> Fernando Gont <mailto:fg...@si6networks.com> > 19 May 2013 22:08 > 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.
Do you happen to know how Windows behaves in this case? Are we already effectively running with this (tiny) risk in production but (I) just didn't know it? > 2) This "risk" is the price of one additional bit of entropy (another > approach would have been to clear the U/L bit). Agreed. > 3) Since there's quite a bit of MAC address reuse out there, nodes > should probably have to gracefully handle DAD failures anyway. Agreed. > > >> 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. I'd personally expect draft-ietf-6man-ug-00 to mention the issue, but not necessarily to "solve" it. 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. 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. > >> 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? No. Not from my part. > >> 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? "be" sounds either imperative (e.g. "be gone!") or old style English to me. present tense of to be + past participle = "passive voice" You could also consider: #It is not unusual for people to assume, or expect, that enabling "temporary addresses" [RFC4941] would mitigate all of the security/privacy implications of traditional SLAAC addresses.# > Thanks! > > Best regards, > Ray Hunter <mailto:v6...@globis.net> > 19 May 2013 20:49 > 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 > 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, > ------------------------------------------------------------------------ -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
