Subject: Re: [6lo] Last Call: <draft-ietf-6lo-btle-13.txt> (IPv6 over BLUETOOTH(R) Low Energy) to Proposed Standard

From: "Carles Gomez Montenegro" <[email-masked]>
Date: Tue, 9 Jun 2015 13:55:03 +0200

Hi Alex,

Do you have any news on any Bluetooth SIG plans to create some version of
BLE that can be compatible with classic Bluetooth?

Since the Bluetooth protocol stack has been significantly redesigned for
Bluetooth Low Energy, these are actually two different technologies,
similar to considering IEEE 802.15.4 and IEEE 802.11. We don't expect them
to interoperate.

Best regards,

Carles

> Le 26/05/2015 14:58, The IESG a écrit :
>>
>> The IESG has received a request from the IPv6 over Networks of
>> Resource-constrained Nodes WG (6lo) to consider the following document:
>> - 'IPv6 over BLUETOOTH(R) Low Energy'
>>    <draft-ietf-6lo-btle-13.txt> as Proposed Standard
>
> Hi,
>
> BTLE is a good tech, but it is not backwards compatible - a BTLE smart
> object does not talk to a BT smartphone - you have to buy a new
> smartphone because of the BTLE devices.
>
> So I wonder whether mandatory HC in IP/BTLE does not introduce
> compatibility problems to IP (HC is optional in IP/BT)?
>
> As an end user, I would have appreciated if BTLE were compatible with BT
> in first place.
>
> If BTLE were rendered compatible with BT in the near future - will
> mandatory HC of this RFC break IP?  Or will this RFC survive unmodified
> when BTLE is made compatible to BT?
>
> (to understand this questioning compare this retro-compatibility issue
> to 802.11b, g, n, ac).
>
> Yours,
>
> Alex
>
>>
>> The IESG plans to make a decision in the next few weeks, and solicits
>> final comments on this action. Please send substantive comments to the
>> [email-masked] mailing lists by 2015-06-09. Exceptionally, comments may
>> be
>> sent to [email-masked] instead. In either case, please retain the
>> beginning of the Subject line to allow automated sorting.
>>
>> 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 file can be obtained via
>> https://datatracker.ietf.org/doc/draft-ietf-6lo-btle/
>>
>> IESG discussion can be tracked via
>> https://datatracker.ietf.org/doc/draft-ietf-6lo-btle/ballot/
>>
>>
>> No IPR declarations have been submitted directly on this I-D.
>>
>>
>> _______________________________________________
>> 6lo mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/6lo
>>
>>
>
>
> _______________________________________________
> 6lo mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6lo
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 09 Jun 2015 15:34:42 +0200

Hi Carles,

Le 09/06/2015 13:55, Carles Gomez Montenegro a écrit :
> Hi Alex,
>
> Do you have any news on any Bluetooth SIG plans to create some
> version of BLE that can be compatible with classic Bluetooth?

Unfortunately no, I have no such news.

Is there a link person here in 6lo to whom we can ask about the
future plans of BTLE at Bluetooth SIG?

> Since the Bluetooth protocol stack has been significantly redesigned
> for Bluetooth Low Energy, these are actually two different
> technologies, similar to considering IEEE 802.15.4 and IEEE 802.11.
> We don't expect them to interoperate.

Well one wouldnt expect an IP/15.4 device to talk to an IP/11 device yet
IP/15.4 is precisely the same stack as IP/11 - there are no mandatory
differences between RFC2464 and RFC4944.

What we have here is a direction in which the IP/BTLE stack becomes
different than an IP/Bluetooth stack.  The difference lies in the Header
Compression mandate.  Were it optional we'd talk compatibility.

(I am saying this after having just run pand on Bluetooth on linux,
captured packets with wireshark, and checked whether or not there's
header compression; could you please wireshark on BTLE and tell me
whether there is Header Compression?  thanks.).

Alex

>>> Resource-constrained Nodes WG (6lo) to consider the following
>>> document: - 'IPv6 over BLUETOOTH(R) Low Energy'
>> BTLE is a good tech, but it is not backwards compatible - a BTLE
>> smart object does not talk to a BT smartphone - you have to buy a
>> new smartphone because of the BTLE devices.
>>
>> As an end user, I would have appreciated if BTLE were compatible
>> with BT in first place.
>>
>>  mandatory HC of this RFC break IP?  Or will this RFC survive
>> unmodified when BTLE is made compatible to BT?
>>
>> (to understand this questioning compare this retro-compatibility
>> issue to 802.11b, g, n, ac).
>>
>> Yours,
>>
>> Alex
>>
>>>
>>> The IESG plans to make a decision in the next few weeks, and
>>> solicits final comments on this action. Please send substantive
>>> comments to the [email-masked] mailing lists by 2015-06-09.
>>> Exceptionally, comments may be sent to [email-masked] instead. In
>>> either case, please retain the beginning of the Subject line to
>>> allow automated sorting.
>>>
>>> Abstract
>>>
>>>
>>> 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.
>>>
>>>
>>>
>>>
>>> _______________________________________________ 6lo mailing list
>>>  [email-masked] https://www.ietf.org/mailman/listinfo/6lo
>>>
>>>
>>
>>
>> _______________________________________________ 6lo mailing list
>> [email-masked] https://www.ietf.org/mailman/listinfo/6lo
>>
>
>
>
>

---

From: "Carles Gomez Montenegro" <[email-masked]>
Date: Tue, 9 Jun 2015 16:32:15 +0200

Hi Alex,

> future plans of BTLE at Bluetooth SIG?

Well, I was asking my previous question since it would be very surprising
to me to find that something like what you mentioned (Bluetooth SIG
producing a BLE specification compatible with classic Bluetooth) actually
happens or is even planned.

> Compression mandate.  Were it optional we'd talk compatibility.

No: the difference is significantly greater. The solutions for IP over
Bluetooth I am aware of differ significantly in the layer(s) between IP
and L2CAP from what there is between IPv6 and L2CAP in the IPv6 over BLE
draft.

The purpose of the IPv6 over BLE draft is to allow IPv6 run over BLE.
Enabling what you suggest would be a completely different story.

And I think we should not design for something that just does not exist
and seems highly unlikely to exist in the future.

> whether there is Header Compression?  thanks.).

Well, if IPv6 over BLE has been implemented per draft-ietf-6lo-btle, then
header compression should be there.

Best regards,

Carles

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 09 Jun 2015 16:50:52 +0200

> happens or is even planned.

Ok, I understand now.

> and seems highly unlikely to exist in the future.

Indeed, if Bluetooth SIG does not plan for such things (new BTLE 
backwards compatible with Bluetooth) then it is worthless to make IP 
over some fictitious link.

