Subject: DAD question

From: "Fred Baker (fred)" <[email-masked]>
Date: Fri, 10 Aug 2012 22:17:15 +0000

Call this "making sure I'm on the same page as anyone else"…

RFC 4941 describes privacy addresses, and RFC 4291 describes an EID based on a MAC Address. RFC 4862 describes stateless address autoconfiguration, and uses RFC 4861's duplicate address detection mechanism.

My question is: what happens if any of them discovers that it has created an address that is already in use in the network?

There would appear to be two options: 
(1) "ah, OK, I guess I didn't really want to talk today"
(2) Following RFC 4941, guess again until one creates a unique address

Is it fair to assume that implementations do DAD and follow (2)?

---

From: Jared Mauch <[email-masked]>
Date: Fri, 10 Aug 2012 18:19:21 -0400

> Is it fair to assume that implementations do DAD and follow (2)?

This is the logical thing that I personally would do..

- Jared

---

From: Fernando Gont <[email-masked]>
Date: Fri, 10 Aug 2012 20:08:17 -0300

Hi, Fred,

On 08/10/2012 07:17 PM, Fred Baker (fred) wrote:
> RFC 4941 describes privacy addresses, and RFC 4291 describes an EID
> based on a MAC Address. RFC 4862 describes stateless address
> autoconfiguration, and uses RFC 4861's duplicate address detection
> mechanism.
> 
> My question is: what happens if any of them discovers that it has
> created an address that is already in use in the network?

For traditional SLAAC (i.e. EID based on the MAC address), SLAAC simply
fails.

IIRC, you get different results depending on whether DAD fails for a
link-local address, or it fails for a non-link-local address. For the
former, you may need to reboot your system. For the later, I seem to
recall that some systems "perform DAD", but do not care if DAD actually
fails.

Simplest answer: "Try it":

