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

Erik Nordmark <erik.nordmark@oracle.com> Fri, 30 July 2010 08:14 UTC

Return-Path: <erik.nordmark@oracle.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 0C89B3A6A76 for <autoconf@core3.amsl.com>; Fri, 30 Jul 2010 01:14:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.338
X-Spam-Level:
X-Spam-Status: No, score=-6.338 tagged_above=-999 required=5 tests=[AWL=0.261, 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 4pX3K4aCt5Io for <autoconf@core3.amsl.com>; Fri, 30 Jul 2010 01:14:14 -0700 (PDT)
Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 469173A69BD for <autoconf@ietf.org>; Fri, 30 Jul 2010 01:14:14 -0700 (PDT)
Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o6U8Ebpj031180 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <autoconf@ietf.org>; Fri, 30 Jul 2010 08:14:38 GMT
Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o6U6mNnc017917 for <autoconf@ietf.org>; Fri, 30 Jul 2010 08:14:34 GMT
Received: from abhmt020.oracle.com by acsmt355.oracle.com with ESMTP id 451609581280477567; Fri, 30 Jul 2010 01:12:47 -0700
Received: from [10.7.251.248] (/10.7.251.248) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 30 Jul 2010 01:12:47 -0700
Message-ID: <4C528979.7010006@oracle.com>
Date: Fri, 30 Jul 2010 01:12:41 -0700
From: Erik Nordmark <erik.nordmark@oracle.com>
User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.9) Gecko/20100607 Lightning/1.0b1 Thunderbird/3.0.4
MIME-Version: 1.0
To: autoconf@ietf.org
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>
In-Reply-To: <4C516EEE.8080504@oracle.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Source-IP: acsmt353.oracle.com [141.146.40.153]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090204.4C5289EC.0022:SCFMA4539814,ss=1,fgs=0
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 08:14:18 -0000

Please double-check this, but I think it has all the list of changes 
that Jari said verbally.

    Erik

----

Change the title
FROM
                  IP Addressing Model in Ad Hoc Networks
TO
                  A Router Addressing Model in Ad Hoc Networks

In section 5:
OLD:
  Routing protocols running on a router may exhibit different
  requirements for uniqueness of interface addresses; some have no such
  requirements, others have requirements ranging from local uniqueness
  only, to uniqueness within, at least, the routing domain (as defined
  in [RFC1136]).

  Configuring an IP address that is unique within the routing domain
  satisfies the less stringent uniqueness requirements of local
  uniqueness, while also enabling protocols which have the most
  stringent requirements of uniqueness within the routing domain.  This
  suggests the following principle:

  o  an IP address assigned to an interface that connects to a link
     with undetermined connectivity properties should be unique, at
     least within the routing domain.
NEW:
  Routing protocols running on a router may exhibit different
  requirements for uniqueness of interface addresses; some have no such
  requirements, others have requirements ranging from local uniqueness
  only, to uniqueness within, at least, the routing domain (as defined
  in [RFC1136]).
  Routing protocols that do not require unique IP addresses within the
  routing domain utilize a separate unique identifier within the routing
  protocol itself; such identifiers could be based on factory assignment
  or configuration.

  Nevertheless, configuring an IP address that is unique within the routing
  domain satisfies the less stringent uniqueness requirements of local
  uniqueness, while also enabling protocols which have the most
  stringent requirements of uniqueness within the routing domain.  As a 
result, the following principle allows for IP autoconfiguration to
  apply to the widest array of routing protocols:

  o  an IP address assigned to an interface that connects to a link
     with undetermined connectivity properties should be unique, at
     least within the routing domain.

In Section 6.1:
OLD:
  o  There is no mechanism to ensure that IPv6 link-local addresses are
     unique across multiple links, hence they cannot be used to
     reliably identify routers (it is often desirable to identify a
     router with an IP address).
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.

---