Impact of IPv4 Transfers on Routing Table Fragmentation

Over the past two decades, the IPv4 BGP routing table has steadily grown in size. The collective of the Routing Information Service (RIS) route collectors observed an increase from around 90,000 entries in October 2000 to 630,000 entries in October 2016. For most of these years the two contributing factors were announcements of new address blocks which had been allocated or assigned by the Regional Internet Registries (RIRs) and deaggregatation of existing address blocks - more specific prefixes being announced in addition to or instead of the prefixes allocated by the RIRs. With the adoption of transfer policies in the APNIC, ARIN and RIPE NCC service regions, a third driver for routing table growth was added: when only part of an existing allocation or assignment is transferred, the minimum number of entries to describe reachability of the address space in the routing system increases. In this article, we investigate the impact four years of registered IPv4 transfers in the RIPE NCC service region have had on the routing table.

Figure 1: Growth of the BGP table as seen by RIS

The exact impact transfers have on the routing system is not predictable. While it is clear that the number of entries at maximum aggregation goes up, the routing table already features a lot of deaggregation. Thus, it all depends on how the new holder of the transferred block announces the address space compared to the original holder. If the original holder had no routes in BGP and the new holder announces the acquired space, the number of routes in BGP increases. But if the original holder already announced a more specific equal to the transferred block and the new holder does not deaggregate further, the transfer will have no impact on the routing system. And if the new holder deaggregates less than the original holder, the number of entries in BGP will even decrease after a transfer has been completed.

To investigate the impact of transfers in the RIPE NCC service region, we started from the list of registered transfers. For each transfer, we identified the covering (allocated or assigned) address block as it existed in the RIPE Registry on 15 September 2012, when the available pool first fell to the level of one /8 and the first transfer had yet to be made. Excluding 185/8, which is still being allocated from, we find 1,666 unique IPv4 ranges from which 4,922 transfers were made between 1 October 2012 and 1 October 2016. Next, we determined how many prefixes this address space was covered by in the RIPE Registry and in the BGP routing table at weekly intervals over the last four years. Subtracting the initial values from the weekly results provided us with the changes over time, shown in Figure 2. This focus on change rather than absolute values allows for a better comparison of growth in the routing table and the amount of address space allocated or assigned (also referred to as delegated) in the RIPE NCC service region.

Figure 2: Changes in fragmentation in BGP and  the RIPE registry from IPv4 blocks used in transfers

When it comes to fragmentation in the RIPE Registry, the graph shows a rapid increase (the red dots) between August 2014 and August 2015. More than 2,000 additional records were created during this time period. Inspecting the underlying data, we find that the main contribution to this surge comes from just five large allocations (between /15 and /12) which were split and transferred to other parties in small chunks (/21 to /24). Outside this period the growth in address space fragmentation is less rapid but is still present. This reflects a steady rate in transfers smaller than the IP blocks they originate from. It is also worth noting that in August 2014 policy proposal 2014-01, "Abandoning the Minimum Allocation Size for IPv4" was implemented, after it reached consensus in July 2014. That opened the possibility to transfer blocks of size /23 and smaller and thus increased the potential for fragmentation in the address registry.

Turning to BGP, we see a lot more variation in the changes over time for address space involved in transfers. The number of prefixes first goes up, becomes more or less stable for half a year, and decreases in the next 18 months. Then, following a sharp rebound in January 2015 (without a corresponding increase in address space fragmentation, which suggests large-scale deaggregation) the number of prefixes grows steadily over a long period. A possible explanation is that some parties who were about to offer resources on the transfer market were first recovering address blocks from existing customers. When contracts expired or were cancelled, the corresponding routes in BGP may have been withdrawn, only to come back once the transfers were completed. The evolution of the total number of unique IP addresses announced in BGP from the address blocks used in transfers supports this theory. Figure 3 shows a decrease of about two million addresses in the last four months of 2013. This shows that the drop in announced prefixes was really due to addresses being withdrawn from BGP and not due to the withdrawal of more specific routes from an announced covering aggregate.

