Subject: Re: My InternetWeek op-ed column on IPv6 privacy issues

From: Bill Frezza <[email-masked]>
Date: Sun, 10 Oct 1999 18:10:31 -0400

Gentle readers,

Thank you for your feedback on my recent column "Where's All The Outrage
About The IPv6 Privacy Threat" 

http://www.internetwk.com/columns/frezz100499.htm

Normally I respond to every letter I receive, but the volume of mail on
this one broke all records so I'm afraid I have to send out a group note.
(It seems that peeved IETF geeks are even more vociferous than peeved
Mac-heads. :)

Let me, in particular, address some of the comments from the folks who
insist that there is no privacy problem with IPv6 or that the problem is
identical with IPv4 or that the problem has already been solved by the IETF
or that the use of EUI-64 addressing is optional and not mandatory,
therefore there's no problem. (I do not intend to reply to the folks who
just plain don't care about privacy as this is a philosophical issue beyond
the scope of this note. As for readers who don't like my inflammatory
writing style, feel free not to read my column. I write op-eds, not news
articles.)

1) Yes, IPv4 has its own privacy problems. In fact, any time one uses a
static or long-lived IP address, the possibility exists for abusive
systematic surveillance. The fact that a central registry of addresses does
or does not exist has no bearing on the potential threat as such a data
base can be built over time, particularly for individuals or groups that
have been specifically targeted. In addition, countries like China or
Singapore could easily require registration. Why give them the tools in the
first place?

2) Yes, dynamic assignment of IP addresses for dial-up users as well as
Network Address Translation (NAT) helps mitigate (though does not
eliminate) the privacy problem. As we move towards an "always connected"
Internet, with more and more users communicating via Cable Modems or DSL,
more IP addresses will become long lived, hence the problem will get worse.

3) It's too late to change IPv4 while it is not too late to change IPv6. My
column was intended as a call to action to get the IETF off it's duff. A
fault in my column is that I did not specifically describe proposals being
circulated to address the issue, one of which is attached below. Mea culpa,
and my apologies to the good guys for ignoring their efforts. May the force
be with you.

4) Be that as it may, draft-ietf-ipngwg-addrconf-privacy-00.txt is just a
proposal. It has not been and may not be adopted. Absent further action, it
will go away. If it is adopted, it may or may not be implemented by major
vendors, especially if the final standard offers a Chinese menu of choices.

5) Note that the proposal ACKNOWLEDGES THE PROBLEM. In addition it points
out that

> The desires of protecting individual privacy vs. the desire to 
> effectively maintain and debug a network can conflict with each 
> other. 

The same can be said across the board for many aspects of law enforcement
in a society that values liberty. Just think how much safer the streets
would be if we all walked around with electronic radio ID collars
registering our movements. Fortunately, we have chosen not to construct
such a society (although if you follow the development of the CALEA laws,
this is not for want of the FBI trying).

6) The solutions proposed in draft-ietf-ipngwg-addrconf-privacy-00.txt
cause a a major problem with one of the other goals of IPv6

>   The IPv6 addressing architecture goes to great lengths to ensure that
>   interface identifiers are globally unique. During the IPng
>   discussions of the GSE proposal [GSE], it was felt that keeping
>   interface identifiers globally unique in practice might prove useful
>   to future transport protocols. Usage of the algorithms in this
>   document would eliminate that future flexibility.

The random assignment algorithms look very promising. I hope they are
adopted, but no one knows yet how this conflict is going to be resolved.

7) At the end of the day, what matters to the average netizen is not the
menu of possible alternatives described in IETF standards, but the actual
default implementation in popular products, e.g. Windows. Just because an
educated and motivated geek can get into the plumbing of his machine and
find a way to solve his own privacy problem doesn't mean the problem has
been solved for the bulk of average users. If the folks at Microsoft don't
properly address this in their future products, I can positively,
absolutely guarantee that it will blow up in their face.

8) Readers who are interested in registering their concerns should contact
the CDT at www.CDT.org. I got a very nice note from them indicating that
they are now wading into the issue. One hopes that EPIC and the EFF will
follow suit.

Cheers,

Bill Frezza
InternetWeek
[email-masked]

PS Special thanks to Scott Bradner and Mike O'Dell for helping me
understand some of the technical nuances of this issue that I had
previously misunderstood. Notwithstanding, I stand by my column and hope
all you geeks do something about it. The opinions above are my own.

