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. 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. -- or something like that. John -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of ext Thomas Narten Sent: Friday, July 24, 2009 10:35 AM To: [email protected] Subject: Node Requirements: Issue 14 - Privacy Extensions The document currently says: > 5.7.3. Privacy Extensions for Address Configuration in IPv6 - RFC > 4941 > > Privacy Extensions for Stateless Address Autoconfiguration [RFC4941] > SHOULD be supported. 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. IMO, additional context is needed. As 4941 itself states, RFC 4941 is only useful for mobile devices -- devices that actually move around within the network. Servers generally do not do that. Plus, servers are by definition visible (so folk can access them). Thus, in the case of servers, a blanket SHOULD is not appropriate. I'd like to propose the following replacement text: Privacy Extensions for Stateless Address Autoconfiguration [RFC4941] addresses a specific problem involving a mobile device 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 as 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. This may raise privacy concerns as described in [RFC 4862]. 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. Note also that I propose dropping: 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. The above recommendation is not in RFC 4941, and I do not believe it is appropriate for an AS to be adding a requirement that 4941 itself does not mention. Comments? Thomas -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
