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. 

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/>
> 

-- 
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

Attachment: smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan

Reply via email to