On Fri, Jun 01, 2001 at 11:39:27PM +0200, T@W wrote:

 > About the Internet Protocol Version 6 proposal [found at IPv6.org],
 > concerned people point to "the privacy issue contingent with IPv6 - namely
 > that one part of the new IP address would be the hardware address of the
 > network interface card it runs through".

Yes, it is true that auto-configured global and link-local addresses
are derived from the MAC address of their associated interface (oh, the
horror!!!) -- however, there is no Great Conspiracy here -- it's done
that way merely to ensure some uniqueness in the address, i.e. so there
aren't clashes.

 > Comments like:" it is a 'feature' rather than a trap door:"  are just
 > raising smokescreens

A smokescreen to cover up what, exactly?

 > "The idea behind having fixed-width, 64-bit wide host identifiers is that
 > they aren't assigned manually as in IPv4. Instead, v6 host addresses are
 > recommended (not mandated!) to be built from so-called EUI64 addresses.
 > EUI64 addresses are -- as the name says -- 64-bits wide, and derived from
 > MAC addresses of the underlying network interface. For example, with
 > Ethernet, the 6-byte (48-bit) MAC address is usually filled with the hex
 > bits "fffe" in the middle -- the MAC address."

Yes, it's called address autoconfiguration, and it's extremely useful.  On
the other hand, you don't have to use it if you don't want.  You can
manually assign ipv6 addresses just like you can with ipv4.  And, by default,
the only EUI64-derived address you'll get is the default link-local, so
you don't have to worry about Them getting your credit card number from your
MAC address.

(For those who don't know -- link-local addresses are ones which are not
globally addressable -- valid on the link associated with the interface
they are on only.. they're used to do e.g. Neighbor Discovery, which
is the ipv6 analog to ARP.)

 > 
 > See also http://www.epic.org/alert/EPIC_Alert_6.16.html
 > 
 > So my  plead is : "Abandon IPv6..now!"
 > 
 > Touchwood
 > 

-- 
        -- Jason R. Thorpe <thorpej@zembu.com>