Hacker News Reader

Comment by hartator | Hacker News Reader

IPv6 was over engineered. The fact that you need several hours to understand it while you get IPv4 in 5 minutes doesn’t push for adoption.

View on HN

I learn new things about IPv4 every day. Over the weekend there was an article about someone writing an IPv4 address parser and there were a couple of cases that were new to me.

One thing about "second system syndrome" that doesn't get talked about much is how the second system always has to take into account the unwritten rules from the first system, that the original designer didn't take into account. What was previously unspecified now becomes specified, and that increases the amount of text in the second system's specification. But, the complexity might not be as high -- it's just that you can read about it all in one place.

Ehhh I don't know about that. IP takes a while to understand for most of the reasons articulated in the post. DHCP and ARP, for example, are a bit strange. It's just everyone already understands it, so explanations have been distilled pretty well.

That being said, I don't grok IPv6 myself, on account of never actually looking into it.

ARP I'll give you (though even there it's only actually in the binding of IPv4 to ethernet-like lower layers. IP over e.g. PPP doesn't need it). DHCP isn't inherent in IPv4 at all though. You want to throw it in, because IPv6 has address autoconfiguration built-in. But this is actually just more evidence that IPv6 is more complex.

I want to throw DHCP in because in practice, you need it to connect to random IPv4 networks.

Besides, the counterpoint is even tougher. Should we expect beginners to configure static addresses when actually configuring their networks? Getting bogged down in the details of broadcast addresses, subnet masks and gateway addresses can be a bit unsettling for a total beginner. It's second nature to seasoned hackers, so we discount how foreign it was when we first learned it.

Explain. IPv4 takes time to understand too (e.g. subnetting) but it's more common so people deal with it much more.

Understanding how to read/write an IPv6 address is WAY more complicated than for IPv4. That barrier to entry alone likely prevents a lot of casual adoption. You can come back that IPv6 isn’t all that bad, but the real world adoption rate amongst individuals, even skilled hobbyists, speaks for itself.

I'm not that sure on how an adoption rate of 30-35% speaks for itself?

https://www.google.com/intl/ru/ipv6/statistics.html#tab=ipv6...

Maybe you mean that the increase in adoption is too slow, and I agree to that, but change always takes more time than we want, specially when there isn't clear financial incentives.

ipv6 is today older than the internet was when it was invented.

That’s why I said among individuals, specifically hobbyists. Sure, companies that consume vast quantities of IPv4 addresses have an economic incentive to use IPv6, so you will see some adoption. But the reason there is such a long tail is because the cost of adoption (learning it) is higher than the supposed benefits for most individuals and small corporations.

That is probably the silliest argument against IPv6 you can make. Just look at the header structure and IPv6 becomes pretty clear. And without old cruft that IPv4 is burdened with, I would argue IPv6 is easier to grok.

The ideal situation for both IPv4 and IPv6 is to not have to deal with raw addresses. If you are reading IP addresses over the phone or in a ticket to connect to computers on a regular basis, your company did IT on the real cheap and is likely suboptimal in many ways except for amount of money spent on IT.

Not as much, you could learn the basics on ipv4 in two to three 4 hour classes of study - assuming you know how to convert between binary octal and decimal.

The same is true of IPv6? There is really nothing deeply magical there that takes forever to understand.

Maybe be a bit more concrete about what's so much more complicated about IPv6 than IPv4..

What I am seeing here mostly is the biggest problem is that you can't hold an IPv6 address in your head. Ever.

I can look at an v4 address then 15 seconds later look at another address and know they are different. That's not possible with v6.

So I think people are conflating "difficult to wield" as "more complicated".

If you only use autoconfiguration perhaps, but for manually assigned addresses it's really not too bad since one can structure them in a logical way (which would be extremely expensive to do in the IPv4 case).

If you are a company you can get your own IPv6 space and can structure things hierarchically: <company prefix>:<site>:<vlan>::<hostnumber>.

And in fact I can remember more IPv6 addresses for hosts than IPv4 addresses for the same hosts right now.. so there is that.

And yet I have fe80:: in my head and 2001:db8:: in my head (as well as my own /32). I don’t have the documentation prefix (if one even exists) for IPv4 in my head.

It’s harder, but “can’t... ever” and “not possible” are not true for everyone.

