Subject: Re: [6lowpan] [Fwd: New Version Notification for draft-ietf-6lowpan-nd-03]

From: Richard Kelsey <[email-masked]>
Date: Tue, 09 Jun 2009 10:34:40 -0400

Date: Thu, 28 May 2009 00:55:27 +0200
   From: Zach Shelby <[email-masked]>

   A new version of draft-ietf-6lowpan-nd is now available at:
   http://www.ietf.org/internet-drafts/draft-ietf-6lowpan-nd-03.txt

   Changes:

   - Whiteboard is supported by all Edge Routers for option simplicity

Zach,

While this simplifies the options, I think it might be a net
loss in terms of complexity and cost, at least for some
networks.  In particular, I think that it would be
unfortunate if forwarding messages between two LoWPANs
required that any router doing such forwarding have a
whiteboard.  Is this the case?

Would it be possible to avoid the need for a whiteboard in a
network by only using IPv6 addresses derived from EUI64s?
While conflicts are still possible, they are very unlikely
(outside of development and testing, where they can happen
with some regularity).  802.15.4 16-bit addresses could
still be used for link-layer next-hop addresses, as that
requires only local, and not global, conflict detection.

On a related note, there is some discussion of what happens
when a non-Edge-Router reboots (using a lollipop mechanism
for TIDs), but I didn't see anything about what happens if
an Edge Router reboots.  Is the expectation that the
whiteboard will be kept in non-volatile storage?

                                 -Richard Kelsey

---

From: Richard Kelsey <[email-masked]>
Date: Tue, 09 Jun 2009 11:00:23 -0400

Zach,

The security section says that MAC sublayer cryptography
is expected to provide:

   secure unicast to/from Routers and secure broadcast from
   the Routers in a way that prevents tampering with or
   replaying the RA messages.

802.15.4 security does not provide replay protection.  It
does have a means for including frame counters in messages,
but there is no mechanism for synchronizing frame counters
in the first place.  The frame counters prevent messages
from being replayed out of order, but they do not prevent
replaying in general.  This seems particularly important for
RA messages, which are often some of the first packets
traveling over a link or the first packets received after a
reboot.

It may be that the limited replay protection that 802.15.4
security provides is sufficient in this case, but I think
that this needs to be spelled out in more detail.  Either
that or real replay protection needs to be provided by
extending 802.15.4 security or adding additional security
at the 6LoWPAN adaption layer.
                                   -Richard Kelsey

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 9 Jun 2009 20:26:25 +0200

On Jun 9, 2009, at 17:00, Richard Kelsey wrote:

> 802.15.4 security does not provide replay protection

I think a better way to say this is slightly more blunt:
"802.15.4 does not provide security".

802.15.4 only provides mechanisms (such as AES/CCM) that need to be  
used in the right way to achieve the security objectives.

Replay protection with memoryless nodes is hard, indeed.

(WG chair hat:)
We do need to work on security in the 6LoWPAN WG.
I would like to go to Stockholm with a pretty good idea of what the  
steps will be.
I would love to hear your, and everybody else's, input.

Gruesse, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 9 Jun 2009 20:35:55 +0200

> In particular, I think that it would be

Right now, the architecture is that packets only enter and leave a  
LoWPAN through an ER.
ERs have whiteboards and (if multiple) are interconnected by a fast  
backbone link.

Can you give more details of a scenario where this is suboptimal?

> with some regularity).

I've got one word for you: counterfeiting.

(So the point is less the detection of IPv6 address collisions but of  
EUI-64 collisions, indeed.)

> 802.15.4 16-bit addresses could

How does local conflict detection work when nodes tend to attach to  
routers they haven't seen before?
Of course, a node could have many 16-bit short addresses if we were  
using the cluster approach (with separate PAN IDs per router).
Is that what you are hinting at?

(Such an approach would cost some header compression efficiency, at  
about 8 bytes per message.)

> whiteboard will be kept in non-volatile storage?

That would help.
(If you don't do that, it will be hard to avoid a blackout for about a  
registration lifetime, unless we have something like an "ER reboot  
sequence" disseminated through the network.  Which will bring a  
galopping herd of re-registrations, unless dithered, which will cause  
blackouts for the dithering period.)

Gruesse, Carsten

---

From: Rene Struik <[email-masked]>
Date: Tue, 9 Jun 2009 15:05:12 -0400

Hi Carsten:

For an overview of security functionality provided by 802.15.4-2006, cf. Clause 5.6 of the standard (excerpted below).

FYI - With IEEE 802.15.4e, intention is to introduce some security enhancements (e.g., timeliness) and realize overhead reduction techniques (cutting down on over-the-air traffic) have been proposed -- cf., e.g., the following documents (all posted on the IEEE 802 reflector https://mentor.ieee.org/802.15/documents ):

Documents related to the security and overhead reduction proposal with 802.15.4e:
15-08-0828-08-004e-security-and-efficiency-enhancements.ppt
15-08-0848-01-004e-security-and-efficiency-enhancements-overview.doc
15-08-0849-00-004e-streamlined-security-clause-802-15-4-2006.pdf
15-09-0233-04-004e-frame-control-field-discussion.xls

Intention is to have a first draft of IEEE 802.15.4e ready prior to the next IEEE 802 meeting, San Francisco, CA, July 12-17, 2009.

I hope this helps.

Best regards, Rene

[source: excerpt from IEEE 802.15.4-2006, Clause 5.6]

The cryptographic mechanism in this standard is based on symmetric-key cryptography and uses keys that
are provided by higher layer processes. The establishment and maintenance of these keys are outside the
scope of this standard. The mechanism assumes a secure implementation of cryptographic operations and
secure and authentic storage of keying material.

The cryptographic mechanism provides particular combinations of the following security services:
- Data confidentiality: Assurance that transmitted information is only disclosed to parties for which it
is intended.
- Data authenticity: Assurance of the source of transmitted information (and, hereby, that information
was not modified in transit).
- Replay protection: Assurance that duplicate information is detected.

The actual frame protection provided can be adapted on a frame-by-frame basis and allows for varying
levels of data authenticity (to minimize security overhead in transmitted frames where required) and for
optional data confidentiality. When nontrivial protection is required, replay protection is always provided.

Cryptographic frame protection may use a key shared between two peer devices (link key) or a key shared
among a group of devices (group key), thus allowing some flexibility and application-specific tradeoffs
between key storage and key maintenance costs versus the cryptographic protection provided. If a group key
is used for peer-to-peer communication, protection is provided only against outsider devices and not against
potential malicious devices in the key-sharing group.

For more detailed information on the cryptographic security mechanisms used for protected MAC frames
following this standard, refer to Clause 7.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Carsten Bormann
Sent: Tuesday, June 09, 2009 2:26 PM
To: Richard Kelsey
Cc: [email-masked]
Subject: Re: [6lowpan] ND and MAC-level security

(WG chair hat:)

Gruesse, Carsten

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

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 9 Jun 2009 21:33:16 +0200

Hi Rene,

thanks for the information about 15.4e -- that draft would be very  
welcome input for Stockholm!

The clause you cited from 15.4-2006 says what I said in a couple more  
words:
15.4 provides state-of-the-art cryptographic mechanisms.
These can be used for security, but 15.4 does not say how.
In particular there is no defined key management.
The references you gave don't change that (but they do contain  
proposals for nice fixes, in particular finally a secured ACK).

I'm not saying all this to critique 15.4, just to wake up people on  
this list to the fact that we cannot simply rely on the wonderful  
security provided by 15.4 -- there is none, unless we add key  
management.

Gruesse, Carsten

PS.: 2^20 seconds ≠ 48.5 days :-)

---

From: Rene Struik <[email-masked]>
Date: Tue, 9 Jun 2009 15:41:58 -0400

Hi Carsten:

Indeed, 802.15.4 only provides facilities for key usage and not for any other aspects of the key lifecycle (key initialization, key distribution, key updates, etc, etc.).

Indeed, 2^{20} seconds are not 48.5 days, but 2^{22} seconds roughly are...

Rene

-----Original Message-----
From: Carsten Bormann [mailto:[email-masked]] 
Sent: Tuesday, June 09, 2009 3:33 PM
To: Rene Struik
Cc: Richard Kelsey; [email-masked]
Subject: Re: [6lowpan] ND and MAC-level security

Hi Rene,

Gruesse, Carsten

---

From: Richard Kelsey <[email-masked]>
Date: Tue, 09 Jun 2009 16:21:21 -0400

From: Carsten Bormann <[email-masked]>
   Date: Tue, 9 Jun 2009 20:35:55 +0200

   > whiteboard.  Is this the case?

   Right now, the architecture is that packets only enter
   and leave a LoWPAN through an ER.  ERs have whiteboards
   and (if multiple) are interconnected by a fast backbone
   link.

   Can you give more details of a scenario where this is
   suboptimal?

One example is wanting to connect an existing ad-hoc LoWPAN
to an IPv6 infrastructure via another LoWPAN.  It would be
preferable to do so without moving the existing ad-hoc
whiteboard or adding otherwise unecessary relays.

More generally, I am concerned that requiring a whiteboard
adds a single point of failure and requires having a device
with additional resources.  I admit that I am unclear on
exactly how much RAM etc. the whiteboard requires.  In
particular, this is why I was asking about the need for
nonvolatile storage.

I'm sorry, I don't follow you.  What kind of counterfeiting
does the whiteboard detect?  I would think that would
require security mechanisms beyond those mentioned in the ND
draft, e.g. certificates of some kind.

   > requires only local, and not global, conflict detection.

   How does local conflict detection work when nodes tend to
   attach to routers they haven't seen before?

If the link-layer security makes use of the sender's
EUI64 there has to be some exchange of EUI64's before
messages can be decrypted or authenticated.  That
exchange can also detect local conflicts in 16-bit
addresses.

Yes.
                                -Richard Kelsey

---

From: Richard Kelsey <[email-masked]>
Date: Tue, 09 Jun 2009 16:29:05 -0400

From: Carsten Bormann <[email-masked]>
   Date: Tue, 9 Jun 2009 21:33:16 +0200

And frame counter synchronization.  People see the frame
counters and think they replay protection.  We should
either finish the job or not use the frame counters.

                               -Richard Kelsey

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 9 Jun 2009 22:52:11 +0200

On Jun 9, 2009, at 22:21, Richard Kelsey wrote:

> connect an existing ad-hoc LoWPAN

The ad-hoc LoWPAN would have to renumber to directly connect to the  
Internet, right?

Do you want the old ad-hoc nodes to be part of the new LoWPAN?  If  
not, there will be some relaying somewhere, because the LoWPAN is a  
stub network with a single prefix.
(The existing ad-hoc whiteboard could do NEMO, for instance.)

Gruesse, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 9 Jun 2009 23:06:17 +0200

> draft, e.g. certificates of some kind.

This is not about security.

Let's say Vendor E smoke detectors become really popular, and every US  
household wants one.
So some black-hat operation in some country starts to build cheap  
counterfeits.
These would be commissioned somewhere with all that a Vendor E smoke  
detector needs, even a fake EUI-64 with Vendor E's OUI so the network  
monitors tell you the device is a Genuine Vendor E smoke detector.
(As we all know from experiences with Vendor C, this is not at all a  
movie-plot scenario.)

Unless Vendor E hands out number ranges to its counterfeiters :-), I  
don't see how these EUIs would be unique.

Protecting the uniqueness of EUI-64s using tamper-proof device keys  
and a certificate sounds interesting...  (They wouldn't really be  
tamper-proof [1] and so all fake smoke detectors would have one of the  
key/certificate/EUI combinations of the fifteen Vendor E smoke  
detectors the bad guys bought and opened.)

Oh and all that paranoia aside, manufacturing errors have happened and  
do happen.
The Whiteboard does not help much in detecting counterfeiting, but it  
does help in detecting IID (and thus EUI-64) collisions.

Gruesse, Carsten

[1] http://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-711.pdf

---

From: Robert Cragie <[email-masked]>
Date: Wed, 10 Jun 2009 05:44:25 +0100

It is possible to use various key establishment mechanisms based on 
shared secrets or asymmetric cryptography to not only establish key 
pairs but also to mutully authenticate and exchange information for 
frame counter synchronisation. These have never been part of 15.4 but do 
need to be defined somewhere.

