Re: [v6ops] [*SPAM* Score/Req: 3.9/3.3] Re: [*SPAM* Score/Req: 3.9/3.3] Re: reclassify 464XLAT as standard instead of info

[Alexandre Petrescu <[e-mail]>]

Le 20/09/2017 à 23:41, Ole Troan a écrit :
>> But you cant have simultaneously CLAT and DHCPv6-PD on the same
>> client. Because CLAT wants that to be a /64 prefix.  It will break
>> when the client gets a /63.
>> 
>> Moreover, design suggestions from CLAT assume that /64 is
>> sufficient. That is wrong - /64 is not sufficient.
>> 
>>> There are lots of cases where more than one solution to the same
>>> problem becomes a standards track RFC.
>> 
>> But one wont prohibit the other.
>> 
>> CLAT prohibits DHCPv6-PD.
> 
> RFC6877 section 6.3 states the opposite.

Ole,

RFCs are one thing, and I agree with you.  And here we do RFCs.

But very much of what RFCs do is from implementations.

It's hard to claim RFC this and RFC that if on the other hand it is 
clear that Android blocks[*] DHCPv6 straight.  It looks like we would 
stick our head in the sand.

Androids are very numerous devices, and RFCs are less numerous.

Here, in this operations group, there is need that Android accepts these
RFCs.

And we need that before we even talk moving an Android-only CLAT from
INFORMATIONAL to something else.

Alex
PS: to support the claim that Android explicitely blocks DHCPv6, I can
provide pointers to public Google pages, numerous requests of DHCPv6
integration in Android (to avoid need of 'rooting' the devices), the
availability of DHCPv6 app in Android store that runs only on WiFi and
must 'root', invitations from competitor OSs to bring DHCPv6 there
instead of Android, and more.

> 
> Ole
>