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

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

Hi - let's lay this out fully so we can clearly understand the DAD implications.

Let's say a node 'N' has a WAN interface (the one that connects to the provider
network), a loopback interface, and a LAN interface (the one that connects to
tethered hosts/networks). 'N' sends a DHCPv6 PD Solicit over the WAN interface
and receives a prefix delegation 'P'. 'N' can now assign prefix 'P' to either the
loopback interface or the LAN interface, but MUST NOT assign 'P' to the WAN
interface. Now let's look at three cases:

1) 'N' assigns 'P' to the LAN interface and configures an address 'A' from 'P' that
   it also assigns to the LAN interface. 'N' MUST do DAD on the LAN interface for
   address 'A', but does not do DAD on the WAN interface because 'P' is not
   assigned to that interface.

2) 'N' assigns 'A' and 'P' to the loopback interface. 'N' does not do DAD
    on either the LAN or the WAN interface.

3) 'N' assigns 'P' to the loopback interface and assigns 'A' to the WAN interface.
    Again, 'N' does not do DAD on the WAN interface because (again) 'P' is not
    assigned to that interface.

Now, stepping back, outside observers (e.g., neighbors on the WAN link)
are completely oblivious to the way 'N' provisions 'P' and 'A' internally. All an
outside observer can tell is that 'N' emanates packets with source address
'A', and that 'P' is not on link. Therefore, there is no DAD required on the
WAN interface.

Thanks - Fred
[e-mail]

> -----Original Message-----
> From: v6ops [mailto:[e-mail]] On Behalf Of Templin, Fred L
> Sent: Tuesday, November 03, 2015 2:37 PM
> To: Brian E Carpenter; Lorenzo Colitti
> Cc: [e-mail]
> Subject: Re: [v6ops] DAD again [was: draft-ietf-v6ops-host-addr-availability discussion]
> 
> 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.
> 
> Thanks - Fred
> [e-mail]
> 
> >    Brian
> >
> > >
> > > Thanks - Fred
> > > [e-mail]
> > >
> > >>>> Come to that, a manual address might collide.
> > >>>
> > >>> The client itself is the only node that is permitted to assign addresses
> > >>> from the delegated prefix to an interface, so there is no risk of
> > >>> collision unless the client itself is somehow corrupt.
> > >>
> > >> Or another client on the same LAN gets too clever.
> > >>
> > >>    Brian
> > >>
> > >>>
> > >>> Thanks - Fred
> > >>> [e-mail]
> > >>>
> > >>>>     Brian
> > >>>>
> > >>>>>
> > >>>>> Thanks - Fred
> > >>>>>
> > >>>>> From: v6ops [mailto:[e-mail]] On Behalf Of Templin, Fred L
> > >>>>> Sent: Monday, November 02, 2015 5:24 PM
> > >>>>> To: Lorenzo Colitti
> > >>>>> Cc: [e-mail]
> > >>>>> Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability discussion
> > >>>>>
> > >>>>> Hi Lorenzo,
> > >>>>>
> > >>>>> Responses below in “green”:
> > >>>>>
> > >>>>> From: Lorenzo Colitti [mailto:[e-mail]]
> > >>>>> Sent: Monday, November 02, 2015 5:04 PM
> > >>>>> To: Templin, Fred L
> > >>>>> Cc: Fred Baker (fred); [e-mail]<mailto:[e-mail]>
> > >>>>> Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability discussion
> > >>>>>
> > >>>>> On Tue, Nov 3, 2015 at 8:59 AM, Templin, Fred L <[e-mail]<mailto:[e-mail]>> wrote:
> > >>>>> I have one text addition suggestion and one question. On P. 7, in Table 1,
> > >>>>> suggest adding a new final row as follows:
> > >>>>>
> > >>>>>   requires DAD               Yes                  Yes                   No                 N/A
> > >>>>>
> > >>>>> Meaning that multi-addresses configured by SLAAC or DHCPv6 IA_NA/IA_TA
> > >>>>> must use DAD to check for duplicates on the link they were obtained. In a
> > >>>>> multi-addressing environment where millions of addresses are required,
> > >>>>> this could amount to a substantial amount of DAD multicast traffic. On the
> > >>>>> other hand, DAD is not needed for DHCPv6 PD because the network has
> > >>>>> unambiguously delegated the prefix for the node's exclusive use.
> > >>>>>
> > >>>>> I don't think "Requires DAD: No" is correct. Even if the device gets a /64 prefix entirely for its own use, it still needs to do DAD
> > with
> > >>>> any other devices on that /64 (e.g., tethered devices, VMs, etc.).
> > >>>>>
> > >>>>> I'm not opposed to adding a line to the table, though I don't think it provides much value - if we put our mind to it, I'm sure
> we
> > >> could
> > >>>> come up with lots of things we could add to the table that aren't there at the moment. My main concern is that if we add
> > >> something to
> > >>>> the table it needs to be correct.
> > >>>>>
> > >>>>> What I mean is “Requires DAD on the interface over which the prefix was received”,
> > >>>>> but that was too long to fit in the table. Let’s call the interface “A”. If the node gets
> > >>>>> SLAAC addresses or DHCP IA_NA/IA_TA addresses over interface “A”, then it needs
> > >>>>> to do DAD on interface “A” for each such address. If the node gets a DHCPv6 PD
> > >>>>> over interface “A”, however, it does not need to do DAD over interface “A” at all.
> > >>>>>
> > >>>>> If the node assigns the delegated prefix to interface “B”, then you are right that
> > >>>>> that DAD will be required among all tethered devices, VMs, etc. on interface “B”.
> > >>>>> But, there will still be no need for DAD on interface “A”. Does that clarify?
> > >>>>>
> > >>>>> I have a question also on table 1. Under ""Unlimited" endpoints", why does
> > >>>>> it say "no" for DHCPv6 PD? I think it should say "yes" instead, since a prefix
> > >>>>> obtained by DHCPv6 PD can be used to configure an unlimited number of
> > >>>>> addresses on the link over which the prefix was received.
> > >>>>>
> > >>>>> The table is written from the perspective of the network assigning addresses to devices that connect to it. Therefore, it says
> > "no"
> > >>>> because if you use DHCPv6 PD you can't assign address space to an unlimited number of endpoints - you are limited to
> however
> > >> many
> > >>>> /64s you have available.
> > >>>>>
> > >>>>> If you use IA_NA or SLAAC, any network with a /64 subnet has, at least in theory, an "unlimited" number of addresses to
> assign
> > to
> > >>>> clients. Of course, that's only true in theory. In practice, there's going to be a limit due to scaling reasons.
> > >>>>>
> > >>>>> I don’t understand this. True that SLAAC and DHCPv6 IA_NA/IA_TA can be used
> > >>>>> to assign an unlimited number of addresses to interface “A”. But, so can DHCPv6
> > >>>>> PD. When the node receives the delegated prefix (e.g., a /64), it can assign as
> > >>>>> many unique IPv6 addresses as it likes to interface “A”. And again, it need not
> > >>>>> do DAD for any of them.
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>> _______________________________________________
> > >>>>> v6ops mailing list
> > >>>>> [e-mail]
> > >>>>> https://www.ietf.org/mailman/listinfo/v6ops
> > >>>>>
> > >>>
> > >
> 
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops