Hi, Karl, Please find my comments in-line....
On 04/14/2012 03:02 PM, Karl Auer wrote: > On Sat, 2012-04-14 at 14:05 +0200, Fernando Gont wrote: >> Shouldn't it be specified with RFC 2119 language? > > The first para just described intent. The others used 2119 language. The point is that without RFC2119-language, we'd not be recommending nodes whether to use draft-gont-6man-stable-privacy-addresses, and they might continue using the MAC-based addresses when they should probably be doing otherwise. >> Yep. I think it would be better to have all IIDs generated with the >> algorithm. > > It may be better, but it is a change to a massively widely-implemented > mechanism. Well, yes. But certainly implementations that predate this document would not need to comply with it (i.e., a product doesn't need to comply with *future* specifications). I personally think it would be important to move away from the MAC-based addresses, not only for their negative security implications (host-tracking and host-scanning), but also because right now we're missing the opportunity to take advantage of the IPv6 increased address space to provide improved security when compared to IPv4. > I suggest therefore > > "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 (but SHOULD > NOT) be generated using Modified-IEEE format interface identifiers. I don't think that you can have a MAY and SHOULD NOT for the same thing as noted above: they conflict with each other. Besides, I think that link-local addresses should be generated with the same algorithm, since there are ways in which they can leak out, and hence could be potentially used for host-tracking. >> Sorry, what you put in the key would be used for setting the IID?? > > Yep - if I set the flag and put "::53" in the key, then the address > generated will be prefix::53. I think this would be asking for trouble. Somebody might manually set the secret_key to a secret they use for something else, then mistakenly set the flag, and then the secret_key leaks out..... > But this is just an off-topic idea and not > essential to your draft. Agreed. 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 --------------------------------------------------------------------
