Re: [Autoconf] Autoconf addressing model

Alexandru Petrescu <> Tue, 03 March 2009 21:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2055A3A67D6 for <>; Tue, 3 Mar 2009 13:18:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.127
X-Spam-Status: No, score=-2.127 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599, HELO_EQ_FR=0.35]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 09DHt8pCrQVX for <>; Tue, 3 Mar 2009 13:18:17 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 1B00B3A69A0 for <>; Tue, 3 Mar 2009 13:18:15 -0800 (PST)
Received: from (localhost []) by (Postfix) with ESMTP id E0C544C815C; Tue, 3 Mar 2009 22:18:38 +0100 (CET)
Received: from [] ( []) by (Postfix) with ESMTP id 464014C819D; Tue, 3 Mar 2009 22:18:35 +0100 (CET)
Message-ID: <>
Date: Tue, 03 Mar 2009 22:18:32 +0100
From: Alexandru Petrescu <>
User-Agent: Thunderbird (Windows/20081209)
MIME-Version: 1.0
To: "Charles E. Perkins" <>
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> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-Antivirus: avast! (VPS 090303-1, 03/03/2009), Outbound message
X-Antivirus-Status: Clean
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: Tue, 03 Mar 2009 21:18:18 -0000

Charles - overall:
-I don't find it advantageous to specify an addressing architecture
  talking about virtual interfaces, be they loopback interfaces; rather
  I'd describe real interfaces.
-I find it more advantageous to describe stable subnets, with prefixes
  (between /48 and /64) exchanged around, rather than /128s.
-I would avoid the assumption that an ad-hoc router maintains a
  stable IP address while moving around.

For details, see below.


The churning aspect of host-based routes was just one argument against
/128s and finally against loopback/virtual interfaces.

Of course, host-based routes could work in some networks, mainly
depending on their size and way of moving.

Charles E. Perkins a écrit :
> Hello Alex,
> Alexandru Petrescu wrote:
>> Teco, the problem is simple: host-based routes are not preferrable.
> Why is that?

BEcause we simply don't know the size of the network in which they could
work.  And that apparently it is avoided to put any limit on size of any

Even approximative evaluations of the size of the network in which these
host-based routes would work aren't preferred by many.

>> Host-based routes in routers surrounding router X (this is what a 
>> /128 address on a virtual interface on router X implies, be that 
>> loopback interface or not loopback interface) for a dynamically 
>> changing topology may lead to too many routes coming up and down, 
>> too many specific entries in the routing tables, too much dedicated
>>  routing messaging, and more.
> This magically "forgets" the last 10 years of development for ad hoc 
> networking protocols.  Do you think this work was somehow invalid? 
> Solving the problems you mentioned was, after all, the entire point 
> of the work.

Sorry for having sounded neglecting the results of ad-hoc networking
protocols.  It was not the intention.  I believe some protocols could be
used to propagate prefixes - instead of /128s - and may be more
efficient, grow the network larger.

>> Connecting it to the Internet, with host-based routes propagated up
>>  and down throughout, may risk influencing the routes in the 
>> Internet proper. A new host-based route inserted in the routing 
>> table of the gateway connecting this network to the Internet may 
>> propagate throughout the entire fixed access system.
> That would be the result of somebody making very poor design and 
> configuration choices on the gateway.
> Presumably we can make a specification that would avoid such bad 
> design choices.  I say this, because I have myself been involved with
>  design efforts where we already did it at least two or three times.

Well yes, that's a good point, worth mentioning raw like that.

There is an additional way achieving it: using ULAs, they wouldn't
propagate, because their own nature.  They wouldn't be reachable either.

These aspects could be mentioned.