Every time there's a discussion about IPv6, a suggestion like that appears, without fail. Paraphrasing the classic spamsolutions.txt, "Your idea will not work. Here is why it won't work."

"Requires immediate total cooperation from everybody at once": every single system which wanted to talk to an AWS host would have to implement that IPv4 extension.

"Many server administrators cannot afford to lose business or alienate potential clients": for anyone with a non-upgraded system, the server would be unreachable.

Specifically, your plan fails to account for:

- Lack of centrally controlling authority for networking

- Huge existing software investment in IPv4

- Popularity of NAT and other middleboxes

- Users who don't update their operating system ever

and the following philosophical objections may also apply:

- Ideas similar to yours are easy to come up with, yet none have ever been shown practical

- It will work for a while and then we'll get stuck with it

- It's an ugly hack

"Sorry dude, but I don't think it would work."

(I apologize for choosing your comment for this, but this idea of applying the spamsolutions.txt format to the inevitable "extended IPv4" proposals has been in my head for a long time. Someone with more networking experience should be able to present an even more complete list of "extended IPv4 objections".)

If I understand what you're suggesting, this is basically how NAT64 [0] works to provide backwards compatibility to IPv6 (tunneling IPv4 over IPv6). It uses the first 32 bytes of the IPv6 address to store the IPv4 value.

[0] https://en.wikipedia.org/wiki/NAT64

Pedantic comment here, but NAT64 doesn’t involve any tunneling - it’s pure address translation handled by an edge box, whereas tunneling involves encapsulation.

True, I should have been more precise.

Although there is technically no packet-level encapsulation, from a mathematical perspective you may consider the IPv4 bits "encapsulated" within the IPv6 bits.