In that sense yes, BTLE and Bluetooth would not interoperate and IP 
would not risk interoperability problems because of HC: IP/BT would be 
w/o HC and IP/BTLE would be w/ HC.

> header compression should be there.

Well maybe someone can tell us whether the header compression is present 
with IPv6/BTLE.

There seems to be a BTLE plugin for wireshark available:
https://lacklustre.net/bluetooth/wireshark.html

Is IPv6 running over BTLE?

Alex

---

From: "Carles Gomez Montenegro" <[email-masked]>
Date: Tue, 9 Jun 2015 17:20:53 +0200

Hi Alex,

< snip >

> Is IPv6 running over BTLE?

Yes, several companies have implemented it, including Nordic
(http://www.nordicsemi.com/eng/News/News-releases/Product-Related-News/Nordic-Semiconductor-IPv6-over-Bluetooth-Smart-protocol-stack-for-nRF51-Series-SoCs-enables-small-low-cost-ultra-low-power-Internet-of-Things-applications).

Hope this helps,

Carles

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 09 Jun 2015 17:20:39 +0200

> (http://www.nordicsemi.com/eng/News/News-releases/Product-Related-News/Nordic-Semiconductor-IPv6-over-Bluetooth-Smart-protocol-stack-for-nRF51-Series-SoCs-enables-small-low-cost-ultra-low-power-Int…

Do you have a wireshark dump?  Many companies implement many things.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 09 Jun 2015 17:44:40 +0200

> (http://www.nordicsemi.com/eng/News/News-releases/Product-Related-News/Nordic-Semiconductor-IPv6-over-Bluetooth-Smart-protocol-stack-for-nRF51-Series-SoCs-enables-small-low-cost-ultra-low-power-Int…

That announcement says "IPv6/BluetoothSmart".    Bluetooth Smart 
comprises classic Bluetooth and BTLE.

Which part is that company implementing:"IP/classicBluetooth" or 
"IP/BTLE"?  Since we agreed that these are two different things we would 
also agree these are two different concepts: "IP/classicBT" and "IP/BTLE".

For that reason, again - is there a packet dump exhibiting IPv6/BTLE w/ 
HC?  That would help clarify to me some things that may be obvious, thanks.

Alex

---

From: "Carles Gomez Montenegro" <[email-masked]>
Date: Tue, 9 Jun 2015 17:53:09 +0200

Hi Alex,

No:

>From the IPv6 over BLE draft, section 2, 1st paragraph:

   "Bluetooth Special Interest Group (Bluetooth SIG) has introduced two
   trademarks, Bluetooth Smart for single-mode devices (a device that
   only supports Bluetooth LE) and Bluetooth Smart Ready for dual-mode
   devices (devices that support both Bluetooth and Bluetooth LE).  In
   the rest of the document, the term Bluetooth LE refers to both types
   of devices."

> HC?  That would help clarify to me some things that may be obvious,

I don't have such a packet dump available, sorry.

Regards,

Carles

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 09 Jun 2015 18:32:03 +0200

>     the rest of the document, the term Bluetooth LE refers to both types

That paragraph of the document is confusing for a couple of reasons.

Is the term Bluetooth LE referring to both single-mode devices and 
dual-mode devices?  Or is it referring to both Bluetooth and to 
Bluetooth LE devices?

The second reason of confusion is that it may try to specify 
IPv6/Bluetooth behaviour which is wrong.  IPv6/Bluetooth does not use HC.

Maybe that paragraph above should be clarified.

> I don't have such a packet dump available, sorry.

Maybe we can ask a member of the 6lo group to provide us a packet dump 
of IPv6/BluetoothLE so we can understand better.

Alex

---

From: "Carles Gomez Montenegro" <[email-masked]>
Date: Tue, 9 Jun 2015 19:17:26 +0200

Hi Alex,

< snip >

> dual-mode devices?  Or is it referring to both Bluetooth and to

- A 'Bluetooth Smart' device only supports Bluetooth LE (as stated in the
paragraph).

- A 'Bluetooth Smart Ready' device has typically two different radio
interfaces (and two different upper layer protocol stacks): one of them
supports Bluetooth LE, whereas the other one supports classic Bluetooth.

> IPv6/Bluetooth behaviour which is wrong.  IPv6/Bluetooth does not use HC.

The paragraph comes after it has been clearly stated in section 1 that:

"This document specifies the details of IPv6 transmission over Bluetooth
LE links."

Nevertheless, I agree that it may not be so clear to a reader without
Bluetooth expertise that 'Bluetooth' and 'Bluetooth LE' refer to
different, non-interoperable technologies. Please see a proposal below.

> Maybe that paragraph above should be clarified.

Would the following be clearer?

NEW:
       "Bluetooth Special Interest Group (Bluetooth SIG) has introduced two
       trademarks, Bluetooth Smart for single-mode devices (a device that
       only supports Bluetooth LE) and Bluetooth Smart Ready for dual-mode
       devices (devices that support both Bluetooth and Bluetooth LE; note
       that Bluetooth and Bluetooth LE are different, non-interoperable
       radio technologies). In the rest of the document, the term Bluetooth
       LE refers to both types of devices."

< snip >

Regards,

Carles

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 10 Jun 2015 13:56:13 +0200

Hi Carles,

Le 09/06/2015 19:17, Carles Gomez Montenegro a écrit :
>>> "Bluetooth Special Interest Group (Bluetooth SIG) has introduced
>>>  two trademarks, Bluetooth Smart for single-mode devices (a
>>> device that only supports Bluetooth LE) and Bluetooth Smart Ready
>>> for dual-mode devices (devices that support both Bluetooth and
>>> Bluetooth LE).  In the rest of the document, the term Bluetooth
> - A 'Bluetooth Smart' device only supports Bluetooth LE (as stated in
> the paragraph).

Ok, a Bluetooth Smart device supports only Bluetooth LE, and Bluetooth
Smart Ready device support both BTLE and classic BT.  (I hope the
Bluetooth SIG agrees with it, because the spec Bluetooth 4.0 seems to
include BTLE).

>  interfaces

I agree it's two different technologies, but I doubt a Bluetooth Smart
Ready device has two different radio interfaces.

My recent laptop has only one Intel Wireless Bluetooth 4.0 radio
interface in the hardware list of Windows ("4.0 " means the spec that
includes text of "Low Energy"). That single interface connects to my old
logitech bluetooth 2.0 keyboard _and_ to my new fitbit flex bluetooth 4.0.

> (and two different upper layer protocol stacks): one of them supports
> Bluetooth LE, whereas the other one supports classic Bluetooth.

Ok, I assume a moment we have a computer with two interfaces: one BTLE
only, and one classic-BT.  What does look like a packet dump of IPv6 on
the BTLE only interface?  Does it include HC?

(I do have here a BTLE-only device, and with packet dumps,
  but that does not have IP).

> "This document specifies the details of IPv6 transmission over
> Bluetooth LE links."
>
> Nevertheless, I agree that it may not be so clear to a reader
> without Bluetooth expertise that 'Bluetooth' and 'Bluetooth LE' refer
> to different, non-interoperable technologies. Please see a proposal
> below.
>
> NEW: "Bluetooth Special Interest Group (Bluetooth SIG) has introduced
> two trademarks, Bluetooth Smart for single-mode devices (a device
> that only supports Bluetooth LE) and Bluetooth Smart Ready for
> dual-mode devices (devices that support both Bluetooth and Bluetooth
> LE; note that Bluetooth and Bluetooth LE are different,
> non-interoperable radio technologies). In the rest of the document,
> the term Bluetooth LE refers to both types of devices."

Thanks for a new formulation.

It clarifies that BT and BTLE are different and incompatible, it is
good.  But "devices" appears too many times and refers to different things.

And, it means that whenever the RFC says
"IPv6 REQUIRES HC over Bluetooth LE" we mean
"IPv6 REQUIRES HC over classical Bluetooth" as well.

I doubt it is the intended meaning?

Because IPv6 does not use HC over classical Bluetooth.  We dont want to 
introduce HC to devices that support only IPv6/BT and not IPv6/BTLE, 
right?  Because that would be introducing incompatibility with old 
Bluetooth devices which dont support HC.

I suggest the following text:
> Bluetooth Special Interest Group (Bluetooth SIG) has introduced two
> trademarks and logos: Bluetooth Smart for single-mode devices (a
> device that only supports Bluetooth LE) and Bluetooth Smart Ready for
> dual-mode devices (a device that supports both Bluetooth and
> Bluetooth LE; note that Bluetooth and Bluetooth LE are different,
> non-interoperable radio technologies).  In the rest of this document,
> the term Bluetooth LE refers to devices that support only Bluetooth
> LE."

Can this text lead to clarification?

Alex

---

From: "Carles Gomez Montenegro" <[email-masked]>
Date: Wed, 10 Jun 2015 16:56:18 +0200

Hi Alex,

> Bluetooth SIG agrees with it, because the spec Bluetooth 4.0 seems to

Well, it was the Bluetooth SIG that defined the 'Bluetooth Smart' and
'Bluetooth Smart Ready' terms.

> the BTLE only interface?  Does it include HC?

If the computer implements draft-ietf-6lo-btle, HC will be present in the
packets in that packet dump.

> good.  But "devices" appears too many times and refers to different

Regarding 'devices', I don't see where the actual problem is. And your
proposed new paragraph below uses 'devices' as many times as in the
paragraph above... Anyway, please find below a new proposal.

> "IPv6 REQUIRES HC over classical Bluetooth" as well.

No!

> I doubt it is the intended meaning?

No!

> Can this text lead to clarification?

No.

Focusing on the last sentence: the document describes how IPv6 runs over
Bluetooth LE interfaces. There may be devices that only support Bluetooth
LE, and devices that support both Bluetooth LE and additional 
non-Bluetooth LE interfaces.

Please find below a new proposal (see the changes in the last sentence).

NEW:
      Bluetooth Special Interest Group (Bluetooth SIG) has introduced
      two trademarks, Bluetooth Smart for single-mode devices (a device
      that only supports Bluetooth LE) and Bluetooth Smart Ready for
      dual-mode devices (devices that support both Bluetooth and Bluetooth
      LE; note that Bluetooth and Bluetooth LE are different,
      non-interoperable radio technologies). In the rest of the document,
      the term Bluetooth LE is used regardless of whether this technology
      is supported by a single-mode or dual-mode device.

(And please recall that the document states in section 1 that "This
document specifies the details of IPv6 transmission over Bluetooth LE
links". So any other technology such as 'classic Bluetooth' or others is
out of the scope of this document.)

Best regards,

Carles

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 10 Jun 2015 17:43:12 +0200

Hi Carles,

Le 10/06/2015 16:56, Carles Gomez Montenegro a écrit :
[...]
>> Ok, I assume a moment we have a computer with two interfaces: one
>> BTLE only, and one classic-BT.  What does look like a packet dump
>> of IPv6 on the BTLE only interface?  Does it include HC?
>
> If the computer implements draft-ietf-6lo-btle, HC will be present
> in the packets in that packet dump.

Is there any such packet?  I think this could hint a maturity level
worth making it an RFC.

There are good indicators making think such a packet may exist: there
are publicly available wireshark dissectors for BTLE.

But there are other indicators making think such a packet may not exist:
a local implementation of BTLE does not use IPv6 off-the-shelf, the
publicly available wireshark dissectors for BTLE dont use IPv6, BTLE is
incompatible with classical Bluetooth for which IPv6 exists, and more.

If you have any hint that such a packet may exist please post.

>> (I do have here a BTLE-only device, and with packet dumps, but
>> that does not have IP).
>>
>>> without Bluetooth expertise that 'Bluetooth' and 'Bluetooth LE'
>>> refer to different, non-interoperable technologies. Please see a
>>> proposal below.
>>>
>>> NEW: "Bluetooth Special Interest Group (Bluetooth SIG) has
>>> introduced two trademarks, Bluetooth Smart for single-mode
>>> devices (a device that only supports Bluetooth LE) and Bluetooth
>>> Smart Ready for dual-mode devices (devices that support both
>>> Bluetooth and Bluetooth LE; note that Bluetooth and Bluetooth LE
>>> are different, non-interoperable radio technologies). In the rest
>>> of the document, the term Bluetooth LE refers to both types of
>>> devices."
>>
> Regarding 'devices', I don't see where the actual problem is. And
> your proposed new paragraph below uses 'devices' as many times as in
> the paragraph above... Anyway, please find below a new proposal.
>
>> And, it means that whenever the RFC says "IPv6 REQUIRES HC over
>> Bluetooth LE" we mean "IPv6 REQUIRES HC over classical Bluetooth"
>> as well.
>
> No!

So one shouldnt be saying that "BTLE refers to both types of devices".

>> I doubt it is the intended meaning?

Ok.  I think this should be stated: "IPv6 runs ok over Bluetooth 2.0
without requiring Header Compression."

>> Because IPv6 does not use HC over classical Bluetooth.  We dont
>> want to introduce HC to devices that support only IPv6/BT and not
>> IPv6/BTLE, right?  Because that would be introducing
>> incompatibility with old Bluetooth devices which dont support HC.
>>
>>> two trademarks and logos: Bluetooth Smart for single-mode
>>> devices (a device that only supports Bluetooth LE) and Bluetooth
>>> Smart Ready for dual-mode devices (a device that supports both
>>> Bluetooth and Bluetooth LE; note that Bluetooth and Bluetooth LE
>>> are different, non-interoperable radio technologies).  In the
>>> rest of this document, the term Bluetooth LE refers to devices
>>> that support only Bluetooth LE."
>>
> Focusing on the last sentence: the document describes how IPv6 runs
> over Bluetooth LE interfaces. There may be devices that only support
> Bluetooth LE, and devices that support both Bluetooth LE and
> additional non-Bluetooth LE interfaces.
>
> NEW: Bluetooth Special Interest Group (Bluetooth SIG) has introduced

This makes more sense.

It could be further improved to say this:
> NEW: Bluetooth Special Interest Group (Bluetooth SIG) has introduced
> is supported by a single-mode or dual-mode device.  In the case IPv6
> runs on the Bluetooth mode of a dual-mode device (not on the BTLE
> mode), then the REQUIREMENTS of this document do not apply.

It sounds better to me.  What do you think?

> links". So any other technology such as 'classic Bluetooth' or others
> is out of the scope of this document.)

Ok, classic Bluetooth (Bluetooth specs 1.0 and 2.0)
are out of the scope of this document.  IPv6 runs ok on classic
Bluetooth.  It's strange though we dont have an RFC for
IPv6/Bluetooth-classic to refer to.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 10 Jun 2015 18:51:53 +0200

> BLE that can be compatible with classic Bluetooth?

Here is some news: Bluetooth 4.2 seems to be offering a procedure to 
negotiate larger data packets ("LE Data Packet Length Extension") 
(instead of currently 27 bytes).  If that materializes can it be assumed 
that Header Compression for IPv6 be less necessary when running IPv6/BTLE?

Alex

---

From: "Carles Gomez Montenegro" <[email-masked]>
Date: Thu, 11 Jun 2015 10:35:28 +0200

Hi Alex,

> incompatible with classical Bluetooth for which IPv6 exists, and more.

In this regard, you may refer to various sources, including the shepherd
writeup:
https://datatracker.ietf.org/doc/draft-ietf-6lo-btle/shepherdwriteup/.

> It sounds better to me.  What do you think?

I respectfully think that the last sentence is not necessary, since in
Section 1 the document states that "This document specifies the details of
IPv6 transmission over Bluetooth LE links".

Regards,

Carles

---

From: "Carles Gomez Montenegro" <[email-masked]>
Date: Thu, 11 Jun 2015 11:17:36 +0200

Hi Alex,

> that Header Compression for IPv6 be less necessary when running IPv6/BTLE?

Just to avoid possible confusion: those 'news' are not related with my
original question above. That is, Bluetooth 4.2 is *not* a move to making
Bluetooth LE "backwards compatible" with classic Bluetooth.

Regarding your question, you always have energy and throughput gains by
using header compression. If the involved packets are 'large', the
benefits are lower in relative terms than with 'short' packets, but there
are still benefits.

Regards,

Carles

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 11 Jun 2015 11:34:57 +0200

Hi Carles,

Yes, I respectfully exchange messages with you, and copy the list.

Please, respectfully, do not forward me outside this discussion.  I 
already make part of several discussions outside this thread on the same 
topic.

Also, when forwarding me, if absolutely necessary, please point me to 
specific phrases or paragraphs.  E.g. which part of the shepherd 
writeup, because some parts of it are wrong and I dont have time to 
discuss them.  And yes many parts of the shepherd writeup are very good 
and correct.

I _can_ spend much time to read code, exercice experiments, read packet 
dumps.

My comments are about reflecting implementation status into documents. 
If we do have deployment of IPv6/BTLE then reflect it.  If we dont have 
deployment of IPv6/BTLE then dont try to pretend it, because there are 
other competitors taking it already.

BTLE is integral part of Bluetooth 4.0 and onwards.

BTLE-only devices are incompatible with Bluetooth-only devices.

Laptops and smartphones are equipped with dual-mode interfaces which 
offer a single interface to IP.

BTLE deployments I am aware of (except one demo) dont use IP.

IPv6 is not part at all of any Bluetooth spec.

> https://datatracker.ietf.org/doc/draft-ietf-6lo-btle/shepherdwriteup/.

Which part of it.

> IPv6 transmission over Bluetooth LE links".

Ok, it can stay that way then, I can live with it that way.

Maybe I can think about writing separately an IP/Bluetooth document.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 11 Jun 2015 11:41:45 +0200

Le 11/06/2015 11:17, Carles Gomez Montenegro a écrit :
>> Here is some news: Bluetooth 4.2 seems to be offering a procedure
>> to negotiate larger data packets ("LE Data Packet Length
>> Extension") (instead of currently 27 bytes).  If that materializes
>> can it be assumed that Header Compression for IPv6 be less
>> necessary when running IPv6/BTLE?
>>
>> Alex
>
> Just to avoid possible confusion: those 'news' are not related with
> my original question above. That is, Bluetooth 4.2 is *not* a move
> to making Bluetooth LE "backwards compatible" with classic
> Bluetooth.

Ok.

But  those old news are still a potential way towards making IPv6 work
over BTLE just as it works over Bluetooth.

> Regarding your question, you always have energy and throughput gains
> by using header compression.

I doubt it is significant enough worth the effort.  Eliminating 38bytes
from a stream of hundreds of bytes can not save too much energy.

If you want to save energy then the most energy saving is by _not_ using
IP.  That is much more gain in terms of energy.

If you want to save energy at IP layer then you must consider
heterogeneous links, i.e. beyond BTLE.  If you consider heterogeneous
links then you must consider inter-operability with existing ways of IP
working on these links.  And these dont use Header Compression.

> If the involved packets are 'large', the benefits are lower in
> relative terms than with 'short' packets, but there are still
> benefits.

I think the benefits exist, maybe like 1-8 percent.  I think they are
not worth the risk of losing interoperability.

I think interoperability should come first - i.e. the capability of
getting a message through, in an end-to-end manner.  Then energy saving
should come.

Of course, energy savings are important.  But we need to think
architecturally how to fit energy savings with the existing world.  It
can't be considered alone.

Alex

---

From: "Carles Gomez Montenegro" <[email-masked]>
Date: Thu, 11 Jun 2015 12:31:53 +0200

Hi Alex,

> already make part of several discussions outside this thread on the same

I don't see in which way I was forwarding you out of the discussion... You
mentioned 'maturity', and the shepherd writeup seemed a relevant document
to reference in this regard.

> discuss them.  And yes many parts of the shepherd writeup are very good

Please refer to the 'Document Quality' part.

> other competitors taking it already.

I think we are not pretending anything...

I already provided a pointer to the implementation by Nordic.
There is also an implementation by Nokia:
https://www.researchgate.net/publication/268805783_Networking_Solutions_for_Connecting_Bluetooth_Low_Energy_Enabled_Machines_to_the_Internet_of_Things
http://wsn.aalto.fi/en/activities/workshops/wowss2012/btle_paper_aalto_wowss2012.pdf

< snip >

> Ok, it can stay that way then, I can live with it that way.

OK, thanks.

Best regards,

Carles

---

From: "Carles Gomez Montenegro" <[email-masked]>
Date: Thu, 11 Jun 2015 12:56:58 +0200

Hi Alex,

> over BTLE just as it works over Bluetooth.

No: it is just a way to extend the size of Bluetooth LE data channel PDUs,
with the purpose of achieving greater throughput in applications that may
need so and/or in any case decreasing the relative penalty of packet
overhead.

By the way, the Bluetooth 4.2 Link Layer packet format supports only up to
257-octet upper layer PDUs, so this is anyway not fulfilling the 1280-byte
MTU IPv6 requirement.

> from a stream of hundreds of bytes can not save too much energy.

IMO, 38 bytes vs 257 bytes is significant. And note that packets are not
'mandatorily large' in Bluetooth 4.2. There will still be many short IPv6
packets over Bluetooth 4.2.

> IP.  That is much more gain in terms of energy.

Two points here:

1) We want to connect devices to the Internet (thus we want IP to run on
these devices).

2) Are you arguing that the 6LoWPAN, 6Lo, 6TiSCH, CoRE, etc. work is
leading to bad design which is not energy efficient?

> working on these links.  And these dont use Header Compression.

In draft-ietf-6lo-btle we are only concerned about running IPv6 over
Bluetooth LE.

And, do you intend to say that routers with e.g. a 6LoWPAN (over 15.4)
interface and other interfaces such as Ethernet or Wifi don't work?

> not worth the risk of losing interoperability.

No: greater percent. Please see above.

> getting a message through, in an end-to-end manner.  Then energy saving

The goal of draft-ietf-6lo-btle is to allow interoperability between
devices that run IPv6 over Bluetooth LE.

> can't be considered alone.

Yes, but please: which is your specific concern (if any) regarding
draft-ietf-6lo-btle?

Regards,

Carles

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 11 Jun 2015 13:50:34 +0200

> need so and/or in any case decreasing the relative penalty of packet

There we may need IP then.

> 257-octet upper layer PDUs, so this is anyway not fulfilling the 1280-byte

This should be told to Bluetooth SIG.  Bluetooth SIG should take it as a 
requirement.  They can devise several ways of satisfying it with very 
good compromises.

IP does not necessarily need to be stripped off of its headers in order 
to satisfy that requirement.

Other SDOs did that in the past and it worked fine.

> packets over Bluetooth 4.2.

This is wrong.

One must have 1280byte sized packets in order to have IP.

There are no shorter IPv6 packets.

One may think about a hypothetical 41byte packet (base header and 1byte 
data), but that is just hypothetical.

> 1) We want to connect devices to the Internet (thus we want IP to run on

So you must conenct it in a manner that satisfies the current 
architecture of the Internet.

If you connect in a different manner then that is not a connection to 
the Internet.

> leading to bad design which is not energy efficient?

I dont understand why you conclude that way?   Are these groups 
targetting energy-efficiency?  Each seems to have different goal than 
energy efficiency (i.e. 6tisch looks at time slots, core looks at a 
disconnected webservice, etc.).

> In draft-ietf-6lo-btle we are only concerned about running IPv6 over

Ok.  I argue that IPv6/BTLE makes no sense if the Internet connection is 
not considered.

IPv6/BTLE will consume much more energy than no-IPv6.

> interface and other interfaces such as Ethernet or Wifi don't work?

No, I am not saying that, I dont udnerstand why you imply I would say so?

A router with a 6lowpan/15.4 does not necessarily _require_ HEader 
Compression - it is optional.   As a matter of fact 6lowpan/15.4 is 
optional altogether - you can have IPv6/15.4 without 6lowpan, it works.

> devices that run IPv6 over Bluetooth LE.

That is a good goal.  But it is only half of the story.  If you only 
need this half, then IP is not needed - it is a hurdle.

The document should  also have the goal to communicate packets from a 
BTLE-only device across the Internet, all the way to another BTLE-only 
device.  I should be able to ping6 a BTLE device across the Internet 
right now.

That is the Internet.

Otherwise you talk small islands of little things disconnected from each 
other and from the Internet.

> Yes, but please: which is your specific concern (if any) regarding

The concerns:
1. REQUIRE HC is way too much
2. implementation status is not mature enough
3. Bluetooth SIG specs dont talk IPv6

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 11 Jun 2015 14:18:53 +0200

Hi Carles,

Le 11/06/2015 12:31, Carles Gomez Montenegro a écrit :
>>  already make part of several discussions outside this thread on
>> the same topic.
>
> I don't see in which way I was forwarding you out of the
> discussion... You mentioned 'maturity', and the shepherd writeup
> seemed a relevant document to reference in this regard.

It is relevant and I suppose authoritative to the IESG.  Others like me 
may have a different oppinion on it.

>> Also, when forwarding me, if absolutely necessary, please point me
>> to specific phrases or paragraphs.  E.g. which part of the shepherd
>> discuss them.  And yes many parts of the shepherd writeup are very
>> good and correct.
>

HEre it is:
> As far as it is known to this Shepherd, so far it has been
> implemented by several companies (one implementation has been
> demonstrated in the hallway of the IETF 83 meeting). The authors are
> aware of several other companies that have implemented (including
> Nordic:
> http://www.nordicsemi.com/eng/News/News-releases/Product-Related-News/Nordic-Semiconductor-IPv6-over-Bluetooth-Smart-protocol-stack-for-nRF51-Series-SoCs-enables-small-low-cost-ultra-low-power-Internet-of-Things-applications
>and also in Bluez).

Can I see a packet dump from one of these companies?

Or is this data a secret between the shepherd and these companies?

If that is a secret I dont understand why there is a LAst Call sent to 
the entire IETF - I really dont care about these secrets.

>> The Bluetooth 4.1 specification and thus BT-LE itself is
>> implemented widely (e.g., in the many current phones, tablets and
>> laptops), so it is important to agree on an IP-over-foo
>> specification for this link layer.

This is not convincing to me.  It is not simply because some link layer
technology is avaialble widely that IP must run on it.

There are many link layers on which IP doesnt run and doesnt need to.
These are typically link layers dedicated to particular applications,
which dont need the power of the IP layer to route through hugely
complex networks.

We must have reasons to make IP run on it.  And these reasons must be
related to the Internet at large, not just local application-specific
connectivity.

If we take these reasons into account then we see more advantages of
connecting BTLE devices to other devices in an end-to-end manner across
wider geographical areas.

>> I _can_ spend much time to read code, exercice experiments, read
>> packet dumps.
>>
>> My comments are about reflecting implementation status into
>> documents. If we do have deployment of IPv6/BTLE then reflect it.
>> If we dont have deployment of IPv6/BTLE then dont try to pretend
>> it, because there are other competitors taking it already.
>
> I already provided a pointer to the implementation by Nordic. There
> is also an implementation by Nokia:

Again, please dont forward me outside.

But let me comment on it for the sake of conversation.

The paper does not show a packet dump.  It just says it was made to
work, but how?

The paper says :
> The  BT - LE downlink was  numbered  from the  same  /64  IPv6 -
> prefix  N9  ha d  on its cellular up link.

The addressing architecture of the protocol is very important, yes.  And 
thanks for mentioning this aspect.  But this is not right way to do IP 
architecture for such routers; this way of doint it (number from the 
same /64) is an INFORMATIONAL RFC.  Relying on INFORMATIONAL aspects as 
key... may make this document INFORMATIONAL as well?  Without this 
numbering from the same /64 the IPv6/BTLE entire mechanism can not work.

It says it modified the ND of the Nokia phone as well, presumably with 
the ARO option.  Is the ARO option in the kernel?  Packet dump of it so 
I can understand?

The paper says it modified BlueZ to make it work on BTLE.  But if so, 
are the sources accepted in the main kernel distribution?  Or is there a 
wireshark dissector for it?

The BlueZ I am using off-the-shelf runs ok over a dual-mode interface 
and does not use HC.

Alex

>>>>> NEW: Bluetooth Special Interest Group (Bluetooth SIG) has
>>>>> devices (a device that only supports Bluetooth LE) and
>>>>> Bluetooth Smart Ready for dual-mode devices (devices that
>>>>> support both Bluetooth and Bluetooth LE; note that Bluetooth
>>>>> and Bluetooth LE are different, non-interoperable radio
>>>>> technologies). In the rest of this document, the term
>>>>> Bluetooth LE is used regardless of whether this technology
>>>>> is supported by a single-mode or dual-mode device.  In the
>>>>> case IPv6 runs on the Bluetooth mode of a dual-mode device
>>>>> (not on the BTLE mode), then the REQUIREMENTS of this
>>>>> document do not apply.
>>>>
>>> I respectfully think that the last sentence is not necessary,
>>> since in Section 1 the document states that "This document
>>> specifies the details of IPv6 transmission over Bluetooth LE
>>> links".
>>

---

From: "Carles Gomez Montenegro" <[email-masked]>
Date: Thu, 11 Jun 2015 14:23:35 +0200

Hi Alex,

< snip >

> Other SDOs did that in the past and it worked fine.

Bluetooth SIG has developed the specs/functionality needed to support
draft-ietf-6lo-btle. This is how they have decided to support IPv6 over
Bluetooth LE.

> There are no shorter IPv6 packets.

Of course there are. Which is the size of an IPv6 packet carrying a TCP
ACK? Which is the size of an IPv6 packet carrying a CoAP message without
payload?

> If you connect in a different manner then that is not a connection to

In what way does draft-ietf-6lo-btle not satisfy the current architecture
of the Internet?

Do you imply that 6LoWPAN (e.g. over IEEE 802.15.4) breaks the current
architecture of the Internet?

> disconnected webservice, etc.).

