> From: [EMAIL PROTECTED] 
(B>
(B> >> Another point. Any reason why autoconfiguration with DAD 
(B> is not possible even if N is > 118? Maybe this was already discussed.
(B> 
(B> Hmm, perhaps your point is something like this:
(B> 
(B>   if N is > 118, simply use the rightmost 118bits of the interface
(B>   identifier following the link-local prefix fe80::/10.  If the
(B>   shortened interface identifier collides with others, DAD will detect
(B>   it as a duplicate of the entire address.  If DAD completes
(B>   successfully, we can simply use the address with the shortened IFID.
(B
(BMy point was simply in response to the comment that manual configuration would be 
(Brequired when N is greater than 118, or more generally N is greater than 128 - prefix 
(Blength.
(B
(B> I don't know if this was discussed in the past, but I'd first like to
(B> point out that this (= shortening the long IFID) can be regarded as a
(B> kind of "manual configuration":
(B> 
(B>    If the interface identifier is more than 118
(B>    bits in length, autoconfiguration fails and manual configuration is
(B>                                                ^^^^^^^^^^^^^^^^^^^^
(B>    required.
(B(from RFC2462, but rfc2462bis will have a 
(B> similar sentence)
(B> 
(B> So, there is nothing that (at least explicitly) prohibits this
(B> operation in RFC2462 or in rfc2462bis.
(B> 
(B> (I would personally not use this type of "semi-auto" manual
(B> configuration in this case though).
(B
(BDon't know about semi-auto. "Manual configuration" is a perfectly clear way of 
(Bexplaining that you can't guarantee address uniqueness in the local subnet if you 
(Bcan't use all of the bits of the supposedly globally unique number (MAC address or 
(Bwhat have you). But there are ways other than manual configuration to select a number 
(B(maybe even at random), and then test it in the local subnet for uniqueness. Unless, 
(Bfor some reason, in this context, that won't work. I was wondering if I was missing 
(Bsomething.
(B
(BBert
(B
(B--------------------------------------------------------------------
(BIETF IPv6 working group mailing list
(B[EMAIL PROTECTED]
(BAdministrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
(B--------------------------------------------------------------------

Reply via email to