Re: [Autoconf] Autoconf addressing model

"Teco Boot" <teco@inf-net.nl> Wed, 04 March 2009 19:35 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 A9AFF28C477 for <autoconf@core3.amsl.com>; Wed, 4 Mar 2009 11:35:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.655
X-Spam-Level:
X-Spam-Status: No, score=-1.655 tagged_above=-999 required=5 tests=[AWL=0.391, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553]
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 h8+fZChqPczB for <autoconf@core3.amsl.com>; Wed, 4 Mar 2009 11:35:14 -0800 (PST)
Received: from hpsmtp-eml18.kpnxchange.com (hpsmtp-eml18.KPNXCHANGE.COM [213.75.38.118]) by core3.amsl.com (Postfix) with ESMTP id CF16B28C446 for <autoconf@ietf.org>; Wed, 4 Mar 2009 11:35:13 -0800 (PST)
Received: from cpsmtp-eml103.kpnxchange.com ([213.75.84.103]) by hpsmtp-eml18.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 4 Mar 2009 20:35:41 +0100
Received: from M90Teco ([86.83.9.22]) by cpsmtp-eml103.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 4 Mar 2009 20:35:40 +0100
From: "Teco Boot" <teco@inf-net.nl>
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> <7FB7EE0A621BA44B8B69E5F0A09DC76407B5D783@xmb-rtp-208.amer.cisco.com> <49AE9827.5090309@gmail.com> <000c01c99ce9$e09bf500$a1d3df00$@nl> <49AEB846.5020103@gmail.com>
In-Reply-To: <49AEB846.5020103@gmail.com>
Date: Wed, 4 Mar 2009 20:35:39 +0100
Message-ID: <000101c99d00$664c7f60$32e57e20$@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: Acmc7X3j+4HosC1JRzGA2GNhP5ShBgAEWOYA
Content-Language: nl
X-OriginalArrivalTime: 04 Mar 2009 19:35:40.0094 (UTC) FILETIME=[666FE5E0:01C99D00]
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 19:35:15 -0000

Inline.

|-----Oorspronkelijk bericht-----
|Van: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com]
|Verzonden: woensdag 4 maart 2009 18:20
|Aan: Teco Boot
|CC: 'Alexandru Petrescu'; 'Stan Ratliff (sratliff)'; autoconf@ietf.org
|Onderwerp: Re: [Autoconf] Autoconf addressing model
|
|Teco Boot a écrit :
|> 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).
|
|I meant to say to explicitely consider the characteristics of the
|link-layers you consider for AUTOCONF ad-hoc networks.  These all have
|specifications about their physical lengths (for wired), for dbm
|powerlevels and range in meters (wireless).

The problem with this is that it is of almost no use for an ad hoc network.
Ad hoc means "to this", "for this purpose". It refers to dealing with
special situations as they occur rather than functions that are repeated on
a regular basis. (http://www.answers.com/topic/ad-hoc). Or "created on the
spur of the moment, impromptu" (http://en.wiktionary.org/wiki/ad_hoc).



|I can't build a network without knowing these specifications
|in detail; its IP addressing architecture is impossible to agree on.

Why do you think you were asked to build a network?
All we ask is a little cooperation in our common goal defining an Autoconf
mechanisms for MANETs.


Teco.



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