All constrained node network space IETF WGs take into consideration the
constraints of the devices (and networks) involved. An outstanding
constraint in this space is energy/power limitations.

> Ok.  I argue that IPv6/BTLE makes no sense if the Internet connection is

It is of course considered. We are concerned with the adaptation of IPv6
over Bluetooth LE links. That's all!

> IPv6/BTLE will consume much more energy than no-IPv6.

Even if that were true (do you have data to support such a statement?) the
IETF consensus is that the best way to connect constrained (C1/C2) devices
 to the Internet is by running IPv6 on these devices.

> No, I am not saying that, I dont udnerstand why you imply I would say so?

Please see your own last e-mail:

"> So you must conenct it in a manner that satisfies the current
> the Internet."

> optional altogether - you can have IPv6/15.4 without 6lowpan, it works.

Even if HC is optional in 6lowpan/15.4, IPv6 packets over those 15.4 links
use the formats specified in RFC 4944/6282. Do you think that "breaks the
Internet architecture"?

> device.  I should be able to ping6 a BTLE device across the Internet

Of course draft-ietf-6lo-btle allows to do so:
https://tools.ietf.org/html/draft-ietf-6lo-btle-13#page-12

> 1. REQUIRE HC is way too much

First of all, this has been WG consensus.

Second, Bluetooth 4.0 and 4.1 are widely deployed, and have that 27-byte
PDU limitation. HC becomes a MUST.

