Deploy360 Events IPv6

RIPE 73 – Highlights from Days 4 & 5

RIPE 73 closingThe RIPE 73 meeting was happening last week in Madrid, Spain, and we’ve been highlighting the presentations and activities related to the Deploy360 technologies. There’s a few things to summarise from the last couple of days of the meeting.

Thursday saw the second part of the IPv6 Working Group that kicked-off with three case studies. First up was Marcus Keane (Microsoft) who discussed IPv6-only deployment at Microsoft. Microsoft’s main campus at Redmond had more than 100 buildings, but there were around 775 sites in the EMEA, Asia and North American regions with a total of approximately 1.2 million devices. They had first deployed dual-stack in 1993, but more broadly from 2006 using a mixture of ISATAP and native IPv6. The main motivations were a shortage of IPv4 address space, but also overlapping private address space that was causing difficulties with the Azure platform and when other enterprises were acquired.

Two test networks had been established at Redmond – one a wireless guest network using SLAAC for address configuration, and the other a wired and wireless corporate network using DHCPv6 stateful that users could opt into. Both use non-redundant NAT64/DNS64 and were gradually extended across the campus, although issues were encountered in that Windows could only support DHCPv6 whilst Android could only support RDNSS. However, some routers could not handle RDNSS so the solution was to operate a centralised default gateway with a L2VPN (EVPN) overlay, although this caused further issues in that EVPN was not supported over the L3VPN provisioned links to most remote sites. Current plans were to start piloting IPv6 only on the corporate networks using the centralised default gateway solution, probably targeting Redmond and Europe first.

Ondřej Caletka (CESNET) then presented how he’d implemented e-mail services over IPv6. As part of the World IPv6 Launch 2012, ten .cz domains had been established that only published AAAA records and allowed users to check whether they could send and receive e-mail via IPv6 (using ‘’).

During the period June to October 2012, around 100 messages were successfully received from 88 unique domains, of which 71 were from different IPv6 addresses although only 50 accepted a TCP connection to port 25. Furthermore, no major free mail services supported sending to an IPv6-only network at that time. Since May 2015 though, 303 messages were received from 138 unique domains, with just 39 bouncing from IPv6 addresses mostly due to no AAAA records being configured for the MX entry. So the problem with mail servers not listening on an IPv6 socket is obviously gone, and with Let’s Encrypt certificates supporting IPv6 validation since July 2016, there are even more incentives to send e-mail over IPv6.

Carlos Fricas (FCCN) provided the last of the case studies with a presentation on RCTS, the Portuguese National Research and Education Network. This serves 77 members that includes universities, polytechnic institutes and other sites, and has operated IPv6 since 2003. 33 of these members currently have an IPv6 connection, with 9 having a daily IPv6 traffic peak above 100 Mb/s and 1 with average IPv6 traffic above 100 Mb/s. RCTS was also hosting Google and Akamai caches with IPv4 and IPv6, and were currently considered other content providers.

Jan Žorž (Internet Society) then updated the group on a new Best Current Operational Practice document that was being developed on IPv6 prefix delegation for end-users – static or dynamic and what size to choose. This is currently being written and edited on Google Docs, but it needs further input and endorsement from operators with practical experience, so volunteers were being sought.

img_0017That just leaves us with Friday’s presentation from Geoff Huston (APNIC) on IPv6 Performance Revisited. Following on from his previous work, he had further looked at how many TCP connections succeeded via IPv6, and whether IPv6 was slower than IPv4. This uses the measurement technique of embedding a script in an online ad that generates a set of URLs to fetch, and then examines connection reliability and round trip time (RTT) when using IPv4, IPv6 and dual-stack.

IPv4 saw connection failure rates of around 1 in 500 (0.22%), but IPv6 saw a failure rate of 1.5% which may possibly be down to tunnelling, end device firmware, firewalling or assymmetric routing. Neither are IPv6 failure rates uniformly distributed globally, with Sri Lanka showing a 45% failure rate, Israel 19%, Mexico 18% and Brazil 9% before figures drop into the 5% range.

When it comes to RTTs, IPv6 appears to be 20-40ms slower on average than IPv4, although this appears to be attributable to routing assymmetry and other reasons. For example, China demonstrates the slowest RTTs using IPv6, whilst in Europe a number of networks are actually faster over IPv6 than IPv4.

