
Android’s IPv6 Is Still Broken - altmind
http://lostintransit.se/2020/05/22/its-2020-and-androids-ipv6-is-still-broken/
======
avian
Is it just me or did we actually start regressing in terms of moving things
off IPv4? A couple of years ago I had a working IPv6 connection at home with a
static /64 delegation. I had full IPv6 connectivity at work. Since I had IPv6
connectivity on my laptop ~90% of the time I actually moved a lot of my own
private services to be IPv6 only, since that helped a lot with the usual
background of port scans and other random annoyances.

Now I'm forced to move these things back to IPv4. My home ISP has first moved
off static delegations in favor of dynamic ones via DHCPv6, and then broke
IPv6 routing completely [1] and after a few weeks of me complaining still
seemingly has no interest in fixing it. The place I work for now has no IPv6
connectivity and has no plans for it in the future. Many people I talk with
don't believe that IPv6 is the future and I commonly hear that they have
forcibly disabled it on their computers due to this or that random problem.

[1]
[https://www.tablix.org/~avian/blog/archives/2020/05/on_missi...](https://www.tablix.org/~avian/blog/archives/2020/05/on_missing_ipv6_router_advertisements/)

~~~
pwdisswordfish2
"Many people I talk with don't believe that IPv6 is the future and I commonly
hear that they have forcibly disabled it on their computers due to this or
that random problem."

It is their choice to make not anyone else's. They could be right. It might
not be the future. I am one of those non-believers. I would love an improved
protocol but I do not see IPv6 as the right fit. I think it is no coincidence
that the providers are having problems with offering it to customers.
Networking is complex and error-prone enough without IPv6. It is less so with
IPv6? We know what the IPv6 zealots will say. Beware of "analyses" that focus
solely on benefits without considering costs.

~~~
Dagger2
That also means that you should beware of "analyses" that ignore the costs of
staying on v4 and not doing v6.

NAT, split DNS, VPNs, RFC1918 clashes and renumbering... this stuff isn't
free, and most of it is totally unnecessary when you have enough address
space.

~~~
ipv6fix
While the above are real costs, beware of promises that IPv6 will remove,
reduce or even lower the cost of doing NAT. As long as there is an IPv4
Internet, NAT will be an integral part of any IPv6 deployment.

~~~
Dagger2
It will do all of those things in the right circumstances though.

Dual-stacked eyeball ISPs see over 50% of their traffic go via native v6. If
they're CGNATing then that corresponds to a substantial drop in the amount of
traffic that needs to be CGNATed, and therefore also a corresponding drop in
the cost of the hardware needed to do it.

------
corty
DHCPv6 is broken. Addresses are assigned not based on MAC addresses like in
DHCPv4, but based on UUIDs. Whether the UUID is per host, hardware, boot or
phase of the moon or just random is essentially random, making it totally
useless for any kind of managed network. One might as well just go with the
simpler alternative of using SLAAC. Any admin claiming DHCPv6 is somehow
better for a managed network than the "anarchy" of SLAAC is deluding
themselves.

There are patches and extensions doing MAC address based assignments, but
those are only sparsely supported in network hardware and software.

For the configuration tasks that DHCP also is used for beyond address
assignment, there are better alternatives like anycast, zeroconf and SLAAC
extensions. The only thing that would make DHCP useful again in 2020 would be
strong cryptographic authentication for devices, maybe tied in with 802.1x and
MAC layer encryption.

Therefore I think android is just ahead of the curve in getting rid of DHCPv6.

~~~
elp
From RFC8415: DUID used by a client or server SHOULD NOT change over time if
at all possible.

Read the fine article. The reasons are mostly the same as DHCP on v4. The
ability to assign a specific IP to a specific device for what ever reason:
Adding reverse DNS, tracking given IP to specific device etc.

It might not be useful against hostile actors (just like ipv4 DHCP) but its
perfectly fine for everyone else.

And the specific argument that "Using it might encourage nat on ipv6" is about
as condescending as saying "Using your computer might encourage you to look at
naughty pictures".

Android is now the ONLY operating system that doesn't support this and in many
ways is harming the uptake of IPV6 because of this. Not being able to use
DHCPv6 for Android reduces the chances of an organisation using DHCPv6 for
everything else which reduces the pressure on vendors to fix any DUID bugs.

~~~
corty
The reasons are the same, agreed. However, the mechanisms DHCPv6 provides are
broken beyond what DHCPv4 has historically provided: With DHCPv4, I can deploy
a device by scanning the MAC address barcode and configure the
autoinstall/autoconfiguration. With IPv6, I can't, the DUID and IAID is
assigned on OS installation for the OS DHCPv6 client. The PXE DHCPv6 client
will use a different set of DUID and IAID which sometimes, but not always will
be based on the system GUID. Also, the system GUID will sometimes be printed
on the packaging, often it won't. So the "enterprise unboxing" experience is
atrocious with DHCPv6 anyways. For android devices things are similarly
broken, there is no PXE, however, one can't correlate the IPv4 and IPv6
addresses for one device because the mac address as a shared identifier isn't
usable in DHCPv6 in most cases anyways.

Things could be fixed, but since historically the DHCPv6 standard has not
included those fixes and just added them later as extensions, things look
rather grim for boot firmware and network equipment.

If you need a proper device identification that cannot be faked, you are out
of luck in any case. Therefore my suggestion of a possible next-generation
protocol that would also solve the problem of confirming device identity by
proper cryptographic authentication.

Also, DUID behaviour is not buggy, your own post cites DUID stability as
"SHOULD NOT change". So all the changing DUIDs are conformant. The standards
were broken from the beginning and it is too late to change them now.

~~~
boomlinde
_> With DHCPv4, I can deploy a device by scanning the MAC address barcode and
configure the autoinstall/autoconfiguration. With IPv6, I can't, the DUID and
IAID is assigned on OS installation for the OS DHCPv6 client._

DUID-LL is link layer address based and if your link layer address is a
burned-in MAC you can definitely just scan a barcode, generate a DUID-LL from
it and look for that DUID in your DHCP traffic. Your product _could_ use a
run-time generated DUID-UUID or some other scheme that can't practically be
printed on the product, but on the other hand a DHCP (v4) using product
_could_ randomize its link layer address on every boot to the same effect.

~~~
corty
It usually isn't "my product" but whatever somebody has bought and wants to
bring onto the network.

~~~
boomlinde
That conclusion fundamentally invalidates your original conclusion, though.
The problem isn't that "DHCPv6 is broken" but that you have a use case which a
certain product someone wants to bring onto the network doesn't satisfy.

~~~
corty
The "product" is DHCPv6 and it doesn't solve the use case it is supposed to
solve: managed networks and enterprises.

As for random hardware and software products on the network: It would be nice
for criteria like "proper IPv6 support" to be blockers, but they aren't for
lack of choice. Almost no product out there has anything resembling proper
IPv6 support. Just try some fresh deployment of anything in a IPv6-only
network, I dare you :)

