Tim's wording is better but still uses the word "connections" which implies TCP to many readers, and hence I prefer "communication".
> -----Original Message----- > From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of > Tim Chown > Sent: Wednesday, July 29, 2009 12:24 AM > To: Thomas Narten > Cc: john.lough...@nokia.com; ipv6@ietf.org; Brian E Carpenter > Subject: Re: Node Requirements: Issue 14 - Privacy Extensions > > On Tue, Jul 28, 2009 at 02:06:45PM -0400, Thomas Narten wrote: > > > > That said, I generally like Brian's proposed text: > > I agree. > > > > 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. > > How about - to avoid the 'server' terminology turning it around to say: > > In such situations, RFC4941 SHOULD be implemented. However, if > the node is not expected to initiate connections, or the > potential > tracking or correlation over time of such connections is not a > concern, 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.) > > It's not just reverse DNS issues. For example I recall a > videoconferencing > app that used multiple connections initiated in different directions > between > two participating hosts. Between v4 hosts the code assumed a single > global > address was used between peers, and that worked, but when ported to > support > v6 it failed due to attempts to connect back to the observed privacy > address > of the remote peer failing because a firewall hole only existed to talk > to > the peer's 'static' global v6 address. I suspect similar 'referal' > issues > may happen in other cases. > > -- > Tim > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
