On 04/14/2012 02:36 AM, Karl Auer wrote: > 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.
Shouldn't it be specified with RFC 2119 language? > 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"] >From my pov, it means that all the algorithm is mandatory (nothing to add or take out). > 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] Yep. I think it would be better to have all IIDs generated with the algorithm. > 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. Ok, I will add this. >> 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. I'd like other to weigh in on this one. -- I don't think there's a need for a "invalid secret key". The secret key is supposed to be generated/selected at installation time. If for some reason such secret_key cannot be randomly generated, the the OS can prompt the user for one. >>> 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. As noted, IIRC this is not clearly defined for traditional SLAAC, either. So, should we be different in this respect? >> 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). This is kind of the way DAD works with traditional SLAAC. However, I'm not sure whether this is the right approach (to have address configuration fail as a result of that), or whether it would be better to have some "backup plan" (even if the address is not stored in on non-volatile storage). For instance, the IIDs that you generate with this scheme are not globally unique, and then, probabilistically speaking, there could be collisions. >> 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. Is this made explicit in any RFC for traditional SLAAC addresses? >> (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. Well, that shouldn't be a big deal, and it would be a big advance. If we were to pursue that path, it should be a "SHOULD", such that in specific scenarios or circumstances nodes can still used the MAC-based addresses. >> 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". Sorry, what you put in the key would be used for setting the IID?? > 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. What's the use case you have in mind? Thanks! Best regards, -- Fernando Gont SI6 Networks e-mail: [email protected] PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
