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.

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.

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.

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

That would have saved a lot of pain.

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.

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.

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!

Then, if you own an IPv4 address, you effectively own an IPv6 subset. Then we reserve a whole bunch of IPv4 addresses for IPv6-only allocations.

I obviously haven't thought it through in detail, but wouldn't something like that effectively transparently work via IPv4 core infrastructure provided the networks at either end support IPv6 if they're using it? We'd still need NAT for IPv6-only endpoints that need to talk to IPv4-only endpoints. It also wouldn't be anywhere near as clean as IPv6 and would lack a few of the nice features, but... an awesome protocol I can't actually use isn't much use to me.

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

The big issue is that the router vendors hated it, the OS vendors hated it, the programming language people hated it, and the software writers hated it. How do I know? NOBODY WANTS TO ADOPT IT except by force, even now.

Worryingly, pro-IPV6 people are consistently arrogant and dismissive. Essentially their argument always boiled down to "ha, you'll be forced to use it eventually and then I'll be RIGHT!!!" which is why IPV6 people hate NATs with a vehement irrational passion, because it floated IPV4 for, what, two decades at least?

I'm guessing it is because IPV6 was a tossed-over-the-wall protocol that didn't get reference implementations from the biggest router vendors first. Here's a very very very very very very troubling link:

https://www.cisco.com/c/dam/en_us/about/ciscoitatwork/networ...

That is Cisco bragging about it's IPV6 website on a pdf from 2011! 2011! Fifteen years after the birth of the protocol. If Cisco did not have an IPv6 site up until FIFTEEN YEARS after protocol definition ... oh god.

Comcast routers weren't IPV6 functional back in 2015, at least they weren't on my cable modem. If an ISP that makes bank on renting and turning over its consumer routing hardware can't roadmap ipv6 adoption within 22 years... ugh.

And my biggest complaint about ipv6 is that they didn't increase the number of ports. Really. We have to keep shoehorning apps into 64k ports rather than a sensible 4 billion, but maybe there's some OS mapping concern with that, doesn't matter, the ship sailed.

https://en.wikipedia.org/wiki/Internet_Protocol_version_4

Somewhere in IPV4 is an options header (up to 40 bytes). Why that didn't provide the necessary space for some degree of backwards compatibility somehow is beyond me.

What should have happened is that the big router vendors got together and agreed on a standard protocol. Then the major OS vendors and language standards bodies got together and made reference implementations for basic networking.

Once that was working / adopted by next gen hardware and software releases, then things might have gotten rolling.

I mean, how much work was that relative to the mind boggling amount of work done to implement NAT and firewall traversal/busting code in, say, Skype? Ever seen those whitepapers? Wow are they doozies. Holy crap are people willing to write code.

This is all screaming at the darkness.

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.

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

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

IPv6 had one job: make more addresses available while keeping the addresses easy to manipulate, and it failed at that.

"Well-known" NAT64 prefix: 64:ff9b::

Everything is so confusing in numbering and addressing: http://www.gestioip.net/cgi-bin/subnet_calculator.cgi?ip=006...

=

If problem was allocation, we could have added one number in front: 123.114.123.130.200

Now for backward compatibility:

  If your device, operating system and application are compatible with IPv6, congratulations, you receive 123.114.123.130.200 and talk natively in IPv6.

  Otherwise, if you are on an IPv4 device, you receive only a portion of the IP address but from a fake IP starting with 250.x.x.x

  inetnum:      250.0.0.0 - 250.255.255.255

  organisation: Future use

  status:       RESERVED

For example, your local home/ISP router can send a truncated version of the IP address: 250.123.130.200 and then it's the responsibility of this translation router to remember the routes at least for some time (and there is always possibility to hardcode routes if needed).

=

A bit like Stateful NAT64 or "SIIT-DC: Stateless IP/ICMP Translation for IPv6 Data Center Environments" or "464XLAT: Combination of Stateful and Stateless Translation"

But now, with all these millions of standards it's such a productivity loss for any tech working in networking.

Similarly when switching CPUs over from 32 bits to 64 bits, the idea was to change the size of words stored in memory, not change the size of words and change the alphabet in use.

https://blog.cloudflare.com/announcing-1111/

RIPE had a policy to extremely rate limit allocations from their last /8, which is how they were able to continue allocating for an extra 7 years. The other RIRs had no such policy.

https://www.ferc.gov/internet-protocol-version-6-ipv6-policy

https://aws.amazon.com/vpc/ipv6/

The price for IP for connections is already builtin to the price. Also, ISPs just use CGNAT to share IPs with multiple customers when they are short, It makes sense to charge more for static IP.

How long ago did you do try IPv6? These days it should just work. If your router doesn’t work, get a better router since it is broken.

[0]: https://ip-ranges.amazonaws.com/ip-ranges.json

BGP is a very insecure protocol. Most of its "security" are enforced by money and contract.

Is this how BGP hijacking is done?

I wonder if sanctions may ever apply to the internet itself and we may see a break up of the internet into regional internet's.

And if we want to ensure global connectivity these associations would need to be completely independent and voluntary standard and such fees would be paid to an international standards body not beholden to any particular nation's whims?

