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

[Brian E Carpenter <[e-mail]>]

On 16/07/2017 19:58, Mark Smith wrote:
> On 16 July 2017 at 16:41, Pascal Thubert (pthubert) <[e-mail]> 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'm not, for 3 reasons:

1. An address collision is so fatal that we cannot leave it open as
even a remote possibility. It could be literally fatal in a safety-critical
application.

2. Even if we specify pseudo-random IDs, we know that some people will
nevertheless define them manually, which leads to a real risk of
collision due to human error. See 1.

3. A bad actor might create an intentional collision. See 1.

So, DAD needs to work.

> 
> 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.

I'm more than surprised. I think that's a bug and IMHO it should be fixed.

> 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 is correct about the intrinsic issues with relying on layer 2
multicast, but we are stuck with it for a while, so a fix seems
necessary.

    Brian
> 
> 
> 
> 
>> Pascal
>>
>>> Le 15 juil. 2017 à 23:01, Brian E Carpenter <[e-mail]> 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
>>> [e-mail]
>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>> --------------------------------------------------------------------
>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> [e-mail]
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>