Comment by jerf | Hacker News Reader

Comment by jerf | Hacker News Reader

I might have made it 64-bits, but I've certainly had this thought before on a non-April Fools basis. A long time ago I thought IPv6 was pretty much just IPv4 with more addresses. Then I found out that was wrong, and I thought it was IPv4 with more addresses and a couple of tweaks. Then I found out that was wrong, and IPv6 is more like "we polled every network protocol designer to find out what features they liked in a protocol and took the set union of them".

I now consider IPv6 to be a textbook example of how not to design a protocol. It would have been hard enough to advance us all to IPv4.1, but transitioning your stuff to IPv6 is terribly harder than it should be. For any serious network program it's like ripping out your spinal cord and putting a new one in. It's no wonder it has basically failed to date, it has proved much more work than I would have expected to actually convert software to use it, let alone use it properly.

It might still be faster for the Internet to actually create IPv4.1 right now, get to consensus, and fully deploy it, than to fully deploy IPv6 from where we are. Probably a close thing.

I'll just repost my disagreement from last time: It seems like the base cost of adopting any new protocol is pretty high, so simplifying IPv6 wouldn't have reduced the transition cost much. Given the high base cost, it actually makes sense to pack in as many fixes as possible IMO, especially since this is our one chance for the next ~25 years or so. (Some people are complaining that IPv6 didn't solve enough problems, like routing scalability.)

http://news.ycombinator.com/item?id=1929871

IPv6 is a perfectly fine protocol.

Supporting IPv6 is absolutely nothing like "ripping out your spinal cord and putting a new one in". It's largely trivial if you aren't doing anything tricky--and, notably, it requires nothing that an IPv4.1 wouldn't require. The Berkeley socket API was designed with support for multiple protocols from the start, so you shouldn't have to touch much beside your address structures and name resolution code.

And I say this from the standpoint of someone who added DHCPv6 support to a DHCPv4 server, which actually is tricky, since DHCPv6 is an entirely different protocol from DHCPv4 and substantially more complicated to boot. It still wasn't all that bad.

Most importantly, IPv6 is done. It's been done for years now. The router support is there. The OS support is there, with the exception of some laggards who really should get around to implementing DHCPv6. It's in active use. (Do you have a DOCSIS 3.0 cable modem? Congratulations, you're using IPv6!) The biggest obstacle to deploying IPv6 is just doing it, and again that's not going to be any easier with an IPv4.1.

This isn't my field, so I could be about to make a fool of myself, but... Watching some NANOG lists I've gotten the distinct impression that the biggest hurdle at this point to large scale deployment of IPv6 at the carrier/etc. level is budgets. The tech is (mostly?) all here to support it, working, from multiple vendors, but it's simply different than whats deployed in many cases. When many of these big networks should have been deploying more transitional technology over time they were busy freaking out and spending 0 money in the recession. Now they're looking at 4 years worth of capex + 100% new customer premise and so they drag their feet some more. Vendors, of course, see this as a huge opportunity so they're maybe not as keen on backporting code to older equipment as they should be.

So carrier NAT and overlapping numbering suddenly looks real good to everyone. Except for the network engineers.

End user equipment (esp things like phones, blu-ray players) is a different story in terms of readiness, but this can be handled at the border.

Reply on news.ycombinator.com