"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.
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
So… NAT.
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.
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.
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.
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.
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.
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?
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.
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.
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.
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.
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.
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.
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.
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.
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
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.
(not worried about them, just curious)
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
2/3 of their internal services don’t. You can do ipv6 only vpc but not if you wanted to use rds or ecr or …
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.
They also did offer IPv6 availability for a short while as a test, but that was quickly shut down, so there is probably a technical issues they can't figure out or they would've kept the trial system running for longer.
Either way, Github isn't communicating, so it's hard to tell if this is indifference or incompetence. As an end user, the distinction doesn't really matter.
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.
Take a look at the state of RPKI. ROA validation is common these days, and ASPA validation will be common soon. You still need to manually validate that your peer truly represents the AS that they claim to, but if that's been done, ROA+ASPA validation prevents unauthorized announcements.
Absent RPKI, people have been filtering based on IRR for ages, which will not necessarily prevent unauthorized announcements, but will require an attacker to leave a paper trail when making one.
Is this how BGP hijacking is done?
But good ISPs filter the prefixes their customers can announce to only those they actually own.
Then you have shitty providers that dont do it, and thats how you get BGP hijacking.
And you cant do this just from any connection, fyi.
You will need a datacenter, cloud host or residential ISP that actually allows you to peer with them and announce routes. This isnt a standard thing you get just by being a customer.
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.
I have no idea how they manage IP allocation internally there though.
IMO we'll see this happen in our lifetimes.
It's possible that your block is a part of a legacy allocation, they are governed differently.
https://www.arin.net/resources/fees/fee_schedule/#legacy-reg...
So you won't be subject to the new fee structure.
If you want to route then you will need an ASN and an ISP willing to announce them. So long as you are up on your LSRA dues I don't see how you won't be able to utilize them.
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.
There can only be ~4.3 billion IPv4 addresses, which means that mathematically IP addresses are severely limited - you can't assign even one single globally routable IPv4 address per human. That's why we have NAT and its evolution CGNAT in the first place.
iphones are v6 only as are indian consumer connections.
Are you sure about this? Do you have a link with details?
If I disconnect from WiFi and use the SIM card currently in my iPhone, and I go to one of the websites that tell me my public IPv4 and IPv6 address it shows that the mobile internet connection I have with this SIM card is IPv4 only.
iPhone 14 Pro
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?
https://www.google.com/intl/en/ipv6/statistics.html#tab=per-...
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.
https://en.wikipedia.org/wiki/Thread_(network_protocol)
Some IoT devices are now IPv6-required.
Your phone perhaps, but the rest of these devices never need a public IP address.
We can debate whether that's a good thing or a bad thing, but that is the way IPv6 is supposed to work.
Pretty much every cell network gives the phone an IP on the subnet, and then uses NAT, or CG-NAT[1] to share the same public IPs for multiple mobile devices.
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.
Still unsure of the benefit of dual stack, but there are numerous costs.
edit: I've been running dual-stack with Windows, macOS, iOS & Linux for at least a decade now - I think it's closer to 20 years than 10! I've never seen it be like the parent post for my personal use, but I have seen it broken like that in places I've worked with incorrectly configured routers/firewalls.
edit 2: this isn't a good idea for v4 either, but it's less broken than v6!
I’m sure I do. But that’s sort of the point. I only use standard commercial hardware with the default config.
If that doesn’t work out of the box, what chance does someone who doesn't have my decades of networking experience have in fixing it?
Granted I’m probably more sensitive than most because I know what network issues look like. Most people probably just think some things are slow sometimes.
My ultimate point though is that this is probably a barrier to adoption.
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.