* Lorenzo Colitti
On the other hand, there exist applications *today* that do require DHCPv6. One such example would be MAP, which IMHO is superior to 464XLAT both for the network operator (statlessness ftw) as well as for the end user (unsolicited inbound packets work, no NAT traversal required). MAP is provisioned with DHCPv6 (I-D.ietf-softwire-map-dhcp), so without DHCPv6 support in Android, MAP support in Android is a non-starter.
Support for the DHCPv6 protocol, or support for assigning addresses from IA_NA?
I'm not 100% certain, but you can possibly run MAP without IA_NA. But I think you'll need the CE to be configured with a predictable IPv6 address so that the BR knows where to send the IPv6-encapsulated or -translated IPv4 packets. I don't see how that would work with SLAAC. But I'm not a MAP expert, so I'm open to be educated otherwise. Anyway, here's a (hopefully constructive) suggestion on a way forward: * Implement DHCPv6 client support (IA_NA, IA_TA, IA_PD .. the works) * Upon network connection, request 2x IA_NA and 1x IA_PD (in addition to SLAAC): ** If you get addressing from SLAAC and/or IA_PD, accept the configuration and connect to the network. *** If apps/services require additional addresses, self-assign them from the on-link/delegated prefix as needed. ** If you get 2x IA_NA, accept the configuration and connect to the network. *** If apps/services requires additional addresses, request additional IA_NA as needed. **** If additional IA_NAs are declined either warn user or trigger Android's already existing «avoided bad network» functionality. ** If you get no SLAAC or IA_PD, and IA_NA <= 1, then refuse to connect to the network (or, for a dual-stack network, connect IPv4-only). (I.e., same behaviour as on a DHCPv6-only network today.) Why N=2? Because it's >1, and what you seem to be worried about is operators using N=1 without thought ("because that's what we did in IPv4"). N=2 will confirm that's not the case for the given network, so I think confirming N=2 gives a much stronger indication that the network allows N=<something reasonable> than confirming N=1. That said, I doubt that you can rely on the network accepting N=<hundreds or more>, neither for DHCPv6 IA_NA *nor* SLAAC, due to neighbour table limitations and DAD overhead (both delay and packets). If the future applications we're imagining needs IPv6 addresses in that ballpark (which isn't *that* far-fetched - say a new address per connection, process, app, whatever), IA_PD is the only mechanism we have today that will work. If you start supporting IA_PD, my bet networks are going to start offering it - just like when you added 464XLAT. Tore