[mvkg]

IPv10[0] makes IPv4 an extension of the IPv6 space. It'll be interesting to see if this takes off, but it doesn't really seem to solve the whole problem. All nodes in the path would have to support IPv10 for it to work.

[0] https://datatracker.ietf.org/doc/draft-omar-ipv10/

[zkms]

The internet-draft you linked is not a proposal that anyone should take seriously. Here is an actual, non-mocking review of that I-D: https://www.ietf.org/mail-archive/web/int-area/current/msg05... . To put it diplomatically, that author does not seem to have a proper understanding of IPv6 deployment nor of any relevant prior art.

There is neither "rough consensus" (besides that the author should have their posting privileges on the IETF lists removed) and certainly not any "running code". They've been trying to get IETF people to care about their harebrained "IPv10" scheme since November 2016; that they have yet to realise that their scheme is useless and that nobody seriously cares is about as depressing as seeing that internet-draft getting cited.

The term "crank" (https://en.wikipedia.org/wiki/Crank_(person)) is applicable here.

[mvkg]

I was a bit surprised to see that it wasn't published on April 1 and got renewed multiple times.

Some parts of it are laughable such as

       IPv10 support on "all" Internet connected hosts can be deployed
       in a very short time by technology companies developing OSs
       (for hosts and networking devices, and there will be no
       dependence on enterprise users and it is just a software
       development process in the NIC cards of all hosts to allow
       encapsulating both IPv4 and IPv6 in the same IP packet header.

But it does have an interesting take on stateless IPv4 <-> IPv6 communication, specifically IPv4 -> IPv6. Obviously it wouldn't work as described without a full deployment, but it seems like something could be done there.

For instance, if an IPv4-only host wanted to communicate to an IPv6-only host, it could send packets to a well-known NAT46 anycast address with an IP option of the destination host. The NAT46 host could then create the IPv6 packet with the correct destination and IPv4-mapped source.

He suggested using the IPv4 routing table for IPv4-mapped IPv6 addresses, which wouldn't be loop-free unless every router was dual stack and did the same thing. However, with what I described, it seems like any dual-stack host (or router) could perform the translation in a loop-free manner.

[cesarb]

I just spent more time than I should have reading these threads (a bigger and more interesting one starts at https://www.ietf.org/mail-archive/web/int-area/current/msg05...). Fascinating. The author:

- Understands that the proposal requires that "anything [that] will process a L3 packet" be upgraded to understand the new packet format, but seems to believe it's a simple matter of making the OS developers (which are "few") "push new updates globally".

- Seems to believe having the proposal ratified by the IETF is both necessary and sufficient for the proposal to be adopted everywhere.

Edit: the author is now requesting that the internet-draft be removed from the database: https://www.ietf.org/mail-archive/web/ietf/current/msg103018...