Robert

Robert Cragie, Principal Engineer

Direct: +44 (0) 114 281 4512
_______________________________________________________________
Jennic Ltd, Furnival Street, Sheffield, S1 4QT,  UK
http://www.jennic.com  Tel: +44 (0) 114 281 2655   Confidential
_______________________________________________________________

---

From: "Burnett, Peter" <[email-masked]>
Date: Wed, 10 Jun 2009 10:18:38 +0200

Carsten,

Is it within the scope of 6lowpan to define key management and frame counter synchronization mechanisms for 15.4?

Thanks
Peter Burnett
Philips

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Robert Cragie
Sent: 2009 Jun 10 05:44
To: Richard Kelsey
Cc: Carsten Bormann; [email-masked]; [email-masked]
Subject: Re: [6lowpan] ND and MAC-level security

Robert

The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 10 Jun 2009 10:21:50 +0200

Hi Carsten and Richard

>blackouts for the dithering period.)

This is a similar discussion we had designing similar features like MIP
Home Agent and IPv6 ND proxy in general.

The usual conclusion is that High Availability is in practice often
proprietary and left to implementation.
You do not necessarily do it the same way when you have 2 routers, 2
forwarding blades in a same router, etc....
In a limited deployment that can afford a lapse while the
re-registrations happen, we can live with simple, low cost routers like
home gateways. If you need more, then you buy an higher-end router that
has HA facilities.

Now if we can do something to make our protocol better, for instance by
finding a better way to use the secondary binding then fine and we are
certainly open to proposals in this matter. Just that we don't want to
mandate the ultimate weapon on the smaller, simpler systems.

Pascal

>Sent: mardi 9 juin 2009 20:36
>To: Richard Kelsey
>Cc: [email-masked]
>Subject: Re: [6lowpan] [Fwd: New Version Notificationfor
draft-ietf-6lowpan-nd-03]

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 10 Jun 2009 11:12:26 +0200

On Jun 10, 2009, at 10:18, Burnett, Peter wrote:

> Is it within the scope of 6lowpan to define key management and frame  
> counter synchronization mechanisms for 15.4?

Not now, but we are on the brink of rechartering.

It very much *is* in the scope right now to have a problem statement/ 
security analysis that prepares this.

To quote:

6. Produce "6LoWPAN Security Analysis" to define the threat model of
6LoWPANs, to document suitability of existing key management
schemes and to discuss bootstrapping/installation/commissioning/setup
issues. This document will be referenced from the "security
considerations" of the other 6LoWPAN documents.
This document will be informational.

So if an argument can be made that e.g. frame counter synchronization  
is a good way to solve replay, let's go ahead and write this up.

Gruesse, Carsten

---

From: Richard Kelsey <[email-masked]>
Date: Wed, 10 Jun 2009 08:39:32 -0400

From: Carsten Bormann <[email-masked]>
   Date: Tue, 9 Jun 2009 23:06:17 +0200

I would argue that the last part shows that this is a
security issue, in that the network monitors are accepting
unauthenticated information as gospel.

But I do agree that it isn't a security issue that 6LoWPAN
should be worried about.  Manufacturers of counterfeit
devices are not going to go through the usual process of
obtaining their own, traceable, EUI64s.  This increases the
odds of there being EUI64 collisions and we need to take
this into account.

   Oh and all that paranoia aside, manufacturing errors have
   happened and do happen.  The Whiteboard does not help
   much in detecting counterfeiting, but it does help in
   detecting IID (and thus EUI-64) collisions.

It comes down to the tradeoff between the costs and benefits
of having a whiteboard.  It isn't clear to me that the
benefits so outweight the costs that 6LoWPAN ND should
require a whiteboard, especially if only EUI64 are being
used.
                              -Richard Kelsey

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 10 Jun 2009 15:16:07 +0200

> require a whiteboard, especially if only EUI64 are being

So what would you propose?

-- scrapping the whiteboard and implementing multicast so we still  
have DAD
-- getting rid of DAD completely and just pray

or maybe make the whiteboard optional, but what does that mean?

-- the ER can announce "no whiteboard today" and all nodes go to "just  
pray" mode
-- even if the ER does a whiteboard, nodes are allowed to not bother  
(which breaks the below)

So maybe they are optional at the ER but nodes still must use them if  
available?

Whiteboards don't just do DAD.
What else is expendable?
-- you already said the 8 bytes additional compression are maybe  
expendable.
-- the ability to suppress messages at the ER that address non- 
existent nodes (which saves a lot of RREQ work)?

Looking at the whole picture, I personally think there are some quite  
real benefits.
But I'd love to hear other opinions.
We only can make the right tradeoff if we understand the impact on the  
deployment scenarios.

Gruesse, Carsten

---

From: Zach Shelby <[email-masked]>
Date: Wed, 10 Jun 2009 17:47:41 +0300

Hi,

>    detecting IID (and thus EUI-64) collisions.

It is not only about detecting collisions. Because you don't have a 
transitive link with all nodes awake at all times, there is no basis for 
which to perform traditional Neighbor Discovery tasks such as DAD and 
NUD, furthermore it is a very useful thing for at least one node in a 
LoWPAN (the Edge Router) to actually know which IPv6 addresses are in use.

RFC4861 ND makes use of quite a few information caches already now 
(neighbor cache, destination cache etc.). A whiteboard is just one more 
cache in ND, so it shouldn't be made into something strange. Instead of 
requiring all nodes to carry a ND caches about all neighbors and 
destinations, we reduce that and just require one or a few edge routers 
to have a whiteboard cache.

> require a whiteboard, especially if only EUI64 are being

In a Simple LoWPAN, the whiteboard really is just a simple cache, not 
that different from a neighbor cache. Regarding implementation, we have 
it implemented on a CC2430 without a problem.

The reason why we made it a built-in feature - was that having it 
optional was adding more implementation complexity for nodes than 
justified, it makes this easier to understand, and ND for 6LoWPAN is 
pretty useless without it.

Considering that the vast majority of the time an edge router also has a 
complete IPv6 stack(!) this is not something to worry about. For ad-hoc 
cases where you configure a router to host a whiteboard - I also don't 
see a problem from experience - you have several other caches already 
and the size of a LoWPAN would often be small. Anyways, even in ad-hoc 
networks you often have a natural node with more memory (which is what 
we are talking about here, not processing power).

As Carsten already pointed out, LoWPANs are stub networks, so you don't 
have routers routing between LoWPANs directly. Instead nodes would join 
both LoWPANs.

- Zach

                         -Richard Kelsey

-- 
http://www.sensinode.com
http://zachshelby.org - My blog “On the Internet of Things”
Mobile: +358 40 7796297

Zach Shelby
Head of Research
Sensinode Ltd.
Kidekuja 2
88610 Vuokatti, FINLAND

This e-mail and all attached material are confidential and may contain 
legally privileged information. If you are not the intended recipient, 
please contact the sender and delete the e-mail from your system without 
producing, distributing or retaining copies thereof.

---

From: Rene Struik <[email-masked]>
Date: Wed, 10 Jun 2009 11:02:18 -0400

Hi Zach:

A small note: With 802.15.4-2006, incoming traffic is discarded if it is destined for a PAN with Id unequal to macPANId (cf. Clause 7.5.6.2, 3rd level filtering). If so, a node can only be part of two networks if one sets the PAN Id to the broadcast PAN identifier (0xffff). In my mind, this needs fixing, since this would make it harder to partition a bigger network according to PANId: one needs to filter on a set of PANIds instead. An example of the latter would be two PANIds: one for the ordinary network and one for a 2-node network between a node and, e.g., a remote control/configuration tool.

Best regards, Rene

== 

Rene

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Zach Shelby
Sent: Wednesday, June 10, 2009 10:48 AM
To: Richard Kelsey
Cc: Carsten Bormann; [email-masked]
Subject: Re: [6lowpan] [Fwd: New Version Notification for draft-ietf-6lowpan-nd-03]

Hi,

- Zach

                         -Richard Kelsey

-- 
http://www.sensinode.com
http://zachshelby.org - My blog "On the Internet of Things"
Mobile: +358 40 7796297

Zach Shelby
Head of Research
Sensinode Ltd.
Kidekuja 2
88610 Vuokatti, FINLAND

---

From: Jonathan Hui <[email-masked]>
Date: Wed, 10 Jun 2009 08:17:39 -0700

Hi Zach,

On Jun 10, 2009, at 7:47 AM, Zach Shelby wrote:
> transitive link with all nodes awake at all times, there is no basis  
> for which to perform traditional Neighbor Discovery tasks such as  
> DAD and NUD, furthermore it is a very useful thing for at least one  
> node in a LoWPAN (the Edge Router) to actually know which IPv6  
> addresses are in use.

Let's be a bit more precise on this statement. In a route-over  
network, the whiteboard is primarily just for detecting collisions.  
Address resolution, NUD, router discovery, etc. has nothing to do with  
the whiteboard. In a mesh-under network, I'd still argue that the  
whiteboard has nothing to do with NUD, router discovery, etc - but  
could help with address resolution.

> (neighbor cache, destination cache etc.). A whiteboard is just one  
> more cache in ND, so it shouldn't be made into something strange.  
> Instead of requiring all nodes to carry a ND caches about all  
> neighbors and destinations, we reduce that and just require one or a  
> few edge routers to have a whiteboard cache.

I disagree that the whiteboard is simply a cache. Traditionally, a  
cache allows you to make a performance tradeoff. With cache's, it's OK  
to have no cache at all - if you are willing to accept the performance  
hit of a cache miss every time. The whiteboard, on the other hand,  
needs to maintain state about all nodes in the network - or it will  
not properly implement DAD.

> In a Simple LoWPAN, the whiteboard really is just a simple cache,  
> not that different from a neighbor cache. Regarding implementation,  
> we have it implemented on a CC2430 without a problem.

The whiteboard is a simple mechanism (but not cache) to implement. But  
complexity is often not just an implementation issue. It's another  
mechanism that a network designers/maintainers need to worry about.  
It's another pile of state placed somewhere in the network. Looking at  
history, same thing happened with DHCP. At a high-level, the  
whiteboard is not much different than a simple DHCP server handing out  
addresses with leases. But IPv6 developed SLAAC for a reason - because  
it removed the need for another component in the network - not because  
it was hard to implement. So we should not be narrow-minded in just  
looking at implementation aspects.

> Considering that the vast majority of the time an edge router also  
> has a complete IPv6 stack(!) this is not something to worry about.  
> For ad-hoc cases where you configure a router to host a whiteboard -  
> I also don't see a problem from experience - you have several other  
> caches already and the size of a LoWPAN would often be small.  
> Anyways, even in ad-hoc networks you often have a natural node with  
> more memory (which is what we are talking about here, not processing  
> power).
>
> As Carsten already pointed out, LoWPANs are stub networks, so you  
> don't have routers routing between LoWPANs directly. Instead nodes  
> would join both LoWPANs.

Note that I'm not disagreeing that the whiteboard can be very useful  
for DAD. Just wanted to make sure we're on the same page as what the  
whiteboard is and what it provides.

--
Jonathan Hui

> This e-mail and all attached material are confidential and may  
> contain legally privileged information. If you are not the intended  
> recipient, please contact the sender and delete the e-mail from your  
> system without producing, distributing or retaining copies thereof.

---

From: Zach Shelby <[email-masked]>
Date: Wed, 10 Jun 2009 18:53:43 +0300

Hi,

Yep, we are basically on the same page. I am just trying to find good 
analogies ;-)

Jonathan Hui wrote:
>> for which to perform traditional Neighbor Discovery tasks such as DAD 
>> and NUD, furthermore it is a very useful thing for at least one node 
>> in a LoWPAN (the Edge Router) to actually know which IPv6 addresses 
>> are in use.
> 
> Let's be a bit more precise on this statement. In a route-over network, 
> the whiteboard is primarily just for detecting collisions. Address 
> resolution, NUD, router discovery, etc. has nothing to do with the 
> whiteboard. In a mesh-under network, I'd still argue that the whiteboard 
> has nothing to do with NUD, router discovery, etc - but could help with 
> address resolution.