Overall, the graph suggests a light correlation between address space fragmentation and BGP table growth from 2015 onward. By October 2016, transfers had created about 5,000 additional entries in the RIPE Registry and the address space was covered by 6,000 additional entries in BGP. At the same time, after four years of transfers, the total amount of addresses announced from the address blocks involved is back roughly to the level it was before transfers started: about 90% of this IPv4 space is now announced in BGP.

Figure 3. Evolution of number of announced addresses in BGP from IPv4 blocks used in transfers

Evolution of non-transferred IPv4 space

Above we showed how, after four years of transfers, the address space involved is covered by about 6,000 additional prefixes in the BGP tables collected by RIS. While part of this will be a direct result of fragmentation in the address registry, there is also the general tendency of ISPs to deaggregate their allocations and announce more-specific prefixes in the routing table, for instance, to accommodate multi-homing. To get an idea to what extent deaggregation contributes to routing table growth, we look at the RIPE NCC-delegated IPv4 blocks not involved in transfers.

In the RIPE NCC service region, registered transfers only started in October 2012, after the RIPE NCC reached its last /8 of IPv4 address space. On 15 September 2012, all address space, except for 185/8 and some reserved pools for special needs (a /13 for temporary assignments, a /16 for IXP assignments and a /16 for unforeseen circumstances), was held by LIRs and End Users. Looking back at how this address space was announced over the past four years gives us a good opportunity to assess how the default free BGP table evolves when an RIR no longer adds new allocations. For all IPv4 blocks allocated or assigned by the RIPE NCC by 15 September 2012, just three options for change were left:

• Address blocks are fully or partially transferred to another LIR
• Address blocks move to another LIR following a merger or acquisition
• Address blocks are returned to the RIPE NCC or deregistered

The impact of transfers was already discussed. In mergers and acquisitions, the holder of the address space changes as well. However, unlike transfers, mergers and acquisitions typically see address blocks moving as a whole; they do not fragment the address registry, thus do not change the maximum possible level of aggregation in BGP. The last option for change is the deregistration of IPv4 resources. This has the potential to reduce the number of routing table entries, but that potential is only realised when the address space was announced before; otherwise there is no impact. Figure 4 below shows how the (fixed) IPv4 space held by LIRs and End Users on 15 September 2012 (and from which no transfers have been made) evolved in the last four years in BGP and in the RIPE Registry.

Figure 4. Changes in fragmentation in BGP and the RIPE Registry from IPv4 blocks NOT used in transfers

Interestingly, the address registry and the routing table show opposing trends. While the RIPE NCC reclaimed and deregistered about 5,000 prefixes, covering some 4.7 million IP addresses, the address space delegated by October 2012 and not used in transfers is now covered by 25,000 additional prefixes in BGP. Comparing this steady growth to the evolution of the total amount of IPv4 space announced from these address blocks (Figure 5 below), indicates deaggregation is the dominant cause; an increasing number of more specifics are announced from prefixes that existed in BGP before. After an initial surge in the first six months, likely from allocations received shortly before the RIPE NCC reached its last /8, the number of addresses (from non-transferred blocks) was roughly stable for more than two years at around 534 million. At the same time the number of prefixes went up by 15%, from 100,00 to 115,000.

Figure 5. Evolution of number of announced addresses in BGP from IPv4 blocks not used in transfers

Conclusion

Over the past four years there has not been a strong correlation between fragmentation in the RIPE Registry due to transfers and an increase of the number of entries in the default free BGP table. The primary reason for the absence of a clear correlation is that some large allocations had already been deaggregated heavily in BGP before transfers surged in the RIPE NCC service region. Only in the last year have we seen some correlation between the rise in address space fragmentation and number of entries in BGP. However, at the same time we have also seen a steady increase in BGP entries covering address space that is not involved in transfers. This indicates that, as far as the RIPE NCC service region is concerned, general deaggregation trends still outweigh routing table growth from IPv4 allocations being transferred in parts.