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

Closed
crisdeleon opened this Issue Sep 29, 2015 · 4 comments

Projects

None yet

3 participants

@crisdeleon
Contributor

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
Member
ydahhrk commented Sep 29, 2015

._. .-.

@ydahhrk ydahhrk added this to the 3.4.0 milestone Sep 29, 2015
@toreanderson
Contributor

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
Member
ydahhrk commented Sep 30, 2015

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 ydahhrk added a commit that referenced this issue Sep 30, 2015
@ydahhrk ydahhrk Issues #173 and #174.
Regarding #174:
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.
d650806
@ydahhrk
Member
ydahhrk commented Nov 10, 2015

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.

@ydahhrk ydahhrk closed this Nov 10, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment