On Fri, 2012-04-13 at 15:29 +0200, Fernando Gont wrote: > "IPv6 implementations conforming to this specification MUST generate > interface identifiers using the algorithm specified in this section in > replacement of Modified EUI-64 format identifiers." > ?
While that is good, it would be clearer if it was expanded out to make the desired points separately: It is intended that the use of Modified-IEEE interface identifiers be replaced wherever possible by the use of interface identifiers generated as described in this specification. When generating interface identifiers, IPv6 implementations conforming to this specification MUST use the algorithm specified in this section. [I'm not sure this is necessary - it seems to be saying that "conforming implementations have to conform"] IPv6 implementations conforming to this specification MUST NOT use Modified-IEEE format interface identifiers [see 4291 Appendix A] for any purpose EXCEPT THAT link local addresses MAY be generated using Modified-IEEE format interface identifiers. [remove everything from EXCEPT THAT onwards if that isn't what you intended] If for any reason the generation of an interface identifier according to this specification fails, IPv6 implementations conforming to this specification MUST NOT fall back to using Modified-IEEE format interface identifiers. Interface identifiers other than Modified-IEEE interface identifiers MAY be used in addition to interface identifiers generated according to this specification. > It shouldn't be possible. The idea is that the secret key is set to a > random number (by default). I still think you need a special value for "invalid secret key", so that any systems do not have any way to obtain random numbers can refuse to autoconfigure if the key is not set. > > 5: Duplicate address detection is not mentioned explicitly, but probably > > should be - what happens if a host does DAD and determines that its > > stable address is already in use? > > Address configuration fails. That should be in the spec. > That said, if deemed appropriate, one could include one additional byte, > "DAD" in the hash function, which is initialized to 0, and that is > incremented by 1 if the host wants to try a different address if/when > DAD fails. > > If we do that, the implementations should probably cache the resulting > address, such that it is stable. (otherwise the resulting address might > change if the same node was brought up while the node with the > conflicting address is off). This may not be possible on systems with no onboard storage, and makes things much more complicated. I suggest that if DAD fails, then autoconfiguration should just fail (at least as regards stable addresses). > Actually, this algorithm could still be used with longer prefixes (i.e., > fewer bits for the IID). So I'm not sure whether we should include this > requirement. e.g., if we were to eventually allow non-/64 autoconfigured > addresses, this algorithm could be use without any changes (while the > traditional MAC-based identifiers couldn't). I like the 64-bit limitation. Either way it should be made explicit. > > 7: Add "An implementation SHOULD provide the means for the user to > > enable and disable the use of stable addresses." > > May be s/stable addresses/this specification/? Fine. > (Note that this is a different issue from item #1 above: Item #1 above > is about what you should do if you implement this spec, while the point > that I'm making in the previous paragraph is that you SHOULD implement > this spec). I don't think a spec can mandate it's own use unless it obsoletes or updates a spec that mandates something. Your spec would have to update 4291, for example, replacing the whole modified-IEEE thing with your mechanism. That's a BIG step. > Additionally, I'd argue that in order to have such thing, then > 1) You'd need to manually configure your address each time you move from > one network to another (as with manual configuration requires you to set > the whole address, rather than just the IID bits), or, No - you could just have a flag that says "the key is the interface identifier I want to use - verbatim". Then that IID gets appended to whatever prefix happens along. Obviously this does NOT have the same anti-tracking qualities etc, but I can see it being useful. It's basically a variation on static addresses that allows portability between networks without having to reconfigure the host. Just as with other forms of static addressing, it is absolutely the administrator's problem to avoid conflicts. Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer ([email protected]) http://www.biplane.com.au/kauer GPG fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017 Old fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687
signature.asc
Description: This is a digitally signed message part
-------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
