Network Working Group M. Azinger
Internet-Draft Frontier Communications
Updates: 1887 (if approved) Corporation
Intended status: Standards Track T. Li
Expires: December 31, 2010 Cisco Systems
J. Weil
Cox Communications
June 29, 2010
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] (and updated
in [RFC4632]) we are now in need of a similar document to give
direction for IPv6 addressing policies. Similarly, [RFC1518]
discussed how to use CIDR to allocate address space for IPv4, and
[RFC1887] 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.
Azinger, et al. Expires December 31, 2010 [Page 1]
Internet-Draft CIDR for IPv6 June 2010
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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Contributing factors to the problem . . . . . . . . . . . . . . 3
3. Aggregation . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Allocation plan . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Current Statistics and Projections . . . . . . . . . . . . . . 6
5.1. Analysis . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.2. Projections . . . . . . . . . . . . . . . . . . . . . . . . 7
5.3. Impact of CIDR . . . . . . . . . . . . . . . . . . . . . . 8
6. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
7. Rules for Route Advertisements . . . . . . . . . . . . . . . . 8
8. Responsibility of configuration and aggregation . . . . . . . . 8
9. Procedural Changes . . . . . . . . . . . . . . . . . . . . . . 9
10. Recommendations . . . . . . . . . . . . . . . . . . . . . . . . 9
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
12.1. Normative References . . . . . . . . . . . . . . . . . . . 9
12.2. Informative References . . . . . . . . . . . . . . . . . . 9
Azinger, et al. Expires December 31, 2010 [Page 2]
Internet-Draft CIDR for IPv6 June 2010
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]. 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.
Azinger, et al. Expires December 31, 2010 [Page 3]
Internet-Draft CIDR for IPv6 June 2010
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]
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].
* 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
Azinger, et al. Expires December 31, 2010 [Page 4]
Internet-Draft CIDR for IPv6 June 2010
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]),
be deployed wherever possible, and that additional protocol
work be done to develop improved technology for renumbering.
End of Excerpt from [RFC4632]
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]
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]
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
Azinger, et al. Expires December 31, 2010 [Page 5]
Internet-Draft CIDR for IPv6 June 2010
allocations that are in turn appropriately sized, such as /48 for
organizations wishing to multi-home.
Start of Excerpt from [RFC4632]
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]. Additional discussion may also be found in [RFC3221].
End of Excerpt from [RFC4632]
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.
+----------------+---------+---------+--------+
| | Jan '09 | Dec '09 | Growth |
+----------------+---------+---------+--------+
| Prefix count | 1,600 | 2,460 | 54% |
| Roots | 1,310 | 1,970 | 50% |
| More Specifics | 290 | 490 | 69% |
| AS Count | 1,220 | 1,830 | 50% |
| Transit | 300 | 390 | 30% |
| Stub | 920 | 1,440 | 56% |
+----------------+---------+---------+--------+
Table 1: IPv6 Routing Table Statistics for 2009 [Huston].
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
Azinger, et al. Expires December 31, 2010 [Page 6]
Internet-Draft CIDR for IPv6 June 2010
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:
Azinger, et al. Expires December 31, 2010 [Page 7]
Internet-Draft CIDR for IPv6 June 2010
+------+---------------+
| Year | Size |
+------+---------------+
| 2009 | 2,460 |
| 2010 | 3,788 |
| 2011 | 5,834 |
| 2012 | 8,985 |
| 2013 | 13,836 |
| 2014 | 21,308 |
| 2015 | 32,814 |
| 2020 | 284,225 |
| 2025 | 2,461,879 |
| 2040 | 1,599,843,323 |
+------+---------------+
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].
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].
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].
Azinger, et al. Expires December 31, 2010 [Page 8]
Internet-Draft CIDR for IPv6 June 2010
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] (and by extension, to the authors of [RFC1519]). 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
[RFC1887] Rekhter, Y. and T. Li, "An
Architecture for IPv6 Unicast
Address Allocation", RFC 1887,
December 1995.
[RFC4632] Fuller, V. and T. Li,
"Classless Inter-domain Routing
(CIDR): The Internet Address
Assignment and Aggregation
Plan", BCP 122, RFC 4632,
August 2006.
12.2. Informative References
[RFC1518] Rekhter, Y. and T. Li, "An
Architecture for IP Address
Allocation with CIDR",
RFC 1518, September 1993.
[RFC1519] Fuller, V., Li, T., Yu, J., and
Azinger, et al. Expires December 31, 2010 [Page 9]
Internet-Draft CIDR for IPv6 June 2010
K. Varadhan, "Classless Inter-
Domain Routing (CIDR): an
Address Assignment and
Aggregation Strategy",
RFC 1519, September 1993.
[RFC2131] Droms, R., "Dynamic Host
Configuration Protocol",
RFC 2131, March 1997.
[RFC3221] Huston, G., "Commentary on
Inter-Domain Routing in the
Internet", RFC 3221,
December 2001.
[RFC4116] Abley, J., Lindqvist, K.,
Davies, E., Black, B., and V.
Gill, "IPv4 Multihoming
Practices and Limitations",
RFC 4116, July 2005.
[I-D.narten-radir-problem-statement] Narten, T., "On the Scalability
of Internet Routing", draft-
narten-radir-problem-statement-
05 (work in progress),
February 2010.
[Huston] Huston, G., "BGP in 2009", <htt
p://www.potaroo.net/
presentations/
2010-03-04-bgp2009.pdf>.
Authors' Addresses
Marla Azinger
Frontier Communications Corporation
Vancouver, WA
USA
EMail: marla.azinger@frontiercorp.com
URI: http://www.frontiercorp.com/
Azinger, et al. Expires December 31, 2010 [Page 10]
Internet-Draft CIDR for IPv6 June 2010
Tony Li
Cisco Systems
170 West Tasman Dr.
San Jose, CA 95134
USA
Phone: +1 408 853 9317
EMail: tony.li@tony.li
Jason Weil
Cox Communications
1400 Lake Hearn Dr.
Atlanta, GA 95134
USA
Phone: +1 404 269 6809
EMail: jason.weil@cox.com
Azinger, et al. Expires December 31, 2010 [Page 11]