Very much this. I'm so given up on hopes for IPv6, that I feel it is almost the time to create IPv8, designing it to be an extension to IPv4, and ditching IPv6 completely,
We need an expanded address space. The ipv6 rollout is proving to be one of the least effective ways to get it in practical terms.
IPv4 prices were in the mid-US$30/IP in early 2021 and they're now around mid-$50:
* https://auctions.ipv4.global
I think The Market™ will decide that trying to run IPv4 in a lot of places will be too expensive, and that end-points will get assigned IPv6 with various translation mechanisms being run for the 'legacy' Internet.
Heck, even AWS if finally allowing IPv6-only infrastructure:
* https://aws.amazon.com/blogs/networking-and-content-delivery...
100% adaption will never come. Just look how many companies still use COBOL software that was developed in the 70s.
The question rather is: when will IPv4 become insignificant enough that your company won't have to care about it anymore?
I see a linear trend that, once adoption started in earnest around 2015 has seen about 30% of users being converted to iPv6. At some point, it’ll be more common to run into issues with v4, which will drive more adoption. The toolchain now needs. To support v6 and defaults using it will become more common. The conversion will limit the scarcity of v4 to some extend, but continued growth of internet access and connected devices adds pressure on the other side.
The problem is connectivity the other way around, but it's simply impossible to cram more address space into IPv4. You'd need a protocol on top of IPv4 and special routing software or hardware on either end of the connection to hack backwards compatibility into the old address ranges.
For many, having a *private* IPv4 space is not just a feature, but a requirement.
The idea of a completely globally flat address space makes perfect technical sense.
However, policy sense may differ as Your Mileage Varies.
A small nitpick: the lower part of that range is reserved for future expansion, so the private range is actually fd00::/8. And you should pick a random /48 within that to be your private 10.x.x.x-like range, not use the whole /8. (See https://en.wikipedia.org/wiki/Unique_local_address#Definitio... for more details.)
As long as there is a provision to soak it in CIDR.
I had looked at the dual-stack portion of AWS some years ago and did not see how this worked.
Doubtless, my oversight.
There is; the idea is to fill up random bits to /48, leaving you with 16 bits of subnetting space until you hit /64. If you're not concerned about aggregating networks, a common pattern on larger networks is to put the VLAN ID there in "false hex", i.e. VLAN 1357 = fd……:1357::/64.
If you need more space you can either generate more random /48 prefixes, or widen the prefix length on your existing /48. The latter is technically against the spirit of ULAs, but… only the pedants will care.
Okay, you can indeed do that... but how do you get an address is the another question. You might answer "Just go to the RIR", sure, but ASNs aren't given willy-nilly, they need to prove that they'll need different routing needs for external peering, and some RIRs do insist on this. The most loose RIR in terns of regulations is RIPE, but what about other companies in other parts of the world?
You also missed the point of this sub-thread since the question was about private space. IPv6 fd00::/8 is IPv4 10.0/8. The only difference is an added bit of semantics to make merging networks easier.
I don't think I've ever seen anyone suggesting using a /48 in fd00:: and NAT66 at the edge, and NAT64 is discouraged rather than maintaining a dual stack solution (and if you need to maintain a working ipv4 solution, why even bother with ipv6)
You get an PI address block and ask your ISP to advertise it on your behalf in their public ASN, e.g.:
> If multi-homing to more than one provider, the customer must obtain an Autonomous System (AS) number, available at http://www.arin.net. If multi-homing only to us, we will provide a private AS number.
* https://support.allstream.com/knowledge-base/bgp-request-inf...
And? Get nothing in some regions because all of their ISPs aren't willing to provide this service even with money?
I know provider-independent addresses, but don't pretend it'll solve the problem of IPv6. The fact that you need to do some service wrangling rather than "take this IP for private use, just don't ask us when IP conflicts happen" (and ULA implementation is inconsistent even in enterprise routers) means headaches abound that didn't exist for IPv4.
And new code has to be written to take advantage of that new protocol. And that new code has to be deployed on every single network element. Don't forget a new DNS record type so that old code is not confused by a new address format. And then everyone has to be convinced to deploy that new code and start assigning those new addresses.
Just like had/has to be done IPv6.
IPv8 will/would have the exact same issues with deployment as IPv6.
There is absolutely no chance of a replacement at this point
If I connect to a Wi-Fi in a Starbucks with IPv6 by default or my recently bought mobile line comes with IPv6, then I would say it is a win.
It is a huge improvement but the story of the failure is a good topic for academic research for future protocols.
I’m surprised it doesn’t. In Europe most providers only give you IPv6 and CGNAT IPv4. Even my landline does that.
it quite likely does today, IPv6 is common with mobile carriers.
While that is a ipv6 success, that is greenfield. And the telecoms are basically running a huge ipv6 nat when they need ipv4 routing.
Which is heretical to ipv6.
The issue of migration of existing ipv4 is still sucky.
Meanwhile normal desktop OS and infrastructure and consumer routers are (20 years after this article) a disaster.
(Of course there's a whole bunch of other anti-spam heuristics, but missing PTR is the most common in my limited personal experience.)
Then there is the issue of equivalence of RFC 1918 for IPv6, another whole can of worms...
https://serverfault.com/questions/216602/what-is-the-ipv6-eq...
There are ways to work around that. All of them (and some more) were tried and/or are in use with IPv6: https://en.wikipedia.org/wiki/IPv6_transition_mechanisms
You'd be stuck with an abysmal MTU for "IPv5" though, because you need that wrapper and the world doesn't seem to want an MTU larger than 1500 outside internal networks.
That's what 6to4 does. When enabled, it encapsulates IPv6 traffic in IPv4 packets and sends them towards a well-known anycast IPv4 address, and the return IPv6 traffic is sent towards a well-known anycast network, where a router encapsulates it in IPv4 packets and sends them towards the IPv4 address contained within the IPv6 address.
I find it amusing that all these "IPv5" proposals either cannot work, or do the same as something which already exists for IPv6 (and in this case, it works; I've used 6to4 for a while).
As complex as some may find IPv6, I find it a lot simpler and more independent of routing services than many proposals for alternatives. The weirdest one I've seen involves concatenation two IP headers, giving everyone one network IP for ISPs and such and one client IP for the individual hosts, but that's just replicating IPv6 with extra steps and an even smaller MTU.
As much as technically I think it was a brilliant idea (a whole /48 assigned to each existing IPv4 address owner), it failed because of the tragedy of commons.
6to4 gateways are still a thing, you can traceroute 192.88.99.1 to find the nearest gateway if you have IPv4 connectivity. I've got one seven hops from my device, but I've also got a static IPv4 address so I have little need for a gateway.
Call the extension "NAT tagging" and add a 24-bit NAT "tag" which reflects the bottom 24 bits of the 10.x space. Every machine with a private ipv4 appends this as its source tag, and it becomes the responsibility of NAT tagging aware NATs to notice the NAT tag on inbound packets and route them appropriately. Client machines which are themselves aware make sure to preserve the source tag when sending packets back to the NAT'ed machine. The tag of every existing public ipv4 is 0.0.0. The only tricky part at this point is encoding all these extra bits in a way which is ignored by existing ipv4 stacks. Although, figure out how to check for it in a handshake of some form (easier with stateful protocols like TCP) and it could hide outside of the IP header itself.
Non compliant endpoints continue to suffer the existing port forwarding/etc issues that exist with current NAT's while updated machines can directly address each other. The various hacks (already in use) to the HTTP hostname fields also solve the problem for tag unaware machines addressing public https servers.
This gives every existing IPv4 address 24 bits of additionally public routable addressing without having to upgrade a single core router/etc.