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

Henning Rogge <henning.rogge@fkie.fraunhofer.de> Fri, 23 July 2010 07:51 UTC

Return-Path: <henning.rogge@fkie.fraunhofer.de>
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 5D4593A67B4 for <autoconf@core3.amsl.com>; Fri, 23 Jul 2010 00:51:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.25
X-Spam-Level:
X-Spam-Status: No, score=-3.25 tagged_above=-999 required=5 tests=[AWL=-1.906, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905]
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 04+OW6mrL-cC for <autoconf@core3.amsl.com>; Fri, 23 Jul 2010 00:51:39 -0700 (PDT)
Received: from mailguard.fgan.de (mailguard.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by core3.amsl.com (Postfix) with ESMTP id 0297B3A698C for <autoconf@ietf.org>; Fri, 23 Jul 2010 00:51:39 -0700 (PDT)
Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fgan.de) by mailguard.fgan.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from <henning.rogge@fkie.fraunhofer.de>) id 1OcD2w-0003hE-SR; Fri, 23 Jul 2010 09:51:54 +0200
Received: from stream.fkie.fgan.de ([128.7.5.148] helo=stream.localnet) by mailhost.fgan.de with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from <henning.rogge@fkie.fraunhofer.de>) id 1OcD2w-0000hg-JZ; Fri, 23 Jul 2010 09:51:54 +0200
From: Henning Rogge <henning.rogge@fkie.fraunhofer.de>
To: Alexandru Petrescu <alexandru.petrescu@gmail.com>
Date: Fri, 23 Jul 2010 09:51:45 +0200
User-Agent: KMail/1.13.5 (Linux/2.6.32-23-generic; KDE/4.4.5; i686; ; )
References: <4C2A6BB7.1000900@piuha.net> <201007230723.58638.henning.rogge@fkie.fraunhofer.de> <4C494806.5060609@gmail.com>
In-Reply-To: <4C494806.5060609@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart7952066.PmpPdymB7o"; protocol="application/pgp-signature"; micalg="pgp-sha1"
Content-Transfer-Encoding: 7bit
Message-Id: <201007230951.51192.henning.rogge@fkie.fraunhofer.de>
X-Virus-Scanned: yes (ClamAV 0.96.1/11419/Fri Jul 23 07:19:40 2010) by mailguard.fgan.de
X-Scan-Signature: 4db47a2f8fc8763431e9cacb4f9c6041
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:51:40 -0000

On Fri July 23 2010 09:43:02 Alexandru Petrescu wrote:
> > 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.
This would only work with preplanned links, because otherwise you would have 
trouble to do neighborhood detection. How do you detect new nodes coming into 
range if they cannot announce their presence with a broadcast, because they 
got no unique ESSID to their neighbors ?

MANET routing protocols are specially designed for the case of unplanned 
networks. You have a single shared medium which the routing protocol use for 
it's work, to do neighborhood/link detection.
If you push this down to link layer, you just move the whole problem down one 
layer, because you need unique addresses on the link layer to do neighborhood 
detection and link establishment.

If you already have a unique link-layer address, just use it to generate a 
unique linklocal-IP.

Henning Rogge

-- 
Diplom-Informatiker Henning Rogge , Fraunhofer-Institut für
Kommunikation, Informationsverarbeitung und Ergonomie FKIE
Kommunikationssysteme (KOM)
Neuenahrer Straße 20, 53343 Wachtberg, Germany
Telefon +49 228 9435-961,   Fax +49 228 9435 685
mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de
GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0