Bluetooth 4.2 allows to avoid fragmentation for greater sized packets, but
HC is still giving significant benefits.

Apparently, you think that mandating HC breaks the Internet architecture.
But it does not.

> 2. implementation status is not mature enough

This is your opinion, but it is not aligned with WG consensus.

> 3. Bluetooth SIG specs dont talk IPv6

Do e.g. 15.4 specs talk IPv6? Does the G.9959 spec talk IPv6?

Regards,

Carles

---

From: "Carles Gomez Montenegro" <[email-masked]>
Date: Thu, 11 Jun 2015 14:30:42 +0200

Hi Alex,

- Bluetooth LE devices are (expected to be) counted in billions. We are
trying to provide the way to connect them to the Internet.

- I give you references of implementations, since you ask about them.

Regards,

Carles

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 11 Jun 2015 15:04:55 +0200

Le 11/06/2015 14:23, Carles Gomez Montenegro a écrit :
> Hi Alex,
>
> < snip >
>
>>> By the way, the Bluetooth 4.2 Link Layer packet format supports
>>> only up to 257-octet upper layer PDUs, so this is anyway not
>>> fulfilling the 1280-byte MTU IPv6 requirement.
>>
>> This should be told to Bluetooth SIG.  Bluetooth SIG should take it
>> as a requirement.  They can devise several ways of satisfying it
>> with very good compromises.
>>
>> IP does not necessarily need to be stripped off of its headers in
>> order to satisfy that requirement.
>>
> Bluetooth SIG has developed the specs/functionality needed to
> support draft-ietf-6lo-btle.

