It makes sense only in the abstract. Once you look at the details of how IPv4 was implemented, it is clear that such an idea makes no sense at all. All IPv4 dev

It makes sense only in the abstract. Once you look at the details of how IPv4 was implemented, it is clear that such an idea makes no sense at all. All IPv4 devices and software are hard coded to use 32 bit addresses. No more and no less. No amount of "design" can make 128 bits fit into 32 short of having designed IPv4 with bigger (or variable length) addresses in the first place. To have an "extended IPv4 space" you must change all hardware and all software to be aware of that extended space. Hardware/software/networks that haven't been changed yet won't be able to use or route "extended" IPv4 packets. Such a situation has all of the same problems as IPv6. Given those fundamental limitations plenty has been done to make inter-operating between protocols work as well as possible. The ::ffff:/96 space was set aside as the "IPv4 embedded in IPv6" space (http://en.wikipedia.org/wiki/IPv6#IPv4-mapped_IPv6_addresses http://en.wikipedia.org/wiki/IPv6#IPv4-mapped_IPv6_addresses) so that IPv6 aware software can talk about IPv4 addresses. Though cannot talk to them because there is no way to encode the 128 bit return address in the 32 bit field. IPv4 was extended with the protocol 41 header option to allow two IPv6 systems to exchange IPv6 packets over the existing IPv4 network (this is how 6to4 and teredo/6in4(tunnelbroker) systems work). This effectively means that anyone with a public IPv4 address (or in the case of teredo even some systems behind NAT4) can talk to IPv6 machines albeit through translation mechanisms that can hurt performance.