Hacker News Reader

Comment by digi_owl | Hacker News Reader

Something of an aside, but i have come to understand that the major issue for adopting IPv6 was hardware.

This both in terms of existing router installs, and endpoint devices that can't be flashed to grok IPv6.

My impression (from seeing IPv6 support projects being regularly deprioritized at a previous employer) is that it's more of a market/deployment problem than a technological one. Layer 3 is a uniquely annoying place in the current networking stack, in that changes to it are useless until everything on the path between you and the other hosts you talk to speak IPv6.

With upper-layer stuff like HTTP2, you can get some return on your investment as long as two hosts that want to talk to each other, however distantly separated, speak the new protocol/features. With lower-layer stuff like 802.11ac or 1GB ethernet, you can get most of the benefits just by upgrading the client hardware and infrastructure in a local setting. If you want to talk over IPv6, though, you need to upgrade clients, local infrastructure (e.g. in-home routers, corporate IT equipment), carrier routers, datacenter routers, and servers. In many cases, each of those things is controlled by a separate organization, and none of those organizations gets any benefit out of implementing IPv6 until everyone else along the chain does so too.

For example - let's say that you're providing some kind of web app or service from your own servers. There's a non-zero effort involved in setting up IPv4/6 dual stack throughout your stack, so you first check if you can even get IPv6 connectivity. Using EC2? Nope - no IPv6. Using a leased server in a colo? Pretty good chance they'll also not even have it available as an option. So at that point, why even work on this feature that you're not going to get to use, and that since it's not exercised by real traffic will probably be full of bugs?

In other words, the age old chicken and egg issue.

Yyyyup. And this time too big for even a titan like Google or Apple to kick-start :-(

And we can't simply dump the whole v4 range into a sub-section of v6 and call it a night either.

While it may work for the v6 side, the v4 side will have a hell of a time talking to anything on the v6 without some kind of network level NAT going on...

This is actually quite widely used (see [1]). The big limitation is that all connections have to be initiated from the IPv6 side, so it's usually used to allow v6-only client networks to access v4 servers, but even that is a big win for bootstrapping - for example, it's let T-Mobile configure all its new Android devices for IPv6-only behind a variant of NAT64.

Another cool trick is IPv4-mapped IPv6 addresses [2], which lets userspace software act like the IPv4 internet is just a subnet of the IPv6 internet, and speak IPv6 only, while the network stack of the host system deals with the annoyances of dual-stack. (In fact, I think on Linux systems this will even let you pretend that an IPv4-only configuration is actually IPv6 ;-) ).

[1] http://en.wikipedia.org/wiki/NAT64 [2] https://tools.ietf.org/html/rfc4038#section-4.2

Well i learn something new every day...

Well, kind of... It's less about not being able to grok IPv6 and more about these routers having limited memory available. IPv6 addresses take up 4x as much memory as IPv4 addresses, and that adds up pretty quickly in a routing table. As routers are typically integrated devices, you can't just go "add more RAM", so sticking with IPv4 effectively quadruples your capacity.

It can be even worse than that. A significant number of routers forward IPv4 packets in hardware but fall back to a software implementation for IPv6. So it might happen that the real bottleneck is not memory but throughput.

As for sticking with IPv4 for increased capacity, it depends. Private networks might get away with it for their internal traffic, but no major ISP nowadays will deliberately choose not to route IPv6 for their customers.

During the initial few years, it was also about hardware limitations. The Cisco kit we had in the early 2000s featured hardware accelerated IPv4 handling but fell back to the host CPU for IPv6. Even a simple ping test would show the difference since the software path was seen as a fallback for anomalies and they'd provisioned the CPU accordingly.

Is that mixing up two different classes of devices?

Home embedded routers run into problems due to the overhead of state tracking and buffers for all the simultaneous connections. If they support 10k simultaneous connections, and they track 2x ip addresses for each, the additional overhead of 2x 12 bytes per ipv6 connection is 240kB memory. Buffers are going to be much, much more than that, and buffer requirements are about the same for ipv4 and ipv6.