Well I dont think so.  What is the EtherType in BTLE headers when 
carrying IPv6?

Where is the BTLE functionality specified at BT SIG (specs/functionality
for supporting IPv6)?  I dont find it, I looked at 4.0, 4.1 and 4.2 and
searched for "IPv6".

What is the adaptation layer between a BTLE MAC header and an EthernetII
MAC header?

All other links provided such an adaptation layer.

>>>>> Regarding your question, you always have energy and
>>>>> throughput gains by using header compression.
>>>>
>>>> I doubt it is significant enough worth the effort. Eliminating
>>>>  38bytes from a stream of hundreds of bytes can not save too
>>>> much energy.
>>>
>>> IMO, 38 bytes vs 257 bytes is significant. And note that packets
>>>  are not 'mandatorily large' in Bluetooth 4.2. There will still
>>> be many short IPv6 packets over Bluetooth 4.2.
>>
>> This is wrong.
>>
> Of course there are.

I thought from the standpoint of the IPv6 stack the minimal MTU is
1280bytes.

> Which is the size of an IPv6 packet carrying a TCP ACK?

I dont know... does this TCP ACK contain the original data being ack'ed?
(like an ICMP err message would).

> Which is the size of an IPv6 packet carrying a CoAP message without
> payload?

40bytes plus the CoAP header which is an UDP header(?)

