- ripe-list - mailman.ripe.net

subscribe ripe-list
by irek＠frodo.frodo.nask.org.pl 08 Feb '93

08 Feb '93

My name is Ireneusz Neska. I am a Local Internet Registry in Poland. I would like to subscribe ripe-list. Regards, Irek.

1 0

ripe-list
by abida＠spiky.rsinet.tn 05 Feb '93

05 Feb '93

Can I have a list of the ripe-list people ? Kind Regards, Nejib ABIDA

1 0

ripe-list
by abida＠spiky.rsinet.tn 05 Feb '93

05 Feb '93

subscribe ripe-list

2 1

Request for Unused Class B Internet Numbers
by Daniel Karrenberg 04 Feb '93

04 Feb '93

Dear colleagues, as you certainly know the amount of class B Internet numbers available for allocation has run quite low. Before this had become a concern European organisations have been allocated substantial blocks of class B network numbers by "the" NIC either for their own use or for reassignment to other organisations. In the meantime the RIPE NCC has taken up the role of European regional Internet registry. In the first half year of operation we have allocated 61 class B networks to European organisations that meet the criteria established by the Internet Assigned Numbers Authority (IANA). In order to ensure fair distribution of the unused class B address space to the Internet community we ask any organisation in Europe holding unused class B numbers to return them to us. We have consulted IANA on this and it has been agreed that all numbers returned in this manner will be retained by the RIPE NCC for re-assignemt to European organisations. Thus Europe as a whole will not "loose" any address space. The NCC will publish a list of all organisations returning numbers each quarter. Also we encourage all organisations currently using class B network numbers for networks with a few 10s of hosts to consider exchanging their class B number for a class C number as a service to the community. Even before this announcement we have already received 7 class B addresses from Deutsches Forschungsnetz (DFN) and one from an individual organisation. We thank them and hope that many of you will follow their example. Daniel Karrenberg RIPE NCC Manager

1 0

RIPE DNS Hostcount January 1993
by Marten Terpstra 04 Feb '93

04 Feb '93

Hi folks, the first hostcount for 1993. We have reached the 300,000 hosts in Europe now. Not much to report really, just BE and PL down a bit. Even after a re-count they stayed low. Connectivity problems are probably the cause. Still the UK and DE zones are fetched inside the countries, thanks JIPS-NOSC and Peter Koch. All output files can again be fetched from ftp.ripe.net:ripe/hostcount. Check the README for details. Again, the total history has been appended below. -Marten ---- RIPE DNS Hostcount Previous Count : Thu Dec 31 This Count : Sun Jan 31 CY SOA COUNTED DUPL REAL CHANGE ============================================================ al 1 0 0 0 0 at 224 9342 56 9286 + 552 be 4 1710 52 1658 - 350 bg 1 1 0 1 + 1 by 0 0 0 0 0 ch 120 24002 174 23828 + 877 cs 44 1796 95 1701 + 811 de 918 67087 1044 66043 + 4748 dk 92 5429 46 5383 + 482 dz 0 0 0 0 0 ee 8 76 0 76 + 9 es 192 6681 103 6578 + 1095 fi 169 20086 480 19606 + 1037 fr 349 26098 379 25719 + 975 gb 1 5 0 5 0 gr 43 840 141 699 + 152 hr 0 0 0 0 0 hu 15 649 4 645 + 156 ie 27 1313 29 1284 + 169 is 19 822 10 812 + 73 it 239 8832 107 8725 + 1618 il 43 3801 47 3754 + 168 lt 1 0 0 0 0 lu 7 114 1 113 + 3 lv 1 7 0 7 0 nl 309 25608 391 25217 + 1171 no 371 19411 265 19146 + 577 pl 83 1314 7 1307 - 256 pt 63 1946 45 1901 + 104 ro 0 0 0 0 0 se 384 26927 279 26648 + 1493 si 1 1 0 1 0 su 127 60 0 60 + 8 tn 2 15 0 15 + 3 ua 28 0 0 0 0 uk 470 61743 8144 53599 + 3778 va 0 0 0 0 0 yu 2 11 0 11 0 ============================================================ 4358 315727 11899 303828 +19454 History Oct 1990 31724 Nov 1990 33665 Dec 1990 29230 Jan 1991 43832 Feb 1991 - Mar 1991 44506 Apr 1991 46948 May 1991 - Jun 1991 63267 Jul 1991 - Aug 1991 73069 Sep 1991 92834 Oct 1991 104824 Nov 1991 129652 Dec 1991 - Jan 1992 - Feb 1992 161434 Mar 1992 167939 Apr 1992 170050 May 1992 182528 Jun 1992 196758 Jul 1992 213017 Aug 1992 221951 Sep 1992 232522 Oct 1992 254585 Nov 1992 271795 Dec 1992 284374 Jan 1993 303828

1 0

INET 93 (Network Training for developing countries)
by Jill.Foster＠newcastle.ac.uk 04 Feb '93

04 Feb '93

