The 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 ‘firstname.lastname@example.org’).
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.
That 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!