draft-ietf-grow-rfc1519bis-04.txt   rfc4632.txt 
GROW V. Fuller Network Working Group V. Fuller
Internet-Draft Cisco Systems Request for Comments: 4632 Cisco Systems
Expires: July 5, 2006 T. Li BCP: 122 T. Li
Li Consulting Obsoletes: 1519 Tropos Networks
January 2006 Category: Best Current Practice August 2006
Classless Inter-Domain Routing (CIDR): The Internet Address Assignment
and Aggregation Plan
draft-ietf-grow-rfc1519bis-04
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at Classless Inter-domain Routing (CIDR):
http://www.ietf.org/ietf/1id-abstracts.txt. The Internet Address Assignment and Aggregation Plan
The list of Internet-Draft Shadow Directories can be accessed at Status of This Memo
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on July 5, 2006. 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 Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
Abstract Abstract
This memo discusses the strategy for address assignment of the This memo discusses the strategy for address assignment of the
existing 32-bit IPv4 address space with a view toward conserving the existing 32-bit IPv4 address space with a view toward conserving the
address space and limiting the growth rate of global routing state. address space and limiting the growth rate of global routing state.
This document obsoletes the original CIDR spec [RFC1519], with This document obsoletes the original Classless Inter-domain Routing
changes made both to clarify the concepts it introduced and, after (CIDR) spec in RFC 1519, with changes made both to clarify the
more than twelve years, to update the Internet community on the concepts it introduced and, after more than twelve years, to update
results of deploying the technology described. the Internet community on the results of deploying the technology
described.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction ....................................................3
2. History and Problem Description . . . . . . . . . . . . . . . 3 2. History and Problem Description .................................3
3. Classless addressing as a solution . . . . . . . . . . . . . . 4 3. Classless Addressing as a Solution ..............................4
3.1. Basic concept and prefix notation . . . . . . . . . . . . 5 3.1. Basic Concept and Prefix Notation ..........................5
4. Address assignment and routing aggregation . . . . . . . . . . 8 4. Address Assignment and Routing Aggregation ......................8
4.1. Aggregation efficiency and limitations . . . . . . . . . . 8 4.1. Aggregation Efficiency and Limitations .....................8
4.2. Distributed assignment of address space . . . . . . . . . 9 4.2. Distributed Assignment of Address Space ...................10
5. Routing implementation considerations . . . . . . . . . . . . 10 5. Routing Implementation Considerations ..........................11
5.1. Rules for route advertisement . . . . . . . . . . . . . . 11 5.1. Rules for Route Advertisement .............................11
5.2. How the rules work . . . . . . . . . . . . . . . . . . . . 12 5.2. How the Rules Work ........................................12
5.3. A note on prefix filter formats . . . . . . . . . . . . . 13 5.3. A Note on Prefix Filter Formats ...........................13
5.4. Responsibility for and configuration of aggregation . . . 13 5.4. Responsibility for and Configuration of Aggregation .......13
5.5. Route propagation and routing protocol considerations . . 14 5.5. Route Propagation and Routing Protocol Considerations .....15
6. Example of new address assignments and routing . . . . . . . . 15 6. Example of New Address Assignments and Routing .................15
6.1. Address delegation . . . . . . . . . . . . . . . . . . . . 15 6.1. Address Delegation ........................................15
6.2. Routing advertisements . . . . . . . . . . . . . . . . . . 17 6.2. Routing Advertisements ....................................17
7. Domain Name Service considerations . . . . . . . . . . . . . . 18 7. Domain Name Service Considerations .............................18
8. Transition to a long term solution . . . . . . . . . . . . . . 18 8. Transition to a Long-Term Solution .............................18
9. Analysis of CIDR's effect on global routing state . . . . . . 18 9. Analysis of CIDR's Effect on Global Routing State ..............19
10. Conclusions and Recommendations . . . . . . . . . . . . . . . 20 10. Conclusions and Recommendations ...............................20
11. Status updates to CIDR documents . . . . . . . . . . . . . . . 21 11. Status Updates to CIDR Documents ..............................21
12. Security Considerations . . . . . . . . . . . . . . . . . . . 23 12. Security Considerations .......................................23
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 13. Acknowledgements ..............................................24
14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24 14. References ....................................................25
15. Appendix A: Area Director Comments and Responses . . . . . . . 24 14.1. Normative References .....................................25
16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 14.2. Informative References ...................................25
16.1. Normative References . . . . . . . . . . . . . . . . . . . 26
16.2. Informative References . . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28
Intellectual Property and Copyright Statements . . . . . . . . . . 29
1. Introduction 1. Introduction
This memo discusses the strategy for address assignment of the This memo discusses the strategy for address assignment of the
existing 32-bit IPv4 address space with a view toward conserving the existing 32-bit IPv4 address space with a view toward conserving the
address space and limiting the growth rate of global routing state. address space and limiting the growth rate of global routing state.
This document obsoletes the original CIDR spec [RFC1519], with This document obsoletes the original CIDR spec [RFC1519], with
changes made both to clarify the concepts it introduced and, after changes made both to clarify the concepts it introduced and, after
more than twelve years, to update the Internet community on the more than twelve years, to update the Internet community on the
results of deploying the technology described. results of deploying the technology described.
2. History and Problem Description 2. History and Problem Description
What is now known as the Internet started as a research project in 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 the 1970s to design and develop a set of protocols that could be used
with many different network technologies to provide a seamless, end- with many different network technologies to provide a seamless, end-
to-end facility for interconnecting a diverse set of end systems. to-end facility for interconnecting a diverse set of end systems.
When determining how the 32-bit address space would be used, certain When it was determined how the 32-bit address space would be used,
assumptions were made about the number of organizations to be certain assumptions were made about the number of organizations to be
connected, the number of end systems per organization, and total connected, the number of end systems per organization, and total
number of end systems on the network. The end result was the number of end systems on the network. The end result was the
establishment (see [RFC791]) of three classes of networks: class A establishment (see [RFC791]) of three classes of networks: Class A
(most significant address bits '00'), with 128 possible networks each (most significant address bits '00'), with 128 possible networks each
with 16777216 end systems (minus special bit values reserved for and 16777216 end systems (minus special bit values reserved for
network/broadcast addresses); class B (MSB '10'), with 16384 possible network/broadcast addresses); Class B (MSB '10'), with 16384 possible
networks each with 65536 end systems (less reserved values); and networks each with 65536 end systems (less reserved values); and
class C (MSB '110'), with 2097152 possible networks each with 254 end Class C (MSB '110'), and 2097152 possible networks each and 254 end
systems (256 bit combinations minus the reserved all-zeros and all- systems (256 bit combinations minus the reserved all-zeros and all-
ones patterns). The set of addresses with MSB '111' was reserved for ones patterns). The set of addresses with MSB '111' was reserved for
future use; parts of this were eventually defined (MSB '1110') for future use; parts of this were eventually defined (MSB '1110') for
use with IPv4 multicast and parts are still reserved as of the use with IPv4 multicast and parts are still reserved as of the
writing of this document. writing of this document.
In the late 1980s, the expansion and commercialization of the former In the late 1980s, the expansion and commercialization of the former
research network resulted in the connection of many new organizations research network resulted in the connection of many new organizations
to the rapidly-growing Internet and each new organization required an to the rapidly growing Internet, and each new organization required
address assignment according to the class A/B/C addressing plan. As an address assignment according to the Class A/B/C addressing plan.
demand for new network numbers, particularly in the class B space As demand for new network numbers (particularly in the Class B space)
started to take on what appeared to be an exponential growth rate, took what appeared to be an exponential growth rate, some members of
some members of the operations and engineering community started to the operations and engineering community started to have concerns
have concerns over the long-term scaling properties of the class over the long-term scaling properties of the class A/B/C system and
A/B/C system and began thinking about how to modify network number began thinking about how to modify network number assignment policy
assignment policy and routing protocols to better accommodate the and routing protocols to accommodate the growth. In November, 1991,
growth. In November, 1991, the IETF created the ROAD (Routing and the Internet Engineering Task Force (IETF) created the ROAD (Routing
Addressing) group to examine the situation. This group met in and Addressing) group to examine the situation. This group met in
January, 1992 and identified three major problems: January 1992 and identified three major problems:
1. Exhaustion of the class B network address space. One fundamental 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 cause of this problem is the lack of a network class of a size
which is appropriate for mid-sized organization; class C, with a that is appropriate for mid-sized organization. Class C, with a
maximum of 254 host addresses, is too small, while class B, which maximum of 254 host addresses, is too small, whereas Class B,
allows up to 65534 host addresses, is too large for most which allows up to 65534 host addresses, is too large for most
organizations but was the best fit available for use with organizations but was the best fit available for use with
subnetting. subnetting.
2. Growth of routing tables in Internet routers beyond the ability 2. Growth of routing tables in Internet routers beyond the ability
of current software, hardware, and people to effectively manage. of current software, hardware, and people to effectively manage.
3. Eventual exhaustion of the 32-bit IPv4 address space. 3. Eventual exhaustion of the 32-bit IPv4 address space.
It was clear that then-current rates of Internet growth would cause It was clear that then-current rates of Internet growth would
the first two problems to become critical some time between 1993 and cause the first two problems to become critical sometime between
1995. Work already in progress on topological assignment of 1993 and 1995. Work already in progress on topological
addressing for CLNS, which was presented to the community at the assignment of addressing for Connectionless Network Service
Boulder IETF in December of 1990, led to thoughts on how to re- (CLNS), which was presented to the community at the Boulder IETF
structure the 32-bit IPv4 address space to increase its lifespan. in December of 1990, led to thoughts on how to re-structure the
Work in the ROAD group followed and eventually resulted in the 32-bit IPv4 address space to increase its lifespan. Work in the
publication of [RFC1338] and later [RFC1519]. 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 The design and deployment of CIDR was intended to solve these
problems by providing a mechanism to slow the growth of global problems by providing a mechanism to slow the growth of global
routing tables and to reduce the rate of consumption of IPv4 address routing tables and to reduce the rate of consumption of IPv4
space. It did not and does not attempt to solve the third problem, address space. It did not and does not attempt to solve the
which is of a more long-term nature, but instead endeavors to ease third problem, which is of a more long-term nature; instead, it
enough of the short to mid-term difficulties to allow the Internet to endeavors to ease enough of the short- to mid-term difficulties
continue to function efficiently while progress is made on a longer- to allow the Internet to continue to function efficiently while
term solution. progress is made on a longer-term solution.
More historical background on this effort and on the ROAD group may More historical background on this effort and on the ROAD group
be found in [RFC1380] and at [LWRD]. may be found in [RFC1380] and at [LWRD].
3. Classless addressing as a solution 3. Classless Addressing as a Solution
The solution that the community created was to deprecate the Class The solution that the community created was to deprecate the Class
A/B/C network address assignment system in favor of using A/B/C network address assignment system in favor of using
"classless", hierarchical blocks of IP addresses (referred to as "classless", hierarchical blocks of IP addresses (referred to as
prefixes). The assignment of prefixes is intended to roughly follow prefixes). The assignment of prefixes is intended to roughly follow
the underlying Internet topology so that aggregation can be used to the underlying Internet topology so that aggregation can be used to
facilitate scaling of the global routing system. One implication of facilitate scaling of the global routing system. One implication of
this strategy is that prefix assignment and aggregation is generally this strategy is that prefix assignment and aggregation is generally
done according to provider-subscriber relationships, since that is done according to provider-subscriber relationships, since that is
how the Internet topology is determined. how the Internet topology is determined.
When originally proposed in [RFC1338] and [RFC1519], this addressing When originally proposed in [RFC1338] and [RFC1519], this addressing
plan was intended to be a relatively short-term response, lasting plan was intended to be a relatively short-term response, lasting
approximately three to five years during which a more permanent approximately three to five years, during which a more permanent
addressing and routing architecture would be designed and addressing and routing architecture would be designed and
implemented. As can be inferred from the dates on the original implemented. As can be inferred from the dates on the original
documents, CIDR has far outlasted its anticipated lifespan and has documents, CIDR has far outlasted its anticipated lifespan and has
become the mid-term solution to the problems described above. become the mid-term solution to the problems described above.
It should be noted that in the following text, we describe the Note that in the following text we describe the current policies and
current policies and procedures that have been put in place to procedures that have been put in place to implement the allocation
implement the allocation architecture discussed here. This architecture discussed here. This description is not intended to be
description is not intended to be interpreted as direction to IANA. interpreted as direction to IANA.
Coupled with address management strategies implemented by the Coupled with address management strategies implemented by the
Regional Internet Registries (see [NRO] for details), the deployment Regional Internet Registries (see [NRO] for details), the deployment
of CIDR-style addressing has also reduced the rate at which IPv4 of CIDR-style addressing has also reduced the rate at which IPv4
address space has been consumed, thus providing short-to-medium-term address space has been consumed, thus providing short- to medium-term
relief to problem #3 described above. relief to problem #3, described above.
Note that, as defined, this plan neither requires nor assumes the re- Note that, as defined, this plan neither requires nor assumes the
assignment of those parts of the legacy "class C" space that are not re-assignment of those parts of the legacy "Class C" space that are
amenable to aggregation (sometimes called "the swamp"). Doing so not amenable to aggregation (sometimes called "the swamp"). Doing so
would somewhat reduce routing table sizes (current estimate is that would somewhat reduce routing table sizes (current estimate is that
"the swamp" contains approximately 15,000 entries) though at a "the swamp" contains approximately 15,000 entries), though at a
significant renumbering cost. Similarly, there is no hard significant renumbering cost. Similarly, there is no hard
requirement that any end site renumber when changing transit service requirement that any end site renumber when changing transit service
provider but end sites are encouraged do so to eliminate the need for provider, but end sites are encouraged do so to eliminate the need
explicit advertisement of their prefixes into the global routing for explicit advertisement of their prefixes into the global routing
system. system.
3.1. Basic concept and prefix notation 3.1. Basic Concept and Prefix Notation
In the simplest sense, the change from Class A/B/C network numbers to 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 classless prefixes is to make explicit which bits in a 32-bit IPv4
address are interpreted as the network number (or prefix) associated address are interpreted as the network number (or prefix) associated
with a site and which are the used to number individual end systems 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 within the site. In CIDR notation, a prefix is shown as a 4-octet
quantity, just like a traditional IPv4 address or network number, quantity, just like a traditional IPv4 address or network number,
followed by the "/" (slash) character, followed by a decimal value followed by the "/" (slash) character, followed by a decimal value
between 0 and 32 that describes the number of significant bits. 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 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, 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 "/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 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 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 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 192.168.99.0/24; the most significant 24 bits are ones and the least
significant 8 bits are zeros. significant 8 bits are zeros.
Using classless prefixes with explicit prefix lengths allows much Using classless prefixes with explicit prefix lengths allows much
more flexible matching of address space blocks to actual need. Where more flexible matching of address space blocks according to actual
formerly only three network sizes were available, prefixes may be need. Where formerly only three network sizes were available,
defined to describe any power-of-two-sized block of between one and prefixes may be defined to describe any power of two-sized block of
2^32 end system addresses. In practice, the unallocated pool of between one and 2^32 end system addresses. In practice, the
addresses is administered by the Internet Assigned Numbers Authority unallocated pool of addresses is administered by the Internet
([IANA]). The IANA makes allocations from this pool to Regional Assigned Numbers Authority ([IANA]). The IANA makes allocations from
Internet Registries, as required. These allocations are made in this pool to Regional Internet Registries, as required. These
contiguous bit-aligned blocks of 2^24 addresses (a.k.a. /8 prefixes). allocations are made in contiguous bit-aligned blocks of 2^24
The RIRs, in turn, allocate or assign smaller address blocks to Local 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). Internet Registries (LIRs) or Internet Service Providers (ISPs).
These entities may make direct use of the assignment (as would These entities may make direct use of the assignment (as would
commonly be the case for an ISP) or may make further sub-allocations commonly be the case for an ISP) or may make further sub-allocations
of addresses to their customers. These RIR address assignments vary of addresses to their customers. These RIR address assignments vary
according to the needs of each ISP or LIR. For example, a large ISP 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) might be allocated an address block of 2^17 addresses (a /15 prefix),
while a smaller ISP may be allocated an address block of 2^11 whereas a smaller ISP may be allocated an address block of 2^11
addresses (a /21 prefix). addresses (a /21 prefix).
Note that the terms "allocate" and "assign" have specific meaning in Note that the terms "allocate" and "assign" have specific meaning in
the Internet address registry system; "allocate" refers to the the Internet address registry system; "allocate" refers to the
delegation of a block of address space to an organization which is delegation of a block of address space to an organization that is
expected to perform further sub-delegations while "assign" is used expected to perform further sub-delegations, and "assign" is used for
for sites that directly use (i.e. number individual hosts) the block sites that directly use (i.e., number individual hosts) the block of
of addresses received. addresses received.
The following table provides a convenient short-cut to all of the The following table provides a convenient shortcut to all the CIDR
CIDR prefix sizes, showing the number of addresses possible in each prefix sizes, showing the number of addresses possible in each prefix
prefix and the number of prefixes of that size that may be numbered and the number of prefixes of that size that may be numbered in the
in the 32-bit IPv4 address space: 32-bit IPv4 address space:
notation addrs/block # blocks notation addrs/block # blocks
-------- ----------- ---------- -------- ----------- ----------
n.n.n.n/32 1 4294967296 "host route" n.n.n.n/32 1 4294967296 "host route"
n.n.n.x/31 2 2147483648 "p2p link" n.n.n.x/31 2 2147483648 "p2p link"
n.n.n.x/30 4 1073741824 n.n.n.x/30 4 1073741824
n.n.n.x/29 8 536870912 n.n.n.x/29 8 536870912
n.n.n.x/28 16 268435456 n.n.n.x/28 16 268435456
n.n.n.x/27 32 134217728 n.n.n.x/27 32 134217728
n.n.n.x/26 64 67108864 n.n.n.x/26 64 67108864
n.n.n.x/25 128 33554432 n.n.n.x/25 128 33554432
n.n.n.0/24 256 16777216 legacy "class C" n.n.n.0/24 256 16777216 legacy "Class C"
n.n.x.0/23 512 8388608 n.n.x.0/23 512 8388608
n.n.x.0/22 1024 4194304 n.n.x.0/22 1024 4194304
n.n.x.0/21 2048 2097152 n.n.x.0/21 2048 2097152
n.n.x.0/20 4096 1048576 n.n.x.0/20 4096 1048576
n.n.x.0/19 8192 524288 n.n.x.0/19 8192 524288
n.n.x.0/18 16384 262144 n.n.x.0/18 16384 262144
n.n.x.0/17 32768 131072 n.n.x.0/17 32768 131072
n.n.0.0/16 65536 65536 legacy "class B" n.n.0.0/16 65536 65536 legacy "Class B"
n.x.0.0/15 131072 32768 n.x.0.0/15 131072 32768
n.x.0.0/14 262144 16384 n.x.0.0/14 262144 16384
n.x.0.0/13 524288 8192 n.x.0.0/13 524288 8192
n.x.0.0/12 1048576 4096 n.x.0.0/12 1048576 4096
n.x.0.0/11 2097152 2048 n.x.0.0/11 2097152 2048
n.x.0.0/10 4194304 1024 n.x.0.0/10 4194304 1024
n.x.0.0/9 8388608 512 n.x.0.0/9 8388608 512
n.0.0.0/8 16777216 256 legacy "class A" n.0.0.0/8 16777216 256 legacy "Class A"
x.0.0.0/7 33554432 128 x.0.0.0/7 33554432 128
x.0.0.0/6 67108864 64 x.0.0.0/6 67108864 64
x.0.0.0/5 134217728 32 x.0.0.0/5 134217728 32
x.0.0.0/4 268435456 16 x.0.0.0/4 268435456 16
x.0.0.0/3 536870912 8 x.0.0.0/3 536870912 8
x.0.0.0/2 1073741824 4 x.0.0.0/2 1073741824 4
x.0.0.0/1 2147483648 2 x.0.0.0/1 2147483648 2
0.0.0.0/0 4294967296 1 "default route" 0.0.0.0/0 4294967296 1 "default route"
n is an 8-bit, decimal octet value. Point to point links are n is an 8-bit decimal octet value. Point-to-point links are
discussed in more detail in [RFC3021]. discussed in more detail in [RFC3021].
x is a 1 to 7 bit value, base on the prefix length, shifted into the x is a 1- to 7-bit value, based on the prefix length, shifted into
most significant bits of the octet and converted into decimal form; the most significant bits of the octet and converted into decimal
the least significant bits of the octet are zero. form; the least significant bits of the octet are zero.
In practice, prefixes of length shorter than 8 have not been In practice, prefixes of length shorter than 8 have not been
allocated or assigned to date, although routes to such short prefixes allocated or assigned to date, although routes to such short prefixes
may exist in routing tables if or when aggressive aggregation is may exist in routing tables if or when aggressive aggregation is
performed. As of the writing of this document, no such routes are performed. As of the writing of this document, no such routes are
seen in the global routing system but operator error and other events seen in the global routing system, but operator error and other
have caused some of them (i.e. 128.0.0.0/1 and 192.0.0.0/2) to be events have caused some of them (i.e., 128.0.0.0/1 and 192.0.0.0/2)
observed in some networks at some times in the past. to be observed in some networks at some times in the past.
4. Address assignment and routing aggregation 4. Address Assignment and Routing Aggregation
Classless addressing and routing was initially developed primarily to Classless addressing and routing was initially developed primarily to
improve the scaling properties of routing on the global Internet. improve the scaling properties of routing on the global Internet.
Because the scaling of routing is very tightly coupled to the way Because the scaling of routing is very tightly coupled to the way
that addresses are used, deployment of CIDR had implications for the that addresses are used, deployment of CIDR had implications for the
way in which addresses were assigned. way in which addresses were assigned.
4.1. Aggregation efficiency and limitations 4.1. Aggregation Efficiency and Limitations
The only commonly-understood method for reducing routing state on a The only commonly understood method for reducing routing state on a
packet-switched network is through aggregation of information. For packet-switched network is through aggregation of information. For
CIDR to succeed in reducing the size and growth rate of the global CIDR to succeed in reducing the size and growth rate of the global
routing system, the IPv4 address assignment process needed to be routing system, the IPv4 address assignment process needed to be
changed to make possible the aggregation of routing information along changed to make possible the aggregation of routing information along
topological lines. Since, in general, the topology of the network is topological lines. Since, in general, the topology of the network is
determined by the service providers who have built it, topologically- determined by the service providers who have built it, topologically
significant address assignments are necessarily service-provider significant address assignments are necessarily service-provider
oriented. oriented.
Aggregation is simple for an end site which is connected to one Aggregation is simple for an end site that is connected to one
service provider: it uses address space assigned by its service service provider: it uses address space assigned by its service
provider and that address space is a small piece of a larger block provider, and that address space is a small piece of a larger block
allocated to the service provider. No explicit route is needed for allocated to the service provider. No explicit route is needed for
the end site - the service provider advertises a single aggregate the end site; the service provider advertises a single aggregate
route for the larger block; this advertisement provides reachability route for the larger block. This advertisement provides reachability
and routeability for all of the customers numbered in the block. and routeability for all the customers numbered in the block.
There are two, more complex, situations that reduce the effectiveness There are two, more complex, situations that reduce the effectiveness
of aggregation: of aggregation:
o An organization which is multi-homed. Because a multi-homed o An organization that is multi-homed. Because a multi-homed
organization must be advertised into the system by each of its organization must be advertised into the system by each of its
service providers, it is often not feasible to aggregate its service providers, it is often not feasible to aggregate its
routing information into the address space of any one of those routing information into the address space of any one of those
providers. Note that the organization still may receive its providers. Note that the organization still may receive its
address assignment out of a service provider's address space address assignment out of a service provider's address space
(which has other advantages), but a route to the organization's (which has other advantages), but that a route to the
prefix is, in the most general case, explicitly advertised by all organization's prefix is, in the most general case, explicitly
of its service providers. For this reason, the global routing advertised by all of its service providers. For this reason, the
cost for a multi-homed organization is generally the same as it global routing cost for a multi-homed organization is generally
was prior to the adoption of CIDR. A more detailed consideration the same as it was prior to the adoption of CIDR. A more detailed
of multi-homing practices can be found in [RFC4116]. consideration of multi-homing practices can be found in [RFC4116].
o An organization which changes service provider but does not o An organization that changes service provider but does not
renumber. This has the effect of "punching a hole" in one of the renumber. This has the effect of "punching a hole" in one of the
original service provider's aggregated route advertisements. CIDR original service provider's aggregated route advertisements. CIDR
handles this situation by requiring the newer service provider to handles this situation by requiring that the newer service
advertise a specific advertisement for the re-homed organization; provider to advertise a specific advertisement for the re-homed
this advertisement is preferred over provider aggregates because organization; this advertisement is preferred over provider
it is a longer match. To maintain efficiency of aggregation, it aggregates because it is a longer match. To maintain efficiency
is recommended that an organization which changes service of aggregation, it is recommended that an organization that
providers plan to eventually migrate its network into a an prefix changes service providers plan eventually to migrate its network
assigned from its new provider's address space. To this end, it into a an prefix assigned from its new provider's address space.
is recommended that mechanisms to facilitate such migration, such To this end, it is recommended that mechanisms to facilitate such
as dynamic host address assignment using [RFC2131]) be deployed migration, such as dynamic host address assignment that uses
wherever possible, and that additional protocol work be done to [RFC2131]), be deployed wherever possible, and that additional
develop improved technology for renumbering. protocol work be done to develop improved technology for
renumbering.
Note that some aggregation efficiency gain can still be had for Note that some aggregation efficiency gain can still be had for
multi-homed sites (and, in general, for any site composed of multi-homed sites (and, in general, for any site composed of
multiple, logical IPv4 networks) - by allocating a contiguous power- multiple, logical IPv4 networks); by allocating a contiguous power-
of-two block address space to the site (as opposed to multiple, of-two block address space to the site (as opposed to multiple,
independent prefixes) the site's routing information may be independent prefixes), the site's routing information may be
aggregated into a single prefix. Also, since the routing cost aggregated into a single prefix. Also, since the routing cost
associated with assigning a multi-homed site out of a service associated with assigning a multi-homed site out of a service
provider's address space is no greater than the old method of provider's address space is no greater than the old method of
sequential number assignment by a central authority, it makes sense sequential number assignment by a central authority, it makes sense
to assign all end-site address space out of blocks allocated to to assign all end-site address space out of blocks allocated to
service providers. service providers.
It is also worthwhile to mention that since aggregation may occur at It is also worthwhile to mention that since aggregation may occur at
multiple levels in the system, it may still be possible to aggregate multiple levels in the system, it may still be possible to aggregate
these anomalous routes at higher levels of whatever hierarchy may be these anomalous routes at higher levels of whatever hierarchy may be
present. For example, if a site is multi-homed to two relatively present. For example, if a site is multi-homed to two relatively
small providers that both obtain connectivity and address space from small providers that both obtain connectivity and address space from
the same large provider, then aggregation by the large provider of the same large provider, then aggregation by the large provider of
routes from the smaller networks will include all routes to the routes from the smaller networks will include all routes to the
multi-homed site. The feasibility of this sort of second-level multi-homed site. The feasibility of this sort of second-level
aggregation depends on whether topological hierarchy exists between a aggregation depends on whether topological hierarchy exists among a
site, its directly-connected providers, and other providers to which site, its directly-connected providers, and other providers to which
they are connected; it may be practical in some regions of the global they are connected; it may be practical in some regions of the global
Internet but not in others. Internet but not in others.
Note: in the discussion and examples which follow, prefix notation is Note: In the discussion and examples that follow, prefix notation is
used to represent routing destinations. This is used for used to represent routing destinations. This is used for
illustration only and does not require that routing protocols use illustration only and does not require that routing protocols use
this representation in their updates. this representation in their updates.
4.2. Distributed assignment of address space 4.2. Distributed Assignment of Address Space
In the early days of the Internet, IPv4 address space assignment was In the early days of the Internet, IPv4 address space assignment was
performed by the central Network Information Center (NIC). Class performed by the central Network Information Center (NIC). Class
A/B/C network numbers were assigned in essentially arbitrary order, A/B/C network numbers were assigned in essentially arbitrary order,
roughly according to the size of the organizations that requested roughly according to the size of the organizations that requested
them. All assignments were recorded centrally and no attempt was them. All assignments were recorded centrally, and no attempt was
made to assign network numbers in a manner that would allow routing made to assign network numbers in a manner that would allow routing
aggregation. aggregation.
When CIDR was originally deployed, the central assignment authority When CIDR was originally deployed, the central assignment authority
continued to exist but changed its procedures to assign large blocks continued to exist but changed its procedures to assign large blocks
of "Class C" network numbers to each service provider. Each service of "Class C" network numbers to each service provider. Each service
provider, in turn, assigned bitmask-oriented subsets of the provider, in turn, assigned bitmask-oriented subsets of the
provider's address space to each customer. This worked reasonably provider's address space to each customer. This worked reasonably
well as long as the number of service providers was relatively small well, as long as the number of service providers was relatively small
and relatively constant but did not scale well as the number of and relatively constant, but it did not scale well, as the number of
service providers grew at a rapid rate. service providers grew at a rapid rate.
As the Internet started to expand rapidly in the 1990s, it became As the Internet started to expand rapidly in the 1990s, it became
clear that a single, centralized address assignment authority was clear that a single, centralized address assignment authority was
problematic. This function began being de-centralized when address problematic. This function began being de-centralized when address
space assignment for European Internet sites was delegated in bit- space assignment for European Internet sites was delegated in bit-
aligned blocks of 16777216 addresses (what CIDR would later define as aligned blocks of 16777216 addresses (what CIDR would later define as
a /8) to the RIPE NCC ([RIPE]), effectively making it the first of a /8) to the RIPE NCC ([RIPE]), effectively making it the first of
the RIRs. Since then, address assignment has been formally the RIRs. Since then, address assignment has been formally
distributed as a hierarchical function with IANA, the RIRs, and the distributed as a hierarchical function with IANA, the RIRs, and the
service providers. Removing the bottleneck of a single organization service providers. Removing the bottleneck of a single organization
having responsibility for the global Internet address space greatly having responsibility for the global Internet address space greatly
improved the efficiency and response time for new assignments. improved the efficiency and response time for new assignments.
Hierarchical delegation of addresses in this manner implies that Hierarchical delegation of addresses in this manner implies that
sites with addresses assigned out of a given service provider are, sites with addresses assigned out of a given service provider are,
for routing purposes, part of that service provider and will be for routing purposes, part of that service provider and will be
routed via its infrastructure. This implies that routing information routed via its infrastructure. This implies that routing information
about multi-homed organizations, i.e., organizations connected to about multi-homed organizations (i.e., organizations connected to
more than one network service provider, will still need to be known more than one network service provider) will still need to be known
by higher levels in the hierarchy. by higher levels in the hierarchy.
A historical perspective on these issues is described in [RFC1518]. A historical perspective on these issues is described in [RFC1518].
Additional discussion may also be found in [RFC3221]. Additional discussion may also be found in [RFC3221].
5. Routing implementation considerations 5. Routing Implementation Considerations
With the change from classful network numbers to classless prefixes, With the change from classful network numbers to classless prefixes,
it is not possible to infer the network mask from the initial bit it is not possible to infer the network mask from the initial bit
pattern of an IPv4 address. This has implications for how routing pattern of an IPv4 address. This has implications for how routing
information is stored and propagated. Network masks or prefix information is stored and propagated. Network masks or prefix
lengths must be explicitly carried in routing protocols. Interior lengths must be explicitly carried in routing protocols. Interior
routing protocols such as OSPF [RFC2178], IS-IS [RFC1195], RIPv2 routing protocols, such as OSPF [RFC2328], Intermediate System to
[RFC2453], and Cisco EIGRP, and the BGP4 exterior routing protocol Intermediate System (IS-IS) [RFC1195], RIPv2 [RFC2453], and Cisco
[RFC4271] all support this functionality, having been developed or Enhanced Interior Gateway Routing Protocol (EIGRP), and the BGP4
modified as part of the deployment of classless inter-domain routing exterior routing protocol [RFC4271], all support this functionality,
during the 1990s. having been developed or modified as part of the deployment of
classless inter-domain routing during the 1990s.
Older interior routing protocols, such as RIP [RFC1058], HELLO, and Older interior routing protocols, such as RIP [RFC1058], HELLO, and
Cisco IGRP, and older exterior routing protocols, such as EGP Cisco Interior Gateway Routing Protocol (IGRP), and older exterior
[RFC904], do not support explicit carriage of prefix length/mask and routing protocols, such as Exterior Gateway Protocol (EGP) [RFC904],
thus cannot be effectively used on the Internet in other than very do not support explicit carriage of prefix length/mask and thus
limited, stub configurations. While their use may be appropriate in cannot be effectively used on the Internet other than in very limited
simple, legacy end-site configurations, they are considered obsolete stub configurations. Although their use may be appropriate in simple
and should NOT be used in transit networks connected to the global legacy end-site configurations, they are considered obsolete and
should NOT be used in transit networks connected to the global
Internet. Internet.
Similarly, routing and forwarding tables in layer-3 network equipment Similarly, routing and forwarding tables in layer-3 network equipment
must be organized to store both prefix and prefix length or mask. must be organized to store both prefix and prefix length or mask.
Equipment which organizes its routing/forwarding information Equipment that organizes its routing/forwarding information according
according to legacy class A/B/C network/subnet conventions cannot be to legacy Class A/B/C network/subnet conventions cannot be expected
expected to work correctly on networks connected to the global to work correctly on networks connected to the global Internet; use
Internet; use of such equipment is not recommended. Fortunately, of such equipment is not recommended. Fortunately, very little such
very little such equipment is in use today. equipment is in use today.
5.1. Rules for route advertisement 5.1. Rules for Route Advertisement
1. Forwarding in the Internet is done on a longest-match basis. 1. Forwarding in the Internet is done on a longest-match basis.
This implies that destinations which are multi-homed relative to This implies that destinations that are multi-homed relative to a
a routing domain must always be explicitly announced into that routing domain must always be explicitly announced into that
routing domain - they cannot be summarized (this makes intuitive routing domain (i.e., they cannot be summarized). If a network
sense - if a network is multi-homed, all of its paths into a is multi-homed, all of its paths into a routing domain that is
routing domain which is "higher" in the hierarchy of networks "higher" in the hierarchy of networks must be known to the
must be known to the "higher" network). "higher" network).
2. A router which generates an aggregate route for multiple, more- 2. A router that generates an aggregate route for multiple, more-
specific routes must discard packets which match the aggregate specific routes must discard packets that match the aggregate
route but not any of the more-specific routes. In other words, route, but not any of the more-specific routes. In other words,
the "next hop" for the aggregate route should be the null the "next hop" for the aggregate route should be the null
destination. This is necessary to prevent forwarding loops when destination. This is necessary to prevent forwarding loops when
some addresses covered by the aggregate are not reachable. some addresses covered by the aggregate are not reachable.
Note that during failures, partial routing of traffic to a site which Note that during failures, partial routing of traffic to a site that
takes its address space from one service provider but which is takes its address space from one service provider but that is
actually reachable only through another (i.e., the case of a site actually reachable only through another (i.e., the case of a site
which has changed service providers) may occur because such traffic that has changed service providers) may occur because such traffic
will be forwarded along the path advertised by the aggregated route. will be forwarded along the path advertised by the aggregated route.
Rule #2 will prevent packet mis-delivery by causing such traffic to Rule #2 will prevent packet misdelivery by causing such traffic to be
be discarded by the advertiser of the aggregated route, but the discarded by the advertiser of the aggregated route, but the output
output of "traceroute" and other similar tools will suggest that a of "traceroute" and other similar tools will suggest that a problem
problem exists within that network rather than in the network which exists within that network rather than in the network that is no
is no longer advertising the more-specific prefix. This may be longer advertising the more-specific prefix. This may be confusing
confusing to those trying to diagnose connectivity problems; see the to those trying to diagnose connectivity problems; see the example in
example in Section 6.2 for details. A solution to this perceived Section 6.2 for details. A solution to this perceived "problem" is
"problem" is beyond the scope of this document - it lies with better beyond the scope of this document; it lies with better education of
education of the user/operator community, not in routing technology. the user/operator community, not in routing technology.
An implementation following these rules should also be generalized, An implementation following these rules should also be generalized,
so that an arbitrary network number and mask are accepted for all so that an arbitrary network number and mask are accepted for all
routing destinations. The only outstanding constraint is that the routing destinations. The only outstanding constraint is that the
mask must be left contiguous. Note that the degenerate route to mask must be left contiguous. Note that the degenerate route to
prefix 0.0.0.0/0 is used as a default route and MUST be accepted by prefix 0.0.0.0/0 is used as a default route and MUST be accepted by
all implementations. Further, to protect against accidental all implementations. Further, to protect against accidental
advertisements of this route via the inter-domain protocol, this advertisements of this route via the inter-domain protocol, this
route should only be advertised to another routing domain when a route should only be advertised to another routing domain when a
router is explicitly configured to do so - never as a non-configured, router is explicitly configured to do so, never as a non-configured,
"default" option. "default" option.
5.2. How the rules work 5.2. How the Rules Work
Rule #1 guarantees that the forwarding algorithm used is consistent Rule #1 guarantees that the forwarding algorithm used is consistent
across routing protocols and implementations. Multi-homed networks across routing protocols and implementations. Multi-homed networks
are always explicitly advertised by every service provider through are always explicitly advertised by every service provider through
which they are routed even if they are a specific subset of one which they are routed, even if they are a specific subset of one
service provider's aggregate (if they are not, they clearly must be service provider's aggregate (if they are not, they clearly must be
explicitly advertised). It may seem as if the "primary" service explicitly advertised). It may seem as if the "primary" service
provider could advertise the multi-homed site implicitly as part of provider could advertise the multi-homed site implicitly as part of
its aggregate, but longest-match forwarding causes this not to work. its aggregate, but longest-match forwarding causes this not to work.
More details are provided in [RFC4116]. More details are provided in [RFC4116].
Rule #2 guarantees that no routing loops form due to aggregation. Rule #2 guarantees that no routing loops form due to aggregation.
Consider a site that has been assigned 192.168.64/19 by its "parent" Consider a site that has been assigned 192.168.64/19 by its "parent"
provider that has 192.168.0.0/16. The "parent" network will provider, which has 192.168.0.0/16. The "parent" network will
advertise 192.168.0.0/16 to the "child" network. If the "child" advertise 192.168.0.0/16 to the "child" network. If the "child"
network were to lose internal connectivity to 192.168.65.0/24 (which network were to lose internal connectivity to 192.168.65.0/24 (which
is part of its aggregate), traffic from the "parent" to the to the is part of its aggregate), traffic from the "parent" to the to the
"child" destined for 192.168.65.1 will follow the "child's" "child" destined for 192.168.65.1 will follow the "child's"
advertised route. When that traffic gets to the "child", however, advertised route. When that traffic gets to the "child", however,
the child *must not* follow the route 192.168.0.0/16 back up to the the child *must not* follow the route 192.168.0.0/16 back up to the
"parent", since that would result in a forwarding loop. Rule #2 says "parent", since that would result in a forwarding loop. Rule #2 says
that the "child" may not follow a less-specific route for a that the "child" may not follow a less-specific route for a
destination which matches one of its own aggregated routes destination that matches one of its own aggregated routes (typically,
(typically, this is implemented by installing a "discard" or "null" this is implemented by installing a "discard" or "null" route for all
route for all aggregated prefixes which one network advertises to aggregated prefixes that one network advertises to another). Note
another). Note that handling of the "default" route (0.0.0.0/0) is a that handling of the "default" route (0.0.0.0/0) is a special case of
special case of this rule - a network must not follow the default to this rule; a network must not follow the default to destinations that
destinations which are part of one of it's aggregated advertisements. are part of one of its aggregated advertisements.
5.3. A note on prefix filter formats 5.3. A Note on Prefix Filter Formats
Systems which process route announcements must be able to verify that Systems that process route announcements must be able to verify that
information which they receive is acceptable according to policy information that they receive is acceptable according to policy
rules. Implementations which filter route advertisements must allow rules. Implementations that filter route advertisements must allow
masks or prefix lengths in filter elements. Thus, filter elements masks or prefix lengths in filter elements. Thus, filter elements
which formerly were specified as: that formerly were specified as
accept 172.16.0.0 accept 172.16.0.0
accept 172.25.120.0.0 accept 172.25.120.0.0
accept 172.31.0.0 accept 172.31.0.0
deny 10.2.0.0 deny 10.2.0.0
accept 10.0.0.0 accept 10.0.0.0
now look something like: now look something like this:
accept 172.16.0.0/16 accept 172.16.0.0/16
accept 172.25.0.0/16 accept 172.25.0.0/16
accept 172.31.0.0/16 accept 172.31.0.0/16
deny 10.2.0.0/16 deny 10.2.0.0/16
accept 10.0.0.0/8 accept 10.0.0.0/8
This is merely making explicit the network mask which was implied by This is merely making explicit the network mask that was implied by
the class A/B/C classification of network numbers. It is also useful the Class A/B/C classification of network numbers. It is also useful
to enhance filtering capability to allow the match of a prefix and to enhance filtering capability to allow the match of a prefix and
all more-specific prefixes with the same bit pattern; fortunately, all more-specific prefixes with the same bit pattern; fortunately,
this functionality has been implemented by most vendors of equipment this functionality has been implemented by most vendors of equipment
used on the Internet. used on the Internet.
5.4. Responsibility for and configuration of aggregation 5.4. Responsibility for and Configuration of Aggregation
Under normal circumstances, a routing domain (or "Autonomous System") Under normal circumstances, a routing domain (or "Autonomous System")
which has been allocated or assigned a set of prefixes has sole that has been allocated or assigned a set of prefixes has sole
responsibility for aggregation of those prefixes. In the usual case, responsibility for aggregation of those prefixes. In the usual case,
the AS will install configuration in one or more of its routers to the AS will install configuration in one or more of its routers to
generate aggregate routes based on more-specific routes known to its generate aggregate routes based on more-specific routes known to its
internal routing system; these aggregate routes are advertised into internal routing system. These aggregate routes are advertised into
the global routing system by the border routers for the routing the global routing system by the border routers for the routing
domain. The more-specific internal routes which overlap with the domain. The more-specific internal routes that overlap with the
aggregate routes should not be advertised globally. In some cases, aggregate routes should not be advertised globally. In some cases,
an AS may wish to delegate aggregation responsibility to another AS an AS may wish to delegate aggregation responsibility to another AS
(for example, a customer may wish for its service provider to (for example, a customer may wish for its service provider to
generate aggregated routing information on its behalf); in such generate aggregated routing information on its behalf); in such
cases, aggregation is performed by a router in the second AS based on cases, aggregation is performed by a router in the second AS
the routes that it receives from the first combined with configured according to the routes that it receives from the first, combined
policy information describing how those routes should be aggregated. with configured policy information describing how those routes should
be aggregated.
It should be mentioned that one provider may choose to perform Note that one provider may choose to perform aggregation on the
aggregation on the routes it receives from another without explicit routes it receives from another without explicit agreement; this is
agreement; this is termed "proxy aggregation". This can be a useful termed "proxy aggregation". This can be a useful tool for reducing
tool for reducing the amount of routing state that an AS must carry the amount of routing state that an AS must carry and propagate to
and propagate to its customers and neighbors. However, proxy its customers and neighbors. However, proxy aggregation can also
aggregation can also create unintended consequences in traffic create unintended consequences in traffic engineering. Consider what
engineering. Consider what happens if both AS 2 and 3 receive routes happens if both AS 2 and 3 receive routes from AS 1 but AS 2 performs
from AS 1 but AS 2 performs proxy aggregation while AS 3 does not. proxy aggregation while AS 3 does not. Other ASes that receive
Other AS's which receive transit routing information from both AS 2 transit routing information from both AS 2 and AS 3 will see an
and AS 3 will see an inconsistent view of the routing information inconsistent view of the routing information originated by AS 1.
originated by AS 1. This may cause an unexpected shift of traffic This may cause an unexpected shift of traffic toward AS 1 through AS
toward AS 1 through AS 3 for AS 3's customers and any others 3 for AS 3's customers and any others receiving transit routes from
receiving transit routes from AS 3. Because proxy aggregation can AS 3. Because proxy aggregation can cause unanticipated consequences
cause unanticipated consequences for parts of the Internet that have for parts of the Internet that have no relationship with either the
no relationship with either the source of the aggregated routes or source of the aggregated routes or the party providing aggregation,
the party providing aggregation, it should be used with extreme it should be used with extreme caution.
caution.
Configuration of the routes to be combined into aggregates is an Configuration of the routes to be combined into aggregates is an
implementation of routing policy and does require some manually- implementation of routing policy and requires some manually
maintained information. As an addition to the information that must maintained information. As an addition to the information that must
be maintained for a set of routeable prefixes, aggregation be maintained for a set of routeable prefixes, aggregation
configuration is typically just a line or two defining the range of configuration is typically just a line or two defining the range of
the block of IPv4 addresses to aggregate. A site performing its own the block of IPv4 addresses to be aggregated. A site performing its
aggregation is doing so for address blocks that it has been assigned; own aggregation is doing so for address blocks that it has been
a site performing aggregation on behalf of another knows this assigned; a site performing aggregation on behalf of another knows
information based on an agreement to delegate aggregation. Assuming this information because of an agreement to delegate aggregation.
that the best common practice for network administrators is to Assuming that the best common practice for network administrators is
exchange lists of prefixes to accept from each other, configuration to exchange lists of prefixes to accept from each other,
of aggregation information does not introduce significant additional configuration of aggregation information does not introduce
administrative overhead. significant additional administrative overhead.
The generation of an aggregate route is usually specified either The generation of an aggregate route is usually specified either
statically or in response to learning an active dynamic route for a statically or in response to learning an active dynamic route for a
prefix contained within the aggregate route. If such dynamic prefix contained within the aggregate route. If such dynamic
aggregate route advertisement is done, care should be taken that aggregate route advertisement is done, care should be taken that
routes are not excessively added or withdrawn (known as "route routes are not excessively added or withdrawn (known as "route
flapping"); in general, a dynamic aggregate route advertisement is flapping"). In general, a dynamic aggregate route advertisement is
added when at least one component of the aggregate becomes reachable added when at least one component of the aggregate becomes reachable
and it is withdrawn only when all components become unreachable. and it is withdrawn only when all components become unreachable.
Properly configured, aggregated routes are more stable than non- Properly configured, aggregated routes are more stable than non-
aggregated routes and thus improve global routing stability. aggregated routes and thus improve global routing stability.
Implementation note: aggregation of the "Class D" (multicast) address Implementation note: Aggregation of the "Class D" (multicast) address
space is beyond the scope of this document. space is beyond the scope of this document.
5.5. Route propagation and routing protocol considerations 5.5. Route Propagation and Routing Protocol Considerations
Prior to the original deployment of CIDR, common practice was to Prior to the original deployment of CIDR, common practice was to
propagate routes learned via exterior routing protocols (i.e. EGP or propagate routes learned via exterior routing protocols (i.e., EGP or
BGP) through a site's interior routing protocol (typically, OSPF, BGP) through a site's interior routing protocol (typically, OSPF,
IS-IS, or RIP). This was done to ensure that consistent and correct IS-IS, or RIP). This was done to ensure that consistent and correct
exit points were chosen for traffic destined to a destination learned exit points were chosen for traffic to be sent to a destination
through those protocols. Four evolutionary effects -- the advent of learned through those protocols. Four evolutionary effects -- the
CIDR, explosive growth of global routing state, widespread adoption advent of CIDR, explosive growth of global routing state, widespread
of BGP4, and a requirement to propagate full path information -- have adoption of BGP4, and a requirement to propagate full path
combined to deprecate that practice. To ensure proper path information -- have combined to deprecate that practice. To ensure
propagation and prevent inter-AS routing inconsistency (BGP4's loop proper path propagation and prevent inter-AS routing inconsistency
detection/prevention mechanism requires full path propagation), (BGP4's loop detection/prevention mechanism requires full path
transit networks must use internal BGP (iBGP) for carrying routes propagation), transit networks must use internal BGP (iBGP) for
learned from other providers both within and through their networks. carrying routes learned from other providers both within and through
their networks.
6. Example of new address assignments and routing 6. Example of New Address Assignments and Routing
6.1. Address delegation 6.1. Address Delegation
Consider the block of 524288 (2^19) addresses beginning with Consider the block of 524288 (2^19) addresses, beginning with
10.24.0.0 and ending with 10.31.255.255 allocated to a single network 10.24.0.0 and ending with 10.31.255.255, allocated to a single
provider, "PA". This is equivalent in size to a block of 2048 legacy network provider, "PA". This is equivalent in size to a block of
"class C" network numbers (or /24s). A classless route to this block 2048 legacy "Class C" network numbers (or /24s). A classless route
would be described as 10.24.0.0 with mask of 255.248.0.0 the prefix to this block would be described as 10.24.0.0 with a mask of
10.24.0.0/13. 255.248.0.0 and the prefix 10.24.0.0/13.
Assume this service provider connects six sites in the following Assume that this service provider connects six sites in the following
order (significant because it demonstrates how temporary "holes" may order (significant because it demonstrates how temporary "holes" may
form in the service provider's address space): form in the service provider's address space):
o "C1" requiring fewer than 2048 addresses (/21 or 8 x /24) o "C1", requiring fewer than 2048 addresses (/21 or 8 x /24)
o "C2" requiring fewer than 4096 addresses (/20 or 16 x /24) o "C2", requiring fewer than 4096 addresses (/20 or 16 x /24)
o "C3" requiring fewer than 1024 addresses (/22 or 4 x /24) o "C3", requiring fewer than 1024 addresses (/22 or 4 x /24)
o "C4" requiring fewer than 1024 addresses (/22 or 4 x /24) o "C4", requiring fewer than 1024 addresses (/22 or 4 x /24)
o "C5" requiring fewer than 512 addresses (/23 or 2 x /24) o "C5", requiring fewer than 512 addresses (/23 or 2 x /24)
o "C6" requiring fewer than 512 addresses (/23 or 2 x /24) o "C6", requiring fewer than 512 addresses (/23 or 2 x /24)
In all cases, the number of IPv4 addresses "required" by each site is In all cases, the number of IPv4 addresses "required" by each site is
assumed to allow for significant growth. The service provider assumed to allow for significant growth. The service provider
delegates its address space as follows: delegates its address space as follows:
o C1: assign 10.24.0 through 10.24.7. This block of networks is o C1. assign 10.24.0 through 10.24.7. This block of networks is
described by the route 10.24.0.0/21 (mask 255.255.248.0) described by the route 10.24.0.0/21 (mask 255.255.248.0).
o C2: assign 10.24.16 through 10.24.31. This block is described by
the route 10.24.16.0/20 (mask 255.255.240.0)
o C3: assign 10.24.8 through 10.24.11. This block is described by o C2. Assign 10.24.16 through 10.24.31. This block is described by
the route 10.24.8.0/22 (mask 255.255.252.0) the route 10.24.16.0/20 (mask 255.255.240.0).
o C4: assign 10.24.12 through 10.24.15. This block is described by o C3. Assign 10.24.8 through 10.24.11. This block is described by
the route 10.24.12.0/22 (mask 255.255.252.0) the route 10.24.8.0/22 (mask 255.255.252.0).
o C5: assign 10.24.32 and 10.24.33. This block is described by the o C4. Assign 10.24.12 through 10.24.15. This block is described by
route 10.24.32.0/23 (mask 255.255.254.0) the route 10.24.12.0/22 (mask 255.255.252.0).
o C6: assign 10.24.34 and 10.24.35. This block is described by the o C5. Assign 10.24.32 and 10.24.33. This block is described by the
route 10.24.34.0/23 (mask 255.255.254.0) route 10.24.32.0/23 (mask 255.255.254.0).
o C6. Assign 10.24.34 and 10.24.35. This block is described by the
route 10.24.34.0/23 (mask 255.255.254.0).
These six sites should be represented as six prefixes of varying size These six sites should be represented as six prefixes of varying size
within the provider's IGP. If, for some reason, the provider uses an within the provider's IGP. If, for some reason, the provider uses an
obsolete IGP that doesn't support classless routing or variable- obsolete IGP that doesn't support classless routing or variable-
length subnets, then explicit routes for all /24s will have to be length subnets, then explicit routes for all /24s will have to be
carried. carried.
To make this example more realistic, assume that C4 and C5 are multi- To make this example more realistic, assume that C4 and C5 are multi-
homed through some other service provider, "PB". Further assume the homed through some other service provider, "PB". Further assume the
existence of a site "C7" which was originally connected to "RB" but existence of a site, "C7", that was originally connected to "RB" but
has moved to "PA". For this reason, it has a block of network that has moved to "PA". For this reason, it has a block of network
numbers which are assigned out "PB"'s block of (the next) 2048 x /24. numbers that are assigned out PB's block of (the next) 2048 x /24.
o C7: assign 10.32.0 through 10.32.15. This block is described by o C7. Assign 10.32.0 through 10.32.15. This block is described by
the route 10.32.0.0/20 (mask 255.255.240.0) the route 10.32.0.0/20 (mask 255.255.240.0).
For the multi-homed sites, assume that C4 is advertised as primary For the multi-homed sites, assume that C4 is advertised as primary
via "RA" and secondary via "RB"; C5 is primary via "RB" and secondary via "RA" and secondary via "RB"; and that C5 is primary via "RB" and
via "RA". In addition, assume that "RA" and "RB" are both connected secondary via "RA". In addition, assume that "RA" and "RB" are both
to the same transit service provider "BB". connected to the same transit service provider, "BB".
Graphically, this topology looks something like this: Graphically, this topology looks something like this:
10.24.0.0 -- 10.24.7.0__ __10.32.0.0 - 10.32.15.0 10.24.0.0 -- 10.24.7.0__ __10.32.0.0 - 10.32.15.0
C1: 10.24.0.0/21 \ / C7: 10.32.0.0/20 C1: 10.24.0.0/21 \ / C7: 10.32.0.0/20
\ / \ /
+----+ +----+ +----+ +----+
10.24.16.0 - 10.24.31.0_ | | | | 10.24.16.0 - 10.24.31.0_ | | | |
C2: 10.24.16.0/20 \ | | _10.24.12.0 - 10.24.15.0__ | | C2: 10.24.16.0/20 \ | | _10.24.12.0 - 10.24.15.0__ | |
\| | / C4: 10.24.12.0/20 \ | | \| | / C4: 10.24.12.0/20 \ | |
skipping to change at page 17, line 30 skipping to change at page 17, line 37
|| || || ||
routing advertisements: || || routing advertisements: || ||
|| || || ||
10.24.12.0/22 (C4) || 10.24.12.0/22 (C4) || 10.24.12.0/22 (C4) || 10.24.12.0/22 (C4) ||
10.32.0.0/20 (C7) || 10.24.32.0/23 (C5) || 10.32.0.0/20 (C7) || 10.24.32.0/23 (C5) ||
10.24.0.0/13 (PA) || 10.32.0.0/13 (PB) || 10.24.0.0/13 (PA) || 10.32.0.0/13 (PB) ||
|| || || ||
VV VV VV VV
+---------- BACKBONE NETWORK BB ----------+ +---------- BACKBONE NETWORK BB ----------+
6.2. Routing advertisements 6.2. Routing Advertisements
To follow rule #1, PA will need to advertise the block of addresses To follow rule #1, PA will need to advertise the block of addresses
that it was given and C7. Since C4 is multi-homed and primary that it was given and C7. Since C4 is multi-homed and primary
through PA, it must also be advertised. C5 is multi-homed and through PA, it must also be advertised. C5 is multi-homed and
primary through PB. In principal (and in the example above), it need primary through PB. In principle (and in the example above), it need
not be advertised since longest match by PB will automatically select not be advertised, since longest match by PB will automatically
PB as primary and the advertisement of PA's aggregate will be used as select PB as primary and the advertisement of PA's aggregate will be
a secondary. In actual practice, C5 will normally be advertised via used as a secondary. In actual practice, C5 will normally be
both providers. advertised via both providers.
Advertisements from "PA" to "BB" will be: Advertisements from "PA" to "BB" will be
10.24.12.0/22 primary (advertises C4) 10.24.12.0/22 primary (advertises C4)
10.32.0.0/20 primary (advertises C7) 10.32.0.0/20 primary (advertises C7)
10.24.0.0/13 primary (advertises remainder of PA) 10.24.0.0/13 primary (advertises remainder of PA)
For PB, the advertisements must also include C4 and C5, as well as
its block of addresses.
For PB, the advertisements must also include C4 and C5 as well as Advertisements from "PB" to "BB" will be
it's block of addresses.
Advertisements from "PB" to "BB" will be:
10.24.12.0/22 secondary (advertises C4) 10.24.12.0/22 secondary (advertises C4)
10.24.32.0/23 primary (advertises C5) 10.24.32.0/23 primary (advertises C5)
10.32.0.0/13 primary (advertises remainder of RB) 10.32.0.0/13 primary (advertises remainder of RB)
To illustrate the problem diagnosis issue mentioned in Section 5.1, To illustrate the problem diagnosis issue mentioned in Section 5.1,
consider what happens if PA loses connectivity to C7 (the site which consider what happens if PA loses connectivity to C7 (the site that
is assigned out of PB's space). In a stateful protocol, PA will is assigned out of PB's space). In a stateful protocol, PA will
announce to BB that 10.32.0.0/20 has become unreachable. Now, when announce to BB that 10.32.0.0/20 has become unreachable. Now, when
BB flushes this information out of its routing table, any future BB flushes this information out of its routing table, any future
traffic sent through it for this destination will be forwarded to PB traffic sent through it for this destination will be forwarded to PB
(where it will be dropped according to Rule #2) by virtue of PB's (where it will be dropped according to Rule #2) by virtue of PB's
less specific match 10.32.0.0/13. While this does not cause an less-specific match, 10.32.0.0/13. Although this does not cause an
operational problem (C7 is unreachable in any case), it does create operational problem (C7 is unreachable in any case), it does create
some extra traffic across "BB" (and may also prove confusing to some extra traffic across "BB" (and may also prove confusing to
someone trying to debug the outage with "traceroute"). A mechanism someone trying to debug the outage with "traceroute"). A mechanism
to cache such unreachable state might be nice but is beyond the scope to cache such unreachable state might be nice, but it is beyond the
of this document. scope of this document.
7. Domain Name Service considerations 7. Domain Name Service Considerations
One aspect of Internet services which was notably affected by the One aspect of Internet services that was notably affected by the move
move to CIDR was the mechanism used for address-to-name translation: to CIDR was the mechanism used for address-to-name translation: the
the IN-ADDR.ARPA zone of the domain system. Because this zone is IN-ADDR.ARPA zone of the domain system. Because this zone is
delegated on octet boundaries only, the move to an address assignment delegated on octet boundaries only, the move to an address assignment
plan which uses bitmask-oriented addressing caused some increase in plan that uses bitmask-oriented addressing caused some increase in
work for those who maintain parts of the IN-ADDR.ARPA zone. work for those who maintain parts of the IN-ADDR.ARPA zone.
A description of techniques to populate the IN-ADDR.ARPA zone when A description of techniques to populate the IN-ADDR.ARPA zone when
using address blocks that do not align to octet boundaries is and used address that blocks that do not align to octet boundaries is
described in [RFC2317]. described in [RFC2317].
8. Transition to a long term solution 8. Transition to a Long-Term Solution
CIDR was designed to be a short-term solution to the problems of CIDR was designed to be a short-term solution to the problems of
routing state and address depletion on the IPv4 Internet. It does routing state and address depletion on the IPv4 Internet. It does
not change the fundamental Internet routing or addressing not change the fundamental Internet routing or addressing
architectures. It is not expected to affect any plans for transition architectures. It is not expected to affect any plans for transition
to a more long-term solution except, perhaps, by delaying the urgency to a more long-term solution except, perhaps, by delaying the urgency
of developing such a solution. of developing such a solution.
9. Analysis of CIDR's effect on global routing state 9. Analysis of CIDR's Effect on Global Routing State
When CIDR was first proposed in the early 1990s, the original authors When CIDR was first proposed in the early 1990s, the original authors
made some observations about the growth rate of global routing state made some observations about the growth rate of global routing state
and offered projections on how CIDR deployment would, hopefully, and offered projections on how CIDR deployment would, hopefully,
reduce what appeared to be exponential growth to a more sustainable reduce what appeared to be exponential growth to a more sustainable
rate. Since that deployment, an ongoing effort, called "The CIDR rate. Since that deployment, an ongoing effort, called "The CIDR
Report" [CRPT] has attempted to quantify and track that growth rate. Report" [CRPT], has attempted to quantify and track that growth rate.
What follows is a brief summary of the CIDR report as of March, 2005, What follows is a brief summary of the CIDR report as of March 2005,
with an attempt to explain the various patterns of and change in with an attempt to explain the various patterns and changes of growth
growth rate that have occurred since measurements of the size of rate that have occurred since measurements of the size of global
global routing state began in 1988. routing state began in 1988.
Examining the graph of "Active BGP Table Entries" [CBGP] there appear When the graph of "Active BGP Table Entries" [CBGP] is examined,
to be several different growth trends with distinct inflection points there appear to be several different growth trends with distinct
reflecting changes in policy and practice. The trends and events inflection points reflecting changes in policy and practice. The
which are believed to have caused them were: trends and events that are believed to have caused them were as
follows:
1. Exponential growth at the far left of the graph. This represents 1. Exponential growth at the far left of the graph. This represents
the period of early expansion and commercialization of the former the period of early expansion and commercialization of the former
research network, from the late 1980s through approximately 1994. research network, from the late 1980s through approximately 1994.
The major driver for this growth was a lack of aggregation The major driver for this growth was a lack of aggregation
capability for transit providers, and the widespread use of capability for transit providers, and the widespread use of
legacy Class C allocations for end sites. Each time a new site legacy Class C allocations for end sites. Each time a new site
was connected to the global Internet, one or more new routing was connected to the global Internet, one or more new routing
entries were generated. entries were generated.
skipping to change at page 19, line 41 skipping to change at page 19, line 48
aggregation of the "supernet" blocks. Note that the periods of aggregation of the "supernet" blocks. Note that the periods of
largest declines in the number of routing table entries typically largest declines in the number of routing table entries typically
correspond to the weeks following each meeting of the IETF CIDR correspond to the weeks following each meeting of the IETF CIDR
Deployment Working Group. Deployment Working Group.
4. Roughly linear growth from mid-1994 to early 1999 as CIDR-based 4. Roughly linear growth from mid-1994 to early 1999 as CIDR-based
address assignments were made and aggregated routes added address assignments were made and aggregated routes added
throughout the network. throughout the network.
5. A new period of exponential growth again from early 1999 until 5. A new period of exponential growth again from early 1999 until
2001 as the "high-tech bubble" fueled both rapid expansion of 2001 as the "high-tech bubble" fueled both rapid expansion of the
Internet as well as a large increase in more-specific route Internet, as well as a large increase in more-specific route
advertisements for multi-homing and traffic engineering. advertisements for multi-homing and traffic engineering.
6. Flattening of growth through 2001 caused by a combination of the 6. Flattening of growth through 2001 caused by a combination of the
"dot-com bust", which caused many organizations to cease "dot-com bust", which caused many organizations to cease
operations, and the "CIDR police" [CPOL] work aimed at improving operations, and the "CIDR police" [CPOL] work aimed at improving
aggregation efficiency. aggregation efficiency.
7. Roughly linear growth through 2002 and 2003. This most likely 7. Roughly linear growth through 2002 and 2003. This most likely
represents a resumption of the "normal" growth rate observed represents a resumption of the "normal" growth rate observed
before the "bubble" as well as an end to the "CIDR Police" before the "bubble", as well as an end to the "CIDR Police"
effort. effort.
8. A more recent trend of exponential growth beginning in 2004. The 8. A more recent trend of exponential growth beginning in 2004. The
best explanation would seem to be an improvement of the global best explanation would seem to be an improvement of the global
economy driving increased expansion of the Internet and the economy driving increased expansion of the Internet and the
continued absence of the "CIDR Police" effort, which previously continued absence of the "CIDR Police" effort, which previously
served as an educational tool for new providers to improve served as an educational tool for new providers to improve
aggregation efficiency. There have also been some cases where aggregation efficiency. There have also been some cases where
service providers have deliberately de-aggregated prefixes in an service providers have deliberately de-aggregated prefixes in an
attempt to mitigate security problems caused by conflicting route attempt to mitigate security problems caused by conflicting route
advertisements (see Section 12). While this behavior may solve advertisements (see Section 12). Although this behavior may
the short-term problems seen by such providers, it is solve the short-term problems seen by such providers, it is
fundamentally non-scalable and quite detrimental to the community fundamentally non-scalable and quite detrimental to the community
as a whole. In addition, there appear to be many providers as a whole. In addition, there appear to be many providers
advertising both their allocated prefixes and all of the /24 advertising both their allocated prefixes and all the /24
components of them, probably due to a lack of consistent current components thereof, probably due to a lack of consistent current
information about recommended routing configuration. information about recommended routing configuration.
10. Conclusions and Recommendations 10. Conclusions and Recommendations
In 1992, when CIDR was first developed, there were serious problems In 1992, when CIDR was first developed, there were serious problems
facing the continued growth of the Internet. Growth in routing state facing the continued growth of the Internet. Growth in routing state
complexity and the rapid increase in consumption of address space complexity and the rapid increase in consumption of address space
made it appear that one or both problems would preclude continued made it appear that one or both problems would preclude continued
growth of the Internet within a few short years. growth of the Internet within a few short years.
Deployment of CIDR, in combination with BGP4's support for carrying Deployment of CIDR, in combination with BGP4's support for carrying
classless prefix routes, alleviated the short-term crisis. It was classless prefix routes, alleviated the short-term crisis. It was
only through a concerted effort by both the equipment manufacturers only through a concerted effort by both the equipment manufacturers
and the provider community that this was achieved. The threat (and, and the provider community that this was achieved. The threat (and,
perhaps in some cases, actual implementation of) charging networks perhaps in some cases, actual implementation of) charging networks
for advertising prefixes may have offered an additional incentive to for advertising prefixes may have offered an additional incentive to
share the address space, and hence the associated costs of share the address space, and thus the associated costs of advertising
advertising routes to service providers. routes to service providers.
The IPv4 routing system architecture carries topology information The IPv4 routing system architecture carries topology information
based on aggregate address advertisements and a collection of more- based on aggregate address advertisements and a collection of more-
specific advertisements that are associated with traffic engineering, specific advertisements that are associated with traffic engineering,
multi-homing and local configuration. As of March, 2005, the base multi-homing, and local configuration. As of March 2005, the base
aggregate address load in the routing system has some 75,000 entries. aggregate address load in the routing system has some 75,000 entries.
Approximately 85,000 additional entries are more specific entries of Approximately 85,000 additional entries are more specific entries of
this base "root" collection. There is reason to believe that many of this base "root" collection. There is reason to believe that many of
these additional entries exist to solve problems of regional or even these additional entries exist to solve problems of regional or even
local scope and should not need to be globally propagated. local scope and should not need to be globally propagated.
An obvious question to ask is whether CIDR can continue to be a An obvious question to ask is whether CIDR can continue to be a
viable approach to keeping global routing state growth and address viable approach to keeping global routing state growth and address
space depletion at sustainable rates. Recent measurements indicate space depletion at sustainable rates. Recent measurements indicate
that exponential growth has resumed but further analysis suggests that exponential growth has resumed, but further analysis suggests
that this trend can be mitigated by a more active effort to educate that this trend can be mitigated by a more active effort to educate
service providers on efficient aggregation strategies and proper service providers as to efficient aggregation strategies and proper
equipment configuration. Looking farther forward, there is a clear equipment configuration. Looking farther forward, there is a clear
need for better multi-homing technology that does not require global need for better multi-homing technology that does not require global
routing state for each site and for methods of performing traffic routing state for each site and for methods of performing traffic
load balancing that do not require adding even more state. Without load balancing that do not require adding even more state. Without
such developments and in the absence of major architectural change, such developments and in the absence of major architectural change,
aggregation is the only tool available for making routing scale in aggregation is the only tool available for making routing scale in
the global Internet. the global Internet.
11. Status updates to CIDR documents 11. Status Updates to CIDR Documents
This memo renders obsolete and requests re-classification as Historic This memo renders obsolete and requests re-classification as Historic
the following RFCs describing CIDR usage and deployment: the following RFCs describing CIDR usage and deployment:
o RFC 1467: Status of CIDR Deployment in the Internet o RFC 1467: Status of CIDR Deployment in the Internet
This Informational RFC described the status of CIDR deployment in This Informational RFC described the status of CIDR deployment in
1993. As of 2005, CIDR has been thoroughly deployed, so this 1993. As of 2005, CIDR has been thoroughly deployed, so this
status note only provides a historical data point. status note only provides a historical data point.
skipping to change at page 21, line 40 skipping to change at page 21, line 47
This very short Informational RFC described the IAB's endorsement This very short Informational RFC described the IAB's endorsement
of the use of CIDR to address scaling issues. Because the goal of of the use of CIDR to address scaling issues. Because the goal of
RFC 1481 has been achieved, it is now only of historical value. RFC 1481 has been achieved, it is now only of historical value.
o RFC 1482: Aggregation Support in the NSFNET Policy-Based Routing o RFC 1482: Aggregation Support in the NSFNET Policy-Based Routing
Database Database
This Informational RFC describes plans for support of route This Informational RFC describes plans for support of route
aggregation, as specified by CIDR, on the NSFNET. Because the aggregation, as specified by CIDR, on the NSFNET. Because the
NSFNET has long since ceased to exist and CIDR has been been NSFNET has long since ceased to exist and CIDR has been
ubiquitously deployed, RFC 1482 now only has historical relevance. ubiquitously deployed, RFC 1482 now only has historical relevance.
o RFC 1517: Applicability Statement for the Implementation of o RFC 1517: Applicability Statement for the Implementation of
Classless Inter-Domain Routing (CIDR) Classless Inter-Domain Routing (CIDR)
This Standards Track RFC described where CIDR was expected to be This Standards Track RFC described where CIDR was expected to be
required and where it was expected to be (strongly) recommended. required and where it was expected to be (strongly) recommended.
With the full deployment of CIDR on the Internet, situations where With the full deployment of CIDR on the Internet, situations where
CIDR is not required are of only historical interest. CIDR is not required are of only historical interest.
o RFC 1518: An Architecture for IP Address Allocation with CIDR o RFC 1518: An Architecture for IP Address Allocation with CIDR
This Standards Track RFC discussed routing and address aggregation This Standards Track RFC discussed routing and address aggregation
considerations at some length. Some of these issues are considerations at some length. Some of these issues are
summarized in this document in section Section 3.1. Because summarized in this document in section Section 3.1. Because
skipping to change at page 22, line 36 skipping to change at page 22, line 40
deployment in 1995; it notes that formerly-classful addresses were deployment in 1995; it notes that formerly-classful addresses were
to be allocated using CIDR mechanisms and describes the use of a to be allocated using CIDR mechanisms and describes the use of a
default route for non-CIDR-aware sites. With the full deployment default route for non-CIDR-aware sites. With the full deployment
of CIDR on the Internet, such scenarios are no longer of CIDR on the Internet, such scenarios are no longer
operationally relevant. operationally relevant.
o RFC 1878: Variable Length Subnet Table For IPv4 o RFC 1878: Variable Length Subnet Table For IPv4
This Informational RFC provided a table of pre-calculated subnet This Informational RFC provided a table of pre-calculated subnet
masks and address counts for each subnet size. With the masks and address counts for each subnet size. With the
incorporation of a similar table into this document (see incorporation of a similar table into this document (see Section
Section 3.1), it is no longer necessary to document it in a 3.1), it is no longer necessary to document it in a separate RFC.
separate RFC.
o RFC 2036: Observations on the use of Components of the Class A o RFC 2036: Observations on the use of Components of the Class A
Address Space within the Internet Address Space within the Internet
This Informational RFC described several operational issues This Informational RFC described several operational issues
associated with the allocation of classless prefixes from associated with the allocation of classless prefixes from
previously-classful address space. With the full deployment of previously-classful address space. With the full deployment of
CIDR on the Internet and more than half a dozen years of CIDR on the Internet and more than half a dozen years of
experience making classless prefix allocations out of historical experience making classless prefix allocations out of historical
"class A" address space, this RFC now has only historical value. "Class A" address space, this RFC now has only historical value.
12. Security Considerations 12. Security Considerations
The introduction of routing protocols which support classless The introduction of routing protocols that support classless prefixes
prefixes and a move to a forwarding model that mandates that more- and a move to a forwarding model that mandates that more-specific
specific (longest-match) routes be preferred when they overlap with (longest-match) routes be preferred when they overlap with routes to
routes to less-specific prefixes introduces at least two security less-specific prefixes introduces at least two security concerns:
concerns:
1. Traffic can be hijacked by advertising a prefix for a given 1. Traffic can be hijacked by advertising a prefix for a given
destination that is more specific than the aggregate that is destination that is more specific than the aggregate that is
normally advertised for that destination. For example, assume a normally advertised for that destination. For example, assume
popular end system with address 192.168.17.100 that is connected that a popular end system with the address 192.168.17.100 is
to a service provider that advertises 192.168.16.0/20. A connected to a service provider that advertises 192.168.16.0/20.
malicious network operator interested in intercepting traffic for A malicious network operator interested in intercepting traffic
this site might advertise, or at least attempt to advertise, for this site might advertise, or at least attempt to advertise,
192.168.17.0/24 into the global routing system. Because this 192.168.17.0/24 into the global routing system. Because this
prefix is more-specific than the "normal" prefix, traffic will be prefix is more specific than the "normal" prefix, traffic will be
diverted away from the legitimate end system and to the network diverted away from the legitimate end system and to the network
owned by the malicious operator. Prior to the advent of CIDR, it owned by the malicious operator. Prior to the advent of CIDR, it
was possible to induce traffic from some parts of the network to was possible to induce traffic from some parts of the network to
follow a false advertisement that exactly matched a particular follow a false advertisement that exactly matched a particular
network number; CIDR makes this problem somewhat worse, since network number; CIDR makes this problem somewhat worse, since
longest-match routing generally causes all traffic to prefer longest-match routing generally causes all traffic to prefer
more-specific routes over less-specific routes. The remedy for more-specific routes over less-specific routes. The remedy for
the CIDR-based attack, though, is the same as for a pre-CIDR- the CIDR-based attack, though, is the same as for a pre-CIDR-
based attack: establishment of trust relationships between based attack: establishment of trust relationships between
providers, coupled with and strong route policy filters at providers, coupled with and strong route policy filters at
provider borders. Unfortunately, the implementation of such provider borders. Unfortunately, the implementation of such
filters is difficult in the highly de-centralized Internet. As a filters is difficult in the highly de-centralized Internet. As a
workaround, many providers do implement generic filters that set workaround, many providers do implement generic filters that set
upper bounds, derived from RIR guidelines for the sizes of blocks upper bounds, derived from RIR guidelines for the sizes of blocks
that they allocate, on the lengths of prefixes that are accepted that they allocate, on the lengths of prefixes that are accepted
from other providers. It is worth noting that "spammers" have from other providers. Note that "spammers" have been observed
been observed using this sort of attack to temporarily hijack using this sort of attack to hijack address space temporarily in
address space in order to hide the origin of the traffic ("spam" order to hide the origin of the traffic ("spam" email messages)
email messages) that they generate. that they generate.
2. Denial-of-service attacks can be launched against many parts of 2. Denial-of-service attacks can be launched against many parts of
the Internet infrastructure by advertising a large number of the Internet infrastructure by advertising a large number of
routes into the system. Such an attack is intended to cause routes into the system. Such an attack is intended to cause
router failures by overflowing routing and forwarding tables. A router failures by overflowing routing and forwarding tables. A
good example of a non-malicious incident which caused this sort good example of a non-malicious incident that caused this sort of
of failure was the infamous "AS 7007" event [7007] where a router failure was the infamous "AS 7007" event [7007], where a router
mis-configuration by an operator caused a huge number of invalid mis-configuration by an operator caused a huge number of invalid
routes to be propagated through the global routing system. routes to be propagated through the global routing system.
Again, this sort of attack is not really new with CIDR; using Again, this sort of attack is not really new with CIDR; using
legacy class A/B/C routes, it was possible to advertise a maximum legacy Class A/B/C routes, it was possible to advertise a maximum
of 16843008 unique network numbers into the global routing of 16843008 unique network numbers into the global routing
system, a number which is sufficient to cause problems for even system, a number that is sufficient to cause problems for even
the most modern routing equipment made in 2005. What is the most modern routing equipment made in 2005. What is
different is that the moderate complexity of correctly different is that the moderate complexity of correctly
configuring routers in the presence of CIDR does tend to make configuring routers in the presence of CIDR tends to make
accidental "attacks" of this sort more likely. Measures to accidental "attacks" of this sort more likely. Measures to
prevent this sort of attack are much the same as those described prevent this sort of attack are much the same as those described
above for the hijacking, with the addition that best common above for the hijacking, with the addition that best common
practice is to also configure a reasonable maximum number of practice is also to configure a reasonable maximum number of
prefixes that a border router will accept from its neighbors. prefixes that a border router will accept from its neighbors.
Note that this is not intended to be an exhaustive analysis of the Note that this is not intended to be an exhaustive analysis of the
sorts of attacks that CIDR makes easier; a more comprehensive sorts of attacks that CIDR makes easier; a more comprehensive
analysis of security vulnerabilities in the global routing system is analysis of security vulnerabilities in the global routing system is
beyond the scope of this document. beyond the scope of this document.
13. IANA Considerations 13. Acknowledgements
[RFC Editor: This section to be removed prior to publication.]
There are no IANA Considerations raised in this document.
14. Acknowledgments
The authors wish to express appreciation to the other original The authors wish to express appreciation to the other original
authors of RFC1519 (Kannan Varadhan, Jessica Yu), to the ROAD group authors of RFC 1519 (Kannan Varadhan, Jessica Yu); to the ROAD group,
with whom many of the ideas behind CIDR were inspired and developed, with whom many of the ideas behind CIDR were inspired and developed;
and to the early reviewers of this re-spun version of the document and to the early reviewers of this re-spun version of the document
(Barry Greene, Danny McPherson, Dave Meyer, Eliot Lear, Bill Norton, (Barry Greene, Danny McPherson, Dave Meyer, Eliot Lear, Bill Norton,
Ted Seely, Philip Smith, Pekka Savola) whose comments, corrections, Ted Seely, Philip Smith, Pekka Savola), whose comments, corrections,
and suggestions were invaluable. We would especially like to thank and suggestions were invaluable. We would especially like to thank
Geoff Huston for contributions well above and beyond the call of Geoff Huston for contributions well above and beyond the call of
duty. duty.
15. Appendix A: Area Director Comments and Responses 14. References
[RFC Editor: Please remove this section prior to publication]
Review comments and responses:
1. The document describes the interaction between the IANA and the
RIRs in address allocation. Is this logically part of a
standards-track document that is describing address aggregation?
2. This part of the document is describing the current situation
with respect to address distribution. It appears that the
defining document here is
http://www.aso.icann.org/docs/aso-001-2.pdf, which is entirely
consistent with the document.
3. As this is a description of the current situation, and as this
are no "IANA Considerations" section then it is felt that it is
clear that this is not to be interpreted as a direction to IANA.
To further ensure that this is clear to future generations,
we've also added a suitable caveat to section Section 3.
4. The text describes interactions between RIRs and LIRs or ISPs.
Is this description correct?
5. In considering the entire RIR system this is indeed the case.
While some RIRs use LIRs who, in turn, interact with ISPs, other
RIRs interact directly with ISPs, or use a mixed mode of
interaction with both LIRs and ISPS.
6. The text references dynamic host address assignment [RFC2131] as
a recommended technology, and suggests that additional protocol
work be undertaken to develop improved technology for
renumbering. The review suggested further document references
and further elaboration in the text.
7. While it would be possible to include a larger set of references
and additional text on this topic, it is a matter where there is
a distinct risk of the document losing focus here. The topic of
this section is one of situations where there are constraints on
aggregation, rather than a detailed examination of various
mitigating steps.
8. The example in Section 5 uses network 10 rather than the
documentation prefix 192.0.2.0/24.
9. The text is showing a practical example of aggregation using
prefix sizes that would be encountered in an operational
context. The documentation prefix is too small to encompass
this example, and designated private address space was used in
this example.
10. The text shows an example of DNS delegations where the address
blocks are smaller than a /24. Should the solution be reworded
as a reference to RFC2137?
11. The text describes the impact of CIDR on reverse delegations in
the DNS and the methods used in the DNS to respond to this. It
is considered to be an integral part of this document.
12. Should the document refer to a graph of data by reference?
13. The document is describing a sequence of trends in the state of
inter-domain routing over the past years, and the graph is the
most effective presentation of this material.
16. References
16.1. Normative References 14.1. Normative References
[RFC791] Postel, J., "Internet Protocol", RFC 791, September 1981. [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September
1981.
16.2. Informative References 14.2. Informative References
[7007] "NANOG mailing list discussion of the "AS 7007" incident", [7007] "NANOG mailing list discussion of the "AS 7007" incident",
<http://www.merit.edu/mail.archives/nanog/1997-04/ <http://www.merit.edu/mail.archives/nanog/1997-04/
msg00340.html>. msg00340.html>.
[CBGP] "Graph: Active BGP Table Entries, 1988 to Present", [CBGP] "Graph: Active BGP Table Entries, 1988 to Present",
<http://bgp.potaroo.net/as4637/>. <http://bgp.potaroo.net/as4637/>.
[CPOL] "CIDR Police - Please Pull Over and Show Us Your BGP", [CPOL] "CIDR Police - Please Pull Over and Show Us Your BGP",
<http://www.nanog.org/mtg-0302/cidr.html>. <http://www.nanog.org/mtg-0302/cidr.html>.
skipping to change at page 26, line 40 skipping to change at page 25, line 35
[IANA] "Internet Assigned Numbers Authority", [IANA] "Internet Assigned Numbers Authority",
<http://www.iana.org>. <http://www.iana.org>.
[LWRD] "The Long and Winding Road", [LWRD] "The Long and Winding Road",
<http://rms46.vlsm.org/1/42.html>. <http://rms46.vlsm.org/1/42.html>.
[NRO] "Number Resource Organization", <http://www.nro.net>. [NRO] "Number Resource Organization", <http://www.nro.net>.
[RFC904] Mills, D., "Exterior Gateway Protocol formal [RFC904] Mills, D., "Exterior Gateway Protocol formal
specification", RFC 904, April 1984. specification", RFC 904, April 1 1984.
[RFC1058] Hedrick, C., "Routing Information Protocol", RFC 1058, [RFC1058] Hedrick, C., "Routing Information Protocol", RFC 1058,
June 1988. June 1988.
[RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and
dual environments", RFC 1195, December 1990. dual environments", RFC 1195, December 1990.
[RFC1338] Fuller, V., Li, T., Varadhan, K., and J. Yu, [RFC1338] Fuller, V., Li, T., Yu, J., and K. Varadhan,
"Supernetting: an Address Assignment and Aggregation "Supernetting: an Address Assignment and Aggregation
Strategy", RFC 1338, June 1992. Strategy", RFC 1338, June 1992.
[RFC1380] Gross, P. and P. Almquist, "IESG Deliberations on Routing [RFC1380] Gross, P. and P. Almquist, "IESG Deliberations on Routing
and Addressing", RFC 1380, November 1992. and Addressing", RFC 1380, November 1992.
[RFC1518] Rekhter, Y. and T. Li, "An Architecture for IP Address [RFC1518] Rekhter, Y. and T. Li, "An Architecture for IP Address
Allocation with CIDR", RFC 1518, September 1993. Allocation with CIDR", RFC 1518, September 1993.
[RFC1519] Fuller, V., Li, T., Varadhan, K., and J. Yu, "Classless [RFC1519] Fuller, V., Li, T., Yu, J., and K. Varadhan, "Classless
Inter-Domain Routing: an Address Assignment and Inter-Domain Routing (CIDR): an Address Assignment and
Aggregation Strategy", RFC 1519, September 1993. Aggregation Strategy", RFC 1519, September 1993.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC
RFC 2131, March 1997. 2131, March 1997.
[RFC2178] Moy, J., "The OSPF Specification Version 2", RFC 2178, [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
July 1997.
[RFC2317] Eidnes, H., de Groot, G., and P. Vixie, "Classless IN- [RFC2317] Eidnes, H., de Groot, G., and P. Vixie, "Classless IN-
ADDR.ARPA delegation", RFC 2317, March 1998. ADDR.ARPA delegation", BCP 20, RFC 2317, March 1998.
[RFC2453] Malkin, G., "RIP Version 2", RFC 2453, November 1998. [RFC2453] Malkin, G., "RIP Version 2", STD 56, RFC 2453, November
1998.
[RFC3021] Retana, A., White, R., Fuller, V., and D. McPherson, [RFC3021] Retana, A., White, R., Fuller, V., and D. McPherson,
"Using 31-Bit Prefixes on IPv4 Point-to-Point Links", "Using 31-Bit Prefixes on IPv4 Point-to-Point Links", RFC
RFC 3021, December 2000. 3021, December 2000.
[RFC3221] Huston, G., "Commentary on Inter-Domain Routing in the [RFC3221] Huston, G., "Commentary on Inter-Domain Routing in the
Internet", RFC 3221, December 2001. Internet", RFC 3221, December 2001.
[RFC4116] Abley, J., Lindqvist, K., Davies, E., Black, B., and V. [RFC4116] Abley, J., Lindqvist, K., Davies, E., Black, B., and V.
Gill, "IPv4 Multihoming Practices and Limitations", Gill, "IPv4 Multihoming Practices and Limitations", RFC
RFC 4116, July 2005. 4116, July 2005.
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
Protocol 4 (BGP-4)", RFC 4271, January 2006. Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RIPE] "RIPE Network Coordination Centre", <http://www.ripe.net>. [RIPE] "RIPE Network Coordination Centre", <http://www.ripe.net>.
Authors' Addresses Authors' Addresses
Vince Fuller Vince Fuller
170 W. Tasman Drive 170 W. Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
USA USA
Email: vaf@cisco.com EMail: vaf@cisco.com
Tony Li Tony Li
Li Consulting 555 Del Rey Avenue
Sunnyvale, CA 94085
Email: tony.li@tony.li Email: tli@tropos.com
Intellectual Property Statement Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
skipping to change at page 29, line 29 skipping to change at page 27, line 45
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Disclaimer of Validity Acknowledgement
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is provided by the IETF
Internet Society. Administrative Support Activity (IASA).
 End of changes. 167 change blocks. 
512 lines changed or deleted 424 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/