‹ Back
Deploy360 21 November 2015

RIPE 71 – Highlights from Days 3 & 4

Kevin Meynell
By Kevin MeynellSenior Manager, Technical and Operational Engagement

RIPE71_logoThe RIPE 71 meeting is happening this week in Bucharest and each day we’ll be highlighting the presentations and activities related to the Deploy360 technologies.

Wednesday and Thursday were primarily devoted to RIPE NCC and RIPE policy matters, but there was also some interest for Deploy360 in the RIPE IPv6 and DNS Working Groups.

To start, we absolutely have to highlight the presentation by Geoff Huston on IPv6 Performance. This attempts to answer the questions about reliability of IPv6 connections in terms of how often TCP connections succeed, and whether IPv6 is actually slower than IPv4. Using a script embedded in an online advert that generates a set of URLs to fetch, this allows servers to determine reliability and RTTs, with measurements taken in both 2011 and 2015.

The first set of measurements taken in 2011 reveal astonishingly high failure rates for TCP connections over IPv6; around 40% on average. However, this was during the period when Teredo and 6to4 were still common and suggests either firewall configurations blocking incoming connections, or overloading/reliability issues with outgoing relays.

Matters seem to have improved in 2015, with substantially lower failure rates of just over 4% which also showed progressive improvement over the course of the year. Teredo has almost disappeared, but 6to4 still accounts for 27% of IPv6 connections and has a 9% failure rate. Unicast IPv6 hovers around 2%, although this compares with just 0.2% for IPv4.

Looking at the speed measurements, the comparative data from 2015 also shows significant improvement over 2011. In fact, for IPv6 unicast it is faster about half of the time, and 70% of all unicast cases are within 10 ms RTT of IPv4, although this decreases significantly with 6to4.

The conclusions are that if you can establish a connection then IPv4 and IPv6 appear to have comparable performance, although currently the odds of establishing the connection still favour IPv4. This might point to the various transition mechanisms employed, and further encourage the deployment of native IPv6.

It’s also worth highlighting a couple of IPv6 case studies presented in the IPv6 Working Group. First of all the presentation from Timo Hilbrink about IPv6 deployment at XS4All, a Dutch ISP that has enabled IPv6 for all subscribers since June 2014 and currently has 175,000 active IPv6 users. Then also the presentation from Oskari Rasi about IPv6 deployment at DNA Finland, the largest cable operator in that country that in 2015 has launched IPv6 support in their mobile, cable and DSL products.

And last but not least from the IPv6 Working Group, check out the presentation by Sander Steffann on DHCPKit which aims to solve the issues of dynamically assigned static IPv6 prefixes. Existing DHCPv6-PD servers did not work as well as desired, so a new DHCP server framework has been developed to handle this.

Over in the DNS Working Group there were also several items of interest. There was a good presentation from Chris Baker on iOS and OSX preferences for IPv6. In July 2015, Apple announced that iOS 9.x and OSX El Capitan 10.11.x would prefer using IPv6 by default, and Dyn have undertaken some real world tests on DNS resolution. This led to some interesting observations about the different underlying topologies of IPv4 and IPv6, and some anomalies that led to IPv6 queries being sent to servers in different continents.

Following on were a couple of presentations from NLnet Labs on work into ways to deliver DNSSEC information to end hosts that have customer premises equipment blocking it. They had enabled them to raise the number of successful DNSSEC queries to almost 80%, so please do take a look at the presentations on a Discovery Method for a Validating Stub Resolver, and DNSSEC for Legacy Applications.

Finally, you should be aware of the ICANN plans for the forthcoming Root Zone Key Signing Key rollover. This specifically relates to RFC 5011 which specifies a means for automated updating of DNSSEC trust anchors, but there are some concerns about how operators choose to follow the recommendations and whether existing tools fully or partially support these. ICANN is therefore raising awareness of this issue and building a list of parties who might be affected in order to best plan how to undertake the rollover and when.

All the presentations and videos from these sessions can be found on the RIPE 71 website.

‹ Back

Disclaimer: Viewpoints expressed in this post are those of the author and may or may not reflect official Internet Society positions.

Related articles

Improving Technical Security 15 March 2019

DNS Privacy Frequently Asked Questions (FAQ)

We previously posted about how the DNS does not inherently employ any mechanisms to provide confidentiality for DNS transactions,...

Improving Technical Security 14 March 2019

Introduction to DNS Privacy

Almost every time we use an Internet application, it starts with a DNS (Domain Name System) transaction to map...

Improving Technical Security 13 March 2019

IPv6 Security for IPv4 Engineers

It is often argued that IPv4 practices should be forgotten when deploying IPv6, as after all IPv6 is a...

Join the conversation with Internet Society members around the world