On Tuesday, June 11, 2002, at 03:29 PM, Erik Nordmark wrote:
>
> The proposed text is trying to say that temporary addresses are
> preferable
> but that there might be issues (such as applications having problems)
> which consistitute a good enough reason to not follow the default.
> Thus there is significant freedom for implementors to use their best
> judgement based on their knowledge about the applications.
>
> Do you see a problem with this approach?
> If SA is a temporary address and SB is a public address, then prefer
> SA. Similarly, if SB is a temporary address and SA is a public
> address, then prefer SB.
> An implementation MUST support a per-connection configuration
> mechanism (for example, an API extension) to reverse the sense of
> this preference and prefer public addresses over public
> addresses.
This proposed text means that all the existing clients that
talks to server that uses reverse DNS lookup will need to be
modified to use this new API extension to re-establish an
existing behavior that would otherwise be broken.
Until such an API is standardized and implemented, this seems
to me an hazardous path. Also, this is asking exiting application
who do not care about privacy to pay for the benefits of the new
ones who desire privacy. I would be convinced this is worth
doing if the number of applications that need to change is
limited, and I'm afraid it is not. Does the IESG have data about this?
And, last but not least, is having most of the traffic sent by client
using this privacy extension such a good thing? Although I understand the
desire from some applications for privacy, I'm afraid it would
create network management nightmares when doing traffic analysis.
Can you imagine a large site trying to do snoop/tcpdump
when most of the traffic is RFC3041?
- Alain.
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
