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