The whiteboard can also be used for NUD across the whole LoWPAN, you are 
correct that DAD is the main purpose. The whiteboard also enables 
extended LoWPAN topologies (which is where the idea originally comes 
from, the BbR draft from Pascal). Furthermore the whiteboard gives an ER 
some valuable information about which IPv6 addresses are in the LoWPAN 
for filtering, management etc.

Additionally we have some ideas for security which the whiteboard may be 
able to help with in the future (to enable a kind of SEND).

> I disagree that the whiteboard is simply a cache. Traditionally, a cache 
> allows you to make a performance tradeoff. With cache's, it's OK to have 
> no cache at all - if you are willing to accept the performance hit of a 
> cache miss every time. The whiteboard, on the other hand, needs to 
> maintain state about all nodes in the network - or it will not properly 
> implement DAD.

Cache may be a bad analogy, I see your point. It is very similar to a 
binding cache in MIPv6, and it does keep (soft) state about all IPv6 
addresses registered to it.

>> that different from a neighbor cache. Regarding implementation, we 
>> have it implemented on a CC2430 without a problem.
> 
> mechanism that a network designers/maintainers need to worry about. It's 
> another pile of state placed somewhere in the network. Looking at 
> history, same thing happened with DHCP. At a high-level, the whiteboard 
> is not much different than a simple DHCP server handing out addresses 
> with leases. But IPv6 developed SLAAC for a reason - because it removed 
> the need for another component in the network - not because it was hard 
> to implement. So we should not be narrow-minded in just looking at 
> implementation aspects.

Right. Just brought up the implementation aspect as an example, I 
remember Richard asked about that.

There is no state in a whiteboard that a network administrator would be 
involved with. It is unlike DHCP, but more like a MIPv6 binding. There 
are no addresses being doled out. Nodes register a binding with the ER. 
The address generation function is stateless - requiring no 
administration. A node could (and may very well) generate its own 
address and register it with the same result (possibly needing more 
NR/NC exchanges).

Agreed that we would not want a new component in the network, ERs 
already exist, and they will already implement ND on their 6lowpan 
interfaces. You would not install a "Whiteboard Server" somewhere in 
your network, it comes built-into the 6lowpan interface driver on an ER 
for example. Humans would not be in the loop here.

>> Considering that the vast majority of the time an edge router also has 
>> a complete IPv6 stack(!) this is not something to worry about. For 
>> ad-hoc cases where you configure a router to host a whiteboard - I 
>> also don't see a problem from experience - you have several other 
>> caches already and the size of a LoWPAN would often be small. Anyways, 
>> even in ad-hoc networks you often have a natural node with more memory 
>> (which is what we are talking about here, not processing power).
>>
> Note that I'm not disagreeing that the whiteboard can be very useful for 
> DAD. Just wanted to make sure we're on the same page as what the 

Yep, DAD is the core feature.

So apart from a generic discussion about whiteboards - how about we 
concentrate on technical details. As a WG we really need to check that 
all the fine details here work - and if not suggest a way to fix/improve 
them. We would like to submit -04 before the Stockholm cutoff.

>> please contact the sender and delete the e-mail from your system 
>> without producing, distributing or retaining copies thereof.

Zach Shelby
Head of Research
Sensinode Ltd.
Kidekuja 2
88610 Vuokatti, FINLAND

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 10 Jun 2009 18:34:25 +0200

> The whiteboard can also be used for NUD across the whole LoWPAN,

A very slow NUD.

Note that the role of NUD is pretty much fulfilled by 802.15.4 link- 
layer ACKs in a LoWPAN.

> There are no addresses being doled out.

Only a little bit :-) (16-bit short addresses.)  But the node keeps  
the state and refreshes regularly.

When an ER reboots that tends to forget the whiteboard, it might hand  
out an address that is in use by another node before that happens to  
refresh.

Gruesse, Carsten

---

From: Jonathan Hui <[email-masked]>
Date: Wed, 10 Jun 2009 10:09:05 -0700

Hi Zach,

On Jun 10, 2009, at 8:53 AM, Zach Shelby wrote:
> The whiteboard can also be used for NUD across the whole LoWPAN, you  
> are correct that DAD is the main purpose. The whiteboard also  
> enables extended LoWPAN topologies (which is where the idea  
> originally comes from, the BbR draft from Pascal). Furthermore the  
> whiteboard gives an ER some valuable information about which IPv6  
> addresses are in the LoWPAN for filtering, management etc.

I don't see the whiteboard as a good substitute for NUD - the  
whiteboard knows it has heard from a node, but doesn't know that it  
can actually communicate with that node. Using the whiteboard for NUD  
also assumes that you mesh through the whiteboard. Note that using the  
whiteboard for NUD is only really useful in mesh-under networks. For  
route over, NUD using the whiteboard doesn't make any sense to me.

ND proxy is the real mechanism that enables extended LoWPAN  
topologies. But again, a number of mechanisms in the BbR draft were  
intended for mesh-under networks. In a route-over network, the  
whiteboard isn't necessary to maintain routes.

> There is no state in a whiteboard that a network administrator would  
> be involved with. It is unlike DHCP, but more like a MIPv6 binding.  
> There are no addresses being doled out. Nodes register a binding  
> with the ER. The address generation function is stateless -  
> requiring no administration. A node could (and may very well)  
> generate its own address and register it with the same result  
> (possibly needing more NR/NC exchanges).

I guess we have different view points on this. In my mind, the  
whiteboard is very similar to DHCP. The whiteboard is telling a node  
whether or not it is OK to use an address, that is logically the same  
as assigning the node that address. The whiteboard may assign a 16-bit  
short address, for use with an IP address - that is exactly the same  
as assigning the node that address.

> your network, it comes built-into the 6lowpan interface driver on an  
> ER for example. Humans would not be in the loop here.

The vast majority of DHCP servers in use today don't require any real  
network administration either. How many consumers really change the  
DHCP settings on their $50 linksys router? But when something does go  
wrong (e.g. dhcp server does not properly hand out addresses), those  
consumers are left to wonder. The whiteboard (DHCP server) is another  
component in the network, whether or not it is co-located on the ER  
(linksys router).

> concentrate on technical details. As a WG we really need to check  
> that all the fine details here work - and if not suggest a way to  
> fix/improve them. We would like to submit -04 before the Stockholm  
> cutoff.

Agreed. We should get as much feedback as we can.

--
Jonathan Hui

---

From: Jonathan Hui <[email-masked]>
Date: Wed, 10 Jun 2009 10:15:05 -0700

Hi Carsten,

> Note that the role of NUD is pretty much fulfilled by 802.15.4 link- 

Only partially, the role of NUD is really to verify reachability at L3.

> the state and refreshes regularly.

Agree. This is not terribly different to DHCP leases in my mind.

> When an ER reboots that tends to forget the whiteboard, it might  
> hand out an address that is in use by another node before that  
> happens to refresh.

And "hand out an address" includes both EUI-64 and 16-bit short  
addresses.

--
Jonathan Hui

---

From: Richard Kelsey <[email-masked]>
Date: Wed, 10 Jun 2009 14:39:15 -0400

Date: Wed, 10 Jun 2009 18:53:43 +0300
   From: Zach Shelby <[email-masked]>

Zach,

Requiring that Edge Routers have a whiteboard was a
significant change from -02 to -03.  I am concerned because
the whiteboard is a single point of failure and because of
the memory required to store it.

Yes, if an Edge Router has a full IPv6 stack, or generally
has plenty of memory, it should certainly have a whiteboard.
In an extended LoWPAN, the Edge Routers clearly have to
have whiteboards.  My concern is with ad-hoc networks of
small devices.

It looks to me as if a whiteboard entry requires at least 20
bytes or so, or 2k bytes for a 100-node network.  Fitting
that into an embedded device with, say, 6k of RAM is going
to be difficult.  If the core benefit is detecting duplicate
EUI64s, it really doesn't seem worth the trouble.  As I
mentioned before, having the Edge Router assign 16-bit IDs
helps with header compression, but is not required for
routing.

As to the technical details, if DAD is the main purpose of
the whiteboard, it seems to me that it might be able to do
so in a more timely fashion.  As I understand the protocol,
if a second node appears with the same EUI64 as a device
already in the network, the collision will not be detected
until the existing device renews its registration.  The
first appearance of the new device will be treated as a
reboot by the original one.  Would it be OK to require that
routers keep address data in non-volatile memory?  If not,
is the collision going to have to be re-detected every time
the colliding device reboots?

By the way, if two devices with the same EUI64 are powered
up or reboot at the same time, it looks to me as if the
conflict might never be detected.  Assuming that the Edge
Router gives them the same registration lifetimes, the two
TIDs will move forward in leap frog fashion, never getting
more than one removed from each other.

                                  -Richard Kelsey

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 10 Jun 2009 21:31:40 +0200

> more than one removed from each other.

I thought that for a while, too.
However, a registration with the same TID is defined to cause a  
conflict.
So if the nodes don't manage to exactly synchronously alternate in  
losing packets, eventually the conflict will be detected.

Unless we require hosts to be awake enough to defend their addresses,  
there is no discernable difference between a reboot and a conflict of  
a new node with a sleeping node.  So it will be hard to enable  
detection immediately after switching on the colliding node.

Gruesse, Carsten

---

From: Zach Shelby <[email-masked]>
Date: Wed, 10 Jun 2009 22:53:17 +0300

Hi,

> the memory required to store it.

I called out to the list before making the change, didn't hear 
complaints, sorry if you missed that.

> have whiteboards.  My concern is with ad-hoc networks of

Got you, so its just the ad-hoc case that worries you... For Simple 
LoWPAN and Extended LoWPAN cases the whiteboard should definitely be a 
built-in feature.

I agree that the ad-hoc case is a question mark. In the previous version 
it was discussed that a router in the Ad-hoc LoWPAN could optionally be 
configured with a whiteboard, and thus provide the services that a 
Simple LoWPAN does. At the minimum some router in the Ad-hoc LoWPAN MUST 
be configured to generate a ULA prefix and disseminate that to other 
routers.

The problem we got into, was how to advertise and detect if a whiteboard 
is supported or not as it was also optional for Simple LoWPANs. So if 
there would be no whiteboard in an Ad-hoc LoWPAN, how would a node 
detect there is no whiteboard feature, and then operate after that? In 
practice you would then have no ER at all in an Ad-hoc LoWPAN.
1. We do have an error code (code 129) which a router can respond with 
to tell a node that no ER is available, so trial and error?
2. Or would we define that if a node sees an RA with a ULA prefix, then 
it assumes there is no whiteboard? Then there really is no whiteboard 
support at all in an Ad-hoc LoWPAN.. fine by me.
3. Or routers in an Ad-hoc LoWPAN could set the M flag to 0 in the RA to 
indicate if there is no ER.
4. Or all of the above?
I would say that #3 is the most logical. And #2 would also be a behavior 
in case a node did try to register.

Then there is the question of how an Ad-hoc LoWPAN really functions 
after that. All addresses would stay optimistic, we would probably need 
to require node to implement NS/NA (now not required, and which don't 
work well over multiple hops and with sleeping nodes), you would be 
stuck with EUI-64 optimistic addresses (and pray they are unique), and 
short-address assignment is out of scope. We would almost be falling 
back to RFC4861 - although 6lowpan-nd still has some useful 
simplifications for this case as well.

What do others think, is this a concern? Do we just run Ad-hoc LoWPANs 
with no ER at all by default? If so, what is the simplest way to detect 
this, and are you happy with how the network will function after this?

- Zach

> the colliding device reboots?

The collision is detected immediately in that case. With the TID you 
would allow the first one to continue operating. So the newer one loses. 
Agreed that we need to go over all the cases in detail again, surely 
there are still some bugs.

> more than one removed from each other.

That could theoretically occur, any suggestions how to avoid that?

With Carsten we have noticed some other fine points to improve in the 
DAD mechanism using TIDs, so all suggestions helpful.

We also need to detail the registration rules for addresses better to 
avoid any problems there (a ticket on that is coming).

Thanks,
Zach

Zach Shelby
Head of Research
Sensinode Ltd.
Kidekuja 2
88610 Vuokatti, FINLAND

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 10 Jun 2009 21:59:34 +0200

On Jun 10 2009, at 21:53, Zach Shelby wrote:

