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

["Templin, Fred L" <[e-mail]>]

Hi Brian,

> -----Original Message-----
> From: Brian E Carpenter [mailto:[e-mail]]
> Sent: Monday, November 16, 2015 5:46 PM
> To: Templin, Fred L; Lorenzo Colitti
> Cc: [e-mail]
> Subject: Re: DAD again [was: draft-ietf-v6ops-host-addr-availability discussion]
> 
> 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.

RFC4862 says:

   -  An interface whose DupAddrDetectTransmits variable is set to zero
      does not perform Duplicate Address Detection.

What that means is that the node does not have to do DAD if it has some
good reason for setting DupAddrDetectTransmits to 0. Such as if the
addresses it assigns to the interface are from a prefix delegation it
has received from a delegating router.

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

Using AERO as an example of an NBMA link, AERO Clients autoconfigure
AERO addresses based on the prefix delegations they receive from AERO
Servers. AERO Servers MUST ensure that the prefixes they give out are
unique to the AERO Client recipient and not given out to other AERO
Clients. So, the AERO address (which is really just an IPv6 link-local
address with an IPv6 prefix embedded in the interface identifier) is
guaranteed to be unique and hence no DAD needed.

Thanks - Fred
[e-mail]


>     Brian
> 
>      Brian