IETF STEERING GROUP (IESG) REPORT FROM THE TELECONFERENCE April 2nd, 1992 Reported by: Greg Vaudreuil, IESG Secretary This report contains - Meeting Agenda - Meeting Attendees - Meeting Notes Please contact IESG Secretary Greg Vaudreuil for more information. ATTENDEES --------- Almquist, Philip / Consultant Borman, David / Cray Research Chiappa, Noel Crocker, Dave / TBO Coya, Steve / CNRI Davin, Chuck / MIT Gross, Philip / ANS Hinden, Robert / BBN Hobby, Russ / UC-DAVIS Piscitello, Dave/ Bellcore Stockman, Bernard / SUNET/NORDUnet Vaudreuil, Greg / CNRI Regrets Crocker, Steve / TIS Estrada, Susan / CERFnet Huizer, Erik / SURFnet Reynolds, Joyce / ISI AGENDA ------ This teleconference was designated as a single topic conference to discuss and craft a plan for implementing an IETF Routing and Addressing development strategy. MINUTES ------- The meeting began with a review of the timeframe the various solutions to the Routing and Addressing problems will be needed. For the ROAD effort, Phill Gross (and others) had investigated the growth rate of various Internet metrics, such as networks in the Merit Policy Routing Database, Assignement of IP network numbers, AS numbers, hosts, and DNS names. He was unable to send the detailed graphs, but did describe the growth trends. Based on the NSFnet Routing Database, the following timeframes were estimated: Class B Address exhaustion: ~ 2 Years ~30,000 configured Routes: ~ 2.5 Years IP address exhaustion: ~ 5 Years The rate of growth of the class B addresses in the Merit database appears to be slowing. It is not clear how this relates to the rate of address assignment. There is some indication that number of unconnected networks is rising. At this point the following amount of the address space is used. Assigned Available Class A 50 128 Class b 7,500 16,384 Class C 30,000 2,097,152 The IESG discussed two of the sort term addressing proposals in terms of their time to deployment and useful life. C Sharp The C Sharp (C#) proposal calls for grouping the remaining C address space into a new class of networks with a larger host space This aggregation will not require hosts to recognize a change in class C addresses. No mask is necessary for a host to differentiate between the host and network portion of an address. Changes will be required to routers to recognize the new class of addresses. These changes are seen as a minor extensions to the current "classful" environment, and are seen as easy to add to current router software. This proposal does not provide for, nor does it prevent the aggregation of routing information and as such makes no improvement in the routing table size. C# "costs" a bit and reduces the effective number of class "C" networks by half. Classless Interdomain Routing (CIDR) The CIDR proposal calls for the elimination of the address class concept. By adding network address masks to interdomain routing protocols, networks can be assigned and aggregated efficiently to reduce the routing table size in transit network routers. This proposal allows both the aggregation of Class C networks into larger more useful networks and the splitting of class A networks into smaller, less wasteful networks. Because CIDR addresses require a address mask to understand which portions of an address are significant, it may either require changes to hosts to enable them to recognize address masks, or require careful engineering of network number assignment such that old-style hosts interpreting addresses as "classfull" won't get confused. The interpretation of the all 1's network broadcast is one such case. If CIDR is used solely for aggregation of existing classes of networks, no changes will be required for hosts. This reduces the utility of CIDR significantly in that Class "A" and Class "B" networks cannot be broken into smaller chunks. If not applied to Class "B" addresses CIDR will not help extend the life of the nearly exhausted Class "B" addresses. The Questions C# and CIDR are not exclusive. Both can be implemented simultaneously. The decision point lies in the timeframe the solution is expected to be used. If aggregation is needed in the immediate short term, there is no choice but CIDR Supernetting. A small survey of router vendors seems to indicate that current products with memory additions will handle up to 16,000 routes. In the near future, it is likely routers will be able to handle 35,000. Does this "more thrust" buy enough time to pursue the "long term" solution without requiring subnetting of Class A and B Via CIDR? How long will it take to implement and deploy the "real" solution, and will either c# and/or the CIDR supernetting last until then? ACTION: Gross, Chiappa -- Further investigate the anticipated capabilities of current and next generation routers with respect to routing table size. The IESG discussed available mechanisms and what problems they addressed. Solutions Matrix | Rout | Class B | IP Exhaustion -------------+---------+---------+------------- C-Sharp | | x | -------------+---------+---------+------------- CIDR | x | x | -------------+---------+---------+------------- More Thrust | x | | -------------+---------+---------+------------- Recycling | | x | -------------+---------+---------+------------- IP encaps x | x | x -------------+---------+---------+------------- ISO encaps | x | x | x -------------+---------+---------+------------- Simple CLNP | x | x | x -------------+---------+---------+------------- Expected Timeframes | : : : More Thrust |@@@@@ : : : | : : : Recycling |@@@@ : : : | : : : Class C-Sharp | @@@@@: : : | : : : CIDR | @@@@@@@@@@@@@@@@ : : | : : : IP Encaps | @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ : | : : : Simple CLNP | : @@@@@@@@@@@@@@@@@@@@@@@@@@@@ | : : : CLNP Encaps | : @@@@@@@@@@@@@@@@@@@@@@ | : : : +-------+---------------+---------------+----------- Time Class B IP Need Exhaustion Exhaustion 10**9 nets Work Plan There are currently several efforts at extending protocols for CIDR Supernetting underway. BGP version 4 is being defined in the BGP working group. Dual IDRP is being developed, and Interdomain Policy Routing is defined to support classless routing. The IESG encourages this work to continue. IP encapsulation, ISO encapsulation (one method of implementing CNAT), and CIDR all require that IP addresses be assigned in "blocks" to facilitate aggregation. The IESG recognized that each of these approaches required an IP addressing plan that supported aggregation. At least the following need to be part of developing an IP addressing plan: the IETF Internet Area, IETF Routing Area, IETF Operational Requirements, FEPG, and IEPG. Action: Gross -- Develop a plan for coordinating the development of an address assignment strategy. Work with Chiappa, Almquist, and Hinden in establishing the appropriate liaison. The IESG did not recommend between CIDR and C# for sort term address extensions at this meeting. However, there was a strong feeling that activities needed to begin immediately, and that the IESG needed to make recommendations on a work plan soon. The IESG asked Philip Almquist to draft a strawman recommended work plan for IESG to consider as its position. ACTION: Almquist -- Using the work of the ROAD working group, and the minutes of this meeting, draft a position for IESG review. The IESG did not have adequate information to discuss the three long term proposals, IP encapsulation, ISO encapsulation (CNAT), and Simple CLNP.