Re: [v6ops] Focused discussion: draft-ietf-v6ops-unique-ipv6-prefix-per-host

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

Hi David,

> -----Original Message-----
> From: David Farmer [mailto:[e-mail]]
> Sent: Wednesday, January 06, 2016 9:33 AM
> To: Templin, Fred L; Fred Baker (fred)
> Cc: David Farmer; [e-mail]; John Brzozowski
> Subject: Re: [v6ops] Focused discussion: draft-ietf-v6ops-unique-ipv6-prefix-per-host
> 
> On 1/6/16 09:42 , Templin, Fred L wrote:
> > Hi David,
> >
> >> -----Original Message-----
> >> From: David Farmer [mailto:[e-mail]]
> >> Sent: Tuesday, January 05, 2016 5:28 PM
> >> To: Templin, Fred L; Fred Baker (fred)
> >> Cc: David Farmer; [e-mail]; John Brzozowski
> >> Subject: Re: [v6ops] Focused discussion: draft-ietf-v6ops-unique-ipv6-prefix-per-host
> >>
> >> On 1/5/16 18:46 , Templin, Fred L wrote:
> >>> Hi David,
> >>>
> >>>> -----Original Message-----
> >>>> From: David Farmer [mailto:[e-mail]]
> >> ...
> >>>> In my view AERO and this draft are working in slightly overlapping, but
> >>>> different solution spaces.
> >>>
> >>> We don't know that without a use case analysis.
> >>
> >> Well as I read this, this doesn't implement DHCPv6 PD. Furthermore, it
> >> doesn't need any client software.  It uses SLAAC and responds to each
> >> IPv6 ND Router Solicitation with a unicast Router Advertisement with
> >> different prefix for each client.  It provides DNS server info with
> >> RADNS and stateless DHCPv6 if the client send a request.
> >
> > How would an unmodified client know that the prefix it receives in
> > a unicast RA is in fact uniquely assigned for the client's exclusive use
> > and not advertised to any other client?
> 
> That's the whole point the client doesn't need to know its been uniquely
> assigned the whole prefix to assign it the whole prefix. The client
> doesn't actually guarantee the uniqueness anyway.  It's perfectly fine
> for client to be blissfully ignorant of that fact.
> 
> Don't get me wrong I'm not saying I don't want clients to do DHCPv6 PD,
> but they just don't have to just to get a whole /64 assigned to them.
> Are there things the client can do if it knows sure.  Should the client
> know, if it can deal with that knowledge, sure.  However, the client
> doesn't have to know, especially if it doesn't know how to deal with
> that knowledge anyway.

OK, I see - so, the client (not knowing that the prefix has been delegated
for its own exclusive use) autoconfigures addresses from the prefix
(because the PIO had A=1) and assigns them to the WiFi interface and
not to some internal virtual interface. That means that the client needs
to send a multicast NS(DAD) over the WiFi interface for every such
address that it autoconfigures. That is different than what we have
been talking about regarding "host-addr-availability".

One thing I see missing in the draft however is that the client also needs
to do DAD for its link-local address before it does anything else - right?

> >> The client requirement are just standard SLAAC, and RADNS or stateless
> >> DHCPv6, that is it.  No DHCPv6 PD client needed, am I missing something?
> >
> > I think so. An unmodified client receiving a PIO with (A=1, L=0) would have
> > no way of knowing that the prefix is being delegated for its own exclusive
> > use and that the prefix would not be advertised to other clients.
> 
> Why does it have to care?  If it cares, it can do DHCPv6 PD, but it
> doesn't have to.  You seem to think it has to care, why?

OK, so the base specification calls for the client to do SLAAC autoconfiguration
of addresses from the advertised prefix and then assign the addresses to the
WiFi interface after it joins the MLD solicited-node multicast group and sends
a multicast NS(DAD) for each such address. Again, that is different than what
we have been talking about in "host-addr-availability".

> >> There is a bunch of WiFi parts too, just like AERO has tunnel stuff, but
> >> that is fairly standard WiFi infrastructure bits.
> >
> > I thought this work was based on tunneling, too? And, AERO can run fine
> > over WiFi just the same as over any link-layer technology.
> 
> The CAPWAP stuff is its own separate thing, already specified.  There
> may be some unique ways it's used here but that's separate, this is the
> point others have made, and I agree.  There is some stuff that needs to
> be tweezed apart but its a good start.
> 
> >> So, there is a really quick use case analysis for you and I'll
> >> reiterate; in my view AERO and this draft are working in slightly
> >> overlapping, but different solution spaces.
> >
> > I don't see how multi-addressing in the spirit of "host-addr-availabiity"
> > can be supported on an unmodified client. There would need to be
> > additional specification telling the client what to do when it receives
> > a PIO with (A=1,L=0). But then, the document becomes a spec and
> > not an informational. And, clients would have to be modified.
> 
> I disagree with the first part

I was referring to the language in "host-addr-availability" that allows
the client to assign addresses from the delegated prefix to internal
interfaces such as a loopback. For an unmodified client that does
not know that it is being granted the entire prefix based on just
(A=1;L=0) in the PIO, that option is not available. So, really, the
two documents in question need to be interpreted in a mutually
exclusive fashion which I think you indicated in an earlier message.

> but agree with at least part of the second part.
> I'm starting to think that we need a real standards track
> document not just a BCP, at least for PIO with (A=1, L=0) not because it
> needs to really fundamentally makes changes.  But I'm worried some
> people will not take this serious without it being standards track.

I agree with standards-track, but I thought standards-track documents
are out of scope for v6ops?

Thanks - Fred
[e-mail]

> --
> ================================================
> David Farmer               Email: [e-mail]
> Office of Information Technology
> University of Minnesota
> 2218 University Ave SE     Phone: [phone]
> Minneapolis, MN 55414-3029  Cell: 1-612-812-9952
> ================================================