Re: [Autoconf] RFC 5889

Erik Nordmark <erik.nordmark@oracle.com> Thu, 29 July 2010 12:04 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 7ABA928C142 for <autoconf@core3.amsl.com>; Thu, 29 Jul 2010 05:04:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.296
X-Spam-Level:
X-Spam-Status: No, score=-6.296 tagged_above=-999 required=5 tests=[AWL=0.303, 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 2MkXB7PkQ8X3 for <autoconf@core3.amsl.com>; Thu, 29 Jul 2010 05:04:56 -0700 (PDT)
Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 6AD2F3A6836 for <autoconf@ietf.org>; Thu, 29 Jul 2010 05:04:56 -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 o6TC5I86016197 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 29 Jul 2010 12:05:20 GMT
Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o6TAo01V022000; Thu, 29 Jul 2010 12:05:18 GMT
Received: from abhmt021.oracle.com by acsmt353.oracle.com with ESMTP id 467560901280405113; Thu, 29 Jul 2010 05:05:13 -0700
Received: from [10.7.251.248] (/10.7.251.248) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 29 Jul 2010 05:05:12 -0700
Message-ID: <4C516E75.2010405@oracle.com>
Date: Thu, 29 Jul 2010 05:05:09 -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: Jari Arkko <jari.arkko@piuha.net>
References: <4C2A6BB7.1000900@piuha.net> <4C2CFADD.3040909@piuha.net> <4C378C29.2040302@oracle.com> <4C4706D8.5040904@piuha.net> <4C516AC9.8030803@oracle.com>
In-Reply-To: <4C516AC9.8030803@oracle.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Source-IP: acsmt355.oracle.com [141.146.40.155]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090203.4C516E7E.0123:SCFMA4539814,ss=1,fgs=0
Cc: "autoconf@ietf.org" <autoconf@ietf.org>
Subject: Re: [Autoconf] 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: Thu, 29 Jul 2010 12:04:57 -0000

I talked to Jari about this earlier in the week, and in the interest of 
trying to close this issue I've gathered together the earlier suggested 
changes, added the suggested title change, and included the edits I 
suggested a few minutes ago.

Note that I'm not particularly wedded to the title change.

    Erik

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

In section 4
REMOVE
    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.

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 is of the modified EUI-64 form is
     globally unique. Thus if link-local addresses are used to reliably
     identify routers then they must be of the modified EUI-64 form.

OLD:
  Therefore, autoconfiguration solutions should be encouraged to
  primarily focus on configuring IP addresses that are not IPv6 link-
  local.
NEW:
  Therefore, an autoconfiguration solution which provides a mechanism for
  assigning addresses with a wider scope than IPv6 link-local alone will
  be more generally useful than one that does not.

---