in ranges of address can be used to
>guarantee that collision will not happen.
>
>-Original Message-
>From: Elwyn Davies [mailto:[EMAIL PROTECTED]
>Sent: Wednesday, July 20, 2005 11:29
>To: [EMAIL PROTECTED]
>Cc: Elwyn Davies; ipv6@ietf.org; Pashby, Ronald W CTR NSWCDD-B35
al Message-
From: Elwyn Davies [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 20, 2005 11:29
To: [EMAIL PROTECTED]
Cc: Elwyn Davies; ipv6@ietf.org; Pashby, Ronald W CTR NSWCDD-B35
Subject: Re: Comments on draft-ietf-ipngwg-icmp-name-lookups-12.txt
JINMEI Tatuya / 神明達哉 wrote:
On Wed, 20 Jul
: Elwyn Davies; ipv6@ietf.org; Pashby, Ronald W CTR NSWCDD-B35
Subject: Re: Comments on draft-ietf-ipngwg-icmp-name-lookups-12.txt
JINMEI Tatuya / 神明達哉 wrote:
>>>>>>On Wed, 20 Jul 2005 11:43:45 +0100,
>>>>>>Elwyn Davies <[EMAIL PROTECTED]> said:
>&g
JINMEI Tatuya / 神明達哉 wrote:
On Wed, 20 Jul 2005 11:43:45 +0100,
Elwyn Davies <[EMAIL PROTECTED]> said:
As I said in my previous posting, I don't think you ought to think
of either solicited node multicast groups or these groups as
dynamically allocated. The groups exist sta
Stig Venaas wrote:
Please don't send HTML, hard for me to read and quote.
Clients should definitely do an MLD join for this group (just as they
should for the solicited multicast address used for ND). My experience
is also that clients do join both the "solicited" and the "name-lookup".
I wou
(Forgot to mention this)
> On Wed, 20 Jul 2005 11:43:45 +0100,
> Elwyn Davies <[EMAIL PROTECTED]> said:
> It occurs to me that there is another issue related to one we have discussed
> for Neighbour Discovery: A node that implements the response side of name
> lookup has to join the rele
> On Wed, 20 Jul 2005 11:43:45 +0100,
> Elwyn Davies <[EMAIL PROTECTED]> said:
> As I said in my previous posting, I don't think you ought to think
> of either solicited node multicast groups or these groups as
> dynamically allocated. The groups exist statically whether any
> nodes are
Please don't send HTML, hard for me to read and quote.
Clients should definitely do an MLD join for this group (just as they
should for the solicited multicast address used for ND). My experience
is also that clients do join both the "solicited" and the "name-lookup".
I would be interested to hear
JINMEI Tatuya / 神明達哉 wrote:
On Mon, 18 Jul 2005 14:13:54 -0500,
"Pashby, Ronald W CTR NSWCDD-B35" <[EMAIL PROTECTED]> said:
In the second paragraph of section 5 it reads:
"Compute the
> On Mon, 18 Jul 2005 14:13:54 -0500,
> "Pashby, Ronald W CTR NSWCDD-B35" <[EMAIL PROTECTED]> said:
> In the second paragraph of section 5 it reads:
> "Compute the MD5 hash [11] of the first label of the Subject Name --
> the portion beginning with the first one-octet length field and up
[mailto:[EMAIL PROTECTED]
Sent: Monday, July 18, 2005 19:48
To: Pashby, Ronald W CTR NSWCDD-B35
Cc: ipv6@ietf.org
Subject: Re: Comments on draft-ietf-ipngwg-icmp-name-lookups-12.txt
Consider:
- The primary point of RFC3307 is to make sure that you can get a unique
IPv6 multicast address - The
Consider:
- The primary point of RFC3307 is to make sure that you can get a unique
IPv6 multicast address - The Layer 2 non-clash is a bonus.
- The addresses are (probably) not taken from the spaces to which
RFC3307 applies (they are 'traditional' P=0 addresses - I believe the
intent was that R
Title: Comments on draft-ietf-ipngwg-icmp-name-lookups-12.txt
In the second paragraph of section 5 it reads:
"Compute the MD5 hash [11] of the first label of the Subject Name -- the portion beginning with the first one-octet length field and up to, but excluding, any subsequent length
13 matches
Mail list logo