
Echoes
• 4 min read
Recently, we spotted a network bug that had precisely the opposite of the intended effect.
Articles
Likes on articles
Stephen is a principal engineer in the Office of the CTO at Fastly, where he spends his time trying to figure out what the Internet is. He obtained his PhD in Internet routing scalability from the University of Glasgow in 2012.
Website: https://sdstrowes.co.uk/
• 6 min read
This year's Internet Measurement Conference (IMC) was held in London from 1 - 3 November. In this article we highlight some of the presented work that we think is interesting and that the RIPE community might find useful.
• 8 min read
This post provides an update on our IPv6 RIPEness project, including an analysis of IPv6 RIPEness for new Local Internet Registries (LIRs).
Hey! The difference is that the .bz2 is a dump of measurement results, but /api/v2/measurements/traceroute/ gives you measurement metadata. The json returned from the API call you provided includes 'result' fields, each of which refers to the measurement IDs with the actual results. If you want, you can run through those pointers and pull down the measurement results manually to get at the result data we're putting into the .bz2 archives. Note also that the output of that API call is paginated; use option "page_size=500" (the maximum) to reduce the number of pages you have to loop over. Hope that helps!
“So, historic data older than one month will be lost (or made unuvailable publically) forever?”
Hi Alexander! Measurement data -- all of it -- is always available via the API. The archives discussed here are a convenience method, offering data from recent public measurements in bulk form. In the future, we may modify this service to hold data for longer or to provide samples of older data, in the same location. If so, we'll be sure to announce it.
“Hi, all. Is there a recommendation (RFC or something) that ISPs follow for allow or not allow and propagate longer than /24 prefixes?”
Hi Alan! I'm not personally aware of a document, only the common convention that has been accepted for many years. Many documents refer to the current practice, including https://www.ripe.net/publications/docs/ripe-399 (from 2006) and https://tools.ietf.org/html/rfc4116 (from 2005). A more recent look at how far /24s propagate on the v4 Internet was published here: https://labs.ripe.net/Members/stephen_strowes/bgp-even-more-specifics-in-2017 In practice, the convention exists to avoid bumping into routing table limits too soon; even natural growth rates using the current conventions can catch networks unawares; for example, https://arstechnica.com/information-technology/2014/08/internet-routers-hitting-512k-limit-some-become-unreliable/
“Do you mean 6rd seriously? We live in year 2017 and you are using a technique for lazy people.”
Hi Thomas; we tend to take the view that reachability via an ISP-provisioned and managed transition mechanism is better than no reachability. Anything that brings more IPv6 to the internet is good.
Of course, the IPv6 world offers much finer granularity. A /32 ought to give folks 2^16 globally routable prefixes, so a maximum y-resolution of 65,536 pixels. x-resolution only relies on how patient the artist is!
Showing 5 comment(s)