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

Thomas Heide Clausen <> Fri, 23 July 2010 08:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 480113A698C for <>; Fri, 23 Jul 2010 01:15:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id R0xduqVySbsh for <>; Fri, 23 Jul 2010 01:15:17 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id DC7EB3A6841 for <>; Fri, 23 Jul 2010 01:15:17 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 37F903236DB1; Fri, 23 Jul 2010 01:15:36 -0700 (PDT)
X-Virus-Scanned: Debian amavisd-new at
Received: from [] ( []) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 1CD923228050; Fri, 23 Jul 2010 01:15:34 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1078)
Content-Type: text/plain; charset=iso-8859-1
From: Thomas Heide Clausen <>
In-Reply-To: <>
Date: Fri, 23 Jul 2010 10:15:33 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <>
To: Alexandru Petrescu <>
X-Mailer: Apple Mail (2.1078)
Cc:, "Dearlove, Christopher \(UK\)" <>
Subject: Re: [Autoconf] RFC 5889 (Was: Call for comments to a new AUTOCONF charter proposal)
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, 23 Jul 2010 08:15:19 -0000

On Jul 23, 2010, at 10:11 , Alexandru Petrescu wrote:

> Le 23/07/2010 09:51, Henning Rogge a écrit :
>> On Fri July 23 2010 09:43:02 Alexandru Petrescu wrote:
>>>> if each of the MRs use a wireless interface, the linklocals WILL
>>>> BE VISIBLE outside their direct link.
>>> Well, the link local addresses will not be visible outside their
>>> direct link, because the different links are on different ESSIDs
>>> and moreover on different channels.  Using wireshark on IP packets
>>> on these different links shows that the link local addressess are
>>> not visible from one link to another.
>> This would only work with preplanned links,
> Most deployments have a high degree of planning.

Then, they're (by definition) not ad-hoc networks.

>> because otherwise you would have trouble to do neighborhood
>> detection. How do you detect new nodes coming into range if they
>> cannot announce their presence with a broadcast, because they got no
>> unique ESSID to their neighbors ?
> Well good question - and I have tried.  The difficult thing is the first
> detection - the "wifi scan" phase; once the drivers have their data set
> up then re-detection is very fast, in the order of tens of milliseconds.
> We could use that to signal between two approaching vehicles.
> More specifically, on WiFi, a beacon is sent periodically, but there are
> also periodic requests replied with a beacon.  These help a lot to
> detect presence of a neighbor previously learned, and fast.
>> MANET routing protocols are specially designed for the case of
>> unplanned networks. You have a single shared medium which the routing
>> protocol use for it's work, to do neighborhood/link detection.
> Well very good.  Is there a case where wireless multi-hop networks are
> possible _without_ MANET routing protocols?  I believe yes, and I
> prototyped and demo.

Very well, but then that's not a MANET.

> Besides, there exist deployments where even though the MRs are mobile
> they stay relatively fixed with respect to each other, in some very
> simple topology: truck convoy, wagons in a train, etc.  These things
> stay formed for long hours and reform right after.  These things don't
> need the power of MANET routing protocols because there are never loops
> formed at link layer, the topology is really simple.

Very well, but then that's not a MANET.

Alex, can we agree that things that are not MANETs tautologically are not MANETs?


>> If you push this down to link layer, you just move the whole problem
>> down one layer, because you need unique addresses on the link layer
>> to do neighborhood detection and link establishment.
> WEll yes... I tend to agree.
> However, one would avoid to bring existing link layer mechanisms up to
> the IP stack too.  These link layer mechanisms are there and work very
> well in their domain.
> The IP stack is not fast enough on the CPU to work at vehicular speeds,
> interruptable by some GUI or heavy TCP.
> The link layer driver executing on a dedicated chipset is much more
> reliable for these kinds of movements.
>> If you already have a unique link-layer address, just use it to
>> generate a unique linklocal-IP.
> Hmmm... right, that's how link local addresses are generated.
> Alex
>> Henning Rogge