> The problem is that the usage of the word "server" is not defined in the > document. I'd prefer to not use the word "server" at all, but instead > say what you mean... "devices that never initiate communication". > "server" means other things to other people and we don't want to > confuse people.
Agreed that server is not well defined... But, all devices initiate communication, even servers. I.e., the web server may well initiate lots of connections with other entities in a data center (e.g., file server), or even to external sites as part of fulfilling a request. So just saying "initiating communication" isn't enough either. The key aspect for where Privacy Extensions provide value is where 1) the device initiates connections, and 2) servers that are the targets of those connections (or other monitoring devices that see the connections) use them to correlate activity associated with that connection with previous activities from previous connections from the same device (usually, hours, days or weeks earlier), and 3) those activities can also be traced back to a single (or very small group of) end users. (i.e, typically if the device has only a single user). Hence, for "clients" (i.e., single-user systems, or any system where the user's keyboard connects), Privacy Extensions have value. But for what I normally think of a stand-aline server (not a client device), there is very limited, if any benefit. Also, for static clients (those that don't move), the benefits of Privacy Extensions are open to debate. For a home DSL (or cable) user, the /64 they have remains constant. So you can correlate activity just via the /64 and get a pretty good approximation. Privacy Extensions have some benefit here, but just how much is up for debate. That said, I'm not sure right off how to capture all the above without making the reader's eyes glaze over. I was trying to use "standalone server" to describe a device that is exclusively a server, and not a client device that (possibly) serves in a dual role of having providing both server and client servics. Thomas -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
