Request for Comments: 4632 Cisco Systems
BCP: 122 T. Li
Obsoletes: 1519 Tropos Networks
Category: Best Current Practice August 2006
Classless Inter-domain Routing (CIDR):
The Internet Address Assignment and Aggregation Plan
Status of This Memo
This document specifies an Internet Best Current Practices for the
Internet Community, and requests discussion and suggestions for
improvements. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This memo discusses the strategy for address assignment of the
existing 32-bit IPv4 address space with a view toward conserving the
address space and limiting the growth rate of global routing state.
This document obsoletes the original Classless Inter-domain Routing
(CIDR) spec in RFC 1519, with changes made both to clarify the
concepts it introduced and, after more than twelve years, to update
the Internet community on the results of deploying the technology
described.
Table of Contents
1. Introduction ....................................................3
2. History and Problem Description .................................3
3. Classless Addressing as a Solution ..............................4
3.1. Basic Concept and Prefix Notation ..........................5
4. Address Assignment and Routing Aggregation ......................8
4.1. Aggregation Efficiency and Limitations .....................8
4.2. Distributed Assignment of Address Space ...................10
5. Routing Implementation Considerations ..........................11
5.1. Rules for Route Advertisement .............................11
5.2. How the Rules Work ........................................12
5.3. A Note on Prefix Filter Formats ...........................13
5.4. Responsibility for and Configuration of Aggregation .......13
5.5. Route Propagation and Routing Protocol Considerations .....15
6. Example of New Address Assignments and Routing .................15
6.1. Address Delegation ........................................15
6.2. Routing Advertisements ....................................17
7. Domain Name Service Considerations .............................18
8. Transition to a Long-Term Solution .............................18
9. Analysis of CIDR’s Effect on Global Routing State ..............19
10. Conclusions and Recommendations ...............................20
11. Status Updates to CIDR Documents ..............................21
12. Security Considerations .......................................23
13. Acknowledgements ..............................................24
14. References ....................................................25
14.1. Normative References .....................................25
14.2. Informative References ...................................25
1. Introduction
This memo discusses the strategy for address assignment of the
existing 32-bit IPv4 address space with a view toward conserving the
address space and limiting the growth rate of global routing state.
This document obsoletes the original CIDR spec [RFC1519], with
changes made both to clarify the concepts it introduced and, after
more than twelve years, to update the Internet community on the
results of deploying the technology described.
2. History and Problem Description
What is now known as the Internet started as a research project in
the 1970s to design and develop a set of protocols that could be used
with many different network technologies to provide a seamless, end-
to-end facility for interconnecting a diverse set of end systems.
When it was determined how the 32-bit address space would be used,
certain assumptions were made about the number of organizations to be
connected, the number of end systems per organization, and total
number of end systems on the network. The end result was the
establishment (see [RFC791]) of three classes of networks: Class A
(most significant address bits ’00’), with 128 possible networks each
and 16777216 end systems (minus special bit values reserved for
network/broadcast addresses); Class B (MSB ’10’), with 16384 possible
networks each with 65536 end systems (less reserved values); and
Class C (MSB ’110’), and 2097152 possible networks each and 254 end
systems (256 bit combinations minus the reserved all-zeros and all-
ones patterns). The set of addresses with MSB ’111’ was reserved for
future use; parts of this were eventually defined (MSB ’1110’) for
use with IPv4 multicast and parts are still reserved as of the
writing of this document.
In the late 1980s, the expansion and commercialization of the former
research network resulted in the connection of many new organizations
to the rapidly growing Internet, and each new organization required
an address assignment according to the Class A/B/C addressing plan.
As demand for new network numbers (particularly in the Class B space)
took what appeared to be an exponential growth rate, some members of
the operations and engineering community started to have concerns
over the long-term scaling properties of the class A/B/C system and
began thinking about how to modify network number assignment policy
and routing protocols to accommodate the growth. In November, 1991,
the Internet Engineering Task Force (IETF) created the ROAD (Routing
and Addressing) group to examine the situation. This group met in
January 1992 and identified three major problems:
1. Exhaustion of the Class B network address space. One fundamental
cause of this problem is the lack of a network class of a size
that is appropriate for mid-sized organization. Class C, with a
maximum of 254 host addresses, is too small, whereas Class B,
which allows up to 65534 host addresses, is too large for most
organizations but was the best fit available for use with
subnetting.
2. Growth of routing tables in Internet routers beyond the ability
of current software, hardware, and people to effectively manage.
3. Eventual exhaustion of the 32-bit IPv4 address space.
It was clear that then-current rates of Internet growth would
cause the first two problems to become critical sometime between
1993 and 1995. Work already in progress on topological
assignment of addressing for Connectionless Network Service
(CLNS), which was presented to the community at the Boulder IETF
in December of 1990, led to thoughts on how to re-structure the
32-bit IPv4 address space to increase its lifespan. Work in the
ROAD group followed and eventually resulted in the publication of
[RFC1338], and later, [RFC1519].
The design and deployment of CIDR was intended to solve these
problems by providing a mechanism to slow the growth of global
routing tables and to reduce the rate of consumption of IPv4
address space. It did not and does not attempt to solve the
third problem, which is of a more long-term nature; instead, it
endeavors to ease enough of the short- to mid-term difficulties
to allow the Internet to continue to function efficiently while
progress is made on a longer-term solution.
More historical background on this effort and on the ROAD group
may be found in [RFC1380] and at [LWRD].
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.
4. Address Assignment and Routing Aggregation
Classless addressing and routing was initially developed primarily to
improve the scaling properties of routing on the global Internet.
Because the scaling of routing is very tightly coupled to the way
that addresses are used, deployment of CIDR had implications for the
way in which addresses were assigned.
4.1. Aggregation Efficiency and Limitations
The only commonly understood method for reducing routing state on a
packet-switched network is through aggregation of information. For
CIDR to succeed in reducing the size and growth rate of the global
routing system, the IPv4 address assignment process needed to be
changed to make possible the aggregation of routing information along
topological lines. Since, in general, the topology of the network is
determined by the service providers who have built it, topologically
significant address assignments are necessarily service-provider
oriented.
Aggregation is simple for an end site that is connected to one
service provider: it uses address space assigned by its service
provider, and that address space is a small piece of a larger block
allocated to the service provider. No explicit route is needed for
the end site; the service provider advertises a single aggregate
route for the larger block. This advertisement provides reachability
and routeability for all the customers numbered in the block.
There are two, more complex, situations that reduce the effectiveness
of aggregation:
o An organization that is multi-homed. Because a multi-homed
organization must be advertised into the system by each of its
service providers, it is often not feasible to aggregate its
routing information into the address space of any one of those
providers. Note that the organization still may receive its
address assignment out of a service provider’s address space
(which has other advantages), but that a route to the
organization’s prefix is, in the most general case, explicitly
advertised by all of its service providers. For this reason, the
global routing cost for a multi-homed organization is generally
the same as it was prior to the adoption of CIDR. A more detailed
consideration of multi-homing practices can be found in [RFC4116].
o An organization that changes service provider but does not
renumber. This has the effect of "punching a hole" in one of the
original service provider’s aggregated route advertisements. CIDR
handles this situation by requiring that the newer service
provider to advertise a specific advertisement for the re-homed
organization; this advertisement is preferred over provider
aggregates because it is a longer match. To maintain efficiency
of aggregation, it is recommended that an organization that
changes service providers plan eventually to migrate its network
into a an prefix assigned from its new provider’s address space.
To this end, it is recommended that mechanisms to facilitate such
migration, such as dynamic host address assignment that uses
[RFC2131]), be deployed wherever possible, and that additional
protocol work be done to develop improved technology for
renumbering.
Note that some aggregation efficiency gain can still be had for
multi-homed sites (and, in general, for any site composed of
multiple, logical IPv4 networks); by allocating a contiguous power-
of-two block address space to the site (as opposed to multiple,
independent prefixes), the site’s routing information may be
aggregated into a single prefix. Also, since the routing cost
associated with assigning a multi-homed site out of a service
provider’s address space is no greater than the old method of
sequential number assignment by a central authority, it makes sense
to assign all end-site address space out of blocks allocated to
service providers.
It is also worthwhile to mention that since aggregation may occur at
multiple levels in the system, it may still be possible to aggregate
these anomalous routes at higher levels of whatever hierarchy may be
present. For example, if a site is multi-homed to two relatively
small providers that both obtain connectivity and address space from
the same large provider, then aggregation by the large provider of
routes from the smaller networks will include all routes to the
multi-homed site. The feasibility of this sort of second-level
aggregation depends on whether topological hierarchy exists among a
site, its directly-connected providers, and other providers to which
they are connected; it may be practical in some regions of the global
Internet but not in others.
Note: In the discussion and examples that follow, prefix notation is
used to represent routing destinations. This is used for
illustration only and does not require that routing protocols use
this representation in their updates.
4.2. Distributed Assignment of Address Space
In the early days of the Internet, IPv4 address space assignment was
performed by the central Network Information Center (NIC). Class
A/B/C network numbers were assigned in essentially arbitrary order,
roughly according to the size of the organizations that requested
them. All assignments were recorded centrally, and no attempt was
made to assign network numbers in a manner that would allow routing
aggregation.
When CIDR was originally deployed, the central assignment authority
continued to exist but changed its procedures to assign large blocks
of "Class C" network numbers to each service provider. Each service
provider, in turn, assigned bitmask-oriented subsets of the
provider’s address space to each customer. This worked reasonably
well, as long as the number of service providers was relatively small
and relatively constant, but it did not scale well, as the number of
service providers grew at a rapid rate.
As the Internet started to expand rapidly in the 1990s, it became
clear that a single, centralized address assignment authority was
problematic. This function began being de-centralized when address
space assignment for European Internet sites was delegated in bit-
aligned blocks of 16777216 addresses (what CIDR would later define as
a /8) to the RIPE NCC ([RIPE]), effectively making it the first of
the RIRs. Since then, address assignment has been formally
distributed as a hierarchical function with IANA, the RIRs, and the
service providers. Removing the bottleneck of a single organization
having responsibility for the global Internet address space greatly
improved the efficiency and response time for new assignments.
Hierarchical delegation of addresses in this manner implies that
sites with addresses assigned out of a given service provider are,
for routing purposes, part of that service provider and will be
routed via its infrastructure. This implies that routing information
about multi-homed organizations (i.e., organizations connected to
more than one network service provider) will still need to be known
by higher levels in the hierarchy.
A historical perspective on these issues is described in [RFC1518].
Additional discussion may also be found in [RFC3221].
5. Routing Implementation Considerations
With the change from classful network numbers to classless prefixes,
it is not possible to infer the network mask from the initial bit
pattern of an IPv4 address. This has implications for how routing
information is stored and propagated. Network masks or prefix
lengths must be explicitly carried in routing protocols. Interior