Subject: draft-ietf-ipngwg-addrconf-privacy-00.txt

From: Thomas Narten <[email-masked]>
Date: Thu, 14 Oct 1999 15:07:20 -0400

Folks,

One thing that would be helpful in this moment of hightened interest
is to take a look at this document and provide specific comments on
it, especially with respect to the Section 2, "Background". The intent
of that section is to provide some overall perspective on the
issue. Some of the comments that have been made recently on this list
should probably be put into this section. 

Regarding the protocol description, per comments and the discussion in
Oslo, the mechanism itself will likely be moved to an appendix or
simply be thrown out. It's too simplistic to be useful in the cases of
real interest. The next version of the document will define a
mechanism that keeps the EUI-64-derived interface ID for link-local
and site-local addresses, but allows the global scope addresses to
have random interface IDs. In addition, nodes need to have both a
"permanent" address (i.e., one with the EUI-64-derived address) that
is "public" so that the node can act as a server and accept incoming
connections. Simultaneously, nodes will want to act as clients,
initiating connections from addresses with the random interface ID
component. Both addresses will be in effect simultaneously.

The interested reader may wish to think about how this might impact
source address selection algorithms that are invoked when initiating
connections.

Thomas
--------------------------------------------------------------------
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-masked]
--------------------------------------------------------------------

---

From: "Richard M. Smith" <[email-masked]>
Date: Thu, 14 Oct 1999 15:56:36 -0400

Hi Thomas,

> The next version of the document will define a
> have random interface IDs. 

One needs to be a bit careful here with the idea
of local vs global addresses.  It's very easy for
programmers to get mixed up and use the wrong one.
The result is that an application software package can 
inadvertently send out a local or site
IPv6 address to a remote server.

I just found an example of this sort of bug
today in IPv4.  I run a NAT box at home (a Web Ramp Internet
sharing box), so I have a "private" IP address
for my computer and a "public" IP address
that the world sees.  I was running a packet
sniffer on the Windows Media Player and discovered
that it includes my private IP address in a Unicode 
string in an MMS packet.  This packet appears to be
sent to a Web server anytime an audio or video clip 
is played.  For what reason this is being done,
I can't say.  This address is meaningless
to the server.  

This bug doesn't matter to me.  However folks who
are using some sort of proxy server to provide
anonymity while watching a video clip are going
to be in for a bit of a surprise.  It's likely
that Web servers have their real IP address anyway.

Richard

---

From: Francis Dupont <[email-masked]>
Date: Fri, 15 Oct 1999 10:04:35 +0200

In your previous mail you wrote:

   real interest.

=> please KISS.

=> this seems for me rather complex... A stupid random and dynamic
interface ID should be enough for untracebility and not worse than
current dynamic IPv4 addresses. If I'd like to have both a server
at a well known address and a personal box for XXX web browsing
(in order to get a nice picture for my screen background :-) then
I should use a second box...

=> argh!

[email-masked]

---

From: Steve Deering <[email-masked]>
Date: Fri, 15 Oct 1999 07:40:42 -0700

>I should use a second box...

One IPv6 phone to place calls and one to receive calls?

Steve