Re: [Autoconf] RFC 5889 (Was: Call for comments to a new AUTOCONF charter proposal)

Erik Nordmark <erik.nordmark@oracle.com> Fri, 09 July 2010 20:53 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 729903A68C1 for <autoconf@core3.amsl.com>; Fri, 9 Jul 2010 13:53:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.45
X-Spam-Level:
X-Spam-Status: No, score=-6.45 tagged_above=-999 required=5 tests=[AWL=0.149, 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 g6HdD0R35f8F for <autoconf@core3.amsl.com>; Fri, 9 Jul 2010 13:53:11 -0700 (PDT)
Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 0A5A83A67EE for <autoconf@ietf.org>; Fri, 9 Jul 2010 13:53:10 -0700 (PDT)
Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o69KrEFO025711 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 9 Jul 2010 20:53:15 GMT
Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o69EKl1q023737; Fri, 9 Jul 2010 20:53:13 GMT
Received: from abhmt016.oracle.com by acsmt355.oracle.com with ESMTP id 414060291278708779; Fri, 09 Jul 2010 13:52:59 -0700
Received: from [10.7.251.248] (/10.7.251.248) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 09 Jul 2010 13:52:58 -0700
Message-ID: <4C378C29.2040302@oracle.com>
Date: Fri, 09 Jul 2010 13:52:57 -0700
From: Erik Nordmark <erik.nordmark@oracle.com>
User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.10) Gecko/20100621 Lightning/1.0b1 Thunderbird/3.0.5
MIME-Version: 1.0
To: Jari Arkko <jari.arkko@piuha.net>
References: <4C2A6BB7.1000900@piuha.net> <4C2CFADD.3040909@piuha.net>
In-Reply-To: <4C2CFADD.3040909@piuha.net>
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.4C378C3A.006F:SCFMA4539814,ss=1,fgs=0
Cc: "autoconf@ietf.org" <autoconf@ietf.org>
Subject: Re: [Autoconf] RFC 5889 (Was: Call for comments to a new AUTOCONF charter proposal)
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, 09 Jul 2010 20:53:12 -0000

On 07/ 1/10 01:30 PM, Jari Arkko wrote:

> We have not had a substantial discussion of the proposal yet with Erik
> -- he has acknowledged that he's seen the proposal but has been too busy
> at day job to do a detailed review. He has promised to provide feedback
> in the next few days. In the meantime I wanted to bring the issue up
> with the working group so that you know what is going on. Ultimately, it
> is your call to make changes. No single person's opinion can change the
> document at this stage, be it Erik, the ADs, or the authors. That being
> said, we do try to fix problems if there are some.
>
> In this particular issue, I personally believe that despite's Erik's
> concern the document as approved was factually correct. However, at the
> same time I think that the document could have been clearer about what
> it is saying about routing protocols and what it is not. That was the
> basis of my suggested edit. I think this edit, if agreed, is somewhere
> between an editorial and technical change and something that can be done
> in AUTH48 with the working group's acceptance. In other words, it is not
> necessary to redo the approval process.

I do think the document is misleading and confused.
That starts with the discrepancy between the title
	IP Addressing Model in Ad Hoc Networks
and the abstract, which limits itself to configuring IP addresses for 
router interfaces and not for the whole of an ad hoc network.

I was under the impression that the WG was looking at a document that 
addressed the scope that is implied by the title.

I find the more limited scope odd, since we existing routing protocols 
like IS-IS that can operate (exchange routing information, forward IP 
packets) without any IP addresses configured on the routers' interfaces. 
(Even though a router needs some IP addresses to be manageable with SNMP 
and to be able to send ICMP errors.)

The implied conclusion that IPv6-link local addresses are undesirable 
for router's interfaces is even odder, since RIPng and OSPFv3 both 
require routers to use IPv6 link-local addresses for the routing 
protocol exchanges.

The document seems to assume that the uniqueness scope of link-local 
addresses is limited to a single link, when it is the routability scope 
which is limited to the link. There is a class of link-local addresses 
with U=1 (those derived from EUI-64) that are globally unique - but 
still is not routable outside of the link.

The result is that the document can easily be construed as discouraging 
approaches that make a lot of sense, which seems counterproductive.
An example of such an approach is a routing protocol which uses IEEE MAC 
addresses as router ids, assigns IPv6 link-local addresses to the 
router's interfaces and uses that in the routing protocol exchanges, and 
configures global addresses for use by applications.


I think the exercise here is to try to correct some minor wording in the 
recommendations in the document, but even if we succeed in doing so the 
premises expressed in the introduction and elsewhere will be a bit odd, 
since they focus on the configuration of router interfaces and not on 
the addressing model of the Ad Hoc network.

> 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 that must also be configured in some manner.

With IS-IS one doesn't configure the router id; it is a factory assigned 
MAC address. Such an approach is perfectly valid for Ad Hoc routing 
protocols as well.

Note that a router (as opposed to routing protocol) require IP addresses 
to be managable and to be able to send ICMP errors. But the above 
paragraph is trying to derive recommendations from the latter.

I suggest the wording
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.
>
> And 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 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, should this be necessary by the routing
> protocol for which IP address autoconfiguration is being provided.

According to RFC 4291 EUI-64-based interface identifiers have global 
scope when created from a universal token. A result of this is that 
link-local addresses formed from such interface identifiers have global 
scope. Hence the "no mechanism" above seems factually incorrect.

Thus I think section 6.1 needs to differentiate between the global and 
local scope for the interface identifiers for it to make sense.
Should I suggest replacement text?

This paragraph seems like a non seqiteur:
    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.
Clearly the application traffic needs to use non-link-local addresses to 
work across multiple links, but that has nothing to do with what IP 
addresses are configured on the interfaces of routers as we see from the 
requirement for RIPng and OSPFv3 to use IPv6 link-locals on router 
interfaces.

Instead the issue is that link-local addresses are not useful for 
applications *other than routing protocols*, and that is the motivation 
for the subsequent paragraph:

> 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.

That misses the point. It is the motivation for this recommendation 
which is confused and misleading, and not the conclusion itself. The 
motivation is that applications (other than routing protocols) most 
likely desire to communicate across the whole Ad Hoc network, if not 
across the whole Internet, which makes link-local addresses of limited use.

But they can still be quite useful as for the purposes of routing 
protocols, and bootstrapping address autoconfiguration protocols.

This confusion is related to the odd scope mismatch between the title 
and the abstract. Clearly we want to be able to autoconfigure 
non-link-local addresses for applications, but the abstract limits the 
scope of the document to IP addressed assigned to router interfaces, and 
there link-local address might be just fine.

Note that the last sentence in the first paragraph in section 4 is also 
misleading (I'm assuming that paragraph is about configuring router 
interfaces and not host interfaces) in saying
    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.
when in fact using link-local address, in particular those based on 
global scope interface identifiers, might be just fine for router 
interfaces.

    Erik