Hi Pascal, Pascal Thubert (pthubert) wrote: > 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.
Yes, IID from EUI-64 isn't the best solution for many cases. I was only suggesting a quick-and-dirty possibility for those cases where a centralized solution is not favorable. > 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 plan to address both SAA and DHCPv6 in a route-over autoconfiguration for 6LoWPAN draft. We should coordinate our efforts to see if there's some commonality. While I expect mesh-under and route-over to utilize different mechanisms, it would still be good to make them similar in areas that they do overlap. On a side note, I'm not sure we want to use the formats as specified in RFC3315. I was thinking of scoping RFC3315 and making it less general to compress the DHCPv6 options formats. For Carsten: DHCP does use link-local multicast, but such a restriction hasn't stopped us from optimizing protocols in 6LoWPAN networks to utilize unicast communication. -- Jonathan Hui > 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
