Re: [v6ops] DAD again [was: draft-ietf-v6ops-host-addr-availability discussion]

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

I guess I've been puzzling over this for ten days, but the PD
discussion made me think about it again. Read to the end to
reload the context and seem my comment:

On 04/11/2015 11:37, Templin, Fred L wrote:
> Hi Brian,
> 
>> -----Original Message-----
>> From: Brian E Carpenter [mailto:[e-mail]]
>> Sent: Tuesday, November 03, 2015 1:47 PM
>> To: Templin, Fred L; Lorenzo Colitti
>> Cc: [e-mail]
>> Subject: DAD again [was: draft-ietf-v6ops-host-addr-availability discussion]
>>
>> Hello Fred,
>>
>> On 03/11/2015 20:10, Templin, Fred L wrote:
>>> Hi Brian,
>>>
>>>> -----Original Message-----
>>>> From: Brian E Carpenter [mailto:[e-mail]]
>>>> Sent: Monday, November 02, 2015 6:55 PM
>>>> To: Templin, Fred L; Lorenzo Colitti
>>>> Cc: [e-mail]
>>>> Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability discussion
>>>>
>>>> Hi Fred,
>>>> On 03/11/2015 14:59, Templin, Fred L wrote:
>>>>> Hi Brian,
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Brian E Carpenter [mailto:[e-mail]]
>>>>>> Sent: Monday, November 02, 2015 5:46 PM
>>>>>> To: Templin, Fred L; Lorenzo Colitti
>>>>>> Cc: [e-mail]
>>>>>> Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability discussion
>>>>>>
>>>>>> On 03/11/2015 14:31, Templin, Fred L wrote:
>>>>>>> Bumping up one level – is it clear to everyone that it is OK to assign addresses
>>>>>>> taken from a DHCPv6 delegated prefix to the interface over which the prefix
>>>>>>> was received?
>>>>>>
>>>>>> If it was legitimately received, I can't see why it wouldn't be OK.
>>>>>
>>>>> OK. When the DHCPv6 server grants a prefix delegation to the client,
>>>>> the server is asserting that that prefix is unique and is now the sole
>>>>> property of the client. So, when you say legitimately received I
>>>>> agree and that is actually a core requirement of DHCPv6 PD.
>>>>> Otherwise, if the DHCPv6 server gave out duplicate prefixes, the
>>>>> routing system would become hopelessly corrupted and address
>>>>> duplication would be the least of our worries.
>>>>>
>>>>>>> And, that DAD is not required for those addresses?
>>>>>>
>>>>>> How is that safe? What is to stop a host running SLAAC once it
>>>>>> sees that prefix in an RA, and hitting the same IID by chance?
>>>>>> At least you need to specify that the A bit must not be set.
>>>>>
>>>>> I am talking about DAD on interface "A" being the interface over
>>>>> which the client receives the prefix delegation. No other node on
>>>>> interface "A" may use the delegated prefix, and no router on
>>>>> interface "A" may advertise the prefix in an RA. The prefix is the
>>>>> sole property of the client that received the PD, so the client is
>>>>> free to assign addresses without needing DAD.
>>>>
>>>> That usage of "may" might confuse some people, so let's pretend
>>>> you used a "MUST NOT" construct instead. I could still construct
>>>> a host stack that would ignore the issue: its logic would be
>>>> "I sent an RS and got no RA/PIO with A=1; but I see traffic from
>>>> prefix 2bad:dead:beef::/64, so I'll do SLAAC and DAD in that prefix."
>>>
>>> The malicious (or otherwise broken) host 'A' could configure any number
>>> of addresses it likes, but it would do so in a vacuum because ingress
>>> filtering will prevent a packet with a source address from a prefix
>>> belonging to host B from being accepted. So, node B has no reason
>>> to fear address duplication by node A.
>>
>> I'm not sure how an ingress filter somewhere upstream would know that
>> the packet came from the "wrong" host. But I don't think that's enough;
>> a duplicate address on the LAN is already a problem in itself.
>>
>>> Also, what if node B in fact did do DAD and A heard it? What is to stop
>>> A from configuring a duplicate address and trying to use it just to mess
>>> up the legitimate operation of node B?
>>
>> Nothing. That, I think, is why the RFCs make DAD mandatory.
>>
>>>
>>> What you are describing is a broken implementation that could only
>>> be employed by a malicious host, and not something that honors
>>> the standards.
>>
>> I don't think it's malicious; it's just trying to get IPv6 connectivity
>> in the face of what it sees as a broken router that isn't responding
>> to RS. But that isn't really my point - my point is that whatever we
>> do, it's impossible to assert that a duplicate address will never arise.
>>
>>> Doing DAD is not going to guard against malicious
>>> hosts.
>>
>> No, but it might allow you to detect the resulting anomaly.
> 
> 
> Actually, the simpler answer to your question is that the node would
> act as a host internally, but appear to be a router on the link from an
> outside observer's perspective. And, routers do not do DAD for the
> source addresses of packets that pass through them.

All routers are also IPv6 nodes, and by definition have an active
IPv6 interface with an address on each of their links. All IPv6 nodes
are supposed to perform DAD on their addresses. RFC 4862 is clear that
this applies even if SLAAC is not used:

   The Duplicate
   Address Detection algorithm is performed on all addresses,
   independently of whether they are obtained via stateless
   autoconfiguration or DHCPv6.

and specifically requires routers to perform DAD:

   In addition, routers are expected to successfully pass the
   Duplicate Address Detection procedure described in this document on
   all addresses prior to assigning them to an interface.

In fact it's particularly important that routers detect any address
collision on any of their interfaces, because downstream hosts or other
routers use each address as a next hop.

I can readily believe that implementations where static addresses are
configured on a simple pt2pt link skip this, but doing so on a broadcast
or NBMA link seems wrong to me.

    Brian

     Brian