Subject: [6lo] We need IPv6 over BTLE packet dumps, please

From: Carsten Bormann <[email-masked]>
Date: Thu, 11 Jun 2015 15:38:21 +0200

>> 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.

Alex,

I think you are confusing gateways (in today's parlance) with routers here.
All routers need an adaptation layer to translate IP to the specific MAC
layer packets being used.  This translation may be very simple
encapsulation, as with Ethernet, or something more complicated may be
going on.  All the Internet is not Ethernet.  In 6LoWPAN networks,
encapsulation often involves fragmentation (not needed for BTLE as BTLE
provides its own segmentation and reassembly) and always some form of
header compression.  The latter is a good idea because power usage is
highly dependent on physical layer packet length and because the
combined IPv6 and UDP headers weigh in at 48 bytes, which is often more
than the payloads that we want to transport for IoT applications.

Historically, routers have been called gateways.  That is no longer the
language we use in modern discourse.  We now use the term gateway for
protocol translating entities, which typically need to have some
application layer knowledge (via configuration or dynamic setup) to do
their job.  Gateways are bad because they are complex, they need to be
replaced when application layers change or just a new application needs
to be deployed, and are generally in the way of deploying applications.

No gateways are needed for IPv6 over BTLE.  This enables integrating
Internet applications on BTLE nodes without needing to configure or
setup intermediate gateways.  Very different from your fitbit example.

> I asked packet dumps to understand.  

I agree that having some packet dumps would be very useful.
May I remind people that there is a repository of 6LoWPAN packet dumps at

	http://svn.tools.ietf.org/svn/wg/6lowpan/packets

Getting some pcaps (or any other form of packet dumps) from a live IPv6
over BTLE implementation would be a very useful contribution here.

Maybe we should more systematically bug the authors of the other 6lo
drafts to contribute packet dumps?

Grüße, Carsten

---

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

Hi Carsten,

Thanks for your reply.  I take it as support in my quest for packet
dumps of IPv6/BTLE.

I have some comments below, but that is outside the request.

Le 11/06/2015 15:38, Carsten Bormann a écrit :
>> 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.
>>
> I think you are confusing gateways (in today's parlance) with routers
> here. All routers need an adaptation layer to translate IP to the
> specific MAC layer packets being used.  This translation may be very
> simple encapsulation, as with Ethernet, or something more complicated
> may be going on.

I agree.  But the more these things are complicated the less likely
they are to be adopted at an IP layer which must stay simple.

> All the Internet is not Ethernet.

I agree in a sense.

All Internet is not Ethernet _cables_ but 99% of the IPv6 Internet is
IPv6/Ethernet RFC2464 and the imitating IPv6-over-foo RFCs.

A big chunk of the 1% left is point-to-point links.

And then there are of course many IP links which are disconnected from
the Internet and which run IP in very different ways than IP on the
Internet.  They will never be connected to the Internet.

> In 6LoWPAN networks, encapsulation often involves fragmentation (not
>  needed for BTLE as BTLE provides its own segmentation and
> reassembly) and always some form of header compression.  The latter
> is a good idea because power usage is highly dependent on physical
> layer packet length and because the combined IPv6 and UDP headers
> weigh in at 48 bytes, which is often more than the payloads that we
> want to transport for IoT applications.

This mixes in high-level concepts which are disjoint.

For one, these links will be happier if IP is not on them, because IP 
consumes a lot.

Most marketed IoT applications are actually simply two segments: a
non-IP link plus an IP link from the bigger computer to a server.

The plethora of IoT devices arriving on market dont run IP and dont need
IP.  The cellular network operators dont allow for this "IPv6 through a
smartphone" either.

Certainly there can be hypothetical applications which may need to
have IP in the end node, direct Thing-to-Thing communications, secure
e2e, server in the Thing, and more.  But HC and 6lowpan are not enabling
that either, simply because they are not any more "end-to-end" than the
deployed Things using nonIP-plus-IP segments.  HC and 6lowpan actually
continue this tendency of two linked incompatible segments, which break
end-to-end.

> Historically, routers have been called gateways.  That is no longer
> the language we use in modern discourse.
>
> We now use the term gateway for protocol translating entities, which
> typically need to have some application layer knowledge (via
> configuration or dynamic setup) to do their job.  Gateways are bad
> because they are complex, they need to be replaced when application
> layers change or just a new application needs to be deployed, and
> are generally in the way of deploying applications.
>
> No gateways are needed for IPv6 over BTLE.

If no gateways are between me and an IPv6/BTLE device why can't I ping6 one?

> This enables integrating Internet applications on BTLE nodes without
> needing to configure or setup intermediate gateways.

That is a good goal, but I think it is only on paper, sorry if I sound 
provoking.

>   Very different from your fitbit example.

I agree if it were so.

> I agree that having some packet dumps would be very useful. May I
> remind people that there is a repository of 6LoWPAN packet dumps at
>

I checked them all.  All are running on Ethernet II.

Would IPv6/BTLE packets also be on Ethernet II?  Would they also exhibit 
an 6lowpan intermediary header?  (because IPv6/BT doesnt).

I still look for packet dumps IPv6/BTLE.

> Getting some pcaps (or any other form of packet dumps) from a live
> IPv6 over BTLE implementation would be a very useful contribution
> here.
>

Bugging them - not necessarily, but talk to them about it.  If they 
provide one here then many people will see it - companies, universities, 
stds participants.

Alex

---

From: Gabriel Montenegro <[email-masked]>
Date: Thu, 11 Jun 2015 17:21:06 +0000

Folks,

I think this has gone off the track into new requirements for publications of RFC's and advice on how link layers should be designed. I think whatever clarifying text that could be added was already suggested (although I'd leave it to the authors for the final form), but beyond that I don't see much constructive discussion going on. 

Could the authors prepare a new revision incorporating latest comments so we can move on and continue with IESG processing?

Thanks,

Gabriel

> -----Original Message-----
> From: 6lo [mailto:[email-masked]] On Behalf Of Alexandru Petrescu
> Sent: Thursday, June 11, 2015 8:34
> To: Carsten Bormann
> Cc: Carles Gomez Montenegro; [email-masked]
> Subject: Re: [6lo] We need IPv6 over BTLE packet dumps, please
> 
> Hi Carsten,
> 
> _______________________________________________
> 6lo mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6lo

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 11 Jun 2015 19:33:24 +0200

Gabriel,

With all due respect.

I think we agreed with Carles on a very short possible text improvement. 
  I will let them decide and I can live with it.

On another hand, I strongly disagree about lack of constructive discussion.

I think BT and BTLE are incompatible technologies and further IPv6 in 
the picture may only make it worse.

Maybe I doubt also about the proposed track: Standards Track.  I would 
rather see this on the EXPERIMENTAL track.

Maybe I doubt about some parts in the shepherd writeup as well.  The 
write up may be misleading in some parts and may mislead decision makers.

For example, the writeup says:
> The low power variant of Bluetooth is commonly specified in revision
> 4.0 of the Bluetooth specifications and commonly referred to as
> Bluetooth 4.0.

This may make think that BTLE is commonly referred to as Bluetooth 4.0. 
  Or, it is not the case.  Bluetooth 4.0 also includes Bluetooth 
classic.  And IPv6 runs ok on Bluetooth classic.  IPv6 runs ok on 
Bluetooth 4.0 w/o this RFC.

Saying what is written above ("commonly referred to"), may make think 
that this RFC (IPv6 over BTLE) is needed in order to make IPv6 over 
Bluetooth 4.0.  Or, that may not be the case.

I guess the writeup can not be changed at this point, but I still think 
it may be misleading to decision making.

> This document describes how IPv6 is transported over
> Bluetooth Low Energy 4.1 using 6LoWPAN techniques.

I think there is no BTLE 4.1.  There is either Bluetooth 4.1, or BTLE 
part of Bluetooth 4.1.

Alex

Le 11/06/2015 19:21, Gabriel Montenegro a écrit :
> Folks,
>
> I think this has gone off the track into new requirements for
> publications of RFC's and advice on how link layers should be
> designed. I think whatever clarifying text that could be added was
> already suggested (although I'd leave it to the authors for the final
> form), but beyond that I don't see much constructive discussion going
> on.
>
> Could the authors prepare a new revision incorporating latest
> comments so we can move on and continue with IESG processing?
>
> Thanks,
>
> Gabriel
>
>> -----Original Message----- From: 6lo [mailto:[email-masked]]
>> On Behalf Of Alexandru Petrescu Sent: Thursday, June 11, 2015 8:34
>> To: Carsten Bormann Cc: Carles Gomez Montenegro; [email-masked]
>> Thanks for your reply.  I take it as support in my quest for
>> packet dumps of IPv6/BTLE.
>>
>>>> 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.
>>>>
>>> I think you are confusing gateways (in today's parlance) with
>>> routers here. All routers need an adaptation layer to translate
>>> IP to the specific MAC layer packets being used.  This
>>> translation may be very simple encapsulation, as with Ethernet,
>>> or something more complicated may be going on.
>>
>> I agree.  But the more these things are complicated the less
>> likely they are to be adopted at an IP layer which must stay
>> simple.
>>
>> All Internet is not Ethernet _cables_ but 99% of the IPv6 Internet
>> is IPv6/Ethernet RFC2464 and the imitating IPv6-over-foo RFCs.
>>
>> And then there are of course many IP links which are disconnected
>> from the Internet and which run IP in very different ways than IP
>> on the Internet.  They will never be connected to the Internet.
>>
>>> In 6LoWPAN networks, encapsulation often involves fragmentation
>>> (not needed for BTLE as BTLE provides its own segmentation and
>>> reassembly) and always some form of header compression.  The
>>> latter is a good idea because power usage is highly dependent on
>>> physical layer packet length and because the combined IPv6 and
>>> UDP headers weigh in at 48 bytes, which is often more than the
>>> payloads that we want to transport for IoT applications.
>>
>> For one, these links will be happier if IP is not on them, because
>> IP consumes a lot.
>>
>> The plethora of IoT devices arriving on market dont run IP and dont
>> need IP.  The cellular network operators dont allow for this "IPv6
>> through a smartphone" either.
>>
>> have IP in the end node, direct Thing-to-Thing communications,
>> secure e2e, server in the Thing, and more.  But HC and 6lowpan are
>> not enabling that either, simply because they are not any more
>> "end-to-end" than the deployed Things using nonIP-plus-IP segments.
>> HC and 6lowpan actually continue this tendency of two linked
>> incompatible segments, which break end-to-end.
>>
>>> Historically, routers have been called gateways.  That is no
>>> longer the language we use in modern discourse.
>>>
>>> We now use the term gateway for protocol translating entities,
>>> which typically need to have some application layer knowledge
>>> (via configuration or dynamic setup) to do their job.  Gateways
>>> are bad because they are complex, they need to be replaced when
>>> application layers change or just a new application needs to be
>>> deployed, and are generally in the way of deploying
>>> applications.
>>>
>>> This enables integrating Internet applications on BTLE nodes
>>> without needing to configure or setup intermediate gateways.
>>
>> That is a good goal, but I think it is only on paper, sorry if I
>> sound provoking.
>>
>>> I agree that having some packet dumps would be very useful. May
>>> I remind people that there is a repository of 6LoWPAN packet
>>> dumps at
>>>
>> Would IPv6/BTLE packets also be on Ethernet II?  Would they also
>> exhibit an 6lowpan intermediary header?  (because IPv6/BT doesnt).
>>
>>> Getting some pcaps (or any other form of packet dumps) from a
>>> live IPv6 over BTLE implementation would be a very useful
>>> contribution here.
>>>
>>> Maybe we should more systematically bug the authors of the other
>>> 6lo drafts to contribute packet dumps?
>>
>> Bugging them - not necessarily, but talk to them about it.  If
>> they provide one here then many people will see it - companies,
>> universities, stds participants.
>>
>> Alex
>>
>>>
>>> Grüße, Carsten
>>>
>>>
>>>
>>
>> _______________________________________________ 6lo mailing list
>> [email-masked] https://www.ietf.org/mailman/listinfo/6lo

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 11 Jun 2015 20:18:13 +0200

> rather see this on the EXPERIMENTAL track.

While I personally don't agree with a number of technical decisions that
were taken since 6LoWPAN agreed on the original version of this
specification, this is the direction that the WG has taken, and that the
BT SIG has contributed to.  Production quality implementations have
since been done.  There is absolutely nothing EXPERIMENTAL about this.

Grüße, Carsten

---

From: Gabriel Montenegro <[email-masked]>
Date: Thu, 11 Jun 2015 18:39:01 +0000

Alex,

We're in complete agreement on this point, this is what I just said:

> . I think whatever clarifying text that could be added was 
> form),

As for the write-up, well, sure, that can be improved. Not sure it's worth it, as the important clarification is what the draft will contain. But if Brian thinks it is worthwhile to improve the writeup, I can copy and massage the clarifying text from the draft, once the new version comes out. 

Thanks,

Gabriel

---

From: Brian Haberman <[email-masked]>
Date: Thu, 11 Jun 2015 16:26:25 -0400

On 6/11/15 2:39 PM, Gabriel Montenegro wrote:
> Alex,
> 
>> I think we agreed with Carles on a very short possible text
>> improvement. I will let them decide and I can live with it.
> 
>> . I think whatever clarifying text that could be added was already
>> suggested (although I'd leave it to the authors for the final 
>> form),
> 
> As for the write-up, well, sure, that can be improved. Not sure it's
> worth it, as the important clarification is what the draft will
> contain. But if Brian thinks it is worthwhile to improve the writeup,
> I can copy and massage the clarifying text from the draft, once the
> new version comes out.
> 

Given the target audience of the shepherd write-up, I don't it is worth
the effort to change it at this point.

Regards,
Brian

---

From: Samita Chakrabarti <[email-masked]>
Date: Fri, 12 Jun 2015 02:44:06 +0000

Hi Alex,

Let us focus on the draft reviewing. 

The draft has  clear  abstract about the  versioning and purpose of this specification.

Also, this is a standard track document--  it has been implemented, reviewed by many  and this specification is important for moving 6lowpan/IPv6 deployment on BTLE. 

For any future extensions to this solution can be  added and specified later like any other standards specification process at IETF.

Thanks for  your  reviews.
-Samita

-----Original Message-----
From: 6lo [mailto:[email-masked]] On Behalf Of Alexandru Petrescu
Sent: Thursday, June 11, 2015 10:33 AM
To: Gabriel Montenegro; Carsten Bormann
Cc: Carles Gomez Montenegro; [email-masked]
Subject: Re: [6lo] We need IPv6 over BTLE packet dumps, please

Gabriel,

With all due respect.

I think BT and BTLE are incompatible technologies and further IPv6 in the picture may only make it worse.

Maybe I doubt also about the proposed track: Standards Track.  I would rather see this on the EXPERIMENTAL track.

Maybe I doubt about some parts in the shepherd writeup as well.  The write up may be misleading in some parts and may mislead decision makers.

This may make think that BTLE is commonly referred to as Bluetooth 4.0. 
  Or, it is not the case.  Bluetooth 4.0 also includes Bluetooth classic.  And IPv6 runs ok on Bluetooth classic.  IPv6 runs ok on Bluetooth 4.0 w/o this RFC.

Saying what is written above ("commonly referred to"), may make think that this RFC (IPv6 over BTLE) is needed in order to make IPv6 over Bluetooth 4.0.  Or, that may not be the case.

I guess the writeup can not be changed at this point, but I still think it may be misleading to decision making.

> This document describes how IPv6 is transported over Bluetooth Low 
> Energy 4.1 using 6LoWPAN techniques.

I think there is no BTLE 4.1.  There is either Bluetooth 4.1, or BTLE part of Bluetooth 4.1.

Alex

Le 11/06/2015 19:21, Gabriel Montenegro a écrit :
> Could the authors prepare a new revision incorporating latest comments 
> so we can move on and continue with IESG processing?
>
> Thanks,
>
> Gabriel
>
>> -----Original Message----- From: 6lo [mailto:[email-masked]] On 
>> Behalf Of Alexandru Petrescu Sent: Thursday, June 11, 2015 8:34
>>> routers here. All routers need an adaptation layer to translate IP 
>>> to the specific MAC layer packets being used.  This translation may 
>>> be very simple encapsulation, as with Ethernet, or something more 
>>> complicated may be going on.
>>
>> from the Internet and which run IP in very different ways than IP on 
>> the Internet.  They will never be connected to the Internet.
>>
>> e2e, server in the Thing, and more.  But HC and 6lowpan are not 
>> enabling that either, simply because they are not any more 
>> provide one here then many people will see it - companies,

---

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

Le 11/06/2015 20:18, Carsten Bormann a écrit :
>> Maybe I doubt also about the proposed track: Standards Track.  I
>> would rather see this on the EXPERIMENTAL track.
>
> While I personally don't agree with a number of technical decisions
> that were taken since 6LoWPAN agreed on the original version of this
> specification, this is the direction that the WG has taken, and that
> the BT SIG has contributed to.

I can agree, but I think it's up to the BT SIG to design non-IP matters
and up to IETF to design IP matters.

> Production quality implementations have since been done.  There is
> absolutely nothing EXPERIMENTAL about this.

Ok, but,

The implementation of this draft uses addressing architecture which is
INFORMATIONAL: extracting the address for a BTLE device from a /64
prefix allocated by the cellular operator is specified in RFC7274
"Extending an IPv6 /64 Prefix from a Third Generation Partnership
Project (3GPP) Mobile Interface to a LAN Link" INFORMATIONAL.

IPv6 works over Bluetooth 4.0 (whose specs include BTLE) without using
this draft, and that is in wide public deployment (bluez).  That should
be Stds Track, and not this draft.

The implementations of this draft are not publicly available, dumps are
not available, etc.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 12 Jun 2015 13:56:41 +0200

> I can copy and massage the clarifying text from the draft, once the

I can agree.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 12 Jun 2015 14:23:48 +0200

Le 12/06/2015 04:44, Samita Chakrabarti a écrit :
> Also, this is a standard track document--  it has been implemented,
> reviewed by many  and this specification is important for moving
> 6lowpan/IPv6 deployment on BTLE.

But it is more important to not break existing IPv6/Bluetooth 
deployments.  IPv6/BTLE is incompatible with IPv6/Bluetooth deployments.

> For any future extensions to this solution can be  added and
> specified later like any other standards specification process at
> IETF.

I am not asking feature extensions.  I am saying that this IPv6/BTLE is 
putting the cart (IPv6/BTLE) before the horse (IPv6/Bluetooth 4.0).

An IPv6/Bluetooth4.0 computer pings ok an IPv6/Bluetooth2.0, whereas an 
IPv6/BTLE-only cant. BTLE spec is part of Bluetooth 4.0, but not part of 
Bluetooth 2.0.

It is IPv6/Bluetooth4.0 that should prime, and the incompatible 
IPv6/BTLE-only should be EXPERIMENTAL.

Unfortunately we dont have an IPv6/Bluetooth4.0 Internet Draft.  I guess 
because there is not much to put in it.  The things are so simple that 
people may not find it worth documenting.  But that is what is deployed 
and compatible, backwards compatible, compatible with good Internet 
connections, open source available, etc.

I can sketch the lines of such IPv6/Bluetooth4.0 draft if there is interest.

Alex

>
> Thanks for  your  reviews. -Samita
>
>
>
>
>
>
>
> Behalf Of Alexandru Petrescu Sent: Thursday, June 11, 2015 10:33 AM
> To: Gabriel Montenegro; Carsten Bormann Cc: Carles Gomez Montenegro;
> [email-masked] Subject: Re: [6lo] We need IPv6 over BTLE packet dumps,
> please
>
> Gabriel,
>
> With all due respect.
>
>> The low power variant of Bluetooth is commonly specified in
>> revision 4.0 of the Bluetooth specifications and commonly referred
>> to as Bluetooth 4.0.
>
> This may make think that BTLE is commonly referred to as Bluetooth
> 4.0. Or, it is not the case.  Bluetooth 4.0 also includes Bluetooth
> I guess the writeup can not be changed at this point, but I still
> think it may be misleading to decision making.
>
>> already suggested (although I'd leave it to the authors for the
>> final form), but beyond that I don't see much constructive
>> discussion going on.
>>
>>> -----Original Message----- From: 6lo
>>> [mailto:[email-masked]] On Behalf Of Alexandru Petrescu
>>> Sent: Thursday, June 11, 2015 8:34 To: Carsten Bormann Cc: Carles
>>> Gomez Montenegro; [email-masked] Subject: Re: [6lo] We need IPv6
>>> over BTLE packet dumps, please
>>>
>>> Hi Carsten,
>>>
>>>>> 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.
>>>>>
>>> All Internet is not Ethernet _cables_ but 99% of the IPv6
>>> Internet is IPv6/Ethernet RFC2464 and the imitating IPv6-over-foo
>>> RFCs.
>>>
>>> And then there are of course many IP links which are
>>> disconnected from the Internet and which run IP in very different
>>> ways than IP on the Internet.  They will never be connected to
>>> the Internet.
>>>
>>>> latter is a good idea because power usage is highly dependent
>>>> on physical layer packet length and because the combined IPv6
>>>> and UDP headers weigh in at 48 bytes, which is often more than
>>>> the payloads that we want to transport for IoT applications.
>>>
>>> For one, these links will be happier if IP is not on them,
>>> because IP consumes a lot.
>>>
>>> Most marketed IoT applications are actually simply two segments:
>>> a non-IP link plus an IP link from the bigger computer to a
>>> server.
>>>
>>> The plethora of IoT devices arriving on market dont run IP and
>>> dont need IP.  The cellular network operators dont allow for this
>>> "IPv6 through a smartphone" either.
>>>
>>> Certainly there can be hypothetical applications which may need
>>> to have IP in the end node, direct Thing-to-Thing communications,
>>> secure e2e, server in the Thing, and more.  But HC and 6lowpan
>>> are not enabling that either, simply because they are not any
>>> more "end-to-end" than the deployed Things using nonIP-plus-IP
>>> segments. HC and 6lowpan actually continue this tendency of two
>>> linked incompatible segments, which break end-to-end.
>>>
>>>> Maybe we should more systematically bug the authors of the
>>>> other 6lo drafts to contribute packet dumps?
>>>

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 12 Jun 2015 14:42:16 +0200

Hi Carsten,

Would it be possible to upload the attached packet dumps
(IPv6/Bluetooth2.0 and IPv6/Bluetooth4.0 wireshark and hcidump LCAP
captures) on

http://svn.tools.ietf.org/svn/wg/6lowpan/packets/

I can provide them in other formats if necessary.

For information, on the Internet one can find BTLE wireshark dissectors
and BTLE wireshark packet dumps, although they dont seem to feature IP.

Thanks in advance,

Alex

Le 11/06/2015 15:38, Carsten Bormann a écrit :
> may be going on.  All the Internet is not Ethernet.  In 6LoWPAN
> networks, encapsulation often involves fragmentation (not needed for
> BTLE as BTLE provides its own segmentation and reassembly) and always
> some form of header compression.  The latter is a good idea because
> power usage is highly dependent on physical layer packet length and
> because the combined IPv6 and UDP headers weigh in at 48 bytes, which
> is often more than the payloads that we want to transport for IoT
> applications.
>
> the language we use in modern discourse.  We now use the term gateway
> for protocol translating entities, which typically need to have some
> application layer knowledge (via configuration or dynamic setup) to
> do their job.  Gateways are bad because they are complex, they need
> to be replaced when application layers change or just a new
> application needs to be deployed, and are generally in the way of
> deploying applications.
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 12 Jun 2015 14:55:43 +0200

Hello members of group 6lo,

I propose to write the following Internet Draft.  Would you be 
interested to contribute?

"IPv6 over Bluetooth 4.0"
Stds Track

MTU: the IPv6 ICMPv6 Echo Request packet on Bluetooth4.0 is of size 
118bytes.

Frame format: an IPv6 packet over a Bluetooth 4.0 interface is 
containing the following fields:

   Ethernet II:
     Destination: IEEE MAC address on 48 bits
     Source: IEEE MAC address on 48 bits
     Type: IPv6 (0x86DD)
   IPv6:
     Base Header (RFC2460)
   ICMPv6:
     RFC443

Stateless Autoconfiguration: the MAC address is used to form an IID, as 
in RFC2464.

Link-local addresses: the IPv6 over Bluetooth4.0 link-local address is 
formed by appending fe80::/64 to the IID formed earler.

Address mapping -- unicast: The Source and Target ll addresses are 
formed from the MAC address.

Address mapping -- multicast:.

Security considerations: supports IPsec end-to-end security.

Referenes: RFC2464.

Alex

---

From: Gabriel Montenegro <[email-masked]>
Date: Mon, 15 Jun 2015 20:28:54 +0000

According to how you've described this work it would have little (no?) relation to 6lo working group. If so, why would this be the appropriate list to discuss?

Thanks,

Gabriel
Ps - FYI, it is not the case that nobody has tried to develop an IP-over-BT document at the IETF. It was tried a long time ago, and it was the subject of its own BoF. 

> Sent: Friday, June 12, 2015 5:56
> To: [email-masked]
> Subject: [6lo] Sketch of an IPv6-over-Bluetooth4.0 Internet Draft
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 16 Jun 2015 11:03:20 +0200

Hi Gabriel,

I agree with you in a sense: as long as it does not have 6lowpan header 
then it would not be relevant to 6lo.

But, on another hand, this is Bluetooth, and BTLE is part of 
Bluetooth4.0.  And IP runs ok on Bluetooth4.0.  One would obviously 
appreciate IP/Bluetooth4.0 to be compatible with IP/BTLE.

A member of this group mentioned in private that Bluetooth 4.2 uses IP 
Support Profile.  But I dont know whether Bluetooth4.2 is deployed in 
laptops on market today, whether IPSP uses 6lowpan or not, whether IPSP 
is supported by the bluez open source or not.

Yours,

Alex

Le 15/06/2015 22:28, Gabriel Montenegro a écrit :
> According to how you've described this work it would have little
> (no?) relation to 6lo working group. If so, why would this be the
> appropriate list to discuss?
>
> Thanks,
>
> Gabriel Ps - FYI, it is not the case that nobody has tried to develop
> an IP-over-BT document at the IETF. It was tried a long time ago, and
> it was the subject of its own BoF.
>
>> On Behalf Of Alexandru Petrescu Sent: Friday, June 12, 2015 5:56
>> To: [email-masked] Subject: [6lo] Sketch of an IPv6-over-Bluetooth4.0
>> Internet Draft
>>
>> "IPv6 over Bluetooth 4.0" Stds Track
>>
>> MTU: the IPv6 ICMPv6 Echo Request packet on Bluetooth4.0 is of
>> size 118bytes.
>>
>> Ethernet II: Destination: IEEE MAC address on 48 bits Source: IEEE
>> MAC address on 48 bits Type: IPv6 (0x86DD) IPv6: Base Header
>> (RFC2460) ICMPv6: RFC443
>>
>> Stateless Autoconfiguration: the MAC address is used to form an
>> IID, as in RFC2464.
>>
>> Link-local addresses: the IPv6 over Bluetooth4.0 link-local address
>> is formed by appending fe80::/64 to the IID formed earler.
>>