Hacker News new | past | comments | ask | show | jobs | submit login

And yet almost no server supports ipv6 and almost no consumer isp supports it either.



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 simply not true. Over 22% of US Internet consumers have IPv6 addresses. Your mobile phone probably has a (few) IPv6 addresses.

From NANOG 64: https://www.youtube.com/watch?v=EfjdOc41g0s


You can go to http://testipv6.com/ and check for yourself.

Indeed, 1 out of 5 users in USA today has IPv6.


Most servers do support IPv6 these days. It's all the networking infrastructure in the middle that's the problem.


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.


> That's just FUD. Pure and simple.

... 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.

On my publicly-addressable EC2 box:

  ubuntu@ip-10-1-0-213:~$ ifconfig eth0
eth0 Link encap:Ethernet HWaddr 06:01:4b:7f:67:af inet addr:10.1.0.213 Bcast:10.1.0.255 Mask:255.255.255.0 inet6 addr: fe80::401:4bff:fe7f:67af/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:9001 Metric:1 RX packets:1091582 errors:0 dropped:0 overruns:0 frame:0 TX packets:506443 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:1121901368 (1.1 GB) TX bytes:89389900 (89.3 MB)

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.


I got IPv6 connectivity on my LTE-services. (Sweden)


In addition to other answers, here is some food for thought:

Some operators are already working on turning IPv4 off in their networks:

https://www.youtube.com/watch?v=EfjdOc41g0s




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: