Subject: RE: new rev. of rfc2462bis will be coming

From: "Manfredi, Albert E" <[email-masked]>
Date: Sun, 5 Sep 2004 19:17:47 -0400

> From: [email-masked] 
>
> >> Another point. Any reason why autoconfiguration with DAD 
> is not possible even if N is > 118? Maybe this was already discussed.
> 
> Hmm, perhaps your point is something like this:
> 
>   if N is > 118, simply use the rightmost 118bits of the interface
>   identifier following the link-local prefix fe80::/10.  If the
>   shortened interface identifier collides with others, DAD will detect
>   it as a duplicate of the entire address.  If DAD completes
>   successfully, we can simply use the address with the shortened IFID.

My point was simply in response to the comment that manual configuration would be required when N is greater than 118, or more generally N is greater than 128 - prefix length.

> I don't know if this was discussed in the past, but I'd first like to
> point out that this (= shortening the long IFID) can be regarded as a
> kind of "manual configuration":
> 
>    If the interface identifier is more than 118
>    bits in length, autoconfiguration fails and manual configuration is
>                                                ^^^^^^^^^^^^^^^^^^^^
>    required.
(from RFC2462, but rfc2462bis will have a 
> similar sentence)
> 
> So, there is nothing that (at least explicitly) prohibits this
> operation in RFC2462 or in rfc2462bis.
> 
> (I would personally not use this type of "semi-auto" manual
> configuration in this case though).

Don't know about semi-auto. "Manual configuration" is a perfectly clear way of explaining that you can't guarantee address uniqueness in the local subnet if you can't use all of the bits of the supposedly globally unique number (MAC address or what have you). But there are ways other than manual configuration to select a number (maybe even at random), and then test it in the local subnet for uniqueness. Unless, for some reason, in this context, that won't work. I was wondering if I was missing something.

Bert

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Mon, 06 Sep 2004 23:22:14 +0900

>>>>> On Sun, 5 Sep 2004 19:17:47 -0400, 
>>>>> "Manfredi, Albert E" <[email-masked]> said:

> Don't know about semi-auto. "Manual configuration" is a perfectly
> clear way of explaining that you can't guarantee address uniqueness
> in the local subnet if you can't use all of the bits of the
> supposedly globally unique number (MAC address or what have
> you). But there are ways other than manual configuration to select a
> number (maybe even at random), and then test it in the local subnet
> for uniqueness. Unless, for some reason, in this context, that won't
> work. I was wondering if I was missing something.

I'm not really sure if I understand your point, but what RFC2462 and
rfc2462bis are trying to say is, in my understanding, that if
interface_id_len + link_local_prefix_len > 128 then we cannot use the
procedure described in section 5.3 of RFC2462 for creating a
link-local address.  Any other attempts to create a different
link-local address (using a random ID or a shorten IFID, or whatever)
are regarded as "manual configuration" in this context, and it is
beyond the scope of RFC2462/2462bis to describe the details of
alternative "manual" approaches.

At least to me this is pretty clear, and, specifically, I don't see
any need for changing rfc2462bis further on this matter.  If you want
to introduce a change in rfc2462bis for this point, please explicitly
say so (and concrete suggested text would be highly appreciated in
this case).

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]