"Naive" is an inadequate word. We are still futzing with the transition 3 decades later, with no end in sight. Grrr, grumble...

"Please just try to fit more than 4 billion numbers into 4 bytes" -- this is mathematically impossible.

"Just extend the address size" -- this is an entirely new protocol by the definition of IPv4, which uses fixed-size addresses.

The reason for the slow IPv6 adoption is that there was no financial or business pressure. While IPv4 is ubiquitous, nobody individually feels a need to migrate to IPv6.

E.g.: How many customers would you gain by supporting IPv6? Generally zero. That doesn't sell well internally when the network team is asking for a budget.

The IPv6 transition will be like a bankruptcy: very slowly, slowly, then all of a sudden.

The sudden bit will happen when IPv4 address will cost $1K to $10K annually. At that point, customers will be reaching those IPv4 endpoints via three layers of proxies or NAT gateways, and IPv6 will be noticeably faster, more reliable, and free.

So every owner of a ipv4 would get, say, an entire 32 bit space that routes over existing IPv4 infrastructure. So, if the endpoints are upgraded, you have guaranteed end-to-end deliverability without silly hacks such as NAT or STUN.

This doesn't solve the "backwards compatibility" problem itself, because you still have two logical different IP networks running on top of each other, requiring separate name resolution, etc. But what it does solve is the "incentive problem": endpoints are incentivized to upgrade because it gives them an immediate benefit, end-to-end connectivity to other upgraded users with non-routable addresses sitting behind a dumb, non-upgraded IPv4 routers.

For example, VoIP or P2P software would immediately benefit and it would drive adoption for an immediate use-case. In the later stage, when the entire infrastructure can understand the extended packet format, you would start to publish extended routes that don't fall into the hierarchical range, similar to IPv6 today.

IPv6 lacks any such incentive, because me upgrading and enabling it has zero benefits until all hops separating me from the internet also enable it and correctly configure it. On the contrary, by requiring a completely new, complex configuration with no "default, just works" mode, IPv6 introduces a disincentive, because by enabling it not only do I not gain anything, but I risk breaking my internet due to misconfigured upstream. So the conservative setting for IpV6 has, for the last 3 decades, remained "off". This only recently began to change.

The backwards incompatibility is irreducible, inherent to the special place of Layer 3 in the networking stack.

No. The NAT64 hack involves intercepting the DNS requests and rewriting the IPv6 packets in flight so that the IPv6 only clients see outside IPv4 hosts as IPv6. Among many issues, it breaks any end-to-end encrypted protocol that includes IP literals, such as FTP and SIP.

Also, NAT64 presents no immediate benefit to a client upgrading in a IPv4 only environment, since it still doesn't allow two clients behind NAT64 gateways to connect to each other if there isn't an IPv6 connection between them. So the same old IPv6 self-fulfilling tragedy, everybody must upgrade before anybody can see any benefit, therefore nobody upgrades (or uses NAT64).

The main benefit of a backwards compatible packet format is that IPv4.1 islands see each other from day one in the legacy IPv4 internet and get the full benefits of the new protocol, without any configuration or tunnels. The "encapsulation" seen by legacy hops is in fact the canonical, definitive packet structure, there is no temporary transition technology that can break or needs to be configured.

> the problem of IPv4 clients trying to connect to servers with only IPv6 addresses

This is not a problem that can or should be solved, and it's not the problem significantly preventing IPv6 adoption. A non-upgraded client will just see an IPv4 internet, just like an USB 1.0 won't be able to use USB 2.0 speeds.

The difference is that, while a software&hardware upgrade to IPv6 won't bring you any new connectivity without extra configuration from your upstream provider, an IPv4.1 upgrade will instantly allow you to see (and connect end-to-end) to all existing IPv4.1 islands and hosts, using only your legacy, IPv4 connection. The hierarchical extended address space (IPv4 subdivisions) is immediately available, incentivizing adoption without risking connection issues, while the upward extended space becomes available when you have a native IPv4.1 connections, just like with IPv6.

2. Of course there's no immediate benefit for IPv4 clients - there isn't in your proposal either! It's a compatibility measure, allowing IPv6-only clients to talk to IPv4 servers. (I make that distinction because under no scheme can an IPv4 host initiate a connection to a host with no IPv4 address.)

3. I have no idea what you're talking about with the idea that NAT64 requires IPv4 clients to talk to each other over an IPv6 subsegment. I suspect you're thinking of a different transition technology solving a different problem. NAT64 provides a virtual IPv6 subnet containing the entire IPv4 address space. IPv6 clients can send packets to this subnet, at which point they are routed to the nearest NATting gateway and passed into the v4 internet after packet rewriting.

4. FTP and SIP containing IP literals is an irreducible incompatibility, which cannot accommodate an address size change without intrusive packet rewriting anyway.

You also have to deploy new DNS code to handle a new record type to handle longer "IPv4+" addresses.

You also have to deploy new OS and library code with new socket, etc, APIs because all in_addr_t definitions and data structures are 32-bit-only.

What hardware, especially ASICs, do not support wire speed IPv6 and have not for a decade or two?

T-Mobile was gave a presentation on going IPv6-only in 2017:

> For the past 10 years T-Mobile has worked towards creating an IPv6 environment and we are now getting very close to our goal. Stephan presents learning on how to successfully enable IPv6-only using DNS64 with or without 464XLAT. He will do a live demo of the different IP interfaces on an Android handset. Finally, he will discuss and give some best practices on how to handle DNS, applications, and websites that are having issues with DNS64.

* https://www.youtube.com/watch?v=nNMNglk_CvE

So they started in 2007.

Whatever ISP you're with has probably had at least 2-3 tech refreshes in which IPv6 hardware has been available.

For the CPE, Free in France had IPv6 in 2007:

* https://en.wikipedia.org/wiki/IPv6_rapid_deployment

That is called DS-Lite and we have it

Still doesn't solve a problem of old clients not being able to access new servers

No. DS lite is a technology that allows the ISPs to upgrade to IPv6 while their clients do not. This is not the problem preventing IPv6 adoption, quite the contrary, clients support IPv6 from the Windows 2000 and Linux 2.1 era. What held back adoption is precisely that most ISPs don't bother with IPv6, which is an extra headache in configuration and man hours, as long as it provides no benefit to the end user.

The beauty of a backwards compatible packet format is that it takes the last mile ISP completely out of the equation, clients upgrade when they see benefits, and instantly get end-to-end connectivity. This is important for VoIP, push to mobiles etc.

> Still doesn't solve a problem of old clients not being able to access new servers

See sibling comment on why this is not the right problem to solve either.

So… NAT.

