New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Comments

Projects
None yet
3 participants
@crisdeleon
Contributor

crisdeleon commented Sep 29, 2015

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

This comment has been minimized.

Show comment
Hide comment
@ydahhrk

ydahhrk Sep 29, 2015

Member

._. .-.

Member

ydahhrk commented Sep 29, 2015

._. .-.

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

@toreanderson

This comment has been minimized.

Show comment
Hide comment
@toreanderson

toreanderson Sep 29, 2015

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.

Contributor

toreanderson commented Sep 29, 2015

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

This comment has been minimized.

Show comment
Hide comment
@ydahhrk

ydahhrk Sep 30, 2015

Member

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.

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 added a commit that referenced this issue Sep 30, 2015

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.
@ydahhrk

This comment has been minimized.

Show comment
Hide comment
@ydahhrk

ydahhrk Nov 10, 2015

Member

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.

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