Predicting the IPv6 BGP Table Size

One of my readers sent me an interesting question:

Are you aware of any studies looking at the effectiveness of IPv6 address allocation policies? I'm specifically interested in the affects of allocation policy on RIB/FIB sizes.

Well, we haven’t solved a single BGP-inflating problem with IPv6, so expect the IPv6 BGP table to be similar to IPv4 BGP table once IPv6 is widely deployed.

There are three main reasons the global Internet table contains over 450K entries:

  • Ignorance and sloppiness. The CIDR report claims we could aggregate exiting 450K entries into just over 250K entries … but why would the top offenders do that if it costs them nothing to advertise their prefixes (and who cares that everyone else is paying stupidity tax by buying more high-speed RAM).
  • Multihoming. Session-level multihoming was never implemented in the TCP stack (LISP or MP-TCP could help assuming they ever get deployed).
  • Traffic engineering. If you’re multihomed and want to control the use of your uplinks for inbound traffic, you have to advertise smaller chunks of your address space to individual ISPs.

IPv6 doesn’t change a thing (widespread deployment of LISP might), so even if all the prefix hogs start advertising optimized IPv6 prefixes, the absolute minimum we need to describe the current Internet topology (and routing policies expressed by its participants) is around 250K routes.

Things might actually get worse – we might see more prefixes in the IPv6 table because a lot of organizations that used PA (example: a /24 allocated by their ISP) and NAT44 today might consider PI address space to avoid the royal pain of renumbering.

Finally, there’s the noble and worthy push toward NAT-less IPv6 world. That sounds great, until you realize small organizations that use NAT-based IPv4 multihoming today might opt for provider independent IPv6 prefix (which costs around 50 EUR a year in RIPEland) … or use NPT66.

Does the IPv6 BGP table explosion matter? You might believe in the universal safety of Moore’s law, but let me point out that Cisco 7600 with RSP 720-3CXL that you bought yesterday (and won’t be able to depreciate for the next 4-5 years) supports up to 1M IPv4 routes or 512K IPv6 routes (or a mix of both) … and we’re pretty close to that limit already assuming IPv6 prefixes would match maximally-aggregated IPv4 prefix.

ASR 1000 with maximum memory fares a bit better (1M IPv4 routes or 1M IPv6 routes), and MX-80 seems to be in the same range (although I couldn’t find the exact figures anywhere in the data sheets). It might be time to leave the default-free zone if you’re not a Tier-1/2 ISP (or maybe one of the vendors will actually implement virtual aggregation).

More IPv6 Goodies

Recent posts in the same categories

7 comments:

  1. Anonymous 05 March 2013 15:10
    There's a fourth major reason people announce multiple prefixes, which is piecemeal allocations by the RIR's, something which is largely not an issue with v6. At $JOB[-1] we had ~20 v4 blocks (after aggregating blocks initially allocated as separate /24's that happened to be sequential) vs 1 v6.
  2. Jan Zorz 06 March 2013 12:28
    Pretty much disagree. IPv6 BGP table will be much smaller, as the initial allocation sizes are much bigger and also big operators now uses one or two routing slots in the IPv6 table and hundreds of them in IPv4 routing table.

    Of course there are sub-smart people aout there, I saw one even deaggregating /48 PI space to small /56 junks and pushing that to a global IPv6 routing table (there was one last week) and also lot's of other junk is floating around (I can show you the output from my core router, you would be amazed what junk is in the IPv6 table) - but in general, I don't expect the v6 table to explode. Today there are approx. 43.000 ASNs, and the v6 table should not hit 100k anytime soon - provided that we deal with the idiots that de-aggregate :)
    Replies
    1. Ivan Pepelnjak 06 March 2013 15:00
      Let's revisit our data points in 5 years, shall we ;)
    2. Jan Zorz 07 March 2013 12:02
      Some people think that "routing police" would be much needed... soon... :)
    3. Ivan Pepelnjak 07 March 2013 15:10
      Reckless driving on the Internet: http://www.renesys.com/blog/2009/02/the-flap-heard-around-the-worl.shtml
  3. Anonymous 11 March 2013 08:55
    Unless you've done testing and have shown otherwise, I think your routing entry sizes for the ASR are a little low. Depending on the RP and memory configuration, I've seen numbers between 1 million to 29 million for IPv4 (configured as a route reflector with BGP selective download) and 1 million to 7 million for IPv6. To your larger point though, I'm not sure it's a big deal in any case. The number of routes in the global BGP table hasn't changed by an order of magnitude in a long while. When it does change, the hardware guys will just increase the size of TCAM by a few factors.
  4. Pascal 20 March 2013 18:24
    There are other considerations too:
    * what routes will an ISP advertise to its peers? An ISP might carry many ipv4 routes but can summarize the routes allocated to him to its ISP peers. If a large company has PI addresses, many branches, and use multiple ISPs, then there could be many /48 (one per branch) advertised to the ISP peers, unless the branches connect via vpn to the main site. The ISP will not be able to summarize the routes to its peers unless the PIs addresses are allocated carefully (isp based?).

    * most ISPs will accept and advertise to their peers a /48 route (http://en.wikipedia.org/wiki/Comparison_of_IPv6_support_by_major_transit_providers), and companies might not aggregate their PI routes as much as they could.
Add comment
Home
Sidebar