On 20/05/2013 08:08, Fernando Gont wrote:
...
>> If the SLAAC node arrives on link first,
>> draft-ietf-6man-stable-privacy-addresses will back off, increment
>> (and presumably remember) the DAD counter and everything will work
>> nominally.
>>
>> To be clear, I think this is probably more of an issue with
>> draft-ietf-6man-ug-00 than
>> draft-ietf-6man-stable-privacy-addresses-07.
>
> At ome IETF meeting I argued that deprecating the u/g bit is fine, but
> one should have a scheme to deal with DAD failures.
>
>
>> This is already hinted at
>> indraft-ietf-6man-stable-privacy-addresses-07, Quote: "Real world
>> data indicates that MAC address reuse is far more common than assumed
>> [HDMoore]. This means that even IPv6 addresses that employ
>> (allegedly) unique identifiers (such as IEEE identifiers) might
>> result in DAD failures, and hence implementations should be prepared
>> to gracefully handle such occurrences." Which I agree with.
>>
>> So in summary, I'd be happy if this was put on a "to consider" list
>> for draft-ietf-6man-ug-0
If you want to specify what to do after a DAD failure, I think that
is a separate issue. All we can reasonably do in draft-ietf-6man-ug is
mention the risk of IID collisions, I think.
Brian
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
