On Higher Levels of Address Aggregation

The Internet depends upon the efficiency and scalability of the routing system. Without effective routing, no traffic can be delivered. Ensuring that routing scales is key to the Internet architecture. History has shown that the architectural changes made as part of and have been extremely effective. However further improvements are possible. While prefix aggregation at the ISP level has helped provide good routing efficiency, more aggregation is possible. This document discusses how aggregation could be performed above the provider level, forming aggregates at the regional or continental level based on the address allocations that have already been performed. This document also suggests ways that ICANN and the RIRs can change address allocation procedures to enable better future regional and continental aggregation. These changes would have no perceptible effect on ISP or end-site address allocations, and would simply cause the allocations to come from different address blocks from the same RIR. IPv4 and IPv6 addresses and prefixes are used throughout this document as examples. The concepts presented here apply equally to both address spaces.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

The routing subsystem of the Internet is responsible for discovering paths from any point on the Internet to any other point. The results of the routing system are paths instantiated in the forwarding plane of routers throughout the network, resulting in end-to-end connectivity. For routing to function, there must be specific names for hosts. The architecture of the namespace for these names is a critical decision, as these names will have global scope. When we also use these names as a binding to a location in the network, we call these names 'addresses' and the namespace that they are taken from an 'address space'. Scalability is a central concern for routing. Each item of information that routing must propagate around the network requires processing power and memory for storage throughout the network. This scales with the size of the network. If routing also scaled linearly with the number of hosts, then the cost of running the routing system would grow as the size of the network times the number of hosts, which is clearly problematic. For this reason, we cannot have a routing subsystem that just carries individual host routes.

Instead, we seek to define groups of hosts and treat them together as a single abstraction, commonly known as a 'prefix'. We call the process of combining addresses together into a prefix 'aggregation'. Under some circumstances, prefixes themselves may also be aggregated to form another prefix, resulting in a recursive structure. If prefix A is a proper subset of prefix B, we say that A is 'more specific' than B and that B is 'less specific' than A. We can then define the routing efficiency of a specific prefix as the cost of carrying that prefix, plus all of its more specifics, integrated across the entire network, and divided by the number of host addresses subsumed by the prefix. It is well known that abstraction obscures important detail and that abstraction in routing can cause sub-optimal paths, resulting in extra hops, wasted bandwidth, and managerial difficulties. As a result, there will always be a trade-off between scalability and optimality when introducing abstractions. When optimality is paramount and simple reachability is insufficient, the routing subsystem has additional mechanisms that allow network operators to make different path selection choices, sometimes intentionally ignoring or explicitly working against abstraction. We call this broad set of mechanisms 'traffic engineering'.

Abstractions have three different boundaries that we will be concerned with: An abstraction's administrative boundary occurs at the topological interface between the abstraction's administratively controlled network and other administrations. An abstraction's naming boundary is the topological container of all of the host addresses within that abstraction. An abstraction's action boundary is the topological container where the abstraction has an effect on routing's path computation. In simple cases of abstraction, these boundaries are aligned. For example, consider a university that has been assigned the prefix 128.125/16. It has a pair of routers that interface to its two ISP's and it advertises that prefix to both of it's ISPs and no more specifics. The entire university's infrastructe utilizes this one prefix. In this case, the administrative, naming, and action boundary all occur between the university's router's and the ISPs'. As a more interesting example, consider an ISP X that has been assigned the prefix 2001:1234::/32. For its own internal purposes, the ISP chooses to partition this prefix and assigns 2001:1234:5600::/40 to city C, which is an IGP area in the ISP's network. For traffic engineering purposes, ISP X also advertises more specifics of the city C prefix to ISP Y, but not to ISP Z. The more specifics are constrained so that ISP Y cannot propagate them to its neighbors (e.g., using the BGP NO_EXPORT community).

The administrative boundary for the city C prefix is now ISP X's entire network. The naming boundary is city C itself, but the action boundary includes ISP X and Y, but not ISP Z. Placing the abstraction action boundary at an acceptable location is key. If the action boundary is not located correctly, then it may allow prefixes to propagate too far, unnecessarily damaging routing efficiency, or it may not allow prefixes to propagate far enough, causing traffic to take suboptimal paths.

