Re: Detailed review of Significance of IPv6 Interface Identifiers
Brian E Carpenter <brian.e.carpenter@gmail.com> Tue, 03 September 2013 20:23 UTC
Return-Path: <brian.e.carpenter@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F87E21F9F19 for <ipv6@ietfa.amsl.com>; Tue, 3 Sep 2013 13:23:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.603
X-Spam-Level:
X-Spam-Status: No, score=-102.603 tagged_above=-999 required=5 tests=[AWL=-0.004, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YlefeCH9QIpA for <ipv6@ietfa.amsl.com>; Tue, 3 Sep 2013 13:23:46 -0700 (PDT)
Received: from mail-pa0-x229.google.com (mail-pa0-x229.google.com [IPv6:2607:f8b0:400e:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id CAE7D21F8C93 for <6man@ietf.org>; Tue, 3 Sep 2013 13:23:45 -0700 (PDT)
Received: by mail-pa0-f41.google.com with SMTP id bj1so6920128pad.14 for <6man@ietf.org>; Tue, 03 Sep 2013 13:23:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=DT0XIZ2HqU47rEdV7L4DpY4Zi4eootPNfml/aGcKT6w=; b=F6qA8dhvdy+2GItUA+2uzWzgqKcB09Jsi0t2x65IgU0v+UmygWQD0xdIP4ax4kBMeT JVM0KQF7DcUgfp1wvsQwSF45mMzJBKAHYbj9bbVT9TtWZd4k7ymy2SWxixFstjUvCWL6 boiAu1QZ3FN0xu9tu+KIcho1/5PxLk8d9SiJFlEjbBzDpVkreTCaSy7wsp8yWRlzEt1V YYuAqUtx31qQlNHuLdOHMQP4ybgk/w503S+zPtTvK8z8JLnBv2xf2GmclVKbsbfy7/Yt ZFYFzvfMzD3CaGXQnehWzZruKsDG99XzD+VSBdyrNIUXakXuzMDPXBNRnPrh3ENtwGQj LoiA==
X-Received: by 10.66.254.170 with SMTP id aj10mr10665266pad.142.1378239822328; Tue, 03 Sep 2013 13:23:42 -0700 (PDT)
Received: from [192.168.178.20] (250.200.69.111.dynamic.snap.net.nz. [111.69.200.250]) by mx.google.com with ESMTPSA id xl3sm24346325pbb.17.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 03 Sep 2013 13:23:41 -0700 (PDT)
Message-ID: <5226454E.1070403@gmail.com>
Date: Wed, 04 Sep 2013 08:23:42 +1200
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Ray Hunter <v6ops@globis.net>
Subject: Re: Detailed review of Significance of IPv6 Interface Identifiers
References: <520B3529.80802@si6networks.com> <520BF653.8060603@gmail.com> <522309E1.7050806@globis.net> <5223EC0B.8080607@gmail.com> <5224284E.6020604@globis.net> <5224F28E.3040306@gmail.com> <5225D81F.6020009@globis.net>
In-Reply-To: <5225D81F.6020009@globis.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Cc: Fernando Gont <fgont@si6networks.com>, "6man@ietf.org" <6man@ietf.org>, draft-ietf-6man-ug@tools.ietf.org
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Tue, 03 Sep 2013 20:23:48 -0000
Ray, OK, I see your point, but that seems like too much detail to be useful for most readers. I'd be inclined to summarise it considerably. Regards Brian On 04/09/2013 00:37, Ray Hunter wrote: >> Brian E Carpenter <mailto:brian.e.carpenter@gmail.com> >> 2 September 2013 22:18 >> On 02/09/2013 17:55, Ray Hunter wrote: >>>> Brian E Carpenter <mailto:brian.e.carpenter@gmail.com> >>>> 2 September 2013 03:38 >>>> Ray, >>>> >>>>> So AFAICS the u/l restriction and uniqueness restriction is only >>>>> relevant when EUI64 is used in the context of specific LAN hardware, but >>>>> perhaps not all router interface hardware. >>>> The phrasing in the draft looks completely compatible with that to me. >>> I'm not sure what the text is trying to say though. >> Ray, are you asking for a change in the text? Please be specific. >> >> <snip> >> >>> So any IETF standard that assumes a 1:1 relationship between IID and >>> IEEE LAN hardware is heading for trouble. >> Agreed - in what way does the draft imply anything else? > I agree on the conclusion and the meaning. But the reasoning is not > clear to me, nor particularly correct. >> (The words in RFC 4291 that we are obsoleting do seem to imply >> a 1:1 relationship, but that's what the draft fixes.) > Agreed >> Brian >> > Original text: > > /However, this has not so far proved to be the case. Also, there is > evidence from the field that despite the IEEE standard [IEEE802], MAC > addresses with universal scope are sometime incorrectly assigned to > multiple MAC interfaces. Firstly, there are recurrent reports of > manufacturers assigning the same MAC address to multiple devices. > Secondly, significant re-use of the same virtual MAC address is > reported in virtual machine environments. Once transformed into IID > format (with "u" = 1) these identifiers would purport to be > universally unique but would in fact be ambiguous. This has no known > harmful effect as long as the replicated MAC addresses and IIDs are > used on different layer 2 links. If they are used on the same link, > of course there will be a problem, very likely interfering with link- > layer transmission. If not, the problem will be detected by > duplicate address detection [RFC4862] [RFC6775], but such an error > can usually only be resolved by human intervention./ > > Proposed text: > > > / > However, the expected advantages or application of interface identifiers > with universal scope have not materialised. > > There is also evidence from the field that MAC addresses are not as > unique as one might expect, where for example manufacturers have > erroneously allocated the same burned in address to multiple devices. > > Furthermore, IEEE standards and operational practices have advanced > significantly since RFC4291 was published. > > There are at least three use cases in wide-spread production where a > router or other operating system interface at layer 3 may not enjoy > direct access to LAN hardware on a 1:1 relationship so that it can > access a "burned in address" from the MAC layer to create a unique IID > per interface with universal scope (which seemed to be an underlying > assumption when RFC4291 was written): > > - use of software drivers to spoof an operating system into thinking it > is talking to hardware, when in fact no LAN hardware is present e.g. LAN > interfaces on virtual machines. Significant re-use of the same virtual > MAC address has been reported in virtual machine environments. > > - use of an intermediate NIC teaming layer or Link Aggregation Group > that takes a number of underlying layer 2 links and presents them as a > single MAC interface to the client operating systems (IEEE 802.3ad draft > v1, IEEE 802.1ax LACP, proprietary). IEEE 802.1ax states that the MAC > address of the LAG MAY be an address of one of the underlying links in > the Link Aggregation Group, but this is not limited in any way in > implementations. LACP may also add and delete links from the Link > Aggregation Group dynamically, and it would seem counterintuitive that > the associated IID, and thus the IPv6 address, had to change every time > this happened, because the whole purpose of the LAG is to shield the OS > from such low level changes. > > - "Router on a stick", or "firewall on a stick", where a specialist > device such as an inter-VLAN router or firewall is connected to a layer > 2 switch fabric via a single high speed interface, and multiple sub > interfaces are defined at Layer 3, all of which share a common layer 2 > MAC address. These sub interfaces may be transported as a VLAN trunk > (e.g. 802.1Q) into the layer 2 switch fabric, where the individual VLANs > may then be presented on different hardware interfaces, such that the > device may appear to source traffic on multiple physical interfaces > using the same layer 2 address. > > Once transformed into IID > format (with "u" = 1) these identifiers would purport to be > universally unique but would in fact be ambiguous. This has no known > harmful effect as long as the replicated MAC addresses and IIDs are > used on different layer 2 links. If they are used on the same link, > of course there will be a problem, very likely interfering with link- > layer transmission. If not, the problem will be detected by > duplicate address detection [RFC4862] [RFC6775], but such an error > can usually only be resolved by human intervention. > / > > > > > Does that help? >> ------------------------------------------------------------------------ > >
- Detailed review of Significance of IPv6 Interface… Fernando Gont
- Re: Detailed review of Significance of IPv6 Inter… Brian E Carpenter
- Re: Detailed review of Significance of IPv6 Inter… Fred Baker (fred)
- Re: Detailed review of Significance of IPv6 Inter… Brian E Carpenter
- Re: Detailed review of Significance of IPv6 Inter… Randy Bush
- Re: Re: Detailed review of Significance of IPv6 I… Ray Hunter
- Re: Detailed review of Significance of IPv6 Inter… Brian E Carpenter
- Re: Detailed review of Significance of IPv6 Inter… Ray Hunter
- Re: Detailed review of Significance of IPv6 Inter… Brian E Carpenter
- Re: Detailed review of Significance of IPv6 Inter… Ray Hunter
- Re: Detailed review of Significance of IPv6 Inter… Brian E Carpenter
- Re: Detailed review of Significance of IPv6 Inter… Ran Atkinson
- Re: Detailed review of Significance of IPv6 Inter… RJ Atkinson
- Re: Detailed review of Significance of IPv6 Inter… Brian E Carpenter
- Re: Detailed review of Significance of IPv6 Inter… Brian E Carpenter
- Re: Detailed review of Significance of IPv6 Inter… Ray Hunter
- Re: Detailed review of Significance of IPv6 Inter… Brian E Carpenter