> On Mon, 9 Jan 2006 09:51:48 -0800,
> Bob Hinden <[EMAIL PROTECTED]> said:
> Sorry for not responding sooner.
No problem, thanks for the response.
> I suspect that at the time we thought that an EUI-48 was equivalent
> to MAC-48. Actually until you sent your email I wasn't aware of
> > The basic issue left is whether we should allow a node to
> send an ICMP error
> > due to the reception of an NA without the SLLAO. The
> reason for sending the
> > ICMP error is to inform upper layers that the communication has
> > failed.
>
> It took me a while to figure out wha
Title: Re: [Ipsec] Discrepency RFC4301 and RFC4305
Hi John,
I am attaching a new thread regarding the
NULL auth algorithm on the IPsec
mailing list.
This should probably clarify what I had
said in the thread “draft-ietf-ipv6-node-requirements-11.txt”.
Thanks,
Vishwas
F
Jinmei,
Sorry for not responding sooner.
On Dec 9, 2005, at 9:53 AM, ext JINMEI Tatuya / 神明達哉 wrote:
I believe this was discussed and clarified before, but I could not
find any pointer, so let me ask here...
It's regarding the "magic number" of 0xFFFE used in the modified
EUI-64 format for th
> The basic issue left is whether we should allow a node to send an ICMP error
> due to the reception of an NA without the SLLAO. The reason for sending the
> ICMP error is to inform upper layers that the communication has
> failed.
It took me a while to figure out what you are proposing. To summ
I know that this is a little off topic. As part of
my thesis I am trying to analyze who is taking part in making the IPv6
standard.
I have collected some data about the 11 years that
the list has been active, and have found that (not surprisingly) 65% of the
messages to this list come from
The IESG has approved the following document:
- 'Optimistic Duplicate Address Detection for IPv6 '
as a Proposed Standard
This document is the product of the IP Version 6 Working Group Working Group.
The IESG contact persons are Margaret Wasserman and Mark Townsley.
A URL of this Internet-
Hi all,
I propose to update the Node Requirements to handle these:
RFC2401 is now obsoleted by RFC4301
RFC2402 is now obsoleted by RFC4302
RFC2404 is now obsoleted by RFC4305
RFC2406 is now obsoleted by RFC4303, RFC4305
RFC2407,2408,2409 are now obsoleted by RFC4306
Changes are:
"AH [
Hi John,
I am referring to the thread and subsequent mails to:
http://130.230.52.14/list-archive/ipsec/msg05573.html
That said regarding algorithms supported, should we just refer to the
RFC's or should we state each of them explicitly. What if the status of
algorithm's change (due to some vulner
Vishwas,
>I see a few more inconsistencies regarding the same RFC:
>
> Since ESP encryption and authentication are both optional, support
> for the NULL encryption algorithm [RFC-2410] and the NULL
> authentication algorithm [RFC-2406] MUST be provided to maintain
> consistency with the
10 matches
Mail list logo
