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.