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

[David Farmer <[e-mail]>]

On 1/6/16 12:40 , Templin, Fred L wrote:
> 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".

Well not really, what I've been saying all along 
"host-addr-availability" isn't really about DHCPv6 PD that's just one 
way to accomplish it's real intent.  It is the one way that has everyone 
in a tizzy, but its only one way.

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

Yes and No, "host-addr-availability" is BCP telling networks DO NOT 
limit host to one address, one way to do that is assign each host a /64, 
this is one way to accomplish that.  So yes different, but still related.

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

I wouldn't go as far as mutually exclusive, but yes they are separate 
issues, that at least touch each other if not overlap some. :)

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

Yep, we will have to deal with that issue, but lets tweeze things apart 
first then figure out who needs to do what.


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