------------

INTERNET-DRAFT                                             Thomas Narten
                                                                     IBM
<draft-ietf-ipngwg-addrconf-privacy-00.txt>                    June 1999

    Privacy Extensions for Stateless Address Autoconfiguration in IPv6

                <draft-ietf-ipngwg-addrconf-privacy-00.txt>

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet- Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

Abstract

   Nodes use IPv6 stateless address autoconfiguration to generate
   addresses without the necessity of a DHCP server. Addresses are
   formed by combining network prefixes with a constant interface
   identifier derived from the interface's IEEE Indentifier.  This
   document describes an optional extension to IPv6 stateless address
   autoconfiguration that results in a node generating addresses from an
   interface identifier that changes over time. Changing the interface
   identifier over time makes it more difficult for eavesdroppers and
   other information collectors to identify when different addresses
   used in different transactions actually correspond to the same node.

draft-ietf-ipngwg-addrconf-privacy-00.txt                       [Page 1]

INTERNET-DRAFT                                             June 24, 1999

   Contents

   Status of this Memo..........................................    1

   1.  Introduction.............................................    2

   2.  Background...............................................    3

   3.  Protocol Description.....................................    5

   4.  Implications of Changing Interface Identifiers...........    7

   5.  Open Issues and Future Work..............................    7

   6.  Security Considerations..................................    8

   7.  References...............................................    8

   8.  Authors' Addresses.......................................    9

1.  Introduction

   Stateless address autoconfiguration [ADDRCONF] defines how an IPv6
   node generates addresses without the need for a DHCP server. Network
   interfaces typically come with an embedded IEEE Identifier (i.e., a
   link-layer MAC address), and stateless address autoconfiguration uses
   the IEEE identifier to generate a 64-bit interface identifier
   [ADDRARCH]. By design, the interface identifier will typically be
   globally unique. The interface identifier is in turn appended to a
   prefix to form a 128-bit IPv6 address. All nodes use this technique
   to generate link-local addresses for their attached interfaces.
   Additional addresses, including site-local and global-scope
   addresses, are then created by combining prefixes advertised in
   Router Advertisements via Neighbor Discovery [DISCOVERY] with the
   interface identifier.

   As mobile devices (e.g., laptops, PDAs, etc.) move topologically,
   they form new addresses for their current topological point of
   attachment. While the node's address changes as it moves, however,
   the interface identifier contained within the address remains the
   same.  Because the interface identifier associated with a node can
   potentially remain fixed for a long period of time (e.g., months or
   years) concern has been voiced that the interface identifier could in
   some cases be used to track the movement and usage of a particular
   machine. For example, a server that logs the source addresses of
   incoming connections would simultaneously collect identical
   information keyed on the interface id, allowing one to correlate

draft-ietf-ipngwg-addrconf-privacy-00.txt                       [Page 2]

INTERNET-DRAFT                                             June 24, 1999

   activities based on interface identifiers in addition to addresses.
   This is of particular concern with the expected proliferation of
   next-generation network-connected devices (e.g, PDAs, cell phones,
   etc.) in which large numbers of devices are in practice associated
   with a single user. Thus, the interface identifier embedded within an
   address could be used to track activities of an individual.

   This document discusses concerns associated with the embedding of
   interface identifiers within IPv6 addresses and describes optional
   extensions to stateless address autoconfiguration that can help
   mitigate those concerns in environments where such concerns are
   significant.

2.  Background

   This section discusses the problem in more detail and provides
   context for evaluating the significance of the concerns in specific
   environments and makes comparisons with existing practices.

2.1.  Extended Use of the Same Identifier

   The use of a non-changing interface identifier to form addresses is a
   specific instance of the more general case where a constant
   identifier is reused over an extended period of time and in multiple
   independent activities. Anytime the same identifier is used in
   multiple contexts, it becomes possible for that identifier to be used
   to correlate seemingly unrelated activity. For example, a network
   sniffer placed strategically on a link across which all traffic
   to/from a particular host crosses could keep track of which
   destinations a node communicated with and at what times. Such
   information can in some cases be used to infer things, such as what
   hours an employee was active, when someone is at home, etc.

   One of the requirements for correlating seemingly unrelated
   activities is the use (and reuse) of an identifier that is
   recognizable over time within different contexts. IP addresses
   provide one obvious example, but there are more. Many nodes also have
   DNS names associated with their addresses, in which case the DNS name
   serves as a similar identifier. Although the DNS name associated with
   an address is more work to obtain (it may require a DNS query) the
   information is often readily available. In such cases, changing the
   address on a machine over time would do little to address the concern
   raised in this document, as the DNS name would become the correlating
   identifier.

   The use of a constant identifier within an address is of special

