gnrc_sixlowpan_iphc: add support for IPv6 extension header compression

[miri64]

Contribution description

Up until now there was still a part of RFC 6282 missing: IPv6 extension header compression. This PR completes IPHC according to RFC 6282 by adding both compression and decompression for extension headers and encapsulated IPv6 headers (which is part of IPv6 extension header compression in RFC 6282).

Testing procedure

Up until now i only confirmed that the current functionality is not regressed by using tests/gnrc_udp on two iotlab-m3s and sending:

• unfragmented packets without NHC:

  ping6 <link-local addres of 2nd node>
  

• fragmented packets without NHC:

  ping6 -s 160 <link-local addres of 2nd node>
  

• unfragmented packets with NHC

  // start server on 2nd node with `udp server start 61616`
  udp send <link-local addres of 2nd node> 61616 8
  

• fragmented packets with NHC

  // start server on 2nd node with `udp server start 61616`
  udp send <link-local addres of 2nd node> 61616 160
  

Additionally I tested the use case that caused me implementing this: sending IPv6 fragmented packets compressed:

ping6 -s 1500 <link-local addres of 2nd node>
// start server on 2nd node with `udp server start 61616`
udp send <link-local addres of 2nd node> 61616 1500

And confirmed with Wireshark, that the packets are sensible (as far as I can judge).

I plan to provide a dedicated test application utilizing socket_zep and scapy to have more coverage, but that I will do if I find the time for that (this is why this PR is still WIP). (no NHC support for scapy yet)

Issues/PRs references

None technically, however I cherry-picked be7b6d3 out of #12629 to avoid conflicts between this PR and the clean-ups in #12629.

[miri64]

And confirmed with Wireshark, that the packets are sensible (as far as I can judge).

Wireshark does not work well with IPHC and IPv6 fragmentation apparently (and I had to handle that corner case in a very hacky way as well): As with UDP NHC the length field is elided (with encapsulated IPv6 headers as well), we have no way within NHC to reconstruct it if it is in a fragmented IPv6 packet (as it is inferred from the IPv6 packet's length minus the preceding extension headers, which is however with IPv6 fragmentation just the length of the first fragment). We only can update the length field after we reassembled the fragmented IPv6 packet so within the IPv6 extension header module, which is what I did.

[miri64]

Rebased to current master as the merging #12629 caused some conflicts after all :-/

[miri64]

Sadly, scapy has no NHC support yet either, so I updated the OP and removed the WIP label.

[miri64]

Fixed issues pointed out by Murdock.

[benpicco]

Code looks good. I get this is only for fragmented next headers right? So no change in L2-PDU is to be expected.

A node samr21-xpro node with the code from this PR is still able to send and receive fragmented IPv6 packets to a node that doesn't have this patch.

Feel free to squash the fix.

[miri64]

Code looks good. I get this is only for fragmented next headers right? So no change in L2-PDU is to be expected.

No for fragment next header. So when the IPv6 packet is fragmented via the fragment header.

[miri64]

(I'm using this code already relatively successfully on in my experiments for a few days btw)

[miri64]

Squashed

[benpicco]

Code looks good, no regressions when sending fragmented packets to old RIOT nodes or Linux nodes.

[miri64]

Code looks good, no regressions when sending fragmented packets to old RIOT nodes or Linux nodes.

Please clarify what you mean by "fragmented" packets in a 6Lo+IPv6 fragmentation context. Did you send only 6LoWPAN-fragmented packets (packet size <=1280) or also IPv6-fragmented packets (>1280; which in turn are 6LoWPAN-fragmented packets)

[benpicco]

Did you send only 6LoWPAN-fragmented packets (packet size <=1280) or also IPv6-fragmented packets (>1280; which in turn are 6LoWPAN-fragmented packets)

I wasn't even aware I could send packets > 1280 bytes. I only tried 6LoWPAN fragmented packets.

[miri64]

Did you send only 6LoWPAN-fragmented packets (packet size <=1280) or also IPv6-fragmented packets (>1280; which in turn are 6LoWPAN-fragmented packets)

I wasn't even aware I could send packets > 1280 bytes. I only tried 6LoWPAN fragmented packets.

You helped make it possible (#11623, #11596) ;-). This PR adds compression for the IPv6 extension headers (including the fragment header), so using IPv6 fragmentation for testing is important, as lined out in the testing procedures for this PR.

[miri64]

However, since I use this for days now in my setup

(I'm using this code already relatively successfully on in my experiments for a few days btw)

I think we can merge anyway, what do you think @benpicco?