Subject: RE: Privacy problems in IPv6

From: Jim Dunn <[email-masked]>
Date: Sat, 9 Oct 1999 07:35:28 +0100

IMHO I believe it would be better to target our comments and responses to the author of the article who has made a number of incorrect (and possibly damaging) assumptions.

The problem with these sorts of articles, is that they are usually written by people from an business/financial analyst's background, who lack the technical understanding or have not researched the subject enough to write an impartial report. (see below for author)

Bill Frezza is a general partner at Adams Capital Management. He can be
                  reached at [email-masked] or www.acm.com.

 This is potentially very damaging for us, due to the audience at which the article is directed. People will read the article and believe it (what ever happened to responsible journalism ;-> ) and consumer demand for IPv6 will decrease because of it.

If you ask around, many people are vaguely aware that a new IP version is becoming available, but don't know much about it, I work with many IP engineers who know vast ammounts about v4 but little if anything of v6, and articles like this that do not help, because they do not give both sides of the argument and allow people to make a rational and informed decision especially when privacy is involved, a subject that most people can work themselves into a frenzy over, very easily.

In many parts of the world, Privacy is a hard won right and people get very twitchy if they feel that right to privacy is being obused. We have to make sure that articles of this nature are technically accurate and portray the subject matter impartially, so that people don't jump to conclusions.

IPv6 has been in development for a long time, with some extremely clever people contributing to it's continued development, the last thing we want is for deployment to stall because the user's do not have confidence in it.

Jim

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

-----Original Message-----
From:	Thomas Narten [SMTP:[email-masked]]
Sent:	08 October 1999 16:18
To:	Richard M. Smith
Cc:	[email-masked]
Subject:	Re: Privacy problems in IPv6 

Richard,

The article has a number of technical inaccuracies.

> Now, what happens when the Internet Engineering Task Force does the same
> thing, specifying an addressing structure in its next-generation Internet
> protocol, IPv6, such that every packet can be traced back to each user's
> unique network interface card ID? Apparently, nothing.

IPv6 addresses contain MAC addresses only if they were created via
stateless autoconfiguration. If one were to use DHCP instead, this
wouldn't necessarily be the case. (I say necessarily because it would
then be the policy of the server that determines what address you
would get.)

> IPv6 was initially proposed to solve the "problem" that IPv4 has with
> running out of addresses. You would think that the 32-bit address field of
> IPv4, supporting more than 4 billion unique addresses, would be sufficient
> to last quite some time. Unfortunately, the cabal that controlled the
> disposition of these addresses had a habit of handing out large blocks to
> their friends, who parlayed these into start-ups with multibillion-
> dollar market caps. Hence, the "shortage."

The above is grossly innaccurate. I know few people that argue
(convincingly) that we are not in danger of running out of globally
unique IPv4 addresses. It is a question of when, not if.  This has
nothing to do with "cabals". It has to do with the exponential growth
of the Internet, and the current/future trend of making every device
(cell phones, consumer electronics, etc.) capable of connecting to the
Internet.

While it is true that some organizations have received seemingly huge
and "wasteful" assignments, this was (for the most part) done long ago
(e.g., in the 1980s) before anyone had an inkling that address space
needed to be coserved. Also, only 1/4 of the total IPv4 address space
is in use today, so the large blocks that have been handed out in the
past cannot be considered the main problem today.

The "shortage" today is more interesting, given that only 1/4 of the
total address space is actually in use. In practice, however, address
registries are being much more stringent about giving out
addresses. Some folks (like those that can't get as many as they'd
like) say too stringent. But the registries are motivated by the
concern that IPv4 addresses are in fact a limited resource today that
must be carefully managed. This is a complex issue with many differing
opinions as to whether the current policies are in fact "right".

> As you might expect, the address field is so huge that the IETF
> didn't know how to assign it. So, in a move to get buy-in from
> established industry standards bodies, the right-most 64 bits were
> designated to contain EUI-64 format information. This is used by the
> IEEE to assign Ethernet addresses, which are normally not
> transmitted outside a user's LAN.

