Hi, Let me try to summarize on this thread, I do agree with Mathilde that we need to improve the sending algorithm behavior in the draft. I will make a new ticket to deal with these.
First of all, tentative NCE entries were not intended to be used for on-link determination, as Samita pointed out. If we remove the tentative NCE entries from the draft, then this is no issue (see Robert's request). Otherwise we need to clarify this. As mentioned below, the sending algorithm does need updating. First of all, the intention was that a normal NCE is used for on-link determination of a global address, as well as for address resolution, as we can't match the prefix in the route-over case. Text should be added on that to Section 5.6. Mathilde brought up the mesh-under on-link issue. This is a good point, and I agree that with mesh-under technologies you might want to use the L (on-link) flag of the RA to indicate that the prefix is on-link. Even in some types of mesh-under networks it might be wise to assume prefixes are off-link, and thus traffic goes through the 6LBR. This change would require the text in Sections 6.1 and Section 5.6 to be updated. Would these updates resolve the issues brought up in this thread? Zach On Oct 8, 2010, at 10:09 PM, Colin O'Flynn wrote: > Hi Mathilde, > >> Like traditional entries they >> contain the IPv6 address / l2 address mapping however in terms of >> "conceptual sending algorithm behavior" they are more like routing table >> entries. > > Indeed, then you have this neighbor table collision problem if you use them > as such. > > I think 6lowpan-nd is not clear on updating the 'conceptual sending > algorithm' though and how it works over different links. This is especially > a problem for example with mesh-under, where everything is on-link and you > need to send directly. > > Regards, > > -Colin > > -----Original Message----- > From: Mathilde Durvy (mdurvy) [mailto:[email protected]] > Sent: October 8, 2010 1:14 PM > To: Colin O'Flynn; [email protected] > Subject: RE: [6lowpan] 6lowpan-nd neighbour table collision > > Hi Colin, > > Admittedly I know better 4861 than 6lowpan-nd but I think the "conceptual > sending algorithm" is mostly the same. So let me try to answer based on my > understanding... > > > [Colin] I appreciate the link to that description, as it raises some other > questions > for me. In 6lowpan-nd it specifically says that anything but link-local is > off-link, in which case you wouldn't use the NC for anything but link-local > correct? > [Mathilde] Correct, although you still need the NC to find the mapping > between the default router IPv6 address and its L2 address > > [Colin] I had assumed the NC could be used to check if a specific address > was > on-link or not in the absence of other information. From RFC4861 definition: > Neighbor Cache > - A set of entries about individual neighbors to > which traffic has been sent recently. Entries are > keyed on the neighbor's on-link unicast IP address > and contain such information as its link-layer > address, a flag indicating whether the neighbor is... > But 6lowpan-nd says anything but fe80:: is off-link. Thus if you have a > message to a global prefix device, you always send to the default router? > [Mathilde] yes; default router or next-hop as specified by the routing > protocol. > > [Colin] Thus lacking a routing protocol, how could a 6LR send a NA to a 6LN > if that > 6LN registered a global address? The 6lowpan-nd-examples currently have > this: > If Status is a Success: > > 6LR ---------NA-Reg------->6LN > Src= LL64 (6LR) > Dst= GP16 (6LN) > ARO with Status = 0 > If this is 'illegal' then I take full credit for not fully understanding how > IPv6 works in creating that example ;-) But I think other people were > assuming that would work fine as well w/o a routing protocol. > [Mathilde] ] My understanding is that registrations are treated differently > as traditional ND entries (or tentative NCE). Like traditional entries they > contain the IPv6 address / l2 address mapping however in terms of > "conceptual sending algorithm behavior" they are more like routing table > entries. > > > -----Original Message----- > From: Mathilde Durvy (mdurvy) [mailto:[email protected]] > Sent: October 8, 2010 8:42 AM > To: Colin O'Flynn; [email protected] > Subject: RE: [6lowpan] 6lowpan-nd neighbour table collision > > Hi Colin, > > It seems to me that if the addresses are global, presumably built on a > off-link prefix there is no problem. > >> The ABR is address fe80::33:44 so it will now send a multihop ND message. >> The regular IPv6 sending algorithm will first search the NC for > connectivity >> before sending through the default router (fe80::11:22). > > Actually what the IPv6 algorithm says is > " Next-hop determination for a given unicast destination operates as > follows. The sender performs a longest prefix match against the > Prefix List to determine whether the packet's destination is on- or > off-link. If the destination is on-link, the next-hop address is the > same as the packet's destination address. Otherwise, the sender > selects a router from the Default Router List" > " Once the IP address of the next-hop node is known, the sender > examines the Neighbor Cache for link-layer information about that > neighbor." > > Best, > Mathilde > _______________________________________________ > 6lowpan mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/6lowpan > > > _______________________________________________ > 6lowpan mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/6lowpan -- Zach Shelby, Chief Nerd, Sensinode Ltd. http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
