Android (lack of) support for DHCPv6

George, Wes wesley.george at twcable.com
Wed Jun 10 13:25:20 UTC 2015


On 6/9/15, 11:01 PM, "Lorenzo Colitti" <lorenzo at colitti.com> wrote:


>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, and functions such as tethering cannot be
>implemented because there are no IP addresses to assign to downstream
>devices.
>
>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.

WG] ok, I *finally* understand the distinction you're making here, despite
the weird way you're making the argument. You're equating DHCPv6-only with
"single stack IPv6", which is odd, because you're simultaneously waving
away concerns about android not working on IPv6-only networks because it
won't be able to get addresses by saying that you assume that no one is
turning off IPv4 on their network tomorrow since that'll break lots of
other things.

The reality is that this whole argument is needlessly conflating multiple
things in a way that isn't helpful, so I'm going to try to break this into
pieces in order to make forward progress and try to get us away from what
is devolving into a debate that is equal parts religion and kool-aid
drinking contest among IPv6 übernerds.

1) there are *dual stack* networks out there that happen to support IPv4
and IPv6 via DHCP only (I.e. No SLAAC). This is a fact, and you may not
like it, but there's simply no way that you're going to be able to change
it in 100% of the situations.
Most of the folks involved in this discussion are asserting that Android
needs to support those so that the things that can work over IPv6, even
with just a single address, will.

2) on a dual stack network, when the device gets fewer IPv6 addresses than
it wants/needs, it can continue using the same solution it uses on an IPv4
network, even if it's a sub-optimal NAT-based solution. Having a single
IPv6 address is still a net improvement over where we are today, where
100% of the traffic has to be on IPv4 and probably behind multiple layers
of NAT.

3) 464xlat being broken is a non-issue on a dual-stack network, since it
is expressly designed to act as a shim for IPv4-dependent apps on an
IPv6-only network.

4) At some point in the future, there will be IPv6-only networks.
At that time, Android will no longer be able to rely on IPv4 as a fallback
mechanism, and if it can only get one address, that will break things.
Definitely a problem, but not necessarily one that has to be solved
immediately, since anyone doing an IPv6-only network today already knows
that they need to make a lot of allowances for transition mechanisms and
other things to prevent breakage, or are using IPv6-only in tightly
controlled situations where there is no breakage because they can ensure
100% IPv6 support among the things using the network.

5) there are multiple possible ways for a device to get multiple IPv6
addresses if it needs them, including DHCPv6 with multiple IA_NA requests,
a DCHPv6-PD request, SLAAC, or some sort of bridging that allows multiple
virtual interfaces to use the same physical interface, such as the simple
type of hypervisor networking that allows multiple VMs to get DHCP
addresses assigned from the same network.

So what this means is that there is a draft to be written about the need
for multiple address support on IPv6 networks for mobile devices,
enumerating the ways that they use those multiple addresses, and how it
differs from today's IPv4-only or dual-stack implementations, along with a
big discussion on the breakage that can happen on IPv6-only networks if a
device can't get the addresses it needs. It is a fool's errand to assume
that we can dictate one and only one solution to #5 (regardless of one's
perceived influence and market power), so the best we can do is to
document the preferred one(s) and hope that we've made a good enough case
or made them easy enough to use that the majority of network operators do
support them.
Sunset4 is the right place for that draft, so let's discuss it at the next
IETF.

However, the spectre of #4 does NOT mean that DHCPv6 is unusable because
it would break things today on a dual-stack network, so you need to stop
trying to imply that, and stop trying to optimize for use cases that you
yourself admit basically don't exist today by blocking support for
something that we could use today to have more devices using IPv6, were it
available.

Thanks,
Wes George

Anything below this line has been added by my company’s mail server, I
have no control over it.
-----------


This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.


More information about the NANOG mailing list