Re: [Int-area] [ietf-privacy] NAT Reveal / Host Identifiers

[Dan Wing <[e-mail]>]

On Jun 5, 2014, at 1:10 PM, Joe Touch <[e-mail]> 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