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:52 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 DBDD23A69F0 for <autoconf@core3.amsl.com>; Fri, 23 Jul 2010 01:52:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.114
X-Spam-Level:
X-Spam-Status: No, score=-2.114 tagged_above=-999 required=5 tests=[AWL=0.135, 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 A-Sw4hSNScrc for <autoconf@core3.amsl.com>; Fri, 23 Jul 2010 01:52:07 -0700 (PDT)
Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.1]) by core3.amsl.com (Postfix) with ESMTP id A02253A69B5 for <autoconf@ietf.org>; Fri, 23 Jul 2010 01:52:06 -0700 (PDT)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id o6N8qH44008550 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 23 Jul 2010 10:52:18 +0200
Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id o6N8qHfK019388; Fri, 23 Jul 2010 10:52:17 +0200 (envelope-from alexandru.petrescu@gmail.com)
Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id o6N8qGnw013798; Fri, 23 Jul 2010 10:52:17 +0200
Message-ID: <4C495840.60409@gmail.com>
Date: Fri, 23 Jul 2010 10:52:16 +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: Thomas Heide Clausen <thomas@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> <1770ECCA-C51B-42C4-AB7C-A59424E1B01D@thomasclausen.org>
In-Reply-To: <1770ECCA-C51B-42C4-AB7C-A59424E1B01D@thomasclausen.org>
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>
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:52:08 -0000

Le 23/07/2010 10:12, Thomas Heide Clausen a écrit :
>
> 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 - FWIW, you seem to it's easy for AUTOCONF Charter to be MANET 
RFC2501 only.

If so - add "MANET" in the Charter, rfc2501, make that be the exclusive 
AUTOCONF cases and I go away.

I will not call my deployments MANET.

Alex

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