Subject: RE: IPv6 WG Last Call:draft-ietf-ipv6-optimistic-dad-03.txt

From: "Christian Huitema" <[email-masked]>
Date: Thu, 27 Jan 2005 23:41:29 -0800

> On Thu, 27 Jan 2005, Nick 'Sharkey' Moore wrote:
> > Ethernet-derived addresses are indeed also an issue, but they're
> > hypothetically unique ... so we're back to estimating the
> > inestimable ... are they less likely to collide than 3041 because
> > of this supposed uniqueness, or more likely to collide because
> > of the possibility of human error?
> 
> Good question.. The reason why Ethernet MAC addresses would not be
> unique would probably be either human error (manually configuring the
> mac address) or a manufacturing error -- and in either case, it's not
> certain how much analysis on 2^48 would help..

Or, maybe, privacy. If we question the privacy aspects of sending unique
identifiers in IPv6 addresses, then we might also question the privacy
impact of broadcasting unique 48 bit identifiers in Ethernet or WIFI
frames. Rhetorical question: how long will it take before computers
systematically configure a new MAC address each time they reboot, or
each time they roam to a new network?

-- Christian Huitema 

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Pekka Savola <[email-masked]>
Date: Fri, 28 Jan 2005 10:27:46 +0200 (EET)

> each time they roam to a new network?

Actually, a friend of mine wrote this kind of code (Ethernet address 
randomization at bootup) to Linux as an alternative to RFC3041 maybe 
two years ago.  I didn't push for it too much because it would have 
caused confusion under those cases where you have a stationary node 
and MAC address "locking" is used in Ethernet switches. (And there's 
AFAICS no good way to automatically determine this..)

But for example on laptops which are expected to roam a bit more, this 
might make some amount of sense.  It might be better than RFC3041 from 
the L3 perspective, at least.

But the implications should IMHO be explored at some length first 
(maybe write an I-D?).  Changing MAC addresses is going to cause more 
disruption on the roaming host in case of false positives, i.e., the 
laptop thinks it moved but actually didn't, because the communication 
using the old MAC address and resulting IP addresses is going to be 
disrupted unless you assume some kind of Neighbor Advertisement 
message use ("gratuitous ARP").

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Francis Dupont <[email-masked]>
Date: Fri, 28 Jan 2005 10:46:39 +0100

In your previous mail you wrote:

=> I have a concern here: this topic is clearly outside the scope of
the IETF, i.e., it should be handled at the IEEE (in fact IMHO it is
already handled by the IEEE :-).

Regards

[email-masked]

---

From: Alper Yegin <[email-masked]>
Date: Fri, 28 Jan 2005 15:58:33 -0800

> already handled by the IEEE :-).

Then how come this issue is discussed in this "I-D" (check the author
list
:-)

http://ietf.org/internet-drafts/draft-haddad-momipriv-problem-statement-
00.txt

Since IETF's ARP and ND deal with the MAC addresses, I think some
discussion on that is needed at IETF.

Alper

---

From: Francis Dupont <[email-masked]>
Date: Sun, 30 Jan 2005 11:47:01 +0100

=> I was not clear enough: my concern is about producing an IETF
document about MAC address changing, not about discussion about
this topics.

Regards