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

Ryuji Wakikawa <ryuji.wakikawa@gmail.com> Tue, 20 July 2010 05:57 UTC

Return-Path: <ryuji.wakikawa@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 B455C3A682E for <autoconf@core3.amsl.com>; Mon, 19 Jul 2010 22:57:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 nhbgZ2HhU2IO for <autoconf@core3.amsl.com>; Mon, 19 Jul 2010 22:57:05 -0700 (PDT)
Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by core3.amsl.com (Postfix) with ESMTP id 793B93A677C for <autoconf@ietf.org>; Mon, 19 Jul 2010 22:56:59 -0700 (PDT)
Received: by pzk6 with SMTP id 6so2516291pzk.31 for <autoconf@ietf.org>; Mon, 19 Jul 2010 22:57:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=GsQl67zfcQ75tNtckvxYli0EFYNwcVqh3fB+vn/GT4A=; b=rirId3ErYfLPEGAgAQvdx2P/X0OEErWcZ+7w8P70K/S/rjNLxrpR4sBbsy28JFjc8f op8ekTcutiDB4aNi9k5LIbV+A4way24GQvo+iFKTi55DX9UV7TClr/7rP1TqiMptFbqx 7eW1YTTGrauJ0iOET0QyUAtzZEdZGavnd2cXs=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=GVhncdJJZD0yXH1EHP3BxmzDunztKDR+PHrvWgS4IfPHyarOORZklGVkqas+f9TZGo tTh6PaQ9zXktjw5SvVUIO0NUJUdsHA1IsxhbCGXTB3fUX5seETUqQAPm9rlKEo3CmrDL egT8jq+UutBini9jP/EnkqjtFtAWFw8RDCjUI=
Received: by 10.142.132.12 with SMTP id f12mr8116067wfd.73.1279605433678; Mon, 19 Jul 2010 22:57:13 -0700 (PDT)
Received: from [10.0.1.2] (c-98-248-44-75.hsd1.ca.comcast.net [98.248.44.75]) by mx.google.com with ESMTPS id x18sm7347148wfd.20.2010.07.19.22.57.11 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 19 Jul 2010 22:57:12 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: text/plain; charset=us-ascii
From: Ryuji Wakikawa <ryuji.wakikawa@gmail.com>
In-Reply-To: <4C378C29.2040302@oracle.com>
Date: Mon, 19 Jul 2010 22:57:10 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <DA93ABBC-FF5E-4275-A9F1-54C40330D16A@gmail.com>
References: <4C2A6BB7.1000900@piuha.net> <4C2CFADD.3040909@piuha.net> <4C378C29.2040302@oracle.com>
To: Erik Nordmark <erik.nordmark@oracle.com>
X-Mailer: Apple Mail (2.1081)
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: Tue, 20 Jul 2010 05:57:09 -0000

Hi Erik,

Thanks for comments. It will be nice to have your proposed texts.
As you know, AUTOCONF WG has long discussion of Link-Local address treatment. 
Due to the special characteristics of ad-hoc links, the uniqueness of link-local is hardly achieved.   
The link characteristics of ad-hoc network is quite different from the fixed link.

http://ietfreport.isoc.org/all-ids/draft-baccelli-multi-hop-wireless-communication-04.txt

I'm not quite sure how we can handle your comments, because some of comments just reset our 5 yrs achievements. 
I would like to see the comments from AUTOCONF members. 

thanks,
ryuji



On 2010/07/09, at 13:52, Erik Nordmark wrote:

> 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
> _______________________________________________
> Autoconf mailing list
> Autoconf@ietf.org
> https://www.ietf.org/mailman/listinfo/autoconf