Re: [v6ops] When Android might disconnect because lack of DHCPv6 (was: Implementation Status of PREF64)

[Alexandre Petrescu <[e-mail]>]

Le 12/10/2021 à 02:38, Owen DeLong a écrit :
> 
> 
>> On Oct 11, 2021, at 10:52 , David Farmer <[e-mail] 
>> <mailto:[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).

A similar way in which Android might break because it does not do DHCPv6
is in my home setting in a future tense.

My ISP CPE offers both IPv4 and IPv6; for IPv6 it offers either SLAAC or
DHCPv6 but not simultaneously.

In the near future, when I turn off IPv4 at home definitively, and opt
for DHCPv6 on the ISP CPE, the Android tablet will stop being connected
to the Internet even though the Windows PC will continue.

Towards that future, I intermittently turn off IPv4 on my Windows PC to
see how Internet works from home on IPv6, on SLAAC or on DHCPv6.

I dont know whether I will prefer DHCPv6 or SLAAC at home in the future,
but it might be that SLAAC might not cope with several subnets, and an
automated DHCPv6-PD might help.

Alex

> 
> Owen
> 
> 
> _______________________________________________ v6ops mailing list 
> [e-mail] https://www.ietf.org/mailman/listinfo/v6ops
>