Hi Brian, > -----Original Message----- > From: Brian Haberman [mailto:[email protected]] > Sent: mardi 13 octobre 2009 22:29 > To: JP Vasseur (jvasseur) > Cc: Julien Abeille (jabeille); [email protected]; 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 > >> [email protected] <mailto:[email protected]> > >> https://www.ietf.org/mailman/listinfo/6lowpan > > > > _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
