Untranslatable IPv6 Addresses
Suppose n4 is trying to reach n6, but there is a problem (eg. the packet is too big), and R sends n4 an ICMP error. T is translating using prefix 2001:db8::/96 and doesn’t have any records in the EAMT.
R’s packet will have the following addresses:
T is in trouble because the source address of the packet lacks the translation prefix, so an IPv4 address cannot be extracted from it.
Normally, you don’t have many translatable IPv4 addresses, so it’s not reasonable to grant one to every node in your IPv6 domain. Due to their generally forwarding-only purpose, routers are good candidates for owning untranslatable addresses. On the other hand, ICMP errors are important, and an SIIT should not drop it simply because it comes from a router.
To sort things out, RFC 6791 mandates SIIT modules should keep an additional pool of reserved IPv4 addresses. Upon receiving an ICMPv6 error with an untranslatable source, the translator must fall back to use a random address from this pool as source.
In Jool, the pool is called “pool6791v4” and can be populated through
In practice, Jool doesn’t actually force you to populate pool6791. If you leave it empty, Jool will fall back to source untranslatable ICMP errors using its machine’s own IPv4 addresses. As you will see below, this is not entirely ideal, but you can live with it as long as you don’t mind your traceroutes looking confusing.
If you intend on populating pool6791, consider the following (quoting RFC 6791):
The source address used SHOULD NOT cause the ICMP packet to be discarded. It SHOULD NOT be drawn from [RFC1918] or [RFC6598] address space, because that address space is likely to be subject to unicast Reverse Path Forwarding (uRPF) [RFC3704] filtering. (...) Another consideration for source selection is that it should be possible for the IPv4 recipients of the ICMP message to be able to distinguish between different IPv6 network origination of ICMPv6 messages (for example, to support a traceroute diagnostic utility that provides some limited network-level visibility across the IPv4/ IPv6 translator). (...) Currently, the TRACEROUTE and MTR [MTR] are the only consumers of translated ICMPv6 messages that care about the ICMPv6 source address. (...) If a pool of public IPv4 addresses is configured on the translator, it is RECOMMENDED to randomly select the IPv4 source address from the pool. Random selection reduces the probability that two ICMP messages elicited by the same TRACEROUTE might specify the same source address and, therefore, erroneously present the appearance of a routing loop.