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

From: "6lowpan issue tracker" <[email-masked]>
Date: Fri, 27 Aug 2010 13:23:40 -0000

#126: Short MAC address collision
--------------------------------+-------------------------------------------
 Reporter:  zach@…              |       Owner:  samitac@…             
     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/>

---

From: Zach Shelby <[email-masked]>
Date: Fri, 27 Aug 2010 16:28:03 +0300

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 

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

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 30 Aug 2010 18:05:15 -0700

> #126: Short MAC address collision

3. Introduce an "errors-to" field in the ARO.

    Erik

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 30 Aug 2010 18:07:37 -0700

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

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

>> Ticket URL:<http://trac.tools.ietf.org/wg/6lowpan/trac/ticket/126>
>> 6lowpan<http://tools.ietf.org/6lowpan/>
>>
>
>
>
> _______________________________________________
> 6lowpan mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6lowpan

---

From: "Samita Chakrabarti" <[email-masked]>
Date: Mon, 30 Aug 2010 18:28:35 -0700

> 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

> >> --------------------------------+------------------------------------
> >> --------------------------------+-------
> >> Reporter:  zach@.              |       Owner:  samitac@.
> >> --------------------------------+------------------------------------
> >> --------------------------------+-------
> >> 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-
> >> 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.
> >>
> >> --

---

From: "Colin O'Flynn" <[email-masked]>
Date: Tue, 31 Aug 2010 09:28:37 +0100

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-masked] [mailto:[email-masked]] On Behalf
Of Samita Chakrabarti
Sent: August 31, 2010 2:29 AM
To: 'Erik Nordmark'; 'Zach Shelby'
Cc: [email-masked]
Subject: Re: [6lowpan] #126: Short MAC address collision

it
[SC>] 

Thanks,
-Samita