From super.ismiti@gmail.com Wed Feb 4 04:39:41 2009 Return-Path: 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 8CB8B28C201 for ; Wed, 4 Feb 2009 04:39:41 -0800 (PST) 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 KAbq-CZApQHs for ; Wed, 4 Feb 2009 04:39:40 -0800 (PST) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.171]) by core3.amsl.com (Postfix) with ESMTP id C844E28C17E for ; Wed, 4 Feb 2009 04:39:40 -0800 (PST) Received: by wf-out-1314.google.com with SMTP id 27so2824140wfd.31 for ; Wed, 04 Feb 2009 04:39:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=QoNwrR08SEvNL4n6H+twyDXHKXK2DGUfH78xP1opN74=; b=IvQHKfh6/68l5zmYXBIHEn232lVj716HscfSqu/AfGmTtpNUl5waNLNzcHgQNRXuGy abcPASPCWw6Ow7OLd1TrKZPSrkCKmTvT00o8p44+3MWje61PQeKzg0fvMon9a5W7NQfG wxX2o1JESNy+L39UAm3VgZgb4zMu4nK5H1WtQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=f2AhNVag5h8G94BQqPzLjK+v6l909Fr97aKwh2FY/R71Wsfs+Px1D7dExVMmZGcpcR FkNgp+Ez9YQyaC5XgssFiU9qX1nAP+IuMI0tq9Nw9KisOKaWW5H+Gsm7O4A4ddwqNr9N DRhcNrbCBI/LEayMKJmFCwChdLHEKH8+QqN58= MIME-Version: 1.0 Received: by 10.142.240.19 with SMTP id n19mr619861wfh.10.1233751160981; Wed, 04 Feb 2009 04:39:20 -0800 (PST) Date: Wed, 4 Feb 2009 10:39:20 -0200 Message-ID: From: Ricardo Schmidt To: autoconf@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Autoconf] Self-addressing using local information X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2009 12:39:41 -0000 Hello all, I am developing a short introducing research on autoconfiguration in MANETs. Right now I am writing about some protocols for self-addressing. I noticed that, most of the proposed solutions implement a randomly choice of address. For example, a node picks an address from the range 1-2047 for temporary address and later an address from the range 2048-65534 for the tentative address. Well, I would like to know if there available works where a formula is implemented for creating an address, in order to avoid the duplication. Something like Prophet. However, I am looking for a proposal that uses information such as the MAC from the interface to calculate a tentative address. Thanks in advance for repliers! -- Ricardo de Oliveira Schmidt From cjbc@it.uc3m.es Wed Feb 4 04:46:04 2009 Return-Path: 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 CB6CF28C1B0 for ; Wed, 4 Feb 2009 04:46:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.866 X-Spam-Level: X-Spam-Status: No, score=-3.866 tagged_above=-999 required=5 tests=[AWL=1.833, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] 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 qP7hfeyAMxsX for ; Wed, 4 Feb 2009 04:46:03 -0800 (PST) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id B97CF28C0D7 for ; Wed, 4 Feb 2009 04:46:03 -0800 (PST) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Ricardo Schmidt In-Reply-To: References: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-EoMDLtKKcD32mo094l55" Organization: Universidad Carlos III de Madrid Date: Wed, 04 Feb 2009 13:45:41 +0100 Message-Id: <1233751542.9063.8.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.5.0.1026-16442.006 Cc: autoconf@ietf.org Subject: Re: [Autoconf] Self-addressing using local information X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2009 12:46:04 -0000 --=-EoMDLtKKcD32mo094l55 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Hi Ricardo, El mi=E9, 04-02-2009 a las 10:39 -0200, Ricardo Schmidt escribi=F3: > Hello all, >=20 > I am developing a short introducing research on autoconfiguration in MANE= Ts. > Right now I am writing about some protocols for self-addressing. >=20 > I noticed that, most of the proposed solutions implement a randomly > choice of address. > For example, a node picks an address from the range 1-2047 for > temporary address and later an address from the range 2048-65534 for > the tentative address. >=20 > Well, I would like to know if there available works where a formula is > implemented for creating an address, in order to avoid the > duplication. Something like Prophet. However, I am looking for a > proposal that uses information such as the MAC from the interface to > calculate a tentative address. I assume you are considering only IPv4... I think (not 100% sure) Meraki [1] used the following addressing scheme: nodes configure IP addresses that are the static hash of the MAC address onto the entire 10.0.0.0/8 private network. [1] http://meraki.com/oursolution/mesh/ >=20 > Thanks in advance for repliers! >=20 --=20 Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ WEEDEV 2009: 2nd Workshop on Experimental Evaluation and Deployment Experiences on Vehicular networks http://www.weedev.org/ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ --=-EoMDLtKKcD32mo094l55 Content-Type: application/pgp-signature; name=signature.asc Content-Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEABECAAYFAkmJjfUACgkQNdy6TdFwT2f1dgCfUsvdu2G85FXZGofxV6XtAiyi iDkAnjfugpZjisxVpaBvXDboMrIKrHqh =aCTQ -----END PGP SIGNATURE----- --=-EoMDLtKKcD32mo094l55-- From alexandru.petrescu@gmail.com Wed Feb 4 06:57:40 2009 Return-Path: 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 451953A6937 for ; Wed, 4 Feb 2009 06:57:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.179 X-Spam-Level: X-Spam-Status: No, score=-2.179 tagged_above=-999 required=5 tests=[AWL=0.070, 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 3izSZ18mQC6a for ; Wed, 4 Feb 2009 06:57:35 -0800 (PST) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.166.172.106]) by core3.amsl.com (Postfix) with ESMTP id 6282128C268 for ; Wed, 4 Feb 2009 06:57:28 -0800 (PST) Received: from nephilia.intra.cea.fr (nephilia.intra.cea.fr [132.166.88.33]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-1.2) with ESMTP id n14Ev7vV027404; Wed, 4 Feb 2009 15:57:07 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by nephilia.intra.cea.fr (8.13.8/8.13.8) with ESMTP id n14Ev7kP002199; Wed, 4 Feb 2009 15:57:07 +0100 (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 n14Ev6Ca001660; Wed, 4 Feb 2009 15:57:07 +0100 Message-ID: <4989ACC2.6050303@gmail.com> Date: Wed, 04 Feb 2009 15:57:06 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Ricardo Schmidt References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org Subject: Re: [Autoconf] Self-addressing using local information X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2009 14:57:40 -0000 Ricardo Schmidt a écrit : > Hello all, > > I am developing a short introducing research on autoconfiguration in > MANETs. Right now I am writing about some protocols for > self-addressing. 'Self'-addressing? Maybe the use of the loopback address is pertinent? 127.0.0.1 > I noticed that, most of the proposed solutions implement a randomly > choice of address. For example, a node picks an address from the > range 1-2047 for temporary address and later an address from the > range 2048-65534 for the tentative address. Are we talking about an article (which?) or an Internet Draft or an RFC? Or a non-standard implementation? For IPv6 there's the forming of a link-local address from the MAC address of the interface RFC2464, and the 'privacy' extensions for global addresses (basically a random choice) RFC4941. > Well, I would like to know if there available works where a formula > is implemented for creating an address, in order to avoid the > duplication. Something like Prophet. However, I am looking for a > proposal that uses information such as the MAC from the interface to > calculate a tentative address. Sorry what is Prophet? MAC is used directly to form the IPv6 link-local address over Ethernet and the IPv6 global address some times. For IPv4, there are IPv4 link-local addresses 169.254.x.x RFC3927, and within the text there's recommendation to use the MAC address as a seed for the random generation. These addresses are used for example by Microsoft's ActiveSync IP over USB, and I guess by Apple's Bonjour; for example some ActiveSync devices show: > Carte Ethernet Connexion au reseau local 5: > > Suffixe DNS propre a la connexion : > Description . . . . . . . . . . . : Windows Mobile-based Device > Adresse physique . . . . . . . . .: 80-00-60-0F-E8-00 > DHCP active. . . . . . . . . . . : Oui > Configuration automatique activee . . . . : Oui > Adresse IP. . . . . . . . . . . . : 169.254.2.2 > Masque de sous-reseau . . . . . . : 255.255.255.0 > Adresse IP. . . . . . . . . . . . : fe80::8200:60ff:fe0f:e800%16 > Passerelle par defaut . . . . . . : > Serveur DHCP. . . . . . . . . . . : 169.254.2.1 > Serveurs DNS . . . . . . . . . . : fec0:0:0:ffff::1%1 > fec0:0:0:ffff::2%1 > fec0:0:0:ffff::3%1 > Bail obtenu . . . . . . . . . . . : mercredi 4 fevrier 2009 15:10:20 > Bail expirant . . . . . . . . . . : vendredi 6 mars 2009 15:10:20 (remark how this is USB and has no IEEE-assigned MAC address, but it has a 'self'-generated MAC address on 48bit and is used to form an IP address over USB even if there's no IP-over-USB RFC :-) There are sometimes contradictory requirements between uniqueness and privacy of an address. Alex From jari.arkko@piuha.net Tue Feb 17 04:58:25 2009 Return-Path: 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 46F093A6974 for ; Tue, 17 Feb 2009 04:58:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.501 X-Spam-Level: X-Spam-Status: No, score=-2.501 tagged_above=-999 required=5 tests=[AWL=0.098, 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 gFGNwtfmepHl for ; Tue, 17 Feb 2009 04:58:24 -0800 (PST) Received: from smtp.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 3D9483A68B5 for ; Tue, 17 Feb 2009 04:58:24 -0800 (PST) Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id 8FF1D19876C; Tue, 17 Feb 2009 14:58:34 +0200 (EET) Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id 52C1A1986E2; Tue, 17 Feb 2009 14:58:34 +0200 (EET) Message-ID: <499AB479.70906@piuha.net> Date: Tue, 17 Feb 2009 14:58:33 +0200 From: Jari Arkko User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: autoconf@ietf.org, Shubhranshu , Thomas Clausen , RYUJI WAKIKAWA Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Subject: [Autoconf] New plan for the Autoconf WG X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2009 12:58:25 -0000 I have tried to figure out what to do with the WG, because we weren't getting anywhere. The main problems we have are these: - after three years even the principles of the architecture document were not agreed upon - danger of attempting to fix the document based on feedback and still coming back to the above point - the state of the other work items in the group is even worse - chairs having to edit documents - overall lack of energy and progress All this is very frustrating, because I know Manet networks can be configured and successfully operated, and many people are interested in this technology. How can it be so hard to describe this? I don't want to assign blame to anyone about this bad situation, except for all of us together. We screwed up. But I do want to give the WG another chance, with a different setup and goals, and see if we can move forward. If not, the WG will be closed in a matter of months. Here's what we are going to do: We will have a new team. Thomas Clausen and Ryuji Wakikawa will be chairs of the WG. A new person will become the editor of the main document. We will have a different scope for the WG. The WG will focus solely on one deliverable. We have previously been attempting to describe THE architecture; from now on the idea is to write a document that explains a practical way of configuring Manet networks. All existing documents are essentially abandoned at this point. However, if the WG successfully completes the new document you will be able to take on additional work items. The chairs are now searching for a small set of key experts to form a design team. The design team will write a first rough draft of the document, at which point we can open it up for wider discussion in the WG. The plan is that this can be done before San Francisco, where the WG is meeting. Finally, the most important thing: the WG members need to donate their cycles for this effort as well. I think the above plan has a good chance of success -- please contact the chairs to volunteer as editors, design team members, document reviewers, and once we get something out, please engage in a timely discussion about the document on the list. I would also like to thank everyone who has been involved so far, Shubhranshu in particular as he is leaving the chair team. While we have not succeeded, I know that you all have tried really hard... Jari Arkko From jari.arkko@piuha.net Fri Feb 20 11:59:23 2009 Return-Path: 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 4E4C63A67B4 for ; Fri, 20 Feb 2009 11:59:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[AWL=0.049, 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 ik4tigwuAuGE for ; Fri, 20 Feb 2009 11:59:22 -0800 (PST) Received: from smtp.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 4A4C73A6359 for ; Fri, 20 Feb 2009 11:59:22 -0800 (PST) Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id 13F8C198770 for ; Fri, 20 Feb 2009 21:59:36 +0200 (EET) Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id C20B11986EF for ; Fri, 20 Feb 2009 21:59:35 +0200 (EET) Message-ID: <499F0BA7.90501@piuha.net> Date: Fri, 20 Feb 2009 21:59:35 +0200 From: Jari Arkko User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: autoconf@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Subject: [Autoconf] new charter X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2009 19:59:23 -0000 In the light of the new direction for the working group, we are planning to update the charter as follows. Comments appreciated. Jari & the chairs ---- Ad-Hoc Network Autoconfiguration (autoconf) ------------------------------------------------------------- Last Modified: 2009-02-18 Cuurent Status: Active Working Group Additional information is available at tools.ietf.org/wg/autoconf Chair(s): Ryuji Wakikawa [ryuji.wakikawa@gmail.com] Thomas Clausen [T.Clausen@computer.org] Internet Area Director(s): Jari Arkko [jari.arkko@piuha.net] Mark Townsley [townsley@cisco.com] Internet Area Advisor: Jari Arkko [jari.arkko@piuha.net] Mailing Lists: General Discussion: autoconf@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/autoconf Archive: http://www.ietf.org/mail-archive/web/autoconf/current/maillist.html Description of Working Group: In order to communicate among themselves, ad hoc nodes (refer to RFC 2501) need to configure their network interface(s) with local addresses that are valid within an ad hoc network. Ad hoc nodes may also need to configure globally routable addresses, in order to communicate with devices on the Internet. From the IP layer perspective, an ad hoc network presents itself as a L3 multi-hop network formed over a collection of links. The main purpose of the AUTOCONF WG is to describe the addressing model for ad hoc networks and how nodes in these networks configure their addresses. It is required that such models do not cause problems for ad hoc-unaware parts of the system, such as standard applications running on an ad hoc node or regular Internet nodes attached to the ad hoc nodes. This group's effort may include the development of new protocol mechanisms, should the existing IP autoconfiguration mechanisms be found inadequate. However, the first task of the working group is to describe one practical addressing model for ad hoc networks. Once this sole work item is completed, the group can be rechartered to work on additional issues. Goals and Milestones: Apr 2009 Submit initial draft on address configuration in ad hoc networks Sep 2009 Submit address configuration draft to IESG as Informational or close WG From cjbc@it.uc3m.es Fri Feb 20 12:29:35 2009 Return-Path: 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 B4BFE3A6959 for ; Fri, 20 Feb 2009 12:29:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.303 X-Spam-Level: X-Spam-Status: No, score=-4.303 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] 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 hBux2AcIX+jD for ; Fri, 20 Feb 2009 12:29:34 -0800 (PST) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 5AC573A66B4 for ; Fri, 20 Feb 2009 12:29:33 -0800 (PST) Received: from [163.117.139.72] (acorde.it.uc3m.es [163.117.139.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp01.uc3m.es (Postfix) with ESMTP id 328C4BA00EA; Fri, 20 Feb 2009 21:29:47 +0100 (CET) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Jari Arkko In-Reply-To: <499F0BA7.90501@piuha.net> References: <499F0BA7.90501@piuha.net> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-ANEy28oMZR/4pQNHN1C8" Organization: Universidad Carlos III de Madrid Date: Fri, 20 Feb 2009 21:29:46 +0100 Message-Id: <1235161786.4633.73.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16476.000 Cc: autoconf@ietf.org Subject: Re: [Autoconf] new charter X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2009 20:29:35 -0000 --=-ANEy28oMZR/4pQNHN1C8 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Hi Jari, One quick comment (I haven't read the proposed text in detail yet): are we considering IPv6 only? IPv6 and IPv4? IPv4 only? previous charter focused only on IPv6 solutions... Kind Regards, Carlos El vie, 20-02-2009 a las 21:59 +0200, Jari Arkko escribi=F3: > In the light of the new direction for the working group, > we are planning to update the charter as follows. Comments > appreciated. >=20 > Jari & the chairs >=20 > ---- >=20 > Ad-Hoc Network Autoconfiguration (autoconf)=20 > -------------------------------------------------------------=20 > Last Modified: 2009-02-18=20 > =20 > Cuurent Status: Active Working Group=20 > =20 > Additional information is available at tools.ietf.org/wg/autoconf=20 > =20 > Chair(s):=20 > Ryuji Wakikawa [ryuji.wakikawa@gmail.com]=20 > Thomas Clausen [T.Clausen@computer.org]=20 > =20 > Internet Area Director(s):=20 > Jari Arkko [jari.arkko@piuha.net]=20 > Mark Townsley [townsley@cisco.com]=20 > =20 > Internet Area Advisor:=20 > Jari Arkko [jari.arkko@piuha.net]=20 > =20 > Mailing Lists:=20 > General Discussion: autoconf@ietf.org=20 > To Subscribe: https://www.ietf.org/mailman/listinfo/autoconf=20 > Archive:=20 > http://www.ietf.org/mail-archive/web/autoconf/current/maillist.html=20 >=20 > Description of Working Group:=20 > =20 > In order to communicate among themselves, ad hoc nodes (refer to RFC=20 > 2501) need to configure their network interface(s) with local addresses=20 > that are valid within an ad hoc network. Ad hoc nodes may also need to=20 > configure globally routable addresses, in order to communicate with=20 > devices on the Internet. From the IP layer perspective, an ad hoc=20 > network presents itself as a L3 multi-hop network formed over a=20 > collection of links.=20 > =20 > The main purpose of the AUTOCONF WG is to describe the addressing model=20 > for ad hoc networks and how nodes in these networks configure their=20 > addresses. It is required that such models do not cause problems for ad=20 > hoc-unaware parts of the system, such as standard applications running=20 > on an ad hoc node or regular Internet nodes attached to the ad hoc=20 > nodes. This group's effort may include the development of new protocol=20 > mechanisms, should the existing IP autoconfiguration mechanisms be found=20 > inadequate. However, the first task of the working group is to describe=20 > one practical addressing model for ad hoc networks.=20 > =20 > Once this sole work item is completed, the group can be rechartered to=20 > work on additional issues.=20 > =20 > Goals and Milestones:=20 > =20 > Apr 2009 Submit initial draft on address configuration in ad hoc networks > Sep 2009 Submit address configuration draft to IESG as Informational or=20 > close WG >=20 > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf --=20 Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ WEEDEV 2009: 2nd Workshop on Experimental Evaluation and Deployment Experiences on Vehicular networks http://www.weedev.org/ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ --=-ANEy28oMZR/4pQNHN1C8 Content-Type: application/pgp-signature; name=signature.asc Content-Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEABECAAYFAkmfEroACgkQNdy6TdFwT2dOvQCfTlb9VSHYWqjbMnxd8wVJoXkZ WdIAoMdrmKQAB1V1/3D9SvfbMv1SDO2R =mxAg -----END PGP SIGNATURE----- --=-ANEy28oMZR/4pQNHN1C8-- From jari.arkko@piuha.net Fri Feb 20 12:56:57 2009 Return-Path: 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 264E43A6988 for ; Fri, 20 Feb 2009 12:56:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[AWL=0.048, 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 AcCKExywh1V2 for ; Fri, 20 Feb 2009 12:56:56 -0800 (PST) Received: from smtp.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id B8FDF3A63D3 for ; Fri, 20 Feb 2009 12:56:55 -0800 (PST) Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id 169B119876C; Fri, 20 Feb 2009 22:57:09 +0200 (EET) Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id B65B01986EE; Fri, 20 Feb 2009 22:57:08 +0200 (EET) Message-ID: <499F1924.8090801@piuha.net> Date: Fri, 20 Feb 2009 22:57:08 +0200 From: Jari Arkko User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: cjbc@it.uc3m.es References: <499F0BA7.90501@piuha.net> <1235161786.4633.73.camel@localhost> In-Reply-To: <1235161786.4633.73.camel@localhost> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV using ClamSMTP Cc: autoconf@ietf.org Subject: Re: [Autoconf] new charter X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2009 20:56:57 -0000 I intentionally made the new charter not say anything about that. My belief is that the type of architecture document that we are looking at can easily talk about both IPv4 and IPv6. Jari Carlos Jesús Bernardos Cano wrote: > Hi Jari, > > One quick comment (I haven't read the proposed text in detail yet): are > we considering IPv6 only? IPv6 and IPv4? IPv4 only? previous charter > focused only on IPv6 solutions... > > Kind Regards, > > Carlos > > El vie, 20-02-2009 a las 21:59 +0200, Jari Arkko escribió: > >> In the light of the new direction for the working group, >> we are planning to update the charter as follows. Comments >> appreciated. >> >> Jari & the chairs >> >> ---- >> >> Ad-Hoc Network Autoconfiguration (autoconf) >> ------------------------------------------------------------- >> Last Modified: 2009-02-18 >> >> Cuurent Status: Active Working Group >> >> Additional information is available at tools.ietf.org/wg/autoconf >> >> Chair(s): >> Ryuji Wakikawa [ryuji.wakikawa@gmail.com] >> Thomas Clausen [T.Clausen@computer.org] >> >> Internet Area Director(s): >> Jari Arkko [jari.arkko@piuha.net] >> Mark Townsley [townsley@cisco.com] >> >> Internet Area Advisor: >> Jari Arkko [jari.arkko@piuha.net] >> >> Mailing Lists: >> General Discussion: autoconf@ietf.org >> To Subscribe: https://www.ietf.org/mailman/listinfo/autoconf >> Archive: >> http://www.ietf.org/mail-archive/web/autoconf/current/maillist.html >> >> Description of Working Group: >> >> In order to communicate among themselves, ad hoc nodes (refer to RFC >> 2501) need to configure their network interface(s) with local addresses >> that are valid within an ad hoc network. Ad hoc nodes may also need to >> configure globally routable addresses, in order to communicate with >> devices on the Internet. From the IP layer perspective, an ad hoc >> network presents itself as a L3 multi-hop network formed over a >> collection of links. >> >> The main purpose of the AUTOCONF WG is to describe the addressing model >> for ad hoc networks and how nodes in these networks configure their >> addresses. It is required that such models do not cause problems for ad >> hoc-unaware parts of the system, such as standard applications running >> on an ad hoc node or regular Internet nodes attached to the ad hoc >> nodes. This group's effort may include the development of new protocol >> mechanisms, should the existing IP autoconfiguration mechanisms be found >> inadequate. However, the first task of the working group is to describe >> one practical addressing model for ad hoc networks. >> >> Once this sole work item is completed, the group can be rechartered to >> work on additional issues. >> >> Goals and Milestones: >> >> Apr 2009 Submit initial draft on address configuration in ad hoc networks >> Sep 2009 Submit address configuration draft to IESG as Informational or >> close WG >> >> _______________________________________________ >> Autoconf mailing list >> Autoconf@ietf.org >> https://www.ietf.org/mailman/listinfo/autoconf >> From cjbc@it.uc3m.es Fri Feb 20 13:05:07 2009 Return-Path: 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 0E5433A63EC for ; Fri, 20 Feb 2009 13:05:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.001 X-Spam-Level: X-Spam-Status: No, score=-5.001 tagged_above=-999 required=5 tests=[AWL=0.698, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] 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 B42SjZKatMPM for ; Fri, 20 Feb 2009 13:05:05 -0800 (PST) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 94B523A63D3 for ; Fri, 20 Feb 2009 13:05:05 -0800 (PST) Received: from [163.117.139.72] (acorde.it.uc3m.es [163.117.139.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp01.uc3m.es (Postfix) with ESMTP id F0B36BA03D6; Fri, 20 Feb 2009 22:05:18 +0100 (CET) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Jari Arkko In-Reply-To: <499F1924.8090801@piuha.net> References: <499F0BA7.90501@piuha.net> <1235161786.4633.73.camel@localhost> <499F1924.8090801@piuha.net> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-xyLU2fveoWeJBTzOzzvz" Organization: Universidad Carlos III de Madrid Date: Fri, 20 Feb 2009 22:05:18 +0100 Message-Id: <1235163918.4633.78.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16476.002 Cc: autoconf@ietf.org Subject: Re: [Autoconf] new charter X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2009 21:05:07 -0000 --=-xyLU2fveoWeJBTzOzzvz Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable OK, understood. If we finally go to new solutions space (if existing IP autoconfiguration mechanisms cannot be used), then this would have to be discussed, I guess, because there IPv4 vs IPv6 might have an impact. thanks for the clariffication, Carlos El vie, 20-02-2009 a las 22:57 +0200, Jari Arkko escribi=F3: > I intentionally made the new charter not say anything about that. My=20 > belief is that the type of architecture document that we are looking at=20 > can easily talk about both IPv4 and IPv6. >=20 > Jari >=20 > Carlos Jes=FAs Bernardos Cano wrote: > > Hi Jari, > > > > One quick comment (I haven't read the proposed text in detail yet): ar= e > > we considering IPv6 only? IPv6 and IPv4? IPv4 only? previous charter > > focused only on IPv6 solutions... > > > > Kind Regards, > > > > Carlos > > > > El vie, 20-02-2009 a las 21:59 +0200, Jari Arkko escribi=F3: > > =20 > >> In the light of the new direction for the working group, > >> we are planning to update the charter as follows. Comments > >> appreciated. > >> > >> Jari & the chairs > >> > >> ---- > >> > >> Ad-Hoc Network Autoconfiguration (autoconf)=20 > >> -------------------------------------------------------------=20 > >> Last Modified: 2009-02-18=20 > >> =20 > >> Cuurent Status: Active Working Group=20 > >> =20 > >> Additional information is available at tools.ietf.org/wg/autoconf=20 > >> =20 > >> Chair(s):=20 > >> Ryuji Wakikawa [ryuji.wakikawa@gmail.com]=20 > >> Thomas Clausen [T.Clausen@computer.org]=20 > >> =20 > >> Internet Area Director(s):=20 > >> Jari Arkko [jari.arkko@piuha.net]=20 > >> Mark Townsley [townsley@cisco.com]=20 > >> =20 > >> Internet Area Advisor:=20 > >> Jari Arkko [jari.arkko@piuha.net]=20 > >> =20 > >> Mailing Lists:=20 > >> General Discussion: autoconf@ietf.org=20 > >> To Subscribe: https://www.ietf.org/mailman/listinfo/autoconf=20 > >> Archive:=20 > >> http://www.ietf.org/mail-archive/web/autoconf/current/maillist.html=20 > >> > >> Description of Working Group:=20 > >> =20 > >> In order to communicate among themselves, ad hoc nodes (refer to RFC=20 > >> 2501) need to configure their network interface(s) with local addresse= s=20 > >> that are valid within an ad hoc network. Ad hoc nodes may also need to= =20 > >> configure globally routable addresses, in order to communicate with=20 > >> devices on the Internet. From the IP layer perspective, an ad hoc=20 > >> network presents itself as a L3 multi-hop network formed over a=20 > >> collection of links.=20 > >> =20 > >> The main purpose of the AUTOCONF WG is to describe the addressing mode= l=20 > >> for ad hoc networks and how nodes in these networks configure their=20 > >> addresses. It is required that such models do not cause problems for a= d=20 > >> hoc-unaware parts of the system, such as standard applications running= =20 > >> on an ad hoc node or regular Internet nodes attached to the ad hoc=20 > >> nodes. This group's effort may include the development of new protocol= =20 > >> mechanisms, should the existing IP autoconfiguration mechanisms be fou= nd=20 > >> inadequate. However, the first task of the working group is to describ= e=20 > >> one practical addressing model for ad hoc networks.=20 > >> =20 > >> Once this sole work item is completed, the group can be rechartered to= =20 > >> work on additional issues.=20 > >> =20 > >> Goals and Milestones:=20 > >> =20 > >> Apr 2009 Submit initial draft on address configuration in ad hoc netwo= rks > >> Sep 2009 Submit address configuration draft to IESG as Informational o= r=20 > >> close WG > >> > >> _______________________________________________ > >> Autoconf mailing list > >> Autoconf@ietf.org > >> https://www.ietf.org/mailman/listinfo/autoconf > >> =20 >=20 --=20 Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ WEEDEV 2009: 2nd Workshop on Experimental Evaluation and Deployment Experiences on Vehicular networks http://www.weedev.org/ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ --=-xyLU2fveoWeJBTzOzzvz Content-Type: application/pgp-signature; name=signature.asc Content-Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEABECAAYFAkmfGw4ACgkQNdy6TdFwT2crXwCdFryXxINsri45XFFKgBZZcKEH ViwAnj5SzbNCrmQfzBWmgV8IHEiKgDQZ =7X2l -----END PGP SIGNATURE----- --=-xyLU2fveoWeJBTzOzzvz-- From paul@marvell.com Sun Feb 22 23:59:29 2009 Return-Path: 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 32CC13A67A1 for ; Sun, 22 Feb 2009 23:59:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6] 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 nOhhvYkziS9U for ; Sun, 22 Feb 2009 23:59:28 -0800 (PST) Received: from maili.marvell.com (host2.marvell.com [65.219.4.2]) by core3.amsl.com (Postfix) with ESMTP id 2D1833A672F for ; Sun, 22 Feb 2009 23:59:28 -0800 (PST) Received: from MSI-MTA.marvell.com (msi-mta.marvell.com [10.68.76.91]) by maili.marvell.com (Postfix) with ESMTP id C62625F22A; Sun, 22 Feb 2009 23:59:45 -0800 (PST) Received: from sc-owa01.marvell.com ([10.93.76.21]) by MSI-MTA.marvell.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 22 Feb 2009 23:59:45 -0800 Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by sc-owa01.marvell.com ([10.93.76.21]) with mapi; Sun, 22 Feb 2009 23:59:45 -0800 From: Paul Lambert To: "cjbc@it.uc3m.es" , Jari Arkko Date: Sun, 22 Feb 2009 23:59:38 -0800 Thread-Topic: [Autoconf] new charter Thread-Index: AcmTnvM+ZAFJhF1ZRtKaQTlKsJTmRAB67RdQ Message-ID: <7BAC95F5A7E67643AAFB2C31BEE662D01489D12D@SC-VEXCH2.marvell.com> References: <499F0BA7.90501@piuha.net> <1235161786.4633.73.camel@localhost> <499F1924.8090801@piuha.net> <1235163918.4633.78.camel@localhost> In-Reply-To: <1235163918.4633.78.camel@localhost> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 23 Feb 2009 07:59:45.0597 (UTC) FILETIME=[B11986D0:01C9958C] Cc: "autoconf@ietf.org" Subject: Re: [Autoconf] new charter X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 07:59:29 -0000 I'm glad to see IPv4 be in scope in the new charter. I've been lurking on = the list for awhile hoping to find existing or emerging IETF solutions for = ad hoc address assignment. Specifically there is a real need for IP addres= s assignment solutions for 802.11 ad hoc networks. There are unique issues= when security is included based on WPA2 or WPA2 using WPS (Wi-Fi Protected= Setup). Security for WPA2 is connection oriented and requires the pair-wise establi= shment of the keying relationships. This means that WPA2 secured multicast= can not be used for peer discovery or address assignment in an 802.11 ad h= oc network. New mechanisms are required for rapid peer identification and = IP address assignment. I'd be very interested in collaborating on solutions for the specific issue= s of 802.11 ad hoc networks. Regards, Paul > -----Original Message----- > From: autoconf-bounces@ietf.org [mailto:autoconf-bounces@ietf.org] On > Behalf Of Carlos Jes=FAs Bernardos Cano > Sent: Friday, February 20, 2009 1:05 PM > To: Jari Arkko > Cc: autoconf@ietf.org > Subject: Re: [Autoconf] new charter > > OK, understood. If we finally go to new solutions space (if existing IP > autoconfiguration mechanisms cannot be used), then this would have to be > discussed, I guess, because there IPv4 vs IPv6 might have an impact. > > thanks for the clariffication, > > Carlos > > El vie, 20-02-2009 a las 22:57 +0200, Jari Arkko escribi=F3: > > I intentionally made the new charter not say anything about that. My > > belief is that the type of architecture document that we are looking at > > can easily talk about both IPv4 and IPv6. > > > > Jari > > > > Carlos Jes=FAs Bernardos Cano wrote: > > > Hi Jari, > > > > > > One quick comment (I haven't read the proposed text in detail > yet): are > > > we considering IPv6 only? IPv6 and IPv4? IPv4 only? previous charter > > > focused only on IPv6 solutions... > > > > > > Kind Regards, > > > > > > Carlos > > > > > > El vie, 20-02-2009 a las 21:59 +0200, Jari Arkko escribi=F3: > > > > > >> In the light of the new direction for the working group, > > >> we are planning to update the charter as follows. Comments > > >> appreciated. > > >> > > >> Jari & the chairs > > >> > > >> ---- > > >> > > >> Ad-Hoc Network Autoconfiguration (autoconf) > > >> ------------------------------------------------------------- > > >> Last Modified: 2009-02-18 > > >> > > >> Cuurent Status: Active Working Group > > >> > > >> Additional information is available at tools.ietf.org/wg/autoconf > > >> > > >> Chair(s): > > >> Ryuji Wakikawa [ryuji.wakikawa@gmail.com] > > >> Thomas Clausen [T.Clausen@computer.org] > > >> > > >> Internet Area Director(s): > > >> Jari Arkko [jari.arkko@piuha.net] > > >> Mark Townsley [townsley@cisco.com] > > >> > > >> Internet Area Advisor: > > >> Jari Arkko [jari.arkko@piuha.net] > > >> > > >> Mailing Lists: > > >> General Discussion: autoconf@ietf.org > > >> To Subscribe: https://www.ietf.org/mailman/listinfo/autoconf > > >> Archive: > > >> http://www.ietf.org/mail-archive/web/autoconf/current/maillist.html > > >> > > >> Description of Working Group: > > >> > > >> In order to communicate among themselves, ad hoc nodes (refer to RFC > > >> 2501) need to configure their network interface(s) with local > addresses > > >> that are valid within an ad hoc network. Ad hoc nodes may also need > to > > >> configure globally routable addresses, in order to communicate with > > >> devices on the Internet. From the IP layer perspective, an ad hoc > > >> network presents itself as a L3 multi-hop network formed over a > > >> collection of links. > > >> > > >> The main purpose of the AUTOCONF WG is to describe the addressing > model > > >> for ad hoc networks and how nodes in these networks configure their > > >> addresses. It is required that such models do not cause problems for > ad > > >> hoc-unaware parts of the system, such as standard applications > running > > >> on an ad hoc node or regular Internet nodes attached to the ad hoc > > >> nodes. This group's effort may include the development of new > protocol > > >> mechanisms, should the existing IP autoconfiguration mechanisms be > found > > >> inadequate. However, the first task of the working group is to > describe > > >> one practical addressing model for ad hoc networks. > > >> > > >> Once this sole work item is completed, the group can be rechartered > to > > >> work on additional issues. > > >> > > >> Goals and Milestones: > > >> > > >> Apr 2009 Submit initial draft on address configuration in ad hoc > networks > > >> Sep 2009 Submit address configuration draft to IESG as Informational > or > > >> close WG > > >> > > >> _______________________________________________ > > >> Autoconf mailing list > > >> Autoconf@ietf.org > > >> https://www.ietf.org/mailman/listinfo/autoconf > > >> > > > -- > Carlos Jes=FAs Bernardos Cano http://www.netcoms.net > GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > WEEDEV 2009: 2nd Workshop on Experimental Evaluation and > Deployment Experiences on Vehicular networks > http://www.weedev.org/ > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ From emmanuel.baccelli@gmail.com Mon Feb 23 02:03:36 2009 Return-Path: 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 38E1828C0DE for ; Mon, 23 Feb 2009 02:03:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.821 X-Spam-Level: X-Spam-Status: No, score=-1.821 tagged_above=-999 required=5 tests=[AWL=0.155, 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 c8GR-8rGm1fz for ; Mon, 23 Feb 2009 02:03:35 -0800 (PST) Received: from mail-bw0-f161.google.com (mail-bw0-f161.google.com [209.85.218.161]) by core3.amsl.com (Postfix) with ESMTP id B20C33A6B39 for ; Mon, 23 Feb 2009 02:03:19 -0800 (PST) Received: by bwz5 with SMTP id 5so4539466bwz.13 for ; Mon, 23 Feb 2009 02:03:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=459S1xXKKc5ecUa4I9AgUlH6axYyBZk78k30rmigmxA=; b=K38Q15dZQgT/fZ1KaurzMalAHmTaCRm8mBeMjbGggwyovNXCpX37op6Oz88r1dUoTk KAjkSBJjZ1sBDgGbRSKWJxRNLls1kmu5q7pbbj322VN9ere6vkROHQU02cBgvGZjlrv2 UswA/hvNsATR7lQ4ZoXrMwfMSH8+QmX0Jv5og= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; b=G0ueUQPqzK7lJSQB+pB7I5mDWN6Cnp/bfPKiQxXvB5NpBccfeLfBc2ZVYXjTmKmYXS w8FjugDbUF9OJV2kgtBZpwJb/sQIY6etH6X3LpZqGEeJI25cQJyiDy1TVkSKra/a4Up1 tWtcznjVt+ONp35W8mO/JCL1Jk48hhtaN3Njo= MIME-Version: 1.0 Sender: emmanuel.baccelli@gmail.com Received: by 10.103.49.12 with SMTP id b12mr3167539muk.65.1235383415517; Mon, 23 Feb 2009 02:03:35 -0800 (PST) Date: Mon, 23 Feb 2009 11:03:35 +0100 X-Google-Sender-Auth: f8aafa7a7df5ae83 Message-ID: From: Emmanuel Baccelli To: autoconf@ietf.org Content-Type: multipart/alternative; boundary=0016364d1fefa4b2b30463931db8 Subject: [Autoconf] updated draft on aspects of multi-hop wireless communication X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 10:03:36 -0000 --0016364d1fefa4b2b30463931db8 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi all, following the fruitful discussions about initial version of the document, here is an update to the draft describing aspects of multi-hop wireless communication: http://www.ietf.org/internet-drafts/draft-baccelli-multi-hop-wireless-communication-01.txt Again, the goal of this document is to identify a consensus about this topic, and then use this to move on quicker with the rest of the work... Please review it, and provide feedback as soon as possible. Cheers Emmanuel --0016364d1fefa4b2b30463931db8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi all,


following the fruitful discussions about init= ial version of the document, here is an update to the draft describing = ;aspects of multi-hop wireless communication: 

http://www.ietf.org/internet-drafts/draft-bac= celli-multi-hop-wireless-communication-01.txt


Again, the goal of this document = is to identify a consensus about this topic, and then use this to move on q= uicker with the rest of the work...

Please review it, and provide feedback as soon as= possible. 


Cheers
<= br>
Emmanuel
--0016364d1fefa4b2b30463931db8-- From paul@marvell.com Mon Feb 23 02:54:33 2009 Return-Path: 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 C88B728C172 for ; Mon, 23 Feb 2009 02:54:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, 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 pcxlawWy+nR3 for ; Mon, 23 Feb 2009 02:54:32 -0800 (PST) Received: from maili.marvell.com (host2.marvell.com [65.219.4.2]) by core3.amsl.com (Postfix) with ESMTP id D3CDE28C185 for ; Mon, 23 Feb 2009 02:54:32 -0800 (PST) Received: from MSI-MTA.marvell.com (msi-mta.marvell.com [10.68.76.91]) by maili.marvell.com (Postfix) with ESMTP id 06F285F22E; Mon, 23 Feb 2009 02:54:51 -0800 (PST) Received: from sc-owa01.marvell.com ([10.93.76.21]) by MSI-MTA.marvell.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 23 Feb 2009 02:54:50 -0800 Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by sc-owa01.marvell.com ([10.93.76.21]) with mapi; Mon, 23 Feb 2009 02:54:50 -0800 From: Paul Lambert To: Emmanuel Baccelli , "autoconf@ietf.org" Date: Mon, 23 Feb 2009 02:54:43 -0800 Thread-Topic: [Autoconf] updated draft on aspects of multi-hop wireless communication Thread-Index: AcmVng0at4IYN8F8RbqUjfdVphcO8QAAJQyw Message-ID: <7BAC95F5A7E67643AAFB2C31BEE662D01489D135@SC-VEXCH2.marvell.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 23 Feb 2009 10:54:50.0779 (UTC) FILETIME=[26AD16B0:01C995A5] Subject: Re: [Autoconf] updated draft on aspects of multi-hop wireless communication X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 10:54:33 -0000 Hi, The draft-baccelli-multi-hop-wireless-communication-01 provides an interest= ing list of issues that might be addressed by this working group. >From a quick review it does not appear to address: - ad hoc network coalescing. Coalescing has clear implications for IP address assignment - there is no mention of multicast versus unicast issues. Perhaps since the document makes all links potentially asymmetric and unreliable there is no distinction. At least for 802.11 ad hoc I find significant implications. - it does not address link security establishment The process of setting up the link security is out of scope, but as I've mentioned in earlier emails this has a clear impact on available networking mechanisms. It is also a very important architectural consideration to ensure that IP address assignment has some level of security. Asymmetric links in all "ad hoc" networks. Is it possible to partition our= problem statements so that this is just one of several optional attributes= that must be addressed? Most modern wireless MAC layers have reliable unicast. I can see some broa= dcast only links - like satellite broadcast, but outside military applicati= ons I am not familiar with broadly deployed commercial wireless networking = technologies that are based on asymmetric unicast transmissions. Perhaps so= meone on this list could point me to the technologies that they are conside= ring for this requirement. Regards, Paul ________________________________________ From: autoconf-bounces@ietf.org [mailto:autoconf-bounces@ietf.org] On Behal= f Of Emmanuel Baccelli Sent: Monday, February 23, 2009 2:04 AM To: autoconf@ietf.org Subject: [Autoconf] updated draft on aspects of multi-hop wireless communic= ation Hi all, following the fruitful discussions about initial version of the document, h= ere is an update to the draft describing aspects of multi-hop wireless comm= unication: http://www.ietf.org/internet-drafts/draft-baccelli-multi-hop-wireless-commu= nication-01.txt Again, the goal of this document is to identify a consensus about this topi= c, and then use this to move on quicker with the rest of the work... Please review it, and provide feedback as soon as possible. Cheers Emmanuel From emmanuel.baccelli@gmail.com Mon Feb 23 05:00:52 2009 Return-Path: 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 12EFA3A693B for ; Mon, 23 Feb 2009 05:00:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.852 X-Spam-Level: X-Spam-Status: No, score=-1.852 tagged_above=-999 required=5 tests=[AWL=0.124, 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 6UAQwBLicJtL for ; Mon, 23 Feb 2009 05:00:50 -0800 (PST) Received: from mail-bw0-f161.google.com (mail-bw0-f161.google.com [209.85.218.161]) by core3.amsl.com (Postfix) with ESMTP id 014AF3A67F5 for ; Mon, 23 Feb 2009 05:00:49 -0800 (PST) Received: by bwz5 with SMTP id 5so4702276bwz.13 for ; Mon, 23 Feb 2009 05:01:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to :content-type; bh=M/4kiGxE0BzymRrGgHoso0+6HEGWQ1oHfeMjcE1dGWc=; b=kQA4fdGf3RdU2VGK/FOC4Yx93JIScbTGeFroH9fFyHC/a9UDWBIRC7WfmWjUsql3RN 7MqDEv12Wq7Wp3LsS3aeYJhqHzSTFASP4CJQUtyDshfHBZFhrHayO2z2NIDZguVKqbBn 1t5Qu4XdQgzGzSBOoBbakzbLfHP5QlH8d3LwA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; b=jST9vVLGK2mBcERF/yrts4cm3xu+2TeZPxmb23rKv6QtOkZeyuxuObbmebqi4PsXHy A/wqyVEsqpg0jmOVTxvbtQKeNJ4Rp17WanRa7nQtqr/Nu4o2zpEwZkP6BhKioqt77Ai7 Q/sr/Fvsrhsu0AJFH1AxC14jxQ+rkplBmy/iY= MIME-Version: 1.0 Sender: emmanuel.baccelli@gmail.com Received: by 10.103.226.10 with SMTP id d10mr3261426mur.84.1235394066563; Mon, 23 Feb 2009 05:01:06 -0800 (PST) In-Reply-To: <7BAC95F5A7E67643AAFB2C31BEE662D01489D135@SC-VEXCH2.marvell.com> References: <7BAC95F5A7E67643AAFB2C31BEE662D01489D135@SC-VEXCH2.marvell.com> Date: Mon, 23 Feb 2009 14:01:06 +0100 X-Google-Sender-Auth: 3168b10690deff9b Message-ID: From: Emmanuel Baccelli To: "autoconf@ietf.org" Content-Type: multipart/alternative; boundary=0016e6dd96a07ec23804639598a6 Subject: Re: [Autoconf] updated draft on aspects of multi-hop wireless communication X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 13:00:52 -0000 --0016e6dd96a07ec23804639598a6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Paul, thanks for your feedback. This document aims at describing "some important aspects, experienced over the past decade, of multi-hop ad hoc wireless communication between routers", as stated in the abstract. The goal is to reach a common uderstanding of the basic aspects presented in the draft (asymmetry, time-variation, non-transitivity, and radio-range aspects of communcation), which we can then refer to when discussing further issues, such as the ones you mention, for instance. The goal is NOT to write another problem statement, nor to be exhaustive regarding issues that AUTOCONF should address. Do you have any comments about the description of the basic aspects presented in the draft? Cheers, Emmanuel On Mon, Feb 23, 2009 at 11:54 AM, Paul Lambert wrote: > > Hi, > > The draft-baccelli-multi-hop-wireless-communication-01 provides an > interesting list of issues that might be addressed by this working group. > > From a quick review it does not appear to address: > - ad hoc network coalescing. Coalescing has clear implications for > IP address assignment > - there is no mention of multicast versus unicast issues. Perhaps > since the document makes all links potentially asymmetric and > unreliable there is no distinction. At least for 802.11 ad hoc > I find significant implications. > - it does not address link security establishment > The process of setting up the link security is out of scope, but as > I've mentioned in earlier emails this has a clear impact on available > networking mechanisms. > It is also a very important architectural consideration to ensure that > IP address assignment has some level of security. > > Asymmetric links in all "ad hoc" networks. Is it possible to partition our > problem statements so that this is just one of several optional attributes > that must be addressed? > > Most modern wireless MAC layers have reliable unicast. I can see some > broadcast only links - like satellite broadcast, but outside military > applications I am not familiar with broadly deployed commercial wireless > networking technologies that are based on asymmetric unicast transmissions. > Perhaps someone on this list could point me to the technologies that they > are considering for this requirement. > > > Regards, > > Paul > > > ________________________________________ > From: autoconf-bounces@ietf.org [mailto:autoconf-bounces@ietf.org] On > Behalf Of Emmanuel Baccelli > Sent: Monday, February 23, 2009 2:04 AM > To: autoconf@ietf.org > Subject: [Autoconf] updated draft on aspects of multi-hop wireless > communication > > Hi all, > > > following the fruitful discussions about initial version of the document, > here is an update to the draft describing aspects of multi-hop wireless > communication: > > > http://www.ietf.org/internet-drafts/draft-baccelli-multi-hop-wireless-communication-01.txt > > > Again, the goal of this document is to identify a consensus about this > topic, and then use this to move on quicker with the rest of the work... > > Please review it, and provide feedback as soon as possible. > > > Cheers > > Emmanuel > --0016e6dd96a07ec23804639598a6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Paul,

thanks for your feedback. This document aims at= describing "some important aspects, experienced over the past de= cade, of multi-hop ad hoc wireless communication between routers",&nbs= p;as stated in the abstract.

The goal is to reach a common uderstanding of the basic= aspects presented in the draft (asymmetry, time-variation, non-transitivit= y, and radio-range aspects of communcation), which we can then refer to whe= n discussing further issues, such as the ones you mention, for instance.&nb= sp;

The goal is NOT to write another problem statement, nor= to be exhaustive regarding issues that AUTOCONF should address.
=
Do you have any comments about the description of the basic = aspects presented in the draft?


Cheers,

Emmanue= l





On Mon, Feb 23, 2009 at 11:54 AM, Paul Lambert <paul@marvell.com> wrote:

Hi,

The draft-baccelli-multi-hop-wireless-communication-01 provides an interest= ing list of issues that might be addressed by this working group.

>From a quick review it does not appear to address:
 - ad hoc network coalescing.  Coalescing has clear implications = for
  IP address assignment
 - there is no mention of multicast versus unicast issues.  Perha= ps
  since the document makes all links potentially asymmetric and
  unreliable there is no distinction.  At least for 802.11 ad ho= c
  I find significant implications.
 - it does not address link security establishment
  The process of setting up the link security is out of scope, but as=
  I've mentioned in earlier emails this has a clear impact on ava= ilable
  networking mechanisms.
  It is also a very important architectural consideration to ensure t= hat
  IP address assignment has some level of security.

Asymmetric links in all "ad hoc" networks.  Is it possible t= o partition our problem statements so that this is just one of several opti= onal attributes that must be addressed?

Most modern wireless MAC layers have reliable unicast.  I can see some= broadcast only links - like satellite broadcast, but outside military appl= ications I am not familiar with broadly deployed commercial wireless networ= king technologies that are based on asymmetric unicast transmissions. Perha= ps someone on this list could point me to the technologies that they are co= nsidering for this requirement.


Regards,

Paul


________________________________________
From: autoconf-bounces@ietf.or= g [mailto:autoconf-bounces= @ietf.org] On Behalf Of Emmanuel Baccelli
Sent: Monday, February 23, 2009 2:04 AM
To: autoconf@ietf.org
Subject: [Autoconf] updated draft on aspects of multi-hop wireless communic= ation

Hi all,


following the fruitful discussions about initial version of the document, h= ere is an update to the draft describing aspects of multi-hop wireless comm= unication:

http://www.ietf.org/internet-= drafts/draft-baccelli-multi-hop-wireless-communication-01.txt


Again, the goal of this document is to identify a consensus about this topi= c, and then use this to move on quicker with the rest of the work...

Please review it, and provide feedback as soon as possible.


Cheers

Emmanuel

--0016e6dd96a07ec23804639598a6-- From ryuji.wakikawa@gmail.com Mon Feb 23 08:23:08 2009 Return-Path: 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 7188628C142 for ; Mon, 23 Feb 2009 08:23:08 -0800 (PST) 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 VARgg8i-UOBv for ; Mon, 23 Feb 2009 08:23:07 -0800 (PST) Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.187]) by core3.amsl.com (Postfix) with ESMTP id 1F1E428C13E for ; Mon, 23 Feb 2009 08:23:06 -0800 (PST) Received: by ti-out-0910.google.com with SMTP id 11so1476405tim.25 for ; Mon, 23 Feb 2009 08:23:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:in-reply-to:subject :references:message-id:content-type:content-transfer-encoding :mime-version:date:cc:x-mailer; bh=w8e00VbASbcdCGUOJIaiNHsEYRlSt1rZRpiGXXOl2CI=; b=ioJUBIj5XapozOS8TtgwenqAPZb7Czo19NRzjp8W8T4kHnw0ggeP7pk3HKK+8sTMSn L0dOAtcRamu1bnGo7CyqCMa10TiC0J0hwekRy8kuyV4CQV99PLZyzey8DdUsEGYzw3uD a5Myj8H70b3qDqaNvkjFLxS2dq8gcjLy0lwes= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:in-reply-to:subject:references:message-id:content-type :content-transfer-encoding:mime-version:date:cc:x-mailer; b=hoFmGMr+f0CZo2eRM7YPd29DaUCPdfkZCImBSMpMISWmt8AZGw8wukCmuZ3FBnXRtg rBmVbB0PUFdqAJcUdka45iFU/+LuOmEBD/Mxm0WH4H/CTRtcpJ0SE1hTXcA8nAOCw0X7 ATbXZrF1V0CnXLYZv2dUJpHabX8aYIZFd7ZCk= Received: by 10.110.40.8 with SMTP id n8mr6023167tin.41.1235406203909; Mon, 23 Feb 2009 08:23:23 -0800 (PST) Received: from ?10.0.1.198? (h219-110-221-065.catv02.itscom.jp [219.110.221.65]) by mx.google.com with ESMTPS id d4sm949402tib.28.2009.02.23.08.23.21 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 23 Feb 2009 08:23:22 -0800 (PST) From: Ryuji Wakikawa To: autoconf@ietf.org In-Reply-To: <499F0BA7.90501@piuha.net> References: <499F0BA7.90501@piuha.net> Message-Id: <7E8A76F7-2CE0-463A-8EE8-8877C46B4715@gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 24 Feb 2009 01:23:19 +0900 X-Mailer: Apple Mail (2.930.3) Subject: Re: [Autoconf] new charter X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 16:23:08 -0000 Hi all, It seems the line break is missed from Jari's mail. so, resend the new charter. regards, ryuji Ad-Hoc Network Autoconfiguration (autoconf) Last Modified: 2009-02-18 Additional information is available at tools.ietf.org/wg/autoconf Chair(s): Ryuji Wakikawa Thomas Clausen Internet Area Director(s): Jari Arkko Mark Townsley Internet Area Advisor: Jari Arkko Mailing Lists: General Discussion: autoconf@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/autoconf Archive: http://www.ietf.org/mail-archive/web/autoconf/current/maillist.html Description of Working Group: In order to communicate among themselves, ad hoc nodes (refer to RFC 2501) need to configure their network interface(s) with local addresses that are valid within an ad hoc network. Ad hoc nodes may also need to configure globally routable addresses, in order to communicate with devices on the Internet. From the IP layer perspective, an ad hoc network presents itself as a L3 multi-hop network formed over a collection of links. The main purpose of the AUTOCONF WG is to describe the addressing model for ad hoc networks and how nodes in these networks configure their addresses. It is required that such models do not cause problems for ad hoc-unaware parts of the system, such as standard applications running on an ad hoc node or regular Internet nodes attached to the ad hoc nodes. This group's effort may include the development of new protocol mechanisms, should the existing IP autoconfiguration mechanisms be found inadequate. However, the first task of the working group is to describe one practical addressing model for ad hoc networks. Once this sole work item is completed, the group can be rechartered to work on additional issues. Goals and Milestones: Apr 2009 Submit initial draft on address configuration in ad hoc networks Sep 2009 Submit address configuration draft to IESG as Informational or close WG. On 2009/02/21, at 4:59, Jari Arkko wrote: > In the light of the new direction for the working group, > we are planning to update the charter as follows. Comments > appreciated. > > Jari & the chairs > > ---- > > Ad-Hoc Network Autoconfiguration (autoconf) > ------------------------------------------------------------- Last > Modified: 2009-02-18 Cuurent Status: Active Working Group Additional > information is available at tools.ietf.org/wg/autoconf Chair(s): > Ryuji Wakikawa [ryuji.wakikawa@gmail.com] Thomas Clausen [T.Clausen@computer.org > ] Internet Area Director(s): Jari Arkko [jari.arkko@piuha.net] Mark > Townsley [townsley@cisco.com] Internet Area Advisor: Jari Arkko [jari.arkko@piuha.net > ] Mailing Lists: General Discussion: autoconf@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/autoconf > Archive: http://www.ietf.org/mail-archive/web/autoconf/current/maillist.html > Description of Working Group: In order to communicate among > themselves, ad hoc nodes (refer to RFC 2501) need to configure their > network interface(s) with local addresses that are valid within an > ad hoc network. Ad hoc nodes may also need to configure globally > routable addresses, in order to communicate with devices on the > Internet. From the IP layer perspective, an ad hoc network presents > itself as a L3 multi-hop network formed over a collection of links. > The main purpose of the AUTOCONF WG is to describe the addressing > model for ad hoc networks and how nodes in these networks configure > their addresses. It is required that such models do not cause > problems for ad hoc-unaware parts of the system, such as standard > applications running on an ad hoc node or regular Internet nodes > attached to the ad hoc nodes. This group's effort may include the > development of new protocol mechanisms, should the existing IP > autoconfiguration mechanisms be found inadequate. However, the first > task of the working group is to describe one practical addressing > model for ad hoc networks. Once this sole work item is completed, > the group can be rechartered to work on additional issues. Goals and > Milestones: Apr 2009 Submit initial draft on address configuration > in ad hoc networks > Sep 2009 Submit address configuration draft to IESG as Informational > or close WG > > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf From charles.perkins@earthlink.net Mon Feb 23 10:20:49 2009 Return-Path: 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 D46AA3A67D7 for ; Mon, 23 Feb 2009 10:20:49 -0800 (PST) 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 N6vBgw+CSE+I for ; Mon, 23 Feb 2009 10:20:49 -0800 (PST) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by core3.amsl.com (Postfix) with ESMTP id DA87D3A6784 for ; Mon, 23 Feb 2009 10:20:48 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=mGyGiZDtKYw5Gk72o3cZFd35xOSpWikkObcgm7ctMuvQtheneOJis3gZAKMnX4pp; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [99.51.129.145] (helo=[10.166.254.13]) by elasmtp-scoter.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1LbfQP-00057v-Ii; Mon, 23 Feb 2009 13:21:05 -0500 Message-ID: <49A2E90E.10808@earthlink.net> Date: Mon, 23 Feb 2009 10:21:02 -0800 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Paul Lambert References: <7BAC95F5A7E67643AAFB2C31BEE662D01489D135@SC-VEXCH2.marvell.com> In-Reply-To: <7BAC95F5A7E67643AAFB2C31BEE662D01489D135@SC-VEXCH2.marvell.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f52afc5e0f49191bc803abe662aea8393bb350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.51.129.145 Cc: "autoconf@ietf.org" , Emmanuel Baccelli Subject: Re: [Autoconf] updated draft on aspects of multi-hop wireless communication X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 18:20:49 -0000 Hello Paul, The document isn't intended to suggest a list of work items for consideration by [autoconf]. Instead, it is just a description of common properties of radio and other wireless links. These properties are not quite universal, but they are widespread. Some of them can be alleviated a bit by mechanisms below the network protocol level. So we are not suggesting requirements or work items. Instead, we simply wanted to make as clear as possible some of the characteristics of the transmission media whose widespread availability is motivating the work of [autoconf]. Your list of issues would, I think, all fit best in a requirements document. I am almost certain they should be considered out of scope for the document under discussion. Regards, Charlie P. Paul Lambert wrote: > Hi, > > The draft-baccelli-multi-hop-wireless-communication-01 provides an interesting list of issues that might be addressed by this working group. > > >From a quick review it does not appear to address: > - ad hoc network coalescing. Coalescing has clear implications for > IP address assignment > - there is no mention of multicast versus unicast issues. Perhaps > since the document makes all links potentially asymmetric and > unreliable there is no distinction. At least for 802.11 ad hoc > I find significant implications. > - it does not address link security establishment > The process of setting up the link security is out of scope, but as > I've mentioned in earlier emails this has a clear impact on available > networking mechanisms. > It is also a very important architectural consideration to ensure that > IP address assignment has some level of security. > > Asymmetric links in all "ad hoc" networks. Is it possible to partition our problem statements so that this is just one of several optional attributes that must be addressed? > > Most modern wireless MAC layers have reliable unicast. I can see some broadcast only links - like satellite broadcast, but outside military applications I am not familiar with broadly deployed commercial wireless networking technologies that are based on asymmetric unicast transmissions. Perhaps someone on this list could point me to the technologies that they are considering for this requirement. > > > Regards, > > Paul > > From alexandru.petrescu@gmail.com Mon Feb 23 13:55:55 2009 Return-Path: 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 4EBC728C20B for ; Mon, 23 Feb 2009 13:55:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.223 X-Spam-Level: X-Spam-Status: No, score=-2.223 tagged_above=-999 required=5 tests=[AWL=0.026, 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 X4+UJFfM6v9n for ; Mon, 23 Feb 2009 13:55:54 -0800 (PST) Received: from smtp4-g21.free.fr (smtp4-g21.free.fr [212.27.42.4]) by core3.amsl.com (Postfix) with ESMTP id 3494028C18B for ; Mon, 23 Feb 2009 13:55:52 -0800 (PST) Received: from smtp4-g21.free.fr (localhost [127.0.0.1]) by smtp4-g21.free.fr (Postfix) with ESMTP id 814454C810E; Mon, 23 Feb 2009 22:56:06 +0100 (CET) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp4-g21.free.fr (Postfix) with ESMTP id DA5BA4C8176; Mon, 23 Feb 2009 22:56:03 +0100 (CET) Message-ID: <49A31B60.9050604@gmail.com> Date: Mon, 23 Feb 2009 22:55:44 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Emmanuel Baccelli References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 090223-0, 23/02/2009), Outbound message X-Antivirus-Status: Clean Cc: autoconf@ietf.org Subject: Re: [Autoconf] updated draft on aspects of multi-hop wireless communication X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 21:55:55 -0000 Emmanuel, AUTOCONFers, Just a short clarifying point: I think it would be clarifying to illustrate the routers to have two interfaces. Routers with only one interface aren't very typical. Just a note, Alex Emmanuel Baccelli a écrit : > Hi all, > > > following the fruitful discussions about initial version of the > document, here is an update to the draft describing aspects of > multi-hop wireless communication: > > http://www.ietf.org/internet-drafts/draft-baccelli-multi-hop-wireless-communication-01.txt > > > > Again, the goal of this document is to identify a consensus about > this topic, and then use this to move on quicker with the rest of the > work... > > Please review it, and provide feedback as soon as possible. > > > Cheers > > Emmanuel > > > ------------------------------------------------------------------------ > > > _______________________________________________ Autoconf mailing list > Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf From charles.perkins@earthlink.net Mon Feb 23 14:01:48 2009 Return-Path: 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 BDE7B28C225 for ; Mon, 23 Feb 2009 14:01:48 -0800 (PST) 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 TRi3LtJ8f7r5 for ; Mon, 23 Feb 2009 14:01:47 -0800 (PST) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by core3.amsl.com (Postfix) with ESMTP id 8EA1E28C224 for ; Mon, 23 Feb 2009 14:01:47 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=tkPefFSWV1QyKbswhSHXj4k2R2fLIzkqKPLPQZjD28vsbkVNVpQW93AL+RbKIGIj; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [99.51.129.145] (helo=[10.166.254.13]) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1LbisC-0002rQ-SZ; Mon, 23 Feb 2009 17:02:01 -0500 Message-ID: <49A31CD5.4090204@earthlink.net> Date: Mon, 23 Feb 2009 14:01:57 -0800 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Alexandru Petrescu References: <49A31B60.9050604@gmail.com> In-Reply-To: <49A31B60.9050604@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f52eef2b63c5c5077a46d885d087d64f675350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.51.129.145 Cc: autoconf@ietf.org, Emmanuel Baccelli Subject: Re: [Autoconf] updated draft on aspects of multi-hop wireless communication X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 22:01:48 -0000 Hello Alex, On this point I disagree. I think it is better to show the routers with a single network interface -- which is what they have in real life. This is also the reason that techniques like split horizon aren't appropriate. Regards, Charlie P. Alexandru Petrescu wrote: > Emmanuel, AUTOCONFers, > > Just a short clarifying point: I think it would be clarifying to > illustrate the routers to have two interfaces. Routers with only one > interface aren't very typical. > > Just a note, > > Alex > > Emmanuel Baccelli a écrit : >> Hi all, >> >> >> following the fruitful discussions about initial version of the >> document, here is an update to the draft describing aspects of >> multi-hop wireless communication: >> >> http://www.ietf.org/internet-drafts/draft-baccelli-multi-hop-wireless-communication-01.txt >> >> >> >> >> Again, the goal of this document is to identify a consensus about >> this topic, and then use this to move on quicker with the rest of the >> work... >> >> Please review it, and provide feedback as soon as possible. >> >> >> Cheers >> >> Emmanuel >> >> >> ------------------------------------------------------------------------ >> >> >> _______________________________________________ Autoconf mailing list >> Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf > > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf > > From ietf@thomasclausen.org Mon Feb 23 15:20:43 2009 Return-Path: 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 086963A6AEA for ; Mon, 23 Feb 2009 15:20:43 -0800 (PST) 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 tYk0ulqLbZua for ; Mon, 23 Feb 2009 15:20:42 -0800 (PST) Received: from mho-01-bos.mailhop.org (mho-01-bos.mailhop.org [63.208.196.178]) by core3.amsl.com (Postfix) with ESMTP id 210D23A6AE9 for ; Mon, 23 Feb 2009 15:20:42 -0800 (PST) Received: from aste-genev-bois-153-1-76-71.w86-203.abo.wanadoo.fr ([86.203.162.71] helo=[192.168.147.106]) by mho-01-bos.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1Lbk6d-000Pxh-EB; Mon, 23 Feb 2009 23:20:59 +0000 X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 86.203.162.71 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18BxaN3M4T9cl6TFXy+tRCM In-Reply-To: <49A31CD5.4090204@earthlink.net> References: <49A31B60.9050604@gmail.com> <49A31CD5.4090204@earthlink.net> Mime-Version: 1.0 (Apple Message framework v753.1) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <532BA0E9-FBFD-4022-88AF-BB0D5108FF4D@thomasclausen.org> Content-Transfer-Encoding: quoted-printable From: Thomas Heide Clausen Date: Tue, 24 Feb 2009 00:20:56 +0100 To: "Charles E. Perkins" X-Mailer: Apple Mail (2.753.1) Cc: autoconf@ietf.org, Emmanuel Baccelli Subject: Re: [Autoconf] updated draft on aspects of multi-hop wireless communication X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 23:20:43 -0000 Hello Alex, To second Charlie here: in MANETs, routers: o ALWAYS have one MANET interface. o OFTEN they have other (non-MANET) interfaces o OCCASIONALLY have more than one MANET interface I.e. it is quite common for traffic to be forwarded over the same =20 interface as the one on which it was received. Thomas ps: and for the record, AFAIK all MANET wg routing protocols support =20 all the situations listed above, i.e. a MANET router with a single or =20= with multiple MANET interfaces and with or without other non-MANET =20 interfaces. On 23Feb , 2009, at 23:01 , Charles E. Perkins wrote: > > Hello Alex, > > On this point I disagree. I think it is better to show the > routers with a single network interface -- which is what > they have in real life. This is also the reason that techniques > like split horizon aren't appropriate. > > Regards, > Charlie P. > > > Alexandru Petrescu wrote: >> Emmanuel, AUTOCONFers, >> >> Just a short clarifying point: I think it would be clarifying to >> illustrate the routers to have two interfaces. Routers with only one >> interface aren't very typical. >> >> Just a note, >> >> Alex >> >> Emmanuel Baccelli a =E9crit : >>> Hi all, >>> >>> >>> following the fruitful discussions about initial version of the =20 >>> document, here is an update to the draft describing aspects of >>> multi-hop wireless communication: >>> >>> http://www.ietf.org/internet-drafts/draft-baccelli-multi-hop-=20 >>> wireless-communication-01.txt >>> >>> >>> >>> Again, the goal of this document is to identify a consensus about >>> this topic, and then use this to move on quicker with the rest of =20= >>> the >>> work... >>> >>> Please review it, and provide feedback as soon as possible. >>> >>> >>> Cheers >>> >>> Emmanuel >>> >>> >>> --------------------------------------------------------------------=20= >>> ---- >>> >>> >>> _______________________________________________ Autoconf mailing =20 >>> list >>> Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf >> >> _______________________________________________ >> Autoconf mailing list >> Autoconf@ietf.org >> https://www.ietf.org/mailman/listinfo/autoconf >> >> > > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf From paul@marvell.com Tue Feb 24 07:03:49 2009 Return-Path: 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 1CFC13A6A34 for ; Tue, 24 Feb 2009 07:03:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 EnCXqpm0t-FX for ; Tue, 24 Feb 2009 07:03:47 -0800 (PST) Received: from maili.marvell.com (host2.marvell.com [65.219.4.2]) by core3.amsl.com (Postfix) with ESMTP id ED0283A67A2 for ; Tue, 24 Feb 2009 07:03:47 -0800 (PST) Received: from MSI-MTA.marvell.com (msi-mta.marvell.com [10.68.76.91]) by maili.marvell.com (Postfix) with ESMTP id 0675E6211B; Tue, 24 Feb 2009 07:04:07 -0800 (PST) Received: from sc-owa01.marvell.com ([10.93.76.21]) by MSI-MTA.marvell.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 24 Feb 2009 07:04:06 -0800 Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by sc-owa01.marvell.com ([10.93.76.21]) with mapi; Tue, 24 Feb 2009 07:04:06 -0800 From: Paul Lambert To: Emmanuel Baccelli , "autoconf@ietf.org" Date: Tue, 24 Feb 2009 07:03:57 -0800 Thread-Topic: [Autoconf] updated draft on aspects of multi-hop wireless communication Thread-Index: AcmVts2/+HRlOZlOR3SVmQpIK39EBgA1983g Message-ID: <7BAC95F5A7E67643AAFB2C31BEE662D01489D23A@SC-VEXCH2.marvell.com> References: <7BAC95F5A7E67643AAFB2C31BEE662D01489D135@SC-VEXCH2.marvell.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 24 Feb 2009 15:04:06.0840 (UTC) FILETIME=[2398A380:01C99691] Subject: Re: [Autoconf] updated draft on aspects of multi-hop wireless communication X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 15:03:49 -0000 Hi Emmanuel, >The goal is NOT to write another problem statement, nor to be exhaustive >regarding issues that AUTOCONF should address. > >Do you have any comments about the description of the basic aspects >presented in the draft? Well ... if this is not part of the problem statement - I could use a point= er or more discussion on what this group wishes to address in the new reduc= ed scope charter. The document you submitted was though provoking for me on it's notion asymm= etric links. AS I mentioned before - this is not a consideration in any of= the IEEE 802 wireless or cellular protocols where I have experience. I ca= n see that there could be some interesting applications. My primary commen= t was that there are existing ad hoc IP address assignment problems that do= not have this attribute. I am starting to see that I may I may be "talking past' members on this lis= t ... and perhaps should just go away ... I notice that in your draft it s= ays: All are configured to provide store-and-forward functionality on top of these protocols, as needed to enable communications; consequently, they can be classified as routers in the resulting wireless network. None of the consumer devices that I'm concerned with (cellphones, cameras, = printers, etc.) will be routers. They are connected to a ad hoc network an= d still all need IP addresses. I'm a big fan of routers :-) ... but not al= l devices on an ad hoc network forward packets. If this group is solely in= terested in routing protocols ... I should go away and create another non-I= ETF proprietary protocol to solve my problem area. In this context - is there a specific advocate (customers, products, market= s) for the proposals on this list or is it strictly research centric? If there is need for such a target problem set I would like to suggest the = specific problem area of 802.11 ad hoc networks with 802.11i (aka WPA2) sec= urity. If some one is interested in this problem ... let me know ... otherw= ise if this is out of scope I will move to some other mailing list. Regards, Paul ________________________________________ From: autoconf-bounces@ietf.org [mailto:autoconf-bounces@ietf.org] On Behal= f Of Emmanuel Baccelli Sent: Monday, February 23, 2009 5:01 AM To: autoconf@ietf.org Subject: Re: [Autoconf] updated draft on aspects of multi-hop wireless comm= unication Hi Paul, thanks for your feedback. This document aims at describing "some important = aspects, experienced over the past decade, of multi-hop ad hoc wireless com= munication between routers", as stated in the abstract. The goal is to reach a common uderstanding of the basic aspects presented i= n the draft (asymmetry, time-variation, non-transitivity, and radio-range a= spects of communcation), which we can then refer to when discussing further= issues, such as the ones you mention, for instance. The goal is NOT to write another problem statement, nor to be exhaustive re= garding issues that AUTOCONF should address. Do you have any comments about the description of the basic aspects present= ed in the draft? Cheers, Emmanuel On Mon, Feb 23, 2009 at 11:54 AM, Paul Lambert wrote: Hi, The draft-baccelli-multi-hop-wireless-communication-01 provides an interest= ing list of issues that might be addressed by this working group. >From a quick review it does not appear to address: - ad hoc network coalescing. Coalescing has clear implications for IP address assignment - there is no mention of multicast versus unicast issues. Perhaps since the document makes all links potentially asymmetric and unreliable there is no distinction. At least for 802.11 ad hoc I find significant implications. - it does not address link security establishment The process of setting up the link security is out of scope, but as I've mentioned in earlier emails this has a clear impact on available networking mechanisms. It is also a very important architectural consideration to ensure that IP address assignment has some level of security. Asymmetric links in all "ad hoc" networks. Is it possible to partition our= problem statements so that this is just one of several optional attributes= that must be addressed? Most modern wireless MAC layers have reliable unicast. I can see some broa= dcast only links - like satellite broadcast, but outside military applicati= ons I am not familiar with broadly deployed commercial wireless networking = technologies that are based on asymmetric unicast transmissions. Perhaps so= meone on this list could point me to the technologies that they are conside= ring for this requirement. Regards, Paul ________________________________________ From: autoconf-bounces@ietf.org [mailto:autoconf-bounces@ietf.org] On Behal= f Of Emmanuel Baccelli Sent: Monday, February 23, 2009 2:04 AM To: autoconf@ietf.org Subject: [Autoconf] updated draft on aspects of multi-hop wireless communic= ation Hi all, following the fruitful discussions about initial version of the document, h= ere is an update to the draft describing aspects of multi-hop wireless comm= unication: http://www.ietf.org/internet-drafts/draft-baccelli-multi-hop-wireless-commu= nication-01.txt Again, the goal of this document is to identify a consensus about this topi= c, and then use this to move on quicker with the rest of the work... Please review it, and provide feedback as soon as possible. Cheers Emmanuel From paul@marvell.com Tue Feb 24 08:43:53 2009 Return-Path: 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 45A603A6804 for ; Tue, 24 Feb 2009 08:43:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 Qw7RQBL1bnG2 for ; Tue, 24 Feb 2009 08:43:52 -0800 (PST) Received: from maili.marvell.com (host2.marvell.com [65.219.4.2]) by core3.amsl.com (Postfix) with ESMTP id 78EA23A6B28 for ; Tue, 24 Feb 2009 08:43:52 -0800 (PST) Received: from MSI-MTA.marvell.com (msi-mta.marvell.com [10.68.76.91]) by maili.marvell.com (Postfix) with ESMTP id 060A662013; Tue, 24 Feb 2009 08:44:12 -0800 (PST) Received: from sc-owa01.marvell.com ([10.93.76.21]) by MSI-MTA.marvell.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 24 Feb 2009 08:44:11 -0800 Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by sc-owa01.marvell.com ([10.93.76.21]) with mapi; Tue, 24 Feb 2009 08:44:11 -0800 From: Paul Lambert To: "Charles E. Perkins" Date: Tue, 24 Feb 2009 08:44:03 -0800 Thread-Topic: [Autoconf] updated draft on aspects of multi-hop wireless communication Thread-Index: AcmV438KEDo4WTpzQTOdCOhPU7DhSQAs/e3A Message-ID: <7BAC95F5A7E67643AAFB2C31BEE662D01489D24B@SC-VEXCH2.marvell.com> References: <7BAC95F5A7E67643AAFB2C31BEE662D01489D135@SC-VEXCH2.marvell.com> <49A2E90E.10808@earthlink.net> In-Reply-To: <49A2E90E.10808@earthlink.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 24 Feb 2009 16:44:11.0748 (UTC) FILETIME=[1ECCE240:01C9969F] Cc: "autoconf@ietf.org" , Emmanuel Baccelli Subject: Re: [Autoconf] updated draft on aspects of multi-hop wireless communication X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 16:43:53 -0000 Hi Charlie, I'm traveling with limited email ... so I just now saw your note. > I am almost certain they > should be considered out of scope for the document > under discussion. In looking at the reference in the charter for "ad hoc" (RFC 2501) the defi= ned MANET is a Chimera - a mythical beast made of the parts of many other a= nimals. It is a shame that smaller monsters are out of scope (like 802.11 a= d hoc) ... Paul > -----Original Message----- > From: Charles E. Perkins [mailto:charles.perkins@earthlink.net] > Sent: Monday, February 23, 2009 10:21 AM > To: Paul Lambert > Cc: Emmanuel Baccelli; autoconf@ietf.org > Subject: Re: [Autoconf] updated draft on aspects of multi-hop wireless > communication > > > Hello Paul, > > The document isn't intended to suggest a list of work > items for consideration by [autoconf]. Instead, it is just > a description of common properties of radio and other > wireless links. These properties are not quite universal, > but they are widespread. Some of them can be alleviated > a bit by mechanisms below the network protocol level. > > So we are not suggesting requirements or work items. > Instead, we simply wanted to make as clear as possible > some of the characteristics of the transmission media > whose widespread availability is motivating the work > of [autoconf]. > > Your list of issues would, I think, all fit best in a > requirements document. I am almost certain they > should be considered out of scope for the document > under discussion. > > Regards, > Charlie P. > > > Paul Lambert wrote: > > Hi, > > > > The draft-baccelli-multi-hop-wireless-communication-01 provides an > interesting list of issues that might be addressed by this working group. > > > > >From a quick review it does not appear to address: > > - ad hoc network coalescing. Coalescing has clear implications for > > IP address assignment > > - there is no mention of multicast versus unicast issues. Perhaps > > since the document makes all links potentially asymmetric and > > unreliable there is no distinction. At least for 802.11 ad hoc > > I find significant implications. > > - it does not address link security establishment > > The process of setting up the link security is out of scope, but as > > I've mentioned in earlier emails this has a clear impact on availabl= e > > networking mechanisms. > > It is also a very important architectural consideration to ensure > that > > IP address assignment has some level of security. > > > > Asymmetric links in all "ad hoc" networks. Is it possible to partition > our problem statements so that this is just one of several optional > attributes that must be addressed? > > > > Most modern wireless MAC layers have reliable unicast. I can see some > broadcast only links - like satellite broadcast, but outside military > applications I am not familiar with broadly deployed commercial wireless > networking technologies that are based on asymmetric unicast transmission= s. > Perhaps someone on this list could point me to the technologies that they > are considering for this requirement. > > > > > > Regards, > > > > Paul > > > > From charles.perkins@earthlink.net Tue Feb 24 09:44:00 2009 Return-Path: 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 9992428C12C for ; Tue, 24 Feb 2009 09:44:00 -0800 (PST) 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=[AWL=0.000, 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 AP-6zyHah5WY for ; Tue, 24 Feb 2009 09:43:59 -0800 (PST) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by core3.amsl.com (Postfix) with ESMTP id 3D98B28C128 for ; Tue, 24 Feb 2009 09:43:59 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=euVtqNQXXQOqpGACVyIUeBiN0Umk67exUWUhDhVObwJTPwqtBS0M+FGQ3vGyc44U; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [99.51.129.145] (helo=[10.166.254.33]) by elasmtp-mealy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1Lc1KJ-0007OY-75; Tue, 24 Feb 2009 12:44:17 -0500 Message-ID: <49A431E9.3010401@earthlink.net> Date: Tue, 24 Feb 2009 09:44:09 -0800 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Paul Lambert References: <7BAC95F5A7E67643AAFB2C31BEE662D01489D135@SC-VEXCH2.marvell.com> <49A2E90E.10808@earthlink.net> <7BAC95F5A7E67643AAFB2C31BEE662D01489D24B@SC-VEXCH2.marvell.com> In-Reply-To: <7BAC95F5A7E67643AAFB2C31BEE662D01489D24B@SC-VEXCH2.marvell.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f52f810242912a66957a397f22498e59e47350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.51.129.145 Cc: "autoconf@ietf.org" , Emmanuel Baccelli Subject: Re: [Autoconf] updated draft on aspects of multi-hop wireless communication X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 17:44:00 -0000 Hello Paul, Paul Lambert wrote: >> I am almost certain they >> should be considered out of scope for the document >> under discussion. >> > > In looking at the reference in the charter for "ad hoc" (RFC 2501) the defined MANET is a Chimera - a mythical beast made of the parts of many other animals. It is a shame that smaller monsters are out of scope (like 802.11 ad hoc) ... > I am thoroughly mystified by your reply. Just because certain topics are out of scope for the small document by Emmanuel and me, does not mean they are out of scope for [autoconf]. Isn't it possible to have more than one document? Shouldn't we collect requirements in a requirements document instead of every other document that might be written? To be explicit, I am wholly in favor of making sure that the results of [autoconf] are applicable to 802.11 ad hoc. Did I say anything to imply otherwise? Regards, Charlie P. > Paul > > > > >> -----Original Message----- >> From: Charles E. Perkins [mailto:charles.perkins@earthlink.net] >> Sent: Monday, February 23, 2009 10:21 AM >> To: Paul Lambert >> Cc: Emmanuel Baccelli; autoconf@ietf.org >> Subject: Re: [Autoconf] updated draft on aspects of multi-hop wireless >> communication >> >> >> Hello Paul, >> >> The document isn't intended to suggest a list of work >> items for consideration by [autoconf]. Instead, it is just >> a description of common properties of radio and other >> wireless links. These properties are not quite universal, >> but they are widespread. Some of them can be alleviated >> a bit by mechanisms below the network protocol level. >> >> So we are not suggesting requirements or work items. >> Instead, we simply wanted to make as clear as possible >> some of the characteristics of the transmission media >> whose widespread availability is motivating the work >> of [autoconf]. >> >> Your list of issues would, I think, all fit best in a >> requirements document. I am almost certain they >> should be considered out of scope for the document >> under discussion. >> >> Regards, >> Charlie P. >> >> >> Paul Lambert wrote: >> >>> Hi, >>> >>> The draft-baccelli-multi-hop-wireless-communication-01 provides an >>> >> interesting list of issues that might be addressed by this working group. >> >>> >From a quick review it does not appear to address: >>> - ad hoc network coalescing. Coalescing has clear implications for >>> IP address assignment >>> - there is no mention of multicast versus unicast issues. Perhaps >>> since the document makes all links potentially asymmetric and >>> unreliable there is no distinction. At least for 802.11 ad hoc >>> I find significant implications. >>> - it does not address link security establishment >>> The process of setting up the link security is out of scope, but as >>> I've mentioned in earlier emails this has a clear impact on available >>> networking mechanisms. >>> It is also a very important architectural consideration to ensure >>> >> that >> >>> IP address assignment has some level of security. >>> >>> Asymmetric links in all "ad hoc" networks. Is it possible to partition >>> >> our problem statements so that this is just one of several optional >> attributes that must be addressed? >> >>> Most modern wireless MAC layers have reliable unicast. I can see some >>> >> broadcast only links - like satellite broadcast, but outside military >> applications I am not familiar with broadly deployed commercial wireless >> networking technologies that are based on asymmetric unicast transmissions. >> Perhaps someone on this list could point me to the technologies that they >> are considering for this requirement. >> >>> Regards, >>> >>> Paul >>> >>> >>> > > > > From budden@nps.edu Tue Feb 24 11:01:57 2009 Return-Path: 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 3CF693A6B3C for ; Tue, 24 Feb 2009 11:01:57 -0800 (PST) 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 wN3nHz6pqIiP for ; Tue, 24 Feb 2009 11:01:55 -0800 (PST) Received: from virginia.nps.edu (virginia.nps.edu [205.155.65.15]) by core3.amsl.com (Postfix) with ESMTP id CCD9F3A6A1C for ; Tue, 24 Feb 2009 11:01:55 -0800 (PST) Received: from localhost.localdomain ([172.20.57.107]) by virginia.nps.edu with Microsoft SMTPSVC(6.0.3790.3959); Tue, 24 Feb 2009 11:02:15 -0800 Message-ID: <49A44459.9020400@nps.navy.mil> Date: Tue, 24 Feb 2009 11:02:49 -0800 From: Rex Buddenberg User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: "Charles E. Perkins" References: <7BAC95F5A7E67643AAFB2C31BEE662D01489D135@SC-VEXCH2.marvell.com> <49A2E90E.10808@earthlink.net> <7BAC95F5A7E67643AAFB2C31BEE662D01489D24B@SC-VEXCH2.marvell.com> <49A431E9.3010401@earthlink.net> In-Reply-To: <49A431E9.3010401@earthlink.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Feb 2009 19:02:15.0176 (UTC) FILETIME=[681BB080:01C996B2] Cc: "autoconf@ietf.org" , Emmanuel Baccelli Subject: Re: [Autoconf] updated draft on aspects of multi-hop wireless communication X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 19:01:57 -0000 Charlie, Paul has a reality check point and its worthwhile understanding this because missing the point has made both MANET and autoconf harder than they need to be ... IMHO. It's also made them less relevant to what I think I see in the future. My background is analyzing information systems in DoD and emergency services ... why are they not interoperable (or, in the rare inverse instance, why are they interoperable)? In dealing with some DoD bureaucracy, I'm finding that they don't understand the implications of the differences between LANs and WANs. And by MANET stating that every end system is also a router, we equally obfuscate the point. Reality today. Our ships have wired LANs (mostly fast etherrnet and gigabit ethernet) within the hull. End systems (Paul's printers) attach to that LAN. And those end systems don't need more than one entry in the routing table and it's not likely to change. (The analog to your LAN at home is good). The problem that DoD has is not in the LAN; it's in the radio-WAN. Which is the link between the router in Radio Central and that in another ship and/or the commsta ashore. While there's lots of noise in the system, this is properly a pure radio-WAN problem -- entirely a router-router interconnect one. No end systems. This presents MAC and QoS control problems. What's important is that they are isolated from the end systems -- other side of the router. Reality ... not very far in the future. We have all the technology today to extend the internet to a fire truck. But do we want the WAN to reach to all the end systems on the fire truck? Perhaps in the near term, but this is not a long term good idea. What makes better sense is to plant a router on the fire truck and divide the problem into a radio-WAN (sometimes slangily known as 'reachback') and the LAN problem -- which might be solved by a WiFi splotch around the truck. Once you start thinking about reaching to firefighters inside a burning building, this makes more and more sense. And reality ... not much further in the future. Should such a pattern not fit into your automobile? Instead of the cellphone reach to your end system, it reaches to your car-resident router. And you have several end systems within the car that ... attach to a LAN. And reality, again not too far in the future. A Marine infantryman has several end systems, or at least potential end systems, as part of his combat outfit. Radionav receiver, PDA/laptop, rifle scope, night vision goggles (think webcam), laser rangefinder, VOIP rig. As soon as the list becomes plural, the idea of each end system being its own router (which implies it's own radio) ceases to make sense. The difficulty I repeatedly find in DoD programs (we're talking $B here) is that they try to use wireless-LAN technology in a radio-WAN situation. For example, we see satcom and air-ground specifications that persist in using contention access methods, when the Aloha experiment 40 years ago showed that was a lousy idea. The MAC problem is orthogonal to the routing problems, but somewhat of a prerequisite: if the net has crashed due congestion, then your routing tables are likely to be fiction. For Paul: is this anything related to your comments? Charles E. Perkins wrote: > > Hello Paul, > > Paul Lambert wrote: > >>> I am almost certain they >>> should be considered out of scope for the document >>> under discussion. >>> >> >> In looking at the reference in the charter for "ad hoc" (RFC 2501) >> the defined MANET is a Chimera - a mythical beast made of the parts >> of many other animals. It is a shame that smaller monsters are out of >> scope (like 802.11 ad hoc) ... >> > > I am thoroughly mystified by your reply. Just because certain > topics are out of scope for the small document by Emmanuel > and me, does not mean they are out of scope for [autoconf]. > Isn't it possible to have more than one document? Shouldn't we > collect requirements in a requirements document instead of every > other document that might be written? > > To be explicit, I am wholly in favor of making sure that > the results of [autoconf] are applicable to 802.11 ad hoc. > Did I say anything to imply otherwise? > > Regards, > Charlie P. > >> Paul >> >> >> >> >>> -----Original Message----- >>> From: Charles E. Perkins [mailto:charles.perkins@earthlink.net] >>> Sent: Monday, February 23, 2009 10:21 AM >>> To: Paul Lambert >>> Cc: Emmanuel Baccelli; autoconf@ietf.org >>> Subject: Re: [Autoconf] updated draft on aspects of multi-hop wireless >>> communication >>> >>> >>> Hello Paul, >>> >>> The document isn't intended to suggest a list of work >>> items for consideration by [autoconf]. Instead, it is just >>> a description of common properties of radio and other >>> wireless links. These properties are not quite universal, >>> but they are widespread. Some of them can be alleviated >>> a bit by mechanisms below the network protocol level. >>> >>> So we are not suggesting requirements or work items. >>> Instead, we simply wanted to make as clear as possible >>> some of the characteristics of the transmission media >>> whose widespread availability is motivating the work >>> of [autoconf]. >>> >>> Your list of issues would, I think, all fit best in a >>> requirements document. I am almost certain they >>> should be considered out of scope for the document >>> under discussion. >>> >>> Regards, >>> Charlie P. >>> >>> >>> Paul Lambert wrote: >>> >>>> Hi, >>>> >>>> The draft-baccelli-multi-hop-wireless-communication-01 provides an >>>> >>> interesting list of issues that might be addressed by this working >>> group. >>> >>>> >From a quick review it does not appear to address: >>>> - ad hoc network coalescing. Coalescing has clear implications for >>>> IP address assignment >>>> - there is no mention of multicast versus unicast issues. Perhaps >>>> since the document makes all links potentially asymmetric and >>>> unreliable there is no distinction. At least for 802.11 ad hoc >>>> I find significant implications. >>>> - it does not address link security establishment >>>> The process of setting up the link security is out of scope, but as >>>> I've mentioned in earlier emails this has a clear impact on >>>> available >>>> networking mechanisms. >>>> It is also a very important architectural consideration to ensure >>>> >>> that >>> >>>> IP address assignment has some level of security. >>>> >>>> Asymmetric links in all "ad hoc" networks. Is it possible to >>>> partition >>>> >>> our problem statements so that this is just one of several optional >>> attributes that must be addressed? >>> >>>> Most modern wireless MAC layers have reliable unicast. I can see some >>>> >>> broadcast only links - like satellite broadcast, but outside military >>> applications I am not familiar with broadly deployed commercial >>> wireless >>> networking technologies that are based on asymmetric unicast >>> transmissions. >>> Perhaps someone on this list could point me to the technologies that >>> they >>> are considering for this requirement. >>> >>>> Regards, >>>> >>>> Paul >>>> >>>> >>>> >> >> >> >> > > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf > -- Rex Buddenberg Senior Lecturer Naval Postgraduate School Monterey, Ca 93943 831/656-3576 From charles.perkins@earthlink.net Tue Feb 24 11:23:53 2009 Return-Path: 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 40FF73A6927 for ; Tue, 24 Feb 2009 11:23:53 -0800 (PST) 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 Kq2ITTSt1DU0 for ; Tue, 24 Feb 2009 11:23:51 -0800 (PST) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by core3.amsl.com (Postfix) with ESMTP id 854203A68A7 for ; Tue, 24 Feb 2009 11:23:51 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=Il44BqUbuLEDaPp5L370bwBVHBvi7RYYLWGng9U4td/dqN7j0KZ1KjDzgugHB71q; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [99.51.129.145] (helo=[10.166.254.33]) by elasmtp-banded.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1Lc2sy-0001VJ-Gb; Tue, 24 Feb 2009 14:24:08 -0500 Message-ID: <49A44958.4090300@earthlink.net> Date: Tue, 24 Feb 2009 11:24:08 -0800 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Rex Buddenberg References: <7BAC95F5A7E67643AAFB2C31BEE662D01489D135@SC-VEXCH2.marvell.com> <49A2E90E.10808@earthlink.net> <7BAC95F5A7E67643AAFB2C31BEE662D01489D24B@SC-VEXCH2.marvell.com> <49A431E9.3010401@earthlink.net> <49A44459.9020400@nps.navy.mil> In-Reply-To: <49A44459.9020400@nps.navy.mil> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f52aafc8abc0372a90077f0ec4ae36406bf350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.51.129.145 Cc: "autoconf@ietf.org" , Emmanuel Baccelli Subject: Re: [Autoconf] updated draft on aspects of multi-hop wireless communication X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 19:23:53 -0000 Hello Rex, Thanks for the long email. I think that I do have a good handle on the various kinds of mobile communications scenarios as you have outlined below. You have raised the particular point that many nodes in an ad hoc network do not have to be routers. I certainly agree with this, and agree that any work in [autoconf] needs to be able to configure addresses for wireless nodes in an ad hoc network that are not routers. Perhaps Emmanuel and I could better emphasize this point in our draft, but even non-router nodes can be subject to the problems noted in that draft. So we have to find better language to identify the wireless nodes that would be affected other than just calling them "routers". However, I still maintain that this document under discussion is _not_ a requirements document, and that Paul seems to be discussing various requirements for ad hoc networks. Don't you agree that requirements should be located in a separate document? The only "requirement" that we have placed in our small document is a need to deal with reality. I'd also like to point out one somewhat unrelated point. It is agreed, of course, that MAC-layer problems can pre-empt the usefulness of routing protocols. However, routing protocols can themselves cause congestion, and any techniques that we can bring to bear that reduce congestion are likely to increase the overall effectiveness of the MAC layer protocols also. Furthermore, I think it is likely that people who do not have good understanding about the nature of the wireless medium are more likely to make design decisions for routing protocols that would increase congestion. What do you think? Regards, Charlie P. Rex Buddenberg wrote: > Charlie, > > Paul has a reality check point and its worthwhile understanding this > because missing the point has made both MANET and autoconf harder than > they need to be ... IMHO. It's also made them less relevant to what I > think I see in the future. > My background is analyzing information systems in DoD and emergency > services ... why are they not interoperable (or, in the rare inverse > instance, why are they interoperable)? > > In dealing with some DoD bureaucracy, I'm finding that they don't > understand the implications of the differences between LANs and > WANs. And by MANET stating that every end system is also a router, > we equally obfuscate the point. > > Reality today. Our ships have wired LANs (mostly fast etherrnet and > gigabit ethernet) within the hull. End systems (Paul's printers) > attach to that LAN. And those end systems don't need more than one > entry in the routing table and it's not likely to change. (The analog > to your LAN at home is good). > The problem that DoD has is not in the LAN; it's in the radio-WAN. > Which is the link between the router in Radio Central and that in > another ship and/or the commsta ashore. While there's lots of noise > in the system, this is properly a pure radio-WAN problem -- entirely a > router-router interconnect one. No end systems. This presents MAC > and QoS control problems. What's important is that they are isolated > from the end systems -- other side of the router. > > Reality ... not very far in the future. We have all the technology > today to extend the internet to a fire truck. But do we want the WAN > to reach to all the end systems on the fire truck? Perhaps in the > near term, but this is not a long term good idea. What makes better > sense is to plant a router on the fire truck and divide the problem > into a radio-WAN (sometimes slangily known as 'reachback') and the LAN > problem -- which might be solved by a WiFi splotch around the truck. > Once you start thinking about reaching to firefighters inside a > burning building, this makes more and more sense. And reality ... > not much further in the future. Should such a pattern not fit into > your automobile? Instead of the cellphone reach to your end system, > it reaches to your car-resident router. And you have several end > systems within the car that ... attach to a LAN. > And reality, again not too far in the future. A Marine infantryman > has several end systems, or at least potential end systems, as part of > his combat outfit. Radionav receiver, PDA/laptop, rifle scope, night > vision goggles (think webcam), laser rangefinder, VOIP rig. As soon > as the list becomes plural, the idea of each end system being its own > router (which implies it's own radio) ceases to make sense. > > The difficulty I repeatedly find in DoD programs (we're talking $B > here) is that they try to use wireless-LAN technology in a radio-WAN > situation. For example, we see satcom and air-ground specifications > that persist in using contention access methods, when the Aloha > experiment 40 years ago showed that was a lousy idea. The MAC problem > is orthogonal to the routing problems, but somewhat of a prerequisite: > if the net has crashed due congestion, then your routing tables are > likely to be fiction. > > For Paul: is this anything related to your comments? > > > > > Charles E. Perkins wrote: >> >> Hello Paul, >> >> Paul Lambert wrote: >> >>>> I am almost certain they >>>> should be considered out of scope for the document >>>> under discussion. >>>> >>> >>> In looking at the reference in the charter for "ad hoc" (RFC 2501) >>> the defined MANET is a Chimera - a mythical beast made of the parts >>> of many other animals. It is a shame that smaller monsters are out >>> of scope (like 802.11 ad hoc) ... >>> >> >> I am thoroughly mystified by your reply. Just because certain >> topics are out of scope for the small document by Emmanuel >> and me, does not mean they are out of scope for [autoconf]. >> Isn't it possible to have more than one document? Shouldn't we >> collect requirements in a requirements document instead of every >> other document that might be written? >> >> To be explicit, I am wholly in favor of making sure that >> the results of [autoconf] are applicable to 802.11 ad hoc. >> Did I say anything to imply otherwise? >> >> Regards, >> Charlie P. >> >>> Paul >>> >>> >>> >>> >>>> -----Original Message----- >>>> From: Charles E. Perkins [mailto:charles.perkins@earthlink.net] >>>> Sent: Monday, February 23, 2009 10:21 AM >>>> To: Paul Lambert >>>> Cc: Emmanuel Baccelli; autoconf@ietf.org >>>> Subject: Re: [Autoconf] updated draft on aspects of multi-hop wireless >>>> communication >>>> >>>> >>>> Hello Paul, >>>> >>>> The document isn't intended to suggest a list of work >>>> items for consideration by [autoconf]. Instead, it is just >>>> a description of common properties of radio and other >>>> wireless links. These properties are not quite universal, >>>> but they are widespread. Some of them can be alleviated >>>> a bit by mechanisms below the network protocol level. >>>> >>>> So we are not suggesting requirements or work items. >>>> Instead, we simply wanted to make as clear as possible >>>> some of the characteristics of the transmission media >>>> whose widespread availability is motivating the work >>>> of [autoconf]. >>>> >>>> Your list of issues would, I think, all fit best in a >>>> requirements document. I am almost certain they >>>> should be considered out of scope for the document >>>> under discussion. >>>> >>>> Regards, >>>> Charlie P. >>>> >>>> >>>> Paul Lambert wrote: >>>> >>>>> Hi, >>>>> >>>>> The draft-baccelli-multi-hop-wireless-communication-01 provides an >>>>> >>>> interesting list of issues that might be addressed by this working >>>> group. >>>> >>>>> >From a quick review it does not appear to address: >>>>> - ad hoc network coalescing. Coalescing has clear implications for >>>>> IP address assignment >>>>> - there is no mention of multicast versus unicast issues. Perhaps >>>>> since the document makes all links potentially asymmetric and >>>>> unreliable there is no distinction. At least for 802.11 ad hoc >>>>> I find significant implications. >>>>> - it does not address link security establishment >>>>> The process of setting up the link security is out of scope, >>>>> but as >>>>> I've mentioned in earlier emails this has a clear impact on >>>>> available >>>>> networking mechanisms. >>>>> It is also a very important architectural consideration to ensure >>>>> >>>> that >>>> >>>>> IP address assignment has some level of security. >>>>> >>>>> Asymmetric links in all "ad hoc" networks. Is it possible to >>>>> partition >>>>> >>>> our problem statements so that this is just one of several optional >>>> attributes that must be addressed? >>>> >>>>> Most modern wireless MAC layers have reliable unicast. I can see >>>>> some >>>>> >>>> broadcast only links - like satellite broadcast, but outside military >>>> applications I am not familiar with broadly deployed commercial >>>> wireless >>>> networking technologies that are based on asymmetric unicast >>>> transmissions. >>>> Perhaps someone on this list could point me to the technologies >>>> that they >>>> are considering for this requirement. >>>> >>>>> Regards, >>>>> >>>>> Paul >>>>> >>>>> >>>>> >>> >>> >>> >>> >> >> _______________________________________________ >> Autoconf mailing list >> Autoconf@ietf.org >> https://www.ietf.org/mailman/listinfo/autoconf >> > From budden@nps.edu Tue Feb 24 13:30:38 2009 Return-Path: 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 051563A6874 for ; Tue, 24 Feb 2009 13:30:38 -0800 (PST) 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 79eytshDKc1f for ; Tue, 24 Feb 2009 13:30:36 -0800 (PST) Received: from virginia.nps.edu (virginia.nps.edu [205.155.65.15]) by core3.amsl.com (Postfix) with ESMTP id 88D3A3A66B4 for ; Tue, 24 Feb 2009 13:30:36 -0800 (PST) Received: from localhost.localdomain ([172.20.57.107]) by virginia.nps.edu with Microsoft SMTPSVC(6.0.3790.3959); Tue, 24 Feb 2009 13:30:55 -0800 Message-ID: <49A46732.1050706@nps.navy.mil> Date: Tue, 24 Feb 2009 13:31:30 -0800 From: Rex Buddenberg User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: "Charles E. Perkins" References: <7BAC95F5A7E67643AAFB2C31BEE662D01489D135@SC-VEXCH2.marvell.com> <49A2E90E.10808@earthlink.net> <7BAC95F5A7E67643AAFB2C31BEE662D01489D24B@SC-VEXCH2.marvell.com> <49A431E9.3010401@earthlink.net> <49A44459.9020400@nps.navy.mil> <49A44958.4090300@earthlink.net> In-Reply-To: <49A44958.4090300@earthlink.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Feb 2009 21:30:55.0959 (UTC) FILETIME=[2D4F2670:01C996C7] Cc: "autoconf@ietf.org" , Emmanuel Baccelli Subject: Re: [Autoconf] updated draft on aspects of multi-hop wireless communication X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 21:30:38 -0000 Charlie, Thanks for note back ... this might be progress. I was afraid that you might mash the 'irrelevant' button. "However, I still maintain that this document under discussion is _not_ a requirements document..." I'm genuinely confused regarding just what the order of business needs to be and what the document artifacts that result from that should be. I've also been a much more intimate witness on how NOT to do such things within DoD than I ever wanted to be. Are there, perhaps, some parallels? How to get it backwards: 1. Shout 'the acquisition system is broken'. This bloviating is good every four years. So we apply some bandaids to the bureaucracy. 2. Muse that we need an architecture. But we lack a useful definition of the term, so any answer is 'right' and the ones enshrined in the system have nothing to do with interoperability, modularity or interchangeable parts. 3. At this point, the exercise usually peters out, but if it doesn't, we have a requirements flailex. Which tends to look a lot like a Dilbert cartoon. 4. And nobody seems to get to an observed taxonomy of interoperability. Which is what the scenarios of the previous e-mail were hinting at. (taxonomy, reference model, sorting model, Linnaeus) Aside from the steps (e.g. #4) that are missing altogether, this is exactly the reverse order of business! We can, and should, build the reference model without reference to requirements. Is that were we are agreeing or disagreeing? Or even on the same page? Charles E. Perkins wrote: > > Hello Rex, > > Thanks for the long email. I think that I do have a good handle on > the various > kinds of mobile communications scenarios as you have outlined below. > > You have raised the particular point that many nodes in an ad hoc network > do not have to be routers. I certainly agree with this, and agree > that any work > in [autoconf] needs to be able to configure addresses for wireless > nodes in > an ad hoc network that are not routers. Perhaps Emmanuel and I could > better > emphasize this point in our draft, but even non-router nodes can be > subject to > the problems noted in that draft. So we have to find better language to > identify the wireless nodes that would be affected other than just > calling > them "routers". > > However, I still maintain that this document under discussion is _not_ a > requirements document, and that Paul seems to be discussing various > requirements for ad hoc networks. Don't you agree that requirements > should be located in a separate document? The only "requirement" that > we have placed in our small document is a need to deal with reality. > > I'd also like to point out one somewhat unrelated point. It is > agreed, of > course, that MAC-layer problems can pre-empt the usefulness of > routing protocols. However, routing protocols can themselves cause > congestion, and any techniques that we can bring to bear that reduce > congestion are likely to increase the overall effectiveness of the MAC > layer protocols also. Furthermore, I think it is likely that people who > do not have good understanding about the nature of the wireless > medium are more likely to make design decisions for routing protocols > that would increase congestion. > > What do you think? > > Regards, > Charlie P. > > > Rex Buddenberg wrote: >> Charlie, >> >> Paul has a reality check point and its worthwhile understanding this >> because missing the point has made both MANET and autoconf harder >> than they need to be ... IMHO. It's also made them less relevant to >> what I think I see in the future. >> My background is analyzing information systems in DoD and emergency >> services ... why are they not interoperable (or, in the rare inverse >> instance, why are they interoperable)? >> >> In dealing with some DoD bureaucracy, I'm finding that they don't >> understand the implications of the differences between LANs and >> WANs. And by MANET stating that every end system is also a router, >> we equally obfuscate the point. >> >> Reality today. Our ships have wired LANs (mostly fast etherrnet and >> gigabit ethernet) within the hull. End systems (Paul's printers) >> attach to that LAN. And those end systems don't need more than one >> entry in the routing table and it's not likely to change. (The >> analog to your LAN at home is good). >> The problem that DoD has is not in the LAN; it's in the radio-WAN. >> Which is the link between the router in Radio Central and that in >> another ship and/or the commsta ashore. While there's lots of noise >> in the system, this is properly a pure radio-WAN problem -- entirely >> a router-router interconnect one. No end systems. This presents MAC >> and QoS control problems. What's important is that they are isolated >> from the end systems -- other side of the router. >> >> Reality ... not very far in the future. We have all the technology >> today to extend the internet to a fire truck. But do we want the WAN >> to reach to all the end systems on the fire truck? Perhaps in the >> near term, but this is not a long term good idea. What makes better >> sense is to plant a router on the fire truck and divide the problem >> into a radio-WAN (sometimes slangily known as 'reachback') and the >> LAN problem -- which might be solved by a WiFi splotch around the >> truck. Once you start thinking about reaching to firefighters inside >> a burning building, this makes more and more sense. And reality >> ... not much further in the future. Should such a pattern not fit >> into your automobile? Instead of the cellphone reach to your end >> system, it reaches to your car-resident router. And you have several >> end systems within the car that ... attach to a LAN. >> And reality, again not too far in the future. A Marine >> infantryman has several end systems, or at least potential end >> systems, as part of his combat outfit. Radionav receiver, >> PDA/laptop, rifle scope, night vision goggles (think webcam), laser >> rangefinder, VOIP rig. As soon as the list becomes plural, the idea >> of each end system being its own router (which implies it's own >> radio) ceases to make sense. >> >> The difficulty I repeatedly find in DoD programs (we're talking $B >> here) is that they try to use wireless-LAN technology in a radio-WAN >> situation. For example, we see satcom and air-ground specifications >> that persist in using contention access methods, when the Aloha >> experiment 40 years ago showed that was a lousy idea. The MAC >> problem is orthogonal to the routing problems, but somewhat of a >> prerequisite: if the net has crashed due congestion, then your >> routing tables are likely to be fiction. >> >> For Paul: is this anything related to your comments? >> >> >> >> >> Charles E. Perkins wrote: >>> >>> Hello Paul, >>> >>> Paul Lambert wrote: >>> >>>>> I am almost certain they >>>>> should be considered out of scope for the document >>>>> under discussion. >>>>> >>>> >>>> In looking at the reference in the charter for "ad hoc" (RFC 2501) >>>> the defined MANET is a Chimera - a mythical beast made of the parts >>>> of many other animals. It is a shame that smaller monsters are out >>>> of scope (like 802.11 ad hoc) ... >>>> >>> >>> I am thoroughly mystified by your reply. Just because certain >>> topics are out of scope for the small document by Emmanuel >>> and me, does not mean they are out of scope for [autoconf]. >>> Isn't it possible to have more than one document? Shouldn't we >>> collect requirements in a requirements document instead of every >>> other document that might be written? >>> >>> To be explicit, I am wholly in favor of making sure that >>> the results of [autoconf] are applicable to 802.11 ad hoc. >>> Did I say anything to imply otherwise? >>> >>> Regards, >>> Charlie P. >>> >>>> Paul >>>> >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: Charles E. Perkins [mailto:charles.perkins@earthlink.net] >>>>> Sent: Monday, February 23, 2009 10:21 AM >>>>> To: Paul Lambert >>>>> Cc: Emmanuel Baccelli; autoconf@ietf.org >>>>> Subject: Re: [Autoconf] updated draft on aspects of multi-hop >>>>> wireless >>>>> communication >>>>> >>>>> >>>>> Hello Paul, >>>>> >>>>> The document isn't intended to suggest a list of work >>>>> items for consideration by [autoconf]. Instead, it is just >>>>> a description of common properties of radio and other >>>>> wireless links. These properties are not quite universal, >>>>> but they are widespread. Some of them can be alleviated >>>>> a bit by mechanisms below the network protocol level. >>>>> >>>>> So we are not suggesting requirements or work items. >>>>> Instead, we simply wanted to make as clear as possible >>>>> some of the characteristics of the transmission media >>>>> whose widespread availability is motivating the work >>>>> of [autoconf]. >>>>> >>>>> Your list of issues would, I think, all fit best in a >>>>> requirements document. I am almost certain they >>>>> should be considered out of scope for the document >>>>> under discussion. >>>>> >>>>> Regards, >>>>> Charlie P. >>>>> >>>>> >>>>> Paul Lambert wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> The draft-baccelli-multi-hop-wireless-communication-01 provides an >>>>>> >>>>> interesting list of issues that might be addressed by this working >>>>> group. >>>>> >>>>>> >From a quick review it does not appear to address: >>>>>> - ad hoc network coalescing. Coalescing has clear implications for >>>>>> IP address assignment >>>>>> - there is no mention of multicast versus unicast issues. Perhaps >>>>>> since the document makes all links potentially asymmetric and >>>>>> unreliable there is no distinction. At least for 802.11 ad hoc >>>>>> I find significant implications. >>>>>> - it does not address link security establishment >>>>>> The process of setting up the link security is out of scope, >>>>>> but as >>>>>> I've mentioned in earlier emails this has a clear impact on >>>>>> available >>>>>> networking mechanisms. >>>>>> It is also a very important architectural consideration to ensure >>>>>> >>>>> that >>>>> >>>>>> IP address assignment has some level of security. >>>>>> >>>>>> Asymmetric links in all "ad hoc" networks. Is it possible to >>>>>> partition >>>>>> >>>>> our problem statements so that this is just one of several optional >>>>> attributes that must be addressed? >>>>> >>>>>> Most modern wireless MAC layers have reliable unicast. I can see >>>>>> some >>>>>> >>>>> broadcast only links - like satellite broadcast, but outside military >>>>> applications I am not familiar with broadly deployed commercial >>>>> wireless >>>>> networking technologies that are based on asymmetric unicast >>>>> transmissions. >>>>> Perhaps someone on this list could point me to the technologies >>>>> that they >>>>> are considering for this requirement. >>>>> >>>>>> Regards, >>>>>> >>>>>> Paul >>>>>> >>>>>> >>>>>> >>>> >>>> >>>> >>>> >>> >>> _______________________________________________ >>> Autoconf mailing list >>> Autoconf@ietf.org >>> https://www.ietf.org/mailman/listinfo/autoconf >>> >> > > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf > -- Rex Buddenberg Senior Lecturer Naval Postgraduate School Monterey, Ca 93943 831/656-3576 From ietf@thomasclausen.org Tue Feb 24 14:04:01 2009 Return-Path: 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 6E93628C131 for ; Tue, 24 Feb 2009 14:04:01 -0800 (PST) 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 VwGjd57-x+9e for ; Tue, 24 Feb 2009 14:04:00 -0800 (PST) Received: from mho-02-bos.mailhop.org (mho-02-bos.mailhop.org [63.208.196.179]) by core3.amsl.com (Postfix) with ESMTP id 7B48B28C129 for ; Tue, 24 Feb 2009 14:04:00 -0800 (PST) Received: from aste-genev-bois-153-1-76-71.w86-203.abo.wanadoo.fr ([86.203.162.71] helo=[192.168.147.109]) by mho-02-bos.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1Lc5Nz-0004QL-6a; Tue, 24 Feb 2009 22:04:19 +0000 X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 86.203.162.71 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX192EZqFSntXEDSVsoqFFCnZ In-Reply-To: <49A44459.9020400@nps.navy.mil> References: <7BAC95F5A7E67643AAFB2C31BEE662D01489D135@SC-VEXCH2.marvell.com> <49A2E90E.10808@earthlink.net> <7BAC95F5A7E67643AAFB2C31BEE662D01489D24B@SC-VEXCH2.marvell.com> <49A431E9.3010401@earthlink.net> <49A44459.9020400@nps.navy.mil> Mime-Version: 1.0 (Apple Message framework v753.1) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Thomas Heide Clausen Date: Tue, 24 Feb 2009 23:06:03 +0100 To: Rex Buddenberg X-Mailer: Apple Mail (2.753.1) Cc: "autoconf@ietf.org" , Emmanuel Baccelli Subject: Re: [Autoconf] updated draft on aspects of multi-hop wireless communication X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 22:04:01 -0000 On Feb 24, 2009, at 20:02 PM, Rex Buddenberg wrote: > Charlie, > > Paul has a reality check point and its worthwhile understanding > this because missing the point has made both MANET and autoconf > harder than they need to be ... IMHO. It's also made them less > relevant to what I think I see in the future. > My background is analyzing information systems in DoD and emergency > services ... why are they not interoperable (or, in the rare > inverse instance, why are they interoperable)? > > In dealing with some DoD bureaucracy, I'm finding that they don't > understand the implications of the differences between LANs and > WANs. And by MANET stating that every end system is also a > router, we equally obfuscate the point. > I think there's a fundamental misunderstanding here. I'll try to clarify it, if I can... In an OSPF-routed network, for all that OSPF cares about, every "system is [an OSPF] router". That doesn't preclude that an OSPF router may have interfaces towards other entities, called hosts -- but as such hosts do not take part in routing (and in the routing protocol), they're just not relevant when talking about OSPF. In a MANET-routed network, all systems that the MANET routing protocols care about are.....MANET routers. That doesn't preclude that a MANET router may have interfaces towards other entities, called hosts -- but as such hosts do not take part in routing (and in the routing protocol), they're just not relevant when talking about MANETs. In other words.....it's perfectly fine to hang an Ethernet hub or an 802.11 access point or whatnot off of a MANET router, assign a prefix to that link, hang hosts on that link -- and use the MANET routing protocols to exchange that prefix such that these hosts are routable/ reachable. It's not just perfectly fine, that's what MANET routing protocols are build to do ;) I'd actually make the exact opposite point of the one you're making, Rex: every end system is a host -- intermediate systems running MANET protocols are routers. Hosts are unaware of if they're hanging off a MANET, OSPF, ISIS or other router -- they just see a classic IP link and an IP hop and likely a default route. The MANET, OSPF, ISIS or other router deals with the "routing stuff", including characteristics of links to other routers. Hosts never see that. This is as it should be. Occasionally, a system in a MANET may in the same physical box have a logical router and a host present. This isn't that unusual either for non-MANET networks. So when we talk about systems being routers in MANETs, then it's simply because the systems that "we care about" are the routers. Hosts are hanging off (some of) these routers just fine, over classic IP links -- over which the usual slew of protocols works just fine (fortunately -- so we do not have to care about that ;) ). What MANETs are concerned with are MANET routers and their interconnect to other MANET routers. Interconnect from MANET routers to hosts is no different from interconnect from a host to, say, an OSPF router. Does this help? Thomas From teco@inf-net.nl Tue Feb 24 23:11:44 2009 Return-Path: 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 4BFF93A6B55 for ; Tue, 24 Feb 2009 23:11:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] 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 jmZMI8XtViQT for ; Tue, 24 Feb 2009 23:11:43 -0800 (PST) Received: from cpsmtpo-eml03.kpnxchange.com (cpsmtpo-eml03.KPNXCHANGE.COM [213.75.38.152]) by core3.amsl.com (Postfix) with ESMTP id EEB573A6B51 for ; Tue, 24 Feb 2009 23:11:42 -0800 (PST) Received: from cpsmtp-eml110.kpnxchange.com ([10.94.168.110]) by cpsmtpo-eml03.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Feb 2009 08:12:02 +0100 Received: from M90Teco ([86.83.9.22]) by cpsmtp-eml110.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Feb 2009 08:12:01 +0100 From: "Teco Boot" To: "'Thomas Heide Clausen'" , "'Rex Buddenberg'" References: <7BAC95F5A7E67643AAFB2C31BEE662D01489D135@SC-VEXCH2.marvell.com> <49A2E90E.10808@earthlink.net> <7BAC95F5A7E67643AAFB2C31BEE662D01489D24B@SC-VEXCH2.marvell.com> <49A431E9.3010401@earthlink.net> <49A44459.9020400@nps.navy.mil> In-Reply-To: Date: Wed, 25 Feb 2009 08:11:56 +0100 Message-ID: <002901c99718$57cf1c10$076d5430$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcmWy9v7qfeCb60fR1SyEj4AF/0MXgAS8yIw Content-Language: nl X-OriginalArrivalTime: 25 Feb 2009 07:12:01.0140 (UTC) FILETIME=[5A939340:01C99718] Cc: autoconf@ietf.org, 'Emmanuel Baccelli' Subject: Re: [Autoconf] updated draft on aspects of multi-hop wireless communication X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2009 07:11:44 -0000 Minor comment: I would compare an OLSR Router with an OSPF Router with an DYMO Router and with an RIP Router, just to come up with a few protocols. I would not compare an OSPF Router with an MANET Router, this doesn't make sense, an OSPF Router could be a MANET Router. I think MANET is a term for a category of routing protocols, similar to link state protocols (but an orthogonal category). Teco. |-----Oorspronkelijk bericht----- |Van: autoconf-bounces@ietf.org [mailto:autoconf-bounces@ietf.org] Namens |Thomas Heide Clausen |Verzonden: dinsdag 24 februari 2009 23:06 |Aan: Rex Buddenberg |CC: autoconf@ietf.org; Emmanuel Baccelli |Onderwerp: Re: [Autoconf] updated draft on aspects of multi-hop wireless |communication | | |On Feb 24, 2009, at 20:02 PM, Rex Buddenberg wrote: | |> Charlie, |> |> Paul has a reality check point and its worthwhile understanding |> this because missing the point has made both MANET and autoconf |> harder than they need to be ... IMHO. It's also made them less |> relevant to what I think I see in the future. |> My background is analyzing information systems in DoD and emergency |> services ... why are they not interoperable (or, in the rare |> inverse instance, why are they interoperable)? |> |> In dealing with some DoD bureaucracy, I'm finding that they don't |> understand the implications of the differences between LANs and |> WANs. And by MANET stating that every end system is also a |> router, we equally obfuscate the point. |> | | | |I think there's a fundamental misunderstanding here. I'll try to |clarify it, if I can... | |In an OSPF-routed network, for all that OSPF cares about, every |"system is [an OSPF] router". That doesn't preclude that an OSPF |router may have interfaces towards other entities, called hosts -- |but as such hosts do not take part in routing (and in the routing |protocol), they're just not relevant when talking about OSPF. | |In a MANET-routed network, all systems that the MANET routing |protocols care about are.....MANET routers. That doesn't preclude |that a MANET router may have interfaces towards other entities, |called hosts -- but as such hosts do not take part in routing (and in |the routing protocol), they're just not relevant when talking about |MANETs. | |In other words.....it's perfectly fine to hang an Ethernet hub or an |802.11 access point or whatnot off of a MANET router, assign a prefix |to that link, hang hosts on that link -- and use the MANET routing |protocols to exchange that prefix such that these hosts are routable/ |reachable. It's not just perfectly fine, that's what MANET routing |protocols are build to do ;) | |I'd actually make the exact opposite point of the one you're making, |Rex: every end system is a host -- intermediate systems running MANET |protocols are routers. Hosts are unaware of if they're hanging off a |MANET, OSPF, ISIS or other router -- they just see a classic IP link |and an IP hop and likely a default route. The MANET, OSPF, ISIS or |other router deals with the "routing stuff", including |characteristics of links to other routers. Hosts never see that. This |is as it should be. | |Occasionally, a system in a MANET may in the same physical box have a |logical router and a host present. This isn't that unusual either |for non-MANET networks. | |So when we talk about systems being routers in MANETs, then it's |simply because the systems that "we care about" are the routers. |Hosts are hanging off (some of) these routers just fine, over classic |IP links -- over which the usual slew of protocols works just fine |(fortunately -- so we do not have to care about that ;) ). | |What MANETs are concerned with are MANET routers and their |interconnect to other MANET routers. Interconnect from MANET routers |to hosts is no different from interconnect from a host to, say, an |OSPF router. | |Does this help? | |Thomas | |_______________________________________________ |Autoconf mailing list |Autoconf@ietf.org |https://www.ietf.org/mailman/listinfo/autoconf From teco@inf-net.nl Tue Feb 24 23:24:38 2009 Return-Path: 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 554A23A686C for ; Tue, 24 Feb 2009 23:24:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.896 X-Spam-Level: X-Spam-Status: No, score=-0.896 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, MANGLED_PILL=2.3] 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 NF1haUXZMmpo for ; Tue, 24 Feb 2009 23:24:37 -0800 (PST) Received: from cpsmtpo-eml05.kpnxchange.com (cpsmtpo-eml05.KPNXCHANGE.COM [213.75.38.154]) by core3.amsl.com (Postfix) with ESMTP id 89BEC28C14F for ; Tue, 24 Feb 2009 23:24:36 -0800 (PST) Received: from cpsmtp-eml102.kpnxchange.com ([213.75.84.102]) by cpsmtpo-eml05.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Feb 2009 08:24:55 +0100 Received: from M90Teco ([86.83.9.22]) by cpsmtp-eml102.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Feb 2009 08:24:55 +0100 From: "Teco Boot" To: "'Rex Buddenberg'" , "'Charles E. Perkins'" References: <7BAC95F5A7E67643AAFB2C31BEE662D01489D135@SC-VEXCH2.marvell.com> <49A2E90E.10808@earthlink.net> <7BAC95F5A7E67643AAFB2C31BEE662D01489D24B@SC-VEXCH2.marvell.com> <49A431E9.3010401@earthlink.net> <49A44459.9020400@nps.navy.mil> In-Reply-To: <49A44459.9020400@nps.navy.mil> Date: Wed, 25 Feb 2009 08:24:50 +0100 Message-ID: <002a01c9971a$25207dc0$6f617940$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcmWsmzFvZeeoBvoQHWPE3t/sIj39AAZn44A Content-Language: nl X-OriginalArrivalTime: 25 Feb 2009 07:24:55.0595 (UTC) FILETIME=[283007B0:01C9971A] Cc: autoconf@ietf.org, 'Emmanuel Baccelli' Subject: Re: [Autoconf] updated draft on aspects of multi-hop wireless communication X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2009 07:24:38 -0000 Minor comment on "Aloha experiment being a lousy idea": let's not forget that this idea is used quite often. Think of old days Ethernet, WLAN and signaling channel in cellular networks, just to come up with a few examples. More important: I think we should focus on the IP layer, and stay away from media access technology and related problems. Not that is not interesting or important, it is not the focus of IETF in general to work on layer-2 stuff. Teco. |-----Oorspronkelijk bericht----- |Van: autoconf-bounces@ietf.org [mailto:autoconf-bounces@ietf.org] Namens |Rex Buddenberg |Verzonden: dinsdag 24 februari 2009 20:03 |Aan: Charles E. Perkins |CC: autoconf@ietf.org; Emmanuel Baccelli |Onderwerp: Re: [Autoconf] updated draft on aspects of multi-hop wireless |communication | |Charlie, | |Paul has a reality check point and its worthwhile understanding this |because missing the point has made both MANET and autoconf harder than |they need to be ... IMHO. It's also made them less relevant to what I |think I see in the future. | |My background is analyzing information systems in DoD and emergency |services ... why are they not interoperable (or, in the rare inverse |instance, why are they interoperable)? | |In dealing with some DoD bureaucracy, I'm finding that they don't |understand the implications of the differences between LANs and WANs. |And by MANET stating that every end system is also a router, we equally |obfuscate the point. | |Reality today. Our ships have wired LANs (mostly fast etherrnet and |gigabit ethernet) within the hull. End systems (Paul's printers) attach |to that LAN. And those end systems don't need more than one entry in |the routing table and it's not likely to change. (The analog to your |LAN at home is good). | |The problem that DoD has is not in the LAN; it's in the radio-WAN. |Which is the link between the router in Radio Central and that in |another ship and/or the commsta ashore. While there's lots of noise in |the system, this is properly a pure radio-WAN problem -- entirely a |router-router interconnect one. No end systems. This presents MAC and |QoS control problems. What's important is that they are isolated from |the end systems -- other side of the router. | |Reality ... not very far in the future. We have all the technology |today to extend the internet to a fire truck. But do we want the WAN to |reach to all the end systems on the fire truck? Perhaps in the near |term, but this is not a long term good idea. What makes better sense is |to plant a router on the fire truck and divide the problem into a |radio-WAN (sometimes slangily known as 'reachback') and the LAN problem |-- which might be solved by a WiFi splotch around the truck. Once you |start thinking about reaching to firefighters inside a burning building, |this makes more and more sense. | And reality ... not much further in the future. Should such a |pattern not fit into your automobile? Instead of the cellphone reach to |your end system, it reaches to your car-resident router. And you have |several end systems within the car that ... attach to a LAN. | And reality, again not too far in the future. A Marine infantryman |has several end systems, or at least potential end systems, as part of |his combat outfit. Radionav receiver, PDA/laptop, rifle scope, night |vision goggles (think webcam), laser rangefinder, VOIP rig. As soon as |the list becomes plural, the idea of each end system being its own |router (which implies it's own radio) ceases to make sense. | | |The difficulty I repeatedly find in DoD programs (we're talking $B here) |is that they try to use wireless-LAN technology in a radio-WAN |situation. For example, we see satcom and air-ground specifications |that persist in using contention access methods, when the Aloha |experiment 40 years ago showed that was a lousy idea. The MAC problem |is orthogonal to the routing problems, but somewhat of a prerequisite: |if the net has crashed due congestion, then your routing tables are |likely to be fiction. | | |For Paul: is this anything related to your comments? | | | | |Charles E. Perkins wrote: |> |> Hello Paul, |> |> Paul Lambert wrote: |> |>>> I am almost certain they |>>> should be considered out of scope for the document |>>> under discussion. |>>> |>> |>> In looking at the reference in the charter for "ad hoc" (RFC 2501) |>> the defined MANET is a Chimera - a mythical beast made of the parts |>> of many other animals. It is a shame that smaller monsters are out of |>> scope (like 802.11 ad hoc) ... |>> |> |> I am thoroughly mystified by your reply. Just because certain |> topics are out of scope for the small document by Emmanuel |> and me, does not mean they are out of scope for [autoconf]. |> Isn't it possible to have more than one document? Shouldn't we |> collect requirements in a requirements document instead of every |> other document that might be written? |> |> To be explicit, I am wholly in favor of making sure that |> the results of [autoconf] are applicable to 802.11 ad hoc. |> Did I say anything to imply otherwise? |> |> Regards, |> Charlie P. |> |>> Paul |>> |>> |>> |>> |>>> -----Original Message----- |>>> From: Charles E. Perkins [mailto:charles.perkins@earthlink.net] |>>> Sent: Monday, February 23, 2009 10:21 AM |>>> To: Paul Lambert |>>> Cc: Emmanuel Baccelli; autoconf@ietf.org |>>> Subject: Re: [Autoconf] updated draft on aspects of multi-hop |wireless |>>> communication |>>> |>>> |>>> Hello Paul, |>>> |>>> The document isn't intended to suggest a list of work |>>> items for consideration by [autoconf]. Instead, it is just |>>> a description of common properties of radio and other |>>> wireless links. These properties are not quite universal, |>>> but they are widespread. Some of them can be alleviated |>>> a bit by mechanisms below the network protocol level. |>>> |>>> So we are not suggesting requirements or work items. |>>> Instead, we simply wanted to make as clear as possible |>>> some of the characteristics of the transmission media |>>> whose widespread availability is motivating the work |>>> of [autoconf]. |>>> |>>> Your list of issues would, I think, all fit best in a |>>> requirements document. I am almost certain they |>>> should be considered out of scope for the document |>>> under discussion. |>>> |>>> Regards, |>>> Charlie P. |>>> |>>> |>>> Paul Lambert wrote: |>>> |>>>> Hi, |>>>> |>>>> The draft-baccelli-multi-hop-wireless-communication-01 provides an |>>>> |>>> interesting list of issues that might be addressed by this working |>>> group. |>>> |>>>> >From a quick review it does not appear to address: |>>>> - ad hoc network coalescing. Coalescing has clear implications |for |>>>> IP address assignment |>>>> - there is no mention of multicast versus unicast issues. Perhaps |>>>> since the document makes all links potentially asymmetric and |>>>> unreliable there is no distinction. At least for 802.11 ad hoc |>>>> I find significant implications. |>>>> - it does not address link security establishment |>>>> The process of setting up the link security is out of scope, but |as |>>>> I've mentioned in earlier emails this has a clear impact on |>>>> available |>>>> networking mechanisms. |>>>> It is also a very important architectural consideration to |ensure |>>>> |>>> that |>>> |>>>> IP address assignment has some level of security. |>>>> |>>>> Asymmetric links in all "ad hoc" networks. Is it possible to |>>>> partition |>>>> |>>> our problem statements so that this is just one of several optional |>>> attributes that must be addressed? |>>> |>>>> Most modern wireless MAC layers have reliable unicast. I can see |some |>>>> |>>> broadcast only links - like satellite broadcast, but outside |military |>>> applications I am not familiar with broadly deployed commercial |>>> wireless |>>> networking technologies that are based on asymmetric unicast |>>> transmissions. |>>> Perhaps someone on this list could point me to the technologies that |>>> they |>>> are considering for this requirement. |>>> |>>>> Regards, |>>>> |>>>> Paul |>>>> |>>>> |>>>> |>> |>> |>> |>> |> |> _______________________________________________ |> Autoconf mailing list |> Autoconf@ietf.org |> https://www.ietf.org/mailman/listinfo/autoconf |> | |-- |Rex Buddenberg |Senior Lecturer |Naval Postgraduate School |Monterey, Ca 93943 |831/656-3576 | |_______________________________________________ |Autoconf mailing list |Autoconf@ietf.org |https://www.ietf.org/mailman/listinfo/autoconf From teco@inf-net.nl Wed Feb 25 00:01:16 2009 Return-Path: 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 8B3843A68E4 for ; Wed, 25 Feb 2009 00:01:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.471 X-Spam-Level: X-Spam-Status: No, score=-1.471 tagged_above=-999 required=5 tests=[AWL=0.575, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] 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 DyRDKmlTIITi for ; Wed, 25 Feb 2009 00:01:15 -0800 (PST) Received: from hpsmtp-eml16.kpnxchange.com (hpsmtp-eml16.KPNXCHANGE.COM [213.75.38.116]) by core3.amsl.com (Postfix) with ESMTP id F10943A679F for ; Wed, 25 Feb 2009 00:01:14 -0800 (PST) Received: from cpsmtp-eml101.kpnxchange.com ([213.75.84.101]) by hpsmtp-eml16.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Feb 2009 09:01:33 +0100 Received: from M90Teco ([86.83.9.22]) by cpsmtp-eml101.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Feb 2009 09:01:32 +0100 From: "Teco Boot" To: "'Paul Lambert'" References: <7BAC95F5A7E67643AAFB2C31BEE662D01489D135@SC-VEXCH2.marvell.com> <7BAC95F5A7E67643AAFB2C31BEE662D01489D23A@SC-VEXCH2.marvell.com> In-Reply-To: <7BAC95F5A7E67643AAFB2C31BEE662D01489D23A@SC-VEXCH2.marvell.com> Date: Wed, 25 Feb 2009 09:01:27 +0100 Message-ID: <002b01c9971f$42efec50$c8cfc4f0$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcmVts2/+HRlOZlOR3SVmQpIK39EBgA1983gACLnwmA= Content-Language: nl X-OriginalArrivalTime: 25 Feb 2009 08:01:32.0844 (UTC) FILETIME=[45D99EC0:01C9971F] Cc: autoconf@ietf.org, 'Emmanuel Baccelli' Subject: Re: [Autoconf] updated draft on aspects of multi-hop wireless communication X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2009 08:01:16 -0000 Inline. |-----Oorspronkelijk bericht----- |Van: autoconf-bounces@ietf.org [mailto:autoconf-bounces@ietf.org] Namens |Paul Lambert |Verzonden: dinsdag 24 februari 2009 16:04 |Aan: Emmanuel Baccelli; autoconf@ietf.org |Onderwerp: Re: [Autoconf] updated draft on aspects of multi-hop wireless |communication | | |Hi Emmanuel, | | |>The goal is NOT to write another problem statement, nor to be |exhaustive |>regarding issues that AUTOCONF should address. |> |>Do you have any comments about the description of the basic aspects |>presented in the draft? | |Well ... if this is not part of the problem statement - I could use a |pointer or more discussion on what this group wishes to address in the |new reduced scope charter. | |The document you submitted was though provoking for me on it's notion |asymmetric links. AS I mentioned before - this is not a consideration |in any of the IEEE 802 wireless or cellular protocols where I have |experience. I don't understand this statement. I think every wireless or cellular protocol should pay attention to the aspects described in draft-baccelli-multi-hop-wireless-communication. For potential asymmetric links, which is a natural characteristic of wireless links, protocols shall implement a bi-directionality check. Using asymmetric links for a uni-directional broadcast channel is something different. It may be useful and in many cases it is very powerful, but it is out-of-scope of many (all?) routing protocols. Main reason is the lack of a return channel. Of course there are protocols (related to routing protocols) that utilize the broadcast links. And we could think of using these links in MANET, e.g. using the uni-directional links for flooding. Anyway, I do not think this is in scope for [Autoconf] right now. |I can see that there could be some interesting |applications. My primary comment was that there are existing ad hoc IP |address assignment problems that do not have this attribute. | |I am starting to see that I may I may be "talking past' members on this |list ... and perhaps should just go away ... I notice that in your |draft it says: | All are configured to | provide store-and-forward functionality on top of these protocols, as | needed to enable communications; consequently, they can be classified | as routers in the resulting wireless network. | |None of the consumer devices that I'm concerned with (cellphones, |cameras, printers, etc.) will be routers. They are connected to a ad |hoc network and still all need IP addresses. I'm a big fan of routers |:-) ... but not all devices on an ad hoc network forward packets. If |this group is solely interested in routing protocols ... I should go |away and create another non-IETF proprietary protocol to solve my |problem area. I raised this issue also some time ago (I think Vancouver meeting). The room responded with large consensus that nodes could easily run the MANET Routing protocol and still not forward packets. So the node learns neighbors and topology information, but for some policy do not advertize its links. Now the definition of "host" and "router" is somewhat troubled. In IETF, we say a host does not forward packets. But in the routing community working on protocols for dynamic routing, we say routers run the Routing Protocol. Maybe IETF missed the point that hosts do need topology information, e.g. default gateway selection / dead gateway detection, ICMP redirect, failover etc. Running routing protocols on hosts is being used already (e.g. passive RIP). | |In this context - is there a specific advocate (customers, products, |markets) for the proposals on this list or is it strictly research |centric? | |If there is need for such a target problem set I would like to suggest |the specific problem area of 802.11 ad hoc networks with 802.11i (aka |WPA2) security. If some one is interested in this problem ... let me |know ... otherwise if this is out of scope I will move to some other |mailing list. I am interested. But I do not see the problem right now. I think the IP layer is on top of the link layer, and 802.11 (including 802.11i WPA2 in IBSS mode) shall enable communication completely independent of layers above. Can you explain the problem a little bit more? Teco. | |Regards, | |Paul | | | | | |________________________________________ |From: autoconf-bounces@ietf.org [mailto:autoconf-bounces@ietf.org] On |Behalf Of Emmanuel Baccelli |Sent: Monday, February 23, 2009 5:01 AM |To: autoconf@ietf.org |Subject: Re: [Autoconf] updated draft on aspects of multi-hop wireless |communication | |Hi Paul, | |thanks for your feedback. This document aims at describing "some |important aspects, experienced over the past decade, of multi-hop ad hoc |wireless communication between routers", as stated in the abstract. | |The goal is to reach a common uderstanding of the basic aspects |presented in the draft (asymmetry, time-variation, non-transitivity, and |radio-range aspects of communcation), which we can then refer to when |discussing further issues, such as the ones you mention, for instance. | |The goal is NOT to write another problem statement, nor to be exhaustive |regarding issues that AUTOCONF should address. | |Do you have any comments about the description of the basic aspects |presented in the draft? | | |Cheers, | |Emmanuel | | | | |On Mon, Feb 23, 2009 at 11:54 AM, Paul Lambert wrote: | |Hi, | |The draft-baccelli-multi-hop-wireless-communication-01 provides an |interesting list of issues that might be addressed by this working |group. | |From a quick review it does not appear to address: | - ad hoc network coalescing. Coalescing has clear implications for | IP address assignment | - there is no mention of multicast versus unicast issues. Perhaps | since the document makes all links potentially asymmetric and | unreliable there is no distinction. At least for 802.11 ad hoc | I find significant implications. | - it does not address link security establishment | The process of setting up the link security is out of scope, but as | I've mentioned in earlier emails this has a clear impact on available | networking mechanisms. | It is also a very important architectural consideration to ensure that | IP address assignment has some level of security. | |Asymmetric links in all "ad hoc" networks. Is it possible to partition |our problem statements so that this is just one of several optional |attributes that must be addressed? | |Most modern wireless MAC layers have reliable unicast. I can see some |broadcast only links - like satellite broadcast, but outside military |applications I am not familiar with broadly deployed commercial wireless |networking technologies that are based on asymmetric unicast |transmissions. Perhaps someone on this list could point me to the |technologies that they are considering for this requirement. | | |Regards, | |Paul | | |________________________________________ |From: autoconf-bounces@ietf.org [mailto:autoconf-bounces@ietf.org] On |Behalf Of Emmanuel Baccelli |Sent: Monday, February 23, 2009 2:04 AM |To: autoconf@ietf.org |Subject: [Autoconf] updated draft on aspects of multi-hop wireless |communication | |Hi all, | | |following the fruitful discussions about initial version of the |document, here is an update to the draft describing aspects of multi-hop |wireless communication: | |http://www.ietf.org/internet-drafts/draft-baccelli-multi-hop-wireless- |communication-01.txt | | |Again, the goal of this document is to identify a consensus about this |topic, and then use this to move on quicker with the rest of the work... | |Please review it, and provide feedback as soon as possible. | | |Cheers | |Emmanuel | |_______________________________________________ |Autoconf mailing list |Autoconf@ietf.org |https://www.ietf.org/mailman/listinfo/autoconf From teco@inf-net.nl Wed Feb 25 00:22:29 2009 Return-Path: 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 A79A43A68E4 for ; Wed, 25 Feb 2009 00:22:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.513 X-Spam-Level: X-Spam-Status: No, score=-0.513 tagged_above=-999 required=5 tests=[AWL=-0.767, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, MANGLED_PILL=2.3] 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 6xwKzewTyeiw for ; Wed, 25 Feb 2009 00:22:28 -0800 (PST) Received: from hpsmtp-eml20.kpnxchange.com (hpsmtp-eml20.KPNXCHANGE.COM [213.75.38.85]) by core3.amsl.com (Postfix) with ESMTP id 7F36C3A689A for ; Wed, 25 Feb 2009 00:22:28 -0800 (PST) Received: from cpsmtp-eml102.kpnxchange.com ([213.75.84.102]) by hpsmtp-eml20.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Feb 2009 09:22:47 +0100 Received: from M90Teco ([86.83.9.22]) by cpsmtp-eml102.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Feb 2009 09:22:47 +0100 From: "Teco Boot" To: "'Thomas Heide Clausen'" , "'Charles E. Perkins'" References: <49A31B60.9050604@gmail.com> <49A31CD5.4090204@earthlink.net> <532BA0E9-FBFD-4022-88AF-BB0D5108FF4D@thomasclausen.org> In-Reply-To: <532BA0E9-FBFD-4022-88AF-BB0D5108FF4D@thomasclausen.org> Date: Wed, 25 Feb 2009 09:22:41 +0100 Message-ID: <002c01c99722$3a526390$aef72ab0$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcmWDWbJWKEUV20cT+qMyIZTiSHZywBEkM2Q Content-Language: nl X-OriginalArrivalTime: 25 Feb 2009 08:22:47.0130 (UTC) FILETIME=[3D623BA0:01C99722] Cc: autoconf@ietf.org, 'Emmanuel Baccelli' Subject: Re: [Autoconf] updated draft on aspects of multi-hop wireless communication X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2009 08:22:29 -0000 Inline. |-----Oorspronkelijk bericht----- |Van: autoconf-bounces@ietf.org [mailto:autoconf-bounces@ietf.org] = Namens |Thomas Heide Clausen |Verzonden: dinsdag 24 februari 2009 0:21 |Aan: Charles E. Perkins |CC: autoconf@ietf.org; Emmanuel Baccelli |Onderwerp: Re: [Autoconf] updated draft on aspects of multi-hop = wireless |communication | |Hello Alex, | |To second Charlie here: in MANETs, routers: | | o ALWAYS have one MANET interface. | o OFTEN they have other (non-MANET) interfaces | o OCCASIONALLY have more than one MANET interface I think the definition is still not clear. Is it a requirement for a MANET Router to forward packets? What is a MANET interface ? (I think I know, but I refer to the endless discussion in [Autoconf]) Is the MANET a complete set of nodes, including attached hosts and "classical routers"? I think the term MANET is quite abstract and attempts to come up with = strict definitions tend to fail. For specifying protocols, we can come up with strict definitions. We could say: An OLSR Router: o ALWAYS have one OLSR interface; o OFTEN they have other (non-OLSR) interfaces; o OCCASIONALLY have more than one OLSR interface. |I.e. it is quite common for traffic to be forwarded over the same |interface as the one on which it was received. The attribute that traffic may be forwarded over the same interface as = the one on which it was received is not specific to MANET at all. Think of = WLAN AP, DSL/cable concentrators, FR/ATM/ISDN, dual-hop satcom etc. Sometimes = we use logical interfaces for links, sometimes we don't. Using logical interfaces introduce problems utilizing layer-2 broadcast for IP = broadcast / multicast. Please note that I do not suggest having detailed discussions on layer-2 technologies itself. Teco. |Thomas | |ps: and for the record, AFAIK all MANET wg routing protocols support |all the situations listed above, i.e. a MANET router with a single or |with multiple MANET interfaces and with or without other non-MANET |interfaces. | |On 23Feb , 2009, at 23:01 , Charles E. Perkins wrote: | |> |> Hello Alex, |> |> On this point I disagree. I think it is better to show the |> routers with a single network interface -- which is what |> they have in real life. This is also the reason that techniques |> like split horizon aren't appropriate. |> |> Regards, |> Charlie P. |> |> |> Alexandru Petrescu wrote: |>> Emmanuel, AUTOCONFers, |>> |>> Just a short clarifying point: I think it would be clarifying to |>> illustrate the routers to have two interfaces. Routers with only = one |>> interface aren't very typical. |>> |>> Just a note, |>> |>> Alex |>> |>> Emmanuel Baccelli a =E9crit : |>>> Hi all, |>>> |>>> |>>> following the fruitful discussions about initial version of the |>>> document, here is an update to the draft describing aspects of |>>> multi-hop wireless communication: |>>> |>>> http://www.ietf.org/internet-drafts/draft-baccelli-multi-hop- |>>> wireless-communication-01.txt |>>> |>>> |>>> |>>> Again, the goal of this document is to identify a consensus about |>>> this topic, and then use this to move on quicker with the rest of |>>> the |>>> work... |>>> |>>> Please review it, and provide feedback as soon as possible. |>>> |>>> |>>> Cheers |>>> |>>> Emmanuel |>>> |>>> |>>> = -------------------------------------------------------------------- |>>> ---- |>>> |>>> |>>> _______________________________________________ Autoconf mailing |>>> list |>>> Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf |>> |>> _______________________________________________ |>> Autoconf mailing list |>> Autoconf@ietf.org |>> https://www.ietf.org/mailman/listinfo/autoconf |>> |>> |> |> _______________________________________________ |> Autoconf mailing list |> Autoconf@ietf.org |> https://www.ietf.org/mailman/listinfo/autoconf | |_______________________________________________ |Autoconf mailing list |Autoconf@ietf.org |https://www.ietf.org/mailman/listinfo/autoconf From teco@inf-net.nl Wed Feb 25 01:16:14 2009 Return-Path: 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 A4B8B3A6A08 for ; Wed, 25 Feb 2009 01:16:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.471 X-Spam-Level: X-Spam-Status: No, score=-1.471 tagged_above=-999 required=5 tests=[AWL=0.575, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] 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 b1gt+Wi-Lqi7 for ; Wed, 25 Feb 2009 01:16:13 -0800 (PST) Received: from cpsmtpo-eml04.kpnxchange.com (cpsmtpo-eml04.KPNXCHANGE.COM [213.75.38.153]) by core3.amsl.com (Postfix) with ESMTP id 6E5A23A69EC for ; Wed, 25 Feb 2009 01:16:12 -0800 (PST) Received: from cpsmtp-eml104.kpnxchange.com ([213.75.84.104]) by cpsmtpo-eml04.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Feb 2009 10:16:32 +0100 Received: from M90Teco ([86.83.9.22]) by cpsmtp-eml104.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Feb 2009 10:16:32 +0100 From: "Teco Boot" To: "'Emmanuel Baccelli'" References: <002d01c99722$dcf7f650$96e7e2f0$@nl> In-Reply-To: <002d01c99722$dcf7f650$96e7e2f0$@nl> Date: Wed, 25 Feb 2009 10:16:26 +0100 Message-ID: <002e01c99729$bc956350$35c029f0$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcmVnhGiMXawDw5IQfWe0r6wHqKGywBhKxcgAAAKjUA= Content-Language: nl X-OriginalArrivalTime: 25 Feb 2009 09:16:32.0062 (UTC) FILETIME=[BF97CDE0:01C99729] Cc: autoconf@ietf.org Subject: Re: [Autoconf] updated draft on aspects of multi-hop wireless communication X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2009 09:16:14 -0000 Thanks for the updated draft. Here some feedback: On exposed node: I do not understand what is mentioned here. I think the exposed node problem is communication from A to B (correct) and C to D (reverse direction of arrow). With CSMA, transmit from C is delayed = because C noticed carrier busy caused by transmit from A (or CSMA/CA virtual = carrier sense by CTS from B) . The delay was not needed, as C transmission does = not affect B reception of frame transmitted by A. I think exposed node is more a research problem and less an operational problem. On Hidden Terminal: I think this __is__ an operational problem, but = handled in some or many cases by a media access mechanism, like CSMA/CA or TDMA. Some / many cases implies "not all" cases, e.g. CSMA/CA does not work = for multicast. And multicast may be of large importance in MANETs, e.g. = MANET routing protocol flooding. I suggest swapping the two problems, mentioning the important one first. The draft emphasizes problems introduced by limited radio range. Note = that it has also a welcome characteristic, that is spatial reuse. Be positive = on wireless communication one time ? :-) Once again, I think: - We may say that router B is a neighbor of router A. In this terminology, there is no guarantee that router A is a neighbor of router B, even if router B a neighbor of router A. is incorrect. B hears A and I would say A is a neighbor of A and A is = listed in B's neighbor table. Is there a reason not to update the text, as we agreed on before? Teco. |-----Oorspronkelijk bericht----- |Van: autoconf-bounces@ietf.org [mailto:autoconf-bounces@ietf.org] = Namens |Emmanuel Baccelli |Verzonden: maandag 23 februari 2009 11:04 |Aan: autoconf@ietf.org |Onderwerp: [Autoconf] updated draft on aspects of multi-hop wireless |communication | |Hi all, | | |following the fruitful discussions about initial version of the |document, |here is an update to the draft describing=A0aspects of multi-hop = wireless |communication: | |http://www.ietf.org/internet-drafts/draft-baccelli-multi-hop-wireless- |commun |ication-01.txt | | |Again, the goal of this document is to identify a consensus about this |topic, and then use this to move on quicker with the rest of the = work... | |Please review it, and provide feedback as soon as possible. | | |Cheers | |Emmanuel From ietf@thomasclausen.org Wed Feb 25 04:45:12 2009 Return-Path: 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 163EA3A6900 for ; Wed, 25 Feb 2009 04:45:12 -0800 (PST) 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 8fhaZZlhplbE for ; Wed, 25 Feb 2009 04:45:11 -0800 (PST) Received: from mho-01-bos.mailhop.org (mho-01-bos.mailhop.org [63.208.196.178]) by core3.amsl.com (Postfix) with ESMTP id 285953A688A for ; Wed, 25 Feb 2009 04:45:11 -0800 (PST) Received: from aste-genev-bois-153-1-76-71.w86-203.abo.wanadoo.fr ([86.203.162.71] helo=[192.168.147.109]) by mho-01-bos.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1LcJ8k-000PM1-8l; Wed, 25 Feb 2009 12:45:30 +0000 X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 86.203.162.71 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18VHXWx4E2PjXt7W4eG2wUy In-Reply-To: <002b01c9971f$42efec50$c8cfc4f0$@nl> References: <7BAC95F5A7E67643AAFB2C31BEE662D01489D135@SC-VEXCH2.marvell.com> <7BAC95F5A7E67643AAFB2C31BEE662D01489D23A@SC-VEXCH2.marvell.com> <002b01c9971f$42efec50$c8cfc4f0$@nl> Mime-Version: 1.0 (Apple Message framework v753.1) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6F272E51-6C0E-4E99-8215-00487C30343B@thomasclausen.org> Content-Transfer-Encoding: 7bit From: Thomas Heide Clausen Date: Wed, 25 Feb 2009 13:47:15 +0100 To: "Teco Boot" X-Mailer: Apple Mail (2.753.1) Cc: autoconf@ietf.org, 'Emmanuel Baccelli' Subject: Re: [Autoconf] updated draft on aspects of multi-hop wireless communication X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2009 12:45:12 -0000 On Feb 25, 2009, at 09:01 AM, Teco Boot wrote: > |None of the consumer devices that I'm concerned with (cellphones, > |cameras, printers, etc.) will be routers. They are connected to a ad > |hoc network and still all need IP addresses. I'm a big fan of > routers > |:-) ... but not all devices on an ad hoc network forward packets. If > |this group is solely interested in routing protocols ... I should go > |away and create another non-IETF proprietary protocol to solve my > |problem area. > > I raised this issue also some time ago (I think Vancouver meeting). > The room > responded with large consensus that nodes could easily run the > MANET Routing > protocol and still not forward packets. So the node learns > neighbors and > topology information, but for some policy do not advertize its links. > Now the definition of "host" and "router" is somewhat troubled. In > IETF, we > say a host does not forward packets. But in the routing community > working on > protocols for dynamic routing, we say routers run the Routing > Protocol. I'll speak for the network that I build.... If a node runs a MANET routing protocol, such as OLSR(v2), then that node is by [my] definition a router. It can have hosts attached to it on non-MANET interfaces, and it will over its MANET interface take part in a routing graph. In OLSR(v2), a router can set its willingness to 0 (zero). That means that this router is unwilling to be selected as MPR and so not willing to forward traffic destined to *OTHER* MANET routers. It is, however, still forwarding traffic to and from the hosts attached to it, and so providing connectivity to these through the MANET. You could consider it such: o a HOST is an endpoint for communications, with no network-formation responsibilities; o an OLSR(v2) router with "Willingness = 0 (zero)" is an "edge router": providing connectivity only to attached hosts by injecting prefixes for these into the routing domain, but otherwise disclaims network formation responsibilities o an OLSR(v2) router with "Willingness > 0" is, if the topology suggests it, a "core router", also participating in the network formation and traffic forwarding for other OLSR(v2) routers. So, to me, any "node running OLSR(v2)" is a router, and it will be forwarding traffic -- although potentially only to the attached host (s) by acting as an edge-router. > Maybe IETF missed the point that hosts do need topology > information, e.g. > default gateway selection / dead gateway detection, ICMP redirect, > failover > etc. Running routing protocols on hosts is being used already (e.g. > passive > RIP). Whatever happens between an OLSR(v2) router and its attached network or hosts is, as it should, no different from what happens between an OSPF router and its attached network or hosts. So, while that's an interesting topic and discussion, it probably should be taken somewhere more general than AUTOCONF? Thomas From teco@inf-net.nl Wed Feb 25 06:24:46 2009 Return-Path: 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 EDF5928C1AC for ; Wed, 25 Feb 2009 06:24:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.586 X-Spam-Level: X-Spam-Status: No, score=-1.586 tagged_above=-999 required=5 tests=[AWL=0.460, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] 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 sOCzhAHOUTwh for ; Wed, 25 Feb 2009 06:24:43 -0800 (PST) Received: from hpsmtp-eml17.kpnxchange.com (hpsmtp-eml17.KPNXCHANGE.COM [213.75.38.117]) by core3.amsl.com (Postfix) with ESMTP id A112328C1BE for ; Wed, 25 Feb 2009 06:24:42 -0800 (PST) Received: from cpsmtp-eml103.kpnxchange.com ([213.75.84.103]) by hpsmtp-eml17.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Feb 2009 15:24:58 +0100 Received: from M90Teco ([86.83.9.22]) by cpsmtp-eml103.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Feb 2009 15:24:57 +0100 From: "Teco Boot" To: "'Thomas Heide Clausen'" References: <7BAC95F5A7E67643AAFB2C31BEE662D01489D135@SC-VEXCH2.marvell.com> <7BAC95F5A7E67643AAFB2C31BEE662D01489D23A@SC-VEXCH2.marvell.com> <002b01c9971f$42efec50$c8cfc4f0$@nl> <6F272E51-6C0E-4E99-8215-00487C30343B@thomasclausen.org> In-Reply-To: <6F272E51-6C0E-4E99-8215-00487C30343B@thomasclausen.org> Date: Wed, 25 Feb 2009 15:24:53 +0100 Message-ID: <006101c99754$d3468130$79d38390$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcmXRvMrCIUDhQc3Q1O/CKSNyn8YqQADDvkg Content-Language: nl X-OriginalArrivalTime: 25 Feb 2009 14:24:57.0943 (UTC) FILETIME=[D5F52670:01C99754] Cc: autoconf@ietf.org, 'Emmanuel Baccelli' Subject: Re: [Autoconf] updated draft on aspects of multi-hop wireless communication X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2009 14:24:47 -0000 OK, now we have at least three classes of routers: 1: Core router: - Forward packets - Advertize links - Advertize stub networks / external networks - Learn topology 2: Edge router (example from Thomas): - Forward packets - NOT advertize links - Advertize stub networks / external networks - Learn topology 3: My passive RIP example (built quite some time ago...) - NOT forward packets - NOT advertize links - NOT advertize stub networks / external networks - Learn topology The last one is strictly spoken not a router. It is a "host running a routing protocol". For a protocol that constantly repeats topology info, a passive listener is acceptable. For protocols that implement ACK based topology flooding (e.g. OSPF), the node should be part of the hello and flooding mechanisms, but does not have a requirement to inject links and thus does not forward packets. Teco. |-----Oorspronkelijk bericht----- |Van: Thomas Heide Clausen [mailto:ietf@thomasclausen.org] |Verzonden: woensdag 25 februari 2009 13:47 |Aan: Teco Boot |CC: 'Paul Lambert'; autoconf@ietf.org; 'Emmanuel Baccelli' |Onderwerp: Re: [Autoconf] updated draft on aspects of multi-hop wireless |communication | | |On Feb 25, 2009, at 09:01 AM, Teco Boot wrote: | | | |> |None of the consumer devices that I'm concerned with (cellphones, |> |cameras, printers, etc.) will be routers. They are connected to a ad |> |hoc network and still all need IP addresses. I'm a big fan of |> routers |> |:-) ... but not all devices on an ad hoc network forward packets. If |> |this group is solely interested in routing protocols ... I should go |> |away and create another non-IETF proprietary protocol to solve my |> |problem area. |> |> I raised this issue also some time ago (I think Vancouver meeting). |> The room |> responded with large consensus that nodes could easily run the |> MANET Routing |> protocol and still not forward packets. So the node learns |> neighbors and |> topology information, but for some policy do not advertize its links. |> Now the definition of "host" and "router" is somewhat troubled. In |> IETF, we |> say a host does not forward packets. But in the routing community |> working on |> protocols for dynamic routing, we say routers run the Routing |> Protocol. | |I'll speak for the network that I build.... | |If a node runs a MANET routing protocol, such as OLSR(v2), then that |node is by [my] definition a router. It can have hosts attached to it |on non-MANET interfaces, and it will over its MANET interface take |part in a routing graph. | |In OLSR(v2), a router can set its willingness to 0 (zero). That means |that this router is unwilling to be selected as MPR and so not |willing to forward traffic destined to *OTHER* MANET routers. It is, |however, still forwarding traffic to and from the hosts attached to |it, and so providing connectivity to these through the MANET. | |You could consider it such: | | o a HOST is an endpoint for communications, with no network- |formation | responsibilities; | | o an OLSR(v2) router with "Willingness = 0 (zero)" is an "edge |router": | providing connectivity only to attached hosts by injecting |prefixes | for these into the routing domain, but otherwise disclaims |network | formation responsibilities | | o an OLSR(v2) router with "Willingness > 0" is, if the |topology |suggests | it, a "core router", also participating in the network |formation and | traffic forwarding for other OLSR(v2) routers. | |So, to me, any "node running OLSR(v2)" is a router, and it will be |forwarding traffic -- although potentially only to the attached host |(s) by acting as an edge-router. | |> Maybe IETF missed the point that hosts do need topology |> information, e.g. |> default gateway selection / dead gateway detection, ICMP redirect, |> failover |> etc. Running routing protocols on hosts is being used already (e.g. |> passive |> RIP). | |Whatever happens between an OLSR(v2) router and its attached network |or hosts is, as it should, no different from what happens between an |OSPF router and its attached network or hosts. | |So, while that's an interesting topic and discussion, it probably |should be taken somewhere more general than AUTOCONF? | |Thomas From emmanuel.baccelli@gmail.com Wed Feb 25 07:44:33 2009 Return-Path: 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 9EF4C3A69E6 for ; Wed, 25 Feb 2009 07:44:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.873 X-Spam-Level: X-Spam-Status: No, score=-1.873 tagged_above=-999 required=5 tests=[AWL=0.103, 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 FhdTsWvy0rtE for ; Wed, 25 Feb 2009 07:44:32 -0800 (PST) Received: from mail-fx0-f176.google.com (mail-fx0-f176.google.com [209.85.220.176]) by core3.amsl.com (Postfix) with ESMTP id 602EE3A690E for ; Wed, 25 Feb 2009 07:44:31 -0800 (PST) Received: by fxm24 with SMTP id 24so40163fxm.37 for ; Wed, 25 Feb 2009 07:44:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to :content-type; bh=UKUW42IOBLzwV68/4BoT11SENkCbM4sB3mgUkx8Ug1E=; b=aGonr3OaL6u3IPnsJ2dxh2v3XZiA83reEgG8ACk66QqKzsNJwdG+PgC/Vp1uzAC1+/ cylbSTKocGJlkQZqFkCNq6fvaAtuBg4JUfMvTjbCvxY26IZH05ZvhAAPhZRU59AikrLd AN4RzoPje9lX9C+Kd1rG5F/TG9uHuUOVZPDN4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; b=A4nDFhg9RmFr9uqbU+Hl5XRTqgQo1/A00N1w3Vnd9CKYJ25tt5EpECL56gV/F2iiVr 9shayxDY5ZuuS6n1b9ZDoIdlCvYbHEIfcYE7he1nf9KVVO/q9g/opAZP6M7LpIAG7wFv DSbtyHZaeIVdAA+10yXgi+c2jllmf2MbvcuLg= MIME-Version: 1.0 Sender: emmanuel.baccelli@gmail.com Received: by 10.103.198.20 with SMTP id a20mr124634muq.63.1235576689944; Wed, 25 Feb 2009 07:44:49 -0800 (PST) In-Reply-To: <002e01c99729$bc956350$35c029f0$@nl> References: <002d01c99722$dcf7f650$96e7e2f0$@nl> <002e01c99729$bc956350$35c029f0$@nl> Date: Wed, 25 Feb 2009 16:44:49 +0100 X-Google-Sender-Auth: ee24d64b09d8da44 Message-ID: From: Emmanuel Baccelli To: autoconf@ietf.org Content-Type: multipart/alternative; boundary=0016369fa20db26a9a0463c01d67 Subject: Re: [Autoconf] updated draft on aspects of multi-hop wireless communication X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2009 15:44:33 -0000 --0016369fa20db26a9a0463c01d67 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Teco, inline On Wed, Feb 25, 2009 at 10:16 AM, Teco Boot wrote: > Thanks for the updated draft. > Here some feedback: > > On exposed node: I do not understand what is mentioned here. I think the > exposed node problem is communication from A to B (correct) and C to D > (reverse direction of arrow). With CSMA, transmit from C is delayed because > C noticed carrier busy caused by transmit from A (or CSMA/CA virtual > carrier > sense by CTS from B) . The delay was not needed, as C transmission does not > affect B reception of frame transmitted by A. > I think exposed node is more a research problem and less an operational > problem. I agree, but it may become more operational as multi-hop ad hoc networks are more widely deployed. What do you think about this description of the exposed node issues on wikipedia? http://en.wikipedia.org/wiki/Exposed_terminal_problem As for the use of CSMA/CA to cope with this, see my comment below. > > On Hidden Terminal: I think this __is__ an operational problem, but handled > in some or many cases by a media access mechanism, like CSMA/CA or TDMA. > Some / many cases implies "not all" cases, e.g. CSMA/CA does not work for > multicast. And multicast may be of large importance in MANETs, e.g. MANET > routing protocol flooding. Yes you are right, most of the time, L2 will cope with these issues. However, as you mention, not all the time, even with L2 technology that is aware. For example because of multicast/broadcast, or because of non-synchronization (common in multi-hop ad hoc networks). In any case, maybe we should make clearer that this radio range limitation aspect in multi-hop ad hoc networks causes some problems that force L2 to use specific mechanisms (you cite CSMA/CA). Similarly it is causing some of the problems described in Section 3 (and to some extent Section 4) at L3, which have to be taken into account when designing L3 protocols that can support such networks. > > > I suggest swapping the two problems, mentioning the important one first. I don't have a problem with reordering this ;) > > > The draft emphasizes problems introduced by limited radio range. Note that > it has also a welcome characteristic, that is spatial reuse. Be positive on > wireless communication one time ? :-) > > > Once again, I think: > - We may say that router B is a neighbor of router A. In this > terminology, there is no guarantee that router A is a neighbor of > router B, even if router B a neighbor of router A. > is incorrect. B hears A and I would say A is a neighbor of A and A is > listed > in B's neighbor table. > Is there a reason not to update the text, as we agreed on before? I don't follow you here, maybe I misunderstood. If B is a neighbor of A, it means that A hears B, and B is thus in A's routing table. It does not necessarily mean that B hears A too, or that A is in B's routing table, hence it does not mean that A is a neighbor of B too? Emmanuel --0016369fa20db26a9a0463c01d67 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Teco, inline

On Wed, Feb 25, 2009 at 1= 0:16 AM, Teco Boot <teco@inf-net.nl> wrote:
Thanks for the updated draft.
Here some feedback:

On exposed node: I do not understand what is mentioned here. I think the exposed node problem is communication from A to B (correct) and C to D
(reverse direction of arrow). With CSMA, transmit from C is delayed because=
C noticed carrier busy caused by transmit from A (or CSMA/CA virtual carrie= r
sense by CTS from B) . The delay was not needed, as C transmission does not=
affect B reception of frame transmitted by A.
I think exposed node is more a research problem and less an operational
problem.


I agree, but it may= become more operational as multi-hop ad hoc networks are more widely deplo= yed. What do you think about this description of the exposed node issues on= wikipedia?=A0http://en.wikipedia.org/wiki/Exposed_terminal_problem=A0

As for the use of CSMA/CA to cope with this, see my com= ment below.=A0

=A0

On Hidden Terminal: I think this __is__ an operational problem, but handled=
in some or many cases by a media access mechanism, like CSMA/CA or TDMA. Some / many cases implies "not all" cases, e.g. CSMA/CA does not = work for
multicast. And multicast may be of large importance in MANETs, e.g. MANET routing protocol flooding.


Y= es you are right, most of the time, L2 will cope with these issues. However= , as you mention, not all the time,=A0even with L2 technology that is aware= . For example=A0because of multicast/broadcast, or because of non-synchroni= zation (common in multi-hop ad hoc networks).

In any case, maybe we should make clearer that this rad= io range limitation aspect in multi-hop ad hoc networks causes some problem= s that force L2 to use specific mechanisms (you cite CSMA/CA). Similarly it= is causing some of the problems described in Section 3 (and to some extent= Section 4) at L3, which have to be taken into account when designing L3 pr= otocols that can support such networks.



=A0


I suggest swapping the two problems, mentioning the important one first.
=A0

I don't have a problem with= reordering this ;)

=A0


The draft emphasizes problems introduced by limited radio range. Note that<= br> it has also a welcome characteristic, that is spatial reuse. Be positive on=
wireless communication one time ? :-)


Once again, I think:
=A0- We may say that router B is a neighbor of router A. In this
=A0terminology, there is no guarantee that router A is a neighbor of
=A0router B, even if router B a neighbor of router A.
is incorrect. B hears A and I would say A is a neighbor of A and A is liste= d
in B's neighbor table.
Is there a reason not to update the text, as we agreed on before?


I don't follow you here, maybe I = misunderstood. If B is a neighbor of A, it means that A hears B, and B is t= hus in A's routing table. It does not necessarily mean that B hears A t= oo, or that A is in B's routing table, hence it does not mean that A is= a neighbor of B too?
=A0
Emmanuel

--0016369fa20db26a9a0463c01d67-- From emmanuel.baccelli@gmail.com Wed Feb 25 07:57:10 2009 Return-Path: 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 469E83A6A87 for ; Wed, 25 Feb 2009 07:57:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[AWL=0.089, 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 0g6SVy7qyqJN for ; Wed, 25 Feb 2009 07:57:09 -0800 (PST) Received: from mail-fx0-f176.google.com (mail-fx0-f176.google.com [209.85.220.176]) by core3.amsl.com (Postfix) with ESMTP id ED5773A6805 for ; Wed, 25 Feb 2009 07:57:08 -0800 (PST) Received: by fxm24 with SMTP id 24so45943fxm.37 for ; Wed, 25 Feb 2009 07:57:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to :content-type; bh=ExyThFxvmh/x7zVmmgBd3ZKaPmDEmgK/VOTRbLYfWpY=; b=TUZ+uCfb/i/4dXr511GLNO5JIGNh88b8wlgA6PHNy7wEyVhkcwRlSV62hEUeWFpSYY +vMTGuELt8hTmG7EwlQOwqWAeApyHBPgUTKpN24pS2pqtD44qUmGk+pEhOntEH1nHqfh CNi+A88rm75ob6VXMy5FCY9j2Z7Ne4p9J5wBo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; b=CL0WM7atwkYwSCKVAwHbbJjDMz6wVrKAskmSiVvnunE/gieyoH5YGLwYIKY8G94FrV zwtl56aq81pPFQjaesXzUw/OUa4BQWgvYCz2NVQ+ezhdJflWqyK4pnFskB5Vep+7MMcc GDEKZelIh7dH0gsAhxvpnJY3rnmWGxeGViDZA= MIME-Version: 1.0 Sender: emmanuel.baccelli@gmail.com Received: by 10.103.24.17 with SMTP id b17mr139575muj.21.1235577447804; Wed, 25 Feb 2009 07:57:27 -0800 (PST) In-Reply-To: <49A31CD5.4090204@earthlink.net> References: <49A31B60.9050604@gmail.com> <49A31CD5.4090204@earthlink.net> Date: Wed, 25 Feb 2009 16:57:27 +0100 X-Google-Sender-Auth: 3e0d5acaefff2b3a Message-ID: From: Emmanuel Baccelli To: autoconf@ietf.org Content-Type: multipart/alternative; boundary=0016e65a0d86de6e320463c04a51 Subject: Re: [Autoconf] updated draft on aspects of multi-hop wireless communication X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2009 15:57:10 -0000 --0016e65a0d86de6e320463c04a51 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Alex, I think that what Charlie and Thomas want to say is basically: - A router typically has several physical interfaces - A router typically has just one MANET interface (although it may have several) - A router may have just one physical interface (for instance its MANET interface) Emmanuel On Mon, Feb 23, 2009 at 11:01 PM, Charles E. Perkins < charles.perkins@earthlink.net> wrote: > > Hello Alex, > > On this point I disagree. I think it is better to show the > routers with a single network interface -- which is what > they have in real life. This is also the reason that techniques > like split horizon aren't appropriate. > > Regards, > Charlie P. > > > Alexandru Petrescu wrote: > >> Emmanuel, AUTOCONFers, >> >> Just a short clarifying point: I think it would be clarifying to >> illustrate the routers to have two interfaces. Routers with only one >> interface aren't very typical. >> >> Just a note, >> >> Alex >> >> Emmanuel Baccelli a =E9crit : >> >>> Hi all, >>> >>> >>> following the fruitful discussions about initial version of the documen= t, >>> here is an update to the draft describing aspects of >>> multi-hop wireless communication: >>> >>> >>> http://www.ietf.org/internet-drafts/draft-baccelli-multi-hop-wireless-c= ommunication-01.txt >>> >>> >>> >>> Again, the goal of this document is to identify a consensus about >>> this topic, and then use this to move on quicker with the rest of the >>> work... >>> >>> Please review it, and provide feedback as soon as possible. >>> >>> >>> Cheers >>> >>> Emmanuel >>> >>> >>> -----------------------------------------------------------------------= - >>> >>> >>> _______________________________________________ Autoconf mailing list >>> Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf >>> >> >> _______________________________________________ >> Autoconf mailing list >> Autoconf@ietf.org >> https://www.ietf.org/mailman/listinfo/autoconf >> >> >> > --0016e65a0d86de6e320463c04a51 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Alex, I think that what Charlie and Thomas want to say is basically:
- A router typically has several physical interfaces
- A router typically has just one MANET interface (although it may have se= veral)
- A router may have just one physical interface (for instance its MANE= T interface)

Emmanuel


On Mon, Feb 23, 2009 at 11:01 PM, Charles E= . Perkins <charles.perkins@earthlink.net> wrote:

Hello Alex,

On this point I disagree. =A0I think it is better to show the
routers with a single network interface -- which is what
they have in real life. =A0This is also the reason that techniques
like split horizon aren't appropriate.

Regards,
Charlie P.


Alexandru Petrescu wrote:
Emmanuel, AUTOCONFers,

Just a short clarifying point: I think it would be clarifying to
illustrate the routers to have two interfaces. =A0Routers with only one
interface aren't very typical.

Just a note,

Alex

Emmanuel Baccelli a =E9crit :
Hi all,


following the fruitful discussions about initial version of the document, h= ere is an update to the draft describing aspects of
multi-hop wireless communication:

http://www.ietf.org/internet-= drafts/draft-baccelli-multi-hop-wireless-communication-01.txt



Again, the goal of this document is to identify a consensus about
this topic, and then use this to move on quicker with the rest of the
work...

Please review it, and provide feedback as soon as possible.


Cheers

Emmanuel


------------------------------------------------------------------------

_______________________________________________ Autoconf mailing list
=A0Autoconf@ietf.org= https://www.ietf.org/mailman/listinfo/autoconf

_______________________________________________

Autoconf mailing list
Autoconf@ietf.org
https://www.ietf.org/mailman/listinfo/autoconf




--0016e65a0d86de6e320463c04a51-- From alexandru.petrescu@gmail.com Wed Feb 25 08:06:01 2009 Return-Path: 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 50F2928C0F8 for ; Wed, 25 Feb 2009 08:06:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.176 X-Spam-Level: X-Spam-Status: No, score=-2.176 tagged_above=-999 required=5 tests=[AWL=0.073, 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 pyxwvbzAO+Dh for ; Wed, 25 Feb 2009 08:06:00 -0800 (PST) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.166.172.106]) by core3.amsl.com (Postfix) with ESMTP id 28E2F28C0EB for ; Wed, 25 Feb 2009 08:06:00 -0800 (PST) Received: from nephilia.intra.cea.fr (nephilia.intra.cea.fr [132.166.88.33]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-1.2) with ESMTP id n1PG6J0w015333; Wed, 25 Feb 2009 17:06:19 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by nephilia.intra.cea.fr (8.13.8/8.13.8) with ESMTP id n1PG6Jxd027472; Wed, 25 Feb 2009 17:06:19 +0100 (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 n1PG6JQ6008903; Wed, 25 Feb 2009 17:06:19 +0100 Message-ID: <49A56C7A.8090304@gmail.com> Date: Wed, 25 Feb 2009 17:06:18 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Emmanuel Baccelli References: <49A31B60.9050604@gmail.com> <49A31CD5.4090204@earthlink.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org Subject: Re: [Autoconf] updated draft on aspects of multi-hop wireless communication X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2009 16:06:01 -0000 Emmanuel Baccelli a écrit : > Alex, I think that what Charlie and Thomas want to say is basically: > > - A router typically has several physical interfaces > - A router typically has just one MANET interface (although it may have > several) > - A router may have just one physical interface (for instance its MANET > interface) Emmanuel, I agree with the first definition in the list. I think it's probably the most widely accepted definition, among the three. However, the draft pictures a router with only one interface, which is only the third in the list. Alex > > Emmanuel > > > > On Mon, Feb 23, 2009 at 11:01 PM, Charles E. Perkins > > > wrote: > > > Hello Alex, > > On this point I disagree. I think it is better to show the > routers with a single network interface -- which is what > they have in real life. This is also the reason that techniques > like split horizon aren't appropriate. > > Regards, > Charlie P. > > > Alexandru Petrescu wrote: > > Emmanuel, AUTOCONFers, > > Just a short clarifying point: I think it would be clarifying to > illustrate the routers to have two interfaces. Routers with > only one > interface aren't very typical. > > Just a note, > > Alex > > Emmanuel Baccelli a écrit : > > Hi all, > > > following the fruitful discussions about initial version of > the document, here is an update to the draft describing > aspects of > multi-hop wireless communication: > > http://www.ietf.org/internet-drafts/draft-baccelli-multi-hop-wireless-communication-01.txt > > > > > Again, the goal of this document is to identify a consensus > about > this topic, and then use this to move on quicker with the > rest of the > work... > > Please review it, and provide feedback as soon as possible. > > > Cheers > > Emmanuel > > > ------------------------------------------------------------------------ > > > _______________________________________________ Autoconf > mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf > > > _______________________________________________ > > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf > > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf From ietf@thomasclausen.org Wed Feb 25 14:33:23 2009 Return-Path: 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 140C23A6B69 for ; Wed, 25 Feb 2009 14:33:23 -0800 (PST) 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=[AWL=0.000, 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 BmWP0Dz2Qp6z for ; Wed, 25 Feb 2009 14:33:22 -0800 (PST) Received: from mho-02-bos.mailhop.org (mho-02-bos.mailhop.org [63.208.196.179]) by core3.amsl.com (Postfix) with ESMTP id 3421A3A6B1B for ; Wed, 25 Feb 2009 14:33:22 -0800 (PST) Received: from aste-genev-bois-153-1-76-71.w86-203.abo.wanadoo.fr ([86.203.162.71] helo=[192.168.147.109]) by mho-02-bos.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1LcSJy-000D7B-4D; Wed, 25 Feb 2009 22:33:42 +0000 X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 86.203.162.71 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19ASiI5assRgqDrFkL/4mbM In-Reply-To: <49A56C7A.8090304@gmail.com> References: <49A31B60.9050604@gmail.com> <49A31CD5.4090204@earthlink.net> <49A56C7A.8090304@gmail.com> Mime-Version: 1.0 (Apple Message framework v753.1) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: Thomas Heide Clausen Date: Wed, 25 Feb 2009 23:35:28 +0100 To: Alexandru Petrescu X-Mailer: Apple Mail (2.753.1) Cc: autoconf@ietf.org, Emmanuel Baccelli Subject: Re: [Autoconf] updated draft on aspects of multi-hop wireless communication X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2009 22:33:23 -0000 On Feb 25, 2009, at 17:06 PM, Alexandru Petrescu wrote: > Emmanuel Baccelli a =E9crit : >> Alex, I think that what Charlie and Thomas want to say is basically: >> - A router typically has several physical interfaces >> - A router typically has just one MANET interface (although it may =20= >> have several) >> - A router may have just one physical interface (for instance its =20 >> MANET interface) > > Emmanuel, I agree with the first definition in the list. I think =20 > it's probably the most widely accepted definition, among the three. > > However, the draft pictures a router with only one interface, which =20= > is only the third in the list. > I think that the point is that in a MANET as it is commonly deployed, =20= one quite often find routers which have just one physical interface. Thomas > Alex > >> Emmanuel >> On Mon, Feb 23, 2009 at 11:01 PM, Charles E. Perkins =20 >> > > wrote: >> Hello Alex, >> On this point I disagree. I think it is better to show the >> routers with a single network interface -- which is what >> they have in real life. This is also the reason that techniques >> like split horizon aren't appropriate. >> Regards, >> Charlie P. >> Alexandru Petrescu wrote: >> Emmanuel, AUTOCONFers, >> Just a short clarifying point: I think it would be =20 >> clarifying to >> illustrate the routers to have two interfaces. Routers with >> only one >> interface aren't very typical. >> Just a note, >> Alex >> Emmanuel Baccelli a =E9crit : >> Hi all, >> following the fruitful discussions about initial =20 >> version of >> the document, here is an update to the draft describing >> aspects of >> multi-hop wireless communication: >> http://www.ietf.org/internet-drafts/draft-baccelli-=20 >> multi-hop-wireless-communication-01.txt >> Again, the goal of this document is to identify a =20 >> consensus >> about >> this topic, and then use this to move on quicker with the >> rest of the >> work... >> Please review it, and provide feedback as soon as =20 >> possible. >> Cheers >> Emmanuel >> =20 >> ---------------------------------------------------------------------=20= >> --- >> _______________________________________________ Autoconf >> mailing list >> Autoconf@ietf.org >> https://www.ietf.org/mailman/listinfo/autoconf >> _______________________________________________ >> Autoconf mailing list >> Autoconf@ietf.org >> https://www.ietf.org/mailman/listinfo/autoconf >> ---------------------------------------------------------------------=20= >> --- >> _______________________________________________ >> Autoconf mailing list >> Autoconf@ietf.org >> https://www.ietf.org/mailman/listinfo/autoconf > > > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf From emmanuel.baccelli@gmail.com Thu Feb 26 00:11:40 2009 Return-Path: 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 239B428C258 for ; Thu, 26 Feb 2009 00:11:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[AWL=0.078, 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 QSymBDOPYH37 for ; Thu, 26 Feb 2009 00:11:39 -0800 (PST) Received: from mail-bw0-f178.google.com (mail-bw0-f178.google.com [209.85.218.178]) by core3.amsl.com (Postfix) with ESMTP id 4AF6728C1DD for ; Thu, 26 Feb 2009 00:11:37 -0800 (PST) Received: by bwz26 with SMTP id 26so365718bwz.37 for ; Thu, 26 Feb 2009 00:11:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to :content-type; bh=w6rBzaUBpBYawSg7hUpw8zuxU6iMvjSo7ZfbtWCVGpI=; b=utd5JN2ic7VAEEURAQPFpkkPJO6vdQihWgqqTUL+3tu5Vt2+G3nrgkINSbx8218Ve2 dI7mDQU9POXJBl6EaZf0Rmt9Kk1cMybMwQLsUM+P8CrWqzwWuP9baQ6Qp8WJfcKeuuPs hnfjBdBGDeVEABDdjwL1K9dUp7eNyXMMI7m3c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; b=kYc42xLr5yZ4wjwURF78ZVr0II85cy+VRuIKPOStxCTaWPTsfW0gSvrH88uka00kDp VdVfdeiEl4P+9kMyPKEJ0Yc97oji9vfYb9T53t/gtqrU0/Q+bGD8T0i3hIKdVSqDkW3K CFaicQ+cDHrpvtusLPmeEz1Dwy4jRAznyEi5U= MIME-Version: 1.0 Sender: emmanuel.baccelli@gmail.com Received: by 10.103.6.18 with SMTP id j18mr534494mui.33.1235635918323; Thu, 26 Feb 2009 00:11:58 -0800 (PST) In-Reply-To: References: <49A31B60.9050604@gmail.com> <49A31CD5.4090204@earthlink.net> <49A56C7A.8090304@gmail.com> Date: Thu, 26 Feb 2009 09:11:58 +0100 X-Google-Sender-Auth: f567e7287609f437 Message-ID: From: Emmanuel Baccelli To: autoconf@ietf.org Content-Type: multipart/alternative; boundary=001636416899fbbe1d0463cde7bc Subject: Re: [Autoconf] updated draft on aspects of multi-hop wireless communication X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2009 08:11:40 -0000 --001636416899fbbe1d0463cde7bc Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Feb 25, 2009 at 11:35 PM, Thomas Heide Clausen < ietf@thomasclausen.org> wrote: > > On Feb 25, 2009, at 17:06 PM, Alexandru Petrescu wrote: > > Emmanuel Baccelli a =E9crit : >> >>> Alex, I think that what Charlie and Thomas want to say is basically: >>> - A router typically has several physical interfaces >>> - A router typically has just one MANET interface (although it may have >>> several) >>> - A router may have just one physical interface (for instance its MANET >>> interface) >>> >> >> Emmanuel, I agree with the first definition in the list. I think it's >> probably the most widely accepted definition, among the three. >> >> However, the draft pictures a router with only one interface, which is >> only the third in the list. >> >> > I think that the point is that in a MANET as it is commonly deployed, one > quite often find routers which have just one physical interface. > > Thomas > ... and if they have several interfaces, they typically have just one interface of "type" MANET. This is why it make sense to present a description of what's going on on MANETs reduced to a MANET-centric view, where nodes typically have one (MANET) interface. However, again, there is no issue with nodes having several interfaces (ex. HNA in RFC3626 etc.). Emmanuel > > > Alex >> >> Emmanuel >>> On Mon, Feb 23, 2009 at 11:01 PM, Charles E. Perkins < >>> charles.perkins@earthlink.net > >>> wrote: >>> Hello Alex, >>> On this point I disagree. I think it is better to show the >>> routers with a single network interface -- which is what >>> they have in real life. This is also the reason that techniques >>> like split horizon aren't appropriate. >>> Regards, >>> Charlie P. >>> Alexandru Petrescu wrote: >>> Emmanuel, AUTOCONFers, >>> Just a short clarifying point: I think it would be clarifying to >>> illustrate the routers to have two interfaces. Routers with >>> only one >>> interface aren't very typical. >>> Just a note, >>> Alex >>> Emmanuel Baccelli a =E9crit : >>> Hi all, >>> following the fruitful discussions about initial version of >>> the document, here is an update to the draft describing >>> aspects of >>> multi-hop wireless communication: >>> http://www.ietf.org/internet-drafts/draft-baccelli- >>> multi-hop-wireless-communication-01.txt >>> Again, the goal of this document is to identify a consensus >>> about >>> this topic, and then use this to move on quicker with the >>> rest of the >>> work... >>> Please review it, and provide feedback as soon as possible. >>> Cheers >>> Emmanuel >>> >>> ----------------------------------------------------------------------= -- >>> _______________________________________________ Autoconf >>> mailing list >>> Autoconf@ietf.org >>> https://www.ietf.org/mailman/listinfo/autoconf >>> _______________________________________________ >>> Autoconf mailing list >>> Autoconf@ietf.org >>> https://www.ietf.org/mailman/listinfo/autoconf >>> -----------------------------------------------------------------------= - >>> _______________________________________________ >>> Autoconf mailing list >>> Autoconf@ietf.org >>> https://www.ietf.org/mailman/listinfo/autoconf >>> >> >> >> _______________________________________________ >> Autoconf mailing list >> Autoconf@ietf.org >> https://www.ietf.org/mailman/listinfo/autoconf >> > > --001636416899fbbe1d0463cde7bc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Wed, Feb 25, 2009 at 11:35 PM, Thomas= Heide Clausen <ietf@thomasclausen.org> wrote:

On Feb 25, 2009, at 17:06 PM, Alexandru Petrescu wrote:

Emmanuel Baccelli a =E9crit :
Alex, I think that what Charlie and Thomas want to say is basically:
- A router typically has several physical interfaces
- A router typically has just one MANET interface (although it may have sev= eral)
- A router may have just one physical interface (for instance its MANET int= erface)

Emmanuel, I agree with the first definition in the list. =A0I think it'= s probably the most widely accepted definition, among the three.

However, the draft pictures a router with only one interface, which is only= the third in the list.


I think that the point is that in a MANET as it is commonly deployed, one q= uite often find routers which have just one physical interface.

Thomas


... and if they have several interfaces= , they typically have just one interface of "type" MANET. This is= why it make sense to present a description of what's going on on MANET= s reduced to a MANET-centric view, where nodes typically have one (MANET) i= nterface. However, again, there is no issue with nodes having several inter= faces (ex. HNA in RFC3626 etc.).

Emmanuel

=A0


Alex

Emmanuel
On Mon, Feb 23, 2009 at 11:01 PM, Charles E. Perkins <charles.perkins@earthlink.= net <mailto:charles.perkins@earthlink.net>> wrote:
=A0 =A0Hello Alex,
=A0 =A0On this point I disagree. =A0I think it is better to show the
=A0 =A0routers with a single network interface -- which is what
=A0 =A0they have in real life. =A0This is also the reason that techniques<= br> =A0 =A0like split horizon aren't appropriate.
=A0 =A0Regards,
=A0 =A0Charlie P.
=A0 =A0Alexandru Petrescu wrote:
=A0 =A0 =A0 =A0Emmanuel, AUTOCONFers,
=A0 =A0 =A0 =A0Just a short clarifying point: I think it would be clarifyi= ng to
=A0 =A0 =A0 =A0illustrate the routers to have two interfaces. =A0Routers w= ith
=A0 =A0 =A0 =A0only one
=A0 =A0 =A0 =A0interface aren't very typical.
=A0 =A0 =A0 =A0Just a note,
=A0 =A0 =A0 =A0Alex
=A0 =A0 =A0 =A0Emmanuel Baccelli a =E9crit :
=A0 =A0 =A0 =A0 =A0 =A0Hi all,
=A0 =A0 =A0 =A0 =A0 =A0following the fruitful discussions about initial ve= rsion of
=A0 =A0 =A0 =A0 =A0 =A0the document, here is an update to the draft descri= bing
=A0 =A0 =A0 =A0 =A0 =A0aspects of
=A0 =A0 =A0 =A0 =A0 =A0multi-hop wireless communication:
=A0 =A0 =A0 =A0 =A0 =A0http://www.ietf.org/internet-drafts/draft-ba= ccelli-multi-hop-wireless-communication-01.txt
=A0 =A0 =A0 =A0 =A0 =A0Again, the goal of this document is to identify a c= onsensus
=A0 =A0 =A0 =A0 =A0 =A0about
=A0 =A0 =A0 =A0 =A0 =A0this topic, and then use this to move on quicker wi= th the
=A0 =A0 =A0 =A0 =A0 =A0rest of the
=A0 =A0 =A0 =A0 =A0 =A0work...
=A0 =A0 =A0 =A0 =A0 =A0Please review it, and provide feedback as soon as p= ossible.
=A0 =A0 =A0 =A0 =A0 =A0Cheers
=A0 =A0 =A0 =A0 =A0 =A0Emmanuel
=A0 =A0 =A0 =A0 =A0 =A0---------------------------------------------------= ---------------------
=A0 =A0 =A0 =A0 =A0 =A0_______________________________________________ Aut= oconf
=A0 =A0 =A0 =A0 =A0 =A0mailing list
=A0 =A0 =A0 =A0 =A0 =A0 Autoconf@ietf.org <mailto:Autoconf@ietf.org>
=A0 =A0 =A0 =A0 =A0 =A0https://www.ietf.org/mailman/listinfo/autoconf
=A0 =A0 =A0 =A0_______________________________________________
=A0 =A0 =A0 =A0Autoconf mailing list
=A0 =A0 =A0 =A0Auto= conf@ietf.org <mailto:Autoconf@ietf.org>
=A0 =A0 =A0 =A0https://www.ietf.org/mailman/listinfo/autoconf
------------------------------------------------------------------------ _______________________________________________
Autoconf mailing list
Autoconf@ietf.org
https://www.ietf.org/mailman/listinfo/autoconf


_______________________________________________
Autoconf mailing list
Autoconf@ietf.org
https://www.ietf.org/mailman/listinfo/autoconf


--001636416899fbbe1d0463cde7bc-- From alexandru.petrescu@gmail.com Thu Feb 26 09:40:51 2009 Return-Path: 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 F1D263A681D for ; Thu, 26 Feb 2009 09:40:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.179 X-Spam-Level: X-Spam-Status: No, score=-2.179 tagged_above=-999 required=5 tests=[AWL=0.070, 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 3oz0wq8BI38f for ; Thu, 26 Feb 2009 09:40:51 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.1]) by core3.amsl.com (Postfix) with ESMTP id EEB2A3A68C1 for ; Thu, 26 Feb 2009 09:40:50 -0800 (PST) Received: from nephilia.intra.cea.fr (nephilia.intra.cea.fr [132.166.88.33]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-1.2) with ESMTP id n1QHdQQK029876; Thu, 26 Feb 2009 18:39:26 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by nephilia.intra.cea.fr (8.13.8/8.13.8) with ESMTP id n1QHfApY015661; Thu, 26 Feb 2009 18:41:10 +0100 (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 n1QHfAfn012423; Thu, 26 Feb 2009 18:41:10 +0100 Message-ID: <49A6D436.7020505@gmail.com> Date: Thu, 26 Feb 2009 18:41:10 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Ryuji Wakikawa References: <499F0BA7.90501@piuha.net> <7E8A76F7-2CE0-463A-8EE8-8877C46B4715@gmail.com> In-Reply-To: <7E8A76F7-2CE0-463A-8EE8-8877C46B4715@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org Subject: Re: [Autoconf] new charter X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2009 17:40:52 -0000 Ryuji Wakikawa a écrit : [gracefully re-formatted] > Ad-Hoc Network Autoconfiguration (autoconf) > > Last Modified: 2009-02-18 > > Additional information is available at tools.ietf.org/wg/autoconf [snipped] > Description of Working Group: > > In order to communicate among themselves, ad hoc nodes (refer to RFC > 2501) need to configure their network interface(s) with local addresses > that are valid within an ad hoc network. Ad hoc nodes may also need to > configure globally routable addresses, in order to communicate with > devices on the Internet. From the IP layer perspective, an ad hoc > network presents itself as a L3 multi-hop network formed over a > collection of links. > > The main purpose of the AUTOCONF WG is to describe the addressing model > for ad hoc networks and how nodes in these networks configure their > addresses. It is required that such models do not cause problems for ad > hoc-unaware parts of the system, such as standard applications running > on an ad hoc node or regular Internet nodes attached to the ad hoc > nodes. This group's effort may include the development of new protocol > mechanisms, should the existing IP autoconfiguration mechanisms be found > inadequate. However, the first task of the working group is to describe > one practical addressing model for ad hoc networks. Would a straightforward addressing model along the following lines fit the bill?: ----- wifi "adhoc1" ------ wifi "adhoc2" ----- |Host1|---------------|Router|---------------|Host2| ----- LL1 LL2 ------ LL3 LL4 ----- G1 G4 "adhoc1" and "adhoc2": 802.11 ESSIDs in "ad-hoc" mode. Each is an IPv6 subnet. LL1...4: IPv6 link-local addresses. Self-formed according to rfc2464. G1, G4: IPv6 global addresses, for example 2001:db8::1/64 and 2001:db8::4/64. Manually assigned, or pre-configured with SNMP or according to stateless autoconf rfc4862. Alex From charles.perkins@earthlink.net Thu Feb 26 10:01:44 2009 Return-Path: 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 824133A6BD2 for ; Thu, 26 Feb 2009 10:01:44 -0800 (PST) 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=[AWL=0.000, 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 bjaDK5Y5lr1A for ; Thu, 26 Feb 2009 10:01:43 -0800 (PST) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by core3.amsl.com (Postfix) with ESMTP id 6EEA03A6BC4 for ; Thu, 26 Feb 2009 10:01:43 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=TFBGno68B2xz7iFGO7pIJ5r24bjghLVEtoT2aEYOZSF2lcAMwcL/NbJV3SqeYzpv; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [99.51.129.145] (helo=[10.166.254.136]) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1LckYc-0002sM-1S; Thu, 26 Feb 2009 13:02:02 -0500 Message-ID: <49A6D918.7060505@earthlink.net> Date: Thu, 26 Feb 2009 10:02:00 -0800 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Teco Boot References: <49A31B60.9050604@gmail.com> <49A31CD5.4090204@earthlink.net> <532BA0E9-FBFD-4022-88AF-BB0D5108FF4D@thomasclausen.org> <002c01c99722$3a526390$aef72ab0$@nl> In-Reply-To: <002c01c99722$3a526390$aef72ab0$@nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f526761694a95b540d832c725f255593c95350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.51.129.145 Cc: autoconf@ietf.org, 'Emmanuel Baccelli' Subject: Re: [Autoconf] updated draft on aspects of multi-hop wireless communication X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2009 18:01:44 -0000 Hello Teco, I don't think anyone answered all of your questions yet... Here are my answers for some of them. Teco Boot wrote: > Thanks for the updated draft. > Here some feedback: > > On exposed node: I do not understand what is mentioned here. I think the > exposed node problem is communication from A to B (correct) and C to D > (reverse direction of arrow). With CSMA, transmit from C is delayed because > C noticed carrier busy caused by transmit from A (or CSMA/CA virtual carrier > sense by CTS from B) . The delay was not needed, as C transmission does not > affect B reception of frame transmitted by A. > I think exposed node is more a research problem and less an operational > problem. > The picture as drawn is a correct representation of the exposed node problem. RtrC cannot receive packets from RtrD because it's getting interference from the transmissions sent by RtrA. So, the point about transmission from C is not relevant. > On Hidden Terminal: I think this __is__ an operational problem, but handled > in some or many cases by a media access mechanism, like CSMA/CA or TDMA. > Some / many cases implies "not all" cases, e.g. CSMA/CA does not work for > multicast. And multicast may be of large importance in MANETs, e.g. MANET > routing protocol flooding. > > I suggest swapping the two problems, mentioning the important one first. > I think that would be a good idea. > > The draft emphasizes problems introduced by limited radio range. Note that > it has also a welcome characteristic, that is spatial reuse. Be positive on > wireless communication one time ? :-) > O.K. We can mention that. But the point of the draft is not to be negative -- only to explicitly point out some of the well-known realities of radio transmissions. > > Once again, I think: > - We may say that router B is a neighbor of router A. In this > terminology, there is no guarantee that router A is a neighbor of > router B, even if router B a neighbor of router A. > is incorrect. B hears A and I would say A is a neighbor of A and A is listed > in B's neighbor table. > Is there a reason not to update the text, as we agreed on before? > I don't remember the previous discussion, but the fact that there is this disagreement illustrates the real need to identify some unambiguous and agreeable terminology for us to use during our discussions. So, if B hears A either (i) A is a neighbor of B (your interpretation), or (ii) B is a neighbor of A (what was in our draft). I'm happy to settle on either interpretation, but it would be nice if there were some consensus about it on the mailing list. I am assuming one of the two possible resolutions to the typo in your text. Maybe it is a moot point anyway because, if the link is sufficiently asymmetric, either: (a) A is a neighbor of B, but A doesn't know it -- or, (ii) B is a neighbor of A, but A doesn't know it. So for asymmetric links, the concept of "neighbor" is really confusing and maybe we should disqualify the use of that term unless the links are symmetric. Or, perhaps best, we should include some of these points directly in the text of the draft instead of just noting whatever emerges as consensus on the list. Regards, Charlie P. From charles.perkins@earthlink.net Thu Feb 26 10:10:12 2009 Return-Path: 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 CF44E3A69E2 for ; Thu, 26 Feb 2009 10:10:12 -0800 (PST) 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=[AWL=0.000, 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 9b3F1TKts+e6 for ; Thu, 26 Feb 2009 10:10:11 -0800 (PST) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by core3.amsl.com (Postfix) with ESMTP id C2EE93A67A7 for ; Thu, 26 Feb 2009 10:10:11 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=W0/r3n5pfaH0XwwPVJTaeKfjCwdShlBPqg/D1Y7GFTvMno5Qvp0vimHqvEn96B8A; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [99.51.129.145] (helo=[10.166.254.136]) by elasmtp-banded.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1Lckgq-0001vI-LE; Thu, 26 Feb 2009 13:10:32 -0500 Message-ID: <49A6DB17.8010709@earthlink.net> Date: Thu, 26 Feb 2009 10:10:31 -0800 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Rex Buddenberg References: <7BAC95F5A7E67643AAFB2C31BEE662D01489D135@SC-VEXCH2.marvell.com> <49A2E90E.10808@earthlink.net> <7BAC95F5A7E67643AAFB2C31BEE662D01489D24B@SC-VEXCH2.marvell.com> <49A431E9.3010401@earthlink.net> <49A44459.9020400@nps.navy.mil> <49A44958.4090300@earthlink.net> <49A46732.1050706@nps.navy.mil> In-Reply-To: <49A46732.1050706@nps.navy.mil> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f5244a8b7e5d096c2b85e9751ccd39f1751350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.51.129.145 Cc: "autoconf@ietf.org" , Emmanuel Baccelli Subject: Re: [Autoconf] updated draft on aspects of multi-hop wireless communication X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2009 18:10:12 -0000 Hello Rex, ... following up ... Rex Buddenberg wrote: > > I'm genuinely confused regarding just what the order of business needs > to be and what the document artifacts that result from that should be. I think that our small document on aspects of wireless communication is a good first step, and aims to be quite non-controversial. Even so, it appears to be controversial, which I take to be a pretty good indicator that it is needed, and needed immediately. > I've also been a much more intimate witness on how NOT to do such > things within DoD than I ever wanted to be. Are there, perhaps, some > parallels? > > How to get it backwards: > ... I'd be curious to find out if you really think these steps are representative of a way forward that starts with our small "aspects" contribution. > > Aside from the steps (e.g. #4) that are missing altogether, this is > exactly the reverse order of business! We can, and should, build the > reference model without reference to requirements. Is that were we > are agreeing or disagreeing? Or even on the same page? Yes, this is a good question, but I think the answer would have to come from you. Regards, Charlie P. > > > > > > > Charles E. Perkins wrote: >> >> Hello Rex, >> >> Thanks for the long email. I think that I do have a good handle on >> the various >> kinds of mobile communications scenarios as you have outlined below. >> >> You have raised the particular point that many nodes in an ad hoc >> network >> do not have to be routers. I certainly agree with this, and agree >> that any work >> in [autoconf] needs to be able to configure addresses for wireless >> nodes in >> an ad hoc network that are not routers. Perhaps Emmanuel and I could >> better >> emphasize this point in our draft, but even non-router nodes can be >> subject to >> the problems noted in that draft. So we have to find better language to >> identify the wireless nodes that would be affected other than just >> calling >> them "routers". >> >> However, I still maintain that this document under discussion is _not_ a >> requirements document, and that Paul seems to be discussing various >> requirements for ad hoc networks. Don't you agree that requirements >> should be located in a separate document? The only "requirement" that >> we have placed in our small document is a need to deal with reality. >> >> I'd also like to point out one somewhat unrelated point. It is >> agreed, of >> course, that MAC-layer problems can pre-empt the usefulness of >> routing protocols. However, routing protocols can themselves cause >> congestion, and any techniques that we can bring to bear that reduce >> congestion are likely to increase the overall effectiveness of the MAC >> layer protocols also. Furthermore, I think it is likely that people who >> do not have good understanding about the nature of the wireless >> medium are more likely to make design decisions for routing protocols >> that would increase congestion. >> >> What do you think? >> >> Regards, >> Charlie P. >> >> From teco@inf-net.nl Thu Feb 26 11:04:42 2009 Return-Path: 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 3EE4F3A6AC3 for ; Thu, 26 Feb 2009 11:04:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.663 X-Spam-Level: X-Spam-Status: No, score=-1.663 tagged_above=-999 required=5 tests=[AWL=0.383, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] 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 oW7Qr6nW7Eql for ; Thu, 26 Feb 2009 11:04:41 -0800 (PST) Received: from cpsmtpo-eml01.kpnxchange.com (cpsmtpo-eml01.KPNXCHANGE.COM [213.75.38.150]) by core3.amsl.com (Postfix) with ESMTP id 342DB3A6907 for ; Thu, 26 Feb 2009 11:04:40 -0800 (PST) Received: from cpsmtp-eml103.kpnxchange.com ([213.75.84.103]) by cpsmtpo-eml01.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 26 Feb 2009 20:04:58 +0100 Received: from M90Teco ([86.83.9.22]) by cpsmtp-eml103.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 26 Feb 2009 20:04:57 +0100 From: "Teco Boot" To: "'Alexandru Petrescu'" , "'Ryuji Wakikawa'" References: <499F0BA7.90501@piuha.net> <7E8A76F7-2CE0-463A-8EE8-8877C46B4715@gmail.com> <49A6D436.7020505@gmail.com> In-Reply-To: <49A6D436.7020505@gmail.com> Date: Thu, 26 Feb 2009 20:04:57 +0100 Message-ID: <000001c99845$1dc56190$595024b0$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcmYOXIB1YmiHDQaTMKZ3bLe+WwlMQACilZQ Content-Language: nl X-OriginalArrivalTime: 26 Feb 2009 19:04:57.0777 (UTC) FILETIME=[1DDA2210:01C99845] Cc: autoconf@ietf.org Subject: Re: [Autoconf] new charter X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2009 19:04:42 -0000 Inline: |-----Oorspronkelijk bericht----- |Van: autoconf-bounces@ietf.org [mailto:autoconf-bounces@ietf.org] = Namens |Alexandru Petrescu |Verzonden: donderdag 26 februari 2009 18:41 |Aan: Ryuji Wakikawa |CC: autoconf@ietf.org |Onderwerp: Re: [Autoconf] new charter | |Ryuji Wakikawa a =E9crit : |[gracefully re-formatted] |> Ad-Hoc Network Autoconfiguration (autoconf) |> |> Last Modified: 2009-02-18 |> |> Additional information is available at tools.ietf.org/wg/autoconf |[snipped] |> Description of Working Group: |> |> In order to communicate among themselves, ad hoc nodes (refer to RFC |> 2501) need to configure their network interface(s) with local |addresses |> that are valid within an ad hoc network. Ad hoc nodes may also need = to |> configure globally routable addresses, in order to communicate with |> devices on the Internet. From the IP layer perspective, an ad hoc |> network presents itself as a L3 multi-hop network formed over a |> collection of links. |> |> The main purpose of the AUTOCONF WG is to describe the addressing |model |> for ad hoc networks and how nodes in these networks configure their |> addresses. It is required that such models do not cause problems for |ad |> hoc-unaware parts of the system, such as standard applications = running |> on an ad hoc node or regular Internet nodes attached to the ad hoc |> nodes. This group's effort may include the development of new = protocol |> mechanisms, should the existing IP autoconfiguration mechanisms be |found |> inadequate. However, the first task of the working group is to |describe |> one practical addressing model for ad hoc networks. | |Would a straightforward addressing model along the following lines fit |the bill?: | | ----- wifi "adhoc1" ------ wifi "adhoc2" ----- | |Host1|---------------|Router|---------------|Host2| | ----- LL1 LL2 ------ LL3 LL4 ----- | G1 G4 | | | | "adhoc1" and "adhoc2": 802.11 ESSIDs in "ad-hoc" mode. | Each is an IPv6 subnet. | LL1...4: IPv6 link-local addresses. | Self-formed according to rfc2464. | G1, G4: IPv6 global addresses, for example | 2001:db8::1/64 and 2001:db8::4/64. | Manually assigned, or pre-configured with SNMP | or according to stateless autoconf rfc4862. I do not understand why the router doesn't advertize prefixes. If so, = the hosts can autoconfigure globally unique addresses, with distinct = prefixes. If not, and one configures globally unique addresses with same prefix on different segments, (s)he is fully responsible for what services are and = are not provided. I would never design such a network. So I would say: no. My 2ct, Teco |Alex | | |_______________________________________________ |Autoconf mailing list |Autoconf@ietf.org |https://www.ietf.org/mailman/listinfo/autoconf From alexandru.petrescu@gmail.com Thu Feb 26 11:44:48 2009 Return-Path: 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 E553E3A68AC for ; Thu, 26 Feb 2009 11:44:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.224 X-Spam-Level: X-Spam-Status: No, score=-2.224 tagged_above=-999 required=5 tests=[AWL=0.025, 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 E9CLR-uJCSsh for ; Thu, 26 Feb 2009 11:44:48 -0800 (PST) Received: from smtp4-g21.free.fr (smtp4-g21.free.fr [212.27.42.4]) by core3.amsl.com (Postfix) with ESMTP id C307D3A6784 for ; Thu, 26 Feb 2009 11:44:46 -0800 (PST) Received: from smtp4-g21.free.fr (localhost [127.0.0.1]) by smtp4-g21.free.fr (Postfix) with ESMTP id C3C794C81A4; Thu, 26 Feb 2009 20:45:03 +0100 (CET) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp4-g21.free.fr (Postfix) with ESMTP id 6CE174C81FF; Thu, 26 Feb 2009 20:45:00 +0100 (CET) Message-ID: <49A6F125.40400@gmail.com> Date: Thu, 26 Feb 2009 20:44:37 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Teco Boot References: <499F0BA7.90501@piuha.net> <7E8A76F7-2CE0-463A-8EE8-8877C46B4715@gmail.com> <49A6D436.7020505@gmail.com> <000001c99845$1dc56190$595024b0$@nl> In-Reply-To: <000001c99845$1dc56190$595024b0$@nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 090225-1, 25/02/2009), Outbound message X-Antivirus-Status: Clean Cc: autoconf@ietf.org Subject: Re: [Autoconf] new charter X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2009 19:44:49 -0000 Teco Boot a écrit : > Inline: > > |-----Oorspronkelijk bericht----- > |Van: autoconf-bounces@ietf.org [mailto:autoconf-bounces@ietf.org] Namens > |Alexandru Petrescu > |Verzonden: donderdag 26 februari 2009 18:41 > |Aan: Ryuji Wakikawa > |CC: autoconf@ietf.org > |Onderwerp: Re: [Autoconf] new charter > | > |Ryuji Wakikawa a écrit : > |[gracefully re-formatted] > |> Ad-Hoc Network Autoconfiguration (autoconf) > |> > |> Last Modified: 2009-02-18 > |> > |> Additional information is available at tools.ietf.org/wg/autoconf > |[snipped] > |> Description of Working Group: > |> > |> In order to communicate among themselves, ad hoc nodes (refer to RFC > |> 2501) need to configure their network interface(s) with local > |addresses > |> that are valid within an ad hoc network. Ad hoc nodes may also need to > |> configure globally routable addresses, in order to communicate with > |> devices on the Internet. From the IP layer perspective, an ad hoc > |> network presents itself as a L3 multi-hop network formed over a > |> collection of links. > |> > |> The main purpose of the AUTOCONF WG is to describe the addressing > |model > |> for ad hoc networks and how nodes in these networks configure their > |> addresses. It is required that such models do not cause problems for > |ad > |> hoc-unaware parts of the system, such as standard applications running > |> on an ad hoc node or regular Internet nodes attached to the ad hoc > |> nodes. This group's effort may include the development of new protocol > |> mechanisms, should the existing IP autoconfiguration mechanisms be > |found > |> inadequate. However, the first task of the working group is to > |describe > |> one practical addressing model for ad hoc networks. > | > |Would a straightforward addressing model along the following lines fit > |the bill?: > | > | ----- wifi "adhoc1" ------ wifi "adhoc2" ----- > | |Host1|---------------|Router|---------------|Host2| > | ----- LL1 LL2 ------ LL3 LL4 ----- > | G1 G4 > | > | > | > | "adhoc1" and "adhoc2": 802.11 ESSIDs in "ad-hoc" mode. > | Each is an IPv6 subnet. > | LL1...4: IPv6 link-local addresses. > | Self-formed according to rfc2464. > | G1, G4: IPv6 global addresses, for example > | 2001:db8::1/64 and 2001:db8::4/64. > | Manually assigned, or pre-configured with SNMP > | or according to stateless autoconf rfc4862. > > I do not understand why the router doesn't advertize prefixes. If so, the > hosts can autoconfigure globally unique addresses, with distinct prefixes. Sorry, I made an error indeed putting same prefix. How about this updated picture with the prefixes being distinct: ----- wifi "adhoc1" ------ wifi "adhoc2" ----- |Host1|---------------|Router|---------------|Host2| ----- LL1 LL2 ------ LL3 LL4 ----- G1 G4 "adhoc1" and "adhoc2": 802.11 ESSIDs in "ad-hoc" mode. Each is an IPv6 subnet. LL1...4: IPv6 link-local addresses. Self-formed according to rfc2464. G1, G4: IPv6 global addresses, for example 2001:db8:1::1/64 and 2001:db8:2::4/64 Manually assigned, or pre-configured with SNMP or formed according to stateless autoconf rfc4862; the prefixes are advertised by Router in RAs. > If not, and one configures globally unique addresses with same prefix on > different segments, (s)he is fully responsible for what services are and are > not provided. I would never design such a network. I agree. Alex > So I would say: no. > > My 2ct, Teco > > > > |Alex > | > | > |_______________________________________________ > |Autoconf mailing list > |Autoconf@ietf.org > |https://www.ietf.org/mailman/listinfo/autoconf > > From charles.perkins@earthlink.net Thu Feb 26 11:58:14 2009 Return-Path: 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 C2B543A6818 for ; Thu, 26 Feb 2009 11:58:14 -0800 (PST) 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 bRVgddgSrSiC for ; Thu, 26 Feb 2009 11:58:13 -0800 (PST) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by core3.amsl.com (Postfix) with ESMTP id 6AB4E28C2E6 for ; Thu, 26 Feb 2009 11:58:12 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=sAOy6fKMr4uPNCSGAHgkx34qNEtu7m2hHI0etuiweTssI3/fBVpbJRvbt1kukenU; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [99.51.129.145] (helo=[10.166.254.136]) by elasmtp-banded.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1LcmNN-0003fw-Eu for autoconf@ietf.org; Thu, 26 Feb 2009 14:58:34 -0500 Message-ID: <49A6F464.4060402@earthlink.net> Date: Thu, 26 Feb 2009 11:58:28 -0800 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: autoconf@ietf.org References: <499F0BA7.90501@piuha.net> In-Reply-To: <499F0BA7.90501@piuha.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f52b78610b3904e44accd98cb8c73fd78ea350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.51.129.145 Subject: Re: [Autoconf] new charter X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2009 19:58:14 -0000 Hello folks, I have issues with the proposed charter. Jari Arkko wrote: > > In order to communicate among themselves, ad hoc nodes (refer to RFC > 2501) need to configure their network interface(s) with local > addresses that are valid within an ad hoc network. Dymo and AODV allow a node with a global address to work in an ad-hoc network without configuing any local address. I think this is an important feature to maintain. Of course, such nodes wouldo not _necessarily_ have to initiate address configuration protocols as will be specified within [autoconf]. > The main purpose of the AUTOCONF WG is to describe the addressing > model for ad hoc networks and how nodes in these networks configure > their addresses. I would say the main purpose of [autoconf] is to _specify_ how nodes in such networks configure their addresses. Describing the addressing model is simply a crucial step along the way, but it ought to be very simple to do once we get past these initial conceptual roadblocks. > > Apr 2009 Submit initial draft on address configuration in ad hoc networks > Sep 2009 Submit address configuration draft to IESG as Informational > or close WG This doesn't have any deliverable for the autoconfiguration protocol. As such, it seems to me to be overly pessimistic about the ability of the group to make progress. Perhaps it is felt that pessimism is justified by various cyclical processes that have consumed the energy of the group over the last three years. I'd recommend a more constructive outlook, which in itself would motivate stronger contributions from the members of the team. Otherwise, the working group devolves into some exercise in (perhaps useful) abstraction. Imagine what would have happened if [ipv6] were initially chartered only to develop an addressing model! Regards, Charlie P. From teco@inf-net.nl Thu Feb 26 12:22:35 2009 Return-Path: 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 265B328C286 for ; Thu, 26 Feb 2009 12:22:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.717 X-Spam-Level: X-Spam-Status: No, score=-1.717 tagged_above=-999 required=5 tests=[AWL=0.328, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 n1YfrqXjvB4A for ; Thu, 26 Feb 2009 12:22:24 -0800 (PST) Received: from hpsmtp-eml18.kpnxchange.com (hpsmtp-eml18.KPNXCHANGE.COM [213.75.38.118]) by core3.amsl.com (Postfix) with ESMTP id ECDEA28C2CF for ; Thu, 26 Feb 2009 12:22:23 -0800 (PST) Received: from cpsmtp-eml101.kpnxchange.com ([213.75.84.101]) by hpsmtp-eml18.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 26 Feb 2009 21:22:44 +0100 Received: from M90Teco ([86.83.9.22]) by cpsmtp-eml101.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 26 Feb 2009 21:22:42 +0100 From: "Teco Boot" To: "'Emmanuel Baccelli'" References: <002d01c99722$dcf7f650$96e7e2f0$@nl> <002e01c99729$bc956350$35c029f0$@nl> <009c01c99764$7914a650$6b3df2f0$@nl> In-Reply-To: Date: Thu, 26 Feb 2009 21:22:42 +0100 Message-ID: <000701c9984f$fad34d40$f079e7c0$@nl> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0008_01C99858.5C97B540" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcmX7sRpjgJQ89u/QEyzb/Rn1nLANwAWjsmg Content-Language: nl X-OriginalArrivalTime: 26 Feb 2009 20:22:43.0440 (UTC) FILETIME=[FACDCF00:01C9984F] Cc: autoconf@ietf.org Subject: Re: [Autoconf] updated draft on aspects of multi-hop wireless communication X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2009 20:22:35 -0000 Dit is een meerdelig bericht met een MIME-indeling. ------=_NextPart_000_0008_01C99858.5C97B540 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Emmanuel, inline Van: emmanuel.baccelli@gmail.com [mailto:emmanuel.baccelli@gmail.com] Namens Emmanuel Baccelli Verzonden: donderdag 26 februari 2009 9:47 Aan: Teco Boot Onderwerp: Re: [Autoconf] updated draft on aspects of multi-hop wireless communication Hi Teco, thanks for your feedback, please see inline. On Wed, Feb 25, 2009 at 5:16 PM, Teco Boot wrote: Inline. Van: autoconf-bounces@ietf.org [mailto: autoconf-bounces@ietf.org] Namens Emmanuel Baccelli Verzonden: woensdag 25 februari 2009 16:45 Aan: autoconf@ietf.org Onderwerp: Re: [Autoconf] updated draft on aspects of multi-hop wireless communication Hi Teco, inline On Wed, Feb 25, 2009 at 10:16 AM, Teco Boot wrote: Thanks for the updated draft. Here some feedback: On exposed node: I do not understand what is mentioned here. I think the exposed node problem is communication from A to B (correct) and C to D (reverse direction of arrow). With CSMA, transmit from C is delayed because C noticed carrier busy caused by transmit from A (or CSMA/CA virtual carrier sense by CTS from B) . The delay was not needed, as C transmission does not affect B reception of frame transmitted by A. I think exposed node is more a research problem and less an operational problem. I agree, but it may become more operational as multi-hop ad hoc networks are more widely deployed. What do you think about this description of the exposed node issues on wikipedia? http://en.wikipedia.org/wiki/Exposed_terminal_problem OK, this ref depicts the arrow in the right direction. As for the use of CSMA/CA to cope with this, see my comment below. On Hidden Terminal: I think this __is__ an operational problem, but handled in some or many cases by a media access mechanism, like CSMA/CA or TDMA. Some / many cases implies "not all" cases, e.g. CSMA/CA does not work for multicast. And multicast may be of large importance in MANETs, e.g. MANET routing protocol flooding. Yes you are right, most of the time, L2 will cope with these issues. However, as you mention, not all the time, even with L2 technology that is aware. For example because of multicast/broadcast, or because of non-synchronization (common in multi-hop ad hoc networks). Maybe one would say some L2 technology solves this completely, e.g. fixed slot TDMA. Maybe not really ad hoc and limited scalability, but no hidden terminal probem here J OK. Note however that for TDMA you need synchronization. It's not so common in the decentralized, multi-hop environments we are addressing in the draft. But I agree, we could say something like "some popular L2 technologies have these aspects/issues, so we need to take that into account at L3". Teco: Let's specify the L2 technology, to circumvent confusion. CSMA/CA (e.g WLAN with RTS-CTS enabled) unicast traffic and TDMA does not have a hidden terminal problem. Plain CSMA, also being used by broadcast and multicast in a CSMA/CA network has the hidden terminal problem. Different people may have different opinions on "popular L2 technology". In any case, maybe we should make clearer that this radio range limitation aspect in multi-hop ad hoc networks causes some problems that force L2 to use specific mechanisms (you cite CSMA/CA). Similarly it is causing some of the problems described in Section 3 (and to some extent Section 4) at L3, which have to be taken into account when designing L3 protocols that can support such networks. For the hidden terminal problem: I agree that this L2 problem affects L3. For exposed node, I don't see this effect. Can you explain a little more, why? As far as I can see, we potentially get the same result: radio signal collision/retransmission. As explained in http://en.wikipedia.org/wiki/Exposed_terminal_problem Teco: Maybe I have another wiki page as you have. Can you provide text from wiki with the terms "collision" or "retransmission"? My page mentions only "prevented from sending", i.e. delay. if the nodes are not synchronised the problem may occur that the sender will not hear the CTS or the ACK during the transmission of data of the second sender. Teco: This text is on the wiki page I see. It is a special case, where the exposed terminal problem is not solved. It is not a collision or whatsoever. By the way, I wonder if 802.11 really circumvents the Exposed Node problem. See http://wifi.cs.st-andrews.ac.uk/wifiexposednode.html for a more detailed explanation. Anyways, I agree that it is not the main issue for L3, but again, it is noteworthy, as an illustration of issues that come from the fact that radio ranges are limited, and overlapping, a fact that must be taken into account at L3 in the context of networks such as described in this draft. Teco: After having consensus on what the Exposed Node problem is, we can decide on removing it from the text. I would say: remove, as the Exposed Node problem does not affect L3. [skipped some text] The draft emphasizes problems introduced by limited radio range. Note that it has also a welcome characteristic, that is spatial reuse. Be positive on wireless communication one time ? :-) Once again, I think: - We may say that router B is a neighbor of router A. In this terminology, there is no guarantee that router A is a neighbor of router B, even if router B a neighbor of router A. is incorrect. B hears A and I would say A is a neighbor of A and A is listed in B's neighbor table. Is there a reason not to update the text, as we agreed on before? I don't follow you here, maybe I misunderstood. If B is a neighbor of A, it means that A hears B, and B is thus in A's routing table. It does not necessarily mean that B hears A too, or that A is in B's routing table, hence it does not mean that A is a neighbor of B too? B is member of set S and can hear A. B will store the received info in the neighbor table. So from the viewpoint of B, A is a neighbor. This is still confusing for me, but I guess this is just a matter of wording. The essential message here is: B=>A does not imply A=>B, whatever words you want to express the arrow with. Teco: The scenario in the draft is: B hears A. Let us use this scenario. OK? In the draft, which is coherent as far as I can see, we know a priori that B is a neighbor of A. Teco: Who is "we"? God only knows. We imply from this that B is in S(A), so that A hears B. And we can't imply from this that B hears A. Teco: Now you are confusing me. What scenario do you have in mind? B is in set S and can hear A (your draft) or otherwise (above text)? If you want translate the arrows in the reverse with the same vocabulary there is no problem, but I don't see the point really, because it is correct as is. Teco: As replied to Charlie, I prefer the option that corresponds with what routers tell you and not what God only knows. [skipped text] Regards, Teco ------=_NextPart_000_0008_01C99858.5C97B540 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Emmanuel,  inline

 

Van:<= /b> emmanuel.baccelli@gmail.com [mailto:emmanuel.baccelli@gmail.com] = Namens Emmanuel Baccelli
Verzonden: donderdag 26 februari 2009 9:47
Aan: Teco Boot
Onderwerp: Re: [Autoconf] updated draft on aspects of multi-hop = wireless communication

 

Hi Teco, thanks for your feedback, please see = inline.

 

 

On Wed, Feb 25, 2009 at 5:16 PM, Teco Boot <teco@inf-net.nl> = wrote:

Inline.

Van: autoconf-bounces@ietf.org [mailto:autoconf-bounces@ietf.org] Namens Emmanuel Baccelli
Verzonden: woensdag 25 februari 2009 16:45
Aan: autoconf@ietf.org
Onderwerp: Re: [Autoconf] updated draft on aspects of multi-hop = wireless communication

Hi Teco, inline

On Wed, Feb 25, 2009 at 10:16 AM, Teco Boot <teco@inf-net.nl> wrote:

Thanks for the updated draft.
Here some feedback:

On exposed node: I do not understand what is mentioned here. I think = the
exposed node problem is communication from A to B (correct) and C to = D
(reverse direction of arrow). With CSMA, transmit from C is delayed = because
C noticed carrier busy caused by transmit from A (or CSMA/CA virtual = carrier
sense by CTS from B) . The delay was not needed, as C transmission does = not
affect B reception of frame transmitted by A.
I think exposed node is more a research problem and less an = operational
problem.

I agree, but it may become more operational as multi-hop ad hoc = networks are more widely deployed. What do you think about this description of the = exposed node issues on wikipedia? http://en.wikipedia.org/wiki/Exposed_terminal_problem 

OK, this ref depicts = the arrow in the right direction.

As for the use of CSMA/CA to cope with this, see my comment = below. 

 

=


On Hidden Terminal: I think this __is__ an operational problem, but = handled
in some or many cases by a media access mechanism, like CSMA/CA or = TDMA.
Some / many cases implies "not all" cases, e.g. CSMA/CA does = not work for
multicast. And multicast may be of large importance in MANETs, e.g. = MANET
routing protocol flooding.

Yes you are right, most of the time, L2 will cope with these issues. However, as you mention, not all the time, even with L2 technology = that is aware. For example because of multicast/broadcast, or because of non-synchronization (common in multi-hop ad hoc = networks).

Maybe one would say = some L2 technology solves this completely, e.g. fixed slot TDMA. Maybe not = really ad hoc and limited scalability, but no hidden terminal probem here = J

OK. Note however that for TDMA you need = synchronization. It's not so common in the decentralized, multi-hop environments we are addressing in the draft. But I agree, we could say something = like "some popular L2 technologies have these aspects/issues, so we need to take that into account at = L3".

 

Teco:

Let’s specify the L2 technology, to circumvent = confusion.

CSMA/CA (e.g WLAN with RTS-CTS enabled) unicast traffic = and TDMA does not have a hidden terminal problem.

Plain CSMA, also being used by broadcast and multicast in = a CSMA/CA network has the hidden terminal problem.

Different people may have different opinions on = “popular L2 technology”.

 

In any case, maybe we should make clearer that this radio range = limitation aspect in multi-hop ad hoc networks causes some problems that force L2 = to use specific mechanisms (you cite CSMA/CA). Similarly it is causing some of = the problems described in Section 3 (and to some extent Section 4) at L3, = which have to be taken into account when designing L3 protocols that can = support such networks.

For the hidden = terminal problem: I agree that this L2 problem affects L3.

For exposed node, I = don’t see this effect. 

 

 

if the nodes are not synchronised the problem may = occur that the sender will not hear the CTS or the ACK during the transmission of = data of the second sender. 

Anyways, I agree that it is not the main issue for = L3, but again, it is noteworthy, as an illustration of issues that come from the = fact that radio ranges are limited, and overlapping, a fact that must be = taken into account at L3 in the context of networks such as described in this = draft.

 

Teco:

After having consensus on what the Exposed Node problem = is, we can decide on removing it from the text.

I would say: remove, as the Exposed Node problem does not = affect L3.

 

 

[skipped some text]

=



The draft emphasizes problems introduced by limited radio range. Note = that
it has also a welcome characteristic, that is spatial reuse. Be positive = on
wireless communication one time ? :-)


Once again, I think:
 - We may say that router B is a neighbor of router A. In this
 terminology, there is no guarantee that router A is a neighbor = of
 router B, even if router B a neighbor of router A.
is incorrect. B hears A and I would say A is a neighbor of A and A is = listed
in B's neighbor table.
Is there a reason not to update the text, as we agreed on = before?

 

 

I don't follow you here, maybe I misunderstood. If B is a neighbor of = A, it means that A hears B, and B is thus in A's routing table. It does not necessarily mean that B hears A too, or that A is in B's routing table, = hence it does not mean that A is a neighbor of B too?

 

B is member of set S = and can hear A.

B will store the = received info in the neighbor table.

So from the viewpoint = of B, A is a neighbor.

 

 

This is still confusing for me, but I guess this is = just a matter of wording. The essential message here is:

B=3D>A does not imply A=3D>B, whatever words = you want to express the arrow with.

 

Teco:

The scenario in the draft is: B hears A. Let us use this scenario. OK?

 

In the draft, which is coherent as far as I can = see, we know a priori that B is a neighbor of A. 

 

Teco:

Who is “we”? God only = knows…

 

We imply from this that B is in S(A), so that A = hears B. And we can't imply from this that B hears A.

 

Teco:

Now you are confusing me. What scenario do you have in = mind? B is in set S and can hear A (your draft) or otherwise (above text)? =  

 

If you want translate the arrows in the reverse = with the same vocabulary there is no problem, but I don't see the point really, = because it is correct as is.

 

Teco:

As replied to Charlie, I prefer the option that = corresponds with what routers tell you and not what God only knows.

 

 

 

[skipped text]

 

 

Regards, Teco

 

------=_NextPart_000_0008_01C99858.5C97B540-- From teco@inf-net.nl Thu Feb 26 12:25:10 2009 Return-Path: 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 C644C3A6879 for ; Thu, 26 Feb 2009 12:25:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.758 X-Spam-Level: X-Spam-Status: No, score=-1.758 tagged_above=-999 required=5 tests=[AWL=0.288, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] 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 4+BmXzc-yw6T for ; Thu, 26 Feb 2009 12:25:09 -0800 (PST) Received: from cpsmtpo-eml02.kpnxchange.com (cpsmtpo-eml02.KPNXCHANGE.COM [213.75.38.151]) by core3.amsl.com (Postfix) with ESMTP id 61C933A6784 for ; Thu, 26 Feb 2009 12:25:08 -0800 (PST) Received: from cpsmtp-eml101.kpnxchange.com ([213.75.84.101]) by cpsmtpo-eml02.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 26 Feb 2009 21:25:30 +0100 Received: from M90Teco ([86.83.9.22]) by cpsmtp-eml101.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 26 Feb 2009 21:25:29 +0100 From: "Teco Boot" To: "'Alexandru Petrescu'" References: <499F0BA7.90501@piuha.net> <7E8A76F7-2CE0-463A-8EE8-8877C46B4715@gmail.com> <49A6D436.7020505@gmail.com> <000001c99845$1dc56190$595024b0$@nl> <49A6F125.40400@gmail.com> In-Reply-To: <49A6F125.40400@gmail.com> Date: Thu, 26 Feb 2009 21:25:29 +0100 Message-ID: <000c01c99850$5dd31510$19793f30$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcmYSr1vzCd8D66JRfKNQh+ekStmoAABXh+A Content-Language: nl X-OriginalArrivalTime: 26 Feb 2009 20:25:29.0523 (UTC) FILETIME=[5DCC1030:01C99850] Cc: autoconf@ietf.org Subject: Re: [Autoconf] new charter X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2009 20:25:10 -0000 Now I think the addressing fits an acceptable model. Teco |-----Oorspronkelijk bericht----- |Van: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] |Verzonden: donderdag 26 februari 2009 20:45 |Aan: Teco Boot |CC: 'Ryuji Wakikawa'; autoconf@ietf.org |Onderwerp: Re: [Autoconf] new charter | |Teco Boot a =E9crit : |> Inline: |> |> |-----Oorspronkelijk bericht----- |> |Van: autoconf-bounces@ietf.org [mailto:autoconf-bounces@ietf.org] |Namens |> |Alexandru Petrescu |> |Verzonden: donderdag 26 februari 2009 18:41 |> |Aan: Ryuji Wakikawa |> |CC: autoconf@ietf.org |> |Onderwerp: Re: [Autoconf] new charter |> | |> |Ryuji Wakikawa a =E9crit : |> |[gracefully re-formatted] |> |> Ad-Hoc Network Autoconfiguration (autoconf) |> |> |> |> Last Modified: 2009-02-18 |> |> |> |> Additional information is available at tools.ietf.org/wg/autoconf |> |[snipped] |> |> Description of Working Group: |> |> |> |> In order to communicate among themselves, ad hoc nodes (refer to |RFC |> |> 2501) need to configure their network interface(s) with local |> |addresses |> |> that are valid within an ad hoc network. Ad hoc nodes may also = need |to |> |> configure globally routable addresses, in order to communicate = with |> |> devices on the Internet. From the IP layer perspective, an ad hoc |> |> network presents itself as a L3 multi-hop network formed over a |> |> collection of links. |> |> |> |> The main purpose of the AUTOCONF WG is to describe the addressing |> |model |> |> for ad hoc networks and how nodes in these networks configure = their |> |> addresses. It is required that such models do not cause problems |for |> |ad |> |> hoc-unaware parts of the system, such as standard applications |running |> |> on an ad hoc node or regular Internet nodes attached to the ad hoc |> |> nodes. This group's effort may include the development of new |protocol |> |> mechanisms, should the existing IP autoconfiguration mechanisms be |> |found |> |> inadequate. However, the first task of the working group is to |> |describe |> |> one practical addressing model for ad hoc networks. |> | |> |Would a straightforward addressing model along the following lines |fit |> |the bill?: |> | |> | ----- wifi "adhoc1" ------ wifi "adhoc2" ----- |> | |Host1|---------------|Router|---------------|Host2| |> | ----- LL1 LL2 ------ LL3 LL4 ----- |> | G1 G4 |> | |> | |> | |> | "adhoc1" and "adhoc2": 802.11 ESSIDs in "ad-hoc" mode. |> | Each is an IPv6 subnet. |> | LL1...4: IPv6 link-local addresses. |> | Self-formed according to rfc2464. |> | G1, G4: IPv6 global addresses, for example |> | 2001:db8::1/64 and 2001:db8::4/64. |> | Manually assigned, or pre-configured with SNMP |> | or according to stateless autoconf rfc4862. |> |> I do not understand why the router doesn't advertize prefixes. If so, |the |> hosts can autoconfigure globally unique addresses, with distinct |prefixes. | |Sorry, I made an error indeed putting same prefix. How about this |updated picture with the prefixes being distinct: | | | ----- wifi "adhoc1" ------ wifi "adhoc2" ----- | |Host1|---------------|Router|---------------|Host2| | ----- LL1 LL2 ------ LL3 LL4 ----- | G1 G4 | | | "adhoc1" and "adhoc2": 802.11 ESSIDs in "ad-hoc" mode. | Each is an IPv6 subnet. | LL1...4: IPv6 link-local addresses. | Self-formed according to rfc2464. | G1, G4: IPv6 global addresses, for example | 2001:db8:1::1/64 and | 2001:db8:2::4/64 | Manually assigned, or pre-configured with SNMP | or formed according to stateless autoconf rfc4862; | the prefixes are advertised by Router in RAs. | |> If not, and one configures globally unique addresses with same prefix |on |> different segments, (s)he is fully responsible for what services are |and are |> not provided. I would never design such a network. | |I agree. | |Alex | |> So I would say: no. |> |> My 2ct, Teco |> |> |> |> |Alex |> | |> | |> |_______________________________________________ |> |Autoconf mailing list |> |Autoconf@ietf.org |> |https://www.ietf.org/mailman/listinfo/autoconf |> |> From cjbc@it.uc3m.es Thu Feb 26 12:41:22 2009 Return-Path: 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 87A0C3A6879 for ; Thu, 26 Feb 2009 12:41:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.699 X-Spam-Level: X-Spam-Status: No, score=-5.699 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] 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 EzcFVW0bVVxs for ; Thu, 26 Feb 2009 12:41:15 -0800 (PST) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 3FF823A680E for ; Thu, 26 Feb 2009 12:41:14 -0800 (PST) Received: from [192.168.0.12] (82.159.31.227.dyn.user.ono.com [82.159.31.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp01.uc3m.es (Postfix) with ESMTP id E860FBA3D15; Thu, 26 Feb 2009 21:41:34 +0100 (CET) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Alexandru Petrescu In-Reply-To: <49A6F125.40400@gmail.com> References: <499F0BA7.90501@piuha.net> <7E8A76F7-2CE0-463A-8EE8-8877C46B4715@gmail.com> <49A6D436.7020505@gmail.com> <000001c99845$1dc56190$595024b0$@nl> <49A6F125.40400@gmail.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-R/WxRD+hRqi8jGBWIS5P" Organization: Universidad Carlos III de Madrid Date: Thu, 26 Feb 2009 21:41:27 +0100 Message-Id: <1235680887.4585.5.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16488.001 Cc: autoconf@ietf.org Subject: Re: [Autoconf] new charter X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2009 20:41:22 -0000 --=-R/WxRD+hRqi8jGBWIS5P Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Hi Alex: One question below. El jue, 26-02-2009 a las 20:44 +0100, Alexandru Petrescu escribi=F3: > Sorry, I made an error indeed putting same prefix. How about this=20 > updated picture with the prefixes being distinct: >=20 >=20 > ----- wifi "adhoc1" ------ wifi "adhoc2" ----- > |Host1|---------------|Router|---------------|Host2| > ----- LL1 LL2 ------ LL3 LL4 ----- > G1 G4 >=20 >=20 > "adhoc1" and "adhoc2": 802.11 ESSIDs in "ad-hoc" mode. > Each is an IPv6 subnet. > LL1...4: IPv6 link-local addresses. > Self-formed according to rfc2464. > G1, G4: IPv6 global addresses, for example > 2001:db8:1::1/64 and > 2001:db8:2::4/64 > Manually assigned, or pre-configured with SNMP > or formed according to stateless autoconf rfc4862; > the prefixes are advertised by Router in RAs. >=20 Does this model only apply to Host-Router-Host scenarios? I mean, does this model apply for Router-Router-Router scenarios? I fully agree the model fits the first scenario, but I don't for the second, since routers' mobility within the ad-hoc network would force them to change prefixes often, I guess. For those scenarios it might be better to think of addressing models in which MANET routers are configured with /128 (or /32 for IPv4) addresses, so they don't need to change their addresses as a result of link changes. Kind Regards, Carlos --=20 Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ WEEDEV 2009: 2nd Workshop on Experimental Evaluation and Deployment Experiences on Vehicular networks http://www.weedev.org/ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ --=-R/WxRD+hRqi8jGBWIS5P Content-Type: application/pgp-signature; name=signature.asc Content-Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEABECAAYFAkmm/nAACgkQNdy6TdFwT2cHRwCeJBrE8+EI9e1V1dprOS4pbZ5e xcsAoOKFbAs+xHE8FiY2B7yo4yrx9t0u =uwh5 -----END PGP SIGNATURE----- --=-R/WxRD+hRqi8jGBWIS5P-- From dream.hjlim@gmail.com Thu Feb 26 17:36:59 2009 Return-Path: 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 BB3EC28C195 for ; Thu, 26 Feb 2009 17:36:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6] 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 cCxThVt9e3gQ for ; Thu, 26 Feb 2009 17:36:58 -0800 (PST) Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.184]) by core3.amsl.com (Postfix) with ESMTP id 322293A67B4 for ; Thu, 26 Feb 2009 17:36:55 -0800 (PST) Received: by ti-out-0910.google.com with SMTP id 11so1041688tim.25 for ; Thu, 26 Feb 2009 17:37:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=00d90+nmsfcH3hnj5854EwZi/OJpa3wW+HcW/+2IyyY=; b=ZjeWbrAlO9QI30pFB3ZTyamuIi2SnntvtoEPC36Qp1GWaVdtRHRx6wPd6CFrtMayZs PxZU2X7F33pszlvFFjL0qxCdOygpPdLOuufNRSFcToCW1fXLeRd/JoBfjqIIxlGDA+vP lgoHyHYxK4wtMculo9P1pP1dXne1WN6LX5BJM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=HQFueTZ10Bv82ekeafDs2hCcsHCzbV2iTVCSa5/jdDEHIXFl8zAHd6AYBUv22Fcr57 hOB049OOCT2e0QfN3kk5U8YwRSpOgi1RYEugcvn9sUy1/dz/FR85vkxOjafAGha51MNc tnvR6S0odr0ws/N29Q4fiH+ckjnCEjQseBS/w= MIME-Version: 1.0 Received: by 10.110.14.12 with SMTP id 12mr2796436tin.22.1235698636356; Thu, 26 Feb 2009 17:37:16 -0800 (PST) In-Reply-To: <1235680887.4585.5.camel@localhost> References: <499F0BA7.90501@piuha.net> <7E8A76F7-2CE0-463A-8EE8-8877C46B4715@gmail.com> <49A6D436.7020505@gmail.com> <000001c99845$1dc56190$595024b0$@nl> <49A6F125.40400@gmail.com> <1235680887.4585.5.camel@localhost> Date: Fri, 27 Feb 2009 10:37:16 +0900 Message-ID: <7e8d02d40902261737n1c21b136hd575b8afa8702188@mail.gmail.com> From: HyungJin Lim To: cjbc@it.uc3m.es Content-Type: multipart/alternative; boundary=0016e652ff9a44fd8e0463dc82c2 Cc: Autoconf@ietf.org Subject: Re: [Autoconf] new charter X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 01:36:59 -0000 --0016e652ff9a44fd8e0463dc82c2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Carlos, This is Hyung-Jin, Lim I have a question. See the inline.... 2009/2/27 Carlos Jes=FAs Bernardos Cano > Hi Alex: > > One question below. > > El jue, 26-02-2009 a las 20:44 +0100, Alexandru Petrescu escribi=F3: > > Sorry, I made an error indeed putting same prefix. How about this > > updated picture with the prefixes being distinct: > > > > > > ----- wifi "adhoc1" ------ wifi "adhoc2" ----- > > |Host1|---------------|Router|---------------|Host2| > > ----- LL1 LL2 ------ LL3 LL4 ----- > > G1 G4 > > > > > > "adhoc1" and "adhoc2": 802.11 ESSIDs in "ad-hoc" mode. > > Each is an IPv6 subnet. > > LL1...4: IPv6 link-local addresses. > > Self-formed according to rfc2464. > > G1, G4: IPv6 global addresses, for example > > 2001:db8:1::1/64 and > > 2001:db8:2::4/64 > > Manually assigned, or pre-configured with SNMP > > or formed according to stateless autoconf rfc4862; > > the prefixes are advertised by Router in RAs. > > > > Does this model only apply to Host-Router-Host scenarios? I mean, does > this model apply for Router-Router-Router scenarios? I fully agree the > model fits the first scenario, but I don't for the second, since > routers' mobility within the ad-hoc network would force them to change > prefixes often, I guess. For those scenarios it might be better to think > of addressing models in which MANET routers are configured with /128 > (or /32 for IPv4) addresses, so they don't need to change their > addresses as a result of link changes. > Does AUTOCONF not consider "ad-hoc network to Internet" scenario ? If so, I agree your comment. But if not, your pointing out is not reasonable I think. In case of this situation, MANET routers may need to change their addresses for connectivity/packet forwarding/packet routing to Internet. Best regards, Hyung-Jin Lim > > Kind Regards, > > Carlos > > -- > Carlos Jes=FAs Bernardos Cano http://www.netcoms.net > GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > WEEDEV 2009: 2nd Workshop on Experimental Evaluation and > Deployment Experiences on Vehicular networks > http://www.weedev.org/ > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf > > --0016e652ff9a44fd8e0463dc82c2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Carlos,
=A0
This is Hyung-Jin, Lim
I have a question.
See the inline....

=A0
2009/2/27 Carlos Jes=FAs Bernardos Cano <cjbc@it.= uc3m.es>
Hi Alex:

=A0 =A0 =A0 =A0O= ne question below.

El jue, 26-02-2009 a las 20:44 +0100, Alexandru P= etrescu escribi=F3:
> Sorry, I made an error indeed putting same prefix. =A0How about t= his
> updated picture with the prefixes being distinct:
>
&g= t;
> =A0 =A0 =A0 =A0 =A0----- =A0wifi "adhoc1" =A0------ = =A0wifi "adhoc2" =A0-----
> =A0 =A0 =A0 =A0 |Host1|---------------|Router|---------------|Host2|> =A0 =A0 =A0 =A0 =A0----- LL1 =A0 =A0 =A0 =A0 LL2 ------ LL3 =A0 =A0 = =A0 =A0LL4 =A0-----
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0G1 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0G4
>
>
&g= t; =A0 =A0 =A0 =A0 "adhoc1" and "adhoc2": 802.11 ESSIDs= in "ad-hoc" mode.
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Each is= an IPv6 subnet.
> =A0 =A0 =A0 =A0 LL1...4: IPv6 link-local addresses= .
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Self-formed according to rfc24= 64.
> =A0 =A0 =A0 =A0 G1, G4: =A0IPv6 global addresses, for example > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A02001:db8:1::1/64 and
> =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A02001:db8:2::4/64
> =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0Manually assigned, or pre-configured with SNMP
> =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0or formed according to stateless autoconf rf= c4862;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0the prefixes are advertised by Rout= er in RAs.
>

Does this model only apply to Host-Router-H= ost scenarios? I mean, does
this model apply for Router-Router-Router sc= enarios? I fully agree the
model fits the first scenario, but I don't for the second, since
rou= ters' mobility within the ad-hoc network would force them to change
= prefixes often, I guess. For those scenarios it might be better to think of addressing models in which MANET routers are configured with /128
(or= /32 for IPv4) addresses, so they don't need to change their
address= es as a result of link changes.
=A0
Does AUTOCONF not consider "ad-hoc network to Internet" scen= ario ?
If so, I agree your comment.
But if not, your pointing out is not reasonable I think.
In case of this situation, MANET routers may need to change their addr= esses for connectivity/packet forwarding/packet routing=A0to Internet.
=A0
Best regards,
Hyung-Jin Lim
=A0
=A0

Kind Re= gards,

Carlos

--
=A0Carlos Jes=FAs Bernardos Cano =A0 =A0 http://www.netcoms.net
=A0GPG FP: D29B 0A6A= 639A A561 93CA =A04D55 35DC BA4D D170 4F67
++++++++++++++++++++++++++++= ++++++++++++++++++++++++++++++++
=A0WEEDEV 2009: 2nd Workshop on Experimental Evaluation and
=A0 =A0 =A0 = =A0Deployment Experiences on Vehicular networks
=A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0http://www.= weedev.org/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++= ++++

_______________________________________________
Autoconf= mailing list
Aut= oconf@ietf.org
https://www.ietf.org/mailman/listinfo/autoconf<= br>

--0016e652ff9a44fd8e0463dc82c2-- From cjbc@it.uc3m.es Thu Feb 26 23:24:17 2009 Return-Path: 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 DC8623A6942 for ; Thu, 26 Feb 2009 23:24:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.35 X-Spam-Level: X-Spam-Status: No, score=-5.35 tagged_above=-999 required=5 tests=[AWL=0.349, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] 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 36ryz69IwSBc for ; Thu, 26 Feb 2009 23:24:16 -0800 (PST) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 905383A689C for ; Thu, 26 Feb 2009 23:24:16 -0800 (PST) Received: from [163.117.139.72] (acorde.it.uc3m.es [163.117.139.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp02.uc3m.es (Postfix) with ESMTP id 0BEBF6BDC1F; Fri, 27 Feb 2009 08:24:37 +0100 (CET) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: HyungJin Lim In-Reply-To: <7e8d02d40902261737n1c21b136hd575b8afa8702188@mail.gmail.com> References: <499F0BA7.90501@piuha.net> <7E8A76F7-2CE0-463A-8EE8-8877C46B4715@gmail.com> <49A6D436.7020505@gmail.com> <000001c99845$1dc56190$595024b0$@nl> <49A6F125.40400@gmail.com> <1235680887.4585.5.camel@localhost> <7e8d02d40902261737n1c21b136hd575b8afa8702188@mail.gmail.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-bgfbAjeC7c9XC+6JAgrW" Organization: Universidad Carlos III de Madrid Date: Fri, 27 Feb 2009 08:24:34 +0100 Message-Id: <1235719474.4612.3.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16488.005 Cc: Autoconf@ietf.org Subject: Re: [Autoconf] new charter X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 07:24:17 -0000 --=-bgfbAjeC7c9XC+6JAgrW Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Hi Hyung-Jin, Answer inline below... El vie, 27-02-2009 a las 10:37 +0900, HyungJin Lim escribi=F3: > Hi Carlos, > =20 > This is Hyung-Jin, Lim >=20 > I have a question. > See the inline.... >=20 > =20 > 2009/2/27 Carlos Jes=FAs Bernardos Cano > Hi Alex: > =20 > One question below. > =20 > El jue, 26-02-2009 a las 20:44 +0100, Alexandru Petrescu > escribi=F3: > > Sorry, I made an error indeed putting same prefix. How > about this > > updated picture with the prefixes being distinct: > > > > > > ----- wifi "adhoc1" ------ wifi "adhoc2" ----- > > |Host1|---------------|Router|---------------|Host2| > > ----- LL1 LL2 ------ LL3 LL4 ----- > > G1 G4 > > > > > > "adhoc1" and "adhoc2": 802.11 ESSIDs in "ad-hoc" > mode. > > Each is an IPv6 subnet. > > LL1...4: IPv6 link-local addresses. > > Self-formed according to rfc2464. > > G1, G4: IPv6 global addresses, for example > > 2001:db8:1::1/64 and > > 2001:db8:2::4/64 > > Manually assigned, or pre-configured with > SNMP > > or formed according to stateless autoconf > rfc4862; > > the prefixes are advertised by Router in > RAs. > > > =20 > =20 > Does this model only apply to Host-Router-Host scenarios? I > mean, does > this model apply for Router-Router-Router scenarios? I fully > agree the > model fits the first scenario, but I don't for the second, > since > routers' mobility within the ad-hoc network would force them > to change > prefixes often, I guess. For those scenarios it might be > better to think > of addressing models in which MANET routers are configured > with /128 > (or /32 for IPv4) addresses, so they don't need to change > their > addresses as a result of link changes. > =20 > Does AUTOCONF not consider "ad-hoc network to Internet" scenario ? > If so, I agree your comment. > But if not, your pointing out is not reasonable I think. > In case of this situation, MANET routers may need to change their > addresses for connectivity/packet forwarding/packet routing to > Internet. I think AUTOCONF considers connection to Internet, but even in that case, I think my comment still holds. It's true that in a connected scenario, the addressing depends on the infrastructure the MANET is attached to, but this doesn't necessarily imply that inner nodes have to change their addresses when move within the same MANET. Kind Regards, Carlos > =20 > Best regards, > Hyung-Jin Lim > =20 > =20 > =20 > Kind Regards, > =20 > Carlos > =20 > -- > =20 > Carlos Jes=FAs Bernardos Cano http://www.netcoms.net > GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > WEEDEV 2009: 2nd Workshop on Experimental Evaluation and > Deployment Experiences on Vehicular networks > http://www.weedev.org/ > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > =20 > =20 > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf > =20 >=20 --=20 Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ WEEDEV 2009: 2nd Workshop on Experimental Evaluation and Deployment Experiences on Vehicular networks http://www.weedev.org/ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ --=-bgfbAjeC7c9XC+6JAgrW Content-Type: application/pgp-signature; name=signature.asc Content-Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEABECAAYFAkmnlS0ACgkQNdy6TdFwT2e/NgCffmQDIGVAZxo3Oblr2HAzl++L uHYAoLnVbpO5drNRg6cOcjS8zj3NHO3x =hEER -----END PGP SIGNATURE----- --=-bgfbAjeC7c9XC+6JAgrW-- From dream.hjlim@gmail.com Fri Feb 27 00:00:52 2009 Return-Path: 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 105773A690A for ; Fri, 27 Feb 2009 00:00:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6] 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 Nzxbft3eFLEh for ; Fri, 27 Feb 2009 00:00:50 -0800 (PST) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.28]) by core3.amsl.com (Postfix) with ESMTP id 788673A68D2 for ; Fri, 27 Feb 2009 00:00:50 -0800 (PST) Received: by yw-out-2324.google.com with SMTP id 5so1234758ywh.49 for ; Fri, 27 Feb 2009 00:01:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=pAnU8/wH2z0Hig3tPXNUh6Z8SEOqqv68Oa+Cw5Tl95I=; b=uU90zya0eJXpgSs/mnd6xoBZ6Zk+EYJdTPO7Cbv7G8O5AWoDTcx8X679YSAXqEHnZV Bc09DWMtb6NkFjQTle6JsF6V1ooFGhm7zitWzf1zWmbsvkdqmcCS8kaI0H4elTEy+HMh eAXGmpeS7jVPpgvQZrlMvS48AQFeBD2BcpgRk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=CxLkk8vZwLJ+0/Y01fVavqOIzdwZPAu3FQ2tnanWiH0B5unz+0KEkJ9XowZiKyX/mc 31KdU7fJyN9hS2LCa/LKD4/bWmADG9NIWAkFblRhVW3248W6TJ4V9HGP0BKTpFUSMdYZ Yu2W2UQYnMzv6omUaC9ymBVX4sORwdKA4XLAM= MIME-Version: 1.0 Received: by 10.110.47.9 with SMTP id u9mr3255827tiu.39.1235721670805; Fri, 27 Feb 2009 00:01:10 -0800 (PST) In-Reply-To: <1235719474.4612.3.camel@localhost> References: <499F0BA7.90501@piuha.net> <7E8A76F7-2CE0-463A-8EE8-8877C46B4715@gmail.com> <49A6D436.7020505@gmail.com> <000001c99845$1dc56190$595024b0$@nl> <49A6F125.40400@gmail.com> <1235680887.4585.5.camel@localhost> <7e8d02d40902261737n1c21b136hd575b8afa8702188@mail.gmail.com> <1235719474.4612.3.camel@localhost> Date: Fri, 27 Feb 2009 17:01:10 +0900 Message-ID: <7e8d02d40902270001t7cbd103dife3f70cb6c2f23e0@mail.gmail.com> From: HyungJin Lim To: cjbc@it.uc3m.es, alexandru.petrescu@gmail.com, ryuji.wakikawa@gmail.com Content-Type: multipart/alternative; boundary=0016e65206023acb1f0463e1dffe Cc: autoconf@ietf.org Subject: Re: [Autoconf] new charter X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 08:00:52 -0000 --0016e65206023acb1f0463e1dffe Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Carlos, See inline... 2009/2/27 Carlos Jes=FAs Bernardos Cano > Hi Hyung-Jin, > > Answer inline below... > > El vie, 27-02-2009 a las 10:37 +0900, HyungJin Lim escribi=F3: > > Hi Carlos, > > > > This is Hyung-Jin, Lim > > > > I have a question. > > See the inline.... > > > > > > 2009/2/27 Carlos Jes=FAs Bernardos Cano > > Hi Alex: > > > > One question below. > > > > El jue, 26-02-2009 a las 20:44 +0100, Alexandru Petrescu > > escribi=F3: > > > Sorry, I made an error indeed putting same prefix. How > > about this > > > updated picture with the prefixes being distinct: > > > > > > > > > ----- wifi "adhoc1" ------ wifi "adhoc2" ----- > > > |Host1|---------------|Router|---------------|Host2| > > > ----- LL1 LL2 ------ LL3 LL4 ----- > > > G1 G4 > > > > > > > > > "adhoc1" and "adhoc2": 802.11 ESSIDs in "ad-hoc" > > mode. > > > Each is an IPv6 subnet. > > > LL1...4: IPv6 link-local addresses. > > > Self-formed according to rfc2464. > > > G1, G4: IPv6 global addresses, for example > > > 2001:db8:1::1/64 and > > > 2001:db8:2::4/64 > > > Manually assigned, or pre-configured with > > SNMP > > > or formed according to stateless autoconf > > rfc4862; > > > the prefixes are advertised by Router in > > RAs. > > > > > > > > > Does this model only apply to Host-Router-Host scenarios? I > > mean, does > > this model apply for Router-Router-Router scenarios? I fully > > agree the > > model fits the first scenario, but I don't for the second, > > since > > routers' mobility within the ad-hoc network would force them > > to change > > prefixes often, I guess. For those scenarios it might be > > better to think > > of addressing models in which MANET routers are configured > > with /128 > > (or /32 for IPv4) addresses, so they don't need to change > > their > > addresses as a result of link changes. > > > > Does AUTOCONF not consider "ad-hoc network to Internet" scenario ? > > If so, I agree your comment. > > But if not, your pointing out is not reasonable I think. > > In case of this situation, MANET routers may need to change their > > addresses for connectivity/packet forwarding/packet routing to > > Internet. > > I think AUTOCONF considers connection to Internet, but even in that > case, I think my comment still holds. It's true that in a connected > scenario, the addressing depends on the infrastructure the MANET is > attached to, Right ! > but this doesn't necessarily imply that inner nodes have to > change their addresses when move within the same MANET. In here, I think there are many assumptions and requirements. We should identify some aspects in relation to address configuration in MANET and AUTOCONF. Best regards, Hyung-Jin, Lim > > > Kind Regards, > > Carlos > > > > > Best regards, > > Hyung-Jin Lim > > > > > > > > Kind Regards, > > > > Carlos > > > > -- > > > > Carlos Jes=FAs Bernardos Cano http://www.netcoms.net > > GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > WEEDEV 2009: 2nd Workshop on Experimental Evaluation and > > Deployment Experiences on Vehicular networks > > http://www.weedev.org/ > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > > > > > _______________________________________________ > > Autoconf mailing list > > Autoconf@ietf.org > > https://www.ietf.org/mailman/listinfo/autoconf > > > > > -- > Carlos Jes=FAs Bernardos Cano http://www.netcoms.net > GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > WEEDEV 2009: 2nd Workshop on Experimental Evaluation and > Deployment Experiences on Vehicular networks > http://www.weedev.org/ > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > --0016e65206023acb1f0463e1dffe Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Carlos,
=A0
See inline...

2009/2/27 Carlos Jes=FAs Bernardos Cano <cjbc@it.uc3m.es>
Hi Hyung-Jin,

=A0 =A0 =A0= =A0Answer inline below...

El vie, 27-02-2009 a las 10:37 +0900, Hyu= ngJin Lim escribi=F3:
> Hi Carlos,
>
> This is Hyung-Jin, Li= m
>
> I have a question.
> See the inline....
>
= >
> 2009/2/27 Carlos Jes=FAs Bernardos Cano <cjbc@it.uc3m.es>
> =A0 =A0 =A0 =A0 Hi Alex:
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0One question below.
>
> =A0 =A0 =A0 =A0 El jue, 26-02-2009 a= las 20:44 +0100, Alexandru Petrescu
> =A0 =A0 =A0 =A0 escribi=F3:> =A0 =A0 =A0 =A0 > Sorry, I made an error indeed putting same prefi= x. =A0How
> =A0 =A0 =A0 =A0 about this
> =A0 =A0 =A0 =A0 > updated pictur= e with the prefixes being distinct:
> =A0 =A0 =A0 =A0 >
> = =A0 =A0 =A0 =A0 >
> =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 =A0----- = =A0wifi "adhoc1" =A0------ =A0wifi "adhoc2" =A0----- > =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 |Host1|---------------|Router|---= ------------|Host2|
> =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 =A0----- L= L1 =A0 =A0 =A0 =A0 LL2 ------ LL3 =A0 =A0 =A0 =A0LL4 =A0-----
> =A0 = =A0 =A0 =A0 > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0G1 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0G4
> =A0 =A0 =A0 =A0 >
> =A0 =A0 =A0 =A0 >
> =A0 =A0 =A0 = =A0 > =A0 =A0 =A0 =A0 "adhoc1" and "adhoc2": 802.11 = ESSIDs in "ad-hoc"
> =A0 =A0 =A0 =A0 mode.
> =A0 =A0 = =A0 =A0 > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0Each is an IPv6 subnet.
> =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 LL1...4: IPv6 link-local addresse= s.
> =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Self-for= med according to rfc2464.
> =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 G1, = G4: =A0IPv6 global addresses, for example
> =A0 =A0 =A0 =A0 > =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A02001:db8:1::1/64 and
> =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A02001:db8:2::4/= 64
> =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Manually= assigned, or pre-configured with
> =A0 =A0 =A0 =A0 SNMP
> =A0 = =A0 =A0 =A0 > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0or formed according to = stateless autoconf
> =A0 =A0 =A0 =A0 rfc4862;
> =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0the prefixes are advertised by Router in
> =A0 =A0= =A0 =A0 RAs.
> =A0 =A0 =A0 =A0 >
>
>
> =A0 =A0 = =A0 =A0 Does this model only apply to Host-Router-Host scenarios? I
> =A0 =A0 =A0 =A0 mean, does
> =A0 =A0 =A0 =A0 this model apply fo= r Router-Router-Router scenarios? I fully
> =A0 =A0 =A0 =A0 agree the=
> =A0 =A0 =A0 =A0 model fits the first scenario, but I don't for= the second,
> =A0 =A0 =A0 =A0 since
> =A0 =A0 =A0 =A0 routers' mobility within the ad-hoc network would = force them
> =A0 =A0 =A0 =A0 to change
> =A0 =A0 =A0 =A0 prefix= es often, I guess. For those scenarios it might be
> =A0 =A0 =A0 =A0 = better to think
> =A0 =A0 =A0 =A0 of addressing models in which MANET= routers are configured
> =A0 =A0 =A0 =A0 with /128
> =A0 =A0 =A0 =A0 (or /32 for IPv4) ad= dresses, so they don't need to change
> =A0 =A0 =A0 =A0 their
= > =A0 =A0 =A0 =A0 addresses as a result of link changes.
>
>= Does AUTOCONF not consider "ad-hoc network to Internet" scenario= ?
> If so, I agree your comment.
> But if not, your pointing out is = not reasonable I think.
> In case of this situation, MANET routers ma= y need to change their
> addresses for connectivity/packet forwarding= /packet routing to
> Internet.

I think AUTOCONF considers connection to = Internet, but even in that
case, I think my comment still holds. It'= s true that in a connected
scenario, the addressing depends on the infra= structure the MANET is
attached to,
=A0
=A0Right !
=A0
but this do= esn't necessarily imply that inner nodes have to
change their addres= ses when move within the same MANET.
=A0
In here, I think there are many assumptions and requirements.
We should identify=A0some aspects in relation to address configuration= in MANET and AUTOCONF.=A0
=A0
Best regards,
Hyung-Jin, Lim


Kin= d Regards,

Carlos

>
> Best regards,
> Hyung-Jin Lim<= br>>
>
>
> =A0 =A0 =A0 =A0 Kind Regards,
>
&g= t; =A0 =A0 =A0 =A0 Carlos
>
> =A0 =A0 =A0 =A0 --
>
>= ; =A0 =A0 =A0 =A0 =A0Carlos Jes=FAs Bernardos Cano =A0 =A0 http://www.netcoms.net
> =A0 =A0 =A0 =A0 =A0GPG FP: D29B 0A6A 639A A561 93CA =A04D55 35DC BA4D = D170 4F67
> =A0 =A0 =A0 =A0 +++++++++++++++++++++++++++++++++++++++++= +++++++++++++++++++
> =A0 =A0 =A0 =A0 =A0WEEDEV 2009: 2nd Workshop on= Experimental Evaluation and
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Deployment Experiences on Vehicular net= works
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0http://www.weedev.org/
&g= t; =A0 =A0 =A0 =A0 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++= ++++
>
>
> =A0 =A0 =A0 =A0 ______________________________________= _________
> =A0 =A0 =A0 =A0 Autoconf mailing list
> =A0 =A0 =A0= =A0 Autoconf@ietf.org
> =A0= =A0 =A0 =A0 https://www.ietf.org/mailman/listinfo/autoconf
>
>
--
=A0Carlos Jes=FAs Bernardos Cano =A0 =A0 http://www.netcoms.net
=A0= GPG FP: D29B 0A6A 639A A561 93CA =A04D55 35DC BA4D D170 4F67
+++++++++++= +++++++++++++++++++++++++++++++++++++++++++++++++
=A0WEEDEV 2009: 2nd Workshop on Experimental Evaluation and
=A0 =A0 =A0 = =A0Deployment Experiences on Vehicular networks
=A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0http://www.= weedev.org/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++= ++++

--0016e65206023acb1f0463e1dffe-- From teco@inf-net.nl Fri Feb 27 01:41:14 2009 Return-Path: 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 A7D683A6AEB for ; Fri, 27 Feb 2009 01:41:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.49 X-Spam-Level: X-Spam-Status: No, score=-1.49 tagged_above=-999 required=5 tests=[AWL=-0.044, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_21=0.6] 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 w3wkMJVIqxVS for ; Fri, 27 Feb 2009 01:41:13 -0800 (PST) Received: from hpsmtp-eml20.kpnxchange.com (hpsmtp-eml20.KPNXCHANGE.COM [213.75.38.85]) by core3.amsl.com (Postfix) with ESMTP id CDAFA3A6821 for ; Fri, 27 Feb 2009 01:41:11 -0800 (PST) Received: from cpsmtp-eml101.kpnxchange.com ([213.75.84.101]) by hpsmtp-eml20.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 27 Feb 2009 10:41:27 +0100 Received: from M90Teco ([86.83.9.22]) by cpsmtp-eml101.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 27 Feb 2009 10:41:26 +0100 From: "Teco Boot" To: References: <499F0BA7.90501@piuha.net> <7E8A76F7-2CE0-463A-8EE8-8877C46B4715@gmail.com> <49A6D436.7020505@gmail.com> <000001c99845$1dc56190$595024b0$@nl> <49A6F125.40400@gmail.com> <1235680887.4585.5.camel@localhost> In-Reply-To: <1235680887.4585.5.camel@localhost> Date: Fri, 27 Feb 2009 10:41:26 +0100 Message-ID: <002f01c998bf$8f112210$ad336630$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcmYUp3cco28S7uzQmigySHelCL5AgAWx55A Content-Language: nl X-OriginalArrivalTime: 27 Feb 2009 09:41:26.0855 (UTC) FILETIME=[8F629D70:01C998BF] Subject: [Autoconf] Autoconf addressing model X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 09:41:14 -0000 All, Here my opinion on the to be defined addressing model for MANETs / = Autoconf. I opened a separate thread, as I think (and hope) there will be an = intensive and productive discussion. Some of us like an address model with /32 (IPv4) or /128 (IPv6) prefix-length addresses attached to an interface to a multi-access link. These addresses do not have an Interface-ID.=20 Such a model excludes usage of /64 "prefix swapping", which is IMHO an extremely important attribute of IPv6. And it is specified as mandatory = in some standard track RFCs (e.g. RFC2464).=20 We could discuss and analyze the effect of adopting the /128 (or /32) = prefix lengths for MANET interfaces, but I prefer taking this option as last resort. I think there is a much more obvious option, using the RFC2464 = model for the MANET interface and /128 (or /32) for loopback interfaces. Both would use high probability globally unique Interface IDs like EUI-64 (Extended Unique Identifier). RFC4291 2.1. Addressing Model: All interfaces are required to have at least one Link-Local unicast address (see Section 2.8 for additional required addresses). A single interface may also have multiple IPv6 addresses of any type (unicast, anycast, and multicast) or scope. Unicast addresses with a scope greater than link-scope are not needed for interfaces that are not used as the origin or destination of any IPv6 packets to or from non-neighbors. This is sometimes convenient for point-to-point interfaces. RFC2464 4. Stateless Autoconfiguration: An IPv6 address prefix used for stateless autoconfiguration [ACONF] of an Ethernet interface must have a length of 64 bits. It is not only because the RFC texts that I dislike the /128 in MANET interfaces, it is also backward compatibility with current IP stacks = (and probably many applications). I think an interface with /128 is stub, and thus protocols may assume that there is no other node on this link in = the same subnet. Think of ARP and routing protocols. I verified this with = some product, the outcome confirmed my assumption. I was able to adjust the configuration on one platform so that it worked (Linux), but still the indication is that the model has a high impact. I think using /128 for loopback interfaces fits the requirements for the addressing model. If a loopback interface is used, MANET interfaces do = not require a globally unique address. RFC4291 once more (out of section, = also cited above): Unicast addresses with a scope greater than link-scope are not needed for interfaces that are not used as the origin or destination of any IPv6 packets to or from non-neighbors. So "host functionality" can be provided using the globally (or MANET = local) unique address assigned to a loopback address, or another non-MANET interface. This results in the following addressing model, where all nodes are = routers: +-------+ wifi "adhoc1" +-------+ wifi "adhoc2" +-------+ |Router1|>-------------<|Router2|>-------------<|Router3| +---L---+ LL1 LL21 +---L---+ LL22 LL3 +---L---+ |M1 |M2 |M3 "adhoc1" and "adhoc2": 802.11 SSIDs in "IBSS" mode. Each IBSS is an IPv6 subnet. L: Loopback interface. >, <: MANET interface. LL1, LL21, LL22, LL3: IPv6 link-local addresses. Self-formed according to rfc2464. M1, M2, M3: IPv6 MANET local addresses, for example FD01:db8::1/128, FD01:db8::2/128 and FD01:db8::3/128. Manually assigned, or pre-configured (e.g. with SNMP) or formed according to a to be defined [Autoconf for MANETs] protocol, with a to-be-defined prefix (e.g. ULA, RFC4193). Although all nodes are marked as router, this does not imply all nodes forward packets. All nodes run a MANET routing protocol for learning the MANET topology. In case one of the routers is connected to the Internet or private = network, this router can advertize a prefix in the MANET, and this information is distributed in the MANET with an [Autoconf for MANETs] protocol. Internet | | +-------+-------+ | Access Router | +-------+-------+ | | | Prefix information | V | +-------+ wifi "adhoc1" +---+---+ wifi "adhoc2" +-------+ |Router1|>-------------<|Router2|>-------------<|Router3| +---L---+ LL1 LL21 +---L---+ LL22 LL3 +---L---+ |M1 |M2 |M3 |G1 |G2 |G3 <------- -------> Prefix information Prefix information=20 G1, G2, G3: IPv6 globally unique addresses, for example 2001:db8:G:1/128, 2001:db8:G:2/128 and 2001:db8:G:3/128. Formed according to a to be defined [Autoconf for MANETs] protocol, with the prefix provided by (via) the Access Router. Multi-homing can easily be supported: ---+-------Internet--------+--- | | | | +-------+-------+ +-------+-------+ |Access Router H| |Access Router G| +-------+-------+ +-------+-------+ | | ||Prefix information H | |Prefix information G |V | V | | +---+---+ wifi "adhoc1" +---+---+ wifi "adhoc2" +-------+ |Router1|>-------------<|Router2|>-------------<|Router3| +---L---+ LL1 LL21 +---L---+ LL22 LL3 +---L---+ |M1 |M2 |M3 |G1 |G2 |G3 |H1 |H2 |H3 <------- -------> Prefix information G Prefix information G, H ---------> Prefix information H H1, H2, H3: IPv6 globally unique addresses, for example 2001:db8:H:1/128, 2001:db8:H:2/128 and 2001:db8:H:3/128. Formed according to a to be defined [Autoconf for MANETs] protocol, with the prefix provided by (via) Access Router H. Note that the impact of the number of interfaces is minimal, the address configuration of Router2 is very similar to Router1 and Router3. Also, = the status of the MANET interface has no impact on communication in case of multi-homing and redundant paths. (OK, we might need MIP6 / HIP / SHIM6 = or application layer address swapping mechanisms). It doesn't matter how many ad hoc segments there are. In the following scenario, the link to Access router G disappeared, Router 3 disappeared = and a Router4 joined IBSS "adhoc1". ---+-------Internet------ | =20 | =20 +-------+-------+ =20 |Access Router H| =20 +-------+-------+ =20 | =20 ||Prefix information H =20 |V wifi "adhoc1" | <---------------------------v-------->=20 <------|--v----------------------> |=20 |<-|--------------------v-----------------------|---> | | | | +---+--'+ +---'---+ +---'---+ |Router1|>-------------<|Router2|>-------------<|Router4| +---L---+ LL1 LL21 +---L---+ LL22 LL4 +---L---+ |M1 |M2 |M4 |H1 |H2 |H4 ---------> ---------> Prefix information H Prefix information H Now, Router2 acts as a relay for Router4, so Router4 can reach Router1 = and the Internet. Router1 acts as Border Router for all nodes in the MANET. I have some thoughts on IPv4 supports. Of course IPv4 misses lots of flexibility that is used in above model. But there are ways to support = it, e.g. IPv4 link local (RFC3927) accompanied by some extended form of duplicate address detection (passive checking routing tables). For = globally unique address assignment I think of DHCP-IPv4 over an IPv6 path, = provided as described above. (e.g. Router4 gets its /32 address for its loopback interface from/via Access Router H, using M4 or H4 address and the IPv6 MANET protocol. Any comments? Teco. |-----Oorspronkelijk bericht----- |Van: Carlos Jes=FAs Bernardos Cano [mailto:cjbc@it.uc3m.es] |Verzonden: donderdag 26 februari 2009 21:41 |Aan: Alexandru Petrescu |CC: Teco Boot; autoconf@ietf.org |Onderwerp: Re: [Autoconf] new charter | |Hi Alex: | | One question below. | |El jue, 26-02-2009 a las 20:44 +0100, Alexandru Petrescu escribi=F3: |> Sorry, I made an error indeed putting same prefix. How about this |> updated picture with the prefixes being distinct: |> |> |> ----- wifi "adhoc1" ------ wifi "adhoc2" ----- |> |Host1|---------------|Router|---------------|Host2| |> ----- LL1 LL2 ------ LL3 LL4 ----- |> G1 G4 |> |> |> "adhoc1" and "adhoc2": 802.11 ESSIDs in "ad-hoc" mode. |> Each is an IPv6 subnet. |> LL1...4: IPv6 link-local addresses. |> Self-formed according to rfc2464. |> G1, G4: IPv6 global addresses, for example |> 2001:db8:1::1/64 and |> 2001:db8:2::4/64 |> Manually assigned, or pre-configured with SNMP |> or formed according to stateless autoconf rfc4862; |> the prefixes are advertised by Router in RAs. |> | |Does this model only apply to Host-Router-Host scenarios? I mean, does |this model apply for Router-Router-Router scenarios? I fully agree the |model fits the first scenario, but I don't for the second, since |routers' mobility within the ad-hoc network would force them to change |prefixes often, I guess. For those scenarios it might be better to = think |of addressing models in which MANET routers are configured with /128 |(or /32 for IPv4) addresses, so they don't need to change their |addresses as a result of link changes. | |Kind Regards, | |Carlos | |-- | Carlos Jes=FAs Bernardos Cano http://www.netcoms.net | GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 |++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ | WEEDEV 2009: 2nd Workshop on Experimental Evaluation and | Deployment Experiences on Vehicular networks | http://www.weedev.org/ |++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ From alexandru.petrescu@gmail.com Fri Feb 27 02:07:50 2009 Return-Path: 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 872963A6BAA for ; Fri, 27 Feb 2009 02:07:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.181 X-Spam-Level: X-Spam-Status: No, score=-2.181 tagged_above=-999 required=5 tests=[AWL=0.068, 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 WmH-nDzBcidH for ; Fri, 27 Feb 2009 02:07:49 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.166.172.107]) by core3.amsl.com (Postfix) with ESMTP id 68D973A6AC3 for ; Fri, 27 Feb 2009 02:07:49 -0800 (PST) Received: from nephilia.intra.cea.fr (nephilia.intra.cea.fr [132.166.88.33]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-1.2) with ESMTP id n1RA8A9P030519; Fri, 27 Feb 2009 11:08:10 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by nephilia.intra.cea.fr (8.13.8/8.13.8) with ESMTP id n1RA8AKV005167; Fri, 27 Feb 2009 11:08:10 +0100 (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 n1RA89ri018028; Fri, 27 Feb 2009 11:08:09 +0100 Message-ID: <49A7BB89.5040807@gmail.com> Date: Fri, 27 Feb 2009 11:08:09 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: cjbc@it.uc3m.es References: <499F0BA7.90501@piuha.net> <7E8A76F7-2CE0-463A-8EE8-8877C46B4715@gmail.com> <49A6D436.7020505@gmail.com> <000001c99845$1dc56190$595024b0$@nl> <49A6F125.40400@gmail.com> <1235680887.4585.5.camel@localhost> In-Reply-To: <1235680887.4585.5.camel@localhost> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org Subject: Re: [Autoconf] new charter X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 10:07:50 -0000 Carlos Jesús Bernardos Cano a écrit : > Hi Alex: > > One question below. > > El jue, 26-02-2009 a las 20:44 +0100, Alexandru Petrescu escribió: >> Sorry, I made an error indeed putting same prefix. How about this >> updated picture with the prefixes being distinct: >> >> >> ----- wifi "adhoc1" ------ wifi "adhoc2" ----- >> |Host1|---------------|Router|---------------|Host2| ----- LL1 >> LL2 ------ LL3 LL4 ----- G1 >> G4 >> >> >> "adhoc1" and "adhoc2": 802.11 ESSIDs in "ad-hoc" mode. Each is an >> IPv6 subnet. LL1...4: IPv6 link-local addresses. Self-formed >> according to rfc2464. G1, G4: IPv6 global addresses, for example >> 2001:db8:1::1/64 and 2001:db8:2::4/64 Manually assigned, or >> pre-configured with SNMP or formed according to stateless autoconf >> rfc4862; the prefixes are advertised by Router in RAs. >> > > Does this model only apply to Host-Router-Host scenarios? Yes. > I mean, does this model apply for Router-Router-Router scenarios? Something like this?: ------- wifi "adhoc1" ------- wifi "adhoc2" ------- |Router1|---------------|Router2|---------------|Router3| ------ LL1 LL2 -------LL3 LL4 ------- G1 G4 G1, G4: ? > I fully agree the model fits the first scenario, but I don't for the > second, since routers' mobility within the ad-hoc network would > force them to change prefixes often, I guess. Ah. But before being forced to change a prefix, a Router could still move around as much as it wants. I think the limit is within 25m range, as imposed by the wifi 50m area (25m for two routers in opposite directions). What do you think about this practical limit? > For those scenarios it might be better to think of addressing models > in which MANET routers are configured with /128 (or /32 for IPv4) > addresses, so they don't need to change their addresses as a result > of link changes. Sorry... in the picture above the addresses are also /128. It was an abbreviation for me to show only 2001:db8:1::1/64 assigned to Host1. The full notation should have been 2001:db8:1::/64 prefix and 2001:db8:1::1/128. Would the following picture satisfy the need for /128 addresses?: ----- wifi "adhoc1" ------ wifi "adhoc2" ----- |Host1|---------------|Router|---------------|Host2| ----- LL1 P1 LL2 ------ LL3 P2 LL4 ----- G1 G4 G1, G4: IPv6 global addresses, for example 2001:db8:1::1/128 and 2001:db8:2::4/128 Manually assigned, or pre-configured with SNMP or formed according to stateless autoconf rfc4862; the prefixes are advertised by Router in RAs. P1, P2: IPv6 global prefixes, for example 2001:db8:1::/64 and 2001:db8:2::/64 Manually assigned, or pre-configured with SNMP. Or is it not what you mean? I also don't understand why you think that if /128 addresses are assigned to routers then they don't need to change them as a result of link changes. Alex From alexandru.petrescu@gmail.com Fri Feb 27 02:11:57 2009 Return-Path: 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 ED80F28C2D5 for ; Fri, 27 Feb 2009 02:11:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.182 X-Spam-Level: X-Spam-Status: No, score=-2.182 tagged_above=-999 required=5 tests=[AWL=0.067, 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 aeRdCw9Tn7iQ for ; Fri, 27 Feb 2009 02:11:57 -0800 (PST) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.166.172.106]) by core3.amsl.com (Postfix) with ESMTP id D4A4328C2C1 for ; Fri, 27 Feb 2009 02:11:56 -0800 (PST) Received: from nephilia.intra.cea.fr (nephilia.intra.cea.fr [132.166.88.33]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-1.2) with ESMTP id n1RACHnH004344; Fri, 27 Feb 2009 11:12:17 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by nephilia.intra.cea.fr (8.13.8/8.13.8) with ESMTP id n1RACGKQ010771; Fri, 27 Feb 2009 11:12:16 +0100 (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 n1RACGn1019551; Fri, 27 Feb 2009 11:12:16 +0100 Message-ID: <49A7BC80.4000807@gmail.com> Date: Fri, 27 Feb 2009 11:12:16 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: HyungJin Lim References: <499F0BA7.90501@piuha.net> <7E8A76F7-2CE0-463A-8EE8-8877C46B4715@gmail.com> <49A6D436.7020505@gmail.com> <000001c99845$1dc56190$595024b0$@nl> <49A6F125.40400@gmail.com> <1235680887.4585.5.camel@localhost> <7e8d02d40902261737n1c21b136hd575b8afa8702188@mail.gmail.com> In-Reply-To: <7e8d02d40902261737n1c21b136hd575b8afa8702188@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: Autoconf@ietf.org Subject: Re: [Autoconf] new charter X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 10:11:58 -0000 HyungJin Lim a écrit : > Hi Carlos, > > This is Hyung-Jin, Lim > I have a question. > See the inline.... > > > 2009/2/27 Carlos Jesús Bernardos Cano > > > Hi Alex: > > One question below. > > El jue, 26-02-2009 a las 20:44 +0100, Alexandru Petrescu escribió: > > Sorry, I made an error indeed putting same prefix. How about this > > updated picture with the prefixes being distinct: > > > > > > ----- wifi "adhoc1" ------ wifi "adhoc2" ----- > > |Host1|---------------|Router|---------------|Host2| > > ----- LL1 LL2 ------ LL3 LL4 ----- > > G1 G4 > > > > > > "adhoc1" and "adhoc2": 802.11 ESSIDs in "ad-hoc" mode. > > Each is an IPv6 subnet. > > LL1...4: IPv6 link-local addresses. > > Self-formed according to rfc2464. > > G1, G4: IPv6 global addresses, for example > > 2001:db8:1::1/64 and > > 2001:db8:2::4/64 > > Manually assigned, or pre-configured with SNMP > > or formed according to stateless autoconf rfc4862; > > the prefixes are advertised by Router in RAs. > > > > Does this model only apply to Host-Router-Host scenarios? I mean, does > this model apply for Router-Router-Router scenarios? I fully agree the > model fits the first scenario, but I don't for the second, since > routers' mobility within the ad-hoc network would force them to change > prefixes often, I guess. For those scenarios it might be better to think > of addressing models in which MANET routers are configured with /128 > (or /32 for IPv4) addresses, so they don't need to change their > addresses as a result of link changes. > > > Does AUTOCONF not consider "ad-hoc network to Internet" scenario ? Do you mean something like this?: ----- wifi "adhoc1" ------ wifi "adhoc2" -------- / |Host1|---------------|Router|---------------|Gatewway|---| Internet ----- LL1 LL2 ------ LL3 LL4 -------- \ G1 G4 "adhoc1" and "adhoc2": 802.11 ESSIDs in "ad-hoc" mode. Each is an IPv6 subnet. LL1...4: IPv6 link-local addresses. Self-formed according to rfc2464. G1, G4: ? Alex From sonia.gammar@ensi.rnu.tn Fri Feb 27 02:13:11 2009 Return-Path: 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 666433A6991 for ; Fri, 27 Feb 2009 02:13:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.67 X-Spam-Level: *** X-Spam-Status: No, score=3.67 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, MSGID_MULTIPLE_AT=1.449, TVD_SPACE_RATIO=2.219] 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 cKPOSwzuhakc for ; Fri, 27 Feb 2009 02:13:10 -0800 (PST) Received: from planetmail5.outgw.tn (planetmail5.outgw.tn [193.95.97.10]) by core3.amsl.com (Postfix) with ESMTP id 4374D28C296 for ; Fri, 27 Feb 2009 02:13:02 -0800 (PST) Received: from planet.net.tn (smtp-in.planet.tn [193.95.123.26]) by tounes-23.ati.tn (Postfix) with SMTP id 842C61D3003C for ; Fri, 27 Feb 2009 11:13:23 +0100 (CET) Received: from [41.224.241.117] (HELO sonia) by fes2.planet.net.tn (CommuniGate Pro SMTP 5.2.10) with ESMTP id 25427677 for autoconf@ietf.org; Fri, 27 Feb 2009 11:13:32 +0100 From: "Sonia Mettali Gammar" To: Date: Fri, 27 Feb 2009 11:13:12 +0100 Message-ID: <005c01c998c3$ff846080$fe8d2180$@gammar@ensi.rnu.tn> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_005D_01C998CC.6148C880" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcmYw/7rMx2s+SdCQ0iTulub9Vg4wg== Content-Language: fr Subject: [Autoconf] unsubscribe X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 10:13:11 -0000 Il s'agit d'un message à parties multiples au format MIME. ------=_NextPart_000_005D_01C998CC.6148C880 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Unsubscribe autoconf@ietf.org ------=_NextPart_000_005D_01C998CC.6148C880 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Unsubscribe autoconf@ietf.org

------=_NextPart_000_005D_01C998CC.6148C880-- From dream.hjlim@gmail.com Fri Feb 27 02:45:56 2009 Return-Path: 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 0CED33A6C33 for ; Fri, 27 Feb 2009 02:45:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, 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 JunkpWsmbfoS for ; Fri, 27 Feb 2009 02:45:55 -0800 (PST) Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.188]) by core3.amsl.com (Postfix) with ESMTP id A43EE3A6803 for ; Fri, 27 Feb 2009 02:45:53 -0800 (PST) Received: by ti-out-0910.google.com with SMTP id 11so1301363tim.25 for ; Fri, 27 Feb 2009 02:46:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=/EAKj40Ohwbx7DonC31i3uLNuNZD4tieicrM9NGKzRU=; b=lukTj5CoiqnJsLuJXa2XPMsW1RnFMpmgmwQRpwtAnMmCCAagYONsNTuAq0mGOw8nRQ KuS3CIeiKWaKhKR7MUPW9cPoZnRgkZlHc91ijOT+cECgkmBezRM1LY/saCKPB4IHtE2L wVP6awIfGFiQlknQiD3kWot2vDRkkKvQjBBbI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=KkhnBHdpvFptESW8S2vfq3lZHN2ekTGqxDlydpRnEh3zd+b7QY56Wr9OcUR9bnxaCu 7uY5yTWVoJ9yz4+vCI7i8rHcBbBIqWo460FQ+LX6y8Sr0zAOgvgCdPGZpQcNgtYns4uh nnkhkLhfPkLS9AJS756rRLRlqpTIhup8HKmtk= MIME-Version: 1.0 Received: by 10.110.52.5 with SMTP id z5mr21286tiz.26.1235731575239; Fri, 27 Feb 2009 02:46:15 -0800 (PST) In-Reply-To: <49A7BC80.4000807@gmail.com> References: <499F0BA7.90501@piuha.net> <7E8A76F7-2CE0-463A-8EE8-8877C46B4715@gmail.com> <49A6D436.7020505@gmail.com> <000001c99845$1dc56190$595024b0$@nl> <49A6F125.40400@gmail.com> <1235680887.4585.5.camel@localhost> <7e8d02d40902261737n1c21b136hd575b8afa8702188@mail.gmail.com> <49A7BC80.4000807@gmail.com> Date: Fri, 27 Feb 2009 19:46:15 +0900 Message-ID: <7e8d02d40902270246k687c68d2t717e301041f8aa53@mail.gmail.com> From: HyungJin Lim To: Alexandru Petrescu , teco@inf-net.nl Content-Type: multipart/alternative; boundary=001485f880e49474e00463e42d3e Cc: Autoconf@ietf.org Subject: Re: [Autoconf] new charter X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 10:45:56 -0000 --001485f880e49474e00463e42d3e Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Alex, Long time, no hear... See inline.... 2009/2/27 Alexandru Petrescu > HyungJin Lim a =E9crit : > >> Hi Carlos, >> This is Hyung-Jin, Lim >> I have a question. >> See the inline.... >> >> 2009/2/27 Carlos Jes=FAs Bernardos Cano > cjbc@it.uc3m.es>> >> >> >> Hi Alex: >> >> One question below. >> >> El jue, 26-02-2009 a las 20:44 +0100, Alexandru Petrescu escribi=F3: >> > Sorry, I made an error indeed putting same prefix. How about this >> > updated picture with the prefixes being distinct: >> > >> > >> > ----- wifi "adhoc1" ------ wifi "adhoc2" ----- >> > |Host1|---------------|Router|---------------|Host2| >> > ----- LL1 LL2 ------ LL3 LL4 ----- >> > G1 G4 >> > >> > >> > "adhoc1" and "adhoc2": 802.11 ESSIDs in "ad-hoc" mode. >> > Each is an IPv6 subnet. >> > LL1...4: IPv6 link-local addresses. >> > Self-formed according to rfc2464. >> > G1, G4: IPv6 global addresses, for example >> > 2001:db8:1::1/64 and >> > 2001:db8:2::4/64 >> > Manually assigned, or pre-configured with SNMP >> > or formed according to stateless autoconf rfc4862= ; >> > the prefixes are advertised by Router in RAs. >> > >> >> Does this model only apply to Host-Router-Host scenarios? I mean, doe= s >> this model apply for Router-Router-Router scenarios? I fully agree th= e >> model fits the first scenario, but I don't for the second, since >> routers' mobility within the ad-hoc network would force them to chang= e >> prefixes often, I guess. For those scenarios it might be better to >> think >> of addressing models in which MANET routers are configured with /128 >> (or /32 for IPv4) addresses, so they don't need to change their >> addresses as a result of link changes. >> >> Does AUTOCONF not consider "ad-hoc network to Internet" scenario ? >> > > Do you mean something like this?: Okey!!. > > > ----- wifi "adhoc1" ------ wifi "adhoc2" -------- / > |Host1|---------------|Router|---------------|Gatewway|---| Internet > ----- LL1 LL2 ------ LL3 LL4 -------- \ > G1 G4 > > > "adhoc1" and "adhoc2": 802.11 ESSIDs in "ad-hoc" mode. > Each is an IPv6 subnet. > LL1...4: IPv6 link-local addresses. > Self-formed according to rfc2464. > G1, G4: ? Host1 may be a Router I think. This router may be mobile router.i.e, NEMO. In disaster environment, this scenario is possible. Then, gateway will use satelite channel. Considering your case, Host1 will get his address from the upper router (case 1) or the gateway (case 2). According to which case is configured, this network has other aspects. anyway, Already, Teco described satifactory aspects relation to this situation in previous message. Do you also agree with his comments ? Thanks, Hyung-Jin, Lim > Alex > > --001485f880e49474e00463e42d3e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Alex,
=A0
Long time, no hear...
See inline....


2009/2/27 Alexandru Petrescu &= lt;alexandru.petrescu@gmail= .com>
HyungJin Lim a =E9crit :
Hi Carlos,
=A0This is Hyung-Jin, Lim
I have a q= uestion.
See the inline....

=A02009/2/27 Carlos Jes=FAs Ber= nardos Cano <cjbc@i= t.uc3m.es <mailto:cjbc@it.uc3m.es>>=20


=A0 =A0Hi Alex:

=A0 =A0 =A0 =A0 =A0 On= e question below.

=A0 =A0El jue, 26-02-2009 a las 20:44 +0100, Alexa= ndru Petrescu escribi=F3:
=A0 =A0 > Sorry, I made an error indeed put= ting same prefix. =A0How about this
=A0 =A0 > updated picture with the prefixes being distinct:
=A0 =A0 &= gt;
=A0 =A0 >
=A0 =A0 > =A0 =A0 =A0 =A0 =A0----- =A0wifi "= adhoc1" =A0------ =A0wifi "adhoc2" =A0-----
=A0 =A0 > = =A0 =A0 =A0 =A0 |Host1|---------------|Router|---------------|Host2|
=A0 =A0 > =A0 =A0 =A0 =A0 =A0----- LL1 =A0 =A0 =A0 =A0 LL2 ------ LL3 = =A0 =A0 =A0 =A0LL4 =A0-----
=A0 =A0 > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= G1 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0G4
=A0= =A0 >
=A0 =A0 >
=A0 =A0 > =A0 =A0 =A0 =A0 "adhoc1"= ; and "adhoc2": 802.11 ESSIDs in "ad-hoc" mode.
=A0 =A0 > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0Each is an IPv6 subnet.
=A0 =A0 > =A0 =A0 =A0 =A0 LL1...4: IPv6 li= nk-local addresses.
=A0 =A0 > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Self= -formed according to rfc2464.
=A0 =A0 > =A0 =A0 =A0 =A0 G1, G4: =A0IP= v6 global addresses, for example
=A0 =A0 > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A02001:db8:1::1/64 and
=A0= =A0 > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A02001:db8:2::4/64
=A0 =A0 &g= t; =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Manually assigned, or pre-configured = with SNMP
=A0 =A0 > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0or formed acco= rding to stateless autoconf rfc4862;
=A0 =A0 > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0the prefixes are advertised= by Router in RAs.
=A0 =A0 >

=A0 =A0Does this model only apply= to Host-Router-Host scenarios? I mean, does
=A0 =A0this model apply for= Router-Router-Router scenarios? I fully agree the
=A0 =A0model fits the first scenario, but I don't for the second, since=
=A0 =A0routers' mobility within the ad-hoc network would force them= to change
=A0 =A0prefixes often, I guess. For those scenarios it might = be better to think
=A0 =A0of addressing models in which MANET routers are configured with /128=
=A0 =A0(or /32 for IPv4) addresses, so they don't need to change th= eir
=A0 =A0addresses as a result of link changes.

=A0Does AUTOCON= F not consider "ad-hoc network to Internet" scenario ?

Do you mean something like this?:
=A0
Okey!!.


=A0= ----- =A0wifi "adhoc1" =A0------ =A0wifi "adhoc2" =A0-= ------- =A0 =A0 /
=A0|Host1|---------------|Router|---------------|Gatewway|---| Internet=20

=A0 ----- LL1 =A0 =A0 =A0 =A0 LL2 ------ LL3 =A0 = =A0 =A0 =A0LL4 =A0-------- =A0 =A0 \
=A0 =A0 =A0 =A0 G1 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0G4


=A0 =A0 =A0 &q= uot;adhoc1" and "adhoc2": 802.11 ESSIDs in "ad-hoc"= ; mode.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Each is an IPv6 = subnet.
=A0 =A0 =A0 LL1...4: IPv6 link-local addresses.
=A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0Self-formed according to rfc2464.
=A0 =A0 =A0 G= 1, G4: ?
=A0
Host1 may be a Router I think.
This router=A0may be mobile router.i.e, NEMO.=A0
In disaster environment, this scenario is possible. Then, gateway will= use satelite channel.
Considering your case,=A0Host1 will get his address from the upper rou= ter (case 1)=A0or the gateway (case 2).
According to which case is configured, this network has other aspects.=
=A0
anyway,
=A0
Already, Teco described=A0satifactory aspects relation to this situati= on in previous message.
Do you also agree with his comments ?
=A0
Thanks,
Hyung-Jin, Lim


Alex

--001485f880e49474e00463e42d3e-- From teco@inf-net.nl Fri Feb 27 03:04:56 2009 Return-Path: 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 0ECB23A6C06 for ; Fri, 27 Feb 2009 03:04:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.786 X-Spam-Level: X-Spam-Status: No, score=-1.786 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] 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 IKcQgcxVYMnA for ; Fri, 27 Feb 2009 03:04:52 -0800 (PST) Received: from cpsmtpo-eml03.kpnxchange.com (cpsmtpo-eml03.KPNXCHANGE.COM [213.75.38.152]) by core3.amsl.com (Postfix) with ESMTP id 257A83A6AFD for ; Fri, 27 Feb 2009 03:04:51 -0800 (PST) Received: from cpsmtp-eml102.kpnxchange.com ([213.75.84.102]) by cpsmtpo-eml03.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 27 Feb 2009 12:05:13 +0100 Received: from M90Teco ([86.83.9.22]) by cpsmtp-eml102.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 27 Feb 2009 12:05:12 +0100 From: "Teco Boot" To: "'Alexandru Petrescu'" References: <499F0BA7.90501@piuha.net> <7E8A76F7-2CE0-463A-8EE8-8877C46B4715@gmail.com> <49A6D436.7020505@gmail.com> <000001c99845$1dc56190$595024b0$@nl> <49A6F125.40400@gmail.com> <1235680887.4585.5.camel@localhost> <49A7BB89.5040807@gmail.com> In-Reply-To: <49A7BB89.5040807@gmail.com> Date: Fri, 27 Feb 2009 12:05:12 +0100 Message-ID: <003901c998cb$42b71e90$c8255bb0$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcmYw06Ce19OAyBdSmioactd0GcudwABwljw Content-Language: nl X-OriginalArrivalTime: 27 Feb 2009 11:05:12.0683 (UTC) FILETIME=[43031BB0:01C998CB] Cc: autoconf@ietf.org Subject: Re: [Autoconf] new charter X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 11:04:56 -0000 Hi Alex, Let's try to be accurate: [skip] |Sorry... in the picture above the addresses are also /128. It was an |abbreviation for me to show only 2001:db8:1::1/64 assigned to Host1. |The full notation should have been 2001:db8:1::/64 prefix and |2001:db8:1::1/128. Would the following picture satisfy the need for |/128 addresses?: When prefix::/64 is assigned to a host, it configures a /64 address and not an /128 address. Routers may generate a /128 prefix-address, and advertize this in the routing domain. Some mechanisms should make sure the /128 routing prefix is unique, if required. It is not required if the prefix is meant as anycast address, routers may use "duplicate prefixes" if this is useful. I think anycast is out-of-scope for [Autoconf], but we should be careful when specifying "MUST" for prefix uniqueness. We should use "SHOULD" instead. Teco. From alexandru.petrescu@gmail.com Fri Feb 27 05:07:05 2009 Return-Path: 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 83AA13A6932 for ; Fri, 27 Feb 2009 05:07:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.884 X-Spam-Level: X-Spam-Status: No, score=-1.884 tagged_above=-999 required=5 tests=[AWL=-0.235, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_21=0.6] 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 1U0bP7T33tPP for ; Fri, 27 Feb 2009 05:07:04 -0800 (PST) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.166.172.106]) by core3.amsl.com (Postfix) with ESMTP id C6E913A6821 for ; Fri, 27 Feb 2009 05:07:03 -0800 (PST) Received: from nephilia.intra.cea.fr (nephilia.intra.cea.fr [132.166.88.33]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-1.2) with ESMTP id n1RD7P3i017632; Fri, 27 Feb 2009 14:07:25 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by nephilia.intra.cea.fr (8.13.8/8.13.8) with ESMTP id n1RD7OKu023761; Fri, 27 Feb 2009 14:07:25 +0100 (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 n1RD7OKC016064; Fri, 27 Feb 2009 14:07:24 +0100 Message-ID: <49A7E58C.2020303@gmail.com> Date: Fri, 27 Feb 2009 14:07:24 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Teco Boot References: <499F0BA7.90501@piuha.net> <7E8A76F7-2CE0-463A-8EE8-8877C46B4715@gmail.com> <49A6D436.7020505@gmail.com> <000001c99845$1dc56190$595024b0$@nl> <49A6F125.40400@gmail.com> <1235680887.4585.5.camel@localhost> <002f01c998bf$8f112210$ad336630$@nl> In-Reply-To: <002f01c998bf$8f112210$ad336630$@nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org Subject: Re: [Autoconf] Autoconf addressing model X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 13:07:05 -0000 Whoa, that's text Teco :-) Let me see where can I practically agree with you: Teco Boot a écrit : [...] > We could discuss and analyze the effect of adopting the /128 (or /32) prefix > lengths for MANET interfaces, but I prefer taking this option as last > resort. I fully agree with you. I find /128 prefix lengths for subnets to be a departure from the typical less-than-64 prefix lengths for subnets. It may even break networks. > I think there is a much more obvious option, using the RFC2464 model > for the MANET interface and /128 (or /32) for loopback interfaces. Both > would use high probability globally unique Interface IDs like EUI-64 > (Extended Unique Identifier). I don't agree going that way. I think loopback addresses are for self addressing not for talking to other nodes. [rfc4291 and 2464 citations] > It is not only because the RFC texts that I dislike the /128 in MANET > interfaces, it is also backward compatibility with current IP stacks (and > probably many applications). I agree. > I think using /128 for loopback interfaces fits the requirements for the > addressing model. If a loopback interface is used, MANET interfaces do not > require a globally unique address. I'm not sure I could agree with the MANET interface being the loopback interface. It sounds as a significant departure. > RFC4291 once more (out of section, also > cited above): > Unicast addresses with a > scope greater than link-scope are not needed for interfaces that are > not used as the origin or destination of any IPv6 packets to or from > non-neighbors. > So "host functionality" can be provided using the globally (or MANET local) > unique address assigned to a loopback address, or another non-MANET > interface. An address assigned to an address? I think it risks many misunderstandings. > This results in the following addressing model, where all nodes are routers: > > +-------+ wifi "adhoc1" +-------+ wifi "adhoc2" +-------+ > |Router1|>-------------<|Router2|>-------------<|Router3| > +---L---+ LL1 LL21 +---L---+ LL22 LL3 +---L---+ > |M1 |M2 |M3 > > "adhoc1" and "adhoc2": 802.11 SSIDs in "IBSS" mode. > Each IBSS is an IPv6 subnet. > > L: Loopback interface. > > >, <: MANET interface. The MANET interface is a loopback interface? I disagree. The loopback interface is needed for local inter-process communication, I don't want that to go on to the network. But, most importantly, why is there a need to add other special interfaces to the example pictured above? > LL1, LL21, LL22, LL3: IPv6 link-local addresses. > Self-formed according to rfc2464. > > M1, M2, M3: IPv6 MANET local addresses, for example > FD01:db8::1/128, FD01:db8::2/128 and FD01:db8::3/128. For my clarification, what's fd01? (2001:db8:: is a prefix for documentation rfc3849, ULA is fc00 rfc4193). > Manually assigned, or pre-configured (e.g. with SNMP) > or formed according to a to be defined [Autoconf for MANETs] > protocol, with a to-be-defined prefix (e.g. ULA, RFC4193). > > Although all nodes are marked as router, this does not imply all nodes > forward packets. All nodes run a MANET routing protocol for learning the > MANET topology. > > > In case one of the routers is connected to the Internet or private network, > this router can advertize a prefix in the MANET, and this information is > distributed in the MANET with an [Autoconf for MANETs] protocol. Why shouldn't it be distributed with DHCP and with OSPF, for example. > > Internet > | > | > +-------+-------+ > | Access Router | > +-------+-------+ > | > | | Prefix information > | V > | > +-------+ wifi "adhoc1" +---+---+ wifi "adhoc2" +-------+ > |Router1|>-------------<|Router2|>-------------<|Router3| > +---L---+ LL1 LL21 +---L---+ LL22 LL3 +---L---+ > |M1 |M2 |M3 > |G1 |G2 |G3 > <------- -------> > Prefix information Prefix information > > > G1, G2, G3: IPv6 globally unique addresses, for example > 2001:db8:G:1/128, 2001:db8:G:2/128 and 2001:db8:G:3/128. > Formed according to a to be defined [Autoconf for MANETs] > protocol, with the prefix provided by (via) the Access Router. Above, and in the following figures, I don't understand "--->, Prefix Information". Is that RA? Or OSPF? Or routing protocol? Or DHCP Prefix Delegation? > Multi-homing can easily be supported: maybe. Alex > > ---+-------Internet--------+--- > | | > | | > +-------+-------+ +-------+-------+ > |Access Router H| |Access Router G| > +-------+-------+ +-------+-------+ > | | > ||Prefix information H | |Prefix information G > |V | V > | | > +---+---+ wifi "adhoc1" +---+---+ wifi "adhoc2" +-------+ > |Router1|>-------------<|Router2|>-------------<|Router3| > +---L---+ LL1 LL21 +---L---+ LL22 LL3 +---L---+ > |M1 |M2 |M3 > |G1 |G2 |G3 > |H1 |H2 |H3 > <------- -------> > Prefix information G Prefix information G, H > ---------> > Prefix information H > > H1, H2, H3: IPv6 globally unique addresses, for example > 2001:db8:H:1/128, 2001:db8:H:2/128 and 2001:db8:H:3/128. > Formed according to a to be defined [Autoconf for MANETs] > protocol, with the prefix provided by (via) Access Router H. > > > Note that the impact of the number of interfaces is minimal, the address > configuration of Router2 is very similar to Router1 and Router3. Also, the > status of the MANET interface has no impact on communication in case of > multi-homing and redundant paths. (OK, we might need MIP6 / HIP / SHIM6 or > application layer address swapping mechanisms). > > It doesn't matter how many ad hoc segments there are. In the following > scenario, the link to Access router G disappeared, Router 3 disappeared and > a Router4 joined IBSS "adhoc1". > > > > ---+-------Internet------ > | > | > +-------+-------+ > |Access Router H| > +-------+-------+ > | > ||Prefix information H > |V wifi "adhoc1" > | <---------------------------v--------> > <------|--v----------------------> | > |<-|--------------------v-----------------------|---> > | | | | > +---+--'+ +---'---+ +---'---+ > |Router1|>-------------<|Router2|>-------------<|Router4| > +---L---+ LL1 LL21 +---L---+ LL22 LL4 +---L---+ > |M1 |M2 |M4 > |H1 |H2 |H4 > > ---------> ---------> > Prefix information H Prefix information H > > > Now, Router2 acts as a relay for Router4, so Router4 can reach Router1 and > the Internet. Router1 acts as Border Router for all nodes in the MANET. > > > I have some thoughts on IPv4 supports. Of course IPv4 misses lots of > flexibility that is used in above model. But there are ways to support it, > e.g. IPv4 link local (RFC3927) accompanied by some extended form of > duplicate address detection (passive checking routing tables). For globally > unique address assignment I think of DHCP-IPv4 over an IPv6 path, provided > as described above. (e.g. Router4 gets its /32 address for its loopback > interface from/via Access Router H, using M4 or H4 address and the IPv6 > MANET protocol. > > > Any comments? > Teco. > > > > |-----Oorspronkelijk bericht----- > |Van: Carlos Jesús Bernardos Cano [mailto:cjbc@it.uc3m.es] > |Verzonden: donderdag 26 februari 2009 21:41 > |Aan: Alexandru Petrescu > |CC: Teco Boot; autoconf@ietf.org > |Onderwerp: Re: [Autoconf] new charter > | > |Hi Alex: > | > | One question below. > | > |El jue, 26-02-2009 a las 20:44 +0100, Alexandru Petrescu escribió: > |> Sorry, I made an error indeed putting same prefix. How about this > |> updated picture with the prefixes being distinct: > |> > |> > |> ----- wifi "adhoc1" ------ wifi "adhoc2" ----- > |> |Host1|---------------|Router|---------------|Host2| > |> ----- LL1 LL2 ------ LL3 LL4 ----- > |> G1 G4 > |> > |> > |> "adhoc1" and "adhoc2": 802.11 ESSIDs in "ad-hoc" mode. > |> Each is an IPv6 subnet. > |> LL1...4: IPv6 link-local addresses. > |> Self-formed according to rfc2464. > |> G1, G4: IPv6 global addresses, for example > |> 2001:db8:1::1/64 and > |> 2001:db8:2::4/64 > |> Manually assigned, or pre-configured with SNMP > |> or formed according to stateless autoconf rfc4862; > |> the prefixes are advertised by Router in RAs. > |> > | > |Does this model only apply to Host-Router-Host scenarios? I mean, does > |this model apply for Router-Router-Router scenarios? I fully agree the > |model fits the first scenario, but I don't for the second, since > |routers' mobility within the ad-hoc network would force them to change > |prefixes often, I guess. For those scenarios it might be better to think > |of addressing models in which MANET routers are configured with /128 > |(or /32 for IPv4) addresses, so they don't need to change their > |addresses as a result of link changes. > | > |Kind Regards, > | > |Carlos > | > |-- > | Carlos Jesús Bernardos Cano http://www.netcoms.net > | GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 > |++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > | WEEDEV 2009: 2nd Workshop on Experimental Evaluation and > | Deployment Experiences on Vehicular networks > | http://www.weedev.org/ > |++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > From alexandru.petrescu@gmail.com Fri Feb 27 05:16:32 2009 Return-Path: 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 34F303A6847 for ; Fri, 27 Feb 2009 05:16:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.178 X-Spam-Level: X-Spam-Status: No, score=-2.178 tagged_above=-999 required=5 tests=[AWL=0.071, 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 j0Zw-uU+wPRN for ; Fri, 27 Feb 2009 05:16:31 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.1]) by core3.amsl.com (Postfix) with ESMTP id 39DC33A67E4 for ; Fri, 27 Feb 2009 05:16:31 -0800 (PST) Received: from nephilia.intra.cea.fr (nephilia.intra.cea.fr [132.166.88.33]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-1.2) with ESMTP id n1RDF6YU006901; Fri, 27 Feb 2009 14:15:06 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by nephilia.intra.cea.fr (8.13.8/8.13.8) with ESMTP id n1RDGoo2006210; Fri, 27 Feb 2009 14:16:50 +0100 (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 n1RDGn6H019050; Fri, 27 Feb 2009 14:16:49 +0100 Message-ID: <49A7E7C1.7080300@gmail.com> Date: Fri, 27 Feb 2009 14:16:49 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: HyungJin Lim References: <499F0BA7.90501@piuha.net> <7E8A76F7-2CE0-463A-8EE8-8877C46B4715@gmail.com> <49A6D436.7020505@gmail.com> <000001c99845$1dc56190$595024b0$@nl> <49A6F125.40400@gmail.com> <1235680887.4585.5.camel@localhost> <7e8d02d40902261737n1c21b136hd575b8afa8702188@mail.gmail.com> <49A7BC80.4000807@gmail.com> <7e8d02d40902270246k687c68d2t717e301041f8aa53@mail.gmail.com> In-Reply-To: <7e8d02d40902270246k687c68d2t717e301041f8aa53@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: Autoconf@ietf.org Subject: Re: [Autoconf] new charter X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 13:16:32 -0000 Hi Hyung-Jin, HyungJin Lim a écrit : [...] > Host1 may be a Router I think. This router may be mobile router.i.e, > NEMO. In disaster environment, this scenario is possible. Then, > gateway will use satelite channel. Considering your case, Host1 will > get his address from the upper router (case 1) or the gateway (case > 2). Something along these lines?: ------ wifi "adhoc1" ------ wifi "adhoc2" -------- Satelite / |NEMOMR|---------------|Router|---------------|Gatewway|--------Int'net ------ LL1 LL2 ------ LL3 LL4 -------- \ G1 G4 LL1...4: IPv6 link-local addresses. Self-formed according to rfc2464. G1: formed by NEMOMR either from RA sent by Router, or by DHCPv6 considering Router is a DHCPRelay and Gateway is a DHCPServer. G4: ? > According to which case is configured, this network has other > aspects. I agree. Alex > > anyway, > > Already, Teco described satifactory aspects relation to this > situation in previous message. Do you also agree with his comments ? > > Thanks, Hyung-Jin, Lim > > > Alex > > From alexandru.petrescu@gmail.com Fri Feb 27 05:23:51 2009 Return-Path: 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 901503A67FB for ; Fri, 27 Feb 2009 05:23:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.18 X-Spam-Level: X-Spam-Status: No, score=-2.18 tagged_above=-999 required=5 tests=[AWL=0.069, 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 gBoytYxzxawa for ; Fri, 27 Feb 2009 05:23:50 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.166.172.107]) by core3.amsl.com (Postfix) with ESMTP id 9C0053A67E1 for ; Fri, 27 Feb 2009 05:23:50 -0800 (PST) Received: from nephilia.intra.cea.fr (nephilia.intra.cea.fr [132.166.88.33]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-1.2) with ESMTP id n1RDOAnZ013349; Fri, 27 Feb 2009 14:24:10 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by nephilia.intra.cea.fr (8.13.8/8.13.8) with ESMTP id n1RDOAdM016166; Fri, 27 Feb 2009 14:24:10 +0100 (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 n1RDOAfD006397; Fri, 27 Feb 2009 14:24:10 +0100 Message-ID: <49A7E97A.2010503@gmail.com> Date: Fri, 27 Feb 2009 14:24:10 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Teco Boot References: <499F0BA7.90501@piuha.net> <7E8A76F7-2CE0-463A-8EE8-8877C46B4715@gmail.com> <49A6D436.7020505@gmail.com> <000001c99845$1dc56190$595024b0$@nl> <49A6F125.40400@gmail.com> <1235680887.4585.5.camel@localhost> <49A7BB89.5040807@gmail.com> <003901c998cb$42b71e90$c8255bb0$@nl> In-Reply-To: <003901c998cb$42b71e90$c8255bb0$@nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org Subject: Re: [Autoconf] new charter X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 13:23:51 -0000 Teco Boot a écrit : > Hi Alex, > > Let's try to be accurate: > > [skip] > |Sorry... in the picture above the addresses are also /128. It was an > |abbreviation for me to show only 2001:db8:1::1/64 assigned to Host1. > |The full notation should have been 2001:db8:1::/64 prefix and > |2001:db8:1::1/128. Would the following picture satisfy the need for > |/128 addresses?: > > When prefix::/64 is assigned to a host, it configures a /64 address and not > an /128 address. I'm not sure I understand. The prefix::/64 is typically assigned to a link, not to a host. If a host is connected to that link then it configures a /128 address and a /64 subnet prefix, both "128" and "64" numbers are visible in its tables. I don't understand why the need for /128 prefixes, why isn't the above /64-prefix-and-/128address not sufficient? > Routers may generate a /128 prefix-address, and advertize this in the > routing domain. A host-based route propagated and deleted throughout a domain? I don't see the necessity of doing so. Assuming the routers are mobile within 25m ranges then they wouldn't need to change their addresses, thus no need to propagate host-based routes. Do you agree we consider routers mobile only within 25m ranges? Alex > Some mechanisms should make sure the /128 routing prefix is unique, if > required. It is not required if the prefix is meant as anycast address, > routers may use "duplicate prefixes" if this is useful. I think anycast is > out-of-scope for [Autoconf], but we should be careful when specifying "MUST" > for prefix uniqueness. We should use "SHOULD" instead. > > Teco. > > > > From dream.hjlim@gmail.com Fri Feb 27 06:04:33 2009 Return-Path: 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 2991C3A6ABE for ; Fri, 27 Feb 2009 06:04:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, 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 UfY8znUewwDe for ; Fri, 27 Feb 2009 06:04:32 -0800 (PST) Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.186]) by core3.amsl.com (Postfix) with ESMTP id EE7FC3A69FC for ; Fri, 27 Feb 2009 06:04:31 -0800 (PST) Received: by ti-out-0910.google.com with SMTP id 11so1393442tim.25 for ; Fri, 27 Feb 2009 06:04:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=BUZQHKYAFjXw5MykfZFAPzbbVt/9J8LKGMhOfMDvemA=; b=DfKG4iCtIC67riIlVjj0fA3rEVPsi3kIxPsYnI0MozZhr7VPqpM8Dt8iVdweZ/x9Bj 0zEOGpkkByLkpuZum0WyjCKS0SndrINgVfKDbm88tUrZBvR97foVUUq7LqxDHm9a7cYd Li/4HvtDOk4Q6735iVEm7i+mYeYzZdkLsdFAA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=J8qvcOvwgm2fGSJvbO7Dh9DETU6pZgbQocZvsIM/85y2g8v6/qamG8beEryrydB29a ZMYwCCVv97q7OeDkF5tDwHe/pX4QxWQB1DNq+lh+5KrBlkgKhvJRazXWV2oyHDKbkYgE 3/8ffPGaC/msDhydQNPsiA2/7eqY4ykqe/qXA= MIME-Version: 1.0 Received: by 10.110.26.8 with SMTP id 8mr355830tiz.44.1235743493821; Fri, 27 Feb 2009 06:04:53 -0800 (PST) In-Reply-To: <49A7E7C1.7080300@gmail.com> References: <499F0BA7.90501@piuha.net> <7E8A76F7-2CE0-463A-8EE8-8877C46B4715@gmail.com> <49A6D436.7020505@gmail.com> <000001c99845$1dc56190$595024b0$@nl> <49A6F125.40400@gmail.com> <1235680887.4585.5.camel@localhost> <7e8d02d40902261737n1c21b136hd575b8afa8702188@mail.gmail.com> <49A7BC80.4000807@gmail.com> <7e8d02d40902270246k687c68d2t717e301041f8aa53@mail.gmail.com> <49A7E7C1.7080300@gmail.com> Date: Fri, 27 Feb 2009 23:04:53 +0900 Message-ID: <7e8d02d40902270604j2536a938je0cb1629627ebbe2@mail.gmail.com> From: HyungJin Lim To: Alexandru Petrescu Content-Type: multipart/alternative; boundary=001485f07c08fb93e10463e6f346 Cc: Autoconf@ietf.org Subject: Re: [Autoconf] new charter X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 14:04:33 -0000 --001485f07c08fb93e10463e6f346 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Alex, 2009/2/27 Alexandru Petrescu > Hi Hyung-Jin, > > HyungJin Lim a =E9crit : > [...] > >> Host1 may be a Router I think. This router may be mobile router.i.e, >> NEMO. In disaster environment, this scenario is possible. Then, >> gateway will use satelite channel. Considering your case, Host1 will >> get his address from the upper router (case 1) or the gateway (case >> 2). >> > > Something along these lines?: > > ------ wifi "adhoc1" ------ wifi "adhoc2" -------- Satelite / > |NEMOMR|---------------|Router|---------------|Gatewway|--------Int'net > ------ LL1 LL2 ------ LL3 LL4 -------- \ > G1 G4 > > LL1...4: IPv6 link-local addresses. > Self-formed according to rfc2464. > G1: formed by NEMOMR either from RA sent by Router, or by > DHCPv6 considering Router is a DHCPRelay and Gateway is > a DHCPServer. > G4: ? G4 is Router? or G4 is Gateway ? I guess G4 is located on the link to Gateway, in side of Router. First of all, Gateway now has topologically correct address(TCA) to Internet. Also, Router should have TCA by any address configuration mechanisms. For example, RA sent by Gateway, or any other address conf. mechanisms. Is it right ? Hyung-Jin, Lim > > > > According to which case is configured, this network has other >> aspects. >> > > I agree. > > Alex > > > >> anyway, >> >> Already, Teco described satifactory aspects relation to this >> situation in previous message. Do you also agree with his comments ? >> >> Thanks, Hyung-Jin, Lim >> >> >> Alex >> >> >> > > --001485f07c08fb93e10463e6f346 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Alex,

2009/2/27 Alexandru Petrescu &= lt;alexandru.petrescu@gmail= .com>
Hi Hyung-Jin,

HyungJin Li= m a =E9crit :
[...]=20

Host1 may be a Router I think. T= his router may be mobile router.i.e,
NEMO. In disaster environment, this= scenario is possible. Then,
gateway will use satelite channel. Considering your case, Host1 will
get= his address from the upper router (case 1) or the gateway (case
2).

Something along these lines?:

=A0------ =A0w= ifi "adhoc1" =A0------ =A0wifi "adhoc2" =A0-------- Sat= elite /
|NEMOMR|---------------|Router|---------------|Gatewway|--------Int'net=
=A0------ LL1 =A0 =A0 =A0 =A0 LL2 ------ LL3 =A0 =A0 =A0 =A0LL4 =A0----= ---- =A0 =A0 =A0 =A0 =A0\
=A0 =A0 =A0 =A0G1 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 G4

=A0 =A0 =A0 LL1...4: IPv6 link-local addresses.=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Self-formed according to rfc2464.
=A0 =A0 =A0 G1: formed by NEMOMR either from RA sent by Router, or by
= =A0 =A0 =A0 DHCPv6 considering Router is a DHCPRelay and Gateway is
=A0 =A0 =A0 a DHCPServer.
=A0 =A0 =A0 G4: ?
=A0
=A0=A0 G4 is Router? or G4 is Gateway ? I guess G4 is located on the l= ink to Gateway, in side of Router.
First of all, Gateway now has topologically correct address(TCA) to In= ternet.
Also, Router=A0should have=A0TCA by any address configuration mechanis= ms.
For example, RA sent by=A0Gateway, or=A0any other address conf. mechan= isms.
Is it right ?
=A0
Hyung-Jin, Lim
=A0



According to which case is confi= gured, this network has other
aspects.

I agree= .

Alex=20



anyway,

Already, Teco= described satifactory aspects relation to this
situation in previous me= ssage. Do you also agree with his comments ?

Thanks, Hyung-Jin, Lim


Alex




=

--001485f07c08fb93e10463e6f346-- From alexandru.petrescu@gmail.com Fri Feb 27 06:27:06 2009 Return-Path: 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 6A8193A6A75 for ; Fri, 27 Feb 2009 06:27:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.182 X-Spam-Level: X-Spam-Status: No, score=-2.182 tagged_above=-999 required=5 tests=[AWL=0.067, 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 Tt-oiP2WEYMO for ; Fri, 27 Feb 2009 06:27:05 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.1]) by core3.amsl.com (Postfix) with ESMTP id 702063A6902 for ; Fri, 27 Feb 2009 06:27:05 -0800 (PST) Received: from nephilia.intra.cea.fr (nephilia.intra.cea.fr [132.166.88.33]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-1.2) with ESMTP id n1REPfRJ013442; Fri, 27 Feb 2009 15:25:41 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by nephilia.intra.cea.fr (8.13.8/8.13.8) with ESMTP id n1REROSF022567; Fri, 27 Feb 2009 15:27:24 +0100 (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 n1REROE0027284; Fri, 27 Feb 2009 15:27:24 +0100 Message-ID: <49A7F84C.7030606@gmail.com> Date: Fri, 27 Feb 2009 15:27:24 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: HyungJin Lim References: <499F0BA7.90501@piuha.net> <7E8A76F7-2CE0-463A-8EE8-8877C46B4715@gmail.com> <49A6D436.7020505@gmail.com> <000001c99845$1dc56190$595024b0$@nl> <49A6F125.40400@gmail.com> <1235680887.4585.5.camel@localhost> <7e8d02d40902261737n1c21b136hd575b8afa8702188@mail.gmail.com> <49A7BC80.4000807@gmail.com> <7e8d02d40902270246k687c68d2t717e301041f8aa53@mail.gmail.com> <49A7E7C1.7080300@gmail.com> <7e8d02d40902270604j2536a938je0cb1629627ebbe2@mail.gmail.com> In-Reply-To: <7e8d02d40902270604j2536a938je0cb1629627ebbe2@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: Autoconf@ietf.org Subject: Re: [Autoconf] new charter X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 14:27:06 -0000 HyungJin Lim a écrit : > Hi Alex, > > 2009/2/27 Alexandru Petrescu > > > Hi Hyung-Jin, > > HyungJin Lim a écrit : > [...] > > Host1 may be a Router I think. This router may be mobile router.i.e, > NEMO. In disaster environment, this scenario is possible. Then, > gateway will use satelite channel. Considering your case, Host1 will > get his address from the upper router (case 1) or the gateway (case > 2). > > > Something along these lines?: > > ------ wifi "adhoc1" ------ wifi "adhoc2" -------- Satelite / > |NEMOMR|---------------|Router|---------------|Gatewway|--------Int'net > ------ LL1 LL2 ------ LL3 LL4 -------- \ > G1 G4 > > LL1...4: IPv6 link-local addresses. > Self-formed according to rfc2464. > G1: formed by NEMOMR either from RA sent by Router, or by > DHCPv6 considering Router is a DHCPRelay and Gateway is > a DHCPServer. > G4: ? > > > G4 is Router? or G4 is Gateway ? G4 denotes the Global address of the Gateway, on the wifi "adhoc2" subnet. > I guess G4 is located on the link to > Gateway, in side of Router. > First of all, Gateway now has topologically correct address(TCA) to > Internet. Yes, Gateway has a topologically-correct address, TCA if you wish; on its Satelite interface. > Also, Router should have TCA by any address configuration mechanisms. Why should Router have a TCA? > For example, RA sent by Gateway, or any other address conf. mechanisms. > Is it right ? I'm not sure why the intermediary Router should have any other address than its link-local addresses. Alex From dream.hjlim@gmail.com Fri Feb 27 06:45:25 2009 Return-Path: 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 D5CFD3A6A0B for ; Fri, 27 Feb 2009 06:45:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.498 X-Spam-Level: X-Spam-Status: No, score=-2.498 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, 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 WbkYgj+crq2o for ; Fri, 27 Feb 2009 06:45:24 -0800 (PST) Received: from mail-ew0-f177.google.com (mail-ew0-f177.google.com [209.85.219.177]) by core3.amsl.com (Postfix) with ESMTP id 504E33A6452 for ; Fri, 27 Feb 2009 06:45:24 -0800 (PST) Received: by ewy25 with SMTP id 25so1223651ewy.37 for ; Fri, 27 Feb 2009 06:45:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=861E8NWYC6qTk7lygDAf0NgxMhFhmYnQm2JvcElBxlI=; b=OuA5ECww317ptlDTyo82/jqb1kT30Hv27EldVevzJ096sYvRDERwzAPfbzNFzM+I8v fscH9G8wZPOmCVa5NY7cf+ClsnYHEERK41zeepHoGXwMgsOhtNELyaLErMzSDBEMT4yR wLXTgLrqVEkVWKigQndIwc5hRfE3Pv3Ip9J2I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Ybd0yQ5Dt6sMIQtMThYcFJFAX+JahsQqk3nnxzX5idEa9JpiD+9ri2Xc8t/Os3poVz +fAVZeAAFJh0HkwRBFc36J0E0cLz+M27CCpWmp0z843IoAAbNpBxzSOMSDCr7Rdc5NRh gZMdxMxkR7hJ47JVmvkXuR+Ezk6vE8joCjgZE= MIME-Version: 1.0 Received: by 10.110.84.7 with SMTP id h7mr3731590tib.53.1235745943967; Fri, 27 Feb 2009 06:45:43 -0800 (PST) In-Reply-To: <49A7F84C.7030606@gmail.com> References: <499F0BA7.90501@piuha.net> <000001c99845$1dc56190$595024b0$@nl> <49A6F125.40400@gmail.com> <1235680887.4585.5.camel@localhost> <7e8d02d40902261737n1c21b136hd575b8afa8702188@mail.gmail.com> <49A7BC80.4000807@gmail.com> <7e8d02d40902270246k687c68d2t717e301041f8aa53@mail.gmail.com> <49A7E7C1.7080300@gmail.com> <7e8d02d40902270604j2536a938je0cb1629627ebbe2@mail.gmail.com> <49A7F84C.7030606@gmail.com> Date: Fri, 27 Feb 2009 23:45:43 +0900 Message-ID: <7e8d02d40902270645n6101f745tfca6d41302afadf8@mail.gmail.com> From: HyungJin Lim To: Alexandru Petrescu Content-Type: multipart/alternative; boundary=0016e652062005d88c0463e7867a Cc: Autoconf@ietf.org Subject: Re: [Autoconf] new charter X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 14:45:25 -0000 --0016e652062005d88c0463e7867a Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 2009/2/27 Alexandru Petrescu > HyungJin Lim a =E9crit : > >> Hi Alex, >> >> 2009/2/27 Alexandru Petrescu > alexandru.petrescu@gmail.com>> >> >> Hi Hyung-Jin, >> >> HyungJin Lim a =E9crit : >> [...] >> >> Host1 may be a Router I think. This router may be mobile >> router.i.e, >> NEMO. In disaster environment, this scenario is possible. Then, >> gateway will use satelite channel. Considering your case, Host1 >> will >> get his address from the upper router (case 1) or the gateway (ca= se >> 2). >> >> >> Something along these lines?: >> >> ------ wifi "adhoc1" ------ wifi "adhoc2" -------- Satelite / >> |NEMOMR|---------------|Router|---------------|Gatewway|--------Int'n= et >> ------ LL1 LL2 ------ LL3 LL4 -------- \ >> G1 G4 >> >> LL1...4: IPv6 link-local addresses. >> Self-formed according to rfc2464. >> G1: formed by NEMOMR either from RA sent by Router, or by >> DHCPv6 considering Router is a DHCPRelay and Gateway is >> a DHCPServer. >> G4: ? >> G4 is Router? or G4 is Gateway ? >> > > G4 denotes the Global address of the Gateway, on the wifi "adhoc2" subnet= . > > I guess G4 is located on the link to Gateway, in side of Router. >> First of all, Gateway now has topologically correct address(TCA) to >> Internet. >> > > Yes, Gateway has a topologically-correct address, TCA if you wish; on its > Satelite interface. > > Also, Router should have TCA by any address configuration mechanisms. >> > > Why should Router have a TCA? > Is the Router fixed one ? I think "no". Do you assume this router only ha= s a function for packet routing ? I don't think so. This router also should b= e managed from remote location in any case. In realistic MANET environment, exactly, mesh network, this router can have some roles as host I think. I think we consider MANET-like situation. > > > For example, RA sent by Gateway, or any other address conf. mechanisms. >> Is it right ? >> > > I'm not sure why the intermediary Router should have any other address th= an > its link-local addresses. > Please refers to the above my opinion. Hyung-Jin Lim > > Alex > > > --0016e652062005d88c0463e7867a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

2009/2/27 Alexandru Petrescu &= lt;alexandru.petrescu@gmail= .com>
HyungJin Lim a =E9crit :
Hi Alex,

2009/2/27 Alexan= dru Petrescu <alexandru.petrescu@gmail.com <mailto:alexandru.petrescu@gmail.com= >>=20


=A0 =A0Hi Hyung-Jin,

=A0 =A0HyungJin L= im a =E9crit :
=A0 =A0[...]

=A0 =A0 =A0 =A0Host1 may be a Router = I think. This router may be mobile router.i.e,
=A0 =A0 =A0 =A0NEMO. In d= isaster environment, this scenario is possible. Then,
=A0 =A0 =A0 =A0gateway will use satelite channel. Considering your case, Ho= st1 will
=A0 =A0 =A0 =A0get his address from the upper router (case 1) o= r the gateway (case
=A0 =A0 =A0 =A02).


=A0 =A0Something along= these lines?:

=A0 =A0 ------ =A0wifi "adhoc1" =A0------ = =A0wifi "adhoc2" =A0-------- Satelite /
=A0 =A0|NEMOMR|---------------|Router|---------------|Gatewway|--------Int&= #39;net
=A0 =A0 ------ LL1 =A0 =A0 =A0 =A0 LL2 ------ LL3 =A0 =A0 =A0 = =A0LL4 =A0-------- =A0 =A0 =A0 =A0 =A0\
=A0 =A0 =A0 =A0 =A0 G1 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 G4

=A0 =A0 = =A0 =A0 =A0LL1...4: IPv6 link-local addresses.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Self-formed according to rfc2464.
= =A0 =A0 =A0 =A0 =A0G1: formed by NEMOMR either from RA sent by Router, or b= y
=A0 =A0 =A0 =A0 =A0DHCPv6 considering Router is a DHCPRelay and Gatewa= y is
=A0 =A0 =A0 =A0 =A0a DHCPServer.
=A0 =A0 =A0 =A0 =A0G4: ?
=A0 =A0 G4 is Router? or G4 is Gateway ?

G4 denot= es the Global address of the Gateway, on the wifi "adhoc2" subnet= .=20


I guess G4 is located on the lin= k to Gateway, in side of Router.
First of all, Gateway now has topologic= ally correct address(TCA) to Internet.

Yes, Gateway has a topologically-correct address, TC= A if you wish; on its Satelite =A0interface.=20


Also, Router should have TCA by = any address configuration mechanisms.

Why should = Router have a TCA?=20
=A0
=A0 Is the Router fixed one ? I think "no". Do you assume th= is router only has a function for packet routing ? I don't think so. Th= is router also should be managed from remote location in any case.=A0
In realistic MANET=A0environment, exactly, mesh network, this router c= an have some roles as host I think.
=A0
I think we consider MANET-like situation.
=A0


For example, RA sent by Gateway,= or any other address conf. mechanisms.
Is it right ?
I'm not sure why the intermediary Router should have any other ad= dress than its link-local addresses.
=A0
Please refers to the above my opinion.
=A0
Hyung-Jin Lim
=A0

Alex


--0016e652062005d88c0463e7867a-- From alexandru.petrescu@gmail.com Fri Feb 27 06:58:26 2009 Return-Path: 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 6EA703A6882 for ; Fri, 27 Feb 2009 06:58:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.183 X-Spam-Level: X-Spam-Status: No, score=-2.183 tagged_above=-999 required=5 tests=[AWL=0.066, 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 bQqxFqCnZrZH for ; Fri, 27 Feb 2009 06:58:25 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.166.172.107]) by core3.amsl.com (Postfix) with ESMTP id 686503A6452 for ; Fri, 27 Feb 2009 06:58:25 -0800 (PST) Received: from nephilia.intra.cea.fr (nephilia.intra.cea.fr [132.166.88.33]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-1.2) with ESMTP id n1REwjeg018478; Fri, 27 Feb 2009 15:58:45 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by nephilia.intra.cea.fr (8.13.8/8.13.8) with ESMTP id n1REwiHC004369; Fri, 27 Feb 2009 15:58:45 +0100 (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 n1REwi5M004902; Fri, 27 Feb 2009 15:58:44 +0100 Message-ID: <49A7FFA4.9000101@gmail.com> Date: Fri, 27 Feb 2009 15:58:44 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: HyungJin Lim References: <499F0BA7.90501@piuha.net> <000001c99845$1dc56190$595024b0$@nl> <49A6F125.40400@gmail.com> <1235680887.4585.5.camel@localhost> <7e8d02d40902261737n1c21b136hd575b8afa8702188@mail.gmail.com> <49A7BC80.4000807@gmail.com> <7e8d02d40902270246k687c68d2t717e301041f8aa53@mail.gmail.com> <49A7E7C1.7080300@gmail.com> <7e8d02d40902270604j2536a938je0cb1629627ebbe2@mail.gmail.com> <49A7F84C.7030606@gmail.com> <7e8d02d40902270645n6101f745tfca6d41302afadf8@mail.gmail.com> In-Reply-To: <7e8d02d40902270645n6101f745tfca6d41302afadf8@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: Autoconf@ietf.org Subject: Re: [Autoconf] new charter X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 14:58:26 -0000 ------ wifi "adhoc1" ------ wifi "adhoc2" -------- Satelite / |NEMOMR|---------------|Router|---------------|Gatewway|--------Int'net ------ LL1 LL2 ------ LL3 LL4 -------- TCA \ G1 G4 LL1...4: IPv6 link-local addresses. Self-formed according to rfc2464. G1: address formed by NEMOMR either from RA sent by Router, or by DHCPv6 considering Router is a DHCPRelay and Gateway is a DHCPServer. G4: ? TCA: Topologically-Correct Address, for Gateway. It can be manually configured on Gateway, or DHCP, or stateless autoconf. HyungJin Lim a écrit : >> Why should Router have a TCA? > > > Is the Router fixed one ? I think "no". Right - Router is not fixed: it can move in a circular area of radius 25m. No more than that. Is this sufficient? > Do you assume this router only has a function for packet routing ? Mostly yes. > I don't think so. This router also should be managed from remote > location in any case. In realistic MANET environment, exactly, mesh > network, this router can have some roles as host I think. Ok, Router should be contacted from the Internet. Then we should find some practical way to configure G addresses for Router too. I'm not sure how to come up with G addresses for Router, for the above topology. I'm not sure how to configure G4 on Gateway either. Alex > I think we consider MANET-like situation. > > > > For example, RA sent by Gateway, or any other address conf. > mechanisms. > Is it right ? > > > I'm not sure why the intermediary Router should have any other > address than its link-local addresses. > > > Please refers to the above my opinion. > > Hyung-Jin Lim > > > > Alex > > > From dream.hjlim@gmail.com Fri Feb 27 07:04:38 2009 Return-Path: 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 1F92B3A6966 for ; Fri, 27 Feb 2009 07:04:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.523 X-Spam-Level: X-Spam-Status: No, score=-2.523 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, 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 d2kSuIzkTxoE for ; Fri, 27 Feb 2009 07:04:37 -0800 (PST) Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.189]) by core3.amsl.com (Postfix) with ESMTP id C1CF13A67D4 for ; Fri, 27 Feb 2009 07:04:36 -0800 (PST) Received: by ti-out-0910.google.com with SMTP id 11so1423081tim.25 for ; Fri, 27 Feb 2009 07:04:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=1VndKXUEO6krRxZqa+Py51jxmYv5MU6y2z+7GcCQDr4=; b=rHz2FLXExbXbVRIQFPKf8YrCPjZ7lOaqGWwAXirBWles78M7BN+7Db6SZ4BYj9O1NE m4f0WNAoEZIulQBtOQvHTizbEdTjh1GZpQK2jbj96/81lY+OkGoBRlw1znn1E1w8LClm cOQpwweb32kLOnUT614+UwQTngr8LEKdQUNDA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=c4G4wXEjtbfGKJAx03NdLhJDio6h1gLct2K6Wky2Rz2Mt4mjhGF2rLVE0e6dmwzg0V pCAtcboR2g4P1VUUey5byAj5u6WZfDutmFEmEXxAtrLY7wLg5BLn59FvBwapcA6ZqlcX 4zW7sk3jpryex1Wh27Q58njUhPDQjKOnRD1cI= MIME-Version: 1.0 Received: by 10.110.43.18 with SMTP id q18mr3819337tiq.3.1235747098777; Fri, 27 Feb 2009 07:04:58 -0800 (PST) In-Reply-To: <49A7FFA4.9000101@gmail.com> References: <499F0BA7.90501@piuha.net> <1235680887.4585.5.camel@localhost> <7e8d02d40902261737n1c21b136hd575b8afa8702188@mail.gmail.com> <49A7BC80.4000807@gmail.com> <7e8d02d40902270246k687c68d2t717e301041f8aa53@mail.gmail.com> <49A7E7C1.7080300@gmail.com> <7e8d02d40902270604j2536a938je0cb1629627ebbe2@mail.gmail.com> <49A7F84C.7030606@gmail.com> <7e8d02d40902270645n6101f745tfca6d41302afadf8@mail.gmail.com> <49A7FFA4.9000101@gmail.com> Date: Sat, 28 Feb 2009 00:04:58 +0900 Message-ID: <7e8d02d40902270704o178a97e2m3a84db23708ac4c4@mail.gmail.com> From: HyungJin Lim To: Alexandru Petrescu Content-Type: multipart/alternative; boundary=001485f07c0cdad8880463e7cad0 Cc: Autoconf@ietf.org Subject: Re: [Autoconf] new charter X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 15:04:38 -0000 --001485f07c0cdad8880463e7cad0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 2009/2/27 Alexandru Petrescu > ------ wifi "adhoc1" ------ wifi "adhoc2" -------- Satelite / > |NEMOMR|---------------|Router|---------------|Gatewway|--------Int'net > ------ LL1 LL2 ------ LL3 LL4 -------- TCA \ > G1 G4 > > LL1...4: IPv6 link-local addresses. > Self-formed according to rfc2464. > G1: address formed by NEMOMR either from RA sent by Router, or > by DHCPv6 considering Router is a DHCPRelay and Gateway is > a DHCPServer. > G4: ? > TCA: Topologically-Correct Address, for Gateway. It can be > manually configured on Gateway, or DHCP, or stateless > autoconf. > > HyungJin Lim a =E9crit : > >> Why should Router have a TCA? >>> >> >> >> Is the Router fixed one ? I think "no". >> > > Right - Router is not fixed: it can move in a circular area of radius > 25m. No more than that. Is this sufficient? > > Do you assume this router only has a function for packet routing ? >> > > Mostly yes. > > I don't think so. This router also should be managed from remote location >> in any case. In realistic MANET environment, exactly, mesh network, this >> router can have some roles as host I think. >> > > Ok, Router should be contacted from the Internet. Then we should find so= me > practical way to configure G addresses for Router too. I'm not sure how t= o > come up with G addresses for Router, for the above topology. > > I'm not sure how to configure G4 on Gateway either. If the gateway has one hop distance from the router, and has IPv6 capability, then, the router can get TCA from the gateway I think. This operation is the basic operation. Is it right ? Hyung-Jin, Lim > > > Alex > > > I think we consider MANET-like situation. >> >> >> >> For example, RA sent by Gateway, or any other address conf. >> mechanisms. >> Is it right ? >> >> >> I'm not sure why the intermediary Router should have any other >> address than its link-local addresses. >> >> Please refers to the above my opinion. >> Hyung-Jin Lim >> >> >> Alex >> >> >> >> > > --001485f07c0cdad8880463e7cad0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

2009/2/27 Alexandru Petrescu &= lt;alexandru.petrescu@gmail= .com>
=A0------ =A0wifi "adhoc1" =A0------ =A0wif= i "adhoc2" =A0-------- Satelite /
|NEMOMR|---------------|Rout= er|---------------|Gatewway|--------Int'net
=A0------ LL1 =A0 = =A0 =A0 =A0 LL2 ------ LL3 =A0 =A0 =A0 =A0LL4 =A0-------- =A0TCA =A0 =A0 \= =20

=A0 =A0 =A0 =A0G1 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 G4

=A0 =A0 =A0 LL1...4: IPv6 link-l= ocal addresses.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Self-formed according to = rfc2464.
=A0 =A0 =A0 G1: address formed by NEMOMR either from RA s= ent by Router, or=20

=A0 =A0 =A0 =A0 =A0 by DHCPv6 considering Router = is a DHCPRelay and Gateway is
=A0 =A0 =A0 =A0 =A0 a DHCPServer.
=A0 = =A0 =A0 G4: ?
=A0 =A0 =A0 TCA: Topologically-Correct Address, for = Gateway. =A0It can be
=A0 =A0 =A0 =A0 =A0 =A0manually configured on Gate= way, or DHCP, or stateless
=A0 =A0 =A0 =A0 =A0 =A0autoconf.

HyungJin Lim a =E9crit :=20

Why should Router have a TCA?


Is the Router fixed one ? I think "no".

Right - Router is not fixed: it can move in a circul= ar area of radius
25m. No more than that. Is this sufficient?=20


Do you assume this router only h= as a function for packet routing ?

Mostly yes.=20


I don't think so. This route= r also should be managed from remote location in any case. In realistic MAN= ET environment, exactly, mesh network, this router can have some roles as h= ost I think.

Ok, Router should be contacted from the Internet. = =A0Then we should find some practical way to configure G addresses for Rout= er too. I'm not sure how to come up with G addresses for Router, for th= e above topology.

I'm not sure how to configure G4 on Gateway either.
=A0
=A0 If the gateway has one hop distance from the router, and has IPv6 = capability,
=A0then, the router can get TCA from the gateway I think.
This operation is the basic operation.
=A0Is it right ?
=A0
Hyung-Jin, Lim


Ale= x=20


I think we consider MANET-like s= ituation.



=A0 =A0 =A0 =A0For example, RA sent by Gateway, or= any other address conf.
=A0 =A0 =A0 =A0mechanisms.
=A0 =A0 =A0 =A0Is it right ?


=A0 = =A0I'm not sure why the intermediary Router should have any other
= =A0 =A0address than its link-local addresses.

=A0Please refers to th= e above my opinion.
=A0Hyung-Jin Lim
=A0

=A0 =A0Alex






--001485f07c0cdad8880463e7cad0-- From alexandru.petrescu@gmail.com Fri Feb 27 07:18:27 2009 Return-Path: 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 D0EF53A694A for ; Fri, 27 Feb 2009 07:18:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.185 X-Spam-Level: X-Spam-Status: No, score=-2.185 tagged_above=-999 required=5 tests=[AWL=0.064, 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 nPIBd0VxVTGw for ; Fri, 27 Feb 2009 07:18:27 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.1]) by core3.amsl.com (Postfix) with ESMTP id CE1993A692A for ; Fri, 27 Feb 2009 07:18:26 -0800 (PST) Received: from nephilia.intra.cea.fr (nephilia.intra.cea.fr [132.166.88.33]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-1.2) with ESMTP id n1RFH2uw029487; Fri, 27 Feb 2009 16:17:02 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by nephilia.intra.cea.fr (8.13.8/8.13.8) with ESMTP id n1RFIkIi005442; Fri, 27 Feb 2009 16:18:47 +0100 (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 n1RFIk3Z011972; Fri, 27 Feb 2009 16:18:46 +0100 Message-ID: <49A80456.5080207@gmail.com> Date: Fri, 27 Feb 2009 16:18:46 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: HyungJin Lim References: <499F0BA7.90501@piuha.net> <1235680887.4585.5.camel@localhost> <7e8d02d40902261737n1c21b136hd575b8afa8702188@mail.gmail.com> <49A7BC80.4000807@gmail.com> <7e8d02d40902270246k687c68d2t717e301041f8aa53@mail.gmail.com> <49A7E7C1.7080300@gmail.com> <7e8d02d40902270604j2536a938je0cb1629627ebbe2@mail.gmail.com> <49A7F84C.7030606@gmail.com> <7e8d02d40902270645n6101f745tfca6d41302afadf8@mail.gmail.com> <49A7FFA4.9000101@gmail.com> <7e8d02d40902270704o178a97e2m3a84db23708ac4c4@mail.gmail.com> In-Reply-To: <7e8d02d40902270704o178a97e2m3a84db23708ac4c4@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: Autoconf@ietf.org Subject: Re: [Autoconf] new charter X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 15:18:27 -0000 ------ wifi "adhoc1" ------ wifi "adhoc2" -------- Satelite / |NEMOMR|---------------|Router|---------------|Gatewway|--------Int'net ------ LL1 LL2 ------ LL3 LL4 -------- TCA1 \ G1 G4 LL1...4: IPv6 link-local addresses. Self-formed according to rfc2464. G1: address formed by NEMOMR either from RA sent by Router, or by DHCPv6 considering Router is a DHCPRelay and Gateway is a DHCPServer. G4: ? TCA: Topologically-Correct Address, for Gateway. It can be manually configured on Gateway, or DHCP, or stateless autoconf. HyungJin Lim a écrit : > If the gateway has one hop distance from the router, and has IPv6 > capability, then, the router can get TCA from the gateway I think. Yes, it could. But in that case we should come up with a means for Gateway to obtain not only a TCA1 from the Internet but additionally an entire prefix. Out of this prefix Gateway could form its G4 and put it in RA, and finally Router forms its G address (TCA2 let's say). Without that prefix Router couldn't get a TCA2 from Gateway. (Now I realize that by "G" and "TCA" we actually mean the same thing; we should use just one.) Alex > This operation is the basic operation. > Is it right ? > > Hyung-Jin, Lim > > > > Alex > > > I think we consider MANET-like situation. > > > > For example, RA sent by Gateway, or any other address conf. > mechanisms. > Is it right ? > > > I'm not sure why the intermediary Router should have any other > address than its link-local addresses. > > Please refers to the above my opinion. > Hyung-Jin Lim > > > Alex > > > > > > From teco@inf-net.nl Fri Feb 27 09:01:17 2009 Return-Path: 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 6C15528C2B0 for ; Fri, 27 Feb 2009 09:01:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.91 X-Spam-Level: X-Spam-Status: No, score=-0.91 tagged_above=-999 required=5 tests=[AWL=-0.664, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_54=0.6, J_CHICKENPOX_55=0.6, J_CHICKENPOX_56=0.6] 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 XyCMEosz2Ku3 for ; Fri, 27 Feb 2009 09:01:16 -0800 (PST) Received: from cpsmtpo-eml06.kpnxchange.com (cpsmtpo-eml06.KPNXCHANGE.COM [213.75.38.155]) by core3.amsl.com (Postfix) with ESMTP id 54EBE28C268 for ; Fri, 27 Feb 2009 09:01:16 -0800 (PST) Received: from cpsmtp-eml101.kpnxchange.com ([213.75.84.101]) by cpsmtpo-eml06.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 27 Feb 2009 18:01:27 +0100 Received: from M90Teco ([86.83.9.22]) by cpsmtp-eml101.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 27 Feb 2009 18:01:27 +0100 From: "Teco Boot" To: "'Alexandru Petrescu'" References: <499F0BA7.90501@piuha.net> <7E8A76F7-2CE0-463A-8EE8-8877C46B4715@gmail.com> <49A6D436.7020505@gmail.com> <000001c99845$1dc56190$595024b0$@nl> <49A6F125.40400@gmail.com> <1235680887.4585.5.camel@localhost> <49A7BB89.5040807@gmail.com> <003901c998cb$42b71e90$c8255bb0$@nl> <49A7E97A.2010503@gmail.com> In-Reply-To: <49A7E97A.2010503@gmail.com> Date: Fri, 27 Feb 2009 18:01:26 +0100 Message-ID: <006801c998fd$06c5bd60$14513820$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcmY3q9rlv3+S0D1TIK9du4CoUA55wAD/Kow Content-Language: nl X-OriginalArrivalTime: 27 Feb 2009 17:01:27.0128 (UTC) FILETIME=[072C9580:01C998FD] Cc: autoconf@ietf.org Subject: Re: [Autoconf] new charter X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 17:01:17 -0000 Inline. |-----Oorspronkelijk bericht----- |Van: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] |Verzonden: vrijdag 27 februari 2009 14:24 |Aan: Teco Boot |CC: 'Alexandru Petrescu'; autoconf@ietf.org |Onderwerp: Re: [Autoconf] new charter | |Teco Boot a =E9crit : |> Hi Alex, |> |> Let's try to be accurate: |> |> [skip] |> |Sorry... in the picture above the addresses are also /128. It was = an |> |abbreviation for me to show only 2001:db8:1::1/64 assigned to Host1. |> |The full notation should have been 2001:db8:1::/64 prefix and |> |2001:db8:1::1/128. Would the following picture satisfy the need for |> |/128 addresses?: |> |> When prefix::/64 is assigned to a host, it configures a /64 address |and not |> an /128 address. | |I'm not sure I understand. | |The prefix::/64 is typically assigned to a link, not to a host. If a |host is connected to that link then it configures a /128 address and a |/64 subnet prefix, both "128" and "64" numbers are visible in its |tables. | |I don't understand why the need for /128 prefixes, why isn't the above |/64-prefix-and-/128address not sufficient? This is interesting. I meant generating an address in the /64 prefix. I don't know what is specified in RFCs. I checked behavior on Vista,=20 Linux and IOS:=20 o Linux (debian lenny) adds a /128 prefix in the routing table, to=20 the loopback interface, similar to what I propose in my addressing=20 model mail. It also adds a /64 address-prefix to the Ethernet = interface this is a bit weird, as two interfaces has the same address = configured. o Vista assigns addresses to the Ethernet interface (in my case), and adds /128 prefixes in the routing table. Vista also adds the=20 /64 in the routing table. o IOS behavior is as Vista, addresses to interfaces and /128 in=20 routing table. Details on Linux behavior: the /64 are on Ethernet (eth0) and the /128=20 are on loopback (lo). # ifconfig lo | egrep 'inet6|encap' lo Link encap:Local Loopback =20 inet6 addr: ::1/128 Scope:Host # netstat -6rn | grep 128 ::1/128 :: Un 0 1 17 lo 2001:db8:1:0:20c:29ff:fee3:bdf5/128 :: Un 0 1 11 lo fe80::20c:29ff:fee3:bdf5/128 :: Un 0 1 3 lo fe80::20c:29ff:fee3:bdff/128 :: Un 0 1 0 lo # ifconfig eth0 | egrep 'inet6|encap' eth0 Link encap:Ethernet HWaddr 00:0c:29:e3:bd:f5 =20 inet6 addr: 2001:db8:1:0:20c:29ff:fee3:bdf5/64 Scope:Global inet6 addr: fe80::20c:29ff:fee3:bdf5/64 Scope:Link # netstat -6rn | grep 64=20 2001:db8:1::/64 :: UAe 256 0 15 eth0 fe80::/64 :: U 256 0 0 eth0 fe80::/64 :: U 256 0 0 eth1 Conclusion: I was wrong with my statement. Linux behaves as I mentioned, = other IPv6 stacks have different characteristics. |> Routers may generate a /128 prefix-address, and advertize this in the |> routing domain. | |A host-based route propagated and deleted throughout a domain? I don't |see the necessity of doing so. Assuming the routers are mobile within |25m ranges then they wouldn't need to change their addresses, thus no |need to propagate host-based routes. If the /128 is not propagated, there will be no multi-hop network. In a MANET, I expect nodes to run a MANET Routing protocol and forward = packets. In ad hoc networks, one (you ?) would say nodes could be hosts or Mobile Routers acting as hosts.=20 |Do you agree we consider routers mobile only within 25m ranges? Absolutely not. For me, 25km is a reasonable distance! Just 10^3 times = the distance and 10^6 times the power per bit (single hop) or 10^3 times the power per bit if multi-hop is enabled (and 1000 intermediate nodes....). Just physical laws here. Teco. |Alex | |> Some mechanisms should make sure the /128 routing prefix is unique, = if |> required. It is not required if the prefix is meant as anycast |address, |> routers may use "duplicate prefixes" if this is useful. I think |anycast is |> out-of-scope for [Autoconf], but we should be careful when specifying |"MUST" |> for prefix uniqueness. We should use "SHOULD" instead. |> |> Teco. |> |> |> |> From alexandru.petrescu@gmail.com Fri Feb 27 09:44:32 2009 Return-Path: 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 EC98A3A6A1D for ; Fri, 27 Feb 2009 09:44:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.186 X-Spam-Level: X-Spam-Status: No, score=-2.186 tagged_above=-999 required=5 tests=[AWL=0.063, 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 mo8yya56Ncdd for ; Fri, 27 Feb 2009 09:44:32 -0800 (PST) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.166.172.106]) by core3.amsl.com (Postfix) with ESMTP id 02A883A67A3 for ; Fri, 27 Feb 2009 09:44:31 -0800 (PST) Received: from nephilia.intra.cea.fr (nephilia.intra.cea.fr [132.166.88.33]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-1.2) with ESMTP id n1RHir36000825; Fri, 27 Feb 2009 18:44:53 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by nephilia.intra.cea.fr (8.13.8/8.13.8) with ESMTP id n1RHir8l031663; Fri, 27 Feb 2009 18:44:53 +0100 (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 n1RHirkt011727; Fri, 27 Feb 2009 18:44:53 +0100 Message-ID: <49A82694.8090801@gmail.com> Date: Fri, 27 Feb 2009 18:44:52 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Teco Boot References: <499F0BA7.90501@piuha.net> <7E8A76F7-2CE0-463A-8EE8-8877C46B4715@gmail.com> <49A6D436.7020505@gmail.com> <000001c99845$1dc56190$595024b0$@nl> <49A6F125.40400@gmail.com> <1235680887.4585.5.camel@localhost> <49A7BB89.5040807@gmail.com> <003901c998cb$42b71e90$c8255bb0$@nl> <49A7E97A.2010503@gmail.com> <006801c998fd$06c5bd60$14513820$@nl> In-Reply-To: <006801c998fd$06c5bd60$14513820$@nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org Subject: Re: [Autoconf] practical addressing (was: new charter) X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 17:44:33 -0000 [Thanks for the details Linux/Vista/IOS routing tables! I didn't know all that, only for linux] Teco Boot a écrit : >>> Routers may generate a /128 prefix-address, and advertize this in >>> the routing domain. > >> A host-based route propagated and deleted throughout a domain? I >> don't see the necessity of doing so. Assuming the routers are >> mobile within 25m ranges then they wouldn't need to change their >> addresses, thus no need to propagate host-based routes. > > If the /128 is not propagated, there will be no multi-hop network. Well I disagree. In the multi-hop network below only /64 prefixes are present in Routers' routing tables, no /128 (host-based) routes: ----- wifi "adhoc1" ------ wifi "adhoc2" ------- "adhoc3"----- |Host1|---------------|Router|---------------|Router2|-------|Host2| ----- LL1 P1 LL2 ------ LL3 P2 LL4 -------LL5 P3 LL6--- G1 G4 P1, P2, P3: /64 prefixes, such as: 2001:db8:1::/64 2001:db8:2::/64 and 2001:db8:3::/64 Would this kind of use of /64 prefixes alleviate the need to propagate/delete /128 prefixes throughout the network? Alex From alexandru.petrescu@gmail.com Fri Feb 27 09:47:05 2009 Return-Path: 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 920C228C34F for ; Fri, 27 Feb 2009 09:47:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.188 X-Spam-Level: X-Spam-Status: No, score=-2.188 tagged_above=-999 required=5 tests=[AWL=0.061, 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 qp3L2AuB0v08 for ; Fri, 27 Feb 2009 09:47:04 -0800 (PST) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.166.172.106]) by core3.amsl.com (Postfix) with ESMTP id 1D30528C34D for ; Fri, 27 Feb 2009 09:47:03 -0800 (PST) Received: from nephilia.intra.cea.fr (nephilia.intra.cea.fr [132.166.88.33]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-1.2) with ESMTP id n1RHlQ70003906; Fri, 27 Feb 2009 18:47:26 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by nephilia.intra.cea.fr (8.13.8/8.13.8) with ESMTP id n1RHlQot003755; Fri, 27 Feb 2009 18:47:26 +0100 (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 n1RHlP3q012050; Fri, 27 Feb 2009 18:47:25 +0100 Message-ID: <49A8272D.2060400@gmail.com> Date: Fri, 27 Feb 2009 18:47:25 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Teco Boot References: <499F0BA7.90501@piuha.net> <7E8A76F7-2CE0-463A-8EE8-8877C46B4715@gmail.com> <49A6D436.7020505@gmail.com> <000001c99845$1dc56190$595024b0$@nl> <49A6F125.40400@gmail.com> <1235680887.4585.5.camel@localhost> <49A7BB89.5040807@gmail.com> <003901c998cb$42b71e90$c8255bb0$@nl> <49A7E97A.2010503@gmail.com> <006801c998fd$06c5bd60$14513820$@nl> In-Reply-To: <006801c998fd$06c5bd60$14513820$@nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: autoconf@ietf.org Subject: Re: [Autoconf] new charter X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 17:47:05 -0000 Teco Boot wrote: > In a MANET, I expect nodes to run a MANET Routing protocol and > forward packets. Well I agree with the last part: MANET nodes do forward packets. But I don't agree with the first part: in a MANET I could configure static routes, not necessarily running a MANET routing protocol. > In ad hoc networks, one (you ?) would say nodes could be hosts or > Mobile Routers acting as hosts. Yes. If the future charter rules these kinds of MANET networks which are non-MANET-routing-protocol then I'll go away :-) > |Do you agree we consider routers mobile only within 25m ranges? > > Absolutely not. For me, 25km is a reasonable distance! But is that MANET? Or is it just a 25km subnet? > Just 10^3 times the distance and 10^6 times the power per bit (single > hop) or 10^3 times the power per bit if multi-hop is enabled (and > 1000 intermediate nodes....). Just physical laws here. Well I agree the physical laws are so. But I disagree to have 25km MANETs in the Charter. I agree with "25m IPv6 subnets", if they were explicitely stated so in the charter. Alex Proposed charter pasted below: J. Arkko wrote earlier: > Description of Working Group: > > In order to communicate among themselves, ad hoc nodes (refer to RFC > 2501) need to configure their network interface(s) with local > addresses that are valid within an ad hoc network. Ad hoc nodes may > also need to configure globally routable addresses, in order to > communicate with devices on the Internet. From the IP layer > perspective, an ad hoc network presents itself as a L3 multi-hop > network formed over a collection of links. > > The main purpose of the AUTOCONF WG is to describe the addressing > model for ad hoc networks and how nodes in these networks configure > their addresses. It is required that such models do not cause > problems for ad hoc-unaware parts of the system, such as standard > applications running on an ad hoc node or regular Internet nodes > attached to the ad hoc nodes. This group's effort may include the > development of new protocol mechanisms, should the existing IP > autoconfiguration mechanisms be found inadequate. However, the first > task of the working group is to describe one practical addressing > model for ad hoc networks. > > Once this sole work item is completed, the group can be rechartered > to work on additional issues. > > Goals and Milestones: > > Apr 2009 Submit initial draft on address configuration in ad hoc > networks Sep 2009 Submit address configuration draft to IESG as > Informational or close WG. > From teco@inf-net.nl Fri Feb 27 09:49:23 2009 Return-Path: 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 C09A728C36C for ; Fri, 27 Feb 2009 09:49:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.454 X-Spam-Level: X-Spam-Status: No, score=-1.454 tagged_above=-999 required=5 tests=[AWL=-0.008, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_21=0.6] 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 FmdnT1UrtQrI for ; Fri, 27 Feb 2009 09:49:22 -0800 (PST) Received: from hpsmtp-eml20.kpnxchange.com (hpsmtp-eml20.KPNXCHANGE.COM [213.75.38.85]) by core3.amsl.com (Postfix) with ESMTP id C3CA228C34D for ; Fri, 27 Feb 2009 09:49:20 -0800 (PST) Received: from cpsmtp-eml104.kpnxchange.com ([213.75.84.104]) by hpsmtp-eml20.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 27 Feb 2009 18:49:42 +0100 Received: from M90Teco ([86.83.9.22]) by cpsmtp-eml104.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 27 Feb 2009 18:49:42 +0100 From: "Teco Boot" To: "'Alexandru Petrescu'" References: <499F0BA7.90501@piuha.net> <7E8A76F7-2CE0-463A-8EE8-8877C46B4715@gmail.com> <49A6D436.7020505@gmail.com> <000001c99845$1dc56190$595024b0$@nl> <49A6F125.40400@gmail.com> <1235680887.4585.5.camel@localhost> <002f01c998bf$8f112210$ad336630$@nl> <49A7E58C.2020303@gmail.com> In-Reply-To: <49A7E58C.2020303@gmail.com> Date: Fri, 27 Feb 2009 18:49:40 +0100 Message-ID: <007201c99903$c4182c80$4c488580$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcmY3FfMqdkQoAIbSxCSbSzcti9/QgAIRi0Q Content-Language: nl x-cr-hashedpuzzle: A3hK A4bu D5BA GmCm Gn/g H6K9 JNRP K1+O LNCn OCi8 Obcj QO74 T2Sr U6jd U9kM WDdb; 2; YQBsAGUAeABhAG4AZAByAHUALgBwAGUAdAByAGUAcwBjAHUAQABnAG0AYQBpAGwALgBjAG8AbQA7AGEAdQB0AG8AYwBvAG4AZgBAAGkAZQB0AGYALgBvAHIAZwA=; Sosha1_v1; 7; {41593C1C-282D-4064-99A0-B3321CEBA27B}; dABlAGMAbwBAAGkAbgBmAC0AbgBlAHQALgBuAGwA; Fri, 27 Feb 2009 17:49:35 GMT; UgBFADoAIABBAHUAdABvAGMAbwBuAGYAIABhAGQAZAByAGUAcwBzAGkAbgBnACAAbQBvAGQAZQBsAA== x-cr-puzzleid: {41593C1C-282D-4064-99A0-B3321CEBA27B} X-OriginalArrivalTime: 27 Feb 2009 17:49:42.0231 (UTC) FILETIME=[C4CA3E70:01C99903] Cc: autoconf@ietf.org Subject: Re: [Autoconf] Autoconf addressing model X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 17:49:23 -0000 Inline. |-----Oorspronkelijk bericht----- |Van: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] |Verzonden: vrijdag 27 februari 2009 14:07 |Aan: Teco Boot |CC: autoconf@ietf.org; cjbc@it.uc3m.es |Onderwerp: Re: Autoconf addressing model | |Whoa, that's text Teco :-) Let me see where can I practically agree |with you: | |Teco Boot a =E9crit : |[...] |> We could discuss and analyze the effect of adopting the /128 (or /32) |prefix |> lengths for MANET interfaces, but I prefer taking this option as last |> resort. | |I fully agree with you. I find /128 prefix lengths for subnets to be a |departure from the typical less-than-64 prefix lengths for subnets. It |may even break networks. | |> I think there is a much more obvious option, using the RFC2464 model |> for the MANET interface and /128 (or /32) for loopback interfaces. |Both |> would use high probability globally unique Interface IDs like EUI-64 |> (Extended Unique Identifier). | |I don't agree going that way. I think loopback addresses are for self |addressing not for talking to other nodes. See other mail also, on Linux. I think loopback addresses are often used for stable connections to = routers, where interfaces flap but due to redundancy there are alternative paths. When addresses are used on physical interfaces, and the interface goes = down, connectivity might be broken. I think using router loopback interface addresses for talking to other nodes is best current practice. It is a = basic principle in my network designs. RFC3871: It is a common practice among operators to configure "loopback" pseudo-interfaces to use as the source and destination of management traffic. These are preferred to physical interfaces because they provide a stable, routable address. Services bound to the addresses of physical interface addresses might become unreachable if the associated hardware goes down, is removed, etc. I think the same arguments are valid for non-management traffic in a = MANET. |[rfc4291 and 2464 citations] |> It is not only because the RFC texts that I dislike the /128 in MANET |> interfaces, it is also backward compatibility with current IP stacks |(and |> probably many applications). | |I agree. | |> I think using /128 for loopback interfaces fits the requirements for |the |> addressing model. If a loopback interface is used, MANET interfaces = do |not |> require a globally unique address. | |I'm not sure I could agree with the MANET interface being the loopback |interface. It sounds as a significant departure. The MANET interface is not a loopback interface! It is the interface to = a radio, e.g. 802.11 NIC in IBSS mode (your wifi adhoc). |> RFC4291 once more (out of section, also |> cited above): |> Unicast addresses with a |> scope greater than link-scope are not needed for interfaces that are |> not used as the origin or destination of any IPv6 packets to or from |> non-neighbors. |> So "host functionality" can be provided using the globally (or MANET |local) |> unique address assigned to a loopback address, or another non-MANET |> interface. | |An address assigned to an address? I think it risks many |misunderstandings. Typo, I meant: So "host functionality" can be provided using the globally (or MANET = local) unique address assigned to a loopback interface, or another non-MANET interface.=20 |> This results in the following addressing model, where all nodes are |routers: |> |> +-------+ wifi "adhoc1" +-------+ wifi "adhoc2" +-------+ |> |Router1|>-------------<|Router2|>-------------<|Router3| |> +---L---+ LL1 LL21 +---L---+ LL22 LL3 +---L---+ |> |M1 |M2 |M3 |> |> "adhoc1" and "adhoc2": 802.11 SSIDs in "IBSS" mode. |> Each IBSS is an IPv6 subnet. |> |> L: Loopback interface. |> |> >, <: MANET interface. | |The MANET interface is a loopback interface? I disagree. The loopback |interface is needed for local inter-process communication, I don't want |that to go on to the network. There is some misunderstanding her, the MANET interface is NOT a = loopback interface. It is an interface that enables communication to other MANET nodes. |But, most importantly, why is there a need to add other special |interfaces to the example pictured above? I think this model solves some problems. o The assigned address can be used over whatever interface. This fulfills a requirement of "ad hoc", something works without planning. o Connectivity is not broken if a path swap occurs (the RFC3781 = loopback BCP) o It provides some scalability, as only a single address is needed,=20 even if multiple interfaces are used. o Applications are not confused by "host prefixes" to a link,=20 where other nodes are reachable. I tested this with linux and IPv4 = with /32.=20 Problems started with ARP processing, and I swapped to another addressing=20 model immediately. |> LL1, LL21, LL22, LL3: IPv6 link-local addresses. |> Self-formed according to rfc2464. |> |> M1, M2, M3: IPv6 MANET local addresses, for example |> FD01:db8::1/128, FD01:db8::2/128 and FD01:db8::3/128. | |For my clarification, what's fd01? (2001:db8:: is a prefix for |documentation rfc3849, ULA is fc00 rfc4193). ULA prefix is FC00::/7. 8th but is L, set to 1 if locally assigned. So = all ULA would start with FD, the FC is for the future where a registration = body maintains the universal uniqueness. 0xFC + 0x01 =3D 0xFD. |> Manually assigned, or pre-configured (e.g. with SNMP) |> or formed according to a to be defined [Autoconf for MANETs] |> protocol, with a to-be-defined prefix (e.g. ULA, RFC4193). |> |> Although all nodes are marked as router, this does not imply all = nodes |> forward packets. All nodes run a MANET routing protocol for learning |the |> MANET topology. |> |> |> In case one of the routers is connected to the Internet or private |network, |> this router can advertize a prefix in the MANET, and this information |is |> distributed in the MANET with an [Autoconf for MANETs] protocol. | |Why shouldn't it be distributed with DHCP and with OSPF, for example. In a MANET, there are some problems with standard OSPF. OSPF-MANET is perfectly fine to use in a MANET. DHCP (with relay) can be used for "pull", but there is a problem finding = the best relay agent. I think there should be a mechanism that informs nodes = of available facilities, e.g. shortest path to a DHCP server. Updating ND = RA with some info for finding a DHCP server looks a good idea to me, and I updated my Border Router Discovery Protocol (BRDP) [Autoconf] proposal = for DHCP support already. However, there is a chicken - egg problem. In a wired network, the DHCP client - DHCP relay agent relation is stable. This is certainly not the = case in a MANET. Therefore, I think a DHCP client should start with building reliable communication to a DHCP server, and the MANET routing protocols = can provide such. But the MANET routing protocol needs a prefix that = corresponds to this MANET node. For this reason, I think it makes sense to start = with generating a prefix without DHCP, and we could use a prefix "push model" here. Anyway, ND /SLAAC works with the "push model" already, so nothing new = here. |> |> Internet |> | |> | |> +-------+-------+ |> | Access Router | |> +-------+-------+ |> | |> | | Prefix information |> | V |> | |> +-------+ wifi "adhoc1" +---+---+ wifi "adhoc2" +-------+ |> |Router1|>-------------<|Router2|>-------------<|Router3| |> +---L---+ LL1 LL21 +---L---+ LL22 LL3 +---L---+ |> |M1 |M2 |M3 |> |G1 |G2 |G3 |> <------- -------> |> Prefix information Prefix information |> |> |> G1, G2, G3: IPv6 globally unique addresses, for example |> 2001:db8:G:1/128, 2001:db8:G:2/128 and 2001:db8:G:3/128. |> Formed according to a to be defined [Autoconf for MANETs] |> protocol, with the prefix provided by (via) the Access Router. | |Above, and in the following figures, I don't understand "--->, Prefix |Information". Is that RA? Or OSPF? Or routing protocol? Or DHCP |Prefix Delegation? This is under discussion, and the reason we have an [Autoconf] WG. There are proposals that rely on a routing protocol, but the old charter mentioned being independent of a routing protocol. My BRDP used ND as a transport vehicle, and prefix information was = carried in "Border Router Information Option" which is a look-alike of the = Prefix Information Option. PIO is single-hop, BRIO is multi-hop.=20 |> Multi-homing can easily be supported: | |maybe. Just write some code and compile :-) The problem is border router swapping. If session continuity is = required, we need something like MIP/NEMO, HIP, SHIM6 or NAT / NAT66 at the border. = This is not our focus, I think. Teco. =20 |Alex | |> |> ---+-------Internet--------+--- |> | | |> | | |> +-------+-------+ +-------+-------+ |> |Access Router H| |Access Router G| |> +-------+-------+ +-------+-------+ |> | | |> ||Prefix information H | |Prefix information G |> |V | V |> | | |> +---+---+ wifi "adhoc1" +---+---+ wifi "adhoc2" +-------+ |> |Router1|>-------------<|Router2|>-------------<|Router3| |> +---L---+ LL1 LL21 +---L---+ LL22 LL3 +---L---+ |> |M1 |M2 |M3 |> |G1 |G2 |G3 |> |H1 |H2 |H3 |> <------- -------> |> Prefix information G Prefix information G, H |> ---------> |> Prefix information H |> |> H1, H2, H3: IPv6 globally unique addresses, for example |> 2001:db8:H:1/128, 2001:db8:H:2/128 and 2001:db8:H:3/128. |> Formed according to a to be defined [Autoconf for MANETs] |> protocol, with the prefix provided by (via) Access Router H. |> |> |> Note that the impact of the number of interfaces is minimal, the |address |> configuration of Router2 is very similar to Router1 and Router3. = Also, |the |> status of the MANET interface has no impact on communication in case |of |> multi-homing and redundant paths. (OK, we might need MIP6 / HIP / |SHIM6 or |> application layer address swapping mechanisms). |> |> It doesn't matter how many ad hoc segments there are. In the = following |> scenario, the link to Access router G disappeared, Router 3 |disappeared and |> a Router4 joined IBSS "adhoc1". |> |> |> |> ---+-------Internet------ |> | |> | |> +-------+-------+ |> |Access Router H| |> +-------+-------+ |> | |> ||Prefix information H |> |V wifi "adhoc1" |> | <---------------------------v--------> |> <------|--v----------------------> | |> |<-|--------------------v-----------------------|---> |> | | | | |> +---+--'+ +---'---+ +---'---+ |> |Router1|>-------------<|Router2|>-------------<|Router4| |> +---L---+ LL1 LL21 +---L---+ LL22 LL4 +---L---+ |> |M1 |M2 |M4 |> |H1 |H2 |H4 |> |> ---------> ---------> |> Prefix information H Prefix information H |> |> |> Now, Router2 acts as a relay for Router4, so Router4 can reach = Router1 |and |> the Internet. Router1 acts as Border Router for all nodes in the |MANET. |> |> |> I have some thoughts on IPv4 supports. Of course IPv4 misses lots of |> flexibility that is used in above model. But there are ways to = support |it, |> e.g. IPv4 link local (RFC3927) accompanied by some extended form of |> duplicate address detection (passive checking routing tables). For |globally |> unique address assignment I think of DHCP-IPv4 over an IPv6 path, |provided |> as described above. (e.g. Router4 gets its /32 address for its |loopback |> interface from/via Access Router H, using M4 or H4 address and the |IPv6 |> MANET protocol. |> |> |> Any comments? |> Teco. |> |> |> |> |-----Oorspronkelijk bericht----- |> |Van: Carlos Jes=FAs Bernardos Cano [mailto:cjbc@it.uc3m.es] |> |Verzonden: donderdag 26 februari 2009 21:41 |> |Aan: Alexandru Petrescu |> |CC: Teco Boot; autoconf@ietf.org |> |Onderwerp: Re: [Autoconf] new charter |> | |> |Hi Alex: |> | |> | One question below. |> | |> |El jue, 26-02-2009 a las 20:44 +0100, Alexandru Petrescu escribi=F3: |> |> Sorry, I made an error indeed putting same prefix. How about this |> |> updated picture with the prefixes being distinct: |> |> |> |> |> |> ----- wifi "adhoc1" ------ wifi "adhoc2" ----- |> |> |Host1|---------------|Router|---------------|Host2| |> |> ----- LL1 LL2 ------ LL3 LL4 ----- |> |> G1 G4 |> |> |> |> |> |> "adhoc1" and "adhoc2": 802.11 ESSIDs in "ad-hoc" mode. |> |> Each is an IPv6 subnet. |> |> LL1...4: IPv6 link-local addresses. |> |> Self-formed according to rfc2464. |> |> G1, G4: IPv6 global addresses, for example |> |> 2001:db8:1::1/64 and |> |> 2001:db8:2::4/64 |> |> Manually assigned, or pre-configured with SNMP |> |> or formed according to stateless autoconf = rfc4862; |> |> the prefixes are advertised by Router in RAs. |> |> |> | |> |Does this model only apply to Host-Router-Host scenarios? I mean, |does |> |this model apply for Router-Router-Router scenarios? I fully agree |the |> |model fits the first scenario, but I don't for the second, since |> |routers' mobility within the ad-hoc network would force them to |change |> |prefixes often, I guess. For those scenarios it might be better to |think |> |of addressing models in which MANET routers are configured with /128 |> |(or /32 for IPv4) addresses, so they don't need to change their |> |addresses as a result of link changes. |> | |> |Kind Regards, |> | |> |Carlos |> | |> |-- |> | Carlos Jes=FAs Bernardos Cano http://www.netcoms.net |> | GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 |> |++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ |> | WEEDEV 2009: 2nd Workshop on Experimental Evaluation and |> | Deployment Experiences on Vehicular networks |> | http://www.weedev.org/ |> |++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ |> |> From teco@inf-net.nl Fri Feb 27 10:05:18 2009 Return-Path: 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 0B91928C365 for ; Fri, 27 Feb 2009 10:05:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.754 X-Spam-Level: X-Spam-Status: No, score=-1.754 tagged_above=-999 required=5 tests=[AWL=0.292, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] 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 F9mlD4TFP0iD for ; Fri, 27 Feb 2009 10:05:15 -0800 (PST) Received: from hpsmtp-eml17.kpnxchange.com (hpsmtp-eml17.KPNXCHANGE.COM [213.75.38.117]) by core3.amsl.com (Postfix) with ESMTP id E249B28C1BF for ; Fri, 27 Feb 2009 10:05:14 -0800 (PST) Received: from cpsmtp-eml102.kpnxchange.com ([213.75.84.102]) by hpsmtp-eml17.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 27 Feb 2009 19:05:36 +0100 Received: from M90Teco ([86.83.9.22]) by cpsmtp-eml102.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 27 Feb 2009 19:05:36 +0100 From: "Teco Boot" To: "'Alexandru Petrescu'" References: <499F0BA7.90501@piuha.net> <7E8A76F7-2CE0-463A-8EE8-8877C46B4715@gmail.com> <49A6D436.7020505@gmail.com> <000001c99845$1dc56190$595024b0$@nl> <49A6F125.40400@gmail.com> <1235680887.4585.5.camel@localhost> <49A7BB89.5040807@gmail.com> <003901c998cb$42b71e90$c8255bb0$@nl> <49A7E97A.2010503@gmail.com> <006801c998fd$06c5bd60$14513820$@nl> <49A82694.8090801@gmail.com> In-Reply-To: <49A82694.8090801@gmail.com> Date: Fri, 27 Feb 2009 19:05:35 +0100 Message-ID: <007a01c99905$fd1619a0$f7424ce0$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcmZAxrH8J0z5mHeT162ZLZ1sYi7CAAAWhYQ Content-Language: nl X-OriginalArrivalTime: 27 Feb 2009 18:05:36.0777 (UTC) FILETIME=[FDBE6790:01C99905] Cc: autoconf@ietf.org Subject: Re: [Autoconf] practical addressing (was: new charter) X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 18:05:18 -0000 Inline. |-----Oorspronkelijk bericht----- |Van: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] |Verzonden: vrijdag 27 februari 2009 18:45 |Aan: Teco Boot |CC: autoconf@ietf.org |Onderwerp: Re: practical addressing (was: [Autoconf] new charter) | |[Thanks for the details Linux/Vista/IOS routing tables! I didn't know | all that, only for linux] | |Teco Boot a =E9crit : |>>> Routers may generate a /128 prefix-address, and advertize this in |>>> the routing domain. |> |>> A host-based route propagated and deleted throughout a domain? I |>> don't see the necessity of doing so. Assuming the routers are |>> mobile within 25m ranges then they wouldn't need to change their |>> addresses, thus no need to propagate host-based routes. |> |> If the /128 is not propagated, there will be no multi-hop network. | |Well I disagree. In the multi-hop network below only /64 prefixes are |present in Routers' routing tables, no /128 (host-based) routes: | | | ----- wifi "adhoc1" ------ wifi "adhoc2" ------- "adhoc3"----- | |Host1|---------------|Router|---------------|Router2|-------|Host2| | ----- LL1 P1 LL2 ------ LL3 P2 LL4 -------LL5 P3 LL6--- | G1 G4 | | P1, P2, P3: /64 prefixes, such as: | 2001:db8:1::/64 | 2001:db8:2::/64 and | 2001:db8:3::/64 | |Would this kind of use of /64 prefixes alleviate the need to |propagate/delete /128 prefixes throughout the network? Your routers need two wifi interfaces. Often, there is only one wifi interface. The MANET Routing protocol provides connectivity between = nodes that are out of range from each other, via relay nodes that are in = range. Using many distinct SSIDs can introduce problems, e.g. Host-1 and Host-2 = are near each other, but on a different SSID: ------- wifi "adhoc1" ----- ???? ----- "adhoc2" -------- |Router1|---------------|Host1|--/ /--|Host2|---------|Router2| ------- LL2 P1 LL1 --- ----LL6 P2 LL6------ G1 G4 Router1 and Router2 are out of range. So R1 <--> H2 and H1 <--> R2. Host1 MUST communicate to Host2, this is critical (live or dead). Teco. |Alex From alexandru.petrescu@gmail.com Fri Feb 27 10:17:37 2009 Return-Path: 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 BB0BE28C1BF for ; Fri, 27 Feb 2009 10:17:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.189 X-Spam-Level: X-Spam-Status: No, score=-2.189 tagged_above=-999 required=5 tests=[AWL=0.060, 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 KQt2g1fphgrl for ; Fri, 27 Feb 2009 10:17:36 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.166.172.107]) by core3.amsl.com (Postfix) with ESMTP id 49FB93A683E for ; Fri, 27 Feb 2009 10:17:36 -0800 (PST) Received: from nephilia.intra.cea.fr (nephilia.intra.cea.fr [132.166.88.33]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-1.2) with ESMTP id n1RIHwW9032414; Fri, 27 Feb 2009 19:17:58 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by nephilia.intra.cea.fr (8.13.8/8.13.8) with ESMTP id n1RIHvJa001083; Fri, 27 Feb 2009 19:17:58 +0100 (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 n1RIHvJ4032531; Fri, 27 Feb 2009 19:17:57 +0100 Message-ID: <49A82E55.10208@gmail.com> Date: Fri, 27 Feb 2009 19:17:57 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Teco Boot References: <499F0BA7.90501@piuha.net> <7E8A76F7-2CE0-463A-8EE8-8877C46B4715@gmail.com> <49A6D436.7020505@gmail.com> <000001c99845$1dc56190$595024b0$@nl> <49A6F125.40400@gmail.com> <1235680887.4585.5.camel@localhost> <002f01c998bf$8f112210$ad336630$@nl> <49A7E58C.2020303@gmail.com> <007201c99903$c4182c80$4c488580$@nl> In-Reply-To: <007201c99903$c4182c80$4c488580$@nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org Subject: Re: [Autoconf] Autoconf addressing model X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 18:17:37 -0000 Teco Boot a écrit : [...] >>> I think there is a much more obvious option, using the RFC2464 >>> model for the MANET interface and /128 (or /32) for loopback >>> interfaces. Both would use high probability globally unique >>> Interface IDs like EUI-64 (Extended Unique Identifier). >> >> I don't agree going that way. I think loopback addresses are for >> self addressing not for talking to other nodes. > > See other mail also, on Linux. I think loopback addresses are often > used for stable connections to routers, where interfaces flap but due > to redundancy there are alternative paths. I think you mean a virtual interface actually, not necessarily the loopback interface (and yes, lo is a 'virtual' interface). Not all virtual interfaces are loopback. > RFC3871: It is a common practice among operators to configure > "loopback" pseudo-interfaces to use as the source and destination of > management traffic. Well that RFC is completely wrong please someone correct it. The loopback address is ::1 and it can't be used to communicate outside the computer. Yes pseudo-interface (and maybe 'virtual') but no loopback. And yes the interface in the routing table for the entry address/128 is 'lo' which is yes the loopback interface but no, never will that address be in the src nor dst fields of any packet leaving the computer (other than encapsulated maybe). >> [rfc4291 and 2464 citations] >>> It is not only because the RFC texts that I dislike the /128 in >>> MANET interfaces, it is also backward compatibility with current >>> IP stacks (and probably many applications). >> >> I agree. >> >>> I think using /128 for loopback interfaces fits the requirements >>> for the addressing model. If a loopback interface is used, MANET >>> interfaces do not require a globally unique address. >> >> I'm not sure I could agree with the MANET interface being the >> loopback interface. It sounds as a significant departure. > > The MANET interface is not a loopback interface! It is the interface > to a radio, e.g. 802.11 NIC in IBSS mode (your wifi adhoc). I agree with this. But in the immediately above text you're saying "using /128 for loopback interfaces fits" - I think you meant 'virtual' interface, not 'loopback' interface, right? >>> RFC4291 once more (out of section, also cited above): Unicast >>> addresses with a scope greater than link-scope are not needed for >>> interfaces that are not used as the origin or destination of any >>> IPv6 packets to or from non-neighbors. So "host functionality" >>> can be provided using the globally (or MANET local) unique >>> address assigned to a loopback address, or another non-MANET >>> interface. >> >> An address assigned to an address? I think it risks many >> misunderstandings. > > Typo, I meant: So "host functionality" can be provided using the > globally (or MANET local) unique address assigned to a loopback > interface, or another non-MANET interface. Ok. > I think this model solves some problems. o The assigned address can > be used over whatever interface. This fulfills a requirement of "ad > hoc", something works without planning. I thought the unplanned aspect could be treated by IPv6 stateless autoconf and IPv6-over-Ethernet link-local addresses. > o Connectivity is not broken if a path swap occurs (the RFC3781 > loopback BCP) o It provides some scalability, as only a single > address is needed, even if multiple interfaces are used. o > Applications are not confused by "host prefixes" to a link, where > other nodes are reachable. I tested this with linux and IPv4 with > /32. Before deciding on the solution (address assigned to a virtual interface) I need to udnerstand how path swap occurs and why. > Problems started with ARP processing, and I swapped to another > addressing model immediately. >> For my clarification, what's fd01? (2001:db8:: is a prefix for >> documentation rfc3849, ULA is fc00 rfc4193). > > ULA prefix is FC00::/7. 8th but is L, set to 1 if locally assigned. > So all ULA would start with FD, the FC is for the future where a > registration body maintains the universal uniqueness. > > 0xFC + 0x01 = 0xFD. Ah! So a correct ULA address would be fd01::1/128? In this sense, when drawing pictures I have a choice between fd01::1/128 ULA and 2001:db8::1/128 global address, it's ambiguous. >>> Manually assigned, or pre-configured (e.g. with SNMP) or formed >>> according to a to be defined [Autoconf for MANETs] protocol, with >>> a to-be-defined prefix (e.g. ULA, RFC4193). >>> >>> Although all nodes are marked as router, this does not imply all >>> nodes forward packets. All nodes run a MANET routing protocol for >>> learning >> the >>> MANET topology. >>> >>> >>> In case one of the routers is connected to the Internet or >>> private >> network, >>> this router can advertize a prefix in the MANET, and this >>> information >> is >>> distributed in the MANET with an [Autoconf for MANETs] protocol. >> >> Why shouldn't it be distributed with DHCP and with OSPF, for >> example. > > In a MANET, there are some problems with standard OSPF. OSPF-MANET is > perfectly fine to use in a MANET. Ok. > DHCP (with relay) can be used for "pull", but there is a problem > finding the best relay agent. I think there should be a mechanism > that informs nodes of available facilities, e.g. shortest path to a > DHCP server. Updating ND RA with some info for finding a DHCP server > looks a good idea to me, and I updated my Border Router Discovery > Protocol (BRDP) [Autoconf] proposal for DHCP support already. Sounds interesting. But I think normal DHCP could run ok, provided the Relays know the address of the Server. In a first practical step would be to manually configure the Server's address on each Relays. > However, there is a chicken - egg problem. In a wired network, the > DHCP client - DHCP relay agent relation is stable. This is certainly > not the case in a MANET. Well it is the case in a MANET made of 25meter IPv6 subnets. > Therefore, I think a DHCP client should start with building reliable > communication to a DHCP server, and the MANET routing protocols can > provide such. But the MANET routing protocol needs a prefix that > corresponds to this MANET node. For this reason, I think it makes > sense to start with generating a prefix without DHCP, and we could > use a prefix "push model" here. Well I think this is indeed a very chickeneggy problem: are addresses in place before routing is, or vice-versa. But what would we do in practice? Certainly we'd manually assign some addresses - let's see these cases first. >> Above, and in the following figures, I don't understand "--->, >> Prefix Information". Is that RA? Or OSPF? Or routing protocol? >> Or DHCP Prefix Delegation? > > This is under discussion, and the reason we have an [Autoconf] WG. > There are proposals that rely on a routing protocol, but the old > charter mentioned being independent of a routing protocol. I think we should consider first the practical cases. Alex From sratliff@cisco.com Fri Feb 27 10:20:28 2009 Return-Path: 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 6318E28C367 for ; Fri, 27 Feb 2009 10:20:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 3of8Avgb1-do for ; Fri, 27 Feb 2009 10:20:27 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 04B0D28C35E for ; Fri, 27 Feb 2009 10:20:26 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,277,1233532800"; d="scan'208";a="38676897" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 27 Feb 2009 18:20:49 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n1RIKngO013432; Fri, 27 Feb 2009 13:20:49 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n1RIKn7q008559; Fri, 27 Feb 2009 18:20:49 GMT Received: from xmb-rtp-208.amer.cisco.com ([64.102.31.43]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Feb 2009 13:20:48 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 27 Feb 2009 13:20:47 -0500 Message-ID: <7FB7EE0A621BA44B8B69E5F0A09DC76407AD0C48@xmb-rtp-208.amer.cisco.com> In-Reply-To: <49A8272D.2060400@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Autoconf] new charter Thread-Index: AcmZA4D7GvOj98TgRN+fRurNRpYVsAAA95Nw References: <499F0BA7.90501@piuha.net> <7E8A76F7-2CE0-463A-8EE8-8877C46B4715@gmail.com> <49A6D436.7020505@gmail.com> <000001c99845$1dc56190$595024b0$@nl> <49A6F125.40400@gmail.com> <1235680887.4585.5.camel@localhost><49A7BB89.5040807@gmail.com> <003901c998cb$42b71e90$c8255bb0$@nl><49A7E97A.2010503@gmail.com> <006801c998fd$06c5bd60$14513820$@nl> <49A8272D.2060400@gmail.com> From: "Stan Ratliff (sratliff)" To: "Alexandru Petrescu" , "Teco Boot" X-OriginalArrivalTime: 27 Feb 2009 18:20:48.0982 (UTC) FILETIME=[1D75D760:01C99908] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3777; t=1235758849; x=1236622849; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sratliff@cisco.com; z=From:=20=22Stan=20Ratliff=20(sratliff)=22=20 |Subject:=20RE=3A=20[Autoconf]=20new=20charter |Sender:=20 |To:=20=22Alexandru=20Petrescu=22=20,=0A=20=20=20=20=20=20=20=20=22Teco=20Boot=22=20; bh=X/ZkGa3ob9JYNKN3s+vsmS8Od2H7mWLHj40ummVwtjc=; b=Q/JPXuLot9xtX/VYnzB/PbSdpAV3bKEfHmFiTh1OLw0KDT8KbcArp31GwH SSP03eMJnYPNRuwR4q3ymjQB+GQ0sqeMJockT8mDHNKmk6ECmne15selNrKu 86PFYVRPfo; Authentication-Results: rtp-dkim-1; header.From=sratliff@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: autoconf@ietf.org Subject: Re: [Autoconf] new charter X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 18:20:28 -0000 Inline.=20 > -----Original Message----- > From: autoconf-bounces@ietf.org=20 > [mailto:autoconf-bounces@ietf.org] On Behalf Of Alexandru Petrescu > Sent: Friday, February 27, 2009 12:47 PM > To: Teco Boot > Cc: autoconf@ietf.org > Subject: Re: [Autoconf] new charter >=20 > Teco Boot wrote: > > In a MANET, I expect nodes to run a MANET Routing protocol=20 > and forward=20 > > packets. >=20 > Well I agree with the last part: MANET nodes do forward=20 > packets. But I don't agree with the first part: in a MANET I=20 > could configure static routes, not necessarily running a=20 > MANET routing protocol. >=20 > > In ad hoc networks, one (you ?) would say nodes could be hosts or=20 > > Mobile Routers acting as hosts. >=20 > Yes. If the future charter rules these kinds of MANET=20 > networks which are non-MANET-routing-protocol then I'll go away :-) >=20 > > |Do you agree we consider routers mobile only within 25m ranges? > >=20 > > Absolutely not. For me, 25km is a reasonable distance! >=20 > But is that MANET? Or is it just a 25km subnet? >=20 > > Just 10^3 times the distance and 10^6 times the power per=20 > bit (single > > hop) or 10^3 times the power per bit if multi-hop is=20 > enabled (and 1000=20 > > intermediate nodes....). Just physical laws here. >=20 > Well I agree the physical laws are so. But I disagree to=20 > have 25km MANETs in the Charter. I agree with "25m IPv6=20 > subnets", if they were explicitely stated so in the charter. >=20 > Alex > And I'll have to disagree with the "25m subnets". I regularly deal with line-of-sight radio links that are in excess of 25km. We can't limit ourselves to short-range technologies (e.g. Commercial 802.11, Bluetooth, Zigbee, etc). I don't believe a distance should be explicitly stated in the charter, rather, some verbiage that talks about "radio neighbors in range" should be sufficient.=20 Regards, Stan >=20 > Proposed charter pasted below: > J. Arkko wrote earlier: > > Description of Working Group: > >=20 > > In order to communicate among themselves, ad hoc nodes (refer to RFC > > 2501) need to configure their network interface(s) with local=20 > > addresses that are valid within an ad hoc network. Ad hoc nodes may=20 > > also need to configure globally routable addresses, in order to=20 > > communicate with devices on the Internet. From the IP layer=20 > > perspective, an ad hoc network presents itself as a L3 multi-hop=20 > > network formed over a collection of links. > >=20 > > The main purpose of the AUTOCONF WG is to describe the addressing=20 > > model for ad hoc networks and how nodes in these networks configure=20 > > their addresses. It is required that such models do not=20 > cause problems=20 > > for ad hoc-unaware parts of the system, such as standard=20 > applications=20 > > running on an ad hoc node or regular Internet nodes=20 > attached to the ad=20 > > hoc nodes. This group's effort may include the development of new=20 > > protocol mechanisms, should the existing IP autoconfiguration=20 > > mechanisms be found inadequate. However, the first task of=20 > the working=20 > > group is to describe one practical addressing model for ad hoc=20 > > networks. > >=20 > > Once this sole work item is completed, the group can be=20 > rechartered to=20 > > work on additional issues. > >=20 > > Goals and Milestones: > >=20 > > Apr 2009 Submit initial draft on address configuration in ad hoc=20 > > networks Sep 2009 Submit address configuration draft to IESG as=20 > > Informational or close WG. > >=20 >=20 > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf >=20 From alexandru.petrescu@gmail.com Fri Feb 27 10:24:20 2009 Return-Path: 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 074AF28C1BF for ; Fri, 27 Feb 2009 10:24:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.19 X-Spam-Level: X-Spam-Status: No, score=-2.19 tagged_above=-999 required=5 tests=[AWL=0.059, 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 Bp8fSV9WYvWN for ; Fri, 27 Feb 2009 10:24:19 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.1]) by core3.amsl.com (Postfix) with ESMTP id DEBF628C15A for ; Fri, 27 Feb 2009 10:24:18 -0800 (PST) Received: from nephilia.intra.cea.fr (nephilia.intra.cea.fr [132.166.88.33]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-1.2) with ESMTP id n1RIMtS6022337; Fri, 27 Feb 2009 19:22:55 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by nephilia.intra.cea.fr (8.13.8/8.13.8) with ESMTP id n1RIOdEc006917; Fri, 27 Feb 2009 19:24:39 +0100 (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 n1RIOd2b000965; Fri, 27 Feb 2009 19:24:39 +0100 Message-ID: <49A82FE7.7090703@gmail.com> Date: Fri, 27 Feb 2009 19:24:39 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Teco Boot References: <499F0BA7.90501@piuha.net> <7E8A76F7-2CE0-463A-8EE8-8877C46B4715@gmail.com> <49A6D436.7020505@gmail.com> <000001c99845$1dc56190$595024b0$@nl> <49A6F125.40400@gmail.com> <1235680887.4585.5.camel@localhost> <49A7BB89.5040807@gmail.com> <003901c998cb$42b71e90$c8255bb0$@nl> <49A7E97A.2010503@gmail.com> <006801c998fd$06c5bd60$14513820$@nl> <49A82694.8090801@gmail.com> <007a01c99905$fd1619a0$f7424ce0$@nl> In-Reply-To: <007a01c99905$fd1619a0$f7424ce0$@nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org Subject: Re: [Autoconf] practical addressing X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 18:24:20 -0000 Teco Boot a écrit : > Inline. > > |-----Oorspronkelijk bericht----- > |Van: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] > |Verzonden: vrijdag 27 februari 2009 18:45 > |Aan: Teco Boot > |CC: autoconf@ietf.org > |Onderwerp: Re: practical addressing (was: [Autoconf] new charter) > | > |[Thanks for the details Linux/Vista/IOS routing tables! I didn't know > | all that, only for linux] > | > |Teco Boot a écrit : > |>>> Routers may generate a /128 prefix-address, and advertize this in > |>>> the routing domain. > |> > |>> A host-based route propagated and deleted throughout a domain? I > |>> don't see the necessity of doing so. Assuming the routers are > |>> mobile within 25m ranges then they wouldn't need to change their > |>> addresses, thus no need to propagate host-based routes. > |> > |> If the /128 is not propagated, there will be no multi-hop network. > | > |Well I disagree. In the multi-hop network below only /64 prefixes are > |present in Routers' routing tables, no /128 (host-based) routes: > | > | > | ----- wifi "adhoc1" ------ wifi "adhoc2" ------- "adhoc3"----- > | |Host1|---------------|Router|---------------|Router2|-------|Host2| > | ----- LL1 P1 LL2 ------ LL3 P2 LL4 -------LL5 P3 LL6--- > | G1 G4 > | > | P1, P2, P3: /64 prefixes, such as: > | 2001:db8:1::/64 > | 2001:db8:2::/64 and > | 2001:db8:3::/64 > | > |Would this kind of use of /64 prefixes alleviate the need to > |propagate/delete /128 prefixes throughout the network? > > Your routers need two wifi interfaces. Yes. > Often, there is only one wifi interface. If the charter text said we only look at routers with one physical interface then I'd go away. And if it said we only look at routers with at least two physical interfaces then my figures would be right. > The MANET Routing protocol provides connectivity between nodes that > are out of range from each other, via relay nodes that are in range. Well that can be achieved with simple plain routing, not necessarily a dynamic routing protocol. > Using many distinct SSIDs can introduce problems, e.g. Host-1 and > Host-2 are near each other, but on a different SSID: Using a single SSID can introduce other problems, such as the now documented hidden terminal problem. We should make choices. Alex From alexandru.petrescu@gmail.com Fri Feb 27 10:30:56 2009 Return-Path: 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 1189F28C1BF for ; Fri, 27 Feb 2009 10:30:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.192 X-Spam-Level: X-Spam-Status: No, score=-2.192 tagged_above=-999 required=5 tests=[AWL=0.057, 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 2rf+K94LCuhL for ; Fri, 27 Feb 2009 10:30:55 -0800 (PST) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.166.172.106]) by core3.amsl.com (Postfix) with ESMTP id 0E04B28C15A for ; Fri, 27 Feb 2009 10:30:54 -0800 (PST) Received: from nephilia.intra.cea.fr (nephilia.intra.cea.fr [132.166.88.33]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-1.2) with ESMTP id n1RIVFWd016823; Fri, 27 Feb 2009 19:31:15 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by nephilia.intra.cea.fr (8.13.8/8.13.8) with ESMTP id n1RIVEX4014123; Fri, 27 Feb 2009 19:31:14 +0100 (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 n1RIVEx3018429; Fri, 27 Feb 2009 19:31:14 +0100 Message-ID: <49A83172.70105@gmail.com> Date: Fri, 27 Feb 2009 19:31:14 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: "Stan Ratliff (sratliff)" References: <499F0BA7.90501@piuha.net> <7E8A76F7-2CE0-463A-8EE8-8877C46B4715@gmail.com> <49A6D436.7020505@gmail.com> <000001c99845$1dc56190$595024b0$@nl> <49A6F125.40400@gmail.com> <1235680887.4585.5.camel@localhost><49A7BB89.5040807@gmail.com> <003901c998cb$42b71e90$c8255bb0$@nl><49A7E97A.2010503@gmail.com> <006801c998fd$06c5bd60$14513820$@nl> <49A8272D.2060400@gmail.com> <7FB7EE0A621BA44B8B69E5F0A09DC76407AD0C48@xmb-rtp-208.amer.cisco.com> In-Reply-To: <7FB7EE0A621BA44B8B69E5F0A09DC76407AD0C48@xmb-rtp-208.amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org Subject: Re: [Autoconf] new charter X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 18:30:56 -0000 Stan Ratliff (sratliff) a écrit : >> >> Well I agree the physical laws are so. But I disagree to have 25km >> MANETs in the Charter. I agree with "25m IPv6 subnets", if they >> were explicitely stated so in the charter. >> >> Alex >> > > And I'll have to disagree with the "25m subnets". I regularly deal > with line-of-sight radio links that are in excess of 25km. We can't > limit ourselves to short-range technologies (e.g. Commercial 802.11, > Bluetooth, Zigbee, etc). I don't believe a distance should be > explicitly stated in the charter, rather, some verbiage that talks > about "radio neighbors in range" should be sufficient. I wouldn't disagree with a Charter mentioning we deal with 25m IPv6 subnets and with 30.000km IPv6 subnets, and here are the two practical methods to put addresses on these nodes. But I would disagree with a Charter saying we deal with all wireless links ranging from personal area to sattellite and everything in between and the generic addressing model is the following... Alex From alexandru.petrescu@gmail.com Fri Feb 27 10:37:00 2009 Return-Path: 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 A2F113A6ADB for ; Fri, 27 Feb 2009 10:37:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.193 X-Spam-Level: X-Spam-Status: No, score=-2.193 tagged_above=-999 required=5 tests=[AWL=0.056, 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 vKBgciF-1nrj for ; Fri, 27 Feb 2009 10:37:00 -0800 (PST) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.166.172.106]) by core3.amsl.com (Postfix) with ESMTP id B6CE13A67D4 for ; Fri, 27 Feb 2009 10:36:59 -0800 (PST) Received: from nephilia.intra.cea.fr (nephilia.intra.cea.fr [132.166.88.33]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-1.2) with ESMTP id n1RIbKg4026030; Fri, 27 Feb 2009 19:37:20 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by nephilia.intra.cea.fr (8.13.8/8.13.8) with ESMTP id n1RIbJ03021734; Fri, 27 Feb 2009 19:37:20 +0100 (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 n1RIbJpX019046; Fri, 27 Feb 2009 19:37:19 +0100 Message-ID: <49A832DF.4040805@gmail.com> Date: Fri, 27 Feb 2009 19:37:19 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: "Stan Ratliff (sratliff)" References: <499F0BA7.90501@piuha.net> <7E8A76F7-2CE0-463A-8EE8-8877C46B4715@gmail.com> <49A6D436.7020505@gmail.com> <000001c99845$1dc56190$595024b0$@nl> <49A6F125.40400@gmail.com> <1235680887.4585.5.camel@localhost><49A7BB89.5040807@gmail.com> <003901c998cb$42b71e90$c8255bb0$@nl><49A7E97A.2010503@gmail.com> <006801c998fd$06c5bd60$14513820$@nl> <49A8272D.2060400@gmail.com> <7FB7EE0A621BA44B8B69E5F0A09DC76407AD0C48@xmb-rtp-208.amer.cisco.com> <49A83172.70105@gmail.com> In-Reply-To: <49A83172.70105@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: autoconf@ietf.org Subject: [Autoconf] radio neighbors in range X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 18:37:00 -0000 To my understanding, mentioning radio neighbors in range implies we discover they're risking hidden-terminal and non-transitive problems. Neighbors in fully transitive range with exposed terminals would be more precise. Alex From sratliff@cisco.com Fri Feb 27 10:55:34 2009 Return-Path: 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 BC09528C392 for ; Fri, 27 Feb 2009 10:55:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 GvD3zJXJQ-TG for ; Fri, 27 Feb 2009 10:55:34 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id A4F3328C1EF for ; Fri, 27 Feb 2009 10:55:32 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,277,1233532800"; d="scan'208";a="38722820" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 27 Feb 2009 18:55:55 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n1RItt6D013871; Fri, 27 Feb 2009 13:55:55 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n1RItsHn009951; Fri, 27 Feb 2009 18:55:55 GMT Received: from xmb-rtp-208.amer.cisco.com ([64.102.31.43]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Feb 2009 13:55:54 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 27 Feb 2009 13:55:54 -0500 Message-ID: <7FB7EE0A621BA44B8B69E5F0A09DC76407AD0C70@xmb-rtp-208.amer.cisco.com> In-Reply-To: <49A83172.70105@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Autoconf] new charter Thread-Index: AcmZCZbxWItnMoSSS9+4bsfmeG3saAAAx/mg References: <499F0BA7.90501@piuha.net> <7E8A76F7-2CE0-463A-8EE8-8877C46B4715@gmail.com> <49A6D436.7020505@gmail.com> <000001c99845$1dc56190$595024b0$@nl> <49A6F125.40400@gmail.com> <1235680887.4585.5.camel@localhost><49A7BB89.5040807@gmail.com> <003901c998cb$42b71e90$c8255bb0$@nl><49A7E97A.2010503@gmail.com> <006801c998fd$06c5bd60$14513820$@nl> <49A8272D.2060400@gmail.com> <7FB7EE0A621BA44B8B69E5F0A09DC76407AD0C48@xmb-rtp-208.amer.cisco.com> <49A83172.70105@gmail.com> From: "Stan Ratliff (sratliff)" To: "Alexandru Petrescu" X-OriginalArrivalTime: 27 Feb 2009 18:55:54.0873 (UTC) FILETIME=[04AB4E90:01C9990D] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1804; t=1235760955; x=1236624955; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sratliff@cisco.com; z=From:=20=22Stan=20Ratliff=20(sratliff)=22=20 |Subject:=20RE=3A=20[Autoconf]=20new=20charter |Sender:=20 |To:=20=22Alexandru=20Petrescu=22=20; bh=Mn12wxnCrIqvgykKxj2+IXMbIT8//SANT9w1eg7n9xg=; b=l3CHctZi3ydCIl7g9+BAjyHI/Hv3+Frr8AsAu4SW9lv+WQ2WtR6JJ5dVd7 U31ns9kUYfNS0OYyKWVF1cC2v7sSsqkrMKyWhL365uDheSR2JZtv/gsW/1Y3 5kmQ0oy+09; Authentication-Results: rtp-dkim-1; header.From=sratliff@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: autoconf@ietf.org Subject: Re: [Autoconf] new charter X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 18:55:34 -0000 =20 > -----Original Message----- > From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com]=20 > Sent: Friday, February 27, 2009 1:31 PM > To: Stan Ratliff (sratliff) > Cc: Alexandru Petrescu; Teco Boot; autoconf@ietf.org > Subject: Re: [Autoconf] new charter >=20 > Stan Ratliff (sratliff) a =E9crit : > >>=20 > >> Well I agree the physical laws are so. But I disagree to=20 > have 25km =20 > >> MANETs in the Charter. I agree with "25m IPv6 subnets",=20 > if they were=20 > >> explicitely stated so in the charter. > >>=20 > >> Alex > >>=20 > >=20 > > And I'll have to disagree with the "25m subnets". I regularly deal=20 > > with line-of-sight radio links that are in excess of 25km. We can't=20 > > limit ourselves to short-range technologies (e.g.=20 > Commercial 802.11, =20 > > Bluetooth, Zigbee, etc). I don't believe a distance should be=20 > > explicitly stated in the charter, rather, some verbiage that talks=20 > > about "radio neighbors in range" should be sufficient. >=20 > I wouldn't disagree with a Charter mentioning we deal with=20 > 25m IPv6 subnets and with 30.000km IPv6 subnets, and here are=20 > the two practical methods to put addresses on these nodes. >=20 > But I would disagree with a Charter saying we deal with all=20 > wireless links ranging from personal area to sattellite and=20 > everything in between > and the generic addressing model is the following... >=20 > Alex >=20 Hmmm, that's a problem. Because I don't see a difference in a 3m subnet = using Bluetooth, and a 35,000km "subnet" using a satellite with IP = routing on board. I think the charter needs to solve the problem for = both of those, because I believe the distance of the link shouldn't be a = factor.=20 Regards, Stan >=20 >=20 From sratliff@cisco.com Fri Feb 27 10:57:24 2009 Return-Path: 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 B290B28C395 for ; Fri, 27 Feb 2009 10:57:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 x6iHLEpvrgYw for ; Fri, 27 Feb 2009 10:57:23 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 8F4CB28C1EF for ; Fri, 27 Feb 2009 10:57:23 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,277,1233532800"; d="scan'208";a="38685084" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 27 Feb 2009 18:57:46 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n1RIvj0m008242; Fri, 27 Feb 2009 13:57:45 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n1RIvjg1010910; Fri, 27 Feb 2009 18:57:45 GMT Received: from xmb-rtp-208.amer.cisco.com ([64.102.31.43]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Feb 2009 13:57:45 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 27 Feb 2009 13:57:45 -0500 Message-ID: <7FB7EE0A621BA44B8B69E5F0A09DC76407AD0C74@xmb-rtp-208.amer.cisco.com> In-Reply-To: <49A832DF.4040805@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: radio neighbors in range Thread-Index: AcmZCncwfbrwcfmbRhKcbqL+zob2wQAAqP1A References: <499F0BA7.90501@piuha.net> <7E8A76F7-2CE0-463A-8EE8-8877C46B4715@gmail.com> <49A6D436.7020505@gmail.com> <000001c99845$1dc56190$595024b0$@nl> <49A6F125.40400@gmail.com> <1235680887.4585.5.camel@localhost><49A7BB89.5040807@gmail.com> <003901c998cb$42b71e90$c8255bb0$@nl><49A7E97A.2010503@gmail.com> <006801c998fd$06c5bd60$14513820$@nl> <49A8272D.2060400@gmail.com> <7FB7EE0A621BA44B8B69E5F0A09DC76407AD0C48@xmb-rtp-208.amer.cisco.com> <49A83172.70105@gmail.com> <49A832DF.4040805@gmail.com> From: "Stan Ratliff (sratliff)" To: "Alexandru Petrescu" X-OriginalArrivalTime: 27 Feb 2009 18:57:45.0848 (UTC) FILETIME=[46D0BF80:01C9990D] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=754; t=1235761065; x=1236625065; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sratliff@cisco.com; z=From:=20=22Stan=20Ratliff=20(sratliff)=22=20 |Subject:=20RE=3A=20radio=20neighbors=20in=20range |Sender:=20 |To:=20=22Alexandru=20Petrescu=22=20; bh=8FYRqixWWcwgwOkEYcX9JK/cXSHxKaMMCiZdeDXYhd0=; b=WDDdO8jC2EOyEoPgxOZSpROsXYwdffiS1YcwE3rZAUCq+KGE937/Sb9l4O uXwQgBV81AQd/JNQBAb/DneFxy9nxj1AioAB6fEnNsKBGQ/89h8tO/eAyYGW 49kDYIwy3q; Authentication-Results: rtp-dkim-2; header.From=sratliff@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: autoconf@ietf.org Subject: Re: [Autoconf] radio neighbors in range X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 18:57:24 -0000 OK, I can go with the "fully transitive" verbiage. I don't think the hidden-terminal problem applies here, because that's going to happen regardless of the transitivity of the radio link(s).=20 Regards, Stan=20 > -----Original Message----- > From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com]=20 > Sent: Friday, February 27, 2009 1:37 PM > To: Stan Ratliff (sratliff) > Cc: Teco Boot; autoconf@ietf.org > Subject: radio neighbors in range >=20 > To my understanding, mentioning radio neighbors in range=20 > implies we discover they're risking hidden-terminal and=20 > non-transitive problems. >=20 > Neighbors in fully transitive range with exposed terminals=20 > would be more precise. >=20 > Alex >=20 >=20 >=20 From teco@inf-net.nl Fri Feb 27 11:28:29 2009 Return-Path: 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 E5CD03A6A89 for ; Fri, 27 Feb 2009 11:28:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.575 X-Spam-Level: X-Spam-Status: No, score=-0.575 tagged_above=-999 required=5 tests=[AWL=-0.929, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_44=0.6, J_CHICKENPOX_54=0.6, J_CHICKENPOX_55=0.6, J_CHICKENPOX_56=0.6] 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 MH9t+5i9bUmg for ; Fri, 27 Feb 2009 11:28:28 -0800 (PST) Received: from cpsmtpo-eml02.kpnxchange.com (cpsmtpo-eml02.KPNXCHANGE.COM [213.75.38.151]) by core3.amsl.com (Postfix) with ESMTP id 21A653A6A45 for ; Fri, 27 Feb 2009 11:28:27 -0800 (PST) Received: from cpsmtp-eml109.kpnxchange.com ([10.94.168.109]) by cpsmtpo-eml02.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 27 Feb 2009 20:28:28 +0100 Received: from M90Teco ([86.83.9.22]) by cpsmtp-eml109.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 27 Feb 2009 20:28:28 +0100 From: "Teco Boot" To: "'Alexandru Petrescu'" References: <499F0BA7.90501@piuha.net> <7E8A76F7-2CE0-463A-8EE8-8877C46B4715@gmail.com> <49A6D436.7020505@gmail.com> <000001c99845$1dc56190$595024b0$@nl> <49A6F125.40400@gmail.com> <1235680887.4585.5.camel@localhost> <002f01c998bf$8f112210$ad336630$@nl> <49A7E58C.2020303@gmail.com> <007201c99903$c4182c80$4c488580$@nl> <49A82E55.10208@gmail.com> In-Reply-To: <49A82E55.10208@gmail.com> Date: Fri, 27 Feb 2009 20:28:27 +0100 Message-ID: <007b01c99911$907facf0$b17f06d0$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcmZB7nuNP3vnYWDSVSxqkIY+onCOQAA8YfQ Content-Language: nl x-cr-hashedpuzzle: BjwL DhGr DrxE D1v0 EcOL Fzq6 Hlfc IkZY KW9k LW8M LnJX MfBD Rl+E SAYq Tlnu VHkq; 2; YQBsAGUAeABhAG4AZAByAHUALgBwAGUAdAByAGUAcwBjAHUAQABnAG0AYQBpAGwALgBjAG8AbQA7AGEAdQB0AG8AYwBvAG4AZgBAAGkAZQB0AGYALgBvAHIAZwA=; Sosha1_v1; 7; {2D4501FF-44F0-410D-8F0C-7AB1A93A2828}; dABlAGMAbwBAAGkAbgBmAC0AbgBlAHQALgBuAGwA; Fri, 27 Feb 2009 19:28:21 GMT; UgBFADoAIABBAHUAdABvAGMAbwBuAGYAIABhAGQAZAByAGUAcwBzAGkAbgBnACAAbQBvAGQAZQBsAA== x-cr-puzzleid: {2D4501FF-44F0-410D-8F0C-7AB1A93A2828} X-OriginalArrivalTime: 27 Feb 2009 19:28:28.0069 (UTC) FILETIME=[90DD5D50:01C99911] Cc: autoconf@ietf.org Subject: Re: [Autoconf] Autoconf addressing model X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 19:28:30 -0000 Inline. |-----Oorspronkelijk bericht----- |Van: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] |Verzonden: vrijdag 27 februari 2009 19:18 |Aan: Teco Boot |CC: autoconf@ietf.org |Onderwerp: Re: Autoconf addressing model | |Teco Boot a =E9crit : |[...] |>>> I think there is a much more obvious option, using the RFC2464 |>>> model for the MANET interface and /128 (or /32) for loopback |>>> interfaces. Both would use high probability globally unique |>>> Interface IDs like EUI-64 (Extended Unique Identifier). |>> |>> I don't agree going that way. I think loopback addresses are for |>> self addressing not for talking to other nodes. |> |> See other mail also, on Linux. I think loopback addresses are often |> used for stable connections to routers, where interfaces flap but due |> to redundancy there are alternative paths. | |I think you mean a virtual interface actually, not necessarily the |loopback interface (and yes, lo is a 'virtual' interface). | |Not all virtual interfaces are loopback. Router folks use "loopback" for what is meant here. Virtual interfaces = have a much, much broader meaning. A tunnel interface or VLAN / FR / ATM subinterface is a virtual interface but definitely not what I intent to = use. I prefer keep using the term loopback here. | |> RFC3871: It is a common practice among operators to configure |> "loopback" pseudo-interfaces to use as the source and destination of |> management traffic. | |Well that RFC is completely wrong please someone correct it. The |loopback address is ::1 and it can't be used to communicate outside the |computer. Yes pseudo-interface (and maybe 'virtual') but no loopback. I think you mix up "host loopback" and "router loopback". These are = very, very different! |And yes the interface in the routing table for the entry address/128 is |'lo' which is yes the loopback interface but no, never will that = address |be in the src nor dst fields of any packet leaving the computer (other |than encapsulated maybe). I checked this on the Linux host. I assigned another address on the lo interface. And the Linux host is reachable on this address, as long as = other nodes has a path to this /128 prefix. Sorry, you are wrong. Detailed info: debian-fs1:/proc/sys/net/ipv6/neigh/eth0# ifconfig lo =20 lo Link encap:Local Loopback =20 inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: 2001:db8:1::3333/128 Scope:Global inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:185 errors:0 dropped:0 overruns:0 frame:0 TX packets:185 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0=20 RX bytes:13568 (13.2 KiB) TX bytes:13568 (13.2 KiB) Tested from IOS router: nbs3725#ping 2001:db8:1::3333 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 2001:DB8:1::3333, timeout is 2 = seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max =3D 0/0/4 ms nbs3725# I added reachability manually: nbs3725#show ipv6 route IPv6 Routing Table - 4 entries Codes: C - Connected, L - Local, S - Static, R - RIP, B - BGP U - Per-user Static route, M - MIPv6 I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea, IS - ISIS = summary O - OSPF intra, OI - OSPF inter, OE1 - OSPF ext 1, OE2 - OSPF ext = 2 ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2 D - EIGRP, EX - EIGRP external C 2001:DB8:1::/64 [0/0] via ::, FastEthernet0/0.22 L 2001:DB8:1::1/128 [0/0] via ::, FastEthernet0/0.22 S 2001:DB8:1::3333/128 [1/0] via FE80::20C:29FF:FEE3:BDF5, FastEthernet0/0.22 L FF00::/8 [0/0] via ::, Null0 nbs3725# Debug info, showing that you are wrong, the IP address in interface lo = is reachable: Feb 27 19:08:08.018: IPv6: SAS picked source 2001:DB8:1::1 for 2001:DB8:1::3333 (FastEthernet0/0.22) Feb 27 19:08:08.018: IPv6: nexthop FE80::20C:29FF:FEE3:BDF5, Feb 27 19:08:08.018: IPV6: source 2001:DB8:1::1 (local) Feb 27 19:08:08.018: dest 2001:DB8:1::3333 (FastEthernet0/0.22) Feb 27 19:08:08.018: traffic class 0, flow 0x0, len 100+0, prot = 58, hops 64, originating Feb 27 19:08:08.018: IPv6: Sending on FastEthernet0/0.22 Feb 27 19:08:08.022: IPV6: source 2001:DB8:1::3333 (FastEthernet0/0.22) Feb 27 19:08:08.022: dest 2001:DB8:1::1 Feb 27 19:08:08.022: traffic class 0, flow 0x0, len 100+14, prot = 58, hops 64, forward to ulp SSH works well also. NTP used the address automatically: debian-fs1:~# netstat -anp | grep 3333 tcp6 0 52 2001:db8:1::3333:22 2001:db8:1::1:61026 ESTABLISHED 4756/5 =20 udp6 0 0 2001:db8:1::3333:123 :::* 2308/ntpd =20 |>> [rfc4291 and 2464 citations] |>>> It is not only because the RFC texts that I dislike the /128 in |>>> MANET interfaces, it is also backward compatibility with current |>>> IP stacks (and probably many applications). |>> |>> I agree. |>> |>>> I think using /128 for loopback interfaces fits the requirements |>>> for the addressing model. If a loopback interface is used, MANET |>>> interfaces do not require a globally unique address. |>> |>> I'm not sure I could agree with the MANET interface being the |>> loopback interface. It sounds as a significant departure. |> |> The MANET interface is not a loopback interface! It is the interface |> to a radio, e.g. 802.11 NIC in IBSS mode (your wifi adhoc). | |I agree with this. But in the immediately above text you're saying |"using /128 for loopback interfaces fits" - I think you meant 'virtual' |interface, not 'loopback' interface, right? No, absolutely not. I provided the evidence that the loopback is perfectly usable already. |>>> RFC4291 once more (out of section, also cited above): Unicast |>>> addresses with a scope greater than link-scope are not needed for |>>> interfaces that are not used as the origin or destination of any |>>> IPv6 packets to or from non-neighbors. So "host functionality" |>>> can be provided using the globally (or MANET local) unique |>>> address assigned to a loopback address, or another non-MANET |>>> interface. |>> |>> An address assigned to an address? I think it risks many |>> misunderstandings. |> |> Typo, I meant: So "host functionality" can be provided using the |> globally (or MANET local) unique address assigned to a loopback |> interface, or another non-MANET interface. | |Ok. | | |> I think this model solves some problems. o The assigned address can |> be used over whatever interface. This fulfills a requirement of "ad |> hoc", something works without planning. | |I thought the unplanned aspect could be treated by IPv6 stateless |autoconf and IPv6-over-Ethernet link-local addresses. Yes and no. I like SLAAC, but with SLAAC, thewre is an address per interface. In this model, the node is reachable via the loopback address = via whatever interface. |> o Connectivity is not broken if a path swap occurs (the RFC3781 |> loopback BCP) o It provides some scalability, as only a single |> address is needed, even if multiple interfaces are used. o |> Applications are not confused by "host prefixes" to a link, where |> other nodes are reachable. I tested this with linux and IPv4 with |> /32. | |Before deciding on the solution (address assigned to a virtual |interface) I need to udnerstand how path swap occurs and why. Because movement. A MANET Router may have multiple interfaces, some of = them could be MANET, others wireless infrastructure mode and others MANET. = When a fire truck leaves the brigade, it looses its wired / wifi ESS = connection, but can still communicate with other vehicles nearby using MANET links. |> Problems started with ARP processing, and I swapped to another |> addressing model immediately. | |>> For my clarification, what's fd01? (2001:db8:: is a prefix for |>> documentation rfc3849, ULA is fc00 rfc4193). |> |> ULA prefix is FC00::/7. 8th but is L, set to 1 if locally assigned. |> So all ULA would start with FD, the FC is for the future where a |> registration body maintains the universal uniqueness. |> |> 0xFC + 0x01 =3D 0xFD. | |Ah! So a correct ULA address would be fd01::1/128? In this sense, = when |drawing pictures I have a choice between fd01::1/128 ULA and |2001:db8::1/128 global address, it's ambiguous. | |>>> Manually assigned, or pre-configured (e.g. with SNMP) or formed |>>> according to a to be defined [Autoconf for MANETs] protocol, with |>>> a to-be-defined prefix (e.g. ULA, RFC4193). |>>> |>>> Although all nodes are marked as router, this does not imply all |>>> nodes forward packets. All nodes run a MANET routing protocol for |>>> learning |>> the |>>> MANET topology. |>>> |>>> |>>> In case one of the routers is connected to the Internet or |>>> private |>> network, |>>> this router can advertize a prefix in the MANET, and this |>>> information |>> is |>>> distributed in the MANET with an [Autoconf for MANETs] protocol. |>> |>> Why shouldn't it be distributed with DHCP and with OSPF, for |>> example. |> |> In a MANET, there are some problems with standard OSPF. OSPF-MANET is |> perfectly fine to use in a MANET. | |Ok. | |> DHCP (with relay) can be used for "pull", but there is a problem |> finding the best relay agent. I think there should be a mechanism |> that informs nodes of available facilities, e.g. shortest path to a |> DHCP server. Updating ND RA with some info for finding a DHCP server |> looks a good idea to me, and I updated my Border Router Discovery |> Protocol (BRDP) [Autoconf] proposal for DHCP support already. | |Sounds interesting. But I think normal DHCP could run ok, provided the |Relays know the address of the Server. In a first practical step would |be to manually configure the Server's address on each Relays. When many DHCP Relay Agenst are nearby, who to select? If multicast is = used, all of them will relay and this ends in a DHCP Relay storm (collisions, loss, retry .....) |> However, there is a chicken - egg problem. In a wired network, the |> DHCP client - DHCP relay agent relation is stable. This is certainly |> not the case in a MANET. | |Well it is the case in a MANET made of 25meter IPv6 subnets. Voice over IP over WLAN for 25meter? Just shout!! My requirements are over 25meter. 25km is no joke. Wifi is not usable = here. |> Therefore, I think a DHCP client should start with building reliable |> communication to a DHCP server, and the MANET routing protocols can |> provide such. But the MANET routing protocol needs a prefix that |> corresponds to this MANET node. For this reason, I think it makes |> sense to start with generating a prefix without DHCP, and we could |> use a prefix "push model" here. | |Well I think this is indeed a very chickeneggy problem: are addresses = in |place before routing is, or vice-versa. But what would we do in |practice? Certainly we'd manually assign some addresses - let's see |these cases first. No. MANETs are often used in workgroups, whit lack of knowledge of = configuring something. The network must be plug&play / zero-config. |>> Above, and in the following figures, I don't understand "--->, |>> Prefix Information". Is that RA? Or OSPF? Or routing protocol? |>> Or DHCP Prefix Delegation? |> |> This is under discussion, and the reason we have an [Autoconf] WG. |> There are proposals that rely on a routing protocol, but the old |> charter mentioned being independent of a routing protocol. | |I think we should consider first the practical cases. No. I think we have a clear picture of why MANETs are being used.=20 We need an [Autoconf] solution. Let's take the next steps defining an addressing model, write down the requirements and then look for = solutions. Teco. |Alex From budden@nps.edu Fri Feb 27 11:43:11 2009 Return-Path: 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 B556E3A68BD for ; Fri, 27 Feb 2009 11:43:11 -0800 (PST) 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 wtfJpFmnC9aH for ; Fri, 27 Feb 2009 11:43:10 -0800 (PST) Received: from virginia.nps.edu (virginia.nps.edu [205.155.65.15]) by core3.amsl.com (Postfix) with ESMTP id C7E253A6966 for ; Fri, 27 Feb 2009 11:43:06 -0800 (PST) Received: from localhost.localdomain ([172.20.57.107]) by virginia.nps.edu with Microsoft SMTPSVC(6.0.3790.3959); Fri, 27 Feb 2009 11:43:29 -0800 Message-ID: <49A84285.5030103@nps.navy.mil> Date: Fri, 27 Feb 2009 11:44:05 -0800 From: Rex Buddenberg User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: "Stan Ratliff (sratliff)" References: <499F0BA7.90501@piuha.net> <7E8A76F7-2CE0-463A-8EE8-8877C46B4715@gmail.com> <49A6D436.7020505@gmail.com> <000001c99845$1dc56190$595024b0$@nl> <49A6F125.40400@gmail.com> <1235680887.4585.5.camel@localhost><49A7BB89.5040807@gmail.com> <003901c998cb$42b71e90$c8255bb0$@nl><49A7E97A.2010503@gmail.com> <006801c998fd$06c5bd60$14513820$@nl> <49A8272D.2060400@gmail.com> <7FB7EE0A621BA44B8B69E5F0A09DC76407AD0C48@xmb-rtp-208.amer.cisco.com> <49A83172.70105@gmail.com> <7FB7EE0A621BA44B8B69E5F0A09DC76407AD0C70@xmb-rtp-208.amer.cisco.com> In-Reply-To: <7FB7EE0A621BA44B8B69E5F0A09DC76407AD0C70@xmb-rtp-208.amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 27 Feb 2009 19:43:29.0478 (UTC) FILETIME=[AA257660:01C99913] Cc: autoconf@ietf.org Subject: Re: [Autoconf] new charter X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 19:43:11 -0000 Stan, The difference is not geo footprint (you got that right). Rather the difference is between LAN (at fringe of network) and WAN (in the interior). A WAN will always be at least one router away from end systems. While we're at it, references to SSIDs is not proper -- that's 802.11-specific. Stan Ratliff (sratliff) wrote: > > > >> -----Original Message----- >> From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] >> Sent: Friday, February 27, 2009 1:31 PM >> To: Stan Ratliff (sratliff) >> Cc: Alexandru Petrescu; Teco Boot; autoconf@ietf.org >> Subject: Re: [Autoconf] new charter >> >> Stan Ratliff (sratliff) a écrit : >> >>>> Well I agree the physical laws are so. But I disagree to >>>> >> have 25km >> >>>> MANETs in the Charter. I agree with "25m IPv6 subnets", >>>> >> if they were >> >>>> explicitely stated so in the charter. >>>> >>>> Alex >>>> >>>> >>> And I'll have to disagree with the "25m subnets". I regularly deal >>> with line-of-sight radio links that are in excess of 25km. We can't >>> limit ourselves to short-range technologies (e.g. >>> >> Commercial 802.11, >> >>> Bluetooth, Zigbee, etc). I don't believe a distance should be >>> explicitly stated in the charter, rather, some verbiage that talks >>> about "radio neighbors in range" should be sufficient. >>> >> I wouldn't disagree with a Charter mentioning we deal with >> 25m IPv6 subnets and with 30.000km IPv6 subnets, and here are >> the two practical methods to put addresses on these nodes. >> >> But I would disagree with a Charter saying we deal with all >> wireless links ranging from personal area to sattellite and >> everything in between >> and the generic addressing model is the following... >> >> Alex >> >> > > > Hmmm, that's a problem. Because I don't see a difference in a 3m subnet using Bluetooth, and a 35,000km "subnet" using a satellite with IP routing on board. I think the charter needs to solve the problem for both of those, because I believe the distance of the link shouldn't be a factor. > > Regards, > Stan > > > >> > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf > > -- Rex Buddenberg Senior Lecturer Naval Postgraduate School Monterey, Ca 93943 831/656-3576 From teco@inf-net.nl Fri Feb 27 11:45:54 2009 Return-Path: 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 858493A67E4 for ; Fri, 27 Feb 2009 11:45:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.713 X-Spam-Level: X-Spam-Status: No, score=-1.713 tagged_above=-999 required=5 tests=[AWL=0.333, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] 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 viqz680UVJso for ; Fri, 27 Feb 2009 11:45:53 -0800 (PST) Received: from hpsmtp-eml15.kpnxchange.com (hpsmtp-eml15.KPNXCHANGE.COM [213.75.38.115]) by core3.amsl.com (Postfix) with ESMTP id 4ECEB3A63D3 for ; Fri, 27 Feb 2009 11:45:52 -0800 (PST) Received: from cpsmtp-eml110.kpnxchange.com ([10.94.168.110]) by hpsmtp-eml15.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 27 Feb 2009 20:46:14 +0100 Received: from M90Teco ([86.83.9.22]) by cpsmtp-eml110.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 27 Feb 2009 20:46:14 +0100 From: "Teco Boot" To: "'Alexandru Petrescu'" References: <499F0BA7.90501@piuha.net> <7E8A76F7-2CE0-463A-8EE8-8877C46B4715@gmail.com> <49A6D436.7020505@gmail.com> <000001c99845$1dc56190$595024b0$@nl> <49A6F125.40400@gmail.com> <1235680887.4585.5.camel@localhost> <49A7BB89.5040807@gmail.com> <003901c998cb$42b71e90$c8255bb0$@nl> <49A7E97A.2010503@gmail.com> <006801c998fd$06c5bd60$14513820$@nl> <49A82694.8090801@gmail.com> <007a01c99905$fd1619a0$f7424ce0$@nl> <49A82FE7.7090703@gmail.com> In-Reply-To: <49A82FE7.7090703@gmail.com> Date: Fri, 27 Feb 2009 20:46:13 +0100 Message-ID: <007c01c99914$0c0e7700$242b6500$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcmZCKmKXsNExR/KS32c9Hltw5oYkgACPv2g Content-Language: nl X-OriginalArrivalTime: 27 Feb 2009 19:46:14.0190 (UTC) FILETIME=[0C5284E0:01C99914] Cc: autoconf@ietf.org Subject: Re: [Autoconf] practical addressing X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 19:45:54 -0000 Inline. |-----Oorspronkelijk bericht----- |Van: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] |Verzonden: vrijdag 27 februari 2009 19:25 |Aan: Teco Boot |CC: autoconf@ietf.org |Onderwerp: Re: practical addressing | |Teco Boot a =E9crit : |> Inline. |> |> |-----Oorspronkelijk bericht----- |> |Van: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] |> |Verzonden: vrijdag 27 februari 2009 18:45 |> |Aan: Teco Boot |> |CC: autoconf@ietf.org |> |Onderwerp: Re: practical addressing (was: [Autoconf] new charter) |> | |> |[Thanks for the details Linux/Vista/IOS routing tables! I didn't |know |> | all that, only for linux] |> | |> |Teco Boot a =E9crit : |> |>>> Routers may generate a /128 prefix-address, and advertize this = in |> |>>> the routing domain. |> |> |> |>> A host-based route propagated and deleted throughout a domain? I |> |>> don't see the necessity of doing so. Assuming the routers are |> |>> mobile within 25m ranges then they wouldn't need to change their |> |>> addresses, thus no need to propagate host-based routes. |> |> |> |> If the /128 is not propagated, there will be no multi-hop network. |> | |> |Well I disagree. In the multi-hop network below only /64 prefixes |are |> |present in Routers' routing tables, no /128 (host-based) routes: |> | |> | |> | ----- wifi "adhoc1" ------ wifi "adhoc2" ------- = "adhoc3"----- |> | |Host1|---------------|Router|---------------|Router2|------- ||Host2| |> | ----- LL1 P1 LL2 ------ LL3 P2 LL4 -------LL5 P3 = LL6--- |> | G1 G4 |> | |> | P1, P2, P3: /64 prefixes, such as: |> | 2001:db8:1::/64 |> | 2001:db8:2::/64 and |> | 2001:db8:3::/64 |> | |> |Would this kind of use of /64 prefixes alleviate the need to |> |propagate/delete /128 prefixes throughout the network? |> |> Your routers need two wifi interfaces. | |Yes. | |> Often, there is only one wifi interface. | |If the charter text said we only look at routers with one physical |interface then I'd go away. | |And if it said we only look at routers with at least two physical |interfaces then my figures would be right. MANET Routers have one MANET Interface at a minimum. Two interfaces is = OK.=20 No one said your figures were "wrong". But there are cases that need = other topologies, like the two nearby hosts. |> The MANET Routing protocol provides connectivity between nodes that |> are out of range from each other, via relay nodes that are in range. | |Well that can be achieved with simple plain routing, not necessarily a |dynamic routing protocol. No.=20 One of the goals is providing connectivity in a dynamic topology. Static routing cannot provide this. |> Using many distinct SSIDs can introduce problems, e.g. Host-1 and |> Host-2 are near each other, but on a different SSID: | |Using a single SSID can introduce other problems, such as the now |documented hidden terminal problem. The hidden terminal problem MAY introduce somewhat reduced performance. = In 802.11, we have collision avoidance for unicast using RTS - CTS and automatic retransmit using ACK. Other MANET radios may use other = mechanisms. By the way, 802.11 tests have shown that the carrier sense range is = larger than Tx-Rx range and hidden terminal problem does not occur. (http://info.iet.unipi.it/~anastasi/papers/book_ch03.pdf). And keep in mind the hidden terminal problem applies to infrastructure = mode as well! On the multiple SSID solution, this is not acceptable in many cases, as = my life or dead example (2 hosts in range, connected to different SSISs). Teco. |We should make choices. | |Alex From teco@inf-net.nl Fri Feb 27 11:49:26 2009 Return-Path: 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 78A183A6803 for ; Fri, 27 Feb 2009 11:49:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.733 X-Spam-Level: X-Spam-Status: No, score=-1.733 tagged_above=-999 required=5 tests=[AWL=0.313, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] 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 HGM1nJg7P+LB for ; Fri, 27 Feb 2009 11:49:25 -0800 (PST) Received: from cpsmtpo-eml06.kpnxchange.com (cpsmtpo-eml06.KPNXCHANGE.COM [213.75.38.155]) by core3.amsl.com (Postfix) with ESMTP id 7F0483A67EC for ; Fri, 27 Feb 2009 11:49:25 -0800 (PST) Received: from cpsmtp-eml101.kpnxchange.com ([213.75.84.101]) by cpsmtpo-eml06.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 27 Feb 2009 20:49:47 +0100 Received: from M90Teco ([86.83.9.22]) by cpsmtp-eml101.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 27 Feb 2009 20:49:47 +0100 From: "Teco Boot" To: "'Alexandru Petrescu'" References: <499F0BA7.90501@piuha.net> <7E8A76F7-2CE0-463A-8EE8-8877C46B4715@gmail.com> <49A6D436.7020505@gmail.com> <000001c99845$1dc56190$595024b0$@nl> <49A6F125.40400@gmail.com> <1235680887.4585.5.camel@localhost><49A7BB89.5040807@gmail.com> <003901c998cb$42b71e90$c8255bb0$@nl><49A7E97A.2010503@gmail.com> <006801c998fd$06c5bd60$14513820$@nl> <49A8272D.2060400@gmail.com> <7FB7EE0A621BA44B8B69E5F0A09DC76407AD0C48@xmb-rtp-208.amer.cisco.com> <49A83172.70105@gmail.com> In-Reply-To: <49A83172.70105@gmail.com> Date: Fri, 27 Feb 2009 20:49:46 +0100 Message-ID: <007d01c99914$8b337210$a19a5630$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcmZCZWTvqIpMD6LSL+DuA64x37yHAACqRWQ Content-Language: nl X-OriginalArrivalTime: 27 Feb 2009 19:49:47.0573 (UTC) FILETIME=[8B822E50:01C99914] Cc: autoconf@ietf.org Subject: Re: [Autoconf] new charter X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 19:49:26 -0000 |-----Oorspronkelijk bericht----- |Van: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] |Verzonden: vrijdag 27 februari 2009 19:31 |Aan: Stan Ratliff (sratliff) |CC: Alexandru Petrescu; Teco Boot; autoconf@ietf.org |Onderwerp: Re: [Autoconf] new charter | |Stan Ratliff (sratliff) a =E9crit : |>> |>> Well I agree the physical laws are so. But I disagree to have 25km |>> MANETs in the Charter. I agree with "25m IPv6 subnets", if they |>> were explicitely stated so in the charter. |>> |>> Alex |>> |> |> And I'll have to disagree with the "25m subnets". I regularly deal |> with line-of-sight radio links that are in excess of 25km. We can't |> limit ourselves to short-range technologies (e.g. Commercial 802.11, |> Bluetooth, Zigbee, etc). I don't believe a distance should be |> explicitly stated in the charter, rather, some verbiage that talks |> about "radio neighbors in range" should be sufficient. | |I wouldn't disagree with a Charter mentioning we deal with 25m IPv6 |subnets and with 30.000km IPv6 subnets, and here are the two practical |methods to put addresses on these nodes. | |But I would disagree with a Charter saying we deal with all wireless |links ranging from personal area to sattellite and everything in = between | and the generic addressing model is the following... Why? I did not see a WG charter or RFC before, mentioning such. Check = for example RFC2464. It does not specify the length of a Cat5 cable, nor 10Base5, 10Base2 etc. Teco. | |Alex From teco@inf-net.nl Fri Feb 27 11:53:10 2009 Return-Path: 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 DCA3A3A67EC for ; Fri, 27 Feb 2009 11:53:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.752 X-Spam-Level: X-Spam-Status: No, score=-1.752 tagged_above=-999 required=5 tests=[AWL=0.294, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] 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 16ehwvvWdR+M for ; Fri, 27 Feb 2009 11:53:10 -0800 (PST) Received: from cpsmtpo-eml06.kpnxchange.com (cpsmtpo-eml06.KPNXCHANGE.COM [213.75.38.155]) by core3.amsl.com (Postfix) with ESMTP id F07343A688E for ; Fri, 27 Feb 2009 11:53:09 -0800 (PST) Received: from cpsmtp-eml109.kpnxchange.com ([10.94.168.109]) by cpsmtpo-eml06.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 27 Feb 2009 20:53:32 +0100 Received: from M90Teco ([86.83.9.22]) by cpsmtp-eml109.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 27 Feb 2009 20:53:31 +0100 From: "Teco Boot" To: "'Alexandru Petrescu'" References: <499F0BA7.90501@piuha.net> <7E8A76F7-2CE0-463A-8EE8-8877C46B4715@gmail.com> <49A6D436.7020505@gmail.com> <000001c99845$1dc56190$595024b0$@nl> <49A6F125.40400@gmail.com> <1235680887.4585.5.camel@localhost><49A7BB89.5040807@gmail.com> <003901c998cb$42b71e90$c8255bb0$@nl><49A7E97A.2010503@gmail.com> <006801c998fd$06c5bd60$14513820$@nl> <49A8272D.2060400@gmail.com> <7FB7EE0A621BA44B8B69E5F0A09DC76407AD0C48@xmb-rtp-208.amer.cisco.com> <49A83172.70105@gmail.com> <49A832DF.4040805@gmail.com> In-Reply-To: <49A832DF.4040805@gmail.com> Date: Fri, 27 Feb 2009 20:53:31 +0100 Message-ID: <007e01c99915$10eb9f90$32c2deb0$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcmZCm6JX76zgbd9ROiQjfnWG+Bb8gACkaSw Content-Language: nl X-OriginalArrivalTime: 27 Feb 2009 19:53:31.0998 (UTC) FILETIME=[1146B7E0:01C99915] Cc: autoconf@ietf.org Subject: Re: [Autoconf] radio neighbors in range X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 19:53:10 -0000 Alex, Any idea how to enforce such a restriction to the MANET users? Use 100m Cat5 cables, folded by four? And what if the teapot suddenly passes by? Teco. |-----Oorspronkelijk bericht----- |Van: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] |Verzonden: vrijdag 27 februari 2009 19:37 |Aan: Stan Ratliff (sratliff) |CC: Teco Boot; autoconf@ietf.org |Onderwerp: radio neighbors in range | |To my understanding, mentioning radio neighbors in range implies we |discover they're risking hidden-terminal and non-transitive problems. | |Neighbors in fully transitive range with exposed terminals would be more |precise. | |Alex From teco@inf-net.nl Fri Feb 27 12:00:26 2009 Return-Path: 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 9699328C0F8 for ; Fri, 27 Feb 2009 12:00:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.768 X-Spam-Level: X-Spam-Status: No, score=-1.768 tagged_above=-999 required=5 tests=[AWL=0.278, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] 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 lK9EUwX5tId0 for ; Fri, 27 Feb 2009 12:00:25 -0800 (PST) Received: from cpsmtpo-eml02.kpnxchange.com (cpsmtpo-eml02.KPNXCHANGE.COM [213.75.38.151]) by core3.amsl.com (Postfix) with ESMTP id 4FECD28C42C for ; Fri, 27 Feb 2009 12:00:16 -0800 (PST) Received: from cpsmtp-eml110.kpnxchange.com ([10.94.168.110]) by cpsmtpo-eml02.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 27 Feb 2009 21:00:35 +0100 Received: from M90Teco ([86.83.9.22]) by cpsmtp-eml110.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 27 Feb 2009 21:00:34 +0100 From: "Teco Boot" To: "'Rex Buddenberg'" References: <499F0BA7.90501@piuha.net> <7E8A76F7-2CE0-463A-8EE8-8877C46B4715@gmail.com> <49A6D436.7020505@gmail.com> <000001c99845$1dc56190$595024b0$@nl> <49A6F125.40400@gmail.com> <1235680887.4585.5.camel@localhost><49A7BB89.5040807@gmail.com> <003901c998cb$42b71e90$c8255bb0$@nl><49A7E97A.2010503@gmail.com> <006801c998fd$06c5bd60$14513820$@nl> <49A8272D.2060400@gmail.com> <7FB7EE0A621BA44B8B69E5F0A09DC76407AD0C48@xmb-rtp-208.amer.cisco.com> <49A83172.70105@gmail.com> <7FB7EE0A621BA44B8B69E5F0A09DC76407AD0C70@xmb-rtp-208.amer.cisco.com> <49A84285.5030103@nps.navy.mil> In-Reply-To: <49A84285.5030103@nps.navy.mil> Date: Fri, 27 Feb 2009 21:00:34 +0100 Message-ID: <007f01c99916$0d20bf70$27623e50$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcmZE7BqNK1PwWvqSYeoCV++h7dx5QAAavPQ Content-Language: nl X-OriginalArrivalTime: 27 Feb 2009 20:00:34.0951 (UTC) FILETIME=[0D603970:01C99916] Cc: autoconf@ietf.org Subject: Re: [Autoconf] new charter X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 20:00:26 -0000 |-----Oorspronkelijk bericht----- |Van: autoconf-bounces@ietf.org [mailto:autoconf-bounces@ietf.org] = Namens |Rex Buddenberg |Verzonden: vrijdag 27 februari 2009 20:44 |Aan: Stan Ratliff (sratliff) |CC: autoconf@ietf.org |Onderwerp: Re: [Autoconf] new charter | |Stan, | |The difference is not geo footprint (you got that right). Rather the |difference is between LAN (at fringe of network) and WAN (in the |interior). A WAN will always be at least one router away from end |systems. I am not sure on this.=20 In the disconnected multi-hop MANET, the WAN is NOT available. I agree in having a layered approach, e.g. edge network (or LAN) and backbone (or WAN). |While we're at it, references to SSIDs is not proper -- that's |802.11-specific. Yes. But 802.11 IBSS is often used as a reference for MANETs (cheap equipment?). Teco. |Stan Ratliff (sratliff) wrote: |> |> |> |>> -----Original Message----- |>> From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] |>> Sent: Friday, February 27, 2009 1:31 PM |>> To: Stan Ratliff (sratliff) |>> Cc: Alexandru Petrescu; Teco Boot; autoconf@ietf.org |>> Subject: Re: [Autoconf] new charter |>> |>> Stan Ratliff (sratliff) a =E9crit : |>> |>>>> Well I agree the physical laws are so. But I disagree to |>>>> |>> have 25km |>> |>>>> MANETs in the Charter. I agree with "25m IPv6 subnets", |>>>> |>> if they were |>> |>>>> explicitely stated so in the charter. |>>>> |>>>> Alex |>>>> |>>>> |>>> And I'll have to disagree with the "25m subnets". I regularly deal |>>> with line-of-sight radio links that are in excess of 25km. We can't |>>> limit ourselves to short-range technologies (e.g. |>>> |>> Commercial 802.11, |>> |>>> Bluetooth, Zigbee, etc). I don't believe a distance should be |>>> explicitly stated in the charter, rather, some verbiage that talks |>>> about "radio neighbors in range" should be sufficient. |>>> |>> I wouldn't disagree with a Charter mentioning we deal with |>> 25m IPv6 subnets and with 30.000km IPv6 subnets, and here are |>> the two practical methods to put addresses on these nodes. |>> |>> But I would disagree with a Charter saying we deal with all |>> wireless links ranging from personal area to sattellite and |>> everything in between |>> and the generic addressing model is the following... |>> |>> Alex |>> |>> |> |> |> Hmmm, that's a problem. Because I don't see a difference in a 3m |subnet using Bluetooth, and a 35,000km "subnet" using a satellite with |IP routing on board. I think the charter needs to solve the problem for |both of those, because I believe the distance of the link shouldn't be = a |factor. |> |> Regards, |> Stan |> |> |> |>> |> _______________________________________________ |> Autoconf mailing list |> Autoconf@ietf.org |> https://www.ietf.org/mailman/listinfo/autoconf |> |> | |-- |Rex Buddenberg |Senior Lecturer |Naval Postgraduate School |Monterey, Ca 93943 |831/656-3576 | |_______________________________________________ |Autoconf mailing list |Autoconf@ietf.org |https://www.ietf.org/mailman/listinfo/autoconf From alexandru.petrescu@gmail.com Fri Feb 27 12:03:54 2009 Return-Path: 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 1FD9B3A67B1 for ; Fri, 27 Feb 2009 12:03:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.026 X-Spam-Level: X-Spam-Status: No, score=-1.026 tagged_above=-999 required=5 tests=[AWL=-1.177, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_44=0.6, J_CHICKENPOX_54=0.6, J_CHICKENPOX_55=0.6, J_CHICKENPOX_56=0.6] 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 ZRhGjdws8PmP for ; Fri, 27 Feb 2009 12:03:53 -0800 (PST) Received: from smtp3-g21.free.fr (smtp3-g21.free.fr [212.27.42.3]) by core3.amsl.com (Postfix) with ESMTP id 984883A6839 for ; Fri, 27 Feb 2009 12:03:51 -0800 (PST) Received: from smtp3-g21.free.fr (localhost [127.0.0.1]) by smtp3-g21.free.fr (Postfix) with ESMTP id 423A28180EA; Fri, 27 Feb 2009 21:04:09 +0100 (CET) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp3-g21.free.fr (Postfix) with ESMTP id DC941818052; Fri, 27 Feb 2009 21:04:06 +0100 (CET) Message-ID: <49A8471E.6090506@gmail.com> Date: Fri, 27 Feb 2009 21:03:42 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Teco Boot References: <499F0BA7.90501@piuha.net> <7E8A76F7-2CE0-463A-8EE8-8877C46B4715@gmail.com> <49A6D436.7020505@gmail.com> <000001c99845$1dc56190$595024b0$@nl> <49A6F125.40400@gmail.com> <1235680887.4585.5.camel@localhost> <002f01c998bf$8f112210$ad336630$@nl> <49A7E58C.2020303@gmail.com> <007201c99903$c4182c80$4c488580$@nl> <49A82E55.10208@gmail.com> <007b01c99911$907facf0$b17f06d0$@nl> In-Reply-To: <007b01c99911$907facf0$b17f06d0$@nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 090226-0, 26/02/2009), Outbound message X-Antivirus-Status: Clean Cc: autoconf@ietf.org Subject: Re: [Autoconf] Autoconf addressing model X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 20:03:54 -0000 Teco Boot a écrit : > |Not all virtual interfaces are loopback. Again, do you think all virtual interfaces are 'loopback'? > Router folks use "loopback" for what is meant here. Virtual > interfaces have a much, much broader meaning. A tunnel interface or > VLAN / FR / ATM subinterface is a virtual interface but definitely > not what I intent to use. I prefer keep using the term loopback here. I strongly disagree using the term loopback interface, at least because it can be easily interpreted as the interface on which there's a 'loopback address'. And you don't seem to intend to use the loopback address. The loopback interface is the only interface on which there's a loopback address assigned. > |> RFC3871: It is a common practice among operators to configure |> > "loopback" pseudo-interfaces to use as the source and destination of > |> management traffic. | |Well that RFC is completely wrong please > someone correct it. The |loopback address is ::1 and it can't be > used to communicate outside the |computer. Yes pseudo-interface (and > maybe 'virtual') but no loopback. > > I think you mix up "host loopback" and "router loopback". These are > very, very different! I think there's no difference between host and router loopback. > |And yes the interface in the routing table for the entry address/128 > is |'lo' which is yes the loopback interface but no, never will that > address |be in the src nor dst fields of any packet leaving the > computer (other |than encapsulated maybe). > > I checked this on the Linux host. I assigned another address on the > lo interface. And the Linux host is reachable on this address, as > long as other nodes has a path to this /128 prefix. WEll yes, it is possible to manually assign any 128bit address routable or non-routable, on the loopback interface, as it is possible to assign any address on any interface be it virtual or physical. > Sorry, you are wrong. > > Detailed info: > > debian-fs1:/proc/sys/net/ipv6/neigh/eth0# ifconfig lo lo Link > encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: > 2001:db8:1::3333/128 Scope:Global inet6 addr: ::1/128 Scope:Host UP > LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:185 errors:0 > dropped:0 overruns:0 frame:0 TX packets:185 errors:0 dropped:0 > overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:13568 (13.2 > KiB) TX bytes:13568 (13.2 KiB) > > Tested from IOS router: nbs3725#ping 2001:db8:1::3333 Type escape > sequence to abort. Sending 5, 100-byte ICMP Echos to > 2001:DB8:1::3333, timeout is 2 seconds: !!!!! Success rate is 100 > percent (5/5), round-trip min/avg/max = 0/0/4 ms Well yes, that's ok, I don't see anything wrong with nbs3725 pinging debian-fs1's loopback interface's routable address. But the loopback interface is not used for its intended loopback meaning. That loopback interface doesn't use the loopback address - it's a virtual interface on which the loopback address is assigned. > Debug info, showing that you are wrong, the IP address in interface > lo is reachable: Well yes, because having a non-loopback IPv6 address on the loopback interface. > No, absolutely not. I provided the evidence that the loopback is > perfectly usable already. Why the loopback interface and not another virtual interface? Why mixing loopback semantics with a routable address semantics? > |I thought the unplanned aspect could be treated by IPv6 stateless > |autoconf and IPv6-over-Ethernet link-local addresses. > > Yes and no. I like SLAAC, but with SLAAC, thewre is an address per > interface. In this model, the node is reachable via the loopback > address via whatever interface. I think this creates more headaches than it solves. In a first step, do we agree that the node has typically more than one interface? We didn't seem to. If not, then why should we need to have the node reachable via whatever interface, since there's only one. If there are at least two interfaces, then why can't we use a different address on each of the interfaces? What's wrong with that? The fact that the node moves? Well, you seemed to accept host-based /128 routes - in this case instead of 1 there'll be 2 host-based /128 routes. What's wrong with that again? > |> o Connectivity is not broken if a path swap occurs (the RFC3781 |> > loopback BCP) o It provides some scalability, as only a single |> > address is needed, even if multiple interfaces are used. o |> > Applications are not confused by "host prefixes" to a link, where |> > other nodes are reachable. I tested this with linux and IPv4 with |> > /32. | |Before deciding on the solution (address assigned to a > virtual |interface) I need to udnerstand how path swap occurs and > why. > > Because movement. A MANET Router may have multiple interfaces, some > of them could be MANET, others wireless infrastructure mode and > others MANET. Sorry, I can't go along these lines. Movement described just like that, without any boundary, no pattern, just movement... I think I will simply summarize the topologies we discussed and leave it there. I also agree it's difficult to describe movement on paper (maybe easier on ppt) but we could at least try. [...] > |Sounds interesting. But I think normal DHCP could run ok, provided > the |Relays know the address of the Server. In a first practical > step would |be to manually configure the Server's address on each > Relays. > > When many DHCP Relay Agenst are nearby, who to select? If multicast > is used, all of them will relay and this ends in a DHCP Relay storm > (collisions, loss, retry .....) That issue is simple. Before the node can even have the choice to talk to a Relay, it will have to connect to the wifi "adhoc". The moment it connected to it it will only have one choice: the Relay present on that "adhoc" essid. > |> However, there is a chicken - egg problem. In a wired network, the > |> DHCP client - DHCP relay agent relation is stable. This is > certainly |> not the case in a MANET. | |Well it is the case in a > MANET made of 25meter IPv6 subnets. > > Voice over IP over WLAN for 25meter? Just shout!! :-) :-) I agree. But the IP in VoIP over a 25m IPv6 subnet allows me to talk to another IP much further who wouldn't hear my shout otherwise. > My requirements are over 25meter. 25km is no joke. Wifi is not usable > here. Well then. I think the mechanisms are completely different. A 25km radio link would use an addressing mechanism completely different. > |> Therefore, I think a DHCP client should start with building > reliable |> communication to a DHCP server, and the MANET routing > protocols can |> provide such. But the MANET routing protocol needs a > prefix that |> corresponds to this MANET node. For this reason, I > think it makes |> sense to start with generating a prefix without > DHCP, and we could |> use a prefix "push model" here. | |Well I think > this is indeed a very chickeneggy problem: are addresses in |place > before routing is, or vice-versa. But what would we do in |practice? > Certainly we'd manually assign some addresses - let's see |these > cases first. > > No. MANETs are often used in workgroups, whit lack of knowledge of > configuring something. The network must be plug&play / zero-config. > > > > |>> Above, and in the following figures, I don't understand "--->, > |>> Prefix Information". Is that RA? Or OSPF? Or routing protocol? > |>> Or DHCP Prefix Delegation? |> |> This is under discussion, and > the reason we have an [Autoconf] WG. |> There are proposals that rely > on a routing protocol, but the old |> charter mentioned being > independent of a routing protocol. | |I think we should consider > first the practical cases. > > No. I think we have a clear picture of why MANETs are being used. We > need an [Autoconf] solution. Let's take the next steps defining an > addressing model, write down the requirements and then look for > solutions. Sorry, it seems the Autoconf solution will come to live only if the first practical addressing solution can get agreement on. Alex From alexandru.petrescu@gmail.com Fri Feb 27 12:12:14 2009 Return-Path: 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 7B7843A6AD0 for ; Fri, 27 Feb 2009 12:12:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.16 X-Spam-Level: X-Spam-Status: No, score=-2.16 tagged_above=-999 required=5 tests=[AWL=0.089, 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 OeOuS-zbgQ+z for ; Fri, 27 Feb 2009 12:12:13 -0800 (PST) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by core3.amsl.com (Postfix) with ESMTP id 851013A6A89 for ; Fri, 27 Feb 2009 12:12:11 -0800 (PST) Received: from smtp5-g21.free.fr (localhost [127.0.0.1]) by smtp5-g21.free.fr (Postfix) with ESMTP id 8E62DD480E8; Fri, 27 Feb 2009 21:12:29 +0100 (CET) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp5-g21.free.fr (Postfix) with ESMTP id 66FC0D4819C; Fri, 27 Feb 2009 21:12:27 +0100 (CET) Message-ID: <49A84912.9060107@gmail.com> Date: Fri, 27 Feb 2009 21:12:02 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Teco Boot References: <499F0BA7.90501@piuha.net> <7E8A76F7-2CE0-463A-8EE8-8877C46B4715@gmail.com> <49A6D436.7020505@gmail.com> <000001c99845$1dc56190$595024b0$@nl> <49A6F125.40400@gmail.com> <1235680887.4585.5.camel@localhost><49A7BB89.5040807@gmail.com> <003901c998cb$42b71e90$c8255bb0$@nl><49A7E97A.2010503@gmail.com> <006801c998fd$06c5bd60$14513820$@nl> <49A8272D.2060400@gmail.com> <7FB7EE0A621BA44B8B69E5F0A09DC76407AD0C48@xmb-rtp-208.amer.cisco.com> <49A83172.70105@gmail.com> <49A832DF.4040805@gmail.com> <007e01c99915$10eb9f90$32c2deb0$@nl> In-Reply-To: <007e01c99915$10eb9f90$32c2deb0$@nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 090226-0, 26/02/2009), Outbound message X-Antivirus-Status: Clean Cc: autoconf@ietf.org Subject: Re: [Autoconf] radio neighbors in range X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 20:12:14 -0000 Teco Boot a écrit : > Alex, > > Any idea how to enforce such a restriction to the MANET users? By writing user manuals with specific tags: 25m no more. Within that range terminals are exposed and range is transitive. (the same for any 25m, 30.000m, etc). Alex > Use 100m Cat5 cables, folded by four? > > And what if the teapot suddenly passes by? > > Teco. > > |-----Oorspronkelijk bericht----- > |Van: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] > |Verzonden: vrijdag 27 februari 2009 19:37 > |Aan: Stan Ratliff (sratliff) > |CC: Teco Boot; autoconf@ietf.org > |Onderwerp: radio neighbors in range > | > |To my understanding, mentioning radio neighbors in range implies we > |discover they're risking hidden-terminal and non-transitive problems. > | > |Neighbors in fully transitive range with exposed terminals would be more > |precise. > | > |Alex > > > From sratliff@cisco.com Fri Feb 27 12:12:59 2009 Return-Path: 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 0FE7C3A69FF for ; Fri, 27 Feb 2009 12:12:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 L-6yLNVPwckJ for ; Fri, 27 Feb 2009 12:12:58 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id EDAF13A695A for ; Fri, 27 Feb 2009 12:12:57 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,278,1233532800"; d="scan'208";a="38734888" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 27 Feb 2009 20:13:20 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n1RKDK0b001037; Fri, 27 Feb 2009 15:13:20 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n1RKDKCi029296; Fri, 27 Feb 2009 20:13:20 GMT Received: from xmb-rtp-208.amer.cisco.com ([64.102.31.43]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Feb 2009 15:13:20 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 27 Feb 2009 15:13:18 -0500 Message-ID: <7FB7EE0A621BA44B8B69E5F0A09DC76407AD0CF3@xmb-rtp-208.amer.cisco.com> In-Reply-To: <49A84285.5030103@nps.navy.mil> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Autoconf] new charter Thread-Index: AcmZE76JekuVqIpRT865d5rBrQuoRAAA3vDw References: <499F0BA7.90501@piuha.net> <7E8A76F7-2CE0-463A-8EE8-8877C46B4715@gmail.com> <49A6D436.7020505@gmail.com> <000001c99845$1dc56190$595024b0$@nl> <49A6F125.40400@gmail.com> <1235680887.4585.5.camel@localhost><49A7BB89.5040807@gmail.com> <003901c998cb$42b71e90$c8255bb0$@nl><49A7E97A.2010503@gmail.com> <006801c998fd$06c5bd60$14513820$@nl> <49A8272D.2060400@gmail.com> <7FB7EE0A621BA44B8B69E5F0A09DC76407AD0C48@xmb-rtp-208.amer.cisco.com> <49A83172.70105@gmail.com> <7FB7EE0A621BA44B8B69E5F0A09DC76407AD0C70@xmb-rtp-208.amer.cisco.com> <49A84285.5030103@nps.navy.mil> From: "Stan Ratliff (sratliff)" To: "Rex Buddenberg" X-OriginalArrivalTime: 27 Feb 2009 20:13:20.0038 (UTC) FILETIME=[D5673C60:01C99917] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3154; t=1235765600; x=1236629600; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sratliff@cisco.com; z=From:=20=22Stan=20Ratliff=20(sratliff)=22=20 |Subject:=20RE=3A=20[Autoconf]=20new=20charter |Sender:=20 |To:=20=22Rex=20Buddenberg=22=20; bh=Hfxik8N7vmSPmQWkhvL1Q1X1KCfAAn0H/8t6aBpExwA=; b=dTrciDCpTiCwvTzctbB4+8RMXTCPBU1ITRyZENBbdSjSUh5CHNR0WS1eXT ljTpf1Co3mOaxy3Q+moTbU64HOYgWzSMVvvunzsB+zKeAt6wWPqiKA/5uu0C G6tP0K8BXa; Authentication-Results: rtp-dkim-1; header.From=sratliff@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: autoconf@ietf.org Subject: Re: [Autoconf] new charter X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 20:12:59 -0000 > -----Original Message----- > From: Rex Buddenberg [mailto:budden@nps.navy.mil]=20 > Sent: Friday, February 27, 2009 2:44 PM > To: Stan Ratliff (sratliff) > Cc: Alexandru Petrescu; autoconf@ietf.org > Subject: Re: [Autoconf] new charter >=20 > Stan, >=20 > The difference is not geo footprint (you got that right). =20 > Rather the difference is between LAN (at fringe of network)=20 > and WAN (in the interior). A WAN will always be at least one=20 > router away from end systems.=20 Rex,=20 Absolutely agree with you. I understood the issue to be the former = instead of the latter.=20 Regards, Stan=20 >=20 > While we're at it, references to SSIDs is not proper --=20 > that's 802.11-specific.=20 >=20 > Stan Ratliff (sratliff) wrote: > > =20 > > > > =20 > >> -----Original Message----- > >> From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] > >> Sent: Friday, February 27, 2009 1:31 PM > >> To: Stan Ratliff (sratliff) > >> Cc: Alexandru Petrescu; Teco Boot; autoconf@ietf.org > >> Subject: Re: [Autoconf] new charter > >> > >> Stan Ratliff (sratliff) a =E9crit : > >> =20 > >>>> Well I agree the physical laws are so. But I disagree to > >>>> =20 > >> have 25km > >> =20 > >>>> MANETs in the Charter. I agree with "25m IPv6 subnets", > >>>> =20 > >> if they were > >> =20 > >>>> explicitely stated so in the charter. > >>>> > >>>> Alex > >>>> > >>>> =20 > >>> And I'll have to disagree with the "25m subnets". I=20 > regularly deal=20 > >>> with line-of-sight radio links that are in excess of=20 > 25km. We can't=20 > >>> limit ourselves to short-range technologies (e.g. > >>> =20 > >> Commercial 802.11, > >> =20 > >>> Bluetooth, Zigbee, etc). I don't believe a distance should be=20 > >>> explicitly stated in the charter, rather, some verbiage=20 > that talks=20 > >>> about "radio neighbors in range" should be sufficient. > >>> =20 > >> I wouldn't disagree with a Charter mentioning we deal with=20 > 25m IPv6=20 > >> subnets and with 30.000km IPv6 subnets, and here are the two=20 > >> practical methods to put addresses on these nodes. > >> > >> But I would disagree with a Charter saying we deal with=20 > all wireless=20 > >> links ranging from personal area to sattellite and everything in=20 > >> between > >> and the generic addressing model is the following... > >> > >> Alex > >> > >> =20 > > > > > > Hmmm, that's a problem. Because I don't see a difference in=20 > a 3m subnet using Bluetooth, and a 35,000km "subnet" using a=20 > satellite with IP routing on board. I think the charter needs=20 > to solve the problem for both of those, because I believe the=20 > distance of the link shouldn't be a factor.=20 > > > > Regards, > > Stan > > > > > > =20 > >> =20 > > _______________________________________________ > > Autoconf mailing list > > Autoconf@ietf.org > > https://www.ietf.org/mailman/listinfo/autoconf > > > > =20 >=20 > -- > Rex Buddenberg > Senior Lecturer > Naval Postgraduate School > Monterey, Ca 93943 > 831/656-3576 >=20 >=20 From alexandru.petrescu@gmail.com Fri Feb 27 12:55:02 2009 Return-Path: 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 BBF4D3A67D0 for ; Fri, 27 Feb 2009 12:55:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.165 X-Spam-Level: X-Spam-Status: No, score=-2.165 tagged_above=-999 required=5 tests=[AWL=0.084, 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 44180iOIismA for ; Fri, 27 Feb 2009 12:55:02 -0800 (PST) Received: from smtp3-g21.free.fr (smtp3-g21.free.fr [212.27.42.3]) by core3.amsl.com (Postfix) with ESMTP id DD5873A67AE for ; Fri, 27 Feb 2009 12:55:00 -0800 (PST) Received: from smtp3-g21.free.fr (localhost [127.0.0.1]) by smtp3-g21.free.fr (Postfix) with ESMTP id 001B881818E; Fri, 27 Feb 2009 21:55:18 +0100 (CET) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp3-g21.free.fr (Postfix) with ESMTP id 6562A8180BA; Fri, 27 Feb 2009 21:55:15 +0100 (CET) Message-ID: <49A8531A.3020404@gmail.com> Date: Fri, 27 Feb 2009 21:54:50 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Rex Buddenberg References: <499F0BA7.90501@piuha.net> <7E8A76F7-2CE0-463A-8EE8-8877C46B4715@gmail.com> <49A6D436.7020505@gmail.com> <000001c99845$1dc56190$595024b0$@nl> <49A6F125.40400@gmail.com> <1235680887.4585.5.camel@localhost><49A7BB89.5040807@gmail.com> <003901c998cb$42b71e90$c8255bb0$@nl><49A7E97A.2010503@gmail.com> <006801c998fd$06c5bd60$14513820$@nl> <49A8272D.2060400@gmail.com> <7FB7EE0A621BA44B8B69E5F0A09DC76407AD0C48@xmb-rtp-208.amer.cisco.com> <49A83172.70105@gmail.com> <7FB7EE0A621BA44B8B69E5F0A09DC76407AD0C70@xmb-rtp-208.amer.cisco.com> <49A84285.5030103@nps.navy.mil> In-Reply-To: <49A84285.5030103@nps.navy.mil> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 090227-0, 27/02/2009), Outbound message X-Antivirus-Status: Clean Cc: autoconf@ietf.org Subject: Re: [Autoconf] new charter X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 20:55:02 -0000 Rex Buddenberg a écrit : > Stan, > > The difference is not geo footprint (you got that right). Rather the > difference is between LAN (at fringe of network) and WAN (in the > interior). A WAN will always be at least one router away from end systems. > While we're at it, references to SSIDs is not proper -- that's > 802.11-specific. 802.11-specific because that's what many people actually mean. "Ad-hoc" type of SSID is there for same reason. Many MANET experiments happened with 802.11 links. Wireless LANs, WaveLAN, all are in scope and deserve mentioning. They're the building blocks out of which MANETs can come up. For LOS satcom communications: if I knew the precise names then I could find the manner in which they (or their admins) configure their IPv6 addresses. I'm specifically keeping out of MANET 802.15.4 (akin to WPAN) because there seems to be an IPv6 ND draft for this link which already has its own address autoconfiguration quirks. For WMAN: I'm aware of 802.16 and it has its own already IETF specified means of forming IPv6 addresses. In this landscape, I'm not sure how could Autoconf practical way of forming addresses not mention WiFi. Alex From sratliff@cisco.com Fri Feb 27 13:13:00 2009 Return-Path: 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 092093A68AB for ; Fri, 27 Feb 2009 13:13:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 WXU+yXEATtPj for ; Fri, 27 Feb 2009 13:12:59 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id AFC6F3A657C for ; Fri, 27 Feb 2009 13:12:41 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,278,1233532800"; d="scan'208";a="148553214" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 27 Feb 2009 21:13:04 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n1RLD4C3028941; Fri, 27 Feb 2009 13:13:04 -0800 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n1RLD3Jl006253; Fri, 27 Feb 2009 21:13:04 GMT Received: from xmb-rtp-208.amer.cisco.com ([64.102.31.43]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Feb 2009 16:13:03 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 27 Feb 2009 16:13:03 -0500 Message-ID: <7FB7EE0A621BA44B8B69E5F0A09DC76407AD0D5F@xmb-rtp-208.amer.cisco.com> In-Reply-To: <49A8531A.3020404@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Autoconf] new charter Thread-Index: AcmZHcMuiDangreJRsm1P7a4wBZSGAAAaDeg References: <499F0BA7.90501@piuha.net> <7E8A76F7-2CE0-463A-8EE8-8877C46B4715@gmail.com> <49A6D436.7020505@gmail.com> <000001c99845$1dc56190$595024b0$@nl> <49A6F125.40400@gmail.com> <1235680887.4585.5.camel@localhost><49A7BB89.5040807@gmail.com> <003901c998cb$42b71e90$c8255bb0$@nl><49A7E97A.2010503@gmail.com> <006801c998fd$06c5bd60$14513820$@nl> <49A8272D.2060400@gmail.com> <7FB7EE0A621BA44B8B69E5F0A09DC76407AD0C48@xmb-rtp-208.amer.cisco.com> <49A83172.70105@gmail.com> <7FB7EE0A621BA44B8B69E5F0A09DC76407AD0C70@xmb-rtp-208.amer.cisco.com> <49A84285.5030103@nps.navy.mil> <49A8531A.3020404@gmail.com> From: "Stan Ratliff (sratliff)" To: "Alexandru Petrescu" , "Rex Buddenberg" X-OriginalArrivalTime: 27 Feb 2009 21:13:03.0992 (UTC) FILETIME=[2D9B3780:01C99920] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1987; t=1235769184; x=1236633184; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sratliff@cisco.com; z=From:=20=22Stan=20Ratliff=20(sratliff)=22=20 |Subject:=20RE=3A=20[Autoconf]=20new=20charter |Sender:=20; bh=5Exwb4ctGLmtVrjOvVOpxWfEUQfo3MmqnAp/9/iWAv4=; b=JEj/3e+NSzOrh1PiJ16BqNTDgBzxqEa8+jWYrvl5SHNLz7Xi3NQ1SvcSRt +b419RB347UbofJX0r5BYcf7jCj6GLMXGQSvWdhskotn9jLE9ReXtoOihQJq ee+wAClbd+; Authentication-Results: sj-dkim-4; header.From=sratliff@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: autoconf@ietf.org Subject: Re: [Autoconf] new charter X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 21:13:00 -0000 =20 > -----Original Message----- > From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com]=20 > Sent: Friday, February 27, 2009 3:55 PM > To: Rex Buddenberg > Cc: Stan Ratliff (sratliff); Alexandru Petrescu; autoconf@ietf.org > Subject: Re: [Autoconf] new charter >=20 > Rex Buddenberg a =E9crit : > > Stan, > >=20 > > The difference is not geo footprint (you got that right). =20 > Rather the=20 > > difference is between LAN (at fringe of network) and WAN (in the=20 > > interior). A WAN will always be at least one router away=20 > from end systems. > > While we're at it, references to SSIDs is not proper -- that's=20 > > 802.11-specific. >=20 > 802.11-specific because that's what many people actually=20 > mean. "Ad-hoc"=20 > type of SSID is there for same reason. Many MANET=20 > experiments happened with 802.11 links. Wireless LANs,=20 > WaveLAN, all are in scope and deserve mentioning. They're=20 > the building blocks out of which MANETs can come up. >=20 > For LOS satcom communications: if I knew the precise names=20 > then I could find the manner in which they (or their admins)=20 > configure their IPv6 addresses. >=20 > I'm specifically keeping out of MANET 802.15.4 (akin to WPAN)=20 > because there seems to be an IPv6 ND draft for this link=20 > which already has its own address autoconfiguration quirks. >=20 > For WMAN: I'm aware of 802.16 and it has its own already IETF=20 > specified means of forming IPv6 addresses. >=20 > In this landscape, I'm not sure how could Autoconf practical=20 > way of forming addresses not mention WiFi. >=20 > Alex >=20 Alex,=20 None of the MANET networks I deploy are based on WiFi. I think that = turning the discussion into one that is 802.11-centric is not a good = idea -- it's analogous to our earlier discussion on distance of the = radio link. Why should the Layer 2 protocol in use effect the selection = of Layer 3 addresses?=20 Regards, Stan =20 From teco@inf-net.nl Fri Feb 27 13:15:33 2009 Return-Path: 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 A2F2828C0E5 for ; Fri, 27 Feb 2009 13:15:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.583 X-Spam-Level: X-Spam-Status: No, score=-0.583 tagged_above=-999 required=5 tests=[AWL=-0.937, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_44=0.6, J_CHICKENPOX_54=0.6, J_CHICKENPOX_55=0.6, J_CHICKENPOX_56=0.6] 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 NJ9WWrj6CPXC for ; Fri, 27 Feb 2009 13:15:32 -0800 (PST) Received: from hpsmtp-eml16.kpnxchange.com (hpsmtp-eml16.KPNXCHANGE.COM [213.75.38.116]) by core3.amsl.com (Postfix) with ESMTP id 95B8D3A6832 for ; Fri, 27 Feb 2009 13:15:31 -0800 (PST) Received: from cpsmtp-eml109.kpnxchange.com ([10.94.168.109]) by hpsmtp-eml16.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 27 Feb 2009 22:15:53 +0100 Received: from M90Teco ([86.83.9.22]) by cpsmtp-eml109.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 27 Feb 2009 22:15:53 +0100 From: "Teco Boot" To: "'Alexandru Petrescu'" References: <499F0BA7.90501@piuha.net> <7E8A76F7-2CE0-463A-8EE8-8877C46B4715@gmail.com> <49A6D436.7020505@gmail.com> <000001c99845$1dc56190$595024b0$@nl> <49A6F125.40400@gmail.com> <1235680887.4585.5.camel@localhost> <002f01c998bf$8f112210$ad336630$@nl> <49A7E58C.2020303@gmail.com> <007201c99903$c4182c80$4c488580$@nl> <49A82E55.10208@gmail.com> <007b01c99911$907facf0$b17f06d0$@nl> <49A8471E.6090506@gmail.com> In-Reply-To: <49A8471E.6090506@gmail.com> Date: Fri, 27 Feb 2009 22:15:52 +0100 Message-ID: <009501c99920$92154340$b63fc9c0$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcmZFo/wAf6La0ghTXWDTKfrSBgx/AAACemA Content-Language: nl x-cr-hashedpuzzle: AhU2 BCSR EVLw HLF1 HV+5 H0k4 LsxN MpjE NQ5d Pr7C P5AC P+yG R1vA S3kD S7/V T5Jq; 2; YQBsAGUAeABhAG4AZAByAHUALgBwAGUAdAByAGUAcwBjAHUAQABnAG0AYQBpAGwALgBjAG8AbQA7AGEAdQB0AG8AYwBvAG4AZgBAAGkAZQB0AGYALgBvAHIAZwA=; Sosha1_v1; 7; {FFA28AB4-D17D-4731-88D6-362800CF3D5C}; dABlAGMAbwBAAGkAbgBmAC0AbgBlAHQALgBuAGwA; Fri, 27 Feb 2009 21:15:47 GMT; UgBlADoAIABBAHUAdABvAGMAbwBuAGYAIABhAGQAZAByAGUAcwBzAGkAbgBnACAAbQBvAGQAZQBsAA== x-cr-puzzleid: {FFA28AB4-D17D-4731-88D6-362800CF3D5C} X-OriginalArrivalTime: 27 Feb 2009 21:15:53.0156 (UTC) FILETIME=[926F9840:01C99920] Cc: autoconf@ietf.org Subject: Re: [Autoconf] Autoconf addressing model X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 21:15:33 -0000 |-----Oorspronkelijk bericht----- |Van: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] |Verzonden: vrijdag 27 februari 2009 21:04 |Aan: Teco Boot |CC: autoconf@ietf.org |Onderwerp: [SPAM] Re: Autoconf addressing model |Urgentie: Laag | |Teco Boot a =E9crit : |> |Not all virtual interfaces are loopback. | |Again, do you think all virtual interfaces are 'loopback'? Not at all. And "loopback" on its own is meaningless. |> Router folks use "loopback" for what is meant here. Virtual |> interfaces have a much, much broader meaning. A tunnel interface or |> VLAN / FR / ATM subinterface is a virtual interface but definitely |> not what I intent to use. I prefer keep using the term loopback here. | |I strongly disagree using the term loopback interface, at least because |it can be easily interpreted as the interface on which there's a |'loopback address'. =20 Check for example ISP BCP, rfc5375 I agree on that there can be confusion on loopback address (node local) = and loopback interface. |And you don't seem to intend to use the loopback |address. No, I don't. |The loopback interface is the only interface on which there's a = loopback |address assigned. This is NOT a node requirement. RFC4291: 2.5.3. The Loopback Address The unicast address 0:0:0:0:0:0:0:1 is called the loopback address. It may be used by a node to send an IPv6 packet to itself. It must not be assigned to any physical interface. It is treated as having Link-Local scope, and may be thought of as the Link-Local unicast address of a virtual interface (typically called the "loopback interface") to an imaginary link that goes nowhere. Note the wording "may be". The other way around is definitely false: RFC3484 (default address selection): Implementations that wish to support the use of global source addresses assigned to a loopback interface should behave as if the loopback interface originates and forwards the packet. Assigning non-"loopback addresses" on the loopback interfaces is = permitted. |> |> RFC3871: It is a common practice among operators to configure |> |> "loopback" pseudo-interfaces to use as the source and destination of |> |> management traffic. | |Well that RFC is completely wrong please |> someone correct it. The |loopback address is ::1 and it can't be |> used to communicate outside the |computer. Yes pseudo-interface (and |> maybe 'virtual') but no loopback. |> |> I think you mix up "host loopback" and "router loopback". These are |> very, very different! | |I think there's no difference between host and router loopback. Yes.=20 On a host (strong end system model, RFC1122), traffic sent out the host = MUST have the source address of the outgoing interface. On a router, this is = not the case. Therefore assignment of addresses on loopback interfaces on routers is different than on (strong ES) hosts. |> |And yes the interface in the routing table for the entry address/128 |> is |'lo' which is yes the loopback interface but no, never will that |> address |be in the src nor dst fields of any packet leaving the |> computer (other |than encapsulated maybe). |> |> I checked this on the Linux host. I assigned another address on the |> lo interface. And the Linux host is reachable on this address, as |> long as other nodes has a path to this /128 prefix. | |WEll yes, it is possible to manually assign any 128bit address routable |or non-routable, on the loopback interface, as it is possible to assign |any address on any interface be it virtual or physical. | |> Sorry, you are wrong. |> |> Detailed info: |> |> debian-fs1:/proc/sys/net/ipv6/neigh/eth0# ifconfig lo lo Link |> encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: |> 2001:db8:1::3333/128 Scope:Global inet6 addr: ::1/128 Scope:Host UP |> LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:185 errors:0 |> dropped:0 overruns:0 frame:0 TX packets:185 errors:0 dropped:0 |> overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:13568 (13.2 |> KiB) TX bytes:13568 (13.2 KiB) |> |> Tested from IOS router: nbs3725#ping 2001:db8:1::3333 Type escape |> sequence to abort. Sending 5, 100-byte ICMP Echos to |> 2001:DB8:1::3333, timeout is 2 seconds: !!!!! Success rate is 100 |> percent (5/5), round-trip min/avg/max =3D 0/0/4 ms | |Well yes, that's ok, I don't see anything wrong with nbs3725 pinging |debian-fs1's loopback interface's routable address. | |But the loopback interface is not used for its intended loopback |meaning. That loopback interface doesn't use the loopback address - |it's a virtual interface on which the loopback address is assigned. Yes, the "lo" interface is used for loopback address and for other = purposes. |> Debug info, showing that you are wrong, the IP address in interface |> lo is reachable: | |Well yes, because having a non-loopback IPv6 address on the loopback |interface. | |> No, absolutely not. I provided the evidence that the loopback is |> perfectly usable already. | |Why the loopback interface and not another virtual interface? Why |mixing loopback semantics with a routable address semantics? | |> |I thought the unplanned aspect could be treated by IPv6 stateless |> |autoconf and IPv6-over-Ethernet link-local addresses. |> |> Yes and no. I like SLAAC, but with SLAAC, thewre is an address per |> interface. In this model, the node is reachable via the loopback |> address via whatever interface. | |I think this creates more headaches than it solves. | |In a first step, do we agree that the node has typically more than one |interface? We didn't seem to. If not, then why should we need to have |the node reachable via whatever interface, since there's only one. If there is only one (external) interface, there is no redundancy and = the advantages do not apply. |If there are at least two interfaces, then why can't we use a different |address on each of the interfaces? What's wrong with that? The fact |that the node moves? Well, you seemed to accept host-based /128 routes |- in this case instead of 1 there'll be 2 host-based /128 routes. |What's wrong with that again? At least 2 advantages: o 1 address: lower overhead o no address swap needed when session swaps from one interface to the = other (and if interfaces go down!). |> |> o Connectivity is not broken if a path swap occurs (the RFC3781 |> |> loopback BCP) o It provides some scalability, as only a single |> |> address is needed, even if multiple interfaces are used. o |> |> Applications are not confused by "host prefixes" to a link, where |> |> other nodes are reachable. I tested this with linux and IPv4 with |> |> /32. | |Before deciding on the solution (address assigned to a |> virtual |interface) I need to udnerstand how path swap occurs and |> why. |> |> Because movement. A MANET Router may have multiple interfaces, some |> of them could be MANET, others wireless infrastructure mode and |> others MANET. | |Sorry, I can't go along these lines. Movement described just like = that, |without any boundary, no pattern, just movement... | |I think I will simply summarize the topologies we discussed and leave = it |there. | |I also agree it's difficult to describe movement on paper (maybe easier |on ppt) but we could at least try. | |[...] |> |Sounds interesting. But I think normal DHCP could run ok, provided |> the |Relays know the address of the Server. In a first practical |> step would |be to manually configure the Server's address on each |> Relays. |> |> When many DHCP Relay Agenst are nearby, who to select? If multicast |> is used, all of them will relay and this ends in a DHCP Relay storm |> (collisions, loss, retry .....) | |That issue is simple. Before the node can even have the choice to talk |to a Relay, it will have to connect to the wifi "adhoc". The moment it |connected to it it will only have one choice: the Relay present on that |"adhoc" essid. Your assumption is single hop communication and no MANET routing = protocol. I am interested in the more complex topologies. There is no "essid" in ad hoc mode. It is the "ssid" of the IBSS. Only = ESS has essid. Let's try to be accurate. |> |> However, there is a chicken - egg problem. In a wired network, the |> |> DHCP client - DHCP relay agent relation is stable. This is |> certainly |> not the case in a MANET. | |Well it is the case in a |> MANET made of 25meter IPv6 subnets. |> |> Voice over IP over WLAN for 25meter? Just shout!! | |:-) :-) I agree. | |But the IP in VoIP over a 25m IPv6 subnet allows me to talk to another |IP much further who wouldn't hear my shout otherwise. Yes. a MANET topology could be a short-range / high data rate radio link = to another MANET Router, with low data rate / long range to a remote peer, = and another hop via short-range / high data radio link. In a mobile ad hoc environment, nodes are free to move and the network should provide the = best connectivity to the users that is technical feasible.=20 Not only the nodes may move, obstacles may also move (teapot, truck). |> My requirements are over 25meter. 25km is no joke. Wifi is not usable |> here. | |Well then. I think the mechanisms are completely different. A 25km |radio link would use an addressing mechanism completely different. Not sure on this.=20 The to-be-defined [Autoconf] MANET addressing mechanism MUST support the basics also! |> |> Therefore, I think a DHCP client should start with building |> reliable |> communication to a DHCP server, and the MANET routing |> protocols can |> provide such. But the MANET routing protocol needs a |> prefix that |> corresponds to this MANET node. For this reason, I |> think it makes |> sense to start with generating a prefix without |> DHCP, and we could |> use a prefix "push model" here. | |Well I think |> this is indeed a very chickeneggy problem: are addresses in |place |> before routing is, or vice-versa. But what would we do in |practice? |> Certainly we'd manually assign some addresses - let's see |these |> cases first. |> |> No. MANETs are often used in workgroups, whit lack of knowledge of |> configuring something. The network must be plug&play / zero-config. |> |> |> |> |>> Above, and in the following figures, I don't understand "--->, |> |>> Prefix Information". Is that RA? Or OSPF? Or routing protocol? |> |>> Or DHCP Prefix Delegation? |> |> This is under discussion, and |> the reason we have an [Autoconf] WG. |> There are proposals that rely |> on a routing protocol, but the old |> charter mentioned being |> independent of a routing protocol. | |I think we should consider |> first the practical cases. |> |> No. I think we have a clear picture of why MANETs are being used. We |> need an [Autoconf] solution. Let's take the next steps defining an |> addressing model, write down the requirements and then look for |> solutions. | |Sorry, it seems the Autoconf solution will come to live only if the |first practical addressing solution can get agreement on. The we may come up with some guidelines using current technologies. We already know this is broken if we want to support the more complex topologies. What about this scenario: here, the obstacle is moving: (802.11 term: STA is station) +------------------------+ +------------------------+ | | | | | ____STA-B | | ____STA-B | | ___/ | | | ___/ | | STA-A | | | STA-A OBSTACLE | | '--_ | | | '--_ | | '----STA-C | | '----STA-C | | OBSTACLE | | | +------------------------+ +------------------------+ 1-1: No hindrance 1-2: B-C blocked +------------------------+ +------------------------+ | | | O | | ____STA-B | | B STA-B | | ___/ | | | S | | | STA-A OB | | | STA-A T | | | ST | | | A | | | AC STA-C | | C STA-C | | LE | | LE | +------------------------+ +------------------------+ 1-3: A-C blocked 1-4: A-B & A-C blocked MANET Scenarios with blocking obstacle Compare with this one: (802.11 term: AP is access point) +------------------------+ +------------------------+ | | | | | ____STA-B | | ____STA-B | | ___/ | | ___/ | | AP-A | | AP-A OBSTACLE | | '--_ | | '--_ | | '----STA-C | | '----STA-C | | OBSTACLE | | | +------------------------+ +------------------------+ 4-1: No hindrance 4-2: No hindrance +------------------------+ +------------------------+ | | | O | | ____STA-B | | B STA-B | | ___/ | | S | | AP-A OB | | AP-A T | | ST | | A | | AC STA-C | | C STA-C | | LE | | LE | +------------------------+ +------------------------+ 4-3: A-C & B-C blocked 4-4: All blocked 802.11 BSS L2 topology with blocking obstacle In these scenario's, the MANET model provides better connectivity. I = won't say more bandwidth, lower loss or other link quality metrics, but for = high availability the MANET model definitely wins.=20 Teco. |Alex From cjbc@it.uc3m.es Sat Feb 28 05:24:07 2009 Return-Path: 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 528C73A67CC for ; Sat, 28 Feb 2009 05:24:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.699 X-Spam-Level: X-Spam-Status: No, score=-5.699 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] 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 sF537QxGjMSw for ; Sat, 28 Feb 2009 05:24:06 -0800 (PST) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id DEDA93A6768 for ; Sat, 28 Feb 2009 05:24:05 -0800 (PST) Received: from [192.168.1.209] (213.37.82.74.static.user.ono.com [213.37.82.74]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp01.uc3m.es (Postfix) with ESMTP id 6CBA9B4D480; Sat, 28 Feb 2009 14:24:27 +0100 (CET) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Alexandru Petrescu In-Reply-To: <49A7BB89.5040807@gmail.com> References: <499F0BA7.90501@piuha.net> <7E8A76F7-2CE0-463A-8EE8-8877C46B4715@gmail.com> <49A6D436.7020505@gmail.com> <000001c99845$1dc56190$595024b0$@nl> <49A6F125.40400@gmail.com> <1235680887.4585.5.camel@localhost> <49A7BB89.5040807@gmail.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-FQrbQ/tth9QACsHddSin" Organization: Universidad Carlos III de Madrid Date: Sat, 28 Feb 2009 14:24:26 +0100 Message-Id: <1235827466.6096.13.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16490.007 Cc: autoconf@ietf.org Subject: Re: [Autoconf] new charter X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Feb 2009 13:24:07 -0000 --=-FQrbQ/tth9QACsHddSin Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Hi Alex, Sorry for the late reply, trying to catch up now... El vie, 27-02-2009 a las 11:08 +0100, Alexandru Petrescu escribi=F3: > Carlos Jes=FAs Bernardos Cano a =E9crit : > > Hi Alex: > >=20 > > One question below. > >=20 > > El jue, 26-02-2009 a las 20:44 +0100, Alexandru Petrescu escribi=F3: > >> Sorry, I made an error indeed putting same prefix. How about this > >> updated picture with the prefixes being distinct: > >>=20 > >>=20 > >> ----- wifi "adhoc1" ------ wifi "adhoc2" -----=20 > >> |Host1|---------------|Router|---------------|Host2| ----- LL1 > >> LL2 ------ LL3 LL4 ----- G1 > >> G4 > >>=20 > >>=20 > >> "adhoc1" and "adhoc2": 802.11 ESSIDs in "ad-hoc" mode. Each is an > >> IPv6 subnet. LL1...4: IPv6 link-local addresses. Self-formed > >> according to rfc2464. G1, G4: IPv6 global addresses, for example=20 > >> 2001:db8:1::1/64 and 2001:db8:2::4/64 Manually assigned, or > >> pre-configured with SNMP or formed according to stateless autoconf > >> rfc4862; the prefixes are advertised by Router in RAs. > >>=20 > >=20 > > Does this model only apply to Host-Router-Host scenarios? >=20 > Yes. >=20 > > I mean, does this model apply for Router-Router-Router scenarios? >=20 > Something like this?: >=20 > ------- wifi "adhoc1" ------- wifi "adhoc2" ------- > |Router1|---------------|Router2|---------------|Router3| > ------ LL1 LL2 -------LL3 LL4 ------- > G1 G4 >=20 > G1, G4: ? >=20 > > I fully agree the model fits the first scenario, but I don't for the > > second, since routers' mobility within the ad-hoc network would > > force them to change prefixes often, I guess. >=20 > Ah. But before being forced to change a prefix, a Router could still > move around as much as it wants. I think the limit is within 25m range, > as imposed by the wifi 50m area (25m for two routers in opposite > directions). What do you think about this practical limit? Well, this is tipically the range for 802.11bg (.11a can even less, .11p is more). It's a matter of the scenario we consider to asusume that this range is enough for a router (i.e. it will not move further). Anyway, due to the characteristics of the wireless and unmanaged nature of MANETs, it might be the case that even without movement routers need to change addresses (think of your pictur above in which Router2 is turned off). >=20 > > For those scenarios it might be better to think of addressing models > > in which MANET routers are configured with /128 (or /32 for IPv4) > > addresses, so they don't need to change their addresses as a result > > of link changes. >=20 > Sorry... in the picture above the addresses are also /128. It was an=20 > abbreviation for me to show only 2001:db8:1::1/64 assigned to Host1.=20 > The full notation should have been 2001:db8:1::/64 prefix and=20 > 2001:db8:1::1/128. Would the following picture satisfy the need for=20 > /128 addresses?: >=20 > ----- wifi "adhoc1" ------ wifi "adhoc2" ----- > |Host1|---------------|Router|---------------|Host2| > ----- LL1 P1 LL2 ------ LL3 P2 LL4 ----- > G1 G4 >=20 > G1, G4: IPv6 global addresses, for example > 2001:db8:1::1/128 and > 2001:db8:2::4/128 > Manually assigned, or pre-configured with SNMP > or formed according to stateless autoconf rfc4862; > the prefixes are advertised by Router in RAs. > P1, P2: IPv6 global prefixes, for example > 2001:db8:1::/64 and > 2001:db8:2::/64 > Manually assigned, or pre-configured with SNMP. >=20 >=20 > Or is it not what you mean? Yes, more ore less, but I think I agree with Teco in which I'd assign those /128 addresses to loopback (not physical) interfaces. >=20 > I also don't understand why you think that if /128 addresses are=20 > assigned to routers then they don't need to change them as a result of=20 > link changes. This is because in my understanding a /128 address cannot be formed according ti rfc4862 (only /64 can). If the router gets a /128 address by any other means, the MANET routing protocol would take care of ensuring this address isreachable despite the movement of the router.=20 Carlos >=20 > Alex >=20 >=20 --=20 Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ WEEDEV 2009: 2nd Workshop on Experimental Evaluation and Deployment Experiences on Vehicular networks http://www.weedev.org/ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ --=-FQrbQ/tth9QACsHddSin Content-Type: application/pgp-signature; name=signature.asc Content-Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEABECAAYFAkmpOwoACgkQNdy6TdFwT2cO3ACff3SUw/s4v4TPCG/W7O5Ue1Is aHMAnRLB+B6rD7yyUuu/3kWQu1VUCdv6 =oLY9 -----END PGP SIGNATURE----- --=-FQrbQ/tth9QACsHddSin-- From cjbc@it.uc3m.es Sat Feb 28 05:43:20 2009 Return-Path: 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 9C7813A6A0C for ; Sat, 28 Feb 2009 05:43:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.699 X-Spam-Level: X-Spam-Status: No, score=-5.699 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] 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 u4OG22b1iTsH for ; Sat, 28 Feb 2009 05:43:19 -0800 (PST) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id BF2EA3A68C0 for ; Sat, 28 Feb 2009 05:43:18 -0800 (PST) Received: from [192.168.1.209] (213.37.82.74.static.user.ono.com [213.37.82.74]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp01.uc3m.es (Postfix) with ESMTP id 43E37B4D459; Sat, 28 Feb 2009 14:43:40 +0100 (CET) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Teco Boot In-Reply-To: <002f01c998bf$8f112210$ad336630$@nl> References: <499F0BA7.90501@piuha.net> <7E8A76F7-2CE0-463A-8EE8-8877C46B4715@gmail.com> <49A6D436.7020505@gmail.com> <000001c99845$1dc56190$595024b0$@nl> <49A6F125.40400@gmail.com> <1235680887.4585.5.camel@localhost> <002f01c998bf$8f112210$ad336630$@nl> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-XFpBWjpEdx1XhkqiCOmc" Organization: Universidad Carlos III de Madrid Date: Sat, 28 Feb 2009 14:43:39 +0100 Message-Id: <1235828619.6096.24.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16490.007 Cc: autoconf@ietf.org Subject: Re: [Autoconf] Autoconf addressing model X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Feb 2009 13:43:20 -0000 --=-XFpBWjpEdx1XhkqiCOmc Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Hi Teco, El vie, 27-02-2009 a las 10:41 +0100, Teco Boot escribi=F3: > All, >=20 > Here my opinion on the to be defined addressing model for MANETs / Autoco= nf. > I opened a separate thread, as I think (and hope) there will be an intens= ive > and productive discussion. >=20 > Some of us like an address model with /32 (IPv4) or /128 (IPv6) > prefix-length addresses attached to an interface to a multi-access link. > These addresses do not have an Interface-ID.=20 >=20 > Such a model excludes usage of /64 "prefix swapping", which is IMHO an > extremely important attribute of IPv6. And it is specified as mandatory i= n > some standard track RFCs (e.g. RFC2464).=20 >=20 > We could discuss and analyze the effect of adopting the /128 (or /32) pre= fix > lengths for MANET interfaces, but I prefer taking this option as last > resort. I think there is a much more obvious option, using the RFC2464 mo= del > for the MANET interface and /128 (or /32) for loopback interfaces. Both > would use high probability globally unique Interface IDs like EUI-64 > (Extended Unique Identifier). Agree, this is also my understanding. >=20 > RFC4291 2.1. Addressing Model: > All interfaces are required to have at least one Link-Local unicast > address (see Section 2.8 for additional required addresses). A > single interface may also have multiple IPv6 addresses of any type > (unicast, anycast, and multicast) or scope. Unicast addresses with a > scope greater than link-scope are not needed for interfaces that are > not used as the origin or destination of any IPv6 packets to or from > non-neighbors. This is sometimes convenient for point-to-point > interfaces. >=20 > RFC2464 4. Stateless Autoconfiguration: > An IPv6 address prefix used for stateless autoconfiguration [ACONF] > of an Ethernet interface must have a length of 64 bits. >=20 > It is not only because the RFC texts that I dislike the /128 in MANET > interfaces, it is also backward compatibility with current IP stacks (and > probably many applications). I think an interface with /128 is stub, and > thus protocols may assume that there is no other node on this link in the > same subnet. Think of ARP and routing protocols. I verified this with som= e > product, the outcome confirmed my assumption. I was able to adjust the > configuration on one platform so that it worked (Linux), but still the > indication is that the model has a high impact. >=20 > I think using /128 for loopback interfaces fits the requirements for the > addressing model. If a loopback interface is used, MANET interfaces do no= t > require a globally unique address. RFC4291 once more (out of section, als= o > cited above): > Unicast addresses with a > scope greater than link-scope are not needed for interfaces that are > not used as the origin or destination of any IPv6 packets to or from > non-neighbors. > So "host functionality" can be provided using the globally (or MANET loca= l) > unique address assigned to a loopback address, or another non-MANET > interface. >=20 > This results in the following addressing model, where all nodes are route= rs: >=20 > +-------+ wifi "adhoc1" +-------+ wifi "adhoc2" +-------+ > |Router1|>-------------<|Router2|>-------------<|Router3| > +---L---+ LL1 LL21 +---L---+ LL22 LL3 +---L---+ > |M1 |M2 |M3 >=20 > "adhoc1" and "adhoc2": 802.11 SSIDs in "IBSS" mode. > Each IBSS is an IPv6 subnet. >=20 > L: Loopback interface. >=20 > >, <: MANET interface. >=20 > LL1, LL21, LL22, LL3: IPv6 link-local addresses. > Self-formed according to rfc2464. >=20 > M1, M2, M3: IPv6 MANET local addresses, for example > FD01:db8::1/128, FD01:db8::2/128 and FD01:db8::3/128. > Manually assigned, or pre-configured (e.g. with SNMP) > or formed according to a to be defined [Autoconf for MANETs] > protocol, with a to-be-defined prefix (e.g. ULA, RFC4193). >=20 > Although all nodes are marked as router, this does not imply all nodes > forward packets. All nodes run a MANET routing protocol for learning the > MANET topology. >=20 I think I'm also agree here. >=20 > In case one of the routers is connected to the Internet or private networ= k, > this router can advertize a prefix in the MANET, and this information is > distributed in the MANET with an [Autoconf for MANETs] protocol. >=20 >=20 > Internet > | > | > +-------+-------+ > | Access Router | > +-------+-------+ > | > | | Prefix information > | V > | > +-------+ wifi "adhoc1" +---+---+ wifi "adhoc2" +-------+ > |Router1|>-------------<|Router2|>-------------<|Router3| > +---L---+ LL1 LL21 +---L---+ LL22 LL3 +---L---+ > |M1 |M2 |M3 > |G1 |G2 |G3 > <------- -------> > Prefix information Prefix information=20 >=20 >=20 > G1, G2, G3: IPv6 globally unique addresses, for example > 2001:db8:G:1/128, 2001:db8:G:2/128 and 2001:db8:G:3/128. > Formed according to a to be defined [Autoconf for MANETs] > protocol, with the prefix provided by (via) the Access Router. >=20 >=20 > Multi-homing can easily be supported: >=20 > ---+-------Internet--------+--- > | | > | | > +-------+-------+ +-------+-------+ > |Access Router H| |Access Router G| > +-------+-------+ +-------+-------+ > | | > ||Prefix information H | |Prefix information G > |V | V > | | > +---+---+ wifi "adhoc1" +---+---+ wifi "adhoc2" +-------+ > |Router1|>-------------<|Router2|>-------------<|Router3| > +---L---+ LL1 LL21 +---L---+ LL22 LL3 +---L---+ > |M1 |M2 |M3 > |G1 |G2 |G3 > |H1 |H2 |H3 > <------- -------> > Prefix information G Prefix information G, H > ---------> > Prefix information H >=20 > H1, H2, H3: IPv6 globally unique addresses, for example > 2001:db8:H:1/128, 2001:db8:H:2/128 and 2001:db8:H:3/128. > Formed according to a to be defined [Autoconf for MANETs] > protocol, with the prefix provided by (via) Access Router H. >=20 >=20 > Note that the impact of the number of interfaces is minimal, the address > configuration of Router2 is very similar to Router1 and Router3. Also, th= e > status of the MANET interface has no impact on communication in case of > multi-homing and redundant paths. (OK, we might need MIP6 / HIP / SHIM6 o= r > application layer address swapping mechanisms). >=20 > It doesn't matter how many ad hoc segments there are. In the following > scenario, the link to Access router G disappeared, Router 3 disappeared a= nd > a Router4 joined IBSS "adhoc1". >=20 >=20 >=20 > ---+-------Internet------ > | =20 > | =20 > +-------+-------+ =20 > |Access Router H| =20 > +-------+-------+ =20 > | =20 > ||Prefix information H =20 > |V wifi "adhoc1" > | <---------------------------v-------->=20 > <------|--v----------------------> |=20 > |<-|--------------------v-----------------------|---> > | | | | > +---+--'+ +---'---+ +---'---+ > |Router1|>-------------<|Router2|>-------------<|Router4| > +---L---+ LL1 LL21 +---L---+ LL22 LL4 +---L---+ > |M1 |M2 |M4 > |H1 |H2 |H4 >=20 > ---------> ---------> > Prefix information H Prefix information H >=20 >=20 > Now, Router2 acts as a relay for Router4, so Router4 can reach Router1 an= d > the Internet. Router1 acts as Border Router for all nodes in the MANET. >=20 While I think this is also much in linee with my thinking, I think it's better to focus on the simplest cases before. Thanks, Carlos >=20 > I have some thoughts on IPv4 supports. Of course IPv4 misses lots of > flexibility that is used in above model. But there are ways to support it= , > e.g. IPv4 link local (RFC3927) accompanied by some extended form of > duplicate address detection (passive checking routing tables). For global= ly > unique address assignment I think of DHCP-IPv4 over an IPv6 path, provide= d > as described above. (e.g. Router4 gets its /32 address for its loopback > interface from/via Access Router H, using M4 or H4 address and the IPv6 > MANET protocol. >=20 >=20 > Any comments? > Teco. >=20 >=20 >=20 > |-----Oorspronkelijk bericht----- > |Van: Carlos Jes=FAs Bernardos Cano [mailto:cjbc@it.uc3m.es] > |Verzonden: donderdag 26 februari 2009 21:41 > |Aan: Alexandru Petrescu > |CC: Teco Boot; autoconf@ietf.org > |Onderwerp: Re: [Autoconf] new charter > | > |Hi Alex: > | > | One question below. > | > |El jue, 26-02-2009 a las 20:44 +0100, Alexandru Petrescu escribi=F3: > |> Sorry, I made an error indeed putting same prefix. How about this > |> updated picture with the prefixes being distinct: > |> > |> > |> ----- wifi "adhoc1" ------ wifi "adhoc2" ----- > |> |Host1|---------------|Router|---------------|Host2| > |> ----- LL1 LL2 ------ LL3 LL4 ----- > |> G1 G4 > |> > |> > |> "adhoc1" and "adhoc2": 802.11 ESSIDs in "ad-hoc" mode. > |> Each is an IPv6 subnet. > |> LL1...4: IPv6 link-local addresses. > |> Self-formed according to rfc2464. > |> G1, G4: IPv6 global addresses, for example > |> 2001:db8:1::1/64 and > |> 2001:db8:2::4/64 > |> Manually assigned, or pre-configured with SNMP > |> or formed according to stateless autoconf rfc4862; > |> the prefixes are advertised by Router in RAs. > |> > | > |Does this model only apply to Host-Router-Host scenarios? I mean, does > |this model apply for Router-Router-Router scenarios? I fully agree the > |model fits the first scenario, but I don't for the second, since > |routers' mobility within the ad-hoc network would force them to change > |prefixes often, I guess. For those scenarios it might be better to think > |of addressing models in which MANET routers are configured with /128 > |(or /32 for IPv4) addresses, so they don't need to change their > |addresses as a result of link changes. > | > |Kind Regards, > | > |Carlos > | > |-- > | Carlos Jes=FAs Bernardos Cano http://www.netcoms.net > | GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 > |++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > | WEEDEV 2009: 2nd Workshop on Experimental Evaluation and > | Deployment Experiences on Vehicular networks > | http://www.weedev.org/ > |++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >=20 --=20 Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ WEEDEV 2009: 2nd Workshop on Experimental Evaluation and Deployment Experiences on Vehicular networks http://www.weedev.org/ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ --=-XFpBWjpEdx1XhkqiCOmc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEABECAAYFAkmpP4sACgkQNdy6TdFwT2fCrgCg5SvvP27GxnnTRm9tbmpHeimv l0MAn2AJP4Vn3h36eLHPnW9n9UJFIF30 =1Qn6 -----END PGP SIGNATURE----- --=-XFpBWjpEdx1XhkqiCOmc-- From cjbc@it.uc3m.es Sat Feb 28 05:43:26 2009 Return-Path: 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 E9EA428C104 for ; Sat, 28 Feb 2009 05:43:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.101 X-Spam-Level: X-Spam-Status: No, score=-4.101 tagged_above=-999 required=5 tests=[AWL=-1.598, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, J_CHICKENPOX_54=0.6, J_CHICKENPOX_55=0.6, J_CHICKENPOX_56=0.6, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] 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 23bwgB9OEXK7 for ; Sat, 28 Feb 2009 05:43:26 -0800 (PST) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id AFCED3A69E0 for ; Sat, 28 Feb 2009 05:43:25 -0800 (PST) Received: from [192.168.1.209] (213.37.82.74.static.user.ono.com [213.37.82.74]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp01.uc3m.es (Postfix) with ESMTP id 843FCB4D48F; Sat, 28 Feb 2009 14:43:47 +0100 (CET) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Teco Boot In-Reply-To: <006801c998fd$06c5bd60$14513820$@nl> References: <499F0BA7.90501@piuha.net> <7E8A76F7-2CE0-463A-8EE8-8877C46B4715@gmail.com> <49A6D436.7020505@gmail.com> <000001c99845$1dc56190$595024b0$@nl> <49A6F125.40400@gmail.com> <1235680887.4585.5.camel@localhost> <49A7BB89.5040807@gmail.com> <003901c998cb$42b71e90$c8255bb0$@nl> <49A7E97A.2010503@gmail.com> <006801c998fd$06c5bd60$14513820$@nl> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-zKizSSc/tvdYOWw3T8XP" Organization: Universidad Carlos III de Madrid Date: Sat, 28 Feb 2009 14:43:42 +0100 Message-Id: <1235828622.6096.25.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16490.007 Cc: autoconf@ietf.org Subject: Re: [Autoconf] new charter X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Feb 2009 13:43:27 -0000 --=-zKizSSc/tvdYOWw3T8XP Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Hi Teco, El vie, 27-02-2009 a las 18:01 +0100, Teco Boot escribi=F3: > Inline. >=20 > |-----Oorspronkelijk bericht----- > |Van: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] > |Verzonden: vrijdag 27 februari 2009 14:24 > |Aan: Teco Boot > |CC: 'Alexandru Petrescu'; autoconf@ietf.org > |Onderwerp: Re: [Autoconf] new charter > | > |Teco Boot a =E9crit : > |> Hi Alex, > |> > |> Let's try to be accurate: > |> > |> [skip] > |> |Sorry... in the picture above the addresses are also /128. It was an > |> |abbreviation for me to show only 2001:db8:1::1/64 assigned to Host1. > |> |The full notation should have been 2001:db8:1::/64 prefix and > |> |2001:db8:1::1/128. Would the following picture satisfy the need for > |> |/128 addresses?: > |> > |> When prefix::/64 is assigned to a host, it configures a /64 address > |and not > |> an /128 address. > | > |I'm not sure I understand. > | > |The prefix::/64 is typically assigned to a link, not to a host. If a > |host is connected to that link then it configures a /128 address and a > |/64 subnet prefix, both "128" and "64" numbers are visible in its > |tables. > | > |I don't understand why the need for /128 prefixes, why isn't the above > |/64-prefix-and-/128address not sufficient? >=20 > This is interesting. I meant generating an address in the /64 prefix. > I don't know what is specified in RFCs. I checked behavior on Vista,=20 > Linux and IOS:=20 > o Linux (debian lenny) adds a /128 prefix in the routing table, to=20 > the loopback interface, similar to what I propose in my addressing=20 > model mail. It also adds a /64 address-prefix to the Ethernet interfa= ce > this is a bit weird, as two interfaces has the same address configure= d. You mean the /64 for the link local addresses? this is not weird, they have scope of a link, so there can perfectly be the same address on different interfaces. >=20 > o Vista assigns addresses to the Ethernet interface (in my case), > and adds /128 prefixes in the routing table. Vista also adds the=20 > /64 in the routing table. > o IOS behavior is as Vista, addresses to interfaces and /128 in=20 > routing table. >=20 > Details on Linux behavior: the /64 are on Ethernet (eth0) and the /128=20 > are on loopback (lo). >=20 > # ifconfig lo | egrep 'inet6|encap' > lo Link encap:Local Loopback =20 > inet6 addr: ::1/128 Scope:Host > # netstat -6rn | grep 128 > ::1/128 :: Un 0 1 17 lo > 2001:db8:1:0:20c:29ff:fee3:bdf5/128 :: Un 0 1 11 lo > fe80::20c:29ff:fee3:bdf5/128 :: Un 0 1 3 lo > fe80::20c:29ff:fee3:bdff/128 :: Un 0 1 0 lo >=20 > # ifconfig eth0 | egrep 'inet6|encap' > eth0 Link encap:Ethernet HWaddr 00:0c:29:e3:bd:f5 =20 > inet6 addr: 2001:db8:1:0:20c:29ff:fee3:bdf5/64 Scope:Global > inet6 addr: fe80::20c:29ff:fee3:bdf5/64 Scope:Link > # netstat -6rn | grep 64=20 > 2001:db8:1::/64 :: UAe 256 0 15 eth0 > fe80::/64 :: U 256 0 0 eth0 > fe80::/64 :: U 256 0 0 eth1 >=20 Just a suggestion (OT to this mailing list): it's better to use the 'ip' (iproute) command (ifconfig, route and netstat are deprecated, as far as I know since 2.4 kernels). Besides, 'ipi command is far easier to use: 'ip -6 addr', 'ip -6 ro' Thanks, Carlos >=20 > Conclusion: I was wrong with my statement. Linux behaves as I mentioned,=20 > other IPv6 stacks have different characteristics. >=20 >=20 >=20 >=20 >=20 > |> Routers may generate a /128 prefix-address, and advertize this in the > |> routing domain. > | > |A host-based route propagated and deleted throughout a domain? I don't > |see the necessity of doing so. Assuming the routers are mobile within > |25m ranges then they wouldn't need to change their addresses, thus no > |need to propagate host-based routes. >=20 > If the /128 is not propagated, there will be no multi-hop network. In a > MANET, I expect nodes to run a MANET Routing protocol and forward packets= . > In ad hoc networks, one (you ?) would say nodes could be hosts or Mobile > Routers acting as hosts.=20 >=20 >=20 > |Do you agree we consider routers mobile only within 25m ranges? >=20 > Absolutely not. For me, 25km is a reasonable distance! Just 10^3 times th= e > distance and 10^6 times the power per bit (single hop) or 10^3 times the > power per bit if multi-hop is enabled (and 1000 intermediate nodes....). > Just physical laws here. >=20 >=20 > Teco. >=20 >=20 > |Alex > | > |> Some mechanisms should make sure the /128 routing prefix is unique, if > |> required. It is not required if the prefix is meant as anycast > |address, > |> routers may use "duplicate prefixes" if this is useful. I think > |anycast is > |> out-of-scope for [Autoconf], but we should be careful when specifying > |"MUST" > |> for prefix uniqueness. We should use "SHOULD" instead. > |> > |> Teco. > |> > |> > |> > |> >=20 >=20 > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf --=20 Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ WEEDEV 2009: 2nd Workshop on Experimental Evaluation and Deployment Experiences on Vehicular networks http://www.weedev.org/ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ --=-zKizSSc/tvdYOWw3T8XP Content-Type: application/pgp-signature; name=signature.asc Content-Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEABECAAYFAkmpP40ACgkQNdy6TdFwT2f2LACfabjwhr7j1FnKr1GD8NLVa4jq K7sAnii9dGXJvnp/RXK6Yel+5uUeJlDq =N3fE -----END PGP SIGNATURE----- --=-zKizSSc/tvdYOWw3T8XP-- From cjbc@it.uc3m.es Sat Feb 28 05:43:29 2009 Return-Path: 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 688613A6A18 for ; Sat, 28 Feb 2009 05:43:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.966 X-Spam-Level: X-Spam-Status: No, score=-3.966 tagged_above=-999 required=5 tests=[AWL=-0.667, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, J_CHICKENPOX_44=0.6, J_CHICKENPOX_54=0.6, J_CHICKENPOX_55=0.6, J_CHICKENPOX_56=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] 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 dG-A9FNdGMra for ; Sat, 28 Feb 2009 05:43:27 -0800 (PST) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 632413A69E0 for ; Sat, 28 Feb 2009 05:43:27 -0800 (PST) Received: from [192.168.1.209] (213.37.82.74.static.user.ono.com [213.37.82.74]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp02.uc3m.es (Postfix) with ESMTP id 942ED65A1F3; Sat, 28 Feb 2009 14:43:48 +0100 (CET) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Teco Boot In-Reply-To: <007b01c99911$907facf0$b17f06d0$@nl> References: <499F0BA7.90501@piuha.net> <7E8A76F7-2CE0-463A-8EE8-8877C46B4715@gmail.com> <49A6D436.7020505@gmail.com> <000001c99845$1dc56190$595024b0$@nl> <49A6F125.40400@gmail.com> <1235680887.4585.5.camel@localhost> <002f01c998bf$8f112210$ad336630$@nl> <49A7E58C.2020303@gmail.com> <007201c99903$c4182c80$4c488580$@nl> <49A82E55.10208@gmail.com> <007b01c99911$907facf0$b17f06d0$@nl> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-zdLy5X1gE8l+qVyIL3so" Organization: Universidad Carlos III de Madrid Date: Sat, 28 Feb 2009 14:43:44 +0100 Message-Id: <1235828624.6096.26.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16490.007 Cc: autoconf@ietf.org Subject: Re: [Autoconf] Autoconf addressing model X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Feb 2009 13:43:29 -0000 --=-zdLy5X1gE8l+qVyIL3so Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Hi, El vie, 27-02-2009 a las 20:28 +0100, Teco Boot escribi=F3: > Inline. >=20 > |-----Oorspronkelijk bericht----- > |Van: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] > |Verzonden: vrijdag 27 februari 2009 19:18 > |Aan: Teco Boot > |CC: autoconf@ietf.org > |Onderwerp: Re: Autoconf addressing model > | > |Teco Boot a =E9crit : > |[...] > |>>> I think there is a much more obvious option, using the RFC2464 > |>>> model for the MANET interface and /128 (or /32) for loopback > |>>> interfaces. Both would use high probability globally unique > |>>> Interface IDs like EUI-64 (Extended Unique Identifier). > |>> > |>> I don't agree going that way. I think loopback addresses are for > |>> self addressing not for talking to other nodes. > |> > |> See other mail also, on Linux. I think loopback addresses are often > |> used for stable connections to routers, where interfaces flap but due > |> to redundancy there are alternative paths. > | > |I think you mean a virtual interface actually, not necessarily the > |loopback interface (and yes, lo is a 'virtual' interface). > | > |Not all virtual interfaces are loopback. >=20 > Router folks use "loopback" for what is meant here. Virtual interfaces ha= ve > a much, much broader meaning. A tunnel interface or VLAN / FR / ATM > subinterface is a virtual interface but definitely not what I intent to u= se. > I prefer keep using the term loopback here. Agree, I prefer that term as well. >=20 > | > |> RFC3871: It is a common practice among operators to configure > |> "loopback" pseudo-interfaces to use as the source and destination of > |> management traffic. > | > |Well that RFC is completely wrong please someone correct it. The > |loopback address is ::1 and it can't be used to communicate outside the > |computer. Yes pseudo-interface (and maybe 'virtual') but no loopback. >=20 > I think you mix up "host loopback" and "router loopback". These are very, > very different! Agree, don't know if the semantic difference is documented somewhere, but I share the same understanding. Regards, Carlos >=20 >=20 >=20 > |And yes the interface in the routing table for the entry address/128 is > |'lo' which is yes the loopback interface but no, never will that address > |be in the src nor dst fields of any packet leaving the computer (other > |than encapsulated maybe). >=20 > I checked this on the Linux host. I assigned another address on the lo > interface. And the Linux host is reachable on this address, as long as ot= her > nodes has a path to this /128 prefix. >=20 > Sorry, you are wrong. >=20 > Detailed info: >=20 > debian-fs1:/proc/sys/net/ipv6/neigh/eth0# ifconfig lo =20 > lo Link encap:Local Loopback =20 > inet addr:127.0.0.1 Mask:255.0.0.0 > inet6 addr: 2001:db8:1::3333/128 Scope:Global > inet6 addr: ::1/128 Scope:Host > UP LOOPBACK RUNNING MTU:16436 Metric:1 > RX packets:185 errors:0 dropped:0 overruns:0 frame:0 > TX packets:185 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:0=20 > RX bytes:13568 (13.2 KiB) TX bytes:13568 (13.2 KiB) >=20 > Tested from IOS router: > nbs3725#ping 2001:db8:1::3333 > Type escape sequence to abort. > Sending 5, 100-byte ICMP Echos to 2001:DB8:1::3333, timeout is 2 seconds: > !!!!! > Success rate is 100 percent (5/5), round-trip min/avg/max =3D 0/0/4 ms > nbs3725# >=20 > I added reachability manually: > nbs3725#show ipv6 route > IPv6 Routing Table - 4 entries > Codes: C - Connected, L - Local, S - Static, R - RIP, B - BGP > U - Per-user Static route, M - MIPv6 > I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary > O - OSPF intra, OI - OSPF inter, OE1 - OSPF ext 1, OE2 - OSPF ext = 2 > ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2 > D - EIGRP, EX - EIGRP external > C 2001:DB8:1::/64 [0/0] > via ::, FastEthernet0/0.22 > L 2001:DB8:1::1/128 [0/0] > via ::, FastEthernet0/0.22 > S 2001:DB8:1::3333/128 [1/0] > via FE80::20C:29FF:FEE3:BDF5, FastEthernet0/0.22 > L FF00::/8 [0/0] > via ::, Null0 > nbs3725# >=20 > Debug info, showing that you are wrong, the IP address in interface lo is > reachable: > Feb 27 19:08:08.018: IPv6: SAS picked source 2001:DB8:1::1 for > 2001:DB8:1::3333 (FastEthernet0/0.22) > Feb 27 19:08:08.018: IPv6: nexthop FE80::20C:29FF:FEE3:BDF5, > Feb 27 19:08:08.018: IPV6: source 2001:DB8:1::1 (local) > Feb 27 19:08:08.018: dest 2001:DB8:1::3333 (FastEthernet0/0.22) > Feb 27 19:08:08.018: traffic class 0, flow 0x0, len 100+0, prot 58, > hops 64, originating > Feb 27 19:08:08.018: IPv6: Sending on FastEthernet0/0.22 >=20 > Feb 27 19:08:08.022: IPV6: source 2001:DB8:1::3333 (FastEthernet0/0.22) > Feb 27 19:08:08.022: dest 2001:DB8:1::1 > Feb 27 19:08:08.022: traffic class 0, flow 0x0, len 100+14, prot 58= , > hops 64, forward to ulp >=20 > SSH works well also. NTP used the address automatically: > debian-fs1:~# netstat -anp | grep 3333 > tcp6 0 52 2001:db8:1::3333:22 2001:db8:1::1:61026 > ESTABLISHED 4756/5 =20 > udp6 0 0 2001:db8:1::3333:123 :::* > 2308/ntpd =20 >=20 >=20 > |>> [rfc4291 and 2464 citations] > |>>> It is not only because the RFC texts that I dislike the /128 in > |>>> MANET interfaces, it is also backward compatibility with current > |>>> IP stacks (and probably many applications). > |>> > |>> I agree. > |>> > |>>> I think using /128 for loopback interfaces fits the requirements > |>>> for the addressing model. If a loopback interface is used, MANET > |>>> interfaces do not require a globally unique address. > |>> > |>> I'm not sure I could agree with the MANET interface being the > |>> loopback interface. It sounds as a significant departure. > |> > |> The MANET interface is not a loopback interface! It is the interface > |> to a radio, e.g. 802.11 NIC in IBSS mode (your wifi adhoc). > | > |I agree with this. But in the immediately above text you're saying > |"using /128 for loopback interfaces fits" - I think you meant 'virtual' > |interface, not 'loopback' interface, right? >=20 > No, absolutely not. > I provided the evidence that the loopback is perfectly usable already. >=20 >=20 > |>>> RFC4291 once more (out of section, also cited above): Unicast > |>>> addresses with a scope greater than link-scope are not needed for > |>>> interfaces that are not used as the origin or destination of any > |>>> IPv6 packets to or from non-neighbors. So "host functionality" > |>>> can be provided using the globally (or MANET local) unique > |>>> address assigned to a loopback address, or another non-MANET > |>>> interface. > |>> > |>> An address assigned to an address? I think it risks many > |>> misunderstandings. > |> > |> Typo, I meant: So "host functionality" can be provided using the > |> globally (or MANET local) unique address assigned to a loopback > |> interface, or another non-MANET interface. > | > |Ok. > | > | > |> I think this model solves some problems. o The assigned address can > |> be used over whatever interface. This fulfills a requirement of "ad > |> hoc", something works without planning. > | > |I thought the unplanned aspect could be treated by IPv6 stateless > |autoconf and IPv6-over-Ethernet link-local addresses. >=20 > Yes and no. I like SLAAC, but with SLAAC, thewre is an address per > interface. In this model, the node is reachable via the loopback address = via > whatever interface. >=20 >=20 >=20 > |> o Connectivity is not broken if a path swap occurs (the RFC3781 > |> loopback BCP) o It provides some scalability, as only a single > |> address is needed, even if multiple interfaces are used. o > |> Applications are not confused by "host prefixes" to a link, where > |> other nodes are reachable. I tested this with linux and IPv4 with > |> /32. > | > |Before deciding on the solution (address assigned to a virtual > |interface) I need to udnerstand how path swap occurs and why. >=20 > Because movement. A MANET Router may have multiple interfaces, some of th= em > could be MANET, others wireless infrastructure mode and others MANET. Whe= n a > fire truck leaves the brigade, it looses its wired / wifi ESS connection, > but can still communicate with other vehicles nearby using MANET links. >=20 >=20 >=20 > |> Problems started with ARP processing, and I swapped to another > |> addressing model immediately. > | > |>> For my clarification, what's fd01? (2001:db8:: is a prefix for > |>> documentation rfc3849, ULA is fc00 rfc4193). > |> > |> ULA prefix is FC00::/7. 8th but is L, set to 1 if locally assigned. > |> So all ULA would start with FD, the FC is for the future where a > |> registration body maintains the universal uniqueness. > |> > |> 0xFC + 0x01 =3D 0xFD. > | > |Ah! So a correct ULA address would be fd01::1/128? In this sense, when > |drawing pictures I have a choice between fd01::1/128 ULA and > |2001:db8::1/128 global address, it's ambiguous. > | > |>>> Manually assigned, or pre-configured (e.g. with SNMP) or formed > |>>> according to a to be defined [Autoconf for MANETs] protocol, with > |>>> a to-be-defined prefix (e.g. ULA, RFC4193). > |>>> > |>>> Although all nodes are marked as router, this does not imply all > |>>> nodes forward packets. All nodes run a MANET routing protocol for > |>>> learning > |>> the > |>>> MANET topology. > |>>> > |>>> > |>>> In case one of the routers is connected to the Internet or > |>>> private > |>> network, > |>>> this router can advertize a prefix in the MANET, and this > |>>> information > |>> is > |>>> distributed in the MANET with an [Autoconf for MANETs] protocol. > |>> > |>> Why shouldn't it be distributed with DHCP and with OSPF, for > |>> example. > |> > |> In a MANET, there are some problems with standard OSPF. OSPF-MANET is > |> perfectly fine to use in a MANET. > | > |Ok. > | > |> DHCP (with relay) can be used for "pull", but there is a problem > |> finding the best relay agent. I think there should be a mechanism > |> that informs nodes of available facilities, e.g. shortest path to a > |> DHCP server. Updating ND RA with some info for finding a DHCP server > |> looks a good idea to me, and I updated my Border Router Discovery > |> Protocol (BRDP) [Autoconf] proposal for DHCP support already. > | > |Sounds interesting. But I think normal DHCP could run ok, provided the > |Relays know the address of the Server. In a first practical step would > |be to manually configure the Server's address on each Relays. >=20 > When many DHCP Relay Agenst are nearby, who to select? If multicast is us= ed, > all of them will relay and this ends in a DHCP Relay storm (collisions, > loss, retry .....) >=20 >=20 >=20 > |> However, there is a chicken - egg problem. In a wired network, the > |> DHCP client - DHCP relay agent relation is stable. This is certainly > |> not the case in a MANET. > | > |Well it is the case in a MANET made of 25meter IPv6 subnets. >=20 > Voice over IP over WLAN for 25meter? Just shout!! > My requirements are over 25meter. 25km is no joke. Wifi is not usable her= e. >=20 >=20 > |> Therefore, I think a DHCP client should start with building reliable > |> communication to a DHCP server, and the MANET routing protocols can > |> provide such. But the MANET routing protocol needs a prefix that > |> corresponds to this MANET node. For this reason, I think it makes > |> sense to start with generating a prefix without DHCP, and we could > |> use a prefix "push model" here. > | > |Well I think this is indeed a very chickeneggy problem: are addresses in > |place before routing is, or vice-versa. But what would we do in > |practice? Certainly we'd manually assign some addresses - let's see > |these cases first. >=20 > No. > MANETs are often used in workgroups, whit lack of knowledge of configurin= g > something. The network must be plug&play / zero-config. >=20 >=20 >=20 > |>> Above, and in the following figures, I don't understand "--->, > |>> Prefix Information". Is that RA? Or OSPF? Or routing protocol? > |>> Or DHCP Prefix Delegation? > |> > |> This is under discussion, and the reason we have an [Autoconf] WG. > |> There are proposals that rely on a routing protocol, but the old > |> charter mentioned being independent of a routing protocol. > | > |I think we should consider first the practical cases. >=20 > No. I think we have a clear picture of why MANETs are being used.=20 > We need an [Autoconf] solution. Let's take the next steps defining an > addressing model, write down the requirements and then look for solutions= . >=20 >=20 > Teco. >=20 >=20 > |Alex >=20 > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf --=20 Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ WEEDEV 2009: 2nd Workshop on Experimental Evaluation and Deployment Experiences on Vehicular networks http://www.weedev.org/ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ --=-zdLy5X1gE8l+qVyIL3so Content-Type: application/pgp-signature; name=signature.asc Content-Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEABECAAYFAkmpP5AACgkQNdy6TdFwT2d6fQCdGoSiecq9H7ujRKvvzLSiwptk xgYAn3DUf8C2XNsq3fHG8jkeYpRAVGkD =GNCZ -----END PGP SIGNATURE----- --=-zdLy5X1gE8l+qVyIL3so-- From alexandru.petrescu@gmail.com Sat Feb 28 05:51:16 2009 Return-Path: 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 842383A6997 for ; Sat, 28 Feb 2009 05:51:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.169 X-Spam-Level: X-Spam-Status: No, score=-2.169 tagged_above=-999 required=5 tests=[AWL=0.080, 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 205V8UENyVRq for ; Sat, 28 Feb 2009 05:51:15 -0800 (PST) Received: from smtp3-g21.free.fr (smtp3-g21.free.fr [212.27.42.3]) by core3.amsl.com (Postfix) with ESMTP id 7F2E83A68C0 for ; Sat, 28 Feb 2009 05:51:13 -0800 (PST) Received: from smtp3-g21.free.fr (localhost [127.0.0.1]) by smtp3-g21.free.fr (Postfix) with ESMTP id D5A8E818109; Sat, 28 Feb 2009 14:51:33 +0100 (CET) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp3-g21.free.fr (Postfix) with ESMTP id 3FC4C818002; Sat, 28 Feb 2009 14:51:30 +0100 (CET) Message-ID: <49A94148.3040805@gmail.com> Date: Sat, 28 Feb 2009 14:51:04 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: "Stan Ratliff (sratliff)" References: <499F0BA7.90501@piuha.net> <7E8A76F7-2CE0-463A-8EE8-8877C46B4715@gmail.com> <49A6D436.7020505@gmail.com> <000001c99845$1dc56190$595024b0$@nl> <49A6F125.40400@gmail.com> <1235680887.4585.5.camel@localhost><49A7BB89.5040807@gmail.com> <003901c998cb$42b71e90$c8255bb0$@nl><49A7E97A.2010503@gmail.com> <006801c998fd$06c5bd60$14513820$@nl> <49A8272D.2060400@gmail.com> <7FB7EE0A621BA44B8B69E5F0A09DC76407AD0C48@xmb-rtp-208.amer.cisco.com> <49A83172.70105@gmail.com> <7FB7EE0A621BA44B8B69E5F0A09DC76407AD0C70@xmb-rtp-208.amer.cisco.com> <49A84285.5030103@nps.navy.mil> <49A8531A.3020404@gmail.com> <7FB7EE0A621BA44B8B69E5F0A09DC76407AD0D5F@xmb-rtp-208.amer.cisco.com> In-Reply-To: <7FB7EE0A621BA44B8B69E5F0A09DC76407AD0D5F@xmb-rtp-208.amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 090227-0, 27/02/2009), Outbound message X-Antivirus-Status: Clean Cc: Rex Buddenberg , autoconf@ietf.org Subject: Re: [Autoconf] new charter X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Feb 2009 13:51:16 -0000 Stan Ratliff (sratliff) a écrit : > > >> -----Original Message----- From: Alexandru Petrescu >> [mailto:alexandru.petrescu@gmail.com] Sent: Friday, February 27, >> 2009 3:55 PM To: Rex Buddenberg Cc: Stan Ratliff (sratliff); >> Alexandru Petrescu; autoconf@ietf.org Subject: Re: [Autoconf] new >> charter >> >> Rex Buddenberg a écrit : >>> Stan, >>> >>> The difference is not geo footprint (you got that right). >> Rather the >>> difference is between LAN (at fringe of network) and WAN (in the >>> interior). A WAN will always be at least one router away >> from end systems. >>> While we're at it, references to SSIDs is not proper -- that's >>> 802.11-specific. >> 802.11-specific because that's what many people actually mean. >> "Ad-hoc" type of SSID is there for same reason. Many MANET >> experiments happened with 802.11 links. Wireless LANs, WaveLAN, >> all are in scope and deserve mentioning. They're the building >> blocks out of which MANETs can come up. >> >> For LOS satcom communications: if I knew the precise names then I >> could find the manner in which they (or their admins) configure >> their IPv6 addresses. >> >> I'm specifically keeping out of MANET 802.15.4 (akin to WPAN) >> because there seems to be an IPv6 ND draft for this link which >> already has its own address autoconfiguration quirks. >> >> For WMAN: I'm aware of 802.16 and it has its own already IETF >> specified means of forming IPv6 addresses. >> >> In this landscape, I'm not sure how could Autoconf practical way of >> forming addresses not mention WiFi. >> >> Alex >> > > Alex, > > None of the MANET networks I deploy are based on WiFi. I think that > turning the discussion into one that is 802.11-centric is not a good > idea -- it's analogous to our earlier discussion on distance of the > radio link. Why should the Layer 2 protocol in use effect the > selection of Layer 3 addresses? If not 802.11 then what link layer name? I agree it's a good direction to stay independent on the link-layer name - IP should run over them all. At the same time I'm afraid once we spell out the link layer name we implicitely name the way in which the initial assignment of an IPv6 address to the nodes attached to that link layer, is spelled out. And we should at least reuse that. Thank you for the oppinion, and I think many people think along the lines you suggest. Alex From alexandru.petrescu@gmail.com Sat Feb 28 06:07:08 2009 Return-Path: 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 4E7E33A6A6A for ; Sat, 28 Feb 2009 06:07:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.173 X-Spam-Level: X-Spam-Status: No, score=-2.173 tagged_above=-999 required=5 tests=[AWL=0.076, 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 qkfXsCU-qvG9 for ; Sat, 28 Feb 2009 06:07:07 -0800 (PST) Received: from smtp4-g21.free.fr (smtp4-g21.free.fr [212.27.42.4]) by core3.amsl.com (Postfix) with ESMTP id C94F93A6A4D for ; Sat, 28 Feb 2009 06:07:05 -0800 (PST) Received: from smtp4-g21.free.fr (localhost [127.0.0.1]) by smtp4-g21.free.fr (Postfix) with ESMTP id D01654C8148; Sat, 28 Feb 2009 15:07:24 +0100 (CET) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp4-g21.free.fr (Postfix) with ESMTP id 84C6B4C8125; Sat, 28 Feb 2009 15:07:21 +0100 (CET) Message-ID: <49A944FF.9000102@gmail.com> Date: Sat, 28 Feb 2009 15:06:55 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Teco Boot References: <499F0BA7.90501@piuha.net> <7E8A76F7-2CE0-463A-8EE8-8877C46B4715@gmail.com> <49A6D436.7020505@gmail.com> <000001c99845$1dc56190$595024b0$@nl> <49A6F125.40400@gmail.com> <1235680887.4585.5.camel@localhost> <002f01c998bf$8f112210$ad336630$@nl> <49A7E58C.2020303@gmail.com> <007201c99903$c4182c80$4c488580$@nl> <49A82E55.10208@gmail.com> <007b01c99911$907facf0$b17f06d0$@nl> <49A8471E.6090506@gmail.com> <009501c99920$92154340$b63fc9c0$@nl> In-Reply-To: <009501c99920$92154340$b63fc9c0$@nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 090227-0, 27/02/2009), Outbound message X-Antivirus-Status: Clean Cc: autoconf@ietf.org Subject: Re: [Autoconf] Autoconf addressing model X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Feb 2009 14:07:08 -0000 Teco Boot a écrit : > > |-----Oorspronkelijk bericht----- > |Van: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] > |Verzonden: vrijdag 27 februari 2009 21:04 > |Aan: Teco Boot > |CC: autoconf@ietf.org > |Onderwerp: [SPAM] Re: Autoconf addressing model > |Urgentie: Laag > | > |Teco Boot a écrit : > |> |Not all virtual interfaces are loopback. > | > |Again, do you think all virtual interfaces are 'loopback'? > > Not at all. > > And "loopback" on its own is meaningless. No, I think loopback address and loopback interface are meaningful. > |> Router folks use "loopback" for what is meant here. Virtual > |> interfaces have a much, much broader meaning. A tunnel interface or > |> VLAN / FR / ATM subinterface is a virtual interface but definitely > |> not what I intent to use. I prefer keep using the term loopback here. > | > |I strongly disagree using the term loopback interface, at least because > |it can be easily interpreted as the interface on which there's a > |'loopback address'. > > > Check for example ISP BCP, rfc5375 Checked. The fact that Cisco uses 'loopback interface' to be something completely different than the interface holding the loopback address doesn't mean I should too. I disagree with Cisco on this particular point. > I agree on that there can be confusion on loopback address (node local) and > loopback interface. I agree. > |The loopback interface is the only interface on which there's a loopback > |address assigned. > > This is NOT a node requirement. > > RFC4291: > 2.5.3. The Loopback Address > > The unicast address 0:0:0:0:0:0:0:1 is called the loopback address. > It may be used by a node to send an IPv6 packet to itself. It must > not be assigned to any physical interface. It is treated as having > Link-Local scope, and may be thought of as the Link-Local unicast > address of a virtual interface (typically called the "loopback > interface") to an imaginary link that goes nowhere. > > Note the wording "may be". Note the status of that rfc compared to the two rfcs you cited previously calling the loopback interface a virtual interface. > The other way around is definitely false: > RFC3484 (default address selection): > Implementations that wish to support the use > of global source addresses assigned to a loopback interface should > behave as if the loopback interface originates and forwards the > packet. > > Assigning non-"loopback addresses" on the loopback interfaces is permitted. YEs, it is permitted, I agree. But why should one do it? > |> |> RFC3871: It is a common practice among operators to configure |> > |> "loopback" pseudo-interfaces to use as the source and destination of > |> |> management traffic. | |Well that RFC is completely wrong please > |> someone correct it. The |loopback address is ::1 and it can't be > |> used to communicate outside the |computer. Yes pseudo-interface (and > |> maybe 'virtual') but no loopback. > |> > |> I think you mix up "host loopback" and "router loopback". These are > |> very, very different! > | > |I think there's no difference between host and router loopback. > > Yes. > On a host (strong end system model, RFC1122), traffic sent out the host MUST > have the source address of the outgoing interface. On a router, this is not > the case. Therefore assignment of addresses on loopback interfaces on > routers is different than on (strong ES) hosts. YEs, I agree permitted, and implemented. But why should a MANET do that - it could do it with virtual interfaces, not loopback. > |In a first step, do we agree that the node has typically more than one > |interface? We didn't seem to. If not, then why should we need to have > |the node reachable via whatever interface, since there's only one. > > If there is only one (external) interface, there is no redundancy and the > advantages do not apply. Let's decide whether we deal with nodes having two-or-more physical interfaces or with single-physical-interface nodes. > |If there are at least two interfaces, then why can't we use a different > |address on each of the interfaces? What's wrong with that? The fact > |that the node moves? Well, you seemed to accept host-based /128 routes > |- in this case instead of 1 there'll be 2 host-based /128 routes. > |What's wrong with that again? > > At least 2 advantages: > o 1 address: lower overhead ?? overhead of what? > o no address swap needed when session swaps from one interface to the other > (and if interfaces go down!). Swapping sessions from one physical interface to another can happen by using virtual interfaces. IT can happen too without any virtual interface. Some Mobile IPv6 implementation does it. > Your assumption is single hop communication and no MANET routing protocol. I > am interested in the more complex topologies. The pictures I drawn are multihop. And indeed I don't assume a MANET routing protocol. Neither does the charter. And that's ok. > There is no "essid" in ad hoc mode. It is the "ssid" of the IBSS. Only ESS > has essid. > Let's try to be accurate. iwconfig essid "adhoc1" mode ad-hoc is also accurate. > |> |> However, there is a chicken - egg problem. In a wired network, the > |> |> DHCP client - DHCP relay agent relation is stable. This is > |> certainly |> not the case in a MANET. | |Well it is the case in a > |> MANET made of 25meter IPv6 subnets. > |> > |> Voice over IP over WLAN for 25meter? Just shout!! > | > |:-) :-) I agree. > | > |But the IP in VoIP over a 25m IPv6 subnet allows me to talk to another > |IP much further who wouldn't hear my shout otherwise. > > Yes. a MANET topology could be a short-range / high data rate radio link to > another MANET Router, with low data rate / long range to a remote peer, and > another hop via short-range / high data radio link. In a mobile ad hoc > environment, nodes are free to move and the network should provide the best > connectivity to the users that is technical feasible. > > Not only the nodes may move, obstacles may also move (teapot, truck). Ah! Thank you for the pictures below. Later I will collect all the pictures posted recently. I will list them in a email for future record. [...] > What about this scenario: here, the obstacle is moving: > > (802.11 term: STA is station) > > +------------------------+ +------------------------+ > | | | | > | ____STA-B | | ____STA-B | > | ___/ | | | ___/ | > | STA-A | | | STA-A OBSTACLE | > | '--_ | | | '--_ | > | '----STA-C | | '----STA-C | > | OBSTACLE | | | > +------------------------+ +------------------------+ > 1-1: No hindrance 1-2: B-C blocked > > +------------------------+ +------------------------+ > | | | O | > | ____STA-B | | B STA-B | > | ___/ | | | S | | > | STA-A OB | | | STA-A T | | > | ST | | | A | | > | AC STA-C | | C STA-C | > | LE | | LE | > +------------------------+ +------------------------+ > 1-3: A-C blocked 1-4: A-B & A-C blocked > > MANET Scenarios with blocking obstacle This is absolutely wonderful. I set it aside. > Compare with this one: > > (802.11 term: AP is access point) > > +------------------------+ +------------------------+ > | | | | > | ____STA-B | | ____STA-B | > | ___/ | | ___/ | > | AP-A | | AP-A OBSTACLE | > | '--_ | | '--_ | > | '----STA-C | | '----STA-C | > | OBSTACLE | | | > +------------------------+ +------------------------+ > 4-1: No hindrance 4-2: No hindrance > > +------------------------+ +------------------------+ > | | | O | > | ____STA-B | | B STA-B | > | ___/ | | S | > | AP-A OB | | AP-A T | > | ST | | A | > | AC STA-C | | C STA-C | > | LE | | LE | > +------------------------+ +------------------------+ > 4-3: A-C & B-C blocked 4-4: All blocked > > 802.11 BSS L2 topology with blocking obstacle > > > In these scenario's, the MANET model provides better connectivity. I won't > say more bandwidth, lower loss or other link quality metrics, but for high > availability the MANET model definitely wins. I set this aside too. HAving them pictured, may I ask you: do you think anything will ever be able to communicate through Obstacles? Alex From alexandru.petrescu@gmail.com Sat Feb 28 06:09:26 2009 Return-Path: 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 C70443A6A08 for ; Sat, 28 Feb 2009 06:09:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.176 X-Spam-Level: X-Spam-Status: No, score=-2.176 tagged_above=-999 required=5 tests=[AWL=0.073, 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 az3raF7LgEnr for ; Sat, 28 Feb 2009 06:09:26 -0800 (PST) Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [212.27.42.6]) by core3.amsl.com (Postfix) with ESMTP id C57343A6997 for ; Sat, 28 Feb 2009 06:09:24 -0800 (PST) Received: from smtp6-g21.free.fr (localhost [127.0.0.1]) by smtp6-g21.free.fr (Postfix) with ESMTP id 40709E0810F; Sat, 28 Feb 2009 15:09:42 +0100 (CET) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp6-g21.free.fr (Postfix) with ESMTP id 018C9E080E3; Sat, 28 Feb 2009 15:09:39 +0100 (CET) Message-ID: <49A94589.9050203@gmail.com> Date: Sat, 28 Feb 2009 15:09:13 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: cjbc@it.uc3m.es References: <499F0BA7.90501@piuha.net> <7E8A76F7-2CE0-463A-8EE8-8877C46B4715@gmail.com> <49A6D436.7020505@gmail.com> <000001c99845$1dc56190$595024b0$@nl> <49A6F125.40400@gmail.com> <1235680887.4585.5.camel@localhost> <002f01c998bf$8f112210$ad336630$@nl> <1235828619.6096.24.camel@localhost> In-Reply-To: <1235828619.6096.24.camel@localhost> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 090227-0, 27/02/2009), Outbound message X-Antivirus-Status: Clean Cc: autoconf@ietf.org Subject: Re: [Autoconf] Autoconf addressing model X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Feb 2009 14:09:26 -0000 Carlos Jesús Bernardos Cano a écrit : [...] >> It doesn't matter how many ad hoc segments there are. In the following >> scenario, the link to Access router G disappeared, Router 3 disappeared and >> a Router4 joined IBSS "adhoc1". >> >> >> >> ---+-------Internet------ >> | >> | >> +-------+-------+ >> |Access Router H| >> +-------+-------+ >> | >> ||Prefix information H >> |V wifi "adhoc1" >> | <---------------------------v--------> >> <------|--v----------------------> | >> |<-|--------------------v-----------------------|---> >> | | | | >> +---+--'+ +---'---+ +---'---+ >> |Router1|>-------------<|Router2|>-------------<|Router4| >> +---L---+ LL1 LL21 +---L---+ LL22 LL4 +---L---+ >> |M1 |M2 |M4 >> |H1 |H2 |H4 >> >> ---------> ---------> >> Prefix information H Prefix information H >> >> >> Now, Router2 acts as a relay for Router4, so Router4 can reach Router1 and >> the Internet. Router1 acts as Border Router for all nodes in the MANET. >> > > While I think this is also much in linee with my thinking, I think it's > better to focus on the simplest cases before. What are the simplest cases? Alex From cjbc@it.uc3m.es Sat Feb 28 08:38:17 2009 Return-Path: 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 17D3C3A696C for ; Sat, 28 Feb 2009 08:38:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5 X-Spam-Level: X-Spam-Status: No, score=-5 tagged_above=-999 required=5 tests=[AWL=0.700, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] 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 JC4iPioH2CHG for ; Sat, 28 Feb 2009 08:38:16 -0800 (PST) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id A62B43A6805 for ; Sat, 28 Feb 2009 08:38:15 -0800 (PST) Received: from [192.168.1.209] (213.37.82.74.static.user.ono.com [213.37.82.74]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp01.uc3m.es (Postfix) with ESMTP id 0A2BBB4D4A1; Sat, 28 Feb 2009 17:38:38 +0100 (CET) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Alexandru Petrescu In-Reply-To: <49A94589.9050203@gmail.com> References: <499F0BA7.90501@piuha.net> <7E8A76F7-2CE0-463A-8EE8-8877C46B4715@gmail.com> <49A6D436.7020505@gmail.com> <000001c99845$1dc56190$595024b0$@nl> <49A6F125.40400@gmail.com> <1235680887.4585.5.camel@localhost> <002f01c998bf$8f112210$ad336630$@nl> <1235828619.6096.24.camel@localhost> <49A94589.9050203@gmail.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-7/hG8RdAMkmRCpBMsrD9" Organization: Universidad Carlos III de Madrid Date: Sat, 28 Feb 2009 17:38:37 +0100 Message-Id: <1235839117.6096.30.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16492.000 Cc: autoconf@ietf.org Subject: Re: [Autoconf] Autoconf addressing model X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Feb 2009 16:38:17 -0000 --=-7/hG8RdAMkmRCpBMsrD9 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Hi Alex, I mean, let's try to agree on the basics (addressing model) and then let's try to understand what happens with multihoming and more complex scenarios. Thanks, Carlos El s=E1b, 28-02-2009 a las 15:09 +0100, Alexandru Petrescu escribi=F3: > Carlos Jes=FAs Bernardos Cano a =E9crit : > [...] > >> It doesn't matter how many ad hoc segments there are. In the following > >> scenario, the link to Access router G disappeared, Router 3 disappeare= d and > >> a Router4 joined IBSS "adhoc1". > >> > >> > >> > >> ---+-------Internet------ > >> | =20 > >> | =20 > >> +-------+-------+ =20 > >> |Access Router H| =20 > >> +-------+-------+ =20 > >> | =20 > >> ||Prefix information H =20 > >> |V wifi "adhoc1" > >> | <---------------------------v-------->=20 > >> <------|--v----------------------> |=20 > >> |<-|--------------------v-----------------------|---> > >> | | | | > >> +---+--'+ +---'---+ +---'---+ > >> |Router1|>-------------<|Router2|>-------------<|Router4| > >> +---L---+ LL1 LL21 +---L---+ LL22 LL4 +---L---+ > >> |M1 |M2 |M4 > >> |H1 |H2 |H4 > >> > >> ---------> ---------> > >> Prefix information H Prefix information H > >> > >> > >> Now, Router2 acts as a relay for Router4, so Router4 can reach Router1= and > >> the Internet. Router1 acts as Border Router for all nodes in the MANET= . > >> > >=20 > > While I think this is also much in linee with my thinking, I think it's > > better to focus on the simplest cases before. >=20 > What are the simplest cases? >=20 > Alex >=20 --=20 Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ WEEDEV 2009: 2nd Workshop on Experimental Evaluation and Deployment Experiences on Vehicular networks http://www.weedev.org/ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ --=-7/hG8RdAMkmRCpBMsrD9 Content-Type: application/pgp-signature; name=signature.asc Content-Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEABECAAYFAkmpaI0ACgkQNdy6TdFwT2dCAwCgtATXhMB9DbnbocouomrRJAqL wRAAn3EI4eB7YagcjOK0uK92aXKdBg1p =uKwY -----END PGP SIGNATURE----- --=-7/hG8RdAMkmRCpBMsrD9-- From dream.hjlim@gmail.com Sat Feb 28 19:05:39 2009 Return-Path: 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 9F59D3A6B76 for ; Sat, 28 Feb 2009 19:05:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.538 X-Spam-Level: X-Spam-Status: No, score=-2.538 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, 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 H2HMYMggLAgu for ; Sat, 28 Feb 2009 19:05:38 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.226]) by core3.amsl.com (Postfix) with ESMTP id 695193A67C0 for ; Sat, 28 Feb 2009 19:05:38 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id l9so1618478rvb.49 for ; Sat, 28 Feb 2009 19:06:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=ExDCFjSN2UiIHOB1H+xRws6Lq87Go8dtG0my086EWBM=; b=FWLuvV4fkfHkmjSkbvNGJmLi0/t6n2AT8CYBwRprsuNxdf7lkdtyhPgYs3UvfEykO3 JwyUXdvgLYypAAS5Lms/yolmc6iBOaZX/esnrzsFwqhEZHDBBDKXUK0eg8tSBuJT8e5B cnVb++nv7y/N+TvBmW8IJyJgJSTubyMPv8p8s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Ga1sy3OUpmY+dHmAaMHFLfwgyjQ/e++2fzsV59MN868Gkrk4ZE0gTD8IEkeISTcThz 0MyZXXGjSv2bsLXh2u0vWT8Z8ORuZYmY9JyVmwBSJ7qr7PryJJ7w1T5pngOvhCmd6HP5 UfDhPLkWDCUJNkQEcKe96JCAT6WsjO5NfJqQs= MIME-Version: 1.0 Received: by 10.142.242.8 with SMTP id p8mr2190526wfh.60.1235876762807; Sat, 28 Feb 2009 19:06:02 -0800 (PST) In-Reply-To: <49A94589.9050203@gmail.com> References: <499F0BA7.90501@piuha.net> <7E8A76F7-2CE0-463A-8EE8-8877C46B4715@gmail.com> <49A6D436.7020505@gmail.com> <000001c99845$1dc56190$595024b0$@nl> <49A6F125.40400@gmail.com> <1235680887.4585.5.camel@localhost> <002f01c998bf$8f112210$ad336630$@nl> <1235828619.6096.24.camel@localhost> <49A94589.9050203@gmail.com> Date: Sun, 1 Mar 2009 12:06:02 +0900 Message-ID: <7e8d02d40902281906k3fd36f03ud329c1db2738221e@mail.gmail.com> From: HyungJin Lim To: Alexandru Petrescu Content-Type: multipart/alternative; boundary=000e0cd32af06eeda6046405fb63 Cc: autoconf@ietf.org Subject: Re: [Autoconf] Autoconf addressing model X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Mar 2009 03:05:39 -0000 --000e0cd32af06eeda6046405fb63 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable inline.. 2009/2/28, Alexandru Petrescu : > > Carlos Jes=FAs Bernardos Cano a =E9crit : > [...] > >> It doesn't matter how many ad hoc segments there are. In the following >>> scenario, the link to Access router G disappeared, Router 3 disappeared >>> and >>> a Router4 joined IBSS "adhoc1". >>> >>> >>> >>> ---+-------Internet------ >>> | | +-------+-------+ >>> |Access Router H| +-------+-------+ | >>> ||Prefix information H |V wif= i >>> "adhoc1" >>> | <---------------------------v--------> >>> <------|--v----------------------> | >>> |<-|--------------------v-----------------------|---> >>> | | | | >>> +---+--'+ +---'---+ +---'---+ >>> |Router1|>-------------<|Router2|>-------------<|Router4| >>> +---L---+ LL1 LL21 +---L---+ LL22 LL4 +---L---+ >>> |M1 |M2 |M4 >>> |H1 |H2 |H4 >>> >>> ---------> ---------> >>> Prefix information H Prefix information H >>> >>> >>> Now, Router2 acts as a relay for Router4, so Router4 can reach Router1 >>> and >>> the Internet. Router1 acts as Border Router for all nodes in the MANET. >>> >>> >> While I think this is also much in linee with my thinking, I think it's >> better to focus on the simplest cases before. >> > > What are the simplest cases? I think we can divided into two category in MANET scenario as follows. Category 1 Scenario 1: "MANET to Internet", in case, depths of nested routers(NEMO) is under three levels. This is practical case in real world (i.e., most scenarios in real world) Scenario 2: "MANET to Internet", depths of nested routers is more than three levels. (i.e., perhaps disaster situation, etc.. ) Category 2 (scenario 3) : "Only MANET", in case, the network does not ha= s a connectivity to Internet. (i.e., peer-to-peer network, etc..) Requirement of address model we need is different according with considered scenario I think. Then some scenarios included in category 2 not needs topological meaningful address. Which area is AUTOCONF want to pinpoint ? I think AUTOCONF should satisfy requirements between pure MANET, NEMO and MANEMO that can compose of mesh network, although we discussed about the difference between MANET, NEMO and MANEMO Moreover, these networks can has some impacts due to mobility pattern= , wireless coverage and any other situations. AUTOCONF Addressing model can make a important role to efficient and secure aspects. What do you think about my comments ? Hyung-Jin, Lim > Alex > > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf > --000e0cd32af06eeda6046405fb63 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable inline..

2009/2/28, Alexandru Petrescu <alexandru.petrescu@gmail.com>= ;:=20
Carlos Jes=FAs Bernardos Cano a = =E9crit :
[...]
It doesn't matter how many a= d hoc segments there are. In the following
scenario, the link to Access = router G disappeared, Router 3 disappeared and
a Router4 joined IBSS "adhoc1".



=A0 =A0 ---+------= -Internet------
=A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 +-------+-------+ =A0 =A0 =A0|Access = Router H| =A0 =A0 =A0 +-------+-------+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0||Prefix informa= tion H =A0 =A0 =A0 =A0 =A0|V =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 wifi &= quot;adhoc1"
=A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <------------------= ---------v--------> =A0<------|--v----------------------> =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0|<-|-------------------= -v-----------------------|--->
=A0 =A0 =A0 =A0| =A0| =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
=A0 =A0+---+--'+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 +---'---+ =A0 =A0 =A0 = =A0 =A0 =A0 =A0 +---'---+
=A0 =A0|Router1|>-------------<|Rout= er2|>-------------<|Router4|
=A0 =A0+---L---+ LL1 =A0 =A0 =A0LL21 = +---L---+ LL22 =A0 =A0 =A0LL4 +---L---+
=A0 =A0 =A0 =A0|M1 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 |M2 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |M4=
=A0 =A0 =A0 =A0|H1 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |H2 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 |H4

=A0 =A0 =A0 =A0 =A0 =A0 =A0---------= > =A0 =A0 =A0 =A0 =A0 =A0 =A0 --------->
=A0 =A0 =A0 =A0 =A0 =A0 = =A0Prefix information H =A0 =A0 Prefix information H


Now, Router= 2 acts as a relay for Router4, so Router4 can reach Router1 and
the Internet. Router1 acts as Border Router for all nodes in the MANET.
=

While I think this is also much in linee with my think= ing, I think it's
better to focus on the simplest cases before.

What are the simplest cases?
=A0
=A0=A0 I think we can divided into two category in MANET scenario as f= ollows.
=A0
=A0=A0=A0=A0=A0=A0 =A0Category 1
=A0=A0 =A0=A0=A0=A0 =A0=A0=A0 Scenario 1: "MANET to=A0Internet&qu= ot;, in case,=A0depths of nested routers(NEMO) =A0is under three levels.
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0This is practical case in real world (i.e., most=A0scenarios in re= al world)
=A0=A0=A0=A0=A0=A0=A0=A0 Scenario 2: "MANET to Internet", de= pths of nested routers is more than three levels.
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 (i.e., perhaps disaster situation, etc..=A0)
=A0
=A0=A0=A0=A0=A0 =A0Category=A02 (scenario 3)=A0
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0 : "Only MANET", in case, the network does not has a con= nectivity to Internet.
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 (i.e., peer-to-peer network, etc..)
=A0=A0=A0
=A0=A0=A0=A0=A0Requirement of address model we need=A0is different acc= ording with considered scenario I think.
=A0=A0=A0=A0 Then=A0some scenarios included in category 2 not needs to= pological meaningful address.=A0
=A0
=A0=A0=A0=A0=A0=A0Which area=A0is AUTOCONF want to pinpoint ?
=A0
=A0 =A0=A0=A0 I think AUTOCONF should satisfy requirements=A0between p= ure MANET, NEMO and=A0MANEMO
=A0=A0=A0=A0=A0=A0that can compose of=A0mesh network, although we disc= ussed about the difference=A0between MANET, NEMO and=A0MANEMO
=A0=A0=A0=A0
=A0=A0=A0=A0=A0=A0Moreover,=A0these networks can has some impacts=A0du= e to mobility pattern, wireless coverage and any other situations.=A0AUTOCO= NF Addressing=A0model=A0can=A0make a important role=A0to efficient and=A0se= cure aspects.
=A0
=A0=A0=A0=A0 What do you think about my comments ?
=A0=A0=A0=A0
=A0=A0 Hyung-Jin, Lim
=A0
Alex

_______________________________________________
A= utoconf mailing list
Autoconf@ietf.= org
https://www.ietf= .org/mailman/listinfo/autoconf

--000e0cd32af06eeda6046405fb63--