CoAP protocol (as another discussion) has another drawback - it mandates 
the server to run on a gateway; it thus makes it impossible to run on 
the sensor.  Or the sensors should be able to run servers by themselves.

>> One may think about a hypothetical 41byte packet (base header and
>> 1byte data), but that is just hypothetical.
>>
>>>> If you want to save energy then the most energy saving is by
>>>> _not_ using IP.  That is much more gain in terms of energy.
>>>
>>> Two points here:
>>>
>>> 1) We want to connect devices to the Internet (thus we want IP to
>>> run on these devices).
>>
>> If you connect in a different manner then that is not a connection
>>  to the Internet.
>
> In what way does draft-ietf-6lo-btle not satisfy the current

I would not put it that broad, but in a sense yes.

In the current Internet everyone can talk to other.  But an IPv6/BTLE
node as per this document can not talk to an IPv6/BT in the same subnet,
because of that HC.

Without talking HC: IP can not solve a link layer problem.

The fact that interfaces are declared both BT and BTLE, yet BT and BTLE 
are incompatible is a huge link layer problem.  But it is not IP's problem.

IP can connect together heterogeneous links by means of routing.  These 
means are specified, exist.  Yet IPv6/BTLE does not want to talk 
Bluetooth-classic.

> Do you imply that 6LoWPAN (e.g. over IEEE 802.15.4)

