Frank and Frank -- 15 March 1992 -- B-I ---------------------------------------- Network Working Group F. Solensky INTERNET-DRAFT F. Kastenholz Updates: 791, 904, 1122 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 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 address the limitations inherent in the current routing architectures and technology that are discussed in [1] and [2]. These must wait until new architectures are developed. Specifically, the issue of scaling is not 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. Of the three classes of IP network numbers, Class A (which can support up to 16,777,214 unique host identifier addresses within the Solensky, Kastenholz [Page 1] INTERNET DRAFT March, 1992 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 [4,9]; 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% [8]. 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. This document contains that fix. 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. * The musically inclined may appreciate the mnemonic device: the two address classes that are least likely to be further subdivided correspond to the white keys on a piano that do not have black keys a half-step above them: B and E. However, one needs to be careful not to read too much into these names since, as stated earlier, this methodology does not address the issue of scaling. Solensky, Kastenholz [Page 2] INTERNET DRAFT March, 1992 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 alternative of using fewer bits in the network portion of the address (including 4096 additional Class B-sized networks) had been considered 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 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 notation. The dotted-decimal notation used to express addresses does not need to be changed: one can simply refer to a block of addresses. 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 Solensky, Kastenholz [Page 3] INTERNET DRAFT March, 1992 the prefix '11110' for Class E addresses and defining addresses with a prefix of '11111' as a reserved "Class F" space) had been considered. 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 communicate 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 a trivial modification: they simply have to use a mask of FFFFF000 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 preferable to the C# space because it would be a greater incentive for vendors/authors to update their IP software to support classless routing. However, there are many boxes out there 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" [6]. Exterior Gateway Protocol (EGP) The changes to the address formats described in this memo suggest some modifications to the Exterior Gateway Protocol [5]. We describe how the Class C# addresses are to be represented within the EGP messages and a methodology by which neighboring systems can reduce Solensky, Kastenholz [Page 4] INTERNET DRAFT March, 1992 the length of the routing table update messages. In order to keep the length of protocol messages down to a minimum, EGP generally 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 determine the field's length. When a host address is specified in the message instead, the recipient will have already determined the network 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 rephrase 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 modified 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 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 two full bytes in length, zero-filled on the right to maintain byte alignment. The Network address field for Class C# addresses will 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. Solensky, Kastenholz [Page 5] INTERNET DRAFT March, 1992 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 originating 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. +-------+ | |<--------------------------------+-------------+ +----->| 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 |<-------------+------------------+-------------+ | | +-------+ Domain Name Servers Another consideration that needs to be addressed is the impact this change will have on various Domain Name Servers. Current implementations make the assumption that the While it would take relatively little time to add sixteen individual NS records, this Solensky, Kastenholz [Page 6] INTERNET DRAFT March, 1992 could 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. Conclusions It must be emphasized that the use of Class C# network addresses is intended only to be a work-around to the immediate problem. 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 [7,8] will cause the computational intensity of keeping track of these routes to require an entirely different routing and addressing architecture for the Internet such as one of the solutions outlined in [1]. 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. 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] "Internet Numbers", S. Kirkpatrick, M. Stahl, M. Recker, RFC 1166, SRI International, July 1990. [5] "Exterior Gateway Protocol Formal Specification", D.L. Mills, RFC 904, SRI International, April 1984. [6] "Transmission Control Protocol", J. Postel, RFC 793, SRI International, August 1980. [6] "Growth of the Internet", Mike St. Johns, Proceedings of the Thirteenth Internet Engineering Task Force, April 11-14, 1989, pages 244-248. Solensky, Kastenholz [Page 7] INTERNET DRAFT March, 1992 [7] "Continued Internet Growth", Frank Solensky, Proceedings of the Eighteenth Internet Engineering Task Force, July 30-August 3, 1990. pages 59-61. [8] Internet Monthly Report, A. Westine [ed], September, 1991. 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 8]