What if nations started adding intercontinental NAT gateways acting as the entry and exit points between their national boundaries and the rest of the world.

This is by design. If we let arbitrary routings of /64 blocks pollute the global routing table shit is going to go sideways as the rest of the net scales up and up. We made that mistake with IPv4 and the only reason our routers haven't gone thermonuclear keeping up with the announced routes is we literally ran out of address space.

We're not going to get the IPv6 equivalent of IPv4 /24s announced ever again. While minimum prefix lengths aren't hard enforced (yet), unless you have the means/reason to be multihomed using /48s you're pretty much going to be under the hierarchical routing of your transport or last mile provider.

Mandating something like a static /56 (physical location locked) to be available at no extra cost if the customer asks for it, would work fine, though. I'd even accept requiring this only for contracts that allow more than one customer device to access the Internet simultaneously. Yes, a phone plan with two SIMs on one contract would already trigger this.

Having a ton of people/businesses with their own announced and unaggregatable /48s would add a lot of entries to routing tables.

If you're asking for a minimum sized range, you don't have to justify more than one ip. It's not super hard to find somewhere where you can be multihomed either, although it's unlikely to be at your home. (Maybe ask isn't exactly the right verb, assuming ARIN/RIPE are out of addresses, you're asking for them to process a transfer that you paid/will pay the current responsible party for)

Also, there is no organization that can require anything of an ISP’s addressing plan. The IETF and the RIRs are associations, not governing bodies.

Just buy service which does what you actually want - rather than insisting it should be mandatory which means everybody has to pay for it. I have static allocations (both IPv6 and, very small, IPv4) because I care. Most people don't care.

It doesn’t account for inflation?

Most content distribution networks (CDNs) support IPv6 even if the back-end is IPv4. For most web sites, a CDN is a good idea in general, so just use one.

For developers: don't hard-code IPv4 as an assumption. E.g.: don't validate network addresses with an IPv4-only regex, and don't store addresses into a 32-bit unsigned integer. Most SDKs and APIs have supported IPv4/IPv6 dual-mode addresses for like... two decades by default. Just don't... undo... all that effort!

Generally: Use DNS instead of IP addresses. Do it properly by respecting TTLs and using multiple upstream DNS servers in a fast failover configuration. This is not the default in many systems, especially Linux distros used in servers. Many admins "prefer" raw IP addresses because they think "DNS is unreliable". It isn't, it's just the default config that's poor.

- Compatibility bridges for v6-only hosts to connect to v4 servers

- The IP address market encouraging old v4 allocation owners to sell off their space (at the expense of a bloated routing table)

In 2009, IANA and the RIRs created a process for buying and selling IP addresses. Which is something they never wanted to allow, but their hand was forced by the abysmal levels of v6 adoption back then. Two years later IANA would allocate the last /8s, and the RIRs that got those allocations would exhaust them in the years following[1]. The only virgin v4 address space remaining is reserved specifically for ISPs setting up v4 compatibility for native v6 networks.

You did not notice this because the v6 transition has already happened, and it was boring. In 2023, Google reports 40-45% v6 adoption[0]. This is largely due to LTE making v6 a mandatory feature. Had we kept mobile traffic on v4, networks would've adopted shedloads of CGNAT, and even then that hits a wall when you start running out of ephemeral ports to disguise addressing information inside of. This would have resulted in significantly worse behavior for smartphone users, especially in heavily populated countries like India (which have far higher v6 utilization).

[0] https://www.google.com/intl/en/ipv6/statistics.html#tab=ipv6...

[1] https://en.wikipedia.org/wiki/IPv4_address_exhaustion

The article you're responding to is a dramatic demonstration that it has happened: Amazon's IPs would not be worth $4.5B if we hadn't run out. It requires us all to ration a resource (namely numbers) that should be near-infinite and essentially free.

iphones are v6 only as are indian consumer connections.

Sigh

You can also acquire and use a /24 out of a class A or B block, thanks to this newfangled thing called CIDR. ;)

Thats what I have in my RIPE Account.

Essentially, how are they better than IPv6 addresses?

Your phone perhaps, but the rest of these devices never need a public IP address.

Before I switched ISPs a few weeks ago to one without IPv6, I was with an ISP with IPv6 (dual-stack) for about five years and had zero problems.

In fact it worked 'too well' initially: when I was still IPv4-only I had put a bunch of Facebook domains in my iMac's /etc/hosts file pointing to 127.0.0.1 so that all those little icons would stop loading. At some point I noticed they were back.

After some head scratching over a day or so I realized that Facebook was IPv6-enabled, and so the icons were loading because AAAA records were working. Adding ::1 for Facebook in hosts fixed things.

kek - i too am waiting

Tell that to 45% of the Internet.

Also, half of the bingo items there are intentionally humorous, and if you are taking those items literally (I wouldn't be able to tell, you never listed them out) - congratulations, you are part of the bingo :)

I've tried running web servers as pure IPv6 plays, which I would happily, happily prefer. It is just not possible. Even things I'm convinced will work, like cellphones, which are mostly IPv6 these days, won't connect.

You must be an RIR member to hold IPs and there are membership dues that you must pay each year to maintain your allocation. Once you are a member of an RIR you just have to make a request and at least with ARIN that request and fulfillment is free.