[Autoconf] Forgot one [Was: RFC 5889

Erik Nordmark <erik.nordmark@oracle.com> Thu, 29 July 2010 12:07 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 19F853A69A2 for <autoconf@core3.amsl.com>; Thu, 29 Jul 2010 05:07:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.308
X-Spam-Level:
X-Spam-Status: No, score=-6.308 tagged_above=-999 required=5 tests=[AWL=0.291, 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 I5ILCfjuHO1I for <autoconf@core3.amsl.com>; Thu, 29 Jul 2010 05:06:59 -0700 (PDT)
Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id E967F3A68B2 for <autoconf@ietf.org>; Thu, 29 Jul 2010 05:06:58 -0700 (PDT)
Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o6TC7LLp020447 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 29 Jul 2010 12:07:22 GMT
Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o6TC0uE9007042; Thu, 29 Jul 2010 12:07:20 GMT
Received: from abhmt005.oracle.com by acsmt355.oracle.com with ESMTP id 467566471280405233; Thu, 29 Jul 2010 05:07: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:07:12 -0700
Message-ID: <4C516EEE.8080504@oracle.com>
Date: Thu, 29 Jul 2010 05:07:10 -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> <4C516E75.2010405@oracle.com>
In-Reply-To: <4C516E75.2010405@oracle.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Source-IP: acsmt354.oracle.com [141.146.40.154]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090205.4C516EF8.028F:SCFMA4539814,ss=1,fgs=0
Cc: "autoconf@ietf.org" <autoconf@ietf.org>
Subject: [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: Thu, 29 Jul 2010 12:07:03 -0000

[I lost one of the suggested edits. This is the complete list.]

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.

In section 6.1
FROM
    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.
TO
    o  Routers often need to be reachable at a global address for
       management purposes.

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

Also in section 6.1
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.

---