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

Alexandru Petrescu <alexandru.petrescu@gmail.com> Thu, 08 July 2010 18:21 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 EB1E13A6804 for <autoconf@core3.amsl.com>; Thu, 8 Jul 2010 11:21:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.177
X-Spam-Level:
X-Spam-Status: No, score=-1.177 tagged_above=-999 required=5 tests=[AWL=1.072, BAYES_00=-2.599, 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 GX9AmeAivlQB for <autoconf@core3.amsl.com>; Thu, 8 Jul 2010 11:21:41 -0700 (PDT)
Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by core3.amsl.com (Postfix) with ESMTP id 6E69B3A67C0 for <autoconf@ietf.org>; Thu, 8 Jul 2010 11:21:39 -0700 (PDT)
Received: from [127.0.0.1] (unknown [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id 715159400C2 for <autoconf@ietf.org>; Thu, 8 Jul 2010 20:21:39 +0200 (CEST)
Message-ID: <4C361731.9020809@gmail.com>
Date: Thu, 08 Jul 2010 20:21:37 +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> <4C360AAE.9090103@earthlink.net>
In-Reply-To: <4C360AAE.9090103@earthlink.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 18:21:43 -0000

Le 08/07/2010 19:28, Charles E. Perkins a écrit :
>
> Hello Jari,
>
> I support the publication of RFC 5889 with the inclusion of
> the revisions as you and Erik have suggested below.
>
> Regarding the last edit, I am also O.K. with that, but
> with the understanding that link-local solutions are
> neither favored or disfavored per se.

That sounds as a "MAY LL" which is more positive to my reading than 
"There is no mechanism to ensure uniqueness LL ... hence ... cannot ..."

Writing "There MAY be link-local solutions" is something I could easily 
agree with.

Alex

  Wide applicability
> and performance issues (for example) are (to me at least)
> much more important.
>
> Regards,
> Charlie P.
>
>
> On 6/29/2010 2:55 PM, Jari Arkko wrote:
>> 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.
>>
>> _______________________________________________
>> Autoconf mailing list
>> Autoconf@ietf.org
>> https://www.ietf.org/mailman/listinfo/autoconf
>>
>
> _______________________________________________
> Autoconf mailing list
> Autoconf@ietf.org
> https://www.ietf.org/mailman/listinfo/autoconf
>