Re: [Autoconf] Autoconf addressing model

Alexandru Petrescu <alexandru.petrescu@gmail.com> Tue, 03 March 2009 22:30 UTC

Return-Path: <alexandru.petrescu@gmail.com>
X-Original-To: autoconf@core3.amsl.com
Delivered-To: autoconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EAA553A6973 for <autoconf@core3.amsl.com>; Tue, 3 Mar 2009 14:30:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.132
X-Spam-Level:
X-Spam-Status: No, score=-2.132 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599, HELO_EQ_FR=0.35]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8yyfQ0YtPNLx for <autoconf@core3.amsl.com>; Tue, 3 Mar 2009 14:30:04 -0800 (PST)
Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by core3.amsl.com (Postfix) with ESMTP id B980C3A6A97 for <autoconf@ietf.org>; Tue, 3 Mar 2009 14:30:02 -0800 (PST)
Received: from smtp1-g21.free.fr (localhost [127.0.0.1]) by smtp1-g21.free.fr (Postfix) with ESMTP id 869E8940019; Tue, 3 Mar 2009 23:30:25 +0100 (CET)
Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id 328D39400C4; Tue, 3 Mar 2009 23:30:23 +0100 (CET)
Message-ID: <49ADAF7C.1050509@gmail.com>
Date: Tue, 03 Mar 2009 23:30:20 +0100
From: Alexandru Petrescu <alexandru.petrescu@gmail.com>
User-Agent: Thunderbird 2.0.0.19 (Windows/20081209)
MIME-Version: 1.0
To: "Charles E. Perkins" <charles.perkins@earthlink.net>
References: <499F0BA7.90501@piuha.net> <7E8A76F7-2CE0-463A-8EE8-8877C46B4715@gmail.com> <49A6D436.7020505@gmail.com> <000001c99845$1dc56190$595024b0$@nl> <49A6F125.40400@gmail.com> <1235680887.4585.5.camel@localhost> <002f01c998bf$8f112210$ad336630$@nl> <49A7E58C.2020303@gmail.com> <007201c99903$c4182c80$4c488580$@nl> <49A82E55.10208@gmail.com> <007b01c99911$907facf0$b17f06d0$@nl> <49A8471E.6090506@gmail.com> <009501c99920$92154340$b63fc9c0$@nl> <49A944FF.9000102@gmail.com> <003001c99b2c$a3fcf4a0$ebf6dde0$@nl> <49AD5184.6080300@gmail.com> <000101c99c3c$3121a870$9364f950$@nl> <49AD9760.3080909@gmail.com> <49AD98D4.3@earthlink.net> <49AD9EA8.6040803@gmail.com> <49ADA17B.9040600@earthlink.net>
In-Reply-To: <49ADA17B.9040600@earthlink.net>
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
Cc: autoconf@ietf.org
Subject: Re: [Autoconf] Autoconf addressing model
X-BeenThere: autoconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/autoconf>
List-Post: <mailto:autoconf@ietf.org>
List-Help: <mailto:autoconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Mar 2009 22:30:05 -0000

Charles E. Perkins a écrit :
> 
> Hello Alex,
> 
> Alexandru Petrescu wrote:
>> 
>> -I find it more advantageous to describe stable subnets, with
>> prefixes (between /48 and /64) exchanged around, rather than /128s.
>> 
> 
> 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.

>> -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.

>> The churning aspect of host-based routes was just one argument
>> against /128s and finally against loopback/virtual interfaces.
> 
> Are the other arguments easily summarized in a few words?

No :-) sorry

>> Of course, host-based routes could work in some networks, mainly 
>> depending on their size and way of moving.
> 
> This is true.  I don't see what's wrong with it.
> 
>> 
>> 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 kind.
> 
> 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.

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?

>> Even approximative evaluations of the size of the network in which
>> these host-based routes would work aren't preferred by many.
> 
> I must have missed that, sorry.  Those "many" didn't often assert 
> their preferences in the [manet] working group.

Ok, it was my own interpretation.

>>> 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.
> 
> 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.

Thanks for the message,

Alex