IPv4 as deployed with NAT is more complex than IPv6. The most significant barriers to V6 adoption are, in this order:

1. It’s an entirely new network. IPv4 only hosts are not reachable on the IPv6 net. It replaces rather than extends IP, and I can’t figure out why they did that.

2. The addresses are too long to remember and easily type, and the encoding with its shortening rules is non-canonical and annoying to visually parse.

Extending V4 to 64 bits on top of the V4 space would have been a much better idea for multiple reasons. Every V4 becomes a /32 in a full /64. Using something like base32 addresses could have been kept to just barely type-able length.

People always push back on #2 with “use DNS.” I always wonder if these people have ever done IT or devops. You constantly type IPs in the real world and long V6 addresses are a huge annoyance.

> Every V4 becomes a /32 in a full /64.

IPv4-mapped IPv6? http://www.tcpipguide.com/free/t_IPv6IPv4AddressEmbedding-2....

I do a lot of devops and haven't typed an IP address in a while. I do a lot of comparisons, however, and comparing 128 bit numbers is slightly more difficult than 32 bit numbers. Overall, I stopped remembering IP address a long time ago. I wouldn't recognize "jrock.us" if you showed it to me. I kind of recognize my current external IPv4 address, but it could be off by a lot before I'd notice.

I think, many years ago, I typed a lot of IP addresses, but don't anymore. I am personally fully-ready for IPv6, but understand that the world is not. (For example, my website was IPv6-accessible for many years, but changed providers and now it's not. I was a little sad about this, but it turns out nobody cares, so I didn't spend any time on it. Unfortunate, but someday it will work again, I'm sure.)

> It’s an entirely new network. IPv4 only hosts are not reachable on the IPv6 net. It replaces rather than extends IP, and I can’t figure out why they did that.

IPv6 cannot be an extension of IPv4 since IPv4 is not forward-compatible. It has nothing in it that would allow stuffing more address bits into it. And since you cannot encode more than 32bit in 32bit you will never be able to have a IPv4 successor that can just interoperate with IPv4 - you will always end up in exactly the same situation as IPv6 is right now.

And if you just want to route your IPv4-ng over IPv4 in the core or something (which is what your idea is more or less). You can do that with IPv6 as well: Use 6in4 tunneling.

But you are still at the same problem that a IPv4-only cannot communicate with an IPv4-ng-only host, since it is unaware of IPv4-ng.

There's plenty of room if the IPv4 header to extend it.

The most significant bit of the IP protocol number field is mostly unused. The IP protocols that use it could be safely deprecated on the open Internet.

Setting the MSB indicates a 64-bit address.

In 64-bit mode the source IP and destination IP fields in the V4 header become the most significant 32 bits of the source and destination IP. The least significant 32 bits of each are present in the options field, which contains enough room for both. In 64-bit mode any other use of the options field is deprecated. The bit index of these 32-bit chunks in the options field could be standardized to permit easy hardware decoding. The part of the options that indicate the option type and length could be present for backward compatibility with IP64-unaware routers but otherwise ignored.

Uglier than a clean slate design? Sure, a bit. But if this had been done, we'd already be using it everywhere and the problem would be solved.

TCP, UDP, and other IP protocols could remain almost entirely unchanged, though I imagine tables in software stacks would have to be extended to support 64 bits of address space. That's not a major change.

I just came up with that in 10 minutes while replying to this post. I assume it would take a committee several years to write the above spec.

The big "win" here is that existing IPv4 routers in the Internet's core infrastructure do not need to be upgraded all at once. They'd just lack the ability to understand anything beyond /32.

Honestly there are probably enough /32's to give one to every major endpoint, so I wonder if the core would even need to worry about it at all. I imagine that ISPs would hand out /32's to business customers (maybe for an additional fee), but once IP64 were widely deployed they'd probably hand out /48's to most subscribers. That would give you 65,535 "real" IP addresses for your house or small business. Mobile phones might get a /56, which would give them 256 IPs for tethering and permit cellular networks some additional IP space.

There are nice things about 128-bit addresses, but I am not sure they are worth adding 30+ years to the transition and having to lug around the hideous boat anchor that is NAT for an extra few decades.

