> 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
