alt Hacker NewsThe Road Not Taken: A World Where IPv4 Evolved
Comments
> Who owns all these new addresses? You do. If you own an IPv4 address, you automatically own the entire 96‑bit subspace beneath it. Every IPv4 address becomes the root of a vast extended address tree. It has to work this way because any router that doesn’t understand IPv4x will still route purely on the old 32‑bit address. There’s no point assigning part of your subspace to someone else — their packets will still land on your router whether you like it or not.
So the folks that just happen to get in early on the IPv4 address land rush (US, Western world) now also get to grab all this new address space?
What about any new players? This particular aspect idea seems to reward incumbents. Unlike IPv6, where new players (and countries and continents) that weren't online early get a chance to get equal footing in the expanded address space.
It seems like this really only helps intermediate routers.
All endpoints need to upgrade to IPv4x before anyone can reasonably use it. If I have servers on IPv4x, clients can reach my network fine, but they then can't reach individual servers. Clients need to know IPv4x to reach IPv4x servers.
Similarly, IPv4x clients talking to IPv4 servers do what? Send an IPv4x packet with the remaining IPv4x address bits zeroed out? Nope a V4 server won't understand it. So they're sending an IPv4 packet and the response gets back to your network but doesn't know how to get the last mile back to the IPv4x client?
I desperately wish there was a way to have "one stack to rule them all", whether that is IPv4x or IPv4 mapped into a portion of IPv6. But there doesn't seem to be an actually workable solution to it.
> The Version field must remain 4.
And at the same time the address format and IP header is extended, effectively still splitting one network into two (one of which is a superset of the others)?
A fundamentally breaking change remains a breaking change, whether you have the guts to bump your version number or not.
Similar discussion from a couple of months ago: https://news.ycombinator.com/item?id=46468625
I personally feel that IPv6 is one of the clearest cases of second system syndrome. What we needed was more address bits. What we got was a nearly total redesign-by-committee with many elegant features but had difficult backwards compatibility.
In my view, the problem largely comes from the way the Internet has grown. Many of these concepts developed together with the Internet, and IPv4 was the protocol that evolved with them.
I see many ISPs deploying IPv6 but still following the same design principles they used for IPv4. In reality, IPv6 should be treated as a new protocol with different capabilities and assumptions.
For example, dynamic IP addresses are common with IPv4, but with IPv6 every user should ideally receive a stable /64 prefix, with the ability to request additional prefixes through prefix delegation (PD) if needed.
Another example is bring-your-own IP space. This is practically impossible for normal users with IPv4, but IPv6 makes it much more feasible. However, almost no ISPs offer this. It would be great if ISPs allowed technically inclined users to announce their own address space and move it with them when switching providers.
Thanks for reading and commenting everyone!
Note though that I'm not proposing IPv4x as something we should work towards now. Indeed, I come down on the side of being happy that we're in the IPv6 world instead of this alternative history.
> Who owns all these new addresses? You do. If you own an IPv4 address, you automatically own the entire 96‑bit subspace beneath it. Every IPv4 address becomes the root of a vast extended address tree.
Huh:
> For any 32-bit global IPv4 address that is assigned to a host, a 48-bit 6to4 IPv6 prefix can be constructed for use by that host (and if applicable the network behind it) by appending the IPv4 address to 2002::/16.
> For example, the global IPv4 address 192.0.2.4 has the corresponding 6to4 prefix 2002:c000:0204::/48. This gives a prefix length of 48 bits, which leaves room for a 16-bit subnet field and 64 bit host addresses within the subnets.
Reminds me of https://cr.yp.to/djbdns/ipv6mess.html
Which has been discussed previously: https://hn.algolia.com/?q=The+IPv6+mess
This sounds a lot like what we have in 6to4 (for 25+ years now), where nodes behind two ipv4 derived prefixes can automatically talk to each other p2p, and use a gateway to communicate with the rest of the v6 internet.
I actually disagree: that's the road taken. NAT is practically this. When you're behind a NAT, you're effectively using a 64-bit address space. Two more layers of NAT, and you can have 128-bit address space. "The first part" of the address is a globally routable IPv4 address, and the rest is kept by the routers on the path tracking NAT connection states.
And NAT needed zero software changes. That's why it's won. It brought the benefits of whatever extension protocol with existing mechanisms of IPv4.
IPv6 isn't an alternative to IPv4, it's an alternative to all IPv4xes.
I'm glad this exists, because it demonstrates there are ways to make a next-gen IP interoperable with IPv4, and that while IPng had interoperability has part of its assessment, it completely nixed it because they didn't want to go with the other proposals at the time which had some consideration for it.
Their hypothetical approach of extending IPv4 reminds me of how TLS v1.3 masquerades as v1.2 in order to pass through meddling middleboxes safely.
"IPv6 does that."
Are you sure about that? Until a few years ago my residential ISP was IPv4 only. I definitely couldn't connect to an IPv6-only service back then.
Not a single discussion here of his SixGate proposal (but many mischaracterizations of IPv4x as a "proposal", when it was rather an alternate history). So HN.
We should basically all call our ISPs and ask for ipv6 to be implemented.
Similar discussion from 10 years ago: https://news.ycombinator.com/item?id=10854570
My fantasy road-not-taken for IPv4 is one where it originally used 36 bit addressing like the PDP-10. 64 billion addresses would be enough that we probably wouldn't have had the address exhaustion crisis in the first place, though routing would still get more complicated as most of the world's population (and many devices) started communicating over IP networks.
IPv4 was evolved, it is now a 48 bit address, signified by IP:PORT.
“IPv6 is waiting for adoption”
A major website sees over 46 percent of its traffic over ipv6. A major mobile operator has a network that runs entirely over ipv6.
This is not “waiting for adoption” so I stopped reading there.
https://www.google.com/intl/en/ipv6/statistics.html
https://www.internetsociety.org/deploy360/2014/case-study-t-...
IPv6 is fine. The advice on ULAs is garbage. The purpose of a protocol is to provide utility, not proscription.
30 years on and if I have a machine with an ipv6 only network and run
"ping 1.1.1.1"
it doesn't work.
If stacks had moved to ipv6 only, and the OS and network library do the translation of existing ipv4, I think things would have moved faster. Every few months I try out my ipv6 only network and inevitably something fails and I'm back to my ipv4 only network (as I don't see the benefit of dual-stack, just the headaches)
Sure you'd need a 64 gateway, but then that can be the same device that does your current 44 natting.
what happens when a legacy host sends a 32 bit address to a 128 bit endpoint? it doesn't have enough information to forward it anywhere
in 100 years ipv4 will be recognized as one of the great discoveries like calculus. ipv6 is a misnomer really. It's a separate, and lesser protocol. Much like other second systems, it was too ambitious and not pragmatic enough.
Rather than looking down on IPv4 , we should admire how incredible it's design was. Its elegance and intuitiveness, resourcefulness have all led to it outlasting every prediction of it's demise.
Em-dashes in this article.
What is described here is basically just CIDR plus NAT which is...what we actually have.
At the time IPv6 was being defined (I was there) CIDR was just being introduced and NAT hadn't been deployed widely. If someone had raised their hand and said "I think if we force people to use NAT and push down on the route table size with CIDR, I think it'll be ok" (nobody said that iirc), they would have been rejected because sentiment was heavily against creating a two-level network. After all having uniform addressing was pretty much the reason internet protocols took off.
> In a nutshell, an IPv4x packet is a normal IPv4 packet, just with 128‑bit addresses. The first 32 bits of both the source and target address sit in their usual place in the header, while the extra 96 bits of each address (the “subspace”) are tucked into the first 24 bytes of the IPv4 body. A flag in the header marks the packet as IPv4x, so routers that understand the extension can read the full address, while routers that don’t simply ignore the extra data and forward it as usual.
So you have to ship new code to every 'network element' to support IPv4x. Just like with IPv6.
So you have to update DNS to create new resource record types ("A" is hard-coded to 32-bits) to support the new longer addresses, and have all user-land code start asking for, using, and understanding the new record replies. Just like with IPv6. (And their DNS idea won't work—or won't work differently than IPv6: a lot of legacy code did not have room in data structures for multiple reply types: sure you'd get the "A" but unless you updated the code to get the "AX" address (for ipv4X addresses) you could never get to the longer with address… just like IPv6 needed code updates to recognize AAAA, otherwise you were A-only.)
You need to update socket APIs to hold new data structures for longer addresses so your app can tell the kernel to send packets to the new addresses. Just like with IPv6.
A single residential connection that gets a single IPv4 address also gets to use all the /96 'behind it' with this IPv4x proposal? People complain about the "wastefulness" of /64s now, and this is even more so (to the tune of 32 bits). You'd probably be better served with pushing the new bits to the other end… like…
* https://en.wikipedia.org/wiki/IPv6#IPv4-mapped_IPv6_addresse...