This gets repeated over and over, but the issue is that it's an impossible task.
A ipv4-only host cannot ever directly communicate with a IPv6/IPv7/.. host.
The issue is simply that you cannot fit more than 32bit of information into 32bit.
There are plenty of migration technologies that exist to integrate IPv4 and IPv6 (NAT64, tunneling ipv6 over ipv4, etc. etc.).
And anything like IPv7/IPv6-light will end up with the same issues and solutions you are facing today with IPv6.
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.
This was brought up in another part of the thread. I'm copy-pasting my reply:
---
From the RFC (emphasis added):
> The long term goal of the TUBA proposal involves transition to a worldwide Internet which operates much as the current Internet, but with CLNP replacing IP and with NSAP addresses replacing IP addresses.
[…]
In §3 Migration:
> Updated Internet hosts talk to old Internet hosts using the current Internet suite unchanged. Updated Internet hosts talk to other updated Internet hosts using (TCP or UDP over) CLNP. This implies that updated Internet hosts must be able to send either old-style packets (using IP), or new style packet (using CLNP). Which to send is determined via the normal name-to-address lookup.
So you're replacing IPv4 with something that is not-IPv4 on every router and every host. During the transition period everyone will have IPv4 and not-IPv4 addresses.
How is not-IPv4 being CLNP/NSAP any different that not-IPv4 being IPv6? What am I missing?
In §6 on DNS:
> TUBA requires that a new DNS resource record entry type ("long-address") be defined, to store longer Internet (i.e., NSAP) addresses.
In case of BGP it was possible since it's not a end to end communication protocol.
How exactly does TUBA solve the problem where ipv4-only host wants to communicate with a non-ipv4 host?
This proposal solves none of the issues we are facing of IPv6.
The RFC suggests some of the transitional technologies that are in issue with IPv6 today/the past: tunneling IPv6 over IPv4 (6in4, teredo, etc.), dualstack, NAT64 and other mapping, AAAA recrods in dns.
But it doesn't get around the fact that you cannot fit more than 32bit of information into a 32bit address.
also, in the case of BGP it is also possible because it is a protocol with a strict process around its use in the default free zone with a community of peers who all benefit from being interconnected and being able to exchange routes.
it is far easier to convince a couple of thousand organizations to modify their highly specialized infrastructure compared to end users and manufacturers who just want to use or create widgets which will do what is required.
RFC1347 (TUBA) is architecturally not very different from a Dual Stack IPv6 setup with 6rd and IPv4 (CG)NAT, except that you're stuck with the fragmented IPv4 routing table forever since the extended (CLNP) packets are routed over the original IPv4 network. And of course it's missing various other improvements made in IPv6 such as the higher baseline MTU of 1280 bytes (vs. the IPv4 baseline MTU of 576 bytes minus the CLNP headers), the removal of in-route IP fragmentation, the streamlined IP header, etc. Implementing TUBA would still requirement changes to all existing network applications and many protocols to work with extended addresses, so you might as well just add IPv6 support instead.
This exists for IPv6 and would need to exist for any alternative proposal.
And there are certain deployments of this in action, where hosts only have IPv6 and they only receive IPv4 connectivity via NAT mapping at the edge.
One issue with it is however that it doesn't address the address exhaustion issue since you would still need one IPv4 address for each IPv6 address you want to map to.
A ipv4-only host cannot ever directly communicate with a IPv6/IPv7/.. host. The issue is simply that you cannot fit more than 32bit of information into 32bit.
There are plenty of migration technologies that exist to integrate IPv4 and IPv6 (NAT64, tunneling ipv6 over ipv4, etc. etc.). And anything like IPv7/IPv6-light will end up with the same issues and solutions you are facing today with IPv6.