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
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