> 3. Or routers in an Ad-hoc LoWPAN could set the M flag to 0 in the  
> RA to indicate if there is no ER.

Right, they already have to do that.
So no M-flag, no NR.

> after that. All addresses would stay optimistic, we would probably  
> need to require node to implement NS/NA

That is an absolute show-stopper.  Making hosts more complex so you  
can save a couple bytes in an ER is a no-no.

Since I think that the NR will also play an important role in  
bootstrapping the routing, the hope to get by without an ER seems to  
be wishful thinking.

"just pray" mode could be specified for nodes that experience an M=0  
world.
All communciation should stay link-local.
The routing protocol won't come up anyway, I'd think.

Gruesse, Carsten

---

From: Richard Kelsey <[email-masked]>
Date: Wed, 10 Jun 2009 17:46:04 -0400

From: Carsten Bormann <[email-masked]>
   Date: Wed, 10 Jun 2009 21:31:40 +0200

In section 7.7, if TID1 is equal to TID2 are the two
consistent?  In other words does zero count as a small
increment/decrement?

If receiving the same TID twice is treated as an OII
collision, what mechanisms are there for detecting
duplicate packets?

Now that I have just read 7.7 again, at the very end it
says:

   If the new value is not consistent with a recent value
   saved in the whiteboard entry then it is rejected as a
   collision.

>From context, I think "rejected as a collision" means that
the TID does not indicate a collision and thus is accepted,
but the wording could be clearer.

That is certainly true if hosts have no available
non-volatile storage.  Even if they do have such storage, it
isn't clear how much it would help to make use of it.

                            -Richard Kelsey

---

From: Richard Kelsey <[email-masked]>
Date: Wed, 10 Jun 2009 18:19:28 -0400

Date: Wed, 10 Jun 2009 22:53:17 +0300
   From: Zach Shelby <[email-masked]>

   Richard Kelsey wrote:

   > As I understand the protocol,

   The collision is detected immediately in that case. With
   the TID you would allow the first one to continue
   operating. So the newer one loses.

I don't see why it is detected immediately if the
conflicting device reboots.  How are post-reboot
registrations by the conflicting device any different from
when it registers the first time?

   > more than one removed from each other.

   That could theoretically occur, any suggestions how to
   avoid that?

Carsten wrote:

  I thought that for a while, too.  However, a registration
  with the same TID is defined to cause a conflict.  So if
  the nodes don't manage to exactly synchronously alternate
  in losing packets, eventually the conflict will be
  detected.

I don't know who is right.
                                    -Richard Kelsey

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 11 Jun 2009 00:20:48 +0200

> consistent?  In other words does zero count as a small

You are right that the text is not explicit about that.

> collision, what mechanisms are there for detecting

Good point.

Well, I think the lollipop text needs some more work.

Gruesse, Carsten

---

From: Hamid Mukhtar <[email-masked]>
Date: Thu, 11 Jun 2009 08:31:45 +0900

Hi Carsten,

SNMP based network management is also critical for 6LoWPANs. If the working
group is considering rechartering soon, this meeting would be a nice time to
discuss that too.

Regards,
Hamid

On Wed, Jun 10, 2009 at 6:12 PM, Carsten Bormann <[email-masked]> wrote:

> It very much *is* in the scope right now to have a problem
> statement/security analysis that prepares this.
>
> To quote:
>
> So if an argument can be made that e.g. frame counter synchronization is a
> good way to solve replay, let's go ahead and write this up.
>
> Gruesse, Carsten
>
>

---

From: Hamid Mukhtar <[email-masked]>
Date: Thu, 11 Jun 2009 08:32:38 +0900

Hi Carsten,

Regards,
Hamid

---

From: Brian Frank <[email-masked]>
Date: Wed, 10 Jun 2009 21:15:31 -0400

I think an UDP-based application level protocol that works well over
6LoWPANs and with sleeping nodes is a sorely lacking feature.  However, I am
not sure SNMP is the best starting point.

---

From: Hamid Mukhtar <[email-masked]>
Date: Thu, 11 Jun 2009 12:28:56 +0900

SNMP is widely used for management and monitoring of IP networks and
it's deployment would also ensure re-usability of the existing
established network management tools.
A possible investigation to determine the usability of SNMPv3 (or an
appropriate adaptation of it) is needed.
Moreover, SNMP is deployable in 6LoWPANs and three basic deployment
models may be possible for SNMP given 6LoWPANs.

1.  Lightweight E2E
The SNMP manager talks SNMPv3 end-to-end to the nodes. (Adaptations
may be needed by specifying suitable deployment parameters through an
Applicability Statement).

       Manager <-------------------------------------> 6LoWPAN nodes
                              SNMPv3
2.  Proxy Model
The SNMP manager talks SNMPv3 to an SNMP proxy residing on the 6LoWPAN
Gateway (or a proxy server). Existing management tools (as long as
they are proxy aware) can be reused. In this model, 6LoWPAN adaptation
layer may not be strictly needed since SNMP can run over directly over
IEEE 802 networks [RFC4789].

     Manager <-------->    SNMP Proxy   <--------------> 6LoWPAN nodes
               SNMPv3  (6LoWPAN Gateway)     SNMPv3

3.  SNMP with Sub-Agent Protocols
The SNMP manager talks SNMPv3 to an extensible SNMP agent residing on
the 6LoWPAN router which uses a subagent protocol (e.g. a 6LoWPAN
enhanced version of AgentX) to populate its MIB.  In this scenario,
6LoWPAN adaptation layer may not actually be needed since such
subagent protocol can also run directly over 802.15.4.  However, the
current standard subagent protocol has to be optimized for 6LoWPAN.

    Manager <------->   SNMP Agent    <-----------------> 6LoWPAN nodes
              SNMPv3 (6LoWPAN Gateway) SubAgent Protocol

Network Management in my opinion should certainly be considered as a
possible charter item once the group recharters.

Regards,
Hamid

On Thu, Jun 11, 2009 at 10:15 AM, Brian Frank <[email-masked]> wrote:
>
> I think an UDP-based application level protocol that works well over 6LoWPANs and with sleeping nodes is a sorely lacking feature.  However, I am not sure SNMP is the best starting point.
>
>> SNMP based network management is also critical for 6LoWPANs. If the working group is considering rechartering soon, this meeting would be a nice time to discuss that too.
>>
>> Regards,
>> Hamid
>>
>
>

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 11 Jun 2009 07:53:52 +0200

> possible charter item once the group recharters.

Hamid,

thanks, that is great input.
Would it possible for you to write up the three approaches in some  
more detail in an Internet draft before the Stockholm Internet-Draft  
deadline?

SNMP clearly is an important protocol, but has been criticized for  
LoWPAN usage for three reasons:

1) relatively expensive (implementation, bytes in packet) encoding
2) expensive security model of SNMPv3
3) "server polls" does not fit well with sleeping battery-operated  
nodes.

So solutions that address one or more of these items would be very  
welcome.

In addition, the Edge Router is a likely candidate for a MIB.
The Whiteboard certainly is one of the data structures any network  
manager would want to look at with SNMP.  Nodes might want to drop  
additional information for SNMP access there through appropriate NR  
options so they don't have to answer GETs themselves.

Gruesse, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 11 Jun 2009 07:56:17 +0200

On Jun 11, 2009, at 03:15, Brian Frank wrote:

> However, I am not sure SNMP is the best starting point.

Now, what *is* the best starting point?

One interesting submission we haven't spent much time looking at is:

http://tools.ietf.org/html/draft-tolle-cap-00

Gruesse, Carsten

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 11 Jun 2009 08:26:43 +0200

> more detail in an Internet draft before the Stockholm Internet-Draft  

http://tools.ietf.org/html/draft-hamid-6lowpan-snmp-optimizations-01

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Hamid Mukhtar <[email-masked]>
Date: Thu, 11 Jun 2009 17:23:34 +0900

Dear Carsten,

As Juergen mentioned, we already submitted an internet draft to address most
of the issues that you pointed out.
We hope to get some working group input before the meeting on the deployment
models and the optimization issues to move forward on it.

Regards,
Hamid

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 11 Jun 2009 10:55:27 +0200

At the bottom of this email there is request for more feedback on this 
topic.

I haven't checked the latest version of the draft.  I have already 
expressed the following about 6LoWPAN ND related to this discussion:

-I think it is not good the 6LoWPAN ND draft assumes it safe to convert
  a MAC address to an IPv6 address.  This effectively forbids the
  manual assignment of addresses on nodes, and DHCP too.
-I think it is not good for 6LoWPAN ND to assign full /128 addresses
  with the RA (i.e. an RA forces the receiver to configure the address
  contained in that RA).  DHCP does so already, why not using it.
-I think it is not good to have a single subnet span both the
  egressinterface of ER _and_ the LoWPAN - these should be two different
  subnets.
-I think the whiteboard concept should be clarified, or I should try to
  better understand it.

Alex

Jonathan Hui a écrit :
>> are correct that DAD is the main purpose. The whiteboard also enables 
>> from, the BbR draft from Pascal). Furthermore the whiteboard gives an 
>> ER some valuable information about which IPv6 addresses are in the 
>> LoWPAN for filtering, management etc.
> 
> I don't see the whiteboard as a good substitute for NUD - the whiteboard 
> knows it has heard from a node, but doesn't know that it can actually 
> communicate with that node. Using the whiteboard for NUD also assumes 
> that you mesh through the whiteboard. Note that using the whiteboard for 
> NUD is only really useful in mesh-under networks. For route over, NUD 
> using the whiteboard doesn't make any sense to me.
> 
> ND proxy is the real mechanism that enables extended LoWPAN topologies. 
> But again, a number of mechanisms in the BbR draft were intended for 
> mesh-under networks. In a route-over network, the whiteboard isn't 
> necessary to maintain routes.
> 
>> There are no addresses being doled out. Nodes register a binding with 
>> the ER. The address generation function is stateless - requiring no 
> whether or not it is OK to use an address, that is logically the same as 
> assigning the node that address. The whiteboard may assign a 16-bit 
> short address, for use with an IP address - that is exactly the same as 
> assigning the node that address.
> 
> network administration either. How many consumers really change the DHCP 
> settings on their $50 linksys router? But when something does go wrong 
> (e.g. dhcp server does not properly hand out addresses), those consumers 
> are left to wonder. The whiteboard (DHCP server) is another component in 
> the network, whether or not it is co-located on the ER (linksys router).
> 
>> all the fine details here work - and if not suggest a way to

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 11 Jun 2009 10:56:44 +0200

Brian Frank a écrit :
> 6LoWPANs and with sleeping nodes is a sorely lacking feature.  However, 
> I am not sure SNMP is the best starting point.

Is there a MIB (Management Information Base) effort for 6LoWPAN ND?  It 
may be too early... but MIB is necessary.

Alex

> 
> 
> On Wed, Jun 10, 2009 at 7:31 PM, Hamid Mukhtar <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     Hi Carsten,
>      
>     SNMP based network management is also critical for 6LoWPANs. If the
>     working group is considering rechartering soon, this meeting
>     would be a nice time to discuss that too.
>      
>     Regards,
>     Hamid
>      
> 
> 
> 
> ------------------------------------------------------------------------
>

---

From: Hamid Mukhtar <[email-masked]>
Date: Thu, 11 Jun 2009 18:32:13 +0900

On Thu, Jun 11, 2009 at 5:56 PM, Alexandru
Petrescu<[email-masked]> wrote:
> Is there a MIB (Management Information Base) effort for 6LoWPAN ND?  It may
> be too early... but MIB is necessary.
>

6LoWPAN MIB has already been there for a while. IPv6 ND options are
currently a part of IP-MIB likewise 6LoWPAN ND options may be added to
the 6LoWPAN MIB when the 6LoWPAN ND is finalized. However, a separate
MIB module may be needed for the white board data structure as pointed
out by Carsten.

Hamid

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 11 Jun 2009 12:10:15 +0200

Hamid Mukhtar a écrit :
>>> I think an UDP-based application level protocol that works well
>>> over 6LoWPANs and with sleeping nodes is a sorely lacking
>>> feature.  However, I am not sure SNMP is the best starting point.
>>> 
>> 
>> Is there a MIB (Management Information Base) effort for 6LoWPAN ND?
>> It may be too early... but MIB is necessary.
>> 
> 
> 6LoWPAN MIB has already been there for a while.

