On Nov 12, 2010, at 07:58, Stephen Dawson-Haggerty wrote: > Okay, that sounds good; does that mean RPL routers might need to run > ND to solve the link-layer address of the next hop? Could I also > assume that the addresses RPL puts in the source header are derived > from link-layer addresses (maybe if we're in the same prefix) so that > I can just directly translate them? Let's face it, that's what I > really want to do :). > > Steve
(I can't answer the general question about RPL; the below is for 6LoWPAN only.) There is some text on the router-to-router use of 6LoWPAN-ND in section 6.5.5 of draft-ietf-6lowpan-nd-14.txt. The first paragraph is right to the point. The "optional" approach in the second paragraph is probably not the right way to do things in a 6LoWPAN. I don't think there is a way for a router in 6LoWPAN to send a packet to a neighboring router without revealing its L2 address, so I don't know what kind of network this functionality would be used for. (But then the same is true for most uses of SLLAO, and some people continue to insist they should be used even in 6LoWPANs.) I don't think one should ever use an algorithmic mapping of L3 to L2 addresses. (It is fine as an implementation optimization -- don't store both if they match. But never assume they will.) It is probably most useful to continue the ND part of discussion on the 6LoWPAN list; therefore I put ROLL on BCC. (Context below for 6lowpan-only subscribers.) Gruesse, Carsten > > On Thu, Nov 11, 2010 at 3:49 PM, Jonathan Hui <[email protected]> wrote: >> >> Steve, >> >> You can make the on-link assumption when using the RPL routing header. >> Section 4.2 of draft-ietf-6man-rpl-routing-header requires routers to ensure >> that the next entry is on-link. If the next entry is not on-link, the >> router must drop the packet. >> >> BTW, I'm not convinced that using 6lowpan-nd between RPL routers even the >> right approach. The current 6lowpan-nd spec is primarily focused on the >> host-router interface, which makes much more sense to me than applying the >> same protocol for router-router interfaces. >> >> -- >> Jonathan Hui >> >> On Nov 11, 2010, at 2:46 PM, Stephen Dawson-Haggerty wrote: >> >>> Ahh -- I only checked the roll mailing list archives... I don't really >>> like the idea of keeping a neighbor cache for the downstream nodes, >>> since it seems like it partially defeats the point of being >>> "non-storing"; although you only would need one-hop neighbors that >>> could still be a large set and you don't know which ones. >>> >>> I thought about just assuming it's on-link, but in that case we'll >>> need to require that there is a mapping from the global address to the >>> LL address. I think this will be mostly true, but seems like either >>> RPL or 6lowpan should explicitly require it. It's also a little >>> strange, I think, to make an exception and say that "other addresses >>> are off link, unless they're in a routing header." >>> >>> Anyways, I'll go scan those 6lowpan archives, thanks for the clarification. >>> >>> Steve >>> >>> On Thu, Nov 11, 2010 at 2:35 PM, Colin O'Flynn <[email protected]> wrote: >>>> Hi Steve, >>>> >>>> That exact problem you mention was discussed on the 6LoWPAN mailing list. >>>> If >>>> you follow the way the standards are written, it won't work since global >>>> addresses are 'off-link' and you can never reach them! >>>> >>>> How it can be accomplished though use of the neighbor cache & NUD to >>>> determine if a link is reachable or not. The point of assuming the prefix >>>> is >>>> off-link is so you don't send NS for an unreachable node, but instead send >>>> to the default router. But if you have NC entries, you should consider the >>>> nodes on-link. See section 6.5.4 of 6lowpan-nd-14. >>>> >>>> Another method is just to always assume a node which you have received a >>>> downward source route to is reachable. Presumably RPL is taking care of >>>> ensuring that node is actually registered through you, so if you got a >>>> message which indicates the next-hop is that node, it should be reachable. >>>> >>>> HTH, >>>> >>>> -Colin O'Flynn >>>> >>>> >>>> -----Original Message----- >>>> From: [email protected] [mailto:[email protected]] On Behalf Of >>>> Stephen Dawson-Haggerty >>>> Sent: November 11, 2010 5:12 PM >>>> To: ROLL WG >>>> Subject: [Roll] Non-storing mode address types >>>> >>>> Hi -- trying to figure out how to construct downward source routes using >>>> DAOs. >>>> >>>> The 6lowpan-nd draft says that "All other prefixes are assumed to be >>>> off-link ... They are therefore sent to one of the routers in the >>>> Default Router List." This presumably means up, not down, so the >>>> addresses in the routing header wold need to be link local? It seems >>>> more likely that RPL wanted them to be global, though? >>>> >>>> Related, the target option in the DAO specifies a global address, of >>>> course; it looks like the parent address is also a global address. >>>> This is what leads to my confusion about the source route because >>>> while you can construct a path of global addresses, I must be missing >>>> how the intermediate hops can resolve the next hops of the addresses. >>>> >>>> If the parent addresses were link-local, I think it would work, so >>>> long as the originating DAO also included a SLLA option; then the path >>>> would be composed of only link-layer addresses. This seems a little >>>> strange, though. I looked in 6.7.8 and 9 for guidance on this, but am >>>> still confused... >>>> >>>> Thanks, >>>> Steve >>>> >>>> -- >>>> stephen dawson-haggerty >>>> http://cs.berkeley.edu/~stevedh >>>> uc berkeley wireless and embedded systems lab >>>> berkeley, ca 94720 >>>> _______________________________________________ >>>> Roll mailing list >>>> [email protected] >>>> https://www.ietf.org/mailman/listinfo/roll >>>> >>>> >>> >>> >>> >>> -- >>> stephen dawson-haggerty >>> http://cs.berkeley.edu/~stevedh >>> uc berkeley wireless and embedded systems lab >>> berkeley, ca 94720 >>> _______________________________________________ >>> Roll mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/roll >> >> > > > > -- > stephen dawson-haggerty > http://cs.berkeley.edu/~stevedh > uc berkeley wireless and embedded systems lab > berkeley, ca 94720 > _______________________________________________ > Roll mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/roll _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
