Re: IPv6 Routing & ND vs. Addressing, (Was: Re: <draft-ietf-6man-rfc4291bis-09.txt>)

On 16 July 2017 at 16:41, Pascal Thubert (pthubert) <pthubert@cisco.com> wrote:
> Hello Brian:
>
> I'd say that DAD detecting a duplication is not a failure; just doing its job right.
>
> The DAD failure that hurts is DAD false negative like can be easily obtained on wireless  because the reliability of the multicast is largely different from that of wire.
>
> Are we ready to say that addresses that are generated with enough randomness in them do not need DAD?
>

I looked up RFC4862 to find out how many DAD attempts there were,
because I'd assumed 3 to 4, and if so, then if that many attempts
failed, I'd say the link is well beyond its capacity. Something would
need to be done to remedy a link capacity problem in that case.

I was surprised to find, as Ole mentioned, the number of attempts was
only 1 rather than 3 or 4.

One thing it does say about that value is:

Default: 1, but may be overridden by a link-type specific value in
      the document that covers issues related to the transmission of IP
      over a particular link type (e.g., [RFC2464]).

Although Wifi is emulating Ethernet at the IPv6 interface layer, it
doesn't have the same multicast characteristics, so perhaps there
should be an IPv6 over Wifi RFC that specifies IPv6's parameters to
suit.

> Pascal
>
>> Le 15 juil. 2017 à 23:01, Brian E Carpenter <brian.e.carpenter@gmail.com> a écrit :
>>
>> On 16/07/2017 01:39, Philip Homburg wrote:
>>>> This is backwards. The goals of pseudo-random IIDs are to reduce the
>>>> probability that scanning attacks find hosts, and to reduce the risk
>>>> of IIDs being used to breach privacy.
>>>>
>>>> If these goals are met, the collision probability will in any case
>>>> be low, so DAD failure will be exceedingly rare.
>>>
>>> I completely disagree. A collision is fatal. We are nowhere near transparently
>>> handling all collisions. At best we can hope that DAD can make one node
>>> continue unaffected.
>>
>> I'm confused.
>>
>> Firstly, do we have any experimental evidence that collisions
>> are a real operational problem? (Obviously, MAC address collisions are
>> disastrous at layer 2 anyway, so although IPv6+(Modified EUI-64) needs to
>> detect them, they are irrelevant to the current discussion.)
>>
>> Secondly, if a collision does occur with IPv6+(pseudo-random IID),
>> recovery is obvious: after DAD failure, generate a new pseudo-random
>> IID and try again. This is perfectly compatible with RFC4862 section 5.5
>> and is specfied in RFC7217 for stable IIDs and in RFC4941 for privacy
>> addresses.
>>
>>    Brian
>>
>>>
>>> In contrast, people have been scanning my IPv4 ranges for the past 20 years
>>> or so. That may be annoying. That may amplify attacks opportunities. But
>>> in it self it is not fatal.
>>>
>>>
>>> .
>>>
>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> ipv6@ietf.org
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------