Subject: Re: [6lowpan] #126: Short MAC address collision

From: "6lowpan issue tracker" <[email-masked]>
Date: Tue, 14 Sep 2010 20:02:35 -0000

#126: Short MAC address collision
--------------------------------+-------------------------------------------
 Reporter:  zach@…              |       Owner:  samitac@…             
     Type:  defect              |      Status:  assigned              
 Priority:  major               |   Milestone:                        
Component:  nd                  |     Version:                        
 Severity:  -                   |    Keywords:                        
--------------------------------+-------------------------------------------
Changes (by samitac@…):

  * status:  new => assigned

Comment:

 Other solutions proposed/considered:

 3. Add "error-to" address field in the ARO between 6LN and 6LR

 4. Add a separate option “Multiple Address verification” option
      o  It is used when one wants to verify the second or third addresses
 besides the unique addr
      o  It is optional and does not require any change in the existing
 default behavior

 Analysis: We identified along with the working group that the main issue
 is being able to return the DAD duplicate NA error-status to the uniquely
 identifiable address when conflicting MAC-16 addresses are used on the
 same link.

 The authors carefully considered all the above options for solving the
 above problem and also we looked into minimal change in the document as we
 are pretty close to the last call. Also we considered applicability of
 SEND on ND if we applied each solution. Adding a separate ICMP message
 type for multihop-DAD was another consideration we discussed.

 The conclusion is a combination of "Error-to" and Colin's proposal to use
 EUI-64 in the ARO to send the error-status back to the conflicting node.
 In this case, only change in the document and code is to handle the error
 case in NA status field when NS-registration request is made. This is true
 for both multihop and single hop address registration.

 Solution:

    Address registration errors are not sent back to the source address
    of the NS due to a possible risk of L2 address collision.  Instead
    the NA is sent to the link-local IPv6 address with the IID part
    derived from the EUI-64 field of the ARO as per [RFC4944].  In
    particular, this means that the universal/local bit needs to be
    inverted.  The NA is formatted with a copy of the ARO from the NS,
    but with the Status field set to indicate the appropriate error.

 Acknowledgement: Thanks to Colin for helping with the solutions and
 providing some message examples for next revision of the 6lowpan-nd draft.

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/6lowpan/trac/ticket/126#comment:1>
6lowpan <http://tools.ietf.org/6lowpan/>