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

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

Hello Mukom,

See below for my responses.

Fred
[e-mail]

From: Mukom Akong T. [mailto:[e-mail]]
Sent: Saturday, November 07, 2015 10:21 PM
To: Templin, Fred L
Cc: Brian E Carpenter; Lorenzo Colitti; [e-mail]
Subject: Re: [v6ops] DAD again [was: draft-ietf-v6ops-host-addr-availability discussion]



On 4 November 2015 at 03:30, Templin, Fred L <[e-mail]<mailto:[e-mail]>> wrote:
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).


If N is a node on a LAN, then it's 'WAN' interface is simply its Ethernet or Wireless link and the it's 'provider' could be the subnet router. It's 'LAN' interfaces will be some virtual interfaces belonging to VMs for example.

FLT >>> Let's use as example an enterprise mobile device such as a tablet. The
FLT>>> tablet has a WiFi interface, and let's say it has some virtual interfaces
FLT>>> belonging to VMs using the example you provided. In that case, what
FLT>>> I am calling "WAN" is actually the "WiFI" interface, and what I am
FLT>>> calling "LAN" is the internal virtual interfaces, yes.

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


This is correct, since this WAN interface would have already gotten legitimate non-link-local addresses by other means.

FLT>>> Not necessarily; the WAN interface could be on a link that provides
FLT>>> link-local-only addressing, for example.

The host would then be requesting a PD only for other interfaces apart from the WAN interface.

FLT>>> Correct.

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.


Isn't DAD done on addresses rather than prefixes? DAD will be done on A because it is a full address (128 bits) that will be binded to the LAN interface.

FLT>>> Yes, DAD is done when an address 'A' is assigned to an interface over which
FLT>>> DAD is required - for every such address 'A'.

The language of 'assigning' a prefix to an interface is a bit confusing. The current mechanisms for doing this today (creating a ND PIO for prefix P or having P as some DHCPv6 scope) should not trigger DAD.

FLT>>> Assigning a prefix to an interface does not invoke DAD; only assigning
FLT>>> addresses to an interface over which DAD is required invokes DAD.


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


Correct, DAD is triggered per address per interface of N. Only one address is being given to an interface (the loopback) and DAD will be done for that.

FLT>>> No, loopback is an example of an interface where DAD is not required.

Again the use of 'assign' as applied to a prefix here is confusing . One doesn't 'assign' a prefix to an interface and especially not loopback interface AFAIK.

FLT>>> The correct language per RFC4861 is to "[add the prefix] to the Prefix List" of the
FLT>>> interface to which the prefix is being applied. So, yes, my terminology was loose
FLT>>> but "add the prefix to the Prefix List" is what I intended.

There's no reason to do DAD on LAN/WAN interfaces because no address is being assigned to them.

FLT>>> Right.

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.


I don't think this  is correct. DAD will be done for the WAN interface for address A irrespective of whether P is 'assigned' to it (just as DAD is performed for Link Local Addresses).

FLT>>> RFC4862 says:
FLT>>>    -  An interface whose DupAddrDetectTransmits variable is set to zero
FLT>>>       does not perform Duplicate Address Detection.
FLT>>> This shows that the node has latitude in when it can deem DAD as unnecessary
FLT>>> for a given interface. In this case, the address A is not matched by a prefix in the
FLT>>> Prefix List for the WAN interface and it is known that the prefix will never
FLT>>> never be added to the Prefix List for the WAN interface by node N nor any
FLT>>> node on the WAN link.

If my understanding of your use of 'assigning' P is correct, then it could take the form of P being sent in a PIO of a RA with A = 1. That act has no bearing on whether DAD is performed until a host takes P, generates an IID and tries to assign it to an interface.

FLT>>> The P that I am talking about is one which has been delegated to node N
FLT>>> for that node's exclusive use, and MUST NOT be considered on-link on
FLT>>> the WAN interface. Details of the delegation (whether it be DHCPv6 PD,
FLT>>> manual configuration, or something else) are irrelevant.

