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

From: Jonathan Hui <[email-masked]>
Date: Sun, 03 Jun 2007 21:51:35 -0700

There are two cases when we talk about coexistence of protocols: (i) 
protocols that run on logically distinct networks and (ii) protocols 
that run on the same network. In the former case, I agree that computing 
MICs is the answer to keep the logically distinct networks separate, and 
should not rely on a few defined bits in the message payload. Using MICs 
is simply common sense when building a robust network. However, allowing 
multiple protocols to coexist on the same network is an important notion 
to keep when moving forward. LLC/SNAP allows different protocols to 
coexist above 802.3 and 802.11. IPv4 networks rely on a some of these 
protocols (e.g. ARP). While IPv6 has essentially moved ARP into ND, 
there may be other (possibly yet unforeseen) cases where we want one or 
more protocols operating directly on top of L2 to coexist with 6lowpan.

--
Jonathan Hui
[email-masked]

Kris Pister wrote:
> 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.
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> 6lowpan mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/6lowpan

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

---

From: "Joe Polastre" <[email-masked]>
Date: Sun, 3 Jun 2007 22:23:28 -0700

What Kris was proposing achieves the goals of both (i) and (ii)
networks.  The MIC has become a standard parameter for a variety of
different networking standards.  By including it at layer 2, you're
promoting co-existence with other protocols of the same layer 2
implementation while permitting flexibility in the network protocol
selection (pick from the alphabet soup of IPv6, SP100.11a, Zigbee Pro,
or Wireless HART).

Quite frankly, LLC/802.2 has been ineffective at best in promoting
different protocols to coexist.  Most major operating systems build
their own abstraction, or do implement 802.2 but bypass it for quite a
few instances.  Linux, for example, implements case statements in its
IP implementation that changes the behavior of IP based on the type of
underlying link.  Given that this is an IP-based standards group, the
only clear existing abstraction that has effectively decoupled the
lower layers and permitted coexistence is IP and not 802.2 or LLC.
That doesn't mean it should be ignored; however, it does not achieve
the goals that you outline in your email.

-Joe

On 6/3/07, Jonathan Hui <[email-masked]> wrote:
> > David – nice tutorial.  That's very helpful.
> >
> >
> >
> > Regarding the dispatch discussion, I'm still concerned that this appears
> > proprietary protocols and international standards with which I've been
> > we've spent countless hours in discussion and debate on the topic.
> >
> >
> >
> > beyond the 802.15.4 FCS, you're doomed.  With the CRC16, you can
> > that's what the 15.4 standard supports.  So if you've got to have MIC,
> > (0x495056366F766572366C6F7750414E21 encodes "IPv6over6lowPAN" nicely in
> > **don't** use a MIC (e.g. zigbee with security turned off), and the

---

From: Jonathan Hui <[email-masked]>
Date: Sun, 03 Jun 2007 23:08:38 -0700

> selection (pick from the alphabet soup of IPv6, SP100.11a, Zigbee Pro,

So lets take a concrete example: your favorite networking protocol 
(YFNP) and a over-the-air programming protocol (OTAP). One could argue 
that OTAP should not depend on YFNP in the case where you want to 
upgrade YFNP to YFNPng. Such incompatibility already exists with ZigBee 
2006 and Pro. So for them to coexist in my network, I'll need to have 
two different keys, one for each protocol. When decoding a packet, I'll 
either need to try both keys and pick the one that works or rely on some 
common understanding of 802.15.4's key-identifier. The former is fairly 
inefficient. Maybe the argument is with appropriate hardware, we can 
efficiently apply a set of keys and have it return the one that worked, 
or none at all. Are there protocols operating on 802.15.4 that have 
scoped out more efficient ways of selecting the key to use? Or are you 
satisfied with the trial-and-error approach?

> the goals that you outline in your email.

While LLC/802.2 may have been ineffective at promoting different 
protocols to coexist in general, it does allow IPv4 and ARP to coexist 
by adapting EtherType values. Try running an IP box without one of these 
services. Maybe it would have been better to say that 802.15.4 lacks the 
upper-layer protocol type field of 802.3. Remember that 6lowpan is not 
about trying to run IPv6 on link-layers other than 802.15.4, so I wasn't 
trying to propose LLC as a useful abstraction to link layers.

This of this discussion is probably best left to the IEEE. Just trying 
to shed some light on why NALP exists in the first place.

--
Jonathan Hui
[email-masked]

---

From: "Joe Polastre" <[email-masked]>
Date: Sun, 3 Jun 2007 23:15:40 -0700

> satisfied with the trial-and-error approach?

The problem is that you're trying to cross layer boundaries and IEEE
802.15.4 was never intended to allow such usage.

IEEE 802.15.4 specifies a link key--a key that can be used to validate
traffic between two hosts at the data link level.  What you are
describing is network keying, which is beyond the scope of IEEE
802.15.4.  YFNP, YFNPng, and OTAP can all specify their desired
security scheme and keying approach (for example, OTAP may implement a
network-wide keying scheme while YFNP is a multicast protocol that
uses group keying).  Either way, these are concerns above the data
link layer, and we should not confuse security at the network layer
with security at the data link layer.

-Joe

---

From: Jonathan Hui <[email-masked]>
Date: Sun, 03 Jun 2007 23:47:52 -0700

> 802.15.4 was never intended to allow such usage.

Which brings us back to the two kinds of coexistence. In one case, we 
have coexistance of 6lowpan, zigbee, wireless hart. This is easily 
solvable with Kris' proposal. In the other, we have coexistance of YFNP 
and OTAP. Which 6lowpan has provided provisions for with the use of NALP.

> with security at the data link layer.

There's no confusion here. Kris' argument was based on the fact that an 
802.15.4 4-byte MIC provide better integrity checks than 16-bit CRCs 
while also providing a convenient mechanism for segmenting a collection 
of nodes. With link-layer MICs in place, then a simple and now plausible 
solution is to have some bits in the payload define what upper-layer 
protocol is running. Having a 6lowpan-specific key still works since 
NALP protocols are necessarily aware of 6lowpan, since they conform to 
its protocol-identifier mechanism. Another way is, as you suggest, to 
provide network-level keying for segmentation, which then gets back to 
the "how do i determine what key to use" problem.

--
Jonathan Hui
[email-masked]