> and somewhat backward compatible with IPv4.

How would it be at all backward compatible other than what NAT64 already does?

I suspect the thinking is that all of IPv4 could have been a contained within the IPv6 space. Perhaps at at the very beginning or very end of it.

Any time you would reference an IPv4 address when v6 enabled, the stack would simply fill in the remaining bits and forward your packets down the line.

This had to have been thought about though, and I suspect the architects of v6 felt it would've been sub-par to what we have. No idea if that's true though.

▲

yjftsjthsd-h 4 days ago | parent | next [-]

> I suspect the thinking is that all of IPv4 could have been a contained within the IPv6 space. Perhaps at at the very beginning or very end of it.

They actually went with 64:ff9b::/96 as the default (though IPv6 is so big that you can just pick another area if you want in ULA space or whatever).

> Any time you would reference an IPv4 address when v6 enabled, the stack would simply fill in the remaining bits and forward your packets down the line.

There are actually multiple implementations, depending on OS and whether you want it in kernel space or user space.

> This had to have been thought about though, and I suspect the architects of v6 felt it would've been sub-par to what we have. No idea if that's true though.

They thought about it, named it NAT64 ( https://en.wikipedia.org/wiki/NAT64 ), published it, and it's in wide use. It frequently is combined with 464XLAT ( https://en.wikipedia.org/wiki/IPv6_transition_mechanism#464X... ) to make the transition mostly invisible to users/applications.

	▲	herczegzsolt 3 days ago \| parent [-]
		There are actually multiple areas already: ::ffff:0:0/96 IPv6-mapped This space is intended for an OS or network stack to map IPv4 addresses towards higher layers, so applications could technically be IPv6 only. The packet was/will be standard IPv4 when it reaches the network wire. ::/96 and ::ffff:0:0:0/96 IPv6-compatible/IPv6-mapped These were originally intended to be used on networks to differentiate IPv4 addresses depending on the capability of the target and decide who will do the translation. These are now deprecated, but the whole ::/8 is reserved, and these addresses are promised to never be assigned to anything else. 64:ff9b::/96 IPv6-translated This is the space for IPv6 to IPv4 NAT translators. Actually the whole /48 is reserved, so you can run address multiple private translators in a single network if required. This is widely used and supported. As a side note Teredo addresses (2001::/32) and 6to4 addresses (2002::/16) all embed the entire IPv4 address space, although they are more complex than a simple 1-to-1 mapping. They are rarely used.

▲

Ekaros 4 days ago | parent | prev [-]

Problem always is how to get packet back. The IPv4 host can get packet from somewhere. But if it simply does not have enough bits to represent the return address it cannot send packet back that actually arrives. Unless you do something like NAT that is get help form something on the way. And that something then has to keep track of whatever was done.