In the above figure, suppose that prefix A is advertised by router R1 and prefix B is advertised by R4. If aggregation is performed at router R6, then that is inefficient. Router R3 is the next hop for both prefix A and B, so if R3 had aggregated A and B, R6 would have less state to carry. Conversely, if aggregation happened at routers R2 and R5, then R3 would likely make a suboptimal forwarding decision, possibly sending traffic for prefix B via R2 instead of the optimal R5. From this, we can see that the perfect location for the action boundary is the first point where all paths would merge. For pragmatic reasons, it's easier to put action boundaries at administrative boundaries. Thus, the optimal action boundary would be the network boundary after the path merge point.

Abstraction can be used to help aggregate routing information above the ISP level, as well as below. While this is currently not commonly done, it should be considered as a means of further reducing the size of the global routing table and improving routing efficiency. Address allocation today is performed at the behest of the Internet Assigned Numbers Authority (IANA), currently delegated to five Regional Internet Registries (RIRs): AFRINIC, APNIC, ARIN, LACNIC, RIPE NCC. Those registries are assigned large blocks of address space that they in turn assign to ISPs and other networks. We can take advantage of the topological connectivity within a region and consider aggregation across ISPs. Current address allocation policies have given each RIR a number of address blocks. While aggregation of these blocks is not a requirement, they are a convenient starting point. Any ISP can look at their routing table and determine whether or not they are within the optimal abstraction boundary of such a prefix. If not, then that prefix is good candidate for aggregation by the ISP. While the ISP could aggregate the prefix on routers where it would be advertised to other ASes, it might be more beneficial if the ISP performed the aggregation on the routers where the more specifics enter the network. This saves the ISP from carrying the more specific prefixes internally, which is an economic incentive to aggregate. There are several important considerations when contemplating this. Since more specifics are not carried internally, traffic for the prefix will find the closest exit point. This is sometimes known as 'hot potato routing'. This may or may not be compatible with the ISP's routing policy. Aggregation may also cause global traffic patterns for the prefix to change. Since more specific prefixes are preferred, if an ISP starts advertising an aggregate to its neighbors and those neighbors are still receiving more specifics from other sources, the traffic for the prefix may be diverted away from the ISP through the more specifics. This may also be in conflict with the ISP's routing policy. If not, then it may actually be beneficial to the ISP as they are still offering transit for that prefix, but not actually carrying any traffic for it. This is another economic incentive to aggregate. ISPs that wish to perform this aggregation are able to do so unilaterally. No coordination with other entities is required, although prior discussion beforhand might avoid operational issues. A common traffic engineering practice today is to advertise more specifics of a prefix today at different entry points with different path attributes in an attempt to influence inbound traffic patterns. This has proven very effective and become very common. This is very harmful to overall routing efficiency because the more specifics propagate very widely, far beyond their point of actual impact. Regional aggregation could help to recapture much of this inefficiency.

Continental aggregation was previously discussed in . Today, some RIRs are closely aligned with a continent, so continental and regional aggregation are aligned. However, for RIRs that serve more than one continent, there is a natural opportunity for additional aggregation. Continental boundaries are commonly aligned with a few very expensive links. In graph theoretic terms, these links form a natural cut-set, making a continent a possible valuable abstraction. Since routing across the cut-set is likely to be expensive, providers will want to optimize it, however, it is also likely that the optimal abstraction action boundary for a continental abstraction is just beyond the links in the cut-set. To maximize the ability to create continental abstractions, RIRs that serve more than one continent should consider allocating blocks by continent and delegating from within those blocks to entities within those continents.

The current IPv6 Global Unicast Address Assignments are found in . While some hierarchical allocation is being practiced, there have been numerous blocks allocated that are not aggregatable. This document recommends that ICANN review their policy on global address allocation and consider reserving shorter prefixes for RIRs, such as /4's or /8's, and then making further allocations to the RIRs from these shorter prefixes. This would, in the distant future, enable more opportunities for regional aggregation.

This document recommends that RIRs optimize their address allocation policies to maximize the opportunities for regional and continental aggregation. RIRs that serve more than one continent should consider allocating address blocks per continent and delegating from those blocks to providers on that continent. Allocations to multi-regional providers should be done from separate blocks than regional providers. This will maximize the opportunity to aggregate regional providers.

This document encourages ISPs to aggregate more, both to help the overall routing efficiency of the overall Internet also to help contain local costs, as well as churn from oscillating more specific prefixes and accidental deaggregation.

The author would like to take this opportunity to thank IANA for years of selfless service. This document makes no further requests of IANA.

This document creates no new security issues.

The author would like to acknowledge the contributions of J. Noel Chiappa to routing architecture in general and for his specific insights in defining the abstraction naming boundary and the abstraction action boundary.