gnrc/sixlowpan/ctx: clamp prefix length to 64 bit#19648
gnrc/sixlowpan/ctx: clamp prefix length to 64 bit#19648benpicco wants to merge 1 commit intoRIOT-OS:masterfrom
Conversation
benpicco
added
Type: bug
|
|
||
| /* IPHC does not support prefixes shorter than 64 bit | ||
| * see https://datatracker.ietf.org/doc/html/rfc6282#page-9 */ | ||
| if (prefix_len < 64) { |
There was a problem hiding this comment.
Shouldn't that rather result in an error instead of silently changing the passed value?
There was a problem hiding this comment.
It's only about what can be compressed. Say you have a prefix of fd00::/32. With the proposed change, we can still use the compression context if all prefix bits are zero.
| Address | Can be compressed |
|---|---|
| fd00::1234 | ✅ |
| fd00:0:c000::1234 | ❌ |
| fd12::1234 | ❌ |
If we would not accept the compression context at all, addresses that could have been compressed are not.
| Address | Can be compressed |
|---|---|
| fd00::1234 | ❌ |
| fd00:0:c000::1234 | ❌ |
| fd12::1234 | ❌ |
And even for the 96 bits, the prefix is a 64-bit, the remaining bits are then But besides that point, I am not sure that clamping the prefix length is a good idea. 6Lo-ND does not put any restrictions on the prefix length and also RFC 6282 is very clear on what should happen if a prefix is shorter or longer than 64-bit:
So if the prefix is shorter, the space between the prefix and the IID is filled with 0-bits, if the prefix is longer, its bits take preference over the IID bits.
I don't see how that is a problem with regards to header compression... Maybe there is a bug in compression where it is not checked if the bits not covered by either prefix or IID are actually 0? |
Looks like it. See #19649 for an alternative approach (still untested) |
|
superseded by #19649 |
4 participants
Contribution description
IPHC only allows to elide the first 64, 96 or 128 bits of an address.
If e.g. a /32 subnet like
fd00::/32is added as a compression context, the addressfd00:0:c000:0:6481:20ff:fef9:b694would match it.But when IPHC used, there is no way to recover the missing 32 bit - the receiver would interpret the address as
fd00::6481:20ff:fef9:b694which is wrong.To prevent this, clamp prefixes to 64 bit.
We could also get rid of the prefix length field entirely, but that's a bit more of an invasive change.
Testing procedure
Issues/PRs references