> 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...

▲

lxgr 3 hours ago | parent [-]

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.

▲

xorcist 2 hours ago | parent | next [-]

> everything in v4x that happens to have the last 96 bits unset

That's pretty much identical to 6in4 and similar proposals.

The Internet really needs a variant of the "So, you have an anti spam proposal" meme that used to be popular. Yes, it kill fresh ideas in the bud sometimes, but it also helps establish a cultural baseline for what is constructive discussion.

Nobody needs to hear about the same old ideas that were subsumed by IPv6 because they required a flag day, delayed address exhaustion only about six months, or exploded routing tables to impossible sizes.

If you have new ideas, let's hear them, but the discussion around v6 has been on constant repeat since before it was finalized and that's not useful to anyone.

	▲	lxgr 2 hours ago \| parent \| next [-]
		I feel like the greatest vindication of v6 is that I’m reading the same old arguments served over a quietly working v6 connection more often than not. While people were busy betting on the non-adoption of v6, it just happened. —Sent from my IPv6 phone
	▲	throw0101d an hour ago \| parent \| prev [-]
		> The Internet really needs a variant of the "So, you have an anti spam proposal" meme that used to be popular. For those unfamiliar: * https://craphound.com/spamsolutions.txt

▲

joseda-hg 2 hours ago | parent | prev | next [-]

I might be interpreting wrong, but doesn't IPv6 also have a "implicit bridge" for IPv4?

▲

wmf 2 hours ago | parent | prev [-]

IPv6 had an implicit bridge called 6to4 but it was phased out because it wasn't that reliable.