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

Henning Rogge <hrogge@googlemail.com> Fri, 09 July 2010 14:15 UTC

Return-Path: <hrogge@googlemail.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 A5F6D3A69FC for <autoconf@core3.amsl.com>; Fri, 9 Jul 2010 07:15:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.185
X-Spam-Level:
X-Spam-Status: No, score=-0.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185]
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 4HU8qSe1XebZ for <autoconf@core3.amsl.com>; Fri, 9 Jul 2010 07:15:47 -0700 (PDT)
Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 42EB23A69E6 for <autoconf@ietf.org>; Fri, 9 Jul 2010 07:15:47 -0700 (PDT)
Received: by wwb24 with SMTP id 24so4128656wwb.13 for <autoconf@ietf.org>; Fri, 09 Jul 2010 07:15:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date :user-agent:cc:references:in-reply-to:mime-version:content-type :content-transfer-encoding:message-id; bh=8BKe4uHHsKE6NCGNGvHb2DfUDSu9DgYE4HovarKC5eM=; b=PMpB2B79RnmHK74VFF+uJGK4K9nUbSBDEB3LoqvVaWDEtInbsm//GwiIwj4ZdwvHZJ df7q4Vizx6lYzG85bqiJR/Y1ul1lnxPzRdEaKXxPRTR9wCnmQOAat4mfhIc4vH8zvlFb YayktSEgJDas7dAv2citfiTm/gc7Gt6YWdgy8=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; b=oWenFuNZjaYunY9zKKgUoyILdNnvrUBCwwmPFd+utAk21TMYWiWjXEl7ciaIZ6m/fP M5iESbaiB3J7kE4PEiIuccSdc78LQHh9ZP9fRXNLox+41MgpeQY+2ONh9/eUczj96D3n tNzVLR+7Q9p1BjwYK1LqObXSGLrOVURtJk9W0=
Received: by 10.216.187.143 with SMTP id y15mr1868314wem.74.1278684948417; Fri, 09 Jul 2010 07:15:48 -0700 (PDT)
Received: from core2.localnet (static-87-79-93-195.netcologne.de [87.79.93.195]) by mx.google.com with ESMTPS id o11sm36717wej.45.2010.07.09.07.15.47 (version=SSLv3 cipher=RC4-MD5); Fri, 09 Jul 2010 07:15:47 -0700 (PDT)
From: Henning Rogge <hrogge@googlemail.com>
To: autoconf@ietf.org
Date: Fri, 09 Jul 2010 16:15:32 +0200
User-Agent: KMail/1.13.5 (Linux/2.6.34-gentoo-r1; KDE/4.4.5; x86_64; ; )
References: <4C2A6BB7.1000900@piuha.net> <4C2CFADD.3040909@piuha.net>
In-Reply-To: <4C2CFADD.3040909@piuha.net>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart9405069.46BtVVvVxT"; protocol="application/pgp-signature"; micalg="pgp-sha1"
Content-Transfer-Encoding: 7bit
Message-Id: <201007091615.39159.hrogge@googlemail.com>
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 14:15:48 -0000

Am Donnerstag 01 Juli 2010, 22:30:21 schrieb Jari Arkko:

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

ACK to this section.

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

I think this is still too strong.
"There is no mechanism to ensure..." does sound as there never will be one. If 
we cannot find a mechanism/protocol to do this, we cannot find one that 
creates routing unique adresses (because the later would do the former too).

I think it should start with something like this:
"The default mechanisms of IPv6 cannot ensure that..."
(instead of "There is no mechanism to ensure that...")

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

ACK to this.

Any autoconfiguration sollution that solves the "routing unique" case can 
easily be adapted to solve the "linklocal" one.

Henning Rogge
-- 
1) You can't win.
2) You can't break even.
3) You can't leave the game.
— The Laws of Thermodynamics, summarized