This is why people have been trying to promote IPv6 for the last couple decades. It is silly that new internet companies should have to pay money to those who got here first.
Still waiting for AAAA records on news.ycombinator.com. IPv6-only SIP trunking would also be nice, since an IPv4 address is the main cost of hosting a small PBX.
Yeah, I truly do not understand what's causing Hacker News or Reddit to drag their feet. My guess is they've simply done the calculus and decided the number of impacted users doesn't justify the cost, and meanwhile, they already have their v4 allocation so there's no financial pressure either.
I'm starting to think the RIR's should just start charging increasing YoY maintenance fees on v4 address space for companies that haven't rolled out v6. Those companies, who already have an allocation, are really benefiting from a negative externality. Maybe it's time they start paying for the privilege.
Its almost an incentive to not do IPv6, then. ISPs have v4 working fine, its only the new guys that get screwed, so the incumbents can actually make life harder for competition by making sure everybody still need v4 addresses. Or, they dont want their "investments" to depreciate, kind of like why some NFA collectors oppose re-opening the machinegun registry.
IPv6 should have been designed to be backwards compatible and smoothly transition people over. Why not design it so you can just quietly migrate to ipv6 on the infrastructure side by introducing automatic translation of ipv4 packets into ipv6 and back by padding and removing zeros, and automatically reserving all the resulting ipv6 addresses to their ipv4 equivalent owners.
This situation is the result of poor design and roll-out decisions, not the fault of everyone else.
> IPv6 should have been designed to be backwards compatible
Impossible. You can't communicate between two hosts without both hosts being able to address the other -- and there's no way for an IPv4-only host to pack 128 bits of address into a 32-bit host field.
I don't think it's impossible per se. You could probably get around that limitation via a beefed up version of NAT, along with a couple DNS hacks. Obviously, that's some ugly hacky BS though.
I think better design could have avoided that issue to begin with by facilitating smooth roll over.
Still, I'd start with translating ipv4 addresses into a reserved range of ipv6 addresses. ...and if ipv4-only clients can't initiate new connections to ipv6 addresses outside that range, OH WELL. (There's probably wiggle room to NAT your way through anyway) More importantly, if there's a default in-built way for ipv6-only machines to initiate connections to ipv4-only machines, and the ipv4 machines can return traffic via some type of NAT, there's a lot more incentive to switch to support ipv6 since more machines would be using it.
What you describe there is basically NAT64 [1]. Not a ton of reason to actually deploy NAT64, though, when practically everything's going to be dual-stack anyways and you're not saving any IPv4 addresses versus that dual-stack arrangement with a typical IPv4 NAT. (There are also compatibility issues to consider; not everything can work with IPv6 addresses at the application level, especially early on in the transition.)
IPv4 addresses can be converted to an IPv6 equivalent [0] and that can be used to keep the existing owned v4 blocks intact for protocol translation. What would have been nice is if standards would have forced migration of owned blocks and pressed Tier0 / Tier1 providers to handle "legacy" v4 traffic on ingress into their ASNs. Carriers are the driftpins in the equation here, they have to start the ball rolling and there needs to be an interop transition phase. All the pieces are there, there's just no incentive.
Consider this: The OS reserves 10.0.0.0/8 for this purpose, possibly with a few common exceptions (10.0.0.0/16 maybe) being allowed through unmodified. If an ipv4 server has an incoming connection from an ipv6 address. That ipv6 address is given a corresponding 10.x.x.x address. Likewise, if an ipv4 client does a gethostbyname a 10.x.x.x address is allocated and returned. This simple system already supports 16m concurrent connections.
Sounds like you're describing NAT-PT, originally proposed in RFC 2766 (published in 2000).
It suffers from a lot of practical problems, which are described at length in RFC 4966. For example, without careful special handling it breaks protocols like FTP/SNMP/H.323 that embed IP addresses in data packets; it breaks IPsec; it can't handle fragmentation; and it suffers from scalability issues.
> it breaks protocols like FTP/SNMP/H.323 that embed IP addresses in data packets
Well it doesn't break them exactly. An ipv6 capable application would connect to the embedded ipv6 address and not be natted. But it fails to make a legacy application work, so you are no worse off at least.
I wonder if you could use something like IP in IP (https://en.wikipedia.org/wiki/IP_in_IP), basically just slap another IP header on your packet so your IP becomes two 32 bit IPs, one for your ISP and one for you.
That sounds really painful to work with, and it would still largely lack backwards compatibility -- hosts on both ends would need to be patched to support the "double address".
patching hosts would be easy, but the routers in between would probably not need any changes and that's big since it was one of the holdups of v6 deployment.
That exists for IPv6 in various variants: 6in4, teredo, 6to4, etc. (and the inverse variants of tunneling IPv4 over IPv6 also exist in many different forms).
Many of those can be used even if your own ISP has no support for IPv6 at all.
Many of the require manual configuration (as in the case of tunnel brokers) however, which makes it less likely for non-technical users to use them.
The idea would be to add first class support for it in the OS. Your ISP DHCP could add an addtional option specifying your upstream ISP address as well as your local address for example. Then your hosts interface will get configured with both addresses and automatically add wrap outgoing ip packets in the outer address.
This would also be possible with IPv6 (not with DHCP involvement, but with other mechanisms).
But the issue is that some ISPs (and cloud providers) simply don't care or even actively drag their feet (since it may be in their business interest to do so for now).
As I'm (slowly, begrudgingly) learning about IPv6 I can't help but agree. Astounding that backwards compatibility was abandoned in favor of ... Being able to hand out a /64 or /48 to anyone with a pulse? No residential customer needs that many addresses, yet I can call my ISP today and block that off for eternity. To what end?
IPv6 should just have been a superset and 0..1.xxx.yyy.zzz.ttt should have been the legacy IPv4 space. I really don't get the point of all the bizarre block assignments, hexadecimal fetish, and general "why is this seemingly purposefully such a pain in the ass" feeling I get whenever I look at it.
It is something like one /48 for each second square meter of land on Earth or something in that ballpark. It definitely can be exhausted, but that is only because we more or less use the last 64 bit for grouping hosts, autoconfiguration etc. which doesn't have to be the case everywhere (e.g. container hosts, where giving each container or even a container host a /80 can be more than enough).
Still waiting for AAAA records on news.ycombinator.com. IPv6-only SIP trunking would also be nice, since an IPv4 address is the main cost of hosting a small PBX.