Another good question from Mark Seery:
It is also often stated that better route aggregation could provide extended life for the IPv4 address space as well. This is often observed to be a) related to operational practices and b) impacts of dual homing. Could you comment on whether an address space crunch would in your opinion provide sufficient incentive to improve route aggregation practices, or do you see the problem as being beyond that at this point?
The short answer to IPv4 address aggregation as a possible retardant to the depletion rate is, “been there, done that, didn’t work.” Here’s why:
In the last post I discussed one of the goals of CIDR, which was to conserve IPv4 addresses through more efficient allocation. CIDR fulfilled that goal admirably. The other goal of CIDR was to slow the “routing table explosion” observed in the early 1990s—the rapid increase in the number of entries showing up in the BGP routing tables of the Internet. Considering that at the time CIDR was implemented there were around 9,000 entries in the BGP tables and there are now well over 200,000, CIDR was much less successful in meeting its second objective than it was in meeting its first.
The idea was that if you want to connect to the Internet, you get your IPv4 addresses from your ISP; the addresses your ISP give you are a part of its own assigned block of addresses, which it was assigned out of the block of addresses of its own upstream provider, and so on, up to a Tier 1 provider that was allocated its block from the Regional Internet Registry (RIR). When that Tier 1 provider advertises its prefix into the BGP tables, the prefix represents all of its connected users and their connected users—an aggregate address.
The intended benefits are smaller tables, conserving resources at the core of the Internet, and more importantly, hiding the instabilities that regularly occur at the edges. If the connection to some end user with a /24 block of addresses is flapping, but the user’s block is a part of a /19 aggregate advertised by an upstream provider, those flaps are never seen at the higher reaches of the Internet; BGP in the core does not have to process them, making the entire Internet more stable.
That was the intention, and there were efforts for a while to enforce this aggregation policy. Some Tier 1 carriers, for example, would not accept prefixes longer than /19. The effort failed primarily because of multihoming, as Mark touches upon.
Even a short explanation of the problem is a little long-winded, but here goes:
Suppose you are an end-user connected (for redundancy or other reasons) to two ISPs, and your prefix is a /24 assigned to you out of ISP1’s /19 CIDR block. All packets routed to your network match ISP1’s aggregate address and are routed to you through ISP1; nothing comes in from ISP2 except packets sourced from its own customers. So to correct this problem, ISP2 advertises your /24 in addition to its own aggregate. But that isn’t good either, because now longest-match routing means all packets coming to you from beyond ISP1 and ISP2 match the longer /24 advertised by ISP2, and all incoming packets traverse that ISP.
In order for incoming packets to your network to be routed over the best path through either ISP1 or ISP2, both ISPs must advertise your /24 prefix. So ISP1 “punches a hole” in its CIDR block to advertise your more-specific /24.
The problem is similar if you acquire a provider independent (PI) block directly from the RIR (and they all have policies that allow assignment of long prefixes to multihomed users): All of your ISPs must advertise your PI block, which is usually going to be a /23 or longer.
A look at the current BGP table statistics shows you how badly multihoming has defeated the intentions of route aggregation: Only 16% of the prefixes in the current Internet routing table are /19 or smaller; a whopping 53% of the prefixes are /24s.
Unfortunately, IPv6 has no ready solutions to the problem either. A long list of IPv6 multihoming solutions have been proposed over the years, but all so far appear to create more problems than they solve. Almost all involve one or both of the following approaches:
(1) Support multiple IPv6 addresses on every publicly reachable interface on your network, one address from each of your ISPs. This would create serious challenges for DNS: If DNS returns multiple addresses in response to a query, which address should be preferred? Do the multiple addresses need to be tested for validity? Although the addresses belong to the same destination, they are reachable through different ISPs; how is the address with the best route from the source determined? And how does the host with multiple addresses decide which to use as its source address?
(2) Use an application at the edge of the network at each ISP connection that rewrites the prefix of the source address in outgoing packets to match the prefix of the attached ISP. This also creates some curious challenges for DNS, in addition to NAT-like problems that are associated with changing packet addresses.
There is still some hope that a practical multihoming solution will be found for IPv6, but in the meantime the IPv6 multihoming practices are no different from the IPv4 practices. And considering that the reason for needing IPv6 is to support billions upon billions of new IP devices and services, we have to wonder what the impact on the Internet routing tables will be. Will the core router vendors be able to continually keep up with the growing BGP table?
One final note: There is one area in which the transition to IPv6 might help get the Internet routing table under control, and that is to assign IPv6 addresses in a geographic hierarchy. We already do this with telephone numbers, breaking them into country codes, area codes, and exchange codes. If we assign IPv6 prefixes similarly, aggregation might yet save our bacon.
