Jool is allowing /96 Network-Specific Prefixes that are not compliant with RFC 6052

[crisdeleon]

RFC 6052, section 2.2 states the following:

Bits 64 to 71 of the address are reserved for compatibility with the host identifier format defined in the IPv6 addressing architecture [RFC4291]. These bits MUST be set to zero. When using a /96 Network-Specific Prefix, the administrators MUST ensure that the bits 64 to 71 are set to zero.

At the moment, it is possible to add to the pool6 a /96 Network-Specific Prefix that violates the last statement,

e. g. 64:0:0:0:ff00::/96

In which all bits from 64 to 71 are set to one (1).

[ydahhrk]

._. .-.

[toreanderson]

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

[ydahhrk]

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

Deal.

[ydahhrk]

Er... In the end, I decided to accept nonzero u-bits only if --force is present.
This looks more intuitive IMO, as opposed to printing a message in stderr but succeeding anyway.