On Jun 5, 2014, at 1:10 PM, Joe Touch <to...@isi.edu> wrote: > On 6/5/2014 5:48 AM, Stephen Farrell wrote: >> I share those concerns. And adopting this without any consideration >> of BCP188 would fly in the face of a very recent, very thoroughly >> discussed, IETF consensus. > > That BCP thankfully includes zero RFC2119 language except the single word > "should" (not capitalized) in the abstract, thus every new document is > trivially compliant with its recommendations. > > (I really wish the IETF community cared as much about technical correctness > and protocol robustness as they did about issuing that IMO largely political > statement, which "flies in the face" of 40+ years of using globally-assigned, > globally-unique IP addresses as endpoint identifiers as the basis of the > Internet architecture).
Stephen, It seems NAPT has become IETF's privacy feature of 2014 because multiple users are sharing one identifier (IP address and presumably randomized ports [RFC6056], although many NAPT deployments use address ranges because of fear of compressing log files). As a former co-chair of BEHAVE it is refreshing to see the IETF embracing NAPT as a desirable feature. However, if NAPT provides privacy and NAT Reveal removes it, where does that leave a host's IPv6 source address with respect to BCP188? Afterall, an IPv6 address is quite traceable, even with IPv6 privacy addresses (especially as IPv6 privacy addresses are currently deployed which only obtain a new IPv6 privacy address every 24 hours or when attaching to a new network). If BCP188 does not prevent deployment of IPv6, I would like to understand the additional privacy leakage of IPv4+NAT+NAT_Reveal compared to the privacy leakage of IPv6+privacy_address. -d _______________________________________________ ietf-privacy mailing list ietf-privacy@ietf.org https://www.ietf.org/mailman/listinfo/ietf-privacy
