I would think the SLLAO in an NS would tell a 6LR that both the IP
source address and the IP address in the ARO resolve to the same MAC
address. However, if we wanted a different MAC address for the IP
address in the ARO why not just add another SLLAO following the ARO.
Question is though: Do we really need this separation, since both IP
addresses are essentially assigned to one interface with one MAC 16bit
address.
Dario
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 the
EUI-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
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