Do you mean draft-daniel-6lowpan-mib-00.txt?

It doesn't seem to be in the list of WG items:

> The document name you specified, "draft-ietf-6lowpan", matched multiple documents:
> 
>     sort by date sort by name
> 
>     04 Apr 2007  draft-ietf-6lowpan-format
>     08 Dec 2008  draft-ietf-6lowpan-hc
>     27 May 2009  draft-ietf-6lowpan-nd
>     02 Mar 2007  draft-ietf-6lowpan-problem
>     25 Mar 2009  draft-ietf-6lowpan-routing-requirements
>     09 Mar 2009  draft-ietf-6lowpan-usecases
> 
>     Found 6 matches.

The 6LoWPAN Charter doesn't seem to mention it either.

Alex

---

From: Hamid Mukhtar <[email-masked]>
Date: Thu, 11 Jun 2009 19:22:21 +0900

> It doesn't seem to be in the list of WG items:

Ya I was referring to the same draft which certainly isnt a working group item.
The working group isnt chartered for network management yet.
However, the draft may be considered as an interesting item once the
group recharters.

---

From: Brian Frank <[email-masked]>
Date: Thu, 11 Jun 2009 07:07:48 -0400

>  However, I am not sure SNMP is the best starting point.

Here are my thoughts on this issue...

6LoWPAN's tremendous potential is to displace the zillions of
closed, proprietary, and non-IP "standards" based protocols used for smart
devices.  As such the key problem is not network management per se, but easy
access to the information in these devices (which is typically sensor data).

There are a couple reasons that I think SNMP falls short for unlocking the
information trapped in smart devices:

  - SNMP may be commonly used by this group of engineers, but it isn't
something used very often by most software developers in their daily jobs

  - The information model for SNMP is predefined based on MIBs which is a
fairly limited type system for modeling information.

  - SNMPs basic model seems ill suited to battery powered devices which
spent most of their life sleeping

What I consider the best starting point is HTTP.  Let's assume for a second
that a gateway can compress HTTP into a suitable binary format inside UDP
packets (which I believe is quite possible).  What advantages does HTTP
have?

  - HTTP is by far the most popular protocol on the planet,
immediately familiar to just about any software developer, and with rich
APIs included in just about any programming language's toolbox

  - HTTP is the protocol of the web which makes it *the* protocol for
sharing information.  If a piece of data is going to be published on the
web, then it should have a URL.  The amazing potential of 6LoWPAN is that
every sensor on the planet can be given a URL.

  - HTTP has a sophisticated, well-known, and widely used model for caching
information.  It is my belief that caching is the best solution for dealing
with sleeping nodes, by having powered nodes serve as their HTTP caches.

 - HTTP doesn't prescribe any specific information model, rather it enables
transport of any MIME encoded data.  As an opened ended transport layer, it
enables continual evolution and innovation in how information is modeled.

Defining an application layer protocol which works well over 6LoWPAN is a
topic near and dear to my heart.  Currently, the lack of one is a real thorn
in our side to actually deploying 6LoWPAN into the real world.  Until their
is an IETF application protocol that runs well over 6LoWPAN, I think
adoption will continue to be stifled.

If there is interest, I would be glad to post a draft to start some
discussions around the idea of using compressed HTTP over 6LoWPANs.

Brian

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 11 Jun 2009 13:17:18 +0200

On Thu, Jun 11, 2009 at 12:22:21PM +0200, Hamid Mukhtar wrote:
 
> Ya I was referring to the same draft which certainly isnt a working
> group item.  The working group isnt chartered for network management
> yet.  However, the draft may be considered as an interesting item
> once the group recharters.

The WG needs to define and agree on the problem that is to be solved.
Technically, I can imagine to make SNMP a first class citizen on a
6LowPAN node but I can equally well imagine that SNMP sits on a device
connecting a 6LowPAN cloud to the Internet and uses other (subagent,
proxy, ...) protocols to interact with 6LowPAN nodes. There are
different solutions possible but it really boils down to what the
problem is that is to be solved if you want to select one of the
approaches.

I assume many 6LowPAN devices simply want to carry as few protocols as
possible. But on the other hand, the claimed benefits of 6LowPAN (RFC
4919) are among other things are that existing tools and IP network
technologies can be reused and 6LowPAN does not need intermediate
entities like translation gateways or proxies...

Personally, if I were to put SNMP (or any other protocol for that
matter) on a 6LowPAN device, I would try to use it for as many tasks
as possible. Having multiple protocols on a 6LowPAN device for
different purposes appears to be a costly idea to me.

/js

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 11 Jun 2009 13:36:37 +0200

Brian,

I think pointing to HTTP is very good thinking.

You are actually selling it short:

> every sensor on the planet can be given a URL

It's the *resource* on the sensor that is given a URL.
One sensor may (and is likely to have) multiple resources.

The following are some of the problems we would have to work on with  
HTTP:

-- uses TCP (easily fixed for small data units)
-- HTTP headers use chatty encoding (fixable)
-- HTTP uses request-response, not push (many ways to fix, need to  
select one/some)
-- security

Gruesse, Carsten

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 11 Jun 2009 13:58:30 +0200

Hi Carsten:

All this makes a lot of sense to me. At some point though, it appears
that the work belongs to another area. 

Would there be a way for 6LoWPAN to trigger/sponsor work in
http://www.apps.ietf.org/  about compressed web services for use in
LoWPANs? 

If that was to succeed the next question would be whether that would be
relevant to manage the device as well, and the answer would probably be
yes...

Pascal

>Sent: jeudi 11 juin 2009 13:37
>To: Brian Frank
>Cc: Hamid Mukhtar; [email-masked]

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 11 Jun 2009 14:08:51 +0200

> http://www.apps.ietf.org/  about compressed web services for use in

Not all work we spawn will be in INT area.
Say, a key management protocol might spawn a small WG in SEC.
ROLL already is in RTG.
So why not spawn a WG in APP?
But let's first demonstrate the need, the interest and the feasibility.
The ADs will then sort out where the work should go.

The hard part is just to make sure we are not getting our requirements  
diluted in that other venue -- for example, I would seriously object  
if any 6LoWPAN-related HTTP work would be bundled up with a general  
"binary HTTP" effort.

Gruesse, Carsten

---

From: Zach Shelby <[email-masked]>
Date: Thu, 11 Jun 2009 15:29:20 +0300

Hi,

Great discussion, I agree that embedded web-services and HTTP in general 
  are important to develop for 6LoWPAN. Plus service discovery, 
management etc.

I have actually been thinking that we need to continue on two fronts as 
well, and agree with Carsten completely:

1. Recharter 6lowpan to take care of security and other INT area 
improvements that have been identified.

2. Create a 6lowapp WG in the APP area which would work on application 
protocol improvements for use over 6LoWPAN and other similar limited 
frame/bandwidth networks.

Anyways, #2 is something I am really interested to work on.

- Zach

Carsten Bormann wrote:
> diluted in that other venue -- for example, I would seriously object if 
> any 6LoWPAN-related HTTP work would be bundled up with a general "binary 
> HTTP" effort.
> 
> Gruesse, Carsten
> 

Zach Shelby
Head of Research
Sensinode Ltd.
Kidekuja 2
88610 Vuokatti, FINLAND

---

From: "Don Sturek" <[email-masked]>
Date: Thu, 11 Jun 2009 05:31:12 -0700

Hi Brian,

We are developing a Smart Meter application (using 6LowPAN and assuming
ROLL) which could definitely use a compact, binary message exchange protocol
like your proposal below using HTTP using UDP.

I know this conversation is a bit early but would it be possible to explore
this work a bit further?   We will need to select some technology fairly
soon and it would be a shame not to consider HTTP as a starting point.

Best Regards,

Don Sturek

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Brian Frank
Sent: Thursday, June 11, 2009 4:08 AM
To: Carsten Bormann
Cc: Hamid Mukhtar; [email-masked]
Subject: Re: [6lowpan] ND and MAC-level security

 

6LoWPAN's tremendous potential is to displace the zillions of closed,
proprietary, and non-IP "standards" based protocols used for smart devices.
As such the key problem is not network management per se, but easy access to
the information in these devices (which is typically sensor data).  

  - HTTP is by far the most popular protocol on the planet, immediately
familiar to just about any software developer, and with rich APIs included
in just about any programming language's toolbox

Brian

---

From: "Don Sturek" <[email-masked]>
Date: Thu, 11 Jun 2009 05:45:57 -0700

Hi Carsten,

I am not so sure the CAP I-D is the best starting point.   CAP is based on
ZigBee service discovery which assumes statically held service information
and a compact set of query primitives each device can use to determine
compatible application services.

In a later thread, there was mention of a variation of HTTP using binary
encoding (mapped to XML I would presume) and running over UDP.  This would
seem to be an elegant start to a service discovery protocol for 6LowPAN
devices.  It would be nice as well to have a caching scheme so sleepy
devices could contribute their service information and make it visible
without needing to be awake all the time to do so.

Other alternatives could include using another tokenized XML solution like
W3C EXI, OBiX, etc with some type of caching solution like those supported
in SLP or SDDP.

I think this really does not below in 6LowPAN though.  Perhaps we could ask
for formation of a group in in the Application area to address?

Best Regards,
Don Sturek

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Carsten Bormann
Sent: Wednesday, June 10, 2009 10:56 PM
To: Brian Frank
Cc: Hamid Mukhtar; [email-masked]
Subject: Re: [6lowpan] ND and MAC-level security

Gruesse, Carsten

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 11 Jun 2009 14:53:30 +0200

>as assigning the node that address.

Hi Jonathan:

Looks so alike and still is so fundamentally different. Ralph explained
that in SFO a lot better than I can ever do but that has to do with the
model below. 

In DHCP, the server owns the address and lends it away. You have to get
back to that server to renew the binding. In whiteboard, the nodes owns
the address and registers it where it wants, or anywhere (anycast). 

When we do SeND, that distinction might blur quite a bit but still, the
white board acts on behalf of the node so it does not hold any master
state (like a pool with LRI etc...) after the node is gone.

Pascal

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 11 Jun 2009 15:00:39 +0200

Hi Jonathan;

The Whiteboard lost quite a bit of its value when route over was added
to the picture, that is true. I think that the value of a more generic
solution compensates largely. The Whiteboard still serves its main
purpose, that is to save multicast flows and let the node sleep when
they need to. But NUD, Redirect, and first hop security are either
distributed or replaced by services from the routing world (routing
updates and ICMP unreachable). Guess what, the result is in fact a lot
more compatible with NBMA at large.

What might be misunderstood reading your (correct) words is how
important and complex DAD can be in a LoWPAN. We want to enable a node
mobility within the subnet and we want it as part of the base mechanism,
with no renumbering, no additional discovery, no MIP tunnel, no P-MIP in
the LoWPAN routers, and whether the node uses the same edge router or
moves to a different one. So a big question in DAD is whether this is
the same node that moved or rebooted, or a different node coming in. And
the whiteboard is responsible to figure that out, in a distributed
manner when you have a backbone.

Then there's first hop security. In the mesh under model, that is
something that the edge router could handle and it still has its value
in route over though the LoWPAN router could be asked to do their share
- that piece of the design is not completed yet. Then as Zach mentioned,
there is SeND. A economical way for the device to get SeND over the
backbone would be to use the white board to compute the CGA in the first
place so the white board can defend it later as part of the ND proxy
operation.

Finally there's global mobility. We could easily use the white board
registration as a MIP6/NEMO proxy HA binding (not P-MIP but rather
Global HAHA type proxy). The Whiteboard would operate as a proxy for the
ND protocol and handle all the route optimization flows on behalf of the
node. Remind me to ask you about IPinIP compression in HC :)

So I fully support the change - that I did not trigger - to make the
Whiteboard a mandatory feature of the edge router. Still I understand we
need to work on the flows where the White board is saturated, see about
DoS attacks etc...

Cheers,

Pascal

>From: [email-masked] [mailto:[email-masked]] On
Behalf Of Jonathan Hui
>Sent: mercredi 10 juin 2009 17:18
>To: Zach Shelby

