To clarify, my usage of the word "server" was meant to cover "server
only" devices, i.e., ones that don't have individual users using them
to initiate activities like web surfing.
Think rack mounted servers, storage devices, content servers,
etc. There is an entire industry surrounding those platforms, and a
key point is that many applications and protocols that apply to client
devices (e.g., laptops, cell phones, PDAs, etc.) just aren't relevant
to such servers.
I fully agree that there are general purpose operating systems that
can support both client systems or servers (e.g., linux, windows,
etc.). But there are also appliances and other devices that are not
intended for use as client devices by individual users.
Those types of devices do not need to implement Privacy Extensions.
That said, I generally like Brian's proposed text:
> That suggests a rewrite of both of the proposed
> new paragraphs:
> Privacy Extensions for Stateless Address Autoconfiguration
> [RFC4941] addresses a specific problem involving a client device
> whose user is concerned about its activity or location being
> tracked. The problem arises both for a static client and for
> one that regularly changes its point of attachment to the
> Internet. When using Stateless Address Autoconfiguration [RFC
> 4862], the Interface Identifier portion of formed addresses stays
> constant and is globally unique. Thus, although a node's global
> IPv6 address will change if it changes its point of attachment, the
> Interface Identifier portion of those addresses remain the same,
> making it possible for servers to track the location of an
> individual device as it moves around, or its pattern of activity
> if it remains in one place. This may raise privacy concerns as
> described in [RFC 4862].
> In such situations, RFC4941 SHOULD be implemented. In other cases,
> RFC4941 provides limited or no benefit.
One possible tweak on the last sentence, how about:
In such situations, RFC4941 SHOULD be implemented. In other
cases, such as with standalone servers, RFC4941 provides limited
or no benefit.
> > It is
> > noted that a number of applications do not work with addresses
> > generated with this method, while other applications work quite
> > well with them.
More to the point, there was (at the time) and (probably) still is
today some controversy as to whether the above statement is actually
correct. There have certainly been anectdotes to the effect that
privacy addresses don't work well in some cases (because they aren't
in the DNS properly), but I am also quite sure that the reverse DNS is
not well populated generally, so its unclear how real an issue that is
in practice. (For example, those of you that travel a lot will likely
find that often the "local" hotel address you are given is not in the
DNS.)
Just to give an indication of how controversial the "requirement" that
addresses be in the reverse DNS is, consider the dnsop document:
http://tools.ietf.org/html/draft-ietf-dnsop-inaddr-required-07
It is expired presumably because the WG could not really reach
agreeement on what to do with it. I recall they had many discussions
about whether the document was needed or whether it solved a non
problem...
Thomas
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
