Remove ieee802154 from IphcRepr

[Dominaezzz]

First part of #1031 .

The IphcRepr type was written in terms of ieee802154 addresses.
I've replaced the ieee802154 address for structures that closer match the RFC and can be used on other mediums like BLE.

After this, I need to do the same for sixlowpan/mod.rs and move the ieee802154 bits into the wire/ieee802154.rs file.

[codecov]

Codecov Report

Attention: Patch coverage is 49.50690% with 256 lines in your changes missing coverage. Please review.

Project coverage is 80.26%. Comparing base (74bd1e5) to head (36d2d05).
Report is 6 commits behind head on main.

Files with missing lines	Patch %	Lines
src/wire/sixlowpan/iphc.rs	39.39%	140 Missing ⚠️
src/wire/sixlowpan/mod.rs	43.47%	91 Missing ⚠️
src/wire/ieee802154.rs	63.76%	25 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1033      +/-   ##
==========================================
- Coverage   80.88%   80.26%   -0.62%     
==========================================
  Files          81       81              
  Lines       28452    28734     +282     
==========================================
+ Hits        23013    23064      +51     
- Misses       5439     5670     +231     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[Dominaezzz]

Was hoping to get some feedback on the structure of things before investing time into improving coverage.

[Dirbaio]

Could you explain why is this needed to support 6lowpan over BLE?

IIUC address compression works the same way in both 6lo over BLE and 6lo over ieee802.15.4. The info you use to compress/decompress is an EUI64 that can be derived from either the ieee802.15.4 link address or the BLE link address. So I think it should be possible to pass in the EUI64, and have higher layers calculate it differently depending on whether the link is ieee802.15.4 or BLE? Then the code can stay in the same place, the refactor is not needed.

I'm not a 6lowpan expert though. Hopefully @thvdveld can weigh in.

(The reason I'm a bit concerned with the refactor is that "look at packet fields, write Rust enum, copy it around, match it to do thing" typically increases code size vs "look at packet fields, do thing")

[Dominaezzz]

The info you use to compress/decompress is an EUI64 that can be derived from either the ieee802.15.4 link address or the BLE link address.

Yes, this is largely the case for non-contextual compression.
The problem with the existing IphcRepr is, it has ieee802.15.4 link addresses hard coded into it, which cannot be used by BLE. BLE uses mac addresses which are a different length (48 bits) to ieee802.15.4 link addresses (64 bits).
This PR just makes the type more agnostic.

So I think it should be possible to pass in the EUI64, and have higher layers calculate it differently depending on whether the link is ieee802.15.4 or BLE? Then the code can stay in the same place, the refactor is not needed.

Due to the things I've mentioned above, some kind of refactor will still be needed to remove ieee802.15.4 from IphcRepr to allow it to be used for BLE.
See this.

There's more info in the linked issue.

[Dirbaio]

My question is: why can't we keep the current code structure, just replace LlAddress with an EUI64? Higher layers derive this EUI64 from either the ieee802154 or BLE address.

This way wire::sixlowpan is agnostic from ieee802154 and we keep the current code structure which is simpler and uses less flash. No need for the enums you added.

[Dominaezzz]

I unfortunately don't know enough about ieee802154 to give you a good answer. @thvdveld thinks an EUI64 isn't enough for ieee802154.

[thvdveld]

I had a look at RFC6282 for the address compression, and I think working just with EUI64 will work (sorry for not checking that before). We still have to implement the part where an EUI-64 address can be formed from a short address (we only have the implementation for IEEE 802.15.4 extended addresses), which is defined in section 3.2.2. This means that the full implementation of the compression needs to be rewritten to actually do it with the EUI-64 address. I'm not sure if the case where nothing can be elided from the IPv6 address and the full address is going to be in-lined in the packet is going to occur in BLE.

For multicast IPv6, as I understand it, the multicast compression format for IEEE 802.15.4 is not used in BLE, since there is no multicast/broadcast in BLE. IPv6 multicast packets need to be replicated to each link. However, multicast uses broadcast in IEEE 802.15.4.

[Dominaezzz]

Ah I see. In that case this PR isn't what smoltcp is looking for.