[6lowpan] Noteworthy changes in draft-ietf-6lowpan-btle-11.txt

[<[e-mail]>]

Hi,



We just posted draft-ietf-6lowpan-btle-11.txt that contains both changes based on the feedback from IESG, but also changes based on the feedback by Marcel De Kogel. Marcel has implemented the draft and found some issues during his work.



Please check out the changes and comment if not OK.



Revision: http://www.ietf.org/internet-drafts/draft-ietf-6lowpan-btle-11.txt

Diff: http://www.ietf.org/rfcdiff?url2=draft-ietf-6lowpan-btle-11



The summary of changes based on _Marcel's findings_ are listed below (I hope I didn't miss any). IESG's comments (DISCUSSes) are visible in the tracker.



1) BT-LE device addressing: it is now clarified that the BT-LE address may not be globally unique like the MAC in typical interface cards is. The BT-LE address may also be randomly generated (once in first boot, or more often per BT-LE device lifetime). This requires that the IID generated from the random BT-LE address to have Universal/Local bit set to zero. This caused changes to section 2.3 (description of addressing), 3.2 (note that IID can be inferred from Neighbor Cache with device address), and 3.2.1 (Universal/Local bit).



2) The L2CAP channel characteristics were too unclear, and are now clarified in the section 3.2.



3) 3.2 had a bug: it said in rev -10 "IID derived directly from the 48-bit Bluetooth Device addresses", which was wrong because in case of privacy addresses there was no way to derive IID from 48-bit Bluetooth Device address. Instead we need to say:"the IID value inferred, with help of Neighbor Cache, from the link-layer address".



4) We were missing text related to communications between nodes in the BT-LE piconet. We had to clarify in section 3.2 and 3.2.4 that the BT-LE slaves cannot directly talk to each other with link-local addresses. i.e. that in the star topology each branch is individual link, even if they share the /64 prefix. That also causes that the PIO option in RA must have on-link flag bit 'L' set to zero. This is updated into section 3.2.1. Due the lack of means for BT-LE slaves to talk to each other with link-local addresses, the piconet needs to be numbered with ULA if BT-LE slave-to-slave communications are needed and global addresses are not present (text added to 3.2.4).



Best regards,



Teemu