Just to reiterate on ND: The creation of an NCE to hold the unconfirmed IP/LL address of the joining node does not make sense for the reasons Colin has clearly outlined. It also contradicts generally the usage of options to carry information where statelessness is required, e.g. RS/RA. Therefore, as I have said many times before, it makes more sense to carry this (these) addresses in the options.
Please note these observations are coming from an interop event with 10 participants, all using different, real-world platforms based on radios and all observing the same issue. Therefore I think this really needs to be given proper credence in the working group. I would go so far as to say we should change ND to carry the information in the options and consider if there are any issues with that. SEND was mentioned, but I would like to see a proper explanation of why that is an issue.
We will probably implement an alternative and test that to prove it works and would be the right way forward.
Robert Robert Cragie (Pacific Gas & Electric) Gridmerge Ltd. 89 Greenfield Crescent, Wakefield, WF4 4WA, UK +44 1924 910888 +1 415 513 0064 http://www.gridmerge.com <http://www.gridmerge.com/> On 08/10/2010 9:26 AM, Colin O'Flynn wrote:
Hi Mathilde, 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? 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? 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. Regards, -Colin -----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 forconnectivitybefore 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
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
