From mailman-bounces@core3.amsl.com Fri Feb 1 06:04:24 2008 Return-Path: X-Original-To: ietfarch-autoconf-archive@core3.amsl.com Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4EBD1296755 for ; Fri, 1 Feb 2008 06:00:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.588 X-Spam-Level: X-Spam-Status: No, score=-2.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vwrEKBCciZQi for ; Fri, 1 Feb 2008 06:00:55 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 93641295411 for ; Fri, 1 Feb 2008 05:37:26 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: ietf.org mailing list memberships reminder From: mailman-owner@ietf.org To: autoconf-archive@megatron.ietf.org X-No-Archive: yes Message-ID: Date: Fri, 01 Feb 2008 05:05:25 -0800 Precedence: bulk X-BeenThere: mailman@core3.amsl.com X-Mailman-Version: 2.1.9 List-Id: X-List-Administrivia: yes Sender: mailman-bounces@core3.amsl.com Errors-To: mailman-bounces@core3.amsl.com This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, mailman-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@ietf.org. Thanks! http://www.ietf.org/mailman/options/autoconf/autoconf-archive%40megatron.ietf.org From mailman-bounces@core3.amsl.com Fri Feb 1 06:11:48 2008 Return-Path: X-Original-To: ietfarch-autoconf-archive@core3.amsl.com Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8302428E8CA for ; Fri, 1 Feb 2008 06:03:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.588 X-Spam-Level: X-Spam-Status: No, score=-2.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id APhgjtPCd-XJ for ; Fri, 1 Feb 2008 06:03:17 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2324C29691F for ; Fri, 1 Feb 2008 05:37:48 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: ietf.org mailing list memberships reminder From: mailman-owner@ietf.org To: autoconf-archive@megatron.ietf.org X-No-Archive: yes Message-ID: Date: Fri, 01 Feb 2008 05:05:26 -0800 Precedence: bulk X-BeenThere: mailman@core3.amsl.com X-Mailman-Version: 2.1.9 List-Id: X-List-Administrivia: yes Sender: mailman-bounces@core3.amsl.com Errors-To: mailman-bounces@core3.amsl.com This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, mailman-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@ietf.org. Thanks! http://www.ietf.org/mailman/options/autoconf/autoconf-archive%40megatron.ietf.org From autoconf-bounces@ietf.org Thu Feb 7 00:22:47 2008 Return-Path: X-Original-To: ietfarch-autoconf-archive@core3.amsl.com Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9AED53A71B9; Thu, 7 Feb 2008 00:22:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.899 X-Spam-Level: X-Spam-Status: No, score=-2.899 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_18=0.6, J_CHICKENPOX_33=0.6, J_CHICKENPOX_91=0.6, RCVD_IN_DNSWL_MED=-4] Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iNrbpw+oSzU7; Thu, 7 Feb 2008 00:22:46 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F0933A6D02; Thu, 7 Feb 2008 00:22:46 -0800 (PST) X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B69FD3A6D02 for ; Thu, 7 Feb 2008 00:22:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from core3.amsl.com ([127.0.0.1]) by localhost (mail.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ug4WLxj9Zo4F for ; Thu, 7 Feb 2008 00:22:43 -0800 (PST) Received: from mail.um.es (mail.um.es [155.54.212.109]) by core3.amsl.com (Postfix) with ESMTP id 5C6A43A67D5 for ; Thu, 7 Feb 2008 00:22:42 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.um.es (Postfix) with ESMTP id 7A9BF656DD for ; Thu, 7 Feb 2008 09:24:11 +0100 (CET) X-Virus-Scanned: by amavisd-new-2.4.2 (20060627) (Debian) at xenon1.telemat.um.es Received: from mail.um.es ([127.0.0.1]) by localhost (xenon1.telemat.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id VvUtcvA9ir4H for ; Thu, 7 Feb 2008 09:24:10 +0100 (CET) Received: from inf-205-58.um.es (inf-205-58.um.es [155.54.205.58]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: pedrom@smtp.um.es) by mail.um.es (Postfix) with ESMTP id 962AE656D7 for ; Thu, 7 Feb 2008 09:24:10 +0100 (CET) Message-ID: <47AAC029.8030908@dif.um.es> Date: Thu, 07 Feb 2008 09:24:09 +0100 From: "Pedro M. Ruiz" User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: autoconf@ietf.org Subject: [Autoconf] [CFP] IEEE MASS 2008: Submission open (deadline March 14, 2008) X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org ------------------------------------------------------- CALL FOR PAPERS IEEE MASS 2008 Fifth IEEE International Conference on Mobile Ad-hoc and Sensor Systems September 29 ? October 2, 2008 Hilton Atlanta Atlanta, GA, USA http://www.cse.psu.edu/IEEEMASS08/ Sponsors: IEEE, IEEE Computer Society, IEEE Technical Committee on Distributed Processing, IEEE Technical Committee on Simulation, and IEEE Technical Committee on Computer Communications Wireless ad-hoc communication has applications in a variety of environments, such as conferences, hospitals, battlefields and disaster-recovery/rescue operations, and is also being actively investigated as an alternative paradigm for Internet connectivity in both urban and rural areas. Wireless sensor and actuator networks are also being deployed for enhancing industrial control processes and supply-chains, and for various forms of environmental monitoring. The IEEE MASS 2008 conference is the fifth edition of MASS and aims at addressing advances in research on multi-hop ad-hoc and sensor networks, covering topics ranging from technology issues to applications and test-bed development. IEEE MASS 2008 solicits riginal, unpublished contributions in all aspects of (mobile) ad-hoc networks and wireless sensor networks (WSN), systems and applications. Submitted articles must not be concurrently considered elsewhere for publication. Extended versions of selected papers will be considered for fast track publication in the Pervasive and Mobile Computing Journal (www.elsevier.come/locate/pmc). Scope: Topics include, but are not limited to: - Physical layer impact on higher layers in ad-hoc networks and WSNs - Directional / smart antennas - Multi-channel, multi-radio and MIMO technologies - MAC protocols (802.11, 802.15.4, UWB) - Wireless mesh networks and cognitive networks - P2P/overlay/content distribution architectures for wireless ad hoc networks - Delay tolerant networks and opportunistic networking - Vehicular networks and protocols - Mobile/robotic sensor networks - Power-aware architectures, algorithms and protocols design - Clustering, topology control, coverage and connectivity issues - Routing protocols (unicast, multicast, broadcast, geocast) - Data transport, management and information scheduling - Data gathering, fusion, and dissemination in WSNs - Localization, synchronization and cooperative sensing in WSNs - Sensor networks and pervasive infrastructures - Capacity planning and admission control in ad-hoc networks - Handoff / mobility management and seamless internetworking - Resource management and wireless QoS Provisioning - Cross layer design and optimization - Incentive-based and game-theoretic approaches in ad-hoc networks - Reliability, resiliency and fault tolerance techniques - Security, privacy, and trust issues - Management and monitoring of ad-hoc and sensor networks - Operating systems and middleware support - Novel applications and architectures for WSNs - Modeling, analysis and performance evaluation - Measurements and experience from experimental systems and test-beds Submission Guidelines: All submissions must be full papers in PDF format and uploaded on EDAS. Direct link for paper submission (abstracts due within March 14, 2008): http://www.edas.info/newPaper.php?c=6118& They must not exceed 10 single-spaced, double-column pages using at least 11 pt size fonts on 8.5 x 11 inch pages in IEEE style format. Detailed formatting and submission instructions will be available on the conference website. WORKSHOP Proposals: Workshop proposals are solicited on cutting-edge topics that complement or supplement the main theme of IEEE MASS 2008. Please contact the Workshop Co-chairs with proposals or for any questions. The submission deadline is Feb 15. DEMO Proposals: Proposals are solicited for technical demonstrations of experimental ad-hoc and sensor networking systems. Visit the conference website for instructions on submitting demo proposals or contact the Demo Chair. PAPER Submission Deadlines: Abstracts Due: March 14, 2008 Manuscripts Due: March 21, 2008 Acceptance Notification: June 20, 2008 Camera-ready Submission: July 18, 2008 ORGANIZING COMMITTEE GENERAL Chair Tom La Porta, Pennsylvania State University, USA (tlp at cse.psuedu) PROGRAM Chair Sajal K. Das, The University of Texas at Arlington, USA (das at uta.edu) TPC Vice Chairs Luciano Bononi, University of Bologna, Italy (bononi at cs.unibo.it) Archan Misra, IBM Watson Research Center, USA (archan at us.ibm.com) Chunming Qiao, University of Buffalo, USA (qiao at cse.buffalo.edu) WORKSHOP Co-Chairs Yonghe Liu, University of Texas at Arlington, USA (yonghe at cse.uta.edu) Sencun Zhu, Pennsylvania State University, USA (szhu at cse.psu.edu) FINANCE & REGISTRATION Chair: Anup Kumar, University of Louisville, USA PUBLICATION Chair Dajin Wang, Montclair State University, USA PUBLICITY Co-Chairs Sunghyun Choi, Seoul National University, Korea (schoi at snu.ac.kr) Murat Demirbas, University of Buffalo, USA (demirbas at cse.buffalo.edu) Pedro Ruiz, University of Murcia, Spain (pedrom at dif.um.es) LOCAL ARRANGEMENTS Chair George Riley, Georgia Tech, USA (riley at ece.gatech.edu) WEB Chair Sharanya Eswaran, Pennsylvania State Univ, USA (eswaran at cse.psu.edu) STEERING COMMITTEE Co-chairs Dharma P. Agrawal, University of Cincinnati, USA Jie Wu (TCDP), Florida Atlantic University & NSF, USA TECHNICAL PROGRAM COMMITTEE Nael Abu-Ghazaleh, State University of New York at Binghamton, USA Prathima Agrawal, Auburn University, USA Ian Akyildiz, Georgia Institute of Technology, USA Kevin Almeroth, University of California at Santa Barbara Giuseppe Anastasi, University of Pisa, Italy Stefano Basagni, Northeastern University, USA Elizabeth Belding, University of California at Santa Barbara, USA Brahim Bensaou, Hong Kong Univ. of Science and Technology, Hong Kong Amiya Bhattacharya, New Mexico State University, USA Douglas Blough, Georgia Institute of Technology, USA Luciano Bononi, University of Bologna, Italy Azzedine Boukerche, University of Ottawa, Canada Joel Branch, IBM Watson Research Center, USA Raffaele Bruno, IIT?CNR, Pisa, Italy Levente Buttyan, CrySys lab, Budapest Univ. of tech. and econ., Hungary Guohong Cao, Pennsylvania State University, USA Jiannong Cao, Hong Kong Polytechnic University, Hong Kong Antonio Capone, Politecnico di Milano, Italy Mainak Chatterjee, University of Central Florida, USA Guihai Chen, Nanjing University, China Hsiao-Hwa Chen, National Sun Yat-Sen University, Taiwan Yanghee Choi, Seoul National University, Korea Chun Tung Chou, University of New South Wales, Australia Amitabha Das, Nanyang Technological University, Singapore Sajal K. Das, The University of Texas at Arlington, USA Swades De, Indian Institute of Technology, India Murat Demirbas, State University of New York at Buffalo, USA Falko Dressler, University of Erlangen, Germany Eylem Ekici, Ohio State University,USA Karoly Farkas, University of West Hungary, Hungary Laura Feeney, Swedish Institute of Computer Science, Sweden Ratan Ghosh, Indian Institute of Technology at Kanpur, India Silvia Giordano, University of Applied Science ?(SUPSI), Switzerland Mesut G?nes, Computer Science, Freie Universit?t Berlin, Germany Zygmunt Haas, Cornell University, USA Qi Han, Colorado School of Mines, USA Paul Havinga, University of Twente, The Netherlands Tian He, University of Minnesota, USA Sanjay Jha, University of New South Wales, Australia Xiaohua Jia, City University of Hong Kong, Hong Kong Vana Kalogeraki, University of California at Riverside, USA Koushik Kar, Rensselaer Polytechnic Institute, USA Holger Karl, University of Paderborn, Germany Sneha Kasera, University of Utah, USA Young-Bae Ko, Ajou University, Korea Sastry Kompella, Naval Research Laboratory, USA Farinaz Koushanfar, Rice University, USA Evangelos Kranakis, Carleton University, Canada Bhaskar Krishnamachari, University of Southern California, USA Sudha Krishnamurthy, Deutsche Telekom Laboratories, Germany Taekyoung Kwon, Seoul National University, Korea Tom La Porta, Pennsylvania State University, USA Sung-Ju Lee, HP Labs, USA Qilian Liang, The University of Texas at Arlington, USA Weifa Liang, Australian National University, Australia Lavy Libman, NICTA, Sydney, Australia Yonghe Liu, The University of Texas at Arlington, USA Yunhao Liu, Hong Kong University of Science and Technology, Hong Kong Cecilia Mascolo, University College London, UK Martin Mauve, Heinrich Heine University, D?sseldorf, Germany Ciaran Mc Goldrick, Trinity College at Dublin, Ireland Tommaso Melodia, State University of New York at Buffalo, mUSA Jelena Misic, University of Manitoba, Canada Archan Misra, IBM Watson Research Center, USA Mehul Motani, National University of Singapore, Singapore Farid Na?t-Abdesselam, University of Sciences and Tech. of Lille, France Peng Ning, North Carolina State University, USA Sergio Palazzo, University of Catania, Italy Jos? Parente de Oliveira, ITA, Brazil Andrea Passarella, IIT-CNR, Pisa, Italy Dirk Pesch, Cork Institute of Technology, Ireland Chiara Petrioli, University of Rome "La Sapienza", Italy Tien Pham, Army Research Laboratory, USA Cristina M. Pinotti, University of Perugia, Italy Dario Pompili, Rutgers University, The State Univ. of New Jersey, USA Ravi Prakash, University of Texas at Dallas, USA Chunming Qiao, State University of New York at Buffalo, USA Lili Qiu, The University of Texas at Austin, USA Milena Radenkovic, University of Nottingham, UK Fengyuan Ren, Tsinghua University, China Pedro Ruiz, University of Murcia, Spain Weisong Shi, Wayne State University, USA Yi Shi, Virginia Tech, USA Rajeev Shorey, General Motors Research, India David Simplot-Ryl, INRIA & University of Lille, France Raghupathy Sivakumar, Georgia Institute of Technology, USA Krishna Sivalingam, University of Maryland at Baltimore County, USA Harry Skianis, National Centre for Scientific Res. 'Demokritos', Greece Cormac Sreenan, University College of Cork, Ireland Vikram Srinivasan, Bell Labs Research, India Violet Syrotiuk, Arizona State University, USA Vic Thomas, Honeywell, USA Ozan Tonguz, Carnegie Mellon University, USA Wade Trappe, Rutgers University, The State Univ. of New Jersey, USA Yu-Chee Tseng, National Chiao-Tung University, Taiwan Roberto Verdone, University of Bologna, Italy Mehmet Vuran, University of Nebraska-Lincoln, USA Carlos Becker Westphall, Federal University of Santa Catarina, Brazil Hongyi Wu, University of Louisiana at Lafayette, Louisiana Wendong Xiao, Institute for Infocomm Research, Singapore Wensheng Zhang, Iowa State University, USA Sheng Zhong, State University of New York at Buffalo, USA Yanmin Zhu, Imperial College of London, UK Michele Zorzi, Universit? degli Studi di Padova, Italy -- --------------------------------------------------------------------- Pedro M. Ruiz, Ph.D, MIEEE. 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 http://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Mon Feb 18 07:38:00 2008 Return-Path: X-Original-To: ietfarch-autoconf-archive@core3.amsl.com Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA2BA28C420; Mon, 18 Feb 2008 07:37:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.628 X-Spam-Level: X-Spam-Status: No, score=-0.628 tagged_above=-999 required=5 tests=[AWL=-0.540, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_FR=0.35, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LdZeR7DD9aUl; Mon, 18 Feb 2008 07:37:58 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 34B083A6D62; Mon, 18 Feb 2008 07:37:51 -0800 (PST) X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A8FCA28C35F for ; Mon, 18 Feb 2008 07:37:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z7HcXZ4fN78n for ; Mon, 18 Feb 2008 07:37:47 -0800 (PST) Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by core3.amsl.com (Postfix) with ESMTP id BA1E428C4FC for ; Mon, 18 Feb 2008 07:35:31 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.25,371,1199660400"; d="scan'208";a="22751274" Received: from sphinx.lix.polytechnique.fr (HELO BoolfightMaN-Laptop.local) ([129.104.11.1]) by mail4-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 18 Feb 2008 16:35:28 +0100 Message-ID: <47B9A5BF.9060106@inria.fr> Date: Mon, 18 Feb 2008 16:35:27 +0100 From: Emmanuel Baccelli User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: autoconf@ietf.org References: <47AAC029.8030908@dif.um.es> In-Reply-To: <47AAC029.8030908@dif.um.es> Subject: [Autoconf] AUTOCONF Problem Statement: reviews needed. X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Hi all, an updated version of the problem statement is available at the following URL: http://wiki.emmanuelbaccelli.org/uploads/Ietf/draft-ietf-autoconf-problem-statement-04-PREVIEW-5.txt Your review is needed in order for the document to go forward. Please provide your feedback this week -- the cut-off date being next Monday. The document is short (20 pages), so don't refrain! Thanks, and see you soon in Philadelphia. Emmanuel _______________________________________________ Autoconf mailing list Autoconf@ietf.org http://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Mon Feb 18 12:31:23 2008 Return-Path: X-Original-To: ietfarch-autoconf-archive@core3.amsl.com Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E1DE28C77C; Mon, 18 Feb 2008 12:31:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.448 X-Spam-Level: X-Spam-Status: No, score=-0.448 tagged_above=-999 required=5 tests=[AWL=-0.011, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UnQAONS5StL6; Mon, 18 Feb 2008 12:31:22 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 759C828C5B8; Mon, 18 Feb 2008 12:27:28 -0800 (PST) X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 066AF3A6D6E for ; Mon, 18 Feb 2008 12:27:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pr09YmhlqhDD for ; Mon, 18 Feb 2008 12:27:26 -0800 (PST) Received: from hotmail2.netcop.nl (hotmail2.netcop.nl [194.109.204.37]) by core3.amsl.com (Postfix) with ESMTP id BBC0828C5B8 for ; Mon, 18 Feb 2008 12:20:06 -0800 (PST) Received: by hotmail2.netcop.nl (Postfix, from userid 500) id A86DB780018; Mon, 18 Feb 2008 21:20:02 +0100 (CET) Received: from M90Teco (unknown [83.68.31.87]) by hotmail2.netcop.nl (Postfix) with ESMTP id 8E594780012; Mon, 18 Feb 2008 21:19:58 +0100 (CET) From: "Teco Boot" To: "'Emmanuel Baccelli'" References: <47AAC029.8030908@dif.um.es> <47B9A5BF.9060106@inria.fr> In-Reply-To: <47B9A5BF.9060106@inria.fr> Date: Mon, 18 Feb 2008 21:19:50 +0100 Message-ID: <000001c8726b$9d66b440$d8341cc0$@nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AchyREfrALL1pinWQL6MBnjD9MQaswAGBsgA Content-Language: nl X-Mailscan: CLEAN Cc: autoconf@ietf.org Subject: Re: [Autoconf] AUTOCONF Problem Statement: reviews needed. X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Hi Emanuel, Thanks for the new draft. I think the document is largely improved. Here some comments: Page 4; Network merging: Why not using "MANET merging"? Same for Network partitioning. And why using term "disconnected MANETs"? What is the difference with "Autonomous MANETs"? Page 6; 3.1.1. I think Car-to-car communication is more or less an autonomous MANET, where car-to-infrastructure is an example of a subordinate MANET. c/Car-to-car communication networks/Vehicle communication networks/ ?? Page 7; 3.2.1. c/inapproriate/ inappropriate/ Page 8; 4. 3. c/face/case/ Page 10; 5.1.2. I don't think correctly operating DHCP servers will provide non-unique IP addresses. Why is this suggested? I would say each DHCP server manages its own pool of addresses and it will never offer addresses or prefixes with already active leases. Same remark on page 11 - 5.3.2 Page 11; 5.3.2 When IP connectivity exists between a MANET Router and a DHCP Server (set up by whatever mechanism), what is the problem with DHCP-PD? I can't follow. Page 12; R 02 First, the term prefix. I think this term is used in another context as RFC4291. In RFC4291 a prefix is simply the subnet part of an address. In this document, we specify that a prefix is some kind a aggregate of subnets. I like this approach, as aggregating may reduce routing protocol overhead. But using the same term for two purposes is confusing. Second, I think the aggregated prefix allocation is a bootstrap problem (onetime shot) and I am not sure if this requirement is a "must" in the MANET Autoconf context. I think also the allocated prefixes are to be used for the non-MANET interfaces on a MANET Router. I think current protocols for prefix delegation can be used, under the condition that the requirements for MANET address autoconfiguration are fulfilled. Page 12; R 05 c/asymetry/asymmetry/ CU@philly, Teco > -----Oorspronkelijk bericht----- > Van: autoconf-bounces@ietf.org [mailto:autoconf-bounces@ietf.org] > Namens Emmanuel Baccelli > Verzonden: maandag 18 februari 2008 16:35 > Aan: autoconf@ietf.org > Onderwerp: [Autoconf] AUTOCONF Problem Statement: reviews needed. > > Hi all, > > an updated version of the problem statement is available at the > following URL: > > http://wiki.emmanuelbaccelli.org/uploads/Ietf/draft-ietf-autoconf- > problem-statement-04-PREVIEW-5.txt > > Your review is needed in order for the document to go forward. Please > provide your feedback this week -- the cut-off date being next Monday. > The document is short (20 pages), so don't refrain! > > Thanks, and see you soon in Philadelphia. > > Emmanuel > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > http://www.ietf.org/mailman/listinfo/autoconf _______________________________________________ Autoconf mailing list Autoconf@ietf.org http://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Tue Feb 19 04:09:00 2008 Return-Path: X-Original-To: ietfarch-autoconf-archive@core3.amsl.com Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F0BD28C4B1; Tue, 19 Feb 2008 04:09:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.018 X-Spam-Level: X-Spam-Status: No, score=-1.018 tagged_above=-999 required=5 tests=[AWL=-0.931, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_FR=0.35, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YChdWm8lDkvk; Tue, 19 Feb 2008 04:08:59 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A6F63A6A78; Tue, 19 Feb 2008 04:08:59 -0800 (PST) X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C56328C4B1 for ; Tue, 19 Feb 2008 04:08:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8QKbYGYJ8idm for ; Tue, 19 Feb 2008 04:08:56 -0800 (PST) Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by core3.amsl.com (Postfix) with ESMTP id A77B53A680D for ; Tue, 19 Feb 2008 04:08:55 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.25,375,1199660400"; d="scan'208";a="9343744" Received: from ras75-3-82-226-221-97.fbx.proxad.net (HELO BoolfightMaN-Laptop.local) ([82.226.221.97]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 19 Feb 2008 13:08:50 +0100 Message-ID: <47BAC6D1.7060100@inria.fr> Date: Tue, 19 Feb 2008 13:08:49 +0100 From: Emmanuel Baccelli User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: autoconf@ietf.org References: <47AAC029.8030908@dif.um.es> <47B9A5BF.9060106@inria.fr> <000001c8726b$9d66b440$d8341cc0$@nl> In-Reply-To: <000001c8726b$9d66b440$d8341cc0$@nl> Subject: Re: [Autoconf] AUTOCONF Problem Statement: reviews needed. X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Hi Teco, thanks for your feedback. Judging from its substance, it seems we have = made great progress! Comments are inline: Emmanuel Teco Boot a =E9crit : > Hi Emmanuel, > > Thanks for the new draft. > I think the document is largely improved. > Here some comments: > > Page 4; Network merging: > Why not using "MANET merging"? > Same for Network partitioning. > And why using term "disconnected MANETs"? What is the difference with > "Autonomous MANETs"? Nework merging can happen between two subordinate MANETs (you would then = get a multihomed MANET). The definition of "network merging" may be = useful to networks in general, not just MANETs. > > Page 6; 3.1.1. > I think Car-to-car communication is more or less an autonomous MANET, = where > car-to-infrastructure is an example of a subordinate MANET. > c/Car-to-car communication networks/Vehicle communication networks/ ?? > Yes I agree. Maybe it is a clearer way to put it. > Page 7; 3.2.1. > c/inapproriate/ inappropriate/ > Page 8; 4. 3. > c/face/case/ > > Page 10; 5.1.2. > I don't think correctly operating DHCP servers will provide non-unique IP > addresses. Why is this suggested? > I would say each DHCP server manages its own pool of addresses and it = will > never offer addresses or prefixes with already active leases. > Same remark on page 11 - 5.3.2 > Yes. But an issue may arise if the pools of addresses of multiple DHCP = servers in the same MANET are not disjoint. This is the issue that is = raised. > Page 11; 5.3.2 > When IP connectivity exists between a MANET Router and a DHCP Server = (set up > by whatever mechanism), what is the problem with DHCP-PD? I can't follow. Well, you are basically dependent on a routing protocol of sorts then, no? > > Page 12; R 02 > First, the term prefix. I think this term is used in another context as > RFC4291. In RFC4291 a prefix is simply the subnet part of an address. In > this document, we specify that a prefix is some kind a aggregate of = subnets. > I like this approach, as aggregating may reduce routing protocol = overhead. > But using the same term for two purposes is confusing. > Second, I think the aggregated prefix allocation is a bootstrap problem > (onetime shot) and I am not sure if this requirement is a "must" in the > MANET Autoconf context. I think also the allocated prefixes are to be = used > for the non-MANET interfaces on a MANET Router. I think current protocols > for prefix delegation can be used, under the condition that the = requirements > for MANET address autoconfiguration are fulfilled. > Well this requirement is basically a direct translation of what is = specified in the MANET arch document. So I guess that if we want to have = this discussion, we should take it there first. But I am not sure this = is relevant in that this discussion already happened I guess. > Page 12; R 05 > c/asymetry/asymmetry/ > > CU@philly, > Teco > >> -----Oorspronkelijk bericht----- >> Van: autoconf-bounces@ietf.org [mailto:autoconf-bounces@ietf.org] >> Namens Emmanuel Baccelli >> Verzonden: maandag 18 februari 2008 16:35 >> Aan: autoconf@ietf.org >> Onderwerp: [Autoconf] AUTOCONF Problem Statement: reviews needed. >> >> Hi all, >> >> an updated version of the problem statement is available at the >> following URL: >> >> http://wiki.emmanuelbaccelli.org/uploads/Ietf/draft-ietf-autoconf- >> problem-statement-04-PREVIEW-5.txt >> >> Your review is needed in order for the document to go forward. Please >> provide your feedback this week -- the cut-off date being next Monday. >> The document is short (20 pages), so don't refrain! >> >> Thanks, and see you soon in Philadelphia. >> >> Emmanuel >> _______________________________________________ >> Autoconf mailing list >> Autoconf@ietf.org >> http://www.ietf.org/mailman/listinfo/autoconf > > _______________________________________________ Autoconf mailing list Autoconf@ietf.org http://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Tue Feb 19 05:54:46 2008 Return-Path: X-Original-To: ietfarch-autoconf-archive@core3.amsl.com Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0CC5E28C57F; Tue, 19 Feb 2008 05:54:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.315 X-Spam-Level: X-Spam-Status: No, score=-1.315 tagged_above=-999 required=5 tests=[AWL=-0.878, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6yQWgROSnF95; Tue, 19 Feb 2008 05:54:44 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD9A63A68AB; Tue, 19 Feb 2008 05:54:44 -0800 (PST) X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B24428C4E8 for ; Tue, 19 Feb 2008 05:54:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GdM-bDEHu0pw for ; Tue, 19 Feb 2008 05:54:42 -0800 (PST) Received: from mho-02-bos.mailhop.org (mho-02-bos.mailhop.org [63.208.196.179]) by core3.amsl.com (Postfix) with ESMTP id AB2583A689A for ; Tue, 19 Feb 2008 05:54:42 -0800 (PST) Received: from [129.104.11.1] (helo=[192.168.112.180]) by mho-02-bos.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1JRSvf-0004gR-CF; Tue, 19 Feb 2008 13:54:39 +0000 X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 129.104.11.1 X-Report-Abuse-To: abuse@dyndns.com (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+FM19fy/WkacMpDSPedl3P In-Reply-To: <47BAC6D1.7060100@inria.fr> References: <47AAC029.8030908@dif.um.es> <47B9A5BF.9060106@inria.fr> <000001c8726b$9d66b440$d8341cc0$@nl> <47BAC6D1.7060100@inria.fr> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: From: Thomas Clausen Date: Tue, 19 Feb 2008 14:54:14 +0100 To: Emmanuel Baccelli X-Mailer: Apple Mail (2.752.3) Cc: autoconf@ietf.org Subject: Re: [Autoconf] AUTOCONF Problem Statement: reviews needed. X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Emmanuel, Teco, Emmanuel, I assume that the items that you have not commented on are = already, or will soon be, integrated into an updated I-D? A couple of comments to the issues Teco brought forward below. On Feb 19, 2008, at 1:08 PM, Emmanuel Baccelli wrote: > Hi Teco, > > thanks for your feedback. Judging from its substance, it seems we have > made great progress! Comments are inline: > > Emmanuel > > > Teco Boot a =E9crit : >> Hi Emmanuel, >> >> Thanks for the new draft. >> I think the document is largely improved. Agreed - and thanks, Teco (and all of you) for making that happen. >> Here some comments: >> >> Page 4; Network merging: >> Why not using "MANET merging"? >> Same for Network partitioning. >> And why using term "disconnected MANETs"? What is the difference with >> "Autonomous MANETs"? > > Nework merging can happen between two subordinate MANETs (you would = > then > get a multihomed MANET). The definition of "network merging" may be > useful to networks in general, not just MANETs. Teco has a point in as much as a "multihomed subordinate MANET = emerging from two formerly single-homed subordinate MANETs" might be = (or be seen) as different from " a large autonomous MANET emerging = from two formerly autonomous and not connected MANETs". It might be = worth exploring in the document if and how (or, if not, why not) such = are different. Good catch - Teco, Emmanuel, do you have opinions on this (the = substance, that is)? I'm actually glad to see that Teco's main comments are to section 5 = and forward, since that's probably where we need eyes to help = understand if the essentials are correctly captured. >> >> Page 10; 5.1.2. >> I don't think correctly operating DHCP servers will provide non- = >> unique IP >> addresses. Why is this suggested? >> I would say each DHCP server manages its own pool of addresses and it > will >> never offer addresses or prefixes with already active leases. >> Same remark on page 11 - 5.3.2 >> > > Yes. But an issue may arise if the pools of addresses of multiple DHCP > servers in the same MANET are not disjoint. This is the issue that is > raised. Just to clarify: Emmanuel, are you suggesting that two DHCP servers = "share" a pool of addresses, without co-ordinating leases with each = other? Does that happen? I think Teco is right in that it doesn't, = unless something is broken elsewhere? Or, are you talking about the = situation in which this co-ordination happens only through the MANET, = which becomes disconnected? > >> Page 11; 5.3.2 >> When IP connectivity exists between a MANET Router and a DHCP Server > (set up >> by whatever mechanism), what is the problem with DHCP-PD? I can't = >> follow. > > Well, you are basically dependent on a routing protocol of sorts = > then, no? Hu-humm.....DHCP proxies and promiscuous abuse of broadcasting seems = an off-the-cuff way to make it happen without a routing protocol as = such. Or (and someone *will* object, but I have seen it done) simple = classical flooding of any and all DHCP traffic, blatantly ignoring = address scopes and hop-limits. In other words, I can imagine ways where no routing protocol as such = is required - granted, I do not recommend any of those in the = abbreviated form stated above. The question is as to if the issue is = captured correctly in the I-D (i.e. does IP connectivity exist = between a MANET router and a DHCP server in the scenarios envisioned? = If not, we need to explain that, plus why. If yes, then Teco seems to = be right ;) ) Thomas >> >> Page 12; R 02 >> First, the term prefix. I think this term is used in another = >> context as >> RFC4291. In RFC4291 a prefix is simply the subnet part of an = >> address. In >> this document, we specify that a prefix is some kind a aggregate of > subnets. >> I like this approach, as aggregating may reduce routing protocol > overhead. >> But using the same term for two purposes is confusing. >> Second, I think the aggregated prefix allocation is a bootstrap = >> problem >> (onetime shot) and I am not sure if this requirement is a "must" = >> in the >> MANET Autoconf context. I think also the allocated prefixes are to be > used >> for the non-MANET interfaces on a MANET Router. I think current = >> protocols >> for prefix delegation can be used, under the condition that the > requirements >> for MANET address autoconfiguration are fulfilled. >> > > Well this requirement is basically a direct translation of what is > specified in the MANET arch document. So I guess that if we want to = > have > this discussion, we should take it there first. But I am not sure this > is relevant in that this discussion already happened I guess. > >> Page 12; R 05 >> c/asymetry/asymmetry/ >> >> CU@philly, >> Teco >> >>> -----Oorspronkelijk bericht----- >>> Van: autoconf-bounces@ietf.org [mailto:autoconf-bounces@ietf.org] >>> Namens Emmanuel Baccelli >>> Verzonden: maandag 18 februari 2008 16:35 >>> Aan: autoconf@ietf.org >>> Onderwerp: [Autoconf] AUTOCONF Problem Statement: reviews needed. >>> >>> Hi all, >>> >>> an updated version of the problem statement is available at the >>> following URL: >>> >>> http://wiki.emmanuelbaccelli.org/uploads/Ietf/draft-ietf-autoconf- >>> problem-statement-04-PREVIEW-5.txt >>> >>> Your review is needed in order for the document to go forward. = >>> Please >>> provide your feedback this week -- the cut-off date being next = >>> Monday. >>> The document is short (20 pages), so don't refrain! >>> >>> Thanks, and see you soon in Philadelphia. >>> >>> Emmanuel >>> _______________________________________________ >>> Autoconf mailing list >>> Autoconf@ietf.org >>> http://www.ietf.org/mailman/listinfo/autoconf >> >> > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > http://www.ietf.org/mailman/listinfo/autoconf > _______________________________________________ Autoconf mailing list Autoconf@ietf.org http://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Tue Feb 19 06:36:06 2008 Return-Path: X-Original-To: ietfarch-autoconf-archive@core3.amsl.com Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4184128C36F; Tue, 19 Feb 2008 06:36:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.414 X-Spam-Level: X-Spam-Status: No, score=-0.414 tagged_above=-999 required=5 tests=[AWL=-0.327, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_FR=0.35, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SV5ajFRgm5qv; Tue, 19 Feb 2008 06:36:04 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE9F228C655; Tue, 19 Feb 2008 06:35:58 -0800 (PST) X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4306328C610 for ; Tue, 19 Feb 2008 06:35:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NUNJGYwpJyoH for ; Tue, 19 Feb 2008 06:35:56 -0800 (PST) Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by core3.amsl.com (Postfix) with ESMTP id B21A128C602 for ; Tue, 19 Feb 2008 06:35:48 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.25,376,1199660400"; d="scan'208";a="9352940" Received: from ras75-3-82-226-221-97.fbx.proxad.net (HELO BoolfightMaN-Laptop.local) ([82.226.221.97]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 19 Feb 2008 15:35:42 +0100 Message-ID: <47BAE93F.3070302@inria.fr> Date: Tue, 19 Feb 2008 15:35:43 +0100 From: Emmanuel Baccelli User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: autoconf@ietf.org References: <47AAC029.8030908@dif.um.es> <47B9A5BF.9060106@inria.fr> <000001c8726b$9d66b440$d8341cc0$@nl> <47BAC6D1.7060100@inria.fr> In-Reply-To: Subject: Re: [Autoconf] AUTOCONF Problem Statement: reviews needed. X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Hi Thomas, I beleive that I commented every item, except spelling-related comments, = or did I miss something? Anyways, my further comments are inline: Thomas Clausen a =E9crit : > Emmanuel, Teco, > = > Emmanuel, I assume that the items that you have not commented on are = > already, or will soon be, integrated into an updated I-D? > = > A couple of comments to the issues Teco brought forward below. > = >>> >>> Page 4; Network merging: >>> Why not using "MANET merging"? >>> Same for Network partitioning. >>> And why using term "disconnected MANETs"? What is the difference with >>> "Autonomous MANETs"? >> >> Nework merging can happen between two subordinate MANETs (you would then >> get a multihomed MANET). The definition of "network merging" may be >> useful to networks in general, not just MANETs. > = > Teco has a point in as much as a "multihomed subordinate MANET emerging = > from two formerly single-homed subordinate MANETs" might be (or be seen) = > as different from " a large autonomous MANET emerging from two formerly = > autonomous and not connected MANETs". It might be worth exploring in the = > document if and how (or, if not, why not) such are different. > = > Good catch - Teco, Emmanuel, do you have opinions on this (the = > substance, that is)? > = I think this scenario distinction has nothing to do with the definition = of network merging. As far as scenarios are concerned, the draft as it = is now classifies the resulting merged MANET as such: (i) is it autonomous or subordinate? If it is subordinate, is it multihomed? (ii) are pre-configured addresses or prefixes are creating duplication = conflicts? (iii) if it is subordinate, are pre-configured addresses or prefixes = against topology correctness? I am wondering what other classification/exception we should incorporate = in addition? Maybe this is sufficient? > > = > I'm actually glad to see that Teco's main comments are to section 5 and = > forward, since that's probably where we need eyes to help understand if = > the essentials are correctly captured. > = >>> >>> Page 10; 5.1.2. >>> I don't think correctly operating DHCP servers will provide = >>> non-unique IP >>> addresses. Why is this suggested? >>> I would say each DHCP server manages its own pool of addresses and it >> will >>> never offer addresses or prefixes with already active leases. >>> Same remark on page 11 - 5.3.2 >>> >> >> Yes. But an issue may arise if the pools of addresses of multiple DHCP >> servers in the same MANET are not disjoint. This is the issue that is >> raised. > = > Just to clarify: Emmanuel, are you suggesting that two DHCP servers = > "share" a pool of addresses, without co-ordinating leases with each = > other? Does that happen? I think Teco is right in that it doesn't, = > unless something is broken elsewhere? Or, are you talking about the = > situation in which this co-ordination happens only through the MANET, = > which becomes disconnected? > = I am saying that if two previously independent MANETs merge, each MANET = having its own DHCP server, there is no assurance that the pools of = "local" addresses they each manage are indeed disjoint, is there? = Duplication issues may thus arise after the merge, and DHCP does not = have a mechanism to dynamically re-configure servers in such cases. >> >>> Page 11; 5.3.2 >>> When IP connectivity exists between a MANET Router and a DHCP Server >> (set up >>> by whatever mechanism), what is the problem with DHCP-PD? I can't = >>> follow. >> >> Well, you are basically dependent on a routing protocol of sorts then, = >> no? > = > Hu-humm.....DHCP proxies and promiscuous abuse of broadcasting seems an = > off-the-cuff way to make it happen without a routing protocol as such. = > Or (and someone *will* object, but I have seen it done) simple classical = > flooding of any and all DHCP traffic, blatantly ignoring address scopes = > and hop-limits. > = > In other words, I can imagine ways where no routing protocol as such is = > required - granted, I do not recommend any of those in the abbreviated = > form stated above. The question is as to if the issue is captured = > correctly in the I-D (i.e. does IP connectivity exist between a MANET = > router and a DHCP server in the scenarios envisioned? If not, we need to = > explain that, plus why. If yes, then Teco seems to be right ;) ) I see. Maybe we could be clearer on this point then. How about adding a = specific sentence in 5.3.2, like "if the topology is or becomes such = that a MANET router cannot communicate with a DHCP server, DHCP-PD is = not operational." What do you think? Emmanuel > = > Thomas > = >>> >>> Page 12; R 02 >>> First, the term prefix. I think this term is used in another context as >>> RFC4291. In RFC4291 a prefix is simply the subnet part of an address. In >>> this document, we specify that a prefix is some kind a aggregate of >> subnets. >>> I like this approach, as aggregating may reduce routing protocol >> overhead. >>> But using the same term for two purposes is confusing. >>> Second, I think the aggregated prefix allocation is a bootstrap problem >>> (onetime shot) and I am not sure if this requirement is a "must" in the >>> MANET Autoconf context. I think also the allocated prefixes are to be >> used >>> for the non-MANET interfaces on a MANET Router. I think current = >>> protocols >>> for prefix delegation can be used, under the condition that the >> requirements >>> for MANET address autoconfiguration are fulfilled. >>> >> >> Well this requirement is basically a direct translation of what is >> specified in the MANET arch document. So I guess that if we want to have >> this discussion, we should take it there first. But I am not sure this >> is relevant in that this discussion already happened I guess. >> >>> Page 12; R 05 >>> c/asymetry/asymmetry/ >>> >>> CU@philly, >>> Teco >>> >>>> -----Oorspronkelijk bericht----- >>>> Van: autoconf-bounces@ietf.org [mailto:autoconf-bounces@ietf.org] >>>> Namens Emmanuel Baccelli >>>> Verzonden: maandag 18 februari 2008 16:35 >>>> Aan: autoconf@ietf.org >>>> Onderwerp: [Autoconf] AUTOCONF Problem Statement: reviews needed. >>>> >>>> Hi all, >>>> >>>> an updated version of the problem statement is available at the >>>> following URL: >>>> >>>> http://wiki.emmanuelbaccelli.org/uploads/Ietf/draft-ietf-autoconf- >>>> problem-statement-04-PREVIEW-5.txt >>>> >>>> Your review is needed in order for the document to go forward. Please >>>> provide your feedback this week -- the cut-off date being next Monday. >>>> The document is short (20 pages), so don't refrain! >>>> >>>> Thanks, and see you soon in Philadelphia. >>>> >>>> Emmanuel >>>> _______________________________________________ >>>> Autoconf mailing list >>>> Autoconf@ietf.org >>>> http://www.ietf.org/mailman/listinfo/autoconf >>> >>> >> _______________________________________________ >> Autoconf mailing list >> Autoconf@ietf.org >> http://www.ietf.org/mailman/listinfo/autoconf >> > = > = _______________________________________________ Autoconf mailing list Autoconf@ietf.org http://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Tue Feb 19 06:39:03 2008 Return-Path: X-Original-To: ietfarch-autoconf-archive@core3.amsl.com Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F314528C0E9; Tue, 19 Feb 2008 06:39:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.311 X-Spam-Level: X-Spam-Status: No, score=-0.311 tagged_above=-999 required=5 tests=[AWL=-0.224, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_FR=0.35, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vri+epg4BQyE; Tue, 19 Feb 2008 06:39:01 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D17E328C4D3; Tue, 19 Feb 2008 06:39:01 -0800 (PST) X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 16A2D28C4D3 for ; Tue, 19 Feb 2008 06:39:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id adE5HBQXLo+h for ; Tue, 19 Feb 2008 06:39:00 -0800 (PST) Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by core3.amsl.com (Postfix) with ESMTP id 6BDDB28C29A for ; Tue, 19 Feb 2008 06:38:59 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.25,376,1199660400"; d="scan'208";a="9353027" Received: from ras75-3-82-226-221-97.fbx.proxad.net (HELO BoolfightMaN-Laptop.local) ([82.226.221.97]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 19 Feb 2008 15:38:55 +0100 Message-ID: <47BAE9FE.3030608@inria.fr> Date: Tue, 19 Feb 2008 15:38:54 +0100 From: Emmanuel Baccelli User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: autoconf@ietf.org References: <47AAC029.8030908@dif.um.es> <47B9A5BF.9060106@inria.fr> <000001c8726b$9d66b440$d8341cc0$@nl> <47BAC6D1.7060100@inria.fr> In-Reply-To: Subject: Re: [Autoconf] AUTOCONF Problem Statement: reviews needed. X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org BTW, the security considerations need special attention while reviewing = the document. So please do NOT skip this section ;) as we definitely = need to hear some feedback on this. Emmanuel Thomas Clausen a =E9crit : > Emmanuel, Teco, > = > Emmanuel, I assume that the items that you have not commented on are = > already, or will soon be, integrated into an updated I-D? > = > A couple of comments to the issues Teco brought forward below. > = > On Feb 19, 2008, at 1:08 PM, Emmanuel Baccelli wrote: > = >> Hi Teco, >> >> thanks for your feedback. Judging from its substance, it seems we have >> made great progress! Comments are inline: >> >> Emmanuel >> >> >> Teco Boot a =E9crit : >>> Hi Emmanuel, >>> >>> Thanks for the new draft. >>> I think the document is largely improved. > = > Agreed - and thanks, Teco (and all of you) for making that happen. > = >>> Here some comments: >>> >>> Page 4; Network merging: >>> Why not using "MANET merging"? >>> Same for Network partitioning. >>> And why using term "disconnected MANETs"? What is the difference with >>> "Autonomous MANETs"? >> >> Nework merging can happen between two subordinate MANETs (you would then >> get a multihomed MANET). The definition of "network merging" may be >> useful to networks in general, not just MANETs. > = > Teco has a point in as much as a "multihomed subordinate MANET emerging = > from two formerly single-homed subordinate MANETs" might be (or be seen) = > as different from " a large autonomous MANET emerging from two formerly = > autonomous and not connected MANETs". It might be worth exploring in the = > document if and how (or, if not, why not) such are different. > = > Good catch - Teco, Emmanuel, do you have opinions on this (the = > substance, that is)? > = > > = > I'm actually glad to see that Teco's main comments are to section 5 and = > forward, since that's probably where we need eyes to help understand if = > the essentials are correctly captured. > = >>> >>> Page 10; 5.1.2. >>> I don't think correctly operating DHCP servers will provide = >>> non-unique IP >>> addresses. Why is this suggested? >>> I would say each DHCP server manages its own pool of addresses and it >> will >>> never offer addresses or prefixes with already active leases. >>> Same remark on page 11 - 5.3.2 >>> >> >> Yes. But an issue may arise if the pools of addresses of multiple DHCP >> servers in the same MANET are not disjoint. This is the issue that is >> raised. > = > Just to clarify: Emmanuel, are you suggesting that two DHCP servers = > "share" a pool of addresses, without co-ordinating leases with each = > other? Does that happen? I think Teco is right in that it doesn't, = > unless something is broken elsewhere? Or, are you talking about the = > situation in which this co-ordination happens only through the MANET, = > which becomes disconnected? > = >> >>> Page 11; 5.3.2 >>> When IP connectivity exists between a MANET Router and a DHCP Server >> (set up >>> by whatever mechanism), what is the problem with DHCP-PD? I can't = >>> follow. >> >> Well, you are basically dependent on a routing protocol of sorts then, = >> no? > = > Hu-humm.....DHCP proxies and promiscuous abuse of broadcasting seems an = > off-the-cuff way to make it happen without a routing protocol as such. = > Or (and someone *will* object, but I have seen it done) simple classical = > flooding of any and all DHCP traffic, blatantly ignoring address scopes = > and hop-limits. > = > In other words, I can imagine ways where no routing protocol as such is = > required - granted, I do not recommend any of those in the abbreviated = > form stated above. The question is as to if the issue is captured = > correctly in the I-D (i.e. does IP connectivity exist between a MANET = > router and a DHCP server in the scenarios envisioned? If not, we need to = > explain that, plus why. If yes, then Teco seems to be right ;) ) > = > Thomas > = >>> >>> Page 12; R 02 >>> First, the term prefix. I think this term is used in another context as >>> RFC4291. In RFC4291 a prefix is simply the subnet part of an address. In >>> this document, we specify that a prefix is some kind a aggregate of >> subnets. >>> I like this approach, as aggregating may reduce routing protocol >> overhead. >>> But using the same term for two purposes is confusing. >>> Second, I think the aggregated prefix allocation is a bootstrap problem >>> (onetime shot) and I am not sure if this requirement is a "must" in the >>> MANET Autoconf context. I think also the allocated prefixes are to be >> used >>> for the non-MANET interfaces on a MANET Router. I think current = >>> protocols >>> for prefix delegation can be used, under the condition that the >> requirements >>> for MANET address autoconfiguration are fulfilled. >>> >> >> Well this requirement is basically a direct translation of what is >> specified in the MANET arch document. So I guess that if we want to have >> this discussion, we should take it there first. But I am not sure this >> is relevant in that this discussion already happened I guess. >> >>> Page 12; R 05 >>> c/asymetry/asymmetry/ >>> >>> CU@philly, >>> Teco >>> >>>> -----Oorspronkelijk bericht----- >>>> Van: autoconf-bounces@ietf.org [mailto:autoconf-bounces@ietf.org] >>>> Namens Emmanuel Baccelli >>>> Verzonden: maandag 18 februari 2008 16:35 >>>> Aan: autoconf@ietf.org >>>> Onderwerp: [Autoconf] AUTOCONF Problem Statement: reviews needed. >>>> >>>> Hi all, >>>> >>>> an updated version of the problem statement is available at the >>>> following URL: >>>> >>>> http://wiki.emmanuelbaccelli.org/uploads/Ietf/draft-ietf-autoconf- >>>> problem-statement-04-PREVIEW-5.txt >>>> >>>> Your review is needed in order for the document to go forward. Please >>>> provide your feedback this week -- the cut-off date being next Monday. >>>> The document is short (20 pages), so don't refrain! >>>> >>>> Thanks, and see you soon in Philadelphia. >>>> >>>> Emmanuel >>>> _______________________________________________ >>>> Autoconf mailing list >>>> Autoconf@ietf.org >>>> http://www.ietf.org/mailman/listinfo/autoconf >>> >>> >> _______________________________________________ >> Autoconf mailing list >> Autoconf@ietf.org >> http://www.ietf.org/mailman/listinfo/autoconf >> > = > = _______________________________________________ Autoconf mailing list Autoconf@ietf.org http://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Wed Feb 20 01:31:27 2008 Return-Path: X-Original-To: ietfarch-autoconf-archive@core3.amsl.com Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 15BFD3A6E26; Wed, 20 Feb 2008 01:31:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.022 X-Spam-Level: X-Spam-Status: No, score=0.022 tagged_above=-999 required=5 tests=[AWL=-0.540, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=1, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lXzeYNk40eDi; Wed, 20 Feb 2008 01:31:25 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E7AEF3A6AF6; Wed, 20 Feb 2008 01:31:25 -0800 (PST) X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 20BF83A691E for ; Wed, 20 Feb 2008 01:31:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7fYWV-LqwpSO for ; Wed, 20 Feb 2008 01:31:22 -0800 (PST) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.224]) by core3.amsl.com (Postfix) with ESMTP id 049EF3A6999 for ; Wed, 20 Feb 2008 01:31:21 -0800 (PST) Received: by wr-out-0506.google.com with SMTP id 50so3464653wri.25 for ; Wed, 20 Feb 2008 01:31:18 -0800 (PST) Received: by 10.150.178.6 with SMTP id a6mr2652551ybf.22.1203499878875; Wed, 20 Feb 2008 01:31:18 -0800 (PST) Received: by 10.78.40.16 with HTTP; Wed, 20 Feb 2008 01:31:18 -0800 (PST) Message-ID: Date: Wed, 20 Feb 2008 10:31:18 +0100 From: "Hasnaa Moustafa" To: "Teco Boot" In-Reply-To: MIME-Version: 1.0 References: Cc: autoconf@ietf.org Subject: Re: [Autoconf] Autoconf Digest, Vol 25, Issue 3 X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0773531674==" Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org --===============0773531674== Content-Type: multipart/alternative; boundary="----=_Part_14666_29303953.1203499878802" ------=_Part_14666_29303953.1203499878802 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Teco, Just few comments below. Kind Regards, Hassnaa > > ---------------------------------------------------------------------- > Date: Mon, 18 Feb 2008 21:19:50 +0100 > From: "Teco Boot" > Subject: Re: [Autoconf] AUTOCONF Problem Statement: reviews needed. > To: "'Emmanuel Baccelli'" > Cc: autoconf@ietf.org > Message-ID: <000001c8726b$9d66b440$d8341cc0$@nl> > Content-Type: text/plain; charset="us-ascii" > > Hi Emanuel, > > Thanks for the new draft. > I think the document is largely improved. > Here some comments: > > Page 4; Network merging: > Why not using "MANET merging"? > Same for Network partitioning. > And why using term "disconnected MANETs"? What is the difference with > "Autonomous MANETs"? I agree with Emmanuel comment that Network merging is a more general term. As this may be a merging of a MANET with an infrastructure network for instance, same thing for partitioning. Concerning the term "disconnected": these are disconnected MANETs that got merged, where this may happen for autonomous and subordinate categories. Page 6; 3.1.1. > I think Car-to-car communication is more or less an autonomous MANET, > where > car-to-infrastructure is an example of a subordinate MANET. > c/Car-to-car communication networks/Vehicle communication networks/ ?? Agree on vehicular communication, however this can fall under the two categories (autonoumous and subordinate) according to the application (if we need Internet for example), and to the road architecture (if there are some fixed deployed entities belonging to a certain authority for example). Page 7; 3.2.1. > c/inapproriate/ inappropriate/ > > Page 8; 4. 3. > c/face/case/ > > Page 10; 5.1.2. > I don't think correctly operating DHCP servers will provide non-unique IP > addresses. Why is this suggested? Actually, it is mentioned that this approach "could be used to some extent for uniqueness maintenance", implying that this is not the whole solution for IP address uniqueness. I would say each DHCP server manages its own pool of addresses and it will > never offer addresses or prefixes with already active leases. > Same remark on page 11 - 5.3.2 > > Page 11; 5.3.2 > When IP connectivity exists between a MANET Router and a DHCP Server (set > up > by whatever mechanism), what is the problem with DHCP-PD? I can't follow. I agree with Thomas last comment on this point: what is the case if there is no IP connectivity between the MANET Router and the DHCP server. This case can frequently occur according to the scenario type and here, there is an issue. Page 12; R 02 > First, the term prefix. I think this term is used in another context as > RFC4291. In RFC4291 a prefix is simply the subnet part of an address. In > this document, we specify that a prefix is some kind a aggregate of > subnets. > I like this approach, as aggregating may reduce routing protocol overhead. > But using the same term for two purposes is confusing. > Second, I think the aggregated prefix allocation is a bootstrap problem > (onetime shot) and I am not sure if this requirement is a "must" in the > MANET Autoconf context. I think also the allocated prefixes are to be used > for the non-MANET interfaces on a MANET Router. I think current protocols > for prefix delegation can be used, under the condition that the > requirements > for MANET address autoconfiguration are fulfilled. > > Page 12; R 05 > c/asymetry/asymmetry/ > > CU@philly, > Teco > ------=_Part_14666_29303953.1203499878802 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Hi Teco,

Just few comments below.
 
Kind Regards,
Hassnaa
 

----------------------------------------------------------------------
Date: Mon, 18 Feb 2008 21:19:50 +0100
From: "Teco Boot" <teco@inf-net.nl>
Subject: Re: [Autoconf] AUTOCONF Problem Statement: reviews needed.
To: "'Emmanuel Baccelli'" <Emmanuel.Baccelli@inria.fr>
Cc: autoconf@ietf.org
Message-ID: <000001c8726b$9d66b440$d8341cc0$@nl>
Content-Type: text/plain;       charset="us-ascii"

Hi Emanuel,

Thanks for the new draft.
I think the document is largely improved.
Here some comments:

Page 4; Network merging:
Why not using "MANET merging"?
Same for Network partitioning.
And why using term "disconnected MANETs"? What is the difference with
"Autonomous MANETs"?
 
I agree with Emmanuel comment that Network merging is a more general term. As this may be a merging of a MANET with an infrastructure network for instance, same thing for partitioning.
 
Concerning the term "disconnected": these are disconnected MANETs that got merged, where this may happen for autonomous and subordinate categories. 

Page 6; 3.1.1.
I think Car-to-car communication is more or less an autonomous MANET, where
car-to-infrastructure is an example of a subordinate MANET.
c/Car-to-car communication networks/Vehicle communication networks/ ??
 
Agree on vehicular communication, however this can fall under the two categories (autonoumous and subordinate) according to the application (if we need Internet for example), and to the road architecture (if there are some fixed deployed entities belonging to a certain authority for example).

Page 7; 3.2.1.
c/inapproriate/ inappropriate/

Page 8; 4. 3.
c/face/case/

Page 10; 5.1.2.
I don't think correctly operating DHCP servers will provide non-unique IP
addresses. Why is this suggested?
 
Actually, it is mentioned that this approach "could be used to some extent for uniqueness maintenance", implying that this is not the whole solution for IP address uniqueness.

I would say each DHCP server manages its own pool of addresses and it will
never offer addresses or prefixes with already active leases.
Same remark on page 11 - 5.3.2

Page 11; 5.3.2
When IP connectivity exists between a MANET Router and a DHCP Server (set up
by whatever mechanism), what is the problem with DHCP-PD? I can't follow.
 
I agree with Thomas last comment on this point: what is the case if there is no IP connectivity between the MANET Router and the DHCP server. This case can frequently occur according to the scenario type and here, there is an issue.

Page 12; R 02
First, the term prefix. I think this term is used in another context as
RFC4291. In RFC4291 a prefix is simply the subnet part of an address. In
this document, we specify that a prefix is some kind a aggregate of subnets.
I like this approach, as aggregating may reduce routing protocol overhead.
But using the same term for two purposes is confusing.
Second, I think the aggregated prefix allocation is a bootstrap problem
(onetime shot) and I am not sure if this requirement is a "must" in the
MANET Autoconf context. I think also the allocated prefixes are to be used
for the non-MANET interfaces on a MANET Router. I think current protocols
for prefix delegation can be used, under the condition that the requirements
for MANET address autoconfiguration are fulfilled.

Page 12; R 05
c/asymetry/asymmetry/

CU@philly,
Teco
------=_Part_14666_29303953.1203499878802-- --===============0773531674== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Autoconf mailing list Autoconf@ietf.org http://www.ietf.org/mailman/listinfo/autoconf --===============0773531674==-- From autoconf-bounces@ietf.org Wed Feb 20 02:57:48 2008 Return-Path: X-Original-To: ietfarch-autoconf-archive@core3.amsl.com Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9BCE33A6C5B; Wed, 20 Feb 2008 02:57:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.519 X-Spam-Level: X-Spam-Status: No, score=-1.519 tagged_above=-999 required=5 tests=[AWL=-1.082, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KL1WRAFdMbIj; Wed, 20 Feb 2008 02:57:46 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A43DD3A6B14; Wed, 20 Feb 2008 02:57:46 -0800 (PST) X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 248D43A6927 for ; Wed, 20 Feb 2008 02:57:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DWOLzj4a5cnr for ; Wed, 20 Feb 2008 02:57:43 -0800 (PST) Received: from hpsmtp-eml12.kpnxchange.com (hpsmtp-eml12.KPNXCHANGE.COM [213.75.38.112]) by core3.amsl.com (Postfix) with ESMTP id B4C3828C368 for ; Wed, 20 Feb 2008 02:56:48 -0800 (PST) Received: from hpsmtp-eml08.kpnxchange.com ([213.75.38.108]) by hpsmtp-eml12.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Feb 2008 11:56:44 +0100 Received: from M90Teco ([86.83.9.22]) by hpsmtp-eml08.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Feb 2008 11:56:30 +0100 From: "Teco Boot" To: "'Emmanuel Baccelli'" , "'Thomas Clausen'" References: <47AAC029.8030908@dif.um.es> <47B9A5BF.9060106@inria.fr> <000001c8726b$9d66b440$d8341cc0$@nl> <47BAC6D1.7060100@inria.fr> In-Reply-To: Date: Wed, 20 Feb 2008 11:56:15 +0100 Message-ID: <001e01c873af$3ab21700$b0164500$@nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Achy/v/dZIgLPcs7QXqpav9UDnjR1QAnn4Iw Content-Language: nl X-OriginalArrivalTime: 20 Feb 2008 10:56:30.0675 (UTC) FILETIME=[3FCA4230:01C873AF] Cc: autoconf@ietf.org Subject: Re: [Autoconf] AUTOCONF Problem Statement: reviews needed. X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Hi, Some comments inline. I have more thoughts which I did not mention in my first response: On uniqueness validation, I posted before my reservations on active DAD. In many cases, this is not needed. RFC4862: > To accommodate > sites that believe the overhead of performing Duplicate Address > Detection outweighs its benefits, the use of Duplicate Address > Detection can be disabled through the administrative setting of a > per-interface configuration flag. The old version of our Problem Statement had some text on this. On multi-homed subordinate MANETs, the current document does not describe this scenario in detail. It is just an instance of a subordinate MANET, as this category is described with "is connected to at least one external network N". I think multi-homed subordinate MANET scenario introduces a large, new problem which is related to the selection mechanism of the path to one of the external networks. This path selection is out-of-control for Autoconf, as it is up to the (MANET) routing protocol to find out the path to the destination. Scenario: '. / `. Network N / Topologically correct `. _,' prefix q:: with Topologically correct `-.__ _,,' respect to network M prefix p:: with `'-.,._,,'' ___ respect to network N : ,-=B4 +-:-+ / = |MNR| ; N +-|-+ / E +-+ +---+ / /|\ \ +---+ ; T = | |...MNR--- .-. ---MNR:....., W +-+ +---+ \ ,-( _)-. / +---+ ! O .-(_ MANET )-. ! R Other ( Communication ) : K Nodes `-(______)-' \ = and \|/ \|/ : M Networks +-|-+ +-|-+ \ = |MNR| \|/ |MNR| \_____ = +-:-+ +-|-+ +-:-+ = |MNR| : +-:-+ +-+ +-+ Now, we have to select a topologically correct prefix p:: with respect to network N but not to network M or a topologically correct prefix q:: with respect to network M but not to network N. It is very hard to select p:: or q::, as it is dependent on the (dynamic) topology of the MANET and the MANET routing protocol. By my knowledge, the MANET protocols we have right now are using the destination IP address for forwarding and not the source IP address. Any thoughts including this problem in the Problem Statement document? I have also my thoughts on needs for authorization on using the external network. I think in real world, many access providers no not allow unauthorized nodes to have access. Getting an address in not that much a problem, using the access network is. = Regards, Teco > -----Oorspronkelijk bericht----- > >> Page 4; Network merging: > >> Why not using "MANET merging"? > >> Same for Network partitioning. > >> And why using term "disconnected MANETs"? What is the difference > with > >> "Autonomous MANETs"? > > > > Nework merging can happen between two subordinate MANETs (you would > > then > > get a multihomed MANET). The definition of "network merging" may be > > useful to networks in general, not just MANETs. [Teco:] = I think we should scope on MANET networks only. = > >> Page 10; 5.1.2. > >> I don't think correctly operating DHCP servers will provide non- > >> unique IP > >> addresses. Why is this suggested? > >> I would say each DHCP server manages its own pool of addresses and > it > > will > >> never offer addresses or prefixes with already active leases. > >> Same remark on page 11 - 5.3.2 > >> > > > > Yes. But an issue may arise if the pools of addresses of multiple > DHCP > > servers in the same MANET are not disjoint. This is the issue that is > > raised. > = > Just to clarify: Emmanuel, are you suggesting that two DHCP servers > "share" a pool of addresses, without co-ordinating leases with each > other? Does that happen? I think Teco is right in that it doesn't, > unless something is broken elsewhere? Or, are you talking about the > situation in which this co-ordination happens only through the MANET, > which becomes disconnected? [Teco:] = I think this is a DHCP problem and it is not specific to MANETs. The DHC WG should work on this. DHC WG is already chartered to cope with wireless / insecure / public LANs. > >> Page 11; 5.3.2 > >> When IP connectivity exists between a MANET Router and a DHCP Server > > (set up > >> by whatever mechanism), what is the problem with DHCP-PD? I can't > >> follow. > > > > Well, you are basically dependent on a routing protocol of sorts > > then, no? > = > Hu-humm.....DHCP proxies and promiscuous abuse of broadcasting seems > an off-the-cuff way to make it happen without a routing protocol as > such. Or (and someone *will* object, but I have seen it done) simple > classical flooding of any and all DHCP traffic, blatantly ignoring > address scopes and hop-limits. > = > In other words, I can imagine ways where no routing protocol as such > is required - granted, I do not recommend any of those in the > abbreviated form stated above. The question is as to if the issue is > captured correctly in the I-D (i.e. does IP connectivity exist > between a MANET router and a DHCP server in the scenarios envisioned? > If not, we need to explain that, plus why. If yes, then Teco seems to > be right ;) ) [Teco:] = I think Autoconf should work on address assignment and MANET WG should work on the routing protocol. Before IP connectivity is arranged, the first step is getting a MANET address. The Second step is MANET routing. After step 2, I think communication between a MANET Router and a DHCP Server should work. Maybe there is a bootstrap problem on DHCP Server discovery, especially if the address (step 1) was not assigned by a DHCP server. On DHCP and routing protocol dependency, I agree there is a problem for getting an address. This is section 5.1. On getting a prefix (section 5.3), there may be a problem. I think section 5.3.1. should describe what the DHCP-PD problem really is. > >> Page 12; R 02 > >> First, the term prefix. I think this term is used in another > >> context as > >> RFC4291. In RFC4291 a prefix is simply the subnet part of an > >> address. In > >> this document, we specify that a prefix is some kind a aggregate of > > subnets. > >> I like this approach, as aggregating may reduce routing protocol > > overhead. > >> But using the same term for two purposes is confusing. > >> Second, I think the aggregated prefix allocation is a bootstrap > >> problem > >> (onetime shot) and I am not sure if this requirement is a "must" > >> in the > >> MANET Autoconf context. I think also the allocated prefixes are to > be > > used > >> for the non-MANET interfaces on a MANET Router. I think current > >> protocols > >> for prefix delegation can be used, under the condition that the > > requirements > >> for MANET address autoconfiguration are fulfilled. > >> > > > > Well this requirement is basically a direct translation of what is > > specified in the MANET arch document. So I guess that if we want to > > have > > this discussion, we should take it there first. But I am not sure > this > > is relevant in that this discussion already happened I guess. [Teco:] = I think pointing to each other doesn't help much. The name of the document is "Terminology and Problem Statement". I think it makes sense that terms are defined clearly in this document and that ManetArch is updated, if needed. = ManetArch does not provide a definition of the term prefix. This document does, and it is not exactly what is described in RFC4291. I do not have a problem with the "aggregatable pool of addresses" definition (out of section 2.), but some of us could get confused. Why not adding the term in 2? Bring in line with RFC3513 & RFC3587 and use Global Routing Prefix and Subnet Prefix? Use MANET Routing Prefix, if we do not want to use Global Routing Prefix? _______________________________________________ Autoconf mailing list Autoconf@ietf.org http://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Wed Feb 20 03:52:49 2008 Return-Path: X-Original-To: ietfarch-autoconf-archive@core3.amsl.com Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B66728C7D9; Wed, 20 Feb 2008 03:52:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.629 X-Spam-Level: X-Spam-Status: No, score=-0.629 tagged_above=-999 required=5 tests=[AWL=-1.192, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=1, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hbdsylbMkH9X; Wed, 20 Feb 2008 03:52:42 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A80A28C1A3; Wed, 20 Feb 2008 03:51:44 -0800 (PST) X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 39AFF28C1A3 for ; Wed, 20 Feb 2008 03:51:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SuzEsP8XRruX for ; Wed, 20 Feb 2008 03:51:37 -0800 (PST) Received: from hpsmtp-eml14.kpnxchange.com (hpsmtp-eml14.KPNXCHANGE.COM [213.75.38.114]) by core3.amsl.com (Postfix) with ESMTP id 6382328C12A for ; Wed, 20 Feb 2008 03:51:35 -0800 (PST) Received: from hpsmtp-eml10.kpnxchange.com ([213.75.38.110]) by hpsmtp-eml14.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Feb 2008 12:51:32 +0100 Received: from M90Teco ([86.83.9.22]) by hpsmtp-eml10.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Feb 2008 12:51:01 +0100 From: "Teco Boot" To: "'Hasnaa Moustafa'" References: In-Reply-To: Date: Wed, 20 Feb 2008 12:50:38 +0100 Message-ID: <002201c873b6$d8dc2f90$8a948eb0$@nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Achzo1tg5ojkD8iFQleUze/EXYogoAAC+YCA Content-Language: nl X-OriginalArrivalTime: 20 Feb 2008 11:51:03.0207 (UTC) FILETIME=[DE5F0370:01C873B6] Cc: autoconf@ietf.org Subject: Re: [Autoconf] Autoconf Digest, Vol 25, Issue 3 X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0397439504==" Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Dit is een meerdelig bericht met een MIME-indeling. --===============0397439504== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0023_01C873BF.3AA09790" Content-Language: nl Dit is een meerdelig bericht met een MIME-indeling. ------=_NextPart_000_0023_01C873BF.3AA09790 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Comments inline. CU, Teco Van: Hasnaa Moustafa [mailto:hasnaa.moustafa@gmail.com] Verzonden: woensdag 20 februari 2008 10:31 Aan: Teco Boot CC: autoconf@ietf.org Onderwerp: Re: Autoconf Digest, Vol 25, Issue 3 Page 4; Network merging: Why not using "MANET merging"? Same for Network partitioning. And why using term "disconnected MANETs"? What is the difference with "Autonomous MANETs"? I agree with Emmanuel comment that Network merging is a more general term. As this may be a merging of a MANET with an infrastructure network for instance, same thing for partitioning. [Teco:] This confuses me. I cannot think of a merge between a MANET network and a non-MANET network. A network is one or the other. Concerning the term "disconnected": these are disconnected MANETs that got merged, where this may happen for autonomous and subordinate categories. [Teco:] I think the term is an orphan. In previous versions, we had Connected MANET. Now, this is called Subordinate MANET. The new term Autonomous MANET is the opposite of a Subordinate MANET. If disconnected MANET is something else than Autonomous MANET, I want to know. Old text: Network merging - the process by which two or more previously disconnected MANETs get connected. Network partitioning - the process by which a MANET splits into two or more disconnected MANETs. Suggested text: MANET merging - the process by which two or more MANETs get connected. MANET partitioning - the process by which a MANET splits into two or more MANETs. Page 6; 3.1.1. I think Car-to-car communication is more or less an autonomous MANET, where car-to-infrastructure is an example of a subordinate MANET. c/Car-to-car communication networks/Vehicle communication networks/ ?? Agree on vehicular communication, however this can fall under the two categories (autonoumous and subordinate) according to the application (if we need Internet for example), and to the road architecture (if there are some fixed deployed entities belonging to a certain authority for example). [Teco:] This is clear in the text. I did not copy the whole paragraph. Page 10; 5.1.2. I don't think correctly operating DHCP servers will provide non-unique IP addresses. Why is this suggested? Actually, it is mentioned that this approach "could be used to some extent for uniqueness maintenance", implying that this is not the whole solution for IP address uniqueness. [Teco:] Yes, there could be incorrectly operating DHCP servers, and collisions with (invalid) manual configured addresses or SLAAC addresses. The text below your quote: For instance if the topology is or becomes such that several DHCP servers configure hosts independently in a MANET, there is no guarantee that leased addresses will indeed be unique, since the DHCP servers will not check a priori the disjoint character of the prefixes they provide leases from. I don't think this will occur. Page 11; 5.3.2 When IP connectivity exists between a MANET Router and a DHCP Server (set up by whatever mechanism), what is the problem with DHCP-PD? I can't follow. I agree with Thomas last comment on this point: what is the case if there is no IP connectivity between the MANET Router and the DHCP server. This case can frequently occur according to the scenario type and here, there is an issue. [Teco:] I included the condition that there is IP connectivity. More on this in the other posting. ------=_NextPart_000_0023_01C873BF.3AA09790 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Comments inline.

CU, Teco

 

Van:<= /b> = Hasnaa Moustafa [mailto:hasnaa.moustafa@gmail.com]
Verzonden: woensdag 20 februari 2008 10:31
Aan: Teco Boot
CC: autoconf@ietf.org
Onderwerp: Re: Autoconf Digest, Vol 25, Issue = 3

 


Page 4; Network merging:
Why not using "MANET merging"?
Same for Network partitioning.
And why using term "disconnected MANETs"? What is the = difference with
"Autonomous MANETs"?

 

I agree with Emmanuel comment that Network = merging is a more general term. As this may be a merging of a MANET with an = infrastructure network for instance, same thing for partitioning.

[Teco:]

This confuses me. I cannot think of a merge between a = MANET network and a non-MANET network. A network is one or the = other.

 

 

Concerning the term "disconnected": these are disconnected MANETs that got merged, where this may happen for autonomous and subordinate categories. 

[Teco:]

I think the term is an orphan. In previous versions, we = had Connected MANET. Now, this is called Subordinate = MANET.

The new term Autonomous MANET is the opposite of a = Subordinate MANET.

If disconnected MANET is something else than Autonomous = MANET, I want to know.

 

Old text:

Network merging  = - the process by which two or more previously

      disconnected MANETs get connected.

Network = partitioning  - the process by which a MANET splits into = two

      or more disconnected = MANETs.

Suggested text:

  MANET merging  - the process by which two or = more MANETs get connected.

MANET = partitioning  - the process by which a MANET splits into = two

      or more = MANETs.

 

 

Page 6; 3.1.1.
I think Car-to-car communication is more or less an autonomous MANET, = where
car-to-infrastructure is an example of a subordinate MANET.
c/Car-to-car communication networks/Vehicle communication networks/ = ??

 

Agree on vehicular communication, however this can = fall under the two categories (autonoumous and subordinate) according to the application (if we need Internet for example), and to the road = architecture (if there are some fixed deployed entities belonging to a certain authority for example).

[Teco:] This is clear in the text. I did not copy the = whole paragraph.

 

Page 10; 5.1.2.
I don't think correctly operating DHCP servers will provide non-unique = IP
addresses. Why is this suggested?

 

Actually, it is mentioned that this approach = "could be used to some extent for uniqueness maintenance", implying that this = is not the whole solution for IP address uniqueness.

[Teco:] Yes, there could be incorrectly operating DHCP = servers, and collisions with (invalid) manual configured addresses or SLAAC = addresses.

The text below your quote:

   For = instance if the

   topology = is or becomes such that several DHCP servers configure = hosts

   = independently in a MANET, there is no guarantee that leased = addresses

   will = indeed be unique, since the DHCP servers will not check a = priori

     the disjoint character of the = prefixes they provide leases from.

I don’t think this will = occur.

 


Page 11; 5.3.2
When IP connectivity exists between a MANET Router and a DHCP Server = (set up
by whatever mechanism), what is the problem with DHCP-PD? I can't = follow.

 

I agree with Thomas last comment on this point: = what is the case if there is no IP connectivity between the MANET Router and the = DHCP server. This case can frequently occur according to the scenario type = and here, there is an issue.

[Teco:] I included the condition that there is IP connectivity. More on this in the other = posting.

------=_NextPart_000_0023_01C873BF.3AA09790-- --===============0397439504== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Autoconf mailing list Autoconf@ietf.org http://www.ietf.org/mailman/listinfo/autoconf --===============0397439504==-- From autoconf-bounces@ietf.org Wed Feb 20 04:40:30 2008 Return-Path: X-Original-To: ietfarch-autoconf-archive@core3.amsl.com Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5CBC928C7A5; Wed, 20 Feb 2008 04:40:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.078 X-Spam-Level: X-Spam-Status: No, score=-1.078 tagged_above=-999 required=5 tests=[AWL=-1.540, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_21=0.6, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LvRsDspyc6Yn; Wed, 20 Feb 2008 04:40:29 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1334528C70E; Wed, 20 Feb 2008 04:40:29 -0800 (PST) X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E5DD28C70E for ; Wed, 20 Feb 2008 04:40:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dF9HyCdquafr for ; Wed, 20 Feb 2008 04:40:26 -0800 (PST) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 2C49B28C0E1 for ; Wed, 20 Feb 2008 04:40:25 -0800 (PST) Received: from [163.117.139.72] (acorde.it.uc3m.es [163.117.139.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp01.uc3m.es (Postfix) with ESMTP id 90F373E2AA3; Wed, 20 Feb 2008 13:34:32 +0100 (CET) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Teco Boot In-Reply-To: <001e01c873af$3ab21700$b0164500$@nl> References: <47AAC029.8030908@dif.um.es><47B9A5BF.9060106@inria.fr> <000001c 8726b$9d66b440$d8341cc0$@nl><47BAC6D1.7060100@inria.fr> <001e01c873af$3ab21700$b0164500$@nl> Organization: Universidad Carlos III de Madrid Date: Wed, 20 Feb 2008 13:34:33 +0100 Message-Id: <1203510873.4276.60.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 Cc: autoconf@ietf.org, 'Emmanuel Baccelli' , 'Thomas Clausen' Subject: Re: [Autoconf] AUTOCONF Problem Statement: reviews needed. X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1889786557==" Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org --===============1889786557== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-UJRAnT6BUEbtSuqhZcWP" --=-UJRAnT6BUEbtSuqhZcWP Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Teco, Thanks for the detailed comments. Some comments inline... On mi=E9, 2008-02-20 at 11:56 +0100, Teco Boot wrote: > Hi, >=20 > Some comments inline. >=20 > I have more thoughts which I did not mention in my first response: >=20 > On uniqueness validation, I posted before my reservations on active DAD. = In > many cases, this is not needed. RFC4862: > > To accommodate > > sites that believe the overhead of performing Duplicate Address > > Detection outweighs its benefits, the use of Duplicate Address > > Detection can be disabled through the administrative setting of a > > per-interface configuration flag. > The old version of our Problem Statement had some text on this. >=20 > On multi-homed subordinate MANETs, the current document does not describe > this scenario in detail. It is just an instance of a subordinate MANET, a= s > this category is described with "is connected to at least one external > network N". > I think multi-homed subordinate MANET scenario introduces a large, new > problem which is related to the selection mechanism of the path to one of > the external networks. This path selection is out-of-control for Autoconf= , > as it is up to the (MANET) routing protocol to find out the path to the > destination. > Scenario: >=20 >=20 > '. / > `. Network N / Topologically correct > `. _,' prefix q:: with > Topologically correct `-.__ _,,' respect to network M > prefix p:: with `'-.,._,,'' ___ > respect to network N : ,-=B4 > +-:-+ / =20 > |MNR| ; N > +-|-+ / E > +-+ +---+ / /|\ \ +---+ ; T=20 > | |...MNR--- .-. ---MNR:....., W > +-+ +---+ \ ,-( _)-. / +---+ ! O > .-(_ MANET )-. ! R > Other ( Communication ) : K > Nodes `-(______)-' \ =20 > and \|/ \|/ : M > Networks +-|-+ +-|-+ \=20 > |MNR| \|/ |MNR| \_____ =20 > +-:-+ +-|-+ +-:-+ =20 > |MNR| : > +-:-+ +-+ > +-+ >=20 > Now, we have to select a topologically correct prefix p:: with respect to > network N but not to network M or a topologically correct prefix q:: with > respect to network M but not to network N. It is very hard to select p:: = or > q::, as it is dependent on the (dynamic) topology of the MANET and the MA= NET > routing protocol. By my knowledge, the MANET protocols we have right now = are > using the destination IP address for forwarding and not the source IP > address. > Any thoughts including this problem in the Problem Statement document? [Carlos] In this case, I'm not sure this issues should be documented in the PS document. To me, this seems more related to routing, but not to IP address autoconfiguration. I agree it is an important problem, but IMHO we are only concerned in this document in providing MNRs with valid and unique IP addresses/prefixes. Do others share that view? maybe I'm missing something... One more comment below... >=20 > I have also my thoughts on needs for authorization on using the external > network. I think in real world, many access providers no not allow > unauthorized nodes to have access. Getting an address in not that much a > problem, using the access network is.=20 [Carlos] This could be related to security, although I see network access authorisation as some-how an orthogonal problem to IP address autoconf. =09 >=20 > Regards, Teco >=20 >=20 >=20 >=20 > > -----Oorspronkelijk bericht----- > > > >> Page 4; Network merging: > > >> Why not using "MANET merging"? > > >> Same for Network partitioning. > > >> And why using term "disconnected MANETs"? What is the difference > > with > > >> "Autonomous MANETs"? > > > > > > Nework merging can happen between two subordinate MANETs (you would > > > then > > > get a multihomed MANET). The definition of "network merging" may be > > > useful to networks in general, not just MANETs. > [Teco:]=20 > I think we should scope on MANET networks only. >=20 > =20 > > >> Page 10; 5.1.2. > > >> I don't think correctly operating DHCP servers will provide non- > > >> unique IP > > >> addresses. Why is this suggested? > > >> I would say each DHCP server manages its own pool of addresses and > > it > > > will > > >> never offer addresses or prefixes with already active leases. > > >> Same remark on page 11 - 5.3.2 > > >> > > > > > > Yes. But an issue may arise if the pools of addresses of multiple > > DHCP > > > servers in the same MANET are not disjoint. This is the issue that is > > > raised. > >=20 > > Just to clarify: Emmanuel, are you suggesting that two DHCP servers > > "share" a pool of addresses, without co-ordinating leases with each > > other? Does that happen? I think Teco is right in that it doesn't, > > unless something is broken elsewhere? Or, are you talking about the > > situation in which this co-ordination happens only through the MANET, > > which becomes disconnected? > [Teco:]=20 > I think this is a DHCP problem and it is not specific to MANETs. > The DHC WG should work on this. > DHC WG is already chartered to cope with wireless / insecure / public LAN= s. >=20 >=20 > > >> Page 11; 5.3.2 > > >> When IP connectivity exists between a MANET Router and a DHCP Server > > > (set up > > >> by whatever mechanism), what is the problem with DHCP-PD? I can't > > >> follow. > > > > > > Well, you are basically dependent on a routing protocol of sorts > > > then, no? > >=20 > > Hu-humm.....DHCP proxies and promiscuous abuse of broadcasting seems > > an off-the-cuff way to make it happen without a routing protocol as > > such. Or (and someone *will* object, but I have seen it done) simple > > classical flooding of any and all DHCP traffic, blatantly ignoring > > address scopes and hop-limits. > >=20 > > In other words, I can imagine ways where no routing protocol as such > > is required - granted, I do not recommend any of those in the > > abbreviated form stated above. The question is as to if the issue is > > captured correctly in the I-D (i.e. does IP connectivity exist > > between a MANET router and a DHCP server in the scenarios envisioned? > > If not, we need to explain that, plus why. If yes, then Teco seems to > > be right ;) ) > [Teco:]=20 > I think Autoconf should work on address assignment and MANET WG should wo= rk > on the routing protocol. > Before IP connectivity is arranged, the first step is getting a MANET > address. The Second step is MANET routing. > After step 2, I think communication between a MANET Router and a DHCP Ser= ver > should work. Maybe there is a bootstrap problem on DHCP Server discovery, > especially if the address (step 1) was not assigned by a DHCP server. >=20 > On DHCP and routing protocol dependency, I agree there is a problem for > getting an address. This is section 5.1. >=20 > On getting a prefix (section 5.3), there may be a problem. I think sectio= n > 5.3.1. should describe what the DHCP-PD problem really is. >=20 >=20 > > >> Page 12; R 02 > > >> First, the term prefix. I think this term is used in another > > >> context as > > >> RFC4291. In RFC4291 a prefix is simply the subnet part of an > > >> address. In > > >> this document, we specify that a prefix is some kind a aggregate of > > > subnets. > > >> I like this approach, as aggregating may reduce routing protocol > > > overhead. > > >> But using the same term for two purposes is confusing. > > >> Second, I think the aggregated prefix allocation is a bootstrap > > >> problem > > >> (onetime shot) and I am not sure if this requirement is a "must" > > >> in the > > >> MANET Autoconf context. I think also the allocated prefixes are to > > be > > > used > > >> for the non-MANET interfaces on a MANET Router. I think current > > >> protocols > > >> for prefix delegation can be used, under the condition that the > > > requirements > > >> for MANET address autoconfiguration are fulfilled. > > >> > > > > > > Well this requirement is basically a direct translation of what is > > > specified in the MANET arch document. So I guess that if we want to > > > have > > > this discussion, we should take it there first. But I am not sure > > this > > > is relevant in that this discussion already happened I guess. > [Teco:]=20 > I think pointing to each other doesn't help much. > The name of the document is "Terminology and Problem Statement". I think = it > makes sense that terms are defined clearly in this document and that > ManetArch is updated, if needed.=20 > ManetArch does not provide a definition of the term prefix. This document > does, and it is not exactly what is described in RFC4291. I do not have a > problem with the "aggregatable pool of addresses" definition (out of sect= ion > 2.), but some of us could get confused. > Why not adding the term in 2? > Bring in line with RFC3513 & RFC3587 and use Global Routing Prefix and > Subnet Prefix? Use MANET Routing Prefix, if we do not want to use Global > Routing Prefix? >=20 [Carlos] For me, the use of prefix in the PS and in the MANET arch document is clear now, but I have to admit that I needed some time to get to it. If we want to clarify that, I think manet-arch document is the best place, IMO, since it's related to the networking model. Kind Regards, Carlos >=20 >=20 >=20 >=20 > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > http://www.ietf.org/mailman/listinfo/autoconf --=20 =A1AS=D3CIATE! Gratis para estudiantes http://www.telematica.ws Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ WEEDEV 2008: 1st Workshop on Experimental Evaluation and Deployment Experiences on Vehicular networks http://www.weedev.org/ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ --=-UJRAnT6BUEbtSuqhZcWP Content-Type: application/pgp-signature; name=signature.asc Content-Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBHvB5ZNdy6TdFwT2cRAjTkAKCJ/1d0O0Pzv4uWID8HQ+QRPz2oTACgwlKj HymmMNw48/o11mq+pxKAwis= =olGd -----END PGP SIGNATURE----- --=-UJRAnT6BUEbtSuqhZcWP-- --===============1889786557== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Autoconf mailing list Autoconf@ietf.org http://www.ietf.org/mailman/listinfo/autoconf --===============1889786557==-- From autoconf-bounces@ietf.org Wed Feb 20 05:12:56 2008 Return-Path: X-Original-To: ietfarch-autoconf-archive@core3.amsl.com Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6ED5D28C776; Wed, 20 Feb 2008 05:12:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.397 X-Spam-Level: X-Spam-Status: No, score=0.397 tagged_above=-999 required=5 tests=[AWL=-0.166, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=1, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DIUNrEDg7Txh; Wed, 20 Feb 2008 05:12:54 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE02F28C7EF; Wed, 20 Feb 2008 05:12:54 -0800 (PST) X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E55F028C576 for ; Wed, 20 Feb 2008 05:12:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2F0U4AyVla2c for ; Wed, 20 Feb 2008 05:12:51 -0800 (PST) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.185]) by core3.amsl.com (Postfix) with ESMTP id A9FBF28C17F for ; Wed, 20 Feb 2008 05:12:50 -0800 (PST) Received: by nf-out-0910.google.com with SMTP id d21so773148nfb.39 for ; Wed, 20 Feb 2008 05:12:46 -0800 (PST) Received: by 10.78.72.20 with SMTP id u20mr13253985hua.51.1203513165709; Wed, 20 Feb 2008 05:12:45 -0800 (PST) Received: by 10.78.40.16 with HTTP; Wed, 20 Feb 2008 05:12:45 -0800 (PST) Message-ID: Date: Wed, 20 Feb 2008 14:12:45 +0100 From: "Hasnaa Moustafa" To: "Teco Boot" In-Reply-To: MIME-Version: 1.0 References: Cc: autoconf@ietf.org Subject: Re: [Autoconf] Autoconf Digest, Vol 25, Issue 4 X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1363437438==" Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org --===============1363437438== Content-Type: multipart/alternative; boundary="----=_Part_16201_26667082.1203513165705" ------=_Part_16201_26667082.1203513165705 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Teco, Few comments inline. Hassnaa ------------------------------ Date: Wed, 20 Feb 2008 12:50:38 +0100 From: "Teco Boot" Subject: Re: [Autoconf] Autoconf Digest, Vol 25, Issue 3 To: "'Hasnaa Moustafa'" Cc: autoconf@ietf.org Message-ID: <002201c873b6$d8dc2f90$8a948eb0$@nl> Content-Type: text/plain; charset="us-ascii" Comments inline. CU, Teco Van: Hasnaa Moustafa [mailto:hasnaa.moustafa@gmail.com] Verzonden: woensdag 20 februari 2008 10:31 Aan: Teco Boot CC: autoconf@ietf.org Onderwerp: Re: Autoconf Digest, Vol 25, Issue 3 Page 4; Network merging: Why not using "MANET merging"? Same for Network partitioning. And why using term "disconnected MANETs"? What is the difference with "Autonomous MANETs"? I agree with Emmanuel comment that Network merging is a more general term. As this may be a merging of a MANET with an infrastructure network for instance, same thing for partitioning. [Teco:] This confuses me. I cannot think of a merge between a MANET network and a non-MANET network. A network is one or the other. Hassnaa: I agree, this is confusing when we say (MANET Merging). But if we say (Network Merging) this would not confuse. A merge between a MANET and non-MANET may occur in subordinate MANET when there is a connection with an external network. Section 3.1.1 in the draft gives an example of a "coverge extension case" when a MANET extends the coverage of a wide area wireless network and hence is connected to it. Concerning the term "disconnected": these are disconnected MANETs that got merged, where this may happen for autonomous and subordinate categories. [Teco:] I think the term is an orphan. In previous versions, we had Connected MANET. Now, this is called Subordinate MANET. The new term Autonomous MANET is the opposite of a Subordinate MANET. If disconnected MANET is something else than Autonomous MANET, I want to know. Old text: Network merging - the process by which two or more previously disconnected MANETs get connected. Network partitioning - the process by which a MANET splits into two or more disconnected MANETs. Suggested text: MANET merging - the process by which two or more MANETs get connected. MANET partitioning - the process by which a MANET splits into two or more MANETs. Hassnaa: the term "disconnected" and "autonomous" should not be compared. As "Autonomous" in the draft is a category of MANET, however the term "disconnected" used in the definition of "Network Merging" is to explain the case when two MANETs that are not connected together got merged. Page 6; 3.1.1. I think Car-to-car communication is more or less an autonomous MANET, where car-to-infrastructure is an example of a subordinate MANET. c/Car-to-car communication networks/Vehicle communication networks/ ?? Agree on vehicular communication, however this can fall under the two categories (autonoumous and subordinate) according to the application (if we need Internet for example), and to the road architecture (if there are some fixed deployed entities belonging to a certain authority for example). [Teco:] This is clear in the text. I did not copy the whole paragraph. Page 10; 5.1.2. I don't think correctly operating DHCP servers will provide non-unique IP addresses. Why is this suggested? Actually, it is mentioned that this approach "could be used to some extent for uniqueness maintenance", implying that this is not the whole solution for IP address uniqueness. [Teco:] Yes, there could be incorrectly operating DHCP servers, and collisions with (invalid) manual configured addresses or SLAAC addresses. The text below your quote: For instance if the topology is or becomes such that several DHCP servers configure hosts independently in a MANET, there is no guarantee that leased addresses will indeed be unique, since the DHCP servers will not check a priori the disjoint character of the prefixes they provide leases from. I don't think this will occur. Hassnaa: if there is no synchronisation between the DHCP servers then checking the disjoint character of the prefixes is an issue. Page 11; 5.3.2 When IP connectivity exists between a MANET Router and a DHCP Server (set up by whatever mechanism), what is the problem with DHCP-PD? I can't follow. I agree with Thomas last comment on this point: what is the case if there is no IP connectivity between the MANET Router and the DHCP server. This case can frequently occur according to the scenario type and here, there is an issue. [Teco:] I included the condition that there is IP connectivity. More on this in the other posting. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.ietf.org/pipermail/autoconf/attachments/20080220/6fe9bbe6/attachment.htm ------------------------------ ------=_Part_16201_26667082.1203513165705 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Hi Teco,
 
Few comments inline.
 
Hassnaa

------------------------------
Date: Wed, 20 Feb 2008 12:50:38 +0100
From: "Teco Boot" <teco@inf-net.nl>
Subject: Re: [Autoconf] Autoconf Digest, Vol 25, Issue 3
To: "'Hasnaa Moustafa'" <hasnaa.moustafa@gmail.com>
Cc: autoconf@ietf.org
Message-ID: <002201c873b6$d8dc2f90$8a948eb0$@nl>
Content-Type: text/plain; charset="us-ascii"

Comments inline.

CU, Teco



Van: Hasnaa Moustafa [mailto:hasnaa.moustafa@gmail.com]
Verzonden: woensdag 20 februari 2008 10:31
Aan: Teco Boot
CC: autoconf@ietf.org
Onderwerp: Re: Autoconf Digest, Vol 25, Issue 3




Page 4; Network merging:
Why not using "MANET merging"?
Same for Network partitioning.
And why using term "disconnected MANETs"? What is the difference with
"Autonomous MANETs"?



I agree with Emmanuel comment that Network merging is a more general term.
As this may be a merging of a MANET with an infrastructure network for
instance, same thing for partitioning.

[Teco:]

This confuses me. I cannot think of a merge between a MANET network and a
non-MANET network. A network is one or the other.

Hassnaa: I agree, this is confusing when we say (MANET Merging). But if we say (Network Merging) this would not confuse. A merge between a MANET and non-MANET may occur in subordinate MANET when there is a connection with an external network. Section 3.1.1 in the draft gives an example of a "coverge extension case" when a MANET extends the coverage of a wide area wireless network and hence is connected to it.



Concerning the term "disconnected": these are disconnected MANETs that got
merged, where this may happen for autonomous and subordinate categories.

[Teco:]

I think the term is an orphan. In previous versions, we had Connected MANET.
Now, this is called Subordinate MANET.
 
The new term Autonomous MANET is the opposite of a Subordinate MANET.

If disconnected MANET is something else than Autonomous MANET, I want to
know.



Old text:

Network merging  - the process by which two or more previously

     disconnected MANETs get connected.

Network partitioning  - the process by which a MANET splits into two

     or more disconnected MANETs.

Suggested text:

MANET merging  - the process by which two or more MANETs get connected.

MANET partitioning  - the process by which a MANET splits into two

     or more MANETs.


Hassnaa: the term "disconnected" and "autonomous" should not be compared. As "Autonomous" in the draft is a category of MANET, however the term "disconnected" used in the definition of "Network Merging" is to explain the case when two MANETs that are not connected together got merged.


Page 6; 3.1.1.
I think Car-to-car communication is more or less an autonomous MANET, where
car-to-infrastructure is an example of a subordinate MANET.
c/Car-to-car communication networks/Vehicle communication networks/ ??



Agree on vehicular communication, however this can fall under the two
categories (autonoumous and subordinate) according to the application (if we
need Internet for example), and to the road architecture (if there are some
fixed deployed entities belonging to a certain authority for example).

[Teco:] This is clear in the text. I did not copy the whole paragraph.



Page 10; 5.1.2.
I don't think correctly operating DHCP servers will provide non-unique IP
addresses. Why is this suggested?



Actually, it is mentioned that this approach "could be used to some extent
for uniqueness maintenance", implying that this is not the whole solution
for IP address uniqueness.

[Teco:] Yes, there could be incorrectly operating DHCP servers, and
collisions with (invalid) manual configured addresses or SLAAC addresses.

The text below your quote:

  For instance if the

  topology is or becomes such that several DHCP servers configure hosts

  independently in a MANET, there is no guarantee that leased addresses

  will indeed be unique, since the DHCP servers will not check a priori

    the disjoint character of the prefixes they provide leases from.

I don't think this will occur.
 
Hassnaa: if there is no synchronisation between the DHCP servers then checking the disjoint character of the prefixes is an issue.



Page 11; 5.3.2
When IP connectivity exists between a MANET Router and a DHCP Server (set up
by whatever mechanism), what is the problem with DHCP-PD? I can't follow.



I agree with Thomas last comment on this point: what is the case if there is
no IP connectivity between the MANET Router and the DHCP server. This case
can frequently occur according to the scenario type and here, there is an
issue.

[Teco:] I included the condition that there is IP connectivity. More on this
in the other posting.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ietf.org/pipermail/autoconf/attachments/20080220/6fe9bbe6/attachment.htm

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

 

------=_Part_16201_26667082.1203513165705-- --===============1363437438== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Autoconf mailing list Autoconf@ietf.org http://www.ietf.org/mailman/listinfo/autoconf --===============1363437438==-- From autoconf-bounces@ietf.org Wed Feb 20 05:23:56 2008 Return-Path: X-Original-To: ietfarch-autoconf-archive@core3.amsl.com Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E9B2A28C7E6; Wed, 20 Feb 2008 05:23:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.372 X-Spam-Level: X-Spam-Status: No, score=0.372 tagged_above=-999 required=5 tests=[AWL=-0.191, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=1, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nxidwZuPeVs7; Wed, 20 Feb 2008 05:23:55 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC23E28C18C; Wed, 20 Feb 2008 05:23:55 -0800 (PST) X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE23528C605 for ; Wed, 20 Feb 2008 05:23:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id su3L1yf3BENM for ; Wed, 20 Feb 2008 05:23:53 -0800 (PST) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.186]) by core3.amsl.com (Postfix) with ESMTP id DAEED28C351 for ; Wed, 20 Feb 2008 05:23:52 -0800 (PST) Received: by nf-out-0910.google.com with SMTP id d21so775202nfb.39 for ; Wed, 20 Feb 2008 05:23:49 -0800 (PST) Received: by 10.78.175.8 with SMTP id x8mr13361113hue.77.1203513828626; Wed, 20 Feb 2008 05:23:48 -0800 (PST) Received: by 10.78.40.16 with HTTP; Wed, 20 Feb 2008 05:23:48 -0800 (PST) Message-ID: Date: Wed, 20 Feb 2008 14:23:48 +0100 From: "Hasnaa Moustafa" To: "Teco Boot" In-Reply-To: MIME-Version: 1.0 References: Cc: autoconf@ietf.org Subject: Re: [Autoconf] Autoconf Digest, Vol 25, Issue 4 X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2011327691==" Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org --===============2011327691== Content-Type: multipart/alternative; boundary="----=_Part_16263_2608773.1203513828623" ------=_Part_16263_2608773.1203513828623 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Teco, A small comment on the authorization point that you discussed, and in fact we have had some discussions on this point before. I agree with you on this point. Actually R10. in the draft discusses the security issue and IMHO, this could be elaborated to highligh the authorization issue. Kind Regards, Hassnaa > ------------------------------ > Date: Wed, 20 Feb 2008 11:56:15 +0100 > From: "Teco Boot" > Subject: Re: [Autoconf] AUTOCONF Problem Statement: reviews needed. > To: "'Emmanuel Baccelli'" , "'Thomas > Clausen'" > Cc: autoconf@ietf.org > Message-ID: <001e01c873af$3ab21700$b0164500$@nl> > Content-Type: text/plain; charset="iso-8859-1" > > Hi, > > Some comments inline. > > I have more thoughts which I did not mention in my first response: > > On uniqueness validation, I posted before my reservations on active DAD. > In > many cases, this is not needed. RFC4862: > > To accommodate > > sites that believe the overhead of performing Duplicate Address > > Detection outweighs its benefits, the use of Duplicate Address > > Detection can be disabled through the administrative setting of a > > per-interface configuration flag. > The old version of our Problem Statement had some text on this. > > On multi-homed subordinate MANETs, the current document does not describe > this scenario in detail. It is just an instance of a subordinate MANET, as > this category is described with "is connected to at least one external > network N". > I think multi-homed subordinate MANET scenario introduces a large, new > problem which is related to the selection mechanism of the path to one of > the external networks. This path selection is out-of-control for Autoconf, > as it is up to the (MANET) routing protocol to find out the path to the > destination. > Scenario: > > > '. / > `. Network N / Topologically correct > `. _,' prefix q:: with > Topologically correct `-.__ _,,' respect to network M > prefix p:: with `'-.,._,,'' ___ > respect to network N : ,-? > +-:-+ / > |MNR| ; N > +-|-+ / E > +-+ +---+ / /|\ \ +---+ ; T > | |...MNR--- .-. ---MNR:....., W > +-+ +---+ \ ,-( _)-. / +---+ ! O > .-(_ MANET )-. ! R > Other ( Communication ) : K > Nodes `-(______)-' \ > and \|/ \|/ : M > Networks +-|-+ +-|-+ \ > |MNR| \|/ |MNR| \_____ > +-:-+ +-|-+ +-:-+ > |MNR| : > +-:-+ +-+ > +-+ > > Now, we have to select a topologically correct prefix p:: with respect to > network N but not to network M or a topologically correct prefix q:: with > respect to network M but not to network N. It is very hard to select p:: > or > q::, as it is dependent on the (dynamic) topology of the MANET and the > MANET > routing protocol. By my knowledge, the MANET protocols we have right now > are > using the destination IP address for forwarding and not the source IP > address. > Any thoughts including this problem in the Problem Statement document? > > I have also my thoughts on needs for authorization on using the external > network. I think in real world, many access providers no not allow > unauthorized nodes to have access. Getting an address in not that much a > problem, using the access network is. > > Regards, Teco > > > > ------=_Part_16263_2608773.1203513828623 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Hi Teco,
 
A small comment on the authorization point that you discussed, and in = fact we have had some discussions on this point before.
 
I agree with you on this point. Actually R10. in the draft discusses t= he security issue and IMHO, this could be elaborated to highligh the author= ization issue.
 
Kind Regards,
Hassnaa
 
------------------------------Date: Wed, 20 Feb 2008 11:56:15 +0100
From: "Teco Boot" <= teco@inf-net.nl>
Subject: Re: [Autoconf] AUTOCONF Problem Statement: reviews needed.
To: = "'Emmanuel Baccelli'" <Emmanuel.Baccelli@inria.fr>, "'Thomas
&nb= sp;      Clausen'" <thomas@thomasclausen.org>
Cc: autoconf@ietf.org
Message-I= D: <001e01c873af$3ab21700$b0164500$@nl>
Content-Type: text/plain;&= nbsp;      charset=3D"iso-8859-1"
Hi,

Some comments inline.

I have more thoughts which I did not mention in my first response:
<= br>On uniqueness validation, I posted before my reservations on active DAD.= In
many cases, this is not needed. RFC4862:
>  To accom= modate
>  sites that believe the overhead of performing Duplicate Add= ress
>  Detection outweighs its benefits, the use of Duplic= ate Address
>  Detection can be disabled through the admini= strative setting of a
>  per-interface configuration flag.<= br> The old version of our Problem Statement had some text on this.

On m= ulti-homed subordinate MANETs, the current document does not describe
th= is scenario in detail. It is just an instance of a subordinate MANET, as this category is described with "is connected to at least one external=
network N".
I think multi-homed subordinate MANET scenario intr= oduces a large, new
problem which is related to the selection mechanism = of the path to one of
the external networks. This path selection is out-of-control for Autoconf,<= br>as it is up to the (MANET) routing protocol to find out the path to the<= br>destination.
Scenario:


      = ;            &#= 39;.            = ;            &n= bsp;  /
            &nb= sp;      `.      &nb= sp; Network N        / &n= bsp; Topologically correct
       &nb= sp;            = `.            =         _,'   &n= bsp;      prefix q:: with
Topologically co= rrect `-.__           _,,= '        respect to network M        prefix p:: with    = ;  `'-.,._,,''      &nb= sp;            =  ___
  respect to network N     =      :       &n= bsp;            = ;   ,-?
         =             &nb= sp;        +-:-+   &= nbsp;           &nbs= p;    /
       &n= bsp;            = ;          |MNR| &nb= sp;            =      ;    N
            &nb= sp;            =      +-|-+      &nbs= p;           / =     E
        &nb= sp;    +-+  +---+ /     &= nbsp;/|\       \ +---+    = ; ;     T
       =       | |...MNR---     &n= bsp; .-.      ---MNR:.....,   =   W
          &nb= sp;  +-+  +---+ \    ,-(  _)-.=    / +---+     !     O             &nb= sp;            =  .-(_ MANET  )-.       &n= bsp;    !     R
  &nbs= p;          Other  &= nbsp;    ( Communication )     &nbs= p;     :     K
   = ;          Nodes  &n= bsp;       `-(______)-'  &= nbsp;           \             a= nd         \|/   &nb= sp;         \|/   &n= bsp;       :   M
             Ne= tworks   +-|-+        &nb= sp;  +-|-+          = \
           &nbs= p;            |= MNR|    \|/    |MNR|  &nb= sp;        \_____
   &= nbsp;           &nbs= p;        +-:-+   +-|-+&n= bsp;  +-:-+
         &= nbsp;           &nbs= p;          |MNR| &n= bsp;   :
            &nb= sp;            =        +-:-+    +-+<= br>            =             &nb= sp;            =     +-+

Now, we have to select a topologically correc= t prefix p:: with respect to
network N but not to network M or a topolog= ically correct prefix q:: with
respect to network M but not to network N. It is very hard to select p:: or=
q::, as it is dependent on the (dynamic) topology of the MANET and the = MANET
routing protocol. By my knowledge, the MANET protocols we have rig= ht now are
using the destination IP address for forwarding and not the source IP
ad= dress.
Any thoughts including this problem in the Problem Statement docu= ment?

I have also my thoughts on needs for authorization on using th= e external
network. I think in real world, many access providers no not allow
unaut= horized nodes to have access. Getting an address in not that much a
prob= lem, using the access network is.

Regards, Teco



------=_Part_16263_2608773.1203513828623-- --===============2011327691== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Autoconf mailing list Autoconf@ietf.org http://www.ietf.org/mailman/listinfo/autoconf --===============2011327691==-- From autoconf-bounces@ietf.org Wed Feb 20 06:04:16 2008 Return-Path: X-Original-To: ietfarch-autoconf-archive@core3.amsl.com Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7749B28C174; Wed, 20 Feb 2008 06:04:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.465 X-Spam-Level: X-Spam-Status: No, score=-0.465 tagged_above=-999 required=5 tests=[AWL=-0.028, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ok9jd+aWI-i5; Wed, 20 Feb 2008 06:04:12 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C18F28C75E; Wed, 20 Feb 2008 06:04:12 -0800 (PST) X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 37B3A28C7F8 for ; Wed, 20 Feb 2008 06:04:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KCqTEow1Ltwc for ; Wed, 20 Feb 2008 06:04:10 -0800 (PST) Received: from mailf.telecomitalia.it (mailf.telecomitalia.it [156.54.233.32]) by core3.amsl.com (Postfix) with ESMTP id A360F28C11A for ; Wed, 20 Feb 2008 06:04:09 -0800 (PST) thread-index: AchzyXKseEh+0Q8MRaC83CtFJYbD6g== Received: from ptpxch010ba020.idc.cww.telecomitalia.it ([156.54.240.53]) by mailf.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Feb 2008 15:04:02 +0100 Received: from ptpxch006ba020.idc.cww.telecomitalia.it ([156.54.240.45]) by ptpxch010ba020.idc.cww.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Feb 2008 15:04:02 +0100 Received: from [10.229.4.58] ([10.229.4.58]) by ptpxch006ba020.idc.cww.telecomitalia.it over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Feb 2008 15:04:01 +0100 Content-Class: urn:content-classes:message Importance: normal Priority: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2992 Message-ID: <47BC32CE.1010009@telecomitalia.it> Date: Wed, 20 Feb 2008 15:01:50 +0100 From: "Simone Ruffino" User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: "Teco Boot" , References: <47AAC029.8030908@dif.um.es> <47B9A5BF.9060106@inria.fr> <000001c8726b$9d66b440$d8341cc0$@nl> <47BAC6D1.7060100@inria.fr> <001e01c873af$3ab21700$b0164500$@nl> In-Reply-To: <001e01c873af$3ab21700$b0164500$@nl> X-OriginalArrivalTime: 20 Feb 2008 14:04:01.0662 (UTC) FILETIME=[71E6A1E0:01C873C9] Subject: Re: [Autoconf] AUTOCONF Problem Statement: reviews needed. X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Hi Teco, some comments below. Thanks for your comments and regs, Simone Teco Boot wrote: > Hi, > = > Some comments inline. > = > I have more thoughts which I did not mention in my first response: > = > On uniqueness validation, I posted before my reservations on active DAD. = In > many cases, this is not needed. RFC4862: >> To accommodate >> sites that believe the overhead of performing Duplicate Address >> Detection outweighs its benefits, the use of Duplicate Address >> Detection can be disabled through the administrative setting of a >> per-interface configuration flag. > The old version of our Problem Statement had some text on this. > = > On multi-homed subordinate MANETs, the current document does not describe > this scenario in detail. It is just an instance of a subordinate MANET, as > this category is described with "is connected to at least one external > network N". > I think multi-homed subordinate MANET scenario introduces a large, new > problem which is related to the selection mechanism of the path to one of > the external networks. This path selection is out-of-control for Autoconf, > as it is up to the (MANET) routing protocol to find out the path to the > destination. > Scenario: > = > = > '. / > `. Network N / Topologically correct > `. _,' prefix q:: with > Topologically correct `-.__ _,,' respect to network M > prefix p:: with `'-.,._,,'' ___ > respect to network N : ,-=B4 > +-:-+ / = > |MNR| ; N > +-|-+ / E > +-+ +---+ / /|\ \ +---+ ; T = > | |...MNR--- .-. ---MNR:....., W > +-+ +---+ \ ,-( _)-. / +---+ ! O > .-(_ MANET )-. ! R > Other ( Communication ) : K > Nodes `-(______)-' \ = > and \|/ \|/ : M > Networks +-|-+ +-|-+ \ = > |MNR| \|/ |MNR| \_____ = > +-:-+ +-|-+ +-:-+ = > |MNR| : > +-:-+ +-+ > +-+ > = > Now, we have to select a topologically correct prefix p:: with respect to > network N but not to network M or a topologically correct prefix q:: with > respect to network M but not to network N. It is very hard to select p:: = or > q::, as it is dependent on the (dynamic) topology of the MANET and the MA= NET > routing protocol. = Great that you raised this point, because I've always stressed this is a = a problem :). I agree: the selection of prefix (and addresses) to use for application = sessions with external hosts is hard, because it directly impacts on the = path followed by return traffic *from* the external network *to* MNRs = *in* the MANET. Routing protocols can only affect the other direction, = i.e. from the MNR to the external network. However, let me elaborate more on this. I think selection of either p:: or q:: is not really a problem per-se. = In fact, MNRs (and connected hosts) could configure both p:: and q:: on = their interfaces: IPv6 permits it. And hosts connected to MNRs could = initiate application sessions with hosts in both networks M and N: = source address selection rules will choose the prefix with the right scope. Moreover, if both Network M and N are eventually connected to the = Internet and if hosts (attached to MNRs) want to initiate application = sessions with hosts on the Internet, p:: and q:: could be equivalent. But in this case, the choice of prefix could depend on other factors, = e.g. performance. In fact, it is actually more important to choose the = optimal Border MNR, in order to prevent return traffic to traverse long = paths in the MANET. Choosing a very far away border router (in terms of = number of hops, w.r.t. the MNR initiating the session) has a direct = impact on applications, especially jitter-sensitive ones like VoIP. So in my opinion there is a 1:1 correspondence between performance and = prefix choice. By my knowledge, the MANET protocols we have right now are > using the destination IP address for forwarding and not the source IP > address. > Any thoughts including this problem in the Problem Statement document? > = I think it could be useful to add some considerations, but, we decided = to keep this version of PS "to-the-bone" as much as possible and get = agreement on this. I'd like to hear opinion of other authors as well. > I have also my thoughts on needs for authorization on using the external > network. I think in real world, many access providers no not allow > unauthorized nodes to have access. Getting an address in not that much a > problem, using the access network is. = > = > Regards, Teco > = -------------------------------------------------------------------- CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above = and may contain confidential information. If you have received the message = in error, be informed that any use of the content hereof is prohibited. Ple= ase return it immediately to the sender and delete the message. Should you = have any questions, please contact us by replying to webmaster@telecomitali= a.it. Thank you www.telecomitalia.it -------------------------------------------------------------------- = _______________________________________________ Autoconf mailing list Autoconf@ietf.org http://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Wed Feb 20 07:22:48 2008 Return-Path: X-Original-To: ietfarch-autoconf-archive@core3.amsl.com Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 09FAB28C1E5; Wed, 20 Feb 2008 07:22:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.984 X-Spam-Level: X-Spam-Status: No, score=-0.984 tagged_above=-999 required=5 tests=[AWL=-0.547, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z3jSKIkKO8HP; Wed, 20 Feb 2008 07:22:46 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD4F828C163; Wed, 20 Feb 2008 07:22:46 -0800 (PST) X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A121D3A69CB for ; Wed, 20 Feb 2008 07:22:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DxZXgEblJ4vK for ; Wed, 20 Feb 2008 07:22:44 -0800 (PST) Received: from hpsmtp-eml13.kpnxchange.com (hpsmtp-eml13.KPNXCHANGE.COM [213.75.38.113]) by core3.amsl.com (Postfix) with ESMTP id C491428C7A2 for ; Wed, 20 Feb 2008 07:22:28 -0800 (PST) Received: from hpsmtp-eml09.kpnxchange.com ([213.75.38.109]) by hpsmtp-eml13.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Feb 2008 16:22:24 +0100 Received: from M90Teco ([86.83.9.22]) by hpsmtp-eml09.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Feb 2008 16:22:20 +0100 From: "Teco Boot" To: "'Simone Ruffino'" References: <47AAC029.8030908@dif.um.es> <47B9A5BF.9060106@inria.fr> <000001c8726b$9d66b440$d8341cc0$@nl> <47BAC6D1.7060100@inria.fr> <001e01c873af$3ab21700$b0164500$@nl> <47BC32CE.1010009@telecomitalia.it> In-Reply-To: <47BC32CE.1010009@telecomitalia.it> Date: Wed, 20 Feb 2008 16:22:10 +0100 Message-ID: <000001c873d4$5d7b1eb0$18715c10$@nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 thread-index: AchzyXKseEh+0Q8MRaC83CtFJYbD6gACOEZA Content-Language: nl X-OriginalArrivalTime: 20 Feb 2008 15:22:20.0547 (UTC) FILETIME=[62A79530:01C873D4] Cc: autoconf@ietf.org Subject: Re: [Autoconf] AUTOCONF Problem Statement: reviews needed. X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Hi Simone, I think it is not only a performance issue. Ingress filtering will simply block incoming traffic with non-conforming source addresses. On Problem Statement "to the bone", I agree. But I think that the dual homed MANET is a very important real world scenario. = And another issue on this, when using both p:: and q:: on the local "classical IP" interface for assignment of addresses to directly connected hosts, these hosts are not aware on what is happening on the MANET. So address maintenance for these nodes, solving the ingress filtering issue and optimizing performance, is not that easy. Ignoring this problem is not my preferred option. In the contrary, I think it is a very important goal. = Regards, Teco NB. In the diagram, network N and M are connected to the Internet. We are in Internet Area, so this is implicit but I forgot to mention. > -----Oorspronkelijk bericht----- > Van: Simone Ruffino [mailto:simone.ruffino@telecomitalia.it] > Verzonden: woensdag 20 februari 2008 15:02 > Aan: Teco Boot; autoconf@ietf.org > Onderwerp: Re: [Autoconf] AUTOCONF Problem Statement: reviews > needed. > = > Hi Teco, > some comments below. > = > Thanks for your comments and regs, > Simone > = > Teco Boot wrote: > > Hi, > > > > Some comments inline. > > > > I have more thoughts which I did not mention in my first response: > > > > On uniqueness validation, I posted before my reservations on active > DAD. In > > many cases, this is not needed. RFC4862: > >> To accommodate > >> sites that believe the overhead of performing Duplicate Address > >> Detection outweighs its benefits, the use of Duplicate Address > >> Detection can be disabled through the administrative setting of a > >> per-interface configuration flag. > > The old version of our Problem Statement had some text on this. > > > > On multi-homed subordinate MANETs, the current document does not > describe > > this scenario in detail. It is just an instance of a subordinate > MANET, as > > this category is described with "is connected to at least one > external > > network N". > > I think multi-homed subordinate MANET scenario introduces a large, > new > > problem which is related to the selection mechanism of the path to > one of > > the external networks. This path selection is out-of-control for > Autoconf, > > as it is up to the (MANET) routing protocol to find out the path to > the > > destination. > > Scenario: > > > > > > '. / > > `. Network N / Topologically > correct > > `. _,' prefix q:: > with > > Topologically correct `-.__ _,,' respect to > network M > > prefix p:: with `'-.,._,,'' ___ > > respect to network N : ,-=B4 > > +-:-+ / > > |MNR| ; N > > +-|-+ / E > > +-+ +---+ / /|\ \ +---+ ; T > > | |...MNR--- .-. ---MNR:....., W > > +-+ +---+ \ ,-( _)-. / +---+ ! O > > .-(_ MANET )-. ! R > > Other ( Communication ) : K > > Nodes `-(______)-' \ > > and \|/ \|/ : M > > Networks +-|-+ +-|-+ \ > > |MNR| \|/ |MNR| \_____ > > +-:-+ +-|-+ +-:-+ > > |MNR| : > > +-:-+ +-+ > > +-+ > > > > Now, we have to select a topologically correct prefix p:: with > respect to > > network N but not to network M or a topologically correct prefix q:: > with > > respect to network M but not to network N. It is very hard to select > p:: or > > q::, as it is dependent on the (dynamic) topology of the MANET and > the MANET > > routing protocol. > = > Great that you raised this point, because I've always stressed this is > a > a problem :). > = > I agree: the selection of prefix (and addresses) to use for application > sessions with external hosts is hard, because it directly impacts on > the > path followed by return traffic *from* the external network *to* MNRs > *in* the MANET. Routing protocols can only affect the other direction, > i.e. from the MNR to the external network. > = > However, let me elaborate more on this. > I think selection of either p:: or q:: is not really a problem per-se. > In fact, MNRs (and connected hosts) could configure both p:: and q:: on > their interfaces: IPv6 permits it. And hosts connected to MNRs could > initiate application sessions with hosts in both networks M and N: > source address selection rules will choose the prefix with the right > scope. > = > Moreover, if both Network M and N are eventually connected to the > Internet and if hosts (attached to MNRs) want to initiate application > sessions with hosts on the Internet, p:: and q:: could be equivalent. > = > But in this case, the choice of prefix could depend on other factors, > e.g. performance. In fact, it is actually more important to choose the > optimal Border MNR, in order to prevent return traffic to traverse long > paths in the MANET. Choosing a very far away border router (in terms of > number of hops, w.r.t. the MNR initiating the session) has a direct > impact on applications, especially jitter-sensitive ones like VoIP. > = > So in my opinion there is a 1:1 correspondence between performance and > prefix choice. > = > = > By my knowledge, the MANET protocols we have right now are > > using the destination IP address for forwarding and not the source IP > > address. > > Any thoughts including this problem in the Problem Statement > document? > > > = > I think it could be useful to add some considerations, but, we decided > to keep this version of PS "to-the-bone" as much as possible and get > agreement on this. I'd like to hear opinion of other authors as well. > = > > I have also my thoughts on needs for authorization on using the > external > > network. I think in real world, many access providers no not allow > > unauthorized nodes to have access. Getting an address in not that > much a > > problem, using the access network is. > > > > Regards, Teco > > > -------------------------------------------------------------------- > = > CONFIDENTIALITY NOTICE > = > This message and its attachments are addressed solely to the persons > above and may contain confidential information. If you have received > the message in error, be informed that any use of the content hereof is > prohibited. Please return it immediately to the sender and delete the > message. Should you have any questions, please contact us by replying > to webmaster@telecomitalia.it. > = > Thank you > = > www.telecomitalia.it > = > -------------------------------------------------------------------- > = _______________________________________________ Autoconf mailing list Autoconf@ietf.org http://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Wed Feb 20 07:54:05 2008 Return-Path: X-Original-To: ietfarch-autoconf-archive@core3.amsl.com Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC0043A6D4C; Wed, 20 Feb 2008 07:54:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.307 X-Spam-Level: X-Spam-Status: No, score=-0.307 tagged_above=-999 required=5 tests=[AWL=-0.770, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_21=0.6, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BJyU4XJAHG05; Wed, 20 Feb 2008 07:54:04 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 80EA43A6965; Wed, 20 Feb 2008 07:54:04 -0800 (PST) X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8268E3A6965 for ; Wed, 20 Feb 2008 07:54:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7XPJVf4c8GUp for ; Wed, 20 Feb 2008 07:54:01 -0800 (PST) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 9AE0B3A6768 for ; Wed, 20 Feb 2008 07:54:00 -0800 (PST) Received: from [163.117.139.72] (acorde.it.uc3m.es [163.117.139.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp01.uc3m.es (Postfix) with ESMTP id C48513E5A31; Wed, 20 Feb 2008 16:53:55 +0100 (CET) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Simone Ruffino In-Reply-To: <47BC32CE.1010009@telecomitalia.it> References: <47AAC029.8030908@dif.um.es> <47B9A5BF.9060106@inria.fr> <000001 c8726b$9d66b440$d8341cc0$@nl> <47BAC6D1.7060100@inria.fr> <001e01c873af$3ab21700$b0164500$@nl> <47BC32CE.1010009@telecomitalia.it> Organization: Universidad Carlos III de Madrid Date: Wed, 20 Feb 2008 16:53:57 +0100 Message-Id: <1203522837.4276.74.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 Cc: autoconf@ietf.org Subject: Re: [Autoconf] AUTOCONF Problem Statement: reviews needed. X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1095882599==" Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org --===============1095882599== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-L+DhAliIisn5NH6oJovT" --=-L+DhAliIisn5NH6oJovT Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Somone, all. Two short comments below. On mi=E9, 2008-02-20 at 15:01 +0100, Simone Ruffino wrote: > Hi Teco, > some comments below. >=20 > Thanks for your comments and regs, > Simone >=20 > Teco Boot wrote: > > Hi, > >=20 > > Some comments inline. > >=20 > > I have more thoughts which I did not mention in my first response: > >=20 > > On uniqueness validation, I posted before my reservations on active > DAD. In > > many cases, this is not needed. RFC4862: > >> To accommodate > >> sites that believe the overhead of performing Duplicate Address > >> Detection outweighs its benefits, the use of Duplicate Address > >> Detection can be disabled through the administrative setting of a > >> per-interface configuration flag. > > The old version of our Problem Statement had some text on this. > >=20 > > On multi-homed subordinate MANETs, the current document does not > describe > > this scenario in detail. It is just an instance of a subordinate > MANET, as > > this category is described with "is connected to at least one > external > > network N". > > I think multi-homed subordinate MANET scenario introduces a large, > new > > problem which is related to the selection mechanism of the path to > one of > > the external networks. This path selection is out-of-control for > Autoconf, > > as it is up to the (MANET) routing protocol to find out the path to > the > > destination. > > Scenario: > >=20 > >=20 > > '. / > > `. Network N / Topologically > correct > > `. _,' prefix q:: > with > > Topologically correct `-.__ _,,' respect to > network M > > prefix p:: with `'-.,._,,'' ___ > > respect to network N : ,-=B4 > > +-:-+ / =20 > > |MNR| ; N > > +-|-+ / E > > +-+ +---+ / /|\ \ +---+ ; T=20 > > | |...MNR--- .-. ---MNR:....., W > > +-+ +---+ \ ,-( _)-. / +---+ ! O > > .-(_ MANET )-. ! R > > Other ( Communication ) : K > > Nodes `-(______)-' \ =20 > > and \|/ \|/ : M > > Networks +-|-+ +-|-+ \=20 > > |MNR| \|/ |MNR| \_____ =20 > > +-:-+ +-|-+ +-:-+ =20 > > |MNR| : > > +-:-+ +-+ > > +-+ > >=20 > > Now, we have to select a topologically correct prefix p:: with > respect to > > network N but not to network M or a topologically correct prefix q:: > with > > respect to network M but not to network N. It is very hard to select > p:: or > > q::, as it is dependent on the (dynamic) topology of the MANET and > the MANET > > routing protocol.=20 >=20 > Great that you raised this point, because I've always stressed this is > a=20 > a problem :). >=20 > I agree: the selection of prefix (and addresses) to use for > application=20 > sessions with external hosts is hard, because it directly impacts on > the=20 > path followed by return traffic *from* the external network *to* MNRs=20 > *in* the MANET. Routing protocols can only affect the other > direction,=20 > i.e. from the MNR to the external network. >=20 > However, let me elaborate more on this. > I think selection of either p:: or q:: is not really a problem > per-se.=20 > In fact, MNRs (and connected hosts) could configure both p:: and q:: > on=20 > their interfaces: IPv6 permits it. And hosts connected to MNRs could=20 > initiate application sessions with hosts in both networks M and N:=20 > source address selection rules will choose the prefix with the right > scope. >=20 > Moreover, if both Network M and N are eventually connected to the=20 > Internet and if hosts (attached to MNRs) want to initiate application=20 > sessions with hosts on the Internet, p:: and q:: could be equivalent. >=20 > But in this case, the choice of prefix could depend on other factors,=20 > e.g. performance. In fact, it is actually more important to choose > the=20 > optimal Border MNR, in order to prevent return traffic to traverse > long=20 > paths in the MANET. Choosing a very far away border router (in terms > of=20 > number of hops, w.r.t. the MNR initiating the session) has a direct=20 > impact on applications, especially jitter-sensitive ones like VoIP. >=20 > So in my opinion there is a 1:1 correspondence between performance > and=20 > prefix choice. [Carlos] I think this problem/scenario also happens in non-MANET scenarios (it's a multihoming issue) and it is not particular of IP address autoconfiguration. I agree is a very interesting issue, but I'm not sure the IP autoconf PS is the right place. The only specific issue I see there is how to detect that an initially multihomed subordinate MANET gets disconnected from one of the external networks it was attached to, and even in this case, this also occurs in non-MANETs. > By my knowledge, the MANET protocols we have right now are > > using the destination IP address for forwarding and not the source > IP > > address. > > Any thoughts including this problem in the Problem Statement > document? > >=20 >=20 > I think it could be useful to add some considerations, but, we > decided=20 > to keep this version of PS "to-the-bone" as much as possible and get=20 > agreement on this. I'd like to hear opinion of other authors as well. [Carlos] Again, I don't see this as an IP address autoconfiguration issue. This is related to MANET routing protocols, and therefore I'd prefer not to include any consideration in the PS. Regards, Carlos >=20 > > I have also my thoughts on needs for authorization on using the > external > > network. I think in real world, many access providers no not allow > > unauthorized nodes to have access. Getting an address in not that > much a > > problem, using the access network is.=20 > >=20 > > Regards, Teco > >=20 > -------------------------------------------------------------------- >=20 > CONFIDENTIALITY NOTICE >=20 > This message and its attachments are addressed solely to the persons > above and may contain confidential information. If you have received > the message in error, be informed that any use of the content hereof > is prohibited. Please return it immediately to the sender and delete > the message. Should you have any questions, please contact us by > replying to webmaster@telecomitalia.it. >=20 > Thank you >=20 > www.telecomitalia.it >=20 > -------------------------------------------------------------------- > =20 > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > http://www.ietf.org/mailman/listinfo/autoconf --=20 =A1AS=D3CIATE! Gratis para estudiantes http://www.telematica.ws Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ WEEDEV 2008: 1st Workshop on Experimental Evaluation and Deployment Experiences on Vehicular networks http://www.weedev.org/ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ --=-L+DhAliIisn5NH6oJovT Content-Type: application/pgp-signature; name=signature.asc Content-Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBHvE0VNdy6TdFwT2cRAuivAJ9he1Nc6ABxSxR+OEYyJ7iTUzPhOgCgsT3q 5UUyGBOrHoIKocTUK+6AxN0= =lhg+ -----END PGP SIGNATURE----- --=-L+DhAliIisn5NH6oJovT-- --===============1095882599== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Autoconf mailing list Autoconf@ietf.org http://www.ietf.org/mailman/listinfo/autoconf --===============1095882599==-- From autoconf-bounces@ietf.org Wed Feb 20 08:04:29 2008 Return-Path: X-Original-To: ietfarch-autoconf-archive@core3.amsl.com Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E30D728C76F; Wed, 20 Feb 2008 08:04:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.477 X-Spam-Level: X-Spam-Status: No, score=-0.477 tagged_above=-999 required=5 tests=[AWL=-0.040, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZHbRVPObdU3Y; Wed, 20 Feb 2008 08:04:28 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B133A3A6950; Wed, 20 Feb 2008 08:04:28 -0800 (PST) X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A240B3A6A5D for ; Wed, 20 Feb 2008 08:04:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0virsup+eBbH for ; Wed, 20 Feb 2008 08:04:25 -0800 (PST) Received: from maild.telecomitalia.it (maild.telecomitalia.it [156.54.233.30]) by core3.amsl.com (Postfix) with ESMTP id 110D93A68F3 for ; Wed, 20 Feb 2008 08:04:24 -0800 (PST) thread-index: Achz2kDL7l5UALlWSXar6Kz1yQ90IA== Received: from ptpxch009ba020.idc.cww.telecomitalia.it ([156.54.240.52]) by maild.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Feb 2008 17:04:20 +0100 Received: from ptpxch006ba020.idc.cww.telecomitalia.it ([156.54.240.45]) by ptpxch009ba020.idc.cww.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Feb 2008 17:04:20 +0100 Received: from [10.229.4.58] ([10.229.4.58]) by ptpxch006ba020.idc.cww.telecomitalia.it over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Feb 2008 17:04:19 +0100 Content-Class: urn:content-classes:message Importance: normal Priority: normal x-mimeole: Produced By Microsoft MimeOLE V6.00.3790.2992 Message-ID: <47BC4F00.4040900@telecomitalia.it> Date: Wed, 20 Feb 2008 17:02:08 +0100 From: "Simone Ruffino" User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: "Teco Boot" References: <47AAC029.8030908@dif.um.es> <47B9A5BF.9060106@inria.fr> <000001c8726b$9d66b440$d8341cc0$@nl> <47BAC6D1.7060100@inria.fr> <001e01c873af$3ab21700$b0164500$@nl> <47BC32CE.1010009@telecomitalia.it> <000001c873d4$5d7b1eb0$18715c10$@nl> In-Reply-To: <000001c873d4$5d7b1eb0$18715c10$@nl> X-OriginalArrivalTime: 20 Feb 2008 16:04:19.0320 (UTC) FILETIME=[3FF5D780:01C873DA] Cc: autoconf@ietf.org Subject: Re: [Autoconf] AUTOCONF Problem Statement: reviews needed. X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Teco, Teco Boot wrote: > Hi Simone, > I think it is not only a performance issue. Ingress filtering will simply > block incoming traffic with non-conforming source addresses. Yes, I didn't mention it in my mail to avoid putting too many problems = on the table but I strongly agree it is a problem in some deployments. > On Problem Statement "to the bone", I agree. But I think that the dual ho= med > MANET is a very important real world scenario. = Agree. Maybe more explanatory text could be needed and, BTW, your = picture is good :) ! But, if we want to include in the PS the topics we covered in our late = mail exchange, the question is, as always: what is the problem? And, = after we come up with a clear definition of the problem: is it something = we cannot solve with standard existing solutions? > And another issue on this, when using both p:: and q:: on the local > "classical IP" interface for assignment of addresses to directly connected > hosts, these hosts are not aware on what is happening on the MANET. So > address maintenance for these nodes, solving the ingress filtering issue = and > optimizing performance, is not that easy. Ignoring this problem is not my > preferred option. In the contrary, I think it is a very important goal. = I agree, also because I don't think it is an unsolvable/impossible = problem. For example, going into solution space, interaction with = routing protocol can help. > Regards, Teco > = > NB. > In the diagram, network N and M are connected to the Internet. We are in > Internet Area, so this is implicit but I forgot to mention. > = >> -----Oorspronkelijk bericht----- >> Van: Simone Ruffino [mailto:simone.ruffino@telecomitalia.it] >> Verzonden: woensdag 20 februari 2008 15:02 >> Aan: Teco Boot; autoconf@ietf.org >> Onderwerp: Re: [Autoconf] AUTOCONF Problem Statement: reviews >> needed. >> >> Hi Teco, >> some comments below. >> >> Thanks for your comments and regs, >> Simone >> >> Teco Boot wrote: >>> Hi, >>> >>> Some comments inline. >>> >>> I have more thoughts which I did not mention in my first response: >>> >>> On uniqueness validation, I posted before my reservations on active >> DAD. In >>> many cases, this is not needed. RFC4862: >>>> To accommodate >>>> sites that believe the overhead of performing Duplicate Address >>>> Detection outweighs its benefits, the use of Duplicate Address >>>> Detection can be disabled through the administrative setting of a >>>> per-interface configuration flag. >>> The old version of our Problem Statement had some text on this. >>> >>> On multi-homed subordinate MANETs, the current document does not >> describe >>> this scenario in detail. It is just an instance of a subordinate >> MANET, as >>> this category is described with "is connected to at least one >> external >>> network N". >>> I think multi-homed subordinate MANET scenario introduces a large, >> new >>> problem which is related to the selection mechanism of the path to >> one of >>> the external networks. This path selection is out-of-control for >> Autoconf, >>> as it is up to the (MANET) routing protocol to find out the path to >> the >>> destination. >>> Scenario: >>> >>> >>> '. / >>> `. Network N / Topologically >> correct >>> `. _,' prefix q:: >> with >>> Topologically correct `-.__ _,,' respect to >> network M >>> prefix p:: with `'-.,._,,'' ___ >>> respect to network N : ,-=B4 >>> +-:-+ / >>> |MNR| ; N >>> +-|-+ / E >>> +-+ +---+ / /|\ \ +---+ ; T >>> | |...MNR--- .-. ---MNR:....., W >>> +-+ +---+ \ ,-( _)-. / +---+ ! O >>> .-(_ MANET )-. ! R >>> Other ( Communication ) : K >>> Nodes `-(______)-' \ >>> and \|/ \|/ : M >>> Networks +-|-+ +-|-+ \ >>> |MNR| \|/ |MNR| \_____ >>> +-:-+ +-|-+ +-:-+ >>> |MNR| : >>> +-:-+ +-+ >>> +-+ >>> >>> Now, we have to select a topologically correct prefix p:: with >> respect to >>> network N but not to network M or a topologically correct prefix q:: >> with >>> respect to network M but not to network N. It is very hard to select >> p:: or >>> q::, as it is dependent on the (dynamic) topology of the MANET and >> the MANET >>> routing protocol. >> Great that you raised this point, because I've always stressed this is >> a >> a problem :). >> >> I agree: the selection of prefix (and addresses) to use for application >> sessions with external hosts is hard, because it directly impacts on >> the >> path followed by return traffic *from* the external network *to* MNRs >> *in* the MANET. Routing protocols can only affect the other direction, >> i.e. from the MNR to the external network. >> >> However, let me elaborate more on this. >> I think selection of either p:: or q:: is not really a problem per-se. >> In fact, MNRs (and connected hosts) could configure both p:: and q:: on >> their interfaces: IPv6 permits it. And hosts connected to MNRs could >> initiate application sessions with hosts in both networks M and N: >> source address selection rules will choose the prefix with the right >> scope. >> >> Moreover, if both Network M and N are eventually connected to the >> Internet and if hosts (attached to MNRs) want to initiate application >> sessions with hosts on the Internet, p:: and q:: could be equivalent. >> >> But in this case, the choice of prefix could depend on other factors, >> e.g. performance. In fact, it is actually more important to choose the >> optimal Border MNR, in order to prevent return traffic to traverse long >> paths in the MANET. Choosing a very far away border router (in terms of >> number of hops, w.r.t. the MNR initiating the session) has a direct >> impact on applications, especially jitter-sensitive ones like VoIP. >> >> So in my opinion there is a 1:1 correspondence between performance and >> prefix choice. >> >> >> By my knowledge, the MANET protocols we have right now are >>> using the destination IP address for forwarding and not the source IP >>> address. >>> Any thoughts including this problem in the Problem Statement >> document? >> I think it could be useful to add some considerations, but, we decided >> to keep this version of PS "to-the-bone" as much as possible and get >> agreement on this. I'd like to hear opinion of other authors as well. >> >>> I have also my thoughts on needs for authorization on using the >> external >>> network. I think in real world, many access providers no not allow >>> unauthorized nodes to have access. Getting an address in not that >> much a >>> problem, using the access network is. >>> >>> Regards, Teco >>> >> -------------------------------------------------------------------- >> >> CONFIDENTIALITY NOTICE >> >> This message and its attachments are addressed solely to the persons >> above and may contain confidential information. If you have received >> the message in error, be informed that any use of the content hereof is >> prohibited. Please return it immediately to the sender and delete the >> message. Should you have any questions, please contact us by replying >> to webmaster@telecomitalia.it. >> >> Thank you >> >> www.telecomitalia.it >> >> -------------------------------------------------------------------- >> > = -------------------------------------------------------------------- CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above = and may contain confidential information. If you have received the message = in error, be informed that any use of the content hereof is prohibited. Ple= ase return it immediately to the sender and delete the message. Should you = have any questions, please contact us by replying to webmaster@telecomitali= a.it. Thank you www.telecomitalia.it -------------------------------------------------------------------- = _______________________________________________ Autoconf mailing list Autoconf@ietf.org http://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Wed Feb 20 08:19:18 2008 Return-Path: X-Original-To: ietfarch-autoconf-archive@core3.amsl.com Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE70E28C7F6; Wed, 20 Feb 2008 08:19:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.55 X-Spam-Level: X-Spam-Status: No, score=-0.55 tagged_above=-999 required=5 tests=[AWL=-0.713, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_21=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hj5P3sexUhhi; Wed, 20 Feb 2008 08:19:17 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9216128C7FF; Wed, 20 Feb 2008 08:19:17 -0800 (PST) X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2537F28C286 for ; Wed, 20 Feb 2008 08:19:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id suBSVr4UlY2r for ; Wed, 20 Feb 2008 08:19:14 -0800 (PST) Received: from hpsmtp-eml15.kpnxchange.com (hpsmtp-eml15.KPNXCHANGE.COM [213.75.38.115]) by core3.amsl.com (Postfix) with ESMTP id 63AFF28C7F6 for ; Wed, 20 Feb 2008 08:19:13 -0800 (PST) Received: from hpsmtp-eml07.kpnxchange.com ([213.75.38.107]) by hpsmtp-eml15.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Feb 2008 17:19:10 +0100 Received: from M90Teco ([86.83.9.22]) by hpsmtp-eml07.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Feb 2008 17:19:07 +0100 From: "Teco Boot" To: References: <47AAC029.8030908@dif.um.es> <47B9A5BF.9060106@inria.fr> <000001 c8726b$9d66b440$d8341cc0$@nl> <47BAC6D1.7060100@inria.fr> <001e01c873af$3ab21700$b0164500$@nl> <47BC32CE.1010009@telecomitalia.it> <1203522837.4276.74.camel@localhost> In-Reply-To: <1203522837.4276.74.camel@localhost> Date: Wed, 20 Feb 2008 17:18:58 +0100 Message-ID: <001401c873dc$4c34fec0$e49efc40$@nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 thread-index: Achz2NOVPPG9LeyHQbS31U0R/hsZkgAAezSg Content-Language: nl X-OriginalArrivalTime: 20 Feb 2008 16:19:07.0323 (UTC) FILETIME=[514058B0:01C873DC] Cc: autoconf@ietf.org Subject: Re: [Autoconf] AUTOCONF Problem Statement: reviews needed. X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Hi Carlos, Maybe it is true that is some "unmanaged and open" wired networks, the multi-homing issue can arise. But I think the hosts can deal with this issue, by selecting a default gateway. And yes, there is a relation between the selected gateway and the generated SLAAC address. I think that in a open, wireless network where we introduce a MANET protocol, the problem is out-of-control. The MANET Router connected hosts do not have any idea of the MANET topology and I do not see a method that these nodes can select a source address, other than try and error. The MANET Router itself could perform an internal MANET topology table lookup and try to detect the egress to the Internet, and use corresponding source address. I think this method does not work in all cases, e.g. session continuity during movement is a problem. Any other opinions? Teco. > -----Oorspronkelijk bericht----- > Van: Carlos Jes=FAs Bernardos Cano [mailto:cjbc@it.uc3m.es] > Verzonden: woensdag 20 februari 2008 16:54 > Aan: Simone Ruffino > CC: Teco Boot; autoconf@ietf.org > Onderwerp: Re: [Autoconf] AUTOCONF Problem Statement: reviews needed. > = > Hi Somone, all. > = > Two short comments below. > = > On mi=E9, 2008-02-20 at 15:01 +0100, Simone Ruffino wrote: > > Hi Teco, > > some comments below. > > > > Thanks for your comments and regs, > > Simone > > > > Teco Boot wrote: > > > Hi, > > > > > > Some comments inline. > > > > > > I have more thoughts which I did not mention in my first response: > > > > > > On uniqueness validation, I posted before my reservations on active > > DAD. In > > > many cases, this is not needed. RFC4862: > > >> To accommodate > > >> sites that believe the overhead of performing Duplicate Address > > >> Detection outweighs its benefits, the use of Duplicate Address > > >> Detection can be disabled through the administrative setting of a > > >> per-interface configuration flag. > > > The old version of our Problem Statement had some text on this. > > > > > > On multi-homed subordinate MANETs, the current document does not > > describe > > > this scenario in detail. It is just an instance of a subordinate > > MANET, as > > > this category is described with "is connected to at least one > > external > > > network N". > > > I think multi-homed subordinate MANET scenario introduces a large, > > new > > > problem which is related to the selection mechanism of the path to > > one of > > > the external networks. This path selection is out-of-control for > > Autoconf, > > > as it is up to the (MANET) routing protocol to find out the path to > > the > > > destination. > > > Scenario: > > > > > > > > > '. / > > > `. Network N / Topologically > > correct > > > `. _,' prefix q:: > > with > > > Topologically correct `-.__ _,,' respect to > > network M > > > prefix p:: with `'-.,._,,'' ___ > > > respect to network N : ,-=B4 > > > +-:-+ / > > > |MNR| ; N > > > +-|-+ / E > > > +-+ +---+ / /|\ \ +---+ ; T > > > | |...MNR--- .-. ---MNR:....., W > > > +-+ +---+ \ ,-( _)-. / +---+ ! O > > > .-(_ MANET )-. ! R > > > Other ( Communication ) : K > > > Nodes `-(______)-' \ > > > and \|/ \|/ : M > > > Networks +-|-+ +-|-+ \ > > > |MNR| \|/ |MNR| \_____ > > > +-:-+ +-|-+ +-:-+ > > > |MNR| : > > > +-:-+ +-+ > > > +-+ > > > > > > Now, we have to select a topologically correct prefix p:: with > > respect to > > > network N but not to network M or a topologically correct prefix > q:: > > with > > > respect to network M but not to network N. It is very hard to > select > > p:: or > > > q::, as it is dependent on the (dynamic) topology of the MANET and > > the MANET > > > routing protocol. > > > > Great that you raised this point, because I've always stressed this > is > > a a problem :). > > > > I agree: the selection of prefix (and addresses) to use for > > application sessions with external hosts is hard, because it directly > > impacts on the path followed by return traffic *from* the external > > network *to* MNRs > > *in* the MANET. Routing protocols can only affect the other > direction, > > i.e. from the MNR to the external network. > > > > However, let me elaborate more on this. > > I think selection of either p:: or q:: is not really a problem per- > se. > > In fact, MNRs (and connected hosts) could configure both p:: and q:: > > on > > their interfaces: IPv6 permits it. And hosts connected to MNRs could > > initiate application sessions with hosts in both networks M and N: > > source address selection rules will choose the prefix with the right > > scope. > > > > Moreover, if both Network M and N are eventually connected to the > > Internet and if hosts (attached to MNRs) want to initiate application > > sessions with hosts on the Internet, p:: and q:: could be equivalent. > > > > But in this case, the choice of prefix could depend on other factors, > > e.g. performance. In fact, it is actually more important to choose > the > > optimal Border MNR, in order to prevent return traffic to traverse > > long paths in the MANET. Choosing a very far away border router (in > > terms of number of hops, w.r.t. the MNR initiating the session) has a > > direct impact on applications, especially jitter-sensitive ones like > > VoIP. > > > > So in my opinion there is a 1:1 correspondence between performance > and > > prefix choice. > = > [Carlos] I think this problem/scenario also happens in non-MANET > scenarios (it's a multihoming issue) and it is not particular of IP > address autoconfiguration. I agree is a very interesting issue, but I'm > not sure the IP autoconf PS is the right place. The only specific issue > I see there is how to detect that an initially multihomed subordinate > MANET gets disconnected from one of the external networks it was > attached to, and even in this case, this also occurs in non-MANETs. > = > > By my knowledge, the MANET protocols we have right now are > > > using the destination IP address for forwarding and not the source > > IP > > > address. > > > Any thoughts including this problem in the Problem Statement > > document? > > > > > > > I think it could be useful to add some considerations, but, we > decided > > to keep this version of PS "to-the-bone" as much as possible and get > > agreement on this. I'd like to hear opinion of other authors as well. > = > [Carlos] Again, I don't see this as an IP address autoconfiguration > issue. This is related to MANET routing protocols, and therefore I'd > prefer not to include any consideration in the PS. > = > Regards, > = > Carlos > > > > > I have also my thoughts on needs for authorization on using the > > external > > > network. I think in real world, many access providers no not allow > > > unauthorized nodes to have access. Getting an address in not that > > much a > > > problem, using the access network is. > > > > > > Regards, Teco > > > > > -------------------------------------------------------------------- > > > > CONFIDENTIALITY NOTICE > > > > This message and its attachments are addressed solely to the persons > > above and may contain confidential information. If you have received > > the message in error, be informed that any use of the content hereof > > is prohibited. Please return it immediately to the sender and delete > > the message. Should you have any questions, please contact us by > > replying to webmaster@telecomitalia.it. > > > > Thank you > > > > www.telecomitalia.it > > > > -------------------------------------------------------------------- > > > > _______________________________________________ > > Autoconf mailing list > > Autoconf@ietf.org > > http://www.ietf.org/mailman/listinfo/autoconf > -- > =A1AS=D3CIATE! Gratis para estudiantes http://www.telematica.ws > Carlos Jes=FAs Bernardos Cano http://www.netcoms.net > GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > WEEDEV 2008: 1st Workshop on Experimental Evaluation and > Deployment Experiences on Vehicular networks > http://www.weedev.org/ > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ _______________________________________________ Autoconf mailing list Autoconf@ietf.org http://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Wed Feb 20 08:29:10 2008 Return-Path: X-Original-To: ietfarch-autoconf-archive@core3.amsl.com Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA32328C776; Wed, 20 Feb 2008 08:29:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.127 X-Spam-Level: X-Spam-Status: No, score=-0.127 tagged_above=-999 required=5 tests=[AWL=-0.290, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_21=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fCytZGUOPTJI; Wed, 20 Feb 2008 08:29:09 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6FF2328C1B4; Wed, 20 Feb 2008 08:29:09 -0800 (PST) X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1678628C1B4 for ; Wed, 20 Feb 2008 08:29:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yJ4KVJFhCIkf for ; Wed, 20 Feb 2008 08:29:06 -0800 (PST) Received: from mailf.telecomitalia.it (mailf.telecomitalia.it [156.54.233.32]) by core3.amsl.com (Postfix) with ESMTP id 0664B28C191 for ; Wed, 20 Feb 2008 08:29:05 -0800 (PST) thread-index: Achz3bPS2yvy9TPWTda42Vd/zZXrbw== Received: from ptpxch010ba020.idc.cww.telecomitalia.it ([156.54.240.53]) by mailf.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Feb 2008 17:29:02 +0100 Received: from ptpxch006ba020.idc.cww.telecomitalia.it ([156.54.240.45]) by ptpxch010ba020.idc.cww.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Feb 2008 17:29:01 +0100 Received: from [10.229.4.58] ([10.229.4.58]) by ptpxch006ba020.idc.cww.telecomitalia.it over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Feb 2008 17:29:00 +0100 Content-Class: urn:content-classes:message Message-ID: <47BC54C9.3040408@telecomitalia.it> Importance: normal Priority: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2992 Date: Wed, 20 Feb 2008 17:26:49 +0100 From: "Simone Ruffino" User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: "Teco Boot" References: <47AAC029.8030908@dif.um.es> <47B9A5BF.9060106@inria.fr> <000001 c8726b$9d66b440$d8341cc0$@nl> <47BAC6D1.7060100@inria.fr> <001e01c873af$3ab21700$b0164500$@nl> <47BC32CE.1010009@telecomitalia.it> <1203522837.4276.74.camel@localhost> <001401c873dc$4c34fec0$e49efc40$@nl> In-Reply-To: <001401c873dc$4c34fec0$e49efc40$@nl> X-OriginalArrivalTime: 20 Feb 2008 16:29:00.0801 (UTC) FILETIME=[B2FDE710:01C873DD] Cc: autoconf@ietf.org Subject: Re: [Autoconf] AUTOCONF Problem Statement: reviews needed. X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Teco, Teco Boot wrote: > Hi Carlos, > Maybe it is true that is some "unmanaged and open" wired networks, the > multi-homing issue can arise. But I think the hosts can deal with this > issue, by selecting a default gateway. And yes, there is a relation betwe= en > the selected gateway and the generated SLAAC address. > I think that in a open, wireless network where we introduce a MANET > protocol, the problem is out-of-control. The MANET Router connected hosts= do > not have any idea of the MANET topology and I do not see a method that th= ese > nodes can select a source address, other than try and error. > The MANET Router itself could perform an internal MANET topology table > lookup and try to detect the egress to the Internet, and use corresponding > source address. I think this method does not work in all cases, e.g. sess= ion > continuity during movement is a problem. :D FYI, we have implemented (and documented in a expired draft) a solution = that exactly does that. And, it is integrated with Mobile IPv6. I've experimented many times that choosing the wrong border router = (e.g., picking the first one that MNR hears) can tear a voice call down = when MANET topology changes. Instead, with the mechanism you're = suggesting, the best possible performance is guaranteed. Only problem: solution was designed for a multi-link subnet MANET model, = but I think the underlying principle (ruoting table lookup to find best = source address) is still sound. > Any other opinions? > Teco. > = > = >> -----Oorspronkelijk bericht----- >> Van: Carlos Jes=FAs Bernardos Cano [mailto:cjbc@it.uc3m.es] >> Verzonden: woensdag 20 februari 2008 16:54 >> Aan: Simone Ruffino >> CC: Teco Boot; autoconf@ietf.org >> Onderwerp: Re: [Autoconf] AUTOCONF Problem Statement: reviews needed. >> >> Hi Somone, all. >> >> Two short comments below. >> >> On mi=E9, 2008-02-20 at 15:01 +0100, Simone Ruffino wrote: >>> Hi Teco, >>> some comments below. >>> >>> Thanks for your comments and regs, >>> Simone >>> >>> Teco Boot wrote: >>>> Hi, >>>> >>>> Some comments inline. >>>> >>>> I have more thoughts which I did not mention in my first response: >>>> >>>> On uniqueness validation, I posted before my reservations on active >>> DAD. In >>>> many cases, this is not needed. RFC4862: >>>>> To accommodate >>>>> sites that believe the overhead of performing Duplicate Address >>>>> Detection outweighs its benefits, the use of Duplicate Address >>>>> Detection can be disabled through the administrative setting of a >>>>> per-interface configuration flag. >>>> The old version of our Problem Statement had some text on this. >>>> >>>> On multi-homed subordinate MANETs, the current document does not >>> describe >>>> this scenario in detail. It is just an instance of a subordinate >>> MANET, as >>>> this category is described with "is connected to at least one >>> external >>>> network N". >>>> I think multi-homed subordinate MANET scenario introduces a large, >>> new >>>> problem which is related to the selection mechanism of the path to >>> one of >>>> the external networks. This path selection is out-of-control for >>> Autoconf, >>>> as it is up to the (MANET) routing protocol to find out the path to >>> the >>>> destination. >>>> Scenario: >>>> >>>> >>>> '. / >>>> `. Network N / Topologically >>> correct >>>> `. _,' prefix q:: >>> with >>>> Topologically correct `-.__ _,,' respect to >>> network M >>>> prefix p:: with `'-.,._,,'' ___ >>>> respect to network N : ,-=B4 >>>> +-:-+ / >>>> |MNR| ; N >>>> +-|-+ / E >>>> +-+ +---+ / /|\ \ +---+ ; T >>>> | |...MNR--- .-. ---MNR:....., W >>>> +-+ +---+ \ ,-( _)-. / +---+ ! O >>>> .-(_ MANET )-. ! R >>>> Other ( Communication ) : K >>>> Nodes `-(______)-' \ >>>> and \|/ \|/ : M >>>> Networks +-|-+ +-|-+ \ >>>> |MNR| \|/ |MNR| \_____ >>>> +-:-+ +-|-+ +-:-+ >>>> |MNR| : >>>> +-:-+ +-+ >>>> +-+ >>>> >>>> Now, we have to select a topologically correct prefix p:: with >>> respect to >>>> network N but not to network M or a topologically correct prefix >> q:: >>> with >>>> respect to network M but not to network N. It is very hard to >> select >>> p:: or >>>> q::, as it is dependent on the (dynamic) topology of the MANET and >>> the MANET >>>> routing protocol. >>> Great that you raised this point, because I've always stressed this >> is >>> a a problem :). >>> >>> I agree: the selection of prefix (and addresses) to use for >>> application sessions with external hosts is hard, because it directly >>> impacts on the path followed by return traffic *from* the external >>> network *to* MNRs >>> *in* the MANET. Routing protocols can only affect the other >> direction, >>> i.e. from the MNR to the external network. >>> >>> However, let me elaborate more on this. >>> I think selection of either p:: or q:: is not really a problem per- >> se. >>> In fact, MNRs (and connected hosts) could configure both p:: and q:: >>> on >>> their interfaces: IPv6 permits it. And hosts connected to MNRs could >>> initiate application sessions with hosts in both networks M and N: >>> source address selection rules will choose the prefix with the right >>> scope. >>> >>> Moreover, if both Network M and N are eventually connected to the >>> Internet and if hosts (attached to MNRs) want to initiate application >>> sessions with hosts on the Internet, p:: and q:: could be equivalent. >>> >>> But in this case, the choice of prefix could depend on other factors, >>> e.g. performance. In fact, it is actually more important to choose >> the >>> optimal Border MNR, in order to prevent return traffic to traverse >>> long paths in the MANET. Choosing a very far away border router (in >>> terms of number of hops, w.r.t. the MNR initiating the session) has a >>> direct impact on applications, especially jitter-sensitive ones like >>> VoIP. >>> >>> So in my opinion there is a 1:1 correspondence between performance >> and >>> prefix choice. >> [Carlos] I think this problem/scenario also happens in non-MANET >> scenarios (it's a multihoming issue) and it is not particular of IP >> address autoconfiguration. I agree is a very interesting issue, but I'm >> not sure the IP autoconf PS is the right place. The only specific issue >> I see there is how to detect that an initially multihomed subordinate >> MANET gets disconnected from one of the external networks it was >> attached to, and even in this case, this also occurs in non-MANETs. >> >>> By my knowledge, the MANET protocols we have right now are >>>> using the destination IP address for forwarding and not the source >>> IP >>>> address. >>>> Any thoughts including this problem in the Problem Statement >>> document? >>> I think it could be useful to add some considerations, but, we >> decided >>> to keep this version of PS "to-the-bone" as much as possible and get >>> agreement on this. I'd like to hear opinion of other authors as well. >> [Carlos] Again, I don't see this as an IP address autoconfiguration >> issue. This is related to MANET routing protocols, and therefore I'd >> prefer not to include any consideration in the PS. >> >> Regards, >> >> Carlos >>>> I have also my thoughts on needs for authorization on using the >>> external >>>> network. I think in real world, many access providers no not allow >>>> unauthorized nodes to have access. Getting an address in not that >>> much a >>>> problem, using the access network is. >>>> >>>> Regards, Teco >>>> >>> -------------------------------------------------------------------- >>> >>> CONFIDENTIALITY NOTICE >>> >>> This message and its attachments are addressed solely to the persons >>> above and may contain confidential information. If you have received >>> the message in error, be informed that any use of the content hereof >>> is prohibited. Please return it immediately to the sender and delete >>> the message. Should you have any questions, please contact us by >>> replying to webmaster@telecomitalia.it. >>> >>> Thank you >>> >>> www.telecomitalia.it >>> >>> -------------------------------------------------------------------- >>> >>> _______________________________________________ >>> Autoconf mailing list >>> Autoconf@ietf.org >>> http://www.ietf.org/mailman/listinfo/autoconf >> -- >> =A1AS=D3CIATE! Gratis para estudiantes http://www.telematica.ws >> Carlos Jes=FAs Bernardos Cano http://www.netcoms.net >> GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >> WEEDEV 2008: 1st Workshop on Experimental Evaluation and >> Deployment Experiences on Vehicular networks >> http://www.weedev.org/ >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > = > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > http://www.ietf.org/mailman/listinfo/autoconf -------------------------------------------------------------------- CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above = and may contain confidential information. If you have received the message = in error, be informed that any use of the content hereof is prohibited. Ple= ase return it immediately to the sender and delete the message. Should you = have any questions, please contact us by replying to webmaster@telecomitali= a.it. Thank you www.telecomitalia.it -------------------------------------------------------------------- = _______________________________________________ Autoconf mailing list Autoconf@ietf.org http://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Wed Feb 20 08:40:23 2008 Return-Path: X-Original-To: ietfarch-autoconf-archive@core3.amsl.com Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 73FAF3A6AB0; Wed, 20 Feb 2008 08:40:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.115 X-Spam-Level: X-Spam-Status: No, score=-0.115 tagged_above=-999 required=5 tests=[AWL=-0.578, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_21=0.6, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ec2856LoxOQw; Wed, 20 Feb 2008 08:40:22 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1AB603A6E19; Wed, 20 Feb 2008 08:40:22 -0800 (PST) X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A72F33A6A26 for ; Wed, 20 Feb 2008 08:40:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6UfeHkq81uCG for ; Wed, 20 Feb 2008 08:40:19 -0800 (PST) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id DB32C3A6950 for ; Wed, 20 Feb 2008 08:40:18 -0800 (PST) Received: from [163.117.139.72] (acorde.it.uc3m.es [163.117.139.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp01.uc3m.es (Postfix) with ESMTP id 546A63E6307; Wed, 20 Feb 2008 17:30:16 +0100 (CET) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Teco Boot In-Reply-To: <001401c873dc$4c34fec0$e49efc40$@nl> References: <47AAC029.8030908@dif.um.es> <47B9A5BF.9060106@inria.fr> <000001 c8726b$9d66b440$d8341cc0$@nl> <47BAC6D1.7060100@inria.fr> <001e01c873af$3ab21700$b0164500$@nl> <47BC32CE.1010009@telecomitalia.it> <1203522837.4276.74.camel@localhost> <001401c873dc$4c34fec0$e49efc40$@nl> Organization: Universidad Carlos III de Madrid Date: Wed, 20 Feb 2008 17:30:17 +0100 Message-Id: <1203525017.4276.106.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 Cc: autoconf@ietf.org Subject: Re: [Autoconf] AUTOCONF Problem Statement: reviews needed. X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0344993149==" Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org --===============0344993149== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-vrXiSok9qCS5+1aktam+" --=-vrXiSok9qCS5+1aktam+ Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Teco, On mi=E9, 2008-02-20 at 17:18 +0100, Teco Boot wrote: > Hi Carlos, > Maybe it is true that is some "unmanaged and open" wired networks, the > multi-homing issue can arise. But I think the hosts can deal with this The site multihoming issue may arise even in controlled wired networks that are connected to several ISPs. In IPv4 there are solutions to deal with the failure of one of the ISPs (mainly based on BGP). I still don't see why MANET is so different here (from an IP address autoconf point of view, routing is a different issue). Regards, Carlos > issue, by selecting a default gateway. And yes, there is a relation betwe= en > the selected gateway and the generated SLAAC address. > I think that in a open, wireless network where we introduce a MANET > protocol, the problem is out-of-control. The MANET Router connected hosts= do > not have any idea of the MANET topology and I do not see a method that th= ese > nodes can select a source address, other than try and error. > The MANET Router itself could perform an internal MANET topology table > lookup and try to detect the egress to the Internet, and use correspondin= g > source address. I think this method does not work in all cases, e.g. sess= ion > continuity during movement is a problem. > Any other opinions? > Teco. >=20 >=20 > > -----Oorspronkelijk bericht----- > > Van: Carlos Jes=FAs Bernardos Cano [mailto:cjbc@it.uc3m.es] > > Verzonden: woensdag 20 februari 2008 16:54 > > Aan: Simone Ruffino > > CC: Teco Boot; autoconf@ietf.org > > Onderwerp: Re: [Autoconf] AUTOCONF Problem Statement: reviews needed. > >=20 > > Hi Somone, all. > >=20 > > Two short comments below. > >=20 > > On mi=E9, 2008-02-20 at 15:01 +0100, Simone Ruffino wrote: > > > Hi Teco, > > > some comments below. > > > > > > Thanks for your comments and regs, > > > Simone > > > > > > Teco Boot wrote: > > > > Hi, > > > > > > > > Some comments inline. > > > > > > > > I have more thoughts which I did not mention in my first response: > > > > > > > > On uniqueness validation, I posted before my reservations on active > > > DAD. In > > > > many cases, this is not needed. RFC4862: > > > >> To accommodate > > > >> sites that believe the overhead of performing Duplicate Address > > > >> Detection outweighs its benefits, the use of Duplicate Address > > > >> Detection can be disabled through the administrative setting of a > > > >> per-interface configuration flag. > > > > The old version of our Problem Statement had some text on this. > > > > > > > > On multi-homed subordinate MANETs, the current document does not > > > describe > > > > this scenario in detail. It is just an instance of a subordinate > > > MANET, as > > > > this category is described with "is connected to at least one > > > external > > > > network N". > > > > I think multi-homed subordinate MANET scenario introduces a large, > > > new > > > > problem which is related to the selection mechanism of the path to > > > one of > > > > the external networks. This path selection is out-of-control for > > > Autoconf, > > > > as it is up to the (MANET) routing protocol to find out the path to > > > the > > > > destination. > > > > Scenario: > > > > > > > > > > > > '. / > > > > `. Network N / Topologically > > > correct > > > > `. _,' prefix q:: > > > with > > > > Topologically correct `-.__ _,,' respect to > > > network M > > > > prefix p:: with `'-.,._,,'' ___ > > > > respect to network N : ,-=B4 > > > > +-:-+ / > > > > |MNR| ; N > > > > +-|-+ / E > > > > +-+ +---+ / /|\ \ +---+ ; T > > > > | |...MNR--- .-. ---MNR:....., W > > > > +-+ +---+ \ ,-( _)-. / +---+ ! O > > > > .-(_ MANET )-. ! R > > > > Other ( Communication ) : K > > > > Nodes `-(______)-' \ > > > > and \|/ \|/ : M > > > > Networks +-|-+ +-|-+ \ > > > > |MNR| \|/ |MNR| \_____ > > > > +-:-+ +-|-+ +-:-+ > > > > |MNR| : > > > > +-:-+ +-+ > > > > +-+ > > > > > > > > Now, we have to select a topologically correct prefix p:: with > > > respect to > > > > network N but not to network M or a topologically correct prefix > > q:: > > > with > > > > respect to network M but not to network N. It is very hard to > > select > > > p:: or > > > > q::, as it is dependent on the (dynamic) topology of the MANET and > > > the MANET > > > > routing protocol. > > > > > > Great that you raised this point, because I've always stressed this > > is > > > a a problem :). > > > > > > I agree: the selection of prefix (and addresses) to use for > > > application sessions with external hosts is hard, because it directly > > > impacts on the path followed by return traffic *from* the external > > > network *to* MNRs > > > *in* the MANET. Routing protocols can only affect the other > > direction, > > > i.e. from the MNR to the external network. > > > > > > However, let me elaborate more on this. > > > I think selection of either p:: or q:: is not really a problem per- > > se. > > > In fact, MNRs (and connected hosts) could configure both p:: and q:: > > > on > > > their interfaces: IPv6 permits it. And hosts connected to MNRs could > > > initiate application sessions with hosts in both networks M and N: > > > source address selection rules will choose the prefix with the right > > > scope. > > > > > > Moreover, if both Network M and N are eventually connected to the > > > Internet and if hosts (attached to MNRs) want to initiate application > > > sessions with hosts on the Internet, p:: and q:: could be equivalent. > > > > > > But in this case, the choice of prefix could depend on other factors, > > > e.g. performance. In fact, it is actually more important to choose > > the > > > optimal Border MNR, in order to prevent return traffic to traverse > > > long paths in the MANET. Choosing a very far away border router (in > > > terms of number of hops, w.r.t. the MNR initiating the session) has a > > > direct impact on applications, especially jitter-sensitive ones like > > > VoIP. > > > > > > So in my opinion there is a 1:1 correspondence between performance > > and > > > prefix choice. > >=20 > > [Carlos] I think this problem/scenario also happens in non-MANET > > scenarios (it's a multihoming issue) and it is not particular of IP > > address autoconfiguration. I agree is a very interesting issue, but I'm > > not sure the IP autoconf PS is the right place. The only specific issue > > I see there is how to detect that an initially multihomed subordinate > > MANET gets disconnected from one of the external networks it was > > attached to, and even in this case, this also occurs in non-MANETs. > >=20 > > > By my knowledge, the MANET protocols we have right now are > > > > using the destination IP address for forwarding and not the source > > > IP > > > > address. > > > > Any thoughts including this problem in the Problem Statement > > > document? > > > > > > > > > > I think it could be useful to add some considerations, but, we > > decided > > > to keep this version of PS "to-the-bone" as much as possible and get > > > agreement on this. I'd like to hear opinion of other authors as well. > >=20 > > [Carlos] Again, I don't see this as an IP address autoconfiguration > > issue. This is related to MANET routing protocols, and therefore I'd > > prefer not to include any consideration in the PS. > >=20 > > Regards, > >=20 > > Carlos > > > > > > > I have also my thoughts on needs for authorization on using the > > > external > > > > network. I think in real world, many access providers no not allow > > > > unauthorized nodes to have access. Getting an address in not that > > > much a > > > > problem, using the access network is. > > > > > > > > Regards, Teco > > > > > > > -------------------------------------------------------------------- > > > > > > CONFIDENTIALITY NOTICE > > > > > > This message and its attachments are addressed solely to the persons > > > above and may contain confidential information. If you have received > > > the message in error, be informed that any use of the content hereof > > > is prohibited. Please return it immediately to the sender and delete > > > the message. Should you have any questions, please contact us by > > > replying to webmaster@telecomitalia.it. > > > > > > Thank you > > > > > > www.telecomitalia.it > > > > > > -------------------------------------------------------------------- > > > > > > _______________________________________________ > > > Autoconf mailing list > > > Autoconf@ietf.org > > > http://www.ietf.org/mailman/listinfo/autoconf > > -- > > =A1AS=D3CIATE! Gratis para estudiantes http://www.telematica.ws > > Carlos Jes=FAs Bernardos Cano http://www.netcoms.net > > GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > WEEDEV 2008: 1st Workshop on Experimental Evaluation and > > Deployment Experiences on Vehicular networks > > http://www.weedev.org/ > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >=20 --=20 =A1AS=D3CIATE! Gratis para estudiantes http://www.telematica.ws Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ WEEDEV 2008: 1st Workshop on Experimental Evaluation and Deployment Experiences on Vehicular networks http://www.weedev.org/ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ --=-vrXiSok9qCS5+1aktam+ Content-Type: application/pgp-signature; name=signature.asc Content-Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBHvFWZNdy6TdFwT2cRAg5rAJ4nf7TYfJjzSd778ev8Vhqss+LeeQCfTt31 jck+ShtchZ8p661JyaGPX4Q= =gKnw -----END PGP SIGNATURE----- --=-vrXiSok9qCS5+1aktam+-- --===============0344993149== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Autoconf mailing list Autoconf@ietf.org http://www.ietf.org/mailman/listinfo/autoconf --===============0344993149==-- From autoconf-bounces@ietf.org Wed Feb 20 08:41:21 2008 Return-Path: X-Original-To: ietfarch-autoconf-archive@core3.amsl.com Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3ADAD3A6E6A; Wed, 20 Feb 2008 08:41:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.391 X-Spam-Level: X-Spam-Status: No, score=-0.391 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rK83Stsx0QlR; Wed, 20 Feb 2008 08:41:20 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1DE4C3A6E35; Wed, 20 Feb 2008 08:41:20 -0800 (PST) X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97BB03A6E35 for ; Wed, 20 Feb 2008 08:41:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 40tMDv3WAWd7 for ; Wed, 20 Feb 2008 08:41:18 -0800 (PST) Received: from mailf.telecomitalia.it (mailf.telecomitalia.it [156.54.233.32]) by core3.amsl.com (Postfix) with ESMTP id 319233A6950 for ; Wed, 20 Feb 2008 08:41:18 -0800 (PST) thread-index: Achz32hRPNLVFNShSl+KwdBaNBOuPw== Received: from ptpxch007ba020.idc.cww.telecomitalia.it ([156.54.240.50]) by mailf.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Feb 2008 17:41:14 +0100 Received: from ptpxch006ba020.idc.cww.telecomitalia.it ([156.54.240.45]) by ptpxch007ba020.idc.cww.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Feb 2008 17:41:13 +0100 Received: from [10.229.4.58] ([10.229.4.58]) by ptpxch006ba020.idc.cww.telecomitalia.it over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Feb 2008 17:41:13 +0100 Content-Class: urn:content-classes:message Message-ID: <47BC57A6.9030004@telecomitalia.it> Importance: normal Priority: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2992 Date: Wed, 20 Feb 2008 17:39:02 +0100 From: "Simone Ruffino" User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: References: <47AAC029.8030908@dif.um.es> <47B9A5BF.9060106@inria.fr> <000001 c8726b$9d66b440$d8341cc0$@nl> <47BAC6D1.7060100@inria.fr> <001e01c873af$3ab21700$b0164500$@nl> <47BC32CE.1010009@telecomitalia.it> <1203522837.4276.74.camel@localhost> In-Reply-To: <1203522837.4276.74.camel@localhost> X-OriginalArrivalTime: 20 Feb 2008 16:41:13.0089 (UTC) FILETIME=[67782F10:01C873DF] Cc: autoconf@ietf.org Subject: Re: [Autoconf] AUTOCONF Problem Statement: reviews needed. X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Carlos Jes=FAs Bernardos Cano wrote: > Hi Somone, all. > = > Two short comments below. > = > On mi=E9, 2008-02-20 at 15:01 +0100, Simone Ruffino wrote: [[SNIP]] >> >> I agree: the selection of prefix (and addresses) to use for >> application = >> sessions with external hosts is hard, because it directly impacts on >> the = >> path followed by return traffic *from* the external network *to* MNRs = >> *in* the MANET. Routing protocols can only affect the other >> direction, = >> i.e. from the MNR to the external network. >> >> However, let me elaborate more on this. >> I think selection of either p:: or q:: is not really a problem >> per-se. = >> In fact, MNRs (and connected hosts) could configure both p:: and q:: >> on = >> their interfaces: IPv6 permits it. And hosts connected to MNRs could = >> initiate application sessions with hosts in both networks M and N: = >> source address selection rules will choose the prefix with the right >> scope. >> >> Moreover, if both Network M and N are eventually connected to the = >> Internet and if hosts (attached to MNRs) want to initiate application = >> sessions with hosts on the Internet, p:: and q:: could be equivalent. >> >> But in this case, the choice of prefix could depend on other factors, = >> e.g. performance. In fact, it is actually more important to choose >> the = >> optimal Border MNR, in order to prevent return traffic to traverse >> long = >> paths in the MANET. Choosing a very far away border router (in terms >> of = >> number of hops, w.r.t. the MNR initiating the session) has a direct = >> impact on applications, especially jitter-sensitive ones like VoIP. >> >> So in my opinion there is a 1:1 correspondence between performance >> and = >> prefix choice. > = > [Carlos] I think this problem/scenario also happens in non-MANET > scenarios (it's a multihoming issue) and it is not particular of IP > address autoconfiguration. I agree is a very interesting issue, but I'm > not sure the IP autoconf PS is the right place. The only specific issue > I see there is how to detect that an initially multihomed subordinate > MANET gets disconnected from one of the external networks it was > attached to, and even in this case, this also occurs in non-MANETs. > = I respectfully don't agree. MANET has specific problems, deriving from the fact that routers can = dynamically change topology (which usually does not happen in wired = networks....): the choice of a random prefix (from a pool of available = prefixes) by an MNR could, one minute later, cause severe performance = degradation to hosts. This of course cannot be avoided in single-border-router scenarios, but, = if multiple border routers are available, this CAN be avoided, with = proper prefix selection mechanisms. So, I think that (as with DHCP) the question is: are existing solutions = able to cope with specific MANET environment, ... including here the = fact that there is a Big difference between a three-hop path and a = four-hop path .... :) ? >> By my knowledge, the MANET protocols we have right now are >>> using the destination IP address for forwarding and not the source >> IP >>> address. >>> Any thoughts including this problem in the Problem Statement >> document? >> I think it could be useful to add some considerations, but, we >> decided = >> to keep this version of PS "to-the-bone" as much as possible and get = >> agreement on this. I'd like to hear opinion of other authors as well. > = > [Carlos] Again, I don't see this as an IP address autoconfiguration > issue. This is related to MANET routing protocols, and therefore I'd > prefer not to include any consideration in the PS. > = > Regards, > = > Carlos -------------------------------------------------------------------- CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above = and may contain confidential information. If you have received the message = in error, be informed that any use of the content hereof is prohibited. Ple= ase return it immediately to the sender and delete the message. Should you = have any questions, please contact us by replying to webmaster@telecomitali= a.it. Thank you www.telecomitalia.it -------------------------------------------------------------------- = _______________________________________________ Autoconf mailing list Autoconf@ietf.org http://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Wed Feb 20 08:43:21 2008 Return-Path: X-Original-To: ietfarch-autoconf-archive@core3.amsl.com Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB2573A6E26; Wed, 20 Feb 2008 08:43:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.472 X-Spam-Level: X-Spam-Status: No, score=-0.472 tagged_above=-999 required=5 tests=[AWL=-0.635, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_21=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YVmviMJ6wb-H; Wed, 20 Feb 2008 08:43:20 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 899193A6A26; Wed, 20 Feb 2008 08:43:20 -0800 (PST) X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3936E3A6950 for ; Wed, 20 Feb 2008 08:43:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EnILZas-afPC for ; Wed, 20 Feb 2008 08:43:18 -0800 (PST) Received: from hpsmtp-eml11.kpnxchange.com (hpsmtp-eml11.KPNXCHANGE.COM [213.75.38.111]) by core3.amsl.com (Postfix) with ESMTP id 67DF53A6A26 for ; Wed, 20 Feb 2008 08:43:17 -0800 (PST) Received: from hpsmtp-eml04.kpnxchange.com ([213.75.38.104]) by hpsmtp-eml11.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Feb 2008 17:43:13 +0100 Received: from M90Teco ([86.83.9.22]) by hpsmtp-eml04.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Feb 2008 17:42:56 +0100 From: "Teco Boot" To: "'Simone Ruffino'" References: <47AAC029.8030908@dif.um.es> <47B9A5BF.9060106@inria.fr> <000001 c8726b$9d66b440$d8341cc0$@nl> <47BAC6D1.7060100@inria.fr> <001e01c873af$3ab21700$b0164500$@nl> <47BC32CE.1010009@telecomitalia.it> <1203522837.4276.74.camel@localhost> <001401c873dc$4c34fec0$e49efc40$@nl> <47BC54C9.3040408@telecomitalia.it> In-Reply-To: <47BC54C9.3040408@telecomitalia.it> Date: Wed, 20 Feb 2008 17:42:44 +0100 Message-ID: <001901c873df$9fe315e0$dfa941a0$@nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 thread-index: Achz3bPS2yvy9TPWTda42Vd/zZXrbwAAQKBg Content-Language: nl X-OriginalArrivalTime: 20 Feb 2008 16:42:56.0136 (UTC) FILETIME=[A4E3E880:01C873DF] Cc: autoconf@ietf.org Subject: Re: [Autoconf] AUTOCONF Problem Statement: reviews needed. X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org I do not want to suggest a solution at this moment. After Philly, I will. My intention was to make clear taht it is hard for a MANET node to select a source address that is appropriate for communication with nodes outside a multi-homed MANET. And that for a MANET router connected host, it is undoable. I think try-and-error is not an acceptable solution. I always thought this is an important real world issue. Your effort on this is some evidence;-) Teco. > -----Oorspronkelijk bericht----- > Van: Simone Ruffino [mailto:simone.ruffino@telecomitalia.it] > Verzonden: woensdag 20 februari 2008 17:27 > Aan: Teco Boot > CC: cjbc@it.uc3m.es; autoconf@ietf.org > Onderwerp: Re: [Autoconf] AUTOCONF Problem Statement: reviews needed. > = > Teco, > = > Teco Boot wrote: > > Hi Carlos, > > Maybe it is true that is some "unmanaged and open" wired networks, > the > > multi-homing issue can arise. But I think the hosts can deal with > this > > issue, by selecting a default gateway. And yes, there is a relation > between > > the selected gateway and the generated SLAAC address. > > I think that in a open, wireless network where we introduce a MANET > > protocol, the problem is out-of-control. The MANET Router connected > hosts do > > not have any idea of the MANET topology and I do not see a method > that these > > nodes can select a source address, other than try and error. > > The MANET Router itself could perform an internal MANET topology > table > > lookup and try to detect the egress to the Internet, and use > corresponding > > source address. I think this method does not work in all cases, e.g. > session > > continuity during movement is a problem. > = > :D > = > FYI, we have implemented (and documented in a expired draft) a solution > that exactly does that. > And, it is integrated with Mobile IPv6. > I've experimented many times that choosing the wrong border router > (e.g., picking the first one that MNR hears) can tear a voice call down > when MANET topology changes. Instead, with the mechanism you're > suggesting, the best possible performance is guaranteed. > = > Only problem: solution was designed for a multi-link subnet MANET > model, > but I think the underlying principle (ruoting table lookup to find best > source address) is still sound. > = > = > > Any other opinions? > > Teco. > > > > > >> -----Oorspronkelijk bericht----- > >> Van: Carlos Jes=FAs Bernardos Cano [mailto:cjbc@it.uc3m.es] > >> Verzonden: woensdag 20 februari 2008 16:54 > >> Aan: Simone Ruffino > >> CC: Teco Boot; autoconf@ietf.org > >> Onderwerp: Re: [Autoconf] AUTOCONF Problem Statement: reviews > needed. > >> > >> Hi Somone, all. > >> > >> Two short comments below. > >> > >> On mi=E9, 2008-02-20 at 15:01 +0100, Simone Ruffino wrote: > >>> Hi Teco, > >>> some comments below. > >>> > >>> Thanks for your comments and regs, > >>> Simone > >>> > >>> Teco Boot wrote: > >>>> Hi, > >>>> > >>>> Some comments inline. > >>>> > >>>> I have more thoughts which I did not mention in my first response: > >>>> > >>>> On uniqueness validation, I posted before my reservations on > active > >>> DAD. In > >>>> many cases, this is not needed. RFC4862: > >>>>> To accommodate > >>>>> sites that believe the overhead of performing Duplicate Address > >>>>> Detection outweighs its benefits, the use of Duplicate Address > >>>>> Detection can be disabled through the administrative setting of a > >>>>> per-interface configuration flag. > >>>> The old version of our Problem Statement had some text on this. > >>>> > >>>> On multi-homed subordinate MANETs, the current document does not > >>> describe > >>>> this scenario in detail. It is just an instance of a subordinate > >>> MANET, as > >>>> this category is described with "is connected to at least one > >>> external > >>>> network N". > >>>> I think multi-homed subordinate MANET scenario introduces a large, > >>> new > >>>> problem which is related to the selection mechanism of the path to > >>> one of > >>>> the external networks. This path selection is out-of-control for > >>> Autoconf, > >>>> as it is up to the (MANET) routing protocol to find out the path > to > >>> the > >>>> destination. > >>>> Scenario: > >>>> > >>>> > >>>> '. / > >>>> `. Network N / Topologically > >>> correct > >>>> `. _,' prefix > q:: > >>> with > >>>> Topologically correct `-.__ _,,' respect to > >>> network M > >>>> prefix p:: with `'-.,._,,'' ___ > >>>> respect to network N : ,-=B4 > >>>> +-:-+ / > >>>> |MNR| ; N > >>>> +-|-+ / E > >>>> +-+ +---+ / /|\ \ +---+ ; T > >>>> | |...MNR--- .-. ---MNR:....., W > >>>> +-+ +---+ \ ,-( _)-. / +---+ ! O > >>>> .-(_ MANET )-. ! R > >>>> Other ( Communication ) : K > >>>> Nodes `-(______)-' \ > >>>> and \|/ \|/ : M > >>>> Networks +-|-+ +-|-+ \ > >>>> |MNR| \|/ |MNR| \_____ > >>>> +-:-+ +-|-+ +-:-+ > >>>> |MNR| : > >>>> +-:-+ +-+ > >>>> +-+ > >>>> > >>>> Now, we have to select a topologically correct prefix p:: with > >>> respect to > >>>> network N but not to network M or a topologically correct prefix > >> q:: > >>> with > >>>> respect to network M but not to network N. It is very hard to > >> select > >>> p:: or > >>>> q::, as it is dependent on the (dynamic) topology of the MANET and > >>> the MANET > >>>> routing protocol. > >>> Great that you raised this point, because I've always stressed this > >> is > >>> a a problem :). > >>> > >>> I agree: the selection of prefix (and addresses) to use for > >>> application sessions with external hosts is hard, because it > directly > >>> impacts on the path followed by return traffic *from* the external > >>> network *to* MNRs > >>> *in* the MANET. Routing protocols can only affect the other > >> direction, > >>> i.e. from the MNR to the external network. > >>> > >>> However, let me elaborate more on this. > >>> I think selection of either p:: or q:: is not really a problem per- > >> se. > >>> In fact, MNRs (and connected hosts) could configure both p:: and > q:: > >>> on > >>> their interfaces: IPv6 permits it. And hosts connected to MNRs > could > >>> initiate application sessions with hosts in both networks M and N: > >>> source address selection rules will choose the prefix with the > right > >>> scope. > >>> > >>> Moreover, if both Network M and N are eventually connected to the > >>> Internet and if hosts (attached to MNRs) want to initiate > application > >>> sessions with hosts on the Internet, p:: and q:: could be > equivalent. > >>> > >>> But in this case, the choice of prefix could depend on other > factors, > >>> e.g. performance. In fact, it is actually more important to choose > >> the > >>> optimal Border MNR, in order to prevent return traffic to traverse > >>> long paths in the MANET. Choosing a very far away border router (in > >>> terms of number of hops, w.r.t. the MNR initiating the session) has > a > >>> direct impact on applications, especially jitter-sensitive ones > like > >>> VoIP. > >>> > >>> So in my opinion there is a 1:1 correspondence between performance > >> and > >>> prefix choice. > >> [Carlos] I think this problem/scenario also happens in non-MANET > >> scenarios (it's a multihoming issue) and it is not particular of IP > >> address autoconfiguration. I agree is a very interesting issue, but > I'm > >> not sure the IP autoconf PS is the right place. The only specific > issue > >> I see there is how to detect that an initially multihomed > subordinate > >> MANET gets disconnected from one of the external networks it was > >> attached to, and even in this case, this also occurs in non-MANETs. > >> > >>> By my knowledge, the MANET protocols we have right now are > >>>> using the destination IP address for forwarding and not the source > >>> IP > >>>> address. > >>>> Any thoughts including this problem in the Problem Statement > >>> document? > >>> I think it could be useful to add some considerations, but, we > >> decided > >>> to keep this version of PS "to-the-bone" as much as possible and > get > >>> agreement on this. I'd like to hear opinion of other authors as > well. > >> [Carlos] Again, I don't see this as an IP address autoconfiguration > >> issue. This is related to MANET routing protocols, and therefore I'd > >> prefer not to include any consideration in the PS. > >> > >> Regards, > >> > >> Carlos > >>>> I have also my thoughts on needs for authorization on using the > >>> external > >>>> network. I think in real world, many access providers no not allow > >>>> unauthorized nodes to have access. Getting an address in not that > >>> much a > >>>> problem, using the access network is. > >>>> > >>>> Regards, Teco > >>>> > >>> ------------------------------------------------------------------- > - > >>> > >>> CONFIDENTIALITY NOTICE > >>> > >>> This message and its attachments are addressed solely to the > persons > >>> above and may contain confidential information. If you have > received > >>> the message in error, be informed that any use of the content > hereof > >>> is prohibited. Please return it immediately to the sender and > delete > >>> the message. Should you have any questions, please contact us by > >>> replying to webmaster@telecomitalia.it. > >>> > >>> Thank you > >>> > >>> www.telecomitalia.it > >>> > >>> ------------------------------------------------------------------- > - > >>> > >>> _______________________________________________ > >>> Autoconf mailing list > >>> Autoconf@ietf.org > >>> http://www.ietf.org/mailman/listinfo/autoconf > >> -- > >> =A1AS=D3CIATE! Gratis para estudiantes http://www.telematica.ws > >> Carlos Jes=FAs Bernardos Cano http://www.netcoms.net > >> GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 > >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > >> WEEDEV 2008: 1st Workshop on Experimental Evaluation and > >> Deployment Experiences on Vehicular networks > >> http://www.weedev.org/ > >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > > > _______________________________________________ > > Autoconf mailing list > > Autoconf@ietf.org > > http://www.ietf.org/mailman/listinfo/autoconf > -------------------------------------------------------------------- > = > CONFIDENTIALITY NOTICE > = > This message and its attachments are addressed solely to the persons > above and may contain confidential information. If you have received > the message in error, be informed that any use of the content hereof is > prohibited. Please return it immediately to the sender and delete the > message. Should you have any questions, please contact us by replying > to webmaster@telecomitalia.it. > = > Thank you > = > www.telecomitalia.it > = > -------------------------------------------------------------------- > = _______________________________________________ Autoconf mailing list Autoconf@ietf.org http://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Wed Feb 20 08:55:25 2008 Return-Path: X-Original-To: ietfarch-autoconf-archive@core3.amsl.com Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F5C428C7DF; Wed, 20 Feb 2008 08:55:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.82 X-Spam-Level: X-Spam-Status: No, score=-2.82 tagged_above=-999 required=5 tests=[AWL=-3.779, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, MIME_QP_LONG_LINE=1.396, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lCR6lIBbClj4; Wed, 20 Feb 2008 08:55:24 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 78C6128C22D; Wed, 20 Feb 2008 08:55:24 -0800 (PST) X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C32F28C22D for ; Wed, 20 Feb 2008 08:55:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zx7qjKofd6Ic for ; Wed, 20 Feb 2008 08:55:22 -0800 (PST) Received: from xenon1.um.es (mail.um.es [155.54.212.109]) by core3.amsl.com (Postfix) with ESMTP id 7185728C286 for ; Wed, 20 Feb 2008 08:55:22 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by xenon1.um.es (Postfix) with ESMTP id EB6256706B for ; Wed, 20 Feb 2008 17:55:18 +0100 (CET) X-Virus-Scanned: by amavisd-new-2.4.2 (20060627) (Debian) at xenon1.telemat.um.es Received: from xenon1.um.es ([127.0.0.1]) by localhost (xenon1.telemat.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id jlrMoSQC4xHL for ; Wed, 20 Feb 2008 17:55:18 +0100 (CET) Received: from aries.dif.um.es (aries.inf.um.es [155.54.210.253]) by xenon1.um.es (Postfix) with SMTP id EF8506704F for ; Wed, 20 Feb 2008 17:55:17 +0100 (CET) Received: (qmail 15578 invoked from network); 20 Feb 2008 16:09:44 -0000 Received: from inf-205-38.um.es (155.54.205.38) by aries.dif.um.es with SMTP; 20 Feb 2008 16:09:44 -0000 From: "Francisco J. Ros" Organization: University of Murcia To: autoconf@ietf.org Date: Wed, 20 Feb 2008 18:02:23 +0100 User-Agent: KMail/1.9.5 References: <47AAC029.8030908@dif.um.es> <1203522837.4276.74.camel@localhost> <47BC57A6.9030004@telecomitalia.it> In-Reply-To: <47BC57A6.9030004@telecomitalia.it> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200802201802.23166.fjrm@dif.um.es> Subject: Re: [Autoconf] AUTOCONF Problem Statement: reviews needed. X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Hi Simone, all, I've been following the discussion and tend to agree with Carlos. In my = opinion, the MNR can configure as many prefixes as are available for each o= f = its interfaces. Then, the selection of one border router or another accordi= ng = to a given metric (e.g. hop count) is a routing issue not related to = autoconf. The source address selection policy should then take into account = the border router which is being used in order to avoid the ingress filteri= ng = issue. I don't think the P-S is the right place to discuss this, although I don't = have a strong feeling on this either. Regards, fran On Wednesday 20 February 2008 17:39, Simone Ruffino wrote: > Carlos Jes=FAs Bernardos Cano wrote: > > [Carlos] I think this problem/scenario also happens in non-MANET > > scenarios (it's a multihoming issue) and it is not particular of IP > > address autoconfiguration. I agree is a very interesting issue, but I'm > > not sure the IP autoconf PS is the right place. The only specific issue > > I see there is how to detect that an initially multihomed subordinate > > MANET gets disconnected from one of the external networks it was > > attached to, and even in this case, this also occurs in non-MANETs. > > I respectfully don't agree. > MANET has specific problems, deriving from the fact that routers can > dynamically change topology (which usually does not happen in wired > networks....): the choice of a random prefix (from a pool of available > prefixes) by an MNR could, one minute later, cause severe performance > degradation to hosts. > This of course cannot be avoided in single-border-router scenarios, but, > if multiple border routers are available, this CAN be avoided, with > proper prefix selection mechanisms. > > So, I think that (as with DHCP) the question is: are existing solutions > able to cope with specific MANET environment, ... including here the > fact that there is a Big difference between a three-hop path and a > four-hop path .... :) ? > -- = Francisco J. Ros, Ph.D. Student Dept. of Information and Communications Engineering University of Murcia, Murcia (Spain) http://masimum.inf.um.es/fjrm/ _______________________________________________ Autoconf mailing list Autoconf@ietf.org http://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Wed Feb 20 08:58:11 2008 Return-Path: X-Original-To: ietfarch-autoconf-archive@core3.amsl.com Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A83D728C669; Wed, 20 Feb 2008 08:58:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.73 X-Spam-Level: X-Spam-Status: No, score=-0.73 tagged_above=-999 required=5 tests=[AWL=-0.293, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fj4PHLWs+6Ah; Wed, 20 Feb 2008 08:58:10 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D4B853A6AB0; Wed, 20 Feb 2008 08:58:10 -0800 (PST) X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E1113A6AB0 for ; Wed, 20 Feb 2008 08:58:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Td8CFQ2bb+Dl for ; Wed, 20 Feb 2008 08:58:09 -0800 (PST) Received: from hpsmtp-eml18.kpnxchange.com (hpsmtp-eml18.kpnxchange.com [213.75.38.118]) by core3.amsl.com (Postfix) with ESMTP id 2C0EB3A6A90 for ; Wed, 20 Feb 2008 08:58:09 -0800 (PST) Received: from hpsmtp-eml09.kpnxchange.com ([213.75.38.109]) by hpsmtp-eml18.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Feb 2008 17:58:05 +0100 Received: from M90Teco ([86.83.9.22]) by hpsmtp-eml09.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Feb 2008 17:58:04 +0100 From: "Teco Boot" To: References: <47AAC029.8030908@dif.um.es> <47B9A5BF.9060106@inria.fr> <000001 c8726b$9d66b440$d8341cc0$@nl> <47BAC6D1.7060100@inria.fr> <001e01c873af$3ab21700$b0164500$@nl> <47BC32CE.1010009@telecomitalia.it> <1203522837.4276.74.camel@localhost> <001401c873dc$4c34fec0$e49efc40$@nl> <1203525017.4276.106.camel@localhost> In-Reply-To: <1203525017.4276.106.camel@localhost> Date: Wed, 20 Feb 2008 17:57:55 +0100 Message-ID: <001d01c873e1$bd05aa00$3710fe00$@nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 thread-index: Achz30fTCaGFQI+ZTEmt1Jc/9Ga+hwAAJCew Content-Language: nl X-OriginalArrivalTime: 20 Feb 2008 16:58:04.0145 (UTC) FILETIME=[C21B1610:01C873E1] Cc: autoconf@ietf.org Subject: Re: [Autoconf] AUTOCONF Problem Statement: reviews needed. X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Hi Carlos, There are BCPs to circumvent this problem. I always used ingress filters on ingress interfaces and never on transit links. I would never, never, never deploy an open wireless access network without strict ingress filtering. I highly prefer ingress filtering on secured and fully controlled access networks, just for making sure every node is behaving well. I want to keep this BCP as long as possible, including supporting a multi-homed secured and fully controlled access network. The options are opening the ingress filters on all exit points for all possible exit points, or strict filters on each exit point and source address selection on all nodes. With multiple access providers, the wide ingress filter is no option anymore. Many large network operators offer different access technologies, and I doubt if wide filters will be used here. Regards, Teco. > -----Oorspronkelijk bericht----- > Van: Carlos Jes=FAs Bernardos Cano [mailto:cjbc@it.uc3m.es] > Verzonden: woensdag 20 februari 2008 17:30 > Aan: Teco Boot > CC: autoconf@ietf.org > Onderwerp: RE: [Autoconf] AUTOCONF Problem Statement: reviews needed. > = > Hi Teco, > = > On mi=E9, 2008-02-20 at 17:18 +0100, Teco Boot wrote: > > Hi Carlos, > > Maybe it is true that is some "unmanaged and open" wired networks, > the > > multi-homing issue can arise. But I think the hosts can deal with > this > = > The site multihoming issue may arise even in controlled wired > networks that are connected to several ISPs. In IPv4 there are > solutions to deal with the failure of one of the ISPs (mainly based on > BGP). I still don't see why MANET is so different here (from an IP > address autoconf point of view, routing is a different issue). > = > Regards, > = > Carlos > = _______________________________________________ Autoconf mailing list Autoconf@ietf.org http://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Wed Feb 20 09:03:47 2008 Return-Path: X-Original-To: ietfarch-autoconf-archive@core3.amsl.com Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A1CE828C8B4; Wed, 20 Feb 2008 09:03:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.727 X-Spam-Level: X-Spam-Status: No, score=-0.727 tagged_above=-999 required=5 tests=[AWL=-0.290, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uBaFkDfyTr7H; Wed, 20 Feb 2008 09:03:46 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B73728C16C; Wed, 20 Feb 2008 09:03:25 -0800 (PST) X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 854CB28C9BB for ; Wed, 20 Feb 2008 09:03:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aHfsEoqeG2f4 for ; Wed, 20 Feb 2008 09:03:22 -0800 (PST) Received: from hpsmtp-eml14.kpnxchange.com (hpsmtp-eml14.KPNXCHANGE.COM [213.75.38.114]) by core3.amsl.com (Postfix) with ESMTP id 206DD28C849 for ; Wed, 20 Feb 2008 09:02:01 -0800 (PST) Received: from hpsmtp-eml06.kpnxchange.com ([213.75.38.106]) by hpsmtp-eml14.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Feb 2008 18:01:57 +0100 Received: from M90Teco ([86.83.9.22]) by hpsmtp-eml06.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Feb 2008 18:01:56 +0100 From: "Teco Boot" To: "'Francisco J. Ros'" References: <47AAC029.8030908@dif.um.es> <1203522837.4276.74.camel@localhost> <47BC57A6.9030004@telecomitalia.it> <200802201802.23166.fjrm@dif.um.es> In-Reply-To: <200802201802.23166.fjrm@dif.um.es> Date: Wed, 20 Feb 2008 18:01:48 +0100 Message-ID: <001e01c873e2$47b7f360$d727da20$@nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 thread-index: Achz4WRw6wfAXrhaTyezDu7LAK8sygAAHI6g Content-Language: nl X-OriginalArrivalTime: 20 Feb 2008 17:01:57.0076 (UTC) FILETIME=[4CF18940:01C873E2] Cc: autoconf@ietf.org Subject: Re: [Autoconf] AUTOCONF Problem Statement: reviews needed. X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Hi Francisco, What about the connected hosts? What about movement and session continuity? What about a reactive MANET routing protocol? Regards, Teco > -----Oorspronkelijk bericht----- > Van: autoconf-bounces@ietf.org [mailto:autoconf-bounces@ietf.org] > Namens Francisco J. Ros > Verzonden: woensdag 20 februari 2008 18:02 > Aan: autoconf@ietf.org > Onderwerp: Re: [Autoconf] AUTOCONF Problem Statement: reviews needed. > = > Hi Simone, all, > = > I've been following the discussion and tend to agree with Carlos. In my > opinion, the MNR can configure as many prefixes as are available for > each of > its interfaces. Then, the selection of one border router or another > according > to a given metric (e.g. hop count) is a routing issue not related to > autoconf. The source address selection policy should then take into > account > the border router which is being used in order to avoid the ingress > filtering > issue. > = > I don't think the P-S is the right place to discuss this, although I > don't > have a strong feeling on this either. > = > Regards, > fran > = > On Wednesday 20 February 2008 17:39, Simone Ruffino wrote: > > > Carlos Jes=FAs Bernardos Cano wrote: > > > [Carlos] I think this problem/scenario also happens in non-MANET > > > scenarios (it's a multihoming issue) and it is not particular of IP > > > address autoconfiguration. I agree is a very interesting issue, but > I'm > > > not sure the IP autoconf PS is the right place. The only specific > issue > > > I see there is how to detect that an initially multihomed > subordinate > > > MANET gets disconnected from one of the external networks it was > > > attached to, and even in this case, this also occurs in non-MANETs. > > > > I respectfully don't agree. > > MANET has specific problems, deriving from the fact that routers can > > dynamically change topology (which usually does not happen in wired > > networks....): the choice of a random prefix (from a pool of > available > > prefixes) by an MNR could, one minute later, cause severe performance > > degradation to hosts. > > This of course cannot be avoided in single-border-router scenarios, > but, > > if multiple border routers are available, this CAN be avoided, with > > proper prefix selection mechanisms. > > > > So, I think that (as with DHCP) the question is: are existing > solutions > > able to cope with specific MANET environment, ... including here the > > fact that there is a Big difference between a three-hop path and a > > four-hop path .... :) ? > > > = > -- > Francisco J. Ros, Ph.D. Student > Dept. of Information and Communications Engineering > University of Murcia, Murcia (Spain) > = > http://masimum.inf.um.es/fjrm/ > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > http://www.ietf.org/mailman/listinfo/autoconf _______________________________________________ Autoconf mailing list Autoconf@ietf.org http://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Wed Feb 20 09:36:38 2008 Return-Path: X-Original-To: ietfarch-autoconf-archive@core3.amsl.com Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A61628C7DF; Wed, 20 Feb 2008 09:36:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.403 X-Spam-Level: X-Spam-Status: No, score=-0.403 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IoAyB3A-Dwaq; Wed, 20 Feb 2008 09:36:37 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2756528C639; Wed, 20 Feb 2008 09:36:37 -0800 (PST) X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CEBB128C61D for ; Wed, 20 Feb 2008 09:36:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gJAU01CPxkaM for ; Wed, 20 Feb 2008 09:36:35 -0800 (PST) Received: from maile.telecomitalia.it (maile.telecomitalia.it [156.54.233.31]) by core3.amsl.com (Postfix) with ESMTP id AC12928C5F6 for ; Wed, 20 Feb 2008 09:36:34 -0800 (PST) thread-index: Achz5yEQCfAF1VNaRy6wjwlT6q73eA== Received: from ptpxch009ba020.idc.cww.telecomitalia.it ([156.54.240.52]) by maile.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Feb 2008 18:36:30 +0100 Received: from ptpxch006ba020.idc.cww.telecomitalia.it ([156.54.240.45]) by ptpxch009ba020.idc.cww.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Feb 2008 18:36:30 +0100 Received: from [10.229.4.58] ([10.229.4.58]) by ptpxch006ba020.idc.cww.telecomitalia.it over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Feb 2008 18:36:29 +0100 Content-Class: urn:content-classes:message Importance: normal Priority: normal x-mimeole: Produced By Microsoft MimeOLE V6.00.3790.2992 Message-ID: <47BC649A.3000202@telecomitalia.it> Date: Wed, 20 Feb 2008 18:34:18 +0100 From: "Simone Ruffino" User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: "Francisco J. Ros" References: <47AAC029.8030908@dif.um.es> <1203522837.4276.74.camel@localhost> <47BC57A6.9030004@telecomitalia.it> <200802201802.23166.fjrm@dif.um.es> In-Reply-To: <200802201802.23166.fjrm@dif.um.es> X-OriginalArrivalTime: 20 Feb 2008 17:36:29.0738 (UTC) FILETIME=[2058A8A0:01C873E7] Cc: autoconf@ietf.org Subject: Re: [Autoconf] AUTOCONF Problem Statement: reviews needed. X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Hi Francisco, Please see below. Simone Francisco J. Ros wrote: > Hi Simone, all, > = > I've been following the discussion and tend to agree with Carlos. In my = > opinion, the MNR can configure as many prefixes as are available for each= of = > its interfaces. Then, the selection of one border router or another accor= ding = > to a given metric (e.g. hop count) is a routing issue not related to = > autoconf. = Well, every time I raise this point we end up here ..:). But, as a matter of fact: - performance degradation caused by prefix choice and - ingress filtering are not tackled anywhere. The source address selection policy should then take into account > the border router which is being used in order to avoid the ingress filte= ring = > issue. Well, yes, but it's not that easy...:) Because, if you're doing that and the border routers change frequently, = applications are degraded as well, even if a session continuity solution = like MIPv6 is in place. > = > I don't think the P-S is the right place to discuss this, although I don'= t = > have a strong feeling on this either. Although my personal opinion is that they could be mentioned in the P-S, = right now, as an author, I feel much more important to get consensus on = what are the _basic_ problems to solve. I.e., if DHCP does not work, nothing else works.... > = > Regards, > fran > = > On Wednesday 20 February 2008 17:39, Simone Ruffino wrote: > >> Carlos Jes=FAs Bernardos Cano wrote: >>> [Carlos] I think this problem/scenario also happens in non-MANET >>> scenarios (it's a multihoming issue) and it is not particular of IP >>> address autoconfiguration. I agree is a very interesting issue, but I'm >>> not sure the IP autoconf PS is the right place. The only specific issue >>> I see there is how to detect that an initially multihomed subordinate >>> MANET gets disconnected from one of the external networks it was >>> attached to, and even in this case, this also occurs in non-MANETs. >> I respectfully don't agree. >> MANET has specific problems, deriving from the fact that routers can >> dynamically change topology (which usually does not happen in wired >> networks....): the choice of a random prefix (from a pool of available >> prefixes) by an MNR could, one minute later, cause severe performance >> degradation to hosts. >> This of course cannot be avoided in single-border-router scenarios, but, >> if multiple border routers are available, this CAN be avoided, with >> proper prefix selection mechanisms. >> >> So, I think that (as with DHCP) the question is: are existing solutions >> able to cope with specific MANET environment, ... including here the >> fact that there is a Big difference between a three-hop path and a >> four-hop path .... :) ? >> > = -------------------------------------------------------------------- CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above = and may contain confidential information. If you have received the message = in error, be informed that any use of the content hereof is prohibited. Ple= ase return it immediately to the sender and delete the message. Should you = have any questions, please contact us by replying to webmaster@telecomitali= a.it. Thank you www.telecomitalia.it -------------------------------------------------------------------- = _______________________________________________ Autoconf mailing list Autoconf@ietf.org http://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Wed Feb 20 09:50:51 2008 Return-Path: X-Original-To: ietfarch-autoconf-archive@core3.amsl.com Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1DDEF28C972; Wed, 20 Feb 2008 09:50:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.664 X-Spam-Level: X-Spam-Status: No, score=0.664 tagged_above=-999 required=5 tests=[AWL=-1.195, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_21=0.6, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rzlGmJe7xQuW; Wed, 20 Feb 2008 09:50:50 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D0AA828C95D; Wed, 20 Feb 2008 09:50:48 -0800 (PST) X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C6C3728C211 for ; Wed, 20 Feb 2008 09:50:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GCbCprBiXyHm for ; Wed, 20 Feb 2008 09:50:46 -0800 (PST) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 13AFA28C911 for ; Wed, 20 Feb 2008 09:50:44 -0800 (PST) Received: from [163.117.139.72] (acorde.it.uc3m.es [163.117.139.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp02.uc3m.es (Postfix) with ESMTP id 5998E31C89A; Wed, 20 Feb 2008 18:50:40 +0100 (CET) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Simone Ruffino In-Reply-To: <47BC649A.3000202@telecomitalia.it> References: <47AAC029.8030908@dif.um.es> <1203522837.4276.74.camel@localhost> <47BC57A6.9030004@telecomitalia.it> <200802201802.23166.fjrm@dif.um.es> <47BC649A.3000202@telecomitalia.it> Organization: Universidad Carlos III de Madrid Date: Wed, 20 Feb 2008 18:50:42 +0100 Message-Id: <1203529842.4276.108.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 Cc: autoconf@ietf.org Subject: Re: [Autoconf] AUTOCONF Problem Statement: reviews needed. X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0177238092==" Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org --===============0177238092== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-ZXt0uoS5T+T83/N28xV7" --=-ZXt0uoS5T+T83/N28xV7 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Hi Simone, On mi=E9, 2008-02-20 at 18:34 +0100, Simone Ruffino wrote: > Hi Francisco, > Please see below. > Simone >=20 > Francisco J. Ros wrote: > > Hi Simone, all, > >=20 > > I've been following the discussion and tend to agree with Carlos. In my= =20 > > opinion, the MNR can configure as many prefixes as are available for ea= ch of=20 > > its interfaces. Then, the selection of one border router or another acc= ording=20 > > to a given metric (e.g. hop count) is a routing issue not related to=20 > > autoconf.=20 >=20 > Well, every time I raise this point we end up here ..:). > But, as a matter of fact: > - performance degradation caused by prefix choice and > - ingress filtering > are not tackled anywhere. >=20 > The source address selection policy should then take into account > > the border router which is being used in order to avoid the ingress fil= tering=20 > > issue. >=20 > Well, yes, but it's not that easy...:) > Because, if you're doing that and the border routers change frequently,=20 > applications are degraded as well, even if a session continuity solution=20 > like MIPv6 is in place. >=20 > >=20 > > I don't think the P-S is the right place to discuss this, although I do= n't=20 > > have a strong feeling on this either. >=20 > Although my personal opinion is that they could be mentioned in the P-S,=20 > right now, as an author, I feel much more important to get consensus on=20 > what are the _basic_ problems to solve. > I.e., if DHCP does not work, nothing else works.... Agree on the latter :-) >=20 > >=20 > > Regards, > > fran > >=20 > > On Wednesday 20 February 2008 17:39, Simone Ruffino wrote: > > > >> Carlos Jes=FAs Bernardos Cano wrote: > >>> [Carlos] I think this problem/scenario also happens in non-MANET > >>> scenarios (it's a multihoming issue) and it is not particular of IP > >>> address autoconfiguration. I agree is a very interesting issue, but I= 'm > >>> not sure the IP autoconf PS is the right place. The only specific iss= ue > >>> I see there is how to detect that an initially multihomed subordinate > >>> MANET gets disconnected from one of the external networks it was > >>> attached to, and even in this case, this also occurs in non-MANETs. > >> I respectfully don't agree. > >> MANET has specific problems, deriving from the fact that routers can > >> dynamically change topology (which usually does not happen in wired > >> networks....): the choice of a random prefix (from a pool of available > >> prefixes) by an MNR could, one minute later, cause severe performance > >> degradation to hosts. > >> This of course cannot be avoided in single-border-router scenarios, bu= t, > >> if multiple border routers are available, this CAN be avoided, with > >> proper prefix selection mechanisms. > >> > >> So, I think that (as with DHCP) the question is: are existing solution= s > >> able to cope with specific MANET environment, ... including here the > >> fact that there is a Big difference between a three-hop path and a > >> four-hop path .... :) ? > >> > >=20 > -------------------------------------------------------------------- >=20 > CONFIDENTIALITY NOTICE >=20 > This message and its attachments are addressed solely to the persons abov= e and may contain confidential information. If you have received the messag= e in error, be informed that any use of the content hereof is prohibited. P= lease return it immediately to the sender and delete the message. Should yo= u have any questions, please contact us by replying to webmaster@telecomita= lia.it. >=20 > Thank you >=20 > www.telecomitalia.it >=20 > -------------------------------------------------------------------- > =20 --=20 =A1AS=D3CIATE! Gratis para estudiantes http://www.telematica.ws Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ WEEDEV 2008: 1st Workshop on Experimental Evaluation and Deployment Experiences on Vehicular networks http://www.weedev.org/ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ --=-ZXt0uoS5T+T83/N28xV7 Content-Type: application/pgp-signature; name=signature.asc Content-Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBHvGhyNdy6TdFwT2cRAnDfAKDlvSYq558nhUzTw4Lyum2xdXnmmQCfUKBq KcwjCl9LHN94X6VlqQ10VKA= =cKnp -----END PGP SIGNATURE----- --=-ZXt0uoS5T+T83/N28xV7-- --===============0177238092== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Autoconf mailing list Autoconf@ietf.org http://www.ietf.org/mailman/listinfo/autoconf --===============0177238092==-- From autoconf-bounces@ietf.org Wed Feb 20 10:36:27 2008 Return-Path: X-Original-To: ietfarch-autoconf-archive@core3.amsl.com Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6EADB28C459; Wed, 20 Feb 2008 10:36:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.697 X-Spam-Level: X-Spam-Status: No, score=-0.697 tagged_above=-999 required=5 tests=[AWL=-0.260, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uJg1XX1Nc5+r; Wed, 20 Feb 2008 10:36:22 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 21FD43A6A3C; Wed, 20 Feb 2008 10:36:22 -0800 (PST) X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0A403A69A2 for ; Wed, 20 Feb 2008 10:36:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id esBcblzGgtvY for ; Wed, 20 Feb 2008 10:36:19 -0800 (PST) Received: from hpsmtp-eml20.kpnxchange.com (hpsmtp-eml20.kpnxchange.com [213.75.38.85]) by core3.amsl.com (Postfix) with ESMTP id 6DAE63A6A3C for ; Wed, 20 Feb 2008 10:36:18 -0800 (PST) Received: from hpsmtp-eml01.kpnxchange.com ([213.75.38.101]) by hpsmtp-eml20.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Feb 2008 19:36:15 +0100 Received: from M90Teco ([86.83.9.22]) by hpsmtp-eml01.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Feb 2008 19:36:14 +0100 From: "Teco Boot" To: , "'Simone Ruffino'" References: <47AAC029.8030908@dif.um.es> <1203522837.4276.74.camel@localhost> <47BC57A6.9030004@telecomitalia.it> <200802201802.23166.fjrm@dif.um.es> <47BC649A.3000202@telecomitalia.it> <1203529842.4276.108.camel@localhost> In-Reply-To: <1203529842.4276.108.camel@localhost> Date: Wed, 20 Feb 2008 19:36:01 +0100 Message-ID: <006801c873ef$73762640$5a6272c0$@nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 thread-index: Achz6YsyAMsrl4mvRYSvSz8sZw+qDgABTbNQ Content-Language: nl X-OriginalArrivalTime: 20 Feb 2008 18:36:14.0589 (UTC) FILETIME=[791582D0:01C873EF] Cc: autoconf@ietf.org Subject: Re: [Autoconf] AUTOCONF Problem Statement: reviews needed. X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org > > I.e., if DHCP does not work, nothing else works.... > > Agree on the latter :-) > Why not giving SLAAC a chance? I think SLAAC and ULA fits MANET Autoconf requirements pretty well. And there are other options. So I don't agree at all :-) Cheers, Teco. _______________________________________________ Autoconf mailing list Autoconf@ietf.org http://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Wed Feb 20 10:50:15 2008 Return-Path: X-Original-To: ietfarch-autoconf-archive@core3.amsl.com Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D96AE28C9A3; Wed, 20 Feb 2008 10:50:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.069 X-Spam-Level: X-Spam-Status: No, score=-0.069 tagged_above=-999 required=5 tests=[AWL=-0.532, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_21=0.6, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hw2FNH5dqxlS; Wed, 20 Feb 2008 10:50:15 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 527E83A6E83; Wed, 20 Feb 2008 10:49:45 -0800 (PST) X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 042DA3A6E81 for ; Wed, 20 Feb 2008 10:49:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZyjdyWc6592l for ; Wed, 20 Feb 2008 10:49:44 -0800 (PST) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 7A70D28C1EC for ; Wed, 20 Feb 2008 10:49:19 -0800 (PST) Received: from [163.117.139.72] (acorde.it.uc3m.es [163.117.139.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp01.uc3m.es (Postfix) with ESMTP id A22AD3CEE40; Wed, 20 Feb 2008 19:49:14 +0100 (CET) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Teco Boot In-Reply-To: <006801c873ef$73762640$5a6272c0$@nl> References: <47AAC029.8030908@dif.um.es> <1203522837.4276.74.camel@localhost> <47BC57A6.9030004@telecomitalia.it> <2 00802201802.23166.fjrm@dif.um.es> <47BC649A.3000202@telecomitalia.it> <1203529842.4276.108.camel@localhost> <006801c873ef$73762640$5a6272c0$@nl> Organization: Universidad Carlos III de Madrid Date: Wed, 20 Feb 2008 19:49:16 +0100 Message-Id: <1203533356.4276.152.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 Cc: autoconf@ietf.org Subject: Re: [Autoconf] AUTOCONF Problem Statement: reviews needed. X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1031306654==" Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org --===============1031306654== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-jT/9ye6c1yGq0XSojpfx" --=-jT/9ye6c1yGq0XSojpfx Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Hi Teco, I meant "agree on that the most important thing is to get consensus on what are the _basic_ problems to solve.", nothing about the use of DCHP/SLAAC,... Sorry for the misunderstanding. Regards, Carlos On mi=E9, 2008-02-20 at 19:36 +0100, Teco Boot wrote: > > > I.e., if DHCP does not work, nothing else works.... > >=20 > > Agree on the latter :-) > >=20 > Why not giving SLAAC a chance? I think SLAAC and ULA fits MANET Autoconf > requirements pretty well. > And there are other options. So I don't agree at all :-) > Cheers, Teco. >=20 >=20 --=20 =A1AS=D3CIATE! Gratis para estudiantes http://www.telematica.ws Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ WEEDEV 2008: 1st Workshop on Experimental Evaluation and Deployment Experiences on Vehicular networks http://www.weedev.org/ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ --=-jT/9ye6c1yGq0XSojpfx Content-Type: application/pgp-signature; name=signature.asc Content-Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBHvHYsNdy6TdFwT2cRArzOAKCc5sc2JvR9P/PffoeBCrWJuWrNEgCeMTYO 0k+NKLso+caPD9Pwurtx+Yg= =wHYi -----END PGP SIGNATURE----- --=-jT/9ye6c1yGq0XSojpfx-- --===============1031306654== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Autoconf mailing list Autoconf@ietf.org http://www.ietf.org/mailman/listinfo/autoconf --===============1031306654==-- From autoconf-bounces@ietf.org Wed Feb 20 13:29:56 2008 Return-Path: X-Original-To: ietfarch-autoconf-archive@core3.amsl.com Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7386C28C0D9; Wed, 20 Feb 2008 13:29:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.725 X-Spam-Level: X-Spam-Status: No, score=0.725 tagged_above=-999 required=5 tests=[AWL=-0.438, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=1, J_CHICKENPOX_31=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iW-oE6CLa0qW; Wed, 20 Feb 2008 13:29:55 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D92A28C642; Wed, 20 Feb 2008 13:29:55 -0800 (PST) X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD4A228C773 for ; Wed, 20 Feb 2008 13:29:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id twHmF-cxFlri for ; Wed, 20 Feb 2008 13:29:52 -0800 (PST) Received: from hs-out-0708.google.com (hs-out-0708.google.com [64.233.178.240]) by core3.amsl.com (Postfix) with ESMTP id 5CB9628C642 for ; Wed, 20 Feb 2008 13:29:52 -0800 (PST) Received: by hs-out-0708.google.com with SMTP id 54so2463354hsz.5 for ; Wed, 20 Feb 2008 13:29:44 -0800 (PST) Received: by 10.78.81.20 with SMTP id e20mr14383796hub.37.1203542982895; Wed, 20 Feb 2008 13:29:42 -0800 (PST) Received: by 10.78.40.16 with HTTP; Wed, 20 Feb 2008 13:29:42 -0800 (PST) Message-ID: Date: Wed, 20 Feb 2008 22:29:42 +0100 From: "Hasnaa Moustafa" To: autoconf@ietf.org In-Reply-To: MIME-Version: 1.0 References: Subject: Re: [Autoconf] Autoconf Digest, Vol 25, Issue 8 X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0040687812==" Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org --===============0040687812== Content-Type: multipart/alternative; boundary="----=_Part_2049_32781394.1203542982890" ------=_Part_2049_32781394.1203542982890 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, I also agree that the issue of the border router choice (although it's importance) should not be in the PS draft. Kind Regards, Hassnaa ------------------------------ Date: Wed, 20 Feb 2008 18:02:23 +0100 From: "Francisco J. Ros" Subject: Re: [Autoconf] AUTOCONF Problem Statement: reviews needed. To: autoconf@ietf.org Message-ID: <200802201802.23166.fjrm@dif.um.es> Content-Type: text/plain; charset="iso-8859-1" Hi Simone, all, I've been following the discussion and tend to agree with Carlos. In my opinion, the MNR can configure as many prefixes as are available for each of its interfaces. Then, the selection of one border router or another according to a given metric (e.g. hop count) is a routing issue not related to autoconf. The source address selection policy should then take into account the border router which is being used in order to avoid the ingress filtering issue. I don't think the P-S is the right place to discuss this, although I don't have a strong feeling on this either. Regards, fran On Wednesday 20 February 2008 17:39, Simone Ruffino wrote: > Carlos Jes?s Bernardos Cano wrote: > > [Carlos] I think this problem/scenario also happens in non-MANET > > scenarios (it's a multihoming issue) and it is not particular of IP > > address autoconfiguration. I agree is a very interesting issue, but I'm > > not sure the IP autoconf PS is the right place. The only specific issue > > I see there is how to detect that an initially multihomed subordinate > > MANET gets disconnected from one of the external networks it was > > attached to, and even in this case, this also occurs in non-MANETs. > > I respectfully don't agree. > MANET has specific problems, deriving from the fact that routers can > dynamically change topology (which usually does not happen in wired > networks....): the choice of a random prefix (from a pool of available > prefixes) by an MNR could, one minute later, cause severe performance > degradation to hosts. > This of course cannot be avoided in single-border-router scenarios, but, > if multiple border routers are available, this CAN be avoided, with > proper prefix selection mechanisms. > > So, I think that (as with DHCP) the question is: are existing solutions > able to cope with specific MANET environment, ... including here the > fact that there is a Big difference between a three-hop path and a > four-hop path .... :) ? > -- Francisco J. Ros, Ph.D. Student Dept. of Information and Communications Engineering University of Murcia, Murcia (Spain) http://masimum.inf.um.es/fjrm/ ------=_Part_2049_32781394.1203542982890 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Hi,
 
I also agree that the issue of the border router choice (although it's importance) should not be in the PS draft.
 
Kind Regards,
Hassnaa

------------------------------
Date: Wed, 20 Feb 2008 18:02:23 +0100
From: "Francisco J. Ros" <fjrm@dif.um.es>
Subject: Re: [Autoconf] AUTOCONF Problem Statement: reviews needed.
To: autoconf@ietf.org
Message-ID: <200802201802.23166.fjrm@dif.um.es>
Content-Type: text/plain;  charset="iso-8859-1"

Hi Simone, all,

I've been following the discussion and tend to agree with Carlos. In my
opinion, the MNR can configure as many prefixes as are available for each of
its interfaces. Then, the selection of one border router or another according
to a given metric (e.g. hop count) is a routing issue not related to
autoconf. The source address selection policy should then take into account
the border router which is being used in order to avoid the ingress filtering
issue.

I don't think the P-S is the right place to discuss this, although I don't
have a strong feeling on this either.

Regards,
fran

On Wednesday 20 February 2008 17:39, Simone Ruffino wrote:
<snip>
> Carlos Jes?s Bernardos Cano wrote:
> > [Carlos] I think this problem/scenario also happens in non-MANET
> > scenarios (it's a multihoming issue) and it is not particular of IP
> > address autoconfiguration. I agree is a very interesting issue, but I'm
> > not sure the IP autoconf PS is the right place. The only specific issue
> > I see there is how to detect that an initially multihomed subordinate
> > MANET gets disconnected from one of the external networks it was
> > attached to, and even in this case, this also occurs in non-MANETs.
>
> I respectfully don't agree.
> MANET has specific problems, deriving from the fact that routers can
> dynamically change topology (which usually does not happen in wired
> networks....): the choice of a random prefix (from a pool of available
> prefixes) by an MNR could, one minute later, cause severe performance
> degradation to hosts.
> This of course cannot be avoided in single-border-router scenarios, but,
> if multiple border routers are available, this CAN be avoided, with
> proper prefix selection mechanisms.
>
> So, I think that (as with DHCP) the question is: are existing solutions
> able to cope with specific MANET environment, ... including here the
> fact that there is a Big difference between a three-hop path and a
> four-hop path .... :) ?
>

--
Francisco J. Ros, Ph.D. Student
Dept. of Information and Communications Engineering
University of Murcia, Murcia (Spain)

http://masimum.inf.um.es/fjrm/

 
------=_Part_2049_32781394.1203542982890-- --===============0040687812== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Autoconf mailing list Autoconf@ietf.org http://www.ietf.org/mailman/listinfo/autoconf --===============0040687812==-- From autoconf-bounces@ietf.org Wed Feb 20 23:52:25 2008 Return-Path: X-Original-To: ietfarch-autoconf-archive@core3.amsl.com Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B1A828C997; Wed, 20 Feb 2008 23:52:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.413 X-Spam-Level: X-Spam-Status: No, score=-0.413 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mze-yAXVf+dt; Wed, 20 Feb 2008 23:52:24 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA50928C9A1; Wed, 20 Feb 2008 23:52:23 -0800 (PST) X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2EEFD28C7A2 for ; Wed, 20 Feb 2008 23:52:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 043KtMymRjkW for ; Wed, 20 Feb 2008 23:52:19 -0800 (PST) Received: from maild.telecomitalia.it (maild.telecomitalia.it [156.54.233.30]) by core3.amsl.com (Postfix) with ESMTP id 99C6C28C9B3 for ; Wed, 20 Feb 2008 23:52:16 -0800 (PST) thread-index: Ach0Xqp0Pp1AogPDTrKiSXfWKGdd7A== Received: from ptpxch007ba020.idc.cww.telecomitalia.it ([156.54.240.50]) by maild.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Feb 2008 08:52:11 +0100 Received: from ptpxch005ba020.idc.cww.telecomitalia.it ([156.54.240.44]) by ptpxch007ba020.idc.cww.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Feb 2008 08:52:10 +0100 Received: from [10.229.4.58] ([10.229.4.58]) by ptpxch005ba020.idc.cww.telecomitalia.it over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Feb 2008 08:52:10 +0100 Content-Class: urn:content-classes:message Importance: normal Priority: normal x-mimeole: Produced By Microsoft MimeOLE V6.00.3790.2992 Message-ID: <47BD2D25.10007@telecomitalia.it> Date: Thu, 21 Feb 2008 08:49:57 +0100 From: "Simone Ruffino" User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: References: <47AAC029.8030908@dif.um.es> <1203522837.4276.74.camel@localhost> <47BC57A6.9030004@telecomitalia.it> <2 00802201802.23166.fjrm@dif.um.es> <47BC649A.3000202@telecomitalia.it> <1203529842.4276.108.camel@localhost> <006801c873ef$73762640$5a6272c0$@nl> <1203533356.4276.152.camel@localhost> In-Reply-To: <1203533356.4276.152.camel@localhost> X-OriginalArrivalTime: 21 Feb 2008 07:52:10.0250 (UTC) FILETIME=[A9AD16A0:01C8745E] Cc: autoconf@ietf.org Subject: Re: [Autoconf] AUTOCONF Problem Statement: reviews needed. X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Yes, thanks Carlos, this is what I meant too (DHCP was more like an example). Simone Carlos Jes=FAs Bernardos Cano wrote: > Hi Teco, > = > I meant "agree on that the most important thing is to get consensus on > what are the _basic_ problems to solve.", nothing about the use of > DCHP/SLAAC,... > = > Sorry for the misunderstanding. > = > Regards, > = > Carlos > = > On mi=E9, 2008-02-20 at 19:36 +0100, Teco Boot wrote: >>>> I.e., if DHCP does not work, nothing else works.... >>> Agree on the latter :-) >>> >> Why not giving SLAAC a chance? I think SLAAC and ULA fits MANET Autoconf >> requirements pretty well. >> And there are other options. So I don't agree at all :-) >> Cheers, Teco. >> >> -------------------------------------------------------------------- CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above = and may contain confidential information. If you have received the message = in error, be informed that any use of the content hereof is prohibited. Ple= ase return it immediately to the sender and delete the message. Should you = have any questions, please contact us by replying to webmaster@telecomitali= a.it. Thank you www.telecomitalia.it -------------------------------------------------------------------- = _______________________________________________ Autoconf mailing list Autoconf@ietf.org http://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Thu Feb 21 00:55:34 2008 Return-Path: X-Original-To: ietfarch-autoconf-archive@core3.amsl.com Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 89C2C28C9C2; Thu, 21 Feb 2008 00:55:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[AWL=-2.584, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=1, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X+W85levZ484; Thu, 21 Feb 2008 00:55:33 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C076A28C9D4; Thu, 21 Feb 2008 00:55:33 -0800 (PST) X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 74AF128C9D4 for ; Thu, 21 Feb 2008 00:55:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LZL0dT3IVEd2 for ; Thu, 21 Feb 2008 00:55:31 -0800 (PST) Received: from mailout2.samsung.com (mailout2.samsung.com [203.254.224.25]) by core3.amsl.com (Postfix) with ESMTP id 64C1328C9C2 for ; Thu, 21 Feb 2008 00:55:26 -0800 (PST) Received: from epmmp2 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0JWK005B3ZG5NJ@mailout2.samsung.com> for autoconf@ietf.org; Thu, 21 Feb 2008 17:55:17 +0900 (KST) Received: from Shubhranshu ([107.108.82.43]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0JWK0095NZG34X@mmp2.samsung.com> for autoconf@ietf.org; Thu, 21 Feb 2008 17:55:17 +0900 (KST) Date: Thu, 21 Feb 2008 14:28:10 +0530 From: Shubhranshu To: autoconf@ietf.org Message-id: <008f01c87467$e3316da0$2b526c6b@sisodomain.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-Priority: 3 X-MSMail-priority: Normal Subject: [Autoconf] IETF-71 Autoconf WG Meeting Agenda X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1659120478==" Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org This is a multi-part message in MIME format. --===============1659120478== Content-type: multipart/alternative; boundary="Boundary_(ID_1JKbruXOi1z0KV0KDzL0Xw)" This is a multi-part message in MIME format. --Boundary_(ID_1JKbruXOi1z0KV0KDzL0Xw) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT If you have any agenda item for the upcoming Autoconf WG meeting then please send them to the chairs or to the list. Autoconf WG session is tentatively scheduled for Tuesday, https://datatracker.ietf.org/meeting/71/agenda.html : AUTOCONF WG Session 1 (2 hours) Tuesday, March 11, 2008 Afternoon Session I 1300-1500, Breakoout Room - Shubhranshu --Boundary_(ID_1JKbruXOi1z0KV0KDzL0Xw) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: 7BIT
If you have any agenda item for the upcoming Autoconf WG meeting
then please send them to the chairs or to the list.

Autoconf WG session is tentatively scheduled for Tuesday,
https://datatracker.ietf.org/meeting/71/agenda.html :

AUTOCONF WG Session 1 (2 hours)
Tuesday, March 11, 2008
Afternoon Session I  1300-1500, Breakoout Room 

- Shubhranshu
--Boundary_(ID_1JKbruXOi1z0KV0KDzL0Xw)-- --===============1659120478== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Autoconf mailing list Autoconf@ietf.org http://www.ietf.org/mailman/listinfo/autoconf --===============1659120478==-- From autoconf-bounces@ietf.org Thu Feb 21 01:48:43 2008 Return-Path: X-Original-To: ietfarch-autoconf-archive@core3.amsl.com Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4229A28CA26; Thu, 21 Feb 2008 01:48:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.711 X-Spam-Level: X-Spam-Status: No, score=-0.711 tagged_above=-999 required=5 tests=[AWL=-0.274, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xug2FBvGkuH9; Thu, 21 Feb 2008 01:48:42 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7EFFE28CA01; Thu, 21 Feb 2008 01:48:42 -0800 (PST) X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF06828CA01 for ; Thu, 21 Feb 2008 01:48:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gALmY65UCvA7 for ; Thu, 21 Feb 2008 01:48:40 -0800 (PST) Received: from hpsmtp-eml15.kpnxchange.com (hpsmtp-eml15.kpnxchange.com [213.75.38.115]) by core3.amsl.com (Postfix) with ESMTP id A2BBA28C806 for ; Thu, 21 Feb 2008 01:48:39 -0800 (PST) Received: from hpsmtp-eml10.kpnxchange.com ([213.75.38.110]) by hpsmtp-eml15.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Feb 2008 10:48:36 +0100 Received: from M90Teco ([86.83.9.22]) by hpsmtp-eml10.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Feb 2008 10:48:35 +0100 From: "Teco Boot" To: "'Emmanuel Baccelli'" , "'Thomas Clausen'" , "'Shubhranshu'" References: <47AAC029.8030908@dif.um.es> <47B9A5BF.9060106@inria.fr> <000001c8726b$9d66b440$d8341cc0$@nl> <47BAC6D1.7060100@inria.fr> In-Reply-To: Date: Thu, 21 Feb 2008 10:48:26 +0100 Message-ID: <00a801c8746e$e835e590$b8a1b0b0$@nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 thread-index: Achy/v/dZIgLPcs7QXqpav9UDnjR1QAnn4IwADL61LA= Content-Language: nl X-OriginalArrivalTime: 21 Feb 2008 09:48:35.0135 (UTC) FILETIME=[ECFDF4F0:01C8746E] Cc: autoconf@ietf.org Subject: Re: [Autoconf] AUTOCONF Problem Statement: reviews needed. X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Hi Emmanuel, WG chairs, I posted some of my "additional" thoughts on the PS document. There was some discussion, maybe we can come up with an outcome: 1) Need for active DAD. Not that much response yet. It is a comment on the Autoconf PS text. Add a single line at the end of 5.2.2? Proposed text: > Also the Duplicate Address Detection signalling could > introduce unacceptable overhead. Text is in line with text above in section 5.2.2 and in line with RFC4862. 2) Multi-homed subordinate MANETs and source address selection and session continuity. This is an important real-world problem that must be addressed somewhere. However the problem is a result of what Autoconf and MANET achieves, so input for a follow-up. I can live with an outcome that the Autoconf WG produces a separate document describing this scenario and introduced problem(s). I can present the scenario and the introduced problem(s) in Philly. I did in Chicago, but there were few seconds left for my presentation, and I think many of us may not understood the scenario and the introduced problem(s). What do you think? 3) Authorization to use access to external network. This is also an important real-world problem that must be addressed somewhere. Similar to problem 2, it is a problem that is introduced as a result of what Autoconf and MANET achieves. We could describe this problem in more detail in the scenario document I suggested above. Can the WG chairs can react on my proposal? Opinion from ADs? Regards, Teco _______________________________________________ Autoconf mailing list Autoconf@ietf.org http://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Thu Feb 21 02:13:21 2008 Return-Path: X-Original-To: ietfarch-autoconf-archive@core3.amsl.com Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 723D428CA72; Thu, 21 Feb 2008 02:13:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.309 X-Spam-Level: X-Spam-Status: No, score=-0.309 tagged_above=-999 required=5 tests=[AWL=-0.222, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_FR=0.35, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00iAoQ9U2aNd; Thu, 21 Feb 2008 02:13:20 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9965628CA3C; Thu, 21 Feb 2008 02:13:20 -0800 (PST) X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2231428CA23 for ; Thu, 21 Feb 2008 02:13:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b9mqYE9rJwRm for ; Thu, 21 Feb 2008 02:13:19 -0800 (PST) Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by core3.amsl.com (Postfix) with ESMTP id CB96D28C9AE for ; Thu, 21 Feb 2008 02:13:18 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.25,385,1199660400"; d="scan'208";a="22861498" Received: from ras75-3-82-226-221-97.fbx.proxad.net (HELO BoolfightMaN-Laptop.local) ([82.226.221.97]) by mail4-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 21 Feb 2008 11:13:13 +0100 Message-ID: <47BD4EB8.4040503@inria.fr> Date: Thu, 21 Feb 2008 11:13:12 +0100 From: Emmanuel Baccelli User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: autoconf@ietf.org References: <47AAC029.8030908@dif.um.es> <47B9A5BF.9060106@inria.fr> <000001c8726b$9d66b440$d8341cc0$@nl> <47BAC6D1.7060100@inria.fr> <00a801c8746e$e835e590$b8a1b0b0$@nl> In-Reply-To: <00a801c8746e$e835e590$b8a1b0b0$@nl> Subject: Re: [Autoconf] AUTOCONF Problem Statement: reviews needed. X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Hi Teco, Teco Boot a =E9crit : > Hi Emmanuel, WG chairs, > = > I posted some of my "additional" thoughts on the PS document. There was s= ome > discussion, maybe we can come up with an outcome: > = > 1) Need for active DAD. > Not that much response yet. It is a comment on the Autoconf PS text. Add a > single line at the end of 5.2.2? > Proposed text: >> Also the Duplicate Address Detection signalling could = >> introduce unacceptable overhead. > Text is in line with text above in section 5.2.2 and in line with RFC4862. > = I guess your argument basically says "NDP is not optimized", but it does = not say: "NDP does not work". I agree you have a point, but for now the = document concentrates on why "NDP does not work", and it is explained in = section 5.2.2. Furthermore, in section 6.1, solutions requirements (i.e. R06) state = that "solutions must achieve low overhead". So I guess that your concern = is covered anyways. Do you agree? > 2) Multi-homed subordinate MANETs and source address selection and session > continuity. > This is an important real-world problem that must be addressed somewhere. > However the problem is a result of what Autoconf and MANET achieves, so > input for a follow-up. I can live with an outcome that the Autoconf WG > produces a separate document describing this scenario and introduced > problem(s). I can present the scenario and the introduced problem(s) in > Philly. I did in Chicago, but there were few seconds left for my > presentation, and I think many of us may not understood the scenario and = the > introduced problem(s). > What do you think? In section 6.1., solutions requirements (i.e. R11) state that "solutions = should work in MANETs connected to external network(s), via multiple = border routers." Does this take into account your concern? If not, how = do you suggest we alter this requirement to take it into account? > 3) Authorization to use access to external network. > This is also an important real-world problem that must be addressed > somewhere. Similar to problem 2, it is a problem that is introduced as a > result of what Autoconf and MANET achieves. We could describe this problem > in more detail in the scenario document I suggested above. > = Again, do you think R11 covers this? Or how do you suggest we alter it? Emmanuel > Can the WG chairs can react on my proposal? > Opinion from ADs? > = > Regards, Teco > = > = > = _______________________________________________ Autoconf mailing list Autoconf@ietf.org http://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Thu Feb 21 03:13:33 2008 Return-Path: X-Original-To: ietfarch-autoconf-archive@core3.amsl.com Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9355228C460; Thu, 21 Feb 2008 03:13:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.694 X-Spam-Level: X-Spam-Status: No, score=-0.694 tagged_above=-999 required=5 tests=[AWL=-0.257, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5w-8hUL1Xtpy; Thu, 21 Feb 2008 03:13:32 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9BD8B3A6AAB; Thu, 21 Feb 2008 03:13:32 -0800 (PST) X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC4BB3A6D96 for ; Thu, 21 Feb 2008 03:13:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BX2LFweE24by for ; Thu, 21 Feb 2008 03:13:29 -0800 (PST) Received: from hpsmtp-eml16.kpnxchange.com (hpsmtp-eml16.KPNXCHANGE.COM [213.75.38.116]) by core3.amsl.com (Postfix) with ESMTP id AE2B83A6AAB for ; Thu, 21 Feb 2008 03:13:28 -0800 (PST) Received: from hpsmtp-eml06.kpnxchange.com ([213.75.38.106]) by hpsmtp-eml16.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Feb 2008 12:13:22 +0100 Received: from M90Teco ([86.83.9.22]) by hpsmtp-eml06.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Feb 2008 12:13:22 +0100 From: "Teco Boot" To: "'Emmanuel Baccelli'" References: <47AAC029.8030908@dif.um.es> <47B9A5BF.9060106@inria.fr> <000001c8726b$9d66b440$d8341cc0$@nl> <47BAC6D1.7060100@inria.fr> <00a801c8746e$e835e590$b8a1b0b0$@nl> <47BD4EB8.4040503@inria.fr> In-Reply-To: <47BD4EB8.4040503@inria.fr> Date: Thu, 21 Feb 2008 12:13:14 +0100 Message-ID: <00b001c8747a$c06adc80$41409580$@nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 thread-index: Ach0cmM7uyN6oBOkTFmWCskUtjoi+AAAFNAQ Content-Language: nl X-OriginalArrivalTime: 21 Feb 2008 11:13:22.0596 (UTC) FILETIME=[C55AE640:01C8747A] Cc: autoconf@ietf.org Subject: Re: [Autoconf] AUTOCONF Problem Statement: reviews needed. X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Hi, Comments inline. Regards, Teco > -----Oorspronkelijk bericht----- > Van: autoconf-bounces@ietf.org [mailto:autoconf-bounces@ietf.org] > Namens Emmanuel Baccelli > Verzonden: donderdag 21 februari 2008 11:13 > Aan: autoconf@ietf.org > Onderwerp: Re: [Autoconf] AUTOCONF Problem Statement: reviews needed. > = > Hi Teco, > = > Teco Boot a =E9crit : > > Hi Emmanuel, WG chairs, > > > > I posted some of my "additional" thoughts on the PS document. There > was some > > discussion, maybe we can come up with an outcome: > > > > 1) Need for active DAD. > > Not that much response yet. It is a comment on the Autoconf PS text. > Add a > > single line at the end of 5.2.2? > > Proposed text: > >> Also the Duplicate Address Detection signalling could > >> introduce unacceptable overhead. > > Text is in line with text above in section 5.2.2 and in line with > RFC4862. > > > = > I guess your argument basically says "NDP is not optimized", but it > does > not say: "NDP does not work". I agree you have a point, but for now the > document concentrates on why "NDP does not work", and it is explained > in > section 5.2.2. > = > Furthermore, in section 6.1, solutions requirements (i.e. R06) state > that "solutions must achieve low overhead". So I guess that your > concern > is covered anyways. Do you agree? [Teco:] = R06 is OK, this req is important. The proposed text mentions a problem with usage of NDP DAD in a wireless network were overhead is a concern. The problem is directly related to NDP. Therefore I liked to mention this explicitly. > > 2) Multi-homed subordinate MANETs and source address selection and > session > > continuity. > > This is an important real-world problem that must be addressed > somewhere. > > However the problem is a result of what Autoconf and MANET achieves, > so > > input for a follow-up. I can live with an outcome that the Autoconf > WG > > produces a separate document describing this scenario and introduced > > problem(s). I can present the scenario and the introduced problem(s) > in > > Philly. I did in Chicago, but there were few seconds left for my > > presentation, and I think many of us may not understood the scenario > and the > > introduced problem(s). > > What do you think? > = > In section 6.1., solutions requirements (i.e. R11) state that > "solutions > should work in MANETs connected to external network(s), via multiple > border routers." Does this take into account your concern? If not, how > do you suggest we alter this requirement to take it into account? [Teco:] = Req11 is OK, but very general. And it is a should, not a must. Add R 11.1.? **> Solutions must circumvent problems with source address filtering = **> on ingress to external networks. The problems with multiple external networks are not described in current PS document. The discussion on ML made also clear the problem is not well understood. = I'll wait for a reaction from chairs on where to describe the problems. Simone mentioned that the performance degradation caused by non-optimal prefix choice is not tackled anywhere. Add R 11.2.? **> Solutions should select addresses and prefixes to optimize communication **> to external networks. > > 3) Authorization to use access to external network. > > This is also an important real-world problem that must be addressed > > somewhere. Similar to problem 2, it is a problem that is introduced > as a > > result of what Autoconf and MANET achieves. We could describe this > problem > > in more detail in the scenario document I suggested above. > > > = > Again, do you think R11 covers this? Or how do you suggest we alter it? [Teco:] = Here I don't think R 11 addresses the problem. Add R 11.3.? **> Solutions must comply with authorization mechanisms validating access to **> external networks. > = > Emmanuel > = > > Can the WG chairs can react on my proposal? > > Opinion from ADs? > > > > Regards, Teco > > > > > > > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > http://www.ietf.org/mailman/listinfo/autoconf _______________________________________________ Autoconf mailing list Autoconf@ietf.org http://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Thu Feb 21 07:23:38 2008 Return-Path: X-Original-To: ietfarch-autoconf-archive@core3.amsl.com Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0547A28CA59; Thu, 21 Feb 2008 07:23:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.408 X-Spam-Level: X-Spam-Status: No, score=0.408 tagged_above=-999 required=5 tests=[AWL=-0.155, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=1, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id skVNkdh3083X; Thu, 21 Feb 2008 07:23:36 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3ACD028C97F; Thu, 21 Feb 2008 07:23:33 -0800 (PST) X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 08F5C28C72F for ; Thu, 21 Feb 2008 07:23:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5zlu-n7GYuB4 for ; Thu, 21 Feb 2008 07:23:30 -0800 (PST) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.188]) by core3.amsl.com (Postfix) with ESMTP id E25BC28C962 for ; Thu, 21 Feb 2008 07:22:10 -0800 (PST) Received: by nf-out-0910.google.com with SMTP id d21so31677nfb.39 for ; Thu, 21 Feb 2008 07:22:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=ExNo3LP3FPGUYbkgXJbhtVPZ7w53PWu0OB2zqr5eDFU=; b=ew20AQjXFhMx12gvYkCxeaT7P1ReCeeMYNVGUYik7oi5t/mw9B2pqeRspLco9LaAKrs8psF550nkOv3K2eD9T8fqQBSStfEUVeTp0ls+gYEj9I6xRmnZYlggj58sfa1hlHsFqjLGSPXBFubAa1btnXVYc3PQ4DrzuaFzS3M/7SU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=AMLas3uQjyvboVW7qV76Img0Hv65M9KHd4as2EaXIsgLy/fdkrW0BcyUYrBLCaScdFVzzZ5Ao9d8Y8ZzpLV4/TlA6CcRMPbRUL8brCwUr9WoB2zNt99wwp+PzWUVOxSQglPjWgS/c+T/v5cw3HKj3hhn+Yqej40vMgwPFDJWnws= Received: by 10.78.161.4 with SMTP id j4mr15945974hue.25.1203607325730; Thu, 21 Feb 2008 07:22:05 -0800 (PST) Received: by 10.78.40.16 with HTTP; Thu, 21 Feb 2008 07:22:05 -0800 (PST) Message-ID: Date: Thu, 21 Feb 2008 16:22:05 +0100 From: "Hasnaa Moustafa" To: "Teco Boot" In-Reply-To: MIME-Version: 1.0 References: Cc: autoconf@ietf.org Subject: Re: [Autoconf] Autoconf Digest, Vol 25, Issue 10 X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0426913737==" Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org --===============0426913737== Content-Type: multipart/alternative; boundary="----=_Part_5652_7163774.1203607325721" ------=_Part_5652_7163774.1203607325721 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Teco, I agree with you on considering something about the authorization. You proposed in your mail below the following text to elaborate R11 " Solutions must comply with authorization mechanisms validating access to external networks.". IMHO, this fits more under R10 related to the security issue. What do you think of this text as R10.1 "Solutions must allow IP addresses/prefixes assignment to only authorized nodes"? And this requriement applies only when there is a connection with external networks (we do not need to mention that explicitly) since R14 says that the requirements applications are scenario specific. Kind Regards, Hassnaa ------------------------------ Date: Thu, 21 Feb 2008 12:13:14 +0100 From: "Teco Boot" Subject: Re: [Autoconf] AUTOCONF Problem Statement: reviews needed. To: "'Emmanuel Baccelli'" Cc: autoconf@ietf.org Message-ID: <00b001c8747a$c06adc80$41409580$@nl> Content-Type: text/plain; charset="iso-8859-1" Hi, Comments inline. Regards, Teco > -----Oorspronkelijk bericht----- > Van: autoconf-bounces@ietf.org [mailto:autoconf-bounces@ietf.org] > Namens Emmanuel Baccelli > Verzonden: donderdag 21 februari 2008 11:13 > Aan: autoconf@ietf.org > Onderwerp: Re: [Autoconf] AUTOCONF Problem Statement: reviews needed. > > Hi Teco, > > Teco Boot a ?crit : > > Hi Emmanuel, WG chairs, > > > > I posted some of my "additional" thoughts on the PS document. There > was some > > discussion, maybe we can come up with an outcome: > > > > 1) Need for active DAD. > > Not that much response yet. It is a comment on the Autoconf PS text. > Add a > > single line at the end of 5.2.2? > > Proposed text: > >> Also the Duplicate Address Detection signalling could > >> introduce unacceptable overhead. > > Text is in line with text above in section 5.2.2 and in line with > RFC4862. > > > > I guess your argument basically says "NDP is not optimized", but it > does > not say: "NDP does not work". I agree you have a point, but for now the > document concentrates on why "NDP does not work", and it is explained > in > section 5.2.2. > > Furthermore, in section 6.1, solutions requirements (i.e. R06) state > that "solutions must achieve low overhead". So I guess that your > concern > is covered anyways. Do you agree? [Teco:] R06 is OK, this req is important. The proposed text mentions a problem with usage of NDP DAD in a wireless network were overhead is a concern. The problem is directly related to NDP. Therefore I liked to mention this explicitly. > > 2) Multi-homed subordinate MANETs and source address selection and > session > > continuity. > > This is an important real-world problem that must be addressed > somewhere. > > However the problem is a result of what Autoconf and MANET achieves, > so > > input for a follow-up. I can live with an outcome that the Autoconf > WG > > produces a separate document describing this scenario and introduced > > problem(s). I can present the scenario and the introduced problem(s) > in > > Philly. I did in Chicago, but there were few seconds left for my > > presentation, and I think many of us may not understood the scenario > and the > > introduced problem(s). > > What do you think? > > In section 6.1., solutions requirements (i.e. R11) state that > "solutions > should work in MANETs connected to external network(s), via multiple > border routers." Does this take into account your concern? If not, how > do you suggest we alter this requirement to take it into account? [Teco:] Req11 is OK, but very general. And it is a should, not a must. Add R 11.1.? **> Solutions must circumvent problems with source address filtering **> on ingress to external networks. The problems with multiple external networks are not described in current PS document. The discussion on ML made also clear the problem is not well understood. I'll wait for a reaction from chairs on where to describe the problems. Simone mentioned that the performance degradation caused by non-optimal prefix choice is not tackled anywhere. Add R 11.2.? **> Solutions should select addresses and prefixes to optimize communication **> to external networks. > > 3) Authorization to use access to external network. > > This is also an important real-world problem that must be addressed > > somewhere. Similar to problem 2, it is a problem that is introduced > as a > > result of what Autoconf and MANET achieves. We could describe this > problem > > in more detail in the scenario document I suggested above. > > > > Again, do you think R11 covers this? Or how do you suggest we alter it? [Teco:] Here I don't think R 11 addresses the problem. Add R 11.3.? **> Solutions must comply with authorization mechanisms validating access to **> external networks. > > Emmanuel > > > Can the WG chairs can react on my proposal? > > Opinion from ADs? > > > > Regards, Teco > > > > > > > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > http://www.ietf.org/mailman/listinfo/autoconf ------------------------------ _______________________________________________ Autoconf mailing list Autoconf@ietf.org http://www.ietf.org/mailman/listinfo/autoconf End of Autoconf Digest, Vol 25, Issue 10 **************************************** ------=_Part_5652_7163774.1203607325721 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Hi Teco,
 
I agree with you on considering something about the authorization. You proposed in your mail below the following text to elaborate R11 " Solutions must comply with authorization mechanisms validating access to external networks.".
 
IMHO, this fits more under R10 related to the security issue. What do you think of this text as R10.1 "Solutions must allow IP addresses/prefixes assignment to only authorized nodes"? And this requriement applies only when there is a connection with external networks (we do not need to mention that explicitly) since R14 says that the requirements applications are scenario specific.
 
Kind Regards,
Hassnaa
------------------------------
Date: Thu, 21 Feb 2008 12:13:14 +0100
From: "Teco Boot" <teco@inf-net.nl>
Subject: Re: [Autoconf] AUTOCONF Problem Statement: reviews needed.
To: "'Emmanuel Baccelli'" <Emmanuel.Baccelli@inria.fr>
Cc: autoconf@ietf.org
Message-ID: <00b001c8747a$c06adc80$41409580$@nl>
Content-Type: text/plain;       charset="iso-8859-1"

Hi, Comments inline.
Regards, Teco

> -----Oorspronkelijk bericht-----
> Van: autoconf-bounces@ietf.org [mailto:autoconf-bounces@ietf.org]
> Namens Emmanuel Baccelli
> Verzonden: donderdag 21 februari 2008 11:13
> Aan: autoconf@ietf.org
> Onderwerp: Re: [Autoconf] AUTOCONF Problem Statement: reviews needed.
>
> Hi Teco,
>
> Teco Boot a ?crit :
> > Hi Emmanuel, WG chairs,
> >
> > I posted some of my "additional" thoughts on the PS document. There
> was some
> > discussion, maybe we can come up with an outcome:
> >
> > 1) Need for active DAD.
> > Not that much response yet. It is a comment on the Autoconf PS text.
> Add a
> > single line at the end of 5.2.2?
> > Proposed text:
> >>   Also the Duplicate Address Detection signalling could
> >>   introduce unacceptable overhead.
> > Text is in line with text above in section 5.2.2 and in line with
> RFC4862.
> >
>
> I guess your argument basically says "NDP is not optimized", but it
> does
> not say: "NDP does not work". I agree you have a point, but for now the
> document concentrates on why "NDP does not work", and it is explained
> in
> section 5.2.2.
>
> Furthermore, in section 6.1, solutions requirements (i.e. R06) state
> that "solutions must achieve low overhead". So I guess that your
> concern
> is covered anyways. Do you agree?
[Teco:]
R06 is OK, this req is important.
The proposed text mentions a problem with usage of NDP DAD in a wireless
network were overhead is a concern. The problem is directly related to NDP.
Therefore I liked to mention this explicitly.


> > 2) Multi-homed subordinate MANETs and source address selection and
> session
> > continuity.
> > This is an important real-world problem that must be addressed
> somewhere.
> > However the problem is a result of what Autoconf and MANET achieves,
> so
> > input for a follow-up. I can live with an outcome that the Autoconf
> WG
> > produces a separate document describing this scenario and introduced
> > problem(s). I can present the scenario and the introduced problem(s)
> in
> > Philly. I did in Chicago, but there were few seconds left for my
> > presentation, and I think many of us may not understood the scenario
> and the
> > introduced problem(s).
> > What do you think?
>
> In section 6.1., solutions requirements (i.e. R11) state that
> "solutions
> should work in MANETs connected to external network(s), via multiple
> border routers." Does this take into account your concern? If not, how
> do you suggest we alter this requirement to take it into account?
[Teco:]
Req11 is OK, but very general. And it is a should, not a must.
Add R 11.1.?
**> Solutions must circumvent problems with source address filtering
**> on ingress to external networks.
The problems with multiple external networks are not described in current PS
document. The discussion on ML made also clear the problem is not well
understood.
I'll wait for a reaction from chairs on where to describe the problems.

Simone mentioned that the performance degradation caused by non-optimal
prefix choice is not tackled anywhere.
Add R 11.2.?
**> Solutions should select addresses and prefixes to optimize communication
**> to external networks.


> > 3) Authorization to use access to external network.
> > This is also an important real-world problem that must be addressed
> > somewhere. Similar to problem 2, it is a problem that is introduced
> as a
> > result of what Autoconf and MANET achieves. We could describe this
> problem
> > in more detail in the scenario document I suggested above.
> >
>
> Again, do you think R11 covers this? Or how do you suggest we alter it?
[Teco:]
Here I don't think R 11 addresses the problem.
Add R 11.3.?
**> Solutions must comply with authorization mechanisms validating access to

**> external networks.


>
> Emmanuel
>
> > Can the WG chairs can react on my proposal?
> > Opinion from ADs?
> >
> > Regards, Teco
> >
> >
> >
> _______________________________________________
> Autoconf mailing list
> Autoconf@ietf.org
> http://www.ietf.org/mailman/listinfo/autoconf



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

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


End of Autoconf Digest, Vol 25, Issue 10
****************************************
 

------=_Part_5652_7163774.1203607325721-- --===============0426913737== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Autoconf mailing list Autoconf@ietf.org http://www.ietf.org/mailman/listinfo/autoconf --===============0426913737==-- From autoconf-bounces@ietf.org Thu Feb 21 07:39:36 2008 Return-Path: X-Original-To: ietfarch-autoconf-archive@core3.amsl.com Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0270F3A68ED; Thu, 21 Feb 2008 07:39:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.189 X-Spam-Level: X-Spam-Status: No, score=-0.189 tagged_above=-999 required=5 tests=[AWL=-0.752, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=1, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hNvt9oNkTV1Q; Thu, 21 Feb 2008 07:39:35 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 14C303A6E81; Thu, 21 Feb 2008 07:39:35 -0800 (PST) X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA0733A6D4C for ; Thu, 21 Feb 2008 07:39:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tMKyrYCDgrGI for ; Thu, 21 Feb 2008 07:39:33 -0800 (PST) Received: from hpsmtp-eml13.kpnxchange.com (hpsmtp-eml13.KPNXCHANGE.COM [213.75.38.113]) by core3.amsl.com (Postfix) with ESMTP id 80F1D3A6E81 for ; Thu, 21 Feb 2008 07:39:31 -0800 (PST) Received: from hpsmtp-eml01.kpnxchange.com ([213.75.38.101]) by hpsmtp-eml13.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Feb 2008 16:39:26 +0100 Received: from M90Teco ([86.83.9.22]) by hpsmtp-eml01.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Feb 2008 16:39:25 +0100 From: "Teco Boot" To: "'Hasnaa Moustafa'" References: In-Reply-To: Date: Thu, 21 Feb 2008 16:39:16 +0100 Message-ID: <00df01c8749f$eb119800$c134c800$@nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 thread-index: Ach0nYYv2gfX2CKyQhOMZwoQeQD/agAADKCA Content-Language: nl X-OriginalArrivalTime: 21 Feb 2008 15:39:26.0049 (UTC) FILETIME=[F0508510:01C8749F] Cc: autoconf@ietf.org Subject: Re: [Autoconf] AUTOCONF Problem Statement: reviews needed. X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1049486086==" Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Dit is een meerdelig bericht met een MIME-indeling. --===============1049486086== Content-Type: multipart/alternative; boundary="----=_NextPart_000_00E0_01C874A8.4CD60000" Content-Language: nl Dit is een meerdelig bericht met een MIME-indeling. ------=_NextPart_000_00E0_01C874A8.4CD60000 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Hassnaa, I think the section 7 security threats are different than authentication / authorization for access to external networks. And the problem we discuss right now is about assigning an address or prefix that is associated with an external network, but traffic to this external network could be blocked because the AAA procedure was not performed. For this reason, I prefer the requirement on R 11, which is about MANETs connected to external network(s). Secure communication within a MANET is a different problem. I am not sure what Autoconf WG should do at this moment. For example, protecting MANET Routing protocol is a task for MANET WG. Problems with SeND (used in an ad hoc network) could be a problem for Autoconf, if ND is to be used. Regards, Teco Van: Hasnaa Moustafa [mailto:hasnaa.moustafa@gmail.com] Verzonden: donderdag 21 februari 2008 16:22 Aan: Teco Boot CC: autoconf@ietf.org Onderwerp: Re: Autoconf Digest, Vol 25, Issue 10 Hi Teco, I agree with you on considering something about the authorization. You proposed in your mail below the following text to elaborate R11 " Solutions must comply with authorization mechanisms validating access to external networks.". IMHO, this fits more under R10 related to the security issue. What do you think of this text as R10.1 "Solutions must allow IP addresses/prefixes assignment to only authorized nodes"? And this requriement applies only when there is a connection with external networks (we do not need to mention that explicitly) since R14 says that the requirements applications are scenario specific. Kind Regards, Hassnaa ------=_NextPart_000_00E0_01C874A8.4CD60000 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Hassnaa,

 

I think the section 7 security threats are different than authentication / authorization for access to external = networks.

 

And the problem we discuss right now is about assigning = an address or prefix that is associated with an external network, but = traffic to this external network could be blocked because the AAA procedure was not performed. For this reason, I prefer the requirement on R 11, which is = about MANETs connected to external network(s).

 

Secure communication within a MANET is a different = problem. I am not sure what Autoconf WG should do at this moment. For example, = protecting MANET Routing protocol is a task for MANET WG. Problems with SeND (used in an = ad hoc network) could be a problem for Autoconf, if ND is to be used. =

 

Regards, Teco

 

 

Van:<= /b> = Hasnaa Moustafa [mailto:hasnaa.moustafa@gmail.com]
Verzonden: donderdag 21 februari 2008 16:22
Aan: Teco Boot
CC: autoconf@ietf.org
Onderwerp: Re: Autoconf Digest, Vol 25, Issue = 10

 

Hi Teco,

 

I agree with you on considering something = about the authorization. You proposed in your mail below the following text to = elaborate R11 " Solutions must comply with authorization mechanisms = validating access to external networks.".

 

IMHO, this fits more under R10 related to the = security issue. What do you think of this text as R10.1 "Solutions = must allow IP addresses/prefixes assignment to only authorized nodes"? = And this requriement applies only when there is a connection with external = networks (we do not need to mention that explicitly) since R14 says that the requirements applications are scenario specific.

 

Kind Regards,

Hassnaa

 

------=_NextPart_000_00E0_01C874A8.4CD60000-- --===============1049486086== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Autoconf mailing list Autoconf@ietf.org http://www.ietf.org/mailman/listinfo/autoconf --===============1049486086==-- From autoconf-bounces@ietf.org Thu Feb 21 10:09:02 2008 Return-Path: X-Original-To: ietfarch-autoconf-archive@core3.amsl.com Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0878A28CB11; Thu, 21 Feb 2008 10:09:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.614 X-Spam-Level: X-Spam-Status: No, score=-2.614 tagged_above=-999 required=5 tests=[AWL=-2.177, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lcVLsxp4HKre; Thu, 21 Feb 2008 10:09:00 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A33CE28CAF3; Thu, 21 Feb 2008 10:09:00 -0800 (PST) X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C85C28CA67 for ; Thu, 21 Feb 2008 10:08:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VbNwvzCwYdzh for ; Thu, 21 Feb 2008 10:08:53 -0800 (PST) Received: from mail153.messagelabs.com (mail153.messagelabs.com [216.82.253.51]) by core3.amsl.com (Postfix) with SMTP id 2122128CB09 for ; Thu, 21 Feb 2008 10:08:39 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-6.tower-153.messagelabs.com!1203617315!5964826!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [144.189.100.105] Received: (qmail 19572 invoked from network); 21 Feb 2008 18:08:35 -0000 Received: from motgate5.mot.com (HELO motgate5.mot.com) (144.189.100.105) by server-6.tower-153.messagelabs.com with SMTP; 21 Feb 2008 18:08:35 -0000 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate5.mot.com (8.12.11/Motorola) with ESMTP id m1LI8ZeA006033; Thu, 21 Feb 2008 11:08:35 -0700 (MST) Received: from az10vts04.mot.com (az10vts04.mot.com [10.64.251.245]) by az33exr03.mot.com (8.13.1/Vontu) with SMTP id m1LI8YDU018622; Thu, 21 Feb 2008 12:08:34 -0600 (CST) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id m1LI8WfJ018583; Thu, 21 Feb 2008 12:08:33 -0600 (CST) Message-ID: <47BDBE1F.1060201@gmail.com> Date: Thu, 21 Feb 2008 19:08:31 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Emmanuel Baccelli References: <47AAC029.8030908@dif.um.es> <47B9A5BF.9060106@inria.fr> In-Reply-To: <47B9A5BF.9060106@inria.fr> X-Antivirus: avast! (VPS 080220-0, 20/02/2008), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected Cc: autoconf@ietf.org Subject: Re: [Autoconf] AUTOCONF Problem Statement: reviews needed. X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Emmanuel Baccelli wrote: > Hi all, > > an updated version of the problem statement is available at the > following URL: > > http://wiki.emmanuelbaccelli.org/uploads/Ietf/draft-ietf-autoconf-problem-statement-04-PREVIEW-5.txt > > > > Your review is needed in order for the document to go forward. Please > provide your feedback this week -- the cut-off date being next > Monday. The document is short (20 pages), so don't refrain! Hi Manu, thanks for submitting this revised version. I'm personally still trying to identify the space into which this can become a problem and how a solution could fit some requirements. The draft is clearer than before. Stating DHCP/PD/NDP don't work when the connections break doesn't mean we have a problem, because nothing could ever work when connections break - AUTOCONF included. Stating they can be part of solution, but not everything in a solution - I agree with that part. Defining new 'disjoint prefixes' as opposed to discussing old 'unique prefixes' seems a more common denominator, I can grasp it, but I'm not sure the draft definition of disjoint prefixes was discussed and agreed already. PRobably yes. I will not oppose it. I have a marginal theoretical interest in disjoint and unique prefixes and other items affecting how routing may work, but that doesn't mean I oppose the way AUTOCONF choose to do it. Otherwise yes, the structure and reading of the entire draft makes sense to me. Alex > > Thanks, and see you soon in Philadelphia. > > Emmanuel _______________________________________________ Autoconf > mailing list Autoconf@ietf.org > http://www.ietf.org/mailman/listinfo/autoconf > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ Autoconf mailing list Autoconf@ietf.org http://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Thu Feb 21 10:27:34 2008 Return-Path: X-Original-To: ietfarch-autoconf-archive@core3.amsl.com Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 20E7A3A6D00; Thu, 21 Feb 2008 10:27:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.284 X-Spam-Level: X-Spam-Status: No, score=-0.284 tagged_above=-999 required=5 tests=[AWL=-0.197, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_FR=0.35, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y4+k2jjMbiyK; Thu, 21 Feb 2008 10:27:33 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8EC0D28C9D3; Thu, 21 Feb 2008 10:27:29 -0800 (PST) X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C093A28C9D3 for ; Thu, 21 Feb 2008 10:27:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mAc0fVKHA5mN for ; Thu, 21 Feb 2008 10:27:28 -0800 (PST) Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by core3.amsl.com (Postfix) with ESMTP id 371773A6B73 for ; Thu, 21 Feb 2008 10:26:58 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.25,387,1199660400"; d="scan'208";a="8398591" Received: from sphinx.lix.polytechnique.fr (HELO BoolfightMaN-Laptop.local) ([129.104.11.1]) by mail1-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 21 Feb 2008 19:26:53 +0100 Message-ID: <47BDC26C.8070708@inria.fr> Date: Thu, 21 Feb 2008 19:26:52 +0100 From: Emmanuel Baccelli User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: autoconf@ietf.org References: <47AAC029.8030908@dif.um.es> <47B9A5BF.9060106@inria.fr> <47BDBE1F.1060201@gmail.com> In-Reply-To: <47BDBE1F.1060201@gmail.com> Subject: Re: [Autoconf] AUTOCONF Problem Statement: reviews needed. X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Hi Alex, thanks for your feedback. I am happy that the draft seems to make more = sense to you ;) Please see my comments inline: Alexandru Petrescu a =E9crit : > Emmanuel Baccelli wrote: >> Hi all, >> >> an updated version of the problem statement is available at the = >> following URL: >> >> http://wiki.emmanuelbaccelli.org/uploads/Ietf/draft-ietf-autoconf-proble= m-statement-04-PREVIEW-5.txt = >> >> >> >> >> Your review is needed in order for the document to go forward. Please >> provide your feedback this week -- the cut-off date being next = >> Monday. The document is short (20 pages), so don't refrain! > = > Hi Manu, thanks for submitting this revised version. > = > I'm personally still trying to identify the space into which this can > become a problem and how a solution could fit some requirements. > = > The draft is clearer than before. > = > Stating DHCP/PD/NDP don't work when the connections break doesn't mean > we have a problem, because nothing could ever work when connections > break - AUTOCONF included. Stating they can be part of solution, but > not everything in a solution - I agree with that part. > = Yes, MANETs are a new challenge, and the document describes a subset of = the new challenges regarding IP autoconfiguration (stating that existing = solutions are not sufficient). > Defining new 'disjoint prefixes' as opposed to discussing old 'unique > prefixes' seems a more common denominator, I can grasp it, but I'm not > sure the draft definition of disjoint prefixes was discussed and agreed > already. PRobably yes. I will not oppose it. I have a marginal > theoretical interest in disjoint and unique prefixes and other items > affecting how routing may work, but that doesn't mean I oppose the way > AUTOCONF choose to do it. OK. I guess this indeed results from the "unique prefix" discussion, = that happened a while back, and also from the MANET-architecture = document. If you can suggest a better way to express the fact that = "addresses with prefixA are all different from addresses in prefixB" = please do so, we will use it! > = > Otherwise yes, the structure and reading of the entire draft makes sense > to me. > = Great! Emmanuel _______________________________________________ Autoconf mailing list Autoconf@ietf.org http://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Thu Feb 21 12:43:58 2008 Return-Path: X-Original-To: ietfarch-autoconf-archive@core3.amsl.com Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 72D3C28C133; Thu, 21 Feb 2008 12:43:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[AWL=-1.450, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zl4xn+Cp9axw; Thu, 21 Feb 2008 12:43:54 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9EAFC28C526; Thu, 21 Feb 2008 12:43:54 -0800 (PST) X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4666B28C293 for ; Thu, 21 Feb 2008 12:43:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uHw3AByTgZ7P for ; Thu, 21 Feb 2008 12:43:53 -0800 (PST) Received: from mail128.messagelabs.com (mail128.messagelabs.com [216.82.250.131]) by core3.amsl.com (Postfix) with SMTP id 5291C28C526 for ; Thu, 21 Feb 2008 12:43:53 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-6.tower-128.messagelabs.com!1203626628!1124182!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 13505 invoked from network); 21 Feb 2008 20:43:48 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-6.tower-128.messagelabs.com with SMTP; 21 Feb 2008 20:43:48 -0000 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id m1LKhmIA017075; Thu, 21 Feb 2008 13:43:48 -0700 (MST) Received: from il06vts03.mot.com (il06vts03.mot.com [129.188.137.143]) by il06exr01.mot.com (8.13.5/Vontu) with SMTP id m1LKhl3J026578; Thu, 21 Feb 2008 14:43:48 -0600 (CST) Received: from [127.0.0.1] ([10.129.40.137]) by il06exr01.mot.com (8.13.5/8.13.0) with ESMTP id m1LKhjvo026561; Thu, 21 Feb 2008 14:43:46 -0600 (CST) Message-ID: <47BDE281.4050503@gmail.com> Date: Thu, 21 Feb 2008 21:43:45 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Emmanuel Baccelli References: <47AAC029.8030908@dif.um.es> <47B9A5BF.9060106@inria.fr> <47BDBE1F.1060201@gmail.com> <47BDC26C.8070708@inria.fr> In-Reply-To: <47BDC26C.8070708@inria.fr> X-Antivirus: avast! (VPS 080221-0, 21/02/2008), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected Cc: autoconf@ietf.org Subject: Re: [Autoconf] AUTOCONF Problem Statement: reviews needed. X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Emmanuel Baccelli wrote: [... >> Stating DHCP/PD/NDP don't work when the connections break doesn't >> mean we have a problem, because nothing could ever work when >> connections break - AUTOCONF included. Stating they can be part >> of solution, but not everything in a solution - I agree with that >> part. >> > > Yes, MANETs are a new challenge, and the document describes a subset > of the new challenges regarding IP autoconfiguration (stating that > existing solutions are not sufficient). This is what should be identified, but we said this over and over :-) >> Defining new 'disjoint prefixes' as opposed to discussing old >> 'unique prefixes' seems a more common denominator, I can grasp it, >> but I'm not sure the draft definition of disjoint prefixes was >> discussed and agreed already. PRobably yes. I will not oppose it. >> I have a marginal theoretical interest in disjoint and unique >> prefixes and other items affecting how routing may work, but that >> doesn't mean I oppose the way AUTOCONF choose to do it. > > OK. I guess this indeed results from the "unique prefix" discussion, > that happened a while back, and also from the MANET-architecture > document. If you can suggest a better way to express the fact that > "addresses with prefixA are all different from addresses in prefixB" > please do so, we will use it! This is disgression following. I'm not sure we can express the fact that addresses with prefixA are all different from addresses in prefixB unless we assume (1) prefix length n of prefixA is equal to prefix length n of prefixB and (2) the underlying routing system uses longest prefix matching and prefixes are the contiguous set of leftmost n bits. Whereas the latter seems to be a good assumption in many routing systems, especially IPv6 (probably less IPv4), the former was not an assumption in your discussions, only in mine :-) (I'm not sure whether it figures in the draft). But yes, intuitively 'disjoint prefixes' resonate like 'unique prefixes' to me, and seems people can agree with it as is. Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ Autoconf mailing list Autoconf@ietf.org http://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Fri Feb 22 00:02:31 2008 Return-Path: X-Original-To: ietfarch-autoconf-archive@core3.amsl.com Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A9983A6885; Fri, 22 Feb 2008 00:02:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.027 X-Spam-Level: * X-Spam-Status: No, score=1.027 tagged_above=-999 required=5 tests=[AWL=-1.330, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=1, MIME_BASE64_BLANKS=0.041, MIME_BASE64_TEXT=1.753, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mNXr7PSqy6Hz; Fri, 22 Feb 2008 00:02:30 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C79673A68B5; Fri, 22 Feb 2008 00:02:29 -0800 (PST) X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A15C3A6885 for ; Fri, 22 Feb 2008 00:02:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 239yB6+UQp4O for ; Fri, 22 Feb 2008 00:02:28 -0800 (PST) Received: from mailout1.samsung.com (mailout1.samsung.com [203.254.224.24]) by core3.amsl.com (Postfix) with ESMTP id 2D5803A68B5 for ; Fri, 22 Feb 2008 00:02:28 -0800 (PST) Received: from ep_ms13_bk (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 <0JWM00FRNRNUQ4@mailout1.samsung.com> for autoconf@ietf.org; Fri, 22 Feb 2008 17:02:18 +0900 (KST) Received: from ep_spt03 (ms13.samsung.com [203.254.225.109]) by ms13.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0JWM00EBLRNULT@ms13.samsung.com> for autoconf@ietf.org; Fri, 22 Feb 2008 17:02:18 +0900 (KST) Content-return: prohibited Date: Fri, 22 Feb 2008 08:02:18 +0000 (GMT) From: ASHUTOSH BHATIA To: autoconf@ietf.org Message-id: <0JWM00EBMRNULT@ms13.samsung.com> MIME-version: 1.0 MIME-version: 1.0 X-Priority: 3 Msgkey: 20080222074757949@ashutosh.78 X-MTR: 20080222074757949@ashutosh.78 X-EPLocale: en_US.windows-1252 X-EPWebmail-Msg-Type: personal X-EPWebmail-Reply-Demand: 0 X-EPApproval-Locale: X-EPHeader: ML X-Generator: NamoMIME 6.0.0.3 Subject: [Autoconf] AUTOCONF Problem Statement: Unique Prefix Requirement X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ashutosh.78@samsung.com List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1776377768==" Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org --===============1776377768== Content-return: prohibited Content-type: text/html; charset=windows-1252 Content-transfer-encoding: base64 PEhUTUw+PEhFQUQ+PE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVudD0ndGV4dC9o dG1sOyBjaGFyc2V0PXdpbmRvd3MtMTI1Mic+Cjx0aXRsZT5TYW1zdW5nIEVudGVycHJpc2UgUG9y dGFsIG15U2luZ2xlPC90aXRsZT4KPHN0eWxlPiBQLCB0ZCwgbGkge2ZvbnQtZmFtaWx5OkFyaWFs LCBhcmlhbDsgZm9udC1zaXplOjlwdDsgbWFyZ2luLXRvcDo1cHg7bWFyZ2luLWJvdHRvbTo1cHg7 fSBib2R5e2ZvbnQtZmFtaWx5OkFyaWFsLCBhcmlhbDsgZm9udC1zaXplOjlwdDt9PC9zdHlsZT4K PC9IRUFEPgo8Qk9EWT5IaSBBbGwsDQo8cD5JIGFtIG5ldyB0byB0aGlzIGtpbmQgb2YgRHJhZnQg ZGlzY3Vzc2lvbi4gUGxlYXNlIGlnbm9yZSAmbmJzcDtteSBtaXN0YWtlcy4gDQo8L3A+DQo8cD5J IHdvdWxkIGxpa2UgdG8gcmFpc2UgbXkgY29tbW5ldHMgcmVnYXJkaW5nIHVuaXF1ZSBwcmVmaXgg cmVxdWlyZW1lbnQgZm9yIA0KRWFjaCBNQU5FVCBSb3V0ZXIuIFRoaXMgbWF5IHJlc3RyaWN0IHRo ZSBzaXplIG9mIE1BTkVUIGZvciBhIHBlcnRpY3VsYXIgZGVwbG95bWVudCANCndoZW4gTUFORVQg aXMgZGVwbG95ZWQgaW4gYW4gSVAgc3VibmV0IG9mIHN1ZmZpY2llbnRseSBsYXJnZSBwcmVmaXgu IDwvcD4NCjxwPmZvciBleGFtcGxlIGlmICZuYnNwO3N1Ym5ldCBwcmVmaXggJm5ic3A7Jm5ic3A7 aXMgJm5ic3A7cDo6LzU2LiBpbiB0aGF0IGNhc2UgDQpvdXQgb2YgNjQgYml0cyBvbmx5IDggYml0 cyBhcmUgbGVmdC4gd2hpY2ggd2lsbCByZXN0cmljdCBNQU5FVCBzaXplIHRvIDI1Ni4gDQpUaGlz IHJlcXVpcmVtZW50IGltcG9zZXMgYSByZXN0cmljdGlvbiBvbiAmcXVvdDtNQU5FVCBkZXBsb3lt ZW50JnF1b3Q7ICZuYnNwO29ubHkgDQphdCB0b3AgbGV2ZWwgbm90IGRvd24gdGhlIGhlaXJhcmNo eS48L3A+DQo8cD4mbmJzcDs8L3A+DQo8cD5SZWdhcmRzIDwvcD4NCjxwPkFzaHV0b3NoPC9wPg0K PHA+Jm5ic3A7PC9wPg0KPHA+Jm5ic3A7PC9wPjxwPiZuYnNwOzwvcD48IS0tU1A6YXNodXRvc2gu NzgtLT48IS0tYXNodXRvc2guNzg6RVAtLT48L0JPRFk+PC9IVE1MPg== --===============1776377768== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Autoconf mailing list Autoconf@ietf.org http://www.ietf.org/mailman/listinfo/autoconf --===============1776377768==-- From autoconf-bounces@ietf.org Fri Feb 22 04:48:50 2008 Return-Path: X-Original-To: ietfarch-autoconf-archive@core3.amsl.com Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2189928C16E; Fri, 22 Feb 2008 04:48:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.402 X-Spam-Level: X-Spam-Status: No, score=-0.402 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tXB0v4FsxEtw; Fri, 22 Feb 2008 04:48:49 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A917828C381; Fri, 22 Feb 2008 04:48:45 -0800 (PST) X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D6B528C391 for ; Fri, 22 Feb 2008 04:48:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wEp79OMx-4nC for ; Fri, 22 Feb 2008 04:48:43 -0800 (PST) Received: from mxav03.cc.niigata-u.ac.jp (ccmail.cc.niigata-u.ac.jp [133.35.23.1]) by core3.amsl.com (Postfix) with ESMTP id 8A35428C830 for ; Fri, 22 Feb 2008 04:47:00 -0800 (PST) Received: from mxav03.cc.niigata-u.ac.jp (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id A2853295F80 for ; Fri, 22 Feb 2008 21:42:40 +0900 (JST) Received: from mxav03.cc.niigata-u.ac.jp (localhost.localdomain [127.0.0.1]) by mxav03.cc.niigata-u.ac.jp (Postfix) with SMTP id 9061D295F7A for ; Fri, 22 Feb 2008 21:42:40 +0900 (JST) Received: (qmail 11653 invoked from network); 22 Feb 2008 21:42:40 +0900 Received: from unknown (HELO chamame.ie.niigata-u.ac.jp) (133.35.169.34) by mxav03.cc.niigata-u.ac.jp with SMTP; 22 Feb 2008 21:42:40 +0900 Received: (qmail 555 invoked from network); 22 Feb 2008 21:42:33 +0900 Received: from unknown (HELO neccomputer.ie.niigata-u.ac.jp) (133.35.156.66) by chamame.ie.niigata-u.ac.jp with SMTP; 22 Feb 2008 21:42:33 +0900 Message-Id: <7.0.0.16.2.20080222211648.05023600@ie.niigata-u.ac.jp> X-Mailer: QUALCOMM Windows Eudora Version 7J rev1.0 Date: Fri, 22 Feb 2008 21:42:36 +0900 To: Alexandru Petrescu , Emmanuel Baccelli From: mase In-Reply-To: <47BDE281.4050503@gmail.com> References: <47AAC029.8030908@dif.um.es> <47B9A5BF.9060106@inria.fr> <47BDBE1F.1060201@gmail.com> <47BDC26C.8070708@inria.fr> <47BDE281.4050503@gmail.com> Mime-Version: 1.0 Cc: autoconf@ietf.org Subject: Re: [Autoconf] AUTOCONF Problem Statement: reviews needed. X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Alex, Comments in line. At 05:43 08/02/22, Alexandru Petrescu wrote: > >> Defining new 'disjoint prefixes' as opposed to discussing old > >> 'unique prefixes' seems a more common denominator, I can grasp it, > >> but I'm not sure the draft definition of disjoint prefixes was > >> discussed and agreed already. PRobably yes. I will not oppose it. > >> I have a marginal theoretical interest in disjoint and unique > >> prefixes and other items affecting how routing may work, but that > >> doesn't mean I oppose the way AUTOCONF choose to do it. > > > > OK. I guess this indeed results from the "unique prefix" discussion, > > that happened a while back, and also from the MANET-architecture > > document. If you can suggest a better way to express the fact that > > "addresses with prefixA are all different from addresses in prefixB" > > please do so, we will use it! > >This is disgression following. I'm not sure we can express the fact >that addresses with prefixA are all different from addresses in prefixB >unless we assume (1) prefix length n of prefixA is equal to prefix >length n of prefixB and (2) the underlying routing system uses longest >prefix matching and prefixes are the contiguous set of leftmost n bits. > >Whereas the latter seems to be a good assumption in many routing >systems, especially IPv6 (probably less IPv4), the former was not an >assumption in your discussions, only in mine :-) (I'm not sure whether >it figures in the draft). > >But yes, intuitively 'disjoint prefixes' resonate like 'unique prefixes' >to me, and seems people can agree with it as is. Regardless of the prefix length, a prefix represents an address range, a set of addresses, Then, two prefixes, disjoint to each other, mean that two address ranges are not overlapping. That is, two sets of addresses do not have a common set of addresses. Underlying routing system must use the whole prefix A with length n and the whole prefix B with length m in routing. Longest prefix matching must not used in routing in the MANET. Does this help your understanding? Kenichi >Alex _______________________________________________ Autoconf mailing list Autoconf@ietf.org http://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Fri Feb 22 07:38:36 2008 Return-Path: X-Original-To: ietfarch-autoconf-archive@core3.amsl.com Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B1DF28C493; Fri, 22 Feb 2008 07:38:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.823 X-Spam-Level: X-Spam-Status: No, score=-1.823 tagged_above=-999 required=5 tests=[AWL=-1.386, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VzwTMjkbPYv7; Fri, 22 Feb 2008 07:38:35 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E90F28C830; Fri, 22 Feb 2008 07:38:34 -0800 (PST) X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E215F28C25A for ; Fri, 22 Feb 2008 07:38:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WBm824aWzP2U for ; Fri, 22 Feb 2008 07:38:28 -0800 (PST) Received: from mail153.messagelabs.com (mail153.messagelabs.com [216.82.253.51]) by core3.amsl.com (Postfix) with SMTP id 4A58328C919 for ; Fri, 22 Feb 2008 07:37:19 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-3.tower-153.messagelabs.com!1203694633!12074207!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 10480 invoked from network); 22 Feb 2008 15:37:14 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-3.tower-153.messagelabs.com with SMTP; 22 Feb 2008 15:37:14 -0000 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id m1MFb58e001746; Fri, 22 Feb 2008 08:37:13 -0700 (MST) Received: from il06vts02.mot.com (il06vts02.mot.com [129.188.137.142]) by il06exr01.mot.com (8.13.5/Vontu) with SMTP id m1MFb5kX010363; Fri, 22 Feb 2008 09:37:05 -0600 (CST) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr01.mot.com (8.13.5/8.13.0) with ESMTP id m1MFb2Jx010345; Fri, 22 Feb 2008 09:37:03 -0600 (CST) Message-ID: <47BEEC1E.7000500@gmail.com> Date: Fri, 22 Feb 2008 16:37:02 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: mase References: <47AAC029.8030908@dif.um.es> <47B9A5BF.9060106@inria.fr> <47BDBE1F.1060201@gmail.com> <47BDC26C.8070708@inria.fr> <47BDE281.4050503@gmail.com> <7.0.0.16.2.20080222211648.05023600@ie.niigata-u.ac.jp> In-Reply-To: <7.0.0.16.2.20080222211648.05023600@ie.niigata-u.ac.jp> X-Antivirus: avast! (VPS 080221-0, 21/02/2008), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected Cc: autoconf@ietf.org, Emmanuel Baccelli Subject: Re: [Autoconf] AUTOCONF Problem Statement: reviews needed. X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org mase wrote: > Alex, > > Comments in line. > > At 05:43 08/02/22, Alexandru Petrescu wrote: >>>> Defining new 'disjoint prefixes' as opposed to discussing old >>>> 'unique prefixes' seems a more common denominator, I can grasp >>>> it, but I'm not sure the draft definition of disjoint prefixes >>>> was discussed and agreed already. PRobably yes. I will not >>>> oppose it. I have a marginal theoretical interest in disjoint >>>> and unique prefixes and other items affecting how routing may >>>> work, but that doesn't mean I oppose the way AUTOCONF choose to >>>> do it. >>> >>> OK. I guess this indeed results from the "unique prefix" >>> discussion, that happened a while back, and also from the >>> MANET-architecture document. If you can suggest a better way to >>> express the fact that "addresses with prefixA are all different >>> from addresses in prefixB" please do so, we will use it! >> >> This is disgression following. I'm not sure we can express the >> fact that addresses with prefixA are all different from addresses >> in prefixB unless we assume (1) prefix length n of prefixA is equal >> to prefix length n of prefixB and (2) the underlying routing >> system uses longest prefix matching and prefixes are the contiguous >> set of leftmost n bits. >> >> Whereas the latter seems to be a good assumption in many routing >> systems, especially IPv6 (probably less IPv4), the former was not >> an assumption in your discussions, only in mine :-) (I'm not sure >> whether it figures in the draft). >> >> But yes, intuitively 'disjoint prefixes' resonate like 'unique >> prefixes' to me, and seems people can agree with it as is. > > Regardless of the prefix length, a prefix represents an address > range, a set of addresses, Then, two prefixes, disjoint to each > other, mean that two address ranges are not overlapping. That is, two > sets of addresses do not have a common set of addresses. Sounds ok... I can then understand that if two sets of addresses don't have a common subset of addresses then the two sets of addresses may contain each a prefix different than the other prefix? I'd say 'may', because there exist of course two sets of addresses that don't have any common subset of addresses and that don't have any common prefix either (differ at leftmost bit). > Underlying routing system must use the whole prefix A with length n > and the whole prefix B with length m in routing. MUST? Are there any routing system that doesn't use longest prefix match? Are there routing systems that don't use prefix matching at all? I'd suppose yes, like in policy routing. Also yes because link-layer 'routing' in bluetooth seems to be exact matching on link-layer addresses, there being no prefixes. > Longest prefix matching must not used in routing in the MANET. I think you say longest-prefix matching must be used, and the 'not' above is just a typo? > Does this help your understanding? Well yes, thank you, as I said previously, I will not oppose the agreements in this discussion and I will try to follow the discussion from a distance. Alex > > Kenichi > > >> Alex > > > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ Autoconf mailing list Autoconf@ietf.org http://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Fri Feb 22 13:33:38 2008 Return-Path: X-Original-To: ietfarch-autoconf-archive@core3.amsl.com Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D640C28C327; Fri, 22 Feb 2008 13:33:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.405 X-Spam-Level: X-Spam-Status: No, score=-0.405 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8kmR8vdzIAd5; Fri, 22 Feb 2008 13:33:37 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C130A28C3BD; Fri, 22 Feb 2008 13:33:36 -0800 (PST) X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2ABDA28C3C0 for ; Fri, 22 Feb 2008 13:33:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mKBO-H+mXobx for ; Fri, 22 Feb 2008 13:33:33 -0800 (PST) Received: from mxav01.cc.niigata-u.ac.jp (ccmail.cc.niigata-u.ac.jp [133.35.23.1]) by core3.amsl.com (Postfix) with ESMTP id 0B33B28C5CF for ; Fri, 22 Feb 2008 13:33:17 -0800 (PST) Received: from mxav01.cc.niigata-u.ac.jp (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 9846D4F7A5F for ; Sat, 23 Feb 2008 06:28:13 +0900 (JST) Received: from mxav01.cc.niigata-u.ac.jp (localhost.localdomain [127.0.0.1]) by mxav01.cc.niigata-u.ac.jp (Postfix) with SMTP id A32264F8804 for ; Sat, 23 Feb 2008 06:28:06 +0900 (JST) Received: (qmail 22735 invoked from network); 23 Feb 2008 06:28:06 +0900 Received: from unknown (HELO chamame.ie.niigata-u.ac.jp) (133.35.169.34) by mxav01.cc.niigata-u.ac.jp with SMTP; 23 Feb 2008 06:28:06 +0900 Received: (qmail 25270 invoked from network); 23 Feb 2008 06:27:59 +0900 Received: from unknown (HELO neccomputer.ie.niigata-u.ac.jp) (133.35.156.66) by chamame.ie.niigata-u.ac.jp with SMTP; 23 Feb 2008 06:27:59 +0900 Message-Id: <7.0.0.16.2.20080223061407.0516ad10@ie.niigata-u.ac.jp> X-Mailer: QUALCOMM Windows Eudora Version 7J rev1.0 Date: Sat, 23 Feb 2008 06:28:03 +0900 To: Alexandru Petrescu From: mase In-Reply-To: <47BEEC1E.7000500@gmail.com> References: <47AAC029.8030908@dif.um.es> <47B9A5BF.9060106@inria.fr> <47BDBE1F.1060201@gmail.com> <47BDC26C.8070708@inria.fr> <47BDE281.4050503@gmail.com> <7.0.0.16.2.20080222211648.05023600@ie.niigata-u.ac.jp> <47BEEC1E.7000500@gmail.com> Mime-Version: 1.0 Cc: autoconf@ietf.org, Emmanuel Baccelli Subject: Re: [Autoconf] AUTOCONF Problem Statement: reviews needed. X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org At 00:37 08/02/23, Alexandru Petrescu wrote: >mase wrote: >>Alex, >>Comments in line. >>At 05:43 08/02/22, Alexandru Petrescu wrote: >>>>>Defining new 'disjoint prefixes' as opposed to discussing old >>>>>'unique prefixes' seems a more common denominator, I can grasp >>>>>it, but I'm not sure the draft definition of disjoint prefixes >>>>>was discussed and agreed already. PRobably yes. I will not >>>>>oppose it. I have a marginal theoretical interest in disjoint >>>>>and unique prefixes and other items affecting how routing may >>>>>work, but that doesn't mean I oppose the way AUTOCONF choose to >>>>> do it. >>>>OK. I guess this indeed results from the "unique prefix" >>>>discussion, that happened a while back, and also from the >>>>MANET-architecture document. If you can suggest a better way to >>>>express the fact that "addresses with prefixA are all different >>>>from addresses in prefixB" please do so, we will use it! >>>This is disgression following. I'm not sure we can express >>>the fact that addresses with prefixA are all different from >>>addresses in prefixB unless we assume (1) prefix length n of prefixA is equal >>> to prefix length n of prefixB and (2) the underlying routing >>> system uses longest prefix matching and prefixes are the contiguous >>> set of leftmost n bits. >>>Whereas the latter seems to be a good assumption in many >>>routing systems, especially IPv6 (probably less IPv4), the former >>>was not an assumption in your discussions, only in mine :-) (I'm >>>not sure whether it figures in the draft). >>>But yes, intuitively 'disjoint prefixes' resonate like 'unique >>>prefixes' to me, and seems people can agree with it as is. >>Regardless of the prefix length, a prefix represents an address >>range, a set of addresses, Then, two prefixes, disjoint to each >>other, mean that two address ranges are not overlapping. That is, two >> sets of addresses do not have a common set of addresses. > >Sounds ok... I can then understand that if two sets of addresses don't >have a common subset of addresses then the two sets of addresses may >contain each a prefix different than the other prefix? I'd say 'may', >because there exist of course two sets of addresses that don't have any >common subset of addresses and that don't have any common prefix either >(differ at leftmost bit). No. Let W, X, Y, Z are 8bit sequences, respectively. Prefix WX/16 and WYZ/24 has a common Prefix W/8 but, Prefix WX and WYZ does not have a common sebset of addresses. >>Underlying routing system must use the whole prefix A with length >>n and the whole prefix B with length m in routing. > >MUST? Are there any routing system that doesn't use longest prefix >match? Are there routing systems that don't use prefix matching at all? > I'd suppose yes, like in policy routing. Also yes because link-layer >'routing' in bluetooth seems to be exact matching on link-layer >addresses, there being no prefixes. > >>Longest prefix matching must not used in routing in the MANET. > >I think you say longest-prefix matching must be used, and the 'not' >above is just a typo? Sorry for the confusion. Longest-prefix matching is workable. >>Does this help your understanding? > >Well yes, thank you, as I said previously, I will not oppose the >agreements in this discussion and I will try to follow the discussion >from a distance. Thank you for the discussions to clarify points. Kenichi >Alex > >>Kenichi >> >>>Alex >> > > >______________________________________________________________________ >This email has been scanned by the MessageLabs Email Security System. >For more information please visit http://www.messagelabs.com/email >______________________________________________________________________ > _______________________________________________ Autoconf mailing list Autoconf@ietf.org http://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Fri Feb 22 13:36:42 2008 Return-Path: X-Original-To: ietfarch-autoconf-archive@core3.amsl.com Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F1A553A6D09; Fri, 22 Feb 2008 13:36:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.402 X-Spam-Level: X-Spam-Status: No, score=-0.402 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hOAb39lEIHGY; Fri, 22 Feb 2008 13:36:41 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2820A3A6CE8; Fri, 22 Feb 2008 13:36:41 -0800 (PST) X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A721D3A69D7 for ; Fri, 22 Feb 2008 13:36:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 74VrTLs-8l7g for ; Fri, 22 Feb 2008 13:36:36 -0800 (PST) Received: from mxav03.cc.niigata-u.ac.jp (ccmail.cc.niigata-u.ac.jp [133.35.23.1]) by core3.amsl.com (Postfix) with ESMTP id C78513A67F5 for ; Fri, 22 Feb 2008 13:36:36 -0800 (PST) Received: from mxav03.cc.niigata-u.ac.jp (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 40FA92955EB for ; Sat, 23 Feb 2008 06:36:19 +0900 (JST) Received: from mxav03.cc.niigata-u.ac.jp (localhost.localdomain [127.0.0.1]) by mxav03.cc.niigata-u.ac.jp (Postfix) with SMTP id 2EC1D294E3D for ; Sat, 23 Feb 2008 06:36:19 +0900 (JST) Received: (qmail 11620 invoked from network); 23 Feb 2008 06:36:19 +0900 Received: from unknown (HELO chamame.ie.niigata-u.ac.jp) (133.35.169.34) by mxav03.cc.niigata-u.ac.jp with SMTP; 23 Feb 2008 06:36:19 +0900 Received: (qmail 25400 invoked from network); 23 Feb 2008 06:36:19 +0900 Received: from unknown (HELO neccomputer.ie.niigata-u.ac.jp) (133.35.156.66) by chamame.ie.niigata-u.ac.jp with SMTP; 23 Feb 2008 06:36:19 +0900 Message-Id: <7.0.0.16.2.20080223063236.052155d0@ie.niigata-u.ac.jp> X-Mailer: QUALCOMM Windows Eudora Version 7J rev1.0 Date: Sat, 23 Feb 2008 06:36:23 +0900 To: ashutosh.78@samsung.com, autoconf@ietf.org From: mase In-Reply-To: <0JWM00EBMRNULT@ms13.samsung.com> References: <0JWM00EBMRNULT@ms13.samsung.com> Mime-Version: 1.0 Subject: Re: [Autoconf] AUTOCONF Problem Statement: Unique Prefix Requirement X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org At 17:02 08/02/22, ASHUTOSH BHATIA wrote: >Content-return: prohibited >Content-type: text/html; charset=windows-1252 > >Hi All, > >I am new to this kind of Draft discussion. Please ignore my mistakes. > >I would like to raise my commnets regarding unique prefix >requirement for Each MANET Router. We use "unique prefix" no more. We use "disjoint" instead. >This may restrict the size of MANET for a perticular deployment >when MANET is deployed in an IP subnet of sufficiently large prefix. > >for example if subnet prefix is p::/56. in that case out of 64 >bits only 8 bits are left. which will restrict MANET size to 256. >This requirement imposes a restriction on "MANET deployment" only >at top level not down the heirarchy. I am not sure about your question. You may use an appropriate prefix length in your application. Regards, Kenichi > > >Regards > >Ashutosh > > > > > > >_______________________________________________ >Autoconf mailing list >Autoconf@ietf.org >http://www.ietf.org/mailman/listinfo/autoconf _______________________________________________ Autoconf mailing list Autoconf@ietf.org http://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Fri Feb 22 17:44:52 2008 Return-Path: X-Original-To: ietfarch-autoconf-archive@core3.amsl.com Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0DC753A6D33; Fri, 22 Feb 2008 17:44:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.499 X-Spam-Level: X-Spam-Status: No, score=-1.499 tagged_above=-999 required=5 tests=[AWL=-1.062, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 35PnuCC64Abs; Fri, 22 Feb 2008 17:44:51 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 412C528C5D5; Fri, 22 Feb 2008 17:38:54 -0800 (PST) X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 85A253A6D33 for ; Fri, 22 Feb 2008 17:38:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9JcMoK2sTH5t for ; Fri, 22 Feb 2008 17:38:52 -0800 (PST) Received: from mail153.messagelabs.com (mail153.messagelabs.com [216.82.253.51]) by core3.amsl.com (Postfix) with SMTP id E3B1128CB36 for ; Fri, 22 Feb 2008 17:35:39 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-3.tower-153.messagelabs.com!1203730534!12128438!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 3525 invoked from network); 23 Feb 2008 01:35:35 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-3.tower-153.messagelabs.com with SMTP; 23 Feb 2008 01:35:35 -0000 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id m1N1ZYS7026040; Fri, 22 Feb 2008 18:35:34 -0700 (MST) Received: from il06vts01.mot.com (il06vts01.mot.com [129.188.137.141]) by il06exr01.mot.com (8.13.5/Vontu) with SMTP id m1N1ZX89015913; Fri, 22 Feb 2008 19:35:33 -0600 (CST) Received: from [127.0.0.1] (mvp-10-169-4-35.corp.mot.com [10.169.4.35]) by il06exr01.mot.com (8.13.5/8.13.0) with ESMTP id m1N1ZUrp015888; Fri, 22 Feb 2008 19:35:31 -0600 (CST) Message-ID: <47BF7861.8010006@gmail.com> Date: Sat, 23 Feb 2008 02:35:29 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: mase References: <47AAC029.8030908@dif.um.es> <47B9A5BF.9060106@inria.fr> <47BDBE1F.1060201@gmail.com> <47BDC26C.8070708@inria.fr> <47BDE281.4050503@gmail.com> <7.0.0.16.2.20080222211648.05023600@ie.niigata-u.ac.jp> <47BEEC1E.7000500@gmail.com> <7.0.0.16.2.20080223061407.0516ad10@ie.niigata-u.ac.jp> In-Reply-To: <7.0.0.16.2.20080223061407.0516ad10@ie.niigata-u.ac.jp> X-Antivirus: avast! (VPS 080222-0, 22/02/2008), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected Cc: autoconf@ietf.org, Emmanuel Baccelli Subject: Re: [Autoconf] AUTOCONF Problem Statement: reviews needed. X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org mase wrote: > > At 00:37 08/02/23, Alexandru Petrescu wrote: >> mase wrote: >>> Alex, Comments in line. At 05:43 08/02/22, Alexandru Petrescu >>> wrote: >>>>>> Defining new 'disjoint prefixes' as opposed to discussing >>>>>> old 'unique prefixes' seems a more common denominator, I >>>>>> can grasp it, but I'm not sure the draft definition of >>>>>> disjoint prefixes was discussed and agreed already. >>>>>> PRobably yes. I will not oppose it. I have a marginal >>>>>> theoretical interest in disjoint and unique prefixes and >>>>>> other items affecting how routing may work, but that >>>>>> doesn't mean I oppose the way AUTOCONF choose to do it. >>>>> OK. I guess this indeed results from the "unique prefix" >>>>> discussion, that happened a while back, and also from the >>>>> MANET-architecture document. If you can suggest a better way >>>>> to express the fact that "addresses with prefixA are all >>>>> different from addresses in prefixB" please do so, we will >>>>> use it! >>>> This is disgression following. I'm not sure we can express the >>>> fact that addresses with prefixA are all different from >>>> addresses in prefixB unless we assume (1) prefix length n of >>>> prefixA is equal to prefix length n of prefixB and (2) the >>>> underlying routing system uses longest prefix matching and >>>> prefixes are the contiguous set of leftmost n bits. Whereas the >>>> latter seems to be a good assumption in many routing systems, >>>> especially IPv6 (probably less IPv4), the former was not an >>>> assumption in your discussions, only in mine :-) (I'm not sure >>>> whether it figures in the draft). But yes, intuitively >>>> 'disjoint prefixes' resonate like 'unique prefixes' to me, and >>>> seems people can agree with it as is. >>> Regardless of the prefix length, a prefix represents an address >>> range, a set of addresses, Then, two prefixes, disjoint to each >>> other, mean that two address ranges are not overlapping. That is, >>> two sets of addresses do not have a common set of addresses. >> >> Sounds ok... I can then understand that if two sets of addresses >> don't have a common subset of addresses then the two sets of >> addresses may contain each a prefix different than the other >> prefix? I'd say 'may', because there exist of course two sets of >> addresses that don't have any common subset of addresses and that >> don't have any common prefix either (differ at leftmost bit). > > No. Let W, X, Y, Z are 8bit sequences, respectively. Prefix WX/16 and > WYZ/24 has a common Prefix W/8 but, Prefix WX and WYZ does not have > a common subset of addresses. Right, WX and WYZ look as a perfect illustration for what 'disjoint' means, worth noting down! Not even one address generated from WX can ever be generated from WYZ, and reciprocally. Code would be: given a pair of tuples [prefix, prefixlen] pick the smallest prefix length, compare that number of leftmost bits of the two prefixes. If they match then the two prefixes are not disjoint, otherwise they're disjoint. Remark the relationship is not transitive. I could have 0 disjoint from 10, 10 disjoint from 001 and yet 0 not disjoint from 001. In this sense 'disjoint' relationship is very different from 'unique' relationship. It's difficult to talk about three - or a pool of - prefixes being disjoint (two by two? 3 by 2?). Whereas if we assume all prefixes have same prefix length it's very easy to talk about n 'unique' prefixes. Sidenote, I would avoid the term 'overlap' below > Disjoint prefixes - two prefixes are said to be disjoint if and only > if their respective address ranges do not overlap. because makes one think that some addresses may overlap on some leftmost bits, whereas I think you meant no address from one prefix's range is present in the other's range (comparing addresses by an exact 128bit match). Or maybe it's just my reading. Just some notes... Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ Autoconf mailing list Autoconf@ietf.org http://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Fri Feb 22 18:55:15 2008 Return-Path: X-Original-To: ietfarch-autoconf-archive@core3.amsl.com Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2787F3A698E; Fri, 22 Feb 2008 18:55:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.402 X-Spam-Level: X-Spam-Status: No, score=-0.402 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dKU+uphgFdvt; Fri, 22 Feb 2008 18:55:14 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 255C73A6803; Fri, 22 Feb 2008 18:55:14 -0800 (PST) X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 795C73A6966 for ; Fri, 22 Feb 2008 18:55:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1fVTJeixcHkm for ; Fri, 22 Feb 2008 18:55:12 -0800 (PST) Received: from mxav03.cc.niigata-u.ac.jp (ccmail.cc.niigata-u.ac.jp [133.35.23.1]) by core3.amsl.com (Postfix) with ESMTP id 3A8213A67EB for ; Fri, 22 Feb 2008 18:55:11 -0800 (PST) Received: from mxav03.cc.niigata-u.ac.jp (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 9E340295EAA for ; Sat, 23 Feb 2008 11:49:41 +0900 (JST) Received: from mxav03.cc.niigata-u.ac.jp (localhost.localdomain [127.0.0.1]) by mxav03.cc.niigata-u.ac.jp (Postfix) with SMTP id 8B2E2295E58 for ; Sat, 23 Feb 2008 11:49:41 +0900 (JST) Received: (qmail 17293 invoked from network); 23 Feb 2008 11:49:41 +0900 Received: from unknown (HELO chamame.ie.niigata-u.ac.jp) (133.35.169.34) by mxav03.cc.niigata-u.ac.jp with SMTP; 23 Feb 2008 11:49:41 +0900 Received: (qmail 4627 invoked from network); 23 Feb 2008 11:49:34 +0900 Received: from unknown (HELO neccomputer.ie.niigata-u.ac.jp) (133.35.156.66) by chamame.ie.niigata-u.ac.jp with SMTP; 23 Feb 2008 11:49:34 +0900 Message-Id: <7.0.0.16.2.20080223111650.04e76fb8@ie.niigata-u.ac.jp> X-Mailer: QUALCOMM Windows Eudora Version 7J rev1.0 Date: Sat, 23 Feb 2008 11:49:38 +0900 To: Alexandru Petrescu From: mase In-Reply-To: <47BF7861.8010006@gmail.com> References: <47AAC029.8030908@dif.um.es> <47B9A5BF.9060106@inria.fr> <47BDBE1F.1060201@gmail.com> <47BDC26C.8070708@inria.fr> <47BDE281.4050503@gmail.com> <7.0.0.16.2.20080222211648.05023600@ie.niigata-u.ac.jp> <47BEEC1E.7000500@gmail.com> <7.0.0.16.2.20080223061407.0516ad10@ie.niigata-u.ac.jp> <47BF7861.8010006@gmail.com> Mime-Version: 1.0 Cc: autoconf@ietf.org, Emmanuel Baccelli Subject: Re: [Autoconf] AUTOCONF Problem Statement: reviews needed. X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org At 10:35 08/02/23, Alexandru Petrescu wrote: >mase wrote: >>At 00:37 08/02/23, Alexandru Petrescu wrote: >>>mase wrote: >>>>Alex, Comments in line. At 05:43 08/02/22, Alexandru Petrescu wrote: >>>>>>>Defining new 'disjoint prefixes' as opposed to discussing old >>>>>>>'unique prefixes' seems a more common denominator, I can grasp >>>>>>>it, but I'm not sure the draft definition of disjoint prefixes >>>>>>>was discussed and agreed already. PRobably yes. I will not >>>>>>>oppose it. I have a marginal theoretical interest in disjoint >>>>>>>and unique prefixes and other items affecting how routing may >>>>>>>work, but that doesn't mean I oppose the way AUTOCONF choose to do it. >>>>>>OK. I guess this indeed results from the "unique prefix" >>>>>>discussion, that happened a while back, and also from the >>>>>>MANET-architecture document. If you can suggest a better way to >>>>>>express the fact that "addresses with prefixA are all different >>>>>>from addresses in prefixB" please do so, we will use it! >>>>>This is disgression following. I'm not sure we can express the >>>>> fact that addresses with prefixA are all different from >>>>> addresses in prefixB unless we assume (1) prefix length n of >>>>> prefixA is equal to prefix length n of prefixB and (2) the >>>>> underlying routing system uses longest prefix matching and >>>>> prefixes are the contiguous set of leftmost n bits. Whereas the >>>>> latter seems to be a good assumption in many routing >>>>> systems, especially IPv6 (probably less IPv4), the former was >>>>> not an assumption in your discussions, only in mine :-) (I'm >>>>> not sure whether it figures in the draft). But yes, intuitively >>>>> 'disjoint prefixes' resonate like 'unique prefixes' to me, and >>>>> seems people can agree with it as is. >>>>Regardless of the prefix length, a prefix represents an >>>>address range, a set of addresses, Then, two prefixes, disjoint >>>>to each other, mean that two address ranges are not overlapping. That is, >>>>two sets of addresses do not have a common set of addresses. >>>Sounds ok... I can then understand that if two sets of >>>addresses don't have a common subset of addresses then the two >>>sets of addresses may contain each a prefix different than the >>>other prefix? I'd say 'may', because there exist of course two >>>sets of addresses that don't have any common subset of addresses >>>and that don't have any common prefix either (differ at leftmost bit). >>No. Let W, X, Y, Z are 8bit sequences, respectively. Prefix WX/16 and >> WYZ/24 has a common Prefix W/8 but, Prefix WX and WYZ does not >> have a common subset of addresses. > >Right, WX and WYZ look as a perfect illustration for what 'disjoint' >means, worth noting down! Not even one address generated from WX can >ever be generated from WYZ, and reciprocally. Right. >Code would be: given a pair of tuples [prefix, prefixlen] pick the >smallest prefix length, compare that number of leftmost bits of the two >prefixes. If they match then the two prefixes are not disjoint, >otherwise they're disjoint. Right. >Remark the relationship is not transitive. I could have 0 disjoint from >10, 10 disjoint from 001 and yet 0 not disjoint from 001. In this sense >'disjoint' relationship is very different from 'unique' relationship. Prefix is the set of addresses. Using your example above, the set 0 and the set 10 is disjoint. Since the set 001 is included in the set 0, it is natural that the set 001 is also disjoint to the set 10. >It's difficult to talk about three - or a pool of - prefixes being >disjoint (two by two? 3 by 2?). Whereas if we assume all prefixes have >same prefix length it's very easy to talk about n 'unique' prefixes. I believe efficient calculation is possible without the same prefix length assumtion. I also think that it is not difficult to produce multiple disjoint prefixes, that are disjoint to each other. I think that allowing different lenghth prefix is important and useful in some scenarios. For example, assume that node 1 has authority of the prefix WX/16 and node 2 has authority of the prefix WY/16. Later, node 2 takes WYZ/24 for itself and gives WYA/24 to other node, resulting different length prefixes. >Sidenote, I would avoid the term 'overlap' below >>Disjoint prefixes - two prefixes are said to be disjoint if and only >> if their respective address ranges do not overlap. >because makes one think that some addresses may overlap on some leftmost >bits, whereas I think you meant no address from one prefix's range is >present in the other's range (comparing addresses by an exact 128bit >match). Or maybe it's just my reading. I understand that overlap may be confusing. Thanks, Kenichi >Just some notes... > >Alex > > >______________________________________________________________________ >This email has been scanned by the MessageLabs Email Security System. >For more information please visit >http://www.messagelabs.com/email >______________________________________________________________________ > _______________________________________________ Autoconf mailing list Autoconf@ietf.org http://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Sat Feb 23 03:09:10 2008 Return-Path: X-Original-To: ietfarch-autoconf-archive@core3.amsl.com Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1FE4528C191; Sat, 23 Feb 2008 03:09:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.53 X-Spam-Level: X-Spam-Status: No, score=-1.53 tagged_above=-999 required=5 tests=[AWL=-1.093, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ScIikrpuiNo; Sat, 23 Feb 2008 03:09:09 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 505163A6A27; Sat, 23 Feb 2008 03:09:09 -0800 (PST) X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4AACA3A6A6B for ; Sat, 23 Feb 2008 03:09:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BiJE7HG-nT+4 for ; Sat, 23 Feb 2008 03:09:07 -0800 (PST) Received: from mail153.messagelabs.com (mail153.messagelabs.com [216.82.253.51]) by core3.amsl.com (Postfix) with SMTP id 4CA5928C110 for ; Sat, 23 Feb 2008 03:09:06 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-12.tower-153.messagelabs.com!1203764941!9230900!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 29323 invoked from network); 23 Feb 2008 11:09:02 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-12.tower-153.messagelabs.com with SMTP; 23 Feb 2008 11:09:02 -0000 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id m1NB8wFH016834; Sat, 23 Feb 2008 04:09:01 -0700 (MST) Received: from il06vts02.mot.com (il06vts02.mot.com [129.188.137.142]) by il06exr03.mot.com (8.13.1/Vontu) with SMTP id m1NB8wES022884; Sat, 23 Feb 2008 05:08:58 -0600 (CST) Received: from [127.0.0.1] ([10.129.40.72]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id m1NB8u0I022880; Sat, 23 Feb 2008 05:08:56 -0600 (CST) Message-ID: <47BFFEC7.40709@gmail.com> Date: Sat, 23 Feb 2008 12:08:55 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: mase References: <47AAC029.8030908@dif.um.es> <47B9A5BF.9060106@inria.fr> <47BDBE1F.1060201@gmail.com> <47BDC26C.8070708@inria.fr> <47BDE281.4050503@gmail.com> <7.0.0.16.2.20080222211648.05023600@ie.niigata-u.ac.jp> <47BEEC1E.7000500@gmail.com> <7.0.0.16.2.20080223061407.0516ad10@ie.niigata-u.ac.jp> <47BF7861.8010006@gmail.com> <7.0.0.16.2.20080223111650.04e76fb8@ie.niigata-u.ac.jp> In-Reply-To: <7.0.0.16.2.20080223111650.04e76fb8@ie.niigata-u.ac.jp> X-Antivirus: avast! (VPS 080222-0, 22/02/2008), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected Cc: autoconf@ietf.org, Emmanuel Baccelli Subject: Re: [Autoconf] AUTOCONF Problem Statement: reviews needed. X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Hi Kenichi, mase wrote: [...] >>> No. Let W, X, Y, Z are 8bit sequences, respectively. Prefix WX/16 >>> and WYZ/24 has a common Prefix W/8 but, Prefix WX and WYZ does >>> not have a common subset of addresses. >> >> Right, WX and WYZ look as a perfect illustration for what >> 'disjoint' means, worth noting down! Not even one address >> generated from WX can ever be generated from WYZ, and reciprocally. >> >> >> >> >> >> >> >> > > Right. > > >> Code would be: given a pair of tuples [prefix, prefixlen] pick the >> smallest prefix length, compare that number of leftmost bits of >> the two prefixes. If they match then the two prefixes are not >> disjoint, otherwise they're disjoint. > > Right. > > >> Remark the relationship is not transitive. I could have 0 disjoint >> from 10, 10 disjoint from 001 and yet 0 not disjoint from 001. In >> this sense 'disjoint' relationship is very different from 'unique' >> relationship. > > Prefix is the set of addresses. Using your example above, the set 0 > and the set 10 is disjoint. Since the set 001 is included in the set > 0, it is natural that the set 001 is also disjoint to the set 10. Right, that sounds natural as well. Let's look at this text: > 2. [allow each MANET router to] be allocated IPv6 prefixes that are > disjoint from prefixes allocated to other routers within the MANET. Do you mean a new router should be allocated (e.g.) two prefixes, each prefix being disjoint from each existing router's prefix? But are those two new prefixes disjoint between themselves or they could be joint? Because it is possible to allocate two new prefixes 0 and 001 to a new router, each prefix being disjoint from the already allocated prefix 10, yet the two new allocated prefixes are not disjoint between themselves. This leads to a situation where the allocation happened according to goal 2 above yet it could make goal 3 impossible: > 3. maintain, within the MANET, [...] the disjoint character of > allocated prefixes (even in face of network merging). This is confusing to me, ? Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ Autoconf mailing list Autoconf@ietf.org http://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Sat Feb 23 16:35:28 2008 Return-Path: X-Original-To: ietfarch-autoconf-archive@core3.amsl.com Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 63AB43A685F; Sat, 23 Feb 2008 16:35:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.405 X-Spam-Level: X-Spam-Status: No, score=-0.405 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1i2fPp1tgkpq; Sat, 23 Feb 2008 16:35:27 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D01C3A6AD8; Sat, 23 Feb 2008 16:35:27 -0800 (PST) X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 246543A6AD8 for ; Sat, 23 Feb 2008 16:35:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8W65fW1SqhtV for ; Sat, 23 Feb 2008 16:35:25 -0800 (PST) Received: from mxav03.cc.niigata-u.ac.jp (ccmail.cc.niigata-u.ac.jp [133.35.23.1]) by core3.amsl.com (Postfix) with ESMTP id 8D8B93A685F for ; Sat, 23 Feb 2008 16:35:24 -0800 (PST) Received: from mxav03.cc.niigata-u.ac.jp (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id A2C15297362 for ; Sun, 24 Feb 2008 09:34:29 +0900 (JST) Received: from mxav03.cc.niigata-u.ac.jp (localhost.localdomain [127.0.0.1]) by mxav03.cc.niigata-u.ac.jp (Postfix) with SMTP id 16E5A29734A for ; Sun, 24 Feb 2008 09:34:29 +0900 (JST) Received: (qmail 510 invoked from network); 24 Feb 2008 09:34:29 +0900 Received: from unknown (HELO chamame.ie.niigata-u.ac.jp) (133.35.169.34) by mxav03.cc.niigata-u.ac.jp with SMTP; 24 Feb 2008 09:34:29 +0900 Received: (qmail 21741 invoked from network); 24 Feb 2008 09:34:21 +0900 Received: from unknown (HELO neccomputer.ie.niigata-u.ac.jp) (133.35.156.66) by chamame.ie.niigata-u.ac.jp with SMTP; 24 Feb 2008 09:34:21 +0900 Message-Id: <7.0.0.16.2.20080224072338.0515f628@ie.niigata-u.ac.jp> X-Mailer: QUALCOMM Windows Eudora Version 7J rev1.0 Date: Sun, 24 Feb 2008 09:34:27 +0900 To: Alexandru Petrescu From: mase In-Reply-To: <47BFFEC7.40709@gmail.com> References: <47AAC029.8030908@dif.um.es> <47B9A5BF.9060106@inria.fr> <47BDBE1F.1060201@gmail.com> <47BDC26C.8070708@inria.fr> <47BDE281.4050503@gmail.com> <7.0.0.16.2.20080222211648.05023600@ie.niigata-u.ac.jp> <47BEEC1E.7000500@gmail.com> <7.0.0.16.2.20080223061407.0516ad10@ie.niigata-u.ac.jp> <47BF7861.8010006@gmail.com> <7.0.0.16.2.20080223111650.04e76fb8@ie.niigata-u.ac.jp> <47BFFEC7.40709@gmail.com> Mime-Version: 1.0 Cc: autoconf@ietf.org, Emmanuel Baccelli Subject: Re: [Autoconf] AUTOCONF Problem Statement: reviews needed. X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Hi Alex, At 20:08 08/02/23, Alexandru Petrescu wrote: >Hi Kenichi, > >mase wrote: >[...] >>>>No. Let W, X, Y, Z are 8bit sequences, respectively. Prefix WX/16 >>>> and WYZ/24 has a common Prefix W/8 but, Prefix WX and WYZ does >>>> not have a common subset of addresses. >>>Right, WX and WYZ look as a perfect illustration for what >>>'disjoint' means, worth noting down! Not even one address >>>generated from WX can ever be generated from WYZ, and reciprocally. >>> >>> >>> >>Right. >> >>>Code would be: given a pair of tuples [prefix, prefixlen] pick the >>> smallest prefix length, compare that number of leftmost bits of >>>the two prefixes. If they match then the two prefixes are not >>>disjoint, otherwise they're disjoint. >>Right. >> >>>Remark the relationship is not transitive. I could have 0 disjoint >>> from 10, 10 disjoint from 001 and yet 0 not disjoint from 001. In >>> this sense 'disjoint' relationship is very different from 'unique' >>> relationship. >>Prefix is the set of addresses. Using your example above, the >>set 0 and the set 10 is disjoint. Since the set 001 is included in >>the set 0, it is natural that the set 001 is also disjoint to the set 10. > >Right, that sounds natural as well. > >Let's look at this text: >>2. [allow each MANET router to] be allocated IPv6 prefixes that >>are disjoint from prefixes allocated to other routers within the MANET. > >Do you mean a new router should be allocated (e.g.) two prefixes, each > prefix being disjoint from each existing router's prefix? But are >those two new prefixes disjoint between themselves or they could be joint? No, a new router should be allocated one prefix in principle. This prefix must be disjoint from any of the already addlocated prefixes for other routers. >Because it is possible to allocate two new prefixes 0 and 001 to a new >router, each prefix being disjoint from the already allocated prefix 10, >yet the two new allocated prefixes are not disjoint between themselves. > This leads to a situation where the allocation happened according to >goal 2 above yet it could make goal 3 impossible: Assume that an exisitng MANET router i has prefix pi. The prefix of router i and router j, pi and pj, are disjoint. Goal 2 says that a new router x will be allocated prefix px, that is disjoint from each of pi, pj and other prefixes of the existing routers in the MANET. >>3. maintain, within the MANET, [...] the disjoint character of >>allocated prefixes (even in face of network merging). > >This is confusing to me, ? Assume that there are two separated MANET, MANET1 and MANET2. Router i in MANT1 has prefix p1i and router j in MANET2 has prefix p2j. Since MANET1 and 2 were independent, p1x and p2y may be same. After merging, this violates the disjoint character of allocated prefixes in the merged MANET. Goal 3 addresses that such issues should be resolved. Is this clear? Kenichi >Alex > >______________________________________________________________________ >This email has been scanned by the MessageLabs Email Security System. >For more information please visit http://www.messagelabs.com/email >______________________________________________________________________ > _______________________________________________ Autoconf mailing list Autoconf@ietf.org http://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Sun Feb 24 01:00:51 2008 Return-Path: X-Original-To: ietfarch-autoconf-archive@core3.amsl.com Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C6B193A6ABC; Sun, 24 Feb 2008 01:00:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.668 X-Spam-Level: X-Spam-Status: No, score=-0.668 tagged_above=-999 required=5 tests=[AWL=-0.231, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q2e2gDyAHOhG; Sun, 24 Feb 2008 01:00:50 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D2E953A6860; Sun, 24 Feb 2008 01:00:50 -0800 (PST) X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4CC5C3A6860 for ; Sun, 24 Feb 2008 01:00:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bKj2j9jU1Kqs for ; Sun, 24 Feb 2008 01:00:48 -0800 (PST) Received: from hpsmtp-eml19.kpnxchange.com (hpsmtp-eml19.KPNXCHANGE.COM [213.75.38.84]) by core3.amsl.com (Postfix) with ESMTP id DD5E83A63CB for ; Sun, 24 Feb 2008 01:00:47 -0800 (PST) Received: from hpsmtp-eml04.kpnxchange.com ([213.75.38.104]) by hpsmtp-eml19.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 24 Feb 2008 10:00:41 +0100 Received: from M90Teco ([86.83.9.22]) by hpsmtp-eml04.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 24 Feb 2008 10:00:34 +0100 From: "Teco Boot" To: "'mase'" , "'Alexandru Petrescu'" References: <47AAC029.8030908@dif.um.es> <47B9A5BF.9060106@inria.fr> <47BDBE1F.1060201@gmail.com> <47BDC26C.8070708@inria.fr> <47BDE281.4050503@gmail.com> <7.0.0.16.2.20080222211648.05023600@ie.niigata-u.ac.jp> <47BEEC1E.7000500@gmail.com> <7.0.0.16.2.20080223061407.0516ad10@ie.niigata-u.ac.jp> <47BF7861.8010006@gmail.com> <7.0.0.16.2.20080223111650.04e76fb8@ie.niigata-u.ac.jp> <47BFFEC7.40709@gmail.com> <7.0.0.16.2.20080224072338.0515f628@ie.niigata-u.ac.jp> In-Reply-To: <7.0.0.16.2.20080224072338.0515f628@ie.niigata-u.ac.jp> Date: Sun, 24 Feb 2008 10:00:30 +0100 Message-ID: <001901c876c3$b529b990$1f7d2cb0$@nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ach2fSfAgc0SuWu+RIOSm/ruhc0mWAAQVl7Q Content-Language: nl X-OriginalArrivalTime: 24 Feb 2008 09:00:34.0116 (UTC) FILETIME=[B7029840:01C876C3] Cc: autoconf@ietf.org Subject: Re: [Autoconf] AUTOCONF Problem Statement: reviews needed. X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org All, Just some remarks on the "prefix-discussion". 1) I still doubt Autoconf should put much effort on prefixes. I still do not understand the problem, or I think it is not a real-world problem. I think current protocols for PD can be used in Subordinate MANETs and random ULA prefixes can be used in a Autonomous MANET with extreme low probability on collisions, e.g. using a 52-bit Global_ID. 2) Discussion on terminology, to be used for unique / disjoint / non-overlapping / mutually exclusive or whatever prefixes is a general routing issue. Too much discussion on this term on Autoconf ML is a waste of time. 3) Please keep in mind prefixes are not disjoint by definition, think about anycast (or VRRF, but this is out-of-scope for a MANET). Are there existing IETF protocols for verifying disjoint prefixes on routers? Regards, Teco > -----Oorspronkelijk bericht----- > Van: autoconf-bounces@ietf.org [mailto:autoconf-bounces@ietf.org] > Namens mase > Verzonden: zondag 24 februari 2008 1:34 > Aan: Alexandru Petrescu > CC: autoconf@ietf.org; Emmanuel Baccelli > Onderwerp: Re: [Autoconf] AUTOCONF Problem Statement: reviews needed. > > Hi Alex, > > At 20:08 08/02/23, Alexandru Petrescu wrote: > >Hi Kenichi, > > > >mase wrote: > >[...] > >>>>No. Let W, X, Y, Z are 8bit sequences, respectively. Prefix WX/16 > >>>> and WYZ/24 has a common Prefix W/8 but, Prefix WX and WYZ does > >>>> not have a common subset of addresses. > >>>Right, WX and WYZ look as a perfect illustration for what > >>>'disjoint' means, worth noting down! Not even one address > >>>generated from WX can ever be generated from WYZ, and reciprocally. > >>> > >>> > >>> > >>Right. > >> > >>>Code would be: given a pair of tuples [prefix, prefixlen] pick the > >>> smallest prefix length, compare that number of leftmost bits of > >>>the two prefixes. If they match then the two prefixes are not > >>>disjoint, otherwise they're disjoint. > >>Right. > >> > >>>Remark the relationship is not transitive. I could have 0 disjoint > >>> from 10, 10 disjoint from 001 and yet 0 not disjoint from 001. In > >>> this sense 'disjoint' relationship is very different from 'unique' > >>> relationship. > >>Prefix is the set of addresses. Using your example above, the > >>set 0 and the set 10 is disjoint. Since the set 001 is included in > >>the set 0, it is natural that the set 001 is also disjoint to the > set 10. > > > >Right, that sounds natural as well. > > > >Let's look at this text: > >>2. [allow each MANET router to] be allocated IPv6 prefixes that > >>are disjoint from prefixes allocated to other routers within the > MANET. > > > >Do you mean a new router should be allocated (e.g.) two prefixes, each > > prefix being disjoint from each existing router's prefix? But are > >those two new prefixes disjoint between themselves or they could be > joint? > > No, a new router should be allocated one prefix in principle. This > prefix must be disjoint from any of the already addlocated prefixes > for other routers. > > > >Because it is possible to allocate two new prefixes 0 and 001 to a new > >router, each prefix being disjoint from the already allocated prefix > 10, > >yet the two new allocated prefixes are not disjoint between > themselves. > > This leads to a situation where the allocation happened according to > >goal 2 above yet it could make goal 3 impossible: > > Assume that an exisitng MANET router i has prefix pi. The prefix of > router i and router j, pi and pj, are disjoint. Goal 2 says that a > new router x will be allocated prefix px, that is disjoint from > each of pi, pj and other prefixes of the existing routers in the MANET. > > > >>3. maintain, within the MANET, [...] the disjoint character of > >>allocated prefixes (even in face of network merging). > > > >This is confusing to me, ? > > Assume that there are two separated MANET, MANET1 and MANET2. > Router i in MANT1 has prefix p1i and router j in MANET2 has prefix > p2j. Since MANET1 and 2 were independent, p1x and p2y may be same. > After merging, this violates the disjoint character of allocated > prefixes in the merged MANET. Goal 3 addresses that such issues > should be resolved. Is this clear? > > Kenichi > > > >Alex > > > >______________________________________________________________________ > >This email has been scanned by the MessageLabs Email Security System. > >For more information please visit http://www.messagelabs.com/email > >______________________________________________________________________ > > > > > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > http://www.ietf.org/mailman/listinfo/autoconf _______________________________________________ Autoconf mailing list Autoconf@ietf.org http://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Sun Feb 24 04:49:43 2008 Return-Path: X-Original-To: ietfarch-autoconf-archive@core3.amsl.com Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E9C5B28C105; Sun, 24 Feb 2008 04:49:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.404 X-Spam-Level: X-Spam-Status: No, score=-0.404 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ifsXUWpL5Ayh; Sun, 24 Feb 2008 04:49:42 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D444B3A6A36; Sun, 24 Feb 2008 04:49:42 -0800 (PST) X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C00083A6A23 for ; Sun, 24 Feb 2008 04:49:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8RkCn6KXU9kL for ; Sun, 24 Feb 2008 04:49:40 -0800 (PST) Received: from mxav03.cc.niigata-u.ac.jp (ccmail.cc.niigata-u.ac.jp [133.35.23.1]) by core3.amsl.com (Postfix) with ESMTP id 171B53A6A36 for ; Sun, 24 Feb 2008 04:49:38 -0800 (PST) Received: from mxav03.cc.niigata-u.ac.jp (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 6D69529743A for ; Sun, 24 Feb 2008 21:47:12 +0900 (JST) Received: from mxav03.cc.niigata-u.ac.jp (localhost.localdomain [127.0.0.1]) by mxav03.cc.niigata-u.ac.jp (Postfix) with SMTP id 59F3F297416 for ; Sun, 24 Feb 2008 21:47:12 +0900 (JST) Received: (qmail 19769 invoked from network); 24 Feb 2008 21:47:12 +0900 Received: from unknown (HELO chamame.ie.niigata-u.ac.jp) (133.35.169.34) by mxav03.cc.niigata-u.ac.jp with SMTP; 24 Feb 2008 21:47:12 +0900 Received: (qmail 11879 invoked from network); 24 Feb 2008 21:47:11 +0900 Received: from unknown (HELO neccomputer.ie.niigata-u.ac.jp) (133.35.156.66) by chamame.ie.niigata-u.ac.jp with SMTP; 24 Feb 2008 21:47:11 +0900 Message-Id: <7.0.0.16.2.20080224212243.052f6598@ie.niigata-u.ac.jp> X-Mailer: QUALCOMM Windows Eudora Version 7J rev1.0 Date: Sun, 24 Feb 2008 21:47:18 +0900 To: "Teco Boot" , "'Alexandru Petrescu'" From: mase In-Reply-To: <001901c876c3$b529b990$1f7d2cb0$@nl> References: <47AAC029.8030908@dif.um.es> <47B9A5BF.9060106@inria.fr> <47BDBE1F.1060201@gmail.com> <47BDC26C.8070708@inria.fr> <47BDE281.4050503@gmail.com> <7.0.0.16.2.20080222211648.05023600@ie.niigata-u.ac.jp> <47BEEC1E.7000500@gmail.com> <7.0.0.16.2.20080223061407.0516ad10@ie.niigata-u.ac.jp> <47BF7861.8010006@gmail.com> <7.0.0.16.2.20080223111650.04e76fb8@ie.niigata-u.ac.jp> <47BFFEC7.40709@gmail.com> <7.0.0.16.2.20080224072338.0515f628@ie.niigata-u.ac.jp> <001901c876c3$b529b990$1f7d2cb0$@nl> Mime-Version: 1.0 Cc: autoconf@ietf.org Subject: Re: [Autoconf] AUTOCONF Problem Statement: reviews needed. X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org Hi Teco, Thank you for your comments. My comments are in line. At 18:00 08/02/24, Teco Boot wrote: >All, >Just some remarks on the "prefix-discussion". >1) I still doubt Autoconf should put much effort on prefixes. I still do not >understand the problem, or I think it is not a real-world problem. I think >current protocols for PD can be used in Subordinate MANETs and random ULA >prefixes can be used in a Autonomous MANET with extreme low probability on >collisions, e.g. using a 52-bit Global_ID. Wether random prefixes work or not depends on the prefix length, that may be selected depending on applications and scenarios. >2) Discussion on terminology, to be used for unique / disjoint / >non-overlapping / mutually exclusive or whatever prefixes is a general >routing issue. Too much discussion on this term on Autoconf ML is a waste of >time. I think that unique address and disjoint prefix characeristisc are required for discussing any routing issues, but they are not necessarily discussed with routing issues. We therefore discuss these issues in autoconf WG, not manet WG. >3) Please keep in mind prefixes are not disjoint by definition, think about >anycast (or VRRF, but this is out-of-scope for a MANET). Are there existing >IETF protocols for verifying disjoint prefixes on routers? >Regards, Teco Disjoint prefix characteristics are at least required for unicast routing. Regards, Kenichi > > -----Oorspronkelijk bericht----- > > Van: autoconf-bounces@ietf.org [mailto:autoconf-bounces@ietf.org] > > Namens mase > > Verzonden: zondag 24 februari 2008 1:34 > > Aan: Alexandru Petrescu > > CC: autoconf@ietf.org; Emmanuel Baccelli > > Onderwerp: Re: [Autoconf] AUTOCONF Problem Statement: reviews needed. > > > > Hi Alex, > > > > At 20:08 08/02/23, Alexandru Petrescu wrote: > > >Hi Kenichi, > > > > > >mase wrote: > > >[...] > > >>>>No. Let W, X, Y, Z are 8bit sequences, respectively. Prefix WX/16 > > >>>> and WYZ/24 has a common Prefix W/8 but, Prefix WX and WYZ does > > >>>> not have a common subset of addresses. > > >>>Right, WX and WYZ look as a perfect illustration for what > > >>>'disjoint' means, worth noting down! Not even one address > > >>>generated from WX can ever be generated from WYZ, and reciprocally. > > >>> > > >>> > > >>> > > >>Right. > > >> > > >>>Code would be: given a pair of tuples [prefix, prefixlen] pick the > > >>> smallest prefix length, compare that number of leftmost bits of > > >>>the two prefixes. If they match then the two prefixes are not > > >>>disjoint, otherwise they're disjoint. > > >>Right. > > >> > > >>>Remark the relationship is not transitive. I could have 0 disjoint > > >>> from 10, 10 disjoint from 001 and yet 0 not disjoint from 001. In > > >>> this sense 'disjoint' relationship is very different from 'unique' > > >>> relationship. > > >>Prefix is the set of addresses. Using your example above, the > > >>set 0 and the set 10 is disjoint. Since the set 001 is included in > > >>the set 0, it is natural that the set 001 is also disjoint to the > > set 10. > > > > > >Right, that sounds natural as well. > > > > > >Let's look at this text: > > >>2. [allow each MANET router to] be allocated IPv6 prefixes that > > >>are disjoint from prefixes allocated to other routers within the > > MANET. > > > > > >Do you mean a new router should be allocated (e.g.) two prefixes, each > > > prefix being disjoint from each existing router's prefix? But are > > >those two new prefixes disjoint between themselves or they could be > > joint? > > > > No, a new router should be allocated one prefix in principle. This > > prefix must be disjoint from any of the already addlocated prefixes > > for other routers. > > > > > > >Because it is possible to allocate two new prefixes 0 and 001 to a new > > >router, each prefix being disjoint from the already allocated prefix > > 10, > > >yet the two new allocated prefixes are not disjoint between > > themselves. > > > This leads to a situation where the allocation happened according to > > >goal 2 above yet it could make goal 3 impossible: > > > > Assume that an exisitng MANET router i has prefix pi. The prefix of > > router i and router j, pi and pj, are disjoint. Goal 2 says that a > > new router x will be allocated prefix px, that is disjoint from > > each of pi, pj and other prefixes of the existing routers in the MANET. > > > > > > >>3. maintain, within the MANET, [...] the disjoint character of > > >>allocated prefixes (even in face of network merging). > > > > > >This is confusing to me, ? > > > > Assume that there are two separated MANET, MANET1 and MANET2. > > Router i in MANT1 has prefix p1i and router j in MANET2 has prefix > > p2j. Since MANET1 and 2 were independent, p1x and p2y may be same. > > After merging, this violates the disjoint character of allocated > > prefixes in the merged MANET. Goal 3 addresses that such issues > > should be resolved. Is this clear? > > > > Kenichi > > > > > > >Alex > > > > > >______________________________________________________________________ > > >This email has been scanned by the MessageLabs Email Security System. > > >For more information please visit http://www.messagelabs.com/email > > >______________________________________________________________________ > > > > > > > > > _______________________________________________ > > Autoconf mailing list > > Autoconf@ietf.org > > http://www.ietf.org/mailman/listinfo/autoconf _______________________________________________ Autoconf mailing list Autoconf@ietf.org http://www.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Tue Feb 26 11:30:17 2008 Return-Path: X-Original-To: ietfarch-autoconf-archive@core3.amsl.com Delivered-To: ietfarch-autoconf-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 61C3428C478; Tue, 26 Feb 2008 11:30:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.587 X-Spam-Level: X-Spam-Status: No, score=-2.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pkQEd3FmcYpu; Tue, 26 Feb 2008 11:30:16 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 93BCE28C7B2; Tue, 26 Feb 2008 11:30:04 -0800 (PST) X-Original-To: autoconf@ietf.org Delivered-To: autoconf@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 9179A28C2C1; Tue, 26 Feb 2008 11:30:01 -0800 (PST) Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: <20080226193001.9179A28C2C1@core3.amsl.com> Date: Tue, 26 Feb 2008 11:30:01 -0800 (PST) Cc: autoconf@ietf.org Subject: [Autoconf] I-D ACTION:draft-ietf-autoconf-statement-04.txt X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: autoconf-bounces@ietf.org Errors-To: autoconf-bounces@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Ad-Hoc Network Autoconfiguration Working Group of the IETF. Title : Address Autoconfiguration for MANET: Terminology and Problem Statement Author(s) : E. Baccelli, K. Mase, S. Ruffino, S. Singh Filename : draft-ietf-autoconf-statement-04.txt Pages : 22 Date : 2008-2-26 This document states the problems pertaining to automatic IPv6 address configuration and prefix allocation in MANETs. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-autoconf-statement-04.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-ietf-autoconf-statement-04.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 _______________________________________________ Autoconf mailing list Autoconf@ietf.org http://www.ietf.org/mailman/listinfo/autoconf