Subject: [6lowpan] "cry out loud" vs. "white board"

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 18 Mar 2008 17:53:02 +0100

Hi:

Neighbor Discovery is traditionally implemented over multicast. And
multicast is more often than not implemented over a plain mac level
broadcast. This is the "cry out loud" paradigm, perfectly suited for
Ethernet, and totally unsuited for LowPANs.

draft-chakrabarti-6lowpan-ipv6-nd makes a great point on explaining the
steps that this takes and the associated cost. I think that this part of
the document has already most of the attributes to be turned into a ND
problem statement WG doc for 6LoWPAN.

What I disagree with is the approach to solve the problem by patching
optimizations all over the process. We have to face that the result is
still not acceptable and that the whole paradigm should be revised for
the LowPAN. In a memory constrained device, implementing MLDv2 is huge
overkill, even if its use can be reduced in runtime by refined
optimizations. In a same fashion, relying on mesh-under multicast
support is unrealistic.

At the other end of the routing spectrum from the "cry out loud"
paradigm, the "white board" model proposes a solution where one node
acts as a reference for all the others. With that model, every node
claims an address by writing on the white board and looks up an address
by reading from the white board. DAD is a lookup / commit collapsed in a
single NS flow. All NS/NA become unicast activity, no MLD, dead simple.
And RAs are broadcast.

The catch is obviously that the white board is not a fully distributed
model. Is that even acceptable? If we consider that LowPANs usually have
a sink of some sort, probably a higher-power never-sleeping router, then
it makes a lot of sense to use that special node for placing the
function. So why not?

I tried to capture this idea in
http://tools.ietf.org/html/draft-thubert-6lowpan-backbone-router. On top
of the white board, the draft adds the capability for the white board to
act as a ND proxy and extend the LoWPAN across an IP backbone and
potentially scale the PAN into a very large link.

Note that the draft was renamed from LoWPAN to 6lowpan but the content
is unchanged. 

So, what do you think?

Pascal 

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

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 18 Mar 2008 18:05:37 +0100

Pascal,

the security properties of the ND protocol are well understood, so  
that SEND was developed to improve them.
What would be a good security model for the "white board" approach?
Could a "white board" in turn be useful for coordinating security?
How to get rid of the single point of failure?

Gruesse, Carsten

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 18 Mar 2008 18:17:05 +0100

Hi Carsten:

Many good points:

1) current SeND is not compatible with the RFC 4944 compression

2) current SeND is unrealistic on motes, mostly due to the CPU cost of
computing a CGA address
    But since the cga address is computed based on the public key it
would be possible for the white board could do the CGA work as part of
the registration process.

3) with white board, NA is proxied. So a proxy SeND is required, as
documented in
http://tools.ietf.org/html/rfc4389 
http://tools.ietf.org/html/draft-daley-send-spnd-prob-02

RFC still in the oven but work exists: 
http://tools.ietf.org/html/draft-krishnan-cgaext-proxy-send-00

4) Could a "white board" in turn be useful for coordinating security?
You need to answer that one. There are certainly interesting properties
there.

5) How to get rid of the single point of failure?
This is usually left to vendors, HSRP, VRRP or else. Note that the BbR
is not on the way for intra LoWPAN data exchange, just lookup. It can
die and restart but it's better if it can persist the caches.

What do you think?

Pascal

>-----Original Message-----
>From: Carsten Bormann [mailto:[email-masked]]
>Sent: mardi 18 mars 2008 18:06
>To: Pascal Thubert (pthubert)
>Cc: Carsten Bormann; 6lowpan
>Subject: Re: [6lowpan] "cry out loud" vs. "white board"
>
>Pascal,
>

---

From: Philip Levis <[email-masked]>
Date: Wed, 19 Mar 2008 16:55:24 -0800

> Note that the draft was renamed from LoWPAN to 6lowpan but the content
I think the idea of a whiteboard is powerful. It definitely makes more 
sense than "shout out." I am leery of the requirement that there be a 
single coordinating node, however. Your text puts it precisely: 
"consider that LowPANs *usually* have a sink of some sort" (emphasis 
mine). Forcing this to be centralized requires such a node exist and 
therefore precludes certain kinds of LowPANs.

