768k Day. Will it Happen? Did it Happen?

We've seen some buzz around 768k day. Some years ago the Internet experienced "512k day" (see the RIPE Labs article we wrote about it at the time), and it was predicted that due to reconfigs there could also be a "768k day".

This is the day that an unknown number of Internet routers would be affected by their IPv4 tables going over 768k routes. While there is much that remains unclear about whether and how this will happen, we can provide the view we have from our Routing Information Service (RIS).

It's even unclear where the 768k boundary is exactly. We've seen many sources interpret this as 768,000 (i.e. k =  1000), but clueful netops told us the 'k' should be interpreted as 1024, so the boundary is at 786,432.

We have a whois-type interface to RIS called "riswhois" that we can actually use to build a quick prototype monitor of the IPv4 tables provided by RIS. The "peers" query will show you the number of IPv4 and IPv6 routes for all of our RIS peers for the latest RIS dump file (which is produced for every 8 hour interval).

Anybody logged in to a UNIX-type computer that has a whois client and standard UNIX tools can do something like this:

whois -h riswhois.ripe.net peers | sort -n -k 4

The output of this is as follows:

What this shows is that RIS currently has nine peers that have over 768,000 IPv4 routes, none are over 786,432 yet as of 26 April 2019.

This data is also available as a data call in RIPEstat ( https://stat.ripe.net/data/ris-peers/data.json ). We've created a temporary dashboard of the state of RIS with regards to 768k routes which is available here:

RIPEstat widget will be rendered here

A standalone version of this is available at https://stat.ripe.net/widget/ris-768

What this shows is what percentage of our full-feed IPv4 RIS peers goes over the 768k limit based on the latest data we have a full snapshot of RIS for. We expect it to take quite some time before a majority, or even all, RIS peers are over the limit. We also noticed a large diversity in table sizes from our full-feed IPv4 peers, which indicates that potential effects of going over the 768k limit could be days or weeks apart, depending on where on the Internet you are. 

What can you do as network operator? If you have network equipment that might be affected by this, you have a number of options: as some immediate actions you could filter your routes or reconfigure your router before your table hits 768k. But what to do longer term about these types of limits? Some suggest to work with much smaller tables and a default route (see for instance this SwiNOG presentation by Fredy Künzler or this blog post by David Barroso).

If we find interesting things in the routing tables we monitor with RIS, we will report these on RIPE Labs.

Edited on 26 April 2019 to reflect the unclarity over k=1000 vs k=1024