Now, stepping back, outside observers (e.g., neighbors on the WAN link)
are completely oblivious to the way 'N' provisions 'P' and 'A' internally.

Correct.

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.


If N is a host on a LAN (which requests a PD for VMS), then its WAN interface is actually a LAN interface. Assuming it already provisioned an address for that WAN interface, it doesn't need to provision A from the delegated prefix. However I don't see any reason why it cannot provision an address A from a sub-prefix (P') where P' is a sub prefix of P (e.g. it gets a /60 P via PD, provisions a /64 P' and assigns address A out of P').

FLT>>> Yes, there is ambiguity in the terms "WAN" and "LAN". What is intended in
FLT>>> this discussion however is that "WAN" means the upstream interface attached
FLT>>> to the provider network and "LAN" means the downstream-attached virtual or
FLT>>> physical interfaces of node N.

DAD must be done for that address A.

FLT>>> No; not at all. A is derived from a prefix P hat is delegated for N's exclusive
FLT>>> use and is guaranteed to not be on-link on the WAN interface. DAD is
FLT>>> therefore not required on the WAN interface



Thanks - Fred
[e-mail]<mailto:[e-mail]>

> -----Original Message-----
> From: v6ops [mailto:[e-mail]<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]<mailto:[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]<mailto:[e-mail]>]
> > Sent: Tuesday, November 03, 2015 1:47 PM
> > To: Templin, Fred L; Lorenzo Colitti
> > Cc: [e-mail]<mailto:[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]<mailto:[e-mail]>]
> > >> Sent: Monday, November 02, 2015 6:55 PM
> > >> To: Templin, Fred L; Lorenzo Colitti
> > >> Cc: [e-mail]<mailto:[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]<mailto:[e-mail]>]
> > >>>> Sent: Monday, November 02, 2015 5:46 PM
> > >>>> To: Templin, Fred L; Lorenzo Colitti
> > >>>> Cc: [e-mail]<mailto:[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]<mailto:[e-mail]>
>
> >    Brian
> >
> > >
> > > Thanks - Fred
> > > [e-mail]<mailto:[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]<mailto:[e-mail]>
> > >>>
> > >>>>     Brian
> > >>>>
> > >>>>>
> > >>>>> Thanks - Fred
> > >>>>>
> > >>>>> From: v6ops [mailto:[e-mail]<mailto:[e-mail]>] On Behalf Of Templin, Fred L
> > >>>>> Sent: Monday, November 02, 2015 5:24 PM
> > >>>>> To: Lorenzo Colitti
> > >>>>> Cc: [e-mail]<mailto:[e-mail]>
> > >>>>> Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability discussion
> > >>>>>
> > >>>>> Hi Lorenzo,
> > >>>>>
> > >>>>> Responses below in "green":
> > >>>>>
> > >>>>> From: Lorenzo Colitti [mailto:[e-mail]<mailto:[e-mail]>]
> > >>>>> Sent: Monday, November 02, 2015 5:04 PM
> > >>>>> To: Templin, Fred L
> > >>>>> Cc: Fred Baker (fred); [e-mail]<mailto:[e-mail]><mailto:[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]><mailto:[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]<mailto:[e-mail]>
> > >>>>> https://www.ietf.org/mailman/listinfo/v6ops
> > >>>>>
> > >>>
> > >
>
> _______________________________________________
> v6ops mailing list
> [e-mail]<mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/v6ops
_______________________________________________
v6ops mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/v6ops



--

Mukom Akong T.

LinkedIn:Mukom<https://www.linkedin.com/in/mukom>  |  twitter: @perfexcellent
------------------------------------------------------------------------------------------------------------------------------------------
"When you work, you are the FLUTE through whose lungs the whispering of the hours turns to MUSIC" - Kahlil Gibran
-------------------------------------------------------------------------------------------------------------------------------------------