Re: [6lowpan] ND Short Address Collisions

[Robert Cragie]

 Hi Samita,

Comments inline, bracketed by <RCC></RCC>

Robert

Robert Cragie (Pacific Gas & Electric)

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 1924 910888
+1 415 513 0064
http://www.gridmerge.com <http://www.gridmerge.com/>


On 25/08/2010 11:40 PM, Samita Chakrabarti wrote:

Hi Robert,

Please see below.

*From:* 6lowpan-boun...@ietf.org [mailto:6lowpan-boun...@ietf.org] *On Behalf Of *Robert Cragie

*Sent:* Tuesday, August 24, 2010 8:58 AM
*To:* Colin O'Flynn
*Cc:* 'Carsten Bormann'; '6lowpan 6lowpan'
*Subject:* Re: [6lowpan] ND Short Address Collisions

I fully support this. I am disappointed that it got such short shrift in Maastricht, to be honest. */[SC>] Sorry for your disappointment. The problem is that we cannot tune the IETF document too much to one deployment or implementation. Also, note that tentative NCE solves the duplicate IP-address detection problem immediately at the on-link and on multi-hop cases. Trying to solve duplicate MAC address detection by 6lowpan-ND, IMHO is too much to ask from the L3 protocol. Can't 6lowpan-nd assume that the L2-address uniqueness are ensured by either assigning EUI-64 based MAC addresses or by some other means during bootstrapping?/*

<RCC>



</RCC>

The point is this work was developed under the 6lowpan WG. So it seems contradictory to then state that it can't be tuned to one deployment or implementation; surely that was the whole point of developing it in the first place? On the basis that 802.15.4 uses 16-bit addresses, and 6lowpan is aimed at 802.15.4, it has to be correctly supported in the proposal. The way 6lowpan is specified now, and the general case of address autoconfiguration will mean there is always a two-way relationship between the MAC and the IPv6 address. In that case, it seems reasonable to me that duplicate address detection for the IPv6 address performs the same function. So if you additional bootstrapping is needed to ensure the 16-bit MAC address is unique prior to ND, then, based on the autoconfiguration rules, there will be no particular need for NS/NA to perform the address registration for the purposes of address conflict resolution as this will already have been done. If this is the intention, then the way ZigBee IP for one uses 6lowpan ND will have to be completely reconsidered.

*//*





*/[SC>] /*



*/ /*







*/BTW, I assume you meant 6LBR instead of ABRO above -- right?/*

Firstly, one question is: Is 6lowpan ND always going to be for just 6lowpan? This may seem a stupid question but consideration has been given so far to cases which clearly do not exist in 6lowpan, e.g CGAs and IP addresses which do not have two-way mapping with a MAC address. */6lowpan-nd, to my knowledge is targeting a larger scope. 6lowpan is obviously the primary deployment area today. It could also be equally applicable to any lossy or unreliable mesh network such as Wifi mesh-network or a mesh network of any route-over topology./* If the answer to this is yes, there is a strong argument for optimising all of the ND protocol to benefit from the two-way mapping between the IP address and MAC address property, including e.g. eliding LLAOs. Also the whole CGA issue is also meaningless for 6lowpan as the addresses are clearly not cryptographically generated. If the answer to the first question is "possibly not", would we then have to carry both the tentative MAC address and IP address in the ARO and have the ABRO check both for the case where there is no two-way mapping between the IP address and MAC address? The alternative could be to carry it in the target address, but that is overloading its meaning somewhat and probably not appropriate. Also, if we have to consider CGAs, then it would be possible to carry some addtional option. */[SC>] What you are proposing here seems only needed for non-unique MAC addressed multi-hop network. Perhaps we can look into adding an optional multihop-address option between 6LR-6LBR to take care of this. It might be applicable for other scenarios than GP16 address collision. Let me check with the co-authors./*

<RCC>It is needed where the IPv6 address is not autoconfigured from the MAC address and where the MAC address itself needs to be checked. Earlier you say it's too much to ask for an L3 protocol, but LLAOs are used widely, so I don't think it's out of scope. Yes, I meant 6LBR (the device the ABRO points to).</RCC>

*//*

*/ /*

*/Thanks,/*

*/-Samita/*

*/ /*

*/ /*

*/ /*


Robert

Robert Cragie (Pacific Gas & Electric)

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 1924 910888
+1 415 513 0064
http://www.gridmerge.com <http://www.gridmerge.com/>


On 23/08/2010 8:57 PM, Colin O'Flynn wrote:

Hi Carsten,

address for the initial part of DAD. Only the node it is registering
through/to knows about this LL-64 based address.

used the LL-64 address as the source of the RS.

since your one-hop neighbors already talked to you on your LL-64 based
address.

L2 address&  IPv6 address being registered. This allows the parent of the
node to update its neighbor cache when it receives the confirmation of a
successful address registration. Using the method I'm proposing would
require:
   -Infer the L2 address somehow, for example in the GP16 case you can infer
the L2 address
   -Add a SLLAO/TLLAO to the NS message that tells the parent what the L2
address of this IPv6 address that is being registered WOULD be if the
registration is successful. This is probably hacking RFC4861 in unacceptable
ways.
   -Add the link-layer address to the ARO, the only 'clean' solution I see.

From: Carsten Bormann [mailto:c...@tzi.org]
Sent: August 23, 2010 8:10 PM
To: Colin O'Flynn
Cc: 6lowpan 6lowpan
Subject: Re: [6lowpan] ND Short Address Collisions

    putting in 6lowpan-ND that you must send from an address based on the

EUI-64

address.)

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.

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.

understand the trade-offs.

6lowpan mailing list
6lowpan@ietf.org  <mailto:6lowpan@ietf.org>
https://www.ietf.org/mailman/listinfo/6lowpan

Such a system as I'm proposing would only need to use the LL-64 based When the node first powered on and performed a RS, it would have already Thus I don't think you are really exposing/using any additional information, One additional consideration I thought of: The method as currently used in ND-12 DOES provide the linkage between the Regards, -Colin O'Flynn -----Original Message----- On Aug 21, 2010, at 13:45, Colin O'Flynn wrote: (I assume, this is for 6LoWPAN-ND transactions that register/DAD a 16-bit One of the decisions we made on the way from ND-08 to ND-09 was to simplify But let's consider what we lose: -- the use of privacy addresses in this capacity. Since we already need to I haven't formed an opinion yet -- I'm still in the process of trying to Gruesse, Carsten _______________________________________________

smime.p7s
Description: S/MIME Cryptographic Signature

_______________________________________________
6lowpan mailing list
6lowpan@ietf.org
https://www.ietf.org/mailman/listinfo/6lowpan