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 3:46 AM
> To: Templin, Fred L
> Cc: [e-mail]
> Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability discussion - address out of the delegated prefix, on the egress - no DAD
> 
> Hi Fred,
> 
> Le 03/11/2015 19:05, Templin, Fred L a écrit :
> > 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?
> 
> I think it can work with defroute and no onlink prefix.

OK.

> Whether or not is bad can be a matter of number of such redirects.
> Intuitively, it can be very few Redirects if a few Hosts, and it can be
> many Redirects if the Hosts are tethering devices; because each active
> address behind device would need to be be re-directed.

This is why AERO specifies a "prefix redirect" capability where the redirect
covers not just a singleton address but the entire delegated prefix. It is
currently specified for tunnels, but can also be adapted for ordinary links.
RFC6706 is where the prefix redirect was originally specified, and carries
over into AERO(bis).

> But yes the DAD-less aspect of addresses self-formed out of DHCP-PD'ed
> prefixes looks good.

OK.

Thanks - Fred
[e-mail]

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