Re: [v6ops] Implementation Status of PREF64

[Owen DeLong <[e-mail]>]

> On Oct 11, 2021, at 10:52 , David Farmer <[e-mail]> wrote:
> 
> 
> 
> On Mon, Oct 11, 2021 at 12:09 PM Owen DeLong <owen=[e-mail] <mailto:[e-mail]>> wrote:
> 
> 
>> On Oct 11, 2021, at 09:37 , David Farmer <farmer=[e-mail] <mailto:farmer=[e-mail]>> wrote:
>> 
>> 
>> 
>> On Mon, Oct 11, 2021 at 1:13 AM Lorenzo Colitti <lorenzo=[e-mail] <mailto:[e-mail]>> wrote:
>> On Mon, Oct 11, 2021 at 1:36 PM Owen DeLong <owen=[e-mail] <mailto:[e-mail]>> wrote:
>> Suppose an OS developer ships a DHCPv6 implementation that requires N addresses and does not enable the IPv6 stack unless it receives all of them. How does that do anything to address statements such as, "my network, my rules" that have been made on this thread? Any operator that wants to assign only one address per device still cannot use such hosts on their network, and can still criticise the implementation for not doing what they want.
>> 
>> At least it provides a possible way forward for networks that don’t want to assign addresses outside of IA_NA or IA_PD to provide addressing to android devices.
>> 
>> Surely a single IA_NA + a routed IA_PD would meet your requirements, right?
>> 
>> IA_PD, even by itself without IA_NA, has none of the concerns in this thread. RFC 7934 explicitly recommends it, actually. Not sure if enterprise network operators can or would want to deploy IA_PD though. Is that something that we can nudge the industry towards?
>> 
>> I think this is a perfectly reasonable option for the general purpose use case, but I will note there is no clear guidance for the use case of IA_PD on Hosts, and even the guidance for the use of IA_PD with routers is somewhat fuzzy or at least incomplete, in my opinion. Nevertheless, this may or may not be reasonable for special or restricted purpose use cases, especially when compliance regimes are required, like PCI or NIST-800-171. I support IA_PA on hosts, but whether or not that is an acceptable replacement for IA_AN and/or IA_TA for all use cases is very much an open question, and not entirely a technical question for that matter.
> 
> At the point where a host solicits and/or accepts IA_PD, it has effectively declared itself to be a router.
> 
> Since most android devices have multiple interface and the ability to provide a “hotspot” capability, they are, in fact, routers.
> 
> Yes, that is technically correct, and I expect most enterprises don't, or at least don't want to, view Android devices as routers. Also, I expect extending the network or "tethering" is not acceptable behavior in a PCI or NIST-800-171 compliance contexts. So, that is part of the challenge for this approach. and why this may not be an acceptable replacement for IA_AN and/or IA_TA.

Agreed… I’m fine with android implementing IA_NA and then duking it out over how many IA_NA/IA_TA addresses it requires to not shut down the IPv6 stack.

Most of the enterprises that I know of holding up IPv6 deployments “because android” are willing to work around this in various ways (It might get a PD, but
the delegated prefix may have significant restrictions or no access to the LAN, etc.)

The clients I’ve talked to are willing to work with the scenario where android only partially breaks on their network as long as it gets at least one IA_NA
address and they can manage that. They don’t mind a user having an android that can open a ticket to be told “yeah, that’s because android’s
iPv6 implementation is broken, here’s Lorenzo’s email.” The don’t want a situation where android just breaks outright because it thinks it created
an address through SLAAC that can’t actually reach anything like it expects (which is what happens currently, because android utterly and in blatant
violation of the RFCs ignores the M bit).

Owen