~~~
Dagger2
I run my home desktop and many of my VMs as v6-only and _almost_ everything
works fine.

There are a few things that have a problem (mostly games, for some reason),
but not many. Though I could imagine "enterprise-grade" software, which often
seems to be worse than open-source software, having similar problems.

------
vetinari
> Android still has a broken IPv6 implementation in 2020. By design. They are
> not going to fix it. There are a couple of valid arguments from Google and
> Lorenzo Colitti, but they are pretty weak.

Any care to substantiate, why they are weak?

I'm going to substantiate, why their argument is strong:

1) With DHCPv6, the network operator can force your device to obtain only
single IP address. With SLAAC, you can invent your own, any amount you want,
it just has to be within the same subnet; the /64, smallest subnet, is pretty
huge.

2) For tethering with IPv6, you need multiple IP addresses. You cannot do NAT
as you do with IPv4.

Therefore, with IPv6, telcos could disable the tethering function of the
phones / charge extras, just by suitably configuring their network. It is
obvious, that the major supplier of mobile OS won't allow doing that. Hence,
no DHCPv6.

~~~
steerablesafe
> 2) For tethering with IPv6, you need multiple IP addresses. You cannot do
> NAT as you do with IPv4.

I definitely don't want to see NAT with IPv6, but what makes it impossible?

~~~
garaetjjte
It's possible.

