Bug 195269

Summary:	Bluetooth - 6lowpan -- RFC7668 vs. draft - IPv6 addressing
Product:	Networking	Reporter:	Benjamin A. (aignerb)
Component:	Other	Assignee:	Stephen Hemminger (stephen)
Status:	RESOLVED PATCH_ALREADY_AVAILABLE
Severity:	normal	CC:	aignerb, luiz.dentz
Priority:	P1
Hardware:	All
OS:	Linux
Kernel Version:	4.9.0-2-amd64 (Debian)	Subsystem:
Regression:	No	Bisected commit-id:

Description Benjamin A. 2017-04-06 11:37:40 UTC

Dear all,

my first bug report (hopefully :-)) for the Kernel ^^

Citing 6lowpan.c:675:

/* Universal/local bit set, BT 6lowpan draft ch. 3.2.1 */

If the address is identified as a public address, the original address byte get's a set bit at 2^1.
Otherwise, it will be deleted.
so far, so good. That works well, BUT:


the current RFC7668 does NOT state anything like that. Neither in ch. 3.2.1 or any other chapters I looked through.


Please tell me, am I wrong or is this a non-conform implementation?


Anyway, thank you very much for this rock-stable piece of software :-)

Best wishes, Benjamin

Comment 1 Luiz Von Dentz 2017-04-07 08:51:58 UTC

It is already fixed in bluetooth-next:

commit d74a94fd915d8d0f87836d281fcb1c081af495f8
Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Date:   Sun Mar 12 10:19:38 2017 +0200

    6lowpan: Fix IID format for Bluetooth
    
    According 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.
    
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Reviewed-by: Stefan Schmidt <stefan@osg.samsung.com>
    Acked-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
    Signed-off-by: Marcel Holtmann <marcel@holtmann.org>

Comment 2 Benjamin A. 2017-04-07 13:59:00 UTC

Ok, thank you very much. Sry for that mistake.

-> Resolved