[riot-notifications] [RIOT-OS/RIOT] gnrc_netif: centralize device-type-specific functions (#10524)

Martine Lenders notifications at github.com
Sat Jan 5 23:55:02 CET 2019


> > Also, the IID is not the interfaces EUI-64 (it refers to the IEEE 802.15.4 long address), as the second U/L-Bit gets still flipped.
> 
> I'm confused a bit, the IID as the second part of an IPv6 address is an EUI-64. If it is derived from MAC48, Bit 1 in first byte is already flipped. I would expect that `gnrc_netif_ipv6_iid_from_addr` provides exactly the EUI-64 from its MAC-48.

Yes and no. The [IID is formed from the EUI-64](https://tools.ietf.org/html/rfc2464#section-4) by flipping the bit, so the IID is semantically distinct from the IID (though RIOT-internally we use the same type for practicality, since syntactically they are the same). The EUI-64 for a IEEE 802.15.4 is given, as it [only knows EUI-64](https://tools.ietf.org/html/rfc4944#section-6) (and 2-bit short addresses were a stuffing algorithm is also specified). For a MAC-48 (or EUI-48) it needs to be formed as you described by stuffing. The main reason why I stated RFC 6775 might not apply for ESP-now (and most of our IEEE 802.15.4 devices, since we do not have an address provided by the vendor there) is that RFC 6775 assumes the EUI-64 is globally unique.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/RIOT-OS/RIOT/pull/10524#issuecomment-451699097
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.riot-os.org/pipermail/notifications/attachments/20190105/76753559/attachment.html>


More information about the notifications mailing list