draft-ietf-ipngwg-addrconf-privacy-00.txt                       [Page 3]

INTERNET-DRAFT                                             June 24, 1999

   concern because addresses are a fundamental requirement of
   communication and cannot easily be hidden from eavesdroppers and
   other parties. Even when higher layers encrypt their payloads,
   addresses in packet headers appear in the clear.  Consequently, if a
   mobile host (e.g., laptop) accessed the network from several
   different locations, an eavesdropper might be able to track the
   movement of that mobile host from place to place, even if the upper
   layer payloads were encrypted [SERIALNUM].

2.2.  Not a New Issue

   Although the topic of this document may at first appear to be an
   issue new to IPv6, similar issues already exist in today's Internet
   already. That is, addresses used in today's Internet are often
   constant in practice for extended periods of time. In many sites,
   addresses are assigned statically; such addresses typically change
   infrequently. However, many sites are moving away from static
   allocation to dynamic allocation via DHCP. In theory, the address a
   client gets via DHCP can change over time, but in practice servers
   return the same address to the same client (unless addresses are in
   such short supply that they are reused immediately by a different
   node when they become free). Thus, although many sites use DHCP,
   clients end up using the same address for months at a time.

   Nodes that need a (non-changing) DNS name generally have static
   addresses assigned to them to simplify the configuration of DNS
   servers. Although Dynamic DNS [DDNS] can be used to update the DNS
   dynamically, it is not widely deployed today. In addition, changing
   an address but keeping the same DNS name does not really address the
   underlying concern, since the DNS name becomes a non-changing
   identifier. Servers generally require a DNS name (so clients can
   connect to them), and clients often do as well (e.g., some servers
   refuse to speak to a client whose address cannot be mapped into a DNS
   name that also maps back into the same address).

   Many network services require that the client authenticate itself to
   the server before gaining access to a resource. The authentication
   step binds the activity (e.g., TCP connection) to a specific entity
   (e.g., an end user). In such cases, a server already has the ability
   to track usage by an individual, independent of the address they
   happen to use. Indeed, such tracking is an important part of
   accounting.

   Web browsers and servers typically exchange "cookies" with each
   other. Such cookies allow web servers to correlate a current activity
   with a previous activity. One common usage is to send back targeted
   advertising to a browser by noting that a transaction that it is

draft-ietf-ipngwg-addrconf-privacy-00.txt                       [Page 4]

INTERNET-DRAFT                                             June 24, 1999

   performing was started by an entity that previously requested
   information that had the side-effect of indicating the interest of
   the querier.

2.3.  Possible Approaches

   One way to avoid some of the problems discussed above would be to use
   DHCP for obtaining addresses. With DHCP, the DHCP server could
   arrange to hand out addresses that change over time.

   Another approach, one compatible with the stateless address
   autoconfiguration architecture would be to change the interface id
   portion of an address over time. For example, upon each system
   restart, select a new interface identifier different from the ones
   used previously. Changing the interface identifier makes it more
   difficult to look at the IP addresses in independent transactions and
   identify which ones actually correspond to the same node.

   In order to make it difficult to make educated guesses as to whether
   two different interface identifiers belong to the same node, the
   algorithm for generating alternate identifiers must include input
   that has an unpredictable component from the perspective of the
   outside entity's collecting information. Picking identifiers from a
   pseudorandom sequence suffices, so long as the specific sequence
   cannot be determined by an outsider examining just the identifiers
   that appear in addresses. This document proposes the use of an MD5
   hash, using a per-interface "key" that varies from one interface to
   another. Specifically, we use the interface identifier generated
   using the normal procedure [ADDRARCH] as the key.

3.  Protocol Description

   The goal of this section is to define procedures that:

   1) Result in a different interface identifier being generated at each
      system restart or attachment to a network.

   2) Produce a sequence of interface identifiers that appear to be
      random in the sense that it is difficult for an outside observer
      to predict a future identifier based on a current one and it is
      difficult to determine previous identifiers knowing only the
      present one.

   We describe two approaches. The first assumes the presence of stable
   storage that can be used to record state history for use as input
   into the next iteration of the algorithm, i.e., after a system

