> Fernando Gont <mailto:fg...@si6networks.com> > 19 May 2013 19:33 > Folks, > > I've posted a rev of the aforementioned document, meant to address the > comments received during IETF LC. > > This rev is the result of the IETF LC discussions we had on the 6man wg > list and on the general IETF list, and of off-list discussions with a > number of folks who generously provided input, reviewed proposed > changes, etc. > > I'd expect this rev to be "ready to ship" or very close to that. But > please provide your input confirming whether you think that's the case, > or whether there are any remaining issues to be solved. > > The rev is available at: > <http://tools.ietf.org/html/draft-ietf-6man-stable-privacy-addresses-07>. > > A diff from the previous version of the I-D is available at: > <tools.ietf.org//rfcdiff?url1=http://tools.ietf.org/id/draft-ietf-6man-stable-privacy-addresses-06.txt&url2=http://tools.ietf.org/id/draft-ietf-6man-stable-privacy-addresses-07.txt>. > > Thanks so much! > > Best regards, > ------------------------------------------------------------------------ I think the draft is looking very good and is "ready to go." I support it.
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] 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. It does beg the question which node should back off in this case (if any). Probably the best course of action would be for the SLAAC node to choose a different link local address. Although this could have consequences, as e.g. static routes may point to the link local address. 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 Some minor nits s/shouldproduce/should produce/ 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./ s/or when network interface happen/or when network interfaces happen/ /Privacy issues still present when temporary addresses are employed/ /employed/ is not bold after the new line (XML source or rendering artefact?) B1.3 has the same /server-like functions/ with /functions/ not in bold, so it looks like the rendering. 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"# Thanks. regards, RayH -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
