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
Jool is allowing /96 Network-Specific Prefixes that are not compliant with RFC 6052 #174
RFC 6052, section 2.2 states the following:
At the moment, it is possible to add to the pool6 a /96 Network-Specific Prefix that violates the last statement,
In which all bits from 64 to 71 are set to one (1).
The reason for requiring bits 64-71 be 0 was because RFC4261 makes some requirements about the format of valid Interface IDs with regards to the so-called u-bit; it must be cleared for non-globally-unique Interface IDs. The u-bit is contained in the byte at position 64-71. In order to construct an standards-compliant Interface ID based on RFC6052 when using traditional SIIT with a /96 prefix, the u-bit is part of the prefix itself, so that requirement transfers into the prefix selection.
This is also the reason why RFC6052 section 2.2 scatters the embedded IPv4 address "all over the place" for prefix lengths other than /96; it's trying hard to avoid putting anything into u-bit.
However, RFC7136 clarifies that the u-bit has no significance in Interface IDs that are not derived from MAC addresses. That is our case (rather, they are derived from IPv4 addresses). So the rationale for RFC6052 requiring bits 64-71 to be cleared no longer exists, and it was probably an oversight by the RFC7136 to not update RFC6052 accordingly (I'll notify the authors).
In any case, considering all of the above, I'd suggest resolving this issue by going no further than make Jool emit a warning (but still accepting it) if the admin inserts a non-compliant