draft-ietf-ipngwg-addrconf-privacy-00.txt                       [Page 5]

INTERNET-DRAFT                                             June 24, 1999

   restart. A second approach addresses the case where stable storage is
   unavailable and the interface identifier must be generated at random.

3.1.  When Stable Storage is Present

   The following algorithm assumes the presence of a 64-bit "history
   value" that is used as input in generating an interface identifier.
   The very first time the system boots (i.e., out-of-the-box), any
   value can be used including all zeros. Whenever a new interface
   identifier is generated, its value is saved in the seed for the next
   iteration of the process.

   Section 5.3 of [ADDRCONF] describes the steps for generating a link-
   local address when an interface becomes enabled. This document
   modifies that step in the following way. Rather than use interface
   identifiers generated as described in [ADDRARCH], the identifier is
   generated as follows:

   1) Take the history value from the previous iteration (or 0 if there
      is no previous value) and append to it the interface identifier
      generated as described in [ADDRARCH].
   2) Compute the MD5 message digest [MD5] over the quantity created in
      step 1).
   3) Take the left-most 64-bits of the MD5 digest and set bit 6 (the
      left-most bit is numbered 0) to zero. This creates an interface
      identifier with the universal/local bit indicating local
      significance only. Use the resultant identifier for generating
      addresses as outlined in [ADDRCONF]. That is, use the interface
      identifier to generate a link-local and other appropriate
      addresses.
   4) Save the interface identifier created in step 3) in stable storage
      as the history value to be used in the next iteration of the
      algorithm.

   MD5 was chosen for convenience, not because of strict requirements.
   IPv6 nodes are already required to implement MD5 as part of IPsec
   [IPSEC], thus the code will already be present on IPv6 machines.

3.2.  In The Absence of Stable Storage

   In the absence of stable storage, no history information will be
   available to generate a pseudo-random sequence of interface
   identifiers. Consequently, identifiers will need to be generated at
   random. A number of techniques might be appropriate. Consult [RANDOM]
   for suggestions on good sources for obtaining random numbers. Note
   that even though a machine may not have stable storage for storing

draft-ietf-ipngwg-addrconf-privacy-00.txt                       [Page 6]

INTERNET-DRAFT                                             June 24, 1999

   the previously using interface identifier, they will in many cases
   have configuration information that differs from one machine to
   another (e.g., user identity, security keys, etc.). One approach to
   generating random interface identifiers in such cases is to use the
   configuration information to generate some data bits (which may be
   remain constant for the life of the machine, but will vary from one
   machine to another), append some random data and compute the MD5
   digest as before. The remaining details for generating addresses
   would be analogous to those of the previous section.

4.  Implications of Changing Interface Identifiers

   The IPv6 addressing architecture goes to great lengths to ensure that
   interface identifiers are globally unique. During the IPng
   discussions of the GSE proposal [GSE], it was felt that keeping
   interface identifiers globally unique in practice might prove useful
   to future transport protocols. Usage of the algorithms in this
   document would eliminate that future flexibility.

   The desires of protecting individual privacy vs. the desire to
   effectively maintain and debug a network can conflict with each
   other. Having clients use addresses that change over time will make
   it more difficult to track down and isolate operational problems. For
   example, when looking at packet traces, it could become more
   difficult to determine whether one is seeing behavior caused by a
   single errant machine, or by a number of them.

5.  Open Issues and Future Work

   This document specifies that a node generate a new interface
   identifier each time it autoconfigures an interface. The same
   identifier is used to generate all addresses, including link-local,
   site-local and global. However, the concerns this document addresses
   are most likely relevant only to global-scope addresses. Thus, it may
   make sense for a node to have two interface identifiers, the standard
   one [ADDRCONF] used for link-local and site-local addresses, with a
   changing one used only for global-scope addresses. This would appear
   to require only small changes from the current specification.

   In some cases, one could imagine the need to change an address more
   frequently than upon reboot or movement to a new location. For
   example, for machines that do not restart for months at time, one
   might change addresses every few days or weeks. In extreme cases, one
   might even want to change addresses upon the initiation of each new
   TCP connection. Doing frequent changes would appear to add
   significant issues and possible implementation complications. For

