I'm very happy with Thomas' tweak to my tweak to his words. Brian
On 2009-07-29 06:06, Thomas Narten wrote: > 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 --------------------------------------------------------------------
