On Sat, Jul 25, 2009 at 07:54:13AM +0200, [email protected] wrote: > 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.
The suggestion to use 'rolling' IP addresses for 'servers' was included in early drafts of RFC 5157, but it was removed because it was deemed out of scope at the time. The suggestion was made in the context of static systems, but the above use case seems quite valid to me. The property we've implicitly had for Privacy Addresses in general is that nodes have a static global address listed in DNS that they can be reached by, but may use Privacy Address(es) when acting as initiators/clients, and those Privacy Address(es) are not listed in the DNS. > 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. I think the notion that Privacy Extensions are only useful for mobile nodes is somewhat limiting. e.g. in RFC4864 the use of Privacy Addresses is discussed for static nodes in the context of making it harder for nodes to be profiled over time. > 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. There are certainly some application uses (we first ran into these with certain conferencing tools in 6NET) and there are also significant implications for network management (tying IPs to specific nodes over time, use of ACLs etc). However my feeling about the node requirements text is that we should be defining what priorities we put on capability, not advocating whether that capability should be used or not in certain cases. In that sense having the use of Privacy Addresses configurable on a per application basis is desirable, but to include that requirement in an Informational document when no API exists(or does it?) may be rather premature? (But something the wg should look at) Tim -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