I've been asked to forward this. Please reply to Art st. George. Jill Foster (ISUS WG chair) %%%%%%%% Forwarded message %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Date: Wed, 03 Feb 1993 21:14 MST >From: "DOV - DR. ART ST. GEORGE" <STGEORGE(a)bootes.unm.edu> Subject: INET 93 To: jill.foster @ newcastle.ac.uk Dear Jill: would you please circulate the announcement below to the European community?> Also, I'm in charge of the network services track for the developing nations workshop of INET 93. I am in need of someone with French/English language skills and knowledge of network services to act as either an instructor or mentor. If you know of anyone, please let me know. Thanks, Art ======================================================================= INET '93 Network Training Workshop for Developing Countries February 2, 1993 In conjunction with the INET '93 Conference, the Internet Society is sponsoring a workshop for networking training for developing countries prior to the conference itself. The workshop will be held at Stanford University during August 10-16, 1993. Goals ----- The goals of the workshop are: 1. To train a critical mass of trainers/professionals in network infrastructure, transport and services to be able to support an extension of meaningful networking activities leading to Internet connectivity within developing countries represented. 2. To identify and share individual and institutional contacts as well as information sources that will assist the process of development, using international connections to and on the Internet. 3. To build robust professional linkages between all participants in the programs so that the mentor-student and peer relationships formed during the workshop and conference will remain strong and of continuing usefulness well beyond the workshop and conference. 4. To increase the level of cooperation among existing projects and activities for establishing data networks in developing countries. Program ------- An intensive program of instruction is planned for each of three program tracks: 1. Basic technical transport training. This training is designed for network technicians and technical staff focusing upon the establishment and operation of an initial network presence in a country and possibly initiating the deployment of a basic national network infrastructure in the country. It is anticipated that this initial network presence will be upgraded at a later time to support full Internet connectivity. Participants in the basic technical track should have some hands-on experience administering a computer system. Additional experience with operating systems, modems, basic communications protocols and related topics is highly desirable, but not required. Upon completion, participants will be expected to teach these skills to others in their country, expanding the breadth of networking knowledge available nationally. Topics covered will include: - Overview of computer systems, operating systems, and data communications - Store-and-forward and packet network concepts; alternative network development approaches and protocols - Modem technology - UUCP networking: principles, operation, and management - Internet-connected electronic mail services - Internet basic structure and services - Organizational steps to setting up national nets Participants will work in small groups to configure a network of store- and-forward UUCP mail nodes, and will install electronic mail services on the network. 2. Advanced technical transport training. This training is designed for network engineers who may have operational UUCP or FidoNet links within their country and/or to other countries and who want to learn about establishing and maintaining an IP network. This track will teach how to install and operate low cost Internet links within a country and between countries. Philosophy and administration will be taught as well as host, router, and physical link operation. Upon completion, participants will be expected to teach these skills to others in their country, expanding the breadth of networking knowledge available nationally. Participants should know basic communications concepts and some protocols and should have had experience operating a network node, such as FidoNet, UUCP or IP. As most work will be done with DOS and routers, participants need have no UNIX experience, but it would be helpful. Attendees should be engineering- capable. Topics covered will include: - TCP/IP protocols; IP routing principles and capabilities - Routers: DOS-based and commercial products - The domain naming system; name servers and services - Management and debugging of routed networks - Issues in multi-protocol environments - Functions and operation of a network information center (NIC) and a network operations center (NOC) - Network administration and security Participants will engage in extensive hands-on training, setting up a group of prototype low-cost IP-based nodes and establishing a network with them. In addition, participants will be able to take advantage of the workshop's location in Silicon Valley to visit several major suppliers of networking hardware and software for technical presentations and discussions. 3. Network navigation and services training. This training is designed for network information specialists focusing upon how to use connectivity to the Internet to obtain access to specialists, network resources, and information in electronic data bases. This group includes but is not limited to librarians, development specialists, and information specialists within government, higher education, and non- governmental organizations (NGOs). The purpose of the track is to provide participants with the skills to discover and exploit the various network services available on the Internet worldwide. Upon completion, participants will be expected to teach these skills to others in their country, expanding the breadth of networking knowledge available nationally. Participants should have had some hands-on experience using a computer system. Additional experience with operating systems, modems, basic communications protocols and related topics is highly desirable, but is not assumed. Topics covered will include: - Development of global data communications and impact upon developing countries - Personal electronic communication: locating experts and establishing effective communications - Many-to-many communication: UseNet News - Telnet: Remote access to computing systems and information services - FTP: Finding and retrieving network-accessible information files - Electronic libraries: on-line catalogs, periodicals and databases - Internet navigation tools and information search strategies Participants will engage in extensive hands-on training, accessing and using actual Internet resources through Stanford University's computing facilities. In additional to undergoing technical training and laboratory work, participants in all three tracks will have an opportunity to have dinner and spend an evening with a host family in the Silicon Valley area. Location -------- The workshop will be held at Stanford University, in Palo Alto, California, U.S.A. Palo Alto is approximately 30 kilometers south of the San Francisco International Airport and 50 kilometers south of the city of San Francisco. Limousine transport is available from San Francisco Airport to Palo Alto. Workshop sessions will take place in the Jordan Quadrangle and at the Elliott Program Center. Participants will be housed in student housing within the Sterling Quadrangle, located a 5 minute walk away from workshop session locations. Dates ----- Participants should plan to arrive at Stanford University on the afternoon of Tuesday, August 10th. Workshops sessions will be held all day from Wednesday, August 11th through Monday, August 16th. Transportation will be provided to San Francisco at the end of the workshop. The INET '93 Conference will be held at the Hyatt Embarcadero Hotel in San Francisco. The Conference begins on the evening of Tuesday, August 17th and continues through Friday, August 20th. Working language ---------------- The working language of the workshop will be English. A working knowledge of English will be required of each participant. Additional language skills will be supplied by members of the workshop training staff. Eligibility ----------- The workshop is specifically directed toward the needs of people from developing countries who are playing or will play an important part in introducing and extending networking in their countries. Attendees should be involved in establishing a networking presence in their countries, in institutionalizing its operation, and in assisting the country's schools and universities, governmental agencies, non- governmental organizations, local firms, and residents in learning about and exploiting the range of services available through such network connectivity. Staff members of international and bilateral technical co-operation agencies, as well as professionals involved in international technical and development assistance, are eligible for attendance. It is the responsibility of participants to obtain appropriate visas for travel to the United States, if needed, to attend the workshop and the related conferences. Enrollment is limited to about 100 people. We encourage you to apply as early as possible. Costs ----- The cost of attending the workshop and the INET '93 conference is U.S. $1,500. This fee includes: o All tuition and fees for the workshop o All lodging and meal charges, starting with dinner on Tuesday evening, August 10th through lunch on Monday, August 16th o Transportation to industrial site visits and from Stanford University to the San Francisco hotel district at the end of the workshop on Monday, August 16th o Registration at the INET '93 Conference (August 17-20), including meals and social events included in conference registration. Almost all meals during the Conference are covered by this fee. The fee does not include any transportation costs except for local transportation in the San Francisco area as noted above. Participants will be housed in student housing in the Sterling Quadrangle at Stanford University, along with some of the workshop instructors. Participants should plan to budget an additional amount in the range of $75-$100 per day for food and lodging for 4 days and nights in San Francisco. (Almost all meals during INET '93 are included in the conference registration fee and are therefore included in the workshop fee.) Participants wishing to remain in San Francisco for an additional week for the INTEROP '93 Fall Conference and Exhibits should budget an additional $100-$125 per day for 7 days to cover lodging and meals plus approximately $1,000 for INTEROP '93 Fall conference registration and tutorials. Financial assistance -------------------- Financial assistance to cover a part or all of each participant's expenditures is expected be available to deserving and financially needy candidates. The total resources expected to be available to INET '93 for financial assistance are adequate to meet a significant portion but by no means all of the demand from participants requiring such assistance. Participants needing financial assistance are strongly encouraged to seek other sources of funding to meet a part of their expenses in addition to requesting funds from INET '93. Financial assistance will be allocated to participants on the basis of both their financial need and their expected contribution to network development in their country. If you request financial assistance for the workshop, please provide the financial information requested in the application for admission. Financial assistance for workshop and conference attendance will be disbursed in one or more of the following forms: partial or total support of the workshop and conference registration fee, prepaid airline tickets available at point of departure, and cash stipends for INET '93 living expenses, which will be disbursed during the workshop. Application for admission ------------------------- To apply for admission to the workshop, please complete the attached form and submit it to INET '93 Workshop Headquarters by May 1, 1993. If you expect to attend the workshop as the result of being awarded a United Nations or similar fellowship awarded by a multilateral or bilateral aid agency, it would be useful if a copy of the fellowship application were appended to the application. Applicants will be notified of their acceptance to the program and the amount of financial assistance available for them during the first week of June. Applicants who are admitted will be asked to verify their attendance by mid-June, based upon the amount of assistance that can be made available. Applicants are strongly encouraged to submit some form of electronic address when available (possibly telex or fax) in order to expedite notification of their acceptance as well as further correspondence regarding participation. ----------------------------------------------------------------------- INET '93 Developing Countries Network Training Workshop Application for Admission Name: Address: Employer: Telephone: Telex: Fax: Electronic mail address (if any): Nationality: Knowledge of English: __ Track applied for: |__| Basic technical track (check one) __ |__| Advanced technical track __ |__| Network services track 1. Please summarize your educational background and relate your training to the prerequisites for the track you would like to attend. 2. Please describe your current job and duties and how they relate to data networking activities in your country. 3. Please describe how you expect to implement the knowledge you gain through attendance at the workshop and conference(s) upon your return to your country. Do you anticipate any change in your position or duties when you return as a result of your participation in these events? 4. If you are requesting financial aid from INET '93 for attending the workshop and conference, please provide an itemized expenditure budget for your travel and expenses. Please also provide an income budget containing sources of income that are available to you for attending. Please include with your application a signed statement from the head of your institution stating that no additional funds (beyond those included in your income budget) are available to you for the purpose of undertaking this travel and participating in this training and conference activity. 5. Please describe any issues or circumstances that would affect your participation in the workshop, e.g. physical disabilities, medical conditions, or dietary restrictions. Signature: ________________________________ Date: _________________ Please return this application to: Mail: INET '93 Developing Countries Workshop c/o USRA 625 Ellis Street, Suite 205 Mountain View, California 94043 U.S.A. Voice: 1.415.390.0317 Facsimile: 1.415.390.0318 Telex: 235128 NYU UR (Attention: INET '93 Developing Countries Workshop) Applications may be submitted electronically by sending electronic mail to: workshop-request(a)inet93.stanford.edu ====================================================================== George Sadowsky, Director Phone: (212) 998-3040 Academic Computing Facility Fax: (212) 995-4120 New York University Telex: 235128 NYU UR 251 Mercer Street Bitnet: sadowsky@nyuacf New York, New York 10012-1185 Internet: sadowsky(a)nyu.edu

