Erik, We're in a loop.
I thought you agreed that a random (that you called a key) was a simple and good enough tool to differentiate 2 nodes that would be using a same address, EUI based or not. We agree that the random (key) would be better stored in persistent memory, whenever possible. I agree with your point that the node does not need to know what the LR does with the LBR, that's backend stuff. I agree with your other point that the LR can respond quickly yes to registration and then kill it later for a number of reasons. My point is that one such reason could be that a back end check with the LBR says that this address is a actually a dup, as detected by a different random. Pascal > -----Original Message----- > From: Erik Nordmark [mailto:[email protected]] > Sent: Tuesday, June 01, 2010 2:00 PM > To: Pascal Thubert (pthubert) > Cc: Tetsuya Murakami; [email protected] > Subject: Re: [6lowpan] SLLA option in NS > > On 06/ 1/10 04:23 AM, Pascal Thubert (pthubert) wrote: > > >> So a host with EUI-64=X boots, and uses boot-time-random=Y. Registers > > with > >> a lifetime of say three days. > >> Then the host is rebooted, comes back up and uses boot-time-random=Z. > >> > >> Then it will fail to register its EUI-64-based, since it will be a > > duplicate. > >> > >> The issue is that the information used to identify the node (to tell > > two nodes > >> apart) must be in stable storage. > >> That probably means that a spoofed/cloned host would duplicate that > >> information as well. > >> > >> Hence adding more information doesn't seem to help. > >> [...] > >> > > [Pascal] In the simplest instance I expected to use the rnd as a > > simple correlator, though. > > But if it helps to call it a key let's call it that way. We seem to > > have problems with agreeing on names :) > > I think you are missing or ignoring my point about stable storage. That is the > key point - not the name. > > >> If DAD fails for a short address, then the host should try a > >> different > > short > >> address. Ditto if it is a RFC 4941 temporary address. > > > > [Pascal] I was asking about the EUI-64 based address. A node > > registers, and the router says no. > > Please read 6lowpan-nd-09. > > A 6LR doesn't say no for an EUI-64 based address because we assumes > EUI-64 are globally unique, hence no duplicates can exist by definition. > > And as I outlined in an email earlier, I believe forgeries/spoofs/clones are > undetectable in 6lowpan networks. > > > Like I said, most probable cause are misconfig and silicon forgery. > > The EUI-64 shouldn't be configurable; it should come from the factory. > > Erik _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