That being said, this approach seems to implicitly assume mesh under? 
Nodes "use Neighbor Discovery to determine the link-layer addresses for 
neighbors known to reside on attached links and to quickly purge cached 
values that become invalid." ND could operate on a single hop basis. 
This simplifies everything. The place where the whiteboard approach is 
necessary is for DAD. But given that the goal is eventual consistency on 
address assignment, it may be possible to distribute the table in an 
effective way.

Phil

---

From: Jonathan Hui <[email-masked]>
Date: Wed, 19 Mar 2008 18:41:26 -0700

Hi Phil,

Philip Levis wrote:
> sense than "shout out." 

Yes. DHCP has proven itself useful, and for many reasons other than just 
avoiding "shout out".

> therefore precludes certain kinds of LowPANs.

A solution may simply be to configure your IP addresses using an IID 
derived from the EUI-64, which must be unique within a PAN. If you 
really want automatic assignment of short addresses, then that's a 
different beast. But it might not be worth the overhead.

> values that become invalid." ND could operate on a single hop basis. 

Let's be clear on what kind of hop. I'm sure you meant a single 15.4 
radio hop, not an IP hop.

> address assignment, it may be possible to distribute the table in an 

While I agree it does simplify many things, it doesn't simplify 
everything :-). RFC 4861 explicitly assumes multicast-capable links with 
reflexive and transitive reachability. DAD is only one example. ND is 
also used for redirect and to propagate network parameters. In a 
route-over configuration, the mechanisms currently defined aren't very 
useful in a route-over 15.4 PAN. I'm currently signed up to work on an 
I-D that addresses this case, as it is an interesting case to consider.

--
Jonathan Hui

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 20 Mar 2008 11:02:26 +0100

Hi Jonathan and Phil

IID derived from the EUI-64 and Optimistic DAD can save some ND flows.
But then again this is only dampening the shouting and in any case less
efficient than white board approach.

About implementing white board, my initial draft extends ND but I seems
clear now that this will create confusion.  I'd rather follow Jonathan's
view that DHCP is the protocol of choice to perform the registration.
I'll have that in mind for version 01 and probably migrate to DHCP, and
sollicit help of DHCP specialists.

I'm not claiming that we get rid of ND, I'm saying that we propose a
solution where NS and NAs are fully replaced by DHCP requests over the
LoWPAN. We do not MUST or SHOULD the support of NS/NA and propose a
clear DHCP based alternative. Whether we do mesh under or route over, it
seems clear that DHCP will be supported, so the model will still work.

The following tools already exist:

RFC3315 (DHCPv6) that we can use to obtain a DADless address
 
RFC5007 : (Lease query for Ipv6) that we can use to sollicit another
node's address.
  
For Carsten:

http://www.ietf.org/internet-drafts/draft-van-beijnum-cga-dhcp-interacti
on-00.txt

explains that we do not need the dhcp server to generate the CGA
address, a point that I certainly disagree with :)

Pascal
>From: Jonathan Hui [mailto:[email-masked]]
>Sent: jeudi 20 mars 2008 02:41
>To: Philip Levis
>Cc: Pascal Thubert (pthubert); 6lowpan

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 20 Mar 2008 11:25:23 +0100

On Mar 20 2008, at 11:02, Pascal Thubert (pthubert) wrote:

> DHCP is the protocol of choice to perform the registration

Wait a minute; DHCP uses broadcast (well, link-scoped multicast).
So I don't know how much this helps as is.

Gruesse, Carsten

---

From: Jonathan Hui <[email-masked]>
Date: Thu, 20 Mar 2008 08:18:27 -0700

Hi Pascal,

> efficient than white board approach.

Yes, IID from EUI-64 isn't the best solution for many cases. I was only 
suggesting a quick-and-dirty possibility for those cases where a 
centralized solution is not favorable.

> sollicit help of DHCP specialists.

I plan to address both SAA and DHCPv6 in a route-over autoconfiguration 
for 6LoWPAN draft. We should coordinate our efforts to see if there's 
some commonality. While I expect mesh-under and route-over to utilize 
different mechanisms, it would still be good to make them similar in 
areas that they do overlap. On a side note, I'm not sure we want to use 
the formats as specified in RFC3315. I was thinking of scoping RFC3315 
and making it less general to compress the DHCPv6 options formats.

For Carsten: DHCP does use link-local multicast, but such a restriction 
hasn't stopped us from optimizing protocols in 6LoWPAN networks to 
utilize unicast communication.

--
Jonathan Hui