6lowpan is not 802.15.4.  IPv6 runs over 15.4 w/o 6lowpan. (just as in
BT and BTLE: BTLE is not BT, and IPv6 runs ok over BT w/o HC).

> breaks the current architecture of the Internet?

I imply that 6lowpan is an adaptation layer that is not adapting things
as it is need by IP.  Other adaptation layers do its job such that IP 
runs over these links in a very simple and straighforward manner.

>>> 2) Are you arguing that the 6LoWPAN, 6Lo, 6TiSCH, CoRE, etc. work
>>> is leading to bad design which is not energy efficient?
>>
>> targetting energy-efficiency?  Each seems to have different goal
>> than energy efficiency (i.e. 6tisch looks at time slots, core looks
>> at a disconnected webservice, etc.).
>
> All constrained node network space IETF WGs take into consideration
> the constraints of the devices (and networks) involved.

That is your view.

> An outstanding constraint in this space is energy/power limitations.

Well, that is your view again.

The energy "limitations" depend where you look from.  Looked at from
some IP perspective there is no energy limitation.

A watch is limited in energy, yes, (run on CR2032), but it is so limited
that it does not run IP.  It does not need it, and IP is a hurdle for
it: operators dont give a /63 to a smartphone, and IETF doesnt allow
shorter IIDs than 64.

For that reason - everyone is happy with current situation: energy
limitation?  No need of IP.  IP is not a panacea where a bigger battery
would do the trick.

>>>> heterogeneous links, i.e. beyond BTLE.  If you consider
>>>> heterogeneous links then you must consider inter-operability
>>>> with existing ways of IP working on these links.  And these
>>>> dont use Header Compression.
>>>
>>> In draft-ietf-6lo-btle we are only concerned about running IPv6
>>> over Bluetooth LE.
>>
>> Ok.  I argue that IPv6/BTLE makes no sense if the Internet
>> connection is not considered.
>
> It is of course considered. We are concerned with the adaptation of
> IPv6 over Bluetooth LE links. That's all!

Ok, if the concern is there, let me express my own concern not being
able to ping6 across the Internet an IPv6/BTLE device.  Can you?

> Even if that were true (do you have data to support such a
> statement?)

1280byte packets are larger than 27byte.  It takes about 10nJoules per
1280byte on Bluetooth.

> the IETF consensus is that the best way to connect constrained
> (C1/C2) devices to the Internet is by running IPv6 on these devices.

Either it is a wrong consensus, or we dont talk about the same IPv6.

>>> And, do you intend to say that routers with e.g. a 6LoWPAN (over
>>>  15.4) interface and other interfaces such as Ethernet or Wifi
>>> don't work?
>>
>> If you connect in a different manner then that is not a connection
>>  to the Internet."
>
> Even if HC is optional in 6lowpan/15.4, IPv6 packets over those 15.4
>  links use the formats specified in RFC 4944/6282. Do you think that
>  "breaks the Internet architecture"?

RFC4944 format is ok, under a certain intepretation of options.  These 
options do not include 6lowpan nor HC.

>>>>> If the involved packets are 'large', the benefits are lower
>>>>> in relative terms than with 'short' packets, but there are
>>>>> still benefits.
>>>>
>>>> I think the benefits exist, maybe like 1-8 percent.  I think
>>>> they are not worth the risk of losing interoperability.
>>>
>>>> I think interoperability should come first - i.e. the
>>>> capability of getting a message through, in an end-to-end
>>>> manner.  Then energy saving should come.
>>>
>>> The goal of draft-ietf-6lo-btle is to allow interoperability
>>> between devices that run IPv6 over Bluetooth LE.
>>
>> That is a good goal.  But it is only half of the story.  If you
>> only need this half, then IP is not needed - it is a hurdle.
>>
>> The document should  also have the goal to communicate packets from
>> a BTLE-only device across the Internet, all the way to another
>> BTLE-only device.  I should be able to ping6 a BTLE device across
>> the Internet right now.
>

Can I ping6 an IPv6/BTLE from here now?

>
>> That is the Internet.
>>
>> Otherwise you talk small islands of little things disconnected from
>> each other and from the Internet.
>>
>>>> architecturally how to fit energy savings with the existing
>>>> world.  It can't be considered alone.
>>>
>>> Yes, but please: which is your specific concern (if any)
>>> regarding draft-ietf-6lo-btle?
>>
>> The concerns: 1. REQUIRE HC is way too much
>

