CIDR for IPv6: Address Aggregation, Allocation, and Assignment Strategy
draft-azinger-cidrv6-00

Abstract

This document discusses strategies for assigning and aggregating IPv6 address space. While CIDR was created to help alleviate this problem in regards to IPv4 addresses with the original [RFC1519] (Fuller, V., Li, T., Yu, J., and K. Varadhan, “Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy,” September 1993.) (and updated in [RFC4632] (Fuller, V. and T. Li, “Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan,” August 2006.)) we are now in need of a similar document to give direction for IPv6 addressing policies. Similarly, [RFC1518] (Rekhter, Y. and T. Li, “An Architecture for IP Address Allocation with CIDR,” September 1993.) discussed how to use CIDR to allocate address space for IPv4, and [RFC1887] (Rekhter, Y. and T. Li, “An Architecture for IPv6 Unicast Address Allocation,” December 1995.) discusses the subject for IPv6. The objective here is to update these documents and provide the best current guidance on how to manage address space in conjunction with managing the growth of routing tables in an IPv6 world.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months 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.”

This Internet-Draft will expire on December 31, 2010.

Copyright Notice

Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

1.  Introduction
2.  Contributing factors to the problem
3.  Aggregation
4.  Allocation plan
5.  Current Statistics and Projections
    5.1.  Analysis
    5.2.  Projections
    5.3.  Impact of CIDR
6.  Protocol
7.  Rules for Route Advertisements
8.  Responsibility of configuration and aggregation
9.  Procedural Changes
10.  Recommendations
11.  Acknowledgements
12.  References
    12.1.  Normative References
    12.2.  Informative References

1.  Introduction

The Internet has continued to evolve and the demands placed on its infrastructure continue to grow at an increasing rate. While there are a number of contributing factors there are a few key elements that have led to a concerning escalation in routing table growth and have made scalability an area of serious concern for network operators. Effort must be put forward to minimize the impact of IPv6 deployment to the routing system. Two key aspects of this system include routing table churn composed of routing advertisements and withdrawals and the routing table size as measured by the number of entries in the DFZ, the Default-Free zone. While retaining current Internet practices, this document addresses the problem of routing table size by examining steps to minimize the impact of Multi-homing and Traffic Engineering, two widely implemented features that provide enhanced network resiliency and traffic path control.

2.  Contributing factors to the problem

There are several factors that work against routing table scalability. A full description of the contributing factors and views can be read in [I‑D.narten‑radir‑problem‑statement] (Narten, T., “On the Scalability of Internet Routing,” February 2010.). The exhaustion of the unassigned IPv4 address space is the principal motivator resulting in two of the key growth drivers. The first driver is the presence of increasingly longer prefixes in the DFZ Over the years the longest prefix generally accepted globally has increased from a relatively small number of classful prefixes to a preponderance of classless /24 CIDR prefixes. As IPv4 address availability diminishes, more Internet users are and will continue to push their providers to route even longer prefixes externally that in the past were filtered. This is something that we must look to minimize and find ways to deter as much as possible.

The second driver resulting from IPv4 address exhaustion is the rapid uptake in IPv6 deployment by providers and end users. This adoption, while clearly in the best interest for the long term viability of the Internet, contributes a unique set of challenges that must be addressed to promote efficient routing table growth. Some of these challenges visible today are the liberal assignment of Provider Independent (PI) space to end users, micro-allocations, and critical network infrastructure allocations by the various RIRs.

These drivers have increased the need for more guidance on routing policy in order to limit the number of unnecessary entries in the global routing table. The future impact of this increased pressure on routing table growth is an area of immediate concern.

3.  Aggregation

The common method for reducing state on both internal and external routing tables is through aggregation of information. Borrowing from experience gained in operating IPv4 networks, in order for CIDR to succeed in reducing the global routing system growth rate, the IPv6 address assignment process needs to make aggregation of routing information along topological lines. In general, the topology of the network has not changed since IPv4 CIDR and even with IPv6 the topology of the network is still determined by the service providers who have built it. . Topologically significant address assignments are necessarily service-provider oriented.

Start of Excerpt from [RFC4632] (Fuller, V. and T. Li, “Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan,” August 2006.)

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.

Aggregation is simple for an end site that is connected to one service provider: it uses address space assigned by its service provider, and that address space is a small piece of a larger block allocated to the service provider. No explicit route is needed for the end site; the service provider advertises a single aggregate route for the larger block. This advertisement provides reachability and routeability for all the customers numbered in the block.

There are two, more complex, situations that reduce the effectiveness of aggregation:

• An organization that 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 that a route to the organization's 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] (Abley, J., Lindqvist, K., Davies, E., Black, B., and V. Gill, “IPv4 Multihoming Practices and Limitations,” July 2005.).
• An organization that 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 that 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 that changes service providers plan eventually to migrate its network into a an prefix assigned from its new provider's address space. To this end, it is recommended that mechanisms to facilitate such migration, such as dynamic host address assignment that uses [RFC2131] (Droms, R., “Dynamic Host Configuration Protocol,” March 1997.)), be deployed wherever possible, and that additional protocol work be done to develop improved technology for renumbering.

End of Excerpt from [RFC4632] (Fuller, V. and T. Li, “Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan,” August 2006.)

It is important to recognize that some efficiency can still be gained with multi-homed sites (and in general, for any site composed of multiple, logical IPv6 networks).

Start of Excerpt from [RFC4632] (Fuller, V. and T. Li, “Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan,” August 2006.)

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.

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 among 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.

