Hi, Ray, Thanks so much for your feedback! -- Please find my comments in-line....
On 05/19/2013 03:49 PM, Ray Hunter wrote: > I think the draft is looking very good and is "ready to go." I > support it. Thanks! > I'm not 100.00000% convinced by one sentence, but I can live with > it. > > Quote: "We note that this method is incrementally deployable, since > it does not pose any interoperability implications when deployed on > networks where other nodes do not implement or employ it." > > AFAICS there's a very very unlikely race condition scenario where a > node implementing draft-ietf-6man-stable-privacy-addresses could > cause a collision of a link local address with a node implementing > existing SLAAC, because the node running > draft-ietf-6man-stable-privacy-addresses arrived on link first and > completes DAD before the SLAAC node connects to the link. > > If the SLAAC node continues to deploy 4862 literally as defined in > Section5.4.5, it will completely shut down IPv6 on the affected > interface, unless it implements the MAY clause in 5.4.5 and > continues IPv6 operation, in which case there will be a possibility > of a node that runs IPv6 on an interface and which configures IPv6 > GUA using SLAAC, but does not have a link-local address on the link. > [5.4.5 still bans assigning any address failing DAD AFAICS, even > though IPv6 operation is permitted on the interface] 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. 2) This "risk" is the price of one additional bit of entropy (another approach would have been to clear the U/L bit). 3) Since there's quite a bit of MAC address reuse out there, nodes should probably have to gracefully handle DAD failures anyway. > 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. > This is already hinted at > indraft-ietf-6man-stable-privacy-addresses-07, Quote: "Real world > data indicates that MAC address reuse is far more common than assumed > [HDMoore]. This means that even IPv6 addresses that employ > (allegedly) unique identifiers (such as IEEE identifiers) might > result in DAD failures, and hence implementations should be prepared > to gracefully handle such occurrences." Which I agree with. > > So in summary, I'd be happy if this was put on a "to consider" list > for draft-ietf-6man-ug-0 Any changes required on draft-ietf-6man-stable-privacy-addresses? > Some minor nits s/shouldproduce/should produce/ Done! -- THanks! (for some reason, I obtained a zero-length output when trying to sue the spell-checker at tools.ietf.org) > s/The prefix to be used for SLAAC, as learned from an ICMPv6/ Router > Advertisement message./The prefix to be used for SLAAC, as learned > from an ICMPv6 Router Advertisement message, or the Link-Local IPv6 > Unicast prefix./ Fixed. Thanks! > s/or when network interface happen/or when network interfaces > happen/ Fixed. > /Privacy issues still present when temporary addresses are employed/ > /employed/ is not bold after the new line (XML source or rendering > artefact?) Yep -- the txt should be fine. > B1.3 has the same /server-like functions/ with /functions/ > not in bold, so it looks like the rendering. Yep. > 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? 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 --------------------------------------------------------------------
