[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
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]