Re: [Autoconf] RFC 5889 (Was: Call for comments to a new AUTOCONF charter proposal)
Erik Nordmark <erik.nordmark@oracle.com> Fri, 09 July 2010 20:53 UTC
Return-Path: <erik.nordmark@oracle.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 729903A68C1 for <autoconf@core3.amsl.com>; Fri, 9 Jul 2010 13:53:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.45
X-Spam-Level:
X-Spam-Status: No, score=-6.45 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 g6HdD0R35f8F for <autoconf@core3.amsl.com>; Fri, 9 Jul 2010 13:53:11 -0700 (PDT)
Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 0A5A83A67EE for <autoconf@ietf.org>; Fri, 9 Jul 2010 13:53:10 -0700 (PDT)
Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o69KrEFO025711 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 9 Jul 2010 20:53:15 GMT
Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o69EKl1q023737; Fri, 9 Jul 2010 20:53:13 GMT
Received: from abhmt016.oracle.com by acsmt355.oracle.com with ESMTP id 414060291278708779; Fri, 09 Jul 2010 13:52:59 -0700
Received: from [10.7.251.248] (/10.7.251.248) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 09 Jul 2010 13:52:58 -0700
Message-ID: <4C378C29.2040302@oracle.com>
Date: Fri, 09 Jul 2010 13:52:57 -0700
From: Erik Nordmark <erik.nordmark@oracle.com>
User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.10) Gecko/20100621 Lightning/1.0b1 Thunderbird/3.0.5
MIME-Version: 1.0
To: Jari Arkko <jari.arkko@piuha.net>
References: <4C2A6BB7.1000900@piuha.net> <4C2CFADD.3040909@piuha.net>
In-Reply-To: <4C2CFADD.3040909@piuha.net>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Source-IP: acsmt353.oracle.com [141.146.40.153]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090204.4C378C3A.006F:SCFMA4539814,ss=1,fgs=0
Cc: "autoconf@ietf.org" <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 20:53:12 -0000
On 07/ 1/10 01:30 PM, Jari Arkko wrote: > We have not had a substantial discussion of the proposal yet with Erik > -- he has acknowledged that he's seen the proposal but has been too busy > at day job to do a detailed review. He has promised to provide feedback > in the next few days. In the meantime I wanted to bring the issue up > with the working group so that you know what is going on. Ultimately, it > is your call to make changes. No single person's opinion can change the > document at this stage, be it Erik, the ADs, or the authors. That being > said, we do try to fix problems if there are some. > > In this particular issue, I personally believe that despite's Erik's > concern the document as approved was factually correct. However, at the > same time I think that the document could have been clearer about what > it is saying about routing protocols and what it is not. That was the > basis of my suggested edit. I think this edit, if agreed, is somewhere > between an editorial and technical change and something that can be done > in AUTH48 with the working group's acceptance. In other words, it is not > necessary to redo the approval process. I do think the document is misleading and confused. That starts with the discrepancy between the title IP Addressing Model in Ad Hoc Networks and the abstract, which limits itself to configuring IP addresses for router interfaces and not for the whole of an ad hoc network. I was under the impression that the WG was looking at a document that addressed the scope that is implied by the title. I find the more limited scope odd, since we existing routing protocols like IS-IS that can operate (exchange routing information, forward IP packets) without any IP addresses configured on the routers' interfaces. (Even though a router needs some IP addresses to be manageable with SNMP and to be able to send ICMP errors.) The implied conclusion that IPv6-link local addresses are undesirable for router's interfaces is even odder, since RIPng and OSPFv3 both require routers to use IPv6 link-local addresses for the routing protocol exchanges. The document seems to assume that the uniqueness scope of link-local addresses is limited to a single link, when it is the routability scope which is limited to the link. There is a class of link-local addresses with U=1 (those derived from EUI-64) that are globally unique - but still is not routable outside of the link. 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. 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. 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. > 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? 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: > 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. But they can still be quite useful as for the purposes of routing protocols, and bootstrapping address autoconfiguration protocols. 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. 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. Erik
- 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