Every so often I hear the claim that some service or other does not support IPv6 not because of some technical issue, or some cost or business issue, but simply because the service operator is of the view that IPv6 offers an inferior level service as compared to IPv4, and by offering the service over IPv6 they would be exposing their clients to an inferior level of performance of the service. But is this really the case? Is IPv6 an inferior cousin of IPv4 in terms of service performance?
There is an extensive project underway to make our services easier to use and work together seamlessly, so that they provide the most value to you. Over the last couple of months we have been working very hard on the RIPE Database. We have made some fundamental changes to the web interface, which we are pleased to introduce to you.
The RIPE Routing Information Service (RIS) and RIPE Atlas produce large amounts of data that needs to be processed, stored and made available to the public. We've been using Hadoop for some time now. In this article we look at the design of the infrastructure we currently have in place and describe how we use it to serve RIPE Atlas and RIPEstat users.
In September of this year, we activated DNS-based Authentication of Named Entities (DANE) for our main web services, including www.ripe.net, the LIR Portal, RIPE Atlas and RIPE Labs.
One of the measurements that we have been running for a long time is IPv6 RIPEness, where we measure the IPv6 activity of our members. We award our members with stars if they (for example) announce their IPv6 allocation in the global routing table.
The Internet has a robust infrastructure that was designed to route around damage. But how well does it do this? We use RIPE Atlas to look at how large-scale disruptions in the Internet's core infrastructure affect end-to-end connectivity on the Internet.
In the course of 2015 we have expanded the K-root anycast cluster with 17 hosted servers in 15 new cities. We look at RIPE Atlas to see what impact this had on performance on both global and regional scales.
We're thinking about implementing WiFi measurements in RIPE Atlas, and we want to know what you think. There are several different ways we could do this - find out more below and then take our poll to make your voice heard!
In April this year we announced that K-root would open up for expansion to new locations. Since then we have added 17 additional K-root hosted nodes. Now is a good point in the expansion of K-root for us to provide a short update.
Rolling over the algorithm (usually to a stronger variant) used to sign a DNS zone isn't as easy as regular key roll-overs. This is because some DNSSEC validators are less forgiving than others, and fail validation unless the right combination of keys and signatures is present in a zone. This article describes our experiences with DNSSEC algorithm roll-over. We hope that our experience will help others who may be considering doing this.
There are a number of interesting new features and enhancements for RIPE Atlas users. Learn how you can put them to use!
We're pleased to announce a fresh new look for the RIPE NCC that better reflects who we are and what we do. Learn more about why we made the change and what the design process involved from the RIPE NCC's graphic designer, Miguel Bastos. We hope you'll like what you see!
We look at the RIPE NCC in terms of growth, geographic distribution and IPv6 deployment. We find that recent RIPE policy changes have had an impact on membership statistics and development trends.
In order to expand the reach of F-root, one of the 13 root servers, we at ISC looked at where queries to our F-root servers are coming from and where it would make most sense to place new nodes. As a first step, we looked at the existing nodes to see how they behave and if there is anything we can improve. We used RIPE Atlas to do this.
We've made some extensive improvements to the RIPE NCC Routing Information Service (RIS) which is an integral part of RIPEstat and heavily used by researchers and network operators. More changes will come and we need your feedback! Please note the questions at the end of this article.
In September 2012 the RIPE NCC reached its last /8 of available IPv4 addresses. This activated a new phase in the RIPE IPv4 policies, with each LIR now eligible to receive one final /22 allocation. In this article we look at developments in IPv4 allocations and remaining addresses at the RIPE NCC in the three years since then.
The Isolario project introduces a new concept of Route Collectors to devise real-time services and attract new BGP data sources. Thanks to the integration of BGPlay, the project provides new interesting troubleshooting tools to monitor BGP routes in real-time.
When operators and researchers use data from BGP route collectors such as RIS and Route Views, it's not easy to tell if a path announced to a collector is an ISP's customer cone, an internal route, or one learned from peering or transit. In this post we look at what information we can currently get from BGP communities in RIS.
Dyn Research published an article on K-root recently. Here we would like to augment the picture with data from RIPE Atlas in order to provide a more complete picture of the effect of the K-root node in Iran.
Please read about this new milestone release of the popular BGPlay web application. It can now receive BGP messages using WebSocket and update the visualisation on the fly.