[https://tools.ietf.org/id/draft-mrw-
nat66-00.html](https://tools.ietf.org/id/draft-mrw-nat66-00.html)

[https://www.tldp.org/HOWTO/Linux+IPv6-HOWTO/ch18s04.html](https://www.tldp.org/HOWTO/Linux+IPv6-HOWTO/ch18s04.html)

~~~
qalmakka
NAT66 is indeed possible, and it actually happened to me to use it, but it's
really ugly and clunky to use. This is mostly because you are forced to use
ULAs, which almost every IP stack by default rightfully considers as private
addresses (see RFC 3484). So, if a host has a valid IPv4 route for 0.0.0.0/0
and one for the IPv6 internet that refers to an ULA, its resolver will almost
always prioritise the former route unless you configure it to do otherwise
(i.e. on Glibc you can change how getaddrinfo() works by editing its label
table in /etc/gai.conf).

~~~
joecool1029
Since running wireguard with algo.sh seems to be popular now, this is the
situation you'll end up in with most ipv6 supporting cloud hosting providers.
Digital Ocean only gives 16 ipv6 addresses to the best of my knowledge, others
are probably limited to only 1.

~~~
amaccuish
I moved from OWH because they only assigned a /128 to VPSes, so you're sharing
a /64 with other servers. That was problematic because I run my own email
server, and blacklists for IPv6 tend to be specific to a /64, meaning
neighbouring servers landed my own server on blacklists (i.e. they blanket
blacklist the whole /64). And obvs cloud providers sadly host a lot of
spammers.

In the end, since OVH even after being asked for years offer no option for
/64s on VPSes, I moved to Hetzner, where a VPS gets it's own /64, so only I am
responsible for my mail server's reputation.

~~~
Avamander
I just recently had the same issue, I really don't understand why the fsck
they're doing that s __*. Don 't they have billions of IPv6 addresses?

------
jrockway
I mean, there are two sets of standards. Google picked one, the author picked
the other. The other 2000 words of the article seems to be a rant about how
Google makes money off of ads.

~~~
ken
Isn't it more like "Google picked one, and
Microsoft/Apple/IBM/Linux/*BSD/Cisco/Oracle/HP/... picked the other"? Besides
Google's, the only OSs I see which support IPv6 but not DHCPv6 are VMS,
Symbian, and z/OS.

[https://en.wikipedia.org/wiki/Comparison_of_IPv6_support_in_...](https://en.wikipedia.org/wiki/Comparison_of_IPv6_support_in_operating_systems)

------
eqvinox
> "Initially, Microsoft operating systems did support SLAAC but not RDNSS,
> Android did not want to support DHCPv6. That meant that you couldn’t support
> these two operating systems on the same subnet."

This is incorrect. You can run SLAAC (with or without RDNSS) and stateless
DHCPv6 on the same subnet.

Even more, running DHCPv6 correctly actually _requires_ sending RAs with the O
or M bit set, so you're almost doing SLAAC anyway (setting M disables SLAAC, O
does not.)

Sensible (= stateless) DHCPv6 is an addition to SLAAC/RDNSS to allow pushing
additional config. It is not a replacement.

------
swiley
Just another in the long list of things that’s remained broken in android for
many years.

If you’re worried about novice users getting stuck make defaults but don’t
_break_ things.

------
lmm
It's a bit much to call something "broken" because it won't support the
configuration you want, particularly when that configuration itself could
reasonably be called "broken".

It sounds like DHCPv6 means giving up most of the benefits of IPv6. In which
case better to migrate right than migrate twice.

------
allarm
> You could, of course, run both SLAAC and DHCPv6 simultaneously, but why?

Because it’s what you supposed to do by design?

Here’s a good thread on the IETF IPv6 working group mailing list about it:

[https://mailarchive.ietf.org/arch/msg/ipv6/mqa0qZvlFF8lQWjdZ...](https://mailarchive.ietf.org/arch/msg/ipv6/mqa0qZvlFF8lQWjdZi8UrY7wmLk/)

------
Jonnax
Should we care about enterprises?

It looks like the setup they want will be pretty crap for home users if that
got implemented by ISPs.

You won't be able to tether if ISPs / Mobile networks decide to use the DHCP
to give you a single IP.

This stance of Google's benefits consumers. Howv many consumers are there of
mobile phones and broadband are there in the world compared to workers in a
corporate LAN?

I feel like the question that needs to be asked sometimes is:

Will this enterprise feature negatively affect normal home users.

Imagine your mobile phone network gave you 1 IPv6 address rather than a
subnet.

That is bad. But Google standing firm on not implementing the ability to do
so, has meant that they gotta implement prefix delegation.

~~~
Kronen
If you are going to be fair, the question is how many consumers are there who
use tethering?

~~~
Jonnax
There are more than billion android phones.

How many corporate networks are there?

How many people use laptops and are outside their home and want to use their
mobile network?

------
Kronen
That website is broken too

------
JoeAltmaier
Ok IPV6 is one of those ideas that was obsolete by the time it was deployed.
12 bytes? Why not 16? Why not a UUID for each node? No management; no guessing
who's is who's. Heck, use a new one for every connection.

~~~
poizan42
Without a system with prefixes every router needs to hold the next step for
every single ip address in use in memory all the time and needs to be able to
look them up fast.

~~~
JoeAltmaier
And today we can't do that? That's what I mean by, obsolete before it was
deployed. IPV6 was designed in an age of lesser storage/higher cost memory and
embedded processor power.

And no, not every one. Store the ones routed thru you. That's all you need.
Look them up and keep a cache.

~~~
poizan42
Every node on a local network would need to be able to know whether another
node is on the local network (unless you want all traffic to go through a
router). So do you send arp requests for every ip you try to contact?
Distribute a list through DHCP?

All upstream routers needs to know about your node. So every time someone
somewhere in the world connects a new device a message gets sent up to the
core routers of the internet? And the core routers needs to keep track of
routing tables in the size of billions and be able to look entries up in nano
seconds.

~~~
JoeAltmaier
Thanks, yes those seem like possible algorithms that would work great with
today's technology.

And yes, every time new traffic appears at a 'core' router, entering it into a
cache would be another great algorithm. But they do that now, so no patents
for us.

I love it when somebody 'objects' to a plan, then proceeds to describe the
solution succinctly.

~~~
cesarb
> every time new traffic appears at a 'core' router, entering it into a cache

How does that new traffic appear in the core router? I has to appear in
_every_ core router, otherwise hosts connected to a a core router which didn't
receive that traffic recently wouldn't know how to route to your host. So the
answer would be flooding, which is extremely wasteful of bandwidth and
processing power. Also, it's a _cache_ , which means it expires, so you have
to flood the host announcements constantly (and even if it doesn't expire, you
have core routers going down and being replaced). Once you think over all the
details on how to fix these issues, what you end up with is basically a
routing algorithm, like BGP or others, only replacing the "network" by a
single host.

And once you arrive at a routing algorithm, consider that routing algorithms
have a long history, and have already received a lot of research. That naive
"flooding" algorithm is basically RIP, one of the oldest routing algorithms;
there are good reasons why most people don't use RIP anymore.

~~~
JoeAltmaier
Sure, lots of history. Which is why new solutions are such a hard sell -
everybody quote an authority and concludes 'it has to be this way'.

Traffic appears at core routers because it already gets send there by
peripheral routers as a gateway. Sharing routing information between peer
routers is not unsolvable nor likely onerous.

Strawman solutions (flood constantly) are being deliberately dense. I suspect
because, folks are so very comfortable with what they know, and so very
unwilling to extend themselves. How we got IPV6 in the first place. Which
isn't working either.

~~~
cesarb
> Traffic appears at core routers because it already gets send there by
> peripheral routers as a gateway. Sharing routing information between peer
> routers is not unsolvable nor likely onerous. Strawman solutions (flood
> constantly) are being deliberately dense.

If by "sharing routing information between peer routers" you mean that, when a
router learn of a new host, it shares that information with its peer routers,
which then share that information with their peer routers, that _is_ flooding.
Without flooding, the traffic would not appear at _every_ core router, which
means most routers would not know of your host.

> I suspect because, folks are so very comfortable with what they know, and so
> very unwilling to extend themselves.

I once seriously considered how to make an Internet-scale non-hierarchical
routing protocol, where the host identifier was a cryptographic hash of its
cryptographic public key. The reverse path is easy; once A has successfully
sent a packet to B, all routers in the middle know how to get from B to A. The
forward path (from A to B) is the hard one. Every router knowing every host is
non-viable; consider, for instance, what happens when my phone roams from the
WiFi to the LTE and back (which happens many times per day) - if every router
had to know of that change, for every roaming phone in the world, it would be
enough to overwhelm all the links between them, not to mention their CPUs. I
came to the conclusion that the amount of propagation of the route updates
_must_ be limited for it to be viable, so having every router know of every
host is not possible. Either the routing information must be summarized
somehow (which is what the hierarchical routing used with IPv4 and IPv6 does),
or some other way which does not involve the routers (for instance, path
routing, like MPLS) must be used.

That is, I'm not rejecting your idea because I "feel comfortable" with
hierarchical routing, I'm rejecting your idea because I've already given it
(or something like it) serious consideration, and found it harder than what I
had initially thought.

~~~
JoeAltmaier
No I don't mean the worst interpretation thinkable, when I say 'share that
information'.

Glad to see you've thought of the issues. Now lets brainstorm solutions.

A DNS-style authority with the answer to the routers' questions perhaps.
Updated by the leaf router with some route coloring info for a new leaf node
perhaps. Inquired upon cache miss by core routers? Aged out for frequent
updating (roaming, unique ID per connect, and other short-lived routes).

