Re: [6lowpan] ND Short Address Collisions

["Samita Chakrabarti" <[e-mail]>]

Hi Colin and all,

We have been discussing the short address and duplicate MAC address
implementation issues for a while. The similar problem may happen in IPv6
today during DAD phase. My understanding is that Neighbor discovery protects
the hosts from having duplicate IP-addresses while we are discussing the
corner case of how to solve duplicate MAC address via 6lowpan-ND.

Please note that 6lowpan-ND assumes that link is secure and each host
possesses EUI-64 unique number for its interface. Thus if one turns on short
MAC address (16bit MAC) feature which is not guaranteed to be unique, it is
very logical to assume that uniqueness of such MAC address would be verified
at the link-level during the bootstrap by checking with a network-wide
authentication server or via DHCP service. 

ND-12 updates section 8.2 with the following text:

"   For the synchronous multihop DAD the 6LR performs some additional
   checks to ensure that it has a Neighbor Cache entry it can use to
   respond to the host when it receives a response from a 6LBR.  This
   consists of checking for an already existing (Tentative or
   Registered) Neighbor Cache entry for the registered address with a
   different EUI-64.  If such a Registered NCE exists, then the 6LR
   SHOULD respond that the address is a duplicate.  If such a Tentative
   NCE exists, then the 6LR SHOULD silently ignore the ARO thereby
   relying on the host retransmitting the ARO."

The IETF draft will define specification in general case, but it will not
provide specification for each implementation in a specific standard
development organization. By using GP16 addresses, ZigBee can specify
additional constraints upon using 6lowpan-nd for deployment. But it does not
require change in the IETF document. Please understand this difference.

Zach provided some examples as to how to support GP16 addresses in ND phase
on the mailing list. In later version, we can add one of those examples in
the Appendix section of the document to clarify usage in short MAC address
cases, if that is helpful for ZigBee IP implementation.

Please see below. These are some of my personal comments.

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf
> Of Carsten Bormann
> Sent: Monday, August 23, 2010 12:10 PM
> To: Colin O'Flynn
> Cc: 6lowpan 6lowpan
> Subject: Re: [6lowpan] ND Short Address Collisions
> 
> On Aug 21, 2010, at 13:45, Colin O'Flynn wrote:
> 
> > putting in 6lowpan-ND that you must send from an address based on the
EUI-
> 64
> 
[SC>]  Originally we had the restriction of EUI-64-based address support
only.
ND-simple and other previous version of 6lowpan-nd. But we relaxed that to
support other types of addresses [ as mentioned by Carsten below] and
ofcourse GP16 addresses. But we still require a EUI-64 bit unique number to
identify an interface uniquely in ARO.

In terms of SLLAO, we require SLLAO to be provided with NS because no state
or NCE is created before then. This is done for maintaining generality of
implementations and for double checking the uniqueness of link-layer
addresses for the requested address registration. Also note that 6lowpan-nd
allows a tentative NCE after receiving RS, but there is a timeout.

Thanks,
-Samita


From: [e-mail] [mailto:[e-mail]] On Behalf
Of Colin O'Flynn
Sent: Saturday, August 21, 2010 4:45 AM
To: 'Westergreen Mads-MWEST2'; [e-mail]; 'Dario Tedeschi'
Cc: [e-mail]
Subject: Re: [6lowpan] ND Short Address Collisions

Hello,

Would there be support for putting in 6lowpan-ND that you must send from an
address based on the EUI-64 instead of anticipated 16-bit address? I think
it is more consistent with what is already in 6lowpan-ND. Consider the
following:

>From the assumptions section of 6lowpan-ND, we have:

   o  EUI-64s are globally unique.

   o  All nodes in the LLN have an EUI-64 interface identifier in order
      to do address auto-configuration and detect duplicate addresses.

Thus 6lowpan-ND is already assuming we have a link-local address based on an
EUI-64. Based on those two assumptions you could greatly simplify processing
of NA by performing the following when you receive a NA message:

       [1] Is the EUI-64 my address? If so skip to general processing (not
shown here)

       [2] Am I a 6LR? If so continue to step 3, otherwise abort as nothing
more to do.

       [3] Generate an address by performing the address autoconfiguration
               algorithm on the EUI64 in the ARO with the link-local prefix

       [4] Forward the message to the address generated in step 3,
recalculating ICMPv6 checksum

Such a setup has the following disadvantages:
 -You ALWAYS transmit the registered address in the ARO on first hop,
wasting 16 bytes

But the following advantages:
-Cannot have collision of two 802.15.4 ACK's because you are transmitting to
two nodes at once
-Less FLASH usage, since you have removed temporary NCE, and always use the
same ARO Length which further simplifies code
-Less SRAM usage, since you never need a neighbor cache entry for multi-hop
DAD to complete
-ARO registered address can be changed by ABR. For example if ABR notices a
node is re-registering after that node reboots, the ABR could change
registered address to nodes old address in NA it sends back.
-Avoids "hacks" when sending last-hop NA. By "hack" I mean that people may
just take registered address out of ARO, and send 802.15.4 message to lower
16 bits of registered address, since they are only every registering GP16
addresses in their case. By instead explicitly using EUI-64 to generate
address, you decouple the registered IPv6 address from the MAC address used
during registration. Thus the same code could in the future be used to
register any address, not just GP16 addresses. It is only the final hop that
knows if there should be any correlation between IPv6 address & 802.15.4
address, not intermediate nodes.
-Does not need SLLAO in initial NS

Comments?

  -Colin


> (I assume, this is for 6LoWPAN-ND transactions that register/DAD a 16-bit
> address.)
> 
> One of the decisions we made on the way from ND-08 to ND-09 was to
simplify
> the protocol by basing more of it on the assumption of uniqueness of the
> EUI-64 address.
> Your proposal therefore seems like a logical consequence, as it seems it
> indeed simplifies things more.
> 
> But let's consider what we lose:
> 
> -- the use of privacy addresses in this capacity.  Since we already need
to
> have the EUI-64 exposed to do DAD, I see little loss.
> -- the use of CGA (cryptographically generated addresses) in this
capacity.
> Well, maybe not.  Since a CGA SHOULD be about as unique as an EUI-64, it
> MIGHT be a good substitute if the keys are generated with the same care
that
> we think EUI-64s are instilled.
> -- any other scheme that really wants to use a different kind of address
for
> uniqueness.
> 
> I haven't formed an opinion yet -- I'm still in the process of trying to
> understand the trade-offs.
> 
> Gruesse, Carsten
> 
> _______________________________________________
> 6lowpan mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/6lowpan