Hacker News Reader

Comment by dijit | Hacker News Reader

And yet, when I beg my google cloud rep for IPv6 addresses on instances (or on anything that isn’t the load balancer) I get told that it is not on the immediate roadmap.

The cloud providers have pushed back ipv6 adoption so hard imo. At least native ipv6 access.

I know they’ve thrown in some token support and you /can/ make something work; but compared to VPS providers which consistently deliver machines with IPv6 addresses by default- it’s a huge barrier to adoption. You have to really /want/ it, and most people don’t see the value. Unless it’s a backend for an iOS App.

It really frustrates me.

View on HN

Azure's IPv6 "support" saddens me. It's just painful how minimal their support is.

For one, they NAT all IPv6 traffic.

Let that sink in. Let it percolate. Mull over the fact that the entire purpose of IPv6 is to eliminate NAT, and that it's practically impossible to get an IPv6 NAT-ing network device.

Microsoft must have had to write their own, custom network load balancers to NAT IPv6. It's madness.

Oh, if that's not bad enough, they also hand out ludicrously small /124 ranges of just 16 addresses. Sixteen! Not sixteen trillion or some crazy huge number like that, which is what I've got on my home internet. Sixteen. Six and ten.

But no worries, right? Just allocate more blocks! Bzzt... that would run up against the subscription IP limits with just 100 addresses.

Okay, fine, just because my lab environment needed more than a couple of addresses doesn't mean that everybody is so wasteful with the precious IPv6 address pool. Some people can constrain themselves to just a handful of addresses, and don't have a problem with any of the above.

Except that when Azure finally adds proper, native IPv6 support, whatever work their early adopter customers have done will have to be thrown out and redone. Subnets. DNS addresses. Load balancer rules. NAT rules. Security Groups. Everything will have to be revisited.

So why would you bother?

https://docs.microsoft.com/en-us/azure/virtual-network/ipv6-...

We've been experimenting with Azure's IPv6 support at work recently. The fact it uses NAT is insane - though we could tolerate that. Even worse is that the NAT is broken - it doesn't update the ICMPv6 checksum when it rewrites the source/destination address, so the machines on both ends drop all ICMPv6 traffic that passes through Azure.

This is rather bad considering the importance of ICMPv6 in IPv6 (for Path MTU Discovery, for example).

Their support is being rather useless, despite us having to pay for the privilege of reporting a bug in their own infrastructure to them!

Path MTU Discovery is broken in Azure's IPv4 stack as well, which is even more sad. Similarly to you, I had to report to them that their VPN tunnels only send PMTUD in one direction, so you get this wonderful experience where TCP streams with big packets work in one direction, but not the other! With most ACK packets being small, this can take a surprising amount of time to discover and troubleshoot.

Microsoft sells to a lot of crusty enterprises, and I bet a lot of the IT folks there think NAT is for security and refused to use IPv6 if it wasn't NATed. They probably deployed it that way to placate that particular piece of brain dead security cargo cultism.

Azure sucks anyway. Their prices are not good and their management console is horrible.

You’re right that eliminating NAT is a huge part of IPV6, possibly it’s largest value-add.

That’s why adoption is slow.

NAT isn’t such a huge problem that the industry thinks it’s urgent enough to push hard to solve.

Wow. That's terrible.

It's natural because AWS/GCP/etc are against internet style system architectures (=natural IP addressing of your components), they are all about RFC1918 subnets, NAT gateways and L7 proxying. AWS even tells you it's bad architecture (or at least not "Well Architected") to build internet-style systems.

They've internalised their constraints.

RFC1918 was forced upon the cloud providers only because there weren't enough IPv4 addresses to go around.

If Amazon had started in 1980, they would have simply allocated a /8 for each region and be done with it. No NAT, no gateways, no address translation of any sort. Everything routing to everything else natively.

EC2 originally allocated a public and private address to each VM, so clearly they do have enough addresses to go around.

They had addresses to go around, but not any more.

