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]