Re: [Autoconf] Forgot one [Was: RFC 5889

"Dearlove, Christopher (UK)" <Chris.Dearlove@baesystems.com> Fri, 30 July 2010 09:19 UTC

Return-Path: <Chris.Dearlove@baesystems.com>
X-Original-To: autoconf@core3.amsl.com
Delivered-To: autoconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC7E028C2A9 for <autoconf@core3.amsl.com>; Fri, 30 Jul 2010 02:19:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.823
X-Spam-Level:
X-Spam-Status: No, score=-6.823 tagged_above=-999 required=5 tests=[AWL=-0.224, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 F76nH6ruy2Df for <autoconf@core3.amsl.com>; Fri, 30 Jul 2010 02:19:09 -0700 (PDT)
Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by core3.amsl.com (Postfix) with ESMTP id 5433928C24E for <autoconf@ietf.org>; Fri, 30 Jul 2010 02:19:09 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.55,286,1278284400"; d="scan'208";a="79307092"
Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 30 Jul 2010 10:19:33 +0100
Received: from glkms1102.GREENLNK.NET (glkms1102.greenlnk.net [10.108.36.193]) by baemasodc004.greenlnk.net (Switch-3.4.3/Switch-3.4.3) with ESMTP id o6U9JXoY019452; Fri, 30 Jul 2010 10:19:33 +0100
Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1102.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.3959); Fri, 30 Jul 2010 10:19:33 +0100
x-mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Date: Fri, 30 Jul 2010 10:19:30 +0100
Message-ID: <ABE739C5ADAC9A41ACCC72DF366B719D034C5B98@GLKMS2100.GREENLNK.NET>
In-Reply-To: <4C528979.7010006@oracle.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
thread-topic: [Autoconf] Forgot one [Was: RFC 5889
thread-index: Acsvv0oGDuDl1unJQ52kYHRub+aBagABaoag
References: <4C2A6BB7.1000900@piuha.net><4C2CFADD.3040909@piuha.net> <4C378C29.2040302@oracle.com><4C4706D8.5040904@piuha.net> <4C516AC9.8030803@oracle.com><4C516E75.2010405@oracle.com> <4C516EEE.8080504@oracle.com> <4C528979.7010006@oracle.com>
From: "Dearlove, Christopher (UK)" <Chris.Dearlove@baesystems.com>
To: "Erik Nordmark" <erik.nordmark@oracle.com>, <autoconf@ietf.org>
X-OriginalArrivalTime: 30 Jul 2010 09:19:33.0053 (UTC) FILETIME=[5246D6D0:01CB2FC8]
Subject: Re: [Autoconf] Forgot one [Was: RFC 5889
X-BeenThere: autoconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/autoconf>
List-Post: <mailto:autoconf@ietf.org>
List-Help: <mailto:autoconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 30 Jul 2010 09:19:10 -0000

I was trying to work out if this left the link local address references
coherent or not. These are, I believe, all the paragraphs that discuss
them. I think the first is irrelevant to this discussion, but I've
included it for completeness.

OLD:

   Note that routers may ultimately need additional IP prefixes for the
   diverse applications that could run directly on the routers
   themselves, or for assignment to attached hosts or networks.  For
   IPv6, these addresses may be global [RFC3587], Unique-Local [RFC4193]
   or Link-Local [RFC4291].  For IPv4, the addresses may be global
   (i.e., public) or private [RFC1918].  In general, global scope is
   desired over local scope, though it is understood that this may not
   always be achievable via automatic configuration mechanisms.  In this
   document however, automatic configuration of the prefixes used for
   general applications is considered as a problem that is separable
   from that of automatic configuration of addresses and prefixes
   necessary for routing protocols to function.  This document thus
   focuses on the latter: the type of IP address and subnet mask
   configuration necessary for routing protocols and data packet
   forwarding to function.

OLD:

   Note that while link-local addresses are assumed to be "on link", the
   utility of link-local addresses is limited as described in Section 6.

NOTE: The next four paragraphs (all but the last) are consecutive.

OLD:

   Note that while an IPv6 link-local address is assigned to each
   interface as per [RFC4291], in general link-local addresses are of
   limited utility on links with undetermined connectivity, as
   connectivity to neighbors may be constantly changing.  The known
   limitations are:

NEW:

   o  In general there is no mechanism to ensure that IPv6 link-local
      addresses are unique across multiple links, however link-local
      addresses using an IID that are of the modified EUI-64 form are
      globally unique. Thus if link-local addresses are used to reliably
      identify routers then they must be of the modified EUI-64 form.
OLD:

   o  Routers cannot forward any packets with link-local source or
      destination addresses to other links (as per [RFC4291]) while most
      of the time, routers need to be able to forward packets to/from
      different links.

   Therefore, autoconfiguration solutions should be encouraged to
   primarily focus on configuring IP addresses that are not IPv6 link-
   local.

OLD:

   Note that the use of IPv4 link-local addresses [RFC3927] in this
   context should be discouraged for most applications, as the
   limitations outlined in Section 6.1 for IPv6 link-local addresses
   also concern IPv4 link-local addresses.  These limitations are
   further exacerbated by the smaller pool of IPv4 link-local addresses
   to choose from and thus increased reliance on Duplicate Address
   Detection (DAD).

The text before the bullet points indicates that they are about
"The known weaknesses are". The recommendation "Thus if link-local
addresses are used to reliably identify routers then they must be of
the modified EUI-64 form." doesn't really fit that, and also is a bad
fit with the primary focus referred to after the bullet points. What is
appropriate to say, that EUI-64 addresses are globally unique is said in
the previous sentence. I think the document would be more internally
consistent, and not adding a change in recommendations, if that sentence
were deleted from the new paragraph, which would be left as:

NEW:

   o  In general there is no mechanism to ensure that IPv6 link-local
      addresses are unique across multiple links, however link-local
      addresses using an IID that are of the modified EUI-64 form are
      globally unique.

(Personally, I'd modify that a little further, to:

   o  In general there is no mechanism to ensure that IPv6 link-local
      addresses are unique across multiple links, however link-local
      addresses using an IID that are of the modified EUI-64 form
      ahould be globally unique.

but this is not the point of this email.)

-- 
Christopher Dearlove
Technology Leader, Communications Group
Networks, Security and Information Systems Department
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194  Fax: +44 1245 242124

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87,
Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************