"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.
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.
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.
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'.
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.
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
Technically, in the IP packets, we would have added "IPv6 address", and called the current field "Legacy/backward-compatibility IPv4 address".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.
I actually feel antagonist towards the designers for it.
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
interesting idea
Make of that what you will.
Send the bill to end users is not what should be done.
All this ipv6 endeavour already cost me a lot of time learning and troubleshooting software, and sometimes realizing that some modems doesn't have a good ipv6 stack and the best solution is to turn it off.
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.
Honestly, I've never had such a strong incentive.
How does one buy a block of IPv4 as an individual? (If that's allowed)
After you purchase it, how does it come into your possession?
How do you utilize them?
BGP is a very insecure protocol. Most of its "security" are enforced by money and contract.
Is this how BGP hijacking is done?
You need to provide justification, and frankly it's not that big of a challenge to get a /22 which is what I got. As long as you can show how you would like to use them and over what time frame, they will allow you to go through with the acquisition. An ASN is not required to get any IP block. You can always associate your IPs with any ASN that you want so long as that ASN owner is cooperating with you. I went ahead and grabbed an ASN for ease but some ISPs will allow you to use their ASN.
You also do not have to purchase an IPv4 block from someone. You can go through the normal IPv4 request process, however the waitlist [1] is now over a year long for IPv4. However IPv6 are given out very quickly. IPs you acquire this way are "free" to acquire with your ARIN membership. Your membership dues are determined by the assets you hold, there is a fee schedule [2] and you need to pay it annually to maintain your membership and ASN/IP assignments.
I encourage anyone interested in understanding this process to go through it, it didn't take a ton of time nor did it cost a lot in the grand scheme of things. Being an ARIN member also entitles you to be a part of how IPs are governed in the region you acquired them in. They will occasionally send out surveys and you can vote on issues.
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.
2. You are assigned a BGP Autonomous System Number (ASN) as part of the process. The IPs are assigned to your ASN.
3. You sign a peering contract with ISPs and peer with them using BGP on your router. You use your ASN to announce your block to have traffic routed to/from your router.
One of the tragedies of IPv6, IMO, is not having a better/streamlined process for end users to get allocations without all the red tape. There's tons of space, let's pretend it's the 90s and give away IP blocks to whoever asks. Either require ISPs to give static allocations or make it easier for getting a personal block. No, prefix delegation is not good enough.
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.
Good luck, update us if you do it!
EDIT: I guess this is the cost to _rent_ an IP per month and not the cost of _owning_ an IPv4 address.
At some point. At SOME point, IPv6 will work in enough situations that we can ignore the small minority of situations where it doesn't. If even 90% of the visitors to my web sites could connect on IPv6 I would change tomorrow, but it just isn't that high yet.
If you run only online service, enable ipv6 on it.
Basically, help move the needle on the chicken and egg issue of adoption. Move more traffic to v6 as much as you have control over.
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...
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
But in some sense it’s even more wonderful that your phone can (probably) render 1080p60 video without skipping a beat. Not to mention that it is transmitted over thin air, originating from someone (probably) thousands of miles away.
And even more wonderful is that no one thinks of it as anything special, at all.
I also don't think there are many places willing to announce your ultra specific route because it's not great for routing tables.
You can also acquire and use a /24 out of a class A or B block, thanks to this newfangled thing called CIDR. ;)
RIRs do allow you to transfer your IP blocks to other organizations but you can only do so if the receiving organization proves to the RIR they have a good reason to hold those blocks of IPs. This valuation is based on what a typical IPv4 owner receives in exchange for that transfer of IPv4 addresses.
Just like any assets which you hold a lot of, if AWS dumped their IP addresses on the transfer market, the price of IPv4s would likely fall significantly so I doubt they could actually get that price for all their IPv4s.
[1] https://en.wikipedia.org/wiki/Regional_Internet_registry
Said another way, AWS owns approximately 3% of all IPv4 addresses.
Essentially, how are they better than IPv6 addresses?
Having something that's addressable on the internet is trivial when you have a public IPv4 address.
Don't do that.
Fast forward a couple of decades and everyone needs 10 IPs each. You have your phone, your laptop, your work computer, your TV, your door lock, your door bell camera, your thermostat, etc. And every web site in the world traditionally needed its own IP. And so the world pretty much ran out of those 4Bn addresses.
The "Powers That Be" developed IPv6 which solves this, but not everything works properly yet when connecting with IPv6, so if you want to make sure your software/hardware is guaranteed to connect to everything then you need one of those precious IPv4 addresses.
Now, in the early days of the Internet there were so many addresses that they were handed out like Halloween candy. And many people had so many they didn't even use a fraction of them. So now you can make good money selling your old addresses as they are prime real estate.
Your phone perhaps, but the rest of these devices never need a public IP address.
And then random stuff just doesn't work. Various websites hang, various widgets just don't load, etc. Then I turn it off and everything gets better again.
I'be been too lazy to diagnose why exactly it doesn't work, I just figure it's easier to run with it off. At some point a website I really want to access will require IPv6.
Hopefully by then whatever is broken will be fixed.
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 :)
Based on data from the IPv4 brokerage ipv4.global, the cost of IPv4 addresses has seen a notable increase. In 2014, the price ranged from $6 to $24 per IP, depending on the size of the subnet. By 2021, this range had jumped to between $23 and $60 per IP. The fluctuation between the lowest and highest sales prices for each IPv4 address remained relatively stable until 2021, when we began to see more significant spikes.
The peak prices for IPv4 addresses in 2021 were observed in September and October. During these months, IP addresses allocated by RIPE NCC and ARIN fetched as much as $60 each. Specifically, a /24 block from RIPE NCC sold for $15,360, while ARIN's /22 and /23 blocks went for $61,440 and $30,720, respectively.
Fast forward to October 2022, and the highest sale of the year was recorded: IP addresses allocated by ARIN sold for $60.70 each, or $15,540 for a complete /24 block. Despite these peaks, the IPv4 market appears to have reached a more stable pricing structure, especially when compared to the more volatile price shifts seen in 2021.
$30-35 is the low end per IPv4 address over the last year.
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.