Android (lack of) support for DHCPv6

[tore at fud.no (Tore Anderson)]

* 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