IETF Logo Mail Archive

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

James M Keller <jmkeller@houseofzen.org> Wed, 17 October 2012 12:47 UTC

Return-Path: <jmkeller@houseofzen.org>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBB8821F865B for <v6ops@ietfa.amsl.com>; Wed, 17 Oct 2012 05:47:11 -0700 (PDT)
X-Quarantine-ID: <x-41+dy3nscR>
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER SECTION, Improper folded header field made up entirely of whitespace (char 20 hex): X-Spam_report: ...seofzen.org for details.\n \n Content previ[...]
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x-41+dy3nscR for <v6ops@ietfa.amsl.com>; Wed, 17 Oct 2012 05:47:11 -0700 (PDT)
Received: from omega.houseofzen.org (omega.houseofzen.org [96.126.106.162]) by ietfa.amsl.com (Postfix) with ESMTP id 4A87621F862B for <v6ops@ietf.org>; Wed, 17 Oct 2012 05:47:11 -0700 (PDT)
Received: from localhost ([127.0.0.1]) by omega.houseofzen.org with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from <jmkeller@houseofzen.org>) id 1TOT1h-0007CR-3h; Wed, 17 Oct 2012 08:47:09 -0400
Message-ID: <507EA8CB.40702@houseofzen.org>
Date: Wed, 17 Oct 2012 08:47:07 -0400
From: James M Keller <jmkeller@houseofzen.org>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1
MIME-Version: 1.0
To: Mark Smith <markzzzsmith@yahoo.com.au>
References: <201210161245.q9GCj0q26472@ftpeng-update.cisco.com> <1350417296.76189.YahooMailNeo@web32502.mail.mud.yahoo.com>
In-Reply-To: <1350417296.76189.YahooMailNeo@web32502.mail.mud.yahoo.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Spam_score: -2.9
X-Spam_score_int: -28
X-Spam_bar: --
X-Spam_report: Spam detection software, running on the system "omega.houseofzen.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see postmaster@houseofzen.org for details. Content preview: 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. [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000]
Cc: v6ops@ietf.org
Subject: Re: [v6ops] new draft: draft-gont-v6ops-slaac-issues-with-duplicate-macs
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/v6ops>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 17 Oct 2012 12:47:12 -0000

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

v2.23.0 | Report a Bug | By Email