Infoblox Community

Only You Can Prevent IPv6 Prefix Disaggregation

 

It is no surprise that the Internet is growing. Recently, the “World Internet Users and 2015 Population Stats” were published for the mid-year 2015. From these statistics, we can see that the Internet now reaches 45% of the world’s population. To some that may sound like a little and to some that may sound like a lot. However, it was around 42% only 6 months ago. Further evidence of Internet growth can be seen on the page of http://bgp.potaroo.net/ that shows the graph of the “Active BGP entries (FIB)” in the Internet (as observed from ASN 65000). This graph makes it difficult to see the late-2000s global economic recession’s impact on the Internet. Cisco’s Visual Networking Index (VNI) predicts that this trend will hasten as more populations come online and we see an explosion of mobile devices and the early stages of the Internet of Everything.

 

IPv4 Routing Table-small.png

 

One of the downsides of this growth is the pressure that Internet routing tables experience from the increased scarcity of available public IPv4 addresses. More route prefix fragmentation will occur now that more Regional Internet Registries (RIRs) have exhausted their supply of public IPv4 addresses. IPv4 prefixes will be further split up and traded among organizations as they continue to grow their IPv4 infrastructures and as they embark on deploying IPv6. We are likely to see exponential growth of the IPv4 routing tables as they fragment even further. This is going to occur at the same time that increased address transfers results in additional fragmentation of the Internet.

 

We are already experiencing difficulties with routers holding the entire IPv4 routing table. Last year, the Internet surpassed 512,000 routes in the global routing table. Some of the Internet’s service-provider routers hit up against the 512K TCAM limit and proceeded to drop routes, which caused a little “hiccup” in routing for many. In the meantime, many routers have been upgraded with additional memory and adjusted their TCAM allotment settings.

 

Hopefully, the recent announcements about IPv4 address shortages have prompted the final enterprise hold-outs to start to obtain their IPv6 addresses and configure their routers to advertise these blocks. We can see from the following graph that, in recent years, there have been many organizations that received allocations of IPv6 addresses from their local RIRs.

 

Rir-ipv6-allocation-rate_svg-small.png

One aspect observable on the above graph is that it is not adjusted for the size of the allocation that is granted by the RIR. It is simply a count of the number of allocations made, regardless of the prefix length of that allocation. The minimum size that a single entity will be granted is a /48, but larger organizations that meet the multi-homing requirements can gain larger IPv6 address allocations. This smallest allocation is equal to the smallest prefix length advertised to the Internet Default Free Zone (DFZ). This /48 prefix length is common knowledge and the current prefix-length filtering practice. It is documented in IETF RFC 6177 titled “IPv6 Address Assignment to End Sites”.

 

Depending on the RIR’s policies, organizations that qualify for a Provider Independent (PI) allocation may be given larger amounts of global IPv6 addresses. Larger organizations are given larger IPv6 prefixes based on the number of “sites”, instead of the minimum /48 provided to a singly-homed small business. If we look at the ARIN Number Resource Policy Manual (NRPM) in Section “6.5.8.2. Initial assignment size” states how large of an IPv6 prefix an organization requesting a direct assignment from ARIN might receive based on the number of sites they have.

 

There is a serious problem that can arise with these larger IPv6 prefix allocations to companies. If the companies receiving larger IPv6 prefixes started to fully break up these prefixes into numerous smaller prefixes and advertise them to their upstream ISPs, this could cause the IPv6 Internet Default Free Zone (DFZ) to grow dramatically. This practice is called disaggregation (sometimes also referred to as de-aggregation) which is the opposite of route aggregation (also known as supernetting in the IPv4 case).

 

The RIRs discourage excessive disaggregation by organizations to whom they allocate IPv6 addresses. However, the RIRs lack any method to enforce these policies, so they can only merely discourage this practice. There is technically nothing stopping an organization from receiving a /40 allocation and then turning around and advertising 256 different unique /48s to their ISP with BGP. Furthermore, if an organization was granted a /36, they could potentially advertise 4096 different /48s into the Internet. These are two examples of bad practices that would definitely be considered egregious misuse of the Internet and would warrant filtering by ISPs. This topic has been covered in the IETF draft titled “On the Scalability of Internet Routing”.

 

