Re: [Autoconf] Autoconf addressing model

"Stan Ratliff (sratliff)" <sratliff@cisco.com> Wed, 04 March 2009 14:40 UTC

Return-Path: <sratliff@cisco.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 79A123A68F6 for <autoconf@core3.amsl.com>; Wed, 4 Mar 2009 06:40:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 HVDSJT+5CL1C for <autoconf@core3.amsl.com>; Wed, 4 Mar 2009 06:40:14 -0800 (PST)
Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id E351B3A68AD for <autoconf@ietf.org>; Wed, 4 Mar 2009 06:40:13 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.38,301,1233532800"; d="scan'208";a="38984837"
Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 04 Mar 2009 14:40:41 +0000
Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n24EefEs014431; Wed, 4 Mar 2009 09:40:41 -0500
Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n24EefDh023077; Wed, 4 Mar 2009 14:40:41 GMT
Received: from xmb-rtp-208.amer.cisco.com ([64.102.31.43]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Mar 2009 09:40:41 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 04 Mar 2009 09:40:40 -0500
Message-ID: <7FB7EE0A621BA44B8B69E5F0A09DC76407B5D783@xmb-rtp-208.amer.cisco.com>
In-Reply-To: <49AE3A3A.5000305@gmail.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Autoconf] Autoconf addressing model
Thread-Index: Acmcol9Dy08x3ZdJSlOzpqBHCEjg3gAMpTAg
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>
From: "Stan Ratliff (sratliff)" <sratliff@cisco.com>
To: Alexandru Petrescu <alexandru.petrescu@gmail.com>, "Charles E. Perkins" <charles.perkins@earthlink.net>
X-OriginalArrivalTime: 04 Mar 2009 14:40:41.0544 (UTC) FILETIME=[31477C80:01C99CD7]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6787; t=1236177641; x=1237041641; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sratliff@cisco.com; z=From:=20=22Stan=20Ratliff=20(sratliff)=22=20<sratliff@cisc o.com> |Subject:=20RE=3A=20[Autoconf]=20Autoconf=20addressing=20mo del |Sender:=20 |To:=20=22Alexandru=20Petrescu=22=20<alexandru.petrescu@gma il.com>,=0A=20=20=20=20=20=20=20=20=22Charles=20E.=20Perkins =22=20<charles.perkins@earthlink.net>; bh=gHwWXwxieuAtwHGPW72ouFRl20kbW4ByIxr2Z+MJsE8=; b=PSiier/8j3P9xZ4nK2K73gwK1hBWX1hGBtfjGYC23NavD46XqX4c1cAAKz 3Nuc6+u97zTxl//UeoLcPmAhGZfL/1HfTMIAdd02KAJ+xeHk88OSj3Uh0Sbz /DgT5TUgCF;
Authentication-Results: rtp-dkim-1; header.From=sratliff@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; );
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 14:40:15 -0000

Inline.
 

> -----Original Message-----
> From: autoconf-bounces@ietf.org 
> [mailto:autoconf-bounces@ietf.org] On Behalf Of Alexandru Petrescu
> Sent: Wednesday, March 04, 2009 3:22 AM
> To: Charles E. Perkins
> Cc: autoconf@ietf.org
> Subject: Re: [Autoconf] Autoconf addressing model
> 
> 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 radius.
> 

We've already been over the 25m subnet thing. It's a non-starter. Limiting movement, or mandating that a DHCP or DNS server is always on and available is also a non-starter. 25m subnets with "always on" DNS/DHCP servers sounds to me like a few guys gathering together to play "Doom" at their local coffee shop. I deploy MANET networks for governmental applications. Think disaster recovery, like after Hurricane Katrina, or the last round of wildfires in California. Do you think it appropriate to tell the firefighters "you can't let the trucks get more than 25m apart, or your network breaks"? Or, "if your DNS server should fail, just forget what you're doing and go home"?

So, once again, no -- 25m subnets don't make sense and won't work in the environments where I'm deploying networks. Placing this type of limitation on AUTOCONF will, IMO, make the work output useless.

Stan
 

> > 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 communications.
> 
> 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.
> 
> Alex
> 
> _______________________________________________
> Autoconf mailing list
> Autoconf@ietf.org
> https://www.ietf.org/mailman/listinfo/autoconf
>