Re: draft-gont-6man-managing-privacy-extensions-00.txt

Mark Smith <ipng@69706e6720323030352d30312d31340a.nosense.org> Fri, 25 March 2011 07:20 UTC

Return-Path: <ipng@69706e6720323030352d30312d31340a.nosense.org>
X-Original-To: ipv6@core3.amsl.com
Delivered-To: ipv6@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 236973A696C for <ipv6@core3.amsl.com>; Fri, 25 Mar 2011 00:20:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.575
X-Spam-Level:
X-Spam-Status: No, score=-1.575 tagged_above=-999 required=5 tests=[AWL=0.320, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ckUBvOeRWxdE for <ipv6@core3.amsl.com>; Fri, 25 Mar 2011 00:20:01 -0700 (PDT)
Received: from smtp1.adam.net.au (smtp1.adam.net.au [202.136.110.253]) by core3.amsl.com (Postfix) with ESMTP id B84863A696A for <ipv6@ietf.org>; Fri, 25 Mar 2011 00:20:00 -0700 (PDT)
Received: from 182-239-157-177.ip.adam.com.au ([182.239.157.177] helo=opy.nosense.org) by smtp1.adam.net.au with esmtp (Exim 4.63) (envelope-from <ipng@69706e6720323030352d30312d31340a.nosense.org>) id 1Q31Ke-00043l-IB; Fri, 25 Mar 2011 17:51:16 +1030
Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id E990E530DB; Fri, 25 Mar 2011 17:51:15 +1030 (CST)
Date: Fri, 25 Mar 2011 17:51:15 +1030
From: Mark Smith <ipng@69706e6720323030352d30312d31340a.nosense.org>
To: Fernando Gont <fernando@gont.com.ar>
Subject: Re: draft-gont-6man-managing-privacy-extensions-00.txt
Message-ID: <20110325175115.67f6e91e@opy.nosense.org>
In-Reply-To: <4D8C1A78.4010505@gont.com.ar>
References: <7111FC5F-BC3F-4242-9C3F-037E79894749@gmail.com> <alpine.DEB.1.10.1103091212570.7942@uplift.swm.pp.se> <4D7B5914.6090000@gont.com.ar> <4D80EAAF.6010509@hp.com> <4D8C1A78.4010505@gont.com.ar>
X-Mailer: Claws Mail 3.7.8 (GTK+ 2.22.1; x86_64-unknown-linux-gnu)
X-Location: Lower Mitcham, South Australia, 5062
Mime-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Cc: Brian Haley <brian.haley@hp.com>, ipv6@ietf.org, Ran Atkinson <ran.atkinson@gmail.com>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 25 Mar 2011 07:20:02 -0000

On Fri, 25 Mar 2011 01:30:48 -0300
Fernando Gont <fernando@gont.com.ar> wrote:

> On 16/03/2011 01:51 p.m., Brian Haley wrote:
> 
> > I have an almost off-topic comment, but since I've seen no mention of it
> > in any of these privacy threads...
> > 
> > You have to assume in a large data center that almost every MAC address you
> > encounter is going to be randomly generated.  
> 
> Are they actually random? i.e., I'm curious about the algorithm used for
> generating the Interface IDs.
> 

Here's the routine typically used under Linux to generate these types
of addresses -

include/linux/etherdevice.h

/**
 * random_ether_addr - Generate software assigned random Ethernet
address
 * @addr: Pointer to a six-byte array containing the Ethernet address
 *
 * Generate a random Ethernet address (MAC) that is not multicast
 * and has the local assigned bit set.
 */
static inline void random_ether_addr(u8 *addr)
{
        get_random_bytes (addr, ETH_ALEN);
        addr [0] &= 0xfe;       /* clear multicast bit */
        addr [0] |= 0x02;       /* set local assignment bit (IEEE802) */
}



> 
> > This is because there are
> > *lots* of virtual machines out there, and the density of them is increasing
> > exponentially.  Their MACs could change daily as they are deployed and
> > decommissioned, but from their perspective their MAC is hardware-based.
> > I know you have this as a "SHOULD" requirement, but figured I should mention
> > it since it's one of those places where this bit will be completely ignored.
> 
> From the point of view of the VMs, they would still be using Modified
> EUI-64 Interface Identifiers. This is not that different from the case
> in which the admin sets the MAC address of an interface to some value
> that he wants (other than the *real* address of the interface). IMHO,
> this is out-of-scope for this document.
> 
> Thanks!
> 
> Best regards,
> -- 
> Fernando Gont
> e-mail: fernando@gont.com.ar || fgont@acm.org
> PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
> 
> 
> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------