Because all it does is prepend a prefix, the address translation algorithm from RFC 6052 can take any IPv4 address as input and generate an IPv6 address as a result.
Because it depends on an input IPv6 address containing the prefix, the opposite is not true: It cannot generate an IPv4 address out of any IPv6 address.
I think this is the reason why RFC 6791 requires an IPv4 address pool but doesn't even mention an IPv6 pool; assuming RFC 6052 is the only address translation algorithm at play, any IPv4 router will source ICMPv4 errors in translatable ways. It's IPv6 routers that need to be masked with special IPv4 addresses.
If we're defining new address translation algorithms, I think we risk breaking this assumption. In particular, EAM breaks it. It is entirely possible to configure an EAM table where not every IPv4 address is translatable. (ie. pretty much any EAMT that doesn't include 0.0.0.0/0)
Now, it's true that EAM can be used in concert with RFC 6052 translation (therefore making every IPv4 address translatable), but Tore and I agree that there are use cases where EAM can be used without the 6052 falling back option (https://mail-lists.nic.mx/pipermail/jool-list/2015-August/000041.html). For this reason, it would be asinine for an implementation to force the presence of a 6052 prefix in the configuration as long as there is at least one entry in the EAMT. This could (though in SIIT/DC it doesn't seem to be an issue) lead to a situation where an IPv4 router answers an ICMPv4 error and the translator will have to drop it because its source address doesn't match the EAMT.
I don't know if this is a problem; I'm just theorizing. But it seems to me an "IPv6 RFC 6791 pool" should be defined, if not for the sake of EAM, for the sake of any future address translation algorithms, either IETF-defined or homemade...
ydahhrk
commented
8 years ago
IPv6 pool6791 = A pool of IPv6 addresses used to source untranslatably-sourced ICMPv4 errors with.
Better explained in this e-mail: