Subject: [6lowpan] Dispatch value bit pattern for 6lowPAN

From: "David Culler" <[email-masked]>
Date: Wed, 30 May 2007 16:38:38 -0700

Anthony,
     There was a good bit of discussion on the partitioning of the dispatch
field following the San Diego meeting.  Many felt that ideally, the protocol
identifier would have been carried in the 15.4 header, so we were back
filling.  There was discussion about utilizing only a small fraction of the
initial dispatch address space, so there would be more room for coexistence
with other protocols.  There was not a lot of discussion about whether we
could define the initial dispatch in such a way that it would provide
backward-going coexistence pre-existing protocols, since none of the
proprietary or industry forum protocols seemed to have considered leaving
room for others to fit alongside.  Perhaps the forward-going hope was that
new efforts would at least live along side of 6LoWPAN and all the protocols
built on top of it.
_______________________________________________
6lowpan mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/6lowpan

---

From: "Kris Pister" <[email-masked]>
Date: Thu, 31 May 2007 09:26:25 -0700

David - nice tutorial.  That's very helpful.

Regarding the dispatch discussion, I'm still concerned that this appears
to be leading people to draw the wrong conclusions, or worse, carry
forward the wrong assumptions.

Successful coexistence has nothing to do with the first two bits of the
network header.  Any implementations that make that assumption are
doomed.  Even if we could get the whole world to agree on dispatch
values, those bits (and others) are still going to get flipped
undetected every now and then between TX and RX.  None of the
proprietary protocols and international standards with which I've been
associated have ignored the issue of coexistence.  Quite the contrary,
we've spent countless hours in discussion and debate on the topic.

The conclusion is that without a message integrity check above and
beyond the 802.15.4 FCS, you're doomed.  With the CRC16, you can
probably get away with a 2 byte MIC, but 4 is safer and in any case
that's what the 15.4 standard supports.  So if you've got to have MIC,
then coexistence is simple.  We can choose a default 6lowPAN key
(0x495056366F766572366C6F7750414E21 encodes "IPv6over6lowPAN" nicely in
128 bits :-) ), and unless someone intentionally uses that same key,
then the chances of 6lowPAN networks having coexistence problems with
SmartMesh or HART or sp100 (or zigbee with security turned on) are
effectively zero.  The only coexistence problems then are for people who
*don't* use a MIC (e.g. zigbee with security turned off), and the
problem is for them, not for us.

Once the MAC layer has signed off on the MIC, then your network layer
knows with confidence that this is in fact a valid packet, and *then* it
can look at the first two bits of the network header and do its job.

This seems really simple and obvious to me.  Am I missing something?

ksjp

Kristofer S.J.Pister, Founder & CTO

Dust Networks, 30695 Huntwood Ave. 
Hayward, CA 94544
510-548-DUST

________________________________

From: David Culler [mailto:[email-masked]] 
Sent: Wednesday, May 30, 2007 4:39 PM
To: [email-masked]; [email-masked]
Subject: [6lowpan] Dispatch value bit pattern for 6lowPAN

Anthony,
     There was a good bit of discussion on the partitioning of the
dispatch field following the San Diego meeting.  Many felt that ideally,
the protocol identifier would have been carried in the 15.4 header, so
we were back filling.  There was discussion about utilizing only a small
fraction of the initial dispatch address space, so there would be more
room for coexistence with other protocols.  There was not a lot of
discussion about whether we could define the initial dispatch in such a
way that it would provide backward-going coexistence pre-existing
protocols, since none of the proprietary or industry forum protocols
seemed to have considered leaving room for others to fit alongside.
Perhaps the forward-going hope was that new efforts would at least live
along side of 6LoWPAN and all the protocols built on top of it.

---

From: gabriel montenegro <[email-masked]>
Date: Thu, 31 May 2007 09:45:39 -0700 (PDT)

On the conflict. When we discussed this, two arguments that were done were:
- most deployment in the near and perhaps even far term were expected to be private (i.e, not zigbee, not 6lowpan, completely uncoordinated).
  I do remember seeing such an analyst report, but can't remember details any more.
- most (all?) deployments of 6lowpan were expected to use AES, so this conflict would be avoided in practical terms.

Because of arguments like the above, I think there was not much motivation to try harder at coordination with Zigbee. So I think your conclusion is in line
with previous discussions. Having said that, I think your proposal of a 6lowpan default key for AES makes sense for those deployments that don't actually 
use AES already. I still think it's not a very critical point as I'd expect most deployments will have AES turned on. 

At any rate, this might be an interesting individual submission, perhaps you can write it up?

-gabriel

----- Original Message ----
From: Kris Pister <[email-masked]>
To: David Culler <[email-masked]>; [email-masked]; [email-masked]
Sent: Thursday, May 31, 2007 9:26:25 AM
Subject: RE: [6lowpan] Dispatch value bit pattern for 6lowPAN

 

 

<!--
 _filtered {font-family:Wingdings;panose-1:5 0 0 0 0 0 0 0 0 0;}
 _filtered {font-family:Tahoma;panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;margin-bottom:.0001pt;font-size:12.0pt;font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;text-decoration:underline;}
p.MsoAutoSig, li.MsoAutoSig, div.MsoAutoSig
	{margin:0in;margin-bottom:.0001pt;font-size:12.0pt;font-family:"Times New Roman";}
span.EmailStyle17
	{font-family:Arial;color:navy;}
 _filtered {margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{}
-->

David – nice tutorial.  That’s
very helpful.

Regarding the dispatch discussion, I’m
still concerned that this appears to be leading people to draw the wrong
conclusions, or worse, carry forward the wrong assumptions.

Successful coexistence has nothing to do
with the first two bits of the network header.  Any implementations that
make that assumption are doomed.  Even if we could get the whole world to
agree on dispatch values, those bits (and others) are still going to get
flipped undetected every now and then between TX and RX.  None of the
proprietary protocols and international standards with which I’ve been
associated have ignored the issue of coexistence.  Quite the contrary, we’ve
spent countless hours in discussion and debate on the topic.

The conclusion is that without a message
integrity check above and beyond the 802.15.4 FCS, you’re doomed.  With
the CRC16, you can probably get away with a 2 byte MIC, but 4 is safer and in
any case that’s what the 15.4 standard supports.  So if you’ve
got to have MIC, then coexistence is simple.  We can choose a default
6lowPAN key (0x495056366F766572366C6F7750414E21 encodes “IPv6over6lowPAN”
nicely in 128 bits J ), and unless someone intentionally uses that same key, then the
chances of 6lowPAN networks having coexistence problems with SmartMesh or HART
or sp100 (or zigbee with security turned on) are effectively zero.  The only
coexistence problems then are for people who *don’t*
use a MIC (e.g. zigbee with security turned off), and the problem is for them,
not for us.

Once the MAC layer has signed off on the
MIC, then your network layer knows with confidence that this is in fact a valid
packet, and *then* it can look at
the first two bits of the network header and do its job.

This seems really simple and obvious to
me.  Am I missing something?

ksjp

Kristofer S.J.Pister, Founder &
CTO

Dust Networks, 
30695 Huntwood Ave. 

Hayward, CA 94544

510-548-DUST

From: David Culler
[mailto:[email-masked]] 

Sent: Wednesday, May 30, 2007 4:39
PM

To: [email-masked];
[email-masked]

Subject: [6lowpan] Dispatch value
bit pattern for 6lowPAN

Anthony,

     There was a good bit of discussion on the partitioning of
the dispatch field following the San
  Diego meeting.  Many felt that ideally, the
protocol identifier would have been carried in the 15.4 header, so we were back
filling.  There was discussion about utilizing only a small fraction of
the initial dispatch address space, so there would be more room for coexistence
with other protocols.  There was not a lot of discussion about whether we
could define the initial dispatch in such a way that it would provide
backward-going coexistence pre-existing protocols, since none of the
proprietary or industry forum protocols seemed to have considered leaving room
for others to fit alongside.  Perhaps the forward-going hope was that new
efforts would at least live along side of 6LoWPAN and all the protocols built
on top of it.