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

Zach Shelby <zach@sensinode.com> Fri, 09 July 2010 07:58 UTC

Return-Path: <zach@sensinode.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 363653A6B96 for <autoconf@core3.amsl.com>; Fri, 9 Jul 2010 00:58:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.271
X-Spam-Level:
X-Spam-Status: No, score=-3.271 tagged_above=-999 required=5 tests=[AWL=0.328, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 r0RrE7hDvow4 for <autoconf@core3.amsl.com>; Fri, 9 Jul 2010 00:58:28 -0700 (PDT)
Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 432083A67D3 for <autoconf@ietf.org>; Fri, 9 Jul 2010 00:58:28 -0700 (PDT)
Received: from [62.145.172.52] ([62.145.172.52]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id o697wRIv029546 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 9 Jul 2010 10:58:27 +0300
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: text/plain; charset="us-ascii"
From: Zach Shelby <zach@sensinode.com>
In-Reply-To: <4C360AAE.9090103@earthlink.net>
Date: Fri, 09 Jul 2010 10:58:29 +0300
Content-Transfer-Encoding: 7bit
Message-Id: <A4961E9D-2FCA-4C77-A379-A34566036D3E@sensinode.com>
References: <4C2A6BB7.1000900@piuha.net> <4C360AAE.9090103@earthlink.net>
To: "Charles E. Perkins" <charles.perkins@earthlink.net>
X-Mailer: Apple Mail (2.1081)
Cc: 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: Fri, 09 Jul 2010 07:58:30 -0000

+1 

On Jul 8, 2010, at 8:28 PM, Charles E. Perkins wrote:

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

-- 
Zach Shelby, Chief Nerd, Sensinode Ltd.
http://zachshelby.org  - My blog "On the Internet of Things"
http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet"
Mobile: +358 40 7796297