1 0

JENC4 Preliminary Programme - please use this version
by bersee＠rare.nl 29 Jan '93

29 Jan '93

PRELIMINARY PROGRAMME AND INVITATION - 4TH Joint European Networking Conference - Trondheim, Norway, May 10-13, 1993 "EUROPEAN RESEARCH NETWORKING IN A GLOBAL CONTEXT" Organized by RARE (Reseaux Associes pour la Recherche Europeenne) in cooperation with: o ACM SIGCOMM o EARN o EUnet/EurOpen o IFIP TC6 o Internet Architecture Board o Internet Society o NORDUnet o UNINETT ---------------- Preliminary Programme (version 1.2) Monday, May 10 01 14:00-15:00 Opening Session - Welcome Addresses - Keynote Address: Horst Huenke - CEC, Counsellor DG XIII-C 02 15:30-17:30 Building The European Research Network: Alternative Views - A number of speakers, involved with strategic and political aspects of international networking, will address the following question: "If you could build European Academic Networking from scratch - how would you do it?" Tuesday, May 11 03A 9:00-10:30 Design Cornerstones of the US National Research and Education Network (NREN) - NSFNet Evolution Plans / Jane Caviness - National Science Foundation, US - NREN Research Directions / Paul Mockapetris - DARPA, US - Using ATM/SONET for the Scientific Community / Tony Villasenor - NASA, US 03B 9:00-10:30 Lower Layer Protocols - The European CLNS Pilot / Victor Reijs - SURFnet, NL - Experiences with the DQDB-pilot at the Leibniz- Rechenzentrum (LRZ) in Munich / Victor Apostolescu - LRZ, Germany - XTP over ATM /Ingvild Sorteberg & Oivind Kure - Norwegian Telecom Research, Norway 03C 9:00-10:30 Working Group Session 04A 11:00-12:30 New European Infrastructure: A Status Report - The Operational Unit / Klaus Ullmann - Chairman OU Steering Ctee, DFN, Germany - EBONE / Frode Greisen - EBONE General Manager, UNI-C, Denmark - EUROPAnet - The implications of a multi-protocol backbone / Dai Davies - Director COSINE Project Management Unit, NL 04B 11:00-12:30 Security Services - Implementing and Proving Security Services for the RARE/COSINE Community / M. Purser & S. Barry - Baltimore Technologies, Ireland - Piloting Applications of Security Services / Peter Kirstein et al - University College London, UK - Piloting Security Services for German University Administrations / M. Pattloch et al - DFN, Germany 04C 11:00-12:30 Working Group Session 05A 14:00-15:30 Policy, Funding & Legal Issues - SuperJANET - The Gestation of a High Performance National Research Network / Bob Cooper - Joint Network Team, UK - EZ-REMOTE Service Benefits and Costs / Martyne M. Hallgren - Cornell University, US - Directory Services and Privacy Issues / Erik Huizer et al - SURFnet, NL 05B 14:00-15:30 Multimedia Services and Support - Service and Protocol Implications of Multimedia Support in BISDN / Flavio Bonomi et al - AT&T Bell Laboratories, US - Piloting of Multimedia Services / Peter Kirstein et al - UCL, UK - Using X.400 for Document Delivery / Bill Tuck - IT Research Consultant, UK 05C 14:00-15:30 Global Interconnection and Coordination - GIX - The Global Internet Exchange / Bernhard Stockman - Royal Institute of Technology, Sweden - The RIPE NCC: A Year of Experience with European Internet Coordination / Daniel Karrenberg et al - RIPE NCC, NL - Policy Routing and Type of Service Routing: What are the Users' Requirements and what can we provide them with?/ R. Najmabadi Kia & Bernard Sales - Universite Libre de Bruxelles, Belgium 06A 16:00-17:30 Support for the Development of User Communities - Reaching out to the End-user: Applications, Services and Support / Erik Huizer et al - SURFnet, NL - A Review of the Commercial Internet in Europe / Peter Dawe - PIPEX, UK 06B 16:00-17:30 Accessing and Using the Directory - X.500 for Non-Technical Users / T. Plagemann & B. Plattner - ETH Zurich, Switzerland - Information System using OSI Directory Service / Shigeki Yoshida - University of Tokyo, Japan - A Hierarchical Directory based X.400 MHS Server / Hossam Afifi - INRIA, France 06C 16:00-17:30 Working Group Session Wednesday, May 12 07A 14:00-15:30 New User Communities and Services - The UNINETT SAMSON project 1992 / Peter Hausken - University of Oslo, Norway - MUNIN - A System for Distance Education and Remote Collaboration based on Real Time Multimedia Communication over IP Networks / Geir Pedersen - University of Oslo, Norway - WAN to the Home: Data Communication over CATV Networks / Ton Verschuren - SURFnet, NL 07B 14:00-15:30 Using the Directory for Network Management - Mapping Communication Networks in the Directory / Glenn Mansfield et al - AIC Systems Laboratory, Japan - Large Scale Network Management Databases in X.500 / Peter Sylvester - INRIA, France - Accessing and Managing DNS Information in the X.500 Directory / Antonio Costa et al - Universidade do Minho, Portugal 07C 14:00-15:30 Working Group Session 08A 16:00-17:30 Network Operation and Management - The OSI based management approach to integration of management systems in multi-protocol LANs. A case study / M. Stroinski et al - Technical University Poznan, Poland - NLMP: an Architecture for the OSI Lower Layers Management / M. Colin & Bernard Sales - ULB, Belgium - Monitoring EARN Networking Services / Daniele Bovio & Gregory Lloyd - EARN, France 08B 16:00-17:30 Networks in Support of Mobility - Reaching Off-Campus and Mobile Users / Jim Morrison - Open University, UK - Comparison of Mobile Host Protocols for IP / Andrew Myles - Macquirie University, Australia - The Problem of Providing Continuous Network Access for Mobile Hosts Using the Internet Protocol (IP) / Charles E. Perkins - IBM, US 08C 16:00-17:30 Working Group Session Thursday, May 13 09A 9:00-10:30 Network Operation - OSI Packet Filtering Study / Walter Lazear - The Mitre Corp., US - Study of Network Dynamics / Dheeraj Sanghi et al - University of Maryland, US - A Fairness Analysis of LAN/WAN Protocol Relays / Edmundo Monteiro et al - Universidade do Coimbra, Portugal 09B 9:00-10:30 Quality of Service Definition and Measurement - Design and Utilization of a SNMP: Monitoring Language for X.400 Management / Jean-Francois Paccini et al - Universite de Geneve, Switzerland - COSINE MHS Performance Statistics - Service Measurements and Network Management of a Pan-European Messaging System / Jim Romaguera - NetConsult AG / COSINE MHS Project Team, Switzerland - TCP/IP Performance on Supernett / Olav Kvittem - SINTEF DELAB, Norway 10 11:00-12:30 Evolution of Existing Networks - IP Version 7 / Bob Hinden - Sun Microsystems Inc., US - SuperJanet: Applications / John Dyer - Joint Network Team, UK 11 12:30-12:45 Closing Session - Closing Address / Bernhard Plattner DEMONSTRATIONS At the Conference there will be a demonstration area where participants may visit a number of stands to see displays and demonstrations of various projects and applications of network services for the academic community. POSTER EXHIBITION During the conference, a poster wall will be available for the display of posters covering a topic of common interest to the participants. Participants are invited to submit a poster of one or two A-4 pages, presenting their project. Posters must be handed in at the reception desk not later than Monday May 10, in the evening. They must contain a clear indication of the author's name and affiliation. The Programme Committee will select the two best posters, taking into account the quality of the project, its presentation and the interest to the networking community. One author from each of the two selected projects will be offered free admission to next year's conference. WORKING GROUP SESSIONS Stream C in the conference programme will be dedicated to RARE Working Groups. During these sessions Working Groups will briefly introduce their current activities. Furthermore a number of presentations related to Working Group subjects will be presented. TUTORIALS This year for the first time tutorials will be organized. Tutorials will be held at the end of the Conference, on Thursday afternoon and Friday morning. The following tutorials are scheduled (in parallel): - Protocols for Distributed Computing over Gigabit Networks / David J. Farber - Univ. of Pennsylvania / Guru M. Parulkar - Washington Univ. in St. Louis, US. - X.400: its evolution until nowadays, and its current trends / Olivier Paridaens - Universite Libre de Bruxelles, Belgium. - SNMP Overview / Daniel Karrenberg - RIPE-NCC, Amsterdam, The Netherlands. - Managing TCP/IP Network under UNIX / Suleyman Kondakci - Centre for Information Technology, University of Oslo, Norway. - ISODE - The ISO Development Environment / Michael Mueller - Gesellschaft fuer Mathematik & Datenverarbeitung, St. Augustin, Germany. If you are interested to attend one of the tutorials please register as soon as possible. Please note that tutorials are not included in the conference programme and that a fee of NOK 1200 per tutorial has to be paid separately. VENUE The conference will be held at the main campus of the Norwegian Institute of Technology, which is located at about 15 minutes walking distance from the Trondheim city centre. Banks, post office, stores, restaurants and a travel agency are all located on the campus. In May in Trondheim the weather is usually pleasant. Temperature may vary between 8-15 degrees C. Rainy days may occur. GETTING TO TRONDHEIM Trondheim Airport has direct flights to Copenhagen and Stockholm and further connections to European and overseas destinations. There are frequent domestic flights between Trondheim and the international airports in Oslo, Bergen and Stavanger. Travelling by train within Norway gives an excellent opportunity for sightseeing, and Norwegian trains are of high standard. The train journey over the mountains from Oslo to Trondheim takes approx. 7 hours. An interesting alternative is to travel to Trondheim by coastal boat from Bergen, a journey of approximately 30 hours along the rugged Norwegian coastline. Your travel agent, or any SAS travel agency, can supply you with full details on travel to Trondheim. Special conference discount rates for travel by air within Scandinavia may be obtained. For more information, participants can contact Flyspesialisten Unit Travel Agency tel: +47 7 59 67 44 SOCIAL EVENTS FOR CONFERENCE ATTENDEES Concert and Reception - Monday, May 10, 19.00 You are invited to attend a concert in Nidaros cathedral. Following the concert, the Mayor of Trondheim invites you to a reception at the Archbishop's Residence, which dates back to the 12th Century. The Archbishop who lived there was Olav Engelbrektsson who was forced to flee from the city in 1537, but the charming and elegant residence has been preserved. - Free of charge Gala Dinner - Tuesday, May 11, 19.30 We invite you to try the very best of our regional cooking at the gala dinner. Traditional dishes using prime Norwegian salmon, trout, reindeer, hart and game will be served. During the dinner you will be able to enjoy the nice company of friends and colleagues, as well as some regional entertainment. - Participants: free of charge / accompanying persons: NOK 600 Hiking in Bymarka - Wednesday, May 12, 19.30 A natural wilderness within the city limits, Bymarka is a paradise for joggers, hikers and skiers. You and your fellow 'hikers', accompanied by a guide, will find trails for all levels of proficiency and then round off the evening with a meal at a mountain lodge. Transport both ways between town center and hiking area will be provided. - Charge: NOK 310 Munkholmen Island - Wednesday, May 12, 19.30 Seafood dinner will be served on the historic island of Munkholm, just outside Trondheim. Once a monastery, the island became a prison after the Reformation. Nowadays it is a popular bathing spot. - Charge: NOK 290 Post-Conference Tour - COASTAL HOLIDAY AT HAAHOLMEN - Thursday 13 May - Saturday 15 May Sheltered from the ocean among countless islands on the Northwest coast of Norway, approximately 5 hours by bus from Trondheim, lies the fishing village of Haaholmen. Haaholmen has both old and new fishermen's huts with modern conveniences for its guests. Staying in these real coastal surroundings you can enjoy life on the quay or join in fishing trips and excursions. Haaholmen is owned by Ragnar Thorseth from Her y in Norway - a modern Viking. Mr. Thorseth is internationally known for his round-the-world expedition in the Viking ship Saga Siglar. Originally, the island was owned by his grandfather. The fishing village Haaholmen has long traditions as a 'meeting point' for people travelling along the Northwest coast. The village is now re-created as a unique holiday paradise. Excellent kitchen naturally specializes in delicious seafood. At the quayside you can hire lots of different boats, such as rowing boats, motorboats and sailing boats as well as fishing equipment. Leaving Trondheim on Thursday 13 May at 15.00, we travel by coach to the town of Kristiansund. From here we go by boat along the coast to Haaholmen. Dinner will be served. On Friday we will explore the island of Bjoernsund, located on the South of Haaholmen. Dinner will be served on Haaholmen. We are leaving Haaholmen after breakfast on Saturday, and you will be back in Trondheim on Saturday afternoon. It is necessary to bring warm clothes, rainwear and good shoes/boots. Transport, accommodation, meals and guide service are all included in the price. - Charge: NOK 3800 per person ACCOMPANYING PERSONS PROGRAMME A special programme has been arranged for accompanying persons in addition to the general social programme. Accompanying persons are invited to attend the concert and reception on Monday, May 10, free of charge. All other social events, as well as the Gala Dinner, must be registered and paid for separately. Please indicate on the registration form which events you wish to attend. - Sightseeing in Trondheim - Monday, May 10, 10.00 This tour includes a guided bus trip in the city centre and residential areas, and a guided tour of Nidaros cathedral. Lunch will be served at the Tyholt Tower, a revolving restaurant with a magnificent view of the city. - Charge: NOK 340 - The mountain town of R ros - Tuesday May 11, 8.30 h. R ros is unique! This town is situated 160 km South-east of Trondheim and occupies with pride a place on UNESCO's World Heritage List. You would be forgiven for thinking you stepped back a few hundred years as you wander past the elegant wooden houses and tiny miner's cottages, and visit the eighteenth- century church which dominates this unspoilt mountain town. There will also be time for a visit to the mining museum. A rich variety of traditional Norwegian and Lappish handicrafts can be found in the many small studios in town. Lunch will be served. Travel by coach. - Charge: NOK 520 ACCOMMODATION Rooms have been reserved at several hotels in the centre of Trondheim. Prices vary from approx. NOK 495 - 875 for a single room with bath, including breakfast. If you wish to have a reservation made, please indicate the type of accommodation required on the registration form. Rooms will be allocated in order of receipt of the registration forms. The Secretariat will make the reservation for you at the hotel of your choice (as far as possible), and confirmation of your reservation will be sent to you in the middle of April. Hotel expenses are to be settled directly with the hotel upon departure. REGISTRATION The registration fee includes the full set of papers as they will be presented during the conference, a copy of the conference programme, a copy of the special issue of Computer Networks and ISDN Systems (to be published in October 1993) in which a selected numbers of papers will be published, entry to all sessions, refreshments daily, 3 lunches, the Concert on Monday, the Welcome Reception, and the Gala Dinner. Please note that accompanying persons are free to attend the Welcome Reception and the Concert and can book all other events, but they may not attend any of the technical sessions. Payment must be remitted in Norwegian Kroner - NOK, free from all bank charges. Cheques should be made payable to JENC'93 and should be sent to the Secretariat in Trondheim together with the registration form. Unfortunately we cannot accept credit cards or private cheques. EARLY Registration Fee 3000 NOK ca. 365 ECU LATE Registration Fee 3300 NOK ca. 400 ECU DESK Registration Fee 3600 NOK ca. 435 ECU The early registration fee applies to all fees received before March 29. The late registration fee applies to all payments received between April 1 and May 7. DESK registration is only possible together with payment. Two banks are located on the campus. In case of cancellation before April 31 all fees will be refunded, less a cancellation charge of NOK 500. NO REFUND of registration fees will be made for cancellation after this date. When sending Eurocheques, please note that the total amount of NOK 1300 per cheque may not be exceeded. Payment by bank transfer should be made to: JENC'93 bank account no 8601.10.34510 with Fokus Bank N-7034 Trondheim, Norway All payments should be marked properly with the name of the participant. Confirmation of registration, hotel accommodation etc. will be mailed to participants in the middle of April. Rooms will be allocated in order of receipt. Early registration is therefore recommended. Cancellation terms for the post-conference tour: There will be no fee for cancellations of the post-conference tour if received before 10 April. Fees will not be refunded after this date. If tours must be cancelled by the operator due to lack of interest, payment will be refunded, less a transfer/swift charge. ------------------------------------- REGISTRATION FORM - J E N C '9 3 The enclosed registration form should be completed and returned to the Secretariat to reach Trondheim preferably before 29 March 1993. Registration by e-mail is also possible. Please submit your payment in Norwegian kroner (NOK). Conference Secretariat JENC'93 SEVU, Congress Department The Norwegian Institute of Technology N-7034 Trondheim, Norway Tel: +47 7 59 56 69 Fax: +47 7 51 72 26 E-mail: jenc93(a)sevu.unit.no PLEASE TYPE OR PRINT CLEARLY Surname: First name: Title: University/institute/firm: Office address: Country: Tel: Fax: E-mail: Accompanying person(s) Surname: First name: HOTEL ACCOMMODATION Price Category I: O Single w/bath NOK 795 - 875 O Double w/bath NOK 945 - 1055 Price Category II O Single w/bath NOK 690 - 700 O Double w/bath NOK 790 - 800 Price Category III O Single w/bath NOK 495 - 595 O Double w/bath NOK 595 - 695 No. of persons: Arrival date: Departure date: Due to recent government regulations, all prices may be subject to change. All prices per room per day, including breakfast. Account to be settled directly with the hotel upon departure. ------------------------------------ PAYMENT AND REGISTRATION Please mark as appropriate and include payment. No. Total NOK O EARLY Registration fee NOK 3000 .. ...... O LATE Registration fee NOK 3300 .. ...... O Concert & Reception Inclusive O Gala Dinner Dinner Inclusive O Gala Dinner for Accomp. Pers.NOK 600 .. ...... O Hiking in Bymarka NOK 310 .. ...... O Munkholmen Island NOK 290 .. ...... O Sightseeing in Trondheim NOK 340 .. ...... O Mountain town of Roros NOK 520 .. ...... O Post-Conference Tour NOK 3800 .. ...... I wish to attend one of the following tutorials: O Protocols for Distributed Computing over Gigabit Networks / David J. Farber/ Guru M. Parulkar NOK 1200 ...... O X.400 : its evolution until nowadays, and its current trends / Olivier Paridaens NOK 1200 ...... O SNMP Overview / Daniel Karrenberg NOK 1200 ...... O Managing TCP/IP Network Under UNIX /Suleyman Kondakci NOK 1200 ...... O ISODE - The ISO Development Environment / Michael Mueller NOK 1200 ...... TOTAL NOK ...... Payment: O Cheque enclosed O Payment made to bank account No. 8601.10.34510 (copy of bank transfer enclosed) Date: Signature:

