Subject: [v6ops] What do I do with untranslatable IPv4 addresses?

From: Alberto Leiva <[email-masked]>
Date: Wed, 26 Aug 2015 11:23:07 -0500

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...

Opinions?
Alberto