Hacker News new | past | comments | ask | show | jobs | submit
throw0101d | on: The Road Not Taken: A World Where IPv4 Evolved
> 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...

bmacho | parent | next
> Just like with IPv6.

Yes, but the compatibility is very very easy to support for both hardware vendors, softwares, sysadmins etc. Some things might need a gentle stroke (mostly just enlarge a single bitfield) but after that everything just works, hardware, software, websites, operators.

A protocol is a social problem, and ipv6 fails exactly there.

loading story #47359145
loading story #47357666
lxgr | parent | next
Yes, I was wondering if I was missing something reading the hypothetical: This is still splits the Internet into two incompatible (but often bridged etc.) subnetworks, one on the v4, one on the v4x side, right?

It just so happens that, unlike for v6, v4 and v4x have some "implicit bridges" built-in (i.e. between everything in v4 and everything in v4x that happens to have the last 96 bits unset). Not sure if that actually makes anything better or just kicks the can down the road in an even more messy way.

loading story #47355474
| root | parent | next
{"deleted":true,"id":47357072,"parent":47355088,"time":1773349450,"type":"comment"}
loading story #47355685
loading story #47355506
billpg | parent | next
No, in this hypothetical, routers that don't know about IPv4x will still route based on the top 32 bits of the address which is still in the same place for IPv4 packets. If your machine on your desk and the other machine across the internet both understand IPv4x, but no other machines in the middle do, you'll still get your packets across.
loading story #47358018
loading story #47358757
arka2147483647 | parent
The advantage, as i see it, is that this could be done incrementally. Every new router/firmware/os could add support, until support is ubiquitous.

Contrast this with ip6, which is a completely new system, and thus has a chicken and egg problem.

loading story #47357224
loading story #47357695