So some conclusions that may be drawn are that unicast IPv6 can generally be said to be as fast as IPv4, with faster RTTs around 50% of the time and being within 10ms of the RTT of IPv4 in about 75% of other cases. In terms of connection reliability, the odds are still weighted in favour of establishing a connection via IPv4, although this has improved over time as older transitional mechanisms have been deprecated.

So with that, it’s Adios from us. All the presentations from the meeting can be found on the RIPE 73 website.

The next RIPE meeting will held on 8-12 May 2017 in Budapest, Hungary. We’ll again look forward to seeing you then!

Deploy360 Domain Name System (DNS) IPv6

RIPE 73 – Highlights from Day 3

RIPE 73 DNS Working GroupThe RIPE 73 meeting is happening this week in Madrid, Spain, and we’re highlighting the presentations and activities related to the Deploy360 technologies throughout the week.

Wednesday was mostly devoted to Working Groups, and there were several interesting presentations to highlight during the IPv6 Working Group.

First up was Geoff Huston (APNIC) with the latest facts and figures from the APNIC Labs studies on IPv6 – this time it was the turn of IPv6 and the DNS. When levels of IPv6 adoption are discussed, it invariably refers to what percentage of users are able to access web services via IPv6, but the Internet is more than just the web and a critical component is the DNS. One important question therefore, is how much of the DNS resolution infrastructure is IPv6 capable.

Using the tried-and-tested Google ad technique running between July and August 2016, it was possible to collect around 400 million measurements spanning most of the Internet. This revealed that of 345,394 unique resolvers, around 22% appeared to be capable of using IPv6 to make DNS queries, with around 35% of users directing queries to these IPv6 resolvers. However, 11% of queries appear to be passed to resolvers that are dual stack capable, whereas if the choice of protocol were random this should be closer to 17%. This suggests there’s an inherent bias to use IPv4 when a server is reachable via both protocols.

The reliability of DNS responses via IPv6 was also examined, which revealed a 96% response rate. Whilst within acceptable parameters, it could be further improved with careful configuration of resolvers, in particular by using a local UDP Maximum Transmission Unit (MTU) of 1,500 octets to avoid IPv6 fragmentation and by ensuring there are no ICMPv6 filters.

So the conclusion is that the DNS infrastructure appears to be further ahead than the web in terms of IPv6 usage, and could be substantially higher if query mechanisms were configured to prefer IPv6.

Vaibhav Bajpai (Jacobs University, Bremen) then presented measurements of the effects of Happy Eyeballs. Happy Eyeballs is an algorithm published by the IETF (see RFC 6555) that attempts to determine whether it’s better to use IPv6 or IPv4 for a particular connection by trying them both in parallel, but allowing a response period (typically 300 ms) to order to favour IPv6.

Measurement data was collected between 2013 and 2016 on connections to the top 10,000 Alexa websites. This reveals that TCP connect times to IPv6 websites have considerably improved over this period, that 18% of connections to websites are actually faster over IPv6, with 91% of the slower connections still being within 1 ms of the IPv4 connect time. The Happy Eyeballs timeout period also means that IPv6-capable websites favour IPv6 around 99% of the time.

The timeout intervals were chosen IPv6 connectivity was much more unreliable, particularly when more transition mechanisms had to be used. With more native IPv6 available now, lowering the timeout to 150 ms does not seem to significantly alter these preferences and would improve responsiveness.

The caveats are that only connections to TCP port 80 on the Alexa Top 10,000 websites have been measured, and results may be biased by the vantage points in Europe, the United States and Japan. However, it does again highlight that IPv6 performance is generally comparable with IPv4 performance where IPv6 connectivity is available.

Alain Durand (ICANN) rounded off the session with an analysis of IPv6 as related to GDP per capita. This correlates IPv6 deployment data from APNIC Labs and the Akamai State-of-the-Internet report with GDP per capita data from the World Bank, to see whether more affluent economies are more likely to deploy IPv6 than developing economies.

As might be expected, the top 50 countries by GDP capita (i.e. >USD 23K) tend to have significantly higher levels of IPv6 deployment, although there are substantial variations within this group. For example, Belgium, the United States, Germany, Switzerland, Greece and Portugal stand out from the others with 30-50% rates of deployment compared to an average of around 14%, which suggests specific deployment initiatives rather than funding can reap rewards.

