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

Stan Ratliff <sratliff@cisco.com> Thu, 08 July 2010 17:45 UTC

Return-Path: <sratliff@cisco.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 795C13A679F for <autoconf@core3.amsl.com>; Thu, 8 Jul 2010 10:45:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level:
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 qLqAdU0OYXPn for <autoconf@core3.amsl.com>; Thu, 8 Jul 2010 10:45:24 -0700 (PDT)
Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 020FD3A688B for <autoconf@ietf.org>; Thu, 8 Jul 2010 10:45:23 -0700 (PDT)
Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEAD+rNUxAZnwN/2dsb2JhbACgMXGmaJp7glyCSQSIQg
X-IronPort-AV: E=Sophos;i="4.53,559,1272844800"; d="scan'208";a="130124319"
Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 08 Jul 2010 17:45:23 +0000
Received: from dhcp-64-102-54-238.cisco.com (dhcp-64-102-54-238.cisco.com [64.102.54.238]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o68HjNQk006059; Thu, 8 Jul 2010 17:45:23 GMT
Message-Id: <401ECF37-F543-423F-912B-A10A816FC5B9@cisco.com>
From: Stan Ratliff <sratliff@cisco.com>
To: "Charles E. Perkins" <charles.perkins@earthlink.net>
In-Reply-To: <4C360AAE.9090103@earthlink.net>
Content-Type: text/plain; charset="US-ASCII"; format="flowed"; delsp="yes"
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Date: Thu, 08 Jul 2010 13:45:24 -0400
References: <4C2A6BB7.1000900@piuha.net> <4C360AAE.9090103@earthlink.net>
X-Mailer: Apple Mail (2.936)
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:45:25 -0000

Jari,

+1 on what Charlie said.

Regards,
Stan

On Jul 8, 2010, at 1: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