Re: [Autoconf] Autoconf addressing model

"Charles E. Perkins" <charles.perkins@earthlink.net> Wed, 04 March 2009 17:35 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 682E128C3C1 for <autoconf@core3.amsl.com>; Wed, 4 Mar 2009 09:35:03 -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 DLKaPxGZwLNJ for <autoconf@core3.amsl.com>; Wed, 4 Mar 2009 09:35:02 -0800 (PST)
Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by core3.amsl.com (Postfix) with ESMTP id 6BFDC28C36B for <autoconf@ietf.org>; Wed, 4 Mar 2009 09:35:02 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=cSW8pWG/+gES4grGBUGP2fPMEwnbe1/oEqd7KXqc04yYVeHr7zboZpVCNsazYy8k; 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-mealy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from <charles.perkins@earthlink.net>) id 1Lev0E-0005pj-EH; Wed, 04 Mar 2009 12:35:30 -0500
Message-ID: <49AEBBD1.20308@earthlink.net>
Date: Wed, 04 Mar 2009 09:35:13 -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> <49ADB9FB.6050600@earthlink.net> <49AE3A3A.5000305@gmail.com>
In-Reply-To: <49AE3A3A.5000305@gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f529782536382f400f48300bad175a249ec350badd9bab72f9c350badd9bab72f9c
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: Wed, 04 Mar 2009 17:35:03 -0000

Hello Alex,

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

This 25m radius is not legislated nor approved by the working group.
I don't see anyone else supporting your contention here, and I think the
sooner we resolve that there is no such limitation, the better.

Which then almost immediately invalidates your observation about DNS
and DHCP servers.

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

I maintain that it is not necessary, not always possible, and thus
not relevant to the discussion.

>
> .  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
> communications.
>
> Would you agree such a subnet makes sense?  Does not make sense?

By now I hope it is clear that I don't agree with equating subnets
with physical extents.

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

If you don't have aggregation, you don't have any reason
to define subnets.  Of course if you don't have aggregation,
you can just as easily live with host routes.  Which is my
point all along.

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

Surely, if we have economically realizable subnets, we should
take advantage of them.  That is not at all the same as insisting
that we _must_ have subnets, or even worse distorting physical
reality to lend credence to some fictional subnet boundaries.

Regards,
Charlie P.