1 0

IPv7 - Summary of Current Proposals
by dixon＠rare.nl 28 Jan '93

28 Jan '93

The attached document is distributed as promised during RIPE Meeting 14. Tim RTC(93)004 18th January 1993 Tim Dixon COMPARISON OF PROPOSALS FOR IP VERSION 7 The following is a brief summary of the characteristics of the three main proposals for replacing the current Internet Protocol. It is not intended to be exhaustive or definitive (a brief bibliography at the end points to sources of more information), but to serve as input to the European discussions on these proposals, to be co-ordinated by RARE and RIPE. It should be recognised that the proposals are themselves "moving targets", and in so far as this paper is accurate at all, it reflects the position at the 25th IETF meeting in Washington, DC. Comments from Ross Callon and Paul Tsuchiya on the original draft have been incorporated. The paper begins with a "generic" discussion of the mechanisms for solving problems and achieving particular goals, before discussing the proposals invidually. 1. WHY IS THE CURRENT IP INADEQUATE? The problem has been investigated and formulated by the ROAD group, but briefly reduces to the following: - Exhaustion of IP Class B Address Space - Exhaustion of IP Address Space in General - Non-hierarchical nature of address allocation leading to flat routing space Although the IESG requirements for a new Internet Protocol go further than simply routing and addressing issues, it is these issues that make extension of the current protocol an impractical option. Consequently, most of the discussion and development of the various proposed protocols has concentrated on these specific problems. Near term remedies for these problems include the CIDR proposals (which permit the aggregation of Class C networks for routing purposes) and assignment policies which will allocate Class C network numbers in a fashion which CIDR can take advantage of. Routing protocols supporting CIDR are OSPF and BGP4. None of these are pre-requisites for the new IP (IPv7), but are necessary to prolong the life of the current Internet long enough to work on longer-term solutions. Ross Callon points out that there are other options for prolonging the life of IP and that some ideas have been distributed on the TUBA list. Longer term proposals are being sought which ultimately allow for further growth of the Internet. The timescale for considering these proposals is as follows: - Dec 15 Issue selection criteria as RFC - Feb 12 Two interoperable implementations available - Feb 26 Second draft of proposal documents available The (ambitious) target is for a decision to be made at the 26th IETF (Columbus, Ohio in March 1993) on which proposals to pursue. The current likely candidates for selection are: - PIP ('P' Internet Protocol - an entirely new protocol - TUBA (TCP/UDP with Big Addresses - uses ISO CLNP) - SIP (Simple IP - IP with larger addresses and fewer options) There is a further proposal from Robert Ullman of which I don't claim to have much knowledge. Associated with each of the candidates are transition plans, but these are largely independent of the protocol itself and contain elements which could be adopted separately, even with IP v4, to further extend the life of current implementations and systems. 2. WHAT THE PROPOSALS HAVE IN COMMON 2.1 Larger Addresses All the proposals (of course) make provision for larger address fields which not only increase the number of addressable systems, but also permit the hierarchical allocation of addresses to facilitate route aggregation. 2.2 Philosophy The proposals also originate from a "routing implementation" view of the world - that is to say they focus on the internals of routing within the network and do not primarily look at the network service seen by the end-user, or by applications. This is perhaps inevitable, especially given the tight time constraints for producing interoperable implementations. However, the (few) representatives of real users at the 25th IETF, the people whose support is ultimately necessary to deploy new host implementations, were distinctly unhappy. There is an inbuilt assumption in the proposals that IPv7 is intended to be a universal protocol: that is, that the same network-layer protocol will be used between hosts on the same LAN, between hosts and routers, between routers in the same domain, and between routers in different domains. There are some advantages in defining separate "access" and "long-haul" protocols, and this is not precluded by the requirements. However, despite the few opportunities for major change of this sort within the Internet, the need for speed of development and low risk have led to the proposals being incremental, rather than radical, changes to well-proven existing technology. There is a further unstated assumption that the architecture is targeted at the singly-connected host. It is currently difficult to design IPv4 networks which permit hosts with more than one interface to benefit from increased bandwidth and reliability compared with singly-connected hosts (a consequence of the address belonging to the interface and not the host). It would be preferable if topological constraints such as these were documented. It has been asserted that this is not necessarily a constraint of either the PIP or TUBA proposals, but I believe it is an issue that has not emerged so far amongst the comparative criteria. 2.3 Source Routing The existing IPv4 has provision for source-specified routes, though this is little used [would someone like to contradict me here?], partly because it requires knowledge of the internal structure of the network down to the router level. Source routes are usually required by users when there are policy requirements which make it preferable or imperative that traffic between a source and destination should pass through particular administrative domains. Source routes can also be used by routers within administrative domains to route via particular logical topologies. Source-specified routing requires a number of distinct components: a. The specification by the source of the policy by which the route should be selected b. The selection of a route appropriate to the policy c. Marking traffic with the identified route d. Routing marked traffic accordingly These steps are not wholly independent. The way in which routes are identified in step (c) may constrain the kinds of route which can be selected in previous steps. The destination, inevitably, participates in the specification of source routes either by advertising the policies it is prepared to accept or, conceivably, by a negotiation process. All of the proposals mark source routes by adding a chain of (perhaps partially-specified) intermediate addresses to each packet. None specifies the process by which a host might acquire the information needed to specify these intermediate addresses [not entirely unreasonably at this stage, but further information is expected]. The negative consequences of these decisions are: - Packet headers can become quite long, depending on the number of intermediate addresses that must be specified (although there are mechanisms which are currently specified or which can be imagined to specify only the significant portions of intermediate addresses) - The source route may have to be re-specified periodically if particular intermediate addresses are no longer reachable The positive consequences are: - Inter-domain routers do not have to understand policies, they simply have to mechanically follow the source route - Routers do not have to store context identifying routes, since the information is specified in each packet header - Route servers can be located anywhere in the network, provided the hosts know how to find them. 2.4 Encapsulation Encapsulation is the ability to enclose a network-layer packet within another one so that the actual packet can be directed via a path it would not otherwise take to a router that can remove the outermost packet and direct the resultant packet to its destination. Encapsulation requires: a. An indication in the packet that it contains another packet b. A function in routers which, on receiving such a packet, removes the encapsulation and re-enters the forwarding process All the proposals support encapsulation. Note that it is possible to achieve the effect of source routing by suitable encapsulation by the source. 2.5 Multicast The specification of addresses to permit multicast with various scopes can be accomodated by all the proposals. Internet-wide multicast is, of course, for further study! 2.6 Fragmentation All the proposals support the fragmentation of packets by intermediate routers, though there has been some recent discussion of removing this mechanism from some of the proposals and requiring the use of an MTU-discovery process to avoid the need for fragmentation. Such a decision would effectively preclude the use of transport protocols which use message-count sequence numbering (such as OSI Transport) over the network, as only protocols with byte-count acknowledgement (such as TCP) can deal with MTU reductions during the lifetime of a connection. OSI Transport may not be particularly relevant to the IP community (though it may be of relevance to commercial suppliers providing multiprotocol services), however the consequences for the types of services which may be supported over IPv7 should be noted. 2.7 The End of Lifetime as We Know It The old IPv4 "Time to Live" field has been recast in every case as a simple hop count, largely on grounds of implementation convenience. Although the old TTL was largely implemented in this fashion anyway, it did serve an architectural purpose in putting an upper bound on the lifetime of a packet in the network. If this field is recast as a hop-count, there must be some other specification of the maximum lifetime of a packet in the network so that a source host can ensure that network-layer fragment ids and transport-layer sequence numbers are never in danger of re-use whilst there is a danger of confusion. There are, in fact, three separate issues here: 1 Terminating routing loops (solved by hop count) 2 Bounding lifetime of network-layer packets (a necessity, unspecified so far) to support assumptions by the transport layer 3 Permitting the source to place further restrictions on packet lifetime (for example so that "old" real-time traffic can be discarded in favour of new traffic in the case of congestion (an optional feature, unspecified so far) 3. WHAT THE PROPOSALS ONLY HINT AT 3.1 Resource Reservation Increasingly, applications require a certain bandwidth or transit delay if they are to be at all useful (for example, real-time video and audio transport). Such applications need procedures to indicate their requirements to the network and to have the required resources reserved. This process is in some ways analogous to the selection of a source route: a. The specification by the source of its requirements b. The confirmation that the requirements can be met c. Marking traffic with the requirement d. Routing marked traffic accordingly Traffic which is routed according to the same set of resource requirements is sometimes called a "flow". The identification of flows requires a setup process, and it is tempting to suppose that the same process might also be used to set up source routes, however, there are a number of differences: - All the routers on a path must participate in resource reservation and agree to it - Consequently, it is relatively straightforward to maintain context in each router and the identification for flows can be short - The network can choose to reroute on failure By various means, each proposal could carry flow-identification, though this is very much "for future study" at present. No setup mechansisms are defined. The process for actually reserving the resources is a higher-order problem. The interaction between source-routing and resource reservation needs further investigation: although the two are distinct and have different implementation constraints, the consequence of having two different mechanisms could be that it becomes difficult to select routes which meet both policy and performance goals. 3.2 Address-Assignment Policies In IPv4, addresses were bound to systems on a long-term basis and in many cases could be used interchangeably with DNS names. It is tacitly accepted that the association of an address with a particular system may be more volatile in IPv7. Indeed, one of the proposals, PIP, makes a distinction between the identification of a system (a fixed quantity) and its address, and permits the binding to be altered on the fly. None of the proposals defines bounds for the lifetime of addresses, and the manner in which addresses are assigned is not necessarily bound to a particular proposal. For example, within the larger address space to be provided by IPv7, there is a choice to be made of assigning the "higher order" part of the hierarchical address in a geographically-related fashion or by reference to service provider. Geographically-based addresses can be constant and easy to assign, but represent a renewed danger of degeneration to "flat" addresses within the region of assignment, unless certain topological restrictions are assumed. Provider-based address assignment results in a change of address (if providers are changed) or multiple addresses (if multiple providers are used). Mobile hosts (depending on the underlying technology) can present problems in both geographic and provider-based schemes. Without firm proposals for address-assignment schemes and the consequences for likely address lifetimes, it is impossible to assume that the existing DNS model by which name-to-address bindings can be discovered remains valid. Note that their in an interaction between the mechanism for assignment of addresses and way in which automatic configuration may be deployed. 3.3 Automatic Configuration Amongst the biggest (user) bugbears of current IP services is the administrative effort of maintaining basic configuration information, such as assigning names and addresses to hosts, ensuring these are refelected in the DNS, and keeping this information correct. Part of this results from poor implementation (or the blind belief that vi and awk are network management tools). However, a lot of the problems could be alleviated by making this process more automatic. Some of the possibilities (some mutually-exlusive) are: - Assigning host addresses from some (relative) invariant, such as a LAN address - Defining a protocol for dynamic assignment of addresses within a subnetwork - Defining "generic addresses" by which hosts can without preconfiguration reach necessary local servers (DNS, route servers, etc). - Have hosts determine their name by DNS lookup - Have hosts update their name/address bindings when their configuration changes Whilst a number of the proposals make mention of some of these possibilities, the choice of appropriate solutions depends to some extent on address-assignment policies. Also, dynamic configuration results in some difficult philosopical and practical issues (what exactly is the role of an address?, In what sense is a host "the same host" when its address changes?, How do you handle dynamic changes to DNS mappings and how do you authenticate them?). The groups involved in the proposals would, I think, see most of these questions outside their scope. It would seem to be a failure in the process of defining and selecting candidates for IPv7 that "systemness" issues like these will probably not be much discussed. This is recognised by the participants, and it is likely that, even when a decision is made, some of these ideas will be revisited by a wider audience. It is, however, unlikely that IP will make an impact on proprietary networking systems for the non-technical environment (e.g. Netware, Appletalk), without automatic configuration being taken seriously either in the architecture, or by suppliers. I believe that there are ideas on people's heads of how to address these issues - they simply have not made it onto paper yet. 3.4 Application Interface/Application Protocol Changes A number of common application protocols (FTP, RPC etc) have been identified which specifically transfer 32-bit IPv4 addresses, and there are doubtless others, both standard and proprietary. There are also many applications which treat IPv4 addresses as simple 32-bit integers. Even applications which use BSD sockets and try to handle addresses opaquely will not understand how to parse or print longer addresses (even if the socket structure is big enough to accommodate them). Each proposal, therefore, needs to specify mechanisms to permit existing applications and interfaces to operate in the new environment whilst conversion takes place. It would be useful also, to have (one) specification of a reference programming interface for (TCP and) IPv7 (which would also operate on IPv4), to allow developers to begin changing applications now. All the proposals specify transition mechansisms from which existing application-compatibility can be inferred. There is no sign yet of a new interface specification independent of chosen protocol. 3.5 DNS Changes It is obvious that there has to be a name to address mapping service which supports the new, longer, addresses. All the proposals assume that this service will be provided by DNS, with some suitably-defined new resource record. There is some discussion ongoing about the appropriateness of returning this information along with "A" record information in response to certain enquiries, and which information should be requested first. There is a potential tradeoff between the number of queries needed to establish the correct address to use and the potential for breaking existing implementations by returning information that they do not expect. There has been heat, but not light, generated by discussion of the use of DNS for auto-configuration and the scaling (or otherwise) of reverse translations for certain addressing schemes. 4. WHAT THE PROPOSALS DON'T REALLY MENTION 4.1 Congestion Avoidance IPv4 offers "Source Quench" control messages which may be used by routers to indicate to a source that it is congested and has or may shortly drop packets. TUBA/PIP have a "congestion encountered" bit which provides similar information to the destination. None of these specifications offers detailed instructions on how to use these facilities. However, there has been a substantial body of analysis over recent years that suggests that such facilities can be used (by providing information to the transport protocol) not only to signal congestion, but also to minimise delay through the network layer. Each proposal can offer some form of congestion signalling, but none specifies a mechanism for its use (or an analysis of whether the mechanism is in fact useful). As a user of a network service which currently has a discard rate of around 30% and a round-trip-time of up to 2 seconds for a distance of only 500 miles I would be most interested in some proposals for a more graceful degradation of the network service under excess load. 4.2 Mobile Hosts A characteristic of mobile hosts is that they (relatively) rapidly move their physical location and point of attachment to the network topology. This obviously has signficance for addressing (whether geographical or topological) and routing. There seems to be an understanding of the problem, but so far no detailed specification of a solution. 4.3 Accounting The IESG selection criteria require only that proposals do not have the effect of preventing the collection of information that may be of interest for audit or billing purposes. Consequently, none of the proposals consider potential accounting mechanisms. 4.4 Security "Network Layer Security Issues are For Further Study". Or secret. However, it would be useful to have it demonstrated that each candidate could be extended to provide a level of security, for example against address-spoofing. This will be particularly important if resource-allocation features will permit certain hosts to claim large chunks of available bandwidth for specialised applications. Note that providing some level of security implies manual configuration of security information within the network and must be considered in relationship to auto-configuration goals. 5. WHAT MAKES THE PROPOSALS DIFFERENT? Each proposal is about as different to the others as it is to IPv4 - that is the differences are small in principle, but may have significant effects (extending the size of addresses is only a small difference in principle!). The main distinct characteristics are: PIP: PIP has an innovative header format that facilitates hierarchical, policy and virtual-circuit routing. It also has "opaque" fields in the header whose semantics can be defined differently in different administrative domains and whose use and translation can be negotiated across domain boundaries. No control protocol is yet specified. SIP: SIP offers a "minimalist" approach - removing all little-used fields from the IPv4 header and extending the size of addresses to (only) 64 bits. The control protocol is based on modifications to ICMP. This proposal has the advantages of processing efficiency and familiarity. TUBA: TUBA is based on CLNP (ISO 8473) and the ES-IS (ISO 9542) control protocol. TUBA provides for the operation of TCP transport and UDP over a CLNP network. The main arguments in favour of TUBA are that routers already exist which can handle the network-layer protocol, that the extensible addresses offer a wide margin of "future-proofing" and that there is an opportunity for convergence of standards and products. 5.1 PIP PIP packet headers contain a set of instructions to the router's forwarding processor to perform certain actions on the packet. In traditional protocols, the contents of certain fields imply certain actions; PIP gives the source the flexibility to write small "programs" which direct the routing of packets through the network. PIP addresses have an effectively unlimited length: each level in the topological hierarchy of the network contributes part of the address and addresses change as the network topology changes. In a completely hierarchical network topology, the amount of routing information required at each level could be very small. However, in practice, levels of hierarchy will be determined more by commercial and practical factors than by the constraints of any particular routing protocol. A greater advantage is that higher-order parts of the address may be omitted in local exchanges and that lower-order parts may be omitted in source routes, reducing the amount of topological information that host systems are required to know. There is an assumption that PIP addresses are liable to change, so a further quantity, the PIP ID, is assigned to systems for the purposes of identification. It isn't clear that this quantity has any purpose which could not equally be served by a DNS name [it is more compact, but equally it does not need to be carried in every packet and requires an additional lookup]. However, the problem does arise of how two potentially-communicating host systems find the correct addresses to use. The most complex part of PIP is that the meaning of some of the header fields is determined by mutual agreement within a particular domain. The semantics of specific processing facilities (for example, queuing priority) are registered globally, but the actual use and encoding of requests for these facilities in the packet header can be different in different domains. Border routers between two domains which use different encodings must map from one encoding to another. Since routers may not only be adjacent physically to other domains, but also via "tunnels", the number of different encoding rules a router may need to understand is potentially quite large. Although there is a saving in header space by using such a scheme as opposed to the more familiar "options", the cost in the complexity of negotiating the use and encoding of these facilities, together with re-coding the packets at each domain border, is a subject of some concern. Although it may be possible for hosts to "precompile" the encoding rules for their local domain, there are many potential implementaion difficulties. Although PIP offers the most flexibility of the three proposals, more work needs to be done on "likely use" scenarios which make the potential advantages and disadvantages more concrete. 5.2 SIP SIP is simply IP with larger addresses and fewer options. Its main advantage is that it is even simpler that IPv4 to process. Its main disadvantages are: - It is far from clear that, if 32 bits of address are insufficient, 64 will be enough for the forseeable future; - although there are a few "reserved" bits in the header, the extension of SIP to support new features is not obvious. There's really very little else to say! 5.3 TUBA The characteristics of ISO CLNS are reasonably well known: the protocol bears a strong cultural resemblance to IPv4, though with 20-byte network-layer addressing. Apart from a spurious "Not Invented Here" prejudice, the main argument againt TUBA is that it is rather too like IPv4, offering nothing other than larger, more flexible, addresses. There is proof-by-example that routers are capable of handling the (very) long addresses efficiently, rather less that the longer headers do not adversely impact network bandwidth. There are a number of objections to the proposed control protocol (ISO 9542): - My early experience is that the process by which routers discover hosts is inefficient and resource consuming for routers - and requires quite fine timer resolution on hosts - if large LANs are to be accomodated reasonably. Proponents of TUBA suggest that recent experience suggests that ARP is no better, but I think this issue needs examination. - The "redirect" mechanism is based on (effectively) LAN addreses and not network addresses, meaning that local routers can only "hand-off" complex routing decisions to other routers on the same LAN. Equally, redirection schemes (such as that of IPv4) which redirect to network addresses can result in unnecessary extra hops. Analysis of which solution is better is rather dependent on the scenarios which are constructed. To be fair, however, the part of the protocol which provides for router-discovery provides a mechanism, absent from other proposals, by which hosts can locate nearby gateways and potentially automatically configure their addresses. 6. Transition Plans It should be obvious that a transition which permits "old" hosts to talk to "new" hosts requires: Either: (a) That IPv7 hosts can also use IPv4 or (b) There is translation by an intermediate system and either: (c) The infrastructure between systems is capable of carrying both IPv7 and IPv4 or (d) Tunneling or translation is used to carry one protocol within another in parts of the network The transition plans espoused by the various proposals are simply different combinations of the above. Experience would tend to show that all these things will in fact happen, regardless of which protocol is chosen. One problem of the tunneling/translation process is that there is additional information (the extra address parts) which must be carried across IPv4 tunnels in the network. This can either be carried by adding an extra "header" to the data before encapsulation in the IPv4 packet, or by encoding the information as new IPv4 option types. In the former case, it may be difficult to map error messages correctly, since the original packet is truncated before return; in the latter case there is a danger of the packet being discarded (IPv4 options are not self-describing and new ones may not pass through IPv4 routers). There is thus the possibility of having to introduce a "new" version of IPv4 in order to support IPv7 tunneling. The alternative (in which IPv7 hosts have two stacks and the infrastructure may or may not support IPv7 or IPv4) of course requires a mechanism for resolving which protocols to try. 7. Random Comments This is the first fundamental change in the Internet protocols that has occurred since the Internet was manageable as an entity and its development was tied to US government contracts. It was perhaps inevitable that the IETF/IESG/IAB structure would not have evolved to manage a change of this magnitude and it is to be hoped that the new structures that are proposed will be more successful in promoting a (useful) consensus. It is interesting to see that many of the perceived problems of the OSI process (slow progress, factional infighting over trivia, convergence on the lowest-common denominator solution, lack of consideration for the end-user) are in danger of attaching themselves to IPv7 and it will be interesting to see to what extent these difficulties are an inevitable consequence of wide representation and participation in network design. It could be regarded either as a sign of success or failure of the competitive process for the selection of IPv7 that the three main proposals have few really significant differences. In this respect, the result of the selection process is not of particular significance, but the process itself is perhaps necessary to repair the social and technical cohesion of the Internet Engineering process. 8. Further Information The main discussion lists for the proposals listed are: TUBA: tuba(a)lanl.gov PIP: pip(a)thumper.bellcore.com SIP: sip(a)caldera.usc.edu General: big-internet(a)munnari.oz.au (Requests to: <list name>-request@<host>) Internet Drafts and RFCs for the various proposals can be found in the usual places: Callon, R. TCP and UDP with Bigger Addresses (TUBA), A Simple Proposal for Internet Addressing and Routing rfc/rfc1347.txt Piscitello, D. Use of ISO CLNP in TUBA Environments internet-drafts/draft-piscitello-clnp-00.txt Callon, R. Addressing and End Point Identification, For Use with TUBA internet-drafts/draft-ietf-tuba-address-00.txt, .ps Tsuchiya, P. Pip: The `P' Internet Protocol internet-drafts/draft-tsuchiya-pip-00.txt Tsuchiya, P. Pip Overview and Examples internet-drafts/draft-tsuchiya-pip-overview-01.txt Tsuchiya, P. Pip Header Processing internet-drafts/draft-ietf-pip-processing-00.txt Tsuchiya, P. Pip Objects internet-drafts/draft-ietf-pip-objects-00.txt Tsuchiya, P. Pip Identifiers internet-drafts/draft-ietf-pip-identifiers-00.txt Deering, S. A Simple Internet Protocol parcftp.xerox.com:pub/net-research/sip-spec

1 0

Traffic measurements....
by Torben Noerup Nielsen 24 Jan '93

24 Jan '93

Regrettably, I cannot be in Prague. However, I do owe people an update on what's happened to my traffic measurement project. There has been several problems. One is legality; it's not entirely clear that it's lergal to collect data with the granularity I'm interested in. I have discussed this with various people and I have been unable to get a definite answer. While the user data can be removed and still leave something useful, that may not be enough. It may be necessary to scramble the source/destination addresses completely in order to avoid potential privacy violations. Another problem is that the person I had working on the project resigned and went elsewhere. This caused me a major operational problem and I do not yet know what I can do about it. I do not have the staff to continue the operation right now and it is not clear if and when I will. We - like a number of other groups - are being subjected to budget reductions and staff re-allocation and although we will likely get the position re-filled, it may also be re- programmed :-( What I am left with now is a large stack of CD-ROM's with an enormous amount of data on them. Around six months! The data itself is in good order, but I do not have the analysis programs written. I have tried to make sure that the data itself is saved so that it can be used if I can find the necessary labor to do the job. If anyone is willing to work on getting the necessary analysis programs written, I am willing - subject to agreement to preserve privacy - to make available the data. I trust you will all have a productive meeting. Regards, Torben

1 0

Re: PLEASE READ - Prague info.
by epg＠merit.edu 23 Jan '93

23 Jan '93

Anne, Is it too late to get tickets for the opera? I'd really love to go. See you in Prague. --Elise

1 0