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 PROTECTED]> To: David Culler <[EMAIL PROTECTED]>; [email protected]; [EMAIL PROTECTED] 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 PROTECTED] Sent: Wednesday, May 30, 2007 4:39 PM To: [email protected]; [EMAIL PROTECTED] 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 protected] https://www1.ietf.org/mailman/listinfo/6lowpan
_______________________________________________ 6lowpan mailing list [email protected] https://www1.ietf.org/mailman/listinfo/6lowpan
