Hacker News Reader

Comment by jeroenhd | Hacker News Reader

This is one example where it's clear IPv6 isn't the problem, actually. A lot of problems with AWS would disappear if they would just support IPv6 like your average budget ISP does.

IPv6 just works. Amazon, Github, and Azure don't. That's not really a problem in most cases (very few people go IPv6 only because it's just not necessary with CGNAT, and even then network translation tricks can put up IPv6<->IPv4 bridges easily). In Amazon's case, they don't even need to bother setting up a real network, they could abuse an fd00::/8 network to mimic their 10.0.0.0/8 network if they wanted to.

Amazon is terrible at implementing modern standards. Just look at how long it took them to support DNSSEC on their domains, and even that didn't exactly roll out great the first time.

View on HN

> IPv6 just works

Only via the herculean efforts of a bunch of people having to literally reinvent the world to deal with it. Everything needs IPv6 support specifically. It's such a mess, if IPv6 has just been identical to IPv4 but with larger addresses we would be on it by now. But no they had to make it their religious crusade to eliminate NAT (and now we have NAT66 so clearly a winner) put IPSec in there which is hilarious in the era of Wireguard and eliminate DHCP which is actually insane and makes a stupid number of assumptions about hosts being able to communicate with one another and actually complicates DNS registration.

Can you imagine how trivial it would have been if you could support both v4 and v6 by just supporting v6 and having 0::v4addr be literally equivalent to ipv4? It would be more difficult to not support v6.

> Can you imagine how trivial it would have been if you could support both v4 and v6 by just supporting v6 and having 0::v4addr be literally equivalent to ipv4? It would be more difficult to not support v6.

And how are you supposed to get the packets back when the client has an address outside that range? You still need to add support everywhere, or have NAT gateways into the areas that lack support.

Automatic mapping of IPv4 addresses exists but it requires support infrastructure just as much as any other method of allowing access to IPv4 devices.

Yes I'm not qualified to really argue the point but naively it never made sense to me that IPv4 was not backwards compatible with IPv6 addressing. You'd think the people on the committees would have foreseen the trouble that would avoid. Telephone companies didn't make you dial the area code for local numbers. Microsoft bent over backwards to make sure that old DOS software still worked on Windows. Linux has a mandate to never break userland. This is not an unfamiliar concept.

IP is a bidirectional protocol, so the correct analogy would be if Microsoft had to make DOS software run on Windows, and Windows software run on DOS.

Remember the error "This program cannot be run in DOS mode"?

IPv4 and IPv6 are unidirectionally compatible using NAT64. The fact that you can make an IPv6 to IPv4 TLS connection using a packet-level translator without breaking the endpoints is quite remarkable, and it wouldn't have been possible if the protocols were too dissimilar.

Hey don't forget about NDP and weird ULA thing which is kinda like private but global.

Oh god how could I forget the "let's just replace ARP and make people using LVS and keepalived change their setups."

What you need to support dual stack? Who would do that…

WAN failover is not fun with ipv6 - npt doesn’t solve things because prefix lengths are variable. You end up back with NAT with basic networks again but with ridiculously large address space. Firewall rules a trickier- you need to both let ICMP through but be careful because some can drive network reconfig. DHCP is second class, and the network can do weird things when port isolations are on. The number of (rotating) ipv6 addresses per host gets silly and makes logging / accountability/ trace back systems more convoluted. Then you’ve got neighbor discovery threats, header extension manipulation stuff. And if multicast isn’t working because of a security configuration that breaks assumptions but you also have multicast amplification stuff.

There is a reason well resourced companies like google cloud have been slow w IPv6 - and it can be even more hair pulling in smaller settings.

> npt doesn’t solve things because prefix lengths are variable

Then you pick your shortest prefix length and use that for your network configuration, no? Nothing in NPT is forcing you to use a /48 or a /56, if your failover uplink only provides you with a /80 for some stupid reason you'll still be able to do translation.

DHCPv6 is supported just fine by everything but Android (for some annoying reason). Even with SLAAC, IP addresses shouldn't rotate, unless you enable Privacy Extensions on your server.

If this were the bakery just around the corner we're talking about, I would've accepted these problems as illogical to even try to overcome, but these are billion dollar companies selling network access. When networking is one of your major streams of revenue, I expect better.

Amazon doesn't support DNSSEC on their domains. If you mean that it's possible to DNSSEC-sign a Route53 domain, yes, but AMAZON.COM isn't signed. Very few tech companies have signed their domains; it's a net negative.

Reply on news.ycombinator.com