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

[David Farmer <[e-mail]>]

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.

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

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

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