DHCPv6 forces no such thing. 464XLAT can still be done via PD though it's really again a carrier thing, enterprises will know if they need 464XLAT the device doesn't need to force that it would be possible. Same story with tethering.
> I wrote "would allow to force", not that it forces.
Ah sorry, must have misread my bad. All the same I'm not seeing how this plays into why it should be forced, the phone is just half the story (the CLAT) and if the enterprise wanted to implement 464XLAT they can PD and run a NAT64 gateway. If they don't then it's not going to work just because the device has enough addresses to be a CLAT as there is no NAT64 gateway. Or if they just want their devices to dual stack or single stack v6 instead why does Android get to decide they need to support something they aren't using?
> Unless you are turning Android device into router, you won't need PD support there. What else you need prefix delegation for?
The prefix for 464XLAT or to allow tethering. DHCPv6-PD is how you do this when you're not using SLAAC.
> All the same I'm not seeing how this plays into why it should be forced, the phone is just half the story (the CLAT) and if the enterprise wanted to implement NAT64 and 464XLAT they can PD. If they don't then it's not going to work just because the device has enough addresses to be a CLAT.
You are right. I've used that as an example of why a device would want more IP addresses than one. One of aspects of treating IPv6-as-IPv4 is the assumption, that one IP is enough. I get it, it simplifies logging/reverse resolution for example, but one IP might be not enough and the example, while not be the best, illustrates the point.
> The prefix for 464XLAT or to allow tethering. DHCPv6-PD is how you do this when you're not using SLAAC.
There is a difference in scope between PD and SLAAC:
With PD you usually hand out /64 (or bigger) carved out of whatever larger subnet you have. So if your upstream gets you /48 or /56, this is the mechanism to hand out smaller subnets to routers downstream.
SLAAC support allows any device in the subnet to claim any address inside the announced prefix it wants, unless it is already taken and other device objects. There is no limit on how many addresses it can claim, but claiming /64 or more would take a while :). Claiming a few is enough for tethering to work.
SLAAC is what you get wit RA by default; only those that want to force DHCPv6 on their network disable it (yes, I tried that once when playing with it. That playing was great way to understand why it was a bad idea).
With DHCPv6, even if it is supported in the network, doesn't mean you also get PD. It remains completely optional. This is a problem with many CPEs (i.e. with a class of devices it was designed for!), that are supposed to support PD, but the support is either buggy or non-existent, thus their users never have more than /64.
If enterprises have use cases then unless there is a good solid alternative example that shows it's universally the case one should always have many:1 it just doesn't seem like there is anything beyond "I think this is the better way therefore I won't let you do the other" backing the choice. If an enterprise wants 1:1 mapping of their devices using DHCPv6 for centralized logging, tracking, monitoring, avoiding device specific RA bugs/implementations/limitations, to consolidate the function while dual stacked, certain DHCP options to be available, or any other reason they have then someone else's non-applicable use case for many:1 isn't reasoning for nullification of those cases. In general I'm against any approach from a product/service that takes the stance "we just know better" and doesn't allow the operator to say otherwise even when I agree it is actually the superior way in most cases.
Yeah PD will give you a much an overkill block but there isn't really much of a block shortage. More importantly the alternative is NAT44 on the CLAT so only a single V6 address is required, this is actually what the standard says implementations "SHOULD" do in the single IP scenario as after all 464XLAT doesn't support peer to peer or inbound anyways. And of course people and orgs are free to simply want DHCPv6 on their devices even if it isn't perfect for every scenario.
A "Android doesn't want to support NAT44 for 464XLAT, assign a prefix the the device for the 464xLAT use case" stance I could totally understand. Or even "Carriers are not asking Android to support DHCPv6 deployment methods on LTE, DHCPv6 will only be supported on wireless" is very understandable. The current stance isn't like these though, it's simply "we don't like that type of deployment so we don't allow it". Or maybe I've just missed something big and there is a reason I should have forced a couple customers away from their use cases.
LTE w/ PDN still uses DHCPv6 PD or SLAAC (or both) https://i.imgur.com/2dKAw5W.png