Subject: Re: [6lowpan] Fundamental concerns about 6lowpan ND

From: Julien Abeillé <[email-masked]>
Date: Tue, 13 Oct 2009 07:40:17 +0000 (GMT)

Hi Carsten,

On Mon, 2009-10-12 at 21:13 +0200, Carsten Bormann wrote:

> Sure it would be nice if that "just worked", but it doesn't.

As far as I see, among the procedures defined in 4861 (address resolution, NUD, router discovery, prefix discovery, redirect, next hop determination, parameter discovery, next hop determination, DAD)
ony DAD fails. Just do proxy ND on each lowpan node and this is solved.

regarding the assumptions that you do not know whether your neighbors are sleepy and will receive an IP packet (this is the underlying assumption about failure of NS.., end of 1.2)
- RPL will break with this assupmtion (many protocols will)
- why do you though garantee that unicast will not?
- for NUD, you assume that you will be able to reach the white board although you assume you typically do not know when your neighbors are awake
- if you cannot garantee that your neighbors are awake, how do you reach the white board?
- once you confirmed reachability of a neigbor through white board, how do you know your app will manage to wake him up?

for me this assumption does not hold. Wise MAC like or centralized (e.g. TSMP) layer 2 have been able to provide very high reliability and very low duty cycle for years in real deployments.

In these environments as I said 95% of 4861 ND works, only DAD fails and can be fixed trivialy.

Best,
Julien