Critically, this solves the cold start and connectability problem of NAT: if you get a packet addressed to your outside IP, to a port that has no memorized mapping, to what internal IP do you send it to? Lacking a static or UPnP port assignment, it can only be dropped. The extended packet format would provide this information for every packet, the upgraded outside host would tell you what upgraded internal host it wants to talk to.

Yes, NAT is not a firewall --yet we don't see admins eager to put random lan hosts in the DMZ or enable UPnP.

It's how things work with IPv6, which doesn't have NAT (by default): just because a host has a globally routable address does not mean it is reachable by default.

No. Tunnels encapsulate IPv6 traffic but they need to be set up, I need to know a gateway that is willing to take my traffic, decapsulate it and place it on the IPv6 internet. There are many reasons this is bad idea, it won't ever scale, it's fragile etc. 6rd doesn't improve things significantly.

A backwards compatible packet format will allow you to connect directly to IPv4.1 islands, without any configuration or choke point: the packets you place on the wire have the final extended structure, even if they appear as encapsulation to the legacy IPv4 hosts in the path.

It's as if any IPv6 host on the internet is guaranteed to have its own 6to4 gateway, and the encapsulation just happens to be the exact IPv6 packet / IPv4 compatible structure that you use to connect to any other non-gatewayed host.

Do you mean applying some kind of network address translation?

> So every owner of a ipv4 would get, say, an entire 32 bit space that routes over existing IPv4 infrastructure. So, if the endpoints are upgraded, you have guaranteed end-to-end deliverability without silly hacks such as NAT or STUN.

Ahem.

One major problem is dual stack. It doubles the workload for very limited benefit. You have all the downsides of making ipv4 work in the first place. You've then got all sorts of messes like NAT66 (ipv6 was supposed to get rid of NAT), a lack of clarity on which patch to use (NPTv6 and NAT66 are two different options for the same problem, a problem which was built into ipv6 in the first place), messy hacks like DNS64

Instead had the approach been ipv6 only from the start, with no dual-stack, having the OS transparently deal with sockets to ipv4 devices by converting to the ipv6 mapped address (:ffff:xxxxxxx), and thus eliminating the need for dual stack from the start, things would have moved far far faster. You'd be able to communicate with ipv6 by using stateful NAT at the edge of your ipv6 network (as you do now at the edge of your RFC1918 network), you could expose services on your ipv6 only devices with natting (as you do now).

You'd still have A and AAAA records, your client having an ipv6 stack could prefer AAAA instead of A, but if it needed to use an A record (or someone just tried to connect to 12.34.56.78) the stack would have gone "ok I'm ipv6 only, I'll connect to :ffff:12.34.56.78" and rely on the network to make it happen.

Throw in things like NPTv6 and 464XLAT from the start (rather than 16+ years in) -- the addons which were created to address the fundamental architectural flaws in ipv6 -- and you'd have had a far smoother transition.

There was no way to make the transition to IPv6 without dual stack. The problem was much more that the precise dual-stack approach was not well thought out, when it should have been a fundamental part of the IPv6 RFC itself.

Any ISP who wishes to move to IPv6 still to this day has to consider how it will handle clients that don't speak IPv6, servers that don't speak IPv6, routers they own that don't speak IPv6, and peers who don't speak IPv6. There is no way to make all of this work without having devices that translate between the two (losing most of the benefits of IPv6 when going through this translation, of course).

When you've spent 10 million dollars or more on a router that doesn't speak IPv6, you don't change it one year later just because a new protocol has come up. That thing is there to stay for 5-10 years, and you just work around it as best you can.

> Any solution to the 4->6 transition that assumes that all devices of some class (be it clients, servers, or middleboxes) moved to IPv6 at once is deluded and would not work.

464xlat allows communication from ipv6 only clients to legacy ipv4 ones without the need for a separate stack on your end device

nat46 allows communication from a legacy v4 device to a modern v6 device without the need for a separate stack on your end device

Had ipv6 transition been thought about better back in the 90s then you could have deployed your new subnets as ipv6 only back in 2005 and still communicate with all your older kit.

> That thing is there to stay for 5-10 years, and you just work around it as best you can.

IPv6 is 30 years old. I sweat assets like there's no tomorrow but the oldest kit I've got active today is less than half that. Even for ipv4 only devices, a single legacy subnet would be reachable from my v6-only management devices via my ipv6 backbone via 464xlat

> nat46 allows communication from a legacy v4 device to a modern v6 device without the need for a separate stack on your end device

How does that work if your ISP doesn't support IPv6? Can an OS developer deliver IPv6-only OSs to any end user? How about v4-only VPNs? Ultimately the answer is that devices must support both IPv4 and v6 until the day only one remains. Keeping both active at the same time may be more optional, but there is plenty of software which assumes IPv4 at other layers than simple connectivity. So running IPv6-only is generally a bad idea even today.

Two decades ago I was a member of a ISP consumer group, and we discussed it with a couple ISPs back then. They all were working on a planning for it (one smaller ISP even already implemented it back then!). Apparently in other countries ISPs were allowed to behave irresponsibly.

Really, the only way to force such incompetent ISPs out is if governments get involved, or if all/most backbone providers and IX operators set a date where IPv4 will become very expensive, and then one where it will be switched off...

This is, indeed, how dual-stack works; you open a PF_INET6 socket and use sockaddr_in6 addresses for everything, including IPv4 (which get mapped to ::ffff:/96 addresses). Been like that essentially forever. The “dual” in dual stack refers to the OS' stacks, not userspace.

The year is 2023, The chromium engine is full blown operating system, it has notifications, background task management, GPU acceleration for general compute, it's larger than Windows XP, and can in fact run windows XP in the browser. Teams consumes 500 mb of ram to do the same job ICQ did in 2002 with 5 mb of ram. Cars have 4G, lightbulbs need updates and security patches.

But Ipv6 features take a few extra bytes and are a problem.

Some people pay for each extra byte they have to send through a network, and design whole systems around the goal of minimizing the amount of data they ship around.

No one pays for the extra free gigabyte that Chrome takes over.

Sure they do. It just doesn’t show up in Chrome’s metrics so Chrome doesn’t care about it.

* Start-up time of other applications. If a program needs 1 GB of RAM, and Chrome is holding all but 512 MB, then the program must perform multiple allocations, waiting for Chrome to release its cache after each one.

* Smaller cache in other programs. Consider a program that can run with 4 MB of RAM, but could use up to 1 GB of RAM to cache intermediate results and improve performance. Such a program would check the amount of RAM available and scale their own cache size accordingly.

* Competing caches in multiple Chrome instances. Multiple independent Chrome instances, such as from Electron shells, each try to cache as much as possible until RAM is exhausted.

For Netflix the cost is actually especially low. Cost as a percent of bandwidth is (a few bytes / packet size), and when you're streaming enormous media files packets are almost always max size.

