--- 1/draft-ietf-grow-rfc1519bis-03.txt 2006-02-08 01:12:32.000000000 +0100 +++ 2/draft-ietf-grow-rfc1519bis-04.txt 2006-02-08 01:12:32.000000000 +0100 @@ -1,20 +1,20 @@ GROW V. Fuller Internet-Draft Cisco Systems -Expires: May 12, 2006 T. Li - Portola Networks - November 8, 2005 +Expires: July 5, 2006 T. Li + Li Consulting + January 2006 Classless Inter-Domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan - draft-ietf-grow-rfc1519bis-03 + draft-ietf-grow-rfc1519bis-04 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that @@ -25,25 +25,25 @@ 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 May 12, 2006. + This Internet-Draft will expire on July 5, 2006. Copyright Notice - Copyright (C) The Internet Society (2005). + Copyright (C) The Internet Society (2006). 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. @@ -53,40 +53,40 @@ 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.3. A note on prefix filter formats . . . . . . . . . . . . . 13 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 + 8. Transition to a long term solution . . . . . . . . . . . . . . 18 + 9. Analysis of CIDR's effect on global routing state . . . . . . 18 + 10. Conclusions and Recommendations . . . . . . . . . . . . . . . 20 + 11. Status updates to CIDR documents . . . . . . . . . . . . . . . 21 + 12. Security Considerations . . . . . . . . . . . . . . . . . . . 23 + 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 + 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24 + 15. Appendix A: Area Director Comments and Responses . . . . . . . 24 + 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 + 16.1. Normative References . . . . . . . . . . . . . . . . . . . 26 + 16.2. Informative References . . . . . . . . . . . . . . . . . . 26 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28 + Intellectual Property and Copyright Statements . . . . . . . . . . 29 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. @@ -336,24 +336,25 @@ There are two, more complex, situations that reduce the effectiveness of aggregation: o An organization which is multi-homed. Because a multi-homed organization must be advertised into the system by each of its service providers, it is often not feasible to aggregate its routing information into the address space of any one of those providers. Note that the organization still may receive its address assignment out of a service provider's address space (which has other advantages), but a route to the organization's - prefix must still be explicitly advertised by all of its service - providers. For this reason, the global routing cost for a multi- - homed organization is generally the same as it was prior to the - adoption of CIDR. + prefix is, in the most general case, explicitly advertised by all + of its service providers. For this reason, the global routing + cost for a multi-homed organization is generally the same as it + was prior to the adoption of CIDR. A more detailed consideration + of multi-homing practices can be found in [RFC4116]. o An organization which changes service provider but does not renumber. This has the effect of "punching a hole" in one of the original service provider's aggregated route advertisements. CIDR handles this situation by requiring the newer service provider to advertise a specific advertisement for the re-homed organization; this advertisement is preferred over provider aggregates because it is a longer match. To maintain efficiency of aggregation, it is recommended that an organization which changes service providers plan to eventually migrate its network into a an prefix @@ -361,21 +362,26 @@ 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. + 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. 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 @@ -432,21 +438,21 @@ 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 + [RFC4271] all support this functionality, having been developed or modified as part of the deployment of classless inter-domain routing during the 1990s. Older interior routing protocols, such as RIP [RFC1058], HELLO, and Cisco IGRP, and older exterior routing protocols, such as EGP [RFC904], do not support explicit carriage of prefix length/mask and thus cannot be effectively used on the Internet in other than very limited, stub configurations. While their use may be appropriate in simple, legacy end-site configurations, they are considered obsolete and should NOT be used in transit networks connected to the global @@ -455,27 +461,27 @@ 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. 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). + 1. Forwarding in the Internet is done on a longest-match basis. + 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- specific routes must discard packets which match the aggregate route but not any of the more-specific routes. In other words, the "next hop" for the aggregate route should be the null destination. This is necessary to prevent forwarding loops when some addresses covered by the aggregate are not reachable. Note that during failures, partial routing of traffic to a site which takes its address space from one service provider but which is @@ -492,46 +498,47 @@ "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. + route should only be advertised to another routing domain when a + router is explicitly configured to do so - never as a non-configured, + "default" option. 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. + Rule #1 guarantees that the forwarding algorithm used is consistent + across routing protocols and implementations. 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 longest-match forwarding causes this not to work. + More details are provided in [RFC4116]. Rule #2 guarantees that no routing loops form due to aggregation. Consider a site that has been assigned 192.168.64/19 by its "parent" provider that has 192.168.0.0/16. The "parent" network will advertise 192.168.0.0/16 to the "child" network. If the "child" network were to lose internal connectivity to 192.168.65.0/24 (which is part of its aggregate), traffic from the "parent" to the to the "child" destined for 192.168.65.1 will follow the "child's" advertised route. When that traffic gets to the "child", however, - 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 + the child *must not* follow the route 192.168.0.0/16 back up to the + "parent", since that would result in a forwarding loop. Rule #2 says + 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. 5.3. A note on prefix filter formats Systems which process route announcements must be able to verify that @@ -576,45 +583,46 @@ (for example, a customer may wish for its service provider to generate aggregated routing information on its behalf); in such cases, aggregation is performed by a router in the second AS based on the routes that it receives from the first combined with configured policy information describing how those routes should be aggregated. It should be mentioned that one provider may choose to perform aggregation on the routes it receives from another without explicit agreement; this is termed "proxy aggregation". This can be a useful tool for reducing the amount of routing state that an AS must carry - and propagate to its customers and neighbors, proxy aggregation can - also create inconsistencies in global routing state. Consider what - happens if both AS 2 and 3 receive routes from AS 1 but AS 2 performs - proxy aggregation while AS 3 does not. Other AS's which receive - transit routing information from both AS 2 and AS 3 will see an - inconsistent view of the routing information originated by AS 1. - This may cause an unexpected shift of traffic toward AS 1 through AS - 3 for AS 3's customers and any others receiving transit routes from - AS 3. Because proxy aggregation can cause unanticipated consequences - for parts of the Internet that have no relationship with either the - source of the aggregated routes or the party providing aggregation, - it should be used with extreme caution. + and propagate to its customers and neighbors. However, proxy + aggregation can also create unintended consequences in traffic + engineering. Consider what happens if both AS 2 and 3 receive routes + from AS 1 but AS 2 performs proxy aggregation while AS 3 does not. + Other AS's which receive transit routing information from both AS 2 + and AS 3 will see an inconsistent view of the routing information + originated by AS 1. This may cause an unexpected shift of traffic + toward AS 1 through AS 3 for AS 3's customers and any others + receiving transit routes from AS 3. Because proxy aggregation can + cause unanticipated consequences for parts of the Internet that have + no relationship with either the source of the aggregated routes or + the party providing aggregation, it should be used with extreme + caution. Configuration of the routes to be combined into aggregates is an implementation of routing policy and does require some manually- maintained information. As an addition to the information that must be maintained for a set of routeable prefixes, aggregation configuration is typically just a line or two defining the range of the block of IPv4 addresses to aggregate. A site performing its own aggregation is doing so for address blocks that it has been assigned; a site performing aggregation on behalf of another knows this information based on an agreement to delegate aggregation. Assuming - a best common practice for network administrators to exchange lists - of prefixes to accept from one and other, configuration of - aggregation information does not introduce significant additional + that the best common practice for network administrators is to + exchange lists of prefixes to accept from each other, configuration + of aggregation information does not introduce significant additional administrative overhead. The generation of an aggregate route is usually specified either statically or in response to learning an active dynamic route for a prefix contained within the aggregate route. If such dynamic aggregate route advertisement is done, care should be taken that 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. @@ -666,39 +674,40 @@ o "C5" requiring fewer than 512 addresses (/23 or 2 x /24) o "C6" requiring fewer than 512 addresses (/23 or 2 x /24) In all cases, the number of IPv4 addresses "required" by each site is assumed to allow for significant growth. The service provider delegates its address space as follows: o C1: assign 10.24.0 through 10.24.7. This block of networks is described by the route 10.24.0.0/21 (mask 255.255.248.0) - o C2: assign 10.24.16 through 10.24.31. This block is described by the route 10.24.16.0/20 (mask 255.255.240.0) o C3: assign 10.24.8 through 10.24.11. This block is described by the route 10.24.8.0/22 (mask 255.255.252.0) 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, then - explicit routes all /24s will have to be carried. + within the provider's IGP. If, for some reason, the provider uses an + obsolete IGP that doesn't support classless routing or variable- + length subnets, then explicit routes for 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) @@ -776,96 +785,23 @@ 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 - was also constrained such that delegations were only permitted along - legacy, class A/B/C network number boundaries. This created a - difficult situation for more flexible, CIDR prefixes. Consider a - hypothetical large network provider named "BigNet" which has been - allocated the block 10.4.0.0 through 10.7.255.0 (the CIDR prefix - 10.4.0.0/14). Under the old delegation policies, the top-level IN- - ADDR.ARPA domain servers would need to have 1024 entries of the form: - - 0.4.10.IN-ADDR.ARPA. IN NS NS1.BIG.NET. - - 1.4.10.IN-ADDR.ARPA. IN NS NS1.BIG.NET. - - .... - - 255.7.10.IN-ADDR.ARPA. IN NS NS1.BIG.NET. - - By revising the policy as described above, this was reduced to four - delegation records: - - 4.10.IN-ADDR.ARPA. IN NS NS1.BIG.NET. - - 5.10.IN-ADDR.ARPA. IN NS NS1.BIG.NET. - - 6.10.IN-ADDR.ARPA. IN NS NS1.BIG.NET. - - 7.10.IN-ADDR.ARPA. IN NS NS1.BIG.NET. - - The provider then maintains further delegations of naming authority - for each individual /24 which it assigns, rather than having each - registered separately. Note that due to the way the DNS is designed, - it is still possible for the top-level IN-ADDR.ARPA name servers to - maintain the delegation information for individual networks for which - the provider is unwilling or unable to do so. The example above - illustrates only the records for a single name server. In the normal - case, there are usually several name servers for each domain, thus - the size of the examples will double or triple in the common cases. - - For BIG.NET to assign a blocks smaller than /24 to its customers, it - can similarly delegate DNS authority for those addresses. For - example, if it were to assign 10.4.99.64/26 to its customer - CUSTONE.COM and 10.4.99.128/27 to its customer CUSTTWO.COM, it could - add the following records to delegate DNS for the addresses to those - customers: - - 64.99.4.10.IN-ADDR.ARPA. IN NS NS1.CUSTONE.COM. - - 65.99.4.10.IN-ADDR.ARPA. IN NS NS1.CUSTONE.COM. - - .... - - 127.99.4.10.IN-ADDR.ARPA. IN NS NS1.CUSTONE.COM - - 128.99.4.10.IN-ADDR.ARPA. IN NS NS1.CUSTTWO.COM - - 129.99.4.10.IN-ADDR.ARPA. IN NS NS1.CUSTTWO.COM - - .... - - 159.99.4.10.IN-ADDR.ARPA. IN NS NS1.CUSTTWO.COM - - And if BIG.NET also assigned 10.4.99.160/30 to CUSTTHREE.COM but this - customer did not want to run its own DNS, BIG.NET could provide that - service for the customer by installing the appropriate PTR records: - - 160.99.4.10.IN-ADDR.ARPA. IN PTR NET.CUSTTHREE.COM. - - 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. + A description of techniques to populate the IN-ADDR.ARPA zone when + using address blocks that do not align to octet boundaries is + described in [RFC2317]. 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. @@ -938,42 +874,42 @@ 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. 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 + 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 hence 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 are exist to solve problems of regional or - even local scope and should not need to be globally propagated. + 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 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 @@ -982,86 +918,86 @@ 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 - o This Informational RFC described the status of CIDR deployment in + This Informational RFC described the status of CIDR deployment in 1993. As of 2005, CIDR has been thoroughly deployed, so this 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 + 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 + 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 + 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 + 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 + 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 + 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 + 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 + 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- @@ -1119,21 +1055,22 @@ 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. 13. IANA Considerations - [RFC Editor: This section to be remove prior to publication.] + [RFC Editor: This section to be removed prior to publication.] + There are no IANA Considerations raised in this document. 14. Acknowledgments The authors wish to express appreciation to the other original 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, Danny McPherson, Dave Meyer, Eliot Lear, Bill Norton, Ted Seely, Philip Smith, Pekka Savola) whose comments, corrections, @@ -1171,23 +1108,23 @@ 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 + and additional text on this topic, it is a matter where there is + a distinct risk of the document losing focus here. The topic of + this section is one of situations where there are constraints on aggregation, rather than a detailed examination of various mitigating steps. 8. The example in Section 5 uses network 10 rather than the documentation prefix 192.0.2.0/24. 9. The text is showing a practical example of aggregation using prefix sizes that would be encountered in an operational context. The documentation prefix is too small to encompass this example, and designated private address space was used in @@ -1208,97 +1145,101 @@ most effective presentation of this material. 16. References 16.1. Normative References [RFC791] Postel, J., "Internet Protocol", RFC 791, September 1981. 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. + [7007] "NANOG mailing list discussion of the "AS 7007" incident", + . - [RFC1519] Fuller, V., Li, T., Varadhan, K., and J. Yu, "Classless - Inter-Domain Routing: an Address Assignment and - Aggregation Strategy", RFC 1519, September 1993. + [CBGP] "Graph: Active BGP Table Entries, 1988 to Present", + . + + [CPOL] "CIDR Police - Please Pull Over and Show Us Your BGP", + . + + [CRPT] "The CIDR Report", . [IANA] "Internet Assigned Numbers Authority", . - [RFC3221] Huston, G., "Commentary on Inter-Domain Routing in the - Internet", RFC 3221, December 2001. + [LWRD] "The Long and Winding Road", + . [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", - . + [RFC904] Mills, D., "Exterior Gateway Protocol formal + specification", RFC 904, April 1984. - [RFC2178] Moy, J., "The OSPF Specification Version 2", RFC 2178, - July 1997. + [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. - [RFC2453] Malkin, G., "RIP Version 2", RFC 2453, November 1998. - - [RFC1771] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 - (BGP-4)", RFC 1771, March 1995. + [RFC1338] Fuller, V., Li, T., Varadhan, K., and J. Yu, + "Supernetting: an Address Assignment and Aggregation + Strategy", RFC 1338, June 1992. - [RFC1058] Hedrick, C., "Routing Information Protocol", RFC 1058, - June 1988. + [RFC1380] Gross, P. and P. Almquist, "IESG Deliberations on Routing + and Addressing", RFC 1380, November 1992. - [RFC904] Mills, D., "Exterior Gateway Protocol formal - specification", RFC 904, April 1984. + [RFC1518] Rekhter, Y. and T. Li, "An Architecture for IP Address + Allocation with CIDR", RFC 1518, September 1993. - [RFC3021] Retana, A., White, R., Fuller, V., and D. McPherson, - "Using 31-Bit Prefixes on IPv4 Point-to-Point Links", - RFC 3021, December 2000. + [RFC1519] Fuller, V., Li, T., Varadhan, K., and J. Yu, "Classless + Inter-Domain Routing: an Address Assignment and + Aggregation Strategy", RFC 1519, September 1993. [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997. - [RIPE] "RIPE Network Coordination Centre", . - - [RFC1518] Rekhter, Y. and T. Li, "An Architecture for IP Address - Allocation with CIDR", RFC 1518, September 1993. + [RFC2178] Moy, J., "The OSPF Specification Version 2", RFC 2178, + July 1997. [RFC2317] Eidnes, H., de Groot, G., and P. Vixie, "Classless IN- ADDR.ARPA delegation", RFC 2317, March 1998. - [CRPT] "The CIDR Report", . + [RFC2453] Malkin, G., "RIP Version 2", RFC 2453, November 1998. - [CBGP] "Graph: Active BGP Table Entries, 1988 to Present", - . + [RFC3021] Retana, A., White, R., Fuller, V., and D. McPherson, + "Using 31-Bit Prefixes on IPv4 Point-to-Point Links", + RFC 3021, December 2000. - [CPOL] "CIDR Police - Please Pull Over and Show Us Your BGP", - . + [RFC3221] Huston, G., "Commentary on Inter-Domain Routing in the + Internet", RFC 3221, December 2001. - [7007] "NANOG mailing list discussion of the "AS 7007" incident", - . + [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", . Authors' Addresses Vince Fuller 170 W. Tasman Drive San Jose, CA 95134 USA Email: vaf@cisco.com Tony Li - Portola Networks, Inc. + Li Consulting 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 @@ -1324,18 +1265,18 @@ This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement - Copyright (C) The Internet Society (2005). This document is subject + Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society.