-----Original Message-----
From: ipv6-bounces at ietf.org [mailto:ipv6-bounces at ietf.org] On
Behalf Of
Tim Chown
Sent: Wednesday, July 29, 2009 12:24 AM
To: Thomas Narten
Cc: john.loughney at nokia.com; ipv6 at 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 at ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
