Hello, It is slightly more general than where the 16bit MAC & IPv6 address is duplicate. I see the problem as:
When sending an NA+ARO back to a global address that is a duplicate, that address will already be in the 6LR neighbor cache. There are then two possible problems: *If the MAC address of the 6LN is the same for the conflicting & existing node, it may be difficult to deliver the response reliably *Some stacks may have difficulty sending an IPv6 message to a specific MAC address, when the destination IPv6 address already has a neighbor cache entry with a different MAC address. Provided the proposed "error-to" address is unique in both the IPv6 & MAC address domain, I would see this as an acceptable solution to either problem. Regards, -Colin -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Samita Chakrabarti Sent: August 31, 2010 2:29 AM To: 'Erik Nordmark'; 'Zach Shelby' Cc: [email protected] Subject: Re: [6lowpan] #126: Short MAC address collision > The problem statement as I understand it is that > when there is a duplicate 16 bit MAC address and associated GP16 address it > is hard to ensure that the NA+ARO indicating the duplicate is reliably > delivered back to the host. > > Erik > [SC>] Exactly. That it is the blocking issue when two conflicting Mac-16 addresses are on the same link and one of them is being registered or already registered. The problem is how to ensure to deliver the error to the proper requesting node. Hence Colin's proposal is to use the MAC-64 unique address and corresponding IPv6-address as the src-addr of registration and make some space to allow to carry the GP-16 address for verification. I was trying to generalize this problem in the problem statement. Thanks, -Samita > > Zach > > > > On Aug 27, 2010, at 4:23 PM, 6lowpan issue tracker wrote: > > > >> #126: Short MAC address collision > >> --------------------------------+------------------------------------ > >> --------------------------------+------- > >> Reporter: z...@. | Owner: sami...@. > >> Type: defect | Status: new > >> Priority: major | Milestone: > >> Component: nd | Version: > >> Severity: - | Keywords: > >> --------------------------------+------------------------------------ > >> --------------------------------+------- > >> An EUI-64 node may want to use non-EUI-64 based IPv6 address for > >> communication or it may want to register multiple addresses at the > >> same time via multihop DAD mechanism. We need a way to verify that > >> the additional IPv6-address and its corresponding link-layer > >> address(non- > >> EUI-64) are unique in a 6lowpan network. [ via multi-hop DAD mechanism]. > >> However, for the address registration NS message, the node should use > >> an > >> EUI-64 based IPv6-address and corresponding MAC address to avoid any > >> collision in the local link due to duplicate MAC-addresses. > >> > >> There are a couple different ways to allow an LL64 to be used during > >> registration of a tentative (possibly non-unique) address. > >> > >> 1. Carry the address to be registered in the ARO for the initial > >> registration of a tentative address. Use the address to be registered > >> as the IP SRC address after that as in ND-12. No changes required to > >> the multi-hop DAD mechanism. > >> > >> 2. Carry the address to be registered and the LLA always in the ARO, > >> see proposal by Colin on the list. > >> > >> -- > >> Ticket URL:<http://trac.tools.ietf.org/wg/6lowpan/trac/ticket/126> > >> 6lowpan<http://tools.ietf.org/6lowpan/> > >> > > > > > > > > _______________________________________________ > > 6lowpan mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/6lowpan > > _______________________________________________ > 6lowpan mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/6lowpan _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
