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

"Charles E. Perkins" <charles.perkins@earthlink.net> Thu, 08 July 2010 17:29 UTC

Return-Path: <charles.perkins@earthlink.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 87BF43A63EC for <autoconf@core3.amsl.com>; Thu, 8 Jul 2010 10:29:08 -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 BdCM99dKRIBn for <autoconf@core3.amsl.com>; Thu, 8 Jul 2010 10:29:07 -0700 (PDT)
Received: from elasmtp-galgo.atl.sa.earthlink.net (elasmtp-galgo.atl.sa.earthlink.net [209.86.89.61]) by core3.amsl.com (Postfix) with ESMTP id 32B193A6878 for <autoconf@ietf.org>; Thu, 8 Jul 2010 10:29:06 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=Afu+V841apmhH+N8ZJSwrizcaoZgnZaGq6uqRCwfdRK8+ISeV9jeiq+VNkbvzXmt; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP;
Received: from [12.204.153.98] (helo=[10.166.130.11]) by elasmtp-galgo.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from <charles.perkins@earthlink.net>) id 1OWutv-0003ay-Oh; Thu, 08 Jul 2010 13:28:45 -0400
Message-ID: <4C360AAE.9090103@earthlink.net>
Date: Thu, 08 Jul 2010 10:28:14 -0700
From: "Charles E. Perkins" <charles.perkins@earthlink.net>
Organization: Wichorus Inc.
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5
MIME-Version: 1.0
To: Jari Arkko <jari.arkko@piuha.net>
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: 7bit
X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f52ce6178fbf82111ccbf9e2d32c981e1d7350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 12.204.153.98
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: Thu, 08 Jul 2010 17:29:09 -0000

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
>