Re: [Autoconf] Autoconf addressing model

Alexandru Petrescu <> Wed, 04 March 2009 08:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0EC7628C2BC for <>; Wed, 4 Mar 2009 00:22:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HELO_EQ_FR=0.35]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id vF9Xy-fCSW4Q for <>; Wed, 4 Mar 2009 00:22:03 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id D301828C184 for <>; Wed, 4 Mar 2009 00:22:01 -0800 (PST)
Received: from (localhost []) by (Postfix) with ESMTP id A8C6FD480DE; Wed, 4 Mar 2009 09:22:25 +0100 (CET)
Received: from [] ( []) by (Postfix) with ESMTP id 77798D48135; Wed, 4 Mar 2009 09:22:22 +0100 (CET)
Message-ID: <>
Date: Wed, 04 Mar 2009 09:22:18 +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-2, 04/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: Wed, 04 Mar 2009 08:22:04 -0000

Charles E. Perkins a écrit :
>>> That's fine, as long as the destination is addressable within a 
>>> subnet.  If the destination does not live on a subnet, why not 
>>> use a host route (i.e., /128 address)?
>> Because it wouldn't allow the AUTOCONF network to grow larger and 
>> more dynamic.
> Just saying "subnet" doesn't do that either, though.  In fact, the 
> signaling to support subnets could (conceivably) be even more 
> complicated than the signaling to support host routes.

I agree link-layer signalling within each subnet, for the purpose of
maintaining that subnet coherent, may contain numerous messages.

>>>> -I would avoid the assumption that an ad-hoc router maintains a
>>>>  stable IP address while moving around.
>>> Then you will have trouble.  There is no free lunch. Either: (a) 
>>> the IP address stays the same, and the routes change, or (b) the 
>>> IP address changes, and there is a resolver to associate the IP 
>>> address with some other identifier.
>>> Since the design of the resolver in (b) is an unknown and 
>>> arguably much more difficult, I'll take (a) with a great sigh of 
>>> relief.
>> Resolvers such as (m)DNS or some DHCP features could work I 
>> believe.  I don't understand why it's claimed much more difficult.
> I assure you it is not trivial to implement DNS or DHCP inside an ad 
> hoc network.  Most of the proposals I have seen for this have located
>  the function _outside_ the ad hoc network, for convenient and 
> straightforward access when connectivity is actually available.

Well if the subnet structure is coherent and things don't move around
too much then putting a DNS Server or a DHCP Server in the ad-hoc
network should be easy.

By not moving too much I mean each node not moving out of its 25meter

> Watching your DNS server [(m) or not!] move from place to place in an
>  ad hoc network, sometimes finding itself partitioned from your 
> favorite node, could be an exciting and enlightening adventure.

I agree we could find very dynamic ways of Routers and Hosts of an
ad-hoc network moving in and out such that subnet structure is not
maintained, and thus servers not being reachable.  But unless we
describe these movements we can't deal with them.

>>> Who said we had to avoid size limits?
>> Well we don't have size limits in the charter proposal, we don't 
>> have agreement on '25m IPv6 subnets', we don't have limits on the 
>> types of the link layers involved.
> If you are talking about an ad hoc network with 25,000,000 subnets, 
> then I am basically not on the same page.  And not in the same 
> decade.

Sorry I meant 25meters not millions.  A '25m IPv6 subnet' would be a
wireless coverage area of radius 25meter, without obstacles, and within
which there are only exposed terminals, fully transitive and symmetric

Would you agree such a subnet makes sense?  Does not make sense?

>> However, your question seems to imply you think there may be a 
>> limit: AUTOCONF network is small enough to accommodate host-based 
>> routes.  Is it this?
> I think the network has to accomodate the routes needed for 
> connectivity to destinations within the network.
> Again, just saying "subnet" doesn't buy even one gram of additional 
> scalability.  You need more.
> You need a procedure for enabling aggregation. Such a procedure is 
> not always available.

If by aggregation is meant addressing aggregation (as Teco also
proposes a /60 prefix assigned to several Routers themselves assigning
/64 prefixes to their links) then I think we should not strive to
respect aggregation.  Address aggregation wouldn't make sense if we talk
host-based routes either.

>>> Well, to me it did sound very negative.  Moreover, I think it is 
>>> just fine to pass around subnet prefixes, if you have subnets.
>> Charles, yes - the subnets are there first, before IP.  Once the 
>> link is up the subnet is the set of nodes on it.  In this sense I 
>> agree it is just fine to pass subnet prefixes around.
> This is wrong*2.   First, there is IP, which fixes the address format
>  and address modes.  Then there are subnets. Some people here
> probably remember when the word "subnet" starting coming into more
> active use.
> Second, just because nodes are reachable over the air as neighbors, 
> does not imply they are on the same IP subnet.  Trying to maintain 
> otherwise leads to madness.
> Surely you will agree.  A subnet is an abstraction to support more 
> efficient routing.  It is not a wire or a piece of plastic or a 
> contiguous region of space.

I can live with that.

However, I think the simplest cases we have to deal with have very
simple subnet structure that we should take advantage of.