Hello Alexander, Glad to hear that folks are trying to implement RFC 7668.
You are right in conclusion that no u or g bit handling is required. >From RFC 7668, section 3.2.2 -- it says that one should use 48-bit BT device identification and form the 64-bit IID separated by oxFFFE. The BT identification bits are marked as 'b' in the specification and they stay unchanged. So U/L considerations are not needed. This is still following RFC 7136 method of IPv6 address formation as the 48-bit BT device identification is not the same IEEE based 48bit MAC address. Thanks, -Samita On Sat, Feb 25, 2017 at 10:25 PM, Alexander Aring <[email protected]> wrote: > > 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 <[email protected]> > >> > >> 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 > > _______________________________________________ > 6lo mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/6lo >
_______________________________________________ 6lo mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lo
