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

Alexandru Petrescu <alexandru.petrescu@gmail.com> Thu, 08 July 2010 17:48 UTC

Return-Path: <alexandru.petrescu@gmail.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 D9DFA3A687A for <autoconf@core3.amsl.com>; Thu, 8 Jul 2010 10:48:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.367
X-Spam-Level:
X-Spam-Status: No, score=-0.367 tagged_above=-999 required=5 tests=[AWL=0.393, BAYES_05=-1.11, HELO_EQ_FR=0.35]
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 eeStcY682sjL for <autoconf@core3.amsl.com>; Thu, 8 Jul 2010 10:48:30 -0700 (PDT)
Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by core3.amsl.com (Postfix) with ESMTP id 892843A6831 for <autoconf@ietf.org>; Thu, 8 Jul 2010 10:48:28 -0700 (PDT)
Received: from [127.0.0.1] (unknown [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id 85C0F9400FE for <autoconf@ietf.org>; Thu, 8 Jul 2010 19:48:28 +0200 (CEST)
Message-ID: <4C360F6A.5070208@gmail.com>
Date: Thu, 08 Jul 2010 19:48:26 +0200
From: Alexandru Petrescu <alexandru.petrescu@gmail.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5
MIME-Version: 1.0
To: autoconf@ietf.org
References: <4C2A6BB7.1000900@piuha.net>
In-Reply-To: <4C2A6BB7.1000900@piuha.net>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Antivirus: avast! (VPS 100708-1, 08/07/2010), Outbound message
X-Antivirus-Status: Clean
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: Thu, 08 Jul 2010 17:48:32 -0000

Le 29/06/2010 23:55, Jari Arkko a écrit :
> 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 - I am ready to spend time reading and trying to understand.  I am
ready to give my oppinion about this last point - the IPv6 link-local
addresses.

If asked whether I agree with the NEW text on LLs then I say no, I do
not agree with it.  It is better than the old text but still makes
little sense to my reading (e.g. "IPv6 ll addresses are not unique
across links" is a statement which makes little sense, an answer to
something nobody doubted; worst, to derive conclusions saying that LL
addresses are not useful in "MANET ad-hoc" networks because of their
lack of uniqueness is even less sense.)

My two cents worth,

Alex

>
> 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.
>
> _______________________________________________ Autoconf mailing
> list Autoconf@ietf.org
> https://www.ietf.org/mailman/listinfo/autoconf
>