Colin,
I hope that 6lowpan ND is not a "necessary" evil.
I would like to be able to support the scenario where I can plug a
simple device into my PC or my existing router and have the PC or router
be able to provide RA/RS support for my 6lowpan nodes without having to
change any code on the PC or router.
geoff
On Mon, 2009-10-12 at 17:46 +0100, Colin O'Flynn wrote:
> Hello,
>
>
>
> I understand the problems with ‘redesigning’ a core IPv6 protocol.
>
>
>
> However I’m curious about existing implementations that use full IPv6
> ND, do you have details?
>
>
>
> I see the 6LoWPAN ND as a ‘necessary evil’, however I would love to be
> proven wrong!
>
>
>
> Regards,
>
>
>
> -Colin
>
>
>
> From: [email protected] [mailto:[email protected]] On
> Behalf Of Julien Abeille (jabeille)
> Sent: October 12, 2009 1:47 PM
> To: 6lowpan
> Subject: [6lowpan] Fundamental concerns about 6lowpan ND
>
>
>
>
> 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]
> https://www.ietf.org/mailman/listinfo/6lowpan
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
