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
Suggestion: Predictable selection of RFC6791 addresses #130
Currently, Jool will select addresses from its RFC6791 addresses in a random fashion. That's in line with the RFC's recommendations. The rationale for this recommendation is as follows:
That's all well and good, but it does cause some funny results from traceroute programs that run continuously, such as MTR. See below for an example, where
However, I can imagine an even better way to do it, that stays true to the RFC's rationale. The algorithm I propose is to use the
This means that a traceroute will appear to have a loop (i.e., contain repeating "hops") IFF the number of IPv6 hops is greater than the number of addresses in Jool's RFC6791 pool. But in this case, the random selection approach must necessarily produce repeating hops as well, so it fares no worse.
If the RFC6791 pool contains an equal or greater number of addresses then there are IPv6 hops in the path, the question of whether or not hops will repeat becomes a question of probability - the larger the size of the RFC6791 pool and the smaller number of IPv6 hops, the smaller the probability that repeats will occur - but you can never be certain that they won't. My algorithm would on the other hand guarantee that the traceroute will not contain any repeated hops.
As an added benefit, using a /24 means that if the ICMPv4's source address is x.y.z.n, then you can immediately deduce that the original ICMPv6's
Note that I do not propose that the imminent release of Jool 3.3 should be delayed in order to implement this. Unless it is super easy and super fast to implement, please wait until 3.4! It is absolutely not a important feature in any way, merely a «nice to have».
added a commit
Mar 8, 2015
After testing current Git master I realise that I made a faulty assumption when I thought that my approach would be able to guarantee that no "loops" would show up by using a /24 as the RFC6791 pool, or indeed as long as the size of the RFC6791 pool was greater than the number of IPv6 hops in the path. Because routing may be asymmetric, there are no guarantee that the HLIM of the ICMPv6 Time Exceeded received by Jool from an IPv6 router will accurately indicate the number of hops in to that router in the outbound direction. Even if it did, it is theoretically possible that the various routers in a path use different initial HLIM values in their ICMPv6 errors, causing them to be identical when received by the Jool box.
In any case, the new
See below for output produced by Git master, using 10.0.0.0/24 as the RFC6791 pool:
(Here's the flag's doc: http://jool.mx/usr-flags-global.html#randomize-rfc6791-addresses)