From owner-ipng Wed Jul 5 08:07:59 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12230; Wed, 5 Jul 95 08:07:59 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12224; Wed, 5 Jul 95 08:07:51 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA27433; Wed, 5 Jul 1995 07:57:43 -0700 Received: from VNET.IBM.COM by mercury.Sun.COM (Sun.COM) id HAA08743; Wed, 5 Jul 1995 07:57:42 -0700 Received: from RTP by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 6404; Wed, 05 Jul 95 10:57:31 EDT Received: by RTP (XAGENTA 4.0) id 6130; Wed, 5 Jul 1995 10:47:40 -0400 Received: by cichlid.raleigh.ibm.com (AIX 3.2/UCB 5.64/4.03) id AA19343; Wed, 5 Jul 1995 10:47:28 -0400 Message-Id: <9507051447.AA19343@cichlid.raleigh.ibm.com> To: atkinson@itd.nrl.navy.mil (Ran Atkinson) Cc: ipng@sunroof.Eng.Sun.COM Subject: (IPng 347) ND: link-local address and authentication Date: Wed, 05 Jul 95 10:47:27 -0500 From: "Thomas Narten" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Per the interim meeting, ND requires that source addresses in ND packets be link-local. The current draft, however, states that non-proxy Neighbor Advertisment (NA) messages must use the same source address as the target address of the Neighbor Solicitation; proxy responses are identified by having a source address that differs from the target. The two rules conflict. One way to get around this problem is have all source addresses be link-local, and add a bit to the fixed header that indicates whether a response is from the target itself or a proxy. Is this going to cause problems with respect to authentication (e.g., how does one know that the link-local source of the NA packet is authorized to speak on behalf of the target)? My quick assessment of the situation is that this shouldn't be a problem. The sender of the NA message should have an SPI for the destination of the NA, and the source address it uses is irrelevent (e.g., knowing the shared key is what authenticates the sender, not the shared key together with a particular IP address). Or are things more complicated than this? Thomas ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Jul 5 14:40:08 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12476; Wed, 5 Jul 95 14:40:08 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12470; Wed, 5 Jul 95 14:39:55 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA17837; Wed, 5 Jul 1995 14:29:49 -0700 Received: from sundance.itd.nrl.navy.mil by mercury.Sun.COM (Sun.COM) id OAA27352; Wed, 5 Jul 1995 14:29:45 -0700 Received: from localhost.itd.nrl.navy.mil by cs.nrl.navy.mil id aa01348; 5 Jul 95 22:26 GMT To: ipng@sunroof2.Eng.Sun.COM Subject: (IPng 348) Another fragmentation/reassembly question: big payloads Date: Wed, 05 Jul 1995 17:26:04 -0500 From: Craig Metz Message-Id: <9507052226.aa01348@cs.nrl.navy.mil> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Simply put, if two fragments come in that are 65,000 bytes in length, and they reassemble to 129,944 bytes (both 8-byte frag headers and one of the IPv6 headers go away, remember), do I now have to pretend that I got a jumbogram? The total length is greater than 65575, so I cannot represent it in the 16-bit length field and I cannot proceed as if the result of reassembly is a normal packet. My personal inclination would be to spec out this case. Jumbograms and fragmentation should never have anything to do with each other, IMO. With Path MTU Discovery, the only protocol that should be able to generate fragments at the v6 level is UDP, which cannot transport data longer than 65535 bytes(?) long due to its own length field. There is no reasonable case that I can see where it would be a problem to simply require that reassembled payloads end up 65535 bytes or less in length. Can anyone else see a problem with this? Does upper-bounding the size of a fragmented payload to this number make sense? -Craig ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Jul 6 00:05:51 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12649; Thu, 6 Jul 95 00:05:51 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12638; Thu, 6 Jul 95 00:05:39 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA29812; Wed, 5 Jul 1995 23:55:32 -0700 Received: from dxmint.cern.ch by mercury.Sun.COM (Sun.COM) id XAA18575; Wed, 5 Jul 1995 23:55:27 -0700 Received: from dxcoms.cern.ch by dxmint.cern.ch id AA10542; Thu, 6 Jul 1995 08:55:19 +0200 Received: by dxcoms.cern.ch id AA21085; Thu, 6 Jul 1995 08:55:17 +0200 Message-Id: <9507060655.AA21085@dxcoms.cern.ch> Subject: (IPng 349) Re: Another fragmentation/reassembly question: big payloads To: ipng@sunroof.Eng.Sun.COM (IPv6 List) Date: Thu, 6 Jul 1995 08:55:17 +0200 (MET DST) From: "Brian Carpenter CERN-CN" In-Reply-To: <9507052226.aa01348@cs.nrl.navy.mil> from "Craig Metz" at Jul 5, 95 05:26:04 pm X-Mailer: ELM [version 2.4 PL23 DXCOMS1] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk As a jumbogram proponent, I agree with Craig. I would hope that jumbograms are only used on paths with adequate MTUs, preferably on switched LANs such as HiPPI with no intermediate router. That is the only case where they make sense. Brian >--------- Text sent by Craig Metz follows: > > > Simply put, if two fragments come in that are 65,000 bytes in > length, and they reassemble to 129,944 bytes (both 8-byte frag headers > and one of the IPv6 headers go away, remember), do I now have to pretend > that I got a jumbogram? The total length is greater than 65575, so I cannot > represent it in the 16-bit length field and I cannot proceed as if the > result of reassembly is a normal packet. > > My personal inclination would be to spec out this case. Jumbograms > and fragmentation should never have anything to do with each other, IMO. > With Path MTU Discovery, the only protocol that should be able to generate > fragments at the v6 level is UDP, which cannot transport data longer than > 65535 bytes(?) long due to its own length field. There is no reasonable > case that I can see where it would be a problem to simply require that > reassembled payloads end up 65535 bytes or less in length. Can anyone > else see a problem with this? Does upper-bounding the size of a fragmented > payload to this number make sense? ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Jul 6 05:25:03 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12758; Thu, 6 Jul 95 05:25:03 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12752; Thu, 6 Jul 95 05:24:49 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AB09835; Thu, 6 Jul 1995 05:14:42 -0700 Received: from wintermute.imsi.com by mercury.Sun.COM (Sun.COM) id FAA06222; Thu, 6 Jul 1995 05:14:42 -0700 Received: from relay.imsi.com by wintermute.imsi.com id IAA27701; Thu, 6 Jul 1995 08:13:54 -0400 Received: from snark.imsi.com by relay.imsi.com id IAA02806; Thu, 6 Jul 1995 08:13:54 -0400 Received: by snark.imsi.com (4.1/SMI-4.1) id AA01680; Thu, 6 Jul 95 08:13:53 EDT Message-Id: <9507061213.AA01680@snark.imsi.com> To: "Brian Carpenter CERN-CN" Cc: ipng@sunroof.Eng.Sun.COM (IPv6 List) Subject: (IPng 350) Re: Another fragmentation/reassembly question: big payloads In-Reply-To: Your message of "Thu, 06 Jul 1995 08:55:17 +0200." <9507060655.AA21085@dxcoms.cern.ch> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Thu, 06 Jul 1995 08:13:53 -0400 From: "Perry E. Metzger" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk "Brian Carpenter CERN-CN" writes: > As a jumbogram proponent, I agree with Craig. I would hope that > jumbograms are only used on paths with adequate MTUs, preferably > on switched LANs such as HiPPI with no intermediate router. > That is the only case where they make sense. Its the only place they make sense *right now*. When networks are routinely thousands of times faster, which will not be so long from now measured by the scale of any industry other than ours, we may strongly appreciate the ability to send entire compressed video wall frames or whatever else we happen to want to send over our WANs in single packets. However, I agree that fragmentation is unlikely to be desirable even then, and path MTU discovery will probably be used to assure we don't exceed the limits. I just wanted to dispute the notion that this stuff would only be useful on odd local networks without routers. Perry ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Jul 6 10:14:20 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12833; Thu, 6 Jul 95 10:14:20 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12619; Wed, 5 Jul 95 23:42:52 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA28926; Wed, 5 Jul 1995 23:32:03 -0700 Received: from pec.etri.re.kr by mercury.Sun.COM (Sun.COM) id XAA17002; Wed, 5 Jul 1995 23:30:24 -0700 Received: by pec.etri.re.kr (8.6.9H1/8.6.4) id PAA19557 From: Myung Soon Kim Posted-Date: Thu, 6 Jul 1995 15:02:09 +1000 Message-Id: <199507060502.PAA19557@pec.etri.re.kr> Subject: (IPng 351) ICCC'95 To: larovere@omega.Incc.br, puges@TRANSPAC.atlas.fr, jhpark@einstein.postech.ac.kr, hvisage@rkw-risc.cs.up.ac.za, hvisage@dos-lan.cs.up.ac.za, shlee@cbucc.chungbuk.ac.kr, hipparch@sophia.inria.fr, xtp-relay@cs.concordia.ca, ipng@sunroof.Eng.Sun.COM, osimcast@B Date: Thu, 6 Jul 1995 15:02:07 +0900 (GMT+9:00) Cc: osimcast@BBN.COM, sigmedia@bellcore.com, ietf@ISI.edu, sc6wg4@ntd.comsat.com, rem-conf@es.net, ilka@prz.tu-berlin.de, kathie@katmandu.svi.org, az@prz.tu-berlin.de, thomas@priz.tu-berlin.de, g.carle@ieee.org, mckim@case.kotel.co.kr, hf@hugo.int-evry.fr, fou@pec.etri.re.kr X-Mailer: ELM [version 2.4 PL21-h4] Content-Type: text Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk -------------------------------------------------------------------------------- Information about ICCC'95 is now available on the World Wide Web at the following address : * http://most.etri.re.kr/iccc/ -------------------------------------------------------------------------------- Following is the second announcement of Call For Participation of ICCC'95 which will be held 21-24 of August 1995, in Seoul, Korea. -------------------------------------------------------------------------------- ICCC'95 CALL FOR PARTICIPATION *********************************************************** * 12th International Conference On Computer Communication * *********************************************************** ******************************************* * August 21-24, 1995 * * Hotel Intercontinental, Seoul, Korea * ******************************************* Sponsored by ICCC - International Council for Computer Communication Hosted by ETRI - Electronics and Telecommunications Research Institute KISS - Korea Information Science Society Under the patronage of Ministry of Information and Communication, Republic of Korea Conference Site Hotel Intercontinental Trade Center, P.O.Box 87 159-8 samsung-dong, kangnam-Ku, Seoul, Korea 135-732 Tel:+82-2-555-5656, Telex:K33970 ,Fax:+82-2-559-7990 ADVANCE PROGRAM --------------------- Conference Governor Honorary Conference Chairman ------------------- ---------------------------- Dr. Ronald P. Uhlig Dr. Kyong Sang Hyon Qualcomm, USA Minister, MIC, Korea Conference Chairman Conference Co-chairman --------------------- ----------------------- Prof. Chongsun Hwang Dr. Seungtaik Yang President,KISS,Korea President,ETRI,Korea Technical Program ----------------------- Chair:Dr. Seonjong Chung ETRI,Korea Co-chairs:Dr.Roger Needham Dr. Otto Spaniol Univ. of Cambridge, UK Achen Tech. Univ. Prof. Sergio Fdida Dr. Nicolas Georganas MASI, France Univ. of Ottawa, Canada Dr. Pramode Verma Dr. Hideyoshi Tominaga AT&T,USA Waseda Univ. Japan Publication ------------- Mr. Keosang Lee DACOM,Korea Publicity ----------- Prof. Jaiyong Lee Yonsei Univ.,Korea Registration -------------- Dr. Samyoung Seuh N.C.A.,Korea Treasurer ---------- Dr. Seungkyu Park Ajou Univ.,Korea Social Program ---------------- Dr.Noshik Kim Korea Telecom,Korea Secretary Co-Secretary ----------- -------------- Prof. Yangheei Choi Dr. Younghee Lee Seoul National Univ.,Korea ETRI, Korea Tutorial ---------- Prof. Sunshin An Korea Univ.,Korea Local Arrangements ------------------ Prof. Dongho Lee Kwangwon Univ.,Korea ******************* Keynote Addresses ******************* Tuesday, August 22 10:55 - 12:20 =============================== 1. "Network Intelligence for Information Superhighway" Dr. Louis Pouzin, THESEUS, France 2. "Information & Communication Policy in Korea" Mr. Hongshik Jung Ministry of Information and Communication(MIC), Korea 3. "The Telecommunications Policy Debate in the US - Where is it headed and what will be the effects on NII and GII development." Mr. Tomas J. Sugrue National Telecommunications and Information Administration(NTIA), USA *********** TUTORIALS *********** Monday, August 21, 1995 ======================= T1. "Multimedia Networking: Applications Requirements, Network Infrastructures, Protocols and Servers" Instructor: Fouad A. Tobagi, Stanford University; tobagi@bodega.stanford.edu T2. "Physical and MAC Layers in Cellular Wireless Communication Networks (With Special Emphasis on CDMA Standards)" Instructor: Arogyaswami Paulraj, Stanford University; paulraj@sprite.stanford.edu T3. "Distributed Multimedia Systems and Applications" Instructor: Borko Furht, Florida Atalantic University; borko@cse.fau.edu T4. "Broadband Networking with ATM" Instructor: Anujan Varma, University of California; varma@cse.ucsc.edu ******************** Technical Sessions ******************** Tuesday, August 22 14:00 - 15:30 ================================= Session 1A Information Superhighway ------------------------ 1A.1 R&D Strategy for Technologies for an Integrated Ultra-high Speed Network and Computer System Masahiro Taka, Ultra-high Speed Network and Computer Technology Laboratories(UNCL), Japan 1A.2 A Comprehensive Plan for the Korea Information Infrastructure Joun Cheon, MIC, Korea 1A.3 Information Highways and Competitiveness of Telecommunication Services Firms in Brazil Renata Lebre La Rovere, Universidade Federal do Rio de Janeiro, Jorge Fagundes, Faculdades Integradas Candido Mendes, Brazil Invited Paper: NII Project in R.O.C. - Deployment and Applications of Broadband Trial Network Dr. Jin-Tuu Wang, Telecommunication Laboratories(TL), Taiwan Session 1B Multimedia Communication 1 -------------------------- 1B.1 Statistical Real-Time Channels on Multiaccess Networks Chih-Che Chou, Kang G.Shin, University of Michigan, USA 1B.2 A Multimedia-on-Demand System with End-to-End Quality of Service Guarantees Lek Heng Ngoh, Huanxu Pan, National University of Singapore, Singapore, Aurel Lazar, Columbia University, USA 1B.3 Controlling Agent Interactions in a Tightly Coupled Multiagent Framework Joongmin Choi, Sangkyu Park, Myeongwuk Jang, Sooncheol Baeg, Gwanglo Lee, Younghwan Lim, ETRI, Korea 1B.4 Interactive Multimedia - Services, Success Factors and End-to-End Network Solutions Manfred Gand, Siemens AG, Germany Session 1C ATM Switching 1 --------------- 1C.1 Performance Analysis for ATM Switching of Mixed Continuous-Bit-Rate and Bursty Traffic with Smoothing Function Liao Jianxin, Li Lemin, Lai Guangming, University of Electronic Science and Technology of China, China 1C.2 Design of Network of ATM Switch with Simple Fault Detection Method Jongin Jung, Sungchun Kim, Seogang University, Korea 1C.3 A Novel Architecture for Priority Handling in an ATM Multicast Switch Young C.Oh, Suresh Rai, Lousiana State University, U.S.A 1C.4 Cut Through Routing in Shared Buffered Banyan Networks Seong Leong Ng, Bill Dewar, University of New South Wales, Australia Session 1D High-speed Protocols 1 ---------------------- 1D.1 Modeling of Function-Based Communication Protocol Entities for Performance Assessment, Application to XTP Atika Cohen, Radouane Mrabet, Universite Libre de Bruxelles, Belgium 1D.2 Performance Analysis of a k-Reliable Multicast ARQ Protocol Bongtae Kim, Harry G Perros, Arne A Nilsson, North Carolina State University, USA 1D.3 A Fair and Efficient Access Control Method for High Speed Multimedia LAN and MAN Tadao Saito, Hitoshi Aida, Onur Altintas, Byungsuk Kim,Terumasa Aoki, University of Tokyo, Japan 1D.4 A New Ring Protocol for ATM-MAN Cheul Shim, Keehyun Park, Junho Lee, Jaiyong Lee, Sangbae Lee, Yonsei University, Korea Tuesday, August 22 15:50 - 17:20 ================================= Session 2A Network Architecture -------------------- 2A.1 Design of a Modular and Efficient Communication Subsystem Torsten Braun, Jochen Schiller, Claudia Schmidt, Martina Zitterbart, University of Karlsruhe, Germany 2A.2 Open Platform for Group-working in ODP Environments Changwook Lee, Yongjin Park, Hanyang University, Korea 2A.3 The Design of A Fault-Tolerant ATM Network Chi-Chun Lo, Chen-Yu Chiou, National Chiao-Tung University, Taiwan 2A.4 Architecture of a European-wide Backbone Network A.Hyron, P.Louazel, P.Puges, France Telecom, France Session 2B Multimedia Communication 2 -------------------------- 2B.1 How Smart Valley, Inc. is Creating an Electronic Community in the San Francisco Bay Area Harry J. Saal, Smart Valley. Inc., USA 2B.2 Multi-Carrier Modulation for Multimedia Communications: Symbol Timing and Carrier Phase Synchronization Issues Thierry Pollet, Marc Moeneclaey, University of Ghent, Belgium 2B.3 Performance Analysis of Leaky Bucket Algorithm with Bursty Traffic Input in ATM Networks Sun Hairong, Li Lemin, University of Electronic Science & Technology of China, China 2B.4 Proposal of Architecture for Video on Demand System over ATM Network Keigo Ihara, Yasuhiko Yasuda, Waseda University, Kinji Ono, NCSIS, Japan Session 2C Computer Communication 1 ------------------------ 2C.1 Sojourn Time Analysis of Prioritized DQDB (IEEE802.6) MAN with Bursty Traffic Input Sun Hairong, Li Lemin, University of Electronic Science & Technology of China, China 2C.2 FADM : A New Access Control Method for Distributed Access Subscriber Network Tadao Saito, Hitoshi Aida, Byungsuk Kim, University of Tokyo, Japan 2C.3 Providing Internet Email to the Campus Community at the Lahore University of Management Sciences, Lahore, Pakistan Sohail Aslam, Lahore University of Management Sciences, Pakistan 2C.4 Distributed Mutual Exclusion on Hypercubes Mohamed Naimi, Laboratoire d'Informatique de Besancon, France Session 2D Intelligent Network 1 --------------------- 2D.1 An Object-based Model of the Service Control Function Boris Makarevitch, Helsinki University of Technology, Finland 2D.2 Intelligent Networking-from Narrowband to Broadband Richard B. Robrock II, Bell Communications Research Inc., USA 2D.3 Performance Evaluation of Intelligent Networks Accommodating Various IN Services as well as Basic ISDN Services Minyoung Chung, Dankeun Sung, KAIST, Korea Invited Paper: Evolution of Intelligent Networks Dr. Ronald P. Uhlig, Qualcomm, USA Wednesday, August 23 9:00 - 10:30 ================================== Session 3A Network Management 1 -------------------- 3A.1 Tempo's Transport Quality of Service Stefan Bocking, Siemens AG, Rainer Schatzmayr, TU Berlin, Germany 3A.2 Priority Management to Improve the QOS for Shared Memory ATM Switch Sohail Ahmed, Universiti Pertanian Malaysia, Malaysia 3A.3 Modeling and Management of Distributed Applications and Services Using the OSI Management Framework James W.Hong, Michael J. Katchabaw, Michael A. Bauer, Hanan Lutfiyya, University of Western Ontario, Canada 3A.4 A Delegation Approach on an Application Gateway for Heterogeneous Network Managements Taeyeon Kim, Youngkyun Kim, Bongnam Noh, Chonnam National University, Korea Session 3B Mutimedia Communication 3 ------------------------- 3B.1 Multicast Scheduling for VOD Services Heekyoung Woo, Jichul Park, Chongkwon Kim, Seoul National University, Korea 3B.2 An Efficient Backward Compatible Video Coding Method for MPEG-1 and MPEG-2 Standards Kijin Kim, Soonkak Kwon, Jaekyoon Kim, KAIST, Korea 3B.3 Error Control Schemes for Improving the Performance of MPEG-based Video Communications over ATM Networks Taeseop Han, Luis Orozco-Barbosa, University of Ottawa, Canada 3B.4 An Object Oriented Network Simulation Testbed for Real Time Multimedia Applications Sandeep Kumar, P.Venkataram, Indian Institute of Science, India Session 3C ATM Switching 2 --------------- 3C.1 On the Performance Evaluation of an ATM Switch with Bursty Traffic and Nonindependant Routing Sabine Wittevrongel, Herwig Bruneel, University of Ghent, Belgium 3C.2 Analysis of ATM Switch with Feedback Input Queuing and Output Queuing under Bursty Traffic Ghassan Kbar, William J. Dewar University of New South Wales, Australia 3C.3 Design of a Cost-Effective Modular Architecture for Very Large ATM Switches K. H. Cho, J. H. Park, B. S. Kwon, S. Eun, H. Yoon, KAIST, Korea 3C.4 Analysis of Priority Control Mechanism with Two Thresholds in ATM Switch Network Wongi Park, Youngsun Kim, Chimoon Han, ETRI, Hyoungjin Choi, Sungkyunkwan University, Korea Session 3D Wireless Communication 1 ------------------------ 3D.1 An Improved Leader Election Protocol in Multi-hop Radio Networks Chungki Lee, NCA, Korea, Mostafa H. Ammar, Georgia Institute of Technology, James E. Burns, Bellcore, USA 3D.2 Scheduling Algorithms for Packet Radio Networks Mark L. Huson, Arunabha Sen, Arizona State University, USA 3D.3 HF Radio Prediction Services for PC Communication Kyujin Wee, Seokhee Bae, Radio Research Lab, MIC, Daejoong Kim, Seongkyeong Park, Changeon Kang, Yonsei University, Korea 3D.4 Voice and Packet Data Integration over GSM Networks Giuseppe Bianchi, Antonio Capone, Luigi Fratta, Luigi Musumeci, Politecnico di Milano, Italy Wednesday, August 23 10:50 - 12:20 =================================== Session 4A Network Planning ---------------- 4A.1 Modular Network Planning of Peruvian University Eduardo Gorritti Castro, Aurora Ruiz Rosado, Antenor Orrego University, Peru 4A.2 Communication by Computer : A Proposal of Development to Peru Esteban Rafael Estrada Hora, Cesar Angusto Ramires Luna Victoria, Antenor Orrego University, Peru 4A.3 Differences in Network Planning for Wireless Local Loop and Mobile Wireless Systems Bracha Epstein, Moshe Levin, Tadiran Telecommunications, Israel 4A.4 Use of Conjoint Measurements for an Optimal Design of International Telephone Services Christian Eggenberger, Christof Hauser, University of St. Gallen, Switzerland Session 4B Broadband Communication 1 ------------------------- 4B.1 A Modular Transport Network Node Gerald Lebizay, IBM Lab., France 4B.2 Design Method for Virtual Path Based ATM Networks with Multiple Traffic Classes Byunghan Ryu, Hiroyuki Ohsaki, Masayuki Murata, Hideo Miyahara, Osaka University, Japan 4B.3 A Compatible ATM-DQDB Interconnection in a Broadband Multi-Internetworking Unit Xavier Hesselbach, Sebasti Sallent, Politechnic University of Catalonia, Spain 4B.4 Dynamic Virtual Path Bandwidth Control over Multiple Transmission Links in an ATM Network Eunjoo Ha, Jaehyuk Do, Jongtae Park, Kyungbuk National University, Chimoon Han, ETRI, Korea Session 4C Computer Communication 2 ------------------------ 4C.1 Performance Evaluation of A Deferred Write Technique as a Recovery Technique in Client-Server DBMS Y. Jeon, F.Lombardi, Texas A & M University, USA 4C.2 ATM Switches in Computer Networks, A Proposal for the LAN Environment Hendrik Visage, University of Pretoria, South Africa 4C.3 An Application Configuration for Information Delivery Systems in a Distributed Processing Environment Junichi Kikuchi, Takeya Mukaigaito, Hiroshi Masamoto, Manabu Tsukuda, NTT, Japan 4C.4 Practical Performance Analysis of UDP/IP and TCP/IP over ATM with Special Regard to Protocol-, Operating System- and ATM Layer Limitations Andree Zehl, Thomas P.Kusch Technical University of Berlin, Germany Session 4D Performance Analysis -------------------- 4D.1 MMBP[X]/G/1 Queues and Their Application to the Approximation of the Performance of ATM Switches Mowcheng Lee, ITRI, Taiwan, C. Y. Roger Chen, Syracuse University, USA 4D.2 On the Prediction of the Stochastic Behavior of Time Series by Use of Neural Networks - an Application to Source Modelling $)C Markus D. EbersplAher, University of Stuttgart, Germany 4D.3 Analysis of Optimal Scheduling in Distributed Parallel Queueing Systems Mark S. Squillante, IBM, Konstantinos P. Tsoukatos, University of Maryland, USA 4D.4 Modeling of SONET Links for Per-Session Study of an ATM Multiplexer Rajesh I. Balay, Arne A. Nilsson, North Carolina State University, USA Wednesday, August 23 14:00 - 15:30 =================================== Session 5A Security and Privacy 1 --------------------- 5A.1 Intrusion Detection : A Survey Mansour Esmaili, Reihaneh Safavi-Naini, Josef Pieprzyk, University of Wollongong, Australia 5A.2 Fast Software Encryption Systems for Secure & Private Communication Moldovyan A. A., Institute of Modeling and Intellectualization of Complex Systems, Moldovyan N. A., Academy of Sciences of Moldova Republic, Russia, Moldova 5A.3 A Secure Communication Scheme Using Chaotic Signals Chungyong Lee, Jaejin Lee, Douglas B. Williams, Georgia Institute of Technology, U.S.A 5A.4 A Secure Multiway Election Scheme Sungjun Park, Dongho Won, Sungkyunkwan University, Korea Session 5B Protocol Engineering 1 ---------------------- 5B.1 Automated Verification in an Integrated Protocol Development Environment Ajin Jirachiefpattana, Richard Lai, La Trobe University, Australia 5B.2 High Performance ASN.1/BER Decoder Sunwan Choi, ETRI, Korea 5B.3 Test Generation from SDL Specifications and Input/Output Finite State Machines Byungmoon Chin, ETRI, Korea, Anna R.Cavalli, Toma Macavei, Institut National des Telecommunications, France 5B.4 Designing Tests for Time Dependant Systems Ousamane Konmh Universit Bordeaux I, France Session 5C ATM Traffic 1 ------------- 5C.1 Flow Control of ABR Traffic in ATM Networks Using a Two-level Scheme Wales Kin Fai Wong, Danny H.K.Tsang, Hong Kong University of Science and Technology, Hong Kong 5C.2 Effective Bandwidth Techniques in Bufferless and Buffered ATM Multiplexers B. G. Kim, I. G. Niemegeers, University of Twente, The Netherlands 5C.3 On an Extension of Leaky Bucket Algorithm: Leaky Bucket Algorithm with Multiple Token Rates Dirceu Cavendish, Yuji Oie, Kyushu Institute of Technology, Tetsuya Takine, Osaka University, Japan 5C.4 On GA-based Optimal Dimensioning of Three-Level Traffic Shaper for Statistical Multiplexing in ATM Networks Kyeongsoo Kim, Byeonggi Lee, Seoul National University, Korea Session 5D High-speed Protocols 2 ---------------------- 5D.1 An Integrated Packet Scheduling Algorithm for Highspeed Packet-Switched Wide-Area Networks Jaechang Kwak, Seokyeong University, Korea 5D.2 Robust Communication Protocols for Run-Time Fault Detection G.Noubir, K.Vijayananda, Swiss Federal Institute of Technology, Switzerland 5D.3 A New Presentation Layer Protocol for Partitioned Syntax Transformation Model Guy Berthet, Swiss Federal Institute of Technology, Switzerland 5D.4 Improving End-to-End Throughput for Bulk Data Transfers Tadao Saito, Hitoshi Aida, Onur Altintas, Terumasa Aoki, University of Tokyo, Japan Panels ====== Wednesday, August 23 15:50 - 17:20 =================================== Panel 1 : What does Information Superhighway stand for in your mind? What is its impact on our society? Panel 2 : What are the real issues in current multimedia communications, QOS, Standardization or Services? Panel 3 : Security / Privacy vs. Accessibility in Information Networks. Panel 4 : Will personal/wireless communications dominate over the wire communications? Thursday, August 24 9:00 - 10:30 ================================= Session 6A Network Management 2 6A.1 Multimedia Communication Management Architecture for Information Highways Wonkyu Hong, Eunho Choi, Korea Telecom, Korea 6A.2 A Model for a Time Reference Network Management System Theodore K. Apostolopoulos, Victoria Daskalou, Athens University of Economics and Business, Greece 6A.3 A Group Communication Protocol for Distributed Network Management Systems Kwanghui Lee, Changwon National University, Korea 6A.4 Using BAN logic for the proof of Network Address Integrity Yuko Murayama, Hiroshima City University, Japan Session 6B Protocol Engineering 2 ---------------------- 6B.1 An Integrated Tool for LOTOS Development Ana Cavalli, Patrick Maigron, INT, Hacene Fouchal, Universite de Reims Champagne-Ardennes, France, Sungun Kim, Korea Telecom, Korea 6B.2 Design and Implementation of CFG generator for Estelle Specification Jaehong Park, Cheeha Kim, Jaiyong Lee, POSTECH, Yonsei Univsersity, Korea 6B.3 Specification and Verification, a Unified Approach Anthony Wiles, Anders Ekman, Telia Research AB, Sweden 6B.4 DQDB Networks with a Fast Global Information Scheme Hasein I. Sigiuk, B. H. Pardoe, University of Salford, United Kingdom Session 6C Computer Communication 3 ------------------------ 6C.1 Integrated Multilevel Secure System for Information Retrieval in Distributed Computer Systems Haklin Kimm, University of Tennessee, USA, Jaeyoung Rhi, Samsung Data Systems, Korea 6C.2 On the Use of a Stochastic Estimator Learning Algorithm to the ATM Routing Problem : A Methodology Athanasios V. Vasilakos, Hellenic Air Force Academy, Greece 6C.3 Design of High Performance OSI Software over ATM Network Toshihiko Kato, Toru Hasegawa, Akira Idoue, Kenji Suzuki, Yoshiyori Urano, KDD R&D Lab., Japan 6C.4 Modeling Optimal Overload Control in Distributed Control Systems Ulf Ahlfors, Christian Nyberg, Lund Institute of Technology, Sweden Session 6D Intelligent Network 2 --------------------- 6D.1 A New Traffic Regulation Scheme for SCP Jyhi-Kong Wey, Lir-Fang Sun, Ministry of Transportation and Communications, Wei-Pang Yang, National Chiao Tung University, Taiwan 6D.2 A Petri-Nets Based Approach for Detecting Feature Interactions in Telecommunications Services Junghun Choi, ETRI, Hyeonsoo Kim, Woojin Lee, Yongrae Kwon, KAIST, Korea 6D.3 Transient and Stationary Investigations of Overload Control in Intelligent Networks Maria Kihl, Christian Nyberg, Lund Institute of Technology, Sweden 6D.4 An Implementation of VPN Service on the TDX-10 SSP Hyungik Kim, Seokhun Kim, Jeyseung Lee, Minyong Ahn, Korea Telecom, Korea Thursday, August 24 10:50 - 12:20 ================================== Session 7A Security and Privacy 2 ---------------------- 7A.1 Security for Local Area and Wide Area Networked Computer Communications Vijay Varadharajan, University of Western Sydney, Australia 7A.2 A Key Distribution and Authentication Method on the Q.931 Calling Sequence of ISDN Taekyoung Kwon, Jooseok Song, Yonsei University, Korea 7A.3 Reconfiguration for Service Growth and Self-healing in ATM Networks Based on Virtual Paths Tai H. Noh, AT&T Bell Lab.Dhadesugoor R. Vaman, Xuedao Gu, Stevens Institute of Technology, USA 7A.4 The Extended LFSRs and their Applications to the High Speed Data Protections Seungcheol Goh, Sangjin Lee, Seoungtaek Chee, Sangwoo Park, ETRI, Korea Session 7B Broadband Communication 2 ------------------------- 7B.1 Optimal Sequential Decoding Algorithm in the Land Mobile Fading Channel Jaechoong Han, Goldstar Co. Central Research Lab., Korea, Costas N. Georghiades, Texas A&M University, USA 7B.2 A Pre-negotiation Dynamic Bandwidth Management Algorithm for ATM Connectionless Service Hyunchul Cha, Kijun Han, Kyungpook National University, Korea 7B.3 QOS based Routing for High Speed Environment L. Franck, B. Sales, Brussels Universities, Belgium 7B.4 Service Multiplexing in an ATM Environment Paulo Monteiro, Augusto Casaca, Serafim Nunes, INESC, Portugal Session 7C Optical Communication & Forward Error Correction ------------------------------------------------ 7C.1 Architecture and Performance Evaluation of Future Photonic Networks Jan Spath, Ulrich Gremmelmaier, Uwe Briem, University of Stuttgart, Manfred N. Huber, Simens AG, Germany 7C.2 Limits to Optical Switch Matrices Set by Phase Noise from Semiconductor Optical Amplifiers Joao J. O. Pires, Instituto Superior Tecnico, Portugal 7C.3 Improved Algorithm of the Trace Computation on Trinomial Irreducible Polynomial for RS Code Changho Seo, Jongin Lim, Injeong Chung, Korea University, Korea 7C.4 Performance Analysis of DT-WDMA Protocol Hyun K. Kahng, Jooyoung Park, Korea University, Korea Session 7D Wireless Communication 2 ------------------------ 7D.1 A Design of a MAC Layer Protocol for CBR and VBR Data Transmission on a Single Channel in Wireless LANs P. Venkataram, S. R. Pawamana, Indian Institute of Science, India 7D.2 Performance Evaluation of Priority Packet Reservation Multiple Access and Adaptive Packet Reservation Multiple Access Wu Xiaowen, Huang Shunji, Li Lemin, University of Electronic Science and Technology of China, China 7D.3 Performance of Code Tracking Loop for a Direct-Sequence Spread-Spectrum System in a Mobile Fading Channel Jinyoung Kim, Jaehong Lee, Seoul Natioanl University, Korea Invited Paper: Modern Digital Solutions for Wireless Local Loop Using CDMA Technology Dr. Peter E. Jackson, QUALCOMM, USA Thursday, August 24 14:00 - 15:30 ================================= Session 8A Highspeed Networks ------------------ 8A.1 On Merging and Splitting of Self-Similar Traffic in High Speed Networks Yanhe Fan, Nicolas D.Georganas, University of Ottawa, Canada 8A.2 Effective Priority Control and Addressing Scheme for High Speed Ring Network Sunmoo Kang, Byungchun Jeon, ETRI, Daeyoung Kim, Chungnam National University, Korea 8A.3 CapNet-Shared Memory Distributed Computing over Wide Area High Speed Networks Ming-Chit Tam, David J.Farber, University of Pennsylvania, U.S.A Invited Paper: Fast Communications and Slow Computers Dr. Roger Needham, University of Cambridge United Kingdom Session 8B Broadband Communication 3 ------------------------- 8B.1 Fault-Tolerant ATM LAN/LAN Interworking Inter-LAN Connectionless Data Services E. T. Powner, A. Odeh, Y. Wang, University of Sussex, United Kingdom 8B.2 Simulation Study of CAP in High Bit Rate Asymmetrical Digital Subscriber Line (ADSL) Envirnment Ajit Reddy, Syed V. Ahamed, CUNY, U.S.A 8B.3 Towards Scalable Error Control for Reliable Multipoint Services in ATM Networks Georg Carle, University of Karlsruhe, Germany 8B.4 Relationships among Inter-Dependant Real-Time Streams Luca Delgrossi, Sibylle Schaller, Lars Wolf, IBM European Networking Center, Germany Session 8C ATM Traffic 2 ------------- 8C.1 The Use of Learning Algorithms in ATM Networks Call Admission Control Problem : A Methodology Athanasios V.Vasilakos, Hellenic Air Force Academy, Greece 8C.2 Characterizing Variation of Traffic Parameters in ATM Networks Using Neural Networks Ibrahim Khalil, Borhanuddin Mohd Ali, M.R.Mukerjee, Universiti Pertanian Malaysia, Malaysia 8C.3 A Simple Dynamic Bandwidth Allocation Scheme for ATM Networks Han Zhou, C. H. Chang, Tufts University, USA, D. T. Han, Beijing Steel College, China 8C.4 A Rate Based Flow Control Switch Design for ABR Service in an ATM Network Yoon Chang, Nada Golmie, David Su, NIST, USA Session 8D Satellite Communication ----------------------- 8D.1 Object-Oriented B-ISDN Service Modeling Juhyun Ryu, Cheong Youn, Chungnam National University, Jaeil Jung, Jiyoung Kim,Korea Telecom Korea 8D.2 A Comparison of Satellite and Terrestrial Implementaions of the National Research and Education Network Junghwan Kim, R. M. Buehrer, Mark Keaton, Subash C. Kwatra, William Curry, University of Toledo, USA 8D.3 Multibeam-Switched Demand-Assigned Multiple Access for On Board the Satellite with Data Buffer Doug N. Kim, ETRI, Korea Invited Paper: Dr. K.M.S. Murthy, VISTAR Telecom, Canada Thursday, August 24 15:50 - 16:50 ================================== Session 9A Evolution toward the Highspeed Networks --------------------------------------- 9A.1 A Network Architecture for Multimedia Multiparty Services and the Impact on B-ISDN Control Evolution Luigi Ronchetti, Luca Cipriani, Stefano Salsano Ericsson Telecomunicazioni SpA, Italy 9A.2 Transition to High Speed Network-Super JANET Experience Kicheon Kim, Steven Simpson, David Hutchison Lancaster University, United Kingdom 9A.3 The Evolution of Packet Data Networks : The ATM Opportunity F. Perardi, F.Ferrero, CSELT, R. Pietroiusti, F. Cataldi, Telecom Italia, Italy Session 9B Distance Learning ----------------- 9B.1 An Internet Based Collaborative Distance Learning System : CODILESS Kazuo Watabe, University of Shizuoka, Japan, Matti Hamalainen, Espoo-Vantaa Institute of Technology, Finland, Andrew B. Whinston, University of Texas at Austin, USA 9B.2 Designing Mulitmedia Learning Environments for Anesthetic Methods in Medical Practice Jorn Nilsson, Lund University, Sweden 9B.3 Frame Rate Control in a Multimedia Distance Learning System Lj. Josifovski, S. Gievska, D. Davcev, St. Kiril & Metodij University, Skopje R. of Macedonia Session 9C Computer Communication 4 ------------------------ 9C.1 A Framework on the Design of Communication Gateways Zhong Ping Tao, University of Montreal, Canada 9C.2 A Delay Constrained Distributed Multicast Routing Algorithm Sunjoo Wi, Yanghee Choi, Seoul National University, Korea 9C.3 A Ring Network with Two Tokens Rashid Al-Naami, Doha, Qutar Session 9D Personal Communication Systems ------------------------------ 9D.1 Dynamic Channel Assignment Using Channel Interleaving in the One Dimensional Reuse Partitioning System Kwangmoon Cho, Taiyun Kim, Korea University, Korea 9D.2 SCAI: Integration of Computer and Telecommunications Switches in North American Intelligent Networks for Universal Personal Communications and Multimedia Communications Hazem El-Gendy, EPEC Inc., Canada 9D.3 Performance Analysis of Cellular Mobile Communications under Multipath Interference Jyh-Horng Wen, National Chung Cheng University, Taiwan *************** Social Events *************** Welcome Reception(Cocktail) ----------------------------- A welcome Cocktail Party will be held at p.m. 7 Monday evening, August 21 at Hotel Intercontinental. All conference attendees and spouses are invited. Dinner -------- A Hosted Dinner Party is also scheduled for Tuesday evening, August 22. The place for the party will be announced during the conference. All conference attendees and spouses are invited. Conference Banquet ------------------- Banquet will be held on Tuesday Evening, August 23 Hotel Intercontinental. You Can buy tickets when you register for ICCC'95 on site. Participants who register in advance can also get the tickets from the receptionists by showing the receipt of your pre-registration during the conference. The Banquet ticket is $50. Luncheon ---------- A Luncheon hosted by one of the major telecommunication company in Korea will be on 24th. The schedule is subject to change. The exact date and place for that will be posted during the conference. Industrial Tour ---------------- A free technical visit hosted by four major Korean Telecommunications Indistries - Samsung Electronics Co. Ltd., Hyundai Electronics Co., Daewoo Telecom Ltd., LG Information and Communication Ltd. - is scheduled on 25th, August, the following day of the conference. More detailed information will be available later at Information Desk. Registration for Technical Visit will be accepted during the conference at ICCC'95 Information Desk. ============================< CUT HERE >================================= ****************************** * ADVANCE REGISTRATION * * (Deadline : July 25) * ****************************** PLEASE MAIL OR FAX TO : Korea Information Science Society TEL:+82-2-588-9246 KPO BOX 1205 Seoul, Korea FAX:+82-2-521-1352 OR EMAIL TO : ICCC'95 Email:iccc-reg@krnic.net Name:(last/family)_________________________(first)______________(Mr./Mrs./Ms.) Company:______________________________________________________________________ Address/Mailstop:_____________________________________________________________ City/State/Zip/Country:_______________________________________________________ Daytime Number:_____________________________FAX Number:_______________________ E-mail:_____________________________________ Name of Spouse(Guest):_____________________________ PLEASE CHECK APPROPRIATE FEES: -- CONFERENCE REGISTRATION: Reglar Student --------- --------- Advance Registration(Until July 25, 1995) $450(w360,000) $50(w40,000) Late/On-site Registration(August 21, 1995) $500(w400,000) $100(w80,000) -- TUTORIAL REGISTRATION: Regular Student --------- --------- Advance Registration(Until July 25, 1995) $200(w160,000) $100(w80,000) Late/On-site Registration(August 21, 1995) $250(w200,000) $150(w120,000) -- BANQUET TICKET: Per-person $50(w40,000) TOTAL ENCLOSED:$___________________ METHOD OF PAYMENT: ____Moneyorder ____Mastercard ____Visa ____Other Credit Card Number:_________________ EXP. Date:__________________ Cardholder Name:______________________ Signature:____________________________ ................................................................................ -In case you want cancel your pre-registration, please notify to Korean Information Science Society before July 25. If you do so by July 25, you will receive a 90% refund. If you do so between July 25 and August 14, you will receive a 70% refund. ===========================< CUT HERE >================================== ********************************** * HOTEL RESERVATION FORM * * (deadline : July 20, 1995) * ICCC'95 ********************************** Please Mail or FAX to : LISTED HOTELS BELOW. Name:(Last/Family)______________________(first)_________________(Mr./Mrs./Ms.) Address:_____________________________________________________________________ City/State/Zip/Country:______________________________________________________ Phone Number:____________________________FAX Number:_________________________ Sharing Room with:___________________________________________________________ Check-in___________(Fl. No. ) Check-out________________(Fl. No. ) HOTEL REFERENCE : ICCC'95 Secretariat offically recommend 5 hotels which offer special group rates for ICCC'95 participants. -------------------------------------------------------------------------------- Hotel Distance(by taxi) Rate(Unit: Won) Tel Fax -------------------------------------------------------------------------------- Intercontinental 0 Deluxe Room 127,000 +82-2-559-7777 +82-2-559-7995 ***** Jr. Suite 165,000 -------------------------------------------------------------------------------- Riviera 5 min Double 93,750 +82-2-541-3111 +82-2-546-6111 **** Twin 101,250 -------------------------------------------------------------------------------- Novotel 10 min 1 person 105,000 +82-2-531-6522 +82-2-562-0120 **** 2 persons -------------------------------------------------------------------------------- New World 5 min 93,800 +82-2-557-0111 +82-2-557-0141 **** -------------------------------------------------------------------------------- Clover 15 min 42,000 +82-2-546-1414 +82-2-544-1340 ** -------------------------------------------------------------------------------- * 10% service charge and 10% tax will be added on the above rates. * Hotel International has a double occupancy rate which is 20,000 Won, and Jr. Suite includes breakfast. * 1 US$ is about 800 Won. Name of Hotel:______________________________ Number of Room Required ____Single ____Double ____Twin ____Suite No. of nights___________________ Indicate Special Request and Comments:_________________________________________ _______________________________________________________________________________ Method of Payment: ____American Express ____JCB ____Visa ____Mastercard ____Diners Club Credit Card Number:____________________Exp. Date:___________________________ Cardholder Name:_______________________ Signature:__________________________ ================================================================================ Please return this form to the corresponding hotel. Hotel Address: Riviera: 53-7, Chongdam-dong, Kangnam-gu, Seoul, Korea Novotel: 603, Yoksam-dong, kangnam-gu, Seoul, Korea New World: 112-5, Samsung-dong, kangnam-gu, Seoul, korea Clover: 129-7, Chongdam-dong, kangnam-gu, seoul, Korea ------------------------------------------- ICCC'95 Secretariat Protocol Engineering Center, ETRI Yusong P.O.Box 106,Taejon,Korea Tel:+82-42-860-6598 Fax:+82-42-860-6597 e-mail: mskim@pec.etri.re.kr ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Jul 7 07:59:23 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA13429; Fri, 7 Jul 95 07:59:23 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA13423; Fri, 7 Jul 95 07:59:09 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA06005; Fri, 7 Jul 1995 07:48:58 -0700 Received: from lobster.wellfleet.com by mercury.Sun.COM (Sun.COM) id HAA23143; Fri, 7 Jul 1995 07:48:55 -0700 Received: from BayNetworks.com (pobox.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA28783; Fri, 7 Jul 95 10:47:32 EDT Received: from cabernet.engeast by BayNetworks.com (4.1/SMI-4.1) id AA25612; Fri, 7 Jul 95 10:48:48 EDT Date: Fri, 7 Jul 95 10:48:48 EDT From: rcallon@BayNetworks.com (Ross Callon) Message-Id: <9507071448.AA25612@BayNetworks.com> To: ipng@sunroof2.Eng.Sun.COM Subject: (IPng 352) Joint IPng / Mobile IP Meeting in Stockholm Cc: rcallon@BayNetworks.com, solomon@comm.mot.com Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Mobile IP and IPng are scheduled to meet in a joint session on Tuesday, 18 July 1995, 0900-1130 at Stockholm. The topic will be mobility for IPng. Anyone who wishes to present a proposal for IPng mobility -- or wishes to place a topic on the agenda -- should send an Email to Jim Solomon (solomon@comm.mot.com) as soon as possible (CC to Ross please). We am currently aware only of Charlie Perkins' request to make a presentation (although we expect there to be other presentations as well). Regards, Ross Callon (rcallon@baynetworks.com; co-chair of IPng wg) Jim Solomon (solomon@comm.mot.com, Co-chair, Mobile IP wg) ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Jul 7 10:34:07 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA13490; Fri, 7 Jul 95 10:34:07 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA13484; Fri, 7 Jul 95 10:33:58 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA25496; Fri, 7 Jul 1995 10:23:44 -0700 Received: from watson.ibm.com by mercury.Sun.COM (Sun.COM) id KAA10815; Fri, 7 Jul 1995 10:23:40 -0700 Received: from WATSON by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 2175; Fri, 07 Jul 95 13:21:45 EDT Received: from YKTVMV by watson.vnet.ibm.com with "VAGENT.V1.01 on VAGENT2" id 2965; Fri, 7 Jul 1995 13:21:45 EDT Received: from hawpub1.watson.ibm.com by yktvmv.watson.ibm.com (IBM VM SMTP V2R3) with TCP; Fri, 07 Jul 95 13:21:44 EDT Received: by hawpub1.watson.ibm.com (AIX 3.2/UCB 5.64/930311) id AA16762; Fri, 7 Jul 1995 13:21:25 -0400 From: perk@watson.ibm.com (Charlie Perkins) Message-Id: <9507071721.AA16762@hawpub1.watson.ibm.com> To: mobile-ip@Tadpole.COM, ipng@sunroof2.Eng.Sun.COM Cc: dbj@cs.cmu.edu Subject: (IPng 353) Re: (mobile-ip) Joint IPng / Mobile IP Meeting in Stockholm In-Reply-To: (Your message of Thu, 06 Jul 95 16:47:37 EST.) <9507062147.AA20627@becks.comm.mot.com> Date: Fri, 07 Jul 95 13:21:24 -0500 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk I have prepared a new revision of our earlier proposal for IPv6 mobility. The main difference between this proposal and our earlier proposal is that we now suggest that all IPv6 routers should be able to decapsulate packets and deliver the resulting datagram to mobile nodes which may be using a local point of attachment. In addition we suggest that all IPv6 routers be able to serve as home agents, since this does not represent much additional change in required functionality over what we previously specified, which was that all IPv6 nodes be able to process binding updates. I will submit the revised draft to the Internet Drafts directories today. It is also available now as software.watson.ibm.com:/pub/mobile-ip/ipv6mob.txt Comments are appreciated -- especially before our next working group meeting. Below, I append most of the summary of the revised draft. ======================================================================== Mobility Support in IPv6 ............. - We propose the use of routing headers instead of encapsulation for common traffic destined to a mobile node, since the problems with loose source routing in IPv4 are no longer present in IPv6 - We build upon the commonality between IPv4 registration and route optimization protocols to permit a cleaner and smaller mechanism for accomplishing the same things - We emphasize the need for distributing bindings to the entities that need them, in order to reduce drastically the role of the home agent in handling traffic destined for the mobile node - We build on the expected capability for mobile nodes to receive datagrams at several IPv6 addresses, to suggest the reduced need for external care-of addresses in some common circumstances. - We specify that all IPv6 routers and nodes accept binding updates, and thus that all IPv6 routers be able to operate as home agents, affording major simplifications and optimization at reasonable implementation cost. ======================================================================== Charlie P. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Jul 7 14:19:55 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA13649; Fri, 7 Jul 95 14:19:55 PDT Received: from jurassic.Eng.Sun.COM by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA13643; Fri, 7 Jul 95 14:19:47 PDT Received: from bobo.Eng.Sun.COM by jurassic.Eng.Sun.COM (SMI-8.6/SMI-SVR4) id OAA00472; Fri, 7 Jul 1995 14:09:40 -0700 Received: by bobo.Eng.Sun.COM (SMI-8.6/SMI-SVR4) id OAA06682; Fri, 7 Jul 1995 14:09:19 -0700 Date: Fri, 7 Jul 1995 14:09:19 -0700 From: nordmark@jurassic-248 (Erik Nordmark) Message-Id: <199507072109.OAA06682@bobo.Eng.Sun.COM> To: ipng@sunroof Subject: (IPng 354) New neighbor discovery draft Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk A revised version of the neighbor discovery draft has been submitted as an internet-draft today. If you want to access it before it shows up in the internet-drafts directory you can get it from ftp://playground.sun.com/pub/ipng/draft-ietf-ipngwg-discovery-01.txt The document contains a list of changes since the previous version. Erik & Thomas ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun Jul 9 06:56:53 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14171; Sun, 9 Jul 95 06:56:53 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14165; Sun, 9 Jul 95 06:56:43 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA25106; Sun, 9 Jul 1995 06:46:32 -0700 Received: from tera.csl.sony.co.jp by mercury.Sun.COM (Sun.COM) id GAA28826; Sun, 9 Jul 1995 06:46:32 -0700 Received: (from tera@localhost) by tera.csl.sony.co.jp (8.6.12+2.4W/3.3W3) id WAA02222; Sun, 9 Jul 1995 22:45:54 +0900 Message-Id: <199507091346.WAA02222@tera.csl.sony.co.jp> To: rcallon@baynetworks.com (Ross Callon), solomon@comm.mot.com Cc: ipng@sunroof2.Eng.Sun.COM, mobile-ip@tadpole.com Subject: (IPng 355) Re: Joint IPng / Mobile IP Meeting in Stockholm In-Reply-To: Your message of "Fri, 07 Jul 95 10:48:48 EDT." <9507071448.AA25612@BayNetworks.com> Date: Sun, 09 Jul 95 22:45:54 +0900 From: TERAOKA Fumio Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Co-chairs of IPng and Mobile-IP, > Anyone who wishes to present a proposal for IPng mobility -- or wishes > to place a topic on the agenda -- should send an Email to Jim Solomon > (solomon@comm.mot.com) as soon as possible (CC to Ross please). I would like to give a talk on mobility support in IPv6. I have already submitted a draft (draft-teraoka-ipv6-mobility-sup-01.txt). ------------------------------------------------------------------- TERAOKA, Fumio e-mail: tera@csl.sony.co.jp Sony Computer Science Laboratory Inc. phone: +81-3-5448-4380 ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Jul 10 15:26:24 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14846; Mon, 10 Jul 95 15:26:24 PDT Received: from jurassic.Eng.Sun.COM by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14840; Mon, 10 Jul 95 15:26:16 PDT Received: from kandinsky.Eng.Sun.COM by jurassic.Eng.Sun.COM (SMI-8.6/SMI-SVR4) id PAA06339; Mon, 10 Jul 1995 15:16:05 -0700 Received: by kandinsky.Eng.Sun.COM (5.x/SMI-SVR4) id AA09557; Mon, 10 Jul 1995 15:19:00 -0700 Date: Mon, 10 Jul 1995 15:19:00 -0700 From: gilligan@jurassic.Eng.Sun.COM (Bob Gilligan) Message-Id: <9507102219.AA09557@kandinsky.Eng.Sun.COM> To: ipng@sunroof Subject: (IPng 356) new revision of API spec Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Last week Marc Hasson pointed out a problem with the IPv6 socket API spec: While there was a mechanisms for the application to specify and retrieve a source route when sending and receiving, there was no way to specify which hops of that path should be strict source routes, and which should be loose. After some discussion, Marc and I have come up with a solution that we think will work. The change is to allocate one bit of the array passed in on the sendto() call, and returned to the application on the recvfrom() call, for use as a flag to specify whether the corresponding address represents a loose or strict hop in the source route. I have gone ahead and revised the API spec document to reflect this change. I have submitted the updated document to the internet-drafts archive, but it may not have made it in before the deadline for publication before the Stockholm meeting. I've also put a copy of the revised spec up for anonymous FTP on playground.sun.com in pub/ipng/draft-ietf-ipngwg-bsd-api-02.txt. I think that this change addresses the last of the problems with this spec. I believe it is now ready to be be published as an Informational RFC, as a product of the working group. Bob. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Jul 10 16:18:00 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14892; Mon, 10 Jul 95 16:18:00 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14886; Mon, 10 Jul 95 16:17:48 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA17973; Mon, 10 Jul 1995 16:07:35 -0700 Received: from IETF.nri.reston.VA.US by mercury.Sun.COM (Sun.COM) id QAA14756; Mon, 10 Jul 1995 16:07:31 -0700 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa04494; 10 Jul 95 10:19 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;@mercury Cc: ipng@sunroof.Eng.Sun.COM From: Internet-Drafts@CNRI.Reston.VA.US Reply-To: Internet-Drafts@CNRI.Reston.VA.US Subject: (IPng 357) I-D ACTION:draft-ietf-ipngwg-discovery-01.txt Date: Mon, 10 Jul 95 10:19:37 -0400 Message-Id: <9507101019.aa04494@IETF.CNRI.Reston.VA.US> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPNG Working Group of the IETF. Title : Neighbor Discovery for IP Version 6 (IPv6) Author(s) : T. Narten, E. Nordmark, W. Simpson Filename : draft-ietf-ipngwg-discovery-01.txt Pages : 70 Date : 07/07/1995 This document specifies the Neighbor Discovery protocol for the IP Version 6 protocol. IPv6 nodes on the same link use Neighbor Discovery to discover each other's presence, to determine each other's link-layer addresses, to find routers and to maintain reachability information about the paths to active neighbors. Internet-Drafts are 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-ipngwg-discovery-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-discovery-01.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.8) o Europe Address: nic.nordu.net (192.36.148.17) Address: ftp.nis.garr.it (192.12.192.10) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-discovery-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. For questions, please mail to Internet-Drafts@cnri.reston.va.us. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19950707174051.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-discovery-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-discovery-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19950707174051.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Jul 10 17:47:47 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15022; Mon, 10 Jul 95 17:47:47 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15016; Mon, 10 Jul 95 17:47:38 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA00216; Mon, 10 Jul 1995 17:37:26 -0700 Received: from conch.vast.unsw.edu.au by mercury.Sun.COM (Sun.COM) id RAA29389; Mon, 10 Jul 1995 17:37:24 -0700 Received: from mucket.vast.unsw.edu.au by conch.vast.unsw.edu.au with SMTP id AA18001 (5.65c/IDA-1.4.4 for ); Tue, 11 Jul 1995 10:37:06 +1000 From: Alex Lam Received: by mucket.vast.unsw.edu.au (5.65c/client-1.3) id AA19622; Tue, 11 Jul 1995 10:37:04 +1000 Date: Tue, 11 Jul 1995 10:37:04 +1000 Message-Id: <199507110037.AA19622@mucket.vast.unsw.edu.au> To: ipng@sunroof.Eng.Sun.COM Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Hi, Can someone pointed out what is wrong with the following organisation with regard to Routing Options. Suppose a packet is to be sent from node A to node D. A -> B -> C -> D The package leaving node A has the following configuration: IPv6.Destination_Address = B Routing_Header.Num_Addrs = 1 Routing_Header.Next_Addr = 0 Routing_Header.Address[0] = C Routing_Header.Address[1] = D The package leaving node B has the following configuration: IPv6.Destination_Address = C Routing_Header.Num_Addrs = 1 Routing_Header.Next_Addr = 1 Routing_Header.Address[0] = B Routing_Header.Address[1] = D But the message will not leave node C because Routing_Header.Num_Addrs = Routing_Header.Next_Addr according to Page 15 of spec-02. But if A forwards the package with: IPv6.Destination_Address = B Routing_Header.Num_Addrs = 2 Routing_Header.Next_Addr = 0 Routing_Header.Address[0] = B Routing_Header.Address[1] = C Routing_Header.Address[2] = D then after "swap the IPv6 Destination Address and Address[Next Addr], then increment Next Addr by one". The packet will become: IPv6.Destination_Address = B Routing_Header.Num_Addrs = 2 Routing_Header.Next_Addr = 1 Routing_Header.Address[0] = B Routing_Header.Address[1] = C Routing_Header.Address[2] = D because IPv6.Destination_Address = Routing_Header.Address[Next_Addr] = B Something is wrong, but where ? Alex Lam ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Jul 10 19:19:38 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15090; Mon, 10 Jul 95 19:19:38 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15084; Mon, 10 Jul 95 19:19:29 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA08624; Mon, 10 Jul 1995 19:09:16 -0700 Received: from mentat.com by mercury.Sun.COM (Sun.COM) id TAA10454; Mon, 10 Jul 1995 19:09:16 -0700 Received: from orna.mentat.com ([192.88.122.155]) by mentat.com (4.1/SMI-4.1) id AA08155; Mon, 10 Jul 95 19:07:48 PDT Received: by orna.mentat.com (5.0/SMI-SVR4) id AA00725; Mon, 10 Jul 1995 19:07:47 +0800 Date: Mon, 10 Jul 1995 19:07:47 +0800 From: mark@mentat.com (Marc Hasson) Message-Id: <9507110207.AA00725@orna.mentat.com> To: alexl@vast.unsw.edu.au Subject: (IPng 358) Routing header usage Cc: ipng@sunroof.Eng.Sun.COM X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk On the attached, your setting/understanding of Num_Addrs was incorrect. Num_Addrs is the number of addresses, NOT the highest indexed address. I've rewritten the sequence as it should be: A -> B -> C -> D The packet leaving node A has the following configuration: IPv6.Destination_Address = B Routing_Header.Num_Addrs = 2 Routing_Header.Next_Addr = 0 Routing_Header.Address[0] = C Routing_Header.Address[1] = D The packet leaving node B has the following configuration: IPv6.Destination_Address = C Routing_Header.Num_Addrs = 2 Routing_Header.Next_Addr = 1 Routing_Header.Address[0] = B Routing_Header.Address[1] = D The packet leaving node C has the following configuration: IPv6.Destination_Address = D Routing_Header.Num_Addrs = 2 Routing_Header.Next_Addr = 2 Routing_Header.Address[0] = B Routing_Header.Address[1] = C -- Marc -- > From owner-ipng@sunroof2.Eng.Sun.COM Mon Jul 10 17:38:13 1995 > Received: from venus.Sun.COM by mentat.com (4.1/SMI-4.1) > id AA05639; Mon, 10 Jul 95 17:38:07 PDT > Received: from Eng.Sun.COM by venus.Sun.COM (Sun.COM) > id RAA22820; Mon, 10 Jul 1995 17:38:18 -0700 > Received: from sunroof2.Eng.Sun.COM by Eng.Sun.COM (5.x/SMI-5.3) > id AA25190; Mon, 10 Jul 1995 17:38:10 -0700 > Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) > id AA15022; Mon, 10 Jul 95 17:47:47 PDT > Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) > id AA15016; Mon, 10 Jul 95 17:47:38 PDT > Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) > id AA00216; Mon, 10 Jul 1995 17:37:26 -0700 > Received: from conch.vast.unsw.edu.au by mercury.Sun.COM (Sun.COM) > id RAA29389; Mon, 10 Jul 1995 17:37:24 -0700 > Received: from mucket.vast.unsw.edu.au by conch.vast.unsw.edu.au with SMTP id AA18001 > (5.65c/IDA-1.4.4 for ); Tue, 11 Jul 1995 10:37:06 +1000 > From: Alex Lam > Received: by mucket.vast.unsw.edu.au (5.65c/client-1.3) > id AA19622; Tue, 11 Jul 1995 10:37:04 +1000 > Date: Tue, 11 Jul 1995 10:37:04 +1000 > Message-Id: <199507110037.AA19622@mucket.vast.unsw.edu.au> > To: ipng@sunroof.Eng.Sun.COM > > Hi, > > Can someone pointed out what is wrong with the following organisation > with regard to Routing Options. > > Suppose a packet is to be sent from node A to node D. > > A -> B -> C -> D > > The package leaving node A has the following configuration: > > IPv6.Destination_Address = B > Routing_Header.Num_Addrs = 1 > Routing_Header.Next_Addr = 0 > Routing_Header.Address[0] = C > Routing_Header.Address[1] = D > > The package leaving node B has the following configuration: > > IPv6.Destination_Address = C > Routing_Header.Num_Addrs = 1 > Routing_Header.Next_Addr = 1 > Routing_Header.Address[0] = B > Routing_Header.Address[1] = D > > But the message will not leave node C because > Routing_Header.Num_Addrs = Routing_Header.Next_Addr > according to Page 15 of spec-02. > > But if A forwards the package with: > > IPv6.Destination_Address = B > Routing_Header.Num_Addrs = 2 > Routing_Header.Next_Addr = 0 > Routing_Header.Address[0] = B > Routing_Header.Address[1] = C > Routing_Header.Address[2] = D > > then after "swap the IPv6 Destination Address and Address[Next Addr], then > increment Next Addr by one". The packet will become: > > IPv6.Destination_Address = B > Routing_Header.Num_Addrs = 2 > Routing_Header.Next_Addr = 1 > Routing_Header.Address[0] = B > Routing_Header.Address[1] = C > Routing_Header.Address[2] = D > > because IPv6.Destination_Address = Routing_Header.Address[Next_Addr] = B > > Something is wrong, but where ? > > Alex Lam > > ------------------------------------------------------------------------------ > IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng > IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html > Direct all administrative requests to majordomo@sunroof.eng.sun.com > ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Jul 11 09:16:02 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15355; Tue, 11 Jul 95 09:16:02 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15139; Mon, 10 Jul 95 20:37:49 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA12987; Mon, 10 Jul 1995 20:27:35 -0700 Received: from tsbgw.isl.rdc.toshiba.co.jp by mercury.Sun.COM (Sun.COM) id UAA16964; Mon, 10 Jul 1995 20:27:27 -0700 Received: by tsbgw.isl.rdc.toshiba.co.jp (8.6.12-KCONV/8.23) with UUCP id MAA29039; Tue, 11 Jul 1995 12:26:30 +0900 Received: by mailhost.isl.rdc.toshiba.co.jp (8.6.12-KCONV/1.17) with ESMTP id MAA21763; Tue, 11 Jul 1995 12:21:58 +0900 Message-Id: <199507110321.MAA21763@isl.rdc.toshiba.co.jp> To: alexl@vast.unsw.edu.au Cc: ipng@sunroof.Eng.Sun.COM Subject: (IPng 359) Re: (No Subject in original) In-Reply-To: Your message of "Tue, 11 Jul 1995 10:37:04 +1000" References: <199507110037.AA19622@mucket.vast.unsw.edu.au> X-Mailer: Mew beta version 0.91 on Emacs 19.28.7, Mule 2.2 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Date: Tue, 11 Jul 1995 12:21:54 +0900 From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk >>>>> On Tue, 11 Jul 1995 10:37:04 +1000, >>>>> Alex Lam said: > Suppose a packet is to be sent from node A to node D. > A -> B -> C -> D > The package leaving node A has the following configuration: > IPv6.Destination_Address = B > Routing_Header.Num_Addrs = 1 > Routing_Header.Next_Addr = 0 > Routing_Header.Address[0] = C > Routing_Header.Address[1] = D Num Addr value of routing header is the "number of addresses in the Routing Header", not the "maximum index number of addresses"(c.f. Page 14 of spec-02). So Routing_Header.Num_Addrs must be 2. And if the field is modified, the packet will be sent to the node D correctly. JINMEI, Tatuya Comm. and Info. Systems Research Labs. Toshiba R&D Center jinmei@isl.rdc.toshiba.co.jp ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Jul 11 19:18:17 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15823; Tue, 11 Jul 95 19:18:17 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15817; Tue, 11 Jul 95 19:18:09 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA08213; Tue, 11 Jul 1995 19:07:55 -0700 Received: from conch.vast.unsw.edu.au by mercury.Sun.COM (Sun.COM) id TAA21534; Tue, 11 Jul 1995 19:07:39 -0700 Received: from mucket.vast.unsw.edu.au by conch.vast.unsw.edu.au with SMTP id AA01071 (5.65c/IDA-1.4.4 for ); Wed, 12 Jul 1995 12:07:27 +1000 From: Alex Lam Received: by mucket.vast.unsw.edu.au (5.65c/client-1.3) id AA22341; Wed, 12 Jul 1995 12:07:26 +1000 Message-Id: <199507120207.AA22341@mucket.vast.unsw.edu.au> Subject: (IPng 360) Re: Routing header usage To: mark@mentat.com (Marc Hasson) Date: Wed, 12 Jul 1995 12:07:26 +1000 (EST) Cc: ipng@sunroof.Eng.Sun.COM (ipng) In-Reply-To: <9507110207.AA00725@orna.mentat.com> from "Marc Hasson" at Jul 10, 95 07:07:47 pm X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Hi, > On the attached, your setting/understanding of Num_Addrs was incorrect. > Num_Addrs is the number of addresses, NOT the highest indexed address. Then why does it say "Maximum legal value=23" on page 14 of spec-02 ? Alex Lam -- ****************** | _ |\/| _ Computer Science and Engineering, UNSW |___|_|_| |_ , |-| L E X email: alexl@vast.unsw.edu.au | | alexl@cse.unsw.edu.au ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Jul 11 20:58:07 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15944; Tue, 11 Jul 95 20:58:07 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15938; Tue, 11 Jul 95 20:57:59 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA15041; Tue, 11 Jul 1995 20:47:44 -0700 Received: from mentat.com by mercury.Sun.COM (Sun.COM) id UAA01229; Tue, 11 Jul 1995 20:47:44 -0700 Received: from orna.mentat.com ([192.88.122.155]) by mentat.com (4.1/SMI-4.1) id AA01109; Tue, 11 Jul 95 20:46:06 PDT Received: by orna.mentat.com (5.0/SMI-SVR4) id AA04802; Tue, 11 Jul 1995 20:46:06 +0800 Date: Tue, 11 Jul 1995 20:46:06 +0800 From: mark@mentat.com (Marc Hasson) Message-Id: <9507120346.AA04802@orna.mentat.com> To: alexl@vast.unsw.edu.au Subject: (IPng 361) Re: Routing header usage Cc: ipng@sunroof.Eng.Sun.COM X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk > > On the attached, your setting/understanding of Num_Addrs was incorrect. > > Num_Addrs is the number of addresses, NOT the highest indexed address. > > Then why does it say "Maximum legal value=23" on page 14 of spec-02 ? > > Alex Lam Because there are only 24 bits in the strict/loose bitmask field to describe each of the addresses in the list and the zero'th bit is defined to describe the first leg routing from source to the "first hop" address (which is initially stored in the IPv6 destination field). That only leaves 23 bits left to describe each of the remaining routing hops, including the final destination. Thus Num_Addrs can't exceed 23 addresses. Strict/loose bitmask's bit 23 describes how to route to Address[22]. A source node can thus strict/loose route through 23 intermediate nodes plus the final destination, 24 addresses total. Alex, please note that the diagram in the spec clearly labels the last address as "Address[Num Addrs - 1]". Also, if you work through the procedures I think you'll find it all holds together. If you have any further questions I'll be happy to try answering them off-line from the main list. I think at one point there *may* have been a discussion about either having a 25th strict/loose bit vs. just limiting the number of intermediary hops to 23 and preserve the currently "Reserved" octet whole. The decision seems clear, someone can correct me if I'm wrong. -- Marc -- ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Jul 12 18:03:56 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16555; Wed, 12 Jul 95 18:03:56 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16549; Wed, 12 Jul 95 18:03:48 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA26466; Wed, 12 Jul 1995 17:53:32 -0700 Received: from munnari.oz.au by mercury.Sun.COM (Sun.COM) id RAA00194; Wed, 12 Jul 1995 17:53:21 -0700 From: Alan.Lloyd@datacraft.com.au Received: from datacraft.com.au by munnari.oz.au with MHSnet (5.83--+1.3.1+0.50) id AA06132; Thu, 13 Jul 1995 10:53:05 +1000 (from Alan.Lloyd@datacraft.com.au) Received: from [148.182.10.2] by cms.datacraft.com.au with SMTP (5.65/1.2-eef) id AA06421; Thu, 13 Jul 95 10:32:18 +1000 Received: by dcthq2.datacraft.com.au; Thu, 13 Jul 95 10:54:37 +1100 Date: Thu, 13 Jul 95 10:52:02 +1100 Message-Id: To: ipng@sunroof.Eng.Sun.COM Subject: (IPng 362) comments to ISO on IETF addressing docs X-Incognito-Sn: 578 X-Incognito-Format: VERSION=1.74 ENCRYPTED=NO Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk attached comments (I hope!) begin 666 SC6COM.TXT M5&AE($E%5$8@9&]C=6UE;G1S(&QI'0@1V5N97)A=&EO;B!!9&1R97-S:6YG($%R8VAI=&5C='5R90T\ M9')A9G0M:65T9BUI<&YG+6%D9'(M87)C:"TP,BYT>'0^#0UA+B!086=E(#4@ M+2!486)L92!O;B!!;&QO8V%T:6]N#51H92!T97)M(").975T'0^#0T-82X@5&AE('1I=&QE M(&]F('1H92!D;V-C=6UE;G0@"!W:6QL(&AA=F4@=&\@8V]N2!F;W(@ M=&AI2X@16ET:&5R(&)Y(&1I M2!O=&AE'!I2!T:&5S92!P2!F;W)M(&]F($E!3D$@71E2!)4T\O2515+@T-5&AE(&ES M Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16893; Wed, 12 Jul 95 18:36:16 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16887; Wed, 12 Jul 95 18:36:08 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA29224; Wed, 12 Jul 1995 18:25:52 -0700 Received: from munnari.oz.au by mercury.Sun.COM (Sun.COM) id SAA04560; Wed, 12 Jul 1995 18:25:49 -0700 From: Alan.Lloyd@datacraft.com.au Received: from datacraft.com.au by munnari.oz.au with MHSnet (5.83--+1.3.1+0.50) id AA07617; Thu, 13 Jul 1995 11:25:38 +1000 (from Alan.Lloyd@datacraft.com.au) Received: from [148.182.10.2] by cms.datacraft.com.au with SMTP (5.65/1.2-eef) id AA06599; Thu, 13 Jul 95 11:05:04 +1000 Received: by dcthq2.datacraft.com.au; Thu, 13 Jul 95 11:27:23 +1100 Date: Thu, 13 Jul 95 11:27:20 +1100 Message-Id: To: ipng@sunroof.Eng.Sun.COM Subject: (IPng 363) comments to ISO sc6 on IP6 docs X-Incognito-Sn: 578 X-Incognito-Format: VERSION=1.74 ENCRYPTED=NO Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Re transmitted. our gateway uued the initial post. apologies to the list The IETF documents listed below were circulated through ISO/IEC JTC1/SC6 for comment. The following is provided for SC6 Australia. Also being a contributor to IETF and some of these documents, these comments will also be passed directly to the IETF. Comments 1. ISO/IEC JTC1/SC6 N 9599 An architecture for IPv6 Unicast Address Allocation The document is for discussion and informative. Thus no comments are provided. 2. ISO/IEC JTC1/SC6 N 9601 IP Next Generation Addressing Architecture a. Page 5 - Table on Allocation The term "Neutral Interconnect" caused some confusion. I believe this has been returned to original term of "Geographic". 3. ISO/IEC JTC1/SC6 N 9602 Mechanisms for OSI NSAPs, CLNP and TP over IPv6 a. The title of the doccument should adopt the standard form now being applied. ie. " General comments for consideration on the issues on Page 1. b. Page 1 Issue 1 The use of NSAPs in source routing header should be possible for local use of IPv6 and the use of NSAPs. If used in the wider internet, then the originator should be aware of it optional support within the routing infrastucture. c. Page 1 Issue 2 Sites with more than one NSAP prefix will have to consider the impact of combining the multihoming requirements in (and of) both the CLNP and IPv6 environment. d. Page 1 Issue 3 Discovery and NSAPs. This is an implementation issue. Where implementors build in options that support NSAPs and IPv6 interworking, then the other features of IPv6 such as discovery should be implemented if seen appropriate. There may be additional options required in discovery for this as indeed other functions. These should be raised as and when they are discovered. e. Page 1 Issue 4 The total length field is redundant and should be reserved otherwise additional and possibly conflicting processing may result. (ie if the length fields are corrupt). f. Page 1 Issue 5 Is the NSAP extension included in the security payload.? Because the NSAP header is part of the IPv6 overall header (IPv6 + Options), It should be included in the Authorisation check if it is used because the NSAP destination option is invariant during transfer. g. Page 1 Issue 6 Question on "Truncated NSAPs" - any suitable way. Correlation between the two address forms will have to be applied in some way. Either by direct mapping or some rules based configuration utility, etc. The text in this section is sufficient to assume this. h. Page 1 Issue 7 CLNP and TP encapsulation. These should be a seperate document and the abstract of this document changed. i. Page 1 Issue 8 Document adoption The document should be jointly owned by IPNG and ISO SC6. End of Issues..... j. Page 4 after first para add for clarification. " This document does not address the issues associated with migrating the routing protocols used with CLNP (ES-IS or IS-IS) and transistion of their network infrastructure." k. Page 5 Add note to the end of page 4. Note: the term "restricted NSAPA" is used to indicate that the IPv6 NSAP form described is restricted to the ICD and DCC. The truncated NSAPA form can carry other NSAP forms. l. Page 8 and other pages. The term "Pack Id" is used. This term has been replaced with AnyCast Addresses in the IPv6 specification. 3. ISO/IEC JTC1/SC6 N 9603 Registration of IPv6 Addresses via ISO/ITU a. General The document's date/validity has expired and therefore ISO SC6 should request that the document (if supported by ISO/ITU) should be resubmitted to the IETF for resolution. b. General The ISO and ITU should raise a formal request to IANA and the IESG to propose and accept such allocation mechanisms. c. Title change Its title if the document is resubmitted should be upgraded to: d. Page 4 section 1.1 These address allocation options were written during the formulation of the IPv6 addressing schemes and the work being performed on NSAP support. Effectively these proposed codes could be superceded by the fact that ICD and DCC address forms as NSAPAs are made available and under the IPv6 scheme. ie. ISO/ITU can now offially use and allocate IP6 address space. (Although the support of NSAPAs in the Internet can be questioned and the actual support within specific router products will have to be determined.) Probably the best approach to IPv6 adddress allocation by the ISO/ITU for the ISO/ITU is to: a) formailse the IPv6 address in ISO6523 as a NSAP with an AFI code. But point out that the AFI code is implicit when this address form is used in the Internet ie AFI code = xx , IDP = 16 bytes.(as per the IPv6 address). b) For IANA to allocate a block of address space to ISO which aligns to the regional registry form of IANA so that route compatability can be achieved. eg. Address = Prefix 011 = ISO/ITU assigned. next 5 bits = IANA registry (eg E8 = RIPE) see rekhter- ipv6 -address-format-01.txt with 011/F8 being used for ISO assigned ICD form. eg. 011/F8/ICD/subscriber. and other regional registry allocation forms used for DCC forms eg. 011/xx/CountryCode/provider/subscriber. where xx = non multi regional registry. The next few bytes will be used as the ICD or DCC code with the remaining bytes for provider/subscriber space as per NSAPs. Once this definition is performed, ISO or ITU may be able to select a block of the address space in which it can allocate space to multinationals as ICD codes and address space to countries as national blocks. In the latter case, geographic addresses are already part of the IPv6 form. So that a form could be used by ISO/ITU. The issue of mapping or incorporation of E.164 address forms into the IPv6 form is still to be decided. End of comments regards Alan Lloyd ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Jul 17 09:09:03 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA18995; Mon, 17 Jul 95 09:09:03 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA18989; Mon, 17 Jul 95 09:08:49 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA21068; Mon, 17 Jul 1995 08:58:27 -0700 Received: from IETF.nri.reston.VA.US by mercury.Sun.COM (Sun.COM) id IAA20570; Mon, 17 Jul 1995 08:58:26 -0700 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa05393; 17 Jul 95 11:51 EDT To: IETF-Announce:;@mercury Cc: mwalnut@CNRI.Reston.VA.US, ipng@sunroof.Eng.Sun.COM Subject: (IPng 364) 33rd IETF: ON-SITE AGENDA: ADDTL IPNGWG SESSION Date: Mon, 17 Jul 95 11:51:06 -0400 From: Megan Davies Walnut Message-Id: <9507171151.aa05393@IETF.CNRI.Reston.VA.US> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Group Name: IPNG Working Group Date/Time : Thursday, 20 July: 1300-1500 (no MBONE coverage) Status : New Session, continuing discussion Location : Weapon Room ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Jul 17 15:33:10 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA19514; Mon, 17 Jul 95 15:33:10 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA19438; Mon, 17 Jul 95 14:29:59 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA12189; Mon, 17 Jul 1995 14:19:25 -0700 Received: from new6.reston.mci.net by mercury.Sun.COM (Sun.COM) id OAA17950; Mon, 17 Jul 1995 14:19:25 -0700 Received: (from huddle@localhost) by new6.reston.mci.net (8.6.12/8.6.6) id RAA27018; Mon, 17 Jul 1995 17:18:10 -0400 Date: Mon, 17 Jul 1995 17:18:10 -0400 From: Scott Huddle Message-Id: <199507172118.RAA27018@new6.reston.mci.net> To: mwalnut@CNRI.Reston.VA.US Subject: (IPng 365) Re: 33rd IETF: ON-SITE AGENDA: ADDTL IPNGWG SESSION Cc: ipng@sunroof.Eng.Sun.COM, rw@mci.net Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Megan Davies Walnut writes > > Group Name: IPNG Working Group > Date/Time : Thursday, 20 July: 1300-1500 (no MBONE coverage) > Status : New Session, continuing discussion > Location : Weapon Room And there will be *no fighting in the weapon's room*. follow ups to alt.strangelove. -scott (huddle@mci.net) MCI Internet Engineering ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Jul 20 13:50:01 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA21380; Thu, 20 Jul 95 13:50:01 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA21374; Thu, 20 Jul 95 13:49:47 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA16641; Thu, 20 Jul 1995 13:39:16 -0700 Received: from sundance.itd.nrl.navy.mil by mercury.Sun.COM (Sun.COM) id NAA00471; Thu, 20 Jul 1995 13:39:11 -0700 Subject: (IPng 366) On source address determination To: IPng Mailing list Date: Thu, 20 Jul 1995 16:39:13 -0500 (EST) From: Dan McDonald Cc: Dan McDonald X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: <9507202139.aa13058@cs.nrl.navy.mil> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk [NOTE FROM Dan McD.: Consider sending replies to the list and/or: danmcd@ITD.nrl.navy.mil, NOT danmcd@cs.nrl.navy.mil, There's mail-exchanger weirdness with cs....] Like the subject suggests, I've been contemplating the subject of source address selection. Early on, it was quite simple, use the link-local, or the ::, depending on the destination (which quite frankly was either one of those two forms). The specs don't talk about source address selection all that much, as it is an implementation detail. I'm bringing this up with other implementors and implementations in mind. Today I added a THIRD prefix to the ethernet interface, and, well, um, INTERESTING things started happening, depending on the order in which I add routes, etc. For example, consider the following: An interface has the following addresses attached to it: :: (v4-compatible address) fe80:: (link-local address) fec0:: (site-local routable address) Okay, so I've got those three. So let's say I've figure out the outbound interface (which neatly avoids the multi-homed discussion), and now I want to send a packet. Note that if I'm a router, this isn't a problem, as the source address is already there. This is for communication that ORIGINATES WITH MY NODE. Fine. In my particular scheme of doing things, my "next-hop" cache and/or "neighbor" cache (to use the terms in all of the discovery drafts) has a "suggested source address" (an ifaddr * for you BSD types) in it. Sometimes, if I'm getting new destinations added, the next-hop or neighbor cache has the wrong, or less useful, source address. A particular case is where I add a "transdefault" route to tunnel all :: packets, but I add it BEFORE I set the on-link :: prefix and my :: interface address. Suddenly, I was sending packets of the form: Src: fec0:: Dst: :: Do you see where I'm coming from? I'm not setting the source address correctly. I can see a basic set of rules where: 1. If link-local dest, use link-local src. 2. If v4-compatible dest, use v4-compatible src. 3. If site-local dest, use site-local src. 4. Otherwise, pick "best" source on that interface. I have a few ideas on how to implement #4, but I'll leave those out for now. One other thing, can you imagine doing those four steps on every outgoing d-gram? I didn't think so. I *CAN* imagine, however, doing those four steps when creating a new next-hop or neighbor cache entry. (Sometimes, especially in the case of neighbor caches, the correct source address just falls out. An implementation detail of mine, and probably others who are BSD-ish I guess.) Bottom line: How have people addressed the source-address-selection problem? Also, this is a problem for setting up connection state, because connections in TCP are defined by not just destination but SOURCE as well. How is that done by you folks? My answer is to try my best to determine the source address at the creation of a next-hop or neighbor cache entry. This save doing checks at EVERY outgoing datagram. Alright, folks, let's hear it! I'm soliciting opinions, which means I expect to hear a few opinion advertisements. :) Dan McD. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Jul 24 09:42:23 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA22498; Mon, 24 Jul 95 09:42:23 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA22492; Mon, 24 Jul 95 09:42:14 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA18411; Mon, 24 Jul 1995 09:31:41 -0700 Received: from hubbub.cisco.com by mercury.Sun.COM (Sun.COM) id JAA24723; Mon, 24 Jul 1995 09:31:33 -0700 Received: from puli.cisco.com (puli.cisco.com [171.69.1.174]) by hubbub.cisco.com (8.6.10/CISCO.GATE.1.1) with SMTP id JAA18814 for ipng@sunroof.eng.sun.com; Mon, 24 Jul 1995 09:31:32 -0700 Message-Id: <199507241631.JAA18814@hubbub.cisco.com> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng 367) Lixia's study group Date: Mon, 24 Jul 95 09:31:32 PDT From: Yakov Rekhter Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Folks, At the IPv5 session last IETF Lixia's presentation indicated that she expects her group to complete the study of various address allocation schemes for IPv6, and produce some recommendations (based on the study) by the next IETF. Therefore, I would be like to suggest that we'll put on hold turning the following two I-Ds: An Architecture for IPv6 Unicast Address Allocation An IPv6 Global Unicast Address Format into RFCs pending the recommendations of Lixia's group. Yakov. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Jul 24 11:02:11 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA22559; Mon, 24 Jul 95 11:02:11 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA22553; Mon, 24 Jul 95 11:02:02 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA03144; Mon, 24 Jul 1995 10:51:30 -0700 Received: from alpha.xerox.com by mercury.Sun.COM (Sun.COM) id KAA19605; Mon, 24 Jul 1995 10:51:25 -0700 Received: from redwing.parc.xerox.com ([13.2.116.19]) by alpha.xerox.com with SMTP id <15654(4)>; Mon, 24 Jul 1995 10:50:49 PDT Received: by redwing.parc.xerox.com id <177520>; Mon, 24 Jul 1995 10:50:39 -0700 Date: Mon, 24 Jul 1995 10:50:37 PDT From: Lixia Zhang To: yakov@cisco.com Cc: ipng@sunroof.Eng.Sun.COM Subject: (IPng 368) Re: Lixia's study group In-Reply-To: Your message of Mon, 24 Jul 1995 09:31:32 -0700 Message-Id: Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk > Folks, > > At the IPv5 session last IETF Lixia's presentation indicated that > she expects her group to complete the study of various address allocation > schemes for IPv6, and produce some recommendations (based on the study) > by the next IETF. > > Therefore, I would be like to suggest that we'll put on hold > turning the following two I-Ds: > > An Architecture for IPv6 Unicast Address Allocation > > An IPv6 Global Unicast Address Format > > into RFCs pending the recommendations of Lixia's group. Yakov, I've missed IPng WG meetings for the last couple of IETFs due to time conflicts with other meetings. But given that the two I-Ds have been recommended by the WG to move on, as I learned from email, I do *not* think they should be held back just because of our study group. As a member of the group you certainly understand clearly the goal and our current stage. - I repeat again that our group is just a small *volunteer* group, on a topic that is interesting to everyone in the group--we believe the addressing issue is vitally important so each of us agreed to spend our time evaluating different approaches. - Although the group was started by IAB, we represent noboby but ourselves. And anyone else can do the same, i.e. conduct their own study and report the results to the community at large. I do not think that IETF work in progress should be held back just because somebody is doing further study; the decision belongs to the WG, not others. Lixia ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Jul 24 11:46:01 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA22609; Mon, 24 Jul 95 11:46:01 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA22603; Mon, 24 Jul 95 11:45:53 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA10322; Mon, 24 Jul 1995 11:35:20 -0700 Received: from hubbub.cisco.com by mercury.Sun.COM (Sun.COM) id LAA29040; Mon, 24 Jul 1995 11:35:19 -0700 Received: from puli.cisco.com (puli.cisco.com [171.69.1.174]) by hubbub.cisco.com (8.6.10/CISCO.GATE.1.1) with SMTP id LAA01273; Mon, 24 Jul 1995 11:35:16 -0700 Message-Id: <199507241835.LAA01273@hubbub.cisco.com> To: Lixia Zhang Cc: ipng@sunroof.Eng.Sun.COM Subject: (IPng 369) Re: Lixia's study group In-Reply-To: Your message of "Mon, 24 Jul 95 10:50:37 PDT." Date: Mon, 24 Jul 95 11:35:15 PDT From: Yakov Rekhter Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Lixia, > I do not think that IETF work in progress should be held back just > because somebody is doing further study; the decision belongs to the > WG, not others. You're absolutely correct - the decision belongs to the WG, not the others. That is why I posted my message to the *IPng mailing list*. However, I hope that the results of your group study would help the IPng WG make a more informed decision wrt to the IPv6 address allocation and address format documents. Would you agree with this ? Yakov. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Jul 24 12:30:54 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA22661; Mon, 24 Jul 95 12:30:54 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA22655; Mon, 24 Jul 95 12:30:45 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA17394; Mon, 24 Jul 1995 12:20:13 -0700 Received: from servo.ipsilon.com by mercury.Sun.COM (Sun.COM) id MAA08984; Mon, 24 Jul 1995 12:20:12 -0700 Received: from [204.160.241.224] (acacia.Ipsilon.COM [204.160.241.224]) by servo.ipsilon.com (8.6.11/8.6.10) with SMTP id MAA28684; Mon, 24 Jul 1995 12:18:55 -0700 X-Sender: hinden@mailhost.ipsilon.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 24 Jul 1995 12:21:15 -0700 To: Yakov Rekhter From: hinden@Ipsilon.COM (Bob Hinden) Subject: (IPng 370) Re: Lixia's study group Cc: ipng@sunroof.Eng.Sun.COM Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Yakov, >At the IPv5 session last IETF Lixia's presentation indicated that >she expects her group to complete the study of various address allocation >schemes for IPv6, and produce some recommendations (based on the study) >by the next IETF. I do not think the IAB study group has any direct relationship to the IPv6 work. It is certainly not an IETF working group. >Therefore, I would be like to suggest that we'll put on hold >turning the following two I-Ds: > > An Architecture for IPv6 Unicast Address Allocation > > An IPv6 Global Unicast Address Format > I do not think these documents should be put "on hold" pending the out come of the IAB study group. It is unclear when the study group will be done or how much "consensus" there will be with the outcome. These two documents describe a provider oriented allocation scheme consistent with CIDR. As such they are the only allocation approach which we think will work. Other approaches are interesting but could be described as a research activity. The IPng working group has already decided to move these documents forward. The first document has been through a working group last call, submitted to the IESG, and been through an IESG last call. It is waiting for IESG action. The second document has been through a working group last call and is undergoing some revision, in the area of the size of the individual fields in the address format, as a result of the working group last call. Once that is complete, the working group will do another working group last call and then will send it to the IESG to become a Proposed Standard. Bob ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Jul 24 12:55:46 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA22702; Mon, 24 Jul 95 12:55:46 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA22696; Mon, 24 Jul 95 12:55:37 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA20553; Mon, 24 Jul 1995 12:45:02 -0700 Received: from hubbub.cisco.com by mercury.Sun.COM (Sun.COM) id MAA13590; Mon, 24 Jul 1995 12:44:58 -0700 Received: from puli.cisco.com (puli.cisco.com [171.69.1.174]) by hubbub.cisco.com (8.6.10/CISCO.GATE.1.1) with SMTP id MAA08051; Mon, 24 Jul 1995 12:44:25 -0700 Message-Id: <199507241944.MAA08051@hubbub.cisco.com> To: hinden@ipsilon.com (Bob Hinden) Cc: ipng@sunroof.Eng.Sun.COM Subject: (IPng 371) Re: Lixia's study group In-Reply-To: Your message of "Mon, 24 Jul 95 12:21:15 PDT." Date: Mon, 24 Jul 95 12:44:24 PDT From: Yakov Rekhter Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Bob, > I do not think the IAB study group has any direct relationship to the IPv6 > work. The purpose of this study group is specifically to look at different address allocation strategies for *IPv6*. So, I wonder why do you think that this group does not have "any direct relationship to the IPv6 work" ? > I do not think these documents should be put "on hold" pending the out come > of the IAB study group. It is unclear when the study group will be done ... As you recall, Lixia in her presentation promised to complete the study by the next IETF. So, I don't understand your statement that "It is unclear when the study group will be done". > > These two documents describe a provider oriented allocation scheme > consistent with CIDR. As such they are the only allocation approach which > we think will work. As you recall, Lixia's presentation identified the need to renumber, and support for multihomed subscribers as important deficiencies of the provider oriented allocation. Given continuous negative comments about renumbering, and given continuous growth of multihomed subscribers, I really wonder whether we have a consensus that this approach "will work". > Other approaches are interesting but could be described as a research > activity. Do we have a consensus on your evaluation of other approaches as "a research activity" ? Yakov. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Jul 24 13:11:38 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA22741; Mon, 24 Jul 95 13:11:38 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA22725; Mon, 24 Jul 95 13:07:51 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA22092; Mon, 24 Jul 1995 12:57:19 -0700 Received: from alpha.xerox.com by mercury.Sun.COM (Sun.COM) id MAA16483; Mon, 24 Jul 1995 12:57:13 -0700 Received: from redwing.parc.xerox.com ([13.2.116.19]) by alpha.xerox.com with SMTP id <15209(5)>; Mon, 24 Jul 1995 12:56:48 PDT Received: by redwing.parc.xerox.com id <177520>; Mon, 24 Jul 1995 12:56:44 -0700 Date: Mon, 24 Jul 1995 12:56:32 PDT From: Lixia Zhang To: Yakov Rekhter , ipng@sunroof.Eng.Sun.COM Subject: (IPng 372) Re: Lixia's study group In-Reply-To: Your message of Mon, 24 Jul 1995 11:35:15 -0700 Message-Id: Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk > However, I hope that the results of your group > study would help the IPng WG make a more informed decision wrt > to the IPv6 address allocation and address format documents. > Would you agree with this ? Yakov, First of all, I don't think it is *my* group, but rather it is *your* group :-) I'm merely an organizer, while you're one of the active participants. Other people in the group are also heavily involved in the IPv6 process (e.g. Deering); they have not felt the need to stop moving the named documents to more advanced stage, and personally I value their judgment. Furthermore, all our studies so far have been exploring impacts and open issues of different approaches, including the one you documented in the two I-Ds, that helps ourselves get better prepared in deploying the approach. The study group is here to help; it is *not* meant to interfere the current IPv6 progress, which has been going along so well, thanks to the tremendous effort put in by many people on this list. I assume you share the desire with me to help along and cheer the progress. Lixia ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Jul 24 13:29:33 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA22786; Mon, 24 Jul 95 13:29:33 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA22770; Mon, 24 Jul 95 13:25:25 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA24285; Mon, 24 Jul 1995 13:14:53 -0700 Received: from hubbub.cisco.com by mercury.Sun.COM (Sun.COM) id NAA20446; Mon, 24 Jul 1995 13:14:51 -0700 Received: from puli.cisco.com (puli.cisco.com [171.69.1.174]) by hubbub.cisco.com (8.6.10/CISCO.GATE.1.1) with SMTP id NAA12201; Mon, 24 Jul 1995 13:14:50 -0700 Message-Id: <199507242014.NAA12201@hubbub.cisco.com> To: Lixia Zhang Cc: ipng@sunroof.Eng.Sun.COM Subject: (IPng 373) Re: Lixia's study group In-Reply-To: Your message of "Mon, 24 Jul 95 12:56:32 PDT." Date: Mon, 24 Jul 95 13:14:49 PDT From: Yakov Rekhter Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Lixia, > > The study group is here to help; it is *not* meant to interfere the > current IPv6 progress, which has been going along so well, thanks to > the tremendous effort put in by many people on this list. Agreed. The group is *not* to interfere with the current IPv6 progress, but to help this progress by factoring into the decision process the results produced by this group. > > I assume you share the desire with me to help along and cheer the > progress. Absolutely ! Yakov. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Jul 24 13:51:40 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA22859; Mon, 24 Jul 95 13:51:40 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA22853; Mon, 24 Jul 95 13:51:32 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA27865; Mon, 24 Jul 1995 13:41:01 -0700 Received: from alpha.xerox.com by mercury.Sun.COM (Sun.COM) id NAA26294; Mon, 24 Jul 1995 13:40:58 -0700 Received: from redwing.parc.xerox.com ([13.2.116.19]) by alpha.xerox.com with SMTP id <15516(5)>; Mon, 24 Jul 1995 13:40:51 PDT Received: by redwing.parc.xerox.com id <177520>; Mon, 24 Jul 1995 13:40:47 -0700 Date: Mon, 24 Jul 1995 13:40:41 PDT From: Lixia Zhang To: ipng@sunroof.Eng.Sun.COM Subject: (IPng 374) Re: Lixia's study group In-Reply-To: Your message of Mon, 24 Jul 1995 12:44:24 -0700 Message-Id: Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk > The purpose of this study group is specifically to look at different address > allocation strategies for *IPv6*. This group was asked to evaluate alternative address allocation strategies for the Internet. How much, if at all, we can influence the current practice in IPv4 address allocation is another question. > > These two documents describe a provider oriented allocation scheme > > consistent with CIDR. As such they are the only allocation approach which > > we think will work. > > As you recall, Lixia's presentation identified the need to renumber, > and support for multihomed subscribers as important deficiencies of > the provider oriented allocation. Yakov, I'd like to make the following corrections: - During our group meeting at Stockholm, Yakov pointed out, correctly, that IPv4 architecture explicitly allows multihoming (and that's what I put in my talk slides) - The need to renumber was identified and emphasized by Peter Ford in his talk preceding me. - I presented some potential issues associated with renumbering, as explored during our discussion of last couple of months. I emphasized the need to address these issues in deploying renumbering. Lixia ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Jul 24 14:18:03 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA22895; Mon, 24 Jul 95 14:18:03 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA22889; Mon, 24 Jul 95 14:17:54 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA01515; Mon, 24 Jul 1995 14:07:24 -0700 Received: from servo.ipsilon.com by mercury.Sun.COM (Sun.COM) id OAA02410; Mon, 24 Jul 1995 14:07:21 -0700 Received: from [204.160.241.224] (acacia.Ipsilon.COM [204.160.241.224]) by servo.ipsilon.com (8.6.11/8.6.10) with SMTP id OAA01620; Mon, 24 Jul 1995 14:06:07 -0700 X-Sender: hinden@mailhost.ipsilon.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 24 Jul 1995 14:08:28 -0700 To: Yakov Rekhter From: hinden@Ipsilon.COM (Bob Hinden) Subject: (IPng 375) Re: Lixia's study group Cc: hinden@Ipsilon.COM (Bob Hinden), ipng@sunroof.Eng.Sun.COM Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Yakov, >The purpose of this study group is specifically to look at different address >allocation strategies for *IPv6*. So, I wonder why do you think that this >group does not have "any direct relationship to the IPv6 work" ? Direct as in the output of the study group is not the product of the IPng working group. >As you recall, Lixia in her presentation promised to complete the study >by the next IETF. So, I don't understand your statement that "It is >unclear when >the study group will be done". I suspect that all issues with all of the approaches will not be resolved by the next IETF. The study group may be done, but I doubt the work will be done. >> These two documents describe a provider oriented allocation scheme >> consistent with CIDR. As such they are the only allocation approach which >> we think will work. > >As you recall, Lixia's presentation identified the need to renumber, >and support for multihomed subscribers as important deficiencies of >the provider oriented allocation. Given continuous negative comments >about renumbering, and given continuous growth of multihomed subscribers, >I really wonder whether we have a consensus that this approach "will work". The IPv6 working groups are developing solutions to renumbering now. See the current drafts of neighbor discovery and address auto-configuration. I don't think I have heard any negative comments about the IPv6 renumbering. I believe that IPv6 renumbering will work. >Do we have a consensus on your evaluation of other approaches as "a research >activity" ? If the two of us agree, then it must be a consensus :-) Bob ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Jul 24 14:49:04 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA22937; Mon, 24 Jul 95 14:49:04 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA22930; Mon, 24 Jul 95 14:48:55 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA05829; Mon, 24 Jul 1995 14:38:22 -0700 Received: from hubbub.cisco.com by mercury.Sun.COM (Sun.COM) id OAA08774; Mon, 24 Jul 1995 14:38:20 -0700 Received: from puli.cisco.com (puli.cisco.com [171.69.1.174]) by hubbub.cisco.com (8.6.10/CISCO.GATE.1.1) with SMTP id OAA18798; Mon, 24 Jul 1995 14:38:17 -0700 Message-Id: <199507242138.OAA18798@hubbub.cisco.com> To: Lixia Zhang Cc: ipng@sunroof.Eng.Sun.COM Subject: (IPng 376) Re: Lixia's study group In-Reply-To: Your message of "Mon, 24 Jul 95 13:40:41 PDT." Date: Mon, 24 Jul 95 14:38:17 PDT From: Yakov Rekhter Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Lixia, > I'd like to make the following corrections: > > - During our group meeting at Stockholm, Yakov pointed out, correctly, > that IPv4 architecture explicitly allows multihoming (and that's > what I put in my talk slides) First, let me point out that while the architecture supports multiple addresses per host interface, the architecture provides little or no guidance on how to use this functionality. So, there is little or no host vendor implementations that would allow to exploit this functionality in any meaningful fashion. While support for multi-homed hosts is *necessary* for scalable support of multi-homed sites with provider-based addressing (hosts within a multi-homed site are assigned multiple addresses, one per provider), it is far from obvious that it is *sufficient*. For example, how would an IPv6 host (with multiple addresses per interface) within a (multihomed) site would be able to to preserve an existing transport connection to a host in another site, when the site loses its connectivity to one of its providers. So to summarise, the architecture is certainly incomplete wrt to support for multiple addresses per interface, and supporting multiple addresses per interface may not be sufficient to support multi-homed sites. > > - The need to renumber was identified and emphasized by Peter Ford in > his talk preceding me. We all understand the need. The question is whether IPv6 would adequately address this need, so that renumbering would not be viewed as a significant drawback of provider-based addressing. Yakov. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Jul 24 15:03:17 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA22962; Mon, 24 Jul 95 15:03:17 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA22956; Mon, 24 Jul 95 15:03:08 PDT Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AB07766; Mon, 24 Jul 1995 14:52:36 -0700 Received: from hubbub.cisco.com by Sun.COM (sun-barr.Sun.COM) id AA28366; Mon, 24 Jul 95 14:52:33 PDT Received: from puli.cisco.com (puli.cisco.com [171.69.1.174]) by hubbub.cisco.com (8.6.10/CISCO.GATE.1.1) with SMTP id OAA19620; Mon, 24 Jul 1995 14:49:31 -0700 Message-Id: <199507242149.OAA19620@hubbub.cisco.com> To: hinden@ipsilon.com (Bob Hinden) Cc: ipng@sunroof.Eng.Sun.COM Subject: (IPng 377) Re: Lixia's study group In-Reply-To: Your message of "Mon, 24 Jul 95 14:08:28 PDT." Date: Mon, 24 Jul 95 14:49:30 PDT From: Yakov Rekhter Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Bob, > I believe that IPv6 renumbering will work. I would very much like to get the IPng WG consensus (need not be clear, rough would be ok) that IPv6 renumbering will work *adequately enough*, including addressing the issues raised by Lixia in her presentation, as to make renumbering due to provider-based addressing a non-issue for IPv6. Yakov. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Jul 24 17:39:01 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA23044; Mon, 24 Jul 95 17:39:01 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA23038; Mon, 24 Jul 95 17:38:53 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA28519; Mon, 24 Jul 1995 17:28:21 -0700 Received: from alpha.xerox.com by mercury.Sun.COM (Sun.COM) id RAA10293; Mon, 24 Jul 1995 17:28:17 -0700 Received: from redwing.parc.xerox.com ([13.2.116.19]) by alpha.xerox.com with SMTP id <15509(2)>; Mon, 24 Jul 1995 17:28:08 PDT Received: by redwing.parc.xerox.com id <177520>; Mon, 24 Jul 1995 17:28:03 -0700 Date: Mon, 24 Jul 1995 17:28:02 PDT From: Lixia Zhang To: ipng@sunroof.Eng.Sun.COM Subject: (IPng 378) Re: Lixia's study group In-Reply-To: Your message of Mon, 24 Jul 1995 14:38:17 -0700 Message-Id: Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk I looked out the window wondering if today's sunset would be on the east :-) Yakov, you sound like a totally different person today :-) But seriously by all means I'm glad to see that more people recognize the technical issues related to renumbering, rather than going around telling stories like "how bad address ownership is". > > - During our group meeting at Stockholm, Yakov pointed out, correctly, > > that IPv4 architecture explicitly allows multihoming (and that's > > what I put in my talk slides) > > First, let me point out that while the architecture supports multiple > addresses per host interface, the architecture provides little or no guidance on > how to use this functionality. Absolutely. And to give the credit to where it is due, it was Dave Clark who pointed this issue out, stating that not only we have not developed guidelines but also that there is not yet an existing effort to do so (I reported all this, in verbatim, in my presentation) And I believe that Dave's addressing proposal (posted to this list last Dec, I think) addresses this issue as one of its goals. > While support for multi-homed hosts is *necessary* for scalable support > of multi-homed sites with provider-based addressing (hosts within a > multi-homed site are assigned multiple addresses, one per provider), it > is far from obvious that it is *sufficient*. For example, how would an IPv6 > host (with multiple addresses per interface) within a (multihomed) site > would be able to to preserve an existing transport connection to a host > in another site, when the site loses its connectivity to one of its providers. Again, agreement here. Just for the record, my talk *did* describe this one, together with a number of other issues. > > - The need to renumber was identified and emphasized by Peter Ford in > > his talk preceding me. > > We all understand the need. The question is whether IPv6 would adequately > address this need, so that renumbering would not be viewed as a significant > drawback of provider-based addressing. I'd just make the following general statements: - There is a clear distinction between whether we understand the the impact of doing X, and whether we have all the solutions handy. Understanding the issues is a first step towards solutions. - The attitude of "doing X is THE right way and it'd be just wonderful" is not correct. On the other hand, "going nowhere till perfect solutions show up for everything" does not sound like IETF either. - I believe the current IPv6 address assignment plan has flexibility to accommodate alternative approaches should the need rise in the future. - Except the selection among multiple addresses, most issues we've identified, including the one cited above, are related to higher level protocols and applications, rather than IPv6 issues. - These higher level problems exist with *today's* IPv4 provider-based address assignment, they must be handled, and must be handled soon. The solutions will then likely work with IPv6 as well (thank God IP6 did not change the fundamental IP architecture) Lixia ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Jul 24 17:51:51 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA23065; Mon, 24 Jul 95 17:51:51 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA23059; Mon, 24 Jul 95 17:51:43 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA29879; Mon, 24 Jul 1995 17:41:11 -0700 Received: from inet-gw-2.pa.dec.com by mercury.Sun.COM (Sun.COM) id RAA12494; Mon, 24 Jul 1995 17:41:12 -0700 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-2.pa.dec.com (5.65/24Feb95) id AA05047; Mon, 24 Jul 95 17:39:16 -0700 Received: by xirtlu.zk3.dec.com; id AA04509; Mon, 24 Jul 1995 20:39:21 -0400 Message-Id: <9507250039.AA04509@xirtlu.zk3.dec.com> To: Yakov Rekhter Cc: hinden@ipsilon.com (Bob Hinden), ipng@sunroof.Eng.Sun.COM Subject: (IPng 379) Re: Lixia's study group In-Reply-To: Your message of "Mon, 24 Jul 95 14:49:30 PDT." <199507242149.OAA19620@hubbub.cisco.com> Date: Mon, 24 Jul 95 20:39:15 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk I think we need to advance the specs to proposed standard. During the time from proposed to draft std I think any input we can get as a WG is really really good. The Study Group input will influence me as others I am sure just like when one of us implements IPv6 and tells each other about a feature or bug we find in the specs. So I view moving the present specs along and awaiting the study group results as a win-win scenario. Where I have concerns is what I stated at the podium to Lixia and now Bob Hindens' response to Yakov per addr conf and ND specs. Both of these specs have a deprecation and invalidation lifetime and a strategy to permit renumbering (in a sense realtime) of addresses. I am now determining how this can be implemented and used above the IP layer for IPv6 (see addr conf spec when/how to use these lifetimes). Both ND and Addr Conf are up for proposed std and I agree with Bob on the point that now is the time to relay issues as they will be in last call soon. But clearly these are a start. I have used the same methodology in DHCPv6 as addr conf and ND for that stateful version of autoconfiguration and will be completely in synch with addr conf and ND. In addition Dyn Upds to DNS also will assist with renumbering to permit software developers to write code to also update the DNS as renumbering takes place. I think we are doing the basics for renumbering in IPv6 for the protocols that are being developed to get us to the next generation Internet Protocol (IPv6). But I think there can be an entire suite of protocols to address the renumbering in other parts of the network components such as once the new provider is selected and the administratrive changes can be downloaded to routers (possibly anycast addresses) to begin the topological address change at a network site. I have a lot more ideas on this but thats not part of IPv6 but probably should be part of the ops area in the IETF. Clearly if the IETF does not address the higher level components of renumbering some savy software developers working with providers will for sure IMHO (might even be a good business opportunity for software). But I think in IPv6/DNS/DHC WGs we have done a real good job of giving the industry the low level architecture in addr conf, ND, DHCPv6, and Dyn Upds to get that part of the job done. All of these should be proposed standards by or right after Dec 95 IETF. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Jul 24 19:12:36 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA23112; Mon, 24 Jul 95 19:12:36 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA23106; Mon, 24 Jul 95 19:12:23 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA07298; Mon, 24 Jul 1995 19:01:51 -0700 Received: from ndtl.harvard.edu by mercury.Sun.COM (Sun.COM) id TAA23283; Mon, 24 Jul 1995 19:01:52 -0700 Received: (from sob@localhost) by ndtl.harvard.edu (8.6.9/8.6.9-MT2.02) id VAA23534 for ipng@sunroof.Eng.Sun.COM; Mon, 24 Jul 1995 21:23:01 -0400 (EDT) Date: Mon, 24 Jul 1995 21:23:01 -0400 (EDT) From: Scott Bradner Message-Id: <199507250123.VAA23534@ndtl.harvard.edu> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng 380) Re: Lixia's study group Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Having just cought up on Mail from being away all day, I'd like to stick my few cents worth in here. I'd like to echo what Lixia, Bob & Jim have said. My reading of the working group is that we should progress the documents in question. Provider-based (or network-topology-based) addressing is all we know how to do. We have quite a bit of operational understanding of it, and its limitations (most of which were brought out in the IETF presentations). Of these limatations (the need for renumbering, multi-addresses/interface etc) are addressed, so far without guidance, in the IPv6 work. I can see no way that this type of addressing will not be the 1st type of addressing used with IPv6. having said that, I think that the work that is going on in "Lixia's group" (or is it Yakov's group?) may become quite important, given ponder and research time. A future recommendation from the IPv6-d (tacit?) wg may be to start switching to an addressing plan that results from this work but, in the meantime, I think we have to have what we know ready to be used. I think it is time to progress the documents. Scott ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Jul 24 23:52:35 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA23235; Mon, 24 Jul 95 23:52:35 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA23229; Mon, 24 Jul 95 23:52:26 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA21236; Mon, 24 Jul 1995 23:41:55 -0700 Received: from dxmint.cern.ch by mercury.Sun.COM (Sun.COM) id XAA18647; Mon, 24 Jul 1995 23:41:46 -0700 Received: from dxcoms.cern.ch by dxmint.cern.ch id AA00750; Tue, 25 Jul 1995 08:41:43 +0200 Received: by dxcoms.cern.ch id AA27821; Tue, 25 Jul 1995 08:41:41 +0200 Message-Id: <9507250641.AA27821@dxcoms.cern.ch> Subject: (IPng 381) Re: Lixia's study group To: ipng@sunroof.Eng.Sun.COM (IPv6 List) Date: Tue, 25 Jul 1995 08:41:41 +0200 (MET DST) From: "Brian Carpenter CERN-CN" In-Reply-To: <199507250123.VAA23534@ndtl.harvard.edu> from "Scott Bradner" at Jul 24, 95 09:23:01 pm X-Mailer: ELM [version 2.4 PL23 DXCOMS1] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Scott said: > I'd like to echo what Lixia, Bob & Jim have said. My reading of the > working group is that we should progress the documents in question. > I agree. If anyone is worried by this I would suggest 4 arguments: 1. The current provider proposal burns up only 1/8 of the total address space anyway. We have a lot of flexibility to add new schemes later. 2. In any case we are several years away from widespread deployment, so there is time to change if we have to. 3. In any case we are one to two years away from Internet Standard status, again giving time to change. 4. Early implementors need something concrete to work with right now. Brian Carpenter ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Jul 25 04:28:07 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA23424; Tue, 25 Jul 95 04:28:07 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA23418; Tue, 25 Jul 95 04:27:57 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA00906; Tue, 25 Jul 1995 04:17:26 -0700 Received: from necom830.cc.titech.ac.jp by mercury.Sun.COM (Sun.COM) id EAA08915; Tue, 25 Jul 1995 04:17:24 -0700 Received: by necom830.cc.titech.ac.jp (8.6.11/necom-mx-rg); Tue, 25 Jul 1995 20:13:12 +0900 From: Masataka Ohta Message-Id: <199507251113.UAA11549@necom830.cc.titech.ac.jp> Subject: (IPng 382) Re: Lixia's study group To: hinden@Ipsilon.COM (Bob Hinden) Date: Tue, 25 Jul 95 20:13:11 JST Cc: yakov@cisco.com, hinden@Ipsilon.COM, ipng@sunroof.Eng.Sun.COM In-Reply-To: ; from "Bob Hinden" at Jul 24, 95 2:08 pm X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk > >As you recall, Lixia's presentation identified the need to renumber, Not at all. As I pointed out, it identify the need of the initial dynamic numbering and latter mobility. > The IPv6 working groups are developing solutions to renumbering now. See > the current drafts of neighbor discovery and address auto-configuration. I > don't think I have heard any negative comments about the IPv6 renumbering. > I believe that IPv6 renumbering will work. That's the mechanism useful only for the initial dynamic numbering. Renumbering, which involves invalidation/update of the existing mapping, is a lot more harder and nothing, if any, more than a research topic. Masataka Ohta ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Jul 25 04:37:21 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA23454; Tue, 25 Jul 95 04:37:21 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA23448; Tue, 25 Jul 95 04:37:13 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA01210; Tue, 25 Jul 1995 04:26:42 -0700 Received: from necom830.cc.titech.ac.jp by mercury.Sun.COM (Sun.COM) id EAA09579; Tue, 25 Jul 1995 04:26:39 -0700 Received: by necom830.cc.titech.ac.jp (8.6.11/necom-mx-rg); Tue, 25 Jul 1995 20:22:37 +0900 From: Masataka Ohta Message-Id: <199507251122.UAA11585@necom830.cc.titech.ac.jp> Subject: (IPng 383) Re: Lixia's study group To: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Date: Tue, 25 Jul 95 20:22:35 JST Cc: ipng@sunroof.Eng.Sun.COM In-Reply-To: <9507250641.AA27821@dxcoms.cern.ch>; from "Brian Carpenter CERN-CN" at Jul 25, 95 8:41 am X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk > > I'd like to echo what Lixia, Bob & Jim have said. My reading of the > > working group is that we should progress the documents in question. > > > I agree. If anyone is worried by this I would suggest 4 > arguments: > > 1. The current provider proposal burns up only 1/8 of the > total address space anyway. We have a lot of flexibility to add > new schemes later. No. At Danvers, the WG considers 1/8 is TOO much. A WG consensus on addressing is that Yakov's proposal should not burn so large area so that additional restriction should be imposed to make leading and traling bytes of provider dependent parts fixed 0. It was also agreed that a proposal and a restriction should be published as informational RFCs. > 4. Early implementors need something concrete to work with right now. That's another consensus at Danvers that we temporalily need some addressing scheme, which may or may not be a bad one. I don't think there was any other consensus of the WG on the addressing architecture. Masataka Ohta ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Jul 25 05:01:31 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA23467; Tue, 25 Jul 95 05:01:31 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA23461; Tue, 25 Jul 95 05:01:22 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA01895; Tue, 25 Jul 1995 04:50:52 -0700 Received: from hubbub.cisco.com by mercury.Sun.COM (Sun.COM) id EAA11277; Tue, 25 Jul 1995 04:50:51 -0700 Received: from puli.cisco.com (puli.cisco.com [171.69.1.174]) by hubbub.cisco.com (8.6.10/CISCO.GATE.1.1) with SMTP id EAA12170; Tue, 25 Jul 1995 04:50:49 -0700 Message-Id: <199507251150.EAA12170@hubbub.cisco.com> To: Lixia Zhang Cc: ipng@sunroof.Eng.Sun.COM Subject: (IPng 384) Re: Lixia's study group In-Reply-To: Your message of "Mon, 24 Jul 95 17:28:02 PDT." Date: Tue, 25 Jul 95 04:50:48 PDT From: Yakov Rekhter Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Lixia, > But seriously by all means I'm glad to see that more people recognize > the technical issues related to renumbering, rather than going around > telling stories like "how bad address ownership is". "Address ownership" is neither "bad" nor "good". It is just *incompatible* with the "provider-based" addressing. It would be a *disservice* to the IETF community if we wouldn't articulate this incompatibility *up front*. So, we need to "go around telling stories like" "address ownership" is incompatible with the provider-based addressing. > > I'd just make the following general statements: > > - Except the selection among multiple addresses, most issues we've > identified, including the one cited above, are related to higher > level protocols and applications, rather than IPv6 issues. Making it "someone else's problem" is not a solution. > > - These higher level problems exist with *today's* IPv4 provider-based > address assignment, they must be handled, and must be handled soon. > > The solutions will then likely work with IPv6 as well (thank God IP6 > did not change the fundamental IP architecture) Since IPv6 allows for much larger Internet than IPv4, solutions that could be applied to IPv4 (e.g. just put more memory) may not be applicable to IPv6. Yakov. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Jul 25 05:20:17 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA23487; Tue, 25 Jul 95 05:20:17 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA23481; Tue, 25 Jul 95 05:20:09 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA02457; Tue, 25 Jul 1995 05:09:38 -0700 Received: from hubbub.cisco.com by mercury.Sun.COM (Sun.COM) id FAA12710; Tue, 25 Jul 1995 05:09:38 -0700 Received: from puli.cisco.com (puli.cisco.com [171.69.1.174]) by hubbub.cisco.com (8.6.10/CISCO.GATE.1.1) with SMTP id FAA12706; Tue, 25 Jul 1995 05:06:59 -0700 Message-Id: <199507251206.FAA12706@hubbub.cisco.com> To: bound@zk3.dec.com Cc: ipng@sunroof.Eng.Sun.COM Subject: (IPng 385) Re: Lixia's study group In-Reply-To: Your message of "Mon, 24 Jul 95 20:39:15 EDT." <9507250039.AA04509@xirtlu.zk3.dec.com> Date: Tue, 25 Jul 95 05:06:59 PDT From: Yakov Rekhter Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Jim, > > I think we are doing the basics for renumbering in IPv6 for the > protocols that are being developed to get us to the next generation > Internet Protocol (IPv6). But I think there can be an entire suite of > protocols to address the renumbering in other parts of the network > components such as once the new provider is selected and the > administratrive changes can be downloaded to routers (possibly anycast > addresses) to begin the topological address change at a network site. > I have a lot more ideas on this but thats not part of IPv6 but probably > should be part of the ops area in the IETF. The ability to renumber a whole segment of a network (and not just hosts) is an *essential precondition* for the provider-based addressing to work. Saying that this is "not part of IPv6 but probably should be part of the ops area" does not eliminate this precondition (it just moves this work from one area in the IESG to another). Neither does it solve the problem. And without solving this problem the large scale IPv6 deployment based on the provider-based addressing would cause IPv6 routing system meltdown. > But I think in IPv6/DNS/DHC WGs we have done a real good job of giving > the industry the low level architecture in addr conf, ND, DHCPv6, and Dyn > Upds to get that part of the job done. All of these should be proposed > standards by or right after Dec 95 IETF. > I fully agree that moving ahead with things like addr conf, neighbor discovery, DHCPv6 and Dyn DNS updates is a good idea; as you may know I am actively working on some of these things (Dyn DNS Updates). Yakov. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Jul 25 05:25:07 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA23503; Tue, 25 Jul 95 05:25:07 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA23497; Tue, 25 Jul 95 05:24:59 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA02637; Tue, 25 Jul 1995 05:14:28 -0700 Received: from hubbub.cisco.com by mercury.Sun.COM (Sun.COM) id FAA13192; Tue, 25 Jul 1995 05:14:28 -0700 Received: from puli.cisco.com (puli.cisco.com [171.69.1.174]) by hubbub.cisco.com (8.6.10/CISCO.GATE.1.1) with SMTP id FAA12912; Tue, 25 Jul 1995 05:14:15 -0700 Message-Id: <199507251214.FAA12912@hubbub.cisco.com> To: "Brian Carpenter CERN-CN" Cc: ipng@sunroof.Eng.Sun.COM (IPv6 List) Subject: (IPng 386) Re: Lixia's study group In-Reply-To: Your message of "Tue, 25 Jul 95 08:41:41 +0100." <9507250641.AA27821@dxcoms.cern.ch> Date: Tue, 25 Jul 95 05:14:14 PDT From: Yakov Rekhter Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Brian, > 4. Early implementors need something concrete to work with right now. For transition purposes every IPv6 host must have IPv4 compatible address. Early implementors can use these IPv6 addresses *right now*. Yakov. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Jul 25 05:31:30 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA23515; Tue, 25 Jul 95 05:31:30 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA23509; Tue, 25 Jul 95 05:31:17 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA02901; Tue, 25 Jul 1995 05:20:46 -0700 Received: from ndtl.harvard.edu by mercury.Sun.COM (Sun.COM) id FAA13798; Tue, 25 Jul 1995 05:20:43 -0700 Received: (from sob@localhost) by ndtl.harvard.edu (8.6.9/8.6.9-MT2.02) id IAA24217; Tue, 25 Jul 1995 08:24:18 -0400 (EDT) Date: Tue, 25 Jul 1995 08:24:18 -0400 (EDT) From: Scott Bradner Message-Id: <199507251224.IAA24217@ndtl.harvard.edu> To: brian@dxcoms.cern.ch, mohta@necom830.cc.titech.ac.jp Subject: (IPng 387) Re: Lixia's study group Cc: ipng@sunroof.Eng.Sun.COM Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk I did not see a consensus that 1/8 was too large - some people did think that but it was quite far from a consensus Scott ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Jul 25 05:33:06 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA23527; Tue, 25 Jul 95 05:33:06 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA23521; Tue, 25 Jul 95 05:32:56 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA02987; Tue, 25 Jul 1995 05:22:25 -0700 Received: from hubbub.cisco.com by mercury.Sun.COM (Sun.COM) id FAA13971; Tue, 25 Jul 1995 05:22:25 -0700 Received: from puli.cisco.com (puli.cisco.com [171.69.1.174]) by hubbub.cisco.com (8.6.10/CISCO.GATE.1.1) with SMTP id FAA13107; Tue, 25 Jul 1995 05:21:49 -0700 Message-Id: <199507251221.FAA13107@hubbub.cisco.com> To: Scott Bradner Cc: ipng@sunroof.Eng.Sun.COM Subject: (IPng 388) Re: Lixia's study group In-Reply-To: Your message of "Mon, 24 Jul 95 21:23:01 EDT." <199507250123.VAA23534@ndtl.harvard.edu> Date: Tue, 25 Jul 95 05:21:48 PDT From: Yakov Rekhter Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Scott, > A future recommendation from the IPv6-d (tacit?) wg > may be to start switching to an addressing plan that results from this > work but, in the meantime, I think we have to have what we know ready > to be used. How many changes in the system do you expect will be necessary, and what components of the system do you expect would be impacted by switching to another addressing plan ? Is it just changing addresses on hosts and routers, or would that involve changes to the host and/or router code as well ? Yakov. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Jul 25 05:39:26 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA23543; Tue, 25 Jul 95 05:39:26 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA23537; Tue, 25 Jul 95 05:39:17 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA03196; Tue, 25 Jul 1995 05:28:46 -0700 Received: from hubbub.cisco.com by mercury.Sun.COM (Sun.COM) id FAA14699; Tue, 25 Jul 1995 05:28:46 -0700 Received: from puli.cisco.com (puli.cisco.com [171.69.1.174]) by hubbub.cisco.com (8.6.10/CISCO.GATE.1.1) with SMTP id FAA13296; Tue, 25 Jul 1995 05:28:10 -0700 Message-Id: <199507251228.FAA13296@hubbub.cisco.com> To: Scott Bradner Cc: ipng@sunroof.Eng.Sun.COM Subject: (IPng 389) Re: Lixia's study group In-Reply-To: Your message of "Tue, 25 Jul 95 08:24:18 EDT." <199507251224.IAA24217@ndtl.harvard.edu> Date: Tue, 25 Jul 95 05:28:10 PDT From: Yakov Rekhter Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Scott, > I did not see a consensus that 1/8 was too large - some people did think > that but it was quite far from a consensus > I wonder whether we have a consensus on whether there was a consensus :-) Yakov. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Jul 25 05:44:51 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA23556; Tue, 25 Jul 95 05:44:51 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA23550; Tue, 25 Jul 95 05:44:42 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA03486; Tue, 25 Jul 1995 05:34:12 -0700 Received: from hubbub.cisco.com by mercury.Sun.COM (Sun.COM) id FAA15241; Tue, 25 Jul 1995 05:34:11 -0700 Received: from puli.cisco.com (puli.cisco.com [171.69.1.174]) by hubbub.cisco.com (8.6.10/CISCO.GATE.1.1) with SMTP id FAA13607; Tue, 25 Jul 1995 05:34:06 -0700 Message-Id: <199507251234.FAA13607@hubbub.cisco.com> To: "Brian Carpenter CERN-CN" Cc: ipng@sunroof.Eng.Sun.COM (IPv6 List) Subject: (IPng 390) Re: Lixia's study group In-Reply-To: Your message of "Tue, 25 Jul 95 08:41:41 +0100." <9507250641.AA27821@dxcoms.cern.ch> Date: Tue, 25 Jul 95 05:34:05 PDT From: Yakov Rekhter Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Brian, > I agree. If anyone is worried by this I would suggest 4 > arguments: > > 1. The current provider proposal burns up only 1/8 of the > total address space anyway. We have a lot of flexibility to add > new schemes later. Yes, from the point of available address space I agree with your argument. > > 2. In any case we are several years away from widespread deployment, > so there is time to change if we have to. > > 3. In any case we are one to two years away from Internet Standard > status, again giving time to change. > I would be quite interested in getting some comments from host and router vendors about their view on this issue. Specifically, how acceptable would be for them a situation where the changes would impact host and/or router software. What would be their reaction if the changes would break backward compatibility ? Yakov. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Jul 25 05:49:27 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA23582; Tue, 25 Jul 95 05:49:27 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA23576; Tue, 25 Jul 95 05:49:18 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA03660; Tue, 25 Jul 1995 05:38:47 -0700 Received: from hubbub.cisco.com by mercury.Sun.COM (Sun.COM) id FAA15739; Tue, 25 Jul 1995 05:38:47 -0700 Received: from puli.cisco.com (puli.cisco.com [171.69.1.174]) by hubbub.cisco.com (8.6.10/CISCO.GATE.1.1) with SMTP id FAA13750; Tue, 25 Jul 1995 05:38:44 -0700 Message-Id: <199507251238.FAA13750@hubbub.cisco.com> To: Masataka Ohta Cc: ipng@sunroof.Eng.Sun.COM Subject: (IPng 391) Re: Lixia's study group In-Reply-To: Your message of "Tue, 25 Jul 95 20:22:35 +0200." <199507251122.UAA11585@necom830.cc.titech.ac.jp> Date: Tue, 25 Jul 95 05:38:43 PDT From: Yakov Rekhter Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk > That's another consensus at Danvers that we temporalily need some > addressing scheme, which may or may not be a bad one. As I mentioned before, use of IPv4 compatible addresses provides an addressing scheme for any IPv6 host *today*. Yakov. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Jul 25 05:56:57 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA23602; Tue, 25 Jul 95 05:56:57 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA23596; Tue, 25 Jul 95 05:56:44 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA03967; Tue, 25 Jul 1995 05:46:13 -0700 Received: from wintermute.imsi.com by mercury.Sun.COM (Sun.COM) id FAA16486; Tue, 25 Jul 1995 05:46:12 -0700 Received: from relay.imsi.com by wintermute.imsi.com id IAA26413; Tue, 25 Jul 1995 08:46:06 -0400 Received: from snark.imsi.com by relay.imsi.com id IAA26378; Tue, 25 Jul 1995 08:46:05 -0400 Received: by snark.imsi.com (4.1/SMI-4.1) id AA27826; Tue, 25 Jul 95 08:46:04 EDT Message-Id: <9507251246.AA27826@snark.imsi.com> To: Masataka Ohta Cc: ipng@sunroof.Eng.Sun.COM Subject: (IPng 392) Re: Lixia's study group In-Reply-To: Your message of "Tue, 25 Jul 1995 20:22:35 +0200." <199507251122.UAA11585@necom830.cc.titech.ac.jp> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Tue, 25 Jul 1995 08:46:04 -0400 From: "Perry E. Metzger" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Masataka Ohta writes: > > 1. The current provider proposal burns up only 1/8 of the > > total address space anyway. We have a lot of flexibility to add > > new schemes later. > > No. At Danvers, the WG considers 1/8 is TOO much. I don't think I attended the meeting in question, but I tend to agree that given current disputes about the long term direction of addressing, and given the vast size of the space, allocating a much smaller fraction of it to the current addressing plan would seem to be a good idea. Perry ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Jul 25 07:52:10 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA23689; Tue, 25 Jul 95 07:52:10 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA23683; Tue, 25 Jul 95 07:52:01 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA12329; Tue, 25 Jul 1995 07:41:29 -0700 Received: from VNET.IBM.COM by mercury.Sun.COM (Sun.COM) id HAA03482; Tue, 25 Jul 1995 07:41:20 -0700 Received: from RTP by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 7328; Tue, 25 Jul 95 10:41:07 EDT Received: by RTP (XAGENTA 4.0) id 0540; Tue, 25 Jul 1995 10:40:29 -0400 Received: by cichlid.raleigh.ibm.com (AIX 3.2/UCB 5.64/4.03) id AA18278; Tue, 25 Jul 1995 10:40:26 -0400 Message-Id: <9507251440.AA18278@cichlid.raleigh.ibm.com> To: Yakov Rekhter Cc: hinden@ipsilon.com (Bob Hinden), ipng@sunroof.Eng.Sun.COM Subject: (IPng 393) Re: Lixia's study group In-Reply-To: (Your message of Mon, 24 Jul 95 14:49:30 PDT.) <199507242149.OAA19620@hubbub.cisco.com> Date: Tue, 25 Jul 95 10:40:25 -0500 From: "Thomas Narten" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk >> I believe that IPv6 renumbering will work. >I would very much like to get the IPng WG consensus (need not be clear, >rough would be ok) that IPv6 renumbering will work *adequately enough*, >including addressing the issues raised by Lixia in her presentation, as to make >renumbering due to provider-based addressing a non-issue for IPv6. We need to be careful when talking about renumbering to be sure we are all speaking the same language about just what "renumbering" means. In particular, "renumbering" includes: 1) Getting a new prefix for a site, having nodes configure addresses using the new prefix, and having the routing infrastructure support addresses on the new prefix. 2) Deprecating/invalidating an address, including: a) insuring that nodes no longer use/recognize an address previously assigned to an interface. b) insuring that the routing system no longer delivers packets sent to a deprecated address to the node previously housing that address c) purging all cached bindings of the deprecated address to its previous meaning (e.g., everyone that has used or is using the deprecated address needs to stop using the old address and learn the new one). This touches such areas as DNS caching, applications that query the DNS only once and then assume the address returned is valid forever, open connections, etc. d) reassigning a deprecated address to a different node (e.g., the temporal component of global uniqueness). These issues are all somewhat related to each other, but yet are separate issues. 3) The frequency with which renumbering takes place. Here is where the "real" definition of "renumbering" comes into play. In particular: a) How quickly should the new address be used? b) How quickly must nodes stop using the "old" deprecated address? That is, what is the length of the transition period during which both the old and new addresses are valid? How aggressively should the transition from the old to the new address take place? Appropriate mechanisms for implementing short and aggressive transition times differ from those needed for conservative transitions lasting days and weeks. For example, renumbering on an hourly basis (short time, aggressive transition) implies that DNS TTLs may be extremely low compared to today. What are the implications of doing this? Also, short aggressive transition times probably require that TCP connections remain open across renumberings. This is a solvable problem, but one that requires host changes; IPng is not looking at this issue (yet). And of course, there is the important issue of how to do address/provider selection during the transition period. The current IPv6 framework only addresses points 1) and 2a). Points 2b) and 2d) can probably be dealt with without host involvement (e.g., handled within the routing infrastructure). Point 2c), especially when combined with short aggressive transition periods, has significant implications in practice for current implementations. Very much uncharted territory IMO. The current IPv6 framework assumes that renumbering will take place relatively infrequently (monthly or at most weekly basis) and will have a fairly long transition time (days to weeks). The transition will also be "conservative", in the sense that new connections use the new address, old connections continue using the old address, and at the end of the transition, it is assumed that the number of remaining "open" connections is small enough that they can simply be broken without causing much pain. My sense is that there are diverse views as to whether this assumption is valid, leading to confusion as to whether we "know" how to do "renumbering" now. IPv6 has taken an important step in making renumbering possible in certain (important) scenarios. At the same time, I would not call the problem solved. Thomas ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Jul 25 08:08:25 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA23701; Tue, 25 Jul 95 08:08:25 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA23695; Tue, 25 Jul 95 08:08:16 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA13622; Tue, 25 Jul 1995 07:57:44 -0700 Received: from dxmint.cern.ch by mercury.Sun.COM (Sun.COM) id HAA06374; Tue, 25 Jul 1995 07:57:42 -0700 Received: from dxcoms.cern.ch by dxmint.cern.ch id AA09042; Tue, 25 Jul 1995 16:57:34 +0200 Received: by dxcoms.cern.ch id AA25692; Tue, 25 Jul 1995 16:57:33 +0200 Message-Id: <9507251457.AA25692@dxcoms.cern.ch> Subject: (IPng 394) Re: Lixia's study group To: ipng@sunroof.Eng.Sun.COM (IPv6 List) Date: Tue, 25 Jul 1995 16:57:33 +0200 (MET DST) From: "Brian Carpenter CERN-CN" In-Reply-To: <199507251214.FAA12912@hubbub.cisco.com> from "Yakov Rekhter" at Jul 25, 95 05:14:14 am X-Mailer: ELM [version 2.4 PL23 DXCOMS1] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Yakov, > > 4. Early implementors need something concrete to work with right now. > > For transition purposes every IPv6 host must have IPv4 compatible address. > Early implementors can use these IPv6 addresses *right now*. I've been told by at least one implementor that they need some non-IPv4-compatible addresses too, and not just the link-local ones, for adequate testing. Brian ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Jul 25 08:35:17 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA23731; Tue, 25 Jul 95 08:35:17 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA23725; Tue, 25 Jul 95 08:35:09 PDT Received: from venus.Sun.COM (venus.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA15971; Tue, 25 Jul 1995 08:24:28 -0700 Received: from servo.ipsilon.com by venus.Sun.COM (Sun.COM) id IAA01349; Tue, 25 Jul 1995 08:24:23 -0700 Received: from [204.160.241.224] (acacia.Ipsilon.COM [204.160.241.224]) by servo.ipsilon.com (8.6.11/8.6.10) with SMTP id IAA12208; Tue, 25 Jul 1995 08:22:11 -0700 X-Sender: hinden@mailhost.ipsilon.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 25 Jul 1995 08:24:32 -0700 To: "Brian Carpenter CERN-CN" From: hinden@Ipsilon.COM (Bob Hinden) Subject: (IPng 395) Re: Lixia's study group Cc: ipng@sunroof.Eng.Sun.COM (IPv6 List) Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Brian, >I've been told by at least one implementor that they need some >non-IPv4-compatible addresses too, and not just the link-local >ones, for adequate testing. Yes, it is very important to test the neighbor discovery and addr-conf mechanisms. Bob ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Jul 25 08:49:03 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA23756; Tue, 25 Jul 95 08:49:03 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA23750; Tue, 25 Jul 95 08:48:54 PDT Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA17496; Tue, 25 Jul 1995 08:38:21 -0700 Received: from hubbub.cisco.com by Sun.COM (sun-barr.Sun.COM) id AA28008; Tue, 25 Jul 95 08:38:20 PDT Received: from puli.cisco.com (puli.cisco.com [171.69.1.174]) by hubbub.cisco.com (8.6.10/CISCO.GATE.1.1) with SMTP id IAA23000; Tue, 25 Jul 1995 08:35:18 -0700 Message-Id: <199507251535.IAA23000@hubbub.cisco.com> To: hinden@ipsilon.com (Bob Hinden) Cc: ipng@sunroof.Eng.Sun.COM (IPv6 List) Subject: (IPng 396) Re: Lixia's study group In-Reply-To: Your message of "Tue, 25 Jul 95 08:24:32 PDT." Date: Tue, 25 Jul 95 08:35:18 PDT From: Yakov Rekhter Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Bob, > >I've been told by at least one implementor that they need some > >non-IPv4-compatible addresses too, and not just the link-local > >ones, for adequate testing. > > Yes, it is very important to test the neighbor discovery and addr-conf > mechanisms. > I am sure that the IANA can allocate a small block of addresses (need not be 1/8 of the total IPv6 address space) for testing the neighbor discovery and addr-conf mechanisms. I certainly don't see any reason why we need provider-based addressing for this particular purpose. Yakov. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Jul 25 08:52:36 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA23768; Tue, 25 Jul 95 08:52:36 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA23762; Tue, 25 Jul 95 08:52:24 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA18020; Tue, 25 Jul 1995 08:41:50 -0700 Received: from wintermute.imsi.com by mercury.Sun.COM (Sun.COM) id IAA13835; Tue, 25 Jul 1995 08:41:38 -0700 Received: from relay.imsi.com by wintermute.imsi.com id LAA27261 for ; Tue, 25 Jul 1995 11:41:28 -0400 Received: from webster.imsi.com by relay.imsi.com id LAA28107 for ; Tue, 25 Jul 1995 11:41:27 -0400 Received: from snark.imsi.com by webster.imsi.com (4.1/SMI-4.1) id AA08700; Tue, 25 Jul 95 11:41:27 EDT Date: Tue, 25 Jul 95 11:41:27 EDT From: perry@imsi.com (Perry E. Metzger) Message-Id: <9507251541.AA08700@webster.imsi.com> Received: by snark.imsi.com (4.1/SMI-4.1) id AA23375; Tue, 25 Jul 95 11:41:26 EDT To: ipng@sunroof2.Eng.Sun.COM Subject: (IPng 397) we really should move forward Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk In my humble opinion, as important the addressing discussion is in the long term, we really ought to move forward. IPv6 is way too delayed as it is... Perry ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Jul 25 10:51:11 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA23863; Tue, 25 Jul 95 10:51:11 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA23857; Tue, 25 Jul 95 10:51:02 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA08195; Tue, 25 Jul 1995 10:39:25 -0700 Received: from hubbub.cisco.com by mercury.Sun.COM (Sun.COM) id KAA12087; Tue, 25 Jul 1995 10:37:31 -0700 Received: from puli.cisco.com (puli.cisco.com [171.69.1.174]) by hubbub.cisco.com (8.6.10/CISCO.GATE.1.1) with SMTP id KAA04966; Tue, 25 Jul 1995 10:36:59 -0700 Message-Id: <199507251736.KAA04966@hubbub.cisco.com> To: hinden@ipsilon.com (Bob Hinden) Cc: ipng@sunroof.Eng.Sun.COM (IPv6 List) Subject: (IPng 398) Re: Lixia's study group In-Reply-To: Your message of "Tue, 25 Jul 95 08:35:18 PDT." <199507251535.IAA23000@hubbub.cisco.com> Date: Tue, 25 Jul 95 10:36:58 PDT From: Yakov Rekhter Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk > Bob, > > > >I've been told by at least one implementor that they need some > > >non-IPv4-compatible addresses too, and not just the link-local > > >ones, for adequate testing. > > > > Yes, it is very important to test the neighbor discovery and addr-conf > > mechanisms. > > It was also suggested by Dan McDonald that for testing one could use site-local addresses. Yakov. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Jul 25 14:09:47 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA23917; Tue, 25 Jul 95 14:09:47 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA23911; Tue, 25 Jul 95 14:09:38 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA21351; Tue, 25 Jul 1995 13:59:05 -0700 Received: from servo.ipsilon.com by mercury.Sun.COM (Sun.COM) id NAA00428; Tue, 25 Jul 1995 13:58:51 -0700 Received: from [204.160.241.224] (acacia.Ipsilon.COM [204.160.241.224]) by servo.ipsilon.com (8.6.11/8.6.10) with SMTP id NAA16437; Tue, 25 Jul 1995 13:57:39 -0700 X-Sender: hinden@mailhost.ipsilon.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 25 Jul 1995 13:59:59 -0700 To: Yakov Rekhter From: hinden@Ipsilon.COM (Bob Hinden) Subject: (IPng 399) Re: Lixia's study group Cc: ipng@sunroof.Eng.Sun.COM Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Yakov, >It was also suggested by Dan McDonald that for testing one could >use site-local addresses. Yes, for some testing, but we need more than this to test multiple address prefixes per interface. This is needed to test multihomed sites and renumbering. I assume you think we should test the IPv6 renumbering mechanisms. Bob ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Jul 25 14:19:33 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA23929; Tue, 25 Jul 95 14:19:33 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA23923; Tue, 25 Jul 95 14:19:25 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA23385; Tue, 25 Jul 1995 14:08:39 -0700 Received: from hubbub.cisco.com by mercury.Sun.COM (Sun.COM) id OAA02930; Tue, 25 Jul 1995 14:08:21 -0700 Received: from puli.cisco.com (puli.cisco.com [171.69.1.174]) by hubbub.cisco.com (8.6.10/CISCO.GATE.1.1) with SMTP id OAA27369; Tue, 25 Jul 1995 14:07:48 -0700 Message-Id: <199507252107.OAA27369@hubbub.cisco.com> To: hinden@ipsilon.com (Bob Hinden) Cc: ipng@sunroof.Eng.Sun.COM Subject: (IPng 400) Re: Lixia's study group In-Reply-To: Your message of "Tue, 25 Jul 95 13:59:59 PDT." Date: Tue, 25 Jul 95 14:07:47 PDT From: Yakov Rekhter Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Bob, > >It was also suggested by Dan McDonald that for testing one could > >use site-local addresses. > > Yes, for some testing, but we need more than this to test multiple address > prefixes per interface. This is needed to test multihomed sites and > renumbering. Here is one possible alternative for testing multiple address prefixes per interface. Partition the site-local address space into several non-overlapping blocks (make the size of each block a power of 2). That would create multiple address prefixes, so that we'll be able to test multiple address prefixes per interface. Do you see any problem with this alternative ? > I assume you think we should test the IPv6 renumbering > mechanisms. Your assumption is certainly correct. Yakov. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Jul 25 14:36:03 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA23968; Tue, 25 Jul 95 14:36:03 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA23962; Tue, 25 Jul 95 14:35:54 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA26527; Tue, 25 Jul 1995 14:25:16 -0700 Received: from CU.NIH.GOV by mercury.Sun.COM (Sun.COM) id OAA07141; Tue, 25 Jul 1995 14:24:57 -0700 Message-Id: <199507252124.OAA07141@mercury.Sun.COM> To: hinden@Ipsilon.COM Cc: yakov@cisco.com, hinden@Ipsilon.COM, ipng@sunroof.Eng.Sun.COM From: "Roger Fajman" Date: Tue, 25 Jul 1995 17:23:12 EDT Subject: (IPng 401) Re: Lixia's study group Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk > The IPv6 working groups are developing solutions to renumbering now. See > the current drafts of neighbor discovery and address auto-configuration. I > don't think I have heard any negative comments about the IPv6 renumbering. > I believe that IPv6 renumbering will work. Here's a negative comment I have made before: while address autoconfiguration and DNS dynamic update are great steps forward in renumbering technology, they are not sufficient to get the job done as easily as it should be. There are all kinds of configuration files (router, DNS, DHCP, NETBIOS, TCP wrappers, etc.) that have IP numbers in them. Without automatic ways to update them, renumbering, although easier than now, will still be a significant project for a large site. Perhaps some sort of Renumbering Control Protocol is needed to pass information about renumbering thoughout an organization's network. Certainly greater use of DNS names is part of the solution, but probably not all of it. Use of DNS names in router configurations, for example, presents problems. Whatever the solution is, it needs to be written down in one or more RFCs. Roger Fajman Telephone: +1 301 402 4265 National Institutes of Health Bethesda, Maryland, USA Internet: RAF@CU.NIH.GOV ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Jul 25 15:22:03 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA24061; Tue, 25 Jul 95 15:22:03 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA24055; Tue, 25 Jul 95 15:21:50 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA04647; Tue, 25 Jul 1995 15:11:18 -0700 Received: from wintermute.imsi.com by mercury.Sun.COM (Sun.COM) id PAA18828; Tue, 25 Jul 1995 15:11:16 -0700 Received: from relay.imsi.com by wintermute.imsi.com id SAA29349; Tue, 25 Jul 1995 18:11:13 -0400 Received: from snark.imsi.com by relay.imsi.com id SAA03392; Tue, 25 Jul 1995 18:11:12 -0400 Received: by snark.imsi.com (4.1/SMI-4.1) id AA19917; Tue, 25 Jul 95 18:11:11 EDT Message-Id: <9507252211.AA19917@snark.imsi.com> To: "Roger Fajman" Cc: ipng@sunroof.Eng.Sun.COM Subject: (IPng 402) Re: Lixia's study group In-Reply-To: Your message of "Tue, 25 Jul 1995 17:23:12 EDT." <199507252124.OAA07141@mercury.Sun.COM> Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission Date: Tue, 25 Jul 1995 18:11:11 -0400 From: "Perry E. Metzger" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk "Roger Fajman" writes: > Here's a negative comment I have made before: while address > autoconfiguration and DNS dynamic update are great steps forward in > renumbering technology, they are not sufficient to get the job done as > easily as it should be. There are all kinds of configuration files > (router, DNS, DHCP, NETBIOS, TCP wrappers, etc.) that have IP numbers > in them. Without automatic ways to update them, renumbering, although > easier than now, will still be a significant project for a large site. This is indeed true. I made this point forcefully at Toronto, San Jose, and Stockholm. > Perhaps some sort of Renumbering Control Protocol is needed to pass > information about renumbering thoughout an organization's network. I'm not sure this is sufficient. Protocols aren't really going to fix this. The way to really fix this is to use databases with relational integrity to generate all the configuration files in a consistant manner. See MIT's work with Moira, for example. Unfortunately, this still doesn't fix node locked applications, miscelaneous proprietary application configurations, etc. We have no choice, however, so we should start pushing now to get the right solutions deployed. Perry ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Jul 25 16:14:13 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA24100; Tue, 25 Jul 95 16:14:13 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA24094; Tue, 25 Jul 95 16:14:04 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA12728; Tue, 25 Jul 1995 16:03:30 -0700 Received: from hubbub.cisco.com by mercury.Sun.COM (Sun.COM) id QAA00459; Tue, 25 Jul 1995 16:03:29 -0700 Received: from puli.cisco.com (puli.cisco.com [171.69.1.174]) by hubbub.cisco.com (8.6.10/CISCO.GATE.1.1) with SMTP id QAA06270; Tue, 25 Jul 1995 16:03:24 -0700 Message-Id: <199507252303.QAA06270@hubbub.cisco.com> To: perry@imsi.com Cc: ipng@sunroof.Eng.Sun.COM Subject: (IPng 403) Re: Lixia's study group In-Reply-To: Your message of "Tue, 25 Jul 95 18:11:11 EDT." <9507252211.AA19917@snark.imsi.com> Date: Tue, 25 Jul 95 16:03:23 PDT From: Yakov Rekhter Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Perry, > We have no choice, however, so we should start pushing now to get the > right solutions deployed. > So, what do you think is "the right solution" with respect to the address allocation architecture ? Yakov. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Jul 25 17:18:03 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA24179; Tue, 25 Jul 95 17:18:03 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA24173; Tue, 25 Jul 95 17:17:50 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA22046; Tue, 25 Jul 1995 17:07:17 -0700 Received: from ndtl.harvard.edu by mercury.Sun.COM (Sun.COM) id RAA13188; Tue, 25 Jul 1995 17:07:15 -0700 Received: (from sob@localhost) by ndtl.harvard.edu (8.6.9/8.6.9-MT2.02) id UAA26265; Tue, 25 Jul 1995 20:10:53 -0400 (EDT) Date: Tue, 25 Jul 1995 20:10:53 -0400 (EDT) From: Scott Bradner Message-Id: <199507260010.UAA26265@ndtl.harvard.edu> To: hinden@Ipsilon.COM, RAF@CU.NIH.GOV Subject: (IPng 404) Re: Lixia's study group Cc: ipng@sunroof.Eng.Sun.COM, yakov@cisco.com Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk > Whatever the solution is, it needs to be written down in one or more RFCs. there is an open action item for the CIDRD WG to do just that - there was a volunteer in Stockholm. Scott ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Jul 25 20:43:58 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA24278; Tue, 25 Jul 95 20:43:58 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA24272; Tue, 25 Jul 95 20:43:49 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA08319; Tue, 25 Jul 1995 20:33:15 -0700 Received: from alpha.xerox.com by mercury.Sun.COM (Sun.COM) id UAA08811; Tue, 25 Jul 1995 20:33:16 -0700 Received: from redwing.parc.xerox.com ([13.2.116.19]) by alpha.xerox.com with SMTP id <15806(5)>; Tue, 25 Jul 1995 20:33:07 PDT Received: by redwing.parc.xerox.com id <177520>; Tue, 25 Jul 1995 20:33:00 -0700 Date: Tue, 25 Jul 1995 20:32:51 PDT From: Lixia Zhang To: Yakov Rekhter , ipng@sunroof.Eng.Sun.COM Subject: (IPng 405) Re: Lixia's study group In-Reply-To: Your message of Tue, 25 Jul 1995 04:50:48 -0700 Message-Id: Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk > > But seriously by all means I'm glad to see that more people recognize > > the technical issues related to renumbering, rather than going around > > telling stories like "how bad address ownership is". > > "Address ownership" is neither "bad" nor "good". It is just *incompatible* > with the "provider-based" addressing. It would be a *disservice* to > the IETF community if we wouldn't articulate this incompatibility > *up front*. So, we need to "go around telling stories like" > "address ownership" is incompatible with the provider-based addressing. I certainly agree with the statement that "address ownership" is incompatible with the provider-based addressing. However all this "address ownership" argument seems a misfire on wrong target. No one really wants the ownership. Users unwillingness to give up addresses has many technical reasons behind it, as we witnessed in last couple of days (and many many times previously). To solve the problem we need to examine and resolve each and every technical issue related to address changes. Trying to redirect public attention to "address ownership" causes unnecessary confusion and helps nobody. Lixia ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Jul 25 21:13:53 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA24290; Tue, 25 Jul 95 21:13:53 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA24284; Tue, 25 Jul 95 21:13:44 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA09503; Tue, 25 Jul 1995 21:03:10 -0700 Received: from CU.NIH.GOV by mercury.Sun.COM (Sun.COM) id VAA11438; Tue, 25 Jul 1995 21:03:11 -0700 Message-Id: <199507260403.VAA11438@mercury.Sun.COM> To: sob@ndtl.harvard.edu Cc: hinden@Ipsilon.COM, ipng@sunroof.Eng.Sun.COM, yakov@cisco.com From: "Roger Fajman" Date: Wed, 26 Jul 1995 00:01:29 EDT Subject: (IPng 406) Re: Lixia's study group Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk > > Whatever the solution is, it needs to be written down in one or more RFCs. > > there is an open action item for the CIDRD WG to do just that - there > was a volunteer in Stockholm. > > Scott Wasn't that for IPv4 renumbering technology rather than IPv6? ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Jul 25 22:16:44 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA24314; Tue, 25 Jul 95 22:16:44 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA24308; Tue, 25 Jul 95 22:16:36 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA12055; Tue, 25 Jul 1995 22:06:02 -0700 Received: from alpha.xerox.com by mercury.Sun.COM (Sun.COM) id WAA16935; Tue, 25 Jul 1995 22:06:00 -0700 Received: from redwing.parc.xerox.com ([13.2.116.19]) by alpha.xerox.com with SMTP id <15803(4)>; Tue, 25 Jul 1995 22:05:43 PDT Received: by redwing.parc.xerox.com id <177520>; Tue, 25 Jul 1995 22:05:35 -0700 Date: Tue, 25 Jul 1995 22:05:33 PDT From: Lixia Zhang To: Yakov Rekhter Subject: (IPng 407) Re: Lixia's study group In-Reply-To: Your message of Tue, 25 Jul 1995 04:50:48 -0700 Cc: ipng@sunroof.Eng.Sun.COM Message-Id: Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk > > - These higher level problems exist with *today's* IPv4 provider-based > > address assignment, they must be handled, and must be handled soon. > > > > The solutions will then likely work with IPv6 as well (thank God IP6 > > did not change the fundamental IP architecture) > > Since IPv6 allows for much larger Internet than IPv4, solutions that > could be applied to IPv4 (e.g. just put more memory) may not be applicable > to IPv6. I do not know for sure whether all the solutions for IPv4 would be readily applicable to IPv6. But I also do not know as a fact that they are not. (I have no clue which of the known open issues you think can be coped with by more memory) I stand by my statement that IPv4 and IPv6 are likely to share common solutions to most, if not all, of the common problems. And I think we need to sit down and work the details out. Lixia ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Jul 25 22:23:48 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA24326; Tue, 25 Jul 95 22:23:48 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA24320; Tue, 25 Jul 95 22:23:40 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA12337; Tue, 25 Jul 1995 22:13:06 -0700 Received: from alpha.xerox.com by mercury.Sun.COM (Sun.COM) id WAA17884; Tue, 25 Jul 1995 22:13:08 -0700 Received: from redwing.parc.xerox.com ([13.2.116.19]) by alpha.xerox.com with SMTP id <15514(6)>; Tue, 25 Jul 1995 22:12:54 PDT Received: by redwing.parc.xerox.com id <177520>; Tue, 25 Jul 1995 22:12:51 -0700 Date: Tue, 25 Jul 1995 22:12:51 PDT From: Lixia Zhang To: ipng@sunroof.Eng.Sun.COM Subject: (IPng 408) Re: Lixia's study group In-Reply-To: Your message of Tue, 25 Jul 1995 05:06:59 -0700 Message-Id: Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk > Jim, > > The ability to renumber a whole segment of a network (and not just > hosts) is an *essential precondition* for the provider-based addressing > to work. Saying that this is "not part of IPv6 but probably should be > part of the ops area" does not eliminate this precondition (it just > moves this work from one area in the IESG to another). Neither does it > solve the problem. And without solving this problem the large scale > IPv6 deployment based on the provider-based addressing would cause IPv6 > routing system meltdown. I repeat my question here again: isn't it the case that today's CIDR is pushing provider-based addressing? Don't we have to cope with the issue, i.e. renumbering a whole segment of a network, now (well before any large scale IPv6 deployment)? Lixia ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Jul 25 22:28:34 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA24338; Tue, 25 Jul 95 22:28:34 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA24332; Tue, 25 Jul 95 22:28:25 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA12494; Tue, 25 Jul 1995 22:17:51 -0700 Received: from alpha.xerox.com by mercury.Sun.COM (Sun.COM) id WAA18443; Tue, 25 Jul 1995 22:17:53 -0700 Received: from redwing.parc.xerox.com ([13.2.116.19]) by alpha.xerox.com with SMTP id <15532(6)>; Tue, 25 Jul 1995 22:17:44 PDT Received: by redwing.parc.xerox.com id <177520>; Tue, 25 Jul 1995 22:17:37 -0700 Date: Tue, 25 Jul 1995 22:17:33 PDT From: Lixia Zhang To: ipng@sunroof.Eng.Sun.COM Subject: (IPng 409) Re: Lixia's study group In-Reply-To: Your message of Tue, 25 Jul 1995 05:21:48 -0700 Message-Id: Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk > Scott, > > > A future recommendation from the IPv6-d (tacit?) wg > > may be to start switching to an addressing plan that results from this > > work but, in the meantime, I think we have to have what we know ready > > to be used. > > How many changes in the system do you expect will be necessary, > and what components of the system do you expect would be impacted > by switching to another addressing plan ? Is it just changing addresses > on hosts and routers, or would that involve changes to the host and/or > router code as well ? Yakov, The above are all good questions, but I don't think they should be directed to Scott. Our study group needs to work them out and report back. Lixia ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Jul 25 22:32:38 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA24350; Tue, 25 Jul 95 22:32:38 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA24344; Tue, 25 Jul 95 22:32:30 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA12635; Tue, 25 Jul 1995 22:21:55 -0700 Received: from alpha.xerox.com by mercury.Sun.COM (Sun.COM) id WAA18837; Tue, 25 Jul 1995 22:21:53 -0700 Received: from redwing.parc.xerox.com ([13.2.116.19]) by alpha.xerox.com with SMTP id <15722(3)>; Tue, 25 Jul 1995 22:21:44 PDT Received: by redwing.parc.xerox.com id <177520>; Tue, 25 Jul 1995 22:21:37 -0700 Date: Tue, 25 Jul 1995 22:21:28 PDT From: Lixia Zhang To: ipng@sunroof.Eng.Sun.COM Subject: (IPng 410) Re: Lixia's study group In-Reply-To: Your message of Tue, 25 Jul 1995 05:34:05 -0700 Message-Id: Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk > > 2. In any case we are several years away from widespread deployment, > > so there is time to change if we have to. > > > > 3. In any case we are one to two years away from Internet Standard > > status, again giving time to change. > > > > I would be quite interested in getting some comments from host and router > vendors about their view on this issue. Specifically, how acceptable would > be for them a situation where the changes would impact host > and/or router software. What would be their reaction if the changes > would break backward compatibility ? Either I did not understand the question, or otherwise the answer seems obvious to me: if any future changes are deemed necessary, then they must be able to be phased in with backward compatibility. Lixia ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Jul 25 22:41:23 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA24367; Tue, 25 Jul 95 22:41:23 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA24361; Tue, 25 Jul 95 22:41:15 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AB12918; Tue, 25 Jul 1995 22:30:41 -0700 Received: from alpha.xerox.com by mercury.Sun.COM (Sun.COM) id WAA19702; Tue, 25 Jul 1995 22:30:43 -0700 Received: from redwing.parc.xerox.com ([13.2.116.19]) by alpha.xerox.com with SMTP id <15768(2)>; Tue, 25 Jul 1995 22:30:26 PDT Received: by redwing.parc.xerox.com id <177520>; Tue, 25 Jul 1995 22:30:23 -0700 Date: Tue, 25 Jul 1995 22:30:21 PDT From: Lixia Zhang To: perry@imsi.com, ipng@sunroof.Eng.Sun.COM Subject: (IPng 411) Re: we really should move forward In-Reply-To: Your message of Tue, 25 Jul 1995 08:41:27 -0700 Message-Id: Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk > In my humble opinion, as important the addressing discussion is in the > long term, we really ought to move forward. IPv6 is way too delayed as > it is... I agree here. (and thanks for taking my name off the subject line :-) Lixia ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Jul 26 04:06:22 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA24560; Wed, 26 Jul 95 04:06:22 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA24554; Wed, 26 Jul 95 04:06:08 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA24247; Wed, 26 Jul 1995 03:55:36 -0700 Received: from ndtl.harvard.edu by mercury.Sun.COM (Sun.COM) id DAA13868; Wed, 26 Jul 1995 03:55:35 -0700 Received: (from sob@localhost) by ndtl.harvard.edu (8.6.9/8.6.9-MT2.02) id GAA27140; Wed, 26 Jul 1995 06:58:51 -0400 (EDT) Date: Wed, 26 Jul 1995 06:58:51 -0400 (EDT) From: Scott Bradner Message-Id: <199507261058.GAA27140@ndtl.harvard.edu> To: RAF@CU.NIH.GOV, sob@ndtl.harvard.edu Subject: (IPng 412) Re: Lixia's study group Cc: hinden@Ipsilon.COM, ipng@sunroof.Eng.Sun.COM, yakov@cisco.com Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk > Wasn't that for IPv4 renumbering technology rather than IPv6? Roger, At least at the start, most of the "places" that are affected by renumbering are teh same for v4 & v6. Having a good document which details the places and includes some experiences will, while being targeted to IPv4, be quite useful in determining what IPv6 must be able to do. Scott ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Jul 26 05:07:55 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA24703; Wed, 26 Jul 95 05:07:55 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA24697; Wed, 26 Jul 95 05:07:47 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AB26272; Wed, 26 Jul 1995 04:57:15 -0700 Received: from concorde.inria.fr by mercury.Sun.COM (Sun.COM) id EAA18543; Wed, 26 Jul 1995 04:57:09 -0700 Received: from givry.inria.fr (givry.inria.fr [128.93.8.18]) by concorde.inria.fr (8.6.10/8.6.9) with ESMTP id NAA24342 for ; Wed, 26 Jul 1995 13:57:07 +0200 Received: from givry.inria.fr (localhost.inria.fr [127.0.0.1]) by givry.inria.fr (8.6.10/8.6.6) with ESMTP id NAA19638 for ; Wed, 26 Jul 1995 13:57:07 +0200 Message-Id: <199507261157.NAA19638@givry.inria.fr> From: Francis Dupont To: ipng@sunroof.Eng.Sun.COM (IPv6 List) Subject: (IPng 413) Re: we need *real* IPv6 addresses! In-Reply-To: Your message of Tue, 25 Jul 1995 16:57:33 +0200. <9507251457.AA25692@dxcoms.cern.ch> Date: Wed, 26 Jul 1995 13:57:05 +0200 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk In his previous mail (IPng 394) Brian wrote: Yakov, > > 4. Early implementors need something concrete to work with right now. > > For transition purposes every IPv6 host must have IPv4 compatible address. > Early implementors can use these IPv6 addresses *right now*. I've been told by at least one implementor that they need some non-IPv4-compatible addresses too, and not just the link-local ones, for adequate testing. => I join in the list of IPv6 implementors who need *real* IPv6 addresses! Several things (DNS, router discovery, source address selection (cf IPng 366), etc) are far easier to test with them. Today we have only 4 choices: - IPv4-compatible addresses: they are very special (ie reserved to IPv6-into-IPv4 tunnels). - link-local addresses: neighbor discovery works with them but they have a very particular behavior on multi-homed hosts or routers. They are not routable too. - site-local addresses: they are usable but supposed to be site specific. We can imagine that the world is only one site and use for instance 64 bits in the middle to number all the LANs with IPv6 nodes. It should work but is it serious ? - *real* IPv6 addresses: NIC France and RIPE NCC have requested an IPv6 address space for us but for unknown reasons someone seems to be reluctant... If you have good reasons to postpone the assignment of a small IPv6 address space for testing purpose can we see them ? Regards Francis.Dupont@inria.fr PS: consider this message as an *official* request for *real* IPv6 addresses. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Jul 26 05:20:43 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA24719; Wed, 26 Jul 95 05:20:43 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA24713; Wed, 26 Jul 95 05:20:35 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA26808; Wed, 26 Jul 1995 05:10:03 -0700 Received: from concorde.inria.fr by mercury.Sun.COM (Sun.COM) id FAA19718; Wed, 26 Jul 1995 05:09:56 -0700 Received: from givry.inria.fr (givry.inria.fr [128.93.8.18]) by concorde.inria.fr (8.6.10/8.6.9) with ESMTP id OAA24532 for ; Wed, 26 Jul 1995 14:09:50 +0200 Received: from givry.inria.fr (localhost.inria.fr [127.0.0.1]) by givry.inria.fr (8.6.10/8.6.6) with ESMTP id OAA19683 for ; Wed, 26 Jul 1995 14:09:49 +0200 Message-Id: <199507261209.OAA19683@givry.inria.fr> From: Francis Dupont To: ipng@sunroof.Eng.Sun.COM (IPv6 List) Subject: (IPng 414) the unspecified IPv6 address is "::" Date: Wed, 26 Jul 1995 14:09:48 +0200 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk According to the rule of the least astonishment I suggest to put somewhere in the IPv6 addressing architecture draft (currently draft-ietf-ipngwg-addr-arch-03.txt) the fact that the unspecified IPv6 address can be written "::". Regards Francis.Dupont@inria.fr PS: if someone disagrees we can organize an opinion poll in order to show whether "::" is the obvious compressed form of the unspecified IPv6 address or not. The first time my host gave it I reread the specs to see if it was correct or not then I believe "no, it isn't". ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Jul 26 05:46:07 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA24740; Wed, 26 Jul 95 05:46:07 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA24734; Wed, 26 Jul 95 05:45:59 PDT Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA27955; Wed, 26 Jul 1995 05:35:27 -0700 Received: from concorde.inria.fr by Sun.COM (sun-barr.Sun.COM) id AA04604; Wed, 26 Jul 95 05:35:25 PDT Received: from givry.inria.fr (givry.inria.fr [128.93.8.18]) by concorde.inria.fr (8.6.10/8.6.9) with ESMTP id OAA24841 for ; Wed, 26 Jul 1995 14:25:15 +0200 Received: from givry.inria.fr (localhost.inria.fr [127.0.0.1]) by givry.inria.fr (8.6.10/8.6.6) with ESMTP id OAA19747 for ; Wed, 26 Jul 1995 14:25:14 +0200 Message-Id: <199507261225.OAA19747@givry.inria.fr> From: Francis Dupont To: ipng@sunroof.Eng.Sun.COM (IPv6 List) Subject: (IPng 415) ICMP parameter problem pointer Date: Wed, 26 Jul 1995 14:25:12 +0200 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk The current ICMPv6 draft (draft-ietf-ipngwg-icmp-02.txt) doesn't give a clear definition of the pointer field in Parameter Problem Message (we should take the text of the ISO IS 8473 for instance :-) and the given example seems buggy: The pointer identifies the octet of the original datagram's header where the error was detected. For example, an ICMPv6 message with Type field = 4, Code field = 1, and Pointer field = 48 would indicate that the IPv6 extension header following the IPv6 header of the original datagram is holds an unrecognized Next Header field value. Regards Francis.Dupont@inria.fr ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Jul 26 05:59:37 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA24760; Wed, 26 Jul 95 05:59:37 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA24753; Wed, 26 Jul 95 05:59:28 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA28512; Wed, 26 Jul 1995 05:48:56 -0700 Received: from concorde.inria.fr by mercury.Sun.COM (Sun.COM) id FAA23595; Wed, 26 Jul 1995 05:48:54 -0700 Received: from givry.inria.fr (givry.inria.fr [128.93.8.18]) by concorde.inria.fr (8.6.10/8.6.9) with ESMTP id OAA25245 for ; Wed, 26 Jul 1995 14:48:51 +0200 Received: from givry.inria.fr (localhost.inria.fr [127.0.0.1]) by givry.inria.fr (8.6.10/8.6.6) with ESMTP id OAA19805 for ; Wed, 26 Jul 1995 14:48:51 +0200 Message-Id: <199507261248.OAA19805@givry.inria.fr> From: Francis Dupont To: ipng@sunroof.Eng.Sun.COM (IPv6 List) Subject: (IPng 416) in favor of a preference field in Router Advertisements Date: Wed, 26 Jul 1995 14:48:45 +0200 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk The last ND draft draft-ietf-ipngwg-discovery-01.txt removes the preference field from Router Advertisement messages. On our LAN we have more than 40 junk devices (translation bridges, Kinetics boxes, ...) and only 4 real routers (two of them are backups :-). Junk devices believe they are not so junk and will send stupid RAs when they get IPv6. Then we need preference in RA messages or in config files of software dealing with RA messages. It is far better to put it into RA messages with a reasonable mandatory default value. If we rely on ICMP redirects in order to select "good" routers then we have to make ICMP redirects shorter or better less frequent. In such a case a preference field (in RA) helps too. Regards Francis.Dupont@inria.fr ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Jul 26 06:33:05 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA24780; Wed, 26 Jul 95 06:33:05 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA24774; Wed, 26 Jul 95 06:32:56 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA00027; Wed, 26 Jul 1995 06:22:24 -0700 Received: from concorde.inria.fr by mercury.Sun.COM (Sun.COM) id GAA27666; Wed, 26 Jul 1995 06:22:22 -0700 Received: from givry.inria.fr (givry.inria.fr [128.93.8.18]) by concorde.inria.fr (8.6.10/8.6.9) with ESMTP id PAA25942 for ; Wed, 26 Jul 1995 15:22:10 +0200 Received: from givry.inria.fr (localhost.inria.fr [127.0.0.1]) by givry.inria.fr (8.6.10/8.6.6) with ESMTP id PAA19892 for ; Wed, 26 Jul 1995 15:22:10 +0200 Message-Id: <199507261322.PAA19892@givry.inria.fr> From: Francis Dupont To: ipng@sunroof.Eng.Sun.COM (IPv6 List) Subject: (IPng 417) neighbor unreachable detection / neighbor discovery Date: Wed, 26 Jul 1995 15:22:08 +0200 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk The neighbor unreachable detection behavior can give 4 message exchanges when 2 messages should be enough because if an node A discovers than the node B is reachable then it doesn't imply that B knows A is reachable (in fact in general the NA emission puts B in the probe state and triggers the reverse NUD exchange). I suggest to consider as a reachability confirmation the reception of a neighbor solicitation with an unicast destination address equals to the target address (these kind of NS are sent by probing nodes). Another possibility is to add a "soliciting" bit but I believe it is not necessary. When address resolution has failed the draft says ICMP unreachables MUST be returned for each queued packet but the queue is small and it can be too late. I suggest to enter an hold down state for some seconds but I'd like to get some advices about this idea. Another problem is the current draft doesn't demand the usage of "jitter" in order to avoid auto-synchronization. I have discovered it is a real problem then something must be written about it. If ND/NUD timers are managed by a global periodic procedure it is a good place to add some jitter. Regards Francis.Dupont@inria.fr ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Jul 26 07:12:02 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA24837; Wed, 26 Jul 95 07:12:02 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA24831; Wed, 26 Jul 95 07:11:49 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA02304; Wed, 26 Jul 1995 07:01:17 -0700 Received: from sundance.itd.nrl.navy.mil by mercury.Sun.COM (Sun.COM) id HAA03287; Wed, 26 Jul 1995 07:01:16 -0700 Subject: (IPng 418) Re: neighbor unreachable detection / neighbor discovery To: Francis.Dupont@inria.fr, IPng Mailing list Date: Wed, 26 Jul 1995 10:01:08 -0500 (EST) From: Dan McDonald X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: <9507261501.aa12113@cs.nrl.navy.mil> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk I believe the reason a neighbor solicitation cannot be considered reachability confirmation is because of the half-link problem. I though I had some text from Erik on the subject, but I cannot seem to find it. It's best let the document author(s) be the final word on this anyway. As for jitter, how much jitter is a good thing? It sounds like a good idea, but I'd like to know what magnitude of jitter you're talking about. If you're using global periodics the way ARP does in 4.4's IPv4, I'd figure you're probably talking making a "next-execute time" assignment of: ( (interval) * hz + jitter) where jitter is random and 0 <= jitter < hz. Am I in the ballpark on this one? As for when address resolution fails, again, are you meaning to take a queue from 4.4's ARP and mark the neighbor's route as RTF_REJECT for an amount of time? I asked about this before, but probably not clearly enough. Right now when address resolution fails, I simply delete the neighbor's route and let resolution happen again. Sending ICMP errors can be useful, even if they might be too late, or only sent to a limited number of nodes because the queue is small. Dan ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Jul 26 08:22:45 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA24877; Wed, 26 Jul 95 08:22:45 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA24871; Wed, 26 Jul 95 08:22:37 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AB08398; Wed, 26 Jul 1995 08:12:02 -0700 Received: from VNET.IBM.COM by mercury.Sun.COM (Sun.COM) id IAA16016; Wed, 26 Jul 1995 08:11:25 -0700 Received: from RTP by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 7336; Wed, 26 Jul 95 11:10:24 EDT Received: by RTP (XAGENTA 4.0) id 0945; Wed, 26 Jul 1995 11:10:02 -0400 Received: by cichlid.raleigh.ibm.com (AIX 3.2/UCB 5.64/4.03) id AA18385; Wed, 26 Jul 1995 11:10:07 -0400 Message-Id: <9507261510.AA18385@cichlid.raleigh.ibm.com> To: Francis Dupont Cc: ipng@sunroof.Eng.Sun.COM (IPv6 List) Subject: (IPng 419) Re: neighbor unreachable detection / neighbor discovery In-Reply-To: (Your message of Wed, 26 Jul 95 15:22:08 O.) <199507261322.PAA19892@givry.inria.fr> Date: Wed, 26 Jul 95 11:10:07 -0500 From: "Thomas Narten" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk > The neighbor unreachable detection behavior can give >4 message exchanges when 2 messages should be enough >because if an node A discovers than the node B is >reachable then it doesn't imply that B knows A is reachable >(in fact in general the NA emission puts B in the probe >state and triggers the reverse NUD exchange). > I suggest to consider as a reachability confirmation >the reception of a neighbor solicitation with an unicast >destination address equals to the target address >(these kind of NS are sent by probing nodes). >Another possibility is to add a "soliciting" bit but >I believe it is not necessary. The four packet exchanges are necessary (in the current spec) because both neighbors probe each other independently. It would be possible to reduce this number to three (maybe even two), but that requires changing the NUD protocol and adding sequence numbers and acknowledgements (or something similar) to NA/NS packets. That way, one node's NS could double as an acknowledgment/confirmation for the previous probe. That is something we might want to think about for future changes, but the issue is subtle and complex enough that I don't think we should put it in the current ND spec (we considered it early on, but decided it was too complex). It would not, however, be a good idea to allow the reception of an unsolcited NS to indicate confirmation. As Dan M. pointed out, the path to the neighbor could be down, even though unsolicited NA were being received. This can lead to scenarios where NUD concludes a path is working, even though it is not. That is, NUD no longer works correctly in all cases. > When address resolution has failed the draft says >ICMP unreachables MUST be returned for each queued packet >but the queue is small and it can be too late. >I suggest to enter an hold down state for some seconds >but I'd like to get some advices about this idea. I'm not sure what you mean by "too late". ICMP Unreachable error messages should be treated suspiciosly by the sending host since they might be inaccurate. The main reason for generating them is for diagnostic purposes (e.g., ping/traceroute), or for connections that haven't opened succesfully yet. In the latter case, another address could be tried quickly. > Another problem is the current draft doesn't demand >the usage of "jitter" in order to avoid auto-synchronization. The jitter is already built into the system; intial probes are generated only on demand, as a side effect of sending a packet to a neighbor. The addition of jitter is only required in those cases where periodic messages are generated. Because traffic from upper layers is not periodic, NS/NA packets are not periodic. >I have discovered it is a real problem then something >must be written about it. Are you making a general statement, or one specific to the implementation of Neighbor Discovery? Thomas ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Jul 26 08:26:20 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA24889; Wed, 26 Jul 95 08:26:20 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA24883; Wed, 26 Jul 95 08:26:12 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA08735; Wed, 26 Jul 1995 08:15:37 -0700 Received: from VNET.IBM.COM by mercury.Sun.COM (Sun.COM) id IAA16778; Wed, 26 Jul 1995 08:14:43 -0700 Received: from RTP by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 7457; Wed, 26 Jul 95 11:14:35 EDT Received: by RTP (XAGENTA 4.0) id 0971; Wed, 26 Jul 1995 11:13:50 -0400 Received: by cichlid.raleigh.ibm.com (AIX 3.2/UCB 5.64/4.03) id AA18916; Wed, 26 Jul 1995 11:13:52 -0400 Message-Id: <9507261513.AA18916@cichlid.raleigh.ibm.com> To: Francis Dupont Cc: ipng@sunroof.Eng.Sun.COM (IPv6 List) Subject: (IPng 420) Re: in favor of a preference field in Router Advertisements In-Reply-To: (Your message of Wed, 26 Jul 95 14:48:45 O.) <199507261248.OAA19805@givry.inria.fr> Date: Wed, 26 Jul 95 11:13:52 -0500 From: "Thomas Narten" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk >The last ND draft draft-ietf-ipngwg-discovery-01.txt removes >the preference field from Router Advertisement messages. >On our LAN we have more than 40 junk devices (translation >bridges, Kinetics boxes, ...) and only 4 real routers >(two of them are backups :-). Junk devices believe they are >not so junk and will send stupid RAs when they get IPv6. Having a router preference field simply doesn't solve the problem it is intended to address. Because it is a 20% solution rather than a 100% (or even 90%!) solution, the preference field was dropped at the interim meeting in Mtn View. In Stockholm, kre raised the issue again. For those of you advocating preferences in RA messages, please describe what problem they solve and how the preference field (as defined in the IPv4 router discovery) solves the problem. Default router preferences come into play in only two circumstances: a) a packet is being sent to a destination for the first time, and there is no entry for it in the Destination Cache. b) the current router being used to reach a destination appears to have failed, and a new one is chosen from the default router list. Conceptually, this is similar to case a). Communication has failed, so we delete the cache entry and create a new one. Once a Destination Cache entry for a specific target has been created, that entry is used forever (regardless of whether the router being used is a "good" or "bad" one) as long as it works. The arguments I've heard calling for having a preference field cite examples where "bad" routers should only be used as backups for the case when no "good" routers are available. However, having a router preference does not solve this problem adequately. Assume that your local net has a "good" (high preference) router and "bad" (low preference) router. If the "good" router is available, it will be used initially in creating all entries in the Destination Cache. However, when that router fails, all existing cache entries switch to using the "bad" router, because it is the only one available. When the "good" router becomes available again, it will be used for any *new* cache entries that get created, but has *no* effect on existing entries. End result: all nodes are using the "bad" router rather than the "good" router. This situation persists until the "bad" router crashes. Thus, router preferences don't properly address the "good" vs. "bad" router scenarios that have been cited as the reason for having router preferences. To make preferences really useful, one needs to change the semantics of what preferences mean. For example, we might require that hosts always use the router with the highest preference, switching from lower preference routers to higher preference routers when appropriate. But that also raises such complicating issues such as how to handle redirects from a high preference router to a lower preference router. How long should the redirect be good for? Given that the "good" vs. "bad" router selection can be solved by having routers send redirects as appropriate, I don't think that the additional host complexity needed to do preferences correctly is justified. Thomas ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Jul 26 09:15:40 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA24923; Wed, 26 Jul 95 09:15:40 PDT Received: from jurassic.Eng.Sun.COM (camilla) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA24917; Wed, 26 Jul 95 09:15:27 PDT Received: from picadilly.Eng.Sun.COM by jurassic.Eng.Sun.COM (SMI-8.6/SMI-SVR4) id JAA28609; Wed, 26 Jul 1995 09:04:50 -0700 Received: from picadilly by picadilly.Eng.Sun.COM (SMI-8.6/SMI-SVR4) id JAA15641; Wed, 26 Jul 1995 09:02:46 -0700 Message-Id: <199507261602.JAA15641@picadilly.Eng.Sun.COM> To: Francis Dupont Cc: ipng@sunroof.Eng.Sun.COM (IPv6 List) Subject: (IPng 421) Re: we need *real* IPv6 addresses! Date: Wed, 26 Jul 1995 09:02:41 -0700 From: Steve Parker Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk - => I join in the list of IPv6 implementors who need *real* IPv6 addresses! - Several things (DNS, router discovery, source address selection - (cf IPng 366), etc) are far easier to test with them. I just listened as this was discussed in Stockholm, but I must confess I'm not sure I'm convinced. One of the goals of IPng is that automatic address renumbering work correctly. Therefore, if IPng addresses are issued now, I hope the powers that be in the IETF *promise* numbers issued now to early implementers will be reassigned. If the protocol developers aren't forced to renumber, why should the great unwashed believe we actually made this stuff work? It is true that people doing protocol development need IPv6 addresses which don't collide with other developers' choices. Perhaps within the IPng development effort an ad hoc assignment can occur, with the understanding these are temporary addresses which will be renumbered. This insures: * Developers are forced to practice renumbering * Orderly deployment of IPv6 addresses occurs, and in a timely fashion Cheers, ~sparker ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Jul 26 09:43:30 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA24947; Wed, 26 Jul 95 09:43:30 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA24941; Wed, 26 Jul 95 09:43:13 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA18979; Wed, 26 Jul 1995 09:31:47 -0700 Received: from concorde.inria.fr by mercury.Sun.COM (Sun.COM) id JAA05691; Wed, 26 Jul 1995 09:31:44 -0700 Received: from givry.inria.fr (givry.inria.fr [128.93.8.18]) by concorde.inria.fr (8.6.10/8.6.9) with ESMTP id SAA29866; Wed, 26 Jul 1995 18:31:37 +0200 Received: from givry.inria.fr (localhost.inria.fr [127.0.0.1]) by givry.inria.fr (8.6.10/8.6.6) with ESMTP id SAA20366; Wed, 26 Jul 1995 18:31:36 +0200 Message-Id: <199507261631.SAA20366@givry.inria.fr> From: Francis Dupont To: Dan McDonald Cc: IPng Mailing list Subject: (IPng 422) Re: neighbor unreachable detection / neighbor discovery In-Reply-To: Your message of Wed, 26 Jul 1995 10:01:08 CDT. <9507261501.aa12113@cs.nrl.navy.mil> Date: Wed, 26 Jul 1995 18:31:34 +0200 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk In your previous mail you wrote: I believe the reason a neighbor solicitation cannot be considered reachability confirmation is because of the half-link problem. I though I had some text from Erik on the subject, but I cannot seem to find it. It's best let the document author(s) be the final word on this anyway. => Argh! I have missed the half-link point (it is in the "comparison with IPv4" about ARP only). I agree with the double NUD exchange but there should be a small rationate about the half-link problem in the NUD part of the draft. As for jitter, how much jitter is a good thing? It sounds like a good idea, but I'd like to know what magnitude of jitter you're talking about. If you're using global periodics the way ARP does in 4.4's IPv4, I'd figure you're probably talking making a "next-execute time" assignment of: ( (interval) * hz + jitter) where jitter is random and 0 <= jitter < hz. Am I in the ballpark on this one? => my idea is exactly this (with 0 <= jitter < hz/2 because interval is in seconds and can be 1). NetBSD has a random generator in the kernel then as soon as I see auto-synchronization I suggest a random jitter (cheap way to avoid problems :-). But in fact it is a matter of implementation because I don't use real fine gain timeouts. As for when address resolution fails, again, are you meaning to take a queue from 4.4's ARP and mark the neighbor's route as RTF_REJECT for an amount of time? I asked about this before, but probably not clearly enough. Right now when address resolution fails, I simply delete the neighbor's route and let resolution happen again. => it is my proposal, simply delete neighbor's route is not enough because if some packets come from a not connected source (for instance UDP packets from a DNS resolver with several default nameservers) the ND failure indications can't be returned to the upper layer. Sending ICMP errors can be useful, even if they might be too late, or only sent to a limited number of nodes because the queue is small. => ND failure indications will be delivered to the upper layer in BSD Unixes only if the socket is connected then some kind of hold down is needed... There is nothing about this in the draft then I have looked for other opinions. Thanks Francis.Dupont@inria.fr ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Jul 26 10:21:05 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA24974; Wed, 26 Jul 95 10:21:05 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA24968; Wed, 26 Jul 95 10:20:47 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA24543; Wed, 26 Jul 1995 10:10:04 -0700 Received: from concorde.inria.fr by mercury.Sun.COM (Sun.COM) id KAA16410; Wed, 26 Jul 1995 10:09:56 -0700 Received: from givry.inria.fr (givry.inria.fr [128.93.8.18]) by concorde.inria.fr (8.6.10/8.6.9) with ESMTP id TAA00405; Wed, 26 Jul 1995 19:09:52 +0200 Received: from givry.inria.fr (localhost.inria.fr [127.0.0.1]) by givry.inria.fr (8.6.10/8.6.6) with ESMTP id TAA20464; Wed, 26 Jul 1995 19:09:51 +0200 Message-Id: <199507261709.TAA20464@givry.inria.fr> From: Francis Dupont To: "Thomas Narten" Cc: ipng@sunroof.Eng.Sun.COM (IPv6 List) Subject: (IPng 423) Re: neighbor unreachable detection / neighbor discovery In-Reply-To: Your message of Wed, 26 Jul 1995 11:10:07 CDT. <9507261510.AA18385@cichlid.raleigh.ibm.com> Date: Wed, 26 Jul 1995 19:09:49 +0200 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk In your previous mail you wrote: The four packet exchanges are necessary (in the current spec)... => They are (I have missed the half-link point). > When address resolution has failed the draft says >ICMP unreachables MUST be returned for each queued packet >but the queue is small and it can be too late. >I suggest to enter an hold down state for some seconds >but I'd like to get some advices about this idea. I'm not sure what you mean by "too late". => packets sent by a not-connected UDP on a BSD Unix must fail immediately (or the failure indication is "too late"). Perhaps it is too BSD specific but there are nothing about hold down (in favor or against) then I don't know what to think... ICMP Unreachable error messages should be treated suspiciously by the sending host since they might be inaccurate. The main reason for generating them is for diagnostic purposes (e.g., ping/traceroute), or for connections that haven't opened successfully yet. In the latter case, another address could be tried quickly. => I really believe that failure indications are better than long timeouts ! As soon as you can have ND failure indications you can try to improve/pervert the mechanism with an hold down. I'd like to know if it is allowed and what timer value to use. > Another problem is the current draft doesn't demand >the usage of "jitter" in order to avoid auto-synchronization. The jitter is already built into the system; initial probes are generated only on demand, as a side effect of sending a packet to a neighbor. The addition of jitter is only required in those cases where periodic messages are generated. Because traffic from upper layers is not periodic, NS/NA packets are not periodic. => even if I use real fine grain timeouts I am not convinced... I use a periodic procedure that walks the IPv6 routing table for all kinds of timers expiration and it gives auto-synchronization even with upper layer random traffic. >I have discovered it is a real problem then something >must be written about it. Are you making a general statement, or one specific to the implementation of Neighbor Discovery? => auto-synchronization is a nasty fact in networks. I have seen (lived) too many horror stories involving it and now I promote adaptable timers with a random part... Neighbor Discovery is not immune because it doesn't specify how its timeouts must be implemented then I suggest to add some words about this issue and avoid bad surprises. Regards Francis.Dupont@inria.fr ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Jul 26 10:32:51 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA24989; Wed, 26 Jul 95 10:32:51 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA24983; Wed, 26 Jul 95 10:32:41 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA26115; Wed, 26 Jul 1995 10:19:37 -0700 Received: from servo.ipsilon.com by mercury.Sun.COM (Sun.COM) id KAA19038; Wed, 26 Jul 1995 10:19:27 -0700 Received: from [204.160.241.224] (acacia.Ipsilon.COM [204.160.241.224]) by servo.ipsilon.com (8.6.11/8.6.10) with SMTP id KAA28710; Wed, 26 Jul 1995 10:18:45 -0700 X-Sender: hinden@mailhost.ipsilon.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 26 Jul 1995 10:21:06 -0700 To: Steve Parker From: hinden@Ipsilon.COM (Bob Hinden) Subject: (IPng 424) Re: we need *real* IPv6 addresses! Cc: ipng@sunroof.Eng.Sun.COM (IPv6 List) Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk I am working on a draft for addresses to be used IPv6 testing. I should have it out in about a week. The addresses are taken out of some of the reserved space and requires that anyone using these addresses will have to renumber. The addresses will be structure to permit testing of neighbor discovery, auto addr-config, etc. and at the same time be easy to assign with a minimum of administrative overhead. Please stay tuned. Bob ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Jul 26 10:51:33 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA25028; Wed, 26 Jul 95 10:51:33 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA25021; Wed, 26 Jul 95 10:51:06 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA29573; Wed, 26 Jul 1995 10:40:14 -0700 Received: from concorde.inria.fr by mercury.Sun.COM (Sun.COM) id KAA27059; Wed, 26 Jul 1995 10:39:49 -0700 Received: from givry.inria.fr (givry.inria.fr [128.93.8.18]) by concorde.inria.fr (8.6.10/8.6.9) with ESMTP id TAA00704; Wed, 26 Jul 1995 19:39:25 +0200 Received: from givry.inria.fr (localhost.inria.fr [127.0.0.1]) by givry.inria.fr (8.6.10/8.6.6) with ESMTP id TAA20561; Wed, 26 Jul 1995 19:39:24 +0200 Message-Id: <199507261739.TAA20561@givry.inria.fr> From: Francis Dupont To: "Thomas Narten" Cc: ipng@sunroof.Eng.Sun.COM (IPv6 List) Subject: (IPng 425) Re: in favor of a preference field in Router Advertisements In-Reply-To: Your message of Wed, 26 Jul 1995 11:13:52 CDT. <9507261513.AA18916@cichlid.raleigh.ibm.com> Date: Wed, 26 Jul 1995 19:39:22 +0200 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk In your previous mail you wrote: >The last ND draft draft-ietf-ipngwg-discovery-01.txt removes >the preference field from Router Advertisement messages. >On our LAN we have more than 40 junk devices (translation >bridges, Kinetics boxes, ...) and only 4 real routers >(two of them are backups :-). Junk devices believe they are >not so junk and will send stupid RAs when they get IPv6. Having a router preference field simply doesn't solve the problem it is intended to address. Because it is a 20% solution rather than a 100% (or even 90%!) solution, the preference field was dropped at the interim meeting in Mtn View. In Stockholm, kre raised the issue again. For those of you advocating preferences in RA messages, please describe what problem they solve and how the preference field (as defined in the IPv4 router discovery) solves the problem. => In Stockholm many persons raised the issue again because they believe(d) a router preference is an useful thing. Personally I think this part of the neighbor discovery is too complicated to put in the kernel then an user process should manage the whole stuff and preference will be in its configuration file. But a built-in facility should be nice... I've kept your scenarios because they are good examples in favor of router preferences. Default router preferences come into play in only two circumstances: a) a packet is being sent to a destination for the first time, and there is no entry for it in the Destination Cache. b) the current router being used to reach a destination appears to have failed, and a new one is chosen from the default router list. Conceptually, this is similar to case a). Communication has failed, so we delete the cache entry and create a new one. Once a Destination Cache entry for a specific target has been created, that entry is used forever (regardless of whether the router being used is a "good" or "bad" one) as long as it works. => your hidden hypothesis is the router pointer cannot be updated. If you remove it your argument is not the same. The arguments I've heard calling for having a preference field cite examples where "bad" routers should only be used as backups for the case when no "good" routers are available. However, having a router preference does not solve this problem adequately. Assume that your local net has a "good" (high preference) router and "bad" (low preference) router. => it is the general case (with *good* and *bad* routers) where a preference field is useful. If the "good" router is available, it will be used initially in creating all entries in the Destination Cache. However, when that router fails, all existing cache entries switch to using the "bad" router, because it is the only one available. When the "good" router becomes available again, it will be used for any *new* cache entries that get created, but has *no* effect on existing entries. End result: all nodes are using the "bad" router rather than the "good" router. This situation persists until the "bad" router crashes. => if you can update in one operation all the pointers to the default router you'll switch from *good* to *bad* with only one timeout/failure and from *bad* to *good* as soon as the *good* router will become alive. Thus, router preferences don't properly address the "good" vs. "bad" router scenarios that have been cited as the reason for having router preferences. => They address these scenarios if you can update the default router pointer. To make preferences really useful, one needs to change the semantics of what preferences mean. For example, we might require that hosts always use the router with the highest preference, switching from lower preference routers to higher preference routers when appropriate. But that also raises such complicating issues such as how to handle redirects from a high preference router to a lower preference router. How long should the redirect be good for? => when you receive a redirect you replace the pointer to the router. Given that the "good" vs. "bad" router selection can be solved by having routers send redirects as appropriate, I don't think that the additional host complexity needed to do preferences correctly is justified. => no, redirects give a lot of traffic (576 bytes each), a lot of route entries, etc... If you know 4.4BSD-Lite routing code, my idea is to put the anycast link-local address in the rt_gateway field of routes using the default router (funny, isn't it ? :-) and to update in place the rt_gwroute route entry (it is the real thing) using change requests on the default route. Regards Francis.Dupont@inria.fr ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Jul 26 10:58:21 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA25049; Wed, 26 Jul 95 10:58:21 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA25041; Wed, 26 Jul 95 10:58:12 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA01091; Wed, 26 Jul 1995 10:47:25 -0700 Received: from concorde.inria.fr by mercury.Sun.COM (Sun.COM) id KAA02129; Wed, 26 Jul 1995 10:46:49 -0700 Received: from givry.inria.fr (givry.inria.fr [128.93.8.18]) by concorde.inria.fr (8.6.10/8.6.9) with ESMTP id TAA00771; Wed, 26 Jul 1995 19:46:46 +0200 Received: from givry.inria.fr (localhost.inria.fr [127.0.0.1]) by givry.inria.fr (8.6.10/8.6.6) with ESMTP id TAA20588; Wed, 26 Jul 1995 19:46:45 +0200 Message-Id: <199507261746.TAA20588@givry.inria.fr> From: Francis Dupont To: Steve Parker Cc: ipng@sunroof.Eng.Sun.COM (IPv6 List) Subject: (IPng 426) Re: we need *real* IPv6 addresses! In-Reply-To: Your message of Wed, 26 Jul 1995 09:02:41 PDT. <199507261602.JAA15641@picadilly.Eng.Sun.COM> Date: Wed, 26 Jul 1995 19:46:43 +0200 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk In your previous mail you wrote: - => I join in the list of IPv6 implementors who need *real* IPv6 addresses! - Several things (DNS, router discovery, source address selection - (cf IPng 366), etc) are far easier to test with them. I just listened as this was discussed in Stockholm, but I must confess I'm not sure I'm convinced. One of the goals of IPng is that automatic address renumbering work correctly. Therefore, if IPng addresses are issued now, I hope the powers that be in the IETF *promise* numbers issued now to early implementers will be reassigned. => it is not an issue for early implementors because we have only a small number of IPv6 nodes each and we have to test renumbering in any case... If the protocol developers aren't forced to renumber, why should the great unwashed believe we actually made this stuff work? => I propose that you support our request with the addition "experimental address space must be reassigned when not experimental address space will be available". It is true that people doing protocol development need IPv6 addresses which don't collide with other developers' choices. Perhaps within the IPng development effort an ad hoc assignment can occur, with the understanding these are temporary addresses which will be renumbered. This insures: * Developers are forced to practice renumbering * Orderly deployment of IPv6 addresses occurs, and in a timely fashion => I agree ! I see here no reason to delay experimental address space assignment, we are still waiting for it... Thanks Francis.Dupont@inria.fr ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Jul 26 10:59:29 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA25064; Wed, 26 Jul 95 10:59:29 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA25055; Wed, 26 Jul 95 10:59:05 PDT Received: from venus.Sun.COM (venus.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA01425; Wed, 26 Jul 1995 10:48:19 -0700 Received: from VNET.IBM.COM by venus.Sun.COM (Sun.COM) id KAA16348; Wed, 26 Jul 1995 10:48:08 -0700 Received: from RTP by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 0397; Wed, 26 Jul 95 13:47:59 EDT Received: by RTP (XAGENTA 4.0) id 1028; Wed, 26 Jul 1995 13:47:26 -0400 Received: by cichlid.raleigh.ibm.com (AIX 3.2/UCB 5.64/4.03) id AA18915; Wed, 26 Jul 1995 13:47:36 -0400 Message-Id: <9507261747.AA18915@cichlid.raleigh.ibm.com> To: Francis Dupont Cc: ipng@sunroof.Eng.Sun.COM (IPv6 List) Subject: (IPng 427) Re: neighbor unreachable detection / neighbor discovery In-Reply-To: (Your message of Wed, 26 Jul 95 19:09:49 O.) <199507261709.TAA20464@givry.inria.fr> Date: Wed, 26 Jul 95 13:47:35 -0500 From: "Thomas Narten" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk >=> packets sent by a not-connected UDP on a BSD Unix must fail >immediately (or the failure indication is "too late"). >Perhaps it is too BSD specific but there are nothing about >hold down (in favor or against) then I don't know what to think... Quoting from the current draft: ICMP destination unreachable indication - an error indication returned to the original sender of a packet that cannot be delivered for the reasons outlined in [ICMPv6]. If the error occurs on a node other than the node originating the packet, an ICMP error message is generated. If the error occurs on the originating node, an implementation is not required to actually create and send an ICMP error packet to the source, as long as the sender is notified through an appropriate mechanism (e.g., return value from a procedure call). Note, however, that an implementation may find it convenient in some cases to return errors to the sender by taking the offending packet, generating an ICMP error message, and then delivering it (locally) through the generic error handling routines. For the UDP case you mention above, the last sentence indicates the easiest way to handle the "too late" error situation. The error would then be processed in the same way as any incoming ICMP error; the fact that it was generated on the originating machine is irrelevant. Is the related point you are getting at that many UDP applications ignore ICMP errors, and that having error indications return syncronously via the return value to ip_output() would be useful? I don't disagree with this, but it is not an issue that ND needs to address. >=> I really believe that failure indications are better than >long timeouts ! As soon as you can have ND failure indications >you can try to improve/pervert the mechanism with an hold down. >I'd like to know if it is allowed and what timer value to use. I'm not sure what you are asking. When address resolution fails, do you want to then return ICMP unreachables for all packets sent to that neighbor for the next N seconds, where N is your hold down time? ND certainly doesn't forbid that, but it also doesn't suggest that this should be done. One negative with this approach is that it can return false error indications based on old and invalid information. It seems to me that this approach has some utility, but the above approach (pseudo-delivering an ICMP error) would be easier to implement as well as being correct (e.g., won't generate false unreachables). That way you also properly handle ICMP unreachable errors generated by routers elsewhere on the path. >=> auto-synchronization is a nasty fact in networks. >I have seen (lived) too many horror stories involving it >and now I promote adaptable timers with a random part... >Neighbor Discovery is not immune because it doesn't specify >how its timeouts must be implemented then I suggest to add >some words about this issue and avoid bad surprises. ND does require randomness in those situations where messages are generated periodically or there is danger of many nodes transmitting at roughly the same time (RAs and RSs). I think the only place where we are disagreeing is in the case of retransmitting NS messages for address resolution and NUD. The first packet transmission is sent out on demand, so no randomness is needed. The 2 followup retransmissions are retransmitted via fixed timers. I just don't see the need for adding randomness here. Thomas ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Jul 26 11:28:22 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA25086; Wed, 26 Jul 95 11:28:22 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA25077; Wed, 26 Jul 95 11:21:04 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA06470; Wed, 26 Jul 1995 11:08:57 -0700 Received: from VNET.IBM.COM by mercury.Sun.COM (Sun.COM) id LAA08218; Wed, 26 Jul 1995 11:08:30 -0700 Received: from RTP by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 0772; Wed, 26 Jul 95 14:08:20 EDT Received: by RTP (XAGENTA 4.0) id 1038; Wed, 26 Jul 1995 14:08:05 -0400 Received: by cichlid.raleigh.ibm.com (AIX 3.2/UCB 5.64/4.03) id AA18969; Wed, 26 Jul 1995 14:08:13 -0400 Message-Id: <9507261808.AA18969@cichlid.raleigh.ibm.com> To: Francis Dupont Cc: ipng@sunroof.Eng.Sun.COM (IPv6 List) Subject: (IPng 428) Re: in favor of a preference field in Router Advertisements In-Reply-To: (Your message of Wed, 26 Jul 95 19:39:22 O.) <199507261739.TAA20561@givry.inria.fr> Date: Wed, 26 Jul 95 14:08:13 -0500 From: "Thomas Narten" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk >=> In Stockholm many persons raised the issue again >because they believe(d) a router preference is an useful thing. And again, I'm trying to understand under exactly what scenarios the preference is useful in practice. [Note: I'm assuming IPv4 router discovery semantics.] >Personally I think this part of the neighbor discovery is >too complicated to put in the kernel then an user process >should manage the whole stuff and preference will be in its >configuration file. I'd disagree with the latter point. Preferences should not need to be configured on a per-host basis. Too much administrative hassle. >=> your hidden hypothesis is the router pointer cannot be updated. >If you remove it your argument is not the same. I wouldn't exactly call it my "hidden hypothesis". :-) Rather, it is the semantics of router preferences as defined in the IPv4 RFC. All of your arguments for preferences assume that the semantics of default router preferences should be changed so that the highest preference router is always used. That is, it is no longer a "default router preference" but a "router preference" that should be honored at all times, not just when a default router is selected initialy. Are these the semantics folks mean when they say "we want router preferences"? > Given that the "good" vs. "bad" router selection can be solved by > having routers send redirects as appropriate, I don't think that the > additional host complexity needed to do preferences correctly is > justified. >=> no, redirects give a lot of traffic (576 bytes each), >a lot of route entries, etc... Are you arguing that we need router preferences because the cost of redirects is too expensive? Thomas ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Jul 26 12:14:16 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA25129; Wed, 26 Jul 95 12:14:16 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA25120; Wed, 26 Jul 95 12:14:06 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA17014; Wed, 26 Jul 1995 12:01:10 -0700 Received: from CU.NIH.GOV by mercury.Sun.COM (Sun.COM) id MAA21162; Wed, 26 Jul 1995 12:00:10 -0700 Message-Id: <199507261900.MAA21162@mercury.Sun.COM> To: sob@ndtl.harvard.edu Cc: hinden@Ipsilon.COM, ipng@sunroof.Eng.Sun.COM, yakov@cisco.com From: "Roger Fajman" Date: Wed, 26 Jul 1995 14:59:16 EDT Subject: (IPng 429) Re: Lixia's study group Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk > > Wasn't that for IPv4 renumbering technology rather than IPv6? > > Roger, > At least at the start, most of the "places" that are affected > by renumbering are teh same for v4 & v6. Having a good document which > details the places and includes some experiences will, while being > targeted to IPv4, be quite useful in determining what IPv6 must be > able to do. > > Scott Yes, it will be a good start. But some of the answers for IPv6 are likely to be different, so that will need to be looked at once the IPv4 considerations are written down. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Jul 26 14:04:03 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA25260; Wed, 26 Jul 95 14:04:03 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA25214; Wed, 26 Jul 95 12:43:36 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA24319; Wed, 26 Jul 1995 12:32:58 -0700 Received: from unh.edu by mercury.Sun.COM (Sun.COM) id MAA28471; Wed, 26 Jul 1995 12:32:48 -0700 Received: from whitec.sr.unh.edu by unh.edu with SMTP id AA09258 (5.67b+/IDA-1.5 for <@unh.edu:ipng@sunroof.eng.sun.com>); Wed, 26 Jul 1995 15:32:46 -0400 Received: by whitec.sr.unh.edu (940816.SGI.8.6.9/921111.SGI) for ipng@sunroof.eng.sun.com id PAA07258; Wed, 26 Jul 1995 15:34:56 -0400 Date: Wed, 26 Jul 1995 15:34:56 -0400 From: whl@whitec.sr.unh.edu (William Lenharth) Message-Id: <199507261934.PAA07258@whitec.sr.unh.edu> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng 430) ipv6 at interop95 X-Status: N X-Mailer: Applixware 3.1(473.1) Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk To all interested IPv6 parties. The UNH / Interoperability lab is putting together a technology demonstration booth for the Atlanta interop event. Several technologies will be demonstrated (hands on), ATM, VGAnylan, 100BaseT, Fiberchannel and we hope IPv6. If any company is interested they can connact me at whl@unh.edu. Suggestions are welcome. William H. Lenharth - UNH Research Computing ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Jul 26 16:14:35 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA25412; Wed, 26 Jul 95 16:14:35 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA25406; Wed, 26 Jul 95 16:14:26 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA28466; Wed, 26 Jul 1995 16:03:47 -0700 Received: from hubbub.cisco.com by mercury.Sun.COM (Sun.COM) id QAA09993; Wed, 26 Jul 1995 16:03:27 -0700 Received: from puli.cisco.com (puli.cisco.com [171.69.1.174]) by hubbub.cisco.com (8.6.10/CISCO.GATE.1.1) with SMTP id QAA10261; Wed, 26 Jul 1995 16:03:22 -0700 Message-Id: <199507262303.QAA10261@hubbub.cisco.com> To: Lixia Zhang Cc: ipng@sunroof.Eng.Sun.COM Subject: (IPng 431) Re: Lixia's study group In-Reply-To: Your message of "Tue, 25 Jul 95 22:21:28 PDT." Date: Wed, 26 Jul 95 16:03:21 PDT From: Yakov Rekhter Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Lixia, > > Either I did not understand the question, or otherwise the answer > seems obvious to me: if any future changes are deemed necessary, then > they must be able to be phased in with backward compatibility. "must be able to be phased in with backward compatibility", but with respect to what ? The spec and implementations we have as IPv6 moves to a Proposed Standard ? The spec and implementation we'll have as IPv6 will move to a Draft Standard ? Full Standard ? Yakov. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Jul 26 17:53:11 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA25524; Wed, 26 Jul 95 17:53:11 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA25518; Wed, 26 Jul 95 17:52:58 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA14261; Wed, 26 Jul 1995 17:42:24 -0700 Received: from IETF.nri.reston.VA.US by mercury.Sun.COM (Sun.COM) id RAA29200; Wed, 26 Jul 1995 17:42:21 -0700 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa15773; 26 Jul 95 17:15 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;@mercury Cc: ipng@sunroof.Eng.Sun.COM From: Internet-Drafts@CNRI.Reston.VA.US Reply-To: Internet-Drafts@CNRI.Reston.VA.US Subject: (IPng 432) I-D ACTION:draft-ietf-ipngwg-bsd-api-02.txt Date: Wed, 26 Jul 95 17:15:39 -0400 Message-Id: <9507261715.aa15773@IETF.CNRI.Reston.VA.US> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPNG Working Group of the IETF. Title : IPv6 Program Interfaces for BSD Systems Author(s) : R. Gilligan, S. Thomson, J. Bound Filename : draft-ietf-ipngwg-bsd-api-02.txt Pages : 23 Date : 07/25/1995 In order to implement the version 6 Internet Protocol (IPv6) [1] in an operating system based on Berkeley Unix (4.x BSD), changes must be made to the application program interface (API). TCP/IP applications written for BSD-based operating systems have in the past enjoyed a high degree of portability because most of the systems derived from BSD provide the same API, known informally as "the socket interface". We would like the same portability with IPv6. This memo presents a set of extensions to the BSD socket API to support IPv6. The changes include a new data structure to carry IPv6 addresses, new name to address translation library functions, new address conversion functions, and some new setsockopt() options. The extensions are designed to provide access to IPv6 features, while introducing a minimum of change into the system and providing complete compatibility for existing IPv4 applications. Internet-Drafts are 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-ipngwg-bsd-api-02.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-bsd-api-02.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.8) o Europe Address: nic.nordu.net (192.36.148.17) Address: ftp.nis.garr.it (192.12.192.10) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-bsd-api-02.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. For questions, please mail to Internet-Drafts@cnri.reston.va.us. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19950725162621.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-bsd-api-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-bsd-api-02.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19950725162621.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Jul 27 01:25:06 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA25804; Thu, 27 Jul 95 01:25:06 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA25798; Thu, 27 Jul 95 01:24:57 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA10250; Thu, 27 Jul 1995 01:14:24 -0700 Received: from concorde.inria.fr by mercury.Sun.COM (Sun.COM) id BAA16179; Thu, 27 Jul 1995 01:14:22 -0700 Received: from givry.inria.fr (givry.inria.fr [128.93.8.18]) by concorde.inria.fr (8.6.10/8.6.9) with ESMTP id KAA06917; Thu, 27 Jul 1995 10:14:16 +0200 Received: from givry.inria.fr (localhost.inria.fr [127.0.0.1]) by givry.inria.fr (8.6.10/8.6.6) with ESMTP id KAA21705; Thu, 27 Jul 1995 10:14:14 +0200 Message-Id: <199507270814.KAA21705@givry.inria.fr> From: Francis Dupont To: "Thomas Narten" Cc: ipng@sunroof.Eng.Sun.COM (IPv6 List) Subject: (IPng 433) Re: neighbor unreachable detection / neighbor discovery In-Reply-To: Your message of Wed, 26 Jul 1995 13:47:35 CDT. <9507261747.AA18915@cichlid.raleigh.ibm.com> Date: Thu, 27 Jul 1995 10:14:12 +0200 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk In your previous mail you wrote: >=> packets sent by a not-connected UDP on a BSD Unix must fail >immediately (or the failure indication is "too late"). >Perhaps it is too BSD specific but there are nothing about >hold down (in favor or against) then I don't know what to think... Quoting from the current draft: ICMP destination unreachable indication ... Note, however, that an implementation may find it convenient in some cases to return errors to the sender by taking the offending packet, generating an ICMP error message, and then delivering it (locally) through the generic error handling routines. For the UDP case you mention above, the last sentence indicates the easiest way to handle the "too late" error situation. The error would then be processed in the same way as any incoming ICMP error; the fact that it was generated on the originating machine is irrelevant. => I have implemented it but it doesn't solve the problem with not connected sockets because they need immediate notifications (not immediate == "too late"). Is the related point you are getting at that many UDP applications ignore ICMP errors, and that having error indications return synchronously via the return value to ip_output() would be useful? I don't disagree with this, but it is not an issue that ND needs to address. => I will not fight in favor of the hold down idea but I believe it can be an improvement and there is *nothing* about it in the draft. >=> I really believe that failure indications are better than >long timeouts ! As soon as you can have ND failure indications >you can try to improve/pervert the mechanism with an hold down. >I'd like to know if it is allowed and what timer value to use. I'm not sure what you are asking. When address resolution fails, do you want to then return ICMP unreachables for all packets sent to that neighbor for the next N seconds, where N is your hold down time? => exactly. ND certainly doesn't forbid that, but it also doesn't suggest that this should be done. One negative with this approach is that it can return false error indications based on old and invalid information. It seems to me that this approach has some utility, but the above approach (pseudo-delivering an ICMP error) would be easier to implement as well as being correct (e.g., won't generate false unreachables). That way you also properly handle ICMP unreachable errors generated by routers elsewhere on the path. => Only hold down partially solves my problem! Perhaps BSD has a flaw with not connected sockets but I don't know an easy way to fix it (which is the best solution if it is possible :-) and distributed applications using UDP on small LANs are very important. First BSD Unixes did not implement the hold down mechanism and the BSD behavior has been really *improved* when it has been introduced! Then my request is: - look at the hold down mechanism pros and cons - include it in the draft if the community believes that pros > cons. >=> auto-synchronization is a nasty fact in networks. >I have seen (lived) too many horror stories involving it >and now I promote adaptable timers with a random part... >Neighbor Discovery is not immune because it doesn't specify >how its timeouts must be implemented then I suggest to add >some words about this issue and avoid bad surprises. ND does require randomness in those situations where messages are generated periodically or there is danger of many nodes transmitting at roughly the same time (RAs and RSs). I think the only place where we are disagreeing is in the case of retransmitting NS messages for address resolution and NUD. The first packet transmission is sent out on demand, so no randomness is needed. The 2 followup retransmissions are retransmitted via fixed timers. I just don't see the need for adding randomness here. => without real fine grain timeouts your fixed timers can give auto-synchronization. It is an implementation dependent issue but IMHO I think that we have to deal with it ASAP. Regards Francis.Dupont@inria.fr ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Jul 27 02:23:00 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA25871; Thu, 27 Jul 95 02:23:00 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA25865; Thu, 27 Jul 95 02:22:52 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA12498; Thu, 27 Jul 1995 02:12:19 -0700 Received: from concorde.inria.fr by mercury.Sun.COM (Sun.COM) id CAA21265; Thu, 27 Jul 1995 02:12:16 -0700 Received: from givry.inria.fr (givry.inria.fr [128.93.8.18]) by concorde.inria.fr (8.6.10/8.6.9) with ESMTP id LAA08111; Thu, 27 Jul 1995 11:12:15 +0200 Received: from givry.inria.fr (localhost.inria.fr [127.0.0.1]) by givry.inria.fr (8.6.10/8.6.6) with ESMTP id LAA22068; Thu, 27 Jul 1995 11:12:13 +0200 Message-Id: <199507270912.LAA22068@givry.inria.fr> From: Francis Dupont To: "Thomas Narten" Cc: ipng@sunroof.Eng.Sun.COM (IPv6 List) Subject: (IPng 434) Re: in favor of a preference field in Router Advertisements In-Reply-To: Your message of Wed, 26 Jul 1995 14:08:13 CDT. <9507261808.AA18969@cichlid.raleigh.ibm.com> Date: Thu, 27 Jul 1995 11:12:11 +0200 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk In your previous mail you wrote: >=> In Stockholm many persons raised the issue again >because they believe(d) a router preference is an useful thing. And again, I'm trying to understand under exactly what scenarios the preference is useful in practice. [Note: I'm assuming IPv4 router discovery semantics.] => if you are not assuming IPv4 router discovery semantics the scenarios you have described in the previous message (IPng 420) are good examples of the preference utility. >PERSONALLY I think this part of the neighbor discovery is >too complicated to put in the kernel then an user process >should manage the whole stuff and preference will be in its >configuration file. I'd disagree with the latter point. Preferences should not need to be configured on a per-host basis. Too much administrative hassle. => I prefer to put preference in RA messages than in config files too! >=> your hidden hypothesis is the router pointer cannot be updated. >If you remove it your argument is not the same. I wouldn't exactly call it my "hidden hypothesis". :-) Rather, it is the semantics of router preferences as defined in the IPv4 RFC. => IPv6 is supposed to be better than IPv4, for instance IPv6 RA messages include a very useful link-layer address then I can see no good reason to restrict ourselves to IPv4 semantics ? (PS: I'd like to use *both* RAs and the anycast link-local address (fe80::) as the default router address :-) All of your arguments for preferences assume that the semantics of default router preferences should be changed so that the highest preference router is always used. That is, it is no longer a "default router preference" but a "router preference" that should be honored at all times, not just when a default router is selected initially. => I agree: it is a way to summarize this other semantics. (but this "router preference" should be honored only when the "default router" is used in a destination cache) Are these the semantics folks mean when they say "we want router preferences"? => I want to have the choice and not to be restricted to IPv4 semantics! > Given that the "good" vs. "bad" router selection can be solved by > having routers send redirects as appropriate, I don't think that the > additional host complexity needed to do preferences correctly is > justified. >=> no, redirects give a lot of traffic (576 bytes each), >a lot of route entries, etc... Are you arguing that we need router preferences because the cost of redirects is too expensive? => yes, I *really* believe that a router preference field is far less expensive than heavy usage of redirects. I'd like to avoid redirects when it is possible. Regards Francis.Dupont@inria.fr ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Jul 27 07:10:24 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA25975; Thu, 27 Jul 95 07:10:24 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA25969; Thu, 27 Jul 95 07:10:15 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA23523; Thu, 27 Jul 1995 06:59:40 -0700 Received: from alpha.xerox.com by mercury.Sun.COM (Sun.COM) id GAA18427; Thu, 27 Jul 1995 06:59:40 -0700 Received: from redwing.parc.xerox.com ([13.2.116.19]) by alpha.xerox.com with SMTP id <14571(3)>; Thu, 27 Jul 1995 06:59:26 PDT Received: by redwing.parc.xerox.com id <177520>; Thu, 27 Jul 1995 06:59:22 -0700 Date: Thu, 27 Jul 1995 06:59:13 PDT From: Lixia Zhang To: Yakov Rekhter , ipng@sunroof.Eng.Sun.COM Subject: (IPng 435) Re: Lixia's study group In-Reply-To: Your message of Wed, 26 Jul 1995 16:03:21 -0700 Message-Id: Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk > > Either I did not understand the question, or otherwise the answer > > seems obvious to me: if any future changes are deemed necessary, then > > they must be able to be phased in with backward compatibility. > > "must be able to be phased in with backward compatibility", but with respect > to what ? The spec and implementations we have as IPv6 moves to a Proposed > Standard ? The spec and implementation we'll have as IPv6 will move to a Draft > Standard ? Full Standard ? I recall the issue under discussion was the address assigment plan, and I was saying that, should any changes be made from the current draft, they have to be phased in with backward compatibility. Lixia ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Jul 27 07:16:02 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA26016; Thu, 27 Jul 95 07:16:02 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA26010; Thu, 27 Jul 95 07:15:54 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA23887; Thu, 27 Jul 1995 07:05:16 -0700 Received: from mail1.digital.com by mercury.Sun.COM (Sun.COM) id HAA19303; Thu, 27 Jul 1995 07:05:16 -0700 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by mail1.digital.com; (5.65 EXP 4/12/95 for V3.2/1.0/WV) id AA15739; Thu, 27 Jul 1995 06:51:26 -0700 Received: by xirtlu.zk3.dec.com; id AA00684; Thu, 27 Jul 1995 09:51:22 -0400 Message-Id: <9507271351.AA00684@xirtlu.zk3.dec.com> To: Dan McDonald Cc: IPng Mailing list Subject: (IPng 436) Re: On source address determination In-Reply-To: Your message of "Thu, 20 Jul 95 16:39:13 CDT." <9507202139.aa13058@cs.nrl.navy.mil> Date: Thu, 27 Jul 95 09:51:16 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Dan, >Like the subject suggests, I've been contemplating the subject of source >address selection. Early on, it was quite simple, use the link-local, or >the ::, depending on the destination (which quite frankly was >either one of those two forms). The specs don't talk about source address >selection all that much, as it is an implementation detail. I'm bringing >this up with other implementors and implementations in mind. Not sure it should be in a spec. Might be an implementor choice? But we need to read the addr conf spec on deprecation and invalidation lifetimes carefully and what to do. This will be a real good test too for renumbering as we evolve. But I think that code will exist at the transport and will have to watch what happens to ifnet v6 added fields and/or structures to determine state for connection. >Today I added a THIRD prefix to the ethernet interface, and, well, um, >INTERESTING things started happening, depending on the order in which I add >routes, etc. For example, consider the following: > An interface has the following addresses attached to it: > :: (v4-compatible address) > fe80:: (link-local address) > fec0:: (site-local routable address) >Okay, so I've got those three. So let's say I've figure out the outbound >interface (which neatly avoids the multi-homed discussion), and now I want >to send a packet. Note that if I'm a router, this isn't a problem, as the >source address is already there. This is for communication that ORIGINATES >WITH MY NODE. >Fine. In my particular scheme of doing things, my "next-hop" cache and/or >"neighbor" cache (to use the terms in all of the discovery drafts) has a >"suggested source address" (an ifaddr * for you BSD types) in it. >Sometimes, if I'm getting new destinations added, the next-hop or neighbor >cache has the wrong, or less useful, source address. A particular case is >where I add a "transdefault" route to tunnel all :: packets, but >I add it BEFORE I set the on-link :: prefix and my >:: interface address. Suddenly, I was sending packets of the >form: > Src: fec0:: > Dst: :: >Do you see where I'm coming from? I'm not setting the source address >correctly. >I can see a basic set of rules where: > 1. If link-local dest, use link-local src. > 2. If v4-compatible dest, use v4-compatible src. > 3. If site-local dest, use site-local src. > 4. Otherwise, pick "best" source on that interface. Not clear this is the way to approach the problem, but maybe? For one thing DNS will give the transport an address in the real world (customers will hate keying in IPv6 addresses). Now we do have the problem I have brought up ad-nauseam that we will get multiple addresses per name from the DNS for IPv6 (as we do in IPv4). The API will only pass one address to the transport which will look for an ND entry in the route-cache (at least in our implementation) and pass that or NOT FOUND (NULL) to the IPv6 Layer. So should the IPv6 Layer or Link Layer (depending on where one does ND processing checks) change the destination address? I think not. The application made the choice. Same for source address too. But the source address does have some flexibility here I guess at the transport or network layer. >One other thing, can you imagine doing those four steps on every outgoing >d-gram? I didn't think so. I *CAN* imagine, however, doing those four >steps when creating a new next-hop or neighbor cache entry. (Sometimes, >especially in the case of neighbor caches, the correct source address just >falls out. An implementation detail of mine, and probably others who are >BSD-ish I guess.) No I can't. This cannot be done on a packet-by-packet basis that would be bogus. I think we may need a flag in DNS or in ND cache for global, site, and maybe link-local address. I think an implementation should always use a global address when possible for both source and destination, and in cases where that should not be done should be the exception. But I am not clear yet on when or what the exception is to an implementation? Just a comment on the term BSD-ish. I know of no implemenations that are not BSD-ish in some sense. And I have seen sources for PC's, VMS, UNIX, and even MVS work some of our mainframe IP folks have done. So I think we don't have to differentiate things by BSD-ish. Clearly when talking about the Radix tree the question is has an implemenation updated their "model" to 4.4. But one could talk of UNIX-ish or NT-ish implementations. For example in Digital UNIX we have added Mach parts to VM and Threads to enhance the network kernel and SMP for performance, but its completely transparent to the BSD model. I think BSD is the defacto model for the IP stack for any implementation at most vendors. Simply because if a bright person like Van Jacobson, Craig Partridge, Keith Sklower, Jeff Mogul, or Steve Deering comes up with a new performance gain we can put it into our code base more easily. So far I find IPv6 specs and architecture do not break that benefit (but we got a ways to go). >Bottom line: How have people addressed the source-address-selection > by not just destination but SOURCE as well. How is that > connection state, because connections in TCP are defined > done by you folks? > My answer is to try my best to determine the source address > at the creation of a next-hop or neighbor cache entry. This > save doing checks at EVERY outgoing datagram. Do mask on dst / src addr if > 1 addr per interface for non-local part. This insures if your going to a global dst you use a global src and should also catch site-local address. This means you trust DNS or the user to provide a good addr via the API to the implementation. So that the trust model for this case. This is really only two steps. Or If its a neighbor you can always use link-local. If its not a neighbor you can always use global, unless you want to try site-local first. But if in deprecation mode try to use site-local addresses as this is your hint in the kernel renumbering MAY be taking place (see addr conf spec). Avoid global packet during deprecation mode if possible per the mask strategy above. Very smart implemenation that needs to understand subnets can parse that part of the address for whatever reason (site has dedicated one of the v6 addresses for mobile or dns subnet traffic). Clearly lots to think about before building any real products. So I think it might be valuable to have a flag in ND or ifnet structures to define link-local, site-local, and global addresses if we can figure out the heuristics to determine such state of an address in v6? /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Jul 27 07:27:56 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA26028; Thu, 27 Jul 95 07:27:56 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA26022; Thu, 27 Jul 95 07:27:48 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA24711; Thu, 27 Jul 1995 07:17:11 -0700 Received: from mail1.digital.com by mercury.Sun.COM (Sun.COM) id HAA21390; Thu, 27 Jul 1995 07:17:10 -0700 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by mail1.digital.com; (5.65 EXP 4/12/95 for V3.2/1.0/WV) id AA19606; Thu, 27 Jul 1995 07:06:32 -0700 Received: by xirtlu.zk3.dec.com; id AA01217; Thu, 27 Jul 1995 10:06:25 -0400 Message-Id: <9507271406.AA01217@xirtlu.zk3.dec.com> To: Francis Dupont Cc: "Thomas Narten" , ipng@sunroof.Eng.Sun.COM (IPv6 List) Subject: (IPng 437) Re: in favor of a preference field in Router Advertisements In-Reply-To: Your message of "Wed, 26 Jul 95 19:39:22 +0200." <199507261739.TAA20561@givry.inria.fr> Date: Thu, 27 Jul 95 10:06:19 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk >If you know 4.4BSD-Lite routing code, my idea is to put >the anycast link-local address in the rt_gateway field of >routes using the default router (funny, isn't it ? :-) >and to update in place the rt_gwroute route entry >(it is the real thing) using change requests on the default route. Interesting idea. But how did you know the anycast address? /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Jul 27 07:46:50 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA26045; Thu, 27 Jul 95 07:46:50 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA26039; Thu, 27 Jul 95 07:46:42 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA26280; Thu, 27 Jul 1995 07:36:07 -0700 Received: from alpha.xerox.com by mercury.Sun.COM (Sun.COM) id HAA24746; Thu, 27 Jul 1995 07:36:06 -0700 Received: from redwing.parc.xerox.com ([13.2.116.19]) by alpha.xerox.com with SMTP id <14716(5)>; Thu, 27 Jul 1995 07:35:58 PDT Received: by redwing.parc.xerox.com id <177520>; Thu, 27 Jul 1995 07:35:54 -0700 Date: Thu, 27 Jul 1995 07:35:49 PDT From: Lixia Zhang To: ipng@sunroof.Eng.Sun.COM Subject: (IPng 438) Re: Lixia's study group In-Reply-To: Your message of Tue, 25 Jul 1995 16:03:23 -0700 Message-Id: Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk > > We have no choice, however, so we should start pushing now to get the > > right solutions deployed. > > So, what do you think is "the right solution" with respect to > the address allocation architecture ? > > Yakov. I was curious waiting to see what others' answer might be. In any case here is my 2 cents: for myself I'm yet to learn what "the right solution" should be. However we dont have the luxury just sit and wait until we find the right solution; we need to push IPv6 forward, and we picked the current IPv4 practice as one way to go. Yes there are problems, there are open issues, but we already have to cope with all of that now under IPv4, life cannot become worse just by IPv6 taking the same choice. We may find satisfiable solutions to all the open issues as we move along, and the current choice may turn out to be a "right solution"; or we may find a better solution that we can move into to make life ever happier :) Lixia ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Jul 27 10:31:59 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA26235; Thu, 27 Jul 95 10:31:59 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA26229; Thu, 27 Jul 95 10:31:51 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA17396; Thu, 27 Jul 1995 10:20:53 -0700 Received: from ns1.digital.fr by mercury.Sun.COM (Sun.COM) id KAA04060; Thu, 27 Jul 1995 10:20:36 -0700 Received: by inet-gw-1.digital.fr (5.65/VBE-jep-20mar95) id AA29106; Thu, 27 Jul 95 19:21:19 +0200 Received: from nestvx.enet by vbormc.vbo.dec.com (5.65-jep/rmc-umc-11jul95) id AA18441; Thu, 27 Jul 1995 18:51:43 +0200 Message-Id: <9507271651.AA18441@vbormc.vbo.dec.com> Received: from nestvx.enet; by vbormc.enet; Thu, 27 Jul 95 18:51:46 MET DST Date: Thu, 27 Jul 95 18:51:46 MET DST From: Markus Jork To: "ipng@sunroof.eng.sun.com"@vboRMC.vbo.dec.com Cc: jork@nestvx.enet.dec.com Apparently-To: ipng@sunroof.eng.Sun.COM Subject: (IPng 439) ICMPv6 group membership messages Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Do nodes send group membership messages (query, report and termination) for IPv6 link-local scope multicast addresses? These include the all-nodes, all-routers, DHCP and solicited-node addresses. The same question for node-local addresses. This doesn't seem to make sense because these group membership messages are used to provide information to multicast routers, which have no business in forwarding these kind of multicast addresses anyway. I couldn't find anything about this in the specs ("ICMPv6" and "IPv6 Addressing Architecture"). All the ICMPv6 draft says is: > The ICMPv6 Group Membership messages are used to convey information > about multicast group membership from nodes to their > neighboring routers. The details of their usage is given in [RFC-1112]. RFC 1112 states: > ... a report delay timer is never set for a host's membership > in the all-hosts group (224.0.0.1), and that membership is never > reported. So I don't think it's obvious what to do with IPv6 node-local and link-local scope multicast addresses and we need a clarification in the IPv6 Specs. I suggest that group membership messages are never sent for these kind of addresses. Right? Markus ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Jul 27 11:01:29 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA26310; Thu, 27 Jul 95 11:01:29 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA26304; Thu, 27 Jul 95 11:01:21 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA22083; Thu, 27 Jul 1995 10:50:37 -0700 Received: from inet-gw-2.pa.dec.com by mercury.Sun.COM (Sun.COM) id KAA16950; Thu, 27 Jul 1995 10:50:28 -0700 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-2.pa.dec.com (5.65/24Feb95) id AA15659; Thu, 27 Jul 95 10:40:35 -0700 Received: by xirtlu.zk3.dec.com; id AA06211; Thu, 27 Jul 1995 13:40:38 -0400 Message-Id: <9507271740.AA06211@xirtlu.zk3.dec.com> To: "Thomas Narten" Cc: Francis Dupont , ipng@sunroof.Eng.Sun.COM (IPv6 List) Subject: (IPng 440) Re: in favor of a preference field in Router Advertisements In-Reply-To: Your message of "Wed, 26 Jul 95 14:08:13 CDT." <9507261808.AA18969@cichlid.raleigh.ibm.com> Date: Thu, 27 Jul 95 13:40:33 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Tom/Francis, Got to jump in OK. >All of your arguments for preferences assume that the semantics of >default router preferences should be changed so that the highest >preference router is always used. That is, it is no longer a "default >router preference" but a "router preference" that should be honored at >all times, not just when a default router is selected initialy. >Are these the semantics folks mean when they say "we want router >preferences"? Thats how I view it. So at the interim meeting is it possible preferences were dropped through a misunderstanding of their need and value to a host implementation? >>=> no, redirects give a lot of traffic (576 bytes each), >>a lot of route entries, etc... >Are you arguing that we need router preferences because the cost of >redirects is too expensive? I would contend that redirects are expensive for anything (e.g. mobile, ND, NBMA). I would like to believe we have exhausted all technical possibilities before we use redirects in any case. I await how we are doing ATM via ND at present as an example but it should not hold up ND going to proposed standard (we hope to run IPv6 over ATM in our prototype work and this will be an issue at least for our code base )---> using RSVP to test RSVP for IPv6 over ATM on a host too fyi). But lets not permit this present discussion slow down getting ND to proposed standard OK. I would rather it move along to proposed standard then get some more implementation experience and fix what we learn about. Right now all we are doing (and I think others) is the basics to find nodes. So unless the input would create an objection at last call please lets move this spec to proposed standard. Maybe I am just slow and too old but I think its going to take us awhile to really test ND with stateless and stateful addr conf and then to see its affect to the IP network utilities and other network applications like SNMP. Lets move to proposed standard. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Jul 28 15:41:18 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA27161; Fri, 28 Jul 95 15:41:18 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA27154; Fri, 28 Jul 95 15:41:09 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA29383; Fri, 28 Jul 1995 15:30:33 -0700 Received: from noao.edu by mercury.Sun.COM (Sun.COM) id PAA01507; Fri, 28 Jul 1995 15:30:31 -0700 Received: from gemini.tuc.noao.edu by noao.edu (4.1/SAG-Noao.G102) id AA16345; Fri, 28 Jul 95 15:30:29 MST; for ipng@sunroof.eng.sun.com Received: by gemini.tuc.noao.edu (4.1/SAG.sat.14) id AA13765; Fri, 28 Jul 95 15:30:11 MST; for ipng@sunroof.eng.sun.com Message-Id: <9507282230.AA13765@gemini.tuc.noao.edu> From: rstevens@noao.edu (Richard Stevens) Date: Fri, 28 Jul 1995 15:30:11 -0700 Reply-To: Richard Stevens X-Phone: +1 520 297 9416 X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: ipng@sunroof.Eng.Sun.COM Subject: (IPng 441) reversal of source routes Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk In the API draft (ipngwg-bsd-api-02.txt) the statement is made (p. 12) that "In order for source routing to operate properly, the node receiving a request packet that bears a source route must reverse that source route when sending the reply." But in the mobility draft (perkins-ipv6-mobility- sup-02.txt) is states (p. 10) "In particular, it is fortunate that IPv6 routing headers do not carry the semantics which require reversal of source routes." So I went to the protocol draft (ipngwg-ipv6-spec-02.txt) and found it says nothing about source route reversal. What are the rules regarding source route reversal? Rich Stevens ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun Jul 30 16:46:53 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA27995; Sun, 30 Jul 95 16:46:53 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA27989; Sun, 30 Jul 95 16:46:44 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA16054; Sun, 30 Jul 1995 16:36:05 -0700 Received: from munnari.oz.au by mercury.Sun.COM (Sun.COM) id QAA12609; Sun, 30 Jul 1995 16:35:58 -0700 From: Alan.Lloyd@datacraft.com.au Received: from datacraft.com.au by munnari.oz.au with MHSnet (5.83--+1.3.1+0.50) id AA15698; Mon, 31 Jul 1995 09:35:56 +1000 (from Alan.Lloyd@datacraft.com.au) Received: from [148.182.10.2] by cms.datacraft.com.au with SMTP (5.65/1.2-eef) id AA18243; Mon, 31 Jul 95 09:16:15 +1000 Received: by dcthq2.datacraft.com.au; Mon, 31 Jul 95 9:40:43 +1100 Date: Mon, 31 Jul 95 9:34:44 AUS Message-Id: X-Priority: 3 (Normal) To: Cc: Subject: (IPng 442) Re: Lixia's study group X-Incognito-Sn: 578 X-Incognito-Format: VERSION=2.01a ENCRYPTED=NO Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk renumbering. regardless af all the protocols, etc. where is this pool of reusable addresses come from, who tells all the correspondents of a network that it has been renumbered and when, how is the extent of the renumbering measured re extensibility, what is the effect on system outage, from an internal operational point and an external connectivity point. what happens if the system fails or a link breaks between reallocation. recovery and regression? interesting issue on a global scale eh! regards alan@Oz ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Jul 31 11:02:49 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA28230; Mon, 31 Jul 95 11:02:49 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA28224; Mon, 31 Jul 95 11:02:41 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA05277; Mon, 31 Jul 1995 10:51:43 -0700 Received: from alpha.xerox.com by mercury.Sun.COM (Sun.COM) id KAA29083; Mon, 31 Jul 1995 10:51:22 -0700 Received: from digit.parc.xerox.com ([13.2.117.114]) by alpha.xerox.com with SMTP id <15164(2)>; Mon, 31 Jul 1995 10:51:09 PDT Received: from localhost by digit.parc.xerox.com with SMTP id <75270>; Mon, 31 Jul 1995 10:51:05 -0700 To: Yakov Rekhter Cc: ipng@sunroof.Eng.Sun.COM, deering@parc.xerox.com Subject: (IPng 443) Re: Lixia's study group In-Reply-To: yakov's message of Tue, 25 Jul 95 05:06:59 -0800. <199507251206.FAA12706@hubbub.cisco.com> Date: Mon, 31 Jul 1995 10:51:03 PDT From: Steve Deering Message-Id: <95Jul31.105105pdt.75270@digit.parc.xerox.com> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Yakov, > The ability to renumber a whole segment of a network (and not just > hosts) is an *essential precondition* for the provider-based addressing > to work. If by "renumber" you mean "automatically renumber" (as opposed to manually renumber), then your *essential precondition* has not been met for IPv4. Are you therefore prepared to argue against provider-based addressing for IPv4? Steve ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Jul 31 11:25:41 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA28250; Mon, 31 Jul 95 11:25:41 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA28244; Mon, 31 Jul 95 11:25:33 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA09809; Mon, 31 Jul 1995 11:14:51 -0700 Received: from hubbub.cisco.com by mercury.Sun.COM (Sun.COM) id LAA04711; Mon, 31 Jul 1995 11:14:47 -0700 Received: from puli.cisco.com (puli.cisco.com [171.69.1.174]) by hubbub.cisco.com (8.6.10/CISCO.GATE.1.1) with SMTP id LAA27990; Mon, 31 Jul 1995 11:14:03 -0700 Message-Id: <199507311814.LAA27990@hubbub.cisco.com> To: Steve Deering Cc: ipng@sunroof.Eng.Sun.COM Subject: (IPng 444) Re: Lixia's study group In-Reply-To: Your message of "Mon, 31 Jul 95 10:51:03 PDT." <95Jul31.105105pdt.75270@digit.parc.xerox.com> Date: Mon, 31 Jul 95 11:14:02 PDT From: Yakov Rekhter Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Steve, > If by "renumber" you mean "automatically renumber" (as opposed to manually > renumber), then your *essential precondition* has not been met for IPv4. Are > you therefore prepared to argue against provider-based addressing for IPv4? Do we have any other alternatives to provider-based addressing for IPv4 ? Seems like no. So, our only choice is to proceed with this scheme (which means renumbering as well, whether manual or automatic), for as long as we need to keep IPv4 running, and hope that IPv6 would improve the situation. Do we have any other alternatives with IPv6 ? If "yes", could they be better than provider-based addressing ? Yakov. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Jul 31 11:59:14 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA28306; Mon, 31 Jul 95 11:59:14 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA28300; Mon, 31 Jul 95 11:59:05 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA16530; Mon, 31 Jul 1995 11:48:18 -0700 Received: from alpha.xerox.com by mercury.Sun.COM (Sun.COM) id LAA13550; Mon, 31 Jul 1995 11:48:06 -0700 Received: from digit.parc.xerox.com ([13.2.117.114]) by alpha.xerox.com with SMTP id <15247(2)>; Mon, 31 Jul 1995 11:47:42 PDT Received: from localhost by digit.parc.xerox.com with SMTP id <75270>; Mon, 31 Jul 1995 11:47:38 -0700 To: Yakov Rekhter Cc: ipng@sunroof.Eng.Sun.COM, deering@parc.xerox.com Subject: (IPng 445) Re: Lixia's study group In-Reply-To: yakov's message of Mon, 31 Jul 95 11:14:02 -0800. <199507311814.LAA27990@hubbub.cisco.com> Date: Mon, 31 Jul 1995 11:47:28 PDT From: Steve Deering Message-Id: <95Jul31.114738pdt.75270@digit.parc.xerox.com> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Yakov, > Do we have any other alternatives to provider-based addressing for IPv4 ? > Seems like no. So, our only choice is to proceed with this scheme (which > means renumbering as well, whether manual or automatic), for as long as > we need to keep IPv4 running, and hope that IPv6 would improve the > situation. Then the ability to renumber a whole segment of a network is *not* an "*essential precondition*" for provider-based addressing, as you claimed, but rather something to "improve the situation". I don't think the lack of such an ability at this stage in the development of IPv6 is, by itself, sufficient grounds to reject provider-based addressing for IPv6, any more than it is for IPv4. > Do we have any other alternatives with IPv6 ? If "yes", could they be > better than provider-based addressing ? Yes, we have alternatives, which are better by some measures and worse by others. So far, we haven't been able to get agreement on a single measure (or a weighting of multiple measures) that would enable us to decide that one alternative is strictly "better" than another. Steve ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Jul 31 15:48:12 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA28559; Mon, 31 Jul 95 15:48:12 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA28553; Mon, 31 Jul 95 15:48:03 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA28732; Mon, 31 Jul 1995 15:37:18 -0700 Received: from amdext.amd.com by mercury.Sun.COM (Sun.COM) id PAA04446; Mon, 31 Jul 1995 15:37:07 -0700 Received: from amdint.amd.com by amdext.amd.com with SMTP id AA09162 (5.67a/IDA-1.5+AMD for ); Mon, 31 Jul 1995 15:37:01 -0700 Received: from brahms.amd.com by amdint.amd.com with SMTP id AA06847 (5.67a/IDA-1.5+AMD); Mon, 31 Jul 1995 15:37:00 -0700 Received: from angelo.amd.com by brahms.amd.com (4.1/AMDSN-1.18) id AA05727; Mon, 31 Jul 95 15:36:59 PDT Received: by angelo.amd.com (4.1/AMDC-1.18) id AA10095; Mon, 31 Jul 95 15:36:57 PDT From: David.Roberts@amd.com (Dave Roberts) Message-Id: <9507312236.AA10095@angelo.amd.com> Subject: (IPng 446) Ethertype and multicast filtering info To: deering@parc.xerox.com, hinden@ipsilon.com Date: Mon, 31 Jul 1995 15:36:56 -0700 (PDT) Cc: ipng@sunroof.Eng.Sun.COM (IPNG Mailing List) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Steve and Bob, In Stockholm, I said that I'd mail you information about PC driver behavior and multicast filtering. I just got back from Sweden on Friday (after taking a week vacation). Here's the info I promised. All major PC LAN driver standards are basically multiprotocol. They handle this in different ways. For instance: * NDIS 3 handles this by having the driver perform an indication to the network stack for every packet received. The stack decides whether to accept the packet (by interpreting Ethertype) and if it wants it, calls a function to cause the driver to copy the packet into stack-supplied buffers. The driver simply passes the Ethertype value through without interpretation. * Packet Driver allows a protocol to inform the driver which protocols it wants to receive. It performs a call to the driver at initialization time to specify an Ethertype value it is interested in. The driver simply compares the Ethertype of the received frame to a table it keeps and delivers the frame to the correct protocol. The driver doesn't care what the value is. It's simply a pattern matching exercise. In both cases, allocating a different Ethertype value to IPv6 is not an issue. There are other driver interface standards (notably Novell's ODI and NDIS 2). The basic operation of the others is similar to the above schemes and does not preclude the addition of another Ethertype value. Second, duing the working group meeting presentation on router/neighbor discovery, people expressed concerns about multimedia traffic using a multicast address mapping to the same hash bucket as the multicast address used for router/neighbor discovery. This could definitely be a problem. Here's the scoop. 1. Most controllers use a hash-bucket scheme. Both AMD's LANCE and National's NIC use the same algorithm. As the address comes in, it is fed through a CRC circuit (the CRC circuit checking the frame CRC value). When the last bit of the address has been fed through, the CRC value at that point is latched in a register. The upper 6 bits of the CRC value are used to index a 64-bit vector. Each bit in the vector corresponds to a hash bucket. A set bit causes the frame to be accepted and a cleared bit causes the frame to be rejected. Once the frame has been received, software checks to see if the frame is multicast and if so searches the list of current multicast addresses for this interface for an exact match. 2. These are very common controllers. Both the AMD LANCE and the National NIC architectures have been used in many follow-on chips. All AMD controllers use the LANCE scheme. All National controllers use the NIC scheme. These controllers are used in workstations (Sun, HP, etc.), PCs, printers, routers--basically everything. 3. Fixing this problem is difficult. Two things could be done. First, more hash buckets could be added. It's a simple matter of extending the bit vector and using more bits of the CRC. This is easy but doesn't really eliminate the problem. A second solution is to include more perfect address filtering. Essentially this means using a CAM. This adds significant cost to the chip, which is why chips have used the hashing scheme in the past. *BOTH* schemes suffer from a "how much do you add?" question. In the case of extending the number of hash buckets, how many buckets do you want? In the case of CAM, how many CAM entries do you need? Once the limitations of the extended schemes are reached you encounter the same problems. In the meeting, there was a comment (by Brian Carpenter, I believe) that PCs should simply get better hardware and that we'll grow out of this problem. This is a dangerous sentiment to espouse as a solution to this problem. As I said above, there is no distinction between controllers used in PCs and workstations. They both use the same hardware and the same filtering schemes. Both use state-of-the-art controllers (in fact, many PCs use newer, more state-of-the-art controllers than many workstations). Further, many workstations are now adopting controllers developed for the PC's PCI bus. Again, controllers using these schemes are used in everything--workstations, PCs, routers, printers, etc. In short, it's all the same hardware and everybody has the problems. Anyway, that should give some direction to the current discussions. Dave Roberts Advanced Micro Devices, Inc. I/O and Network Products Division david.roberts@amd.com ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Jul 31 17:21:53 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA28723; Mon, 31 Jul 95 17:21:53 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA28717; Mon, 31 Jul 95 17:21:42 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA12114; Mon, 31 Jul 1995 17:10:53 -0700 Received: from alpha.xerox.com by mercury.Sun.COM (Sun.COM) id KAA18968; Mon, 31 Jul 1995 10:33:17 -0700 Received: from digit.parc.xerox.com ([13.2.117.114]) by alpha.xerox.com with SMTP id <15178(1)>; Mon, 31 Jul 1995 10:32:59 PDT Received: from localhost by digit.parc.xerox.com with SMTP id <75270>; Mon, 31 Jul 1995 10:32:49 -0700 To: Yakov Rekhter Cc: ipng@sunroof.Eng.Sun.COM, deering@parc.xerox.com Subject: (IPng 447) Re: Lixia's study group In-Reply-To: yakov's message of Tue, 25 Jul 95 04:50:48 -0800. <199507251150.EAA12170@hubbub.cisco.com> Date: Mon, 31 Jul 1995 10:32:40 PDT From: Steve Deering Message-Id: <95Jul31.103249pdt.75270@digit.parc.xerox.com> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Yakov writes: "Address ownership" is neither "bad" nor "good". On page 15 of the July '95 issue of Connexions: Address Ownership Considered Fatal by Yakov Rekhter and Tony Li "Fatal" sounds pretty "bad" to me! Steve ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Jul 31 17:52:33 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA28766; Mon, 31 Jul 95 17:52:33 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA28760; Mon, 31 Jul 95 17:52:25 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA16323; Mon, 31 Jul 1995 17:41:44 -0700 Received: from munnari.oz.au by mercury.Sun.COM (Sun.COM) id RAA27900; Mon, 31 Jul 1995 17:41:39 -0700 From: Alan.Lloyd@datacraft.com.au Received: from datacraft.com.au by munnari.oz.au with MHSnet (5.83--+1.3.1+0.50) id AA03791; Tue, 1 Aug 1995 10:41:05 +1000 (from Alan.Lloyd@datacraft.com.au) Received: from [148.182.10.2] by cms.datacraft.com.au with SMTP (5.65/1.2-eef) id AA23194; Tue, 1 Aug 95 10:20:08 +1000 Received: by dcthq2.datacraft.com.au; Tue, 1 Aug 95 10:44:40 +1100 Date: Tue, 1 Aug 95 10:40:28 AUS Message-Id: X-Priority: 3 (Normal) To: Cc: Subject: (IPng 448) Re: Lixia's study group X-Incognito-Sn: 578 X-Incognito-Format: VERSION=2.01a ENCRYPTED=NO Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk steve, perhaps yakov meant that fatal was worse than bad. anyway, has this conversation hit a dead end. :-) regards alan ps. I am still not sure how we deal with unowned addresses. something, somewhere has to define, administer and manage them. Is this a job for the Pope? ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Jul 31 17:59:20 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA28782; Mon, 31 Jul 95 17:59:20 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA28776; Mon, 31 Jul 95 17:59:12 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA17038; Mon, 31 Jul 1995 17:48:31 -0700 Received: from mail1.digital.com by mercury.Sun.COM (Sun.COM) id RAA29195; Mon, 31 Jul 1995 17:48:31 -0700 Received: from muggsy.lkg.dec.com by mail1.digital.com; (5.65 EXP 4/12/95 for V3.2/1.0/WV) id AA27969; Mon, 31 Jul 1995 17:42:39 -0700 Received: from whydos.lkg.dec.com by muggsy.lkg.dec.com (5.65/DEC-Ultrix/4.3) with SMTP id AA04668; Mon, 31 Jul 1995 20:42:37 -0400 Received: from localhost (localhost [127.0.0.1]) by whydos.lkg.dec.com (8.6.11/8.6.9) with SMTP id UAA24210; Mon, 31 Jul 1995 20:52:50 GMT Message-Id: <199507312052.UAA24210@whydos.lkg.dec.com> X-Authentication-Warning: whydos.lkg.dec.com: Host localhost didn't use HELO protocol To: ipng@sunroof.Eng.Sun.COM (IPNG Mailing List) Cc: David.Roberts@amd.com (Dave Roberts) Subject: (IPng 449) Re: Ethertype and multicast filtering info In-Reply-To: Your message of "Mon, 31 Jul 1995 15:36:56 MST." <9507312236.AA10095@angelo.amd.com> X-Mailer: exmh version 1.5omega 10/6/94 Date: Mon, 31 Jul 1995 20:52:49 +0000 From: Matt Thomas Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk In <9507312236.AA10095@angelo.amd.com>, David.Roberts@amd.com (Dave Roberts) wrote: > 1. Most controllers use a hash-bucket scheme. Both AMD's LANCE and > National's NIC use the same algorithm. As the address comes in, it is > fed through a CRC circuit (the CRC circuit checking the frame CRC > value). When the last bit of the address has been fed through, the > CRC value at that point is latched in a register. The upper 6 bits of > the CRC value are used to index a 64-bit vector. Each bit in the > vector corresponds to a hash bucket. A set bit causes the frame to be > accepted and a cleared bit causes the frame to be rejected. Once the > frame has been received, software checks to see if the frame is > multicast and if so searches the list of current multicast addresses > for this interface for an exact match. Note that some chips (such as the Digital PCI Ethernet Controllers) use the low 9 bits (for a 512 bit hash) of the CRC-32 algorithm. So you can't tune it for either the high or the low bits. Most PC drivers assume that only a small number (say about 6) of multicasts will be enabled at any time. They will probably not handle significant numbers of multicasts well, if at all. > 3. Fixing this problem is difficult. Two things could be done. > First, more hash buckets could be added. It's a simple matter of > extending the bit vector and using more bits of the CRC. This is easy > but doesn't really eliminate the problem. A second solution is to > include more perfect address filtering. Essentially this means using > a CAM. This adds significant cost to the chip, which is why chips > have used the hashing scheme in the past. *BOTH* schemes suffer from > a "how much do you add?" question. In the case of extending the > number of hash buckets, how many buckets do you want? In the case of > CAM, how many CAM entries do you need? Once the limitations of the > extended schemes are reached you encounter the same problems. As a data point, the Digital PCI Ethernet Controllers (which have a fairly large chunk of the PCI Controller market) have both perfect filtering (up to 16 addresses) and (as stated above) 512 multicast hash buckets. The Digital FDDI Controllers don't even use a multicast hash but rely on a 62-address address CAM. If the number of addresses exceeds the size of the CAM, then the driver switches into all-multicast and does the filtering itself. > In the meeting, there was a comment (by Brian Carpenter, I believe) > that PCs should simply get better hardware and that we'll grow out of > this problem. This is a dangerous sentiment to espouse as a solution > to this problem. As I said above, there is no distinction between > controllers used in PCs and workstations. They both use the same > hardware and the same filtering schemes. Both use state-of-the-art > controllers (in fact, many PCs use newer, more state-of-the-art > controllers than many workstations). Further, many workstations are > now adopting controllers developed for the PC's PCI bus. Again, > controllers using these schemes are used in everything--workstations, > PCs, routers, printers, etc. In short, it's all the same hardware and > everybody has the problems. These days there is little distinction between PCs and workstations, period. By the time IPv6 is even slightly deployed, probably 2 generations will have passed in the PC universe. That's almost an eternity for them. Even if the networking hardware doesn't get smarter, the CPUs will have gotten faster. 486s are getting close to being obsolete (anything less than a 66 probably is). Think where things will be one or two years out. Should IPv6 push the edge of envelope? Probably not. But then I don't consider using dozens of multicasts as pushing the edge. Any properly written driver should be able to handle that, even using PC hardware. (I know my drivers do; even those that use the LANCE). By the time IPv6 is deploying, one way or another, this will not be a significant issue. Either CPU power will be used to compensate for the old devices/drivers or new better networking hardware will be out which can handle this. Please don't think is this is an IPv6 only issue. As 100mb/s LANs spread, the (ab)use of the broadcast address by various protocols will cause this to become more visible for other protocols as well. Matt Thomas Internet: thomas@lkg.dec.com U*X Networking WWW URL: http://ftp.dec.com/%7Ethomas/ Digital Equipment Corporation Disclaimer: This message reflects my Littleton, MA own warped views, etc. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Jul 31 18:13:15 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA28814; Mon, 31 Jul 95 18:13:15 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA28808; Mon, 31 Jul 95 18:13:06 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA01006; Mon, 31 Jul 1995 10:02:45 -0700 Received: from watson.ibm.com by mercury.Sun.COM (Sun.COM) id KAA12004; Mon, 31 Jul 1995 10:02:39 -0700 Received: from WATSON by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 9051; Mon, 31 Jul 95 13:00:40 EDT Received: from YKTVMV by watson.vnet.ibm.com with "VAGENT.V1.01 on VAGENT2" id 7715; Mon, 31 Jul 1995 13:00:40 EDT Received: from hawpub1.watson.ibm.com by yktvmv.watson.ibm.com (IBM VM SMTP V2Rx) with TCP; Mon, 31 Jul 95 13:00:39 EDT Received: by hawpub1.watson.ibm.com (AIX 3.2/UCB 5.64/930311) id AA40781; Mon, 31 Jul 1995 13:00:19 -0400 From: perk@watson.ibm.com (Charlie Perkins) Message-Id: <9507311700.AA40781@hawpub1.watson.ibm.com> To: Richard Stevens Cc: ipng@sunroof.Eng.Sun.COM Subject: (IPng 450) Re: reversal of source routes In-Reply-To: (Your message of Fri, 28 Jul 95 15:30:11 MST.) <9507282230.AA13765@gemini.tuc.noao.edu> Date: Mon, 31 Jul 95 13:00:19 -0500 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk It was my clear understanding that the IPv4 handling of source routes was considered to be a failure, both because of differing implementations and because of the bad security consequences of requiring the reversal of source routes. I thought that there was agreement that the current draft _purposefully_ omitted the requirement that source routes be reversed, in order to simplify implementations and eliminate the security problems. Perhaps there should be more than one "routing type" for IPv6 routing headers, depending upon whether or not the source route is expected to be reversed. Charlie P. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Jul 31 21:05:22 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA28915; Mon, 31 Jul 95 21:05:22 PDT Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA28909; Mon, 31 Jul 95 21:05:14 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA01010; Mon, 31 Jul 1995 20:54:32 -0700 Received: from ns.crynwr.com by mercury.Sun.COM (Sun.COM) id UAA19356; Mon, 31 Jul 1995 20:54:33 -0700 Received: by ns.crynwr.com (Linux Smail3.1.28.1 #4) id m0sd8PT-000H96C; Mon, 31 Jul 95 23:54 EDT Message-Id: Date: Mon, 31 Jul 95 23:54 EDT From: nelson@crynwr.com (Russell Nelson) To: ipng@sunroof.Eng.Sun.COM Subject: (IPng 451) Re: Ethertype and multicast filtering info Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk From: David.Roberts@amd.com (Dave Roberts) Subject: (IPng 446) Ethertype and multicast filtering info To: deering@parc.xerox.com, hinden@ipsilon.com Cc: ipng@sunroof.Eng.Sun.COM (IPNG Mailing List) Date: Mon, 31 Jul 1995 15:36:56 -0700 (PDT) Second, duing the working group meeting presentation on router/neighbor discovery, people expressed concerns about multimedia traffic using a multicast address mapping to the same hash bucket as the multicast address used for router/neighbor discovery. This could definitely be a problem. It *might* be a problem. If the multicast addresses map to the same hash bucket, then you're going to be an unhappy participant in the multimedia traffic. It depends on how often it happens. If both of these addresses are fixed numbers, then it's bad... very bad. If either of them are chosen at pseudo-random (or effectively so), then it's probably not so bad. The devices that use a hash bucket (and that's probably 99% of the market: AMD LANCE, National NIC, Intel 82586, 82595, Fujitsu 869xx) use 64 buckets. That's something less than 2% probability. The National SONIC has a CAM, but I see a comment in my code that it can't be used for multicast addresses. Dunno if that's right -- it's been a few years. The actual impact on your host depends on how high up in the stack the packets get tossed. A packet driver will immediately discard the packet if there's no receiver for the packet's Ethernet type. Actual cost of doing that is: an interrupt requested (but more on that later), a context switch, reading 14 bytes of ethertype, and running through the list of registered ethertypes. If no match, discard the packet and exit. An NDIS stack always upcalls every stack with the first 100 bytes of the packet until one of them wants it or it's asked all of them. A data point: back when Doom 1.1 was using broadcasts, people complained not because their workstations were slowing down, but because their Novell wide area links were getting pounded by Doom's IPX broadcasts. And these were broadcasts, with a 100% probability that every host had to look at the packet. If your system is busy, then perhaps the interrupt will be dropped. For most Ethernet controllers, that's not a big deal because most of the newer ones have 16Kb of receive buffer (or in the case of the AMD LANCE, they allocate as much buffer--8K's too little, 32K's too much). Some newer Ethernet controllers put everything on the chip, including the buffers. These controllers require very low interrupt latency, sometimes generating multiple interrupts per received packet. The driver will use a smart algorithm that interrupts less often if the system is loaded, but that doesn't help with the small buffers. Don't like these el-cheapo PC Ethernet controllers? Don't complain. That's what's driven the growth of the networking industry. Certainly *I* wouldn't have this job without them, and likely many of you wouldn't have the same job without them either. -- -russ http://www.crynwr.com/~nelson Crynwr Software | Crynwr Software sells packet driver support | ask4 PGP key 11 Grant St. | +1 315 268 1925 (9201 FAX) | Describe the God you don't Potsdam, NY 13676 | believe in, and I won't believe in that God either. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/pub/ipng/html/ipng-main.html Direct all administrative requests to majordomo@sunroof.eng.sun.com