Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Wrong IPv6 source address when translating ICMPv4 errors in stateful mode #132
It appears that when tracerouting from an IPv6 node out through a Jool in Stateful NAT64 mode, the source address of ICMPv4 errors is translated to the original IPv6 destination address, rather than the IPv4-converted IPv6 address of the IPv4 router. This fools certain traceroute programs to believe that the traceroute succeeds, since they end up seeing replies that appears to come from the target of the traceroute. For example, below you can see a traceroute towards the IPv4 address 254.254.254.254 (which obviously don't realy respond to anything, since it's a martian).
A tcpdump running on the Jool node shows what's going on:
So the source address of the original ICMPv4 error
This breaks traceroute through the Stateful NAT64 for all valid destinations, too. Some traceroute programs, like MTR, doesn't show any hops beyond the Jool node, because it gets a response from the original target of the traceroute, as shown here towards Google's public DNS service (the Jool node is
Regular traceroute fares better, as it appears to continue decrementing the TTL when receiving ICMPv6 Time Exceeded. However all the IPv4 hops in the path are represented using the target IPv6 address, rather than their IPv4-converted IPv6 address per RFC6052:
For comparsion, here's another MTR to Google's public DNS through another implementation of Stateful NAT64. It contains plenty of IPv4-converted IPv6 addresses, as I expect it to.
I don't think it's critical, because it only breaks (some) traceroute programs. ICMPv4 errors from any of the IPv4 routers (such as Frag Needed) would make it back to the IPv6 client. They would have an odd IPv6 source address, but the source address of ICMP errors aren't important, as long as they're not bogon/martian and thus at risk of being dropped.
referenced this issue
Mar 10, 2015
added a commit
Mar 11, 2015
I don't think b00dcf4 fixes this completely. Here's
Frame 1 - original ICMPv6 ping packet sent from the IPv6 source host:
Frame 2 - Jool's IPv6->IPv4 translation of frame 1:
Frame 3 - an TTL exceeded error originated by an IPv4 router in response to frame 2:
Frame 4 - Jool's IPv4->IPv6 translation of frame 3:
What seems wrong here is that the destination IPv4 address
For what it's worth, because of this mismatch, frame 4 gets dropped by a stateful IP6Tables firewall before making it back to the IPv6 client, so the traceroute output shows no responses for any hops beyond the Jool NAT64 (except for the final "hop", i.e., the destination).
From my last batch of mails with Tore, we generally agree that the behaviour being complained about here (which is Jool 3.3 and 3.2 behaviour) is in line with RFC 6146. This would make this bug a "won't fix" kind of scenario, but truth be told, the choice of source address could be improved without too much trouble, and we would like to see the IETF's opinion on this.
Therefore, this bug will remain open for the moment. As Tore's last comment argues, commit b00dcf4 was actually a mistake, and therefore it was left out of Jool 3.3.1 on purpose.
I just wrote a lengthy e-mail to the RFC6146 authors and the IETF v6ops working group about the issue.
Whether or not this will be regarded as a bug in RFC6146 itself or not remains to be seen, but it would in any case be nice to have to a user-configurable "not-rfc6146-compliant-but-sane" mode of operation that ensured that the source address of a translated ICMPv6 error is generated by applying the RFC6052 algorithm to the source address of the original ICMPv4 error.
added a commit
Mar 15, 2015
It seems we still don't have much of an answer, so this ended up as an alternate configuration mode, rather than the de facto implementation.