Subject: [6lo] I-D Action: draft-ietf-6lo-btle-06.txt

From: [email-masked]
Date: Fri, 09 Jan 2015 11:07:23 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the IPv6 over Networks of Resource-constrained Nodes Working Group of the IETF.

        Title           : Transmission of IPv6 Packets over BLUETOOTH(R) Low Energy
        Authors         : Johanna Nieminen
                          Teemu Savolainen
                          Markus Isomaki
                          Basavaraj Patil
                          Zach Shelby
                          Carles Gomez
	Filename        : draft-ietf-6lo-btle-06.txt
	Pages           : 17
	Date            : 2015-01-09

Abstract:
   Bluetooth Smart is the brand name for the Bluetooth low energy
   feature in the Bluetooth specification defined by the Bluetooth
   Special Interest Group.  The standard Bluetooth radio has been widely
   implemented and available in mobile phones, notebook computers, audio
   headsets and many other devices.  The low power version of Bluetooth
   is a specification that enables the use of this air interface with
   devices such as sensors, smart meters, appliances, etc.  The low
   power variant of Bluetooth is standardized since the revision 4.0 of
   the Bluetooth specifications, although version 4.1 or newer is
   required for IPv6.  This document describes how IPv6 is transported
   over Bluetooth low energy using 6LoWPAN techniques.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-6lo-btle/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-6lo-btle-06

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-6lo-btle-06

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 10 Jan 2015 08:05:22 +0100

Hi Teemu,

thanks for these updates.

Strictly speaking, the 6LN registers IPv6 addresses, not IIDs, with the 
6LBR; I like that aspect of the -04 wording better.  I'm still trying to 
wrap my head around the condition for being able to elide the IID part 
of an address -- as described in 3.2.3, it is that multiple addresses 
weren't registered for a prefix, but it is not quite clear to me how 6LN 
and 6LBR agree that this is indeed the case (ARO makes sure an address 
is registered, but how do we make sure no other address is still 
registered?).

Maybe it is also worth pointing out that the procedure described in 
section 3.2.2 (inverting U/L as per appendix A of RFC 4291) is also 
replaced by the procedures described here -- I'm not sure every 
implementer will infer that.

Grüße, Carsten

---

From: <[email-masked]>
Date: Sat, 10 Jan 2015 09:45:51 +0000

Hi Carsten,

Right, I had forgotten the RFC6775 sentence:" the address that is to be registered MUST be the IPv6 source address of the NS message". 

In the RFC6282 with SAC=1, DAM=11 the idea is to derive address from context and link-layer address. This would work nicely if addresses were based on Bluetooth Device Address. However, with random IIDs eliding the IID becomes more challenging. The idea here is that if a node has registered only one IPv6 address for a prefix, and there's compression context for the prefix, the address could be fully elided as both 6LN and 6LBR would know from the context information that it is this one address that has been elided. When multiple addresses would be configured for the same prefix, then the IID part would need to be transmitted inline (and prefix bits would come from context information).

I guess if 6LBR would have two address registrations for a 6LN and the 6LN for some reason would think it has only one, the 6LN might elide its address and then 6LBR would have problem decompressing.. But I'm not sure how this situation could arise, as device reboots/Bluetooth disconnections should clear related state on both entities, and registration timeouts clear extra entries from 6LBR.

So attempting to elide random IID definitely increases complexity. If we'd decide that random IIDs shall be always carrier inline, we'd get simpler solution.. but with more bits transmitted with each packet. Implementations would then made tradeoff between compression efficiency and privacy (if using static BDADDR). We could also force just one address registration per prefix, which would support random IIDs and avoid synchronization problems due 6LBR refusing to register multiple addresses for the same prefix from the same host.. 

Next proposal for the text:
	 1.  A Bluetooth LE 6LN SHOULD NOT register its 
	 link-local address. A Bluetooth LE 6LN MUST register its non-link-local addresses
   	 with the 6LBR by sending a Neighbor Solicitation (NS) message with
    	 the Address Registration Option (ARO) and process the Neighbor
     	 Advertisement (NA) accordingly.  The NS with the ARO option MUST be
    	 sent irrespective of the method used to generate the IID.  If the 6LN
    	 registers multiple addresses per compression context, the 6LN 
	 and 6LBR will have to send IID bits inline as in that case there is not enough
 	information available for computing back an elided IID.

I thought we should not discuss about semantics of IID:) So would this text be clearer:
--
of 0xFF and 0xFE in the middle of the 48-bit Bluetooth device address as shown in Figure 4.  In the Figure letter 'b' represents a bit from Bluetooth device address, copied as is without any changes on any bit.
--

Best regards,

	Teemu

-----Original Message-----
From: 6lo [mailto:[email-masked]] On Behalf Of ext Carsten Bormann
Sent: 10. tammikuuta 2015 9:05
To: [email-masked]
Subject: Re: [6lo] I-D Action: draft-ietf-6lo-btle-06.txt

Hi Teemu,

Strictly speaking, the 6LN registers IPv6 addresses, not IIDs, with the 6LBR; I like that aspect of the -04 wording better.  I'm still trying to wrap my head around the condition for being able to elide the IID part of an address -- as described in 3.2.3, it is that multiple addresses weren't registered for a prefix, but it is not quite clear to me how 6LN and 6LBR agree that this is indeed the case (ARO makes sure an address is registered, but how do we make sure no other address is still registered?).

Maybe it is also worth pointing out that the procedure described in section 3.2.2 (inverting U/L as per appendix A of RFC 4291) is also replaced by the procedures described here -- I'm not sure every implementer will infer that.

Grüße, Carsten

_______________________________________________
6lo mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/6lo

---

From: <[email-masked]>
Date: Fri, 16 Jan 2015 08:57:16 +0000

Carsten,

I just posted -07 with updates to these points (but slightly different updates than what I proposed below).

Teemu

-----Original Message-----
From: 6lo [mailto:[email-masked]] On Behalf Of ext [email-masked]
Sent: 10. tammikuuta 2015 11:46
To: [email-masked]; [email-masked]
Subject: Re: [6lo] I-D Action: draft-ietf-6lo-btle-06.txt

Hi Carsten,

Best regards,

	Teemu

-----Original Message-----
From: 6lo [mailto:[email-masked]] On Behalf Of ext Carsten Bormann
Sent: 10. tammikuuta 2015 9:05
To: [email-masked]
Subject: Re: [6lo] I-D Action: draft-ietf-6lo-btle-06.txt

Hi Teemu,

Grüße, Carsten