I think you will be surprised on how much stuff will break in mysterious ways. And that it will create a nightmare to actually operate. But even if we pretend it will just work there is the still the issue that IPv4-only hosts cannot talk to IPv4-NG hosts.

There is no way around that.

And having to upgrade the core is not really an issue (anymore). You are focusing on the wrong issue.

> The big "win" here is that existing IPv4 routers in the Internet's core infrastructure do not need to be upgraded all at once.

As I understand it, that is not the limiting factor in IPv6. Actually, I believe it was the second piece of the Internet's infrastructure to support IPv6 (the first part being OS networking support). Instead, the limiting factor is network management and middleware, in other words the edges and not the core of the Internet, that are holding back IPv6 adoption.

v6 already implements a similar scheme. You set the protocol field in the v4 packet to 41, and then put the v6 addresses at the beginning of the packet payload, with the original packet payload following afterwards.

It doesn't seem to have helped as much as you're claiming.

I could set up an entirely ipv6 network on each of my devices and connect it with nat into IPv4, but crucially I want someone typing "ping 1.1.1.1" or opening a udp conenction to 92.42.35.61 port 5210 would just work, and I don't want to add much overhead (and wide deployment of dual stack is adding overhead)

Imagine I have a mid sized ipv4 network comprising say 200 /24 subnets across multiple locations, all on 192.168.x.0/24, with 192.168.0.0/24 reserved for a vpls connecting them together (say ospf point-to-multipoint, other topologies are preferable of course).

Default router to the internet on 192.168.0.1 (internal), which srcnats to a public IP addresses of 12.12.12.0/24, say 1 hide per subnet, advertised out as BGP to a couple of providers via some /30 links from their allocation.

Now say I want to create a new client network.

1) Create a new subnet on 192.168.201.0/24 and put them all behind the new hide 12.12.12.201

I've done this 100+ times already, no problem, but it's rather legacy.

2) Create a new ipv6 network, with a 192.168.0.89/24 address which links to the other networks

I could create a new ipv6 network, and reach servers on 192.168.12.1, or 192.168.51.8, as well as reaching the internet on ipv4. Traffic leaving the network would get srcnatted to 192.168.0.89.

I then have a new http service I need to add, so I create a new ipv6 server network. This is reachable directly from the wifi clients as I have an ipv6 peering between the wifi client router and the ipv6 server router.

For access from ipv4 subnets I can just put a destination nat on 192.168.0.89 port 80 to my new server, so it's reachable from all other ipv4 clients, but also from ipv6 clients directly. the server wouldn't need as it would see the ipv6 connection from the natting router (which maintains the state). I could also add a port forward from the public IPv4 address too.

3) Do both, and have twice the overhead as I have to manage both an IPv4 and IPv6 network.

I'd rather not do that dual stack. After all what's the point in moving to ipv6 if you need to keep ipv4 running. It would be like using IP and IPX on the same network.

My next step would be to add a public Ipv6 address peering. I put in ipv6 routing on my default router.

Now my new server is reachable directly on ipv6 from my client ipv6 network, and the entire ipv6 internet

It's also reachable from my older network on the internal 192.168 address range, and from the ipv4 internet on

I don't have to have a dual stack on every device (including the server), just on 3 routers.

I notice that some of my customers would like to connect via ipv6, so that's fine, I do an ipv6->ipv4 nat on my firewall for legacy services.

With this setup, which doesn't need me to change 20,000 devices on 200 subnets simultaneously, or end up in a situation where I have 20,000 dual stack devices, I can start migrating to ipv6 without losing any existing ipv4 services. Eventually I will be left with just a handful of ipv4 subnets and a couple of routers running an ipv6/v4 natting gateway

That's a very simplistic statement. That's like saying IA-64 was over-engineered. It's completely unhelpful unless you can articulate in which ways it is over-engineered and propose a practical alternative.

I take my hat off to the AMD folks that brought us x86_64. I challenge you to design a successor to IPv4 that is better than IPv6. Put it out there and let the world start taking shots at it. We'll see how well it holds up.

There is plenty of opportunity for a better idea to catch on. Just like x86_64 succeeded despite the existence of IA-64. IPv6 has been so poorly adopted that it is not too late to retreat.

But it would take a lot more than lazy criticism to find a workable path forward.

Reply on news.ycombinator.com