---

From: Richard Kelsey <[email-masked]>
Date: Thu, 11 Jun 2009 09:02:50 -0400

Zach,

I don't think it would make sense to not have an ER in an ad
hoc LoWPAN.  As you said, some router must generate a ULA
prefix and disseminate it, so there should be an ER.
I am hoping that we can come up with a way to run large
ad hoc networks of (exclusively) small devices without
any major perturbations to the protocol.

The whiteboard is used for assigning 16-bit addresses and
for detecting collisions in OIIs (usually derived from
EUI64s).  Even with a whiteboard, OII collision detection is
somewhat problematic in that there can be a significant
delay during which the colliding devices will be using the
same address(es).  Would it be acceptable for the ER in an
ad hoc network to maintain only a partial whiteboard
containing some fraction of the networks OIIs?  This would
increase the delay before an OII conflict was detected, but
the network would otherwise behave as if the ER had a full
whiteboard.

Having globally-unique 16-bit addresses helps with header
compression.  Typically, all or most of the traffic in a
LoWPAN is either to or from one of a small number of nodes.
Ideally, in a large ad hoc network of small devices the ER
could assign globally-unique 16-bit addresses to only the
high-traffic devices (including itself).  This could be done
by adding a 1-bit flag to address options in order to
indicate that the requesting host is a high- traffic device.
The flag would be only be set if the A (address generation)
flag were also set.  A memory-poor ad hoc ER would use the
flag in deciding which address generation requests to honor.
All other ERs would ignore the flag and always generate an
address.

In summary, if an ad hoc ER lacks sufficient memory for a
full whiteboard, we would see the following:
 - An increased delay in detecting OII collisions.
 - Not all requests for address generation would
   be honored; preference would be given for hosts
   indicating that they were high traffic devices.
 - Some loss in header compression for packets to
   or from hosts that did not receive 16-bit
   addresses.
 - Local (one hop) detection and repair of 16-bit
   addresses at the link layer, presumably done in
   conjunction with link-layer security.

                           -Richard Kelsey

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 11 Jun 2009 15:13:03 +0200

Brian Frank a écrit :
> 
> 
> On Thu, Jun 11, 2009 at 1:56 AM, Carsten Bormann <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>  proprietary, and non-IP "standards" based protocols used for smart 
> devices.  As such the key problem is not network management per se, 
> but easy access to the information in these devices (which is 
> typically sensor data).
> 
> There are a couple reasons that I think SNMP falls short for 
> unlocking the information trapped in smart devices:
> 
> - The information model for SNMP is predefined based on MIBs which is
>  a fairly limited type system for modeling information.
> 

Some deployed SNMP-like databases do have currently parameters related
to power consumption, at least.

> What I consider the best starting point is HTTP.

I agree it's worth considering seriously.

But one point: the main HTTP semantics (unicast GET/POST/PUT) wouldn't
fit a single-multicast request multiple-unicast response semantics, used
for example when querying a set of sensors.  I am not sure how you see it...

> Let's assume for a second that a gateway can compress HTTP into a 
> suitable binary format inside UDP packets (which I believe is quite 
> possible).  What advantages does HTTP have?
> 
>  familiar to just about any software developer, and with rich APIs 
> included in just about any programming language's toolbox

Neither the C Library nor the C++ Standard Template Library include http
calls... not sure what you mean.  Do you mean Java and family?

> sharing information.  If a piece of data is going to be published on 
> the web, then it should have a URL.  The amazing potential of 6LoWPAN
>  is that every sensor on the planet can be given a URL.

A URL yes, but an http server on a sensor?

> - HTTP has a sophisticated, well-known, and widely used model for 
> caching information.  It is my belief that caching is the best 
> solution for dealing with sleeping nodes, by having powered nodes 
> serve as their HTTP caches.
> 
> - HTTP doesn't prescribe any specific information model, rather it 
> enables transport of any MIME encoded data.  As an opened ended 
> transport layer, it enables continual evolution and innovation in how
>  information is modeled.

Does HTTP work with multicast addresses?

> Defining an application layer protocol which works well over 6LoWPAN 
> is a topic near and dear to my heart.  Currently, the lack of one is 
> a real thorn in our side to actually deploying 6LoWPAN into the real 
> world. Until their is an IETF application protocol that runs well 
> over 6LoWPAN, I think adoption will continue to be stifled.
> 

Let's see let's see, sounds interesting.

Alex

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 11 Jun 2009 16:13:54 +0200

Hi:

The text can definitely be improved. But Mostly we need something that
works with all cases covered.

Section 7.6 Address collision detection and resolution

Seems we are missing text when the binding is for the same edge router
different OII. This is a collision and causes a reject exactly like NA
(different OII) during DAD.

The text also says that upon positive re-registration, the edge router
SHOULD set O in NA. This is misworded, in fact it SHOULD send NA(O) as a
refresher and eventually a tie breaker if for some reasons (missed DAD)
incompatible states have setup. An edge router with a registration
should clean up at that point.

Section 7.7 Duplicate OII detection

As Richard said we need to be more precise on equal TID. That must be
treated as a collision otherwise we'll flip flap forever. 

But then is if there is a risk of a packet getting duplicated over the
network we might be doing the wrong thing. Would we need a nonce to
discriminate that? 

Also, in the most pathologic case, if a packet sent to anycast is
duplicated, can it reach 2 different packets received by 2 different
edge routers? 

Pascal

>From: [email-masked] [mailto:[email-masked]] On
Behalf Of Carsten Bormann
>Sent: jeudi 11 juin 2009 00:21
>To: Richard Kelsey
>Cc: [email-masked]

---

From: Brian Frank <[email-masked]>
Date: Thu, 11 Jun 2009 11:19:43 -0400

> to power consumption, at least.

I was more referring to the fact that SNMP doesn't really define a caching
model like HTTP does (assuming you think caching is an effective solution
for fetching information from sleeping nodes).

> for example when querying a set of sensors.  I am not sure how you see

I personally see the world as simple unicast request/response (be it
GET/POST/etc).  To me caching solves much more than just sleeping nodes.
 Effective resource caching between the 6LoWPAN and outside world can do
lots to save bandwidth on the 6LoWPAN, since commonly addressed resources
can be served directly from the cache(s).

> calls... not sure what you mean.  Do you mean Java and family?

Very true!  C doesn't come much does it.  Although I think most people who
want to consume smart device information are likely writing in a higher
level language like Java, C#, VB, Ruby, Python, etc.

> A URL yes, but an http server on a sensor?

We can't run TCP/HTTP straight to the sensor, so we must use some UDP binary
compression which actually runs on the sensor.  I think what matters most is
that they we leverage key HTTP concepts like URIs for addressing information
resources and HTTP semantics for REST, caching, and MIME typing.

> Let's see let's see, sounds interesting.
I am a bit of a new comer to the IETF, so I am not really familiar with the
process.  What is the best way to post a strawman and keep the discussion
going?

---

From: Richard Kelsey <[email-masked]>
Date: Thu, 11 Jun 2009 11:33:10 -0400

From: Carsten Bormann <[email-masked]>
   Date: Thu, 11 Jun 2009 00:20:48 +0200
   Cc: [email-masked]

   Good point.

The TID value could be split into two fields, a counter that
is managed as now and a random bit string indexed by the
counter.  When incrementing the counter a host would also
append a new random bit to the end of the string.  Only the
N most recent bits would be stored and included in the TID.
If two received TIDs have the same or nearly the same
counter the overlapping portions of the bitstrings would
have to agree.  Even a one-bit overlap would detect a
collision half of the time.

This would allow an ER to detect collisions between hosts
whose TID counters happen to synchronize.  Duplicated
packets would not cause false detections.

Does that make sense?
                                -Richard Kelsey

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 11 Jun 2009 18:17:59 +0200

On Jun 11, 2009, at 17:19, Brian Frank wrote:

> What is the best way to post a strawman

Hi Brian,

that is exactly what individually submitted Internet-drafts are meant  
for.
You don't have to write a 60-page tome, just try to put together  
enough for a cogent argument.

Just as an example for such a strawman draft (that I happen to be  
familiar with):
http://tools.ietf.org/html/draft-bormann-6lowpan-cbhc-00
In the end, we actually used only certain elements of the concepts  
proposed, but I think it was useful for the discussion to write those  
2.5 pages (net weight).

Gruesse, Carsten

---

From: Jonathan Hui <[email-masked]>
Date: Thu, 11 Jun 2009 11:51:30 -0700

> state (like a pool with LRI etc...) after the node is gone.

Hi Pascal,

If Ralph could reiterate what he said at the WG meeting on the ML,  
that would certainly help my understanding of the fundamental  
difference between DHCP and whiteboard.

At least in my mental model, the whiteboard is authoritative in what  
nodes can use what address. The node MUST periodically renew the  
binding with the whiteboard. The node cannot use that address when the  
binding expires without renewal because the whiteboard could then  
allow another node to use that same address. Whether or not we view  
the node as "owning" the address is a non-issue for me. Functionally,  
the whiteboard is authoritative and that's not unlike DHCP.

Also, in various places in the ND draft, we say *stateless* address  
autoconfiguration - when in fact this is not the case. The whiteboard  
maintains necessary state for all nodes in the network no matter how  
you spin it. If that state does not exist, is not maintained properly,  
or cannot be reached by the client node, DAD using the whiteboard will  
fail. At the very least, I think we should drop the word "stateless"  
everywhere in the draft.

--
Jonathan Hui

---

From: Rene Struik <[email-masked]>
Date: Thu, 11 Jun 2009 16:44:46 -0400

Hi Richard:

One cautionary node: in my mind, secure, yet easy to use device configuration and trust lifecycle management relies on devices to be uniquely identified in a static way, in a vendor independent fashion. As such, this assumes a globally unique name space across all nodes. This suggests that "globally unique" is not a proper adjective for "16-bit addresses" (unless you wish global device deployment to be limited to 64k devices only [which I hope not...]).

Rene

==

Having globally-unique 16-bit addresses helps with header compression.  Typically, all or most of the traffic in a LoWPAN is either to or from one of a small number of nodes.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Richard Kelsey
Sent: Thursday, June 11, 2009 9:03 AM
To: Zach Shelby
Cc: [email-masked]
Subject: Re: [6lowpan] ad hoc whiteboard (was: [Fwd: New Version Notification for draft-ietf-6lowpan-nd-03])

Zach,

                           -Richard Kelsey

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 12 Jun 2009 10:21:07 +0200

>the whiteboard is authoritative and that's not unlike DHCP.

Seems my words failed to convey the message and I hope Ralph will
express that better.

The key in my mind is that the owner is the node, and the whiteboard is
just an attorney.
Though he is the one who speaks during trial, the attorney can only say
what his client agreed upon.
And the client might switch attorney at will.

With stateful DHCP, the server plays is like a chess player that places
and controls its pawns at will.
So the model is reversed.

>fail. At the very least, I think we should drop the word "stateless"

I think you're very right, that's an excellent point.
 
Stateful in the DHCP acceptance is certainly closer to what we are
doing.

Pascal

---

From: Zach Shelby <[email-masked]>
Date: Fri, 12 Jun 2009 11:30:09 +0300

Hi,

> So the model is reversed.

This is also my understanding.

> I think you're very right, that's an excellent point.

I don't agree completely. The node is creating an address using 
Stateless Address Autoconfiguration (RFC4862), we are not breaking that. 
So in Section 5.2, where we are forming addresses, this is used correctly.

The only thing we are changing, is the mechanism to perform DAD.

I agree that the Whiteboard is not stateless, but it also does not start 
with any state, nor does it require configuration from an administrator. 
It is a blank slate..

Zach Shelby
Head of Research
Sensinode Ltd.
Kidekuja 2
88610 Vuokatti, FINLAND

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 12 Jun 2009 10:55:11 +0200

Hi Zach;

At the end of the day, we need to establish states in the network for
the IPv6 address in use. 
In that regard we are stateful. And that is how I understand that the
DHCP world means it.

Yet we require minimal to no pre-configuration in the network. 
In that we are stateless. And that is how I understand that 4862 means
it.

The core question is whether people will understand better what we are
doing if we qualify it as stateless or stateful based on their more or
less intuitive understanding of the words, or if we'll just create more
embarrassment for ourselves.

