alt Hacker NewsIPv6 is a recursive WTF. It might _look_ like a conservative expansion of IPv4, but it's really not. A lot of operational experience and practices from IPv4 don't apply to IPv6.
For example, in IPv4 each host has one local net address, and the gateway uses NAT to let it speak with the Internet. Simple and clean.
In IPv6 each host has multiple global addresses. But if your global connection goes down, these addresses are supposed to be withdrawn. So your hosts can end up with _no_ addresses. ULA was invented to solve this, but the source selection rules are STILL being debated: https://www.ietf.org/archive/id/draft-ietf-6man-rfc6724-upda...
Then there's DHCP. With IPv4 the almost-universal DHCP serves as an easy way to do network inspection. With IPv6 there's literally _nothing_ similar. Stateful DHCPv6 is not supported on Android (because its engineers are hell-bent on preventing IPv6). And even when it's supported, the protocol doesn't require clients to identify themselves with a human-readable hostname.
Then there's IP fragmentation and PMTU that are a burning trash fire. Or the IPv6 extension headers. Or....
In short, there are VERY good reasons why IPv6 has been floundering.
Replies
> Then there's IP fragmentation and PMTU that are a burning trash fire.
It's not significantly worse on v6 compared to v4. Yes, in theory, you can send v4 packets without DF and helpful routers will fragment for you. In practice, nobody wants that: end points don't like reassembling and may drop fragments; routers have limited cpu budget off the fast path and segment too big is off the fast path, so too big may be dropped rather than be fragmented and with DF, an ICMP may not always be sent, and some routers are configured in ways where they can't ever send an ICMP.
PMTUd blackholes suck just as much on v4 and v6. 6rd tunnels maybe make it a bit easier to hit if you advertise mtu 1500 and are really mtu 1480 because of a tunnel, but there's plenty of derpy networks out there for v4 as well.
> For example, in IPv4 each host has one local net address, and the gateway uses NAT to let it speak with the Internet. Simple and clean.
I assume you mean "interface", not "host". Because it's absolutely not true that a host can only have one "local net address".
EDIT: a brief Google also confirms that a single interface isn't restricted to one address either: sudo ip address add <ip-address>/<prefix-length> dev <interface>
How do the working IPv6 deployments cope with these issues?
The reason: Skill issue.
> For example, in IPv4 each host has one local net address, and the gateway uses NAT to let it speak with the Internet. Simple and clean.
That's only true for smalltime home networks. Try to merge 2 company IPv4 networks with overlapping RFC1918 ranges like 10.0.0.0/8. We'll talk again in 10 years when you are done sorting out that mess ;)
> In IPv6 each host has multiple global addresses. But if your global connection goes down, these addresses are supposed to be withdrawn. So your hosts can end up with _no_ addresses.
Only a problem for home users with frequently changing dialup networks from a stupid ISP. And even then: Your host can still have ULA and link-local addresses (fe80::<mangled-mac-address>).
> ULA was invented to solve this, but the source selection rules are STILL being debated: https://www.ietf.org/archive/id/draft-ietf-6man-rfc6724-upda...
RFC6724 is still valid, they are only debating a slight update that doesn't affect a lot.
> Then there's DHCP.
DHCPv6 is an abomination. But not for the reasons you are enumerating.
> With IPv4 the almost-universal DHCP serves as an easy way to do network inspection.
IPv4 DHCP isn't a sensible means to do network inspection. Any rougue client can steal any IP and MAC address combination by sniffing a little ARP broadcast traffic. Any rogue client can issue themselves any IPv4 address, and even well-behaved clients will sometimes use 169.254.0.0/16 (APIPA) if they somehow didn't see a DHCP answer. If you want something sensible, you need 802.1x with some strong cryptographic identity for host authentication.
> Stateful DHCPv6 is not supported on Android (because its engineers are hell-bent on preventing IPv6).
Yes, that is grade-A-stupid stubborness. On the other hand, see below for the privacy hostname thingy in IPv4 and the randomized privacy mac addresses that mobile devices use nowadays. So even if Android implemented stateful IPv6, you will never be reliably able to track mobile devices on your network. Because all those identifiers in there will be randomized, and any "state" will only last for a short time. If you want reliable state, you need secure authentication like 802.1x on Ethernet or WPA-Enterprise on Wifi, and then bind that identity to the addresses assigned/observed on that port.
> With IPv6 there's literally _nothing_ similar.
Of course there is. DHCPv6 can do everything that IPv4 DHCP can do (by now, took some time until they e.g. included MAC addresses as an option field). But in case of clients like Android that don't do DHCPv6 properly, you still have better odds in IPv6: IPv6 nodes are required to implement multicast (unlike in IPv4 where multicast was optional). So you can just find all your nodes in some network scope by just issuing an all-nodes link-local multicast ping on an interface, like:
> ping6 ff02::1%eth0
There are also other scopes like site-local: > ping6 ff05::1%eth0 https://www.iana.org/assignments/ipv6-multicast-addresses/ip...
(The interface ID (like eth0, eno1, "Wired Network", ...) is necessary here because your machine usually has multiple interfaces and all of those will support those multicast ranges, so the kernel cannot automatically choose for you.)
> And even when it's supported, the protocol doesn't require clients to identify themselves with a human-readable hostname.
DHCP option 12 ("hostname") is an option in IPv4. Clients can leave it out if they like. There is also such a thing as "privacy hostname" which is a thing mobile devices do to get around networks that really want option 12 to be set, but don't want to be trackable. So the hostname field will be something like "mobile-<daily_random>".
What you skipped are the really stupid problems with DHCPv6 which make it practically useless in many situations: DHCPv6 by default doesn't include the MAC address in requests. DHCPv6 forwarders may add that option, but in lots of equipment this is a very recent addition still (though the RFC is 10 years old by now). So if you unbox some new hardware, it will identify by some nonsensical hostname (useless), an interface identifier (IAID, useless, because it may be derived from the MAC address, but it may also be totally random for each request) and a host identifier (DUID, useless, because it may be derived from the mac address, but it may also be totally random for each request). Whats even more stupid, the interface identifier (IAID) can be derived from a MAC address that belongs to another interface than the one that the request is issued on. So in the big-company usecase of unboxing 282938 new laptops with a MAC address sticker, you've got no chance whatsoever to find out which is which, because neither IAID nor DUID are in any way predictable. You'll have to boot the installer, grab the laptop's serial number somewhere in DMI and correlate with that sticker, so tons of extra hassle and fragility because the DHCPv6 people thought that nobody should use MAC addresses anymore...
> For example, in IPv4 each host has one local net address, and the gateway uses NAT to let it speak with the Internet. Simple and clean.
No, that’s not the IPv4 design. That’s an incredibly ugly hack to cope with IPv4 address shortage. It was never meant to work this way. IPv6 fixes this to again work like the original, simpler design, without ”local” addresses or NAT.
> In IPv6 each host has multiple global addresses.
Not necessarily. You can quite easily give each host one, and only one, static IPv6 address, just like with old-style IPv4.