gnrc/sixlowpan/ctx: clamp prefix length to 64 bit #19648
Conversation
| @@ -165,6 +165,12 @@ static inline bool gnrc_sixlowpan_ctx_update_6ctx(const ipv6_addr_t *prefix, uin | |||
| gnrc_sixlowpan_ctx_t *ctx = gnrc_sixlowpan_ctx_lookup_addr(prefix); | |||
| uint8_t cid = 0; | |||
|
|
|||
| /* 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 |
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