Considering that the term stateful was deemed highly confusing and
removed from RFC 4862, I tend to think that in a fashion stateless is
also confusing and could be removed from our text. But I will not fight
either way.

Pascal

>From: Zach Shelby [mailto:[email-masked]]
>Sent: vendredi 12 juin 2009 10:30
>To: Pascal Thubert (pthubert)
>Cc: Ralph Droms (rdroms); [email-masked]
>> Stateful in the DHCP acceptance is certainly closer to what we are
without

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 12 Jun 2009 10:55:15 +0200

> And the client might switch attorney at will.

Pascal, listening you I think I understand what you mean.

Side-note: if you think a node (owner) may permanently keep an IP 
address and then instruct DHCP Servers at various places (attorneys) to 
lease it for it - then this is a typical case of IP route injection. 
The IP address must be reachable at the current DHCP server.  This route 
injection is something highly debatable - is it working, is it 
"churning" routes, etc.

I haven't yet seen it working on large domains.

In small domains (1-2 ERs) it is highly debatable whether one wants the 
node to keep or not the same IP address.  If yes then PMIP would be a 
good candidate to check (Proxy Mobile IP Mobile Nodes keep a single 
address constant while moving and the MAG and LMA maintain the tunelling 
for this address).

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 12 Jun 2009 11:15:07 +0200

> with any state, nor does it require configuration from an administrator. 

This is what PMIP does too: the MN acquires an address with either SLAAC 
or DHCP and then MAG and LMA maintain the tunelling for it, starting 
with a blank binding cache (equiv to whiteboard).

Also, DHCP may have means to work with blank initial states, probably 
modification is needed.  I'm thinking about the CONFIRM message sent by 
the node to the Server.  This contains an IP address.  If the server 
still likes the node to use this address then it REPLYes ok to node. 
There may be other means to enhance DHCP to achieve this blank 
whiteboard node attorney behaviour.

Also, I doubt the blank whiteboard is always the case for the 6LoWPAN ND 
draft, because the it states that the node is assigned a full /128 
address with an RA:
>   This registration method includes a way of requesting a unique
>    address from the ER by setting the 'A' flag in an Address Option
>    during registration.

Alex

---

From: Zach Shelby <[email-masked]>
Date: Fri, 12 Jun 2009 12:40:42 +0300

Alexandru Petrescu wrote:
>> Stateless Address Autoconfiguration (RFC4862), we are not breaking 
>> that. So in Section 5.2, where we are forming addresses, this is used 
>> correctly.
>>
>> I agree that the Whiteboard is not stateless, but it also does not 
>> start with any state, nor does it require configuration from an 
>> administrator. It is a blank slate..
> 

Exactly. Nothing strange here. In fact you could very well call the 
whiteboard a "DAD binding cache". Whiteboard is a nicer name...

>>    address from the ER by setting the 'A' flag in an Address Option

This has nothing to do with the RA, which is only used to advertise 
prefix and context information (see the 6LoWPAN Prefix Information Option).

There is a flag in the Address Option of the Node Registration message 
like that. It indicates that the Edge Router should generate an IPv6 
address with a random short address (e.g. 16-bit) on behalf of the node, 
which it then checks with DAD. This requires no previous state or 
configuration in the whiteboard. The node could (and can) very well do 
this itself, and then just try to register it. This is just an 
optimization to possibly save a couple NR/NC message exchanges.

- Zach

Zach Shelby
Head of Research
Sensinode Ltd.
Kidekuja 2
88610 Vuokatti, FINLAND

---

From: Zach Shelby <[email-masked]>
Date: Fri, 12 Jun 2009 12:55:07 +0300

Hi Alex,

> expressed the following about 6LoWPAN ND related to this discussion:

OK, please read and comment.

>  manual assignment of addresses on nodes, and DHCP too.

This is not an assumption made by ND! This is how 6LoWPAN works. This 
also does not forbid MAC address assignment by any means, MAC addresses, 
both short and long can be configured to the radio chip almost universally.

We are just writing it down here to remind the reader why address 
resolution is not necessary. In the next version we can point out that 
this is a 6LoWPAN basic assumption, not something ND is forcing.

>  contained in that RA).  DHCP does so already, why not using it.

6LoWPAN ND is not doing that. RAs advertise prefix context, which is 
shared state for compression using draft-6lowpan-hc.

>  egressinterface of ER _and_ the LoWPAN - these should be two different

This is only in an Extended LoWPAN topology - which is optional. If you 
don't want to do ND proxy, then just use Simple LoWPANs which use the 
model you like better.

> -I think the whiteboard concept should be clarified, or I should try to

Yep, we have some good ideas on how to do that for nd-04, please read 
and comment specifically if it is still unclear in the text in nd-03. 
There is now a whole subsection on whiteboard in Section 7.

Zach Shelby
Head of Research
Sensinode Ltd.
Kidekuja 2
88610 Vuokatti, FINLAND

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 12 Jun 2009 12:35:12 +0200

> both short and long can be configured to the radio chip almost universally.

What if I want to manually assign 2001:db8::1 on a LoWPAN node?  Who 
will ensure its uniqueness?

I as human know "1" does not correspond to any MAC address, but ER can't 
know this.  YEt ER assumes an IP address corresponds to this "1", and 
worse, the IP address corresponding to this one is led by the prefix 
pre-configured on ER.  (my manually assigned prefix is 2001:db8::/48).

Alex

>>> also assumes that you mesh through the whiteboard. Note that using 
>>> the whiteboard for NUD is only really useful in mesh-under networks. 
>>> For route over, NUD using the whiteboard doesn't make any sense to me.
>>>
>>> as assigning the node that address. The whiteboard may assign a 
>>> 16-bit short address, for use with an IP address - that is exactly 
>>> the same as assigning the node that address.
>>>

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 12 Jun 2009 13:21:30 +0200

> will ensure its uniqueness?

As with 4862, you start out with an optimistic address, do DAD, but  
not with NS, but using NR via the whiteboard.
Nothing special at all except for replacing NS-based DAD with NR-based.

The only problem is that your EUI-64 must be 02:00:00:00:00:00:00:01  
if you actually want to get packets.
(There is an easy hack if your node is a router.)

Gruesse, Carsten

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 12 Jun 2009 14:09:04 +0200

Carsten Bormann a écrit :
> As with 4862, you start out with an optimistic address, do DAD, but not 
> with NS, but using NR via the whiteboard.
> The only problem is that your EUI-64 must be 02:00:00:00:00:00:00:01 if 
> you actually want to get packets.

This ^ restriction (the g bit) is not present anywhere else outside 6LoWPAN.

I can easily assign 1::1 on an interface, and if as human I know I own 
this address then all is fine.

Alex

---

From: Jonathan Hui <[email-masked]>
Date: Fri, 12 Jun 2009 08:01:09 -0700

Hi Pascal,

W.r.t. DHCP or not - I agree with you on the semantic difference  
between the two, but that is not what I wanted to argue. My point is  
that the added cost of having a whiteboard is not much different from  
DHCP - it requires an entity somewhere to respond to requests and  
maintain state about each node that it has responded to. 6LoWPAN ND  
also requires a proxy mechanism for when the whiteboard is not on- 
link. The whiteboard can also be a cause of failure - if a node cannot  
communicate with the whiteboard, it cannot perform DAD, and cannot  
properly join the network.

W.r.t. using the word "stateless", from RFC 4862 we have:

     "The IPv6 stateless autoconfiguration mechanism requires no manual
      configuration of hosts, minimal (if any) configuration of routers,
      and no additional servers."

Also in RFC 4862, we have:

     "The stateless mechanism allows a host to generate its own  
addresses
      using a combination of locally available information and  
information
      advertised by routers."

The first excerpt identifies the main point of SLAAC - no additional  
servers. The second indicates how stateless addresses are formed and  
is where I see Zach's argument coming from. In my view, the real  
benefits of SLAAC are sorely missed now that we do require additional  
servers (whiteboard). Even if a host could configure an address, it  
can't do much with it until it receives a confirmation from the  
whiteboard. In the traditional world, SLAAC is beneficial because DAD  
conveniently doesn't require any servers either - not true in 6LoWPAN  
ND.

We have also already stated that the whiteboard assigning short  
addresses and future ideas for using SeND will blur the line even more  
in that the node no longer builds addresses using information local to  
it.

I still think we should drop "stateless" and avoid the confusion.

--
Jonathan Hui

On Jun 12, 2009, at 1:55 AM, Pascal Thubert (pthubert) wrote:

>>>>> that in SFO a lot better than I can ever do but that has to do  
>>>>> with
>>>>> the
>>>>> model below.
>>>>>
>>>>> In DHCP, the server owns the address and lends it away. You have  
>>>>> to
>>>>> get
>>>>> When we do SeND, that distinction might blur quite a bit but  
>>>>> still,
>>>>> the
> that.
> start
>> contain

---

From: Jonathan Hui <[email-masked]>
Date: Fri, 12 Jun 2009 08:10:29 -0700

On Jun 12, 2009, at 1:30 AM, Zach Shelby wrote:
> that. So in Section 5.2, where we are forming addresses, this is  
> used correctly.

You have to look at the whole process. RFC 4862 SLAAC is useful  
because DAD also does not require any servers or state maintenance.  
I'd argue that if RFC 4862 were changed to use 6LoWPAN ND DAD for  
*all* networks, then the whole point of SLAAC is missed.

> administrator. It is a blank slate..

My closest analogy (again from a protocol point of view, not semantic)  
of 6LoWPAN ND is the DHCP server in your home linksys box. It requires  
no real user-visible network configuration. It doesn't start with any  
per-node state. Nodes on the network must communicate with it to join  
the network. Let's not kid ourselves here in thinking that the  
whiteboard is something that is simpler to understand, use, and manage  
than a simple DHCP server is. It's certainly something that Richard is  
concerned about and I'm sure others will be too.

--
Jonathan Hui

---

From: Richard Kelsey <[email-masked]>
Date: Fri, 12 Jun 2009 11:17:58 -0400

From: Rene Struik <[email-masked]>
   Date: Thu, 11 Jun 2009 16:44:46 -0400

   One cautionary node: in my mind, secure, yet easy to use device
   configuration and trust lifecycle management relies on devices to be
   uniquely identified in a static way, in a vendor independent
   fashion.

Sadly, as I learned on another part of this thread, it
appears that we may not be able to rely on having static,
globally-unique identifiers.  Manufacturers of
counterfeit-branded devices have a disincentive to
cooperate.

   As such, this assumes a globally unique name space across all
   nodes. This suggests that "globally unique" is not a proper adjective
   for "16-bit addresses" (unless you wish global device deployment to be
   limited to 64k devices only [which I hope not...]).

"Globally unique" was indeed incorrect.  I should have
said "unique within the LoWPAN" or some such.

                                  -Richard Kelsey

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 12 Jun 2009 17:16:28 +0200

Jonathan,

(no WG chair hat)

Apart from the philosophical argument made by Pascal, there is a big  
difference in complexity between 6LoWPAN-ND's NR and DHCP.

Your semantics point ("stateless"):

SAA needs DAD.  6LoWPAN-ND does DAD in a different way, because it  
cannot rely on transitive multicast.  But it still does SAA.
If you really want to focus on the "stateless" in SAA, what about the  
states that an SAA node is in (optimistic, tentative, preferred,  
deprecated).  I can already argue that original SAA is not "stateless"  
for this definition of stateless.  So I'm not surprised you can do  
that for your favorite definition.