The 64-bits contain the EUI-64 address for several reasons. For one
thing, 128 bits *is* a lot, and splitting an address into 64 bits for
routing & 64 for host identification does not appear to limit growth
in any realistic sense. 64 bits for routing seems more than adequate
and certainly won't limit future growth.  Having the 64-bit EUI for
the Interface Identifier keeps stateless address autoconfiguration
simple and robust. Also, the 64-bit EUI was chosen to allow future
flexibility with new architectures that might allow IP addresses to be
cleanly separated into a locator and identifier portion. Again, the
EUI-64 is (generally) globally unique, which appears to be a desirable
property from the perspective of separating addrsses into
locator/identifier portions.

I don't understand the reference to "buy in from established industry
standards bodies". We use EUI-64 identifiers because they already
happen to exist and have the desired properties (globally unique and
available on pretty much all hardware). The IETF in never contacted
the IEEE about using them. We just use them. 

> Included in EUI-64 are two interesting pieces of information: the
> registered manufacturer of your NIC card and your 48-bit Ethernet
> address. Surprise!  Every packet you send out onto the public
> Internet using IPv6 has your fingerprints on it. And unlike your IP
> address under IPv4, which you can change, this address is embedded
> in your hardware. Permanently.

Strictly speaking, not true. From the perspective of stateless address
autoconfiguration, one can use an identifier other than the one in the
hardware. This does require manual configuration by the end user. But
it is specifically called out for in the design because it is needed
to handle the case where duplicate addresses occur in hardware.

> The spooks and weirdos in Washington, ever eager to empower the
> surveillance state as they fight a rear-guard action against strong
> encryption, must be thrilled with such a gift. They appear so
> thrilled that the Institute for Information Sciences, heavily funded
> by the Defense Department, is writing a reference stack for IPv6
> that it is quietly hoping to slip into Windows 2000.

Well, if every research project that gets some dollars from govt. is
in reality a nefarious plot run by the "spooks and weirdos" with a
hidden agenda, I guess this might be true. (To be clear: I don't
happen to subscribe to this particular school.)

> It looks like the geeks screwed up this time, though. I hope they
> have the wisdom to fix things before it's too late.

The issue of EUI-64s in IPv6 addresses has been a known problem for a
long time. But the community is certainly not in agreement about how
serious a problem it really is in practice. It is important to
distinguish here "reality" from "perception".  You might take a look
at draft-ietf-ipngwg-addrconf-privacy-00.txt.  It attempts to discuss
some of the issues and attempts to put them in perspective. The
document also proposes a solution for those that believe the issue is
significant. (The document also is a work-in-progress with another
version coming, so it is certainly not the final word on the topic.)
The document takes the view that this would be an optional approach
precisely because it it is unclear that it is the best approach for
all environments.

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

--------------------------------------------------------------------
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: Ignatios Souvatzis <[email-masked]>
Date: Mon, 11 Oct 1999 09:24:06 +0200

>  IMHO I believe it would be better to target our comments and responses to the author of the article who has made a number of incorrect (and possibly damaging) assumptions.

I did, and didn't get any reaction up to now. Well, its deep Sunday night
where he lives, so this still might change.

	-is
-- 
 * Progress (n.): The process through which Usenet has evolved from
   smart people in front of dumb terminals to dumb people in front of
   smart terminals.  -- [email-masked] (obscurity)
--------------------------------------------------------------------
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: Ignatios Souvatzis <[email-masked]>
Date: Mon, 11 Oct 1999 09:50:24 +0200

> where he lives, so this still might change.

Actually, it just arrived. AFAICT, he pretends to acknowledge that dynamic
IP addresses (at dialup providers) make this problem go away, but makes IPv6
responsible for the deployment of cable modems.

	-is