3. Classless Addressing as a Solution

   The solution that the community created was to deprecate the Class
   A/B/C network address assignment system in favor of using
   "classless", hierarchical blocks of IP addresses (referred to as
   prefixes).  The assignment of prefixes is intended to roughly follow
   the underlying Internet topology so that aggregation can be used to
   facilitate scaling of the global routing system.  One implication of
   this strategy is that prefix assignment and aggregation is generally
   done according to provider-subscriber relationships, since that is
   how the Internet topology is determined.

   When originally proposed in [RFC1338] and [RFC1519], this addressing
   plan was intended to be a relatively short-term response, lasting
   approximately three to five years, during which a more permanent
   addressing and routing architecture would be designed and
   implemented.  As can be inferred from the dates on the original
   documents, CIDR has far outlasted its anticipated lifespan and has
   become the mid-term solution to the problems described above.

   Note that in the following text we describe the current policies and
   procedures that have been put in place to implement the allocation
   architecture discussed here.  This description is not intended to be
   interpreted as direction to IANA.

   Coupled with address management strategies implemented by the
   Regional Internet Registries (see [NRO] for details), the deployment
   of CIDR-style addressing has also reduced the rate at which IPv4
   address space has been consumed, thus providing short- to medium-term
   relief to problem #3, described above.

   Note that, as defined, this plan neither requires nor assumes the
   re-assignment of those parts of the legacy "Class C" space that are
   not amenable to aggregation (sometimes called "the swamp").  Doing so
   would somewhat reduce routing table sizes (current estimate is that
   "the swamp" contains approximately 15,000 entries), though at a
   significant renumbering cost.  Similarly, there is no hard
   requirement that any end site renumber when changing transit service
   provider, but end sites are encouraged do so to eliminate the need
   for explicit advertisement of their prefixes into the global routing
   system.

3.1. Basic Concept and Prefix Notation

   In the simplest sense, the change from Class A/B/C network numbers to
   classless prefixes is to make explicit which bits in a 32-bit IPv4
   address are interpreted as the network number (or prefix) associated
   with a site and which are the used to number individual end systems
   within the site.  In CIDR notation, a prefix is shown as a 4-octet
   quantity, just like a traditional IPv4 address or network number,
   followed by the "/" (slash) character, followed by a decimal value
   between 0 and 32 that describes the number of significant bits.

   For example, the legacy "Class B" network 172.16.0.0, with an implied
   network mask of 255.255.0.0, is defined as the prefix 172.16.0.0/16,
   the "/16" indicating that the mask to extract the network portion of
   the prefix is a 32-bit value where the most significant 16 bits are
   ones and the least significant 16 bits are zeros.  Similarly, the
   legacy "Class C" network number 192.168.99.0 is defined as the prefix
   192.168.99.0/24; the most significant 24 bits are ones and the least
   significant 8 bits are zeros.

   Using classless prefixes with explicit prefix lengths allows much
   more flexible matching of address space blocks according to actual
   need.  Where formerly only three network sizes were available,
   prefixes may be defined to describe any power of two-sized block of
   between one and 2^32 end system addresses.  In practice, the
   unallocated pool of addresses is administered by the Internet
   Assigned Numbers Authority ([IANA]).  The IANA makes allocations from
   this pool to Regional Internet Registries, as required.  These
   allocations are made in contiguous bit-aligned blocks of 2^24
   addresses (a.k.a. /8 prefixes).  The Regional Internet Registries
   (RIRs), in turn, allocate or assign smaller address blocks to Local
   Internet Registries (LIRs) or Internet Service Providers (ISPs).
   These entities may make direct use of the assignment (as would
   commonly be the case for an ISP) or may make further sub-allocations
   of addresses to their customers.  These RIR address assignments vary
   according to the needs of each ISP or LIR.  For example, a large ISP
   might be allocated an address block of 2^17 addresses (a /15 prefix),
   whereas a smaller ISP may be allocated an address block of 2^11
   addresses (a /21 prefix).

   Note that the terms "allocate" and "assign" have specific meaning in
   the Internet address registry system; "allocate" refers to the
   delegation of a block of address space to an organization that is
   expected to perform further sub-delegations, and "assign" is used for
   sites that directly use (i.e., number individual hosts) the block of
   addresses received.

   The following table provides a convenient shortcut to all the CIDR
   prefix sizes, showing the number of addresses possible in each prefix
   and the number of prefixes of that size that may be numbered in the
   32-bit IPv4 address space:

       notation       addrs/block      # blocks
       --------       -----------     ----------
       n.n.n.n/32               1     4294967296    "host route"
       n.n.n.x/31               2     2147483648    "p2p link"
       n.n.n.x/30               4     1073741824
       n.n.n.x/29               8      536870912
       n.n.n.x/28              16      268435456
       n.n.n.x/27              32      134217728
       n.n.n.x/26              64       67108864
       n.n.n.x/25             128       33554432
       n.n.n.0/24             256       16777216    legacy "Class C"
       n.n.x.0/23             512        8388608
       n.n.x.0/22            1024        4194304
       n.n.x.0/21            2048        2097152
       n.n.x.0/20            4096        1048576
       n.n.x.0/19            8192         524288
       n.n.x.0/18           16384         262144
       n.n.x.0/17           32768         131072
       n.n.0.0/16           65536          65536    legacy "Class B"
       n.x.0.0/15          131072          32768
       n.x.0.0/14          262144          16384
       n.x.0.0/13          524288           8192
       n.x.0.0/12         1048576           4096
       n.x.0.0/11         2097152           2048
       n.x.0.0/10         4194304           1024
       n.x.0.0/9          8388608            512
       n.0.0.0/8         16777216            256    legacy "Class A"
       x.0.0.0/7         33554432            128
       x.0.0.0/6         67108864             64
       x.0.0.0/5        134217728             32
       x.0.0.0/4        268435456             16
       x.0.0.0/3        536870912              8
       x.0.0.0/2       1073741824              4
       x.0.0.0/1       2147483648              2
       0.0.0.0/0       4294967296              1    "default route"

   n is an 8-bit decimal octet value.  Point-to-point links are
   discussed in more detail in [RFC3021].

   x is a 1- to 7-bit value, based on the prefix length, shifted into
   the most significant bits of the octet and converted into decimal
   form; the least significant bits of the octet are zero.

   In practice, prefixes of length shorter than 8 have not been
   allocated or assigned to date, although routes to such short prefixes
   may exist in routing tables if or when aggressive aggregation is
   performed.  As of the writing of this document, no such routes are
   seen in the global routing system, but operator error and other
   events have caused some of them (i.e., 128.0.0.0/1 and 192.0.0.0/2)
   to be observed in some networks at some times in the past.