From looking it up it looks like it's mostly required when IP's change (e.g. when you change ISP), which for me is more of an argument to use DNS if you want fixed addresses.

And even if you run your internal services with only an AAAA record pointing to the ULA, the client's source address will likely be the global address of the client device unless you tweak the tables on each client, which then means you'll need to have your global address in all your firewall rules to access the internal services on ULAs, which then means you're not saved from having your ISP-provided global address in your configuration, which is what you were trying to avoid by using ULAs.

The problems this caused/s seems to have been an unintended / unforeseen consequence that was more exposed as people gained experience. There's a draft being worked on to officially change the priority:

> The behavior of ULA addressing as defined by [RFC6724] is preferred below legacy IPv4 addressing, thus rendering ULA IPv6 deployment functionally unusable in IPv4 / IPv6 dual-stacked environments. The lack of a consistent and supportable way to manipulate this behavior, across all platforms and at scale is counter to the operational behavior of GUA IPv6 addressing on nearly all modern operating systems that leverage a preference model based on [RFC6724].

* https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-ula

The existence of fridges with twitter integration proves that there is a need to a Lettice to tweet.

There are all kinds of things that exist, steam-powered motorbike among them. Not all of them exist for the right reasons.

Would you rather have a bunch of routers sending out advertisements which every client needs to sort out, or have one consistent multi wan load balancing/failover policy that is transparent to clients?

That's so much simpler than simple src-natting your clients at the edge of your control and routing your outgoing traffic based on a policy at your natting device /s

Using a firewall is obviously an option, but why give an IP to something you don’t want accessible by the outside world?

There's something that works even better as an ultra simple firewall: An ultra simple firewall!

> why give an IP to something you don’t want accessible by the outside world?

- You might change your mind about it needing to be accessible by the outside world, and if it already has a global address you don't need to renumber everything.

- Addressing and routing aren't the same thing; it can be useful to have globally unique addressing even without global reachability.

Thus proving that ipv6 failed in it's mission to get rid of nat

The uses that I found while searching weren't very convincing, I was hoping you could give an example.

Take USB for example. The capabilities of USB 3.1, 3.0, 2.0 is impossible to achieve for USB 1.0. So is high-speed charging.

However, the end-user experience is generally pleasant, nitpicks around some of USB-IF's specific choices aside.

The "end-user experience" IPv6 equivalent of the USB version transition is that a person browsing to "www.google.com" has no clue whatsoever that it actually went via IPv6 instead of IPv4.

Just like with USB 1 to 4, IPv6 goes down the same cables and works the same at the application layer. Some changes occurred, but changes are mandatory for things to change.

You're asking for USB 4 to be magically "the same" as USB 1.0 while sending tens of gigabits over the wires -- not for the end users -- but for the lazy electrical engineers that can't be bothered to update their designs!

This is a fundamental problem. Backwards compatibility (without introducing translation schemes and middleboxes) is literally impossible.

But no, someone said we must redo whole stack and we need every piece of sand to have public routable address..so now we are stuck between rock (old fossilized IPv4) and hard place (completely incompatible IPv6).

No it is not:

* You also have to deploy new DNS code to handle a new record type to handle longer "IPv4+" addresses.

* You also have to deploy new OS and library code with new socket, etc, APIs because all in_addr_t definitions and data structures are 32-bit-only.

If a public service has a "IPv4+" address, how does a not-IPv4+ host, or not-IPv4+ compliant code handle it? If you want >4B addresses you have to tweak all the code that touches address structures. You have to (re)deploy code on all the network elements that touch the packet bits: all the end-user applications (browsers, chat clients, etc), all the end-user operating systems, all the middle-boxes, all the routers. If you have network devices and segments between the public service and the client that are not IPv4+ compliant, you have to configure the clients to send the IPv4+ traffic to translation boxes that are IPv4+ compliant.

Basically all the stuff that is happening with IPv6.

You're re-inventing IPv6.

You're using different words, but you've got a separate addressing scheme, and dependence on proxies to enable everyone to talk to each other. This is exactly where we are with IPv6.

> You could instead move this "port" directly into IP header in backward-compatible way

If you're changing the meaning of the headers, it is by definition not backwards compatible.

There is also no specified way to convert USB 3 to USB 2, but some have tried, with mixed results.

Option 1: "6to4" https://en.wikipedia.org/wiki/6to4

Option 2: "nat64" https://en.wikipedia.org/wiki/NAT64 + DNS64

Option 2b: "nat46" (which makes a few ipv6 hosts available over ipv4 if yo ulike)

Option 3: "Teredo" (also known as "6in4" "tunnel broker" "6over4" "tunneling" ...) https://en.wikipedia.org/wiki/Teredo_tunneling

Option 4: 6rd https://en.wikipedia.org/wiki/IPv6_rapid_deployment

Option 5: ffff/96 (yes I get it, only works if host has both ipv4 and ipv6, on the plus side: no need for the network to support it. Mostly for applications)

Option 6: DS-lite https://en.wikipedia.org/wiki/IPv6_transition_mechanism#Dual...

And then there's the weird ones: https://en.wikipedia.org/wiki/IPv6_transition_mechanism

The issue is most of these require ISPs to deploy new hardware, or deploy new network services. The problem is that network hardware is single-purpose, because only single purpose hardware can sustain the speeds we demand of internet networks. This means a lot of hardware needs to be replaced in order to make the global IPv6 transition and, short of redesigning IPv4, which is 43 years old now, there's no other way to make the transition. All these solutions require either work by your ISP, or work by you yourself on all your hosts.

Section 5.5:

    CRITERION
        The protocol must have a straightforward transition plan from the current IPv4.

  Category: Informational

  Publication of this document does not imply acceptance by the IPng Area of any ideas expressed within.

Clients can be IPv6 only and ideally need a CLAT installed to handle the edge case of IPv4 literals in apps that don't use DNS. The ISP's internal network can be IPv6 only. Only this NAT64 translator needs to speak both IPv6 and IPv4, and only for non-IPv6 traffic.

So there is a bit of a demand, especially here, for forward compatibility.

You need new protocol, sure. But do you _have_ to switch from "1 almost fixed address per interface" to "tons of addresses per interface and dynamically changing"? Did you have to present it as a separate protocol to apps? Did you have to use : in representation, breaking most ad-hoc text processing code? etc..

if they goal was "herr is a new verion of IPv4 with same semantics" then we'd just need to wait for new kernels and libraries to come out, and it would be all done years ago.

There are billions of phones so sure, they should be on ipv6. ipv6 is a kind of super NAT that few people bother to learn

Sorry about that ipv6 committee

true, for now.

sometime it will reverse and i am exited about what will happen in/with the "legacy internet"

