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. 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.
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, Such a system as I'm proposing would only need to use the LL-64 based address for the initial part of DAD. Only the node it is registering through/to knows about this LL-64 based address. When the node first powered on and performed a RS, it would have already used the LL-64 address as the source of the RS. Thus I don't think you are really exposing/using any additional information, since your one-hop neighbors already talked to you on your LL-64 based address. One additional consideration I thought of: The method as currently used in ND-12 DOES provide the linkage between the 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. Regards, -Colin O'Flynn -----Original Message----- From: Carsten Bormann [mailto:[email protected]] Sent: August 23, 2010 8: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 theEUI-64 (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 [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
