Re: [v6ops] draft-ietf-v6ops-host-addr-availability discussion - address out of the delegated prefix, on the egress - no DAD

[Alexandre Petrescu <[e-mail]>]

Le 03/11/2015 10:31, Templin, Fred L a écrit :
> 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? And, that DAD is not required for those addresses?

This indeed new enough at least to me.

I agree that if the prefix is delegated for Host with DHCP-PD then it 
has a tighter bind to that Host, tighter than a prefix _advertised_ to 
it with an RA.

In that sense, certainly yes the Host may self-form and assign an 
address on its interface over which the application DHCP-PD received it 
earlier.

And, since the prefix is administratively unique, it would make little 
sense for the Host to DAD that address on that interface.

Moreover, it would bring some advantages for privacy.  Privacy addresses 
as we know them make only the IID variable, while still keeping a 
trackable prefix (the advertised prefix).  With this way of prefix 
delegation, the Host may decide more ways to obfuscate its identity: use 
sometimes the allocated prefix, other times the advertised prefix, in 
some hard-to-detect sequence.

But, if a Host forms an address out of the delegated prefix and wants to 
talk to its Gateway on that interface, maybe it wants to send an RA to 
that Gateway so the Gateway forms an address out of the delegated prefix 
too.  At that point DAD would be needed.

Alex

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