That would have saved a lot of pain.

How would that be an improvement over the existing situation?

NAT seems to always get a bad rep because it inconveniences the very few that want to have an end to end experience, but there has to be some sacrifice to keep the Internet running for the billions of users.

NAT and by extension CGNAT are the unsung heroes of the Internet.

That's a tautology: "Despite the limitations of IPv4, we're still supporting all the applications that can work within the limitations of IPv4".

Lots of potential P2P applications (that might solve a lot of problems with have with the current centralised model of the internet) either don't make it past the drawing board because of NAT, or have to be encumbered with complex, expensive-to-develop, best-effort NAT-punching behaviour that burdens everyone involved (and can stop an application from being truly P2P by having to run things like STUN servers).

>NAT seems to always get a bad rep because it inconveniences the very few that want to have an end to end experience

I think there would be many more that wanted this if it were trivially easy to do

>but there has to be some sacrifice to keep the Internet running for the billions of users.

What's the sacrifice in using IPv6?

I've seen figures from proponents of Future Internet Architectures such as Named Data Networking claim that consumption is about 80% of Internet traffic. The truth is not everyone needs a Internet addressable host, mobile phones for example don't. And well, we're living in this situation today with CGNAT and you don't hear complaints from customers about not having Internet addressable IPs.

> What's the sacrifice in using IPv6?

Support. Enabling IPv6 on broadband consumer networks, small medium businesses, etc. means that you have to support the various devices v6 stacks and applications and ensure they continue to work just as well as they did with IPv4. IPv6 can still cause damage and the ability to support and fix these issues throw out virtually all incumbent knowledge.

If it were really just a "flip of a switch", everyone would've done it by now.

Gamers get errors about "strict NAT." Traditionally the solution to this problem caused by NAT was to forward the ports. If their ISPs has chosen CGNAT port forwarding is impossible.

VoIP calls that have one way audio are a symptom of reachability issues caused by a firewall or address translation problems. VoIP services have adapted to IPv4 NAT by relying on proxying instead of STUN but CGNAT really degrades reliability.

Smaller newer ISPs that can't obtain one IPv4 address per household are incurring signicant CGNAT costs. https://news.ycombinator.com/item?id=35047624

Video chat uses the kludges of TURN when peer to peer connectivity does not work. This increases costs for the video chat service who in turn require a paid subscription as they will not relay traffic for free.

BitTorrent and file transfer services need direct IP connectivity. If p2p file transfers worked on any network we would not need to mind Gmail's 25MB attachment limit, or pay for intermediary cloud storage.

A CGNAT is a stateful component which makes it expensive to operate. Failover to a backup is hard, as is scalability with this kind of components. And then there are legal requirements. You have to know what user had which IP address at a given time. I'd rather invest in dual stack instead.

It can open the firewall simply by sending something. If it can communicate its public-facing ipv6 address/src port number to the remote side using a SIP proxy (ok, for this signalling, you need a relay), it can receive traffic. No TURN needed either.

What scenario do you have in mind?

The second option may not even work with more paranoid firewalls, which might not allow TCP SYN packets on existing connections.

Though granted, there is support and support. I use hyperoptic in the UK as an ISP. I replaced the native router and I still can't figure out a way to get an IPv6 address.

I don't think that's true.

Some services on the internet are already made available through IPv6. Doesn't that mean their migration to IPv6 is done?

There are however some ISPs that seem to be dragging their feet. I recall I tried to deprecate IPv4 access to a personal project of mine and it was no longer reachable when I tried to access it from my home. Lookups from other points of the world could resolve the IP but not my little home network. I felt forced to continue paying the 2€ I paid for a IPv4 address just because of that.

Edit: to make it abundantly clear, I'm looking at you, Vodafone. You suck.

I don't think that's an informed, thought-out take. The internet works just fine for all intents and purposes if you have some services reachable through IPv4. There is no obligation to shut down IPv4 in order to work with IPv6.

If you're able to go through your daily work seamlessly hitting services with IPv6, that's a successful migration. It matters nothing if an unrelated service hasn't went through their migration yet.

NO!!!

this is what the parent comment meant about ipv6 design. Add an octet and that's it. Same protocol with same rules just a bigger address.

It may be a different version of IP but the protocol and supporting protocols like ARP and DHCP just need to support the new IP.

The reason IPv6 failed is the same reason why when new devs join a team, they find how everything is wrong and try to fix it all and leave a bigger mess than what they started with. You solve problems one step at a time. Overhauls are only justified when your objective is specifically to improve the whole system.

"The reason for the slow IPv6 adoption is that there was no financial or business pressure."

That is only part of the reason. The other part is it is a pain to use, there is no way to use it without also supporting v4 and on top of that you have to learn and adapt other new protocols, addressing schemes, gotcha's and much more.

Just add a freaking octet!

So no router can route it sensibly and no existing client works ? How would that help ?

That's a fresh alternative to the boiling frog metaphor.

Hi, I've adopted it for many reasons and I'm happy. You'll need to update your count. Seriously though, there's lots of people who adopted it - you'll need some more data for a generalisation like this.

> We have to keep shoehorning apps into 64k ports

With ipv6 you typically get a whole range assigned to your machine rather than a single address. Why expand ports, when you can assign millions of apps to different addresses, with the same port that correctly identifies the service type? As a bonus, this already works with DNS AAAA entries so you don't have to mess with SRV to find the right port.

IPv6 is as backward compatible as is possible within this constraint. You can embed IPv4 space within IPv6, there is NAT64, tunneling IPv6 over IPv4 and many other transition technologies. It's not possible to design a protocol that is any more backwards-compatible.

Yikes, couldn't disagree with that more. There are a ton of things that ipv6 designers could have done to make the transition much easier. This is a (now quite old) blog post that is my "go to" that explains a lot of the problems with ipv6: https://cr.yp.to/djbdns/ipv6mess.html

FWIW I couldn't find the link to that post until finding it on one of the comments here, https://news.ycombinator.com/item?id=33894933 . That whole thread has lots of good commentary.

I still don't understand how people can defend ipv6. I remember the "we better get ready to switch to ipv6" noise a quarter century ago when I started my career. And yet we're still talking about how v4 addresses are worth billions. Ipv6 has been an unmitigated disaster. The original architects should have "the perfect is the enemy of the good" forcibly tattooed on their foreheads.

Bernstein was certainly part of that discussion, at the later stages, and the document you link to reflected that. It was just one of many counter proposals that influenced what became IPv6.

Some people seem to suggest that Internet standards are written in some ivory tower and dropped down on the network engineers to implement. In that light, such criticism of IPv6 would be valid and important. But the IETF does not work like that. You can take part, and I can take part, and any reasonable criticism is discussed in the open. In general, practical proposals and code is taken more seriously than loose ideas.