Internet Protocol (IP) routing uses a most-specific routing policy where the packet’s destination address is matched against the prefixes in the forwarding table of a router. The route prefix that most closely matches the destination address is the route that is used to forward the packet. This method is known as the “longest prefix match”. This method can be used for legitimate purposes by an organization that selectively advertised more-specific routes in addition to less-specific routes. The more specific route advertisements override the less-specific routes. An organization may want to do this for the purposes of traffic engineering or some other specific traffic routing policy. Selective disaggregation of a few more-specific routes can be tolerated and may be necessary for some network architectures.

 

The size of the current IPv6 Internet routing table is not nearly as large as the IPv4 Internet routing table. Due to greater efficiency of allocations and the fact that IPv6 is early in its lifecycle, there is very little impactful fragmentation. The size of the current IPv6 routing table continues to grow as IPv6 deployments continue. Hurricane Electric’s Global IPv6 Deployment Progress Report site offers many statistics including one that demonstrates that there are now over 10,000 ASNs advertising IPv6 prefixes and over 20,000 IPv6 routes. The following graph shows how these IPv6 prefix and IPv6-enabled ASN quantities have tracked in recent years.

 

Gnuplot-small.png

 

We do not want to cause the IPv6 Internet routing table to grow out of control and end up like the IPv4 Internet routing table. However, we should remind ourselves that all Internet routers need to facilitate reachability to “the whole Internet”. That means that routers need to hold both the IPv4 and the IPv6 Internet routing tables.

 

A reasonable estimate might be that in five years the IPv4 table grows to 1,000,000 routes and the IPv6 table (with lots of disaggregation) grows to 300,000 routes. Therefore, all routers that currently handle 600,000 routes will need to have double the capacity to hold 1.3 million routes in five years.   Note: I am disregarding situations where routers have multiple peers and, therefore, need to hold full Internet routes from multiple peers.

 

There is peer pressure to prevent an organization from performing disaggregation. ISPs may filter more specific routes if they know or believe an organization is behaving badly. There have been proposals to the RIRs to have policy that forbids the practice of disaggregation. Currently, most RIRs only have policy statements discouraging the practice (see ARIN’s NRPM Section 6.3.4. on Aggregation).

 

We can see which ASNs are performing greater amounts of disaggregation in the IPv4 CIDR Report and the IPv6 CIDR Report. This page lists those ASNs that could improve/reduce the IPv4 DFZ Internet routing table size by doing a better job of aggregation. This page lists those ASNs that are disaggregating IPv6 prefixes. This might be one way of publicly shaming those who are contributing to a larger-than-necessary Internet routing table size.

 

There is also the possibility that RIRs have selected specific ranges of IPv6 addresses solely for the purpose of allocating single /48s to organizations. Therefore, service providers would know about this block’s purpose and be cognizant that no disaggregation was taking place in this range. Service providers would only receive /48 prefix-length routes from customers using addresses from this range.

 

The other force of nature that will have an effect on this trend is how routers will possess increased capacity over time. One of the fundamental “laws of networking” is Moore’s Law which predicts the effective doubling of CPU capability every two years. Organizations that purchase routers would prefer those devices have a five-year or longer lifespan. If the Internet routing tables continue to grow rapidly, then all Internet-connected companies would need to be prepared to upgrade their routers on a shorter three-year purchase cycle to keep up with the speed of table-size growth. Even if the routers had exponentially more capabilities every few years, they would need to be replaced more frequently to keep pace.

 

As Uncle Ben from the Spiderman comic (all rights reserved by Marvel Entertainment/The Walt Disney Company) wisely uttered, “With great power comes great responsibility”. We all must be cognizant of the potential problems that result from excessive IPv6 address disaggregation and each of us should do our part to ensure this practice is discouraged and is not performed. If your organization is planning on using some selective disaggregation for traffic routing purposes, then you should document your plans and share that design with your upstream ISPs so they do not filter those more-specific route advertisements. Don’t be that guy who excessively or completely disaggregates your IPv6 prefix and makes the Internet cry.

 

Smokey2.jpg

 

 

 

 

 

 

Infoblox Blogs
The company blog focuses on company updates, product announcements, and related topics covered by many of our...
The Infoblox Support Central Blog highlights recent Knowledge Base (KB) Articles meant to help customers answer...
Check out the Infoblox Security Blog to learn about various challenges our customers share with us, what Infoblox is...
IPv6 adoption can be intimidating. Even people with years of networking experience may break into a sweat thinking...
The Infoblox Community Blog highlights new features, functionality and information related to events, products and...