draft-ietf-ipngwg-addrconf-privacy-00.txt                       [Page 7]

INTERNET-DRAFT                                             June 24, 1999

   example, an implementation might need to support a significant number
   of address on an interface simultaneously. An implementation would
   also need to keep track of which addresses were being used so as to
   be able to stop using an address once no upper layer protocols are
   using it (but not before). This is in contrast to current approaches
   where addresses are removed from an interface when they become
   invalid [ADDRCONF], independent of whether or not upper layer
   protocols are still using them.

   Some machines server as both clients and servers. In such cases, the
   server would need a DNS name. Whether the address stays fixed or
   changes doesn't matter since the DNS name remains constant.
   Simultaneously, when acting as a client (e.g., initiating
   communication) it may want to vary the address it uses. In such
   environments, one might need multiple addresses. Source address
   selection rules would need to take into account the policy aspects of
   which addresses would be acceptable for use when initiating
   communication.

6.  Security Considerations

   The motivation for this document stems from privacy concerns for
   individuals. This document does not appear to add any security issues
   beyond those already associated with stateless address
   autoconfiguration [ADDRCONF].

7.  References

   [ADDRARCH] Hinden, R. and S. Deering, "IP Version 6 Addressing
           Architecture", RFC 2373, July 1998.

   [ADDRCONF] Thomson, S. and T. Narten, "IPv6 Address
           Autoconfiguration", RFC 2462, December 1998.

   [DHCP] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
           March 1997.

   [DDNS] Vixie et. al., "Dynamic Updates in the Domain Name System (DNS
           UPDATE)", RFC 2136, April 1997.

   [DISCOVERY] Narten, T., Nordmark, E. and W. Simpson, "Neighbor
           Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.

   [GSE-ANALYSIS] Crawford et. al., "Separating Identifiers and Locators
           in Addresses: An Analysis of the GSE Proposal for IPv6 ",
           draft-ietf-ipngwg-esd-analysis-04.txt.

draft-ietf-ipngwg-addrconf-privacy-00.txt                       [Page 8]

INTERNET-DRAFT                                             June 24, 1999

   [IPSEC] Kent, S., Atkinson, R., "Security Architecture for the
           Internet Protocol", RFC 2401, November 1998.

   [MD5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April
           1992.

   [SERIALNUM] Moore, K., "Privacy Considerations for the Use of
           Hardware Serial Numbers in End-to-End Network Protocols",
           draft-iesg-serno-privacy-00.txt.

8.  Authors' Addresses

   Thomas Narten
   IBM Corporation
   P.O. Box 12195
   Research Triangle Park, NC 27709-2195
   USA

   Phone: +1 919 254 7798
   EMail: [email-masked]

draft-ietf-ipngwg-addrconf-privacy-00.txt                       [Page 9] 

--------------------------------------------------------------------
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: Jeff Williams <[email-masked]>
Date: Wed, 13 Oct 1999 16:23:43 +0100

Bill and all,

  Thank you for forwarding this.  It helps to underscore the problems
that will eventually become significant with respect to Privacy problems
with IPv6.  We [INEG Inc.] have been concerned with this problem
with IPv6 for some time and have passed this concern on to the IETF
as well as ICANN as ICANN seems to have a strong belief that
IPv6 is the future.  We respectfully are not in complete agreement
for the privacy concerns amongst others associated with
IPv6 and have decidedly moved towards a private effort towards
IPv8 as a result.  That effort in in deployment as I type this response.

> all you geeks do something about it. The opinions above are my own.

Regards,

--
Jeffrey A. Williams
Spokesman INEGroup (Over 95k members strong!)
CEO/DIR. Internet Network Eng/SR. Java/CORBA Development Eng.
Information Network Eng. Group. INEG. INC.
E-Mail [email-masked]
Contact Number:  972-447-1894
Address: 5 East Kirkwood Blvd. Grapevine Texas 75208

---

From: Jim Bound <[email-masked]>
Date: Thu, 14 Oct 1999 12:45:54 -0400

Give me a break IPv8 is a disgruntled joke.  If you want to discuss IPv8
go create your own list.  This is an IPv6 list and our charter.  IPv8 is
not part of the charter of this working group.  Please take it elswwhere
we have work to do on IPv6 here.

Bill Frezza and others have raised an issue.  It is being addressed in
the IETF.  As one of the key implementors of IPv6 I will tell all this
is on the engineering table now for Ipv6 implementation.  I will also
tell you either fix proposed at this time is not a big deal to the code
base or to get done in products even if they have shipped.  But, what is
important is that the IETF spend the time to get this right quickly and
efficiently and not keep changing the fixes.

But what is not good is to raise false alarms before they are a problem.

/jim

---

From: Jeff Williams <[email-masked]>
Date: Thu, 14 Oct 1999 10:17:24 +0100

Jim and all,

  No, you give everyone else a break.  And while you are at it,
get a grip on that attitude you seem to be displaying here.

  Yes I know very well that IPv8 is not part of the ipng list
forum, and I only mentioned it in passing as in comparison
nothing more, so cool you jets fella!

  The alarm was not raised originally by me as to the privacy
concerns with IPv6, they were raised by others on the IPv6
working group originally in several IETF drafts by others that
are authors of those very drafts as far back as 1997.  So this is
nothing really all that new.  What is new though is the lack of
addressing those privacy concerns to date despite them being known
for some time.

Regards,

---

From: Jim Bound <[email-masked]>
Date: Thu, 14 Oct 1999 13:52:56 -0400

>addressing those privacy concerns to date despite them being known

There is a draft to fix it.  

IPv6 has not been widely deployed.

The vendors will fix it when the draft is worked.

The press is being typical for the 90's.

Most of this mail has been a waste of our time as a working group IMO.
Which I will state any time I feel like it.  So you cool your jets.

/jim

---

From: Jeff Williams <[email-masked]>
Date: Thu, 14 Oct 1999 11:04:22 +0100

Jim and all,

> There is a draft to fix it.

  Yes?  Which one is that?  the latest draft also recognizes the
privacy problem as well.

> IPv6 has not been widely deployed.

  Not likely to be either unless or until these problems in the
spec are corrected.

> The vendors will fix it when the draft is worked.

  That may be, let's hope so.  But there seems to be some
resistance to doing that presently.  Hence public exposure is
necessary in order for the proper pressure to be brought to
bear in order to underscore that this problem MUST be fixed.

> The press is being typical for the 90's.

  The press is always typical, regardless of the decade.

> Which I will state any time I feel like it.  So you cool your jets.

  Oh, feel free, please!  >;)  As will I if I feel that it is relevant and