There is no central command which decides what you or any other network operator should implement. People all over the world implements what they think is good for their network, in order to interoperate with other networks. If anything, Internet standard can be criticized for being slow to fruition because of this open process. That's the price we pay.

It's not very useful to come 20 years later and re-hash the exact same discussion all over again. All counter proposals turned out to be impossible to deploy, and the consensus and running code we ended up with is what we call IPv6. A dual stack approach was the only solution practical enough to get general deployment. There are certainly problems with any protocol, and let's suggest improvements and new protocols. Just make them relevant today if they should have any chance of deployment.

I'm not complaining as if to say "yeah guys, let's stop the ipv6 rollout and do ipv10" or whatever. But I think it is useful to see why the problems of ipv6 came about. A great comment from one of the linked HN threads said "ipv6 was a product of it's time", a time (I put it at mid 90s to mid 00s) when there were a ton of over-complicated, over-engineered specs that were designed by committee. Some examples:

1. XML, and all its complexities and incompatible versions (I still have some PTSD from some Java XML version incompatibilities), vs. what the industry discovered to be the much simpler and now much more widely used JSON.

2. The insanity of SOAP vs. something like REST.

3. The original Enterprise Java Beans spec. Feel like "'nuff said" is good enough here, what a nightmarish shit show that was.

Thankfully I think the industry has largely learned its lesson when it comes to valuing simple even if imperfect specs. But I still totally disagree that "ipv6 is the best we could have done".

You can criticize IPsec and mobile IP which was tacked on to the spec. But starting from scratch, a core IP v6 stack is easier to implement than a v4. The TCP parts is downright nasty in comparison.

Most importantly, IPv6 was developed in the open. IETF is the counter example to design-by-committee. That's true today, and that was doubly true twenty years ago.

Every discussion since them mostly concerns resurrecting old ideas about either impractical extensions (misusing port numbers and flags to extend addressing, none of these schemes have been proven practical), more efficient address space allocations (which would have bought us a couple of years, at most) or various ways to tunnel traffic in backwards compatible ways (which is what we did back when 6bone was a thing, but which is not useful anymore).

The mailing lists are completely open. You can join any one of them today, and people did. You can still follow how the discussions went in the archives. Hopefully no one has suggested that IPv6 is the best we can do, but that the process still works and that anyone capable and interested is welcome to attend.

As to whether the industry's obsession with complexity has faded, I bring you Kubernetes.

I do not mean no changes at a binary level, but at an administrative level. An upgraded "A" record for example so that DNS admins could go about their day somewhere between completely and largely unaware that the protocol was undergoing transparent upgrades behind the scenes while preserving administrative compatibility with all existing configuration files, source data, and user interfaces. In such a scheme it would be quite important that there only be one "A" record from an administrative point of view, not different ones like A and AAAA. Admins need to be insulated from the binary protocol changes going on behind the scenes.

That means that the new address format would need to be compatible with the old one, and of course a routable embedding of the current address space be provided in the new address space. That means existing routing prefixes would have to be preserved indefinitely, complete with the routing table explosion that was a major challenge a couple of decades ago.

All routers would need to be upgraded over the transition period to handle a new frame type that supported current addresses, extended addresses, and a single routing table with larger extended address sizes. It is quite important that there be a single routing table, not two of them. Same configuration file, same everything from an administrative point of view for a decade, while older hardware was gradually replaced with new hardware that had extended capabilities that would be dormant on the public net.

Comparable and in some cases less transparent updates would need to be made to programming APIs, and to the Berkeley socket API in particular. Not to require programmers to do everything for two different layer 3 protocols, but rather to allow them to do it once and have it work with current and extended addresses, transparently from an administrative point of view, not doubled configuration for anything.

There are many other things that would need comparable binary behind the scenes upgrades that would be administratively compatible and not affect current network configuration files, and in particular not require anything to be duplicated from an administrative point of view. No one does that and no one wants to for protocol extensions that are not actually usable yet. It doubles their workload with no short term benefit, and does so indefensibly.

And then after all these extensions and capabilities have been designed, implemented, and transparently deployed across essentially the entire Internet without requiring large scale administrative intervention - a process that could easily take a decade - would the first extended addresses with non-zero bits in the extension fields actually be usable and globally routable in both directions. The entire network would be ready for it, it would be a dormant capability unused until that day arrived and requiring no large scale intervention when that day arrived either, because the silently upgraded network would remain administratively compatible with the old one.

The incentives for vendors to implement it are just not there, since the customer is not actually going to use the expanded address-space feature at all for at least a decade, so why bother implementing it and break the existing stuff in the process? While with IPv6 you could at least somewhat use it right away or at least implement it on the side, where it won't break the existing stuff. And even if you get the vendor to implement it, chances are they are gonna do it the same way IPv6 got implemented initially: By routing it software, so performance is going to absolutely suck. So the first decade after the proposed flag day performance is going to suck until everyone has upgraded their hardware that can do both in hardware.

Next are the random boxes (firewalls or NAT boxes) that will happily mangle all your option bits in the IPv4 header for no reason. Of course while you haven't used any expanded address space everything will seem fine and might even work fine in the lab, but once your flag day arrives and people are supposed to start using it, you will realize it doesn't actually work, because of all those broken boxes in the wild and fun routing bugs and so forth.

And then you get all the regular bugs that come with making any change that were hidden by no one actually using it. You get all the phases IPv6 went through, but much worse and with a couple decades of delay.

The only way to make things work is by using it. The earlier one gets started the better. Wishing really hard does nothing.

Most of the other criticism is not relevant anymore, since we now have a lot of transition technologies that allow IPv6 clients to interoperate with IPv4 servers (this way around is possible since IPv6 is a superset of IPv4). Overall we are now much further into the IPv6 migration than djb ever envisioned.

The only way to remain incentive compatible is to remain administratively compatible, and that is where IPv6 as presently constituted fails dramatically by requiring two independent network configurations to be maintained for the better part of a century, without giving anyone an incremental incentive to maintain the second one, leading to a hold out problem.

The public switched phone network has gone through major upgrades and yet at no point did someone say we are going to throw out all your existing phone numbers and require you to get new ones, or require you to have two independent and incompatible phone numbers that you put on your business cards, have two phones on your desk, or a phone with a mode selection button depending on whether you wanted to call a new style phone number or an old style phone number.

And that - from an administrative point of view - is the fundamental problem with the deployment of IPv6 as we know it. Dual stack now and for decades to come. Dual stack anything is not incentive compatible and should never have been done. The proper solution is single stack everything with capabilities that are dormant until they are deployed on a global level as part of the normal upgrade process in an administratively compatible fashion so that no large scale administrative intervention is required now or at any time in the future.

