Subject: [6lo] RFC 4944bis anyone ?

From: "Turner, Randy" <[email-masked]>
Date: Mon, 8 Sep 2014 14:31:12 +0000

Hi All,

I was curious if the 6lo group is interested in a RFC 4944 "bis" document that includes information related to 802.15.4g and 802.15.4e.

There will be 802.15.4-2015 spec which rolls up all of the addendums into a single doc, which may provide a better reference for any type of "bis" document.

Thanks!
Randy

-----Original Message-----
From: 6lo [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Monday, September 01, 2014 4:58 AM
To: [email-masked]
Subject: Re: [6lo] I-D Action: draft-ietf-6lo-btle-03.txt

Hi,

Here are some updates ref. discussion earlier about possibly conflicting device addresses, link-local address configuration, and DAD optimizations.

Also added clarification that IPv6 packets are sent in network byte order, even though Bluetooth LE protocols utilize little-endian byte ordering (Bluetooth specifications say that byte ordering of L2CAP payload is "application specific" and hence we can have network byte order for IPv6 traffic).

Right after uploading I noticed a too early change of "will publish" to "has published"... i.e. there is no IPSP document available for public yet.

Best regards,

Teemu

-----Original Message-----
From: 6lo [mailto:[email-masked]] On Behalf Of ext [email-masked]
Sent: 1. syyskuuta 2014 11:52
To: [email-masked]
Cc: [email-masked]
Subject: [6lo] I-D Action: draft-ietf-6lo-btle-03.txt

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-03.txt
Pages           : 17
Date            : 2014-09-01

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

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

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/

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

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

P PLEASE CONSIDER OUR ENVIRONMENT BEFORE PRINTING THIS EMAIL.

This e-mail (including any attachments) is confidential and may be legally privileged. If you are not an intended recipient or an authorized representative of an intended recipient, you are prohibited from using, copying or distributing the information in this e-mail or its attachments. If you have received this e-mail in error, please notify the sender immediately by return e-mail and delete all copies of this message and any attachments. Thank you.

---

From: Brian Haberman <[email-masked]>
Date: Mon, 08 Sep 2014 10:46:48 -0400

Randy,
     802.15.4e is being worked on in 6tisch:

http://tools.ietf.org/wg/6tisch/charters

Regards,
Brian

---

From: "Turner, Randy" <[email-masked]>
Date: Mon, 8 Sep 2014 14:53:21 +0000

Hi Brian,

Yes, I understand this...the scope of that effort is specifically TSCH, I was just thinking about another run at an adaptation layer, given the larger payload sizes of 802.15.4g - I didn't see anything in the 6tisch charter that indicated the group was going to obsolete 4944 or update it.  It's very TSCH specific work and no doubt will have significant 4e changes to any existing 4-only MAC layer, I was just looking for a simpler update for the adaptation layer, recognizing 4g and other changes to the evolving .4 doc set which would impact an "adaptation layer"

Randy

-----Original Message-----
From: 6lo [mailto:[email-masked]] On Behalf Of Brian Haberman
Sent: Monday, September 08, 2014 10:47 AM
To: [email-masked]
Subject: Re: [6lo] RFC 4944bis anyone ?

Randy,

Regards,
Brian

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 8 Sep 2014 17:00:28 +0200

On 08 Sep 2014, at 16:53, Turner, Randy <[email-masked]> wrote:

> I was just looking for a simpler update for the adaptation layer, recognizing 4g and other changes to the evolving .4 doc set which would impact an "adaptation layer"

Can you point to specific passages in 4944 that would need to be updated?

Grüße, Carsten

---

From: "Turner, Randy" <[email-masked]>
Date: Mon, 8 Sep 2014 17:05:17 +0000

Hi,

Off the top of my head, possibly the following mods to 4944...

- Amendments to section 4 "Maximum Transmission Unit" wherein MTU sizes are calculated based on 127 octets.

- Section 5.3 that relates to MTU size

- It would be nice if we could rely on interface identifiers based on EUI-64, and a more secure version - it would be nice if we could deprecate the use of 15.4 short addressing...the transient nature of these addresses seems to aggravate an already pressing issue with nodes in the LLN changing their IP address frequently.

- If address/header compression is an "adaptation-layer" thing, I would like to see 4944bis include the current thinking on address/header compression...either RFC 6282 or follow on proposals that are more generic.  If compression  is context-based it would be nice if this work wasn't out of scope (possibly include a reference to RFC 6775 that carries the context) or provide a home in a bis spec for context dissemination.

- Some recognition of the work going on in 6tisch and its' impact on adaptation.

I would basically like to find everything related to adaptation in one spec...

Randy

-----Original Message-----
From: Carsten Bormann [mailto:[email-masked]]
Sent: Monday, September 08, 2014 11:00 AM
To: Turner, Randy
Cc: Brian Haberman; [email-masked]
Subject: Re: [6lo] RFC 4944bis anyone ?

Grüße, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 8 Sep 2014 23:21:11 +0200

> I would basically like to find everything related to adaptation in one spec...

I have been trying to do that in the 6lowpan roadmap.
This is due for an update RSN, and I’ll consider your suggestions.  
Until then, please enjoy the previous version at:

https://tools.ietf.org/html/draft-bormann-6lo-6lowpan-roadmap-00

If you have additional suggestions what should be covered there, I’m all ears.

Grüße, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 8 Sep 2014 23:26:40 +0200

> - It would be nice if we could rely on interface identifiers based on EUI-64, and a more secure version - it would be nice if we could deprecate the use of 15.4 short addressing...the transient nat…

This made me curious — is a need to deprecate short (16-bit) addresses a widely held opinion?
I’m hearing this view for the first time.

Grüße, Carsten

---

From: Thomas Watteyne <[email-masked]>
Date: Mon, 8 Sep 2014 20:56:51 -0700

Carsten,

Absolutely not. For smaller networks and an intelligent way of assigning
them, using 16-bit addressing is VERY helpful.

Thomas

On Mon, Sep 8, 2014 at 2:26 PM, Carsten Bormann <[email-masked]> wrote:

> > - It would be nice if we could rely on interface identifiers based on
> EUI-64, and a more secure version - it would be nice if we could deprecate
> the use of 15.4 short addressing...the transient nature of these addresses
> seems to aggravate an already pressing issue with nodes in the LLN changing
> their IP address frequently.
>

---

From: "Turner, Randy" <[email-masked]>
Date: Tue, 9 Sep 2014 14:06:32 +0000

I do recognize the utility of short addresses in an 802.15.4 network, I just question their use as interface identifiers in a larger IPv6-over-802.15.4(x) network. If every device has an EUI-64, then why not use it?  I'm fine with giving up a few bytes for unique addressing.

Randy

-----Original Message-----
From: Carsten Bormann [mailto:[email-masked]]
Sent: Monday, September 08, 2014 5:27 PM
To: Turner, Randy
Cc: [email-masked]
Subject: Is 16-bit addressing out? (Re: [6lo] RFC 4944bis anyone ?)

> - It would be nice if we could rely on interface identifiers based on EUI-64, and a more secure version - it would be nice if we could deprecate the use of 15.4 short addressing...the transient nat…

This made me curious - is a need to deprecate short (16-bit) addresses a widely held opinion?
I'm hearing this view for the first time.

Grüße, Carsten

---

From: Thomas Watteyne <[email-masked]>
Date: Tue, 9 Sep 2014 10:42:27 -0700

Randy, I understand your point. My argument is that saving 2*6=12 bytes in
each packet by using 16-bit rather than 64-bit addresses is a huge deal.
There are association mechanisms which allows a network to intelligently
assign 16-bit addresses to devices. I would therefore hate for 16-bit
addresses to be deprecated.

On Tue, Sep 9, 2014 at 7:06 AM, Turner, Randy <[email-masked]>
wrote:

> I do recognize the utility of short addresses in an 802.15.4 network, I
> just question their use as interface identifiers in a larger
> IPv6-over-802.15.4(x) network. If every device has an EUI-64, then why not
> use it?  I'm fine with giving up a few bytes for unique addressing.
>
> Randy
>
> This e-mail (including any attachments) is confidential and may be legally
> privileged. If you are not an intended recipient or an authorized
> representative of an intended recipient, you are prohibited from using,
> copying or distributing the information in this e-mail or its attachments.
> If you have received this e-mail in error, please notify the sender
> immediately by return e-mail and delete all copies of this message and any
> attachments. Thank you.
>

---

From: "Turner, Randy" <[email-masked]>
Date: Tue, 9 Sep 2014 17:48:50 +0000

Yes, maybe deprecation is a bit strong across the board – the coordinator’s algorithm for creating PAN IDs and addresses really needs to be thought out – my preference is still EUIs, but like I said, I understand the short-address rationale

R.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Thomas Watteyne
Sent: Tuesday, September 09, 2014 1:42 PM
To: Turner, Randy
Cc: Carsten Bormann; [email-masked]
Subject: Re: [6lo] Is 16-bit addressing out? (Re: RFC 4944bis anyone ?)

Randy, I understand your point. My argument is that saving 2*6=12 bytes in each packet by using 16-bit rather than 64-bit addresses is a huge deal. There are association mechanisms which allows a network to intelligently assign 16-bit addresses to devices. I would therefore hate for 16-bit addresses to be deprecated.

On Tue, Sep 9, 2014 at 7:06 AM, Turner, Randy <[email-masked]<mailto:[email-masked]>> wrote:
I do recognize the utility of short addresses in an 802.15.4 network, I just question their use as interface identifiers in a larger IPv6-over-802.15.4(x) network. If every device has an EUI-64, then why not use it?  I'm fine with giving up a few bytes for unique addressing.

Randy

-----Original Message-----
From: Carsten Bormann [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Monday, September 08, 2014 5:27 PM
To: Turner, Randy
Cc: [email-masked]<mailto:[email-masked]>
Subject: Is 16-bit addressing out? (Re: [6lo] RFC 4944bis anyone ?)

Grüße, Carsten

This e-mail (including any attachments) is confidential and may be legally privileged. If you are not an intended recipient or an authorized representative of an intended recipient, you are prohibited from using, copying or distributing the information in this e-mail or its attachments. If you have received this e-mail in error, please notify the sender immediately by return e-mail and delete all copies of this message and any attachments. Thank you.
_______________________________________________
6lo mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/6lo

---

From: Thomas Watteyne <[email-masked]>
Date: Tue, 9 Sep 2014 10:49:34 -0700

+1

On Tue, Sep 9, 2014 at 10:48 AM, Turner, Randy <[email-masked]>
wrote:

>  Yes, maybe deprecation is a bit strong across the board – the
> coordinator’s algorithm for creating PAN IDs and addresses really needs to
> be thought out – my preference is still EUIs, but like I said, I understand
> the short-address rationale
>
>
>
> R.
>
>
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf Of *Thomas
> Watteyne
> *Sent:* Tuesday, September 09, 2014 1:42 PM
> *To:* Turner, Randy
> *Cc:* Carsten Bormann; [email-masked]
> *Subject:* Re: [6lo] Is 16-bit addressing out? (Re: RFC 4944bis anyone ?)
>
>
>

---

From: Ralph Droms <[email-masked]>
Date: Tue, 9 Sep 2014 14:09:50 -0400

> On Sep 9, 2014, at 1:42 PM, Thomas Watteyne <[email-masked]> wrote:
> 
> Randy, I understand your point. My argument is that saving 2*6=12 bytes in each packet by using 16-bit rather than 64-bit addresses is a huge deal.

It can be much more than 12 bytes with source-route compression

- Ralph

> There are association mechanisms which allows a network to intelligently assign 16-bit addresses to devices. I would therefore hate for 16-bit addresses to be deprecated.
> 
> 
>> On Tue, Sep 9, 2014 at 7:06 AM, Turner, Randy <[email-masked]> wrote:

---

From: Michael Richardson <[email-masked]>
Date: Wed, 10 Sep 2014 08:43:15 -0400

Carsten Bormann <[email-masked]> wrote:
    >> EUI-64, and a more secure version - it would be nice if we could
    >> deprecate the use of 15.4 short addressing...the transient nature of
    >> these addresses seems to aggravate an already pressing issue with
    >> nodes in the LLN changing their IP address frequently.

    > This made me curious — is a need to deprecate short (16-bit) addresses
    > a widely held opinion?  I’m hearing this view for the first time.

Me too.

-- 
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-