Hi Jonathan >> Actually this is not true anymore in nd-06. Based on feedback in >> Stockholm, we relaxed the IID-MAC mapping assumption. If you have a >> LoWPAN that for some reasons assigns an IID that requires address >> resolution, this can be performed on the host-router interface. > >That's great, but can you explain how a node determines whether or not >it needs to perform address resolution? I wasn't able to find how in >draft-06.
A good thing to clarify for sure; I do not remember that we have left anything on target address resolution. In route over, the only address(es) that the node uses at the moment is that of its router(s). The address is found in the RA source MAC and the neighbor relationship is maintain using NR/NC messages. The draft does not attempt to shortcut for P2P - then again the model is very similar to 802.11 infra mode. There's discussion at RPL about line of sight P2P, though, and it appears that we could add something like multicast NA(override) when the address is obtained (and renewed). In mesh under, there used to be some text inherited from the backbone router draft about using the edge router for address resolution. The edge router would be answering with either its own address if the target is to be reached over the backbone of the address of the node if the target is to be reached over the mesh. But the backbone router draft was really minded 802.15.4 and mesh under. This service cannot be generalized to all sorts of NBMA/P2MP where the edge router cannot be assumed to know whether the node can see its destination at L2 and if so at which address. Considering how little assumptions we can safely make about mesh under in general, we dropped resolution and redirection, and stayed on common grounds with route over, that is reachability via the routers. If a given media offers more direct routes and L2 triggers like an (I-)LMI status indicating a Virtual Circuit up/down, then an existing technique such as inverse ND can be used on top of 6LoWPAN ND to resolve those. >>> 2) Using NR/NC exchanges to provide NUD. With the current draft, >>> NR/NC exchanges only maintain reachability information for the link- >>> local address of the attachment router. However, NR/NC exchanges, >>> as defined, cannot provide reachability information for global >>> addresses. Additionally, NR/NC messages cannot be used to maintain >>> reachability information for neighboring hosts (not routers). >>> >> >> Good example. If this is really a problem we can look at ways to >> improve that of course. I don't follow you on why they can't provide >> reachability info for global addresses (from Address Options) - but >> let's talk about that separately. > >Testing reachability is traditionally done by actually using the >target address to send messages. Using the address options only tells >you that the node *thinks* they are assigned to the interface - it >does not test that communication >is actually possible when using the target address. Good thing to clarify as well: Address resolution is not used/needed/required when there is a router between a node and its target. ICMP unreachable is your friend there. Since the draft always goes through the router, only the router needs actual (un)reachability testing. The draft uses NR/NC messages to cover the node to router hop and ICMP unreachable for all other destinations. Then again, some mesh under networks might provide additional P2P connectivity, and then again, there's existing ND operation such as RFC3122 that can be used there. No re-inventing the wheel, no sir. >>> I'm not convinced that these are the only examples that we need to >>> be aware of with the existing draft. I'm also not convinced that >>> enough people have weighed in on the examples above to say that >>> such implications are OK >> >> This is exactly what last call is for ;-) Forcing everyone to >> actually read the thing again, and to make constructive comments. > >I was trying to encourage people to spend the extra cycles by raising >some issues I'm aware about, irrespective of whether or not the draft >is in WGLC. What seems left somewhat open from your mail is: 1) whether a node c/should mcast NA(OverRide) for line of sight P2P. I'd be OK to allow that? 2) whether NR/NC messages do an appropriate job for NUD. At the moment they are simply periodic. Is that enough? Personally I think so. Cheers, Pascal _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
