Re: [Autoconf] WC consensus call for RFC5889 modifications (Fwd:Forgotone [Was: RFC 5889)

Thomas Heide Clausen <> Fri, 06 August 2010 17:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 932533A6892 for <>; Fri, 6 Aug 2010 10:22:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 1.376
X-Spam-Level: *
X-Spam-Status: No, score=1.376 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_WEB=0.619]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id bQEmzCmK+doj for <>; Fri, 6 Aug 2010 10:22:57 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 435003A6879 for <>; Fri, 6 Aug 2010 10:22:57 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 13B5B3236DB7; Fri, 6 Aug 2010 10:23:29 -0700 (PDT)
X-Virus-Scanned: Debian amavisd-new at
Received: from [] (unknown []) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id DE5783236DB8; Fri, 6 Aug 2010 10:23:27 -0700 (PDT)
References: <> <> <> <> <> <> <> <>
In-Reply-To: <>
Mime-Version: 1.0 (iPhone Mail 8A293)
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=utf-8
Message-Id: <>
X-Mailer: iPhone Mail (8A293)
From: Thomas Heide Clausen <>
Date: Fri, 6 Aug 2010 19:22:32 +0200
To: "Charles E. Perkins" <>
Cc: "" <>, Emmanuel Baccelli <>
Subject: Re: [Autoconf] WC consensus call for RFC5889 modifications (Fwd:Forgotone [Was: RFC 5889)
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 06 Aug 2010 17:22:58 -0000


You suggest a face-to-face meeting. As you know I will be in your neck of the woods next week, so let's discuss, then ...


If we do that, we do owe it to the wg to report both the arguments and the outcome of the discussions here on the list, as I believe that both are valuable for the wg. Although (still wearing that hat) I would very much like for as much of the discussions to be in public (ie on the list)....


I'll respond in more details later, but I have suitcases to pack ...

Thomas Clausen

On 6 août 2010, at 18:56, "Charles E. Perkins" <> wrote:

> Hello Thomas,
> I said:
>>> Do you _really_ want to exclude hosts from your network?
>>> Where will the applications reside?
> You said:
>> User applications (regular user applications) reside on hosts. Hosts are
>> accessing the network by way of being connected to (i.e. one IP hop away
>> from) a router.
> Of course I do not have a problem with running applications
> on MANET routers.  I have proposed this for many years --
> and in fact I do not in any way require that the applications
> reside on hosts that are one hop away from a router.
> My question was partly in jest -- but I do fully
> expect that non-routing hosts will be found in many
> or perhaps even most ad hoc networks.  For instance,
> we will have sensor fields and transmit-only data
> aggregators (both of which do not need to be routers,
> but are likely to need addresses).  I keep thinking
> this is totally obvious!
>> The connectivity between a host and a router is a "classic IP link",
>> and there are already excellent protocols in existence for managing
>> also autoconfiguration of addresses for hosts on classic IP links.
> My objection has been to disqualify non-routing hosts from receiving
> addresses by way of an [autoconf] protocol.  There are of course known
> protocols (excellent or not, does not matter here) for configuring
> "classic hosts" on "classic IP links".  I reckon we mean the same
> thing by those terms.
> My point is that there are almost certainly going to be non-routing
> hosts in <networks whose connectivity is established by MANET routers.>
> I would have just said "MANETs", but now we have so little agreement
> that we don't even know what a MANET is any more.
>> The connectivity between routers is.....who knows? Maybe a MANET,
>> maybe an OSPF network, maybe an ISIS network, and maybe links between
>> routers have "undetermined connectivity properties" -- or not, they
>> may be of NBMA or P2P or telepathic nature. However, that's a matter
>> for routers to figure out and manage; hosts are exposed to a classic
>> IP link and are isolated by an IP hop from any specific connectivity
>> properties of the connectivity/links between routers.
> Here I have to disagree.  A host may have an 802.11 link to a router,
> and be subject to every single last problem of indeterminate range,
> interference, link-local ambiguity, and the other concepts which have
> proved so difficult for [autoconf] to resolve (regardless of so much
> reputable research available).
> And, moreover, it's not up to the "routers".  It's up to "us",
> because we're designing the routers (at least in [manet] wg,
> not in [autoconf]).  Moreover, if a MANET router can work better
> by transacting new protocol with a host, then (a) the host may
> then considered to be something besides a "classic host", and
> (b) why not?  Let's figure it out.  But this does NOT mean that
> a network of the abovementioned variety has to REQUIRE changes
> to classic hosts; as an example, NEMO has made a lot of changes
> but still allows "classic" hosts to reside on mobile networks.
> Our situation is a bit different, insofar as mobile wireless hosts
> still must pay due respect to the realities of wireless.
>> Of course, there *may* be applications (for example, the routing demon)
>> running on routers and exposed to the specific connectivity properties
>> of the connectivity/links between routers. These, and only these
>> (non-user) applications should be sufficiently aware of these properties
>> to operate correctly. User-applications reside on hosts, separated by
>> an IP hop from any "strangeness" between routers, and exposed to
>> well-defined properties of a classic IP link.
> I also disagree with this.  Numerous studies have shown that
> applications can benefit from knowledge of bit-error rate,
> link capacity, jitter, and so on.  Of course we'd prefer that
> applications not have to pay attention to CDMA vs. 802.11,
> etc.  Nevertheless, I am sure that in a face-to-face meeting
> on this subject we would quickly find that we are in substantially
> complete agreement.
>>>> >> This architectural consideration thus separated the issue of
>>>> >> "configuring routers" from the issue of "configuring hosts" in this
>>>> >> context, and the rough consensus was that we would first focus on
>>>> >> configuring routers. Which lead us to where we are now.
> ...
>> This particular point was discussed - at length - at IETF'67 in 2006 in
>> San Diego, where it received (in my recollection) wide consensus; in part
>> because of its analogy with the "regular Internet".
> Surely, "configuring" routers and hosts should be
> done differently.  This does NOT imply:
> (a) hosts should be barred from using the address
>    allocation protocol established for MANET routers, or
> (b) hosts should run useless router code in order to
>    make use of said address allocation protocol, or
> (c) the [autoconf] address allocation protocol design
>    should proceed on the assumption that non-routing
>    hosts are out of scope.
> Regards,
> Charlie P.
> _______________________________________________
> Autoconf mailing list