Re: [v6ops] Implementation Status of PREF64

[Alexandre Petrescu <[e-mail]>]

Le 08/10/2021 à 18:28, David Farmer a écrit :
> 
> 
> On Thu, Oct 7, 2021 at 8:21 AM STARK, BARBARA H <[e-mail] 
> <mailto:[e-mail]>> wrote:
> 
>      > > but hosts should not
>      > > be able to set policies on how many IPv6 addresses they accept.
>      >
>      > Sure they can.  There's nothing stopping a dhcpv6 client from
>     refusing
>      > to enable ipv6 on an interface if it gets less than N addresses.
> 
>     Host policy should be dictated by the people in control of the host
>     and not IETF.
>     IETF has no business restricting the rights of device owners and
>     private networks operators to dictate what devices are allowed to do
>     on their network. This sort of prohibition on device owners and
>     private network admins setting host policy would be 100% harmful.
> 
> 
> Ok, the IETF shouldn't pick N, I'm ok with that. But, does that mean you 
> think it is inappropriate for host implementations to enforce some 
> number of IPv6 addresses be available? Or, are you saying that is 
> completely up to network operators?
> 
> I will note a few things;
> 
> 1. The IETF hasn't picked a value of  N, but it has, through RFC7934, 
> said that N<1.
> 2. In effect Android already enforces, N<1, by only supporting the 
> self-assigned addressing model of SLAAC.
> 3. However, by not supporting a DHCPv6 client, Android doesn't support 
> the managed-assignment addressing model of DHCPv6.
> 
> In an effort to find a compromise that allows Android to support DHCPv6 
> and therefore the managed-assignment addressing model, I'm suggesting it 
> is reasonable for DHCPv6 clients to require the availability of more 
> than one IPv6 address before it enables it's IPv6 stack, and it sounds 
> like Lorenzo is at least open to discuss such a comprise.

"DHCPv6 clients to require availability of more than one IPv6 address"?
or
"Android clients to require availability of ~"?

If the latter, then they have already authored a BCP 'Host Address 
Availability', or something like that.  That requires the availability 
of more than one address.  That BCP is agreed through WG and is twisted 
such as to _almost_ required DHCPv6-PD even though it does not really.

That BCP requires that the provider provides a /64 and it assumes that 
in that /64 there are more than one address.  That BCP forgets that all 
these addresses within a /64 are actually on a single subnet.  But, that 
BCP is good in that it forbids that a single /128 is assigned to a Host. 
  It requires a /64 but at the same time one single /64 is just one 
address, really.

This confusion between one /64 and one address is obvious in many 
contexts.  Operators I talk to ask me why 2^64 addresses are not 
sufficient for my subnets in lab, in cars, etc.  There is no clear 
explanation available in a single at hand, and each time I provide an 
explanation of why /64 is really just one address.

The explanation of why a single /64 is actually one address relies on a 
combination of (1) the 64 IID len mandated by RFC 4291, the 000-prefixed 
addresses, the Ethernet being the basis of all IPv6-over-foo RFCs, on 
the reluctance to propose any non-64 IID, and on the SLAAC specification.

Few people have a broad view of all these documents simultaneously.

> 
> However, it seems that some people are insisting that network operators 
> should be able to assign one and only one IPv6 address per client. 

I have not met any such person, on my part.

It might have been the case in year 2003 when GPRS started some 
deployment, but not anymore, especially since that BCP was written.

All operators assign at least a /64 to a requester.  All have their 
minds in comfort with respect to that BCP, because they think a /64 
equals 2^64 addresses.

> Personally, I think this argument is utterly futile, is creating a 
> deadlock, and it is holding back the deployment of IPv6. However, this 
> deadlock is not caused only by Android not supporting DHCPv6, but it is 
> also caused by those that insist that assigning one and only one address 
> is a valid IPv6 deployment strategy, and that network operators should 
> have ultimate and unilateral control in this matter.
> 
> I'm willing to concede that network operators need to allocate more than 
> one IPv6 address per client.. Furthermore, I think it is very important 
> that all major operating systems allow for both IPv6 address 
> assignment models, self-assigned (SLAAC) and managed-assignment (DHCPv6).

I agree.

> 
>     I'm having visions of IETF becoming not unlike the Texas legislature
>     in its desire to dictate "morality".
>     Barbara
> 
> 
> Insisting the network operators have ultimate and unilateral control of 
> this issue is equally dictating "morality".

I think many operators should still understand better what IPv6 is and 
that Google IPv6 is just a part of it however large and millionaire (in 
terms of Android devices) might it be.

Alex

> 
> Thanks.
> 
> -- 
> ===============================================
> David Farmer Email:[e-mail] <mailto:[e-mail]>
> Networking & Telecommunication Services
> Office of Information Technology
> University of Minnesota
> 2218 University Ave SE        Phone: [phone]
> Minneapolis, MN 55414-3029   Cell: 612-812-9952
> ===============================================
> 
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops
>