From autoconf-bounces@ietf.org Mon Jul 10 05:46:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzsLY-00027U-97; Mon, 10 Jul 2006 05:46:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzsLX-00027A-2p for autoconf@ietf.org; Mon, 10 Jul 2006 05:46:31 -0400 Received: from nez-perce.inria.fr ([192.93.2.78]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FzsLT-0005TG-Lm for autoconf@ietf.org; Mon, 10 Jul 2006 05:46:31 -0400 Received: from [192.168.1.3] (Vb17c.v.pppool.de [89.57.177.124]) (authenticated bits=0) by nez-perce.inria.fr (8.13.6/8.13.6) with ESMTP id k6A9kN3j020994 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 10 Jul 2006 11:46:24 +0200 Message-ID: <44B221A8.1030400@inria.fr> Date: Mon, 10 Jul 2006 11:45:12 +0200 From: Emmanuel Baccelli User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: autoconf@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-j-chkmail-Score: MSGID : 44B221EF.003 on nez-perce : j-chkmail score : XX : 5/20 0 X-Miltered: at nez-perce with ID 44B221EF.003 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Subject: [Autoconf] Pre-version of problem-statement I-D. X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ad Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: autoconf-bounces@ietf.org Hi all, Trying to converge the great work of adp, scenario and framework drafts into one document, please find here an initial version of a proposed problem statement draft: http://manetautoconf.online.fr/Blog/wp-content/draft-baccelli-autoconf-statement-00.txt Note that this is an initial version, and that there is room for improvement - so comments are more than welcome. Cheers, Emmanuel _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Tue Jul 11 12:42:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0LJg-0004o7-SO; Tue, 11 Jul 2006 12:42:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyINz-00042e-7t for autoconf@ietf.org; Wed, 05 Jul 2006 21:10:31 -0400 Received: from outbound.mailhop.org ([63.208.196.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyINx-0004E3-0U for autoconf@ietf.org; Wed, 05 Jul 2006 21:10:31 -0400 Received: from did75-10-82-236-230-133.fbx.proxad.net ([82.236.230.133] helo=[192.168.147.101]) by outbound.mailhop.org with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.51) id 1FyINw-0001XL-E2 for autoconf@ietf.org; Wed, 05 Jul 2006 21:10:28 -0400 X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 82.236.230.133 X-Report-Abuse-To: abuse@dyndns.com (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: voop Mime-Version: 1.0 (Apple Message framework v752.2) Content-Transfer-Encoding: 7bit Message-Id: <35D35040-2936-40EF-95D3-C834462188D6@polytechnique.fr> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: autoconf@ietf.org From: Thomas Clausen Date: Thu, 6 Jul 2006 03:10:28 +0200 X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a X-Mailman-Approved-At: Tue, 11 Jul 2006 12:42:31 -0400 Subject: [Autoconf] Update to the manet autoconf "blog" X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ad Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: autoconf-bounces@ietf.org Folks, In preparation for the upcoming IETF, I've tried to update the autoconf blog with whatever I-D's I've seen posted in the past week (s), which seems relevant to the WG. I may have missed some (the volume of I-Ds just prior to an IETF is overwhelming), so if you see something missing, please let me know such that I may rectify it: http://manetautoconf.online.fr/Blog/ I second Shubhranshu in reminding y'all that we appreciate hearing from authors of I-Ds who wish to present or announce their I-D at the wg meeting. See you in Montreal! --thomas -- Thomas Clausen Thomas.Clausen@polytechnique.fr http://www.lix.polytechnique.fr/Labo/Thomas.Clausen/ http://www.lix.polytechnique.fr/hipercom/ _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Tue Jul 11 14:40:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0N9P-00026L-Bt; Tue, 11 Jul 2006 14:40:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0N9P-00026G-0q for autoconf@ietf.org; Tue, 11 Jul 2006 14:40:03 -0400 Received: from mail.um.es ([155.54.212.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0N9M-0003A9-Ku for autoconf@ietf.org; Tue, 11 Jul 2006 14:40:03 -0400 Received: from localhost (localhost [127.0.0.1]) by mail.um.es (Postfix) with ESMTP id 7A33A1FB21F; Tue, 11 Jul 2006 20:39:59 +0200 (CEST) Received: from mail.um.es ([127.0.0.1]) by localhost (xenon1 [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 03228-01-84; Tue, 11 Jul 2006 20:39:58 +0200 (CEST) Received: from [192.150.187.140] (wifi140.icsi.berkeley.edu [192.150.187.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.um.es (Postfix) with ESMTP id 1361B1FB244; Tue, 11 Jul 2006 20:39:57 +0200 (CEST) Message-ID: <44B3F07B.8050000@dif.um.es> Date: Tue, 11 Jul 2006 11:39:55 -0700 From: "Pedro M. Ruiz" User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thomas Clausen Subject: Re: [Autoconf] Update to the manet autoconf "blog" References: <35D35040-2936-40EF-95D3-C834462188D6@polytechnique.fr> In-Reply-To: <35D35040-2936-40EF-95D3-C834462188D6@polytechnique.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at telemat.um.es X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: autoconf@ietf.org X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ad Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: autoconf-bounces@ietf.org Hi Thomas, Unfortunately we couldn't make it to this IETF. I hope we can present in the next one the simulation results that we got comparing EMAP to some of the other schemes as well as or new extensions to the draft-ros-emap-autoconf-02 draft. Regards, --Pedro Thomas Clausen wrote: > Folks, > > In preparation for the upcoming IETF, I've tried to update the > autoconf blog with whatever I-D's I've seen posted in the past week > (s), which seems relevant to the WG. I may have missed some (the > volume of I-Ds just prior to an IETF is overwhelming), so if you see > something missing, please let me know such that I may rectify it: > > http://manetautoconf.online.fr/Blog/ > > I second Shubhranshu in reminding y'all that we appreciate hearing > from authors of I-Ds who wish to present or announce their I-D at the > wg meeting. > > See you in Montreal! > > --thomas > -- --------------------------------------------------------------------- Pedro M. Ruiz, Ph.D. E-mail: pedrom@dif.um.es Fac. Informatica, Univ. of Murcia Phone: +34968364335 Campus de Espinardo s/n Fax: +34968364151 E-30100, Espinardo, Murcia www: ants.dif.um.es/~pedrom/ SPAIN --------------------------------------------------------------------- _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Mon Jul 17 08:52:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2SaH-0006tL-1i; Mon, 17 Jul 2006 08:52:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2SaG-0006tG-3A for autoconf@ietf.org; Mon, 17 Jul 2006 08:52:24 -0400 Received: from web31807.mail.mud.yahoo.com ([68.142.207.70]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G2SaE-0005Z9-EO for autoconf@ietf.org; Mon, 17 Jul 2006 08:52:24 -0400 Received: (qmail 74492 invoked by uid 60001); 17 Jul 2006 12:52:18 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=x1mOd8CptQBjSYx+Qcg+HwTVoX66RYI0UpAhxpyqaV9RhrjUJLZsa5ihHPeH1dTh1+hIjJUkE6yb2MUOhWS+/epZrnaxGiD/u886rBTPzI8R1pzDGD0hsI3upfWB+3usYAcvtdykArQEfgm1BhxCTiRA2WaWjp6KqrRmFAhKNeQ= ; Message-ID: <20060717125218.74490.qmail@web31807.mail.mud.yahoo.com> Received: from [202.164.36.100] by web31807.mail.mud.yahoo.com via HTTP; Mon, 17 Jul 2006 05:52:18 PDT Date: Mon, 17 Jul 2006 05:52:18 -0700 (PDT) From: Harish Kumar To: autoconf@ietf.org MIME-Version: 1.0 X-Spam-Score: 3.2 (+++) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Subject: [Autoconf] (no subject) X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ad Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1142696538==" Errors-To: autoconf-bounces@ietf.org --===============1142696538== Content-Type: multipart/alternative; boundary="0-1472062979-1153140738=:74459" Content-Transfer-Encoding: 8bit --0-1472062979-1153140738=:74459 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit hi Any body please let me know any Simulator in which we can simulate different methods of AutoConfiguration..... thnx harish --------------------------------- Do you Yahoo!? Next-gen email? Have it all with the all-new Yahoo! Mail Beta. --0-1472062979-1153140738=:74459 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
hi
 
Any body please let me know any Simulator in which we can simulate different methods of AutoConfiguration.....
 
thnx
harish

Do you Yahoo!?
Next-gen email? Have it all with the all-new Yahoo! Mail Beta. --0-1472062979-1153140738=:74459-- --===============1142696538== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf --===============1142696538==-- From autoconf-bounces@ietf.org Mon Jul 24 06:17:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G4xV9-0005zU-4J; Mon, 24 Jul 2006 06:17:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G4xV7-0005zP-OF for autoconf@ietf.org; Mon, 24 Jul 2006 06:17:25 -0400 Received: from nez-perce.inria.fr ([192.93.2.78]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G4xV6-0000Kp-Gr for autoconf@ietf.org; Mon, 24 Jul 2006 06:17:25 -0400 Received: from [192.168.1.3] (Va19b.v.pppool.de [89.57.161.155]) (authenticated bits=0) by nez-perce.inria.fr (8.13.6/8.13.6) with ESMTP id k6OAHIbc015679 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 24 Jul 2006 12:17:20 +0200 Message-ID: <44C49D7F.8060403@inria.fr> Date: Mon, 24 Jul 2006 12:14:23 +0200 From: Emmanuel Baccelli User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: autoconf@ietf.org Content-Type: multipart/mixed; boundary="------------060600030601080801090805" X-j-chkmail-Score: MSGID : 44C49E2F.000 on nez-perce : j-chkmail score : XX : 5/20 0 X-Miltered: at nez-perce with ID 44C49E2F.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam-Score: 0.0 (/) X-Scan-Signature: a60b9377a676a0ce7ebd0e0cef6ba8d6 Subject: [Autoconf] Problem Statement draft X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ad Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: autoconf-bounces@ietf.org This is a multi-part message in MIME format. --------------060600030601080801090805 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi all, The problem statement draft-baccelli-autoconf-problem-statement-00 has been submitted as included in attachement. Now is the time to read it and to provide your comments! Regards, Emmanuel --------------060600030601080801090805 Content-Type: text/plain; name="draft-baccelli-autoconf-problem-statement-00.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="draft-baccelli-autoconf-problem-statement-00.txt" MANET Autoconfiguration (Autoconf) E. Baccelli (Ed.) Internet-Draft INRIA Expires: January 25, 2007 K. Mase Niigata University S. Ruffino Telecom Italia S. Singh Samsung July 24, 2006 Address Autoconfiguration for MANET: Terminology and Problem Statement draft-baccelli-autoconf-statement-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on January 25, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Abstract Traditional dynamic IP address assignment solutions are not adapted to mobile ad hoc networks. This document elaborates on this problem, states the need for a new solution, and provides guidelines and Baccelli (Ed.), et al. Expires January 25, 2007 [Page 1] Internet-Draft MANET Autoconf Problem Statement July 2006 requirements for its design. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Overview of the Problem . . . . . . . . . . . . . . . . . 3 1.2. Specification of Requirements . . . . . . . . . . . . . . 3 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 5 2.1. Standalone MANET . . . . . . . . . . . . . . . . . . . . . 5 2.2. MANET Connected to an External Network . . . . . . . . . . 5 3. Deployment Scenarios Selection . . . . . . . . . . . . . . . . 6 4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 7 4.1. Specific Broacast Characteristics . . . . . . . . . . . . 7 4.2. Dynamic Topology . . . . . . . . . . . . . . . . . . . . . 7 4.3. Locally Unique Addresses, Globally Unique Addresses . . . 8 4.4. Multiple Gateways . . . . . . . . . . . . . . . . . . . . 8 5. Solution Guidelines . . . . . . . . . . . . . . . . . . . . . 9 5.1. Solution Model . . . . . . . . . . . . . . . . . . . . . . 9 5.2. General Requirements . . . . . . . . . . . . . . . . . . . 11 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 Intellectual Property and Copyright Statements . . . . . . . . . . 16 Baccelli (Ed.), et al. Expires January 25, 2007 [Page 2] Internet-Draft MANET Autoconf Problem Statement July 2006 1. Introduction Mobile ad hoc networks (i.e. MANETs, refer to RFC 2501) are networks composed of mobile devices also called nodes, that communicate over wireless media, and which dynamically self-organize multi-hop communication between each other. Each node may generate and forwards control traffic, and forward user traffic (thus potentially behaving like a router). Each node may also use the network by generating user traffic (and thus potentially behaving like a host). Some mobile ad hoc network may function regardless of the availability of a connection to the infrastructure (i.e. the Internet). More precisely, a MANET may either be disconnected from the fixed IP infrastructure (then called a standalone MANET), or connected to the fixed IP infrastructure (through one or more gateways). 1.1. Overview of the Problem Prior to participation in IP communication, each node's interface on a MANET that does not beneficiate from appropriate static configuration needs to be automatically assigned at least one IP address, that SHOULD be unique (i) locally, for communication inside the MANET, or (ii) globally, for communication accross the Internet. However, standard automatic IP address assignment solutions do not work "as-is" on MANETs due to ad hoc networks' characteristics, and new mechanisms are therefore needed. The goal of this document is to detail these problems, and to provide guidelines and requirements for solutions to be designed. 1.2. Specification of Requirements In this document, several words are used to signify the requirements of the specification. These words are often capitalized. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 1.3. Terminology In addition to the specific wording described in the previous section, this document uses the following terminology : MANET Node - A device with one or more wireless interfaces and associated IP address(es) which is used by the MANET routing protocol in use. Baccelli (Ed.), et al. Expires January 25, 2007 [Page 3] Internet-Draft MANET Autoconf Problem Statement July 2006 Local address - An IP address configured on a MANET node and valid for communication among MANET nodes that are part of the same ad hoc network. Nodes MUST NOT communicate with other nodes outside the MANET using this address. Global address - An IP address configured on a MANET node and valid for communication with nodes in the Internet, as well as internally within the MANET. Internet gateway - An edge node connected to MANET as well as to the Internet and capable of providing bidirectional connectivity between the Internet and MANET . These gateways are expected to provide topologically correct IPv6 prefixes. Internet gateways mostly run ad hoc routing protocols, but they can also run infrastructure network protocols (e.g. OSPF). Duplicate Address Detection (DAD) - The process by which a node confirms the uniqueness of an address it wishes to configure or has already configured. A node already equipped with an IP address participates in DAD in order to protect its IP address from being used by another node. Pre-service MANET-DAD - The process verifying that a tentative new IP address assignment will not create a conflict with other MANET devices. In-service MANET-DAD - The process of continuously checking that an IP address already in use has not become duplicated in the MANET. Standalone MANET - An independent ad hoc network which has no connectivity, either direct of via Internet gateways, to any other IP networks such as the Internet. Network merger - The process by which two or more ad hoc networks, previously disjoint, get connected. In general, network merger happens as a consequence of node mobility and/or wireless link environment. Network partitioning - The process by which an ad hoc network splits into two or more disconnected ad hoc networks. In general, this proccess happens as a consequence of node mobility and/or wireless link environment. Baccelli (Ed.), et al. Expires January 25, 2007 [Page 4] Internet-Draft MANET Autoconf Problem Statement July 2006 2. Deployment Scenarios Automatic configuration of IP addresses of MANET nodes (AUTOCONF) may be necessary in a number of deployment scenarios. In this section, we outline the use cases that concern and reveal problems related to the Autoconfiguration of MANET nodes. 2.1. Standalone MANET In this kind of scenario, the MANET is not connected to any external network: all traffic is generated by MANET nodes and destined to nodes in the same MANET. Nodes joining a standalone MANET can either (i) have no previous configuration, or (ii) already have one or more MANET local and/or global addresses, statically or dynamically pre- configured, to be used for IP communication. Due to partitions and mergers, standalone MANETs can often be composed with both kinds of nodes. Typical applications of this scenario include private or temporary networks, set-up in areas where neither wireless coverage nor network infrastructure exist (e.g. emergency networks for disaster recovery, or conference-room networks). 2.2. MANET Connected to an External Network In this scenario, the MANET is connected to an external network, (e.g. the Internet), by means of one or more gateways. MANET nodes can generate traffic directed to remote hosts accross the Internet. As in Section 2.1, nodes in a connected MANET could either (i) already own a global IP address, which could be used for external traffic, or (ii) have no previous configuration. Examples include public wireless networks of scattered fixed WLAN Access Points participating in the MANET of mobile users, and acting as Internet Gateways. Another example of such a scenario is the coverage extension of a fixed wide-area wireless network, where one or more mobile nodes in the MANET are connected to the Internet through technologies such as UMTS or WiMAX. Baccelli (Ed.), et al. Expires January 25, 2007 [Page 5] Internet-Draft MANET Autoconf Problem Statement July 2006 3. Deployment Scenarios Selection TBD Baccelli (Ed.), et al. Expires January 25, 2007 [Page 6] Internet-Draft MANET Autoconf Problem Statement July 2006 4. Problem Statement MANET nodes that do not beneficiate from appropriate static IP address configuration may need to automatically configure at least one unique local IPv6 address, in order to enable IP communication within the MANET. To communicate with hosts across the Internet, configuration mechanism may also need to provide one or more global IPv6 addresses. Internet Gateways typically manage topologically correct IPv6 prefixes that can be used to configure global address. They are usually managed by an administrative entity (i.e. a network operator or service provider), however they can also be opportunistic and unmanaged. Internet Gateways are typically fixed, but may also be mobile. Their presence in the MANET may be intermittent (the number of gateways may vary), and thus the availability of an Internet connection in the MANET may also be intermittent. 4.1. Specific Broacast Characteristics Traditional dynamic IP address assignment solutions, such as RFC 2462, 3315 and 2461, do not work as-is in MANETs due to these networks' unique properties, as elaborated in the following sections. These solutions assume that a broadcast direclty reaches every device on the network, whereas it is generally not the case in MANETs. Indeed, some nodes in the MANET will typically be indirectly connected to the source of the broadcast, through several intermediate peer mobile ad hoc nodes. In that respect, it is worth noting that IPv6 does not currently specify an address scope that is applicable for MANET scope. 4.2. Dynamic Topology A significant proportion of the nodes in the MANET may be mobile with wireless interface(s), leading to ever changing neighbors and neighbor sets for most MANET nodes. Therefore network topology may change rather dynamically compared to traditional networks. In particular, phenomena such as MANET paritionning (i.e. a MANET separating into two or more disconnected MANETs) and MANET merging (i.e. two or more disconnected MANETs suddenly being connected) are potential events that may greatly disrupt the uniqueness of IP addresses in use. For instance, a standalone MANET A may feature nodes that use IP addresses that are locally unique within MANET A, but this uniqueness is not guaranteed anymore if MANET A merges at some point with another MANET B. Baccelli (Ed.), et al. Expires January 25, 2007 [Page 7] Internet-Draft MANET Autoconf Problem Statement July 2006 4.3. Locally Unique Addresses, Globally Unique Addresses Moreover, even if a node uses an IP address that is locally unique within its MANET, this address may not be fit for Internet communication. Indeed, in order to be able to communicate with outside the MANET (i.e. the Internet), a node must use an IP address that must be both globally unique, as well as topologically correct, reflecting it's current location. 4.4. Multiple Gateways In the case where multiple gateways are available in the MANET, specific problems arise. One problem is the way in which global prefixes are managed within the MANET. If *one* prefix is used for the whole MANET, partitioning of the MANET may invalid routes in the Internet towards MANET nodes. On the other hand, use of *multiple* network prefixes guarantees traffic is unambiguously routed towards the gateway owning one particular prefix, but asymmetry in the nodes' choice of ingress/egress gateway can lead to non-optimal paths followed by inbound/outbound data traffic. Additional problems come from issues with current IPv6 specifications. For example, the strict application of RFC2462 may lead to check every IPv6 unicast for uniqueness : in a multiple-gateway / multiple-prefixes MANET, this could bring to a large amount of control signalling, due to frequent reconfiguration. Baccelli (Ed.), et al. Expires January 25, 2007 [Page 8] Internet-Draft MANET Autoconf Problem Statement July 2006 5. Solution Guidelines 5.1. Solution Model This section proposes a high-level conceptual view of generic MANET autoconfiguration. The different phases of the autoconfiguration process are abstracted by means of a diagram (see Fig. 1), that may serve as conceptual framework of the issues that nodes have to solve. However, note that solutions do not have to follow this framework. The purpose of this framework is merely to derive a checklist of autoconfiguration functionalities, in order to build solutions taylored for different scenarios. Basically, with regards to IP addressing, a device may find itself into the 3 different phases depicted in Fig 1. : The NO ADDRESS phase - In this phase a device does not have its own IP address. It does not participate in user data forwarding. If a routing protocol is in use in the MANET, the node does not process, generate or forward routing control messages generated by other devices. At some point, the node may generate a (tentative) address by means of a given address generation method. When it generates its address, the device should enter the ADVERTISING phase. The ADVERTISING phase - In this phase, a device does not participate in user data forwarding. If a routing protocol in in use in the MANET, the node does not forward routing control messages generated by other nodes. In this phase, the node may perform pre-service MANET-DAD by means of a given mechanism (for instance by using specific control signalling, that could be embeded in the ad hoc routing signalling in use). If pre-service MANET-DAD is used, and the device detects that its tentative address creates a conflict with other MANET devices, it should re-enters the NO ADDRESS phase. Else, if pre-service MANET-DAD completes without any address conflict being detected, or if pre-service DAD is not required, the node should enter the NORMAL phase. Note that if pre-service MANET-DAD is used, the ADVERTISING phase may have incremental substates in order to reduce the risks of routing table pollution with duplicate addresses. In the LOCAL ADVERTISEMENT phase, pre-service MANET-DAD control signalling reaches only a TTL-limited neighborhood, whereas in the GLOBAL ADVERTISEMENT phase, pre-service MANET-DAD control signalling reaches the whole MANET. Baccelli (Ed.), et al. Expires January 25, 2007 [Page 9] Internet-Draft MANET Autoconf Problem Statement July 2006 The NORMAL phase - In this phase, the device participates in IP communication normally. If a routing protocol is in use in the MANET, the device may process, generate or forward routing control messages as specified by the routing protocol in use, and may generate or forward user data. A device in this phase may perform in-service MANET-DAD by means of a given mechanism (for instance by using specific control messages that can be embeded in the routing control messages). If in-service MANET-DAD is used and if the device detects an address conflict that forces it to acquire a new address to resolve this conflict, the node should return to the NO ADDRESS phase. Note that the phases in this model are cyclic, and that a node can pop up in the MANET in any phase. For instance, a node that beneficiated from appropriate static preconfiguration may start directly in the NORMAL phase. (Address generation) (In-service MANET-DAD) +--------------+ Duplicate address +--------------+ | NO ADDRESS | detected | NORMAL | +----------| phase |<-------------------| phase |<--+ | +--------------+ +--------------+ | | ^ | | | Duplicate address | |(Tentative) address | detected Address | | generated +--------+ checked | | | | | +--------------------------------------------------------+ | | | ADVERTISING phase | | | | | | | | +--------------+ +-------------+ | | | | | LOCAL AD. | | GLOBAL AD. | | | +--->| | phase |----------------->| phase | |---+ | +--------------+ +-------------+ | +--------------------------------------------------------+ (Pre-service MANET-DAD) Fig. 1 Generic autoconfiguration phases. This conceptual framework reveals three specific potential aspects of the problem, which solutions MUST be designed take into account: - The (tentative) IP addresses generation and assignment aspect. - The pre-service DAD aspect, to somehow ensure a reasonalble belief in the fact that an address about to be assigned does not Baccelli (Ed.), et al. Expires January 25, 2007 [Page 10] Internet-Draft MANET Autoconf Problem Statement July 2006 create a conflict. - The in-service DAD aspect, to deal with conflicts that are detected between already assigned addresses. 5.2. General Requirements A solution for IP address autoconfiguration for MANETs is needed for mobile ad hoc node to acquire a correct IP address prior to their full participation in the mobile ad hoc routing protocol(s) in use. Such a solution must address the distributed, multi-hop nature of mobile ad hoc networks. Autoconfiguration mechanisms must be able to follow changes in the MANET and react to gateway connectivity loss, or to the event of new gateways becoming available, (re)configuring addresses accordingly. A solution must achieve its task with minimal overhead, due to scarse bandwidth, and minimal delay, due to the dynamicity of the topology. Baccelli (Ed.), et al. Expires January 25, 2007 [Page 11] Internet-Draft MANET Autoconf Problem Statement July 2006 6. Security Considerations Address configuration in MANET could be prone to security attacks, as in other type of IPv6 networks. Security threats to IPv6 neighbor discovery are discussed in RFC 3756: in particular, analysis includes trust model and threats for a specific ad hoc network scenario, where all the nodes share a common link (i.e. they are one hop away from each other, full-meshed connectivity is available). Although the document does not explicitly address MANETs, where nodes can be multiple hop away from each other, the trust model it provides could be valid also in the context of AUTOCONF. It is also worth noting that, in case of MANET connected to the Internet, other threats defined in RFC3756 could apply here, e.g. attacks involving routers and DoS attacks on Duplicate Address Detection procedures. Analysis has to be further extended to include threats, specific to multi-hop networks and, in particular, related to the address configuration process: security issues of routing protocol operations (e.g. how to secure routing protocol messages) are out of scope of AUTOCONF WG. Baccelli (Ed.), et al. Expires January 25, 2007 [Page 12] Internet-Draft MANET Autoconf Problem Statement July 2006 7. IANA Considerations This document does currently not specify IANA considerations. 8. References [1] Macker, J. and S. Corson, "MANET Routing Protocol Performance Issues and Evaluation Considerations", RFC 2501, January 1999. [2] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IPv6", RFC 2461, December 1998. [3] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6", RFC 3315, July 2003. [4] Narten, T. and S. Thomson, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998. Baccelli (Ed.), et al. Expires January 25, 2007 [Page 13] Internet-Draft MANET Autoconf Problem Statement July 2006 Contributors This document is the result of joint efforts, including those of the following contributers, listed in alphabetical order: C. Adjih (INRIA), T. Clausen (Ecole Polytechnique), C. Perkins (Nokia), P. Ruiz (University of Murcia), P. Stupar (Telecom Italia), D. Thaler (Microsoft). Baccelli (Ed.), et al. Expires January 25, 2007 [Page 14] Internet-Draft MANET Autoconf Problem Statement July 2006 Authors' Addresses Emmanuel Baccelli INRIA Phone: +33 1 69 33 55 11 Email: Emmanuel.Baccelli@inria.fr Kenichi Mase Niigata University Phone: +81 25 262 7446 Email: Mase@ie.niigata-u.ac.jp Simone Ruffino Telecom Italia Phone: +39 011 228 7566 Email: Simone.Ruffino@telecomitalia.it Shubhranshu Singh Samsung Phone: +82 31 280 9569 Email: Shubranshu@gmail.com Baccelli (Ed.), et al. Expires January 25, 2007 [Page 15] Internet-Draft MANET Autoconf Problem Statement July 2006 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Baccelli (Ed.), et al. Expires January 25, 2007 [Page 16] --------------060600030601080801090805 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf --------------060600030601080801090805-- From autoconf-bounces@ietf.org Mon Jul 24 07:21:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G4yVO-0008Mi-UY; Mon, 24 Jul 2006 07:21:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G4yVO-0008Mc-5q for autoconf@ietf.org; Mon, 24 Jul 2006 07:21:46 -0400 Received: from sniper.icu.ac.kr ([210.107.128.51]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G4yVM-0005wH-9D for autoconf@ietf.org; Mon, 24 Jul 2006 07:21:46 -0400 Received: (snipe 2586 invoked by uid 0); 24 Jul 2006 20:21:46 +0900 Received: from newcat@icu.ac.kr with Spamsniper 2.96.00 (Processed in 0.020425 secs); Received: from unknown (HELO ?220.69.185.36?) (Zu??own@220.69.185.36) by unknown with SMTP; 24 Jul 2006 20:21:46 +0900 X-RCPTTO: Emmanuel.Baccelli@inria.fr, autoconf@ietf.org, may@icu.ac.kr Message-ID: <44C4AD3D.9070301@icu.ac.kr> Date: Mon, 24 Jul 2006 20:21:33 +0900 From: Yangwoo Ko User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Emmanuel Baccelli Subject: Re: [Autoconf] Problem Statement draft References: <44C49D7F.8060403@inria.fr> In-Reply-To: <44C49D7F.8060403@inria.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: autoconf@ietf.org, may@icu.ac.kr X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ad Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: autoconf-bounces@ietf.org Dear Emmanuel Baccelli and others, Currently we are working on the issue of interconnection of multiple MANETs. Your document only deals with the case where two MANETs "merge" if they meet. But there are some reasons (e.g. management, security or whatever) that restrict the merge. Even under such a restriction, two MANETs can be interconnected through some nodes. (I try to avoid the word "gateway" because it is commonly used for external (or Internet) gateways.) These interconnection nodes will work like a gateway with enhanced function that meets the "some reasons" mentioned above. The interconnection node can serve as an external gateway if external connection of either (but not both) MANET is broken. Since two MANETs are independently configured standalone networks, interconnection of them should not incur address allocation or assignment. However, interconnection related information (e.g. gateway address to the other MANET) should be distributed in some way. I am not so sure whether this scenario can be decomposed into a combination of standalone MANET and MANET with external connection(s) defined in your document. Regards Emmanuel Baccelli wrote: > Hi all, > > The problem statement draft-baccelli-autoconf-problem-statement-00 has > been submitted as included in attachement. Now is the time to read it > and to provide your comments! > > Regards, > Emmanuel > > (snip) _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Mon Jul 24 17:58:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G58RX-0003fU-Et; Mon, 24 Jul 2006 17:58:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G58RU-0003bG-Kz for autoconf@ietf.org; Mon, 24 Jul 2006 17:58:24 -0400 Received: from ug-out-1314.google.com ([66.249.92.174]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G58RR-0004y0-88 for autoconf@ietf.org; Mon, 24 Jul 2006 17:58:24 -0400 Received: by ug-out-1314.google.com with SMTP id m2so2576856uge for ; Mon, 24 Jul 2006 14:58:20 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=n51jeCcjGMYPzgH8y2gHkpy4ekdMLtzKzNV4OYXwuTRJ6PM1HKeLAgLzj6LyjesZuFuhJ0yC0JBypiW1r/4EEHiFioFTjjxU94sB2lg8kYydY7ZXW7U5Jv1lPXgq98km63Z7nlrrs2zCaGBkOxgxS3Am39fSD76SJA7Q59EIQ6s= Received: by 10.67.29.12 with SMTP id g12mr4028743ugj; Mon, 24 Jul 2006 14:58:20 -0700 (PDT) Received: by 10.66.224.14 with HTTP; Mon, 24 Jul 2006 14:58:20 -0700 (PDT) Message-ID: <374005f30607241458o5dc932ack48945384b224e22@mail.gmail.com> Date: Mon, 24 Jul 2006 14:58:20 -0700 From: "Ian Chakeres" To: manet , autoconf@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: Subject: [Autoconf] Fwd: I-D ACTION:draft-chakeres-manet-iana-00.txt X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ad Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: autoconf-bounces@ietf.org Here is the draft I promised during MANET IETF 66 discussing MANET IANA considerations. It is meant to aid in discussing IANA assignments for MANET. I've broken down the different components into different sections. I think we are all in agreement in the immediate need for LL (link-local) MANET Routers multicast group. Less agreement, but definitely useful is a MANET UDP port. More discussion is needed for Scoped MANET Routers and any other scoped "host/node" multicast groups. Please comment on these. I would especially like some feedback from AUTOCONF people. Please email your comments to the lists or to me directly. Thanks. Ian Chakeres BTW: A document discussing MANET architecture should be coming out this week. Once it is posted I'll send an email also. The arch document may help in discussing the different IANA assignments. ---------- Forwarded message ---------- From: Internet-Drafts@ietf.org Date: Jul 24, 2006 12:50 PM Subject: I-D ACTION:draft-chakeres-manet-iana-00.txt To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Discussing MANET IANA Needs Author(s) : I. Chakeres Filename : draft-chakeres-manet-iana-00.txt Pages : 9 Date : 2006-7-24 This document enumerates several possible IANA assignments for MANET protocols. It is meant to aid and stimulate discussion on this topic. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-chakeres-manet-iana-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-chakeres-manet-iana-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-chakeres-manet-iana-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Tue Jul 25 04:42:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5IV2-0000BG-FL; Tue, 25 Jul 2006 04:42:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5IV1-000087-9A; Tue, 25 Jul 2006 04:42:43 -0400 Received: from balu1.urz.unibas.ch ([131.152.1.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5IUz-0008Tr-RZ; Tue, 25 Jul 2006 04:42:43 -0400 Received: from [131.152.55.200] (baobab.cs.unibas.ch [131.152.55.200]) by balu1.urz.unibas.ch (8.13.7/8.13.7) with ESMTP id k6P8ge1W002610; Tue, 25 Jul 2006 10:42:40 +0200 Message-ID: <44C5D9B3.7040006@unibas.ch> Date: Tue, 25 Jul 2006 10:43:31 +0200 From: Christophe Jelger Organization: University of Basel User-Agent: Debian Thunderbird 1.0.7 (X11/20051017) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ian Chakeres Subject: Re: [Autoconf] Fwd: I-D ACTION:draft-chakeres-manet-iana-00.txt References: <374005f30607241458o5dc932ack48945384b224e22@mail.gmail.com> In-Reply-To: <374005f30607241458o5dc932ack48945384b224e22@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SMTP-Vilter-Version: 1.3.1 X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: autoconf@ietf.org, manet X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ad Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: autoconf-bounces@ietf.org Ian/all, I didn't attend the last ietf meeting so I don't know how this topic was discussed but I remember we had a similar discussion in March 2005 and the consensus (March 17th 2005) was that there should be a multicast address for each MANET routing protocol as done with existing routing protocols (e.g. ff02::5 and ff02::6 for OSPF, ff02::9 for RIP, ff02::d for PIM). One argument was to be consistent with current practices, and another argument was that we already have ff02::1 (all nodes) and ff02::2 (all routers) so it was not clear why we should have an extra "all_manet_routers" address (especially if we have a multicast address for each manet routing protocol). Also having a different multicast address for each manet routing protocol prevents a node that does not run a given routing protocol to process packets associated to it: it will not even receive them at the MAC layer. So I'm rather in favor of having for example ff02::DYMO and ff02::OLSRv2, and if a larger scope is required we can instead have ff0x::DYMO and ff0x::OLSRv2. This implies that there would not be an all_manet_routers address. Now for address autoconfiguration, there could also be a dedicated multicast address ff0x::MANET-AUTOCONF. regards, Christophe PS: note that the same reasoning applies to IPv4 Ian Chakeres wrote: > Here is the draft I promised during MANET IETF 66 discussing MANET > IANA considerations. It is meant to aid in discussing IANA assignments > for MANET. I've broken down the different components into different > sections. > > I think we are all in agreement in the immediate need for LL > (link-local) MANET Routers multicast group. > > Less agreement, but definitely useful is a MANET UDP port. > > More discussion is needed for Scoped MANET Routers and any other > scoped "host/node" multicast groups. Please comment on these. I would > especially like some feedback from AUTOCONF people. > > Please email your comments to the lists or to me directly. > > Thanks. > Ian Chakeres > > BTW: A document discussing MANET architecture should be coming out > this week. Once it is posted I'll send an email also. The arch > document may help in discussing the different IANA assignments. > _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Tue Jul 25 08:34:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5M74-0004MW-V2; Tue, 25 Jul 2006 08:34:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G4gWD-0003LX-BL for autoconf@ietf.org; Sun, 23 Jul 2006 12:09:25 -0400 Received: from ug-out-1314.google.com ([66.249.92.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G4gWC-00064f-1l for autoconf@ietf.org; Sun, 23 Jul 2006 12:09:25 -0400 Received: by ug-out-1314.google.com with SMTP id m2so2022599uge for ; Sun, 23 Jul 2006 09:09:23 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=utEIzqkSLqgeLsnijh4Kz8xsDOW7QTeIumH0l0dLRiy9MaS5gg5fGQdLQSXqXOu+W45RGzp1nnjYKRx3k0TC1XRmr5ZE46kJbY/GSun3A9Lwe1WgiC0CDpLaRj/TcS1aweZDPiknmw3iGVdSAi/FlhahJRZ4/BZ2V4cyrnSYr5Q= Received: by 10.66.220.17 with SMTP id s17mr2656918ugg; Sun, 23 Jul 2006 09:09:23 -0700 (PDT) Received: by 10.66.219.8 with HTTP; Sun, 23 Jul 2006 09:09:23 -0700 (PDT) Message-ID: <992c2bb30607230909i40a5cb8am28e93d4052ad3d37@mail.gmail.com> Date: Mon, 24 Jul 2006 00:09:23 +0800 From: "Luo Gang" To: autoconf MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 X-Mailman-Approved-At: Tue, 25 Jul 2006 08:34:14 -0400 Subject: [Autoconf] Where I can find the informational RFC wrt autoconf X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ad Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: autoconf-bounces@ietf.org autoconf, Hi, all, I am a newbie of this WG. According to the "Goals and Milestones"of the charter of autoconf, there are some informational RFC wrt autoconf should be submitted to IESG, such as, === Apr 2006 Submit 'MANET architecture' document to IESG for publication as an informational RFC May 2006 Submit 'terminology and problem statement' document to IESG for publication as an informational RFC === BUT I don't see any RFC in the same pages. Is there anybody can tell me where I can get them? Thanks in advance! Regards, -- Luo Gang _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Tue Jul 25 10:10:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5NcG-0007U7-R8; Tue, 25 Jul 2006 10:10:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5NcG-0007U1-82 for autoconf@ietf.org; Tue, 25 Jul 2006 10:10:32 -0400 Received: from mailout3.samsung.com ([203.254.224.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5NcD-0002sm-NO for autoconf@ietf.org; Tue, 25 Jul 2006 10:10:32 -0400 Received: from ep_mmp1 (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0J2Y00106Q1F9R@mailout3.samsung.com> for autoconf@ietf.org; Tue, 25 Jul 2006 23:10:27 +0900 (KST) Received: from Shubhranshu ([107.108.4.124]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0J2Y000LIQ1E1G@mmp1.samsung.com> for autoconf@ietf.org; Tue, 25 Jul 2006 23:10:27 +0900 (KST) Date: Tue, 25 Jul 2006 19:41:53 +0530 From: Shubhranshu Subject: Re: [Autoconf] Fwd: I-D ACTION:draft-chakeres-manet-iana-00.txt To: Christophe Jelger Message-id: <024e01c6aff4$4861ae40$7c046c6b@sisodomain.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Mailer: Microsoft Outlook Express 6.00.2900.2869 Content-type: text/plain; reply-type=response; charset=iso-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <374005f30607241458o5dc932ack48945384b224e22@mail.gmail.com> <44C5D9B3.7040006@unibas.ch> X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: autoconf@ietf.org X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ad Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: autoconf-bounces@ietf.org Hello Christophe, ----- Original Message ----- From: "Christophe Jelger" To: "Ian Chakeres" Cc: ; "manet" Sent: Tuesday, July 25, 2006 2:13 PM Subject: Re: [Autoconf] Fwd: I-D ACTION:draft-chakeres-manet-iana-00.txt > Ian/all, > > I didn't attend the last ietf meeting so I don't know how this topic was > discussed but I remember we had a similar discussion in March 2005 and the > consensus (March 17th 2005) was that there should be a multicast address > for each MANET routing protocol as done with existing routing protocols > (e.g. ff02::5 and ff02::6 for OSPF, ff02::9 for RIP, ff02::d for PIM). > > One argument was to be consistent with current practices, and another > argument was that we already have ff02::1 (all nodes) and ff02::2 (all > routers) so it was not clear why we should have an extra > "all_manet_routers" address (especially if we have a multicast address for > each manet routing protocol). Also having a different multicast address > for each manet routing protocol prevents a node that does not run a given > routing protocol to process packets associated to it: it will not even > receive them at the MAC layer. > > So I'm rather in favor of having for example ff02::DYMO and ff02::OLSRv2, > and if a larger scope is required we can instead have ff0x::DYMO and > ff0x::OLSRv2. This implies that there would not be an all_manet_routers > address. Now for address autoconfiguration, there could also be a > dedicated multicast address ff0x::MANET-AUTOCONF. I am yet to read the draft and to go through MANET ML discussions held during March 2005 but a quick question: Do you have any specific use case in mind that may require dedicated multicast address, something like "ff0x::MANET-AUTOCONF ? Also, it would be good to know others opinion on it. As far as I know, none of the proposed solutions for Autoconf has come-up with this requirement. Regards, Shubhranshu > > regards, > Christophe > > PS: note that the same reasoning applies to IPv4 > > Ian Chakeres wrote: >> Here is the draft I promised during MANET IETF 66 discussing MANET >> IANA considerations. It is meant to aid in discussing IANA assignments >> for MANET. I've broken down the different components into different >> sections. >> >> I think we are all in agreement in the immediate need for LL >> (link-local) MANET Routers multicast group. >> >> Less agreement, but definitely useful is a MANET UDP port. >> >> More discussion is needed for Scoped MANET Routers and any other >> scoped "host/node" multicast groups. Please comment on these. I would >> especially like some feedback from AUTOCONF people. >> >> Please email your comments to the lists or to me directly. >> >> Thanks. >> Ian Chakeres >> >> BTW: A document discussing MANET architecture should be coming out >> this week. Once it is posted I'll send an email also. The arch >> document may help in discussing the different IANA assignments. >> > > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www1.ietf.org/mailman/listinfo/autoconf > > _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Tue Jul 25 10:27:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5Nsf-0004t7-DZ; Tue, 25 Jul 2006 10:27:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5Nse-0004t2-5j for autoconf@ietf.org; Tue, 25 Jul 2006 10:27:28 -0400 Received: from s2.itd.nrl.navy.mil ([132.250.83.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5Nsc-0008Rx-UQ for autoconf@ietf.org; Tue, 25 Jul 2006 10:27:28 -0400 Received: from smtp.itd.nrl.navy.mil (smtp.itd.nrl.navy.mil [132.250.86.3]) by s2.itd.nrl.navy.mil (8.13.6+Sun/8.12.8) with SMTP id k6PEROJC012916 for ; Tue, 25 Jul 2006 10:27:24 -0400 (EDT) Received: (from SEXTANT [132.250.92.22]) by smtp.itd.nrl.navy.mil (SMSSMTP 4.1.12.43) with SMTP id M2006072510275812667 for ; Tue, 25 Jul 2006 10:27:58 -0400 From: "Joe Macker" To: "'autoconf'" Subject: RE: [Autoconf] Where I can find the informational RFC wrt autoconf Date: Tue, 25 Jul 2006 10:27:21 -0400 Message-ID: <006e01c6aff6$70e354c0$165cfa84@SEXTANT> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 In-Reply-To: <992c2bb30607230909i40a5cb8am28e93d4052ad3d37@mail.gmail.com> Thread-Index: Acav5ruEWuDf7i/jR26gRU4KqBDA1QADzrsw X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ad Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: autoconf-bounces@ietf.org A -00 architecture document should be out within the next week or so as mentioned at the meetings. This document was delayed to simplify it as briefed at the meeting. -joe _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Tue Jul 25 10:53:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5OHs-0007S4-Kj; Tue, 25 Jul 2006 10:53:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5OHq-0007RW-AW for autoconf@ietf.org; Tue, 25 Jul 2006 10:53:30 -0400 Received: from ug-out-1314.google.com ([66.249.92.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5OHo-000880-Vm for autoconf@ietf.org; Tue, 25 Jul 2006 10:53:30 -0400 Received: by ug-out-1314.google.com with SMTP id m2so2872604uge for ; Tue, 25 Jul 2006 07:53:28 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=RUU9tRT5M9S7v1LNgC40IRu478e/LD/79IO66TKnrw4Rkcbaxn8GSbgaJOxbEQcGD7bavXSTa/uOPRHUekKZrZrJr2Soz89OWxSQiIVVPkKpAWsaqfSnqGXmMDrJ+oP7wZt8E19nQQr5QP0OSK43IVnycWNfraSHbbZsGH4icSk= Received: by 10.67.101.8 with SMTP id d8mr4786701ugm; Tue, 25 Jul 2006 07:53:27 -0700 (PDT) Received: by 10.66.224.14 with HTTP; Tue, 25 Jul 2006 07:53:27 -0700 (PDT) Message-ID: <374005f30607250753n288fbd81lc1b834312f953a34@mail.gmail.com> Date: Tue, 25 Jul 2006 07:53:27 -0700 From: "Ian Chakeres" To: "Christophe Jelger" Subject: Re: [Autoconf] Fwd: I-D ACTION:draft-chakeres-manet-iana-00.txt In-Reply-To: <44C5D9B3.7040006@unibas.ch> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <374005f30607241458o5dc932ack48945384b224e22@mail.gmail.com> <44C5D9B3.7040006@unibas.ch> X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: autoconf@ietf.org, manet X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ad Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: autoconf-bounces@ietf.org Since March 2005, we've come a long way building common building blocks into MANET protocols. We now have a common packet/message format (PacketBB) and a common neighborhood discovery protocol (NHDP). In order to aggregate MANET messages we'd need to send these to the same Multicast group. This is the reasoning behind using a single multicast group; instead of one per protocol. Ian On 7/25/06, Christophe Jelger wrote: > Ian/all, > > I didn't attend the last ietf meeting so I don't know how this topic was > discussed but I remember we had a similar discussion in March 2005 and > the consensus (March 17th 2005) was that there should be a multicast > address for each MANET routing protocol as done with existing routing > protocols (e.g. ff02::5 and ff02::6 for OSPF, ff02::9 for RIP, ff02::d > for PIM). > > One argument was to be consistent with current practices, and another > argument was that we already have ff02::1 (all nodes) and ff02::2 (all > routers) so it was not clear why we should have an extra > "all_manet_routers" address (especially if we have a multicast address > for each manet routing protocol). Also having a different multicast > address for each manet routing protocol prevents a node that does not > run a given routing protocol to process packets associated to it: it > will not even receive them at the MAC layer. > > So I'm rather in favor of having for example ff02::DYMO and > ff02::OLSRv2, and if a larger scope is required we can instead have > ff0x::DYMO and ff0x::OLSRv2. This implies that there would not be an > all_manet_routers address. Now for address autoconfiguration, there > could also be a dedicated multicast address ff0x::MANET-AUTOCONF. > > regards, > Christophe > > PS: note that the same reasoning applies to IPv4 > > Ian Chakeres wrote: > > Here is the draft I promised during MANET IETF 66 discussing MANET > > IANA considerations. It is meant to aid in discussing IANA assignments > > for MANET. I've broken down the different components into different > > sections. > > > > I think we are all in agreement in the immediate need for LL > > (link-local) MANET Routers multicast group. > > > > Less agreement, but definitely useful is a MANET UDP port. > > > > More discussion is needed for Scoped MANET Routers and any other > > scoped "host/node" multicast groups. Please comment on these. I would > > especially like some feedback from AUTOCONF people. > > > > Please email your comments to the lists or to me directly. > > > > Thanks. > > Ian Chakeres > > > > BTW: A document discussing MANET architecture should be coming out > > this week. Once it is posted I'll send an email also. The arch > > document may help in discussing the different IANA assignments. > > > _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Tue Jul 25 11:01:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5OPf-0001f5-An; Tue, 25 Jul 2006 11:01:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5OPe-0001cq-Lh for autoconf@ietf.org; Tue, 25 Jul 2006 11:01:34 -0400 Received: from balu1.urz.unibas.ch ([131.152.1.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5OPc-0003zE-8C for autoconf@ietf.org; Tue, 25 Jul 2006 11:01:34 -0400 Received: from [131.152.55.200] (baobab.cs.unibas.ch [131.152.55.200]) by balu1.urz.unibas.ch (8.13.7/8.13.7) with ESMTP id k6PF1Ti0022364; Tue, 25 Jul 2006 17:01:29 +0200 Message-ID: <44C6327B.9090003@unibas.ch> Date: Tue, 25 Jul 2006 17:02:19 +0200 From: Christophe Jelger Organization: University of Basel User-Agent: Debian Thunderbird 1.0.7 (X11/20051017) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Shubhranshu Subject: Re: [Autoconf] Fwd: I-D ACTION:draft-chakeres-manet-iana-00.txt References: <374005f30607241458o5dc932ack48945384b224e22@mail.gmail.com> <44C5D9B3.7040006@unibas.ch> <024e01c6aff4$4861ae40$7c046c6b@sisodomain.com> In-Reply-To: <024e01c6aff4$4861ae40$7c046c6b@sisodomain.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SMTP-Vilter-Version: 1.3.1 X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: autoconf@ietf.org X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ad Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: autoconf-bounces@ietf.org Hello Shubhranshu, The (simple) idea is that a distributed address assignment scheme or rather an address collision resolution protocol could use something like ff0x::MANET-AUTOCONF. Note that one could also use the all_nodes address ff02::1 and a dedicated port number but this means that "non-interested" nodes will also have to process the packets. Using ff0x::MANET-AUTOCONF is more selective than sending to "everybody that listens". Regarding your comment on existing proposals, it's clearly not a requirement but rather an optimization. Note that for both routing and address configuration this is exactly what is currently being done (there are specific multicast addresses for OSPF, RIP, PIM, MLDv2, DHCP, mDNS). regards, Christophe Shubhranshu wrote: > Hello Christophe, > > I am yet to read the draft and to go through MANET ML discussions held > during March 2005 but > a quick question: Do you have any specific use case in mind that may > require dedicated > multicast address, something like "ff0x::MANET-AUTOCONF ? > > Also, it would be good to know others opinion on it. As far as I know, > none of the proposed > solutions for Autoconf has come-up with this requirement. > > Regards, > Shubhranshu > _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Tue Jul 25 11:36:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5OxL-00059u-9W; Tue, 25 Jul 2006 11:36:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5OxJ-00056b-J6; Tue, 25 Jul 2006 11:36:21 -0400 Received: from balu1.urz.unibas.ch ([131.152.1.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5OxI-0004Q2-3P; Tue, 25 Jul 2006 11:36:21 -0400 Received: from [131.152.55.200] (baobab.cs.unibas.ch [131.152.55.200]) by balu1.urz.unibas.ch (8.13.7/8.13.7) with ESMTP id k6PFaHK0026124; Tue, 25 Jul 2006 17:36:17 +0200 Message-ID: <44C63AA4.4060907@unibas.ch> Date: Tue, 25 Jul 2006 17:37:08 +0200 From: Christophe Jelger Organization: University of Basel User-Agent: Debian Thunderbird 1.0.7 (X11/20051017) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ian Chakeres Subject: Re: [Autoconf] Fwd: I-D ACTION:draft-chakeres-manet-iana-00.txt References: <374005f30607241458o5dc932ack48945384b224e22@mail.gmail.com> <44C5D9B3.7040006@unibas.ch> <374005f30607250753n288fbd81lc1b834312f953a34@mail.gmail.com> In-Reply-To: <374005f30607250753n288fbd81lc1b834312f953a34@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SMTP-Vilter-Version: 1.3.1 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Cc: autoconf@ietf.org, manet X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ad Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: autoconf-bounces@ietf.org Yes that's a good point but having a common packet format is not in contradiction with having a dedicated mcast addr per routing protocol. I understand that having a unique mcast addr makes it easy to aggregate routing information but while I understand this is useful for a given protocol, I cannot see why it's useful among different protocols. I mean, carrying routing messages all over the MANET is one thing, but this makes little sense if intermediate nodes are not ready to partipate in packet forwarding. For example in the following scenario A(DYMO) --- B(OLSRv2) --- C(DYMO) if node C receives DYMO messages from A (messages sent by A are aggregated with the messages sent by B) and vice versa, still node B does not process DYMO messages and hence would not create forwarding states. Communication between A and C is not possible. With dedicated mcast addresses, C and A don't see eachother at the DYMO level but anyway they cannot communicate so it makes perfect sense to me. As I said in an autoconf-only email, having different mcast addresses is an optimization because it introduces some low-level filtering at the MAC layer. For example NHDP introduces the ALL-MANET-NEIGHBORS address: in your view would this be different than the ALL-MANET-ROUTERS address? Personaly I don't see any negative reasons for not having an mcast address per protocol (DYMO, OLSRv2, NHDP). Note that I'm not against your scheme, I just think it's better to have dedicated mcast addresses. regards, Christophe Ian Chakeres wrote: > Since March 2005, we've come a long way building common building > blocks into MANET protocols. We now have a common packet/message > format (PacketBB) and a common neighborhood discovery protocol (NHDP). > In order to aggregate MANET messages we'd need to send these to the > same Multicast group. This is the reasoning behind using a single > multicast group; instead of one per protocol. > > Ian > > On 7/25/06, Christophe Jelger wrote: > >> Ian/all, >> >> I didn't attend the last ietf meeting so I don't know how this topic was >> discussed but I remember we had a similar discussion in March 2005 and >> the consensus (March 17th 2005) was that there should be a multicast >> address for each MANET routing protocol as done with existing routing >> protocols (e.g. ff02::5 and ff02::6 for OSPF, ff02::9 for RIP, ff02::d >> for PIM). >> >> One argument was to be consistent with current practices, and another >> argument was that we already have ff02::1 (all nodes) and ff02::2 (all >> routers) so it was not clear why we should have an extra >> "all_manet_routers" address (especially if we have a multicast address >> for each manet routing protocol). Also having a different multicast >> address for each manet routing protocol prevents a node that does not >> run a given routing protocol to process packets associated to it: it >> will not even receive them at the MAC layer. >> >> So I'm rather in favor of having for example ff02::DYMO and >> ff02::OLSRv2, and if a larger scope is required we can instead have >> ff0x::DYMO and ff0x::OLSRv2. This implies that there would not be an >> all_manet_routers address. Now for address autoconfiguration, there >> could also be a dedicated multicast address ff0x::MANET-AUTOCONF. >> >> regards, >> Christophe >> >> PS: note that the same reasoning applies to IPv4 >> >> Ian Chakeres wrote: >> > Here is the draft I promised during MANET IETF 66 discussing MANET >> > IANA considerations. It is meant to aid in discussing IANA assignments >> > for MANET. I've broken down the different components into different >> > sections. >> > >> > I think we are all in agreement in the immediate need for LL >> > (link-local) MANET Routers multicast group. >> > >> > Less agreement, but definitely useful is a MANET UDP port. >> > >> > More discussion is needed for Scoped MANET Routers and any other >> > scoped "host/node" multicast groups. Please comment on these. I would >> > especially like some feedback from AUTOCONF people. >> > >> > Please email your comments to the lists or to me directly. >> > >> > Thanks. >> > Ian Chakeres >> > >> > BTW: A document discussing MANET architecture should be coming out >> > this week. Once it is posted I'll send an email also. The arch >> > document may help in discussing the different IANA assignments. >> > >> > _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Tue Jul 25 12:38:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5Pvr-00075K-Bn; Tue, 25 Jul 2006 12:38:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5Pvq-00075C-Kn for autoconf@ietf.org; Tue, 25 Jul 2006 12:38:54 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5NkJ-0004dP-5r for autoconf@ietf.org; Tue, 25 Jul 2006 10:18:51 -0400 Received: from mailout1.samsung.com ([203.254.224.24]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G5NeA-0006Zq-6n for autoconf@ietf.org; Tue, 25 Jul 2006 10:12:32 -0400 Received: from ep_mmp2 (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0J2Y00EXKQ4OS3@mailout1.samsung.com> for autoconf@ietf.org; Tue, 25 Jul 2006 23:12:25 +0900 (KST) Received: from Shubhranshu ([107.108.4.124]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0J2Y006KSQ4NGY@mmp2.samsung.com> for autoconf@ietf.org; Tue, 25 Jul 2006 23:12:24 +0900 (KST) Date: Tue, 25 Jul 2006 19:43:50 +0530 From: Shubhranshu Subject: Re: [Autoconf] Where I can find the informational RFC wrt autoconf To: Luo Gang Message-id: <026701c6aff4$8e294c30$7c046c6b@sisodomain.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Mailer: Microsoft Outlook Express 6.00.2900.2869 Content-type: text/plain; reply-type=response; charset=iso-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <992c2bb30607230909i40a5cb8am28e93d4052ad3d37@mail.gmail.com> X-Spam-Score: -2.6 (--) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: autoconf X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ad Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: autoconf-bounces@ietf.org Hello Luo Gang, Please see inline comments: ----- Original Message ----- From: "Luo Gang" To: "autoconf" Sent: Sunday, July 23, 2006 9:39 PM Subject: [Autoconf] Where I can find the informational RFC wrt autoconf > BUT I don't see any RFC in the same pages. > Is there anybody can tell me where I can get them? These informational RFCs have not been published yet. Respective authors are working on these documents and hopefully would soon be available at the Autoconf WG page. Regards, Shubhranshu > Thanks in advance! > > Regards, > -- > Luo Gang > > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www1.ietf.org/mailman/listinfo/autoconf > > _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Tue Jul 25 13:05:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5QLy-0001Ly-9t; Tue, 25 Jul 2006 13:05:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5QLw-0001KO-Jt for autoconf@ietf.org; Tue, 25 Jul 2006 13:05:52 -0400 Received: from ug-out-1314.google.com ([66.249.92.174]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5QLw-00087u-2i for autoconf@ietf.org; Tue, 25 Jul 2006 13:05:52 -0400 Received: by ug-out-1314.google.com with SMTP id m2so2938898uge for ; Tue, 25 Jul 2006 10:05:51 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=fBysRkY4tzrTYp8pADtfsSXNKYEg4Rrki0bKZ4XsFpCk+MPbpYm4a6c24UbsB+A9bQu7qmKd31liTX1e/1jc53OLrgWY9HD9EoztiSulX3ffVmF3BanwBKcwDlFOUDptNZl1KHgr7UOT51LMdGVrAYn5DlePTC2LMIhHpC7by1s= Received: by 10.66.219.11 with SMTP id r11mr4949597ugg; Tue, 25 Jul 2006 10:05:51 -0700 (PDT) Received: by 10.66.224.14 with HTTP; Tue, 25 Jul 2006 10:05:46 -0700 (PDT) Message-ID: <374005f30607251005u5ad2cae6ye795e09ef4b30419@mail.gmail.com> Date: Tue, 25 Jul 2006 10:05:46 -0700 From: "Ian Chakeres" To: "Christophe Jelger" Subject: Re: [Autoconf] Fwd: I-D ACTION:draft-chakeres-manet-iana-00.txt In-Reply-To: <44C63AA4.4060907@unibas.ch> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <374005f30607241458o5dc932ack48945384b224e22@mail.gmail.com> <44C5D9B3.7040006@unibas.ch> <374005f30607250753n288fbd81lc1b834312f953a34@mail.gmail.com> <44C63AA4.4060907@unibas.ch> X-Spam-Score: 0.0 (/) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 Cc: autoconf@ietf.org, manet X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ad Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: autoconf-bounces@ietf.org Given that these protocols are going to run over wireless interfaces (like IEEE 802.11), the main contributor to congestion is channel access (not bits). Therefore; if each protocol uses a separate packet it can result in a significant increase in channel access. Let me give a simple example. OLSR will use NHDP, it will also add certain TLVs to NHDP for determining MPRs. OLSR will also send other messages. It does not really make sense to separate the two onto different multicast addresses or ports. Continuing to add to this example, imagine that a portion of the network is also running DYMO and NHDP. If separate multicast groups were used these messages would consume even more channel access opportunities. One more continuation, it is likely that either reactive or proactive may use SMF with NHDP. Again, if a separate link-local address is used then these messages cannot be aggregated. Realistically, if a certian deployment (provider) requires each part of the solution to use a different multicast group this could be implemented, but I think the default (interoperable behavior) should be to use a single multicast address to reduce channel access. Christophe, do you think we should define one default multicast address and one for each component? Ian Chakeres On 7/25/06, Christophe Jelger wrote: > Yes that's a good point but having a common packet format is not in > contradiction with having a dedicated mcast addr per routing protocol. I > understand that having a unique mcast addr makes it easy to aggregate > routing information but while I understand this is useful for a given > protocol, I cannot see why it's useful among different protocols. I > mean, carrying routing messages all over the MANET is one thing, but > this makes little sense if intermediate nodes are not ready to partipate > in packet forwarding. For example in the following scenario > > A(DYMO) --- B(OLSRv2) --- C(DYMO) > > if node C receives DYMO messages from A (messages sent by A are > aggregated with the messages sent by B) and vice versa, still node B > does not process DYMO messages and hence would not create forwarding > states. Communication between A and C is not possible. With dedicated > mcast addresses, C and A don't see eachother at the DYMO level but > anyway they cannot communicate so it makes perfect sense to me. > > As I said in an autoconf-only email, having different mcast addresses is > an optimization because it introduces some low-level filtering at the > MAC layer. For example NHDP introduces the ALL-MANET-NEIGHBORS address: > in your view would this be different than the ALL-MANET-ROUTERS address? > > Personaly I don't see any negative reasons for not having an mcast > address per protocol (DYMO, OLSRv2, NHDP). Note that I'm not against > your scheme, I just think it's better to have dedicated mcast addresses. > > regards, > Christophe > > Ian Chakeres wrote: > > Since March 2005, we've come a long way building common building > > blocks into MANET protocols. We now have a common packet/message > > format (PacketBB) and a common neighborhood discovery protocol (NHDP). > > In order to aggregate MANET messages we'd need to send these to the > > same Multicast group. This is the reasoning behind using a single > > multicast group; instead of one per protocol. > > > > Ian > > > > On 7/25/06, Christophe Jelger wrote: > > > >> Ian/all, > >> > >> I didn't attend the last ietf meeting so I don't know how this topic was > >> discussed but I remember we had a similar discussion in March 2005 and > >> the consensus (March 17th 2005) was that there should be a multicast > >> address for each MANET routing protocol as done with existing routing > >> protocols (e.g. ff02::5 and ff02::6 for OSPF, ff02::9 for RIP, ff02::d > >> for PIM). > >> > >> One argument was to be consistent with current practices, and another > >> argument was that we already have ff02::1 (all nodes) and ff02::2 (all > >> routers) so it was not clear why we should have an extra > >> "all_manet_routers" address (especially if we have a multicast address > >> for each manet routing protocol). Also having a different multicast > >> address for each manet routing protocol prevents a node that does not > >> run a given routing protocol to process packets associated to it: it > >> will not even receive them at the MAC layer. > >> > >> So I'm rather in favor of having for example ff02::DYMO and > >> ff02::OLSRv2, and if a larger scope is required we can instead have > >> ff0x::DYMO and ff0x::OLSRv2. This implies that there would not be an > >> all_manet_routers address. Now for address autoconfiguration, there > >> could also be a dedicated multicast address ff0x::MANET-AUTOCONF. > >> > >> regards, > >> Christophe > >> > >> PS: note that the same reasoning applies to IPv4 > >> > >> Ian Chakeres wrote: > >> > Here is the draft I promised during MANET IETF 66 discussing MANET > >> > IANA considerations. It is meant to aid in discussing IANA assignments > >> > for MANET. I've broken down the different components into different > >> > sections. > >> > > >> > I think we are all in agreement in the immediate need for LL > >> > (link-local) MANET Routers multicast group. > >> > > >> > Less agreement, but definitely useful is a MANET UDP port. > >> > > >> > More discussion is needed for Scoped MANET Routers and any other > >> > scoped "host/node" multicast groups. Please comment on these. I would > >> > especially like some feedback from AUTOCONF people. > >> > > >> > Please email your comments to the lists or to me directly. > >> > > >> > Thanks. > >> > Ian Chakeres > >> > > >> > BTW: A document discussing MANET architecture should be coming out > >> > this week. Once it is posted I'll send an email also. The arch > >> > document may help in discussing the different IANA assignments. > >> > > >> > > > _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Tue Jul 25 13:32:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5QlP-0002dO-Ab; Tue, 25 Jul 2006 13:32:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5QlM-0002d8-Pi for autoconf@ietf.org; Tue, 25 Jul 2006 13:32:08 -0400 Received: from mail.um.es ([155.54.212.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5QlL-00030w-VK for autoconf@ietf.org; Tue, 25 Jul 2006 13:32:08 -0400 Received: from localhost (localhost [127.0.0.1]) by mail.um.es (Postfix) with ESMTP id ED27323F267 for ; Tue, 25 Jul 2006 19:32:04 +0200 (CEST) Received: from mail.um.es ([127.0.0.1]) by localhost (xenon2 [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 30025-01-92 for ; Tue, 25 Jul 2006 19:32:04 +0200 (CEST) Received: from aries.dif.um.es (aries.inf.um.es [155.54.210.253]) by mail.um.es (Postfix) with SMTP id 790C323F280 for ; Tue, 25 Jul 2006 19:32:04 +0200 (CEST) Received: (qmail 28546 invoked from network); 25 Jul 2006 17:32:12 -0000 Received: from cartman.dif.um.es (155.54.210.126) by aries.dif.um.es with SMTP; 25 Jul 2006 17:32:12 -0000 From: "Francisco J. Ros" Organization: University of Murcia To: manet@ietf.org Subject: Re: [manet] Re: [Autoconf] Fwd: I-D ACTION:draft-chakeres-manet-iana-00.txt Date: Tue, 25 Jul 2006 19:34:53 +0200 User-Agent: KMail/1.7.2 References: <44C63AA4.4060907@unibas.ch> <374005f30607251005u5ad2cae6ye795e09ef4b30419@mail.gmail.com> In-Reply-To: <374005f30607251005u5ad2cae6ye795e09ef4b30419@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200607251934.53978.fjrm@dif.um.es> X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at telemat.um.es X-Spam-Score: 1.9 (+) X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985 Cc: autoconf@ietf.org X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ad Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: autoconf-bounces@ietf.org Hi everyone, On Tuesday 25 July 2006 19:05, Ian Chakeres wrote: > Given that these protocols are going to run over wireless interfaces > (like IEEE 802.11), the main contributor to congestion is channel > access (not bits). Therefore; if each protocol uses a separate packet > it can result in a significant increase in channel access. > However, if the messages are aggregated the packet size increases and, accordingly, the likelihood of having an error in the transmission. I'm just pointing out that there is a tradeoff there. > Let me give a simple example. OLSR will use NHDP, it will also add > certain TLVs to NHDP for determining MPRs. OLSR will also send other > messages. It does not really make sense to separate the two onto > different multicast addresses or ports. > Agree. > Continuing to add to this example, imagine that a portion of the > network is also running DYMO and NHDP. If separate multicast groups > were used these messages would consume even more channel access > opportunities. > If the NHDP had its own multicast address, it wouldn't make a difference whether the other portion is running DYMO or OLSR. > One more continuation, it is likely that either reactive or proactive > may use SMF with NHDP. Again, if a separate link-local address is used > then these messages cannot be aggregated. > Yes. Right now I can't see which approach is better. I think the point raised by Cristophe is important, since processing messages of a protocol which is not implemented by the node seems a waste of resources. On the other hand, sending OLSRv2 and NHDP messages to different addresses sounds quite strange. Regards, Francisco J. Ros > Realistically, if a certian deployment (provider) requires each part > of the solution to use a different multicast group this could be > implemented, but I think the default (interoperable behavior) should > be to use a single multicast address to reduce channel access. > > Christophe, do you think we should define one default multicast > address and one for each component? > > Ian Chakeres > > On 7/25/06, Christophe Jelger wrote: > > Yes that's a good point but having a common packet format is not in > > contradiction with having a dedicated mcast addr per routing protocol. I > > understand that having a unique mcast addr makes it easy to aggregate > > routing information but while I understand this is useful for a given > > protocol, I cannot see why it's useful among different protocols. I > > mean, carrying routing messages all over the MANET is one thing, but > > this makes little sense if intermediate nodes are not ready to partipate > > in packet forwarding. For example in the following scenario > > > > A(DYMO) --- B(OLSRv2) --- C(DYMO) > > > > if node C receives DYMO messages from A (messages sent by A are > > aggregated with the messages sent by B) and vice versa, still node B > > does not process DYMO messages and hence would not create forwarding > > states. Communication between A and C is not possible. With dedicated > > mcast addresses, C and A don't see eachother at the DYMO level but > > anyway they cannot communicate so it makes perfect sense to me. > > > > As I said in an autoconf-only email, having different mcast addresses is > > an optimization because it introduces some low-level filtering at the > > MAC layer. For example NHDP introduces the ALL-MANET-NEIGHBORS address: > > in your view would this be different than the ALL-MANET-ROUTERS address? > > > > Personaly I don't see any negative reasons for not having an mcast > > address per protocol (DYMO, OLSRv2, NHDP). Note that I'm not against > > your scheme, I just think it's better to have dedicated mcast addresses. > > > > regards, > > Christophe > > > > Ian Chakeres wrote: > > > Since March 2005, we've come a long way building common building > > > blocks into MANET protocols. We now have a common packet/message > > > format (PacketBB) and a common neighborhood discovery protocol (NHDP). > > > In order to aggregate MANET messages we'd need to send these to the > > > same Multicast group. This is the reasoning behind using a single > > > multicast group; instead of one per protocol. > > > > > > Ian > > > > > > On 7/25/06, Christophe Jelger wrote: > > >> Ian/all, > > >> > > >> I didn't attend the last ietf meeting so I don't know how this topic > > >> was discussed but I remember we had a similar discussion in March 2005 > > >> and the consensus (March 17th 2005) was that there should be a > > >> multicast address for each MANET routing protocol as done with > > >> existing routing protocols (e.g. ff02::5 and ff02::6 for OSPF, ff02::9 > > >> for RIP, ff02::d for PIM). > > >> > > >> One argument was to be consistent with current practices, and another > > >> argument was that we already have ff02::1 (all nodes) and ff02::2 (all > > >> routers) so it was not clear why we should have an extra > > >> "all_manet_routers" address (especially if we have a multicast address > > >> for each manet routing protocol). Also having a different multicast > > >> address for each manet routing protocol prevents a node that does not > > >> run a given routing protocol to process packets associated to it: it > > >> will not even receive them at the MAC layer. > > >> > > >> So I'm rather in favor of having for example ff02::DYMO and > > >> ff02::OLSRv2, and if a larger scope is required we can instead have > > >> ff0x::DYMO and ff0x::OLSRv2. This implies that there would not be an > > >> all_manet_routers address. Now for address autoconfiguration, there > > >> could also be a dedicated multicast address ff0x::MANET-AUTOCONF. > > >> > > >> regards, > > >> Christophe > > >> > > >> PS: note that the same reasoning applies to IPv4 > > >> > > >> Ian Chakeres wrote: > > >> > Here is the draft I promised during MANET IETF 66 discussing MANET > > >> > IANA considerations. It is meant to aid in discussing IANA > > >> > assignments for MANET. I've broken down the different components > > >> > into different sections. > > >> > > > >> > I think we are all in agreement in the immediate need for LL > > >> > (link-local) MANET Routers multicast group. > > >> > > > >> > Less agreement, but definitely useful is a MANET UDP port. > > >> > > > >> > More discussion is needed for Scoped MANET Routers and any other > > >> > scoped "host/node" multicast groups. Please comment on these. I > > >> > would especially like some feedback from AUTOCONF people. > > >> > > > >> > Please email your comments to the lists or to me directly. > > >> > > > >> > Thanks. > > >> > Ian Chakeres > > >> > > > >> > BTW: A document discussing MANET architecture should be coming out > > >> > this week. Once it is posted I'll send an email also. The arch > > >> > document may help in discussing the different IANA assignments. > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Tue Jul 25 13:41:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5Quh-00064p-D6; Tue, 25 Jul 2006 13:41:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5Qug-00062m-52 for autoconf@ietf.org; Tue, 25 Jul 2006 13:41:46 -0400 Received: from stl-smtpout-01.boeing.com ([130.76.96.56] helo=stl-smtpout-01.ns.cs.boeing.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5Que-000483-Go for autoconf@ietf.org; Tue, 25 Jul 2006 13:41:46 -0400 Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by stl-smtpout-01.ns.cs.boeing.com (8.13.6/8.13.6/TEST_SMTPIN) with ESMTP id k6PHfhnO023019; Tue, 25 Jul 2006 12:41:44 -0500 (CDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id k6PHfho28192; Tue, 25 Jul 2006 12:41:43 -0500 (CDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Jul 2006 10:41:42 -0700 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 Subject: RE: [Autoconf] Fwd: I-D ACTION:draft-chakeres-manet-iana-00.txt Date: Tue, 25 Jul 2006 10:41:38 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A10177417C@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <024e01c6aff4$4861ae40$7c046c6b@sisodomain.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Autoconf] Fwd: I-D ACTION:draft-chakeres-manet-iana-00.txt Thread-Index: Acav9BsBjqayKI9mQ0aw445lJz8b7wAGtjhQ From: "Templin, Fred L" To: "Shubhranshu" , "Christophe Jelger" X-OriginalArrivalTime: 25 Jul 2006 17:41:42.0131 (UTC) FILETIME=[9705CC30:01C6B011] X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: autoconf@ietf.org X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ad Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: autoconf-bounces@ietf.org Shubhranshu, > I am yet to read the draft and to go through MANET ML discussions held > during March 2005 but > a quick question: Do you have any specific use case in mind that may=20 > require dedicated > multicast address, something like "ff0x::MANET-AUTOCONF ? > > Also, it would be good to know others opinion on it. As far as I know, none=20 > of the proposed > solutions for Autoconf has come-up with this requirement. Site-scoped multicast capability is part of the IPv6 addressing architecture (RFC4291, Section 2.7) and is also inferred by the language of the IANA IPv4 "multicast-addresses" registry. 'draft-templin-autoconf-dhcp-01' suggests the need for a MANET site-scoped multicast address for propagation of Extended Router Solicitation/Advertisement (ERA/ERS) messages; see the definition for ERA/ERS as well as section 3.5. In general, 'draft-templin-autoconf-dhcp-01' is treating a MANET as a "site" and applying automatic intra-site tunneling mechanisms as defined by 6over4 (RFC2529) and ISATAP (RFC4214). A future version of the draft will more explicitly describe how those tunneling mechanisms apply. Fred fred.l.templin@boeing.com=20 _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Tue Jul 25 13:58:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5RAy-0003w1-Dv; Tue, 25 Jul 2006 13:58:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5RAx-0003vu-8H for autoconf@ietf.org; Tue, 25 Jul 2006 13:58:35 -0400 Received: from s2.itd.nrl.navy.mil ([132.250.83.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5RAv-0007jb-Vs for autoconf@ietf.org; Tue, 25 Jul 2006 13:58:35 -0400 Received: from smtp.itd.nrl.navy.mil (smtp.itd.nrl.navy.mil [132.250.86.3]) by s2.itd.nrl.navy.mil (8.13.6+Sun/8.12.8) with SMTP id k6PHwRMn027454; Tue, 25 Jul 2006 13:58:30 -0400 (EDT) Received: (from SEXTANT [132.250.92.22]) by smtp.itd.nrl.navy.mil (SMSSMTP 4.1.12.43) with SMTP id M2006072513590414564 ; Tue, 25 Jul 2006 13:59:04 -0400 From: "Joe Macker" To: "'Templin, Fred L'" , "'Shubhranshu'" , "'Christophe Jelger'" Subject: RE: [Autoconf] Fwd: I-D ACTION:draft-chakeres-manet-iana-00.txt Date: Tue, 25 Jul 2006 13:58:27 -0400 Message-ID: <002101c6b013$ee42f2f0$165cfa84@SEXTANT> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acav9BsBjqayKI9mQ0aw445lJz8b7wAGtjhQAADMm3A= In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A10177417C@XCH-NW-7V2.nw.nos.boeing.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: autoconf@ietf.org X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ad Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: autoconf-bounces@ietf.org The draft-ietf-manet-smf-02.txt also suggests the potential support of site-scoped multicast. Although this is relatively wide open as the applications and use cases are evolving. I do not believe the intention of Ian's IANA document is to cover all those potentials because that is an evolving issue. -joe >-----Original Message----- >From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com] >Sent: Tuesday, July 25, 2006 1:42 PM >To: Shubhranshu; Christophe Jelger >Cc: autoconf@ietf.org >Subject: RE: [Autoconf] Fwd: I-D >ACTION:draft-chakeres-manet-iana-00.txt > >Shubhranshu, > >> I am yet to read the draft and to go through MANET ML >discussions held > >> during March 2005 but >> a quick question: Do you have any specific use case in mind >that may >> require dedicated multicast address, something like >> "ff0x::MANET-AUTOCONF ? >> >> Also, it would be good to know others opinion on it. As far >as I know, >none >> of the proposed >> solutions for Autoconf has come-up with this requirement. > >Site-scoped multicast capability is part of the IPv6 >addressing architecture (RFC4291, Section 2.7) and is also >inferred by the language of the IANA IPv4 "multicast-addresses" >registry. 'draft-templin-autoconf-dhcp-01' suggests the need >for a MANET site-scoped multicast address for propagation of >Extended Router Solicitation/Advertisement (ERA/ERS) messages; >see the definition for ERA/ERS as well as section 3.5. > >In general, 'draft-templin-autoconf-dhcp-01' is treating a >MANET as a "site" and applying automatic intra-site tunneling >mechanisms as defined by 6over4 (RFC2529) and ISATAP (RFC4214). >A future version of the draft will more explicitly describe >how those tunneling mechanisms apply. > >Fred >fred.l.templin@boeing.com > >_______________________________________________ >Autoconf mailing list >Autoconf@ietf.org >https://www1.ietf.org/mailman/listinfo/autoconf > _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Tue Jul 25 15:15:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5SNM-00067X-16; Tue, 25 Jul 2006 15:15:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5SNK-00065w-GF; Tue, 25 Jul 2006 15:15:26 -0400 Received: from balu1.urz.unibas.ch ([131.152.1.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5SNJ-0003Ow-1q; Tue, 25 Jul 2006 15:15:26 -0400 Received: from localhost (webmail.urz.unibas.ch [131.152.1.20]) by balu1.urz.unibas.ch (8.13.7/8.13.7) with ESMTP id k6PJFF70008088; Tue, 25 Jul 2006 21:15:15 +0200 Received: from ip-62-241-100-226.evc.net (ip-62-241-100-226.evc.net [62.241.100.226]) by webmail.unibas.ch (IMP) with HTTP for ; Tue, 25 Jul 2006 21:15:15 +0200 Message-ID: <1153854915.44c66dc3b0716@webmail.unibas.ch> Date: Tue, 25 Jul 2006 21:15:15 +0200 From: Christophe.Jelger@unibas.ch To: Ian Chakeres Subject: Re: [Autoconf] Fwd: I-D ACTION:draft-chakeres-manet-iana-00.txt References: <374005f30607241458o5dc932ack48945384b224e22@mail.gmail.com> <44C5D9B3.7040006@unibas.ch> <374005f30607250753n288fbd81lc1b834312f953a34@mail.gmail.com> <44C63AA4.4060907@unibas.ch> <374005f30607251005u5ad2cae6ye795e09ef4b30419@mail.gmail.com> In-Reply-To: <374005f30607251005u5ad2cae6ye795e09ef4b30419@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.3 X-Originating-IP: 62.241.100.226 X-SMTP-Vilter-Version: 1.3.1 X-Spam-Score: 0.2 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: autoconf@ietf.org, manet X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ad Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: autoconf-bounces@ietf.org Ian, See my comments inline. Quoting Ian Chakeres : > Given that these protocols are going to run over wireless interfaces > (like IEEE 802.11), the main contributor to congestion is channel > access (not bits). Therefore; if each protocol uses a separate packet > it can result in a significant increase in channel access. ok that's something I didn't think of. However if this is the only point in favor of aggregation I'm afraid I'm still not really convinced. One drawback of aggregation is increased delay. That is, each node will have to wait some small amount of time (1ms?, 10ms?) to be able to aggregate packets. > > Let me give a simple example. OLSR will use NHDP, it will also add > certain TLVs to NHDP for determining MPRs. OLSR will also send other > messages. It does not really make sense to separate the two onto > different multicast addresses or ports. > > Continuing to add to this example, imagine that a portion of the > network is also running DYMO and NHDP. If separate multicast groups > were used these messages would consume even more channel access > opportunities. > > One more continuation, it is likely that either reactive or proactive > may use SMF with NHDP. Again, if a separate link-local address is used > then these messages cannot be aggregated. > > Realistically, if a certian deployment (provider) requires each part > of the solution to use a different multicast group this could be > implemented, but I think the default (interoperable behavior) should > be to use a single multicast address to reduce channel access. ok I understand your points but I'm just not much convinced about the aggregation feature. Of course it's somehow elegant but I'm not sure the extra complexity is worth the effort. > > Christophe, do you think we should define one default multicast > address and one for each component? Well IMHO I'm still in favor of having separate multicast addresses for e.g. respectively DYMO, OLSRv2 and NHDP. But hey after all this is not the most important issue to be resolved so I won't fight very hard. ;-) regards, Christophe ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Wed Jul 26 00:47:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5bJD-0007uC-V5; Wed, 26 Jul 2006 00:47:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2TzZ-0003ew-Vk for autoconf@ietf.org; Mon, 17 Jul 2006 10:22:37 -0400 Received: from [204.9.221.19] (helo=thingmagic.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2TzW-0001a3-P7 for autoconf@ietf.org; Mon, 17 Jul 2006 10:22:37 -0400 Received: from [66.30.121.250] (account margaret HELO [192.168.2.3]) by thingmagic.com (CommuniGate Pro SMTP 5.0.1) with ESMTPSA id 1117440 for autoconf@ietf.org; Mon, 17 Jul 2006 10:22:34 -0400 Mime-Version: 1.0 (Apple Message framework v750) Content-Transfer-Encoding: 7bit Message-Id: <3DC6F080-4593-48C5-8E46-CC19B6F5E70C@thingmagic.com> Content-Type: text/plain; charset=US-ASCII; format=flowed To: autoconf@ietf.org From: Margaret Wasserman Date: Mon, 17 Jul 2006 10:22:16 -0400 X-Mailer: Apple Mail (2.750) X-Spam-Score: 1.6 (+) X-Scan-Signature: bb8eae9af85e4fcfe76f325e38493bf4 X-Mailman-Approved-At: Wed, 26 Jul 2006 00:47:46 -0400 Subject: [Autoconf] (no subject) X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ad Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: autoconf-bounces@ietf.org unsubscribe _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Wed Jul 26 02:25:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5cq4-0003Nd-Uc; Wed, 26 Jul 2006 02:25:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5cq3-0003My-LD; Wed, 26 Jul 2006 02:25:47 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5cq3-0006Zf-J6; Wed, 26 Jul 2006 02:25:47 -0400 Received: from outbound.mailhop.org ([63.208.196.171]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G5cdK-0006zN-4b; Wed, 26 Jul 2006 02:12:39 -0400 Received: from did75-10-82-236-230-133.fbx.proxad.net ([82.236.230.133] helo=[192.168.147.101]) by outbound.mailhop.org with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.51) id 1G5cdF-0001d5-62; Wed, 26 Jul 2006 02:12:33 -0400 X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 82.236.230.133 X-Report-Abuse-To: abuse@dyndns.com (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: voop In-Reply-To: <1153854915.44c66dc3b0716@webmail.unibas.ch> References: <374005f30607241458o5dc932ack48945384b224e22@mail.gmail.com> <44C5D9B3.7040006@unibas.ch> <374005f30607250753n288fbd81lc1b834312f953a34@mail.gmail.com> <44C63AA4.4060907@unibas.ch> <374005f30607251005u5ad2cae6ye795e09ef4b30419@mail.gmail.com> <1153854915.44c66dc3b0716@webmail.unibas.ch> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <593A0455-728A-472B-B760-0BF2252FD9F4@computer.org> Content-Transfer-Encoding: 7bit From: Thomas Clausen Subject: Re: [Autoconf] Fwd: I-D ACTION:draft-chakeres-manet-iana-00.txt Date: Wed, 26 Jul 2006 08:12:29 +0200 To: Christophe.Jelger@unibas.ch X-Mailer: Apple Mail (2.752.2) X-Spam-Score: -2.6 (--) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Cc: autoconf@ietf.org, manet X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ad Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: autoconf-bounces@ietf.org Christophe, On Jul 25, 2006, at 9:15 PM, Christophe.Jelger@unibas.ch wrote: > Ian, > > See my comments inline. > > Quoting Ian Chakeres : > >> Given that these protocols are going to run over wireless interfaces >> (like IEEE 802.11), the main contributor to congestion is channel >> access (not bits). Therefore; if each protocol uses a separate packet >> it can result in a significant increase in channel access. > > ok that's something I didn't think of. However if this is the only > point in > favor of aggregation I'm afraid I'm still not really convinced. One > drawback of > aggregation is increased delay. That is, each node will have to > wait some small > amount of time (1ms?, 10ms?) to be able to aggregate packets. That depends how it is done. If you run a protocol with periodic message emissions on one node, and then that node needs to forward an "occasional" external message, you have two options" either hold the external message while you wait for your next scheduled periodic message to be up for transmission (which incurs a delay). Or you may chose to immediately generate the next periodic message and transmit this immediately with the "external" message, and then reset your periodic schedule. The devil is in the details. I believe that one detail would be that the MANET routing protocols which use periodic messages are perfectly capable of dealing with triggered "out of schedule" messages, and to reset the schedule as appropriate. Of course, one must not forget that it being *possible* to do something does not mean that it is *mandatory* to do so: if in the example given above the next periodic message was scheduled to be sent in 4 hours, it might possibly be that one would not want to reschedule, but just send the external message. But yes, making a good message scheduler that's general enough to understand these things is part of the exercise of an implementation > >> >> Let me give a simple example. OLSR will use NHDP, it will also add >> certain TLVs to NHDP for determining MPRs. OLSR will also send other >> messages. It does not really make sense to separate the two onto >> different multicast addresses or ports. >> And even more: even looking at the messages from a single nodes perspective, OLSRv2-nodes use NHDP for their local topology maintenance and will thus generate TC messages and NHDP-HELLO messages. Since HELLO messages are sent more frequently than TC messages, even a simple scheduler would say "if I am to send a TC message at the latest at deadline XXX, send it with the last HELLO message with a deadline > Continuing to add to this example, imagine that a portion of the >> network is also running DYMO and NHDP. If separate multicast groups >> were used these messages would consume even more channel access >> opportunities. >> >> One more continuation, it is likely that either reactive or proactive >> may use SMF with NHDP. Again, if a separate link-local address is >> used >> then these messages cannot be aggregated. >> >> Realistically, if a certian deployment (provider) requires each part >> of the solution to use a different multicast group this could be >> implemented, but I think the default (interoperable behavior) should >> be to use a single multicast address to reduce channel access. > > ok I understand your points but I'm just not much convinced about the > aggregation feature. Of course it's somehow elegant but I'm not > sure the extra > complexity is worth the effort. > Christophe, which complexity is it that you are worried about? The parsing of multi-message packets is something we've done in OLSR since before RFC3626. The scheduling issues, you can make a scheduler as complex as you like: taking into account aggregation in a clever way -- or as simple as you like by simply not doing aggregation. We've done that in OLSR since before RFC3626 too. >> >> Christophe, do you think we should define one default multicast >> address and one for each component? > > Well IMHO I'm still in favor of having separate multicast addresses > for e.g. > respectively DYMO, OLSRv2 and NHDP. But hey after all this is not > the most > important issue to be resolved so I won't fight very hard. ;-) I think it is important, so I will fight very hard ;) I do not see what different multicast addresses with identical scope for each component would buy us. Again, speaking with the OLSRv2-hat, I definitely would want my TC and HELLO messages to be aggregateable, and would therefore either say "thou shall send both to generic-manet- mcast-address-XXX", or say "thou shall send both to olsrv2-mcast- address-XXX", but I would *never* want to send them to different addresses. Anything that would prevent me from aggregating such TCs and HELLOs would, in my opinion, be broken. --thomas _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Wed Jul 26 04:20:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5ed4-0007yB-Q0; Wed, 26 Jul 2006 04:20:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5ed2-0007xk-Mo; Wed, 26 Jul 2006 04:20:28 -0400 Received: from balu1.urz.unibas.ch ([131.152.1.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5ed0-0005jG-8U; Wed, 26 Jul 2006 04:20:28 -0400 Received: from [131.152.55.200] (baobab.cs.unibas.ch [131.152.55.200]) by balu1.urz.unibas.ch (8.13.7/8.13.7) with ESMTP id k6Q8KEKa012762; Wed, 26 Jul 2006 10:20:15 +0200 Message-ID: <44C725F2.8080006@unibas.ch> Date: Wed, 26 Jul 2006 10:21:06 +0200 From: Christophe Jelger Organization: University of Basel User-Agent: Debian Thunderbird 1.0.7 (X11/20051017) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thomas Clausen Subject: Re: [Autoconf] Fwd: I-D ACTION:draft-chakeres-manet-iana-00.txt References: <374005f30607241458o5dc932ack48945384b224e22@mail.gmail.com> <44C5D9B3.7040006@unibas.ch> <374005f30607250753n288fbd81lc1b834312f953a34@mail.gmail.com> <44C63AA4.4060907@unibas.ch> <374005f30607251005u5ad2cae6ye795e09ef4b30419@mail.gmail.com> <1153854915.44c66dc3b0716@webmail.unibas.ch> <593A0455-728A-472B-B760-0BF2252FD9F4@computer.org> In-Reply-To: <593A0455-728A-472B-B760-0BF2252FD9F4@computer.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SMTP-Vilter-Version: 1.3.1 X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: autoconf@ietf.org, manet X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ad Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: autoconf-bounces@ietf.org Hello Thomas, Thomas Clausen wrote: > (...) > > Christophe, which complexity is it that you are worried about? The > parsing of multi-message packets is something we've done in OLSR since > before RFC3626. The scheduling issues, you can make a scheduler as > complex as you like: taking into account aggregation in a clever way -- > or as simple as you like by simply not doing aggregation. We've done > that in OLSR since before RFC3626 too. > I refered to what you mention when you say "the devil is in the details" (i.e. the aggregation scheduler). Of course parsing is not an issue. > > I think it is important, so I will fight very hard ;) > > I do not see what different multicast addresses with identical scope > for each component would buy us. Networking is about exchanging messages between interested parties. I just don't buy the idea that each MANET node will have to read and parse messages for which it might have "no interest": this sounds like spam to me. Moreover having a dedicated mcast addr per protocol is the best current practise in the ietf wgs. > Again, speaking with the OLSRv2-hat, I > definitely would want my TC and HELLO messages to be aggregateable, and > would therefore either say "thou shall send both to generic-manet- > mcast-address-XXX", or say "thou shall send both to olsrv2-mcast- > address-XXX", but I would *never* want to send them to different > addresses. At the end the draft authors (DYMO, OLSRv2, NHDP) will choose anyway what they prefer so that's why I cynically say "I won't fight very hard". > > Anything that would prevent me from aggregating such TCs and HELLOs > would, in my opinion, be broken. I realized that. > > > --thomas > _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Wed Jul 26 04:51:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5f75-0004vR-Qb; Wed, 26 Jul 2006 04:51:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5f74-0004vB-AS; Wed, 26 Jul 2006 04:51:30 -0400 Received: from smtp1.bae.co.uk ([20.133.0.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5f72-0000dz-TJ; Wed, 26 Jul 2006 04:51:30 -0400 Received: from ngbaux (ngbaux.msd.bae.co.uk [141.245.68.234]) by smtp1.bae.co.uk (Switch-3.1.9/Switch-3.1.9) with ESMTP id k6Q8pQD0017118; Wed, 26 Jul 2006 09:51:27 +0100 (BST) Received: from glkas0002.GREENLNK.NET ([10.15.184.52]) by ngbaux.net.bae.co.uk (PMDF V5.2-33 #44998) with ESMTP id <0J300063D63PFT@ngbaux.net.bae.co.uk>; Wed, 26 Jul 2006 09:55:01 +0100 (BST) Received: from glkms0001.GREENLNK.NET ([10.15.184.1]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Wed, 26 Jul 2006 09:50:54 +0100 Received: from glkms0008.GREENLNK.NET ([10.15.184.8]) by glkms0001.GREENLNK.NET with Microsoft SMTPSVC(5.0.2195.6713); Wed, 26 Jul 2006 09:50:53 +0100 Date: Wed, 26 Jul 2006 09:50:53 +0100 From: "Dearlove, Christopher (UK)" Subject: RE: [Autoconf] Fwd: I-D ACTION:draft-chakeres-manet-iana-00.txt To: Christophe Jelger , Thomas Clausen Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6556.0 Content-type: text/plain; charset="us-ascii" Content-transfer-encoding: quoted-printable Thread-Topic: [Autoconf] Fwd: I-D ACTION:draft-chakeres-manet-iana-00.txt Thread-Index: AcawjGFft20W25k1RROd7QR+pjcrVgAA5w1g Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 26 Jul 2006 08:50:53.0811 (UTC) FILETIME=[9A5B9430:01C6B090] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: autoconf@ietf.org, manet X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ad Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: autoconf-bounces@ietf.org Christophe Jelger wrote: > Thomas Clausen wrote: >> I do not see what different multicast addresses with identical scope >> for each component would buy us.=0D > Networking is about exchanging messages between interested parties. I=0D > just don't buy the idea that each MANET node will have to read and parse=0D > messages for which it might have "no interest": this sounds like spam to=0D > me. Moreover having a dedicated mcast addr per protocol is the best=0D > current practise in the ietf wgs. It is of course possible to use the same multicast address, but ignore messages you aren't interested in by using different UDP ports. (OK, you have to parse the IP and UDP headers, but not the routing protocol messages.) I'm not arguing for or against this right now, just throwing it into the mix. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Wed Jul 26 05:26:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5fej-0004EH-M7; Wed, 26 Jul 2006 05:26:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5fei-0004E0-Fp for autoconf@ietf.org; Wed, 26 Jul 2006 05:26:16 -0400 Received: from smtp102.plus.mail.re2.yahoo.com ([206.190.53.27]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G5feh-00060Z-0m for autoconf@ietf.org; Wed, 26 Jul 2006 05:26:16 -0400 Received: (qmail 75034 invoked from network); 26 Jul 2006 09:26:14 -0000 Received: from unknown (HELO ?192.168.200.2?) (fjrm4@83.34.174.118 with plain) by smtp102.plus.mail.re2.yahoo.com with SMTP; 26 Jul 2006 09:26:14 -0000 From: "Francisco J. Ros" Organization: University of Murcia To: manet@ietf.org Subject: Re: [manet] RE: [Autoconf] Fwd: I-D ACTION:draft-chakeres-manet-iana-00.txt Date: Wed, 26 Jul 2006 11:26:15 +0200 User-Agent: KMail/1.9.1 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200607261126.16609.fjrm@dif.um.es> X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: autoconf@ietf.org, Thomas Clausen X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ad Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: autoconf-bounces@ietf.org Hello, On Wednesday 26 July 2006 10:50, Dearlove, Christopher (UK) wrote: > It is of course possible to use the same multicast address, but ignore > messages you aren't interested in by using different UDP ports. (OK, > you have to parse the IP and UDP headers, but not the routing protocol > messages.) I'm not arguing for or against this right now, just throwing > it into the mix. > Assuming the same mcast address and different ports... Since we don't want OLSRv2 and NHDP messages to be disaggregated, then they should use the same port, right? Then, a node running DYMO and NHDP would process the routing messages sent by a neighbor running OLSRv2. So, even routing protocol messages are processed by nodes which aren't interested in them (unless I'm missing something). Of course, this only happens if the nodes implement NHDP, but that's quite likely. Regards, fran ______________________________________________ LLama Gratis a cualquier PC del Mundo. Llamadas a fijos y móviles desde 1 céntimo por minuto. http://es.voice.yahoo.com _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Wed Jul 26 06:07:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5gIj-0006Zb-PG; Wed, 26 Jul 2006 06:07:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5gIh-0006ZK-NO; Wed, 26 Jul 2006 06:07:35 -0400 Received: from smtp1.bae.co.uk ([20.133.0.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5gIe-0000XM-2E; Wed, 26 Jul 2006 06:07:35 -0400 Received: from ngbaux (ngbaux.msd.bae.co.uk [141.245.68.234]) by smtp1.bae.co.uk (Switch-3.1.9/Switch-3.1.9) with ESMTP id k6QA7Un3011122; Wed, 26 Jul 2006 11:07:30 +0100 (BST) Received: from glkas0002.GREENLNK.NET ([10.15.184.52]) by ngbaux.net.bae.co.uk (PMDF V5.2-33 #44998) with ESMTP id <0J30008MV9N6VE@ngbaux.net.bae.co.uk>; Wed, 26 Jul 2006 11:11:30 +0100 (BST) Received: from glkms0002.GREENLNK.NET ([10.15.184.2]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Wed, 26 Jul 2006 11:07:23 +0100 Received: from glkms0008.GREENLNK.NET ([10.15.184.8]) by glkms0002.GREENLNK.NET with Microsoft SMTPSVC(5.0.2195.6713); Wed, 26 Jul 2006 11:07:22 +0100 Date: Wed, 26 Jul 2006 11:07:22 +0100 From: "Dearlove, Christopher (UK)" Subject: RE: [manet] RE: [Autoconf] Fwd: I-D ACTION:draft-chakeres-manet-iana-00.txt To: "Francisco J. Ros" , manet@ietf.org Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6556.0 Content-type: text/plain; charset="us-ascii" Content-transfer-encoding: quoted-printable Thread-Topic: [manet] RE: [Autoconf] Fwd: I-D ACTION:draft-chakeres-manet-iana-00.txt Thread-Index: AcawlY/5bG4fp7UXRQeHDAkfEKW/gAABZZYw Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 26 Jul 2006 10:07:22.0957 (UTC) FILETIME=[49B3AFD0:01C6B09B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: autoconf@ietf.org, Thomas Clausen X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ad Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: autoconf-bounces@ietf.org > Assuming the same mcast address and different ports... Since we don't want=0D > OLSRv2 and NHDP messages to be disaggregated, then they should use the same=0D > port, right? Then, a node running DYMO and NHDP would process the routing=0D > messages sent by a neighbor running OLSRv2. > > So, even routing protocol messages are processed by nodes which aren't > interested in them (unless I'm missing something). Of course, this only=0D > happens if the nodes implement NHDP, but that's quite likely. This is a point I've been thinking about, to no definite conclusion. In fact it's even more complicated in one regard, but not quite as bad as the above might suggest in another. My previous comment was about if you want to separate protocol messages, different multicast addresses are one option, but different ports are another. But as you note, you may want to put them together, in which case you really want the same multicast address, and maybe the same port. I'll consider OLSRv2 and SMF, as they make the point I want to make. Both use NHDP, and NHDP sends and receives HELLO messages. But it's more than that. Assuming we don't want to duplicate messages: - The basic NHDP HELLO messages aren't sufficient for OLSRv2 or SMF. OLSRv2 needs to add WILLINGNESS and MPR TLVs. SMF may use these or (for a more interesting case) may want to add some other sort of CDS messages. So both protocols want to "decorate" the HELLO message outgoing. Note that having both in the same HELLO message should be fine. - For efficient messages, OLSRv2 would like to control the HELLO message address ordering. SMF might want to do the same, but not in the same order. This needs further consideration. - Both protocols need to see incoming HELLO messages. - OLSRv2 generates and forwards TC messages. These must be able to be piggybacked with HELLO messages in multi-message packets. (Given that in many cases the number of packets is what matters, the size of the packets is not significant, it could even be more efficient to run NHDP twice in parallel than lose this capability.) - Note that a protocol not using message type X can in fact skip that entire message reading only the type, ignoring the semantics, and the message length, and then skipping ahead by that message length. There is no need to even parse the rest of the message header. - OLSRv2 (at least) may want to suggest a rescheduling of HELLO messages to NHDP. It may want to force all addresses to be reported, in particular if its MPR Set changes. - Other scenarios to be considered are that there may be a need to add a signature to a message or packet. In both cases this needs to be the last thing done. The architecture of all this is not trivial, or at least allowing the options everyone might want isn't. In my case I would implement OLSRv2, and SMF can be treated as an extension to OLSRv2. But others may not want to do that. And I haven't even considered if DYMO wants to join the party - noting that running OLSRv2 and DYMO together is a mostly futile exercise, except on a node which reports itself as a gateway into each of two separate MANETs, one running DYMO, one running OLSRv2. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Wed Jul 26 07:50:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5hug-0004wr-Ty; Wed, 26 Jul 2006 07:50:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5gFi-00055y-AP; Wed, 26 Jul 2006 06:04:30 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5evi-0007Fb-Uf; Wed, 26 Jul 2006 04:39:46 -0400 Received: from mx1.cdacindia.com ([203.199.132.35] helo=mx1.cdac.in) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1G5egu-0001Vt-Bx; Wed, 26 Jul 2006 04:24:30 -0400 Received: from mailhub.cdac.in ([203.199.132.67]) by mx1.cdac.in (SAVSMTP 3.1.0.29) with SMTP id M2006072613524720137 ; Wed, 26 Jul 2006 13:52:47 +0530 Received: from mailhub.cdac.in (mailhub [196.1.109.254]) by mailhub.cdac.in (8.13.4/8.13.4) with ESMTP id k6Q8OBgl008288; Wed, 26 Jul 2006 13:54:12 +0530 From: Abhishek Misra Received: from cdac.in (localhost [127.0.0.1]) by mailhub.cdac.in (8.13.4/8.13.4) with SMTP id k6Q8OBDk008281; Wed, 26 Jul 2006 13:54:11 +0530 Date: Wed, 26 Jul 2006 13:54:11 +0530 (IST) To: "Thomas Clausen" , X-Mailer: TWIG 2.8.3 Message-ID: In-Reply-To: <593A0455-728A-472B-B760-0BF2252FD9F4@computer.org> References: <374005f30607241458o5dc932ack48945384b224e22@mail.gmail.com> <44C5D9B3.7040006@unibas.ch> <374005f30607250753n288fbd81lc1b834312f953a34@mail.gmail.com> <44C63AA4.4060907@unibas.ch> <374005f30607251005u5ad2cae6ye795e09ef4b30419@mail.gmail.com> <1153854915.44c66dc3b0716@webmail.unibas.ch>, <1153854915.44c66dc3b0716@webmail.unibas.ch> X-Spam-Score: -2.6 (--) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 X-Mailman-Approved-At: Wed, 26 Jul 2006 07:50:54 -0400 Cc: autoconf@ietf.org, manet Subject: [Autoconf] Auto IP address assignment in mesh networks X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ad Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: autoconf-bounces@ietf.org Hello, We are trying to develope Wireless Mesh Router[with multiple interfaces] software I wish to know if some auto ip address assignment schemes for mesh networks have been proposed. We plan to use cards in master mode to support clients on each interface and use wds links for routing and forwarding data. Thank You Abhishek Misra _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Wed Jul 26 08:50:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5iqA-0001iJ-K1; Wed, 26 Jul 2006 08:50:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5iq9-0001iE-Mg for autoconf@ietf.org; Wed, 26 Jul 2006 08:50:17 -0400 Received: from concorde.inria.fr ([192.93.2.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5iq8-0004I8-AF for autoconf@ietf.org; Wed, 26 Jul 2006 08:50:17 -0400 Received: from [160.45.116.8] (rosine8.inf.fu-berlin.de [160.45.116.8]) (authenticated bits=0) by concorde.inria.fr (8.13.6/8.13.6) with ESMTP id k6QCnopm029141 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 26 Jul 2006 14:49:51 +0200 Message-ID: <44C7642E.8040002@inria.fr> Date: Wed, 26 Jul 2006 14:46:38 +0200 From: Emmanuel Baccelli User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Yangwoo Ko Subject: Re: [Autoconf] Problem Statement draft References: <44C49D7F.8060403@inria.fr> <44C4AD3D.9070301@icu.ac.kr> In-Reply-To: <44C4AD3D.9070301@icu.ac.kr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Miltered: at concorde with ID 44C764EE.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: autoconf@ietf.org, may@icu.ac.kr X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ad Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: autoconf-bounces@ietf.org Hi Yangwoo, I believe the issue you are raising is now contained in the ITEM 2 I've just listed in the things we were looking to address for 01. Thank you for your feedback. Emmanuel Yangwoo Ko wrote: > > Dear Emmanuel Baccelli and others, > > Currently we are working on the issue of interconnection of > multiple MANETs. Your document only deals with the case > where two MANETs "merge" if they meet. But there are some > reasons (e.g. management, security or whatever) that restrict > the merge. > > Even under such a restriction, two MANETs can be interconnected > through some nodes. (I try to avoid the word "gateway" because > it is commonly used for external (or Internet) gateways.) These > interconnection nodes will work like a gateway with enhanced > function that meets the "some reasons" mentioned above. > > The interconnection node can serve as an external gateway if > external connection of either (but not both) MANET is broken. > > Since two MANETs are independently configured standalone networks, > interconnection of them should not incur address allocation or > assignment. However, interconnection related information > (e.g. gateway address to the other MANET) should be distributed > in some way. > > I am not so sure whether this scenario can be decomposed into > a combination of standalone MANET and MANET with external > connection(s) defined in your document. > > Regards > > Emmanuel Baccelli wrote: > >> Hi all, >> >> The problem statement draft-baccelli-autoconf-problem-statement-00 >> has been submitted as included in attachement. Now is the time to >> read it and to provide your comments! >> >> Regards, >> Emmanuel >> >> (snip) > > > _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Wed Jul 26 11:59:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5lmu-0002lR-MK; Wed, 26 Jul 2006 11:59:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5lms-0002dK-GQ; Wed, 26 Jul 2006 11:59:06 -0400 Received: from s2.itd.nrl.navy.mil ([132.250.83.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5lms-00063Y-5b; Wed, 26 Jul 2006 11:59:06 -0400 Received: from smtp.itd.nrl.navy.mil (smtp.itd.nrl.navy.mil [132.250.86.3]) by s2.itd.nrl.navy.mil (8.13.6+Sun/8.12.8) with SMTP id k6QFwUZw028094; Wed, 26 Jul 2006 11:58:36 -0400 (EDT) Received: (from SEXTANT [132.250.92.22]) by smtp.itd.nrl.navy.mil (SMSSMTP 4.1.12.43) with SMTP id M2006072611591023547 ; Wed, 26 Jul 2006 11:59:10 -0400 From: "Joe Macker" To: "'Dearlove, Christopher \(UK\)'" , "'Francisco J. Ros'" , Subject: RE: [manet] RE: [Autoconf] Fwd: I-DACTION:draft-chakeres-manet-iana-00.txt Date: Wed, 26 Jul 2006 11:58:33 -0400 Message-ID: <008e01c6b0cc$588bc610$165cfa84@SEXTANT> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 In-Reply-To: Thread-Index: AcawlY/5bG4fp7UXRQeHDAkfEKW/gAABZZYwAAwEkoA= X-Spam-Score: 0.0 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c Cc: autoconf@ietf.org, 'Thomas Clausen' X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ad Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: autoconf-bounces@ietf.org Chris: I just want to clarify that SMF has three neighborhood discovery modes defined in -02. The writeup below sounds like its always required to run NHDP separately. So SMF does not need to see HELLOs in mode (2) or (1) just for clarification. (3) would be updated to reference NHDP and related TLVs as you mention for independent operation. The present prototype implementations often run in (2) mode which means OLSRv2 or MANET-OSPF,etc would run the neighborhood discovery and the appropriate optimized CDS (e.g., MPR) information would be shared. With respect to neighborhood topology knowledge and/or discovery, there are three basic modes of SMF operation: 1. Classical Flooding (CF) mode with no requirement for discovery or knowledge of neighborhood topology, 2. External control mode where an external process dynamically sets the local SMF relay status (e.g., Early SMF prototypes have leveraged neighborhood toplogy information collected by MANET unicast routing protocols such as OLSRv2 or Manet-OSPF ), and 3. Independent operating mode using a neighborhood discovery ("hello") protocol to collect the local topology information required for the various CDS algorithm modes discussed in the Appendices. >-----Original Message----- >From: Dearlove, Christopher (UK) >[mailto:chris.dearlove@baesystems.com] >Sent: Wednesday, July 26, 2006 6:07 AM >To: Francisco J. Ros; manet@ietf.org >Cc: autoconf@ietf.org; Thomas Clausen >Subject: RE: [manet] RE: [Autoconf] Fwd: >I-DACTION:draft-chakeres-manet-iana-00.txt > > >> Assuming the same mcast address and different ports... Since we don't >want > >> OLSRv2 and NHDP messages to be disaggregated, then they >should use the >same > >> port, right? Then, a node running DYMO and NHDP would process the >routing > >> messages sent by a neighbor running OLSRv2. >> >> So, even routing protocol messages are processed by nodes >which aren't > >> interested in them (unless I'm missing something). Of course, this >only > >> happens if the nodes implement NHDP, but that's quite likely. > >This is a point I've been thinking about, to no definite conclusion. >In fact it's even more complicated in one regard, but not >quite as bad as the above might suggest in another. > >My previous comment was about if you want to separate protocol >messages, different multicast addresses are one option, but >different ports are another. But as you note, you may want to >put them together, in which case you really want the same >multicast address, and maybe the same port. > >I'll consider OLSRv2 and SMF, as they make the point I want to make. >Both use NHDP, and NHDP sends and receives HELLO messages. But >it's more than that. Assuming we don't want to duplicate messages: > >- The basic NHDP HELLO messages aren't sufficient for OLSRv2 or SMF. > OLSRv2 needs to add WILLINGNESS and MPR TLVs. SMF may use these or > (for a more interesting case) may want to add some other sort of > CDS messages. So both protocols want to "decorate" the HELLO message > outgoing. Note that having both in the same HELLO message should be > fine. > >- For efficient messages, OLSRv2 would like to control the HELLO > message address ordering. SMF might want to do the same, but not > in the same order. This needs further consideration. > >- Both protocols need to see incoming HELLO messages. > >- OLSRv2 generates and forwards TC messages. These must be able > to be piggybacked with HELLO messages in multi-message packets. > (Given that in many cases the number of packets is what matters, > the size of the packets is not significant, it could even be more > efficient to run NHDP twice in parallel than lose this capability.) > >- Note that a protocol not using message type X can in fact skip that > entire message reading only the type, ignoring the semantics, and > the message length, and then skipping ahead by that message length. > There is no need to even parse the rest of the message header. > >- OLSRv2 (at least) may want to suggest a rescheduling of HELLO > messages to NHDP. It may want to force all addresses to be > reported, in particular if its MPR Set changes. > >- Other scenarios to be considered are that there may be a need to > add a signature to a message or packet. In both cases this needs > to be the last thing done. > >The architecture of all this is not trivial, or at least >allowing the options everyone might want isn't. In my case I >would implement OLSRv2, and SMF can be treated as an extension >to OLSRv2. But others may not want to do that. And I haven't >even considered if DYMO wants to join the party - noting that >running OLSRv2 and DYMO together is a mostly futile exercise, >except on a node which reports itself as a gateway into each >of two separate MANETs, one running DYMO, one running OLSRv2. > > >******************************************************************** >This email and any attachments are confidential to the >intended recipient and may also be privileged. If you are not >the intended recipient please delete it from your system and >notify the sender. >You should not copy it or use it for any purpose nor disclose >or distribute its contents to any other person. >******************************************************************** > >_______________________________________________ >Autoconf mailing list >Autoconf@ietf.org >https://www1.ietf.org/mailman/listinfo/autoconf > _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Wed Jul 26 12:05:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5ltF-0005pe-QH; Wed, 26 Jul 2006 12:05:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5ltD-0005pW-S7 for autoconf@ietf.org; Wed, 26 Jul 2006 12:05:39 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5j4J-00070T-VO for autoconf@ietf.org; Wed, 26 Jul 2006 09:04:56 -0400 Received: from concorde.inria.fr ([192.93.2.39]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G5inZ-0007Gu-H3 for autoconf@ietf.org; Wed, 26 Jul 2006 08:47:41 -0400 Received: from [160.45.116.8] (rosine8.inf.fu-berlin.de [160.45.116.8]) (authenticated bits=0) by concorde.inria.fr (8.13.6/8.13.6) with ESMTP id k6QClJmN028654 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 26 Jul 2006 14:47:21 +0200 Message-ID: <44C76397.3000701@inria.fr> Date: Wed, 26 Jul 2006 14:44:07 +0200 From: Emmanuel Baccelli User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: autoconf@ietf.org Content-Type: multipart/mixed; boundary="------------000305060606090301020808" X-j-chkmail-Score: MSGID : 44C76457.004 on concorde : j-chkmail score : XX : 5/20 0 X-Miltered: at concorde with ID 44C76457.004 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam-Score: -2.6 (--) X-Scan-Signature: 28aa4dc616a7f0ac0889ef522e9e39ef Subject: [Autoconf] Problem Statement: input and discussions on the list X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ad Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: autoconf-bounces@ietf.org This is a multi-part message in MIME format. --------------000305060606090301020808 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi all, I would like to stir up the discussion about the Problem Statement draft, as we want to move on to a 01 version soon. I encourage everyone to read the I-D in detail (you will find it in attachement) and to bring to the attention of the list any potential input or issue one may think of. As a starting point, here is a list of items that we are looking to address for 01 (if you have additional items in mind, please do speak up): -- ITEM 1: in Section 2 Should we list all possible scenarios and then specify a selection of targeted scenarios? Or list only targeted scenarios and suppress the Scenario Selection section? -- ITEM 2: in Section 2 Do we need to be more precise about "External Networks"? This denomination is for now used in the document to mean things as diverse as the Internet, or simply another MANET that does not merge with the first one etc. Do we need to be more precise? -- ITEM 3: overall the document Should we replace the "MANET-DAD" denomination with simple "DAD" denomination? -- ITEM 4: in Section 5 Is the phases diagram clear enough? Generic enough? Cheers Emmanuel --------------000305060606090301020808 Content-Type: text/plain; name="draft-baccelli-autoconf-problem-statement-00.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="draft-baccelli-autoconf-problem-statement-00.txt" MANET Autoconfiguration (Autoconf) E. Baccelli (Ed.) Internet-Draft INRIA Expires: January 25, 2007 K. Mase Niigata University S. Ruffino Telecom Italia S. Singh Samsung July 24, 2006 Address Autoconfiguration for MANET: Terminology and Problem Statement draft-baccelli-autoconf-statement-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on January 25, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Abstract Traditional dynamic IP address assignment solutions are not adapted to mobile ad hoc networks. This document elaborates on this problem, states the need for a new solution, and provides guidelines and Baccelli (Ed.), et al. Expires January 25, 2007 [Page 1] Internet-Draft MANET Autoconf Problem Statement July 2006 requirements for its design. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Overview of the Problem . . . . . . . . . . . . . . . . . 3 1.2. Specification of Requirements . . . . . . . . . . . . . . 3 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 5 2.1. Standalone MANET . . . . . . . . . . . . . . . . . . . . . 5 2.2. MANET Connected to an External Network . . . . . . . . . . 5 3. Deployment Scenarios Selection . . . . . . . . . . . . . . . . 6 4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 7 4.1. Specific Broacast Characteristics . . . . . . . . . . . . 7 4.2. Dynamic Topology . . . . . . . . . . . . . . . . . . . . . 7 4.3. Locally Unique Addresses, Globally Unique Addresses . . . 8 4.4. Multiple Gateways . . . . . . . . . . . . . . . . . . . . 8 5. Solution Guidelines . . . . . . . . . . . . . . . . . . . . . 9 5.1. Solution Model . . . . . . . . . . . . . . . . . . . . . . 9 5.2. General Requirements . . . . . . . . . . . . . . . . . . . 11 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 Intellectual Property and Copyright Statements . . . . . . . . . . 16 Baccelli (Ed.), et al. Expires January 25, 2007 [Page 2] Internet-Draft MANET Autoconf Problem Statement July 2006 1. Introduction Mobile ad hoc networks (i.e. MANETs, refer to RFC 2501) are networks composed of mobile devices also called nodes, that communicate over wireless media, and which dynamically self-organize multi-hop communication between each other. Each node may generate and forwards control traffic, and forward user traffic (thus potentially behaving like a router). Each node may also use the network by generating user traffic (and thus potentially behaving like a host). Some mobile ad hoc network may function regardless of the availability of a connection to the infrastructure (i.e. the Internet). More precisely, a MANET may either be disconnected from the fixed IP infrastructure (then called a standalone MANET), or connected to the fixed IP infrastructure (through one or more gateways). 1.1. Overview of the Problem Prior to participation in IP communication, each node's interface on a MANET that does not beneficiate from appropriate static configuration needs to be automatically assigned at least one IP address, that SHOULD be unique (i) locally, for communication inside the MANET, or (ii) globally, for communication accross the Internet. However, standard automatic IP address assignment solutions do not work "as-is" on MANETs due to ad hoc networks' characteristics, and new mechanisms are therefore needed. The goal of this document is to detail these problems, and to provide guidelines and requirements for solutions to be designed. 1.2. Specification of Requirements In this document, several words are used to signify the requirements of the specification. These words are often capitalized. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 1.3. Terminology In addition to the specific wording described in the previous section, this document uses the following terminology : MANET Node - A device with one or more wireless interfaces and associated IP address(es) which is used by the MANET routing protocol in use. Baccelli (Ed.), et al. Expires January 25, 2007 [Page 3] Internet-Draft MANET Autoconf Problem Statement July 2006 Local address - An IP address configured on a MANET node and valid for communication among MANET nodes that are part of the same ad hoc network. Nodes MUST NOT communicate with other nodes outside the MANET using this address. Global address - An IP address configured on a MANET node and valid for communication with nodes in the Internet, as well as internally within the MANET. Internet gateway - An edge node connected to MANET as well as to the Internet and capable of providing bidirectional connectivity between the Internet and MANET . These gateways are expected to provide topologically correct IPv6 prefixes. Internet gateways mostly run ad hoc routing protocols, but they can also run infrastructure network protocols (e.g. OSPF). Duplicate Address Detection (DAD) - The process by which a node confirms the uniqueness of an address it wishes to configure or has already configured. A node already equipped with an IP address participates in DAD in order to protect its IP address from being used by another node. Pre-service MANET-DAD - The process verifying that a tentative new IP address assignment will not create a conflict with other MANET devices. In-service MANET-DAD - The process of continuously checking that an IP address already in use has not become duplicated in the MANET. Standalone MANET - An independent ad hoc network which has no connectivity, either direct of via Internet gateways, to any other IP networks such as the Internet. Network merger - The process by which two or more ad hoc networks, previously disjoint, get connected. In general, network merger happens as a consequence of node mobility and/or wireless link environment. Network partitioning - The process by which an ad hoc network splits into two or more disconnected ad hoc networks. In general, this proccess happens as a consequence of node mobility and/or wireless link environment. Baccelli (Ed.), et al. Expires January 25, 2007 [Page 4] Internet-Draft MANET Autoconf Problem Statement July 2006 2. Deployment Scenarios Automatic configuration of IP addresses of MANET nodes (AUTOCONF) may be necessary in a number of deployment scenarios. In this section, we outline the use cases that concern and reveal problems related to the Autoconfiguration of MANET nodes. 2.1. Standalone MANET In this kind of scenario, the MANET is not connected to any external network: all traffic is generated by MANET nodes and destined to nodes in the same MANET. Nodes joining a standalone MANET can either (i) have no previous configuration, or (ii) already have one or more MANET local and/or global addresses, statically or dynamically pre- configured, to be used for IP communication. Due to partitions and mergers, standalone MANETs can often be composed with both kinds of nodes. Typical applications of this scenario include private or temporary networks, set-up in areas where neither wireless coverage nor network infrastructure exist (e.g. emergency networks for disaster recovery, or conference-room networks). 2.2. MANET Connected to an External Network In this scenario, the MANET is connected to an external network, (e.g. the Internet), by means of one or more gateways. MANET nodes can generate traffic directed to remote hosts accross the Internet. As in Section 2.1, nodes in a connected MANET could either (i) already own a global IP address, which could be used for external traffic, or (ii) have no previous configuration. Examples include public wireless networks of scattered fixed WLAN Access Points participating in the MANET of mobile users, and acting as Internet Gateways. Another example of such a scenario is the coverage extension of a fixed wide-area wireless network, where one or more mobile nodes in the MANET are connected to the Internet through technologies such as UMTS or WiMAX. Baccelli (Ed.), et al. Expires January 25, 2007 [Page 5] Internet-Draft MANET Autoconf Problem Statement July 2006 3. Deployment Scenarios Selection TBD Baccelli (Ed.), et al. Expires January 25, 2007 [Page 6] Internet-Draft MANET Autoconf Problem Statement July 2006 4. Problem Statement MANET nodes that do not beneficiate from appropriate static IP address configuration may need to automatically configure at least one unique local IPv6 address, in order to enable IP communication within the MANET. To communicate with hosts across the Internet, configuration mechanism may also need to provide one or more global IPv6 addresses. Internet Gateways typically manage topologically correct IPv6 prefixes that can be used to configure global address. They are usually managed by an administrative entity (i.e. a network operator or service provider), however they can also be opportunistic and unmanaged. Internet Gateways are typically fixed, but may also be mobile. Their presence in the MANET may be intermittent (the number of gateways may vary), and thus the availability of an Internet connection in the MANET may also be intermittent. 4.1. Specific Broacast Characteristics Traditional dynamic IP address assignment solutions, such as RFC 2462, 3315 and 2461, do not work as-is in MANETs due to these networks' unique properties, as elaborated in the following sections. These solutions assume that a broadcast direclty reaches every device on the network, whereas it is generally not the case in MANETs. Indeed, some nodes in the MANET will typically be indirectly connected to the source of the broadcast, through several intermediate peer mobile ad hoc nodes. In that respect, it is worth noting that IPv6 does not currently specify an address scope that is applicable for MANET scope. 4.2. Dynamic Topology A significant proportion of the nodes in the MANET may be mobile with wireless interface(s), leading to ever changing neighbors and neighbor sets for most MANET nodes. Therefore network topology may change rather dynamically compared to traditional networks. In particular, phenomena such as MANET paritionning (i.e. a MANET separating into two or more disconnected MANETs) and MANET merging (i.e. two or more disconnected MANETs suddenly being connected) are potential events that may greatly disrupt the uniqueness of IP addresses in use. For instance, a standalone MANET A may feature nodes that use IP addresses that are locally unique within MANET A, but this uniqueness is not guaranteed anymore if MANET A merges at some point with another MANET B. Baccelli (Ed.), et al. Expires January 25, 2007 [Page 7] Internet-Draft MANET Autoconf Problem Statement July 2006 4.3. Locally Unique Addresses, Globally Unique Addresses Moreover, even if a node uses an IP address that is locally unique within its MANET, this address may not be fit for Internet communication. Indeed, in order to be able to communicate with outside the MANET (i.e. the Internet), a node must use an IP address that must be both globally unique, as well as topologically correct, reflecting it's current location. 4.4. Multiple Gateways In the case where multiple gateways are available in the MANET, specific problems arise. One problem is the way in which global prefixes are managed within the MANET. If *one* prefix is used for the whole MANET, partitioning of the MANET may invalid routes in the Internet towards MANET nodes. On the other hand, use of *multiple* network prefixes guarantees traffic is unambiguously routed towards the gateway owning one particular prefix, but asymmetry in the nodes' choice of ingress/egress gateway can lead to non-optimal paths followed by inbound/outbound data traffic. Additional problems come from issues with current IPv6 specifications. For example, the strict application of RFC2462 may lead to check every IPv6 unicast for uniqueness : in a multiple-gateway / multiple-prefixes MANET, this could bring to a large amount of control signalling, due to frequent reconfiguration. Baccelli (Ed.), et al. Expires January 25, 2007 [Page 8] Internet-Draft MANET Autoconf Problem Statement July 2006 5. Solution Guidelines 5.1. Solution Model This section proposes a high-level conceptual view of generic MANET autoconfiguration. The different phases of the autoconfiguration process are abstracted by means of a diagram (see Fig. 1), that may serve as conceptual framework of the issues that nodes have to solve. However, note that solutions do not have to follow this framework. The purpose of this framework is merely to derive a checklist of autoconfiguration functionalities, in order to build solutions taylored for different scenarios. Basically, with regards to IP addressing, a device may find itself into the 3 different phases depicted in Fig 1. : The NO ADDRESS phase - In this phase a device does not have its own IP address. It does not participate in user data forwarding. If a routing protocol is in use in the MANET, the node does not process, generate or forward routing control messages generated by other devices. At some point, the node may generate a (tentative) address by means of a given address generation method. When it generates its address, the device should enter the ADVERTISING phase. The ADVERTISING phase - In this phase, a device does not participate in user data forwarding. If a routing protocol in in use in the MANET, the node does not forward routing control messages generated by other nodes. In this phase, the node may perform pre-service MANET-DAD by means of a given mechanism (for instance by using specific control signalling, that could be embeded in the ad hoc routing signalling in use). If pre-service MANET-DAD is used, and the device detects that its tentative address creates a conflict with other MANET devices, it should re-enters the NO ADDRESS phase. Else, if pre-service MANET-DAD completes without any address conflict being detected, or if pre-service DAD is not required, the node should enter the NORMAL phase. Note that if pre-service MANET-DAD is used, the ADVERTISING phase may have incremental substates in order to reduce the risks of routing table pollution with duplicate addresses. In the LOCAL ADVERTISEMENT phase, pre-service MANET-DAD control signalling reaches only a TTL-limited neighborhood, whereas in the GLOBAL ADVERTISEMENT phase, pre-service MANET-DAD control signalling reaches the whole MANET. Baccelli (Ed.), et al. Expires January 25, 2007 [Page 9] Internet-Draft MANET Autoconf Problem Statement July 2006 The NORMAL phase - In this phase, the device participates in IP communication normally. If a routing protocol is in use in the MANET, the device may process, generate or forward routing control messages as specified by the routing protocol in use, and may generate or forward user data. A device in this phase may perform in-service MANET-DAD by means of a given mechanism (for instance by using specific control messages that can be embeded in the routing control messages). If in-service MANET-DAD is used and if the device detects an address conflict that forces it to acquire a new address to resolve this conflict, the node should return to the NO ADDRESS phase. Note that the phases in this model are cyclic, and that a node can pop up in the MANET in any phase. For instance, a node that beneficiated from appropriate static preconfiguration may start directly in the NORMAL phase. (Address generation) (In-service MANET-DAD) +--------------+ Duplicate address +--------------+ | NO ADDRESS | detected | NORMAL | +----------| phase |<-------------------| phase |<--+ | +--------------+ +--------------+ | | ^ | | | Duplicate address | |(Tentative) address | detected Address | | generated +--------+ checked | | | | | +--------------------------------------------------------+ | | | ADVERTISING phase | | | | | | | | +--------------+ +-------------+ | | | | | LOCAL AD. | | GLOBAL AD. | | | +--->| | phase |----------------->| phase | |---+ | +--------------+ +-------------+ | +--------------------------------------------------------+ (Pre-service MANET-DAD) Fig. 1 Generic autoconfiguration phases. This conceptual framework reveals three specific potential aspects of the problem, which solutions MUST be designed take into account: - The (tentative) IP addresses generation and assignment aspect. - The pre-service DAD aspect, to somehow ensure a reasonalble belief in the fact that an address about to be assigned does not Baccelli (Ed.), et al. Expires January 25, 2007 [Page 10] Internet-Draft MANET Autoconf Problem Statement July 2006 create a conflict. - The in-service DAD aspect, to deal with conflicts that are detected between already assigned addresses. 5.2. General Requirements A solution for IP address autoconfiguration for MANETs is needed for mobile ad hoc node to acquire a correct IP address prior to their full participation in the mobile ad hoc routing protocol(s) in use. Such a solution must address the distributed, multi-hop nature of mobile ad hoc networks. Autoconfiguration mechanisms must be able to follow changes in the MANET and react to gateway connectivity loss, or to the event of new gateways becoming available, (re)configuring addresses accordingly. A solution must achieve its task with minimal overhead, due to scarse bandwidth, and minimal delay, due to the dynamicity of the topology. Baccelli (Ed.), et al. Expires January 25, 2007 [Page 11] Internet-Draft MANET Autoconf Problem Statement July 2006 6. Security Considerations Address configuration in MANET could be prone to security attacks, as in other type of IPv6 networks. Security threats to IPv6 neighbor discovery are discussed in RFC 3756: in particular, analysis includes trust model and threats for a specific ad hoc network scenario, where all the nodes share a common link (i.e. they are one hop away from each other, full-meshed connectivity is available). Although the document does not explicitly address MANETs, where nodes can be multiple hop away from each other, the trust model it provides could be valid also in the context of AUTOCONF. It is also worth noting that, in case of MANET connected to the Internet, other threats defined in RFC3756 could apply here, e.g. attacks involving routers and DoS attacks on Duplicate Address Detection procedures. Analysis has to be further extended to include threats, specific to multi-hop networks and, in particular, related to the address configuration process: security issues of routing protocol operations (e.g. how to secure routing protocol messages) are out of scope of AUTOCONF WG. Baccelli (Ed.), et al. Expires January 25, 2007 [Page 12] Internet-Draft MANET Autoconf Problem Statement July 2006 7. IANA Considerations This document does currently not specify IANA considerations. 8. References [1] Macker, J. and S. Corson, "MANET Routing Protocol Performance Issues and Evaluation Considerations", RFC 2501, January 1999. [2] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IPv6", RFC 2461, December 1998. [3] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6", RFC 3315, July 2003. [4] Narten, T. and S. Thomson, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998. Baccelli (Ed.), et al. Expires January 25, 2007 [Page 13] Internet-Draft MANET Autoconf Problem Statement July 2006 Contributors This document is the result of joint efforts, including those of the following contributers, listed in alphabetical order: C. Adjih (INRIA), T. Clausen (Ecole Polytechnique), C. Perkins (Nokia), P. Ruiz (University of Murcia), P. Stupar (Telecom Italia), D. Thaler (Microsoft). Baccelli (Ed.), et al. Expires January 25, 2007 [Page 14] Internet-Draft MANET Autoconf Problem Statement July 2006 Authors' Addresses Emmanuel Baccelli INRIA Phone: +33 1 69 33 55 11 Email: Emmanuel.Baccelli@inria.fr Kenichi Mase Niigata University Phone: +81 25 262 7446 Email: Mase@ie.niigata-u.ac.jp Simone Ruffino Telecom Italia Phone: +39 011 228 7566 Email: Simone.Ruffino@telecomitalia.it Shubhranshu Singh Samsung Phone: +82 31 280 9569 Email: Shubranshu@gmail.com Baccelli (Ed.), et al. Expires January 25, 2007 [Page 15] Internet-Draft MANET Autoconf Problem Statement July 2006 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Baccelli (Ed.), et al. Expires January 25, 2007 [Page 16] --------------000305060606090301020808 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf --------------000305060606090301020808-- From autoconf-bounces@ietf.org Wed Jul 26 12:12:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5lzW-0002lo-RD; Wed, 26 Jul 2006 12:12:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5lzU-0002l9-Gc; Wed, 26 Jul 2006 12:12:08 -0400 Received: from smtp1.bae.co.uk ([20.133.0.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5lzT-0007Pe-3n; Wed, 26 Jul 2006 12:12:08 -0400 Received: from ngbaux (ngbaux.msd.bae.co.uk [141.245.68.234]) by smtp1.bae.co.uk (Switch-3.1.9/Switch-3.1.9) with ESMTP id k6QGBugi018848; Wed, 26 Jul 2006 17:12:05 +0100 (BST) Received: from glkas0002.GREENLNK.NET ([10.15.184.52]) by ngbaux.net.bae.co.uk (PMDF V5.2-33 #44998) with ESMTP id <0J30000KXQIPK5@ngbaux.net.bae.co.uk>; Wed, 26 Jul 2006 17:16:01 +0100 (BST) Received: from glkms0002.GREENLNK.NET ([10.15.184.2]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Wed, 26 Jul 2006 17:11:53 +0100 Received: from glkms0008.GREENLNK.NET ([10.15.184.8]) by glkms0002.GREENLNK.NET with Microsoft SMTPSVC(5.0.2195.6713); Wed, 26 Jul 2006 17:11:53 +0100 Date: Wed, 26 Jul 2006 17:11:51 +0100 From: "Dearlove, Christopher (UK)" Subject: RE: [manet] RE: [Autoconf] Fwd: I-DACTION:draft-chakeres-manet-iana-00.txt To: Joe Macker , "Francisco J. Ros" , manet@ietf.org Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6556.0 Content-type: text/plain; charset="us-ascii" Content-transfer-encoding: quoted-printable Thread-Topic: [manet] RE: [Autoconf] Fwd: I-DACTION:draft-chakeres-manet-iana-00.txt Thread-Index: AcawlY/5bG4fp7UXRQeHDAkfEKW/gAABZZYwAAwEkoAAAFOMEA== Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 26 Jul 2006 16:11:53.0297 (UTC) FILETIME=[3570BC10:01C6B0CE] X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: autoconf@ietf.org, Thomas Clausen X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ad Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: autoconf-bounces@ietf.org > I just want to clarify that SMF has three neighborhood discovery modes > defined in -02. The writeup below sounds like its always required to run > NHDP separately. So SMF does not need to see HELLOs in mode (2) or (1) just > for clarification. Thanks for that. I was of course just considering your case (3), as it's the one that poses the biggest challenges. But (partly because it wasn't relevant to my point, and partly because I'd forgotten all were actually defined in SMF -02) I didn't spell that out. But for case (3) there are the challenges I noted (or at least I think there are - simplification without loss of capability very welcome). > 1. Classical Flooding (CF) mode with no requirement for discovery or > knowledge of neighborhood topology, > > 2. External control mode where an external process dynamically sets > the local SMF relay status (e.g., Early SMF prototypes have > leveraged neighborhood toplogy information collected by MANET > unicast routing protocols such as OLSRv2 or Manet-OSPF ), and I think something got lost here, but nothing critical to this point. > 3. Independent operating mode using a neighborhood discovery > ("hello") protocol to collect the local topology information > required for the various CDS algorithm modes discussed in the > Appendices.=0D ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Wed Jul 26 16:31:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5q2H-0001lv-Cq; Wed, 26 Jul 2006 16:31:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5q2G-0001lm-MW for autoconf@ietf.org; Wed, 26 Jul 2006 16:31:16 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5kcx-0007Fd-R6 for autoconf@ietf.org; Wed, 26 Jul 2006 10:44:47 -0400 Received: from mailout1.samsung.com ([203.254.224.24]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G5kYq-0001L2-32 for autoconf@ietf.org; Wed, 26 Jul 2006 10:40:34 -0400 Received: from ep_mmp2 (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0J3000MBXM3EMD@mailout1.samsung.com> for autoconf@ietf.org; Wed, 26 Jul 2006 23:40:26 +0900 (KST) Received: from Shubhranshu ([107.108.4.124]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0J30001SXM3DRR@mmp2.samsung.com> for autoconf@ietf.org; Wed, 26 Jul 2006 23:40:26 +0900 (KST) Date: Wed, 26 Jul 2006 20:11:53 +0530 From: Shubhranshu Subject: Re: [Autoconf] Fwd: I-D ACTION:draft-chakeres-manet-iana-00.txt To: Christophe Jelger Message-id: <005e01c6b0c1$a3af01d0$7c046c6b@sisodomain.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Mailer: Microsoft Outlook Express 6.00.2900.2869 Content-type: text/plain; reply-type=response; charset=iso-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <374005f30607241458o5dc932ack48945384b224e22@mail.gmail.com> <44C5D9B3.7040006@unibas.ch> <024e01c6aff4$4861ae40$7c046c6b@sisodomain.com> <44C6327B.9090003@unibas.ch> X-Spam-Score: -2.6 (--) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: autoconf@ietf.org X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ad Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: autoconf-bounces@ietf.org Fred, Christophe, See inline comments: ----- Original Message ----- From: "Christophe Jelger" To: "Shubhranshu" Cc: Sent: Tuesday, July 25, 2006 8:32 PM Subject: Re: [Autoconf] Fwd: I-D ACTION:draft-chakeres-manet-iana-00.txt > Hello Shubhranshu, > > The (simple) idea is that a distributed address assignment scheme or > rather an address collision resolution protocol could use something like > ff0x::MANET-AUTOCONF. > My point was (and Christophe already expressed his opinion below) - why not ff02::1 or ff02::2 or ff05::2 would serve the purpose in this case and in draft-templin-autoconf-dhcp-01 ? Seeking new addresses implies that existing addresses cannot be used or not preferred for any particular case. > Note that one could also use the all_nodes address ff02::1 and a > dedicated port number but this means that "non-interested" nodes will > also have to process the packets. Using ff0x::MANET-AUTOCONF is more > selective than sending to "everybody that listens". > Regarding your comment on existing proposals, it's clearly not a > requirement but rather an optimization. Note that for both routing and > address configuration this is exactly what is currently being done > (there are specific multicast addresses for OSPF, RIP, PIM, MLDv2, DHCP, > mDNS). Another point was - if the existing addresses would not serve the purpose then the WG needs to converge on specific cases, which could even mean identifying those "non-interested" nodes, as you mentioned above. - Shubhranshu > > regards, > Christophe _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Wed Jul 26 17:13:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5qgm-0004aH-PB; Wed, 26 Jul 2006 17:13:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5qgl-0004UX-0g for autoconf@ietf.org; Wed, 26 Jul 2006 17:13:07 -0400 Received: from slb-smtpout-01.boeing.com ([130.76.64.48] helo=slb-smtpout-01.ns.cs.boeing.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5qgi-0000KS-MK for autoconf@ietf.org; Wed, 26 Jul 2006 17:13:06 -0400 Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by slb-smtpout-01.ns.cs.boeing.com (8.13.6/8.13.6/TEST_SMTPIN) with ESMTP id k6QLCfSr007338 for ; Wed, 26 Jul 2006 14:12:47 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id k6QLCwo05299 for ; Wed, 26 Jul 2006 16:12:58 -0500 (CDT) Received: from XCH-NW-5V2.nw.nos.boeing.com ([130.247.55.45]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Jul 2006 14:12:56 -0700 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 Subject: RE: [Autoconf] Problem Statement: input and discussions on the list Date: Wed, 26 Jul 2006 14:12:54 -0700 Message-ID: <8BA40F9A33179E4E877E37D7D5E9D82D019BBF0A@XCH-NW-5V2.nw.nos.boeing.com> In-Reply-To: <44C76397.3000701@inria.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Autoconf] Problem Statement: input and discussions on the list Thread-Index: AcawzV1CS8te1iONSh+oiSX/HvbtNQAKV1+A From: "Yi, Seung" To: X-OriginalArrivalTime: 26 Jul 2006 21:12:56.0548 (UTC) FILETIME=[43FA1A40:01C6B0F8] X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ad Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: autoconf-bounces@ietf.org Hi, all, I got a question and a comment. First, the question. What would be the utility of the TTL-limited MANET-DAD described in Section 5.1, Advertising phase. I understand the utility of MANET-wide DAD but I don't see the point of having a TTL-limited DAD support. What am I missing? Now the comments. I don't think LOCAL AD phase and GLOBAL AD phase should be disjoint as pictured in the diagram in Section 5. Why shouldn't a MANET node configure a MANET-local address and also a globally routable address to a MANET interface at the same time? For ITEM2, the document reads to me as it primarily considers some kind of hierarchical network structure where a MANET attaches to a higher-tier network as in the case where a MANET attaches to the Internet as a stub. Related to that, are there any proposals to designate the boundary or membership of a particular MANET? For example, when a MANET splits into two, do they become different MANETs or stay as the same MANET but partitioned? And when they merge back to one, how would one know the two used to belong in the same MANET? Will this have to be enforced by address assignment or by some external mechanism? I'm just wondering if anyone has some insights to share.=20 Regards, - Seung -----Original Message----- From: Emmanuel Baccelli [mailto:Emmanuel.Baccelli@inria.fr]=20 Sent: Wednesday, July 26, 2006 5:44 AM To: autoconf@ietf.org Subject: [Autoconf] Problem Statement: input and discussions on the list Hi all, I would like to stir up the discussion about the Problem Statement draft, as we want to move on to a 01 version soon. I encourage everyone to read the I-D in detail (you will find it in attachement) and to bring to the attention of the list any potential input or issue one may think of. As a starting point, here is a list of items that we are looking to address for 01 (if you have additional items in mind, please do speak up): -- ITEM 1: in Section 2 Should we list all possible scenarios and then specify a selection of targeted scenarios? Or list only targeted scenarios and suppress the Scenario Selection section? -- ITEM 2: in Section 2 Do we need to be more precise about "External Networks"? This denomination is for now used in the document to mean things as diverse as the Internet, or simply another MANET that does not merge with the first one etc. Do we need to be more precise? -- ITEM 3: overall the document Should we replace the "MANET-DAD" denomination with simple "DAD" =20 denomination? -- ITEM 4: in Section 5 Is the phases diagram clear enough? Generic enough? Cheers Emmanuel _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Wed Jul 26 21:40:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5urc-0000EO-0L; Wed, 26 Jul 2006 21:40:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5ura-0000EE-Ab for autoconf@ietf.org; Wed, 26 Jul 2006 21:40:34 -0400 Received: from mailgate.cc.niigata-u.ac.jp ([133.35.14.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5urY-0003wW-3E for autoconf@ietf.org; Wed, 26 Jul 2006 21:40:33 -0400 Received: from mailgate.cc.niigata-u.ac.jp (mailgate.cc.niigata-u.ac.jp [127.0.0.1]) by localhost.cc.niigata-u.ac.jp (Postfix) with ESMTP id 67E72F0144 for ; Thu, 27 Jul 2006 10:45:11 +0900 (JST) Received: from chamame.ie.niigata-u.ac.jp (chamame.ie.niigata-u.ac.jp [133.35.169.34]) by mailgate.cc.niigata-u.ac.jp (Postfix) with SMTP id 5D68DF011F for ; Thu, 27 Jul 2006 10:45:11 +0900 (JST) Received: (qmail 9951 invoked from network); 27 Jul 2006 10:40:21 +0900 Received: from unknown (HELO MS191.ie.niigata-u.ac.jp) (133.35.156.62) by chamame.ie.niigata-u.ac.jp with SMTP; 27 Jul 2006 10:40:21 +0900 Message-Id: <5.0.2.5.2.20060727102848.06f5c3f0@127.0.0.1> X-Sender: mh.ie.niigata-u.ac.jp:mase:apop@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.0.2-J Date: Thu, 27 Jul 2006 10:40:18 +0900 To: "Yi, Seung" , From: mase Subject: RE: [Autoconf] Problem Statement: input and discussions on the list In-Reply-To: <8BA40F9A33179E4E877E37D7D5E9D82D019BBF0A@XCH-NW-5V2.nw.nos .boeing.com> References: <44C76397.3000701@inria.fr> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Cc: X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ad Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: autoconf-bounces@ietf.org Dear Seung, Thank you for your comments. Please see comments in line. At 14:12 06/07/26 -0700, Yi, Seung wrote: >Hi, all, > >I got a question and a comment. > >First, the question. What would be the utility of the TTL-limited >MANET-DAD described in Section 5.1, Advertising phase. I understand the >utility of MANET-wide DAD but I don't see the point of having a >TTL-limited DAD support. What am I missing? Routing protocol may use TTL-limited routing control messages, such as Hello messages in proactive routing protocols and TTL-limited RREQ in reactive routing protocols. A tentative address can be advertised using these control messages, leading to TTL-limited DAD. >Now the comments. I don't think LOCAL AD phase and GLOBAL AD phase >should be disjoint as pictured in the diagram in Section 5. Why >shouldn't a MANET node configure a MANET-local address and also a >globally routable address to a MANET interface at the same time? Global AD means a tentative address advertised MANET-wide, leading to possible MANET-wide DAD. It is not related to whether address is MANET-local or global. Regard, Kenichi >For ITEM2, the document reads to me as it primarily considers some kind >of hierarchical network structure where a MANET attaches to a >higher-tier network as in the case where a MANET attaches to the >Internet as a stub. Related to that, are there any proposals to >designate the boundary or membership of a particular MANET? For example, >when a MANET splits into two, do they become different MANETs or stay as >the same MANET but partitioned? And when they merge back to one, how >would one know the two used to belong in the same MANET? Will this have >to be enforced by address assignment or by some external mechanism? I'm >just wondering if anyone has some insights to share. > >Regards, > >- Seung > >-----Original Message----- >From: Emmanuel Baccelli [mailto:Emmanuel.Baccelli@inria.fr] >Sent: Wednesday, July 26, 2006 5:44 AM >To: autoconf@ietf.org >Subject: [Autoconf] Problem Statement: input and discussions on the list > >Hi all, > >I would like to stir up the discussion about the Problem Statement >draft, as we want to move on to a 01 version soon. I encourage everyone >to read the I-D in detail (you will find it in attachement) and to bring >to the attention of the list any potential input or issue one may think >of. As a starting point, here is a list of items that we are looking to >address for 01 (if you have additional items in mind, please do speak >up): > > >-- ITEM 1: >in Section 2 >Should we list all possible scenarios and then specify a selection of >targeted scenarios? Or list only targeted scenarios and suppress the >Scenario Selection section? > >-- ITEM 2: >in Section 2 >Do we need to be more precise about "External Networks"? This >denomination is for now used in the document to mean things as diverse >as the Internet, or simply another MANET that does not merge with the >first one etc. Do we need to be more precise? > >-- ITEM 3: >overall the document >Should we replace the "MANET-DAD" denomination with simple "DAD" >denomination? > >-- ITEM 4: >in Section 5 >Is the phases diagram clear enough? Generic enough? > > >Cheers >Emmanuel > > > > > >_______________________________________________ >Autoconf mailing list >Autoconf@ietf.org >https://www1.ietf.org/mailman/listinfo/autoconf _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Wed Jul 26 21:49:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5uzs-0000Y3-OX; Wed, 26 Jul 2006 21:49:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5uzr-0000XV-Jk for autoconf@ietf.org; Wed, 26 Jul 2006 21:49:07 -0400 Received: from stl-smtpout-01.boeing.com ([130.76.96.56] helo=stl-smtpout-01.ns.cs.boeing.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5uzo-0006hf-Bx for autoconf@ietf.org; Wed, 26 Jul 2006 21:49:07 -0400 Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by stl-smtpout-01.ns.cs.boeing.com (8.13.6/8.13.6/TEST_SMTPIN) with ESMTP id k6R1n1np002890; Wed, 26 Jul 2006 20:49:02 -0500 (CDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id k6R1n0o02544; Wed, 26 Jul 2006 20:49:00 -0500 (CDT) Received: from XCH-NW-5V2.nw.nos.boeing.com ([130.247.55.45]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Jul 2006 18:49:00 -0700 Received: from 128.207.41.5 ([128.207.41.5]) by XCH-NW-5V2.nw.nos.boeing.com ([130.247.55.50]) with Microsoft Exchange Server HTTP-DAV ; Thu, 27 Jul 2006 01:49:00 +0000 User-Agent: Microsoft-Entourage/11.2.5.060620 Date: Wed, 26 Jul 2006 18:49:21 -0700 Subject: Re: [Autoconf] Problem Statement: input and discussions on the list From: Seung Yi To: mase , Message-ID: Thread-Topic: [Autoconf] Problem Statement: input and discussions on the list Thread-Index: AcaxHuEUH2UPnB0SEduPtgAKldExRg== In-Reply-To: <5.0.2.5.2.20060727102848.06f5c3f0@127.0.0.1> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 27 Jul 2006 01:49:00.0332 (UTC) FILETIME=[D4C2F6C0:01C6B11E] X-Spam-Score: 1.5 (+) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Cc: X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ad Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: autoconf-bounces@ietf.org Dear Kenichi, Thank you for your reply. I can see that there is a possibility to piggyback DAD messages to RREQ. But Would that be useful? One would be able to discover that a tentative address is not being used within the given TTL by doing so but I'm not sure what that buys him. I guess I understood it wrong. Could you provide some more details on the Local AD case? When would that be used and for what purpose? I can see Global AD is basically when a node does the MANET-wide DAD. I'm not quite sure if I understood the Local AD phase. Thanks, - Seung On 7/26/06 6:40 PM, "mase" wrote: > Dear Seung, > > Thank you for your comments. Please see comments in line. > > At 14:12 06/07/26 -0700, Yi, Seung wrote: >> Hi, all, >> >> I got a question and a comment. >> >> First, the question. What would be the utility of the TTL-limited >> MANET-DAD described in Section 5.1, Advertising phase. I understand the >> utility of MANET-wide DAD but I don't see the point of having a >> TTL-limited DAD support. What am I missing? > > Routing protocol may use TTL-limited routing control messages, such as > Hello messages in proactive routing protocols and TTL-limited RREQ in > reactive routing protocols. A tentative address can be advertised using > these control messages, leading to TTL-limited DAD. > > >> Now the comments. I don't think LOCAL AD phase and GLOBAL AD phase >> should be disjoint as pictured in the diagram in Section 5. Why >> shouldn't a MANET node configure a MANET-local address and also a >> globally routable address to a MANET interface at the same time? > > Global AD means a tentative address advertised MANET-wide, leading to > possible MANET-wide DAD. It is not related to whether address is > MANET-local or global. > > Regard, > Kenichi > > >> For ITEM2, the document reads to me as it primarily considers some kind >> of hierarchical network structure where a MANET attaches to a >> higher-tier network as in the case where a MANET attaches to the >> Internet as a stub. Related to that, are there any proposals to >> designate the boundary or membership of a particular MANET? For example, >> when a MANET splits into two, do they become different MANETs or stay as >> the same MANET but partitioned? And when they merge back to one, how >> would one know the two used to belong in the same MANET? Will this have >> to be enforced by address assignment or by some external mechanism? I'm >> just wondering if anyone has some insights to share. >> >> Regards, >> >> - Seung >> >> -----Original Message----- >> From: Emmanuel Baccelli [mailto:Emmanuel.Baccelli@inria.fr] >> Sent: Wednesday, July 26, 2006 5:44 AM >> To: autoconf@ietf.org >> Subject: [Autoconf] Problem Statement: input and discussions on the list >> >> Hi all, >> >> I would like to stir up the discussion about the Problem Statement >> draft, as we want to move on to a 01 version soon. I encourage everyone >> to read the I-D in detail (you will find it in attachement) and to bring >> to the attention of the list any potential input or issue one may think >> of. As a starting point, here is a list of items that we are looking to >> address for 01 (if you have additional items in mind, please do speak >> up): >> >> >> -- ITEM 1: >> in Section 2 >> Should we list all possible scenarios and then specify a selection of >> targeted scenarios? Or list only targeted scenarios and suppress the >> Scenario Selection section? >> >> -- ITEM 2: >> in Section 2 >> Do we need to be more precise about "External Networks"? This >> denomination is for now used in the document to mean things as diverse >> as the Internet, or simply another MANET that does not merge with the >> first one etc. Do we need to be more precise? >> >> -- ITEM 3: >> overall the document >> Should we replace the "MANET-DAD" denomination with simple "DAD" >> denomination? >> >> -- ITEM 4: >> in Section 5 >> Is the phases diagram clear enough? Generic enough? >> >> >> Cheers >> Emmanuel >> >> >> >> >> >> _______________________________________________ >> Autoconf mailing list >> Autoconf@ietf.org >> https://www1.ietf.org/mailman/listinfo/autoconf > _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Thu Jul 27 00:13:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5xFa-00008y-RU; Thu, 27 Jul 2006 00:13:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5xFZ-00007M-Bs for autoconf@ietf.org; Thu, 27 Jul 2006 00:13:29 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5xFZ-0001Bp-9h for autoconf@ietf.org; Thu, 27 Jul 2006 00:13:29 -0400 Received: from mailgate.cc.niigata-u.ac.jp ([133.35.14.100]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G5x7O-00004q-4v for autoconf@ietf.org; Thu, 27 Jul 2006 00:05:04 -0400 Received: from mailgate.cc.niigata-u.ac.jp (mailgate.cc.niigata-u.ac.jp [127.0.0.1]) by localhost.cc.niigata-u.ac.jp (Postfix) with ESMTP id 6F191F0149 for ; Thu, 27 Jul 2006 13:09:33 +0900 (JST) Received: from chamame.ie.niigata-u.ac.jp (chamame.ie.niigata-u.ac.jp [133.35.169.34]) by mailgate.cc.niigata-u.ac.jp (Postfix) with SMTP id 641E3F00FF for ; Thu, 27 Jul 2006 13:09:33 +0900 (JST) Received: (qmail 15368 invoked from network); 27 Jul 2006 13:04:49 +0900 Received: from unknown (HELO MS191.ie.niigata-u.ac.jp) (133.35.156.62) by chamame.ie.niigata-u.ac.jp with SMTP; 27 Jul 2006 13:04:49 +0900 Message-Id: <5.0.2.5.2.20060727114815.0392cbb0@127.0.0.1> X-Sender: mh.ie.niigata-u.ac.jp:mase:apop@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.0.2-J Date: Thu, 27 Jul 2006 13:04:46 +0900 To: Seung Yi , From: mase Subject: Re: [Autoconf] Problem Statement: input and discussions on thelist In-Reply-To: References: <5.0.2.5.2.20060727102848.06f5c3f0@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: -2.6 (--) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c Cc: X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ad Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: autoconf-bounces@ietf.org Dear Seung, At 18:49 06/07/26 -0700, Seung Yi wrote: >Dear Kenichi, > >Thank you for your reply. I can see that there is a possibility to piggyback >DAD messages to RREQ. But Would that be useful? One would be able to >discover that a tentative address is not being used within the given TTL by >doing so but I'm not sure what that buys him. > >I guess I understood it wrong. Could you provide some more details on the >Local AD case? When would that be used and for what purpose? I can see >Global AD is basically when a node does the MANET-wide DAD. I'm not quite >sure if I understood the Local AD phase. I understand your question. If perfect DAD for a tentative address is required, a node may skip Local AD and directly proceed to Global AD. If applications need only limited number of hops communication, only Local AD may be sufficient and Global AD may be skipped. Anyway, Figure 1 is a reference model, where all possible phases are included. It doesn't mean all phases and sub-phases are useful for a given application and scenario. Cheers, Kenichi >Thanks, > >- Seung > > >On 7/26/06 6:40 PM, "mase" wrote: > > > Dear Seung, > > > > Thank you for your comments. Please see comments in line. > > > > At 14:12 06/07/26 -0700, Yi, Seung wrote: > >> Hi, all, > >> > >> I got a question and a comment. > >> > >> First, the question. What would be the utility of the TTL-limited > >> MANET-DAD described in Section 5.1, Advertising phase. I understand the > >> utility of MANET-wide DAD but I don't see the point of having a > >> TTL-limited DAD support. What am I missing? > > > > Routing protocol may use TTL-limited routing control messages, such as > > Hello messages in proactive routing protocols and TTL-limited RREQ in > > reactive routing protocols. A tentative address can be advertised using > > these control messages, leading to TTL-limited DAD. > > > > > >> Now the comments. I don't think LOCAL AD phase and GLOBAL AD phase > >> should be disjoint as pictured in the diagram in Section 5. Why > >> shouldn't a MANET node configure a MANET-local address and also a > >> globally routable address to a MANET interface at the same time? > > > > Global AD means a tentative address advertised MANET-wide, leading to > > possible MANET-wide DAD. It is not related to whether address is > > MANET-local or global. > > > > Regard, > > Kenichi > > > > > >> For ITEM2, the document reads to me as it primarily considers some kind > >> of hierarchical network structure where a MANET attaches to a > >> higher-tier network as in the case where a MANET attaches to the > >> Internet as a stub. Related to that, are there any proposals to > >> designate the boundary or membership of a particular MANET? For example, > >> when a MANET splits into two, do they become different MANETs or stay as > >> the same MANET but partitioned? And when they merge back to one, how > >> would one know the two used to belong in the same MANET? Will this have > >> to be enforced by address assignment or by some external mechanism? I'm > >> just wondering if anyone has some insights to share. > >> > >> Regards, > >> > >> - Seung > >> > >> -----Original Message----- > >> From: Emmanuel Baccelli [mailto:Emmanuel.Baccelli@inria.fr] > >> Sent: Wednesday, July 26, 2006 5:44 AM > >> To: autoconf@ietf.org > >> Subject: [Autoconf] Problem Statement: input and discussions on the list > >> > >> Hi all, > >> > >> I would like to stir up the discussion about the Problem Statement > >> draft, as we want to move on to a 01 version soon. I encourage everyone > >> to read the I-D in detail (you will find it in attachement) and to bring > >> to the attention of the list any potential input or issue one may think > >> of. As a starting point, here is a list of items that we are looking to > >> address for 01 (if you have additional items in mind, please do speak > >> up): > >> > >> > >> -- ITEM 1: > >> in Section 2 > >> Should we list all possible scenarios and then specify a selection of > >> targeted scenarios? Or list only targeted scenarios and suppress the > >> Scenario Selection section? > >> > >> -- ITEM 2: > >> in Section 2 > >> Do we need to be more precise about "External Networks"? This > >> denomination is for now used in the document to mean things as diverse > >> as the Internet, or simply another MANET that does not merge with the > >> first one etc. Do we need to be more precise? > >> > >> -- ITEM 3: > >> overall the document > >> Should we replace the "MANET-DAD" denomination with simple "DAD" > >> denomination? > >> > >> -- ITEM 4: > >> in Section 5 > >> Is the phases diagram clear enough? Generic enough? > >> > >> > >> Cheers > >> Emmanuel > >> > >> > >> > >> > >> > >> _______________________________________________ > >> Autoconf mailing list > >> Autoconf@ietf.org > >> https://www1.ietf.org/mailman/listinfo/autoconf > > _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Thu Jul 27 16:29:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6CUK-0006oc-FG; Thu, 27 Jul 2006 16:29:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6CUJ-0006mt-H2 for autoconf@ietf.org; Thu, 27 Jul 2006 16:29:43 -0400 Received: from blv-smtpout-01.boeing.com ([130.76.32.69] helo=blv-smtpout-01.ns.cs.boeing.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6CUG-0002V2-5o for autoconf@ietf.org; Thu, 27 Jul 2006 16:29:43 -0400 Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by blv-smtpout-01.ns.cs.boeing.com (8.13.6/8.13.6/TEST_SMTPIN) with ESMTP id k6RKTbBZ007820; Thu, 27 Jul 2006 13:29:38 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id k6RKTbo27125; Thu, 27 Jul 2006 15:29:37 -0500 (CDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Jul 2006 13:29:31 -0700 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 Subject: RE: [Autoconf] Fwd: I-D ACTION:draft-chakeres-manet-iana-00.txt Date: Thu, 27 Jul 2006 13:28:41 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A101774190@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <005e01c6b0c1$a3af01d0$7c046c6b@sisodomain.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Autoconf] Fwd: I-D ACTION:draft-chakeres-manet-iana-00.txt Thread-Index: Acaw8noL5U2+mqT7T3yz+YJ9DDSjmAAxKXOw From: "Templin, Fred L" To: "Shubhranshu" , "Christophe Jelger" X-OriginalArrivalTime: 27 Jul 2006 20:29:31.0010 (UTC) FILETIME=[5D5E4E20:01C6B1BB] X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: autoconf@ietf.org X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ad Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: autoconf-bounces@ietf.org Shubhranshu, > My point was (and Christophe already expressed his opinion below) > - why not ff02::1 or ff02::2 or ff05::2 would serve the purpose > in this case and in draft-templin-autoconf-dhcp-01 ? Seeking > new addresses implies that existing addresses cannot be used > or not preferred for any particular case. I tend to agree with Christophe's point (below) that a more-specific multicast group might be more efficient than 'All Routers', since not everyone has to listen and/or less of the topology might be disturbed.=20 >> Note that one could also use the all_nodes address ff02::1 and a=20 >> dedicated port number but this means that "non-interested" nodes will >> also have to process the packets. Using ff0x::MANET-AUTOCONF is more=20 >> selective than sending to "everybody that listens".=20 >> Regarding your comment on existing proposals, it's clearly not a=20 >> requirement but rather an optimization. Note that for both routing and=20 >> address configuration this is exactly what is currently being done=20 >> (there are specific multicast addresses for OSPF, RIP, PIM, MLDv2, DHCP,=20 >> mDNS). > > Another point was - if the existing addresses would not serve the > purpose then the WG needs to converge on specific cases, which > could even mean identifying those "non-interested" nodes, as you > mentioned above. Yes, WG convergence would be a good thing, with an eye toward efficiency and correct mapping to the MANET architecture. Fred fred.l.templin@boeing.com - Shubhranshu >=20 > regards, > Christophe _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf