Re: [6lowpan] Fundamental assumptions of 6lowpan-nd-06: which procedures from which RFCs assume link transitivity

["Julien Abeille (jabeille)" <jabeille at cisco.com>]

Hi Carsten, 

> -----Original Message-----
> From: Carsten Bormann [mailto:cabo at tzi.org] 
> Sent: vendredi 16 octobre 2009 12:39
> To: Julien Abeille (jabeille)
> Cc: Zach Shelby; 6lowpan
> Subject: Re: [6lowpan] Fundamental assumptions of 
> 6lowpan-nd-06: which procedures from which RFCs assume link 
> transitivity
> 
> Great question.
> 
Thank you
> I would like to extend it to "which procedures from which 
> IPv6 RFCs assume link transitivity and/or 
> high-delivery-probability subnet-wide multicast",
I would prefer asking questions individually before merging.
Regarding the second question, we still have two disalignments: 
- "subnet wide" (this is a tough one as we have not discussed addressing
yet) vs "one hop radio wide" . E.g. in route over for link local address
resolution of 2+ hop neighors make no sense to me. Same with off link
prefixes (which we are talking about I think)
- some of us advocate that duty cycling techniques ensure high delivery
probability one hop away: see Jonathan ("The whole discussion around
sleepy nodes is problematic for me as well.  The link is either up or
down, not sort-of kind-of"), Adam's emails. Kris, can you give your TSCH
view?
> as these 
> are the assumptions violated by a LoWPAN (in most 
> configurations, excepting two-node and full-multicast mesh-under).
> 
> Just one example for the former: RFC 4861 redirect assumes 
> that a router can tell a host that it can reach another host 
> via the same link.  Not true in LoWPANs.
> 
> The obvious RFC 4861 example for the problems caused by the 
> latter, i.e. (deliberate) lack of high-delivery-probability 
> subnet-wide multicast, is DAD.  But there may be a lot of 
> other protocols hit by this.  Is this a problem?
> It would be if these protocols were likely to show up in 
> LoWPANs.  One important assumption behind 6LoWPAN is that it 
> is not so likely that LoWPANs will be freely substituted for 
> Ethernet (in the sense that
> 802.11 was essentially employed as an Ersatz Ethernet).  Example:  
> People are not going to open their laptops and see, oh there 
> is a LoWPAN, and start using that for their normal Internet 
> access activities such as E-Mail and Web access (although 
> these two actually would pretty much work).
> 
Agreed (just considering non transitivity), DAD and redirect fail.

> 6LoWPAN started out by saying "let's build an IPv6 link out 
> of 802.15.4", with the assumption it would then be like any 
> other IPv6 link.  It took a couple of years to readjust that 
> assumption.  People newly coming in from high-power IPv6 may 
> now also need some time to readjust theirs.
> 
> Gruesse, Carsten
> 
>