Hi, On 02/26/2017 07:05 AM, Alexander Aring wrote: > > Hi, > > On 02/24/2017 01:14 PM, Luiz Augusto von Dentz wrote: >> From: Luiz Augusto von Dentz <luiz.von.dentz@xxxxxxxxx> >> >> Accourding to RFC 7668 U/L bit shall not be used: >> >> https://wiki.tools.ietf.org/html/rfc7668#section-3.2.2 [Page 10]: >> >> In the figure, letter 'b' represents a bit from the >> Bluetooth device address, copied as is without any changes on any >> bit. This means that no bit in the IID indicates whether the >> underlying Bluetooth device address is public or random. >> >> |0 1|1 3|3 4|4 6| >> |0 5|6 1|2 7|8 3| >> +----------------+----------------+----------------+----------------+ >> |bbbbbbbbbbbbbbbb|bbbbbbbb11111111|11111110bbbbbbbb|bbbbbbbbbbbbbbbb| >> +----------------+----------------+----------------+----------------+ >> >> Because of this the code cannot figure out the address type from the IP >> address anymore thus it makes no sense to use peer_lookup_ba as it needs >> the peer address type. >> > > I am still not quite 100% of this and want to leave my opinion about this > handling which can be interpreted in a different way. > > The RFC says here: > > Following the guidance of [RFC7136], a 64-bit > Interface Identifier (IID) is formed from the 48-bit Bluetooth device > address by inserting two octets, with hexadecimal values of 0xFF and > 0xFE in the middle of the 48-bit Bluetooth device address as shown in > Figure 6. Okay, they said from IID from the 48-bit address. And IID is what you need here and what [RFC7136] describes as result, so I think you are right. There is no need for special u/l bitflip or link-layer multicast handling. - Alex -- To unsubscribe from this list: send the line "unsubscribe linux-wpan" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
