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

Erik Nordmark <erik.nordmark@oracle.com> Thu, 29 July 2010 11:49 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 A46C73A6980 for <autoconf@core3.amsl.com>; Thu, 29 Jul 2010 04:49:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.284
X-Spam-Level:
X-Spam-Status: No, score=-6.284 tagged_above=-999 required=5 tests=[AWL=0.315, 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 CwE1DCOBAUTK for <autoconf@core3.amsl.com>; Thu, 29 Jul 2010 04:49:47 -0700 (PDT)
Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 0772128C153 for <autoconf@ietf.org>; Thu, 29 Jul 2010 04:49:46 -0700 (PDT)
Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o6TBo7PF032758 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 29 Jul 2010 11:50:09 GMT
Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o6TBo3r0032003; Thu, 29 Jul 2010 11:50:04 GMT
Received: from abhmt007.oracle.com by acsmt355.oracle.com with ESMTP id 448166991280404173; Thu, 29 Jul 2010 04:49:33 -0700
Received: from [10.7.251.248] (/10.7.251.248) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 29 Jul 2010 04:49:33 -0700
Message-ID: <4C516AC9.8030803@oracle.com>
Date: Thu, 29 Jul 2010 04:49:29 -0700
From: Erik Nordmark <erik.nordmark@oracle.com>
User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.9) Gecko/20100607 Lightning/1.0b1 Thunderbird/3.0.4
MIME-Version: 1.0
To: Jari Arkko <jari.arkko@piuha.net>
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: 7bit
X-Source-IP: acsmt355.oracle.com [141.146.40.155]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090201.4C516AED.0351: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: Thu, 29 Jul 2010 11:49:48 -0000

On 07/21/10 07:40 AM, Jari Arkko wrote:
> Erik,
>
>> 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.
>
> OK, though I suspect that Section 1 paragraph 3 and Section 6.1 bullet 2
> still says almost everything there is to say about the rest, too.
> Nevertheless, there is a proposal for title change. Perhaps a critical
> issue was not making it clear enough in the document that its not just
> about router addressing, but also just _a_ model, not _the_ model. I
> asked the working group to document one practical model for addressing
> rather than cover all possible options, as their work in trying to do
> the latter had stalled.

OK

>> 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.
>
> This may have been an issue in the document as approved, but I do not
> think there is an implication left in the text with the proposed changes
> folded in.

Apart from the issue below related to link-locals that are globally unique.

> More importantly, as the document correctly states there are differences
> in the requirements that routing protocols place on available addresses.
> I think the document makes a very pragmatic model choice in this light.
>
>> 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.
>
> I agree about the distinction, of course. But I re-read the document
> today but cannot see where the document claims otherwise.

It does say
    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.
and later
    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).

If we strike out the first cited paragraph, and clarify the second cited 
one to say:
    o  In general there is no mechanism to ensure that IPv6 link-local
       addresses are unique across multiple links, however link-local
       addresses using an IID that is of the modified EUI-64 form is
       globally unique. Thus if link-local addresses are used to reliably
       identify routers then they must be of the modified EUI-64 form.



>> 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.

I disagree. My proposed edit above would take care of the issue though.

>> 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.

OK

> 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.

Which mechanism do we have to test that a global IPv6 address is in fact 
globally unique? I certainly don't know of one.

We rely on assumptions that the IPv6 prefixes are uniquely delegated by 
the IANA, RIRs, site subnet number allocating admin, etc down to each 
host. For the EUI-64 we rely on the assumption that the IEEE RAC and the 
vendors uniquely allocate EUI-64s. In neither case do we have a test.

>> 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.

As I said, I have no issue with the final recommendation that
    Therefore, autoconfiguration solutions should be encouraged to
    primarily focus on configuring IP addresses that are not IPv6 link-
    local.

But the text that makes that argument is fundamentally confused about 
the uniqueness issues around link-locals, and also tries to argue things 
from a router perspective when the main argument is that applications 
want something wider than link locals.

I suggest splitting this item into two.
FROM
    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.
TO
    o  Routers often need to be reachable at a global address for
       management purposes.

    o  Routers cannot forward any packets with link-local source or
       destination addresses to other links (as per [RFC4291]) while most
       of the time, applications assume that routers can forward packets
       to/from different links.

If you don't want to add the "management" bullet that is fine with me. 
But the second bullet should be about applications.

    Erik