The remaining countries in the world typically show very low levels of IPv6 deployment although there are some very notable exceptions in Brazil, Ecuador, Haiti and Peru. Rather interestingly, Kiribati showed high IPv6 deployment despite being one of the poorer countries in the world, although of course is a small country in terms of population and with a limited number of network operators.

Another interesting comparison was those countries that could use IPv6, but made relatively little usage of it, whilst other countries with apparently little penetration made heavy use of it. It might therefore be concluded that IPv6 could be more widely used than it is, which is another lesson that it’s increasingly practical to favour IPv6 over IPv4.

One last thing to mention was the proposed clarification from Maximilian Wilhelm (Freifunk Hochstift) on IPv6 Provider Independent Sub-Assignment during the Address Policy Working Group. Current RIPE policy as defined by ripe-637 states that provider independent resources may not be sub-assigned to a third party. The proposal is to change this in ripe-655 to define a sub-assignment as a /64 or shorter in order to provide better guidance to the RIPE NCC and resolve current policy violations.

For those of you who cannot attend the RIPE meeting in person, just a reminder that remote participation is available with audio and video streaming and also a jabber chat room.

The full programme can be found at

Deploy360 Domain Name System (DNS) IPv6

RIPE 73 – Highlights from Day 2

RIPE 73 bannerThe RIPE 73 meeting is happening this week in Madrid, Spain, and we’re highlighting the presentations and activities related to the Deploy360 technologies throughout the week.

Tuesday was a bit of a quiet day for Deploy360, although it’s worth picking out a couple of presentations. Ricardo Schmidt (University of Twente) provided some observations and lessons learned from the attack on the DNS Root in November last year.

Distributed Denial-of-Service (DDoS) attacks have been getting bigger and more frequent in the past few years, but the attack on the 30 November 2016 saw the DNS root hit with an extra 5 million queries per second that generated traffic loads of up to 35+ Gb/s. The B, C, G and H root servers were most affected, the E, F, I, J and K root servers less so, with the D, L and M root servers not seeing any attack traffic at all. However, even the root servers that weren’t directly attacked felt the impact, as the other servers became less responsive and queries started to be re-directed.

Nevertheless, the root DNS handled the situation well due to its distributed nature and built-in redundancy, and at no time was the service completely unreachable. The lessons to be learned though, is that very large DDoS attacks are now possible and this needs to be taken into account when designing distributed systems and countermeasures. It is unclear who was behind the attack or what the motivations were, but it was clearly intended to take down critical infrastructure and should be considered a wake-up call as to the possibilities in the future.

Another interesting talk was given by Annie Edmundson (Princeton University) on transnational routing detours through surveillance states. This was a study on which countries were being traversed by Internet paths to reach popular destinations, where local traffic left a country, and whether end users could avoid certain countries known to practice surveillance. Traffic to the Alexa Top 100 domains from Brazil was analysed, which revealed that nearly 80% was destined for the United States, whilst nearly 85% of the rest of the traffic traversed the United States. However, by establishing relays in particular countries, it was possible to tunnel traffic to avoid specific countries most of the time, the exception being the United States that was difficult to avoid due to the number of sites hosted there.

Future work will be looking at whether there are significant differences between IPv4 and IPv6, as well as the relationship between IXPs and through which countries traffic is routed.

Finally, although not something we normally cover in Deploy360, we should highlight the presentation from Elise Gerich (ICANN) on the IANA Services. As part of the recent IANA stewardship transition, ICANN has recently established an affiliate non-profit public benefit corporation called Public Technical Identifiers (PTI) to perform the IANA services, and Elise provided some details about this.

The more interesting aspect though, is that IANA recently allocated an additional /18 from the recovered pool of IPv4 to each of the Regional Internet Registries, with further allocations scheduled every six months until March 2019. However, if no more blocks were returned, this would be last allocation of IPv4 addresses, so the message once again is that network operators need to have plans to deploy IPv6 before then.

For those of you who cannot attend the RIPE meeting in person, just a reminder that remote participation is available with audio and video streaming and also a jabber chat room.

