Hi Erik: RPL does not have an assumption on this ND operation in particular nor on 4861. But then, the interworking of ND and RPL is left to further work. I hope this work happens somewhere someday. In particular, RPL is prepared to redistribute external routes and that could include host routes learnt from registration. But then, RPL, like the backbone router draft operation, needs the TID that is now gone from ND, to recognize the update from the stale when the LBR states are distributed and clean up.
Cheers; Pascal http://www.xtranormal.com/watch/7011357/ > -----Original Message----- > From: [email protected] [mailto:[email protected]] On > Behalf Of Erik Nordmark > Sent: Tuesday, March 29, 2011 1:14 PM > To: Mukul Goyal > Cc: 6lowpan > Subject: Re: [6lowpan] "Advertize on Behalf" flag in ARO > > On 3/3/11 5:07 AM, Mukul Goyal wrote: > > Hi all > > > > Recently Anders pointed out the need for the "Advertize on Behalf" > > flag in an Address Registration Option (ARO). > > > > We would not have needed this flag if only a host could send a unicast > > NS containing an ARO. However, the way I read Section 6.5.5 in nd-15, > > a 6lowpan router (6LR) can also send a unicast NS to another 6lowpan > > router. This means that a registered neighbor cache entry (NCE) in a > > 6LR could refer to either a host or another 6LR. So, how does a 6LR > > know that a registered NCE belongs to an attached host and it should > > advertize reachability to this host in the routing protocol, such as > > RPL, it is running? > > > > The proposed flag will solve this problem. A host would set "Advertize > > on behalf" flag when it sends an ARO inside a unicast NS message, > > whereas a 6LR wont. > > > > I was wondering if ND authors could comment on this. > > I didn't see anybody else comment, so let me try. > > I don't know what assumptions RPL makes in particular, but if we are talking > about a general case of a routing protocol, I don't see why there would be a > need to tell a difference between a host sending an ARO and a router (which > might be initializing and haven't yet enabled routing and forwarding) sending > an ARO. > > In both cases I'd assume that the unicast address that is registered is > something that should be reachable, hence it makes sense advertising > reachability to that address. > > If this isn't the case, then a routing protocol would typically find out about its > neighboring routers IP addresses, and from that it can decide to treat those > IP addresses differently than the addresses assigned to hosts. > > Erik > _______________________________________________ > 6lowpan mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/6lowpan _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
