On 2009-07-25 17:54, john.lough...@nokia.com wrote: > Thomas, > > I don't think that client / server functionality are so well defined in most > of the IPv6 RFCs, but are more of the node / router functional split. I > think giving some additional information about how a particular node is used > is good - but at the end of the day, most of the node functionality will be > delivered in terms of an OS, where the client / server functionality split is > really not important, IMO. > > Additionally, in an IPv6-world, my hope is that things will be a bit more > interesting in terms of the roles of IPv6 nodes. As you might know, we have > made a port of the Apache web server to mobile phones, and have that in trial > (using IPv4). We use DDNS to manage connectivity to the server. In an IPv6 > world, we definitely would like to use privacy extentions, as we do not > consider that the mobile web server should be accessed by everyone, but would > want to use some level of authentication for clients connecting to the > webserver. > > In summary, I am not sure if this paragraph: > > That said, the problem addressed by Privacy Extensions only happen > when a device regularly changes its point of attachment (i.e., for > mobile devices) and where the mobile device is associated with a > single (or small number) of users In such sitatuations, privacy may > be a concern and RFC4941 SHOULD be implemented. In other cases, > RFC4941 provides limited or no benefit. In particular, RFC4941 > provide little benefit to servers. > > makes sense, I would prefer dropping this paragraph.
Privacy addresses are supposed to have quite short lifetimes and to change quite often. I don't see any way that can be useful for servers, whether fixed or mobile. A server could certainly be configured with a pseudo-random IID but it needs to be a static value. A server could, I suppose, use the RFC4941 algorithm to generate an IID but then use an infinite lifetime for it. However, as far as I can see, RFC4941 only allows finite lifetimes (unless you ignore the first SHOULD in section 3.5). It seems to me that this is not an intended use of RFC4941. That's not to say it's wrong in any way, and we could make this issue go away in the present document simply by deleting the last sentence in the above quote. However, I disagree with the assertion that 4941 is only of interest for mobile devices. I think it can be equally relevant to fixed client devices, in any situation where the user may be concerned about Big Brother watching. 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. > > About this paragraph: > > It is recommended that this behavior be configurable on a > connection basis within each application when available. 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. > > I remember during discussions that some people were worried that not all > applications would work with privacy extensions. Maybe it makes sense to > remove the requirement, but adjust it so that it provides a bit more > information, something like: > > 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. One should consider how applications might use > addresses generated with this mechanism. I think that's too vague to be useful. This document is addressed to a stack implementor and the "configurable" recommendation can in theory be implemented, whereas "one should consider" can't be turned into a product requirement. I think Thomas is right to drop it until we have an actual spec of what it would mean. Brian -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
