Hi Jonathan and Phil IID derived from the EUI-64 and Optimistic DAD can save some ND flows. But then again this is only dampening the shouting and in any case less efficient than white board approach.
About implementing white board, my initial draft extends ND but I seems clear now that this will create confusion. I'd rather follow Jonathan's view that DHCP is the protocol of choice to perform the registration. I'll have that in mind for version 01 and probably migrate to DHCP, and sollicit help of DHCP specialists. I'm not claiming that we get rid of ND, I'm saying that we propose a solution where NS and NAs are fully replaced by DHCP requests over the LoWPAN. We do not MUST or SHOULD the support of NS/NA and propose a clear DHCP based alternative. Whether we do mesh under or route over, it seems clear that DHCP will be supported, so the model will still work. The following tools already exist: RFC3315 (DHCPv6) that we can use to obtain a DADless address RFC5007 : (Lease query for Ipv6) that we can use to sollicit another node's address. For Carsten: http://www.ietf.org/internet-drafts/draft-van-beijnum-cga-dhcp-interacti on-00.txt explains that we do not need the dhcp server to generate the CGA address, a point that I certainly disagree with :) Pascal >-----Original Message----- >From: Jonathan Hui [mailto:[EMAIL PROTECTED] >Sent: jeudi 20 mars 2008 02:41 >To: Philip Levis >Cc: Pascal Thubert (pthubert); 6lowpan >Subject: Re: [6lowpan] "cry out loud" vs. "white board" > > >Hi Phil, > >Philip Levis wrote: >> I think the idea of a whiteboard is powerful. It definitely makes more >> sense than "shout out." > >Yes. DHCP has proven itself useful, and for many reasons other than just >avoiding "shout out". > >> single coordinating node, however. Your text puts it precisely: >> "consider that LowPANs *usually* have a sink of some sort" (emphasis >> mine). Forcing this to be centralized requires such a node exist and >> therefore precludes certain kinds of LowPANs. > >A solution may simply be to configure your IP addresses using an IID >derived from the EUI-64, which must be unique within a PAN. If you >really want automatic assignment of short addresses, then that's a >different beast. But it might not be worth the overhead. > >> That being said, this approach seems to implicitly assume mesh under? >> Nodes "use Neighbor Discovery to determine the link-layer addresses for >> neighbors known to reside on attached links and to quickly purge cached >> values that become invalid." ND could operate on a single hop basis. > >Let's be clear on what kind of hop. I'm sure you meant a single 15.4 >radio hop, not an IP hop. > >> This simplifies everything. The place where the whiteboard approach is >> necessary is for DAD. But given that the goal is eventual consistency on >> address assignment, it may be possible to distribute the table in an >> effective way. > >While I agree it does simplify many things, it doesn't simplify >everything :-). RFC 4861 explicitly assumes multicast-capable links with >reflexive and transitive reachability. DAD is only one example. ND is >also used for redirect and to propagate network parameters. In a >route-over configuration, the mechanisms currently defined aren't very >useful in a route-over 15.4 PAN. I'm currently signed up to work on an >I-D that addresses this case, as it is an interesting case to consider. > >-- >Jonathan Hui _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
