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
>