> The wide-address host would have to have an additional IPv4-compatible address bound to its network interface.
Yes, we call that (having v4 and v6 addresses) a "dual stack" configuration. The host gets to choose which protocol to use as it desires. If you have a v4 address, you can even refer to that (v4) address in v6 packets[1] by setting the leading bits to 0. That is, v4 "A.B.C.D" as a v6 address is just "::A.B.C.D". The v4 address space is embedded into the v6 address space; this is generally automatic in dual-stack configurations. You can even refer to a v4-only address in a v6 packet as "::FFFF:A.B.C.D".
However, if you want your packets to convert back to v4 automagically (so you only have to speak a single v6 stack)... if you want to autoconvert between IP versions in transit...
> some other host would have to have such an IPv4-compatible address on its behalf
As jandrese already pointed out, that's called 4to6, setup the proxy (if needed), and use "64:ff9b::A.B.C.D" for your v4 addresses.
The thing you seem to be asking for is already a feature of IPv6. However, the thing that can never happen is doing any of this transparently in a v4 packet. Where, specifically, in the IPv4 header[2], are you going to put extra SRC and DST address bits? You cannot change the location of any existing bit in the header: everything (including IP-aware routing hardware) (including the software/firmware of every v4-speaking device, most of which will never - or cannot ever - receive an update) already assumes that e.g. "the source address is on header octet 12-15 (bit 96-127)". The only remotely hypothetical place anything could be added would be in an IP Option field, which would be a terrible idea. Other options might change the location of the new address bits in the header, meaning routers would have to sequentially parse all of the option fields to parse addresses, which would be a mandatory delay even with legacy pure-v4 packets. Also, most firewalls will probably drop the new, unexpected option as "possibly malicious". To do anything else to the header, you would need to change the version number, which immediately introduces the compatibility issues everyone complains about with IPv6.
Yes, we call that (having v4 and v6 addresses) a "dual stack" configuration. The host gets to choose which protocol to use as it desires. If you have a v4 address, you can even refer to that (v4) address in v6 packets[1] by setting the leading bits to 0. That is, v4 "A.B.C.D" as a v6 address is just "::A.B.C.D". The v4 address space is embedded into the v6 address space; this is generally automatic in dual-stack configurations. You can even refer to a v4-only address in a v6 packet as "::FFFF:A.B.C.D".
However, if you want your packets to convert back to v4 automagically (so you only have to speak a single v6 stack)... if you want to autoconvert between IP versions in transit...
> some other host would have to have such an IPv4-compatible address on its behalf
As jandrese already pointed out, that's called 4to6, setup the proxy (if needed), and use "64:ff9b::A.B.C.D" for your v4 addresses.
The thing you seem to be asking for is already a feature of IPv6. However, the thing that can never happen is doing any of this transparently in a v4 packet. Where, specifically, in the IPv4 header[2], are you going to put extra SRC and DST address bits? You cannot change the location of any existing bit in the header: everything (including IP-aware routing hardware) (including the software/firmware of every v4-speaking device, most of which will never - or cannot ever - receive an update) already assumes that e.g. "the source address is on header octet 12-15 (bit 96-127)". The only remotely hypothetical place anything could be added would be in an IP Option field, which would be a terrible idea. Other options might change the location of the new address bits in the header, meaning routers would have to sequentially parse all of the option fields to parse addresses, which would be a mandatory delay even with legacy pure-v4 packets. Also, most firewalls will probably drop the new, unexpected option as "possibly malicious". To do anything else to the header, you would need to change the version number, which immediately introduces the compatibility issues everyone complains about with IPv6.
[1] http://www.tcpipguide.com/free/t_IPv6IPv4AddressEmbedding.ht...
[2] https://en.wikipedia.org/wiki/IPv4#Header