On 08/27/10 06:28 AM, Zach Shelby wrote:
Hi,
I created a ticket for the short MAC address collision issue. Yes, we do
recognize that this is something to fix, and are happy to integrate a solution.
Of course we want to minimize the technical changes to the draft as much as
possible, and be sure that the solution doesn't have bad side-effects.
Samita posted a good problem statement to the list, which I captured in this
ticket. I threw in a couple known solutions to the ticket as well, one that was
thrown already already before/during Maastricht, and another posted to the list
by Colin. Surely there may be more as well.
I think Samita provided a useful observation, but AFAICT that isn't the
same as the problem statement. 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
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