AWS has 24 regions. If each one had a single /8 block -- which would be the bare-minimum at their scale these days -- they would eat up 10% of all available IPv4 addresses!

Keep in mind that they would still have to "carve up" that /8 for each customer, which is still an overly tight fit. Either everyone gets a bunch of small random pools of addresses (eww), or they have to restrict each region to a small number of customers (bad for business), or provide each customer with tiny subnets (too restrictive for the big fish customers).

With IPv6 this just vanishes. They could have multiple address ranges for each Region, AZ, CDN POP, or whatever. They could have ranges for each service, making firewall rules trivial. They could give each customer a huge prefix that they could still carve up into many subnets.

I seriously don't get the arguments against IPv6.

Why are people so happy with their constraints?

I also wonder if they're pushing this for lock-in reasons. If they make everyone architect in this way then people need more load balancers, NAT gateways, firewalls, and other complexity, and they charge for all that.

I have noticed that the cloud vendors seem to drag their feet on trivial free features that would undermine the need to use some expensive offering that auto scales to match your credit rating.

For example, Azure Network Security Groups (NSGs) have some glaring omissions that were ignored for years, but have just recently been oh-so-conveniently resolved by Azure Firewall. The old NSGs were free, the firewall costs money, and they also charge per gigabyte of data transferred through it!

Of course, they're recommending that all customers should immediately "uplift" their network architectures to plumb everything through a central firewall.

For security.

You know, income security. For Microsoft.

I should go buy some AMZN and MSFT...

Big cloud figured out how to monetize the tendency of most programmers to overthink, over-architect, and over-engineer everything. It's as if the authors of the old design patterns book found a way to charge for every singleton and factory. Brilliant!

Bucking this trend and building an "Internet-style architecture" is a competitive advantage. You can save multiple orders of magnitude on your hosting and bandwidth costs.

IIRC, all GCPs IPv6 support is complicated by the fact that they adopted IPv6 from the get-go for internal routing, and layer the user-visible virtual address space on top of it, embedding the user-visible addresses inside the invisible "actual" VM addresses, and that layering strategy allows for something super amazing or fast or something. Something like that.

So then you ask the engineers, "when are you going to adopt IPv6?" And they're like: "What do you mean? We've never NOT used IPv6 for everything important."

On the one had my GCP server's "native" IP address that the OS sees is always an IPv4 address. On the other hand, it's always in the 10.x.x.x/8 range. Everything else is NAT and LB.

all of google's internal architecture was built with only IPv4.

Take a look at kubernetes, which is based on google's Borg. It's only now, slowly getting IPv6 support

I don't think thats true, I think internally Google uses ipv6, see for example https://www.usenix.org/legacy/events/lisa11/tech/full_papers... about end users, but I believe the data centers are also ipv6 internally.

