Re: [Autoconf] RFC 5889 (Was: Call for comments to a new AUTOCONF charter proposal)
Alexandru Petrescu <alexandru.petrescu@gmail.com> Wed, 21 July 2010 18:33 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 D83993A6AF4 for <autoconf@core3.amsl.com>; Wed, 21 Jul 2010 11:33:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.445
X-Spam-Level:
X-Spam-Status: No, score=-1.445 tagged_above=-999 required=5 tests=[AWL=0.804, 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 ASrcAICdpd8C for <autoconf@core3.amsl.com>; Wed, 21 Jul 2010 11:33:02 -0700 (PDT)
Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by core3.amsl.com (Postfix) with ESMTP id 4145C3A6A73 for <autoconf@ietf.org>; Wed, 21 Jul 2010 11:32:42 -0700 (PDT)
Received: from [127.0.0.1] (unknown [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id E0D2E940172 for <autoconf@ietf.org>; Wed, 21 Jul 2010 20:32:53 +0200 (CEST)
Message-ID: <4C473D4C.8050504@gmail.com>
Date: Wed, 21 Jul 2010 20:32:44 +0200
From: Alexandru Petrescu <alexandru.petrescu@gmail.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1
MIME-Version: 1.0
To: autoconf@ietf.org
References: <4C2A6BB7.1000900@piuha.net> <4C2CFADD.3040909@piuha.net> <4C378C29.2040302@oracle.com> <4C4706D8.5040904@piuha.net>
In-Reply-To: <4C4706D8.5040904@piuha.net>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Antivirus: avast! (VPS 100721-0, 21/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: Wed, 21 Jul 2010 18:33:07 -0000
Side note... Le 21/07/2010 16:40, Jari Arkko a écrit : [...] >> The result is that the document can easily be construed as >> discouraging approaches that make a lot of sense, which seems >> counterproductive. An example of such an approach is a routing >> protocol which uses IEEE MAC addresses as router ids, assigns IPv6 >> link-local addresses to the router's interfaces and uses that in >> the routing protocol exchanges, and configures global addresses >> for use by applications. > > Again, I do not believe that the changed document can be construed > as discouraging. Again, in my reading the document discourages the use of link-local addresses. It is this draft text: > in general link-local addresses are of limited utility on links with > undetermined connectivity > > [...] > > 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 > > [...] > > o Routers cannot forward any packets with link-local source or > destination addresses to other links > > [...] > > Note that the use of IPv4 link-local addresses [RFC3927] in this > context should be discouraged for most applications, as the > limitations outlined in Section 6.1 for IPv6 link-local addresses > also concern IPv4 link-local addresses. There is no place in the draft talking positively about the use of link-local addresses, despite the numerous agreements on this list that link-local addresses can and are being used by routing protocols. This difference between list statements and draft text is huge. It could be solved by simply saying that "link-local addresses can and are being used by routing protocols and stateless and stateful address auto-configuration" and "IPv4 link-local addresses are in widespread use on e.g. Bluetooth with ActiveSync on numerous small wireless mobile devices; OSs in widespread use self-configure IPv4 and IPv6 link-local addresses upon startup, w/o means to forbid this self configuration". Alex > >> I think the exercise here is to try to correct some minor wording >> in the recommendations in the document, but even if we succeed in >> doing so the premises expressed in the introduction and elsewhere >> will be a bit odd, since they focus on the configuration of router >> interfaces and not on the addressing model of the Ad Hoc network. >> >>> 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]). >>> Routing protocols that do not require unique IP addresses within >>> the routing domain utilize a separate unique identifier within >>> the routing protocol itself that must also be configured in some >>> manner. >> >> With IS-IS one doesn't configure the router id; it is a factory >> assigned MAC address. Such an approach is perfectly valid for Ad >> Hoc routing protocols as well. > > Agreed. I think that case is covered by "configured in some manner", > however. > >> Note that a router (as opposed to routing protocol) require IP >> addresses to be managable and to be able to send ICMP errors. But >> the above paragraph is trying to derive recommendations from the >> latter. >> >> I suggest the wording Routing protocols that do not require unique >> IP addresses within the routing domain utilize a separate unique >> identifier within the routing protocol itself; such identifiers >> could be based on factory assignment or configuration. > > We can make this change. > >>> 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, the following principle allows >>> for IP autoconfiguration to apply to the widest array of routing >>> protocols: >>> >>> 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 by the routing >>> protocol for which IP address autoconfiguration is being >>> provided. >> >> According to RFC 4291 EUI-64-based interface identifiers have >> global scope when created from a universal token. A result of this >> is that link-local addresses formed from such interface identifiers >> have global scope. Hence the "no mechanism" above seems factually >> incorrect. >> >> Thus I think section 6.1 needs to differentiate between the global >> and local scope for the interface identifiers for it to make sense. >> Should I suggest replacement text? > > There is a difference between an intent to create addresses with a > particular scope, and our ability to test that they really are > unique. The text says "no mechanism to ensure" and I take that it > means the testing part. This seems correct, though I do agree that > it might have been confusing. > >> This paragraph seems like a non seqiteur: o Routers cannot forward >> any packets with link-local source or destination addresses to >> other links (as per [RFC4291]) while most of the time, routers >> need to be able to forward packets to/from different links. Clearly >> the application traffic needs to use non-link-local addresses to >> work across multiple links, but that has nothing to do with what IP >> addresses are configured on the interfaces of routers as we see >> from the requirement for RIPng and OSPFv3 to use IPv6 link-locals >> on router interfaces. >> >> Instead the issue is that link-local addresses are not useful for >> applications *other than routing protocols*, and that is the >> motivation for the subsequent paragraph: > > This section talks about the limited utility of link-local > addresses. I agree that the paragraph above is relevant in an > application context. > >>> OLD: Therefore, autoconfiguration solutions should be encouraged >>> to primarily focus on configuring IP addresses that are not IPv6 >>> link- local. NEW: Therefore, an autoconfiguration solution which >>> provides a mechanism for assigning addresses with a wider scope >>> than IPv6 link-local alone will be more generally useful than one >>> that does not. >> >> That misses the point. It is the motivation for this >> recommendation which is confused and misleading, and not the >> conclusion itself. The motivation is that applications (other than >> routing protocols) most likely desire to communicate across the >> whole Ad Hoc network, if not across the whole Internet, which makes >> link-local addresses of limited use. > > We agree so far. > >> But they can still be quite useful as for the purposes of routing >> protocols, and bootstrapping address autoconfiguration protocols. > > And no one is disputing that. However, as stated in the document > there are routing protocols that _do_ require non-link local > addresses. So while I agree with your "can be still quite useful" > claim I do not see a basis for claiming that link local addresses > should be the one and only form of address configuration for routing > protocols, or even that such addresses must be available as part of > an addressing model. > >> This confusion is related to the odd scope mismatch between the >> title and the abstract. Clearly we want to be able to >> autoconfigure non-link-local addresses for applications, but the >> abstract limits the scope of the document to IP addressed assigned >> to router interfaces, and there link-local address might be just >> fine. > > See above. > >> Note that the last sentence in the first paragraph in section 4 is >> also misleading (I'm assuming that paragraph is about configuring >> router interfaces and not host interfaces) in saying Note that >> while link-local addresses are assumed to be "on link", the >> utility of link-local addresses is limited as described in Section >> 6. when in fact using link-local address, in particular those based >> on global scope interface identifiers, might be just fine for >> router interfaces. > > See above. > > Jari > > _______________________________________________ Autoconf mailing list > Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf >
- Re: [Autoconf] RFC 5889 (Was: Call for comments t… Alexandru Petrescu
- [Autoconf] RFC 5889 (Was: Call for comments to a … Jari Arkko
- Re: [Autoconf] RFC 5889 (Was: Call for comments t… Jari Arkko
- Re: [Autoconf] RFC 5889 (Was: Call for comments t… Jari Arkko
- Re: [Autoconf] RFC 5889 (Was: Call for comments t… Henning Rogge
- Re: [Autoconf] RFC 5889 (Was: Call for comments t… Teco Boot
- Re: [Autoconf] RFC 5889 (Was: Call for comments t… Dearlove, Christopher (UK)
- Re: [Autoconf] RFC 5889 (Was: Call for comments t… Ulrich Herberg
- Re: [Autoconf] RFC 5889 (Was: Call for comments t… Charles E. Perkins
- Re: [Autoconf] RFC 5889 (Was: Call for comments t… Alexandru Petrescu
- Re: [Autoconf] RFC 5889 (Was: Call for comments t… Stan Ratliff
- Re: [Autoconf] RFC 5889 (Was: Call for comments t… Alexandru Petrescu
- Re: [Autoconf] RFC 5889 (Was: Call for comments t… Zach Shelby
- Re: [Autoconf] RFC 5889 (Was: Call for comments t… Henning Rogge
- Re: [Autoconf] RFC 5889 (Was: Call for comments t… Teco Boot
- Re: [Autoconf] RFC 5889 (Was: Call for comments t… Henning Rogge
- Re: [Autoconf] RFC 5889 (Was: Call for comments t… Erik Nordmark
- Re: [Autoconf] RFC 5889 (Was: Call for comments t… Zach Shelby
- Re: [Autoconf] RFC 5889 (Was: Call for comments t… Ryuji Wakikawa
- Re: [Autoconf] RFC 5889 (Was: Call for comments t… Ryuji Wakikawa
- Re: [Autoconf] RFC 5889 (Was: Call for comments t… Emmanuel Baccelli
- Re: [Autoconf] RFC 5889 (Was: Call for comments t… Emmanuel Baccelli
- Re: [Autoconf] RFC 5889 (Was: Call for comments t… Jari Arkko
- Re: [Autoconf] RFC 5889 (Was: Call for comments t… Ulrich Herberg
- Re: [Autoconf] RFC 5889 (Was: Call for comments t… Jari Arkko
- Re: [Autoconf] RFC 5889 (Was: Call for comments t… Teco Boot
- Re: [Autoconf] RFC 5889 (Was: Call for comments t… Teco Boot
- Re: [Autoconf] RFC 5889 (Was: Call for comments t… Henning Rogge
- Re: [Autoconf] RFC 5889 (Was: Call for comments t… Teco Boot
- Re: [Autoconf] RFC 5889 (Was: Call for comments t… Alexandru Petrescu
- Re: [Autoconf] RFC 5889 (Was: Call for comments t… Alexandru Petrescu
- Re: [Autoconf] RFC 5889 (Was: Call for comments t… Dearlove, Christopher (UK)
- Re: [Autoconf] RFC 5889 (Was: Call for comments t… Alexandru Petrescu
- Re: [Autoconf] RFC 5889 (Was: Call for comments t… Dearlove, Christopher (UK)
- Re: [Autoconf] RFC 5889 (Was: Call for comments t… Ulrich Herberg
- Re: [Autoconf] RFC 5889 (Was: Call for comments t… Alexandru Petrescu
- Re: [Autoconf] RFC 5889 (Was: Call for comments t… Dearlove, Christopher (UK)
- Re: [Autoconf] RFC 5889 (Was: Call for comments t… Alexandru Petrescu
- Re: [Autoconf] RFC 5889 (Was: Call for comments t… Alexandru Petrescu
- Re: [Autoconf] RFC 5889 (Was: Call for comments t… Alexandru Petrescu
- Re: [Autoconf] RFC 5889 (Was: Call for comments t… Thomas Heide Clausen
- Re: [Autoconf] RFC 5889 (Was: Call for comments t… Alexandru Petrescu
- Re: [Autoconf] RFC 5889 (Was: Call for comments t… Thomas Heide Clausen
- Re: [Autoconf] RFC 5889 (Was: Call for comments t… Alexandru Petrescu
- Re: [Autoconf] RFC 5889 (Was: Call for comments t… Dearlove, Christopher (UK)
- Re: [Autoconf] RFC 5889 (Was: Call for comments t… Alexandru Petrescu
- Re: [Autoconf] RFC 5889 (Was: Call for comments t… Dearlove, Christopher (UK)
- Re: [Autoconf] RFC 5889 (Was: Call for comments t… Dearlove, Christopher (UK)
- Re: [Autoconf] RFC 5889 (Was: Call for comments t… Alexandru Petrescu
- Re: [Autoconf] RFC 5889 (Was: Call for comments t… Alexandru Petrescu
- Re: [Autoconf] RFC 5889 (Was: Call for comments t… Alexandru Petrescu
- Re: [Autoconf] RFC 5889 (Was: Call for comments t… Dearlove, Christopher (UK)
- Re: [Autoconf] RFC 5889 (Was: Call for comments t… Teco Boot
- Re: [Autoconf] RFC 5889 (Was: Call for comments t… Alexandru Petrescu
- Re: [Autoconf] RFC 5889 (Was: Call for comments t… Henning Rogge
- Re: [Autoconf] RFC 5889 (Was: Call for comments t… Alexandru Petrescu
- Re: [Autoconf] RFC 5889 (Was: Call for comments t… Alexandru Petrescu
- Re: [Autoconf] RFC 5889 (Was: Call for comments t… Henning Rogge
- Re: [Autoconf] RFC 5889 (Was: Call for comments t… Alexandru Petrescu
- Re: [Autoconf] RFC 5889 (Was: Call for comments t… Thomas Heide Clausen
- Re: [Autoconf] RFC 5889 (Was: Call for comments t… Henning Rogge
- Re: [Autoconf] RFC 5889 (Was: Call for comments t… Ulrich Herberg
- Re: [Autoconf] RFC 5889 (Was: Call for comments t… Alexandru Petrescu
- Re: [Autoconf] RFC 5889 (Was: Call for comments t… Alexandru Petrescu
- Re: [Autoconf] RFC 5889 (Was: Call for comments t… Thomas Heide Clausen
- Re: [Autoconf] RFC 5889 (Was: Call for comments t… Thomas Heide Clausen
- Re: [Autoconf] RFC 5889 (Was: Call for comments t… Alexandru Petrescu
- Re: [Autoconf] RFC 5889 (Was: Call for comments t… Alexandru Petrescu
- Re: [Autoconf] RFC 5889 (Was: Call for comments t… Dearlove, Christopher (UK)
- Re: [Autoconf] RFC 5889 (Was: Call for comments t… Dearlove, Christopher (UK)
- Re: [Autoconf] RFC 5889 (Was: Call for comments t… Dearlove, Christopher (UK)
- Re: [Autoconf] RFC 5889 (Was: Call for comments t… Dearlove, Christopher (UK)
- Re: [Autoconf] RFC 5889 (Was: Call for comments t… Alexandru Petrescu
- Re: [Autoconf] RFC 5889 (Was: Call for comments t… Alexandru Petrescu
- Re: [Autoconf] RFC 5889 (Was: Call for comments t… Alexandru Petrescu
- Re: [Autoconf] RFC 5889 (Was: Call for comments t… Alexandru Petrescu
- Re: [Autoconf] RFC 5889 (Was: Call for comments t… Dearlove, Christopher (UK)
- Re: [Autoconf] RFC 5889 (Was: Call for comments t… Alexandru Petrescu
- Re: [Autoconf] RFC 5889 (Was: Call for comments t… Alexandru Petrescu
- Re: [Autoconf] RFC 5889 (Was: Call for comments t… Alexandru Petrescu
- Re: [Autoconf] RFC 5889 (Was: Call for comments t… Alexandru Petrescu
- Re: [Autoconf] RFC 5889 (Was: Call for comments t… Henning Rogge
- Re: [Autoconf] RFC 5889 (Was: Call for comments t… Teco Boot
- Re: [Autoconf] RFC 5889 (Was: Call for comments t… Teco Boot
- Re: [Autoconf] RFC 5889 (Was: Call for comments t… Alexandru Petrescu
- Re: [Autoconf] RFC 5889 (Was: Call for comments t… Erik Nordmark
- Re: [Autoconf] RFC 5889 Erik Nordmark
- [Autoconf] Forgot one [Was: RFC 5889 Erik Nordmark
- Re: [Autoconf] RFC 5889 Dearlove, Christopher (UK)
- Re: [Autoconf] RFC 5889 Erik Nordmark
- Re: [Autoconf] Forgot one [Was: RFC 5889 Erik Nordmark
- Re: [Autoconf] Forgot one [Was: RFC 5889 Dearlove, Christopher (UK)
- Re: [Autoconf] what's a router Henning Rogge
- [Autoconf] WC consensus call for RFC5889 modifica… Ryuji Wakikawa
- Re: [Autoconf] WC consensus call for RFC5889 modi… Jari Arkko
- Re: [Autoconf] WC consensus call for RFC5889 modi… Charles E. Perkins
- Re: [Autoconf] WC consensus call for RFC5889 modi… Henning Rogge
- Re: [Autoconf] WC consensus call for RFC5889 modi… Henning Rogge
- Re: [Autoconf] WC consensus call for RFC5889 modi… Charles E. Perkins
- Re: [Autoconf] WC consensus call for RFC5889 modi… Henning Rogge
- Re: [Autoconf] WC consensus call for RFC5889 modi… Teco Boot
- Re: [Autoconf] WC consensus call for RFC5889 modi… Teco Boot
- Re: [Autoconf] WC consensus call for RFC5889 modi… Alexandru Petrescu
- Re: [Autoconf] WC consensus call for RFC5889 modi… Teco Boot
- Re: [Autoconf] WC consensus call for RFC5889 modi… Charles E. Perkins
- Re: [Autoconf] WC consensus call for RFC5889 modi… Charles E. Perkins
- Re: [Autoconf] WC consensus call for RFC5889 modi… Teco Boot
- Re: [Autoconf] WC consensus call for RFC5889 modi… Charles E. Perkins
- Re: [Autoconf] WC consensus call for RFC5889 modi… Teco Boot
- Re: [Autoconf] WC consensus call for RFC5889 modi… Charles E. Perkins
- Re: [Autoconf] WC consensus call for RFC5889 modi… Teco Boot
- Re: [Autoconf] WC consensus call for RFC5889 modi… Henning Rogge
- Re: [Autoconf] WC consensus call for RFC5889 modi… Dearlove, Christopher (UK)
- Re: [Autoconf] what's a router (was: WC consensus… Alexandru Petrescu
- Re: [Autoconf] what's a router (was: WC consensus… Henning Rogge
- Re: [Autoconf] what's a router Alexandru Petrescu
- Re: [Autoconf] WC consensus call for RFC5889 modi… Emmanuel Baccelli
- Re: [Autoconf] what's a router Alexandru Petrescu
- Re: [Autoconf] what's a router Teco Boot
- Re: [Autoconf] what's a router Henning Rogge
- Re: [Autoconf] what's a router (was: WC consensus… Ulrich Herberg
- Re: [Autoconf] what's a router (was: WC consensus… Teco Boot
- Re: [Autoconf] what's a router Alexandru Petrescu
- Re: [Autoconf] what's a router Alexandru Petrescu
- Re: [Autoconf] what's a router Rogge Henning
- Re: [Autoconf] what's a router Alexandru Petrescu
- Re: [Autoconf] what's a router Alexandru Petrescu
- Re: [Autoconf] what's a router Alexandru Petrescu
- Re: [Autoconf] WC consensus call for RFC5889 modi… Alexandru Petrescu
- Re: [Autoconf] what's a router Teco Boot
- Re: [Autoconf] WC consensus call for RFC5889 modi… Charles E. Perkins
- Re: [Autoconf] WC consensus call for RFC5889 modi… Charles E. Perkins
- Re: [Autoconf] WC consensus call for RFC5889 modi… Charles E. Perkins
- Re: [Autoconf] WC consensus call for RFC5889 modi… Thomas Heide Clausen
- Re: [Autoconf] WC consensus call for RFC5889 modi… Charles E. Perkins
- Re: [Autoconf] WC consensus call for RFC5889 modi… Thomas Heide Clausen
- Re: [Autoconf] WC consensus call for RFC5889 modi… Emmanuel Baccelli
- Re: [Autoconf] WC consensus call for RFC5889 modi… Charles E. Perkins
- Re: [Autoconf] WC consensus call for RFC5889 modi… Emmanuel Baccelli
- Re: [Autoconf] WC consensus call for RFC5889 modi… Emmanuel Baccelli