Routers that have full BGP routing tables tend to be serious routers with TCAM. That's expensive and that does put pressure on BGP routing table sizes, to accommodate older and cheaper [real] routers. However, ignoring ipv6 is simply not an option, so there's no point in dreaming about how staying with ipv4 forever would allow quadruple the routing table capacity for a set amount of TCAM.

I was actually referring more to the core routers with TCAM than home routers. And I agree, ignoring IPv6 isn't an option, but it is a viable option to encourage workarounds. Which is exactly what's happened; so most ISPs that support IPv6 do 6to4 tunneling at the edge.

That's a workaround? Interior routers within the ISP don't need to hold the global routing table, so there's no real TCAM pressure on them, right?

As you venture down into the realm of cheap consumer routers, you run out of ROM to hold the code implementing IPv6 long before you run out of RAM.

The IPv4 address table needs 3x as many routes as a non-fragmented address space like IPv6 would, so it's a much smaller difference than it sounds like.

It's more complicated than that; nobody with an ipv4 address had an incentive to switch, and the ipv6 committee addressed the wrong problems in trying to encourage adoption. As IPv4 addresses will likely become more valuable in the future, then there will be a cost incentive to switch.

For another take on the matter, see: http://cr.yp.to/djbdns/ipv6mess.html in particular a good summary of one issue is under "Another way to understand the costs"

Major issue for adopting IPv6 was feature bloat, everyone and their grandma wanted something in the standard and we ended up with complicated mess.

Which feature do you think is the most egregious?

I don't know what will be said but I've wondered why they went to 128 bit addresses when 64 should have been "enough for anybody." Note 64 bit isn't double 32, but rather like 4 billion times more if my math isn't too far off.

Imagine having to type those addresses out by hand. Though skipped 0 are allowed, hex only helps a little. Not looking forward to that.

The second 64 bits are reserved for future innovation. Ethernet nodes happen to populate it with tedious junk, but that forces ISPs to allocate a /64 per user as a bare minimum.

Over the coming years and decades, people will repurpose those bits to do interesting stuff at the network edge, without forklifting the entire Internet again.

I think that was in part futureproofing.

Back when IPv4 was put in place, they had no idea the net would become so important. Now they know, and so going all the way to 128 helps futureproof.

Also, look at the (though media over-hyped) Y2K thing. that was a case of "good enough" that ended up staying in production way beyond expectation.

Heck, there are companies out there selling devices that allow "old" industrial looms to load patterns from SD cards and such when they were originally designed to take floppies. This via a device that have a floppy cable connector at one end, a SD slot at the other, and fix inside a 5.25" or 3.5" drive bay.

Computational stuff seems to stay in use way longer than anyone imagined back when every year or so seemed to produce whole new architectures.

Right, futureproofing. But this is not like when hard disks were 512mb, then 2gb, then 4, and kept hitting very shortsighted limits.

We're surviving now with only minor discomfort on a 32 bit address space, and 64 is billions of times more space.

128 is just showing off for no obvious reason that I can see, besides looking like guids. The number approaches the number of atoms in the universe I believe. I'm guessing a universe-wide addressing system can wait a few years, haha.

That worked with HDDs because you could stop actively using the old, transfer its content to the new, and start using the new.

In the history of the Internet that has been done exactly once, and back then it was 1/1000 (or maybe even 100000) the size it is now.

That is entirely intentional.

There are 64 bits for the network prefix, and then 64 bits for devices on the network.

So you'll have a network like 2001:f4dc:2110::/64, and then you can allocate ::1, ::2, ::3. Real had to allocate by hand, right? Not really. Sure, billions of addresses go unused, but who cares? With expansion it's fine - you just write 2001:f4dc:2110::2.

If you had to write 2001:f4dc:2110:0000:0000:0000:0000:0002 then I would sympathise. But you don't.

Reply on news.ycombinator.com