![\"\"](\"https:\/\/live-infoblox-blog.pantheonsite.io\/wp-content\/uploads\/prefix-disaggregation.jpg\")
<\/p>\n<\/p>\n
It is no surprise that the Internet is growing. Recently, the \u201cWorld Internet Users and 2015 Population Stats<\/u><\/a>\u201d were published for the mid-year 2015. From these statistics, we can see that the Internet now reaches 45% of the world\u2019s 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\u00a0http:\/\/bgp.potaroo.net\/<\/u><\/a>\u00a0that shows the graph of the \u201cActive BGP entries (FIB)<\/u><\/a>\u201d in the Internet (as observed from ASN 65000). This graph makes it difficult to see the\u00a0late-2000s global economic recession\u2019s<\/u><\/a>\u00a0impact on the Internet.\u00a0Cisco\u2019s Visual Networking Index (VNI)<\/u><\/a>\u00a0predicts that this trend will hasten as more populations come online and we see an explosion of mobile devices and the early stages of the\u00a0Internet of Everything<\/u><\/a>.<\/p>\n 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\u00a0(RIRs) have exhausted their supply of public IPv4 address<\/u><\/a>es<\/u>. 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\u00a0even further<\/u><\/a>. This is going to occur at the same time that\u00a0increased address transfers<\/u><\/a>\u00a0results in additional fragmentation of the Internet.<\/p>\n We are already experiencing difficulties with routers holding the entire IPv4 routing table. Last year, the Internet surpassed\u00a0512,000 routes in the global routing table<\/u><\/a>. Some of the Internet\u2019s service-provider routers hit up against the 512K TCAM limit and proceeded to drop routes, which caused a little \u201chiccup<\/u><\/a>\u201d in routing for many. In the meantime, many routers have been upgraded with additional memory and adjusted their TCAM allotment settings.<\/p>\n Hopefully, the recent announcements about\u00a0IPv4 address shortage<\/u><\/a>s<\/u>\u00a0have prompted the final enterprise hold-outs to start to obtain their IPv6 addresses and configure their routers to advertise these blocks. We can see\u00a0from the following graph<\/u><\/a>\u00a0that, in recent years, there have been many organizations that received allocations of IPv6 addresses from their local RIRs.<\/p>\n 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\u00a0Default Free Zone<\/u><\/a>\u00a0(DFZ). This \/48 prefix length is common knowledge and the current prefix-length filtering practice. It is documented in IETF\u00a0RFC 6177<\/u><\/a>\u00a0titled \u201cIPv6 Address Assignment to End Sites\u201d.<\/p>\n Depending on the RIR\u2019s 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 \u201csites\u201d, instead of the minimum \/48 provided to a singly-homed small business. If we look at the\u00a0ARIN Number Resource Policy Manual<\/u><\/a>\u00a0(NRPM) in Section \u201c6.5.8.2. Initial assignment size<\/u><\/a>\u201d 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.<\/p>\n 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\u00a0Default Free Zone<\/u><\/a>\u00a0(DFZ) to grow dramatically. This practice is called disaggregation (sometimes also referred to as de-aggregation) which is the opposite of\u00a0route aggregation<\/u><\/a>\u00a0(also known as\u00a0supernetting<\/u><\/a>\u00a0in the IPv4 case).<\/p>\n 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 \u201cOn the Scalability of Internet Routing<\/u><\/a>\u201d.<\/p>\n Internet Protocol (IP) routing uses a most-specific routing policy where the packet\u2019s 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 \u201clongest prefix match<\/u><\/a>\u201d. 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.<\/p>\n 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\u2019s\u00a0Global IPv6 Deployment Progress Report site<\/u><\/a>\u00a0offers many statistics including one that demonstrates that there are now over 10,000 ASNs advertising IPv6 prefixes and over 20,000 IPv6 routes. The\u00a0following graph shows<\/u><\/a>\u00a0how these IPv6 prefix and IPv6-enabled ASN quantities have tracked in recent years.<\/p>\n 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 \u201cthe whole Internet<\/u><\/a>\u201d. That means that routers need to hold both the IPv4 and the IPv6 Internet routing tables.<\/p>\n 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.\u00a0\u00a0 Note: I am disregarding situations where routers have multiple peers and, therefore, need to hold full Internet routes from multiple peers.<\/p>\n 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\u2019s\u00a0NRPM Section 6.3.4. on Aggregation<\/u><\/a>).<\/p>\n We can see which ASNs are performing greater amounts of disaggregation in the\u00a0IPv4 CIDR Report<\/u><\/a>\u00a0and the\u00a0IPv6 CIDR Report<\/u><\/a>. This\u00a0page lists those ASNs<\/u><\/a>\u00a0that could improve\/reduce the IPv4 DFZ Internet routing table size by doing a better job of aggregation. This\u00a0page lists those ASNs<\/u><\/a>\u00a0that 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.<\/p>\n 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\u2019s 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.<\/p>\n 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 \u201claws of networking<\/u><\/a>\u201d is\u00a0Moore\u2019s Law<\/u><\/a>\u00a0which 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.<\/p>\n As Uncle Ben from the Spiderman comic (all rights reserved by\u00a0Marvel Entertainment<\/u><\/a>\/The Walt Disney Company<\/u><\/a>) wisely uttered, \u201cWith great power comes great responsibility<\/u><\/a>\u201d. 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.\u00a0Don\u2019t be that guy<\/u><\/a>\u00a0who excessively or completely disaggregates your IPv6 prefix and makes the Internet cry.<\/p>\n It is no surprise that the Internet is growing. Recently, the \u201cWorld Internet Users and 2015 Population Stats\u201d were published for the mid-year 2015. From these statistics, we can see that the Internet now reaches 45% of the world\u2019s population. To some that may sound like a little and to some that may sound like […]<\/p>\n","protected":false},"author":321,"featured_media":2330,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"_genesis_hide_title":false,"_genesis_hide_breadcrumbs":false,"_genesis_hide_singular_image":false,"_genesis_hide_footer_widgets":false,"_genesis_custom_body_class":"","_genesis_custom_post_class":"","_genesis_layout":"","footnotes":""},"categories":[17],"tags":[56,38,31],"class_list":{"0":"post-2327","1":"post","2":"type-post","3":"status-publish","4":"format-standard","5":"has-post-thumbnail","7":"category-ipv6-coe","8":"tag-ipv4","9":"tag-ipv6","10":"tag-networking","11":"entry"},"acf":[],"yoast_head":"\n![\"\"](\"https:\/\/live-infoblox-blog.pantheonsite.io\/wp-content\/uploads\/IPv4-Routing-Table-small.png\")
<\/p>\n![\"\"](\"https:\/\/live-infoblox-blog.pantheonsite.io\/wp-content\/uploads\/Rir-ipv6-allocation-rate_svg-small.png\")
<\/p>\n![\"\"](\"https:\/\/live-infoblox-blog.pantheonsite.io\/wp-content\/uploads\/Gnuplot-small.png\")
<\/p>\n![\"\"](\"https:\/\/live-infoblox-blog.pantheonsite.io\/wp-content\/uploads\/Smokey2.jpg\")
<\/p>\n","protected":false},"excerpt":{"rendered":"