necessary.  >;)  But I agree, that most of the denial that there is
a serious privacy concern with IPv6 is a waste of time.

Regards,

---

From: Jim Bound <[email-masked]>
Date: Thu, 14 Oct 1999 16:01:34 -0400

>  Yes?  Which one is that?  the latest draft also recognizes the

THe draft Bill provided in his mail to this forum.  I have read Thomas's
draft and it will work, he provides two solutions.  I would also like to
see a solution where the node administrator can provide a seed for the
EUI token too.

>  Not likely to be either unless or until these problems in the

On the contrary.  I believe IPv6 will be deployed on Intranet's first
and the deployment will happen from within to without and ISPs and
routers will be last to deploy IPv6, which is why we need transition
mechanisms like 6to4.

>.
>.  That may be, let's hope so.  But there seems to be some
>.resistance to doing that presently.  Hence public exposure is

As a note.  Thomas Narten made us aware of this long ago before the
draft came out. Its been on the implementation issue agenda for a long
time.  If anything was late it was a spec.  Not the vendors.  I know of
no vendor or implementor that has stated they would not fix this issue.

>  The press is always typical, regardless of the decade.

At least in the U.S. it is far worse than it has ever been before I can
recall or from the history lessons I have absorbed.  What has happened
here is a complete abuse of the U.S. 1st ammendment which is the right
to free speech.  The articles accusing the IETF and IPv6 of being flawed
and sitting on their backside, were like yelling Fire in a crowded
theatre.

  1.  The IETF is not lax here at all.  The problem is well understood and 
      under control.  Folks can look at Thomas's spec and make comments
      or shoot holes in it.  I think its fine as a note, but would 
      like to see some manual options by node admins.

  2.  IPv6 is not flawed.  If anything IPv6 is more equipped to deal
      with this problem than IPv4 simply cause we have more bits to
      randomize as one solution.  IPv4 does not have that luxury.
      This is an IPv4 problem too.  I could use the "sophist" argument
      that this uproar is even more reason to move to IPv6 quickly cause
      we can fix it and IPv4 cannot.  But that would be dishonorable
      and unethical on my part and also yelling fire in the theatre.

  3.  No Ipv6 implementors have stated they would not make the code
      changes to support this in the Addr Conf spec.  So saying 
      implementors may not fix it was a complete fabrication by
      that assumption, or that we would ship products for IPv6 
      forever with this issue.