The full programme can be found at

Building Trust Deploy360 Domain Name System Security Extensions (DNSSEC) Improving Technical Security IPv6

RIPE 73 – Highlights from Day 1

RIPE 73 plenaryThe RIPE 73 meeting is happening this week in Madrid. Spain is less than sunny at this time of the year, but who cares about the weather outside when there’s plenty of interesting talks to listen to inside? 670 participants are here, along with Jan Žorž and Kevin Meynell from the Deploy360 team to highlight all the relevant presentations and activities.

First up are the results of the IPv6 Deployment Survey recently undertaken by Consulintel which aimed to get a perspective on the types of residential and household services. Jord Palet (Consulintel) explained there were more than 1,200 replies, with 31% of these coming from IPv6 enabled respondees in 100 countries.

31% of the respondees stated that IPv6 was already available as a commercial service, 17% saying it was not available, whilst 52% didn’t know. The most common customer address prefix size was a /56 (35%) with a /64 (33%) also being nearly as common. Other prefix sizes included /29, /44, /57, /60, /62, /127 and /127, although it was interesting that /48 was most common in richer countries, /56 was most common in the ARIN and RIPE regions, whilst /64 was most common in the LACNIC region. However, in terms of address stability (i.e. prefixes don’t change from session-to-session), this was more common in the AfriNIC, APNIC and RIPE regions, much less common in the ARIN region, whilst LACNIC fell somewhere in between. It is unclear why stable IPv6 addresses are not being offered routinely, but this may point to an IPv4 mindset by network operators.

A number of different transition mechanisms appear to be use, but there appears to be an increasing trend to use technologies that do not actually require IPv4 for access. IPv6 reverse DNS did not entirely follow the figures for IPv6 availability, with somewhat fewer IPv6 prefixes delegated in the DNS than in the forward DNS, but there were generally encouraging signs that IPv6 was being deployed correctly.

On a related note, Philipp Richter (Technische Universität Berlin) provided an excellent analysis of Carrier-Grade NAT Deployment. 75 ISPs from all regions of the world took part in a survey on their plans for CGNs, of which 38% had already deployed them, 12% were considering deployment, and 50% had no plans for deployment. It also revealed that subscribers behind CGNs had complained about problems with applications (e.g. gaming), concerns were expressed about the traceability of users, and there were issues with CGN IP addresses being blacklisted. There were further difficulties in troubleshooting connectivity problems, as well as with internal address shortage and/or address fragmentation as even private IP address ranges prove insufficient to meet demand. The implication was that CGNs can ultimately not solve IPv4 address shortages, cause increasing problems as more are deployed, and are not considered a long-term solution by a significant number of ISPs

During the lightning talk session, Geoff Huston (APNIC) highlighted the problem of ensuring which Certificate Authority is allowed to validate a site certificate that is used to establish an encrypted connection. We’ve discussed this before, but any CA can essentially issue a certificate for any domain which means users are forced to rely on a third party for establishing trust connections. An alternative is to put certificates in the DNS and then use the DANE protocol to allow users to validate that those certificates are associated with the correct domain.

One issue though, is that large cryptographic keys and the DNS don’t mix very well thanks to the limitations on UDP packet sizes, and this can force resolvers to switch to TCP for queries. This brings its own problems in terms of responsiveness and loads on DNS servers, but one option is to adopt Elliptic Curve Cryptography (ECC) that allows for strong public/private key pairs with shorter key lengths than equivalent strength keys using RSA. In principle, a 256-bit ECC public key should provide comparable security to a 3072-bit RSA public key.

The Elliptic Curve Digital Signature Algorithm (ECDSA) offers a variant of the Digital Signature Algorithm (DSA), and APNIC Labs are now evaluating where this is deployed in the DNS. A daily overview can be found on the APNIC Labs website, which made for interesting reading in Spain which relied heavily on Google for its DNSSEC validation rates. So still some work to be done!

Roy Arends (ICANN) rounded-off the plenary session with an update on the plans for rolling the Root Zone DNSSEC Key Signing Key. We already discussed this in our recent report on ENOG 12, but it’s important enough to repeat again.