Other changes were made in the early days, like the introduction of dialing, then long distance dialing.

SLACC, interface-specific link-local address both look good in paper but cause lots real life headache.

When it works, it works; when it don't, you have to unlearn and relearn everything network before you could possibly understand the problem, let alone fixing them.

Let me summarize my understanding of what he's saying, because I don't quite see why/how you disagree. I think you (or I) might be misunderstanding his claim.

Imagine this topology: C (client, IPv4-only) <=> R (intermediate router) <=> S (server)

My understanding of djb is he's saying that IPv6 could have been designed such that S could still serve C via only simple software updates -- this means, crucially, without the need for S to separately obtain a public IPv6 address through R, because its IPv4 address would be automatically valid for IPv6.

How can this work? Well, there are two scenarios:

1. If R is IPv4-only, then S could figure that out during some startup/negotiation process, and send only IPv4 packets to R. R only lets IPv4 clients connect to S anyway, so any response (even from IPv6 applications) on S must be going back to an IPv4 address. So the kernel can transparently translate those IPv6 addresses into IPv4 before passing them along to R, and vice-versa.

2. If R supports IPv6, then R can do the same thing S would've done in the previous^ scenario. (In fact, I think S could become IPv6-communication-only in that case, reserving IPv4 for just address leasing? I'm not sure, but in any case, I don't think that matters here.)

Notice that all of this is almost completely stateless. (I think the only state S needs to track here is 1 bit, indicating whether R supports IPv6 or not.) So, S and R can be independently and (importantly, rather trivially) upgraded to support the IPv6 protocol, without losing the ability to talk to any clients within the IPv4 address range.

This is easy and requires no explicit leasing of IPv6 addresses. That step can be implemented and have support for it added later, whenever S is ready to serve clients beyond the IPv4 address space.

Does this make sense? If so, then it seems to show how IPv4-only clients could talk to IPv6 servers without modification. If not, then I'd love to see where I'm mistaken (I very well might be).

The inverse situation (IPv6-only client but IPv4-only server) is not really an issue, since for that situation NAT64 works, since you can embed IPv4 addresses into IPv6.

