draft-ietf-grow-rfc1519bis-00.txt   draft-ietf-grow-rfc1519bis-01.txt 
GROW V. Fuller GROW V. Fuller
Internet-Draft T. Li Internet-Draft T. Li
Expires: October 16, 2005 Cisco Systems Expires: November 2, 2005 Cisco Systems
April 14, 2005 May 1, 2005
Classless Inter-Domain Routing (CIDR): The Internet Address Assignment Classless Inter-Domain Routing (CIDR): The Internet Address Assignment
and Aggregation Plan and Aggregation Plan
draft-ietf-grow-rfc1519bis-00 draft-ietf-grow-rfc1519bis-01
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions This document is an Internet-Draft and is subject to all provisions
of Section 3 of RFC 3667. By submitting this Internet-Draft, each of Section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of 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 is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with which he or she become aware will be disclosed, in accordance with
RFC 3668. RFC 3668.
skipping to change at page 1, line 37 skipping to change at page 1, line 36
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on October 16, 2005. This Internet-Draft will expire on November 2, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2005).
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 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.
Table of Contents Table of Contents
1. History and Problem Description . . . . . . . . . . . . . . 3 1. History and Problem Description . . . . . . . . . . . . . . 3
2. Classless addressing as a solution . . . . . . . . . . . . . 4 1.1 Status updates to CIDR documents . . . . . . . . . . . . . 4
2.1 Basic concept and prefix notation . . . . . . . . . . . . 5 2. Classless addressing as a solution . . . . . . . . . . . . . 6
3. Address assignment and routing aggregation . . . . . . . . . 7 2.1 Basic concept and prefix notation . . . . . . . . . . . . 6
3.1 Aggregation efficiency and limitations . . . . . . . . . . 7 3. Address assignment and routing aggregation . . . . . . . . . 9
3.2 Distributed assignment of address space . . . . . . . . . 9 3.1 Aggregation efficiency and limitations . . . . . . . . . . 9
4. Routing implementation considerations . . . . . . . . . . . 10 3.2 Distributed assignment of address space . . . . . . . . . 10
4.1 Rules for route advertisement . . . . . . . . . . . . . . 10 4. Routing implementation considerations . . . . . . . . . . . 11
4.2 How the rules work . . . . . . . . . . . . . . . . . . . . 11 4.1 Rules for route advertisement . . . . . . . . . . . . . . 12
4.3 A note on prefix filter formats . . . . . . . . . . . . . 12 4.2 How the rules work . . . . . . . . . . . . . . . . . . . . 13
4.4 Responsibility for and configuration of aggregation . . . 12 4.3 A note on prefix filter formats . . . . . . . . . . . . . 13
4.5 Route propagation and routing protocol considerations . . 14 4.4 Responsibility for and configuration of aggregation . . . 14
5. Example of new address assignments and routing . . . . . . . 14 4.5 Route propagation and routing protocol considerations . . 15
5.1 Address delegation . . . . . . . . . . . . . . . . . . . . 14 5. Example of new address assignments and routing . . . . . . . 16
5.2 Routing advertisements . . . . . . . . . . . . . . . . . . 16 5.1 Address delegation . . . . . . . . . . . . . . . . . . . . 16
6. Domain Name Service considerations . . . . . . . . . . . . . 17 5.2 Routing advertisements . . . . . . . . . . . . . . . . . . 18
7. Transition to a long term solution . . . . . . . . . . . . . 19 6. Domain Name Service considerations . . . . . . . . . . . . . 19
8. Analysis of CIDR's effect on global routing state . . . . . 19 7. Transition to a long term solution . . . . . . . . . . . . . 21
9. Conclusions and Recommendations . . . . . . . . . . . . . . 21 8. Analysis of CIDR's effect on global routing state . . . . . 21
10. Security Considerations . . . . . . . . . . . . . . . . . . 21 9. Conclusions and Recommendations . . . . . . . . . . . . . . 23
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 23 10. Security Considerations . . . . . . . . . . . . . . . . . . 23
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 25
12.1 Normative References . . . . . . . . . . . . . . . . . . 23 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
12.2 Informative References . . . . . . . . . . . . . . . . . 23 12.1 Normative References . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 25 12.2 Informative References . . . . . . . . . . . . . . . . . 25
Intellectual Property and Copyright Statements . . . . . . . 26 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 27
Intellectual Property and Copyright Statements . . . . . . . 28
1. History and Problem Description 1. 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 determining how the 32-bit address space would be used, certain
assumptions were made about the number of organizations to be 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
skipping to change at page 4, line 28 skipping to change at page 4, line 28
routing tables and to reduce the rate of consumption of IPv4 address routing tables and to reduce the rate of consumption of IPv4 address
space. It did not and does not attempt to solve the third problem, space. It did not and does not attempt to solve the third problem,
which is of a more long-term nature, but instead endeavors to ease which is of a more long-term nature, but instead endeavors to ease
enough of the short to mid-term difficulties to allow the Internet to enough of the short to mid-term difficulties to allow the Internet to
continue to function efficiently while progress is made on a longer- continue to function efficiently while progress is made on a longer-
term solution. 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 may
be found in [RFC1380] and at [LWRD]. be found in [RFC1380] and at [LWRD].
1.1 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 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 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 2.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.
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 2.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.
2. Classless addressing as a solution 2. 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
skipping to change at page 10, line 5 skipping to change at page 11, line 37
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.
Some of these issues are discussed at greater length in [RFC1518]. A historical perspective on these issues is described in [RFC1518].
Additional discussion may also be found in [RFC3221].
4. Routing implementation considerations 4. 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 [RFC2178], IS-IS [RFC1195], RIPv2
[RFC2453], and Cisco EIGRP, and the BGP4 exterior routing protocol [RFC2453], and Cisco EIGRP, and the BGP4 exterior routing protocol
skipping to change at page 23, line 18 skipping to change at page 25, line 18
analysis of security vulnerabilities in the global routing system analysis of security vulnerabilities in the global routing system
is beyond the scope of this document. is beyond the scope of this document.
11. Acknowledgments 11. 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 RFC1519 (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, Geoff Huston, Danny McPherson, Dave Meyer, Eliot Lear, (Barry Greene, Geoff Huston, Danny McPherson, Dave Meyer, Eliot Lear,
Bill Norton, Ted Seely, Philip Smith) whose comments, corrections, Bill Norton, Ted Seely, Philip Smith, Pekka Savola) whose comments,
and suggestions were invaluable. corrections, and suggestions were invaluable.
12. References 12. References
12.1 Normative References 12.1 Normative References
[RFC791] Postel, J., "Internet Protocol", RFC 791, September 1981. [RFC791] Postel, J., "Internet Protocol", RFC 791, September 1981.
12.2 Informative References 12.2 Informative References
[RFC1338] Fuller, V., Li, T., Varadhan, K., and J. Yu, [RFC1338] Fuller, V., Li, T., Varadhan, K., and J. Yu,
"Supernetting: an Address Assignment and Aggregation "Supernetting: an Address Assignment and Aggregation
Strategy", RFC 1338, June 1992. Strategy", RFC 1338, June 1992.
[RFC1519] Fuller, V., Li, T., Varadhan, K., and J. Yu, "Classless [RFC1519] Fuller, V., Li, T., Varadhan, K., and J. Yu, "Classless
Inter-Domain Routing: an Address Assignment and Inter-Domain Routing: an Address Assignment and
Aggregation Strategy", RFC 1519, September 1993. Aggregation Strategy", RFC 1519, September 1993.
[IANA] "Internet Assigned Numbers Authority", [IANA] "Internet Assigned Numbers Authority",
<http://www.iana.org>. <http://www.iana.org>.
[RFC3221] Huston, G., "Commentary on Inter-Domain Routing in the
Internet", RFC 3221, December 2001.
[NRO] "Number Resource Organization", <http://www.nro.net>. [NRO] "Number Resource Organization", <http://www.nro.net>.
[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.
[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>.
[RFC2178] Moy, J., "The OSPF Specification Version 2", RFC 2178, [RFC2178] Moy, J., "The OSPF Specification Version 2", RFC 2178,
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/