Network Working Group F. Solensky INTERNET-DRAFT F. Kastenholz Clearpoint Research Corp. March 1992 A Revision to IP Address Classifications Status of this Memo This Internet Draft document will be submitted to the RFC editor as a standards document. Comments and suggestions are welcome and may be sent to the Big-Internet@munnari.oz.au mailing list. Distribution of this memo is unlimited. Abstract This memo presents an extension to the method of classifying and assigning IP network numbers. It is intended to provide a work- around to the imminent exhaustion of assignable Class B network numbers (and, to a lesser extent, the recent growth of routes that need to be tracked in the NSFNet routing database) by defining the format of Class C-sharp (C#) IP addresses, consuming the upper half of the existing Class C numbering space. The manner in which these changes impact existing systems is also discussed. It is a product of a "birds-of-a-feather" (BoF) discussion held on July 31, 1991 at the twenty-first IETF conference in Atlanta, GA and subsequent discussions on the mailing list. It should be noted that this document does NOT solve the limitations inherent in the current routing architectures and technology that are discussed in [1], [2] and [4]. These must wait until new architectures are developed. Specifically, the issue of scaling the size of future routing tables is only indirectly addressed. Background During the latter part of the 1980's, an ever-increasing number of organizations came to realize the advantage and importance of allowing their computer systems to interconnect with other systems and networks around the globe. This has both caused and reinforced the tremendous growth in the size of the Internet during this period. While this is usually seen as a positive trend, it has not been without its drawbacks. One of the more immediate problems that this sudden growth has presented is a continuing heavy demand for Class B network numbers. Solensky, Kastenholz [Page 1] INTERNET DRAFT March, 1992 Of the three classes of IP network numbers, Class A (which can support up to 16,777,214 unique host identifier addresses within the same network number), B (up to 65,532), and C (up to 254), the Class B network numbers are being assigned at the highest rate. While there are still a very large number of Class C network numbers available, few moderate-sized organizations expect that their connectivity needs will be satisfied within the limitations of 254 IP addresses, particularly if subnetting is being used. The level of demand for Class B address assignments can be illustrated by a short analysis of the data available. In the period between July 1990 and January 1992, the number of assigned Class B network numbers grew from 2533 to 6883 [5,10]; the latter figure representing just over 42% of the total available Class B network numbers. This increase averages out to an annual growth rate of over 73.7%. If this exponential trend were to continue, the pool of available Class B network numbers would be depleted by March 1993. While the authors acknowledge that a logistic or "s-shaped" curve would be a more realistic model, a projection based on this assumption would not be realistic until we have clearly passed the inflection point on the curve - the point at which the curve starts to climb less rapidly towards its upper limit. The data available at this time suggests that this leveling off has not yet occured to any significant degree: the annual growth rate in the allocation of Class B network numbers between 1983 and mid-1990 was a nearly identical 78% [9]. Whatever the exact shape of the curve, the conclusion that severe problems will erupt as a result of the exhaustion of the Class B network numbers is inescapable. The obvious corollary is that a short-term fix is necessary until the more fundamental problems referred to above can be solved. One approach that had been undertaken to deal with this issue was a change in NIC policy on how IP network numbers would be assigned: rather than assigning a Class B number to a site that was slightly too large for a single Class C number, several Class C net numbers would be granted instead. While this has had the effect of slowing the growth curve in Class B network number assignments to some degree, it has also had the unintended side effect of causing the total number of networks in the NSFNET routing database to increase dramatically: between April 1990 and November 1991, the annual growth rate of the database had been 75.9% per year. Since that time, it has risen to 153.2% per year [4]. Clearly, this is going to present tremendous demand for longer-term solutions to be developed and deployed in a short-term timeframe if this trend continues even for a few months. The proposals in this document are offered to reduce those pressures. Solensky, Kastenholz [Page 2] INTERNET DRAFT March, 1992 Class C-sharp Network Numbers The upper half of the Class C address space -- addresses with a prefix of '1101' -- will be used for the assignment of new Class C- sharp (C#) IP network numbers(*). Within the 28 bits available in Class C# addresses, the first sixteen will define the network number and the remaining twelve will be the local address, as illustrated below. This would correspond to the IP address that fall into the range 208.0.0.0 through 223.255.255.255. 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 1 0 1| NETWORK | Local Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Class C-sharp address The Class C# network with an all-zero network field (IP addresses 208.0.0.0 through 208.0.15.255) will be reserved to indicate host addresses within the local network. It was felt that splitting the network and local address fields into these particular sizes met some of the more important design objectives: * The number of networks created by this division - over 65,000 - should be sufficient to meet the needs of the immediate future while other long-term solutions are being developed. The alter- native of using fewer bits in the network portion of the address (including 4096 additional Class B-sized networks) had been con- sidered but generally dismissed since the smaller count of new network numbers would allow proportionally less time to develop and deploy a replacement Internet architecture. * Many sites that are currently requesting Class B numbers do not come close to fully utilizing the address space and could easily use something a little smaller. The size of a local network in this address class - 4094 hosts in an unsubnetted environment - is large enough to be useful to many organizations without being _________________________ (*) The musically inclined may appreciate the mnemonic device: the two address classes correspond to the white keys on a piano that do not have black keys a half-step above them: B and E (the latter, if sub- divided, could still be called "class F"). However, one needs to be careful not to read too much into these names since, as stated ear- lier, this methodology does not address the issue of scaling. Solensky, Kastenholz [Page 3] INTERNET DRAFT March, 1992 so large that it becomes sparsely populated. It also provides a local field large enough to be separated into useful subnet and host numbers fields: the "regular" Class C addresses lack this feature. This is particularly important now that the use of variable-sized subnet masks within a given network is practical. * The creation of this new address class should sufficiently reduce the demand for the remaining Class B network numbers so that their assignment can be limited to larger sites. Another benefit of this division, while not of great import but nevertheless noteworthy, is that it keeps the division of the network and local addresses fields on nybble boundaries and thereby easier to pick out the individual fields when displayed in hexadecimal nota- tion. The dotted-decimal notation used to express addresses does not need to be changed for host addresses. A network number may be denoted by the range of addresses that it encompasses (eg: the first assignable one would be known as "208.0.16-31"). The proposal to continue the current practice of allocating a space whose prefix started with all 1's and ended with a 0 (i.e. allocate the prefix '11110' for Class E addresses and defining addresses with a prefix of '11111' as a reserved "Class F" space) had been con- sidered. The problem with doing so, however, is that this practice demonstrates the law of diminishing returns: the processing overhead of separating any IP address into its network and local address fields gets increasingly complex while shrinking the reserved address space into a less useful portion - just over 3% - of the total. Another alternative that was discussed was to use the entire Class E address space in this manner and assign the upper halves of both Class A and C address spaces as new reserved address spaces. There are a number of compelling arguments against this approach: * Routers that do not explicitly recognize Class C# addresses would still be able to forward packets, since the destination address would be interpreted as belonging to a Class C network. Class E destination addresses would have to be ignored by these same routers, causing these new networks to be able to communi- cate with only those parts of the Internet that recognized the new address. * It had been argued that announcing the presence of a class C# address to an older router by announcing 16 consecutively- numbered Class C addresses will exacerbate the routing overhead problem in the backbone nets. However, the backbone routers can just as easily be modified to recognize the aggregatability of '1101' addresses as they can be to recognize '1111' addresses by Solensky, Kastenholz [Page 4] INTERNET DRAFT March, 1992 a trivial modification: they simply have to use a mask of 0xFFFFF000 for the C# addresses. Routers that are not on the backbone and are not suffering from excessive numbers of routes need not be changed at all. * It has been argued that using the Class E space would be prefer- able to the C# space because it would provide a greater incen- tive for vendors/authors to update their IP software to support classless routing. However, there are many systems whose IP software is no longer supported, or whose owners will never get around to updating their software even if it is available. Using the Class C# address space is far more consistent with the dictum to "be conservative in what you send and liberal in what you accept from others" [7]. Exterior Gateway Protocol (EGP) The changes to the address formats described in this memo suggest some modifications to the Exterior Gateway Protocol [6]. We describe how the Class C# addresses are to be represented within the EGP mes- sages and a methodology by which neighboring systems can reduce the length of the routing table update messages. This extention, how- ever, is not strictly required to maintain interoperable implementa- tions of EGP. To keep the length of protocol messages down to a minimum, EGP gen- erally represents the IP network and host numbers as variable length fields using the fewest number of bytes necessary. A Class A network number, for example, is stored in a one-byte field. The recipient of the message examines the first couple of bits of the field to deter- mine the field's length. When a host address is specified in the message instead, the recipient will have already determined the net- work number; the length of this field is simply set to the number of bytes needed to complete the address. Within the EGP 'NR Poll' message, the IP Source Network number is always stored in a three-byte field. The original specification describes this field as a single byte network number followed by two bytes of zero when the network falls within the Class A address space and two bytes of network number followed by one byte of zero for Class B network numbers. This recommendation would simply broaden the definition so that this field contains the network number, left justified and zero filled. The 'Network Reachability' (NR) message of EGP also needs to be modi- fied when forwarding information about Class C# networks in a more substantial manner. The Gateway IP address field is long enough to hold the local portion of the address for the corresponding address Solensky, Kastenholz [Page 5] INTERNET DRAFT March, 1992 class (three bytes for Class A addresses, two bytes within a Class B network, one byte for Class C). Similarly, the Network address field is of sufficient length to contain the network number that can be reached by the router whose indicated by the Gateway IP address. While keeping the message length down is desirable, it becomes far more difficult to parse the message if these fields were to become non-byte aligned. For this reason, the Gateway IP address field will, for Class C# addresses, be three full bytes in length, zero- filled on the right to maintain byte alignment. The Network address field for Class C# addresses will also be three bytes long, zero filled on the left. This will remove the need for additional shift operations when reassembling a Class C# address from the message: the third byte of an address is restored through a logical OR operation between the final byte of the Gateway IP address field and the first byte of the Network address field Using these modifications, EGP neighbors that both recognize Class C# addresses will not have much trouble interoperating. However, it is desirable for the neighbor systems to be able to know beforehand if the other will be able to recognize the aggregation of the C# network numbers or if the destination network needs to be described to a less up-to-date router as sixteen separate Class C networks that happen to be consecutively numbered. A reasonably straightforward means to determine this is to use a new code value in the Neighbor Acquisition message. A code value of 5 would indicate to the recipient that the sender recognizes this new address class. If the neighbor is cognizant of Class C# addresses, it responds with a Confirm response (type 3, code 1) and moves into "Down" state; otherwise, it is expected to send a Refuse response due to what it believes to be an invalid command (type 3, code 2, status 7) or an Error response on a bad EGP header (type 8, reason 1) and returns to the "Idle" state. Upon receiving this rejection, the ori- ginating system becomes aware that the receipent does not recognize the aggregation of Class C# addresses and can fall back on sending the traditional Request command (type 3, code 0). If this second attempt is successful, the Class C# networks that are to be announced into the neighboring autonomous system will have to be described as sixteen different Class C networks. This process of receiving an error indication and forming a new request has the effect of creating an additional state. It is labeled as "Aqsn-2" in the state-machine diagram that follows. Solensky, Kastenholz [Page 6] INTERNET DRAFT March, 1992 +-------+ | |<--------------------------------+-------------+ +----->| Idle |-----------------------------+ A A | | |<---------------+ Request| | | | +-------+ A | | | | | A |Cease | |Cease |Cease | Start| |Cease |Refuse | | | | V | | V | | | +-------+ Refuse +-------+ +-------+ Up +-------+ | | |----------->| | | |------>| | | | Aqsn | |Aqsn-2 | | Down | Down | Up | | | |--------+ | | | |<------| | | +-------+ Confirm| +-------+ +-------+ +-------+ | | | | |Confirm A | | |Stop |Stop V | V | | | |Cease-ack V +-----(---+----------+ |Stop |Stop | +-------+ Stop| | | | | | V V V +------| Cease |<-------------+------------------+-------------+ | | +-------+ Border Gateway Protocol (BGP) The Border Gateway Protocol (BGP) as currently defined allows the version number to be negotiated between neighboring systems when the session is first established. BGP version 4 would indicate that the system is able to recognize the Class C# address class. When a ver- sion 4 implementation wishes to announce a single Class C# address to a version 3 implementation, it would present it as sixteen consecu- tively numbered Class C networks. Similarly, a version 4 implementa- tion would be able to aggregate the same sixteen Class C networks into a single Class C# network number. Other extentions to the BGP protocol in this new version (eg: net- masks) are beyond the scope of this document. Since the main argu- ment for Class C# addresses is that it would take less time to imple- ment and deploy, we would advise against any other revisions to the protocol at this time. The work that is currently underway to extend the BGP protocol would then become known as "BGP version 5". Domain Name Servers Another consideration that needs to be addressed is the impact this change will have on various Domain Name Servers. Current implementa- tions make the assumption that the '.in-addr.arpa' delegation is always defined on byte-aligned boundaries. While it would take rela- tively little time to add sixteen individual NS records, this could Solensky, Kastenholz [Page 7] INTERNET DRAFT March, 1992 easily cause the files to become extraordinarily large shortly after this address class becomes official. This is not considered to be the optimal solution: more specific ones are beyond the scope of this document. Supernetting The proposals presented in this document and those presented in [4] do not need to be considered as mutually exclusive options. Rather, Class C# can be thought of as taking the first step towards the "supernetting" proposal. Some of the reasons for pursuing this course: * It should take several months less to implement and deploy Class C# addresses. During the intervening period, the growth rate of the database will be proportionally reduced. Even if the time differential is not large, it could lead to a significantly smaller routing database at the time that supernetting becomes a reality than if current practices were unchanged. This would allow for a longer transition period between supernetting and a long-term solution. * It can provide operational experience in the interactions between routers that are breaking away from the traditional net- work classes and those that have not yet made the transition. Both proposals require the use of the remaining Class C network numbers so as to minimize the impact on host systems. This does not force the adoption of only one of the proposals. For example, class C# network numbers could be assigned as specified and the supernet- ting proposal would make use of the blocks of network numbers where bits 4 through 7 are non-zero (almost 94% of the total Class C address space). Conclusions It must be emphasized that the use of Class C# network addresses is intended only to be a work-around to the immediate problems. It is by no means a solution. While it defines a new class of address numbers that allows four times the number of networks of the original Class B space, this scheme will survive less than three years if current growth rates continue. By that time, it is expected that the increased amount of network connectivity which has been exhibiting similar growth rates [8,9] will cause the computational intensity of keeping track of these routes to require a moderate-term approach such as those described in [4] or an entirely different routing and addressing architecture such as one of the solutions outlined in [1]. Solensky, Kastenholz [Page 8] INTERNET DRAFT March, 1992 This change also points out the necessity of having hosts not pry into address formats. It is plausible to deploy a new network number format if only the routers have to be changed; doing so in a world where most types of host software have to be changed as well is clearly problematic. Security Considerations Security considerations are not discussed in this memo. References: [1] "The IP Addressing Issue", J. Noel Chiappa, Internet Draft, October, 1990. [2] "Towards the Future Architecture", D. Clark, L. Chapin, V. Cerf, R. Braden, RFC 1287, SRI International, December 1991. [3] "Host Extentions for IP Multicasting", S. Deering, RFC 1112, SRI International, August 1989. [4] "Supernetting: an Address Assignment and Aggregation Strategy", V. Fuller, T. Li, J. Yu, K. Varadhan, Internet Draft, March, 1992 [5] "Internet Numbers", S. Kirkpatrick, M. Stahl, M. Recker, RFC 1166, SRI International, July 1990. [6] "Exterior Gateway Protocol Formal Specification", D.L. Mills, RFC 904, SRI International, April 1984. [7] "Transmission Control Protocol", J. Postel, RFC 793, SRI Interna- tional, August 1980. [8] "Growth of the Internet", Mike St. Johns, Proceedings of the Thir- teenth Internet Engineering Task Force, April 11-14, 1989, pages 244-248. [9] "Continued Internet Growth", Frank Solensky, Proceedings of the Eighteenth Internet Engineering Task Force, July 30-August 3, 1990. pages 59-61. [10]Internet Monthly Report, A. Westine [ed], September, 1991. Solensky, Kastenholz [Page 9] INTERNET DRAFT March, 1992 Authors' Address: Frank Solensky Frank Kastenholz Clearpoint Research Corp. 35 Parkwood Drive Hopkinton, MA 01748 Phone: (508) 435-2000 Email: solensky@clearpoint.com, kasten@clearpoint.com Solensky, Kastenholz [Page 10]