The 16-bit address search (it's not really assignment) goes beyond  
SAA, yes.
It appears to be a good optimization (and that's what 6LoWPAN-ND is  
about) to not let the node guess repeatedly until it finds a free slot.

I don't see an additional server, the ER is needed in any case.
The ER better knows which nodes are in the LoWPAN (or it will create  
lots of pointless RREQs), so it is absolutely natural for it to have  
that table ("whiteboard").

Gruesse, Carsten

---

From: Jonathan Hui <[email-masked]>
Date: Fri, 12 Jun 2009 08:32:35 -0700

Hi Carsten,

On Jun 12, 2009, at 8:16 AM, Carsten Bormann wrote:
> If you really want to focus on the "stateless" in SAA, what about  
> the states that an SAA node is in (optimistic, tentative, preferred,  
> deprecated).  I can already argue that original SAA is not  
> "stateless" for this definition of stateless.  So I'm not surprised  
> you can do that for your favorite definition.

Sorry, replace "state" with "per-node state not maintained by the node  
configuring its interface". That is what I meant by "state" in  
previous emails and that is what is meant by "state"-less in RFC 4682,  
at least my interpretation of it.

> I don't see an additional server, the ER is needed in any case.

As I mentioned before, "server" is in the functional sense. It is  
additional code running somewhere else other than the node trying to  
configure an address. It is a piece of code that a joining node must  
interact with simply to join the network. As I said before, if that  
server fails, communication to that server fails, or management of  
that state fails, nodes cannot properly join the network.

> that table ("whiteboard").

Again, we all understand the purpose of the whiteboard. I just want to  
be fair on what it actually provides and the constraints it places on  
the network. In particular, it does not allow a node to perform DAD  
autonomously, and as a result, does not allow a node to assign a  
preferred address autonomously. OTOH, SLAAC with DAD in RFC 4862 does  
allow a node to assign a preferred address autonomously.

--
Jonathan Hui

---

From: Rene Struik <[email-masked]>
Date: Fri, 12 Jun 2009 12:32:51 -0400

Hi Richard:

A simple approach avoiding duplicate device identifiers would be to register devices with a registration authority and hand out device certificates that bind the device id with public/private keying material. If devices can only gain access to a network by presenting their public key certificate, this would push counter-feit devices off the cliff, since the registration authority would not allow registration of more than one device with the same device id. 

(Obviously, one can still try and clone a device by trying and extract private keys as well and copying this info to a number of devices, all with the same device id, something - if deemed to be a real risk - to be dealt with by proper implementation security and security techniques along the supply chain.) 

Best regards, 

Rene

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Richard Kelsey
Sent: Friday, June 12, 2009 11:18 AM
To: Rene Struik
Cc: [email-masked]
Subject: Re: [6lowpan] (16-bit addresses are not globally unique) RE: ad hoc whiteboard (was: [Fwd: New Version Notification for draft-ietf-6lowpan-nd-03])

                                  -Richard Kelsey

---

From: Zach Shelby <[email-masked]>
Date: Fri, 12 Jun 2009 20:40:37 +0300

So to wrap this up - and let everyone relax over the weekend - let me 
summarize here. Considering the route-over, non-transitive, 
sleeping-node environment we are working with - 6LoWPAN-ND has solved 
the problem quite nicely. Now we're really talking about how to explain 
it in a realistic way, minimize the downsides, and work out the bugs.

So I propose the following tickets:

1. Remove stateless from the draft, except in reference to the use of 
RFC4682 SAA while forming addresses (it is the name of the RFC...).

2. We attempt explain the whiteboard in a realistic context in the 
draft, not claiming it walks on water or anything.

3. Improve the address and OII collision text, and the coverage of 
cases. Pascal and Carsten will work on that, suggestions welcome. 
Separate thread.

4. Clarify that other methods can be used to form addresses, not only 
SAA. For example manual configuration, DHCP or any other method (e.g. 
link-layer assignment).

5. Ticket to improve the Ad-hoc LoWPAN case, based on Richard's feedback 
on large ad-hoc networks. Things to consider include making the 
whiteboard optional for that case, or somehow minimizing the state 
needed in an ER. Separate thread.

Thanks everyone for the discussion, let's continue discussing 3 and 5 
and work on constructive improvements.

- Zach

Zach Shelby
Head of Research
Sensinode Ltd.
Kidekuja 2
88610 Vuokatti, FINLAND

---

From: Joaquín Cabezas <[email-masked]>
Date: Thu, 11 Jun 2009 13:50:15 +0200 (CEST)

I totally agree with the HTTP point of view.

In my sensors I'm deploying a minimalistic web server to offer XML-based
reports of data sensors. Now I'm using non-compressed data and the
performance is poor, but I see this approach (http) as a good solution.

Simplicity for developers is essential.

Joaquin Cabezas.

---

From: Ki-Hyung Kim (김기형) <[email-masked]>
Date: Sun, 14 Jun 2009 17:56:25 +0900

As Alex mentioned, I think it is a right time to discuss the 6lowpan MIB as
a WG item.
I want to ask for a working group consensus on this.

__
Ki-Hyung Kim
Associate Professor, Ajou University, Korea,
Tel: +82-31-219-2433, Cel: +82-10-4760-2551

On Thu, Jun 11, 2009 at 19:10, Alexandru Petrescu <
[email-masked]> wrote:

> Hamid Mukhtar a écrit :
>
>> On Thu, Jun 11, 2009 at 5:56 PM, Alexandru Petrescu<
>> [email-masked]> wrote:
>>
>>> Brian Frank a écrit :
>>>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sun, 14 Jun 2009 11:24:34 +0200

On Sun, Jun 14, 2009 at 10:56:25AM +0200, "Ki-Hyung Kim (?????????)" wrote:

> As Alex mentioned, I think it is a right time to discuss the 6lowpan
> MIB as a WG item.  I want to ask for a working group consensus on
> this.

It is not clear to me what the scope of the proposed MIB module work
would be. For example, the ID <draft-daniel-6lowpan-mib-00.txt> has
routing tables inside - perhaps this belongs to a roll effort? I am
also missing text explaining which parts of other standard IPv6 MIB
modules are applicable. And then I like to know how this MIB module is
expected to be implemented - on each 6LowPAN node or just on a base
station / gateway, using SNMP contexts to address the 6LowPAN nodes?

In short, I am missing a high-level description of the scope of the
MIB module work to be carried out as a chartered WG item.

/js

---

From: Ki-Hyung Kim (김기형) <[email-masked]>
Date: Sun, 14 Jun 2009 19:00:53 +0900

On Sun, Jun 14, 2009 at 18:24, Juergen Schoenwaelder <
[email-masked]> wrote:

> routing tables inside - perhaps this belongs to a roll effort?

Current version of the draft assumes mesh-under routing in adaptation layer
because we have the mesh header in 6lowpan format (RFC4944).
It is not yet decided whether 6lowpan will have mesh-under routing or not.
However, I think it could be the starting point at least for the 6lowpan
MIB.

I am
> modules are applicable.

Thank you for pointing it out. we would try to include that in the next
versions.

> And then I like to know how this MIB module is

This MIB is designed for the 6LoWPAN devices (6lowpan node and 6lowpan
router (aka, 6lowpan forwarder)), not for the 6lowpan edge router (aka,
gateway).
Edge router MIB could also be defined for the white board data structure and
the information which is static throughout the whole 6lowpan.

> MIB module work to be carried out as a chartered WG item.

We would add the high-level description of the work in the next version as
you pointed out.
> /js

__
/khk

---

From: Kris Pister <[email-masked]>
Date: Sun, 14 Jun 2009 17:09:26 -0700

I agree.  The ability to do stuff like this is one of the big advantages 
of being connected with the internet.  Let's use it.
As usual Rene, I'm going to ask you to tell me exactly what I'm supposed 
to buy from you (I mean "implement", sorry). :)
What's right approach?  Do we start with what you did in Zigbee, or 
isa100, or an existing rfc, or what?

ksjp

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 15 Jun 2009 08:25:36 +0200

Hi Kris:

It seems to me that we are talking about another global distributed
Internet registry with the capability to store tens of billions of
entries.

A node would really own the 64bit ID once it would have registered it.
IEEE would keep some ranges and free some other up for IPv6 and others
to jump in and allocate IDs formed some other ways like CGA. Then a web
of servers would keep track of unique ids, associated keys and more
stuff overtime.

- This obviously might cause privacy issues so this ID would not be to
be used lightly
- There would be a need to obtain temporary IDs
- This could help forgery detection so I'm sure we could get some
support for the effort :)

What do you think?

Pascal

>From: [email-masked] [mailto:[email-masked]] On
Behalf Of Kris Pister
>Sent: lundi 15 juin 2009 02:09
>To: Rene Struik
>Cc: [email-masked]
>Subject: Re: [6lowpan] (16-bit addresses are not globally unique) RE:
ad hoc whiteboard
>> A simple approach avoiding duplicate device identifiers would be to
register devices with a registration
>authority and hand out device certificates that bind the device id with
public/private keying material. If
>devices can only gain access to a network by presenting their public
key certificate, this would push counter-
>feit devices off the cliff, since the registration authority would not
allow registration of more than one
>device with the same device id.
>>
>> (Obviously, one can still try and clone a device by trying and
extract private keys as well and copying this
>info to a number of devices, all with the same device id, something -
if deemed to be a real risk - to be
>dealt with by proper implementation security and security techniques
along the supply chain.)
>> From: [email-masked] [mailto:[email-masked]] On
Behalf Of Richard Kelsey
>> Subject: Re: [6lowpan] (16-bit addresses are not globally unique) RE:
ad hoc whiteboard (was: [Fwd: New
>Version Notification for draft-ietf-6lowpan-nd-03])
>>

---

From: Kris Pister <[email-masked]>
Date: Mon, 15 Jun 2009 18:11:45 -0700

Yikes!  Not at all.  I'm interested in a mechanism by which people who 
care about security can get what they need, and people who don't care 
about security don't need to be bothered.
I don't see a need for a global registry, although I can imagine one 
emerging.
I'm picturing a separate certification server for industry group X, my 
paranoid home security system Y, and refinery Z.  The policies on things 
like privacy can be set by the individual groups on their specific 
server(s), depending on the application, etc.

My vote is for ECC.  Do we have any unencumbered ECC-based RFCs to look 
to for guidance?

ksjp

Pascal Thubert (pthubert) wrote:
>> I agree.  The ability to do stuff like this is one of the big
>>     
> advantages
>   
>> As usual Rene, I'm going to ask you to tell me exactly what I'm
>>     
> supposed
>   
>>>    configuration and trust lifecycle management relies on devices to
>>>       
> be
>   
>>>    nodes. This suggests that "globally unique" is not a proper
>>>       
> adjective
>   
>>>    for "16-bit addresses" (unless you wish global device deployment
>>>       
> to be
>

---

From: Hamid Mukhtar <[email-masked]>
Date: Tue, 16 Jun 2009 10:38:30 +0900

> fairly limited type system for modeling information.

The predefinition of data is required for standardizing the
information that has to be retrieved. However, application specific
MIBs can always be defined and used.

> packets (which I believe is quite possible).  What advantages does HTTP

same can be done with SNMP packets :).

> every sensor on the planet can be given a URL.

Enabling HTTP on the nodes would really be a nice contribution.
However, I dont agree with using that for management. Reusability of
the tools that are already available for management, monitoring, and
configuration of IP networks is also something that we cannot neglect.
Moreover, SNMP is datagram oriented and also pretty lightweight if it
is coded well - it may fit 6LowPAN applications pretty well.

> with sleeping nodes, by having powered nodes serve as their HTTP caches.

Catching in SNMP may be achieved by AgentX (a subagent protocol).
Currently AgentX is based on TCP, however it can be modified to be
used over UDP to fit the 6LoWPAN requirements.

---

From: Brian Frank <[email-masked]>
Date: Tue, 16 Jun 2009 08:16:02 -0400

> is coded well - it may fit 6LowPAN applications pretty well.

SNMP definitely has the strong allure of network management.  HTTP has the
strong allure of information management.  So perhaps the question is do we
expect 6LoWPAN devices to speak multiple protocols?

One of the very cool things about 6LoWPAN is that as IP it embraces multiple
application level protocols.  This is quite opposed to the various
industry-vertical standards which try to solve the whole problem
top-to-bottom in what mostly turns out as a monolith stack.

However here is the rub - I don't think most 6LoWPAN devices really have the
horse power to be running multiple protocols.  Based on the technology we
are using, I'm pretty sure that we will be required to pick one general
purpose protocol and use it for most everything.  My personal opinion is
that the concerns of information management and integrating smart devices
into the Web is the dominating criteria for selection of what that general
protocol is.

The industry will be looking to the IETF to see what the strategy is for
application level protocols over 6LoWPAN.  So whatever that strategy is, I
think it is important to figure out how many and what protocols are expected
to create interoperable 6LoWPAN devices.