Run na6 (http://www.si6networks.com.ar/tools) as follows:

# ./na6 -i eth0 -j :: -c -o -e -L -vv

where:
"-i eth0": your NIC
"-j ::":   tells the tool to only respond to packets with the Src Addr
           set to the unspec addr (i.e., DAD packets)
"-c":      Set the solicited flag
"-o:"      Set the override flag (shouldn't matter in this case)
"-L":      Listen mode (wait for incoming ns'es)
"-vv":     Be very verbose

> There would appear to be two options: (1) "ah, OK, I guess I didn't
> really want to talk today"

This is what all implementations do for tradicional SLAAC (when they do
honor SLAAC --see above).

> Is it fair to assume that implementations do DAD and follow (2)? 

Might be fair to assume this for the temporary address, but it is
certainly not realistic to assume this for the traditional SLAAC address
(*) (**).

(*) Microsoft Windows allegedly replace the traditional SLAAC addresses
with a RFC4941-based scheme that simply does not cycle the addresses
over time -- hence "(2)" might apply to Windows.

(**) Will head in this direction for
draft-ietf-6man-stable-privacy-addresses

Cheers,
-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Ole Trøan <[email-masked]>
Date: Sat, 11 Aug 2012 10:33:51 +0200

Fred,

> Is it fair to assume that implementations do DAD and follow (2)?

implementations I'm familiar with do 1.
it may be a fair assumption that if an address based on the MAC address is duplicate, the MAC address itself is a duplicate.

cheers,
Ole

---

From: Bob Hinden <[email-masked]>
Date: Sat, 11 Aug 2012 08:36:00 -0700

Ole,

> it may be a fair assumption that if an address based on the MAC address is duplicate, the MAC address itself is a duplicate.

True, but the odds of this happening are very low.  I wonder if we have any data on DAD detecting duplicate addresses and their cause.

For example, has any seen any actual duplicate MAC addresses?  It would be good to collect some data.

Bob

> 
> cheers,
> Ole--------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Dominik Elsbroek <[email-masked]>
Date: Sat, 11 Aug 2012 08:45:08 -0700

Hi list,

i few month ago I played around with dos-new-ip6.c from the IPv6
Attack Toolkit of Marc Heuse (see http://thc.org/thc-ipv6/). The tool
answers to any neighbor solicitation with an neighbor advertisement.
Debian 6.0.5 sent the neighbor solicitation a few times, always
receiving a neighbor advertisement for the desired address. After a
few tries Debian just assigned the desired address. This was tested
using a OpenVPN network with VMs using VirtualBox.

Cheers,
Dominik

---

From: joel jaeggli <[email-masked]>
Date: Sat, 11 Aug 2012 08:47:35 -0700

> For example, has any seen any actual duplicate MAC addresses?  It would be good to collect some data.
Most sun machines that I recall had the same mac address on all interfaces.

Duplicate macs are generally in my experience the product of deliberate 
configuration, cloning virtual machines or similar activity.

---

From: [email-masked]
Date: Sat, 11 Aug 2012 18:01:04 +0200 (CEST)

> True, but the odds of this happening are very low.  I wonder if we have any data on DAD detecting duplicate addresses and their cause.

You may need to qualify "very low".

> For example, has any seen any actual duplicate MAC addresses?  It would be good to collect some data.

Duplicate MAC addresses are regularly seen in the wild. As an example,
from a nearby DHCP server, I have the following duplicates from a total
of 65499 MAC addresses:

5 00:90:4c:91:00:01;
3 00:40:10:20:00:02;
3 00:00:00:00:00:00;
2 bc:b1:f3:61:28:e3;
2 98:0c:82:84:ef:83;
2 34:21:09:03:76:f9;
2 00:1f:1f:8c:d4:d5;
2 00:1f:1f:8c:d4:cd;
2 00:1d:73:11:11:13;
2 00:11:22:33:44:56;

So from this sample a total of 10 MAC addresses occur more than once
(different customers, different locations).

I make no claims about these numbers being representative. My main 
point is that duplicates *occur*, for several different reasons, e.g.

- Manufacturing mistakes
- Software bugs
- MAC address explicitly set

Steinar Haug, Nethelp consulting, [email-masked]

---

From: Mikael Abrahamsson <[email-masked]>
Date: Sat, 11 Aug 2012 18:57:53 +0200 (CEST)

> (different customers, different locations).

I concur. Back 5-8 years ago, we had a few percent of our household 
customers use the same MAC address, namely the one D-link assigned by 
default to their NAT boxes and then added an option to "clone" an inside 
PC address if one wanted to change the WAN facing address.

MAC addresses being non-unique is happening a lot more commonly than it 
should, and needs to be taken in account.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Fernando Gont <[email-masked]>
Date: Sat, 11 Aug 2012 14:16:41 -0300

Hi, Bob,

> True, but the odds of this happening are very low.  I wonder if we have any data on DAD detecting duplicate addresses and their cause.

Virtual machines?

Cheers,

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Sat, 11 Aug 2012 18:57:40 +0000

> it may be a fair assumption that if an address based on the MAC address is duplicate, the MAC address itself is a duplicate.

And that relates to privacy addresses how?

---

From: Ole Trøan <[email-masked]>
Date: Sat, 11 Aug 2012 21:04:10 +0200

> And that relates to privacy addresses how?

it doesn't. is your question how DAD is done for privacy addresses?

then section 3.3 of RFC4941 is quite clear on that.

cheers,
Ole

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Sat, 11 Aug 2012 20:11:06 +0000

> it doesn't. is your question how DAD is done for privacy addresses?

My question is for all addresses. I'm getting responses for MAC addresses.

> then section 3.3 of RFC4941 is quite clear on that.

----------------------------------------------------
The ignorance of how to use new knowledge stockpiles exponentially. 
   - Marshall McLuhan

---

From: Karl Auer <[email-masked]>
Date: Sun, 12 Aug 2012 07:39:04 +1000

On Sat, 2012-08-11 at 18:01 +0200, [email-masked] wrote:
> Duplicate MAC addresses are regularly seen in the wild.

It's important to remember that DAD is link local. It is only checking
whether the same address occurs on the local link. Duplicate MAC
addresses are not actually a problem as long as the duplicates are not
on the same link. If the duplicates ARE on the same link, then you have
a real problem at layer 2 anyway. The same link local address, based on
a MAC, is also a real problem if it's duplicated, for much the same
reason.

Regards, K.

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Karl Auer ([email-masked])
http://www.biplane.com.au/kauer
http://www.biplane.com.au/blog

GPG fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017
Old fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687

---

From: [email-masked]
Date: Sat, 11 Aug 2012 23:48:46 +0200 (CEST)

> a MAC, is also a real problem if it's duplicated, for much the same

We use the 1:1 VLAN model for our customers, so in that sense I agree
with you - these duplicates would not be a problem in our case. If we
had used the N:1 VLAN model instead, it could be a very real problem.

---

From: Fernando Gont <[email-masked]>
Date: Sat, 11 Aug 2012 18:52:09 -0300

On 08/11/2012 06:39 PM, Karl Auer wrote:
> If the duplicates ARE on the same link, then you have
> a real problem at layer 2 anyway. 

It sucks -- e.g., performance-wise.

However, if the layer above 2 employs addressing (e.g. IPv4 and IPv6),
things should still work even in the presence of *this* problem.

Traditional SLAAC addresses deriving the IPv6 address from the (now
non-unique) MAC address introduces a different problem.

Cheers,

---

From: Bob Hinden <[email-masked]>
Date: Sat, 11 Aug 2012 15:17:12 -0700

Steinar,

> from a nearby DHCP server, I have the following duplicates from a total

Interesting.  Are these different machines/interfaces with the same Mac addresses, or the same machine connecting via some other path or location.

My question was about machines/interfaces.  That is, are we seeing manufacturing mistakes, etc.?

Thanks,
Bob

---

From: Bob Hinden <[email-masked]>
Date: Sat, 11 Aug 2012 15:18:01 -0700

>> True, but the odds of this happening are very low.  I wonder if we have any data on DAD detecting duplicate addresses and their cause.

Good point.  

Thanks,
Bob

---

From: Bob Hinden <[email-masked]>
Date: Sat, 11 Aug 2012 15:20:29 -0700

Joel,

> Most sun machines that I recall had the same mac address on all interfaces.

Right, but that would cause DAD to trigger unless the interfaces were connected to the same link.  I would think this is an issue for servers.

> 
> Duplicate macs are generally in my experience the product of deliberate configuration, cloning virtual machines or similar activity.

That makes sense.

Thanks,
Bob

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 12 Aug 2012 08:19:47 +0100

On 11/08/2012 22:39, Karl Auer wrote:
> on the same link. 

I think they are a problem for sites that register MAC addresses and
use them as a first-line authentication mechanism. Obviously that is very
weak from a security point of view, but it's common practice.

   Brian

---

From: Michael Richardson <[email-masked]>
Date: Sun, 12 Aug 2012 12:20:24 -0400

>>>>> "Bob" == Bob Hinden <[email-masked]> writes:
    Bob> True, but the odds of this happening are very low.  I wonder if
    Bob> we have any data on DAD detecting duplicate addresses and their
    Bob> cause. 

In my experience, MAC address duplicates are almost always the result of
too-true copy&paste'ing of virtual machine configurations :-)
(You want to duplicate the virtual machine in order to try an upgrade...)

    Bob> For example, has any seen any actual duplicate MAC addresses?
    Bob> It would be good to collect some data. 

if you remove 00:00:00:00:00:00 and ff:ff:ff:ff:ff:ff from the list,
I've never seen a duplicate.  (all-zeros and all-ones are the result of
the eeprom dying in various ways, or a driver getting confused.  Both
will work until you get a second machine with the same problem)

-- 
Michael Richardson <[email-masked]>, Sandelman Software Works

---

From: Bob Hinden <[email-masked]>
Date: Sun, 12 Aug 2012 10:04:07 -0700

Michael,

> will work until you get a second machine with the same problem)

Thanks, very helpful.

Bob

---

From: Randy Bush <[email-masked]>
Date: Sun, 12 Aug 2012 13:15:28 -0400

> For example, has any seen any actual duplicate MAC addresses?

they have been rife.  discussed on ops lists.

randy

---

From: [email-masked]
Date: Sun, 12 Aug 2012 22:15:39 +0200 (CEST)

> (You want to duplicate the virtual machine in order to try an upgrade...)

Here are a couple of counterexamples, taken from the list of 10 MAC
addresses in my previous message. Both duplicates apparently due to
software error, both affecting Linksys routers:

1. Googling "mac address 00:90:4c:91:00:01" gives me for instance

http://homecommunity.cisco.com/t5/Access-Points/WAP54G-MAC-address-overwritten-how/td-p/26679

http://forum.soft32.com/linux2/Linksys-WAP54G-spontaneously-MAC-ftopict40391.html

2. Googling "mac address 00:40:10:20:00:02" gives me for instance

http://www.dd-wrt.com/phpBB2/viewtopic.php?p=16097&sid=81aa5d3a28eb9718427591418ea20e3e

http://secure.dd-wrt.com/phpBB2/viewtopic.php?t=53350&view=next&sid=c927780443f32c982cf9dd57d73ae952

---

From: "Duncan, Richard (Jeremy)" <[email-masked]>
Date: Fri, 10 Aug 2012 22:32:40 +0000

Fred-

That's not the case at all.  In testing I have done on Unix, Linux and Windows systems they all do (1).  There are a few variations with BSD, but for the most part they just stop trying.  In fact, RFC 4862 allows for that behavior and actually encourages it:

5.4.5. When Duplicate Address Detection Fails

A tentative address that is determined to be a duplicate as described above MUST NOT be assigned to an interface, and the node SHOULD log a system management error.

If the address is a link-local address formed from an interface identifier based on the hardware address, which is supposed to be uniquely assigned (e.g., EUI-64 for an Ethernet interface), IP operation on the interface SHOULD be disabled. By disabling IP operation, the node will then:

- not send any IP packets from the interface,

- silently drop any IP packets received on the interface, and

- not forward any IP packets to the interface (when acting as a router or processing a packet with a Routing header).

In this case, the IP address duplication probably means duplicate hardware addresses are in use, and trying to recover from it by configuring another IP address will not result in a usable network. In fact, it probably makes things worse by creating problems that are harder to diagnose than just disabling network operation on the interface; the user will see a partially working network where some things work, and other things do not.

On the other hand, if the duplicate link-local address is not formed from an interface identifier based on the hardware address, which is supposed to be uniquely assigned, IP operation on the interface MAY be continued.

010100110110010101101101011100000110010101110010001000000100011001101001

Jeremy Duncan
Senior Director, IPv6 Network Architect
Salient Federal Solutions, Inc. (Now including SGIS & Command Information Inc.)
4000 Legato Road, Suite 600
Fairfax, VA 22033
Google Voice: 540.440.1193
[email-masked]

Jared Mauch <[email-masked]> wrote:

- Jared

---

From: [email-masked]
Date: Sun, 12 Aug 2012 22:29:47 +0200 (CEST)

> Interesting.  Are these different machines/interfaces with the same Mac addresses, or the same machine connecting via some other path or location.

I have duplicates on different BRAS boxes in widely different
geographical locations, plus these are almost exclusively residential
users. That makes it highly unlikely that they are the same machine
connecting  via some other path/location.

> My question was about machines/interfaces.  That is, are we seeing manufacturing mistakes, etc.?

Explicit manufacturing mistakes (e.g. vendor turning our X copies of
the same box with the same MAC address) have been reported on ops
lists several times in the past.

Software errors resulting in duplicates have been reported multiple
times (see for instance my reply to Michael Richardson on this list).

The possibility of explicitly configuring the MAC address exists in
many operating systems (e.g. the FreeBSD box I'm typing this on).

The easy availability of "MAC address cloning" was mentioned by Mikael
Abrahamsson. Note that "MAC address cloning" is used in home routers,
not just in VM environments.

---

From: Karl Auer <[email-masked]>
Date: Mon, 13 Aug 2012 07:12:41 +1000

On Fri, 2012-08-10 at 22:32 +0000, Duncan, Richard (Jeremy) wrote:
> That's not the case at all.  In testing I have done on Unix, Linux and
> Windows systems they all do (1).  5.4.5. When Duplicate Address
> Detection Fails

My experience with Linux is that a duplicate LLA resukts in a down
interface, a duplicate GUA results in a permanently-tentative enabled
interface.

Regards, K.

---

From: Carsten Bormann <[email-masked]>
Date: Sun, 12 Aug 2012 23:27:37 +0200

> lists several times in the past.

Counterfeiting of network hardware may be another source of problems.
A counterfeiter has a strong incentive to use an inconspicuous MAC address, i.e. one that is indistinguishable from the real thing, and they may hit the real thing as a result.

Grüße, Carsten

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Mon, 13 Aug 2012 14:28:28 +0000

> My question is: what happens if any of them discovers that it has created an
> address that is already in use in the network?
> 

>From the perspective of the CE router...
BBF decided on the following recommendation:
If DAD (on the WAN) fails for link-local or SLAAC, "vendor should implement graceful handling, including trying other addresses".

Router vendors felt this provided reasonable advice without limiting how they accomplished it. Some thought it would be reasonable to try using MAC addresses associated with other interfaces (from a LAN Ethernet or Wi-Fi interface), increment the previously tried value by 1 or x, and other possibilities. Once there was greater experience with real deployments, where it could be seen what worked and was easy, there would probably be convergence on "best practices".  But it was acknowledged that (1) such duplication of MAC addresses exists and is reasonably prevalent (all service providers see this), (2) it is unlikely that we can stop this from happening, (3) allowing such a CE router to become a brick would generate trouble calls and serve no useful purpose, and (4) implementing code that would try a different value was simple and had no perceived downside (as long as all CE routers had code to try other values). 

As has been pointed out, using 1:1 VLAN would prevent this problem. But my perspective is that the CE router doesn't know what access network it will land in, and needs to be resilient when finding itself in a N:1 VLAN environment.

As Ole pointed out, RFC 4941 explicitly mandates generation of a different privacy address when DAD fails.
RFC 3315 recommends use of DAD and telling the DHCPv6 server (Decline) if DAD fails. But this case isn't perceived to be a problem (unless the DHCPv6 server is misconfigured or someone managed to get that IPv6 Attack Toolkit that Dominik mentioned into the access network -- in which case we have bigger problems). A bigger problem for DHCPv6 servers may be the one of duplicate DUIDs, which may cause a DHCPv6 server to refuse to provide a IA_NA. This apparently is sufficiently prevalent that Microsoft had to provide info on how to fix it: http://support.microsoft.com/kb/2711727

Barbara

---

From: Francis Dupont <[email-masked]>
Date: Tue, 14 Aug 2012 13:41:44 +0200

I remember (perhaps the first detected duplicate?) a very early occurrence
before 1995 with a DEC box using a cloned full config. Same Decnet address
so same MAC address so same IPv6 link-local address...

Regards

[email-masked]

PS: I can contact the person who found it if you need it for archives.

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Tue, 14 Aug 2012 16:28:12 +0000

On Aug 14, 2012, at 4:41 AM, Francis Dupont wrote:

> so same MAC address so same IPv6 link-local address…

Where I'm coming from in this is an expectation on my part that appears to not be shared. If duplicate MAC addresses are unusual but reasonably common (happen with some probability like .01% or whatever), there's a reasonable expectation that there would be a work-around for the issue. The work-around, I suggest, would be to have the station use a privacy address instead of a MAC-based address when a duplicate MAC address is detected.

I've said before that I find the fixation an MAC addresses strange; not all devices have MAC addresses in the first place, and having built an EID from a MAC address, there is no case in which we try to derive the MAC address from it. Not all devices, believe it or not, have Ethernet or WiFi interfaces, and one with a WiFi and something else, such as your telephone, would only use the WiFi MAC address for the EID on that interface. What do I mean by "deriving the MAC from the EID"? There was a proposal in CLNS at one point (which failed for several reasons) to not need ES-IS and instead simply use the MAC address of an interface as the host identifier part of an NSAP - a router could pull it out and simply forward the datagram to the derived MAC address - and that model was used in XNS and IPX as well. But for the same reasons that OSI didn't go with that model, we have not chosen to go with that model in IPv6. 

So the MAC address is at most a seed for building an EID, one of many, and to my small mind if it doesn't result in a unique one, the obvious recovery action is to pick another by a different algorithm.

I gather nobody agrees with me.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 14 Aug 2012 13:02:47 -0400

>>>>> "fred" == fred  <Baker (fred)" <[email-masked]>> writes:
    fred> I've said before that I find the fixation an MAC addresses
    fred> strange; not all devices have MAC addresses in the first
    fred> place, and having built an EID from a MAC address, there is no

But, enough devices have them that it's just not a concern. 
The devices that don't tend not to do any kind of SLAAC.

    fred> So the MAC address is at most a seed for building an EID, one
    fred> of many, and to my small mind if it doesn't result in a unique
    fred> one, the obvious recovery action is to pick another by a
    fred> different algorithm.

    fred> I gather nobody agrees with me.

I think that we agree with you.  I think that most implementations of
SLAAC were done prior to there being any other choice, and simply
haven't been updated to do something different if DAD fails.

---

From: Simon Perreault <[email-masked]>
Date: Tue, 14 Aug 2012 13:16:15 -0400

Le 2012-08-14 12:28, Fred Baker (fred) a écrit :
> Where I'm coming from in this is an expectation on my part that
> appears to not be shared. If duplicate MAC addresses are unusual but
> reasonably common (happen with some probability like .01% or
> whatever), there's a reasonable expectation that there would be a
> work-around for the issue. The work-around, I suggest, would be to
> have the station use a privacy address instead of a MAC-based address
> when a duplicate MAC address is detected.

Since privacy addresses are supposed to be configured alongside regular 
SLAAC addresses, there should be no need for an explicit fallback. Just 
enable both SLAAC and privacy simultaneously. If SLAAC fails, you still 
have privacy.

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Tue, 14 Aug 2012 13:58:41 -0500

> Fred Baker (fred) wrote:

> The work-around, I suggest, would be to have the station use a privacy
> address instead of a MAC-based address when a duplicate MAC address is
> detected.

Actually, I has the same thought when this subject came up. And DAD.

> I gather nobody agrees with me.

FWIW, I totally agree.

Bert

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 15 Aug 2012 08:05:59 +0100

> enable both SLAAC and privacy simultaneously. If SLAAC fails, you still

True, but you won't have connectivity on any network that uses MAC address
registration as a form of weak access control. Not that IPv6 can solve that
problem, but it should be noted.

    Brian

---

From: Daniël W. Crompton <[email-masked]>
Date: Wed, 15 Aug 2012 12:40:02 +0200

On 11 August 2012 17:36, Bob Hinden <[email-masked]> wrote:
<...snipped for brevity...>

> good to collect some data.

Yes, I've seen this for several hardware manufactures. Most memorable were
Sun boxes in which all of the 4 network interfaces shared the same MAC
after unboxing.

D.

blaze your trail

-- 
Daniël W. Crompton <[email-masked]>

 <http://specialbrands.net/>

<http://specialbrands.net/>
http://specialbrands.net/
<http://twitter.com/webhat>
<http://www.facebook.com/webhat><http://plancast.com/webhat><http://www.linkedin.com/in/redhat>

---

From: [email-masked]
Date: Wed, 15 Aug 2012 12:56:27 +0200 (CEST)

> Sun boxes in which all of the 4 network interfaces shared the same MAC

Note that this is a perfectly valid configuration according to the
Ethernet standards.

---

From: Fernando Gont <[email-masked]>
Date: Wed, 15 Aug 2012 08:32:44 -0300

> Note that this is a perfectly valid configuration according to the

Just curious: were the MAC addresses "globally unique"? (me talking
about the U/L bit in the MAC address).

If they were, then I wonder how they could possibly be
standards-compliant... or whether the U/L should have been named
something else. :-)

Cheers,

---

From: [email-masked]
Date: Wed, 15 Aug 2012 13:38:10 +0200 (CEST)

> about the U/L bit in the MAC address).

Globally unique. The point here is that the Ethernet standards require
a globally unique MAC address *per box*, not necessarily per interface.
The "Sun way" of storing a MAC address in EEPROM and configuring all
network cards with the same MAC address was perfectly compliant, just
somewhat unusual.

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Wed, 15 Aug 2012 13:55:23 -0500

> problem, but it should be noted.

Unless that MAC address access control is done at Layer 2, which is not uncommon.

Bert

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Wed, 15 Aug 2012 14:00:26 -0500

> network cards with the same MAC address was perfectly compliant, just

But that's not the whole story, right?

The only way this can work is if one assumes that each interface of that box is connected to a different IP subnet. I don't even think Ethernet rules are what matters here. If the box should happen to be dual homed to the same IP subnet, that Sun scheme doesn't work. (I suppose unless only one of the box's interface is active at any given time.

Bert

---

From: joel jaeggli <[email-masked]>
Date: Wed, 15 Aug 2012 12:18:15 -0700

> The only way this can work is if one assumes that each interface of that box is connected to a different IP subnet. I don't even think Ethernet rules are what matters here. If the box should happen…
To be clear the employment of that scheme predates existence of routers 
in in small network deployments.

if you need more than one interface on the same subnet you adjust them 
accordingly.

---

From: [email-masked]
Date: Wed, 15 Aug 2012 21:25:10 +0200 (CEST)

> The only way this can work is if one assumes that each interface of that box is connected to a different IP subnet. I don't even think Ethernet rules are what matters here. If the box should happen…

Obviously. And I believe more modern Sun boxes actually have a MAC
address per interface. All I'm saying is that there is nothing wrong,
standards-wise, in having *one* globally unique MAC address per box.

Having the same MAC address shared between two (or more) boxes *is*
wrong, standards-wise. And unfortunately that's exactly what we're
seeing in practice. Not often, but "often enough" that it may not be
safe to ignore the possibility.

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Wed, 15 Aug 2012 14:37:37 -0500

[email-masked] wrote:

> All I'm saying is that there is nothing wrong,

But I'm disagreeing.

There is a lot wrong with having the same address on multiple ports of a box, when those multiple ports share the same network. This is true both at layer 2 and at layer 3, right?

There are work-arounds, such as ensuring only one port is active, e.g. via STP or whatever.

The Sun scheme worked only under certain circumstances. It would violate standards in certain scenarios.

> safe to ignore the possibility.

That's also true.

Bert

---

From: [email-masked]
Date: Wed, 15 Aug 2012 21:44:10 +0200 (CEST)

> There is a lot wrong with having the same address on multiple ports of a box, when those multiple ports share the same network. This is true both at layer 2 and at layer 3, right?

For more info see for instance the following comp.dcom.lans.ethernet
message from Rich Seifert:

https://groups.google.com/group/comp.dcom.lans.ethernet/msg/dbe062f75538718d?hl=en&dmode=source&output=gplain

<quote>
Which is exactly why I said MAC addresses are not *ordinarily*
assigned to CPU ports. Sun uses (used?) the model that I actually
prefer, i.e., that the MAC address identifies the *station*, rather
than the network interface. There is a  discussion of these two models
in "The Switch Book," excerpted here:

"There are actually two philosophies for interpreting unicast
addresses. One philosophy follows the premise that a unicast address
identifies a device (e.g., a workstation or server), as opposed to a
network interface installed within the device. Under this philosophy,
when a device has multiple interfaces, it uses the same address on all
of them. This approach was used in the original Xerox Network System
(XNS) and most Sun Microsystems' products.

The other philosophy, that an address uniquely identifies the
interface rather than the device, sees more widespread application
today, and is the model assumed in this book (even though the author
has an affection and longing for the 'architectural purity' of the
single address per device model). Using the address-per-interface
philosophy, a device with multiple interfaces will have multiple
unicast addresses assigned to it.

Both philosophies are valid, in the sense that both can be made to
work properly in a practical network. In neither case is there any
ambiguity about the destination for a frame sent to a given unicast
address."
</quote>

However, this is getting rather far away from the *practical*
problem of DAD in the face of several boxes with the same MAC
address on the same LAN segment.

---

From: Karl Auer <[email-masked]>
Date: Thu, 16 Aug 2012 08:00:27 +1000

On Wed, 2012-08-15 at 13:55 -0500, Manfredi, Albert E wrote:
> > address registration as a form of weak access control.

The two are different. One registers MACs at a central location and
refuses service (eg DHCP) to unregistered MAC addresses. The hosts
already have network access. The other checks at layer 2 whether they
are permitted to access the network at all (e.g. 802.1x).

Both systems have problems with duplicate MAC addresses. Not showstopper
problems, but problems.

Regards, K.

---

From: Ray Hunter <[email-masked]>
Date: Thu, 16 Aug 2012 10:40:41 +0200

I agree with you that there's a potential problem, and treating the MAC 
address as one source of a seed is a potential solution.

I think the discussion would benefit if there was a clear distinction 
made between the BIA (burned in address aka native address that is 
supposedly guaranteed to be unique by the delegated authority from the 
IEEE to the OUI) and a locally administered address (g/l bit).

DECnet IV used the latter, and hence avoiding duplicate MAC addresses 
would depend on actions of local administrators. If admins don't do 
their job correctly they will certainly not be unique, as the MAC 
address is strongly tied to the DECnet IV area and node addresses. The 
IPv6 stack would theoretically still have the former BIA available to 
the drivers to either act as a seed or to use for SLAAC.

Similar situation for Cisco HSRP, VRRP, HP HACMP etc. where there is a 
deliberate duplication of MAC addresses, and some higher layer protocol 
ensures only one is active at any one time. These machines still all 
have a native MAC and IP address, as well as the floating virtual MAC 
address and IP address.

VM's would not generally have any unique globally assigned BIA, and only 
have a locally administered MAC address generated by the local VM code, 
plus perhaps access to one or more global physical NIC adapter 
address(es) (shared with the host OS).

I agree tight bidirectional coupling of L2 address & L3 address is 
generally a bad idea (IPX over FDDI, Token Ring, + Ethernet), but it 
could have avoided many ND resource depletion problems/ potential DoS 
vectors.

I have thought of posting something on VLSM/SLAAC, where the interface 
identifier is simply an automatically assigned semi-random number like 
the Appletalk node address in LLAP. That would potentially be beneficial 
in avoiding duplicate MAC addresses, for encapsulations on systems 
without a MAC address, and also in reducing resources required for ND 
and any other processes that need to log/track non-existent nodes such 
as firewalls and security scanners (there would be no hard link to /64 
any more, and so admins would be free to assign longer prefix lengths). 
VLSM worked quite well in IPv4.

regards,
RayH