Google definitely uses IPv6 internally (ie office WiFi is now using IPv6 only (with the router doing translations to IPv4 if the site doesn’t support IPv6) and afaik most of the servers in the datacenter/clusters are IPv6 only now as they ran out of IPv4 LAN IPs for their clusters.

I just think that there’s little demand on cloud (and tons of other high prior work)

There's little demand for half-baked support.

There would be a lot of demand if IPv6 wasn't an "also ran", a "tack on", some checkbox to tick.

Think about how much network complexity would simply vanish if everything used only public routable IPv6 ranges.

No more split DNS. No more NAT gateways. No need for a separate "public IP" and "private IP". No need to carefully "carve up" the 10.x.x.x range to carefully avoid overlaps... even with future business partners. No need to worry about the "size" of subnets or accidentally running out of addresses in the cramped /24 subnets most people allocate.

It goes on and on.

And on.

But none of that is possible in the public cloud, because it is IPv4 first, and 99% IPv4 by default, and if there's IPv6 support, it's broken, or incomplete, or half-arsed.

Looking at the number of unprotected databases (see i.e. https://news.ycombinator.com/item?id=23957510) I think it's good that cloud providers push for gateways etc. in order to restrict access on network level.

(They still could do IPv6 proper - no argument there)

> I think it's good that cloud providers push for gateways etc. in order to restrict access on network level.

If the default security group for IPv6 only allows SSH and ICMPv6 to an instance/host, what difference does it make?

* https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-secu...

It's not the NATing that gives (internal) networks security, it's the stateful packet inspection at the gateway and--more and more--at the host level.

Nobody said there wouldn't be ACLs or firewalls in an IPv6 network.

IPv4 NAT provides security as a side effect.

You don't need NAT for security.

PS: This is the #1 most common argument trotted out against IPv6, and it is blatantly false.

NAT doesn't do much if anything for security at all, as soon as there's an outbound connection the internet has a port mapping back to your host.

https://www.f5.com/services/resources/white-papers/the-myth-....

You don't even need an outbound connection. If your router receives a packet with a dest IP set to one of your LAN machines, it'll be routed to that LAN machine. NAT does nothing to stop that, and thus does nothing for (this aspect of) security.

As a side benefit of v6, it makes it harder to find unprotected machines due to the vastly increased address space.

Obviously that doesn't make those machines secure, but an insecure machine that hasn't been exploited is better than an insecure machine that has.

GCP will support IPv6 in 2021.

Imagine someone saying, in 2001 that they're adding IPv4 support.

Laughable, right?

IPv6 was available in Windows 2000. Just saying.

Was not that the time of massive migration from IPX/SPX?

I began my IT career in 1999 and I saw exactly one network that still had significant amounts of IPX usage, but it was already primarily IPv4.

If any vendor had tried to sell a network product in 2001 that didn't do IPv4, they would have been laughed out of the room.

Nobody is laughing in the faces of vendors in 2020 for selling products that can't do IPv6 properly... or at all.

Nobody will be laughing in 2021. Or 2022... or...

I suspect we'll be having this conversation in 2030 as well, and the same people complaining about the side-effects of carrier grade NAT four levels deep will trot out things like "IPv6 doesn't have security because it's not behind a NAT!"

One of the last pieces of software I remember using IPX exclusively was Westwood Studios "Red Alert 2" released in 2000, along with its expansion pack released in 2001

I mainly remember as Vista dropped IPX support, rendering those games unplayable on LAN's for years until someone developed a UDP patch instead

I believe that was only because it was mandated by the federal government as part of procurement process. It’s the same reason there was a half baked posix subsystem in Windows NT. I don’t have citations at the moment to prove my memory.

Windows NT was built VMS-style, getting half-baked subsystems is it's entire point.

MS is major pusher of IPv6 in corporate world. Remember that when Windows 2000 was released, major v6 traffic was 6BONE overlay.

Over the next few releases, they worked hard on v6 support, and in fact some issues people had with Vista were caused by NT6 being IPv6-first OS, across all of the MS solutions. MŚ had to go backwards a bit in 6.1, introducing things like v6-over-HTTP tunnels because they found that assuming native v6+ipsec working was too much, even with Teredo.

AWS supports IPv6 almost everywhere. Azure has some support but requires IPv6 NAT for some mysterious reason. Most of the smaller cloud/VPS providers support it: Digital Ocean, Vultr, Linode, OVH, Packet.net, and so on.

The AWS elastic load balancers don’t support IPv6 targets, and since they are used in almost all circumstances means that AWS’ support for IPv6 is practically irrelevant. Plus, it’s not on their road map to fix.

AWS support seems fine to me. You have to do a little setup, but nothing difficult.

> I beg my google cloud rep for IPv6 addresses on instances

Why? What problem does this solve?

It’s a few years old but here’s a really high profile example of private IPv4 causing headaches https://instagram-engineering.com/migrating-from-aws-to-fb-8...

Ease of management.

Overlapping address spaces suck, and sometimes you need direct connections with multiple such spaces.

Reply on news.ycombinator.com