On 05/19/2013 06:19 PM, Ray Hunter wrote: >> >> A few comments here: >> >> 1) Windows doesn't implement the traditional "embed the MAC address in >> the IID" scheme -- so Windows nodes are not affected. > > Do you happen to know how Windows behaves in this case?
No idea. -- Although it shouldn't be hard to find out with the ra6 tool at <http://www.si6networks.com/tools/ipv6toolkit> > Are we already effectively running with this (tiny) risk in production > but (I) just didn't know it? Well, Windows node essentially select their stable addresses as a random number, so... unless I'm missing something, we are. >>> If the SLAAC node arrives on link first, >>> draft-ietf-6man-stable-privacy-addresses will back off, increment >>> (and presumably remember) the DAD counter and everything will work >>> nominally. >>> >>> To be clear, I think this is probably more of an issue with >>> draft-ietf-6man-ug-00 than >>> draft-ietf-6man-stable-privacy-addresses-07. >> >> At ome IETF meeting I argued that deprecating the u/g bit is fine, but >> one should have a scheme to deal with DAD failures. > > It's not clear to me what exactly that scheme would do. But the current > text in 4862 isn't that helpful either. We'll it's left unspecified -- my take is that there's a gap in this area. > I'd personally expect draft-ietf-6man-ug-00 to mention the issue, but > not necessarily to "solve" it. +1 > A full solution might require updating or > expanding 4862, and perhaps other standards, and I don't think it would > be desirable to deprecate the majority of existing running code just for > this issue. Well, it wouldn't be "deprecate existing running code" (i.e., we're not really against existing behaviour, but rather arguing about augmenting it with graceful handling of DAD collisions). > Rather than forcibly clearing the U/L bit in the standard, another way > out without changing any standards text might be for implementers of > draft-ietf-6man-stable-privacy-addresses to be reasonably smart when > they read the text "The resulting Interface Identifier should be > compared against the Subnet-Router Anycast [RFC4291] and the Reserved > Subnet Anycast Addresses [RFC2526], and against those Interface > Identifiers already employed in an address of the same network interface > and the same network prefix." > > So they'd basically loop whilst incrementing the DAD counter for any > Random Interface Identifier generated with u=1 if there's reason to > suspect that there were any nodes running existing SLAAC code on the > link, because the IID may well be in use, even though this particular > address hasn't explicitly failed DAD, nor has the developer been told > that generating an IID with u=1 is invalid. Could that really be reliably determined? >>> s#It is not unusual for people to assume or expect that all the >>> security/privacy implications of traditional SLAAC addresses to me >>> mitigated when "temporary addresses"#It is not unusual for people to >>> assume or expect that all security/privacy implications of >>> traditional SLAAC addresses are mitigated when "temporary >>> addresses"# >> >> "be" rather than "are", actually? > "be" sounds either imperative (e.g. "be gone!") or old style English to me. > > present tense of to be + past participle = "passive voice" OK. Applied your original suggestion. :-) Thanks so much! 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 --------------------------------------------------------------------
