components thereof, probably due to a lack of consistent current
information about recommended routing configuration.
10. Conclusions and Recommendations
In 1992, when CIDR was first developed, there were serious problems
facing the continued growth of the Internet. Growth in routing state
complexity and the rapid increase in consumption of address space
made it appear that one or both problems would preclude continued
growth of the Internet within a few short years.
Deployment of CIDR, in combination with BGP4’s support for carrying
classless prefix routes, alleviated the short-term crisis. It was
only through a concerted effort by both the equipment manufacturers
and the provider community that this was achieved. The threat (and,
perhaps in some cases, actual implementation of) charging networks
for advertising prefixes may have offered an additional incentive to
share the address space, and thus the associated costs of advertising
routes to service providers.
The IPv4 routing system architecture carries topology information
based on aggregate address advertisements and a collection of more-
specific advertisements that are associated with traffic engineering,
multi-homing, and local configuration. As of March 2005, the base
aggregate address load in the routing system has some 75,000 entries.
Approximately 85,000 additional entries are more specific entries of
this base "root" collection. There is reason to believe that many of
these additional entries exist to solve problems of regional or even
local scope and should not need to be globally propagated.
An obvious question to ask is whether CIDR can continue to be a
viable approach to keeping global routing state growth and address
space depletion at sustainable rates. Recent measurements indicate
that exponential growth has resumed, but further analysis suggests
that this trend can be mitigated by a more active effort to educate
service providers as to efficient aggregation strategies and proper
equipment configuration. Looking farther forward, there is a clear
need for better multi-homing technology that does not require global
routing state for each site and for methods of performing traffic
load balancing that do not require adding even more state. Without
such developments and in the absence of major architectural change,
aggregation is the only tool available for making routing scale in
the global Internet.
11. Status Updates to CIDR Documents
This memo renders obsolete and requests re-classification as Historic
the following RFCs describing CIDR usage and deployment:
o RFC 1467: Status of CIDR Deployment in the Internet
This Informational RFC described the status of CIDR deployment in
1993. As of 2005, CIDR has been thoroughly deployed, so this
status note only provides a historical data point.
o RFC 1481: IAB Recommendation for an Intermediate Strategy to
Address the Issue of Scaling
This very short Informational RFC described the IAB’s endorsement
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.
o RFC 1482: Aggregation Support in the NSFNET Policy-Based Routing
Database
This Informational RFC describes plans for support of route
aggregation, as specified by CIDR, on the NSFNET. Because the
NSFNET has long since ceased to exist and CIDR has been
ubiquitously deployed, RFC 1482 now only has historical relevance.
o RFC 1517: Applicability Statement for the Implementation of
Classless Inter-Domain Routing (CIDR)
This Standards Track RFC described where CIDR was expected to be
required and where it was expected to be (strongly) recommended.
With the full deployment of CIDR on the Internet, situations where
CIDR is not required are of only historical interest.
o RFC 1518: An Architecture for IP Address Allocation with CIDR
This Standards Track RFC discussed routing and address aggregation
considerations at some length. Some of these issues are
summarized in this document in section Section 3.1. Because
address assignment policies and procedures now reside mainly with
the RIRs, it is not appropriate to try to document those practices
in a Standards Track RFC. In addition, [RFC3221] also describes
many of the same issues from point of view of the routing system.
o RFC 1520: Exchanging Routing Information Across Provider
Boundaries in the CIDR Environment
This Informational RFC described transition scenarios where CIDR
was not fully supported for exchanging route information between
providers. With the full deployment of CIDR on the Internet, such
scenarios are no longer operationally relevant.
o RFC 1817: CIDR and Classful Routing
This Informational RFC described the implications of CIDR
deployment in 1995; it notes that formerly-classful addresses were
to be allocated using CIDR mechanisms and describes the use of a
default route for non-CIDR-aware sites. With the full deployment
of CIDR on the Internet, such scenarios are no longer
operationally relevant.
o RFC 1878: Variable Length Subnet Table For IPv4
This Informational RFC provided a table of pre-calculated subnet
masks and address counts for each subnet size. With the
incorporation of a similar table into this document (see Section
3.1), it is no longer necessary to document it in a separate RFC.
o RFC 2036: Observations on the use of Components of the Class A
Address Space within the Internet
This Informational RFC described several operational issues
associated with the allocation of classless prefixes from
previously-classful address space. With the full deployment of
CIDR on the Internet and more than half a dozen years of
experience making classless prefix allocations out of historical
"Class A" address space, this RFC now has only historical value.
12. Security Considerations
The introduction of routing protocols that support classless prefixes
and a move to a forwarding model that mandates that more-specific
(longest-match) routes be preferred when they overlap with routes to
less-specific prefixes introduces at least two security concerns:
1. Traffic can be hijacked by advertising a prefix for a given
destination that is more specific than the aggregate that is
normally advertised for that destination. For example, assume
that a popular end system with the address 192.168.17.100 is
connected to a service provider that advertises 192.168.16.0/20.
A malicious network operator interested in intercepting traffic
for this site might advertise, or at least attempt to advertise,
192.168.17.0/24 into the global routing system. Because this
prefix is more specific than the "normal" prefix, traffic will be
diverted away from the legitimate end system and to the network
owned by the malicious operator. Prior to the advent of CIDR, it
was possible to induce traffic from some parts of the network to
follow a false advertisement that exactly matched a particular
network number; CIDR makes this problem somewhat worse, since
longest-match routing generally causes all traffic to prefer
more-specific routes over less-specific routes. The remedy for
the CIDR-based attack, though, is the same as for a pre-CIDR-
based attack: establishment of trust relationships between
providers, coupled with and strong route policy filters at
provider borders. Unfortunately, the implementation of such
filters is difficult in the highly de-centralized Internet. As a
workaround, many providers do implement generic filters that set
upper bounds, derived from RIR guidelines for the sizes of blocks
that they allocate, on the lengths of prefixes that are accepted
from other providers. Note that "spammers" have been observed
using this sort of attack to hijack address space temporarily in
order to hide the origin of the traffic ("spam" email messages)
that they generate.
2. Denial-of-service attacks can be launched against many parts of
the Internet infrastructure by advertising a large number of
routes into the system. Such an attack is intended to cause
router failures by overflowing routing and forwarding tables. A
good example of a non-malicious incident that caused this sort of
failure was the infamous "AS 7007" event [7007], where a router
mis-configuration by an operator caused a huge number of invalid
routes to be propagated through the global routing system.
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
of 16843008 unique network numbers into the global routing
system, a number that is sufficient to cause problems for even
the most modern routing equipment made in 2005. What is
different is that the moderate complexity of correctly
configuring routers in the presence of CIDR tends to make
accidental "attacks" of this sort more likely. Measures to
prevent this sort of attack are much the same as those described
above for the hijacking, with the addition that best common
practice is also to configure a reasonable maximum number of
prefixes that a border router will accept from its neighbors.
Note that this is not intended to be an exhaustive analysis of the
sorts of attacks that CIDR makes easier; a more comprehensive
analysis of security vulnerabilities in the global routing system is
beyond the scope of this document.
13. Acknowledgements
The authors wish to express appreciation to the other original
authors of RFC 1519 (Kannan Varadhan, Jessica Yu); to the ROAD group,
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
(Barry Greene, Danny McPherson, Dave Meyer, Eliot Lear, Bill Norton,
Ted Seely, Philip Smith, Pekka Savola), whose comments, corrections,
and suggestions were invaluable. We would especially like to thank
Geoff Huston for contributions well above and beyond the call of
duty.
14. References
14.1. Normative References
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September
1981.
14.2. Informative References
[7007] "NANOG mailing list discussion of the "AS 7007" incident",
<http://www.merit.edu/mail.archives/nanog/1997-04/
msg00340.html>.
[CBGP] "Graph: Active BGP Table Entries, 1988 to Present",
<http://bgp.potaroo.net/as4637/>.
[CPOL] "CIDR Police - Please Pull Over and Show Us Your BGP",
<http://www.nanog.org/mtg-0302/cidr.html>.
[CRPT] "The CIDR Report", <http://www.cidr-report.org/>.
[IANA] "Internet Assigned Numbers Authority",
<http://www.iana.org>.
[LWRD] "The Long and Winding Road",
<http://rms46.vlsm.org/1/42.html>.
[NRO] "Number Resource Organization", <http://www.nro.net>.
[RFC904] Mills, D., "Exterior Gateway Protocol formal
specification", RFC 904, April 1 1984.
[RFC1058] Hedrick, C., "Routing Information Protocol", RFC 1058,
June 1988.
[RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and
dual environments", RFC 1195, December 1990.
[RFC1338] Fuller, V., Li, T., Yu, J., and K. Varadhan,
"Supernetting: an Address Assignment and Aggregation
Strategy", RFC 1338, June 1992.
[RFC1380] Gross, P. and P. Almquist, "IESG Deliberations on Routing
and Addressing", RFC 1380, November 1992.
[RFC1518] Rekhter, Y. and T. Li, "An Architecture for IP Address
Allocation with CIDR", RFC 1518, September 1993.
[RFC1519] Fuller, V., Li, T., Yu, J., and K. Varadhan, "Classless
Inter-Domain Routing (CIDR): an Address Assignment and
Aggregation Strategy", RFC 1519, September 1993.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC
2131, March 1997.
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC2317] Eidnes, H., de Groot, G., and P. Vixie, "Classless IN-
ADDR.ARPA delegation", BCP 20, RFC 2317, March 1998.
[RFC2453] Malkin, G., "RIP Version 2", STD 56, RFC 2453, November
1998.
[RFC3021] Retana, A., White, R., Fuller, V., and D. McPherson,
"Using 31-Bit Prefixes on IPv4 Point-to-Point Links", RFC
3021, December 2000.
[RFC3221] Huston, G., "Commentary on Inter-Domain Routing in the
Internet", RFC 3221, December 2001.
[RFC4116] Abley, J., Lindqvist, K., Davies, E., Black, B., and V.
Gill, "IPv4 Multihoming Practices and Limitations", RFC
4116, July 2005.
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RIPE] "RIPE Network Coordination Centre", <http://www.ripe.net>.
Authors’ Addresses
Vince Fuller
170 W. Tasman Drive
San Jose, CA 95134
USA
EMail: vaf@cisco.com
Tony Li
555 Del Rey Avenue
Sunnyvale, CA 94085
Email: tli@tropos.com
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
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
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
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).