You are here: Home > Publications > RIPE Labs > Geoff Huston > Routing IPv6 in 2011

Routing IPv6 in 2011

Geoff Huston — 04 Oct 2011
This is a follow-up to the recently published article "Routing 2011" which focused on IPv4. In this new article Geoff is looking at the IPv6 routing table.

Recently I wrote about the IPv4 routing table , and the changes that were observed across 2011. A reader has asked me:

 "Is the v6 table included in this? Would the v6 table size curve in
   any way pick up where the v4 curve "left off"? Maybe I'm being too
   hopeful!"

In response, I promised to provide a followup article with a description of the IPv6 routing table over 2011.

I've generated a plot of the size of the IPv6 routing table from 1 January until the end of September 2011. The vantage point I've used is AS 131072, but the view is not particularly special, and almost any view of the IPv6 routing table will be pretty similar.

Lets use the graph in the previous article of IPv4 routing table size with a comparable graph of the IPv6 routing table size to compare IPv4 and IPv6 (see Figure 1 below).

IPv6 BGP Routing Table in 2011

Figure 1: SIze of IPv6 BGP Routing Table in 2011

What's the difference between IPv4 and IPv6?

The first difference is scale. The IPv4 routing table has grown from some 340,000 entries to a little under 380,000 entries. The IPv6 network has grown from some 4,200 entries in January 2011 to some 7,300 entries at the end of September 2011. In terms of absolute scale the IPv4 network has grown by 40,000 entries, as compared to 3,100 in IPv6. So in terms of absolute values the growth in IPv4 is more than 13 times greater than the growth in IPv6. In relative terms, however its a different story. Those additional 40,000 entries represent a growth of 12% in the size of the IPv4 routing table, while the additional 3,100 IPv6 entries represents a growth of 135% in the size of the IPv6 routing table. While the scale of the IPv6 routing table is far smaller at present in absolute terms, and its growth is far smaller in absolute terms, in relative terms its a different story, where IPv6 is growing at a much faster relative rate.

The second difference is the shape of the two plots. In IPv4 we saw a slowing growing process that was interrupted in late April and this slower growth has persisted until now (the previous article had some explanations and speculation as to the reasons for this, so I won't repeat them here). The shape of growth in IPv6 is quite different, with a noticeable very high growth period from mid May until early June. Indeed this growth spurt stops abruptly on the 8th June, coinciding with World IPv6 Day. It appears that an additional 1,000 entries were added to the IPv6 routing table as part of the preparations for World IPv6 Day. And just to show that we really are good at leaving things to the last minute, the largest growth was in the first 7 days of June! Since June the rate of growth has slackened off, to an average rate of some 7 new entries per day, while the peak average rate in May was some 20 new entries per day.

When will IPv6 be as "large" as IPv4?

The data on 2011 is not quite enough to make a reasonable projection, but if we look back to 2009 and take the last 3 years of IPv6 routing table data we can make some models about where all this could be heading. Firstly, what is "as large as IPv4?" Is it all 380,000 entries that we see today? Or maybe thats not a realistic comparison. Don't forget that the IPv4 routing table has a fair amount of historical legacy in it, and routing practices in IPv4 make heavy use of fragmentation. I've often heard the expectation that this will not be accurately replicated in IPv6, and the evidence in the routing system appears to suggest that the two protocol domains are managed differently in the routing system. In IPv4 the average number of BGP routing advertisements per origin AS is currently at a level of 9.7. In other words each routing entity in the IPv4 network advertises an average of 9.7 separate prefixes into the routing table. The situation with IPv6 is quite different, with each IPv6 origin AS advertising an average of 1.6 separate prefixes per origin AS. There are currently some 40,000 AS's used in the IPv4 routing table, and if this was an equivalent IPv6 network without the history and current routing management practices of IPv4, it can be argued that the equivalent IPv6 network would be just some 64,000 entries, rather than the 380,000 entries we actually see in the IPv4 routing system. The model of growth of this equivalent IPv4 network is:

 v4(x)  = 247 (x**2) -991549 x + 993554584

The compound growth model for IPv6 is modelled by the equation:

 v6(x) = e ** (0.562 * x -1120.904)

As you can see in Figure 2 below, these two equations intersect in mid 2016, when the IPv6 network model has 100,000 entries, and has some 62,500 AS numbers.

IPv4 and IPv6 BGP Table Model Figure 2: Model of growth for IPv4 and IPv6 BGP table entries

Of course all this is, to some extent, just fun with some equations. It is still the case that IPv6 is very much the smaller network today, but these models illustrate that if the current deployment momentum in IPv6 is maintained, then parity with a still growing IPv4 network is theoretically possible within five years from now!

7 Comments

Anonymous says:
05 Oct, 2011 09:45 AM
Hi Geoff,
I liked this graph, thanks for the work!
In your graph, is there -or did you use- any numerical corelation in between v4 and v6 routing table entries?
I mean increase in v6 routing entries should -somehow- affect the v4 routing entries ( maybe decrease in v4 entries since networks will leave v4 addressing)? Just an observation :)
Anonymous says:
05 Oct, 2011 12:26 PM
THanks for your comment. I did not see that correlation, and actually I don't expect to see any such direct correlation. The reason why is that IPv6 is not a direct substitute for IPv4. For example, if I were to immediately switchover from using IPv4 to exclusively use IPv6 then I could only communicate with those folk who also use IPv6, and I could not communicate with all the rest of the Internet that still uses IPv4. So for some time yet we are all going to have to operate our networks in dual stack mode, supporting IPv4 and IPv6. This means that adding IPv6 to your network does not mean that you can drop IPv4. More generally, these additional entries in the IPv6 routing table have no impact on the advertised IPv4 routing table entries.
Anonymous says:
05 Oct, 2011 04:32 PM
Geoff, I'm trying to understand how you calculate growth from 4200 prefixes to 7200 prefixes, an increase of 3100 prefixes, to become a growth of 135% ?

Looks more like 74% to me.

Thanks!
Anonymous says:
05 Oct, 2011 04:53 PM
You know I am trying to understand that too, because it is indeed 74%!

thanks for pointing this out!

Geoff

(the captcha for this comment has got me to enter the word "goat" - I thought it was appropriate for me on this :-))

Anonymous says:
05 Oct, 2011 07:04 PM
Hehe, the Captcha I had to enter for my comment above was "broken". :)

(Now it's "tail", so that makes this a "broken goat tail"? )
Anonymous says:
05 Oct, 2011 11:17 PM
Geoff, i had done something similar some months ago, but using many different approaches. My last graph seems quite similar to yours, although blog readers have shown a preference on much higher numbers.

http://ccie-in-3-months.blo[…]late-ipv6-bgp-table-in.html
Anonymous says:
06 Oct, 2011 08:18 AM
That's some very nice work you've done there! Interestingly, much has changed since March of this year. Curve fitting to IPv6 has been challenging this year - that growth spurt leading up to World IPv6 Day was great for IPv6, but it confused most forms of curve fitting algorithms! A longer discussion about the BGP table size in IPv4 andy IPv6 in recent years, and some further study on predictive approaches can be found at http://www.potaroo.net/ispcol/2011-11/bgp2011.html.
Add comment

You can add a comment by filling out the form below. Only plain text is possible. Web and email addresses will be transformed into clickable links. Comments are moderated so they won't appear immediately.