--- 1/draft-ietf-grow-rfc1519bis-00.txt 2006-02-04 23:24:05.000000000 +0100 +++ 2/draft-ietf-grow-rfc1519bis-01.txt 2006-02-04 23:24:05.000000000 +0100 @@ -1,19 +1,18 @@ - GROW V. Fuller Internet-Draft T. Li -Expires: October 16, 2005 Cisco Systems - April 14, 2005 +Expires: November 2, 2005 Cisco Systems + May 1, 2005 Classless Inter-Domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan - draft-ietf-grow-rfc1519bis-00 + draft-ietf-grow-rfc1519bis-01 Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. 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 become aware will be disclosed, in accordance with RFC 3668. @@ -26,64 +25,65 @@ 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 http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at 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 (C) The Internet Society (2005). Abstract This memo discusses the strategy for address assignment of the existing 32-bit IPv4 address space with a view toward conserving the address space and limiting the growth rate of global routing state. This document obsoletes the original CIDR spec [RFC1519], with changes made both to clarify the concepts it introduced and, after more than twelve years, to update the Internet community on the results of deploying the technology described. Table of Contents 1. History and Problem Description . . . . . . . . . . . . . . 3 - 2. Classless addressing as a solution . . . . . . . . . . . . . 4 - 2.1 Basic concept and prefix notation . . . . . . . . . . . . 5 - 3. Address assignment and routing aggregation . . . . . . . . . 7 - 3.1 Aggregation efficiency and limitations . . . . . . . . . . 7 - 3.2 Distributed assignment of address space . . . . . . . . . 9 - 4. Routing implementation considerations . . . . . . . . . . . 10 - 4.1 Rules for route advertisement . . . . . . . . . . . . . . 10 - 4.2 How the rules work . . . . . . . . . . . . . . . . . . . . 11 - 4.3 A note on prefix filter formats . . . . . . . . . . . . . 12 - 4.4 Responsibility for and configuration of aggregation . . . 12 - 4.5 Route propagation and routing protocol considerations . . 14 - 5. Example of new address assignments and routing . . . . . . . 14 - 5.1 Address delegation . . . . . . . . . . . . . . . . . . . . 14 - 5.2 Routing advertisements . . . . . . . . . . . . . . . . . . 16 - 6. Domain Name Service considerations . . . . . . . . . . . . . 17 - 7. Transition to a long term solution . . . . . . . . . . . . . 19 - 8. Analysis of CIDR's effect on global routing state . . . . . 19 - 9. Conclusions and Recommendations . . . . . . . . . . . . . . 21 - 10. Security Considerations . . . . . . . . . . . . . . . . . . 21 - 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 23 - 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 - 12.1 Normative References . . . . . . . . . . . . . . . . . . 23 - 12.2 Informative References . . . . . . . . . . . . . . . . . 23 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 25 - Intellectual Property and Copyright Statements . . . . . . . 26 + 1.1 Status updates to CIDR documents . . . . . . . . . . . . . 4 + 2. Classless addressing as a solution . . . . . . . . . . . . . 6 + 2.1 Basic concept and prefix notation . . . . . . . . . . . . 6 + 3. Address assignment and routing aggregation . . . . . . . . . 9 + 3.1 Aggregation efficiency and limitations . . . . . . . . . . 9 + 3.2 Distributed assignment of address space . . . . . . . . . 10 + 4. Routing implementation considerations . . . . . . . . . . . 11 + 4.1 Rules for route advertisement . . . . . . . . . . . . . . 12 + 4.2 How the rules work . . . . . . . . . . . . . . . . . . . . 13 + 4.3 A note on prefix filter formats . . . . . . . . . . . . . 13 + 4.4 Responsibility for and configuration of aggregation . . . 14 + 4.5 Route propagation and routing protocol considerations . . 15 + 5. Example of new address assignments and routing . . . . . . . 16 + 5.1 Address delegation . . . . . . . . . . . . . . . . . . . . 16 + 5.2 Routing advertisements . . . . . . . . . . . . . . . . . . 18 + 6. Domain Name Service considerations . . . . . . . . . . . . . 19 + 7. Transition to a long term solution . . . . . . . . . . . . . 21 + 8. Analysis of CIDR's effect on global routing state . . . . . 21 + 9. Conclusions and Recommendations . . . . . . . . . . . . . . 23 + 10. Security Considerations . . . . . . . . . . . . . . . . . . 23 + 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 25 + 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 + 12.1 Normative References . . . . . . . . . . . . . . . . . . 25 + 12.2 Informative References . . . . . . . . . . . . . . . . . 25 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 27 + Intellectual Property and Copyright Statements . . . . . . . 28 1. History and Problem Description What is now known as the Internet started as a research project in the 1970s to design and develop a set of protocols that could be used with many different network technologies to provide a seamless, end- to-end facility for interconnecting a diverse set of end systems. When determining how the 32-bit address space would be used, certain assumptions were made about the number of organizations to be connected, the number of end systems per organization, and total @@ -141,20 +141,99 @@ routing tables and to reduce the rate of consumption of IPv4 address space. It did not and does not attempt to solve the third problem, which is of a more long-term nature, but instead endeavors to ease enough of the short to mid-term difficulties to allow the Internet to continue to function efficiently while progress is made on a longer- term solution. More historical background on this effort and on the ROAD group may be found in [RFC1380] and at [LWRD]. +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 The solution that the community created was to deprecate the Class A/B/C network address assignment system in favor of using "classless", hierarchical blocks of IP addresses (referred to as prefixes). The assignment of prefixes is intended to roughly follow the underlying Internet topology so that aggregation can be used to facilitate scaling of the global routing system. One implication of this strategy is that prefix assignment and aggregation is generally done according to provider-subscriber relationships, since that is @@ -406,21 +485,22 @@ improved the efficiency and response time for new assignments. Hierarchical delegation of addresses in this manner implies that sites with addresses assigned out of a given service provider are, for routing purposes, part of that service provider and will be routed via its infrastructure. This implies that routing information about multi-homed organizations, i.e., organizations connected to more than one network service provider, will still need to be known by higher levels in the hierarchy. - 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 With the change from classful network numbers to classless prefixes, it is not possible to infer the network mask from the initial bit pattern of an IPv4 address. This has implications for how routing information is stored and propagated. Network masks or prefix lengths must be explicitly carried in routing protocols. Interior routing protocols such as OSPF [RFC2178], IS-IS [RFC1195], RIPv2 [RFC2453], and Cisco EIGRP, and the BGP4 exterior routing protocol @@ -1032,42 +1111,45 @@ analysis of security vulnerabilities in the global routing system is beyond the scope of this document. 11. Acknowledgments The authors wish to express appreciation to the other original authors of RFC1519 (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, Geoff Huston, Danny McPherson, Dave Meyer, Eliot Lear, - Bill Norton, Ted Seely, Philip Smith) whose comments, corrections, - and suggestions were invaluable. + Bill Norton, Ted Seely, Philip Smith, Pekka Savola) whose comments, + corrections, and suggestions were invaluable. 12. References 12.1 Normative References [RFC791] Postel, J., "Internet Protocol", RFC 791, September 1981. 12.2 Informative References [RFC1338] Fuller, V., Li, T., Varadhan, K., and J. Yu, "Supernetting: an Address Assignment and Aggregation Strategy", RFC 1338, June 1992. [RFC1519] Fuller, V., Li, T., Varadhan, K., and J. Yu, "Classless Inter-Domain Routing: an Address Assignment and Aggregation Strategy", RFC 1519, September 1993. [IANA] "Internet Assigned Numbers Authority", . + [RFC3221] Huston, G., "Commentary on Inter-Domain Routing in the + Internet", RFC 3221, December 2001. + [NRO] "Number Resource Organization", . [RFC1380] Gross, P. and P. Almquist, "IESG Deliberations on Routing and Addressing", RFC 1380, November 1992. [LWRD] "The Long and Winding Road", . [RFC2178] Moy, J., "The OSPF Specification Version 2", RFC 2178, July 1997.