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

Jari Arkko <jari.arkko@piuha.net> Wed, 21 July 2010 14:40 UTC

Return-Path: <jari.arkko@piuha.net>
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 979463A6826 for <autoconf@core3.amsl.com>; Wed, 21 Jul 2010 07:40:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.301
X-Spam-Level:
X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[AWL=0.298, BAYES_00=-2.599]
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 xkmEQDs9-9vL for <autoconf@core3.amsl.com>; Wed, 21 Jul 2010 07:40:12 -0700 (PDT)
Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 4F8E73A67D1 for <autoconf@ietf.org>; Wed, 21 Jul 2010 07:40:11 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id D38FF2CCCF; Wed, 21 Jul 2010 17:40:26 +0300 (EEST)
X-Virus-Scanned: amavisd-new at piuha.net
Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bwqdnUtE3i05; Wed, 21 Jul 2010 17:40:26 +0300 (EEST)
Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id E8DBB2CC9A; Wed, 21 Jul 2010 17:40:25 +0300 (EEST)
Message-ID: <4C4706D8.5040904@piuha.net>
Date: Wed, 21 Jul 2010 17:40:24 +0300
From: Jari Arkko <jari.arkko@piuha.net>
User-Agent: Thunderbird 2.0.0.24 (X11/20100411)
MIME-Version: 1.0
To: Erik Nordmark <erik.nordmark@oracle.com>
References: <4C2A6BB7.1000900@piuha.net> <4C2CFADD.3040909@piuha.net> <4C378C29.2040302@oracle.com>
In-Reply-To: <4C378C29.2040302@oracle.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
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: Wed, 21 Jul 2010 14:40:13 -0000

Erik,

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

OK, though I suspect that Section 1 paragraph 3 and Section 6.1 bullet 2 
still says almost everything there is to say about the rest, too. 
Nevertheless, there is a proposal for title change. Perhaps a critical 
issue was not making it clear enough in the document that its not just 
about router addressing, but also just _a_ model, not _the_ model. I 
asked the working group to document one practical model for addressing 
rather than cover all possible options, as their work in trying to do 
the latter had stalled.

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

This may have been an issue in the document as approved, but I do not 
think there is an implication left in the text with the proposed changes 
folded in.

More importantly, as the document correctly states there are differences 
in the requirements that routing protocols place on available addresses. 
I think the document makes a very pragmatic model choice in this light.

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

I agree about the distinction, of course. But I re-read the document 
today but cannot see where the document claims otherwise.

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

Again, I do not believe that the changed document can be construed as 
discouraging.

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

Agreed.  I think that case is covered by "configured in some manner", 
however.

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

We can make this change.

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

There is a difference between an intent to create addresses with a 
particular scope, and our ability to test that they really are unique. 
The text says "no mechanism to ensure" and I take that it means the 
testing part. This seems correct, though I do agree that it might have 
been confusing.

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

This section talks about the limited utility of link-local addresses. I 
agree that the paragraph above is relevant in an application context.

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

We agree so far.

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

And no one is disputing that. However, as stated in the document there 
are routing protocols that _do_ require non-link local addresses. So 
while I agree with your "can be still quite useful" claim I do not see a 
basis for claiming that link local addresses should be the one and only 
form of address configuration for routing protocols, or even that such 
addresses must be available as part of an addressing model.

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

See above.

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

See above.

Jari