Subject: Re: Stop implementing IPv6 before real harm is done........please
To: T@W <lsp93@xs4all.nl>
From: Steven M. Bellovin <smb@research.att.com>
List: port-i386
Date: 06/02/2001 12:55:51
In message <v04220800b73d5cb60669@[chilly]>, "T@W" writes:
>Hi all,
>
>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".
>Comments like:" it is a 'feature' rather than a trap door:"  are just
>raising smokescreens
>
>"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."
>
>See also http://www.epic.org/alert/EPIC_Alert_6.16.html

That myth again.  It was never really true to start with, and even the 
limited case where there was some validity to the claim has been dealt 
with by a change to the spec -- a change that was underway well before 
that story hit the press.  (You did note that that alert was 18 months 
old?)

First -- it was never true for dial-up hosts, which get a new IP 
address every time they connect (and probably don't have an Ethernet 
card to start with).  It was never true for DHCP-configured hosts, or 
for hosts with administratively-assigned IP addresses -- the sysadmin 
picks the IP address.  Of course, those are likely to be constant -- 
but that's true today, too; it's not v6-specific.  There's no change.

The scheme described is only used for autoconfiguration of clients when 
there is no dhcp server or the like.  It's a new, optional ability.  
But even for that case, RFC 3041 completely eliminated the problem.

		--Steve Bellovin, http://www.research.att.com/~smb