This could have affected IPv6 deployment, but it won't cause its not a
real problem, cause it will get fixed, cause it is not and never was a
basic flaw in the pristine and elegant design and architecture of the
Next Internet Generation Protocol, which we call IPv6.

But more to the philosophical point which I find great irony with is the
entire notion of privacy.  The best privacy is to live in the mountains
of some place in a cabin and not participate in the world, if one has
the ability to do so.  But at the other extreme when you participate on
the Internet or as one of my colleagues put it elsewhere when you make a
phone call and give out your unlisted number your privacy is reduced.

/jim

---

From: Jeff Williams <[email-masked]>
Date: Thu, 14 Oct 1999 13:18:54 +0100

Jim and all,

> see a solution where the node administrator can provide a seed for the

  Agreed there are two potential solutions on the table presently.  But
neither of them apply to autoimplimnentation do they?  No, they don't,
and hence the concern still remains for obvious reasons.  I don't
think I need to outline those reasons in detail as they have already been
stated very eloquently by others quite nicely.

> routers will be last to deploy IPv6, which is why we need transition

  On IntrAnets, maybe.  But on a broad scale on the Internet, I have
my doubts for several other reasons other than just privacy, 6to4
not withstanding.

> no vendor or implementor that has stated they would not fix this issue.

  Yes, possibly your conclusion here is correct, but the vendors should not
be in a position to have to fix this problem.  It should be part of the spec
to begin with, which is the crux of my argument.

> recall or from the history lessons I have absorbed.

  Well you may be correct here.  But I doubt it really, as this has been
a complaint for as long I I can remember and even before.  SO the
perception is a matter of conjecture.

> What has happened

  SOme do, and some postulate or oversee what need to be done.
This is a fundamental truth in any society.

  As to the "Yelling of fire in a crowded theater" as it may relate
to 1st amendment, I find this is always the charge that those that
have been caught when they are guilty.  Hardly a realistic defense
in this instance.

>       like to see some manual options by node admins.

  Agreed.  It needs also some reversal in the autoimplimentation as well.

>       and unethical on my part and also yelling fire in the theatre.

  Yes to a point I would tend to agree.  BUt we have more experience
with IPv4, and hence have learned to deal with this problem.

Regards,

---

From: Dave Marquardt <[email-masked]>
Date: 14 Oct 1999 15:51:32 -0500

> stated very eloquently by others quite nicely.

What do you mean by "autoimplimnentation"?  Do you mean
autoconfiguration?  As I read Thomas' draft, it certainly does apply
to autoconfiguration.

-Dave

---

From: Jeff Williams <[email-masked]>
Date: Thu, 14 Oct 1999 14:17:57 +0100

Dave and all,

  Yes excuse me, I did mean autoconfiguration.  As I read
Thomas' draft the fix for the MAC privacy problem is not
addressed as a function of autoconfiguration.  What part
did you see that does?

Regards,

---

From: Jim Bound <[email-masked]>
Date: Thu, 14 Oct 1999 21:15:39 -0400

This is a good technical question.

>addressed as a function of autoconfiguration.  What part

From: draft-ietf-ipngwg-addrconf-privacy-00.txt
The following text defines the adjuncts to stateless addrconf RFC 2462
what would need to be done, and the modifications to RFC 2462 to resolve
the issue at hand.  On this list today and yesterday I was also hearing
folks would want manual configuration too.  Me too.  As a third option.
Having implemented addr conf I will say this is very doable and its a
matter of the IETF working on the spec (which is in process) and
wrapping this up.

So as I read the attached below the issue is addressed for address
autoconfiguration.

I would suggest we just move on to the technical work at hand and work
this spec out in the working group.

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
3.  Protocol Description

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

/jim

---

From: Jeff Williams <[email-masked]>
Date: Thu, 14 Oct 1999 20:08:39 +0100

Jim and all,

> matter of the IETF working on the spec (which is in process) and

  I agree here and this is in part one method of addressing the
