First - we already have extended the IPv4 address space by using + PORT in many cases (ie, running through CGNAT). So if I want to talk to another IPv4 host, we focus on IPv4+PORT, and the CGNAT's translate that to private IPv4 addresses on their local networks.
Plenty of good migration options exist(ed) that allow for each host to be single stack and still talk to each other while upgrading at different rates. The basic approach was a simpler ipv6 that didn't change all the concepts around with an ipv4 range embeded in it.
Routing then just proceeded as normal, but if an IPv6 host was trying to talk to an IPv4 host, if the next step in route was IPv4, then router drops the extra IPv6 bits (would likely have been hop before server).
Conversely, when IPv4 host is talking to an IPv6 only host, they are routing back, and then when the next link in route is IPv6 only you rehydrate the IPv4 address with the IPv6 IPv4 prefix. The IPv4 network is talking to you using IPv4+PORT. The Port is basically how we get extra address space ALREADY with IPv4 and CGNAT (but to allow transition now you map that inbound IPv4+PORT to an IPv6 address. Being smart you can actually do a predictable mapping here if you wanted).
Other little tweaks make this better - but the key is that I as an end user can go IPv6 only on my network (ideally in a more IPv4 style without the complexity).
Anyways, some networks are already converging / heading this way with things like X64LAT or whatever - allowing devices to basically see an IPv6 only world. But you are still dragging along this insane IPv6 complexity
You're essentially describing NAT64, a thing which exists in v6 already. I use it on my desktop, which has no v4 address. You're arguing for something we already have.
v6 isn't really very complex. In fact it's generally simpler than v4, especially when you run out of v4 address space and NAT gets involved.
> First - we already have extended the IPv4 address space by using + PORT in many cases (ie, running through CGNAT). So if I want to talk to another IPv4 host, we focus on IPv4+PORT, and the CGNAT's translate that to private IPv4 addresses on their local networks.
So how does a VPS / cloud provider use the +PORT to give themselves and their customers more publicly-available addresses to assign to virtual machines?
> Plenty of good migration options exist(ed) that allow for each host to be single stack and still talk to each other while upgrading at different rates.
Plenty of good migration options exist(ed) that allow for each host to be single stack and still talk to each other while upgrading at different rates. The basic approach was a simpler ipv6 that didn't change all the concepts around with an ipv4 range embeded in it.
Routing then just proceeded as normal, but if an IPv6 host was trying to talk to an IPv4 host, if the next step in route was IPv4, then router drops the extra IPv6 bits (would likely have been hop before server).
Conversely, when IPv4 host is talking to an IPv6 only host, they are routing back, and then when the next link in route is IPv6 only you rehydrate the IPv4 address with the IPv6 IPv4 prefix. The IPv4 network is talking to you using IPv4+PORT. The Port is basically how we get extra address space ALREADY with IPv4 and CGNAT (but to allow transition now you map that inbound IPv4+PORT to an IPv6 address. Being smart you can actually do a predictable mapping here if you wanted).
Other little tweaks make this better - but the key is that I as an end user can go IPv6 only on my network (ideally in a more IPv4 style without the complexity).
Anyways, some networks are already converging / heading this way with things like X64LAT or whatever - allowing devices to basically see an IPv6 only world. But you are still dragging along this insane IPv6 complexity