--- 1/draft-ietf-grow-rfc1519bis-02.txt 2006-02-04 17:22:11.000000000 +0100 +++ 2/draft-ietf-grow-rfc1519bis-03.txt 2006-02-04 17:22:11.000000000 +0100 @@ -1,19 +1,20 @@ GROW V. Fuller -Internet-Draft T. Li -Expires: December 12, 2005 Cisco Systems - June 10, 2005 +Internet-Draft Cisco Systems +Expires: May 12, 2006 T. Li + Portola Networks + November 8, 2005 Classless Inter-Domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan - draft-ietf-grow-rfc1519bis-02 + draft-ietf-grow-rfc1519bis-03 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 @@ -24,67 +25,80 @@ 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 December 12, 2005. + This Internet-Draft will expire on May 12, 2006. 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 - 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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. History and Problem Description . . . . . . . . . . . . . . . 3 + 3. Classless addressing as a solution . . . . . . . . . . . . . . 4 + 3.1. Basic concept and prefix notation . . . . . . . . . . . . 5 + 4. Address assignment and routing aggregation . . . . . . . . . . 8 + 4.1. Aggregation efficiency and limitations . . . . . . . . . . 8 + 4.2. Distributed assignment of address space . . . . . . . . . 9 + 5. Routing implementation considerations . . . . . . . . . . . . 10 + 5.1. Rules for route advertisement . . . . . . . . . . . . . . 11 + 5.2. How the rules work . . . . . . . . . . . . . . . . . . . . 12 + 5.3. A note on prefix filter formats . . . . . . . . . . . . . 12 + 5.4. Responsibility for and configuration of aggregation . . . 13 + 5.5. Route propagation and routing protocol considerations . . 14 + 6. Example of new address assignments and routing . . . . . . . . 15 + 6.1. Address delegation . . . . . . . . . . . . . . . . . . . . 15 + 6.2. Routing advertisements . . . . . . . . . . . . . . . . . . 17 + 7. Domain Name Service considerations . . . . . . . . . . . . . . 18 + 8. Transition to a long term solution . . . . . . . . . . . . . . 20 + 9. Analysis of CIDR's effect on global routing state . . . . . . 20 + 10. Conclusions and Recommendations . . . . . . . . . . . . . . . 22 + 11. Status updates to CIDR documents . . . . . . . . . . . . . . . 22 + 12. Security Considerations . . . . . . . . . . . . . . . . . . . 24 + 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 + 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26 + 15. Appendix A: Area Director Comments and Responses . . . . . . . 26 + 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 + 16.1. Normative References . . . . . . . . . . . . . . . . . . . 27 + 16.2. Informative References . . . . . . . . . . . . . . . . . . 27 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30 + Intellectual Property and Copyright Statements . . . . . . . . . . 31 -1. History and Problem Description +1. Introduction + + This memo discusses the strategy for address assignment of the + existing 32-bit IPv4 address space with a view toward conserving the + address space and limiting the growth rate of global routing state. + This document obsoletes the original CIDR spec [RFC1519], with + changes made both to clarify the concepts it introduced and, after + more than twelve years, to update the Internet community on the + results of deploying the technology described. + +2. History and Problem Description What is now known as the Internet started as a research project in the 1970s to design and develop a set of protocols that could be used with many different network technologies to provide a seamless, end- to-end facility for interconnecting a diverse set of end systems. When 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 number of end systems on the network. The end result was the establishment (see [RFC791]) of three classes of networks: class A @@ -140,137 +154,63 @@ 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 +3. Classless addressing as a solution The solution that the community created was to deprecate the Class A/B/C network address assignment system in favor of using "classless", hierarchical blocks of IP addresses (referred to as prefixes). The assignment of prefixes is intended to roughly follow the underlying Internet topology so that aggregation can be used to facilitate scaling of the global routing system. One implication of this strategy is that prefix assignment and aggregation is generally done according to provider-subscriber relationships, since that is how the Internet topology is determined. When originally proposed in [RFC1338] and [RFC1519], this addressing plan was intended to be a relatively short-term response, lasting approximately three to five years during which a more permanent addressing and routing architecture would be designed and implemented. As can be inferred from the dates on the original documents, CIDR has far outlasted its anticipated lifespan and has become the mid-term solution to the problems described above. + It should be noted that in the following text, we describe the + current policies and procedures that have been put in place to + implement the allocation architecture discussed here. This + description is not intended to be interpreted as direction to IANA. + Coupled with address management strategies implemented by the Regional Internet Registries (see [NRO] for details), the deployment of CIDR-style addressing has also reduced the rate at which IPv4 address space has been consumed, thus providing short-to-medium-term relief to problem #3 described above. Note that, as defined, this plan neither requires nor assumes the re- assignment of those parts of the legacy "class C" space that are not amenable to aggregation (sometimes called "the swamp"). Doing so would somewhat reduce routing table sizes (current estimate is that "the swamp" contains approximately 15,000 entries) though at a significant renumbering cost. Similarly, there is no hard requirement that any end site renumber when changing transit service provider but end sites are encouraged do so to eliminate the need for explicit advertisement of their prefixes into the global routing system. -2.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 classless prefixes is to make explicit which bits in a 32-bit IPv4 address are interpreted as the network number (or prefix) associated with a site and which are the used to number individual end systems within the site. In CIDR notation, a prefix is shown as a 4-octet quantity, just like a traditional IPv4 address or network number, followed by the "/" (slash) character, followed by a decimal value between 0 and 32 that describes the number of significant bits. @@ -310,21 +250,21 @@ of addresses received. The following table provides a convenient short-cut to all of the CIDR prefix sizes, showing the number of addresses possible in each prefix and the number of prefixes of that size that may be numbered in the 32-bit IPv4 address space: notation addrs/block # blocks -------- ----------- ---------- n.n.n.n/32 1 4294967296 "host route" - n.n.n.x/31 2 2147483648 "[RFC3021] p2p link" + n.n.n.x/31 2 2147483648 "p2p link" n.n.n.x/30 4 1073741824 n.n.n.x/29 8 536870912 n.n.n.x/28 16 268435456 n.n.n.x/27 32 134217728 n.n.n.x/26 64 67108864 n.n.n.x/25 128 33554432 n.n.n.0/24 256 16777216 legacy "class C" n.n.x.0/23 512 8388608 n.n.x.0/22 1024 4194304 n.n.x.0/21 2048 2097152 @@ -343,43 +283,44 @@ n.0.0.0/8 16777216 256 legacy "class A" x.0.0.0/7 33554432 128 x.0.0.0/6 67108864 64 x.0.0.0/5 134217728 32 x.0.0.0/4 268435456 16 x.0.0.0/3 536870912 8 x.0.0.0/2 1073741824 4 x.0.0.0/1 2147483648 2 0.0.0.0/0 4294967296 1 "default route" - n is an 8-bit, decimal octet value. + n is an 8-bit, decimal octet value. Point to point links are + discussed in more detail in [RFC3021]. x is a 1 to 7 bit value, base on the prefix length, shifted into the most significant bits of the octet and converted into decimal form; the least significant bits of the octet are zero. - In practice, prefixes of length shorter than 8 are not allocated or - assigned though routes to such short prefixes may exist in routing - tables if or when aggressive aggregation is performed. As of the - writing of this document, no such routes are seen in the global - routing system but operator error and other events have caused some - of them (i.e. 128.0.0.0/1 and 192.0.0.0/2) to be observed in some - networks at some times in the past. + In practice, prefixes of length shorter than 8 have not been + allocated or assigned to date, although routes to such short prefixes + may exist in routing tables if or when aggressive aggregation is + performed. As of the writing of this document, no such routes are + seen in the global routing system but operator error and other events + have caused some of them (i.e. 128.0.0.0/1 and 192.0.0.0/2) to be + observed in some networks at some times in the past. -3. Address assignment and routing aggregation +4. Address assignment and routing aggregation Classless addressing and routing was initially developed primarily to improve the scaling properties of routing on the global Internet. Because the scaling of routing is very tightly coupled to the way that addresses are used, deployment of CIDR had implications for the way in which addresses were assigned. -3.1 Aggregation efficiency and limitations +4.1. Aggregation efficiency and limitations The only commonly-understood method for reducing routing state on a packet-switched network is through aggregation of information. For CIDR to succeed in reducing the size and growth rate of the global routing system, the IPv4 address assignment process needed to be changed to make possible the aggregation of routing information along topological lines. Since, in general, the topology of the network is determined by the service providers who have built it, topologically- significant address assignments are necessarily service-provider oriented. @@ -420,46 +361,41 @@ is recommended that mechanisms to facilitate such migration, such as dynamic host address assignment using [RFC2131]) be deployed wherever possible, and that additional protocol work be done to develop improved technology for renumbering. Note that some aggregation efficiency gain can still be had for multi-homed sites (and, in general, for any site composed of multiple, logical IPv4 networks) - by allocating a contiguous power- of-two block address space to the site (as opposed to multiple, independent prefixes) the site's routing information may be - aggregated into a single prefix. Also, since the routing cost - associated with assigning a multi-homed site out of a service - provider's address space is no greater than the old method of - sequential number assignment by a central authority, it makes sense - to assign all end-site address space out of blocks allocated to - service providers. + aggregated into a single prefix. It is also worthwhile to mention that since aggregation may occur at multiple levels in the system, it may still be possible to aggregate these anomalous routes at higher levels of whatever hierarchy may be present. For example, if a site is multi-homed to two relatively small providers that both obtain connectivity and address space from the same large provider, then aggregation by the large provider of routes from the smaller networks will include all routes to the multi-homed site. The feasibility of this sort of second-level aggregation depends on whether topological hierarchy exists between a site, its directly-connected providers, and other providers to which they are connected; it may be practical in some regions of the global Internet but not in others. Note: in the discussion and examples which follow, prefix notation is used to represent routing destinations. This is used for illustration only and does not require that routing protocols use this representation in their updates. -3.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 performed by the central Network Information Center (NIC). Class A/B/C network numbers were assigned in essentially arbitrary order, roughly according to the size of the organizations that requested them. All assignments were recorded centrally and no attempt was made to assign network numbers in a manner that would allow routing aggregation. When CIDR was originally deployed, the central assignment authority @@ -487,21 +423,21 @@ sites with addresses assigned out of a given service provider are, for routing purposes, part of that service provider and will be routed via its infrastructure. This implies that routing information about multi-homed organizations, i.e., organizations connected to more than one network service provider, will still need to be known by higher levels in the hierarchy. A historical perspective on these issues is described in [RFC1518]. Additional discussion may also be found in [RFC3221]. -4. Routing implementation considerations +5. Routing implementation considerations With the change from classful network numbers to classless prefixes, it is not possible to infer the network mask from the initial bit pattern of an IPv4 address. This has implications for how routing information is stored and propagated. Network masks or prefix lengths must be explicitly carried in routing protocols. Interior routing protocols such as OSPF [RFC2178], IS-IS [RFC1195], RIPv2 [RFC2453], and Cisco EIGRP, and the BGP4 exterior routing protocol [RFC1771] all support this functionality, having been developed or modified as part of the deployment of classless inter-domain routing @@ -517,21 +453,21 @@ Internet. Similarly, routing and forwarding tables in layer-3 network equipment must be organized to store both prefix and prefix length or mask. Equipment which organizes its routing/forwarding information according to legacy class A/B/C network/subnet conventions cannot be expected to work correctly on networks connected to the global Internet; use of such equipment is not recommended. Fortunately, very little such equipment is in use today. -4.1 Rules for route advertisement +5.1. Rules for route advertisement 1. Routing to all destinations must be done on a longest-match basis only. This implies that destinations which are multi-homed relative to a routing domain must always be explicitly announced into that routing domain - they cannot be summarized (this makes intuitive sense - if a network is multi-homed, all of its paths into a routing domain which is "higher" in the hierarchy of networks must be known to the "higher" network). 2. A router which generates an aggregate route for multiple, more- @@ -545,35 +481,35 @@ takes its address space from one service provider but which is actually reachable only through another (i.e., the case of a site which has changed service providers) may occur because such traffic will be forwarded along the path advertised by the aggregated route. Rule #2 will prevent packet mis-delivery by causing such traffic to be discarded by the advertiser of the aggregated route, but the output of "traceroute" and other similar tools will suggest that a problem exists within that network rather than in the network which is no longer advertising the more-specific prefix. This may be confusing to those trying to diagnose connectivity problems; see the - example in Section 5.2 for details. A solution to this perceived + example in Section 6.2 for details. A solution to this perceived "problem" is beyond the scope of this document - it lies with better education of the user/operator community, not in routing technology. An implementation following these rules should also be generalized, so that an arbitrary network number and mask are accepted for all routing destinations. The only outstanding constraint is that the 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 all implementations. Further, to protect against accidental advertisements of this route via the inter-domain protocol, this route should only be advertised when a router is explicitly configured to do so - never as a non-configured, "default" option. -4.2 How the rules work +5.2. How the rules work Rule #1 guarantees that the routing algorithm used is consistent across implementations and consistent with other routing protocols, such as OSPF. Multi-homed networks are always explicitly advertised by every service provider through 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 explicitly advertised). It may seem as if the "primary" service provider could advertise the multi-homed site implicitly as part of its aggregate, but the assumption that longest-match routing is always done causes this not to work. @@ -589,21 +525,21 @@ the mid-level *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 that the "child" may not follow a less-specific route for a destination which matches one of its own aggregated routes (typically, this is implemented by installing a "discard" or "null" route for all aggregated prefixes which one network advertises to another). Note that handling of the "default" route (0.0.0.0/0) is a special case of this rule - a network must not follow the default to destinations which are part of one of it's aggregated advertisements. -4.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 information which they receive is acceptable according to policy rules. Implementations which filter route advertisements must allow masks or prefix lengths in filter elements. Thus, filter elements which formerly were specified as: accept 172.16.0.0 accept 172.25.120.0.0 accept 172.31.0.0 @@ -618,21 +554,21 @@ deny 10.2.0.0/16 accept 10.0.0.0/8 This is merely making explicit the network mask which was implied by 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 all more-specific prefixes with the same bit pattern; fortunately, this functionality has been implemented by most vendors of equipment used on the Internet. -4.4 Responsibility for and configuration of aggregation +5.4. Responsibility for and configuration of aggregation Under normal circumstances, a routing domain (or "Autonomous System") which has been allocated or assigned a set of prefixes has sole responsibility for aggregation of those prefixes. In the usual case, the AS will install configuration in one or more of its routers to generate aggregate routes based on more-specific routes known to its internal routing system; these aggregate routes are advertised into the global routing system by the border routers for the routing domain. The more-specific internal routes which overlap with the aggregate routes should not be advertised globally. In some cases, @@ -681,39 +617,39 @@ routes are not excessively added or withdrawn (known as "route flapping"); in general, a dynamic aggregate route advertisement is added when at least one component of the aggregate becomes reachable and it is withdrawn only when all components become unreachable. Properly configured, aggregated routes are more stable than non- aggregated routes and thus improve global routing stability. Implementation note: aggregation of the "Class D" (multicast) address space is beyond the scope of this document. -4.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 propagate routes learned via exterior routing protocols (i.e. EGP or BGP) through a site's interior routing protocol (typically, OSPF, IS-IS, or RIP). This was done to ensure that consistent and correct exit points were chosen for traffic destined to a destination learned through those protocols. Four evolutionary effects -- the advent of CIDR, explosive growth of global routing state, widespread adoption of BGP4, and a requirement to propagate full path information -- have combined to deprecate that practice. To ensure proper path propagation and prevent inter-AS routing inconsistency (BGP4's loop detection/prevention mechanism requires full path propagation), transit networks must use internal BGP (iBGP) for carrying routes learned from other providers both within and through their networks. -5. Example of new address assignments and routing +6. Example of new address assignments and routing -5.1 Address delegation +6.1. Address delegation 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 provider, "PA". This is equivalent in size to a block of 2048 legacy "class C" network numbers (or /24s). A classless route to this block would be described as 10.24.0.0 with mask of 255.248.0.0 the prefix 10.24.0.0/13. Assume this service provider connects six sites in the following order (significant because it demonstrates how temporary "holes" may @@ -747,23 +683,22 @@ o C4: assign 10.24.12 through 10.24.15. This block is described by the route 10.24.12.0/22 (mask 255.255.252.0) o C5: assign 10.24.32 and 10.24.33. This block is described by the 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 within the provider IGP. If, for some reason, the provider were to - use an obsolete IGP that doesn't support classless routing or - variable-length subnets, then then explicit routes all /24s will have - to be carried. + use an obsolete IGP that doesn't support classless routing, then + explicit routes all /24s will have to be carried. To make this example more realistic, assume that C4 and C5 are multi- homed through some other service provider, "PB". Further assume the existence of a site "C7" which was originally connected to "RB" but 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. 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) @@ -792,21 +727,21 @@ || || routing advertisements: || || || || 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.24.0.0/13 (PA) || 10.32.0.0/13 (PB) || || || VV VV +---------- BACKBONE NETWORK BB ----------+ -5.2 Routing advertisements +6.2. Routing advertisements 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 through PA, it must also be advertised. C5 is multi-homed and primary through PB. In principal (and in the example above), it need not be advertised since longest match by PB will automatically select PB as primary and the advertisement of PA's aggregate will be used as a secondary. In actual practice, C5 will normally be advertised via both providers. @@ -818,35 +753,35 @@ For PB, the advertisements must also include C4 and C5 as well as it's block of addresses. Advertisements from "PB" to "BB" will be: 10.24.12.0/22 secondary (advertises C4) 10.24.32.0/23 primary (advertises C5) 10.32.0.0/13 primary (advertises remainder of RB) - To illustrate the problem diagnosis issue mentioned in Section 4.1, + To illustrate the problem diagnosis issue mentioned in Section 5.1, consider what happens if PA loses connectivity to C7 (the site which 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 BB flushes this information out of its routing table, any future 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 less specific match 10.32.0.0/13. While this does not cause an operational problem (C7 is unreachable in any case), it does create some extra traffic across "BB" (and may also prove confusing to someone trying to debug the outage with "traceroute"). A mechanism to cache such unreachable state might be nice but is beyond the scope of this document. -6. Domain Name Service considerations +7. Domain Name Service considerations One aspect of Internet services which was notably affected by the move to CIDR was the mechanism used for address-to-name translation: the IN-ADDR.ARPA zone of the domain system. Because this zone is delegated on octet boundaries only, the move to an address assignment plan which uses bitmask-oriented addressing caused some increase in work for those who maintain parts of the IN-ADDR.ARPA zone. As described above, the IN-ADDR.ARPA zone is necessarily organized along octet boundaries. Prior to the adoption of CIDR, IN-ADDR.ARPA @@ -918,30 +853,30 @@ 161.99.4.10.IN-ADDR.ARPA. IN PTR HOST1.CUSTTHREE.COM. 162.99.4.10.IN-ADDR.ARPA. IN PTR HOST2.CUSTTHREE.COM. 163.99.4.10.IN-ADDR.ARPA. IN PTR BCAST.CUSTTHREE.COM. See [RFC2317] for a much more detailed discussion of DNS delegation with classless addressing. -7. 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 routing state and address depletion on the IPv4 Internet. It does not change the fundamental Internet routing or addressing architectures. It is not expected to affect any plans for transition to a more long-term solution except, perhaps, by delaying the urgency of developing such a solution. -8. 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 made some observations about the growth rate of global routing state and offered projections on how CIDR deployment would, hopefully, reduce what appeared to be exponential growth to a more sustainable rate. Since that deployment, an ongoing effort, called "The CIDR 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, with an attempt to explain the various patterns of and change in growth rate that have occurred since measurements of the size of @@ -955,21 +890,21 @@ 1. Exponential growth at the far left of the graph. This represents the period of early expansion and commercialization of the former research network, from the late 1980s through approximately 1994. The major driver for this growth was a lack of aggregation capability for transit providers, and the widespread use of legacy Class C allocations for end sites. Each time a new site was connected to the global Internet, one or more new routing entries were generated. 2. Acceleration of the exponential trend in late 1993 and early 1994 - as CIDR supernet" blocks were first assigned by the NIC and + as CIDR "supernet" blocks were first assigned by the NIC and routed as separate legacy class-C networks by service provider. 3. A sharp drop in 1994 as BGP4 deployment by providers allowed aggregation of the "supernet" blocks. Note that the periods of largest declines in the number of routing table entries typically correspond to the weeks following each meeting of the IETF CIDR Deployment Working Group. 4. Roughly linear growth from mid-1994 to early 1999 as CIDR-based address assignments were made and aggregated routes added @@ -991,29 +926,29 @@ effort. 8. A more recent trend of exponential growth beginning in 2004. The best explanation would seem to be an improvement of the global economy driving increased expansion of the Internet and the continued absence of the "CIDR Police" effort, which previously served as an educational tool for new providers to improve aggregation efficiency. There have also been some cases where service providers have deliberately de-aggregated prefixes in an attempt to mitigate security problems caused by conflicting route - advertisements (see Section 10). While this behavior may solve + advertisements (see Section 12). While this behavior may solve the short-term problems seen by such providers, it is fundamentally non-scalable and quite detrimental to the community as a whole. In addition, there appear to be many providers advertising both their allocated prefixes and all of the /24 components of them, probably due to a lack of consistent current information about recommended routing configuration. -9. Conclusions and Recommendations +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 @@ -1040,100 +975,252 @@ that this trend can be mitigated by a more active effort to educate service providers on 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. -10. Security Considerations +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 + + o 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 + + o 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 + + o 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) + + o 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 + + o 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 + + o 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 + + o 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 + + o 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 + + o 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 which 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: - 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 normally advertised for that destination. For example, assume a popular end system with address 192.168.17.100 that 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. It is worth noting that "spammers" have been observed - using this sort of attack to temporarily hijack address space in - order to hide the origin of the traffic ("spam" email messages) - that they generate. + 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. It is worth noting that "spammers" have + been observed using this sort of attack to temporarily hijack + address space in order to hide the origin of the traffic ("spam" + email messages) that they generate. - 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 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 which caused this sort of - failure was the infamous "AS 7007" event [7007] where a router + good example of a non-malicious incident which 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 which 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 does tend 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 to also configure a - reasonable maximum number of prefixes that a border router will - accept from its neighbors. + 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 which 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 does tend 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 to also 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. + analysis of security vulnerabilities in the global routing system is + beyond the scope of this document. -11. Acknowledgments +13. IANA Considerations + + [RFC Editor: This section to be remove prior to publication.] + There are no IANA Considerations raised in this document. + +14. 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, Pekka Savola) whose comments, - corrections, and suggestions were invaluable. + (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. -12. References +15. Appendix A: Area Director Comments and Responses -12.1 Normative 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, there would then be a + distinct risk of the document losing focus. 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 [RFC791] Postel, J., "Internet Protocol", RFC 791, September 1981. -12.2 Informative References +16.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", @@ -1197,25 +1284,23 @@ Authors' Addresses Vince Fuller 170 W. Tasman Drive San Jose, CA 95134 USA Email: vaf@cisco.com Tony Li - 170 W. Tasman Drive - San Jose, CA 95134 - USA + Portola Networks, Inc. - Email: tli@cisco.com + Email: tony.li@tony.li Intellectual Property Statement 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