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

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

Hi Brian, 

> -----Original Message-----
> From: Brian Haberman [mailto:brian at innovationslab.net] 
> Sent: mardi 13 octobre 2009 22:29
> To: JP Vasseur (jvasseur)
> Cc: Julien Abeille (jabeille); bob.hinden at gmail.com; 6lowpan
> Subject: Re: [6lowpan] Fundamental concerns about 6lowpan ND
> 
> Hi JP & 6lowpan WG,
>       I have not done a thorough review of the draft yet, but 
> I did have a brief read to try and understand the approach.  
> I am curious as to why this work is not progressing more 
> along the lines of the IPv6-over-foo type documents that have 
> been published in the past.  Is an 802.15.4 network that much 
> more of an onerous environment for the base IPv6 protocols 
> (modulo some modifications/extensions)?
> 
>       We had similar issues back in the 20th Century with 
> other NBMA-type links.  RFC 2491 was written to capture those 
> interfacing functions needed to allow NDP and such to operate 
> correctly.
> 
>       Is it possible that standard IPv6 nodes could operate 
> on a 6lowpan network as well as a more traditional (e.g., 
> ethernet) one?  If so, this seems like a lot of complexity 
> needed in that device to determine the type of link it is 
> operating on.
> 
This is the point we are trying to raise.
>       I agree that non-transitive links are an issue for more 
> than just
> 802.15.4 networks.  The description given could be applied to 
> 802.11 as well.  Yet, IPv6 over 802.11 works relatively well.
> 
>       It appears that a cross-WG review would be a good idea 
> at this point.  I would like to see some 6MAN contributors 
> comment on this work rather than waiting until a Last Call.
> 
How can we do this?

Thank you,
Julien
> Regards,
> Brian
> 
> JP Vasseur wrote:
> > All valid concerns and questions.
> > 
> > Copying Bob and Brian to get their input there.
> > 
> > Thanks.
> > 
> > JP.
> > 
> > On Oct 12, 2009, at 2:47 PM, Julien Abeille (jabeille) wrote:
> > 
> >> Dear WG,
> >>  
> >> I have serious concerns about the 6lowpan ND draft and 
> would like to 
> >> have the WG opinion on this. I agree that a few issues arise in 
> >> lowpan environments, which are mostly linked to the non 
> transitivity 
> >> of some link layers used in lowpans. However, my two major 
> points of concern are:
> >> - RFC4861 and RFC4862, which are core to IPv6, are being 
> very heavily 
> >> redesigned. I believe that the proposal if it is done in 
> 6lowpan MUST 
> >> be designed as an optional extension to ND, not a redesign. The 
> >> charter states that the draft should propose "optimizations" and 
> >> "limited extensions" to ND. It is not the case at the moment. The 
> >> proxy ND proposal, the mandatory addressing model 
> proposed, also goes 
> >> beyond the scope of the document as spelled out in the charter.
> >> - non transitivity is not a lowpan only issue, hence if 
> adaptations 
> >> to ND must be done, it should be in another WG, probably 6man
> >>  
> >> If these two points are not respected,
> >> - it questions the applicability of IPv6 in smart object networks: 
> >> the draft is redesigning roughly 80% of RFC4861 and RFC4862, which 
> >> are core to IPv6
> >> - existing IPv6 implementations will be strongly impacted, as a 
> >> number of major components will have to become layer 2 dependant:
> >> -- address resolution will have to be disabled
> >> -- DAD will have to be modified
> >> -- NUD will have to be modified
> >> -- prefix discovery will have to be modified
> >> -- autoconf will have to be modified
> >> -- IPv6 addresses will not be configurable if their IID is 
> not based 
> >> on the MAC address
> >> -- ... all these changes are 6lowpan dependant, as they do 
> not impact 
> >> traditional links. This will raise important 
> interoperability issues.
> >> - new layer 3 protocol designs will become layer 2 
> dependant. This is 
> >> what is currently happenning in the ROLL WG by proposing to use a 
> >> different message to transport routing information, 
> depending on the 
> >> medium.
> >>  
> >> Moreover, a number of existing deployments show that the issues 
> >> arised on lowpan networks as far as ND is concerned are 
> not huge: the 
> >> deployments work, and ND as it is has proven to be power 
> consumption 
> >> friendly. DAD is the most problematic procedure, that 
> requires work, 
> >> as two hop neighbors do not see NS sent for DAD (see at the bottom)
> >>  
> >> In conclusion, I believe the advantages of rebuilding neighbor 
> >> discovery for lowpans are by far inferior to those of 
> keeping using 
> >> the "same IP" on all medium. If some redesign has to be 
> done, it MUST 
> >> be done in a more general fashion, probably in 6man, and in a much 
> >> lighter way.
> >>  
> >> Best,
> >> Julien
> >>  
> >> DAD issue description:
> >> node A and node C see node B, but not each other. nodes A 
> and B boot, 
> >> configure a link local address, perfom traditional DAD. It works. 
> >> Node C boots with the same MAC address than A, configures 
> the same IP 
> >> address, sends a NS to perform traditional DAD. A does not 
> see the NS 
> >> hence C address configuration works. A and C have the same 
> address. B 
> >> will not differentiate A and 
> >> _______________________________________________
> >> 6lowpan mailing list
> >> 6lowpan at ietf.org <mailto:6lowpan at ietf.org> 
> >> https://www.ietf.org/mailman/listinfo/6lowpan
> > 
> 
>