As our activity in the Middle East slows from now until the end of July, we take the opportunity to present a recap of the RIPE NCC's second year of operations from the Dubai office.
IP anycast has been widely used to replicate services in multiple locations as a way to deliver better performance and resilience. It has been largely employed by CDNs and DNS operators, such as on the root server system. However, there is little evaluation of anycast under stress.
After 15 years conducting training on IPv6 in over 110 countries, I’ve been asked all sorts of questions. “How do I use my IPv6 addressing space?” “What prefix size should I provide to customers?” Although I have answers to these and many other best practice related questions, the one question, which I have not been able to answer to the best of my ability, is “What is the approach of other ISPs?”. So I decided to find out.
For a while now, the number of active RIPE Atlas probes has hovered around the 9,400 mark. This means that new probes are being connected at a fast enough rate to replace failing probes, but not enough to grow the network. At the same time, the version 3 probes have problems with their USB sticks. This led us to wonder whether these two issues are related.
In May 2015, we looked at IPv4 transfers in the RIPE NCC service region and found signs of an emerging market. Both the number and size of transfers conducted under RIPE Policy showed an upward trend in the years 2013-2014. One year later, we take another look. Did this trend continue? What have been the effects of the inter-RIR transfer policy?
When Rob Blokzijl stepped down, he handed over the role as Chair of RIPE to me in the closing plenary of RIPE 68 in Warsaw, 16 May 2014. Rob had been the RIPE Chair for 25 years since 1989 and there has not been any procedure for selecting the Chair. Rob tasked me to put in place a procedure to elect my successor.
We've updated the RIPE Atlas APIs - and there's a comprehensive new manual to explain how to use them. As a result, the current (version 1) APIs are still available for now, but will be deprecated by the end of the year.
This work demonstrates the value of the results collected by RIPE Atlas independent of the original purpose for collecting them. Using all traceroute results from a particular day as an example, we first show that near real-time analysis of the result stream is feasible. Then we show that this has great potential for studying the packet layer of the Internet in general and for providing tools to network operators in particular. All this suggests a large and diverse potential for further work.
The design of IPv6 represented a relatively conservative evolutionary step of the Internet protocol. Mostly, it's just IPv4 with significantly larger address fields. Mostly, but not completely, as there were some changes. IPv6 changed the boot process to use auto-configuration and multicast to perform functions that were performed by ARP and DHCP in IPv4. IPv6 added a 20-bit Flow Identifier to the packet header. IPv6 replaced IP header options with an optional chain of extension headers. IPv6 also changed the behaviour of packet fragmentation. Which is what we will look at here.
Pinpointing Delay and Forwarding Anomalies Using RIPE Atlas Built-in Measurements - Or How I Learned to Stop Worrying and Love the Built-Ins
Detecting network disruptions is a recurring problem. Clearly locating performance degradation is an important step in debugging and subsequently fixing connectivity issues.
Over the last year the RIPE NCC made a significant number of incremental changes to the RIPE Database user interface. The implementation of streamlined authentication using RIPE NCC Access has put us in a position where we can further improve the user experience in other areas.
Ahead of RIPE 72, we wanted to take another look at our membership statistics. Was membership growth affected by the Executive Board's resolution preventing multiple LIR accounts? And how will the growth in new LIRs affect the projected lifespan of the available IPv4 pool?
This article explains how I use RIPE Atlas probes, the official API and custom scripts to debug network issues.
Please read this guest post by Byron Ellacott, Senior Software Architect at APNIC: The Internet of Things without the Internet is just things, and we’ve had things since the first caveman used a pointy stick to draw on a wall. What then does the Internet bring to things to justify a capital T?
Please enjoy this guest post by Agustín Formoso, Software Developer at LACNIC: Regional connectivity is not an easy metric to measure. To do it properly you need measurements generated by multiple vantage points, located in as many places as possible (both geographically and logically). Besides, connectivity is not something strictly defined, as it has no standard definition (as opposed to many metrics we use in today’s Internet).
RIPE Atlas back-end applications run on more than 40 servers. Each day these machines can produce thousands of application logs of any kind of severity level. In order to be able to track down serious errors, warnings or even unusual behaviour, we decided some time ago to try Elasticsearch as a logging sink. In this article we will look at the design of such a system and describe how we can easily make sense from an ocean of logs.
I attended a conference on Broadband Services and Infrastructure Mapping, which I think had some interesting content for RIPE Labs readers.
The IXP country jedi tool described in earlier RIPE Labs articles, can also be used to analyse the situation in a specific city. This time we look at Berlin.
The RIPE NCC has developed an additional interface for the RIPE community mailing lists – something that we hope will encourage more interaction and discussion among the RIPE community.
Recently we have seen an increase in the frequency of excessive traffic towards the RIPE NCC DNS infrastructure. Our servers generally absorb peak loads without an impact on our DNS services. However, to be better prepared for extreme traffic floods, we will work with an external party to provide additional DNS service capacity for serving the ripe.net zone.