▲ | sedawkgrep 4 days ago | |||||||
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. | ||||||||
| ||||||||
▲ | 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. |