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

Ulrich Herberg <ulrich@herberg.name> Fri, 23 July 2010 07:53 UTC

Return-Path: <ulrich@herberg.name>
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 D15CC3A67E3 for <autoconf@core3.amsl.com>; Fri, 23 Jul 2010 00:53:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.976
X-Spam-Level:
X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001]
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 yQHv0JO-pbRA for <autoconf@core3.amsl.com>; Fri, 23 Jul 2010 00:53:03 -0700 (PDT)
Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id D91A73A67B4 for <autoconf@ietf.org>; Fri, 23 Jul 2010 00:53:02 -0700 (PDT)
Received: by bwz7 with SMTP id 7so1614999bwz.31 for <autoconf@ietf.org>; Fri, 23 Jul 2010 00:53:20 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.204.103.136 with SMTP id k8mr2330397bko.37.1279871600177; Fri, 23 Jul 2010 00:53:20 -0700 (PDT)
Received: by 10.204.163.5 with HTTP; Fri, 23 Jul 2010 00:53:20 -0700 (PDT)
In-Reply-To: <4C494806.5060609@gmail.com>
References: <4C2A6BB7.1000900@piuha.net> <ABE739C5ADAC9A41ACCC72DF366B719D0344FAC3@GLKMS2100.GREENLNK.NET> <4C4899AD.4030808@gmail.com> <201007230723.58638.henning.rogge@fkie.fraunhofer.de> <4C494806.5060609@gmail.com>
Date: Fri, 23 Jul 2010 09:53:20 +0200
Message-ID: <AANLkTi=+VixB225byHoA9OHtckZmdP6myLRT+DaGmnwn@mail.gmail.com>
From: Ulrich Herberg <ulrich@herberg.name>
To: Alexandru Petrescu <alexandru.petrescu@gmail.com>
Content-Type: multipart/alternative; boundary="0016e6d624f9163167048c0954cf"
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 07:53:04 -0000

Alex,

On Fri, Jul 23, 2010 at 9:43 AM, Alexandru Petrescu <
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).


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


>
> 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. Using a
different channel and ESSID for every link? 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?



>
>
>

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


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

Ulrich