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

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

Hi Alex,

> -----Original Message-----
> From: Alexandre Petrescu [mailto:[e-mail]]
> Sent: Tuesday, November 03, 2015 1:25 AM
> To: Templin, Fred L; [e-mail]
> Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability discussion - address out of the delegated prefix, on the egress - no DAD
> 
> 
> 
> Le 03/11/2015 16:13, Templin, Fred L a écrit :
> > Hi Alex,
> >
> >> -----Original Message----- From: v6ops
> >> [mailto:[e-mail]] On Behalf Of Alexandre Petrescu
> >> Sent: Monday, November 02, 2015 6:56 PM To: [e-mail] Subject:
> >> Re: [v6ops] draft-ietf-v6ops-host-addr-availability discussion -
> >> address out of the delegated prefix, on the egress - no DAD
> >>
> >>
> >>
> >> 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.
> >
> > "Host sends an RA to the Gateway" doesn't make any sense that I am
> > aware of.
> 
> I should have said "to the link on which the Gateway is present".
> 
> On a shared link, where each such Host is delegated a prefix (no prefix
> advertised by the RA from the gateway), these Hosts will want to reach
> each other directly w/o being ICMP Redirected by the Gateway.  Which
> address should such a Host use to reach its neighbor.

Each host will initially have only a default route pointing to a router on
the shared link and no on-link prefix. For host-to-host communications
on the link, there would need to be a redirect. Is that bad?

Thanks - Fred

> 
> Alex
> 
> >
> > Thanks - Fred
> >
> >>
> >> 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
> >>>
> >>
> >> _______________________________________________ v6ops mailing list
> >> [e-mail] https://www.ietf.org/mailman/listinfo/v6ops
> >