The RIPE 74 meeting was happening last week in Budapest, Hungary, and we’ve been highlighting the presentations and activities related to the Deploy360 technologies. Although much of the action for us happened on the first couple of days, there’s still quite a few things to highlight from the rest of the week.
Wednesday and Thursday were largely devoted to the Working Groups, and there were several interesting presentations during the IPv6 Working Group.
First up, Enno Rey (ERNW) presented the results of his testing of different operating systems for IPv6 address selection as defined in RFC 6724. This defines multiple ways for source addresses to be selected, and the tests were applied to different versions of Windows (7/8.1/10), Linux (Ubuntu 16.4 & Debian 8), iOS (9.3.2) and Windows 10 Mobile. Whilst different behaviours were observed, all the operating systems did appear to conform to the RFC in a consistent manner, which suggests that interactions with other mechanisms need to be considered when unpredictable behaviour is encountered.
Friso Feenstra (Rabobank) then followed-up on Tuesday’s presentation about how Rabobank had deployed IPv6, with some details about their addressing plan. This is a large bank with a presence in some 20 countries, nearly 1,000 offices and 12 data centres, and he outlined how their /29 prefix was allocated to minimise the size of routing tables, and to keep ACL and firewall configuration simple. They also defined security areas to allow specific network and device rules to be applied, and to ensure routing is clearly demarcated.
Another good case study was provided by Martin Levy (Cloudflare) who talked about how Cloudflare had enabled IPv6 support by default on their websites. This had led to a significant jump in IPv6 traffic as it provided a bridge for IPv6-enabled clients to access IPv4-only content via IPv6, and the presentation includes some interesting figures about who are the top IPv6 network operators, where the traffic is coming from, and the types of devices being used.
Quite a lot of deprecated DNS A6 queries were still being seen though, as well as incomplete A & AAAA records which is limiting the effect of Happy Eyeballs. Cloudflare was therefore proposing to return both a A and AAAA response to an valid query, which should then be cached by resolvers. This is currently the subject of an Internet Draft, although there are two alternative proposals going through the IETF.
Next up was our colleague Jan Žorž who again presented the results from the NAT64/DNS64 testing being undertaken by the Go6lab and supported by the Internet Society. We already discussed this earlier in the year, but it’s again worth mentioning the NAT64check tool that enables websites to be checked for consistency over IPv4, IPv6-only and NAT64, as well to compare responsiveness using the different protocols. This allows network and system administrators to easily identify anything is ‘broken’ and to pinpoint where the problems are occurring, thus allowing any non-IPv6 compatible elements on the website to be fixed.
Rounding off the IPv6 Working Group was a presentation from Jordi Palet (Consulintel) on using 464XLAT in Residential Networks. 464XLAT allows IPv4-only applications on IPv6-only networks to access IPv4 services elsewhere on the Internet, and therefore provides a solution for deploying IPv6 to residential customers where you don’t want existing applications to break. It makes efficient use of existing IPv4 resources, yet allows networks to grow without being reliant on IPv4 availability. As a result, RFC 7084 was currently being updated to recommend support for 464XLAT in the basic requirements for IPv6 customer edge routers.
It should also be mentioned there was a lively panel discussion during the IPv6 Working Group on the topic of IPv6 in the Enterprise. This involved Marcus Keane (Microsoft), Enno Rey (ERNW), Benedikt Stockebrand (Stepladder IT Training & Consulting), Sander Steffann (SJM Steffann) and Friso Feenstra, (Rabobank). A video of the proceedings is available.
There were also a few other things to highlight in the other Working Groups:
During the Routing Working Group, there was an update on MANRS from Ben Maddison. This initiative defines four concrete actions that network operators should implement to promote a culture of collaborative responsibility, and the next steps are to develop a MANRS certification programme as well as partnerships with IXPs.
In the Open Source Working Group, a couple of useful RPKI tools were announced by Andreas Reuter (Freie Universität Berlin). RPKI MIRO is a framework to monitor and inspect RPKI repositories, and includes the RPKI Browser which provides GUI access to the structure of the RPKI and the content of RPKI objects. RTRlib is a C library that implements client functionality to gather data from RPKI caches and perform origin validation, and is used in several applications (e.g. Quagga) to validate and monitor BGP updates.
That just leaves the DNS Working Group and the presentation on DNS Privacy from Benno Overeinder (NLnet Labs). We already discussed DNS over DTLS a few weeks ago, but DNS queries and responses are normally exchanged unencrypted on the network between a DNS client and server, and can therefore be monitored to reveal potentially sensitive information. The aim is deploy mechanisms to provide confidentiality to DNS transactions using TLS, and NLnet Labs and others have developed some test resolvers that can support this. For more information, check out the IETF DNS Privacy Tutorial.
That concludes the week, and we say Viszlát from the beautiful city of Budapest. All the presentations from the meeting can be found on the RIPE 74 website.
The next RIPE meeting will be held on 22-26 October 2017 in Dubai, UAE, which will be the second time it’s gone there. We’ll see you then, Inshallah…