You are free to declare consensus if you feel so.

> Second, Bluetooth 4.0 and 4.1 are widely deployed, and have that
> 27-byte PDU limitation. HC becomes a MUST.

That is wrong.  Before designing HC has one told the PDU limitation 
designers to fragment/reassemble?

Why other link designers can frag/reass and BTLE cant?

> Bluetooth 4.2 allows to avoid fragmentation for greater sized
> packets, but HC is still giving significant benefits.

I think you may be talking about HC at link layer, not HC at IP layer.

> Apparently, you think that mandating HC breaks the Internet
> architecture. But it does not.

This is your conclusion.

On one hand I dont state HC breaks the Internet architecture.

But I state HC has been designed before for cellular links and it was 
got ridden of later.  Then for WiFi again, then lost.  There are RFCs 
for that non-BTLE HC.

I also state that HC breaks end-to-end security, breaks end-to-end 
bidirectional reachability, breaks interoperability, and more.

> This is your opinion, but it is not aligned with WG consensus.

Again, declare consensus if you wish.

But I thought we are in an open environment in which we can look at 
packet dumps freely.

> Do e.g. 15.4 specs talk IPv6? Does the G.9959 spec talk IPv6?

15.4 offers same MAC as .11, so yes, it does talk IPv6.
Also .11p talks IPv6. It's really built in.

G.9959 are secret, so I cant say whether or not it talks IPv6 support.

Many ETSI ITS specs talk specifically IPv6, although not always in the 
right terms.

Lack of "IPv6" talk in Bluetooth SIG specs is worrying, despite the fact 
that IPv6 runs ok on Bluetooth-classic.

Is the Bluetooth SIG caring about IPv6 or is IETF pushing some spec onto 
them?

Alex

>
> Regards,
>
> Carles
>
>
>> Alex
>>
>>>
>>> Regards,
>>>
>>> Carles
>>>
>>>> Alex
>>>>
>>>>
>>>>>
>>>>> Regards,
>>>>>
>>>>> Carles
>>>>>
>>>>>
>>>>>
>>>>
>>>> _______________________________________________ 6lo mailing
>>>> list [email-masked] https://www.ietf.org/mailman/listinfo/6lo
>>>>
>>>
>>>
>>>
>>>
>>

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 11 Jun 2015 15:16:59 +0200

Le 11/06/2015 14:30, Carles Gomez Montenegro a écrit :
> Hi Alex,
>
> - Bluetooth LE devices are (expected to be) counted in billions.

Good for them.

The entire IoT space is rated at between 20 to 80 billion devices to
year 2020.

> We are trying to provide the way to connect them to the Internet.

I think you want to "connect" them to the Internet in the same way that
my fitbit flex dumps its data through a protocol gateway.

That is not IP, although you seem keen on making it carry an "IP" label.

> - I give you references of implementations, since you ask about

I asked packet dumps to understand.  I didnt ask implementations.

What you provided is something that a Google search can provide as well.

Alex

>>>> Please, respectfully, do not forward me outside this
>>>> discussion. I already make part of several discussions outside
>>>> this thread on the same topic.
>>>
>> It is relevant and I suppose authoritative to the IESG.  Others
>> like me may have a different oppinion on it.
>>
>>>> Also, when forwarding me, if absolutely necessary, please
>>>> point me to specific phrases or paragraphs.  E.g. which part of
>>>> the shepherd writeup, because some parts of it are wrong and I
>>>> dont have time to discuss them.  And yes many parts of the
>>>> shepherd writeup are very good and correct.
>>>
>>> demonstrated in the hallway of the IETF 83 meeting). The authors
>>> are aware of several other companies that have implemented
>>> (including Nordic:
and also in Bluez).
>> If that is a secret I dont understand why there is a LAst Call
>> sent to the entire IETF - I really dont care about these secrets.
>>
>>>> implemented widely (e.g., in the many current phones, tablets
>>>> and laptops), so it is important to agree on an IP-over-foo
>> This is not convincing to me.  It is not simply because some link
>> layer technology is avaialble widely that IP must run on it.
>>
>> There are many link layers on which IP doesnt run and doesnt need
>> to. These are typically link layers dedicated to particular
>> applications, which dont need the power of the IP layer to route
>> through hugely complex networks.
>>
>> We must have reasons to make IP run on it.  And these reasons must
>> be related to the Internet at large, not just local
>> application-specific connectivity.
>>
>> If we take these reasons into account then we see more advantages
>> of connecting BTLE devices to other devices in an end-to-end
>> manner across wider geographical areas.
>>
>>>> I _can_ spend much time to read code, exercice experiments,
>>>> read packet dumps.
>>>>
>>>> documents. If we do have deployment of IPv6/BTLE then reflect
>>>> it. If we dont have deployment of IPv6/BTLE then dont try to
>>>> pretend it, because there are other competitors taking it
>>>> already.
>>>
>> The addressing architecture of the protocol is very important,
>> yes. And thanks for mentioning this aspect.  But this is not right
>> way to do IP architecture for such routers; this way of doint it
>> (number from the same /64) is an INFORMATIONAL RFC.  Relying on
>> INFORMATIONAL aspects as key... may make this document
>> INFORMATIONAL as well?  Without this numbering from the same /64
>> the IPv6/BTLE entire mechanism can not work.
>>
>> It says it modified the ND of the Nokia phone as well, presumably
>> with the ARO option.  Is the ARO option in the kernel?  Packet
>> dump of it so I can understand?
>>
>> The paper says it modified BlueZ to make it work on BTLE.  But if
>> so, are the sources accepted in the main kernel distribution?  Or
>> is there a wireshark dissector for it?
>>
>> The BlueZ I am using off-the-shelf runs ok over a dual-mode
>> interface and does not use HC.
>>
>> Alex
>>
>>
>>>
>>> < snip >
>>>
>>>>>>> introduced two trademarks, Bluetooth Smart for
>>>>>>> single-mode devices (a device that only supports
>>>>>>> Bluetooth LE) and Bluetooth Smart Ready for dual-mode
>>>>>>> devices (devices that support both Bluetooth and
>>>>>>> Bluetooth LE; note that Bluetooth and Bluetooth LE are
>>>>>>> different, non-interoperable radio technologies). In the
>>>>>>> rest of this document, the term Bluetooth LE is used
>>>>>>> regardless of whether this technology is supported by a
>>>>>>> single-mode or dual-mode device.  In the case IPv6 runs
>>>>>>> on the Bluetooth mode of a dual-mode device (not on the
>>>>>>> BTLE mode), then the REQUIREMENTS of this document do
>>>>>>> not apply.
>>>>>>