ICANN in its role as the IANA Functions Operator, manages the Key Signing Key (KSK) used to sign the Root Zone Signing Key (ZSK) which is managed by VeriSign and changed every quarter. The current KSK has been used since the Root Zone was first signed in 2010, and whilst it does not have any expiry date, it’s good practice to change keys, the DNSSEC Practice Statement calls for the KSK to be rolled, and ICANN wish to try this exercise under normal rather than emergency conditions (such as a key compromise).

The rollover plan is outlined in five documents, with a view to generating the new KSK in the 4th quarter of 2016, adding it to the root zone on 11 July 2017 (in parallel with the old KSK), and then signing the DNSKEY RRset starting from 11 October 2017. The old KSK will be revoked on 11 January 2018, but will remain in the root zone.

Following the plenary session, Jan Žorž chaired the BCOP Task Force. Sander Steffann reported on the IPv6 for Enterprises work, which was an effort to develop and collate BCOPs into an overall guide for enterprises. There had been a meeting on 7-8 September in Amsterdam where Sander, Jan, Kevin Meynell, Nathalie Trenaman (RIPE NCC) and Ron Broersma (US Navy SPAWAR) to brainstorm on some of the constituent documents covering test environments, host configuration models, routing protocols, addressing plans and security considerations.

Jan also presented the IPv6 prefix delegation for end-users BCOP, but called for comment and support from operators with practical deployment experience, as well as on the RIPE IPv6 Working Group to check the technical validity of the document.

Andrei Robachevsky then outlined the MANRS BCOP which aims to provide practical information on how network operators can improve the security and resilience of the global routing system through four actions that include filtering, anti-spoofing, coordination and address prefix validation.

Last but not least, Guillermo Cicileo (LACNIC) provided an update on the LACNOG BCOP Working Group. This had recently published a Spanish language version of the Requirements for IPv6 in ICT Equipment based on ripe-554, and were working on a similar translation of ripe-631 on IPv6 Troubleshooting for Residential ISP Helpdesks. Other documents in progress included BGP implementation, CPE attack mitigation techniques, Operator and CSIRT cooperation plans, first steps in IPv6 implementation and Remote Triggered Black Hole routes (RTBH).

For those of you who cannot attend the RIPE meeting in person, just a reminder that remote participation is available with audio and video streaming and also a jabber chat room.

The full programme can be found at

Deploy360 Events IPv6

RIPE 73 starts in Madrid next week

ripe-73The RIPE 73 meeting is happening next week in Madrid, Spain, kicking off with a couple of tutorials on the Monday morning, before the opening plenary starts at 15.00 CEST/UTC+2. And there’s a lot on the programme of interest if you’re following the Deploy360 technologies, as both Jan Žorž and Kevin Meynell will be.

In the opening plenary, the results of the IPv6 Deployment Survey on residential and household services undertaken by Consulintel will be presented, followed by an analysis of Carrier-Grade NAT (CGN) from Philipp Richter (TU Berlin). Then check out the state of IPv4 transfer markets with Ioana Livadariu (Simula Research Laboratory).

Jan will then be chairing the BCOP Task Force on Monday evening starting at 19.00 UTC+2. This will discuss progress on documenting best current operational practices, with three BCOP documents up for discussion including a new MANRS BCOP. As ever, the Task Force is also looking for volunteers to help support the task of writing the documents and achieve consensus within the group.

On the Tuesday morning, there’s a focus on anycast, with four presentations covering different aspects of this. The afternoon is devoted more to network security, data protection and privacy issues, although there will also be a panel chaired by Leslie Carr on the unique financial challenges of smaller IXPs

Wednesday and Thursday are traditionally devoted to Working Groups, and as usual we’ll be following the IPv6, DNS and Routing Working Groups and reporting on developments there. It’s also worth noting there’s also an open mic  session on the Internet-of-Things between 19.00 and 20.00 UTC+2, which aims to discuss what role RIPE can play in this space and whether the RIPE community’s expertise can be put to good use in safeguarding the security and stability of the Internet.

Finally on Friday, there will be an update on IPv6 performance from Geoff Huston (APNIC) which always makes for interesting listening.

There are already over 600 registered attendees, so it’s sure to be a busy and productive week. For those of you who cannot attend in person – there is remote participation available with audio and video streaming and also a jabber chat room, so everyone is welcome to participate!

The full programme can be found at