Subject: [v6ops] new draft: draft-gont-v6ops-slaac-issues-with-duplicate-macs

From: <[email-masked]>
Date: Tue, 16 Oct 2012 05:45:00 -0700 (PDT)

A new draft has been posted, at http://tools.ietf.org/html/draft-gont-v6ops-slaac-issues-with-duplicate-macs. Please take a look at it and comment.

---

From: Mark Smith <[email-masked]>
Date: Tue, 16 Oct 2012 12:54:56 -0700 (PDT)

Hi,

----- Original Message -----
> From: "[email-masked]" <[email-masked]>
> To: [email-masked]
> Cc: [email-masked]
> Sent: Tuesday, 16 October 2012 11:45 PM
> Subject: [v6ops] new draft: draft-gont-v6ops-slaac-issues-with-duplicate-macs
> 
> 
> A new draft has been posted, at 
> http://tools.ietf.org/html/draft-gont-v6ops-slaac-issues-with-duplicate-macs. 
> Please take a look at it and comment.
> _______________________________________________

I haven't read it thoroughly, however a few general comments to get the

ball rolling:

- duplicate MAC addresses (by hardware vendors) are generally much rarer
than the draft suggests. I haven't ever come across them in 20 or so
years of dealing with ethernet, and I've only heard very few first hand
accounts of them being encountered. From what I've heard, they've been
accidents by vendors, e.g. server bios installs at the factory that didn't
increment MAC addresses on each new install.

- I think it would be worth both pointing out that the required functional
"scope of uniqueness" for addresses is only the link they're attached
to. Global uniqueness of addresses is for operational convenience,
allowing them to be plugged into a link without having to set the
address. That required scope of uniqueness reduces the likelihood of
address collisions, in particular the case of virtual machines that use
random MAC addresses. According to this player (also a interesting read
about addressing principles in general), MAC addresses were originally
intended to be per-host rather than per-interface identifiers and therefore
the same MAC address would be used on all different links the host was
attached to. I think the per-interface MAC addresses model we've ended
up with evolved from add-in ethernet cards having individual addresses.

"48-bit Absolute Internet and Ethernet Host Numbers", Yogan K. Dalal and
Robert S. Printis
http://ethernethistory.typepad.com/papers/HostNumbers.pdf

- In the broadband ADSL networks I'm familiar with, MAC address
translation (i.e. 1:1 NAT at layer 2) is enabled on the DSL port facing
the customer. Unfortunately the same sorts of NAT related addresses within
the payload issues show up at layer 2 - these DSLAMs will translate MAC
addresses in PPPoE (either that it isn't required, which I can't recall
at the moment) and IPv4, however they don't "support" IPv6 because
they can't translate MAC addresses in IPv6 fields/payloads e.g. ND NS/NA.
Apparently it isn't possible to upgrade them to do this because they don't have
the hardware resources. I see quite a lot of value in coming up with
a solution to detect duplicate MAC addresses in this scenario, rather
than translating them "away", and disabling all or the most recent DSL
port with the duplicate address (i.e. a tack hammer rather than a sledge
hammer solution). However I think that would most likely be something
the ANCP working group would look at, rather than this one.

- Assuming that the IPv6 duplicate address issue can be resolved using
multicast only link layer traffic, layer 2 is still broken for unicast
traffic for the nodes with duplicate layer 2 addresses, as the layer
2 forwarding devices won't be able to cope with duplicate layer 2
addresses. I wonder if the only possible and effective way to properly
solve this issue is to solve it where it is actually caused, at layer 2.

Regards,
Mark.

---

From: James M Keller <[email-masked]>
Date: Wed, 17 Oct 2012 08:47:07 -0400

On 10/16/2012 3:54 PM, Mark Smith wrote:
> I haven't read it thoroughly, however a few general comments to get
> the ball rolling: - duplicate MAC addresses (by hardware vendors) are
> generally much rarer than the draft suggests. I haven't ever come
> across them in 20 or so years of dealing with ethernet, and I've only
> heard very few first hand accounts of them being encountered. From
> what I've heard, they've been accidents by vendors, e.g. server bios
> installs at the factory that didn't increment MAC addresses on each
> new install.

This has become more of an issue of late with virtual hosting systems
generating MAC addresses for VM NICs and then moving images between
environments and ending up with a collision vs physical hardware
burned-in-addresses.

-- 
---
James M Keller

---

From: MAWATARI Masataka <[email-masked]>
Date: Wed, 31 Oct 2012 14:26:05 +0900

Greetings,

I have read through your document.

Layer 2 IXs are dealing with same issues on IPv6 IX segment.

In regard to link local address, both manual configuration routers
and auto configuration (SLAAC) routers are connecting into one
ethernet fabric of IX.  Fortunately duplication do not occur so far.

This document might be worthwhile subject for IPv6 IX.

Kind Regards,
Masataka MAWATARI

* On Tue, 16 Oct 2012 05:45:00 -0700 (PDT)
* <[email-masked]> wrote:

> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: Mark Smith <[email-masked]>
Date: Wed, 31 Oct 2012 01:14:30 -0700 (PDT)

Hi,

----- Original Message -----
> From: MAWATARI Masataka <[email-masked]>
> To: [email-masked]
> Sent: Wednesday, 31 October 2012 4:26 PM
> Subject: Re: [v6ops] new draft: draft-gont-v6ops-slaac-issues-with-duplicate-macs
> 
>G reetings,
> 
> 

How are the IX going to resolve the layer 2 address duplication causing

layer 2 unicast to fail? MAC forced forwarding or something similar?

---

From: Mattia Rossi <[email-masked]>
Date: Wed, 31 Oct 2012 14:11:36 +0100

> environments and ending up with a collision vs physical hardware
I can agree on that, MAC duplication happens quite often with 
duplication of VM's.
Although you'd probably experience Ethernet issues before you come to 
the IPv6 SLAAC issues in most of those situations. Depends on how the 
network's segmented of course.
See section 5.4.5 in RFC 4862:

"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. "

So this is already in contrast with the draft.

Additionally I disagree on the point that RFC 4862 doesn't say what to 
do on DAD, as it states:

5.4 Duplicate Address Detection
[snip]
If the address is derived from an interface identifier, a new identifier 
will need to be assigned to the interface, or all IP addresses for the 
interface will need to be manually configured.
[snap]

It says that a new identifier needs to be assigned. Doesn't say how, but 
it does say it has to.

So, I think the behaviour of DAD described in this draft is actually 
correct. If this poses a problem we should think about rewriting section 
5.4 of RFC 4862 and update the RFC, otherwise we end up with two quite 
contrasting standards.

Mat

---

From: MAWATARI Masataka <[email-masked]>
Date: Thu, 01 Nov 2012 10:26:01 +0900

Hi Mark-san,

If MAC address duplication occured on IX segment, both of IPv4 and
IPv6 would been destroyed.
I think that IX people do not have the definitive solution when it
happens.  First of all they will inquire of router vendors.  It will
not be technical solution depending on the cause.

Kind Regards,
Masataka MAWATARI

* On Wed, 31 Oct 2012 01:14:30 -0700 (PDT)
* Mark Smith <[email-masked]> wrote:

> > ethernet fabric of IX.? Fortunately duplication do not occur so far.
> >?
>