That's mostly not accurate. Every transit provider offers IPv6 transit. It's not any different or more expensive for them. Routes are routes and datagrams are datagrams to them.
The stuff that doesn't support IPv6 is mostly older CPE gear (your old firewall, a bunk load balancer, an oddball console server, etc). You really just need a router that supports IPv6 to offer an IPv6 capable server. Maybe a firewall and loadbalancer if that's in your setup, but those should all support IPv6 already.
Things like your access switches and console servers don't require IPv6 addresses yet. You can leave them on IPv4 for now. Your customers aren't going to be accessing them, only you.
And yet for some reason most co-lo and VM providers I've seen are still incapable of giving their paying customers routable IPv6 addresses.
If, like most people, your servers are sitting in a datacenter, there's going to be a lot of layer-3-aware stuff sitting between you and your users, and empirically it does not support IPv6 end to end.
That's just FUD. Pure and simple. There isn't that much that matters. It's jut routers from edge to core to leaf. Your L2 switches don't care about L3 protocols.
Some of the worse colo vendors aren't offering it because they're lazy or see increased income from higher v4 rental prices.
... are you claiming that most co-los, and major VPS providers like AWS, actually do let you use IPv6? Because that's an easily falsifiable claim. Or are you claiming that this is irrelevant and only motivated by a desire to slow IPv6 adoption? Trust me. I've worked on IPv6, I love IPv6, I want it to get out there in the world.
> There isn't that much that matters. It's jut routers from edge to core to leaf.
Oh, you sweet summer child.
The typical hosting setup involves a server behind a NAT on a network that internally looks nice and layered and normal, but that no outsider can get to. When you ask for a public IP address to be assigned to your box, a 1:1 mapping on the NAT box is installed, so that anything directed to "your" public address is mapped to your internal (private) IP. In the middle is a whole host of firewalls (typically IPv4-aware and either not IPv6-capable or not IPv6-configured, since the configuration is a substantial piece of code), VPNs to layer a more customer-friendly network topology on top of the physical one, and on VPS providers a network virtualization layer that is usually not IPv6-ready.
> Some of the worse colo vendors aren't offering it because they're lazy or see increased income from higher v4 rental prices.
I'm sure they would love to see such increased income. And yet, I've never yet seen a co-lo or VPS provider actually charge anything for IPv4 addresses. If you're going to impute malicious intent to these faceless corporations, you need to at least come up with a realistic motive. Otherwise, the "it's hard and they haven't spent the engineer-days" is a lot more convincing of an argument.
Here's a good example that I think shows that this has to do with the inherent difficulty in maintaining two separate layer-3 infrastructures on the same layer-2: Amazon EC2 does not support IPv6. It is impossible to get a public IPv6 address assigned to one, or even to route IPv6 traffic internally between different EC2-internal subnets. However, they've gone to the trouble of making their load-balancer service (ELB) support IPv6 and IPv4, translating TCP, SSL, HTTP, or HTTPS to IPv4 internally. Why would they do such a thing? The rates they charge for an ELB are peanuts; this is not a profit center. This does have the benefit of keeping IPv6 packets out of the internal network, though; that they went through that effort seems to indicate that they consider that problematic.
If you have a publicly addressable IPv4 address, why would NAT be involved? Every VPS provider I've used assigns your instance a non-RFC1918 address. That's on the host, not on a NAT device. With v6, there's no NAT.
I don't run a VPS/hosting company, so I can't say how many firewalls exist between the edge and customer equipment. I can't imagine that many even offer the service. Today's thought seems to be that's up to the server to filter traffic.
Linode offers IPv6 addresses to each instance. I'm sure there are lots of others that do, too. I can't speak for AWS; I don't work for Amazon.
> If you have a publicly addressable IPv4 address, why would NAT be involved? Every VPS provider I've used assigns your instance a non-RFC1918 address. That's on the host, not on a NAT device.
The reason for NAT in this case is that the box has one network interface, and needs to have two IP addresses - one with which it accesses the local network, and one over which public client connections come in. Unfortunately, IPv4 doesn't allow this - yet another problem solved by IPv6, which in the meanwhile is hacked around by means of NAT.
> With v6, there's no NAT.
Yes. I know. Seriously, you're preaching to the choir when it comes to how many problems IPv6 solves, and how much NAT has broken the internet. I just think you have a very rosy view of how far along IPv6 deployment is.
> Linode offers IPv6 addresses to each instance. I'm sure there are lots of others that do, too.
And that is AWESOME. Actually, in my 10 minutes of research, it seems like most of the smaller providers do (a big wave of them, including Linode, added support around 2011). My experience is with AWS and co-los, where the situation is much, much worse. Absolutely, if your provider gives you IPv6, use it. Please.
> Unfortunately, IPv4 doesn't allow [two IP addresses on one network interface]
That has nothing to do with IPv4, and has everything to do with you using obsolete tools (ifconfig). Use “/bin/ip address add $ADDRESS/$NETMASK dev $INTERFACE” and assign as many addresses as you like – the OS and drivers supports it just fine.
(Not that this should convince anyone to stay in the sinking country that is IPv4.)
The stuff that doesn't support IPv6 is mostly older CPE gear (your old firewall, a bunk load balancer, an oddball console server, etc). You really just need a router that supports IPv6 to offer an IPv6 capable server. Maybe a firewall and loadbalancer if that's in your setup, but those should all support IPv6 already.
Things like your access switches and console servers don't require IPv6 addresses yet. You can leave them on IPv4 for now. Your customers aren't going to be accessing them, only you.