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

Jari Arkko <jari.arkko@piuha.net> Tue, 29 June 2010 21:54 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 0D4823A6930 for <autoconf@core3.amsl.com>; Tue, 29 Jun 2010 14:54:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.577
X-Spam-Level:
X-Spam-Status: No, score=-0.577 tagged_above=-999 required=5 tests=[AWL=-0.578, BAYES_50=0.001]
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 w8q7UxfIZW58 for <autoconf@core3.amsl.com>; Tue, 29 Jun 2010 14:54:56 -0700 (PDT)
Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 35A3C3A69F9 for <autoconf@ietf.org>; Tue, 29 Jun 2010 14:54:55 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 37C5F2CC62; Wed, 30 Jun 2010 00:55:05 +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 kAe1Q3vlf93s; Wed, 30 Jun 2010 00:55:04 +0300 (EEST)
Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 8673B2CED4; Wed, 30 Jun 2010 00:55:04 +0300 (EEST)
Message-ID: <4C2A6BB7.1000900@piuha.net>
Date: Wed, 30 Jun 2010 00:55:03 +0300
From: Jari Arkko <jari.arkko@piuha.net>
User-Agent: Thunderbird 2.0.0.24 (X11/20100411)
MIME-Version: 1.0
To: "Dearlove, Christopher (UK)" <Chris.Dearlove@baesystems.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "autoconf@ietf.org" <autoconf@ietf.org>
Subject: [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: Tue, 29 Jun 2010 21:54:57 -0000

Christopher,

> Incidentally the charter refers to RFC 5889, which is not yet published.
> I see that is in AUTH48, but noted as on hold for a technical issue.
> AUTH48 seems rather late for a technical issue, unless meaning a
> publication technical issue rather than an engineering technical issue.
>   

Yes it is late. We approved the document but after approval there was a 
comment on the IETF last call thread from Erik Nordmark. We are trying 
to resolve it but unfortunately it took a long time for me to do so. But 
we are now trying to do it. The standing proposal is below, comments 
appreciated.

Jari

-----

We talked about this during Anaheim but never got to the end of it. 
Sorry -- I should have posted a suggestion back then but other business 
has kept me busy. I have now looked at the discussion again.

The essence of Erik's complaint was twofold. First, the document claimed 
that routing protocols require a unique IP address (and not just a 
router ID), which is not true. Second, that the document unnecessarily 
dismisses link local identifiers as addresses.

About the first issue: Erik is right that not all routing protocols 
require unique IP addresses at all. But at the same time, apparently 
some routing protocols in the MANET space do require it (e.g., OSLR in 
RFC 3626). In a way, the document is factually correct on this point as 
it states that some protocols do have these requirements. But it may 
also be misleading from another perspective, as we certainly do not want 
to claim that using unique IP addresses is a recommended design for a 
routing protocol or the only possible model.

The second issue is partially related to the first one, as one of the 
reasons for using non-link-local addresses is to enable the use of 
unique addresses in routing protocols. In any case, the intent was never 
to claim that link local addresses cannot be used. The document merely 
makes one recommendation about a commonly used addressing model in adhoc 
networks. I would like to defend the working group's right to publish 
such an "example model" -- particularly after years of effort spent in 
trying to find the true universal model. As long as the working group is 
not making false claims, this is clearly appropriate. But I can see that 
the document could be clearer about its claims.

Here's a possible rewrite of Section 5 to address these issues:

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]). Many modern routing protocols do not need to employ
  unique addresses at all, and theoretically, their only requirement is 
that
  some router identifier is unique.

  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, many current deployments have chosen to employ the following
  simplifying 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.

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 in the chosen
     routing protocol.

OLD:
  Therefore, autoconfiguration solutions should be encouraged to
  primarily focus on configuring IP addresses that are not IPv6 link-
  local.
NEW:
  Therefore, a common theme in many autoconfiguration solutions is to
  focus on configuring IP addresses that are not IPv6 link-
  local.