The only way C (ipv4-only) could communicate with S (ipv6-only) is by either allocating a dedicated ipv4-address to S (doesn't have to be directly connected to S - it can be sent to some translation box that does SIIT) or by upgrading C to support ipv6 and tunneling it (6to4, 6rd, teredo, etc.).

If S is IPv6-only, then either the address is from the IPv4 range, or it's not. If it is, then R can translate between them. If not, then they can't connect. I don't see him suggesting otherwise anywhere.

Even ignoring translation possibility, his point here isn't to claim its magically possible for a server outside the IPv4 address range to talk to an IPv4 client. His point is that this can move everyone to IPv6 for communication, without ISPs also having to deal with leasing addresses outside the IPv4 range, which he believes would help adoption.

But maybe I should reread the article a bit more generously and less literally, maybe he is actually advocating for the IPv6 we have today? Because there are transition technologies like NAT64, SIIT, 6to4, 6rd, etc. that sort of allow some of the things he suggested? "If the IPv6 configuration isn't automatic, it won't happen." sounds like he is actually advocating SLAAC to me?

> What else could he have meant with "In other words: The current IPv6 specifications don't allow public IPv6 addresses to send packets to public IPv4 addresses."

He could've meant "making IPv6 work means much more than upgrading software. Every administrator of a server on a public IPv4 address has to go to extra effort to acquire and enable a public IPv6 address."

You cannot read this and miss the fact that his frustration is with the need for administrators to acquire separate IPv6 addresses.

> maybe I should reread the article a bit more generously and less literally

No need to do either. Just read all of it, instead of 1 or 2 sentences that might sound like amateurish mistakes when you remove several pages of context and then extrapolate without them.

Adding the address to the server is the easiest part of the whole process. Upgrading the software is probably the biggest hurdle with people just hardcoding things to 32-bit left and right (and some badly designed APIs which do either IPv4 or IPv6 but not both in a transparent fashion). And next is actually setting up ipv6 connectivity.

All those other things you would still have to take care of even if you magically could keep using the IPv4 address in IPv6 (however that would work). Never mind that servers don't statically sit around forever, but one has to set up new servers all the time.

So why not go for the inverse approach for new servers? Only give the servers IPv6 addresses and for those servers that still need to be reached via the public IPv4 internet (most internal ones probably have no need of this) can be accessed via SIIT, which performs stateless mapping between IPv4 and IPv6 (for example IPv4 1.2.3.4 gets translated to IPv6 2001:db8::1.2.3.4 and vice versa).

Funny, because the reality is that the software has for the most part been written and the hard part is acquiring v6 addresses. The problem is it isn't just a matter of acquiring a v6 address, it's also supporting the software that the v6 address runs on, and having it work the exact same way as v4.

    The answer is that I'm actually talking about a huge number of IPv4 sites. There's nothing special about my site. When the same situation is repeated at N sites, the code is written only once, while the trivial requests and the trivial configuration changes are repeated N times.
    .
    .
    .
    Well, I'm looking at a much larger group of users, and most of them aren't putting even five seconds into IPv6. They have better things to do. If the IPv6 configuration isn't automatic, it won't happen.

I'm unfamiliar with SIIT, but I bet it doesn't get us closer to the "magic moment" or we would be flocking to IPv6 addresses:

    The magic moment for IPv6 will be the moment when people can start relying on public IPv6 addresses as replacements for public IPv4 addresses. That's the moment when the Internet will no longer be threatened by the IPv4 address crunch.

You don't need to agree with me on what he's saying. The quote "...extra effort to acquire and enable a public IPv6 address" is a directly copied from his own page. It doesn't make sense to read that and claim that's not what he's saying, or to claim I'm "interpreting" it to mean that. That quote is what he's saying.

> even if you magically could keep using the IPv4 address in IPv6 (however that would work)

It's not magical, I explained it in [1]. And he himself started to explain it when he wrote "The specifications could have [...], but they didn't", but he didn't finish the thought, and just left the reader to figure out the rest of it. (Which, again, I explained in [1].)

> Adding the address to the server is the easiest part of the whole process.

The issue isn't "adding the address to the server". The issue is obtaining said address to be able to add it to the server in the first place. This requires both you and your ISP to set up and manage/maintain an entirely independent parallel network with an entirely separate configuration. It's an administrative hurdle, not merely a technical one. I can't explain it better than this user did, so just read his comment [2].

In any case, it's fine if you disagree that this is actually a significant hurdle; I'm not trying to argue that point. My goal here was to portray what djb is saying accurately, not to agree or disagree with it. So if you disagree with it, that's mission accomplished (for me anyway).

[1] https://news.ycombinator.com/item?id=37553377

[2] https://news.ycombinator.com/item?id=37555424

How are R and S negotiating when R cannot even name S on the network? Its stack only allows for 32-bit addresses and S can't have a 32-bit address.

That post was written 20 years ago. I would hope that the migration would be more than "much further along", I'd have hoped it had been completed, like a decade ago.

> is based on the same fundamental misunderstanding that one somehow can extend IPv4 in a way somehow, but remain compatible with IPv4-only clients

I'm not a network engineer, but I've seen loads of commentary from knowledgeable sources that it would have been quite possible to have extended the ipv4 address space without requiring 2 completely separate network stacks.

I think the simple fact that ipv6 includes so many other parts beyond just extending the address space shows what a foolish endeavor it was in the first place. I'm not saying the other bits aren't good ideas, but the only immovable factor that has people wringing their hands about ipv4 is the address limitation. If they had just focused on that, we probably wouldn't be in a situation where we're still running 2 network stacks virtually everywhere, and will be for the foreseeable future. The famous XKCD "Standards" meme says it best: https://xkcd.com/927/

It may sound like a great plan as long as one doesn't look too closely at the details. IPv4 has fixed 32-bit addresses and one cannot cram more than 32-bit of information into a fixed 32-bit field. But one would need to do that for it to be forward compatible, since how would a IPv4-only client open communications with a expanded address space server?

One idea is to only upgrade the client and server and tunnel the expanded address space packets over IPv4. IPv6 has that - that's how it was bootstrapped before native IPv6 connectivity was a thing.

I don't know that I believe this claim at all, but it is at least coherent and possible (unlike claims that N-bit addresses could have been added to IPv4 in a backwards compatible manner). Perhaps SLAAC, the focus on routable end user devices etc were indeed major distractions that pulled focus away from a move to a new larger address space - which is the only thing people actually wanted from IPv6.

I'm not sure this is true. There's a lot of warts in the way IPv4 was put together (ARP is a tire-fire of badness for example), and the opportunity was taken to implement those in a better way. Lots of network engineers are very happy about that.

I think what annoys people is everything else that changed with it, if DHCP (I know), subnets, NAT if you wanted it, etc. was all just the same, if the model was the same the IPs were just longer now, that they wouldn't really complain.

I'm not even sure it would be necessary to put it in unaddressable v4 block, since it would be too long and a different version anyway. Obviously people have thought about this a lot more than me so know a lot more about it, I'm not naïve about that.

https://www.google.com/intl/en/ipv6/statistics.html

Yes, the IPv6 migration has taken much longer than anyone expected. But this argument would have made more sense in 2015 when we were looking at 5% IPv6 deployment and very erratic growth. But it's not, we've been looking at 10% of the market gaining IPv6 support for the last 3 years and are now at 45%. Now granted, this is likely to be largely "new" devices, e.g. in mobile networks and in countries like India where these were hidden behind CGNAT before. But these are exactly the type of devices that an IPv4 extension header couldn't have reached either.

It's a dumb post, to the point I think it must be a deliberate troll. The parts that are possible don't solve any relevant problems ("my new protocol would allow computers that already have public IPv4 addresses to talk to each other" is not a point in favour of your new protocol), and the parts that solve relevant problems aren't possible.

Lol, I'd like to send this to DJ Bernstein, let him know that random Internet commenter thinks that one of his most well-known essays "must be a deliberate troll." Glad HN doesn't support emojis, not enough facepalms it the world for this one.

For example his Qmail was conceptually a very well designed email server but the email standards kept evolving and I'm fairly sure at some point he just said "Qmail is feature complete and secure, no more new features and patches". Like, what? It's networked software, that's not how any of this works.

Who's rejecting the good enough in favor of the perfect, now? This thread is full of "IPv6 is not perfect, so we must reject it".

The idea of 32 becoming scarce was laughable.

Also the complaint about ipv6 isn't a technical one, it's a usability one. Extending it to 48 bits would have been easy enough for people - like international calling.

Those 16 bits could be in hex, as a convention, so something like "(4EA7) 8.8.4.2".

However, I've constantly heard that the 128 bit hexadecimal with colons just looks too complicated and inconvenient.

You might be brilliant and find it easy but to a lot of people ipv6 addresses look like cryptographic hashes

Also having 64-bit for the network address (and 64-bit for the device) does have certain benefits that make it easier to use than shorter addresses in practice for a single entity, since one can hierarchically model the network and do things like <my_network>:<site-id>:<vlan>. So even in absence of DNS one doesn't quite have to remember 128-bit of information for every device.

the pyramids in egypt took over a lifetime to build; a marvel of engineering, as theyve lasted thousands of years and noones had to build replacement pyramids. the problem, though, is noone in todays culture needs pyramids.

A typical ISP will get allocated a much larger allocation like a /20, which allows them to allocate a /56 for each of their customers while still having a few bits to play with. But all starting with the same <isp_network> prefix.

With IPv4 you will have many separate fragmented networks that have no numbers in common. And this will only get worse over time.

However, SLAAC demands that each device is given a 64-bit prefix that it then chooses many random 64-bit host addresses from, without any other rhyme or reason. So, if you want to know the IP of a host you want to connect to, you have to remember at least a 64-bit number that changes every day by design. Add to that some extra bits for the particular part of the network you are in.

So your IPv6 is more like <isp-assigned-prefix, 32-56 bits>:<internal-net-prefix, 8-32 bits>:<random-host-address, 64 bits>. Human friendly this is not.

A machine using IPv6 privacy extensions would have two addresses; one that changes, and one typically based on the MAC address that remains constant.

If you are in the local network with that machine or otherwise are supposed to be in-the-know, you'd know it's fixed address and connect to that.

The most recent anonymous editor to the IPv6 address article on Wikipedia has address "2602:FBF6:0:0:30C6:7069:6DF0:FD24". An IPv4-like notation of that would be "9730.64502.0.0.12486.28777.28144.64804".

There are some technical advantages to doing things that way of course, but they are arguably rather outweighed by the administrative disadvantages. The protocol could have been designed so that typical layer 3 addresses were not much longer, nor harder to type or remember than IPv4 addresses are.

MAP-T shoves the source and destination IPv4 addresses and ports into IPv6 address. This makes IPv4-IPv6-IPv4 NAT possible. Which means it is possible to run IPv6-only network with IPv4 at on the customer network and edges.

This is probably because the idealized world of "only network engineers" is leaky. Programmers, sysadmins, people trying to get their network printer to work, non-specialists have to interface with network addresses constantly.

Saying they shouldn't is not a description of reality. Not everyone who needs to set up or diagnose a network do so as a career path.

Almost all hardware and software has supported ipv6 for many many years. The humans using it are the ones that shut it off or disable it. Unless you address the human behavior of why that is, this problem will not be addressed.

I claim there needs to be a friendlier, casual interface that makes people's lives easier. It can be a crude kneecapped sheen so long as it addresses the needs of the general user. Then they'll use ipv6, not for ideology or virtue reasons about the commons but because it makes their lives easier

I don't really understand the use case for typing up addresses either, copy pasting is going to be more precise, and if one can't read 8 quartet of letters one shouldn't be near networking equipment either.

Heck ibans are about as complex and the general population is coping just fine

It's human and behavior driven and addressing that is a matter of packaging, process, promotion, product, presentation... all those marketing ps.

Also it's increasing at ~5% a year, so in 12 years it'll be at ~104%.

China is a laggard again here. I earlier saw that they were the largest windows xp holdout left. Sure it's only. 0.5% but many places are down to 0.1.

I have an IPv6 address but haven't bothered memorizing it or giving it out because it would just be more hassle.

game.latticeanimal.net. 3600 IN A 1.2.3.4

At the time it provided a real simple desktop tool that you would install, sign in to your account name, and it would auto-update a (very) short TTL DNS A record for you. (Generally in the form of username.dyndns.org, but as I recall donators could also bring their own top level domain.)

We've got mDNS today to fill some of that gap, but I still wonder if it would also still be nice to have a "no click" desktop tool in 2023 that could quickly update very short TTL DNS AAAA records for you on a subdomain of your choice, and sort of lament Dyn's many pivots (and eventual Oracle buy out) because that original idea still has legs even if it didn't survive the 90s. (Though maybe this time as a true non-profit internet service or operating system feature.)

It was extremely common with Teamspeak.

PS: As a developer, I often read logs and go ”oh yeah, that’s just our satellite office IP”. 192.168.1.110 is the network printer, etc. There’s no hope of recognizing IPv6 addresses at a glance the same way.

There's different "rules" from IPv4, but as a developer those mostly don't matter and if your network engineer wants you pattern matching your network's machines, then you can just as easily pattern match your network's machines as with IPv4. (That said, there's privacy reasons your network engineers might not want that, security through obscurity and all that. That can be just as true in IPv4, but fewer companies have enough IPv4 address space to truly obfuscate the network patterns. Life is harder for network engineers in IPv6 not entirely because it "has to be" but because "privacy and security is 'easier' if we use a more complicated approach to IPv6 than we did with IPv4 where we would just sequentially number machines within our allotted space".)

IPv4 was designed for a handful of research institutions. It is not the fault of the designers that it "escaped" the lab into the 'real world'.

On IPv4 or NAT there's just 65535 ports to check. On a /48 with privacy extensions there's 2^80 addresses to go through, which from an external point of view don't remain constant. You can't even ping all of that.

Anyone who can either man-in-the-middle your traffic or is the intended recipient will be able to do fingerprinting based on your TCP/IP traffic. In addition, a lot of your traffic will likely be HTTP(S), in which case the recipient servers will also be able to set cookies, and perform various additional forms of fingerprinting to learn even more about you. The idea that hiding behind a single IP address gives you any protection is delusional.

Okay we are back in 1992 and are wearing a mullet. 'The Internet' is still a relatively small number of mostly university and government sites, and is barely used for anything important, so a flag day seems pretty feasible.

But the biggest problems of all: You can write an IPv4 address on a phone call. You might be even able to remember it. Not the case for IPv6, you need to be an expert in Hex and remember the specs design. I can't do it as a developer, I don't think normal people will be able to do it either.

IPv4 is useful because it's just a number (at least from a person's perspective). It works. Just add a letter to it and then you have x26 the capacity.

Understand very little about the problem space and complain about the best-compromise solution that the people who do know what they're talking about came up with. It's a very comfortable position to be in, I recommend it to everyone.

Things look fine to me, the reality is dual stack, a full ipv6 transition is idyllic and pointless.

I'm certainly not the first ipv6 critic, and you may notice the nuance that I didn't advocate for not using it, I just don't advocate dropping ipv4. Furthermore it doesn't matter if I advocate it or not, like a train ipv4 keeps going, it's only ipv6 that is advocated.

IPv10. The next IP version number that is unassigned, that is conveniently 4+6.

Basically something that is not breaking compatibility with IPv4 and doesn’t require those dual network stacks nonsense.

Then it's not IPv4 and is not compatible with IPv4.

> perhaps we could look at the 240.0.0.0/4 reserved for future use block

What's the current rate of v4 address space consumption? How long will this block last?

> and add more address bytes in the payload or something.

This is, by definition, not backward compatible.

See my suggestion as some kind of NAT-PT at scale. With a better marketing name and user experience.

The problem is indeed hard because no one manage to find a solution at scale since 3 decades.

This is a fundamental and unresolvable problem with "making it backwards compatible"

Of course, we could extend the address space by further breaking the layering of routes, and baking in support for higher layer protocols into routers. We can certainly stuff more address information in HTTP headers, so the web could be extended to essentially arbitrary size by simply requiring routers to look not just at source and destination IPs and source/dest TCP/UDP port numbers, but also client and server HTTP headers. SIP looks a lot like HTTP, so the same solution could work there. TLS already has support for additional headers, so we could also do extra NAT at that layer.

Hell, AWS could then use a single IPv4, and just rely on HTTP/SIP headers or TLS extension headers to know the actual destination! Of course, if you want to run another L7 protocol, tough luck - tunneling it is for you.

If I had to guess the futur, the industry will most likely go towards something like few expensive IPv4 owned by major cloud and internet providers and crazy recursive NAT setups everywhere. Because that works without breaking stuff.

>if you are making more than 4B addresses routable then any existing IPv4 device will not be able to route some addresses, so you will have caused a split in the internet

This has basically already happened. We've massively extended IPv4 by stuffing extra address bits into the router's port number, and it means that any two devices behind NATs can't directly route to each other.

Not being able to route directly doesn’t seem to be a major issue to me. It for sure require more computing power in routers but also adds some safety and privacy by design.

Look at the bigger world around you.

I am, right now, involved in a major cloud migration. Having overlapping, constrained RFC1918 space and also having to NAT everything is presenting an enormous set of constraints and risks. It adds literally zero benefit.

Life would be infinitely easier, and we could provide so many more capabilities if everything could just have a routable IP address. Unfortunately, I'm not in charge of our addressing policy.

NAT is an awful, short-sighted hack that causes many more problems than it solves.

The problem is hard because despite everyone's wishes, it's got nothing to do with technology. All migrations are about economics and incentives, IPv6's qualities as a design (it's a long, long way from perfect, but I'd argue that it's good enough) are irrelevant.