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

Thomas Heide Clausen <thomas@thomasclausen.org> Fri, 23 July 2010 08:12 UTC

Return-Path: <thomas@thomasclausen.org>
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 7AA5B3A6B1C for <autoconf@core3.amsl.com>; Fri, 23 Jul 2010 01:12:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 CWtigWIO2PSf for <autoconf@core3.amsl.com>; Fri, 23 Jul 2010 01:12:02 -0700 (PDT)
Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id F25D83A69B3 for <autoconf@ietf.org>; Fri, 23 Jul 2010 01:12:01 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id 4C2533236DB3; Fri, 23 Jul 2010 01:12:20 -0700 (PDT)
X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net
Received: from [10.0.1.2] (sphinx.lix.polytechnique.fr [129.104.11.1]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTPSA id 379983228050; Fri, 23 Jul 2010 01:12:19 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1078)
Content-Type: text/plain; charset="iso-8859-1"
From: Thomas Heide Clausen <thomas@thomasclausen.org>
In-Reply-To: <4C494C29.5020004@gmail.com>
Date: Fri, 23 Jul 2010 10:12:17 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <1770ECCA-C51B-42C4-AB7C-A59424E1B01D@thomasclausen.org>
References: <4C2A6BB7.1000900@piuha.net> <ABE739C5ADAC9A41ACCC72DF366B719D0344FAC3@GLKMS2100.GREENLNK.NET> <4C4899AD.4030808@gmail.com> <201007230723.58638.henning.rogge@fkie.fraunhofer.de> <4C494806.5060609@gmail.com> <1D0FFC66-A4C6-4E7E-A7C5-13156A9B37A3@thomasclausen.org> <4C494C29.5020004@gmail.com>
To: Alexandru Petrescu <alexandru.petrescu@gmail.com>
X-Mailer: Apple Mail (2.1078)
Cc: autoconf@ietf.org, "Dearlove, Christopher (UK)" <Chris.Dearlove@baesystems.com>
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:12:03 -0000

On Jul 23, 2010, at 10:00 , Alexandru Petrescu wrote:

> Le 23/07/2010 09:47, Thomas Heide Clausen a écrit :
>> 
>> On Jul 23, 2010, at 09:43 , Alexandru Petrescu 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.
>>> 
>>>> 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.
>> 
>> That is the crux of your misunderstanding. They may, in your case, be
>> -- in most MANET cases, they're not.
> 
> Thomas - help me remove this crux.
> 
> Could we make an AUTOCONF non-MANET case where the link local addresses
> are not visible across different wireless links.

No, I don't see how we could make a valid case like that. 

In part, because [autoconf] targets MANETs, trying to make a "non-MANET case" would be quite out of scope.

> Otherwise, could we be stating in the Charter that AUTOCONF deals _only_
> with MANET cases where link local addresses are visible in all radio
> ranges, links undefined, no WiFi ESSID nor similar. Which by your
> definition is 'most MANET cases'.

The reference to 2501 should make it clear that we were talking about MANETs, and so should be familiar with what that entails -- which is (among other things) that the above "link" characteristics are true (and I just see Henning chipped in, and want to +1 to his remark as well). But, I would guess that if adding the keyword "MANET" to the charter is what this discussion is about, then that can be done too.

Thomas

> You mentioned it several times - it
> deserves being in the Charter. Both ways would help me a lot: in the first I stay in the group, present
> at meeting.  In the second I go away.
> 
> Alex
> 
>> 
>> Thomas
>> 
>> 
>>> Using wireshark on IP packets on these different links shows that
>>> the link local addressess are not visible from one link to
>>> another.
>>> 
>>> 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.
>>> 
>>>> 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.
>>> 
>>>> (see http://en.wikipedia.org/wiki/Transitive_relation).
>>> 
>>> Uh?
>>> 
>>> Alex
>>> 
>>>> 
>>>> Henning Rogge
>>>> 
>>> 
>>> 
>> 
>> 
> 
>