End of Excerpt from [RFC4632] (Fuller, V. and T. Li, “Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan,” August 2006.)

4.  Allocation plan

Allocations of /32 or shorter prefixes are best provided to network service providers from their regional registries. RIR initial and subsequent allocation policy to service providers should allow for a minimum of 2 years worth of usage based on historical or business plan projections. Organizations should be assigned appropriate subnets from their network service providers larger aggregate allocations that are in turn appropriately sized, such as /48 for organizations wishing to multi-home.

Start of Excerpt from [RFC4632] (Fuller, V. and T. Li, “Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan,” August 2006.)

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.

A historical perspective on these issues is described in [RFC1518] (Rekhter, Y. and T. Li, “An Architecture for IP Address Allocation with CIDR,” September 1993.). Additional discussion may also be found in [RFC3221] (Huston, G., “Commentary on Inter-Domain Routing in the Internet,” December 2001.).

End of Excerpt from [RFC4632] (Fuller, V. and T. Li, “Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan,” August 2006.)

Similarly to the days of classful routing, IPv6 is following the same historical path of giving PI assignments. It is in the interests of the network infrastructure to document a best practice for obtaining IPv6 addresses, and it is recommended that most, if not all, network numbers be distributed through service providers. Using the process proposed in this document will support this from becoming a growing problem and will also reduce the scalability concerns core engineers face and the workload for Regional Registries.

5.  Current Statistics and Projections

The good news is that IPv6 has started growing at a significant rate. The bad news is that IPv6 has started growing at a significant rate. Table 1 shows the observed growth for 2009.

Table 1: IPv6 Routing Table Statistics for 2009 [Huston] (Huston, G., “BGP in 2009,” .).

There are several salient points that should be extracted from this table. The first, and foremost, is that the routing table is now growing rapidly. At 54% growth, this is faster than Moore's law would accommodate. The roots are prefixes that have no 'less specifics' in the routing table. Even at 50% growth per year, this number exceeds Moore's law. More specifics are typically injected to support traffic engineering or multi-homing.

The AS count growth shows the number of new organizations participating in BGP. Transit ASes are routing domains that have multiple peer ASes. Stub ASes are routing domains that have only a single peer AS.

5.1.  Analysis

These numbers show that 610 new organizations have joined IPv6 routing. Of these new organizations, 85% are stub ASes. The new organizations are injecting 860 new prefixes. Of these, 76% are root prefixes. Since any new AS must inject at least one prefix into routing to be counted, there would appear to be a very high correlation between new stub ASes and new root prefixes. From this, it seems reasonable to conclude that the bulk of the new root prefixes are injected by stub ASes. Further, since it seems unlikely that most of these stub ASes will turn into transit ASes in the future, it also seems reasonable to conclude that these organizations are actually end-user organizations who are injecting routes based on their PI address assignments.

Thus, the bulk of the routing table growth appears to be due to PI prefix injection.

5.2.  Projections

Given the high state of flux in the deployment of IPv6, it seems difficult to conclude that the statistics from 2009 will be representative of future routing table growth. Thanks to the influx of new users who are being forced onto IPv6 by the impending IPv4 runout, there are plausible arguments that would suggest that growth could accelerate. There are also plausible arguments that suggest that as IPv6 deployment reaches ubiquity, that the growth might curtail in a logistic S-curve. Lacking more data, it is difficult to clearly argue that either of these results is inevitable.

It is possible, however, to look at the implications of the current growth rate, if it is sustained at the 2009 rate of 54%. Table 2 shows this growth rate:

Table 2: 54% growth rate, extrapolated

5.3.  Impact of CIDR

With the adoption of the plan outlined here, growth of the routing table in a default-free router is greatly reduced since most new address assignments will come from one of the large blocks allocated to the service providers. This plan recognizes the continued need for multi-homing and the requirement to offer multi-homing via IPv6. Due to this requirement multi-homing will be the main reason for the continued growth of the routing table size but not because of independent subnet statements based solely on the desire for independence.

6.  Protocol

This document requires that all parties implement routing protocols for IPv6 as previously published for IPv4 in [RFC4632] (Fuller, V. and T. Li, “Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan,” August 2006.).

7.  Rules for Route Advertisements

This document requires that all parties follow the rules for route advertisements for IPv6 as previously published for IPv4 in [RFC4632] (Fuller, V. and T. Li, “Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan,” August 2006.).

8.  Responsibility of configuration and aggregation

This document requires that all parties take responsibility of configuration or aggregation for IPv6 as previously published for IPv4 in [RFC4632] (Fuller, V. and T. Li, “Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan,” August 2006.).

9.  Procedural Changes

It is possible that some organizations will need to alter their filters to follow the guidance of this document. This is minimal and should not be considered an issue.

10.  Recommendations

Internet Registries should begin to hand out IPv6 blocks of /32 or shorter to network service providers in order to accommodate both their growth and their customers' growth. In addition Internet Registries should severely limit or eliminate the amount of PI assignments in order to help facilitate the decrease in routing table growth. Service providers will allocate /48's to their customer organizations with multi-home requirements. Implementation and deployment of these modifications should occur immediately.

11.  Acknowledgements

The authors would like to extend their thanks to the authors of [RFC4632] (Fuller, V. and T. Li, “Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan,” August 2006.) (and by extension, to the authors of [RFC1519] (Fuller, V., Li, T., Yu, J., and K. Varadhan, “Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy,” September 1993.)). Much of that work has been incorporated directly into this document as it is conceptually identical and simply translated to IPv6 herein.

12.  References

12.1. Normative References

12.2. Informative References

Authors' Addresses