Re: [Autoconf] Autoconf addressing model

"Teco Boot" <> Thu, 05 March 2009 07:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 07D1D28C11E for <>; Wed, 4 Mar 2009 23:50:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.695
X-Spam-Status: No, score=-1.695 tagged_above=-999 required=5 tests=[AWL=0.351, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id vY2Ej1e8k3GD for <>; Wed, 4 Mar 2009 23:50:25 -0800 (PST)
Received: from (hpsmtp-eml19.KPNXCHANGE.COM []) by (Postfix) with ESMTP id EB9B228C106 for <>; Wed, 4 Mar 2009 23:50:24 -0800 (PST)
Received: from ([]) by with Microsoft SMTPSVC(6.0.3790.3959); Thu, 5 Mar 2009 08:50:52 +0100
Received: from M90Teco ([]) by with Microsoft SMTPSVC(6.0.3790.3959); Thu, 5 Mar 2009 08:50:52 +0100
From: "Teco Boot" <>
To: "'Alexandru Petrescu'" <>
References: <> <> <><000001c99845$1dc56190$595024b0$@nl> <><1235680887.4585.5.camel@localhost> <002f01c998bf$8f112210$ad336630$@nl><> <007201c99903$c4182c80$4c488580$@nl><> <007b01c99911$907facf0$b17f06d0$@nl><> <009501c99920$92154340$b63fc9c0$@nl><> <003001c99b2c$a3fcf4a0$ebf6dde0$@nl><> <000101c99c3c$3121a870$9364f950$@nl><> <><> <><> <> <> <> <> <000c01c99ce9$e09bf500$a1d3df00$@nl> <> <000101c99d00$664c7f60$32e57e20$@nl> <49A m>
In-Reply-To: <>
Date: Thu, 5 Mar 2009 08:50:52 +0100
Message-ID: <001701c99d67$1bb4b5f0$531e21d0$@nl>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AcmdI0+AYp+eHSrVRZewbth4ppMY1AAQQbbQ
Content-Language: nl
X-OriginalArrivalTime: 05 Mar 2009 07:50:52.0761 (UTC) FILETIME=[1BA2B490:01C99D67]
Subject: Re: [Autoconf] Autoconf addressing model
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: Thu, 05 Mar 2009 07:50:32 -0000

|-----Oorspronkelijk bericht-----
|Van: Alexandru Petrescu []
|Verzonden: donderdag 5 maart 2009 0:45
|Aan: Teco Boot
|CC: 'Alexandru Petrescu'; 'Stan Ratliff (sratliff)';
|Onderwerp: Re: [Autoconf] Autoconf addressing model
|Teco Boot a écrit :
|> Inline.
|> |-----Oorspronkelijk bericht-----
|> |Van: Alexandru Petrescu []
|> |Verzonden: woensdag 4 maart 2009 18:20
|> |Aan: Teco Boot
|> |CC: 'Alexandru Petrescu'; 'Stan Ratliff (sratliff)';
|> |Onderwerp: Re: [Autoconf] Autoconf addressing model
|> |
|> |Teco Boot a écrit :
|> |> Alex,
|> |>
|> |> It happen to be I am working on the customer side, not the
|> |> vendor / supplier side. I can say your limitations for 25meter and
|> |> requirement for relay nodes with multiple interfaces are far, far
|> |> from acceptable. I go for what Stan says. Sorry, I cannot go into
|> |> details on what the specs are. I am not in the position to say you,
|> |> this is not the medium to publish and moreover, there is no need
|> |> these details. We in IETF never went in this before (e.g. there is
|> |> range limitation for ICMP messages).
|> |
|> |I meant to say to explicitely consider the characteristics of the
|> |link-layers you consider for AUTOCONF ad-hoc networks.  These all
|> |specifications about their physical lengths (for wired), for dbm
|> |powerlevels and range in meters (wireless).
|> The problem with this is that it is of almost no use for an ad hoc
|> Ad hoc means "to this", "for this purpose". It refers to dealing with
|> special situations as they occur rather than functions that are
|repeated on
|> a regular basis. ( Or "created on
|> spur of the moment, impromptu" (
|Along these lines, an interpretation of 'ad-hoc' is a happening which
|hasn't been planned, spontaneous, etc.  This would contradict the goal
|of planning an addressing architecture for it, unless the limits of
|movement and the characteristics of the underlying link-layers are

There is a difference in a) designing and building a network, ready for
deployment and b) planning for actual deployment. In military, actual
deployment does not occur quite often (luckily!), but it is exercised
repeatedly. For public safety / disaster relief, the network is often in use
for normal conditions (no disaster), here we may have restrictions as you
suggest. But as soon as there is a disaster (small, large), the conditions
may no longer be true. Here also, the large disasters do not occur
frequently. But if it occurs, damage can be huge. 
For both use cases (military and disaster relief), the requirement is that
the network provides as much connectivity as technically possible, also in
unforeseen conditions. Sorry to bother you with one of the major
requirements I am facing, and I am sure I am not the only one. As said,
MANET is being worked on for many years and actually being deployed.

I described the difference in designing and planning deployment. For
designing the network, we need components that have certain characteristics,
e.g. working well in an ad hoc (unplanned) fashion. IMHO this means, that
when a radio link works well over 25 meter, and it is being used in 30 meter
or an obstacle breaks the link or makes it uni-directional (see my diagrams
for details), the network may not melt down. Connectivity should restored
using alternative paths if available and feasible.

Let's go on with refinement an address model for MANETs. This is more
important than quarreling on 25m or analyzing wording, I think.