v4-mapped v6 (rfc4038), not 6to4, right? It was only a transition feature and not how v6 was rolled out by default. I don't even have such an address. You enable v6 and it suddenly means you're reachable with the new addresses, typically assigned via slaac. Also idk if v4-mapped was meant to be split beyond /32s.
But like the similar proposals, it fails to avoid a dual-stack scenario.
Note that going from v4 to v6 also doesn't mean changing all your routes and addresses; you just enable it and everything still works. Network components can get updated behind the scenes without user impact. There's no flag day though; ISPs can start using the new address space as soon as they want, rather than being forced to wait until everybody else is ready.
You do have to change everything to actually use v6 rather than having v4 on the side. Re: flag day, I guess you could use the new address space of v4x before everyone is ready, provided the other side supports it.
Having partial deployment of IPv4x is no different than having partial deployment of IPv6: you have islands of it and have to fall back to the 'legacy' IPv4-plain protocol when the new protocol fails to connect:
Getting "free" new-protocol addresses is also nothing new:
> For any 32-bit global IPv4 address that is assigned to a host, a 48-bit 6to4 IPv6 prefix can be constructed for use by that host (and if applicable the network behind it) by appending the IPv4 address to 2002::/16.
> For example, the global IPv4 address 192.0.2.4 has the corresponding 6to4 prefix 2002:c000:0204::/48. This gives a prefix length of 48 bits, which leaves room for a 16-bit subnet field and 64 bit host addresses within the subnets.
Ok, I see what you mean then by 6to4 already supporting what v4x proposed, but that path wasn't taken either. It's a special feature with rare usage rather than the minimum default way of doing v6.
We did take that path. If you zoom in on the start of https://www.google.co.uk/intl/en/ipv6/statistics.html you can see that 6to4+Teredo was more common than native until 2010. (Okay, that's combined with Teredo, but I think probably 6to4 is the majority of it because Windows will use 6to4 without needing a registry change or custom application behavior.)
You see it as a special feature with rare usage because it competed with native and lost. People overwhelmingly preferred deploying v6 natively instead of deploying 6to4. Obviously more people would be using it if it was the only option, but if you're trying to come up with an alternative to the way v6 went then "an approach that v6 took but which nobody wanted to use when native v6 was the alternative" might not be a very promising place to start.
It's not like the v6 spec said, here are two options on equal footing, go figure out which is better. 6to4 was a temp bolt-on. I had to look up what things were actually like in 2010 because I really don't remember getting a 2002:, which brought me to rfc6343 that explained why exactly 6to4 suffered. A big part of it is that even a v6-enabled ISP didn't give you a 2002:, rather you were relying on anycast to reach a relay server. Why would an ISP or user ever want that mess? Either they do v6, or more likely they don't care and focus on v4.
So actually I take it back, 6to4 was pretty different from this ipv4x idea. I misunderstood and thought a v6-enabled ISP would give you a 2002: under 6to4, which you could later subdivide.
Ignoring that, say 6to4 were like v4x... The idea that those 2 years showed that native was preferable, that was among a small minority who even cared about v6 to begin with (0.25% at the time). This was a primary, not a final.
If your goal is just to roll out support for v6 addresses without actually using them, then you don't need to change anything about your network to do that. (Remember going from XP to Vista? That added support for v6 in Windows, but you didn't need to change your network for it.) This is the same as your described rollout of support for v4x.
Once the world is ready and your ISP actually issues you with v6, then you need to change some things (I would argue not everything). Again, this is the same as for v4x. The only difference is that in the v4x case, you put this after the end and ignored it.
Ignoring the bit you don't like for one of them but not for the other isn't a fair comparison.
Yeah I'm with you on not needing to change much to have v6 without actually using it.
But when the world is actually ready for v6, you do need to change everything. And it's worse than that, the world only becomes ready by people changing everything before the world is ready. You said I put this part at the end of v4x, and yes that's the point, the ordering of changes matters.
v4 doesn't even manage one IP per person. It's fundamentally completely insufficient in a world with personal computing devices. Even if you declared every single IP in v4 to be wasted and demanded we repurposed them all, it wouldn't be enough to fix that.
The multicast and reserved blocks total 32 /8s. Before IANA runout, we were going through over one /8 per month, so this would represent less than 2.5 years of allocations. We've already spent decades buying more time for people to migrate to v6; we don't need another 2.5 years that people will just immediately squander.
NAT is not in any way a feature. I'll admit it can be a useful tool in your toolbox sometimes, but otherwise it's just a completely unnecessary complication that breaks things and wastes time and effort. It's not something to be building the Internet on. You want each device to get an IP and you don't want two devices to have the same IP, because that's how machines on the Internet send packets to each other -- which is the entire point of having the Internet at all.
> All of "the global internet" is in 2002::/16, which effectively gives 32 bits of assignable space. Exactly the same as IPv4 [...] the assumption that all routable prefixes are in 2001::/16 as specified
Global allocations are actually coming from the entire of 2000::/3, not 2002::/16 or 2001::/16 (and there's another five untouched /3s in case we need them). So far about 0.2% of it been allocated to RIRs, and most of that RIR space has not yet been allocated to anybody. We're clearly not exhausting it at anything like the rate of v4.
v6 is less complex than v4 in practice due to not needing NAT, and gains us far more than you're thinking. A /48 contains 65k subnets of effectively infinite hosts each, which is similar to a /8 but with no limit on hosts per network, and there are something on the order of a trillion of them in total rather than 256 of them.
What you're describing there is just an approach to store NAT state inside every packet instead of on the router. I'm not sure that's even an improvement on v4, but in any case it wouldn't increase the size of the address space so it wouldn't help with the one thing driving the need for IPv6.
IPv4 will be with us for a long, long time. My point is that we're stuck with the combination in some form or another and it didn't have to be that way.
Embedding the address extension using the extension mechanism built into IPv4 would have allowed for a true upgrade and a single IP address space. Two nodes with eight-byte IP addresses would exchange packets without any rewriting. That's an address-space expansion, not just a weird way to do NAT. With perfect foresight, I have no doubt the IETF could have embraced NAT as a transition technology quickly obsoleted by broad adoption.
Two 6to4 networks will communicate directly between each other without using a relay, so it will still work for that. Although you ought to be able to use native v6 these days.
If you can't deploy v6 (whether native or 6to4) on the remote side for whatever reason, NAT64 is useful for dealing with conflicting RFC1918. You map each instance of RFC1918 you need to access into different v6 /96s, and then they don't conflict from your perspective. (But like NAT44, it only works for outbound connections; inbound ones need a port forward.)
Plenty of people are switching v4 off. Facebook run basically all of their datacenters without v4. T-Mobile USA use only v6 on their network. Thread only supports v6 in the first place
There are plenty of other places doing the same thing, but these examples alone should be sufficient to disprove "no-one is willing to turn v4 off".
You will certainly need to update applications, because they won't be able to connect to v6 addresses otherwise. 464xlat only helps you connect to v4 addresses. It just means that updating _all_ of your applications is no longer a prerequisite of turning v4 off on your network.
It does exist though. The OS part is 464xlat and the router part is NAT64. You can try the second part out by setting your DNS server to one of the ones listed on https://nat64.net/, which will work with hostnames. To get IP literals to work you need 464xlat, which is currently a bit annoying to set up on Linux.
(Note that using the servers provided by nat64.net is equivalent to using an open proxy, so you probably don't want it for general-purpose use. You would probably want either your ISP to run the NAT64 (equivalent to CGNAT), or to run it on your own router (equivalent to NAT).)
The standard prefix for NAT64 is 64:ff9b::/96, although you can pick any unused prefix for it. ::ffff:0:0/96 is the prefix for a completely different compatibility mechanism that's specifically just for allowing an application to talk to the kernel's v4 stack over AF_INET6 sockets (as you figured out). It was a confusing choice of prefix to use to describe NAT64.
reply