Re: [Autoconf] Autoconf addressing model

"Charles E. Perkins" <charles.perkins@earthlink.net> Tue, 03 March 2009 23:14 UTC

Return-Path: <charles.perkins@earthlink.net>
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 61F3C3A67CC for <autoconf@core3.amsl.com>; Tue, 3 Mar 2009 15:14:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 DnAbtRQvSOCN for <autoconf@core3.amsl.com>; Tue, 3 Mar 2009 15:14:40 -0800 (PST)
Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by core3.amsl.com (Postfix) with ESMTP id 58A1B3A6814 for <autoconf@ietf.org>; Tue, 3 Mar 2009 15:14:40 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=l7R46lVJloo2+i30U8tXcbkvawyy91cg3QyZ9t1rqZ26Kk03RWB5uB6Ik9X+rIMR; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP;
Received: from [99.138.86.46] (helo=[192.168.1.104]) by elasmtp-scoter.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from <charles.perkins@earthlink.net>) id 1LedpL-0003UV-CZ; Tue, 03 Mar 2009 18:15:07 -0500
Message-ID: <49ADB9FB.6050600@earthlink.net>
Date: Tue, 03 Mar 2009 15:15:07 -0800
From: "Charles E. Perkins" <charles.perkins@earthlink.net>
Organization: Wichorus Inc.
User-Agent: Thunderbird 2.0.0.19 (Windows/20081209)
MIME-Version: 1.0
To: Alexandru Petrescu <alexandru.petrescu@gmail.com>
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> <49ADAF7C.1050509@gmail.com>
In-Reply-To: <49ADAF7C.1050509@gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f528ddb54621b1b0b9d32729b63824c8546350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 99.138.86.46
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 23:14:41 -0000

Hello Alex,


Alexandru Petrescu wrote:
>
>>
>> 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 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.

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.

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

Well, then I reserve the right to be very skeptical about their validity.

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


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

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

Regards,
Charlie P.