* 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