[throw0101a]

> I'm curious when we'll declare some sort of "idea bankruptcy" on IPv6, develop a new version (IPv7?) that has a "ease of migration from IPv4" as a stated goal, and deploy/implement that.

We need more addresses. That's the primary problem of IPv4 right now.

So if all the IPv4 code is written to handle 32-bit addresses, how do you create an addressing system that has more than 32-bits of data, but fits with-in a 32-bit data structure?

AFAICT, code updates will needed to occur on every device that needs to talk to the new address scheme. So what's the difference between updating every device to handle IPv6 versus updating every device to handle this hypothetical IPv7?

[zinekeller]

> So if all the IPv4 code is written to handle 32-bit addresses, how do you create an addressing system that has more than 32-bits of data, but fits with-in a 32-bit data structure?

IETF also asked that for AS numbers (which were only ~60,000 originally!) Sure enough, there were some reserved bits actually on the spec, which they used to add an extended address. Nowadays, the original BGP actually operates on a single number: AS23456 and the actual AS number is on that reserved spot.

What's worse is that it was actually already proposed in 1992 (https://datatracker.ietf.org/doc/html/rfc1347). Did it work? Actually, yes! Why IPv6 then? Because it's shiny!

[throw0101a]

From the RFC (emphasis added):

> The long term goal of the TUBA proposal involves transition to a worldwide Internet which operates much as the current Internet, but with CLNP replacing IP and with NSAP addresses replacing IP addresses.

[…]

In §3 Migration:

> Updated Internet hosts talk to old Internet hosts using the current Internet suite unchanged. Updated Internet hosts talk to other updated Internet hosts using (TCP or UDP over) CLNP. This implies that updated Internet hosts must be able to send either old-style packets (using IP), or new style packet (using CLNP). Which to send is determined via the normal name-to-address lookup.

So you're replacing IPv4 with something that is not-IPv4 on every router and every host. During the transition period everyone will have IPv4 and not-IPv4 addresses.

How is not-IPv4 being CLNP/NSAP any different that not-IPv4 being IPv6? What am I missing?

In §6 on DNS:

> TUBA requires that a new DNS resource record entry type ("long-address") be defined, to store longer Internet (i.e., NSAP) addresses.

Which is basically describing AAAA records.

[lowercased]

IPv6 format is just too damn confusing and mental overhead.

Prefixing all IPv4 with 0.0, opens up another 64k copies of the 4 billion address space of a.b.c.d. This would have been far easier for everyone (not just a few admins, but everyone that ever has to deal with an IP address) - to understand and deal with. It still could be, with the aforementioned-yet-not-developed-nor-propsed IPv7.

[stephen_g]

Sorry, that is a misinformed view. Your proposal has exactly the same problem IPv6 has - all network hardware knows the format of an IPv4 header, and you can’t fit larger addresses in it without changing all network hardware and software. So large swathes of the internet would be inaccessible until all those routers, firewalls, middle boxes, cell towers, etc. are replaced, which would take another 20 years! Whereas it’s mostly been done for IPv6.

[kazen44]

20 years to replace core infra is optimistic in a lot of places.

I've seen some places running ATM hardware which was phased out two years ago. it has been running for well over 20 years.

people also seem to forget that with a new network protocol, new designs probably need to be made to make use of new (much needed) features.

those designs already exist in ipv6.