Hacker News Reader

Comment by bruce343434 | Hacker News Reader

I really don't understand what stopped ipv4 from being extended like this: w.x.y.z == 0.0.0.0.w.x.y.z

In fact, you can even ping any 32 bit unsigned integer and it will turn it into an ipv4. Try it: `ping 134744072` will ping `8.8.8.8`

So why not 64 bit? 32 bits fit in 64.

Instead we now have 2 concurrent protocols.

ps. 8*256^3 + 8*256^2 + 8*256 + 8 = 134744072

View on HN

Because "just add 4 more bytes of address space" wouldn't be backwards-compatible with the world's worth of hardware and software built around IPv4 anyways. There just isn't anywhere in an ipv4 packet that you could put those extra bytes that wouldn't break existing systems.

So the only real option is creating a new protocol with a new protocol ID in the header. And if we're making a new protocol anyways, we might as well design it to fix more problems than just address space exhaustion.

And that's what IPv6 is. The Wikipedia article has a lot of details on the kinds of changes it makes and why: https://en.wikipedia.org/wiki/IPv6#Comparison_with_IPv4

Because all the existing routers would break on all the new addresses. A new protocol was created specifically so that legacy equipment would never get the request.

For example, if an old router got a packet for 1.2.3.4.5.6.7.8, where would it send it, if it didn't crash just trying to read that address?

Yes, let's design the internet around keeping 90s routers running as long as possible. Excellent. Let's also design highways with a max speed of 20 MPH so we can accommodate Model T's

A better analogy might be something like upgrading roads with the newly liberated fourth dimension; so mere three dimensional Model Ts - that people will try to use no matter your protest - are very unlikely to end up in the right place. (And not just Model Ts, but the entire twentieth century and a bit's worth of vehicles.)

Roads? Where we're going we don't need roads.

Funny you should mention the Model T. We did the exact same thing with roads as we did with IPv6. We created a new type of road (highways) that the Model T could not go on. But the new cars can still use the old roads, albeit slower than their max speed. This is the same as IPv6 going through carrier grade NAT.

Slowly over time the roads were upgraded, so now you can use mostly high speed roads to get between places and you don't really see Model Ts anymore because it's not convenient to avoid all the high speed roads.

The issue is replacement cost and feasibility. As roads got better pavement (or were more reliably paved) speed limits could increase. I still have some 20-30mph dirt roads near my home here (actually quite a few), but highways were specifically made to support higher speeds (longer straight sections, in sane places smoother curves). Notably, improving road quality did not obsolete the Model T (though it did become obsolete) on its own. It just made them particularly outdated when other, faster, options were now viable.

Nothing has stopped making faster cars just as nothing (fundamentally) has stopped us from making a "better" Internet (supporting more addresses and other features). What hasn't been done is to say, "Ok, so we already have this massive hardware rollout but we're going to literally obsolete 99.99% of it overnight and cost everyone, home users, small businesses, governments, megacorps, billions or trillions to replace their hardware."

Why didn't that happen? Because it would've been stupid. Instead we ended up with what's amounted to two Internets with bridges between them. The transition hasn't been smooth, but it has been happening.

There's no way we could ever stop the world and get everybody to use a new protocol overnight.

Attempting to change the format of an existing protocol in-place in a way that existing hardware and software cannot handle, would be an effort that's dead on arrival.

The global transition to ipv6 is already hard enough, and that's with it designed as a separate protocol so that existing equipment that doesn't understand it can at least gracefully discard it instead of mishandling it.

An IPv4 address isn't A.B.C.D though. That's just a shorthand way for us write it down because those chunks are easier for us to deal with. An IPv4 address is an unsigned 32 bit integer.

The address is not the real issue. An IPv4 header contains 32 bits for the source address and 32 bits for the destination address. That's what needed to be extended. IPv4 implementations expect the destination address to be 32 bits after the source address.

Any fix you can think of to extend the address fields in the header will fall into the situation of having an additional protocol. Because changing the v4 header and calling it a v4 header would probably get your packet dropped as bad. Or have it being sent to somewhere else. Or some other undefined behavior.

So your best option is to have it identify as a new version. Yes, v4 implementations will reject your packet, but that's what you want in this case.

Reply on news.ycombinator.com