On 19 August 2013 18:57, Fernando Gont <fg...@si6networks.com> wrote: > Erik, > > On 08/19/2013 06:40 AM, Erik Kline wrote: >> I pre-apologize, as always, for my ignorance, but...is there an >> implementation of this? Specifically, I'm mildly concerned about this >> for link-local addresses. >> >> Compliant implementations cannot even begin any IPv6 link-local >> operations until the secret key has been loaded from stable storage. >> They also should load the DAD_Counter from non-volatile memory before >> starting link-local operations. And they MUST NOT fallback to other >> link-local autoconfig implementations (last paragraph of section 4). >> >> I agree that this all seems fine in theory. Are we collectively >> convinced this will not lead to tragically (IPv6-)orphaned machines in >> certain scenarios? > > Sorry, what are the scenarios you have in mind?
Well, I guess first I wasn't 100% sure I could think of all the link-local uses and how they would interact with needing to load parameters before starting essential functions for higher layer IPv6 and application things. However, as I said I can't see a problem with it in theory. It's one more thing to wait for before waiting for DAD to complete. No theoretical change; fine. But secondly, how would you implement this in, say, Linux? Right now link-local IPv6 things can begin as soon as the module is loaded or as soon as an interface becomes active if it's already loaded. To support this scheme as I understand it, the Linux kernel ipv6 code would need to take some module parameters at boot or load time, so as to force it to not do link-layer-derived link-local autoconfig but instead load up the required parameters from non-volatile storage. Is my understanding correct? If so, has anyone written this and gotten feedback from net maintainers? I guess I just think that all of the concerns about addresses raised in draft-cooper-6man-ipv6-address-generation-privacy *don't* meaningfully apply to link-local addresses. That document's section 4.2.2 says that the addresses are basically available to an on-link adversary anyway. So I guess I don't see the point of "fixing" something that I don't think is actually broken in this specific context (speaking of link-local use case specifically). -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
