Re: [Autoconf] RFC 5889 (Was: Call for comments to a new AUTOCONF charter proposal)

Alexandru Petrescu <alexandru.petrescu@gmail.com> Fri, 23 July 2010 08:22 UTC

Return-Path: <alexandru.petrescu@gmail.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 AC1063A67DA for <autoconf@core3.amsl.com>; Fri, 23 Jul 2010 01:22:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.103
X-Spam-Level:
X-Spam-Status: No, score=-2.103 tagged_above=-999 required=5 tests=[AWL=0.146, BAYES_00=-2.599, HELO_EQ_FR=0.35]
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 NgR2FBT-41al for <autoconf@core3.amsl.com>; Fri, 23 Jul 2010 01:22:50 -0700 (PDT)
Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.166.172.107]) by core3.amsl.com (Postfix) with ESMTP id 341933A67B4 for <autoconf@ietf.org>; Fri, 23 Jul 2010 01:22:50 -0700 (PDT)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id o6N8N1nu030166 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 23 Jul 2010 10:23:01 +0200
Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id o6N8N0Km011310; Fri, 23 Jul 2010 10:23:01 +0200 (envelope-from alexandru.petrescu@gmail.com)
Received: from [127.0.0.1] ([132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id o6N8N04X023857; Fri, 23 Jul 2010 10:23:00 +0200
Message-ID: <4C495164.4080604@gmail.com>
Date: Fri, 23 Jul 2010 10:23:00 +0200
From: Alexandru Petrescu <alexandru.petrescu@gmail.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1
MIME-Version: 1.0
To: Ulrich Herberg <ulrich@herberg.name>
References: <4C2A6BB7.1000900@piuha.net> <ABE739C5ADAC9A41ACCC72DF366B719D0344FAC3@GLKMS2100.GREENLNK.NET> <4C4899AD.4030808@gmail.com> <201007230723.58638.henning.rogge@fkie.fraunhofer.de> <4C494806.5060609@gmail.com> <AANLkTi=+VixB225byHoA9OHtckZmdP6myLRT+DaGmnwn@mail.gmail.com>
In-Reply-To: <AANLkTi=+VixB225byHoA9OHtckZmdP6myLRT+DaGmnwn@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Cc: autoconf@ietf.org, "Dearlove, Christopher \(UK\)" <Chris.Dearlove@baesystems.com>, Thomas Heide Clausen <thomas@thomasclausen.org>
Subject: Re: [Autoconf] RFC 5889 (Was: Call for comments to a new AUTOCONF charter proposal)
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: Fri, 23 Jul 2010 08:22:51 -0000

Le 23/07/2010 09:53, Ulrich Herberg a écrit :
> Alex,
>
> On Fri, Jul 23, 2010 at 9:43 AM, Alexandru Petrescu
> <alexandru.petrescu@gmail.com <mailto:alexandru.petrescu@gmail.com>>
>  wrote:
>
> Le 23/07/2010 07:23, Henning Rogge a écrit :
>
> On Thu July 22 2010 21:19:09 Alexandru Petrescu wrote:
>
> Le 22/07/2010 17:41, Dearlove, Christopher (UK) a écrit :
>
> And then those link local addresses are visible beyond their local
> link.
>
>
> No, my point is not understood.  The link-local addresses are not
> visible beyond their local link.
>
> When the MRs in LFN--MR--MR--MR--LFN use their link-local addresses
> these are not visible beyond their respective local link.
>
>
> You just have shown that you don't understand what a wireless MANET
> (with multihop links, without most people would not consider it a
> MANET) is.
>
>
> Ulrich, I do make efforts to understand what you understand.  PArt
> of this effort is to refrain the temptation of claiming you don't
> understand what I don't understand.
>
>
>
> It was Henning, who said that, not me :-) (even though in this
> particular example, I agree with him).

I made a mistake, I am sorry Henning and Ulrich.  I actually know you
Ulrich, not Henning.  I need a mental image about who I talk to.

> if each of the MRs use a wireless interface, the linklocals WILL BE
> VISIBLE outside their direct link.
>
>
> Well, the link local addresses will not be visible outside their
> direct link, because the different links are on different ESSIDs and
>  moreover on different channels.  Using wireshark on IP packets on
> these different links shows that the link local addressess are not
> visible from one link to another.
>
>
> Yes, but this is not the general case of a MANET. This is your very
> particular lab setting, which will only work in well-known,
> predefined constraints.

WEll I disagree.  WiFi is designed to use ESSIDs meaningfully, it is in
the manual.  WiFi deployments use ESSIDs.  I'd say that one's refusal to
use ESSIDs is refusal to abide to the manual, build broken things and
then blame IP.

> When you say visible - what do you mean?  I mean "not visible" to the
> IP stack.
>
>
> There is no way to prevent this.
>
>
> YEs there is - use different ESSIDs and, for more insurance, use
> different channels and different keys.  That is for WiFi.  For other
> technologies (3G+, LTE, Bluetooth) there are other link layer means
> such as pdp context and more.
>
>
> Then tell me, how Henning should manage the FunkFeuer Netzwerk.

How much would Henning pay me to build a consistent plan for FunkFeuer
Netzwerk?  Then I'll say.

> Using a different channel and ESSID for every link?

Yes, different ESSID and channel for links in proximity where there may
be a risk of visibility of link layer addresses.  It's like the map
colouring problem - there are solutions.  Internet too has different IP
subnets on different links.

> And even worse, consider a setting where routers actually move in an
>  unknown patterns (i.e. are "mobile"); how would you update ESSIDs
> and channels?

Does such a setting really exist (pure random movements like  in
Brownian)?  Example?

For some wireless deployments studies have been performed to identify
patterns: vehicular, urban citizen, more.  For each there are possible
plans on which WiFi would work good.

Even the most arbitrary movements like in a battlefield have a very high
degree of planning - the command and control is very centralized.

> Because multiple links share interfaces in a non-transitive manner
>
>
> Well yes, at link layer level.  But link layers have their protocols
> which help build understandable links to the IP stack.
>
>
> Yes, but then you are wrong in the MANET WG, because we are not
> talking about L2 meshes (like 802.11s). We are talking about multihop
> communication on L3.

I am in AUTOCONF not in MANET, right?

Alex

>
>
>
> (see http://en.wikipedia.org/wiki/Transitive_relation).
>
>
> Uh?
>
> Alex
>
>
> Henning Rogge
>
>
>
>
> Ulrich