Re: [Autoconf] Autoconf addressing model

"Teco Boot" <teco@inf-net.nl> Wed, 04 March 2009 16:54 UTC

Return-Path: <teco@inf-net.nl>
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 6CCFE3A6B72 for <autoconf@core3.amsl.com>; Wed, 4 Mar 2009 08:54:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.337
X-Spam-Level:
X-Spam-Status: No, score=-0.337 tagged_above=-999 required=5 tests=[AWL=1.167, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_LOW=-1]
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 WGNA+34iVXlT for <autoconf@core3.amsl.com>; Wed, 4 Mar 2009 08:54:05 -0800 (PST)
Received: from server9.hosting2go.nl (server9.hosting2go.nl [83.137.194.84]) by core3.amsl.com (Postfix) with ESMTP id 4B4463A6B56 for <autoconf@ietf.org>; Wed, 4 Mar 2009 08:54:02 -0800 (PST)
Received: (qmail 24104 invoked from network); 4 Mar 2009 17:54:26 +0100
Received: from static.kpn.net (HELO M90Teco) (77.61.241.196) by server9.hosting2go.nl with SMTP; 4 Mar 2009 17:54:26 +0100
From: "Teco Boot" <teco@inf-net.nl>
To: "'Alexandru Petrescu'" <alexandru.petrescu@gmail.com>, "'Stan Ratliff \(sratliff\)'" <sratliff@cisco.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> <7FB7EE0A621BA44B8B69E5F0A09DC76407B5D783@xmb-rtp-208.amer.cisco.com> <49AE9827.5090309@gmail.com>
In-Reply-To: <49AE9827.5090309@gmail.com>
Date: Wed, 4 Mar 2009 17:53:56 +0100
Message-ID: <000c01c99ce9$e09bf500$a1d3df00$@nl>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Acmc2md/jBTyFhX0SNGtQobr5iIW4QADj8Ew
Content-Language: nl
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 16:54:06 -0000

Alex,

It happen to be I am working on the customer side, not the equipment vendor
/ supplier side.
I can say your limitations for 25meter and a requirement for relay nodes
with multiple interfaces are far, far from acceptable. I go for what Stan
says.
Sorry, I cannot go into details on what the specs are. I am not in the
position to say you, this is not the medium to publish and moreover, there
is no need for these details. We in IETF never went in this before (e.g.
there is no range limitation for ICMP messages).

Thanks, Teco

|-----Oorspronkelijk bericht-----
|Van: autoconf-bounces@ietf.org [mailto:autoconf-bounces@ietf.org] Namens
|Alexandru Petrescu
|Verzonden: woensdag 4 maart 2009 16:03
|Aan: Stan Ratliff (sratliff)
|CC: autoconf@ietf.org
|Onderwerp: Re: [Autoconf] Autoconf addressing model
|
|Stan Ratliff (sratliff) a écrit :
|[...]
|> 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"?
|
|No, I don't think it appropriate.
|
|But I didn't mean to imply AUTOCONF networks span only 25meter range -
|they could be made of several such single subnets.
|
|> 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.
|
|How about a unit being a 25m subnet containing exposed terminals; and a
|network growing as a chain of such units, linked by routers.  Would this
|make more sense?
|
|The disaster relief scenarios you describe also have certain limits of
|movements.  For example:
|-firefighter never gets very far away from truck.
|-among all intervening trucks only some are designated as special, for
|  example command and control.
|-etc.
|
|Expressing this inherent structure in terms of subnet structure can be
|very useful.
|
|Alex
|
|>
|> 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
|>>
|>
|
|
|_______________________________________________
|Autoconf mailing list
|Autoconf@ietf.org
|https://www.ietf.org/mailman/listinfo/autoconf