Re: Android (lack of) support for DHCPv6

[Hugo Slabbert <hugo () slabnet com>]

On Wed 2015-Jun-10 12:01:52 +0900, Lorenzo Colitti <lorenzo () colitti com> 
wrote:

> On Wed, Jun 10, 2015 at 3:20 AM, Ray Soucy <rps () maine edu> wrote:
>
> > Clients should support a verity of methods and let network operators choose
> > the solution that fits the environment.  The whole premise for not
> > supporting DHCPv6 seems to be that mobile networks don't need it, but that
> > totally ignores 802.11 which is equally important.
>
> No, the premise is that from a user's point of view, DHCPv6-only networks
> cause regressions in functionality compared to IPv4-only or dual-stack
> networks. For example: IPv4 apps cannot be supported at all due because
> 464xlat cannot be made to work...

Pardon my ignorance as I don't currently have field experience with 
464xlat, but my understanding of the technique is that it is (for the most 
part) dependent on the network cooperating (by providing a DNS64 and NAT64) 
for it to work properly.  If we take the example of an Android handset on a 
campus/enterprise, single stack v6 WLAN, is there any way that 464xlat 
would work without the network operator intentionally providing the 
necessary infrastructure for 464xlat?

E.g. the v6-only network uses SLAAC with RDNSS.  The network operator 
provides resolver addresses to the Android handset via RDNSS, and those 
resolvers aren't DNS64.  The handset queries for ipv4only.arpa, and since 
the resolvers provided by the operator via RDNSS are not DNS64, it gets 
NOERROR rather than a Prefix64-synthesized AAAA.  Result: the handset 
determines there is no DNS64 in the path, and hence 464xlat is not 
possible.

Assume we tweak this to say the handset is very independent-minded and 
queries its own set of DNS64 resolvers.  Further assume that the network 
operator doesn't block DNS queries out to random DNS servers on the 
internet from client devices.  For that to work, the DNS64 has to answer 
recursive queries from this handset from a v6 address within the random 
v6-only network the client device currently finds itself on, so you're 
either looking at needing to provide an open resolver or have some other 
magic to auth the handset to the DNS64 before answering its queries.

Assuming we get this far, the NAT64 indicated in the Prefix64 stuffed into 
the synthesized AAAAs provided by the DNS64 now also needs to provide NAT64 
services to the client device coming from the random v6-only network, again 
by either simply providing free services to whomever comes calling or 
authenticating the handset in some way if it's off-net, originating on the 
random v6-only network in question.

Owing to my ignorange in this space, I'm not aware of too many publicly 
available DNS64/NAT64 services, though some quick searching reveals a 
handful of such sites.  They appear to be mostly research networks, so not 
really anything that I would be comfortable pointing to as a long term 
viable solution at which to point my clients/handsets.  If I'm misinformed 
and e.g. T-Mo plans on making their DNS64/NAT64 infra publicly available 
and hard-coding client devices to point at it, I stand to be corrected.

That is an *awful* lot of assumptions we have to break through to get to a 
working 464xlat service working on a random v6-only WLAN if the 464xlat 
infra is not provided by that WLAN's operator.  So, we either need to 
fulfill a checklist of *several* longshot assumptions/configurations, or 
we're looking at an environment where 464xlat is being provided by the 
network operator for it to have a snowball's chance of working.

If the network operator is providing the 464xlat and they *want* that 
464xlat to be available on this v6-only WLAN, then it is *their* 
responsibility to ensure that their chosen v6 address assignment solution 
(SLAAC or DHCPv6) works with 464xlat and is e.g. capable of PD or multiple 
v6 addresses per client.  If they *choose* to run a v6-only network without 
a v4 access solution and hence with the regressions you listed, is it your 
job to tell them they shouldn't do that or to tell your users they can't 
participate in that network?

> ...and functions such as tethering cannot be implemented because there are 
> no IP addresses to assign to downstream devices.

You had noted on the bug/request:
"It's a fair assumption that many (or at least some) networks that support 
DHCPv6 will limit the number of IP addresses assigned by DHCPv6 to one per 
MAC address."

Your whole argument of DHCPv6 breaking tethering, 464xlat, and other 
technologies that require multiple addresses per interfaces hinges on this 
assumption.  It does not hold true in all cases (multiple posters have 
pointed to solutions such as multiple DUIDs), and in some cases operators 
may be *intentionally choosing* to design the network with such limitations 
in place (research nets; pilot networks; things neither of us have thought 
of yet).  Is it really your assertion that your users would be better 
served *not* being able to connect to these networks *at all* than to 
connect to them on the terms dictated by the network operator?

On a bit of a side note:
Multiple posters on the bug/request are coming from enterprise/campus 
networks that have existing AUPs and enforcement techniques prohibiting 
certain network functions (e.g.  content filtering, restricted outbound 
access, etc.), and would be making an *active choice* as to whether they do 
or do not want to support functions such as tethering, 464xlat, etc.  If I 
find myself on such a WLAN, restricting what I'm trying to do, TBH I write 
it off as something being done intentionally or broken in the network, drop 
off the WLAN and just do it on the cell network.  Does the average user do 
something different?

> Implementing IPv6 NAT can resolve some but not all of these regressions
> (for example, IPv4 apps still cannot be supported). Thus, attempting to
> operate on DHCPv6-only networks a) will create pressure to implement IPv6
> NAT, which causes lots of issues like application complexity, battery life
> issues due to keepalives, etc. b) impose user-visible regressions even if
> we do implement IPv6 NAT.
>
> From a user's point of view, that's just a bad deal, especially since
> IPv4-only networks, dual-stack networks, and IPv6-only networks using SLAAC
> do not have any of those issues. Stateless DHCP and stateful DHCPv6 PD have
> none of those issues, either. If we really need stateful addressing, then
> we should statefully assign prefixes, not single addresses.
>
> I understand that "stateful-one-address-per-device-DHCPv6-only" is easier
> for network operators, but SLAAC really isn't that much harder, and in the
> long run, we'll get more robust apps, better battery life, more innovation,
> and happier users.

And there it is:  "SLAAC is better and it isn't that hard; use it instead."  
It is up to the network operator to make the design choices that best fit 
their network, including if their design goals are to *restrict* certain 
network functions.  You are saying that you know better.

--
Hugo

[1] 
https://www.nanog.org/sites/default/files/wednesday_general_byrne_breakingfree_11.pdf

Attachment: signature.asc
Description: Digital signature