Neither DNSSEC on Route53. Plenty of technologies are just not available on 'insert popular cloud provider of today'. That's why not everyone there where everyone-else.
Why the downvotes? Just because I said something negative about DNSSEC? DNSSEC is a bad solution. More well informed minds than HackerNews have come out as to why DNSSEC is a bad idea. I'm not being mean or spiteful. It really isn't going to work.
They've been working on it for at least three years. We were really interested in deploying our application on the AWS infrastructure, until they made it clear that IPv6 wasn't going to happen for the foreseeable future. I guess they do get good marks for being transparent on their roadmap and not getting our hopes up.
They might have had issues with various gear, tooling, etc. You'd be surprised how many routing vendors screwed up IPv6 subnetting. Hence, why you need to assign a /126 on PtP links for some gear, instead of a /127. Some vendors still thought IPv6 had a broadcast address (it doesn't). Sure that's just an example and doesn't preclude them from offering it, but maybe they're conservative and wanted to get everything working right before releasing it?
Also, some older gear routed/forwarded IPv6 in software; making it much slower.
Our biggest problem had nothing to do with network hardware. It all came down to developers still writing IP regex's wrong for our app. Maybe I should write an e-book "IPv6 for the node/jquery developer?"
tl;dr it's not in Amazon's market interests to delay IPv6 adoption
"Some vendors still thought IPv6 had a broadcast address"
I have never known anyone working with IPv6 for more than a day who doesn't understand that IPv6 does not have a broadcast address. I do not believe any vendor writing a routing stack would fail to understand that. Though, I do agree in early days, they screwed things up. For example, Dell would not route RFC 4193 (FC/7) addresses around 2005. I had to rip out and ship back a dozen of their routers when I realized they weren't going to fix that.
I think you might be onto something about gear though - I've read that Amazon builds their own routers, and routing stack - which means they can't simply deploy a well tested/regressed IPv6 stack, they have to write and test it from scratch. The dark side of doing everything yourself.
So what are server hosts going to do now? If I need to scale up and order some more servers when are we going to get to the point where they say no?
I assume that server hosts are going to start charging larger and larger sums of money per month for more than a single IP on a server in order to claw back some of their allocation from their customers in cases where people didn't really need so many. But how long can this go on?
Up until now, the rational choice was to dole out as many IPv4 addresses as possible, in order to justify a larger allocation from ARIN. Now that the party's over, we should expect ISPs and hosting providers to become more stingy with their addresses: more NATs, more proxies, higher prices.
Any new providers that pop up between now and the date IPv4 becomes irrelevant will be at a competitive disadvantage.
Thus finishing the imprimatur[1]. It is an utter travesty that we haven't junked IPv4 yet. NAT removes the most powerful feature of the internet - that anybody can publish without the permission of a central authority - and I fear too many people in the software industry profit from the resulting centralization to resist things like carrier grade NAT.
> the date IPv4 becomes irrelevant
That date was 03-Feb-2011 at the latest[2].
> competitive disadvantage.
The problem is the people with larger IPv4 address blocks who se this competitive disadvantage as a good thing.
From the perspective of the ISP many customers are totally incapable of implementing NAT and waste IP addresses like they are dollar bills at the strip club.
I suppose that it would be that easy if we were hosting a website. We make an online game though so the general solution isn't going to work for us.
Sure, in principal it's the same but it's going to require a fair bit more manual implementation in our case, not to mention added latency in a very latency sensitive application.
I think your exaggerating the latency effects but anyway you can still buy IPv4 addresses for ~$12/ip. This is really just going to initially hurt service providers which is good because those are the ones who can make large inroads with IPv6
NATs do induce a fair amount of latency. It's not exaggerated. Watch Paul Saab from Facebook talk about how much better IPv6 performs at NANOG 64: https://www.youtube.com/watch?v=EfjdOc41g0s
They're likely referring to scenarios like this:
https://news.ycombinator.com/item?id=8278864 - "IPv6 privacy addresses crashed the MIT CSAIL network"
& the much more complicated host discovery / address assignment process on IPv6 segments.
Still, I think I'd rather deal with some implementation kinks than intentional packet mangling like NAT.
- own a pseudo-TLD like .com.me and are really just creating subdomains
- have a large account / custom pricing deals with a domain registrar such that despite a high total cost, the marginal per-domain cost is approximately $0
- only internally-routable domains e.g. /etc/hosts or company-internal DNS server
- only alternative DNS roots like Namecoin or tor's .onion domains
Comcast, the largest consumer ISP in the US, supports IPv6 on its entire network, and all current modems they supply have it enabled. There are still customers on older modems, and customers who have brought their own modems that do not support it, so only about 50% of Comcast users are actually running IPv6.
Consumer wireless ISPs in the US are also doing pretty good. Verizon has 70% deployment, and AT&T and T-mobile are around 50%.
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.)
Time Warner Cable has implemented IPv6 fully for all residential customers (excluding customer owned modems that do not support IPv6). All new internet circuits for commercial DOCSIS and fiber are built with IPv6 also.