the privacy concerns.  But I would strongly suggest for reasons
that I have already stated the the autoconfiguration include that the
privacy concerns be addressed as a default of the spec.  If this
is done much of the problem with IPv6 in this area would be
adequately addressed.  I also agree that a manual configuration too
be included as has been suggested by others, but be a second
priority to the autoconfiguration fix.

Regards,

---

From: Markku Savela <[email-masked]>
Date: Fri, 15 Oct 1999 10:03:08 +0300 (EET DST)

[I removed the long CC list]

This discussion seems to lead to a situation where IP-addresses are
never "permanent", just when I was hoping that IPv6 would bring enough
addresses to use, so that I could have permanent addresses for myself...

This is a dilemma... 

 - for some things I would like to use random (src) address

 - but, I still would like to have permantent address so that my SMTP
   daemon on mobile phone [:-)] can be contacted (or that it can
   receive voice over IP calls). Or just that I can run WEB server on
   my home machine, to be more realistic.

Is this another dimension to the source address selection discussion?

-- 
Markku Savela ([email-masked]), Technical Research Centre of Finland
Multimedia Systems, P.O.Box 1203,FIN-02044 VTT,http://www.vtt.fi/tte/staff/msa/
--------------------------------------------------------------------
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: Peter Tattam <[email-masked]>
Date: Fri, 15 Oct 1999 18:18:49 +1100 (EST)

> Is this another dimension to the source address selection discussion?

Technically it is plausible to have a mix of both types of addresses.  You
could use set of addresses for making connects, while your permanent addresses
could be used only for receiving connections.   Now that is an interesting
aspect of Ipv6 that could be a good selling point.

Peter

--
Peter R. Tattam                            [email-masked]
Managing Director,    Trumpet Software International Pty Ltd
Hobart, Australia,  Ph. +61-3-6245-0220,  Fax +61-3-62450210

---

From: Jeff Williams <[email-masked]>
Date: Fri, 15 Oct 1999 01:00:51 +0100

Peter and all,

> aspect of Ipv6 that could be a good selling point.

  Yep, you sure could do as you suggest here.  I might be a good
point to make for "Best Practice"??  At least an "Preferred option"??

Regards,

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 15 Oct 1999 10:06:40 -0500

Markku is on a good point. For the billion or so always-on wireless
devices we will have on the net in a few years, permanent addresses
are a must. 

  Brian

---

From: Jeff Williams <[email-masked]>
Date: Mon, 18 Oct 1999 06:54:30 +0100

Brian and all,

  Excuse me Brian, but why must those devices have permanent
IP addresses?  As you know to do so creates a privacy problem
that is also as you know, addressable, pardon the pun.  >;)

Regards,

---

From: Bill Manning <[email-masked]>
Date: Mon, 18 Oct 1999 07:15:41 -0700 (PDT)

Brian,
	Is it worthwhile to keep a distinction between places in the
	topology (e.g. IP addresses) and what the current occupent of
	that space is (e.g. the node name)?

	The driver that Markku and seemingly you make is that the
	node and its place in the topology are invarient.

-- 
--bill

---

From: Stefan Jon Silverman <[email-masked]>
Date: Mon, 18 Oct 1999 21:36:55 -0400 (EDT)

Folks:

	Well, sitting here at a bar typing via a secure pipe into my NYC
machines from my laptop in San Francisco which has a wireless ricochet
modem I would tend to agree.....

	From a security point of view I would like the ricochet device to
have a permanent address so that I can limit the access lists on the NYC
machines.....

	And no, this is not inebreated rambling, I have not yet finished my
first drink.

    TRAVEL: At Scient SF as of 27th of Sept. -- Traveling often, no sched. yet

    Regards,

    b c++'ing u,

    %-) sjs

-------------------------------------------------------------------------------
                  Weebles wobble, but they don't fall down!!!
-------------------------------------------------------------------------------
Stefan Jon Silverman                                 SJS Associates, N.A., Inc.
                                               698 West End Avenue - Suite 15-B
                                                             New York, NY 10025
E-mail:    [email-masked]                                   Phone: 212 662 9450
Website:   http://www.sjsinc.com                            Fax:   212 662 9461
Text-Page: [email-masked]                              Cell:  917 929 1668
-------------------------------------------------------------------------------
                          In San Francisco

Scient:		415 591 3973 [email-masked] (MD - Infrastructure Arch.)
Home:       415 929 0406 [email-masked] (1155 Jones, Apt. 303 - 94133)
-------------------------------------------------------------------------------