Re: [Autoconf] Autoconf addressing model

"Teco Boot" <teco@inf-net.nl> Thu, 05 March 2009 09:37 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 BD1C728C297 for <autoconf@core3.amsl.com>; Thu, 5 Mar 2009 01:37:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.718
X-Spam-Level:
X-Spam-Status: No, score=-1.718 tagged_above=-999 required=5 tests=[AWL=0.328, 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 gpZEkvQf8IJM for <autoconf@core3.amsl.com>; Thu, 5 Mar 2009 01:37:07 -0800 (PST)
Received: from hpsmtp-eml18.kpnxchange.com (hpsmtp-eml18.KPNXCHANGE.COM [213.75.38.118]) by core3.amsl.com (Postfix) with ESMTP id 4A1F228C168 for <autoconf@ietf.org>; Thu, 5 Mar 2009 01:37:06 -0800 (PST)
Received: from cpsmtp-eml103.kpnxchange.com ([213.75.84.103]) by hpsmtp-eml18.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 5 Mar 2009 10:37:31 +0100
Received: from M90Teco ([86.83.9.22]) by cpsmtp-eml103.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 5 Mar 2009 10:37:30 +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> <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> <7FB7EE0A621BA44B8B69E5F0A09DC76407B5D803@xmb-rtp-208.amer.cisco.com> <49AEBA6D.7030903@gmail.com> <7FB7EE0A621BA44B8B69E5F0A09DC76407B5DB1F@xmb-rtp-208.amer.cisco.com> <49AF97FA.702000 7@gmail.com>
In-Reply-To: <49AF97FA.7020007@gmail.com>
Date: Thu, 05 Mar 2009 10:37:31 +0100
Message-ID: <002201c99d76$017d4b20$0477e160$@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: AcmdctttjdWQ/4HCSNqdk2eYiDukiwAALBDQ
Content-Language: nl
X-OriginalArrivalTime: 05 Mar 2009 09:37:30.0829 (UTC) FILETIME=[012E67D0:01C99D76]
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: Thu, 05 Mar 2009 09:37:08 -0000

Inline.

|-----Oorspronkelijk bericht-----
|Van: autoconf-bounces@ietf.org [mailto:autoconf-bounces@ietf.org] Namens
|Alexandru Petrescu
|Verzonden: donderdag 5 maart 2009 10:15
|Aan: Stan Ratliff (sratliff)
|CC: autoconf@ietf.org
|Onderwerp: Re: [Autoconf] Autoconf addressing model
|
|I wanted to clarify better myself because I think I'm misunderstood,
|sorry for insisting on what may appear as circles but I don't want to be
|understood so.
|
|Stan Ratliff (sratliff) a écrit :
|>> Stan Ratliff (sratliff) a écrit :
|>>> First off, you *can't* arbitrarily limit subnets to 25m. 25m from
|>>>  what? The center?
|>> Yes, an area of 25meters with a wifi access point in the center.
|>
|> *By definition*, what you describe is not a MANET. As you state,
|> that's just a WiFi access point.
|
|Ok, I said AP because in a hurry.  I also meant AP-free wifi adhoc mode
|gatherings of ad-hoc interfaces.  The coverage is also about 25meter.
|This is dictated by the max power levels (a number of milliwatts) which
|says how strong can 2.5GHz emit in unlicensed spectrum.
|
|If all such ad-hoc interfaces of that IPv6 subnet stay within 25meter
|range then they're all fully exposed (no hidden terminals).

Not true. Maybe in a lab environment, there is no condition where it fails.
In other circumstances, some iron would be enough for limited range (few
meters). Think of (closed) workplace shelters (EMC or ABC protected).
There are also stories on wlan and micro-wave ovens. 
This is mentioned over and over.



|And I also mean that larger networks could be made out of building
|blocks of 25m (because of powerlevel-limited because
|unlicensed-spectrum), by using Routers.  And still keeping the IPv6
|subnet to be as small at the safe area in which there are all exposed
|terminals, no hidden terminals.

No. There is a limit on spectrum and not all segments can use their own.
This introduces hidden terminal in your scenario. Moreover, you might be
familiar with planning WiFi infrastructures. Do you think this is ad hoc?



|I hope I'm clearer.

I don't think so. You came up with scenario's that are against the 802.11
standards and have serious problems when used in ad hoc fashion. Just my
opinion.



|> That's already solved -- 802.11 clients can roam from access point to
|>  access point.
|
|Well yes and no, depends how it's deployed.  If the APs are bridging
|into a backbone then yes, terminals keep their addresses.  But if the
|APs route then it's not solved.  (Proxy) Mobile IP may be a solution for
|it, but it has its inconvenients in path lengths (RO) and tunnels.

No problems if the APs route and the stations run a MANET protocol. I am
aware of other solutions also, where stations stay hosts (e.g. inject
ND/ARP/other info in routing).



|> But again, this should not be an 802.11-centric discussion.
|
|I agree to have it on more than 802.11.
|
|I've been told recently it's not good for link layer characteristics to
|  control the link-layers to IP addressing.  Yes, put that way I agree
|with it - I don't want link-layers to control IP, rather vice-versa.
|
|But it's also  true that an IPv6 link-local address on Ethernet depends
|directly on the MAC addres (a link-layer ID),

Not by definition and not directly. Nodes are free to use any other
Interface ID.


Teco.



| that an  IPv6 subnet on
|802.16 is a prefix-per-mobile model, and that IPv6 auto-configuration on
|802.15.4 may use a form of address assigned in RA.
|
|That's what I wanted to say about AUTOCONF addressing architecture and
|specific link-layers.
|
|I hope I'm clearer.
|
|Alex
|
|>>> And, how do you designate the center? Do you constantly
|>> re-calculate
|>>> the center based on movement?
|>> No, not constantly re-computed.  But have a fixed view at a point
|>> in time.  Saying everything varies isn't helpful either.
|>>
|>
|> It may not be helpful, but it's reality. You can't rely on a fixed
|> view of a dynamic network; again, by definition, there's movement in
|>  a MANET. Links come and go, and link quality varies from moment to
|> moment.
|>
|>
|>>> Also, from a radio perspective, how do you tell how far
|>> apart you are
|>>> in the first place? Do you suppose that all radios have
|>> GPS? That's a
|>>> non-starter, because GPS signals aren't always available.
|>> No I didn't suppose GPS is available on each device, it wouldn't
|>> work well under foliage.  Just a rough evaluation of a specific
|>> link-layer radio range, correspondign to widely used networks.
|>>
|>>> And what about the wired MANET case brought up by Christopher
|>>> Dearlove? Should we limit the cable runs?
|>> YEs, certainly.  All cabled link-layers have specific limitations
|>> on their lengths: 2m USB, 50m Ethernet Category6 (IIRC) and so on.
|>>
|>>> I could understand (but wouldn't really like) the notion of
|>>> limiting the discussion
|>> to links
|>>> that are transitive; but placing some arbitrary distance
|>> limit that's
|>>> based on 802.11 just doesn't cut it for me.
|>> 802.11 is being used widely, no reason to ignore.
|>
|> I'm not advocating we "ignore" 802.11, or any other L2 technology,
|> for that matter. I'm advocating that we remain Layer 2 agnostic. As
|> Teco mentioned in another email, there are people in this WG that
|> don't deploy MANET networks based on 802.11, or 802.16, or 802.15.4.
|>
|>> I'd happily accept to add another specific limitation, from the
|>> link-layer of your choice.  And be speecifically addressing these
|>> two link layers.  And maybe three.  No more than three.
|>>
|>> I find addressing them all to be difficult for me.
|>
|> I don't understand why the Layer 3 addressing scheme needs to be
|> predicated on a specific Layer 2 technology, or set of technologies.
|>  The Layer 3 addressing scheme should be totally independent of Layer
|>  2 -- isn't that what layering is all about?
|>
|>> (about single point of failure being destroyed by a falling tree:
|>> problem could be addressed at its layer: don't move the command
|>> center under trees risking falling); or maybe have two command
|>> centers, but specificllay two, not an arbitrary large unknown
|>> number.
|>>
|>
|> That essentially boils down to "if it hurts, don't do it", and it
|> doesn't work for my customers. Their environments are dynamic, and
|> they need the ability to respond to ever-changing realities on the
|> ground.
|>
|> At this point, I feel that we're in a discussion that is becoming
|> more and more circular, and therefore, dysfunctional. And that, IMO,
|>  has been the unfortunate reality of this WG since its inception.
|>
|> Regards, Stan
|>
|>
|>> Alex
|>>
|>
|
|_______________________________________________
|Autoconf mailing list
|Autoconf@ietf.org
|https://www.ietf.org/mailman/listinfo/autoconf