‹ Back
Deploy360 30 May 2016

RIPE 72 – Highlights from Day 4 & 5

Kevin Meynell
By Kevin MeynellSenior Manager, Technical and Operational Engagement

RIPE 72The RIPE 72 meeting was happening last week in Copenhagen, Denmark, and we’ve been highlighting the presentations and activities related to the Deploy360 technologies. In this post we’re summarising the last couple of days of activity before the meeting drew to a close.

The Thursday was also mostly devoted to Working Groups, including the second part of the IPv6 Working Group. We have highlighted this before, but it’s worth mentioning again the report on IPv6 deployment in Latin America and the Caribbean from LACNIC. This is a comprehensive survey of the current state of IPv4 exhaustion, case studies of IPv6 deployments, but perhaps more interestingly the problems, challenges and regulatory barriers that were experienced. The report also provides insight into the rationale of those ISPs not currently considering the deployment of IPv6.

This was followed by a useful presentation on Going v6-only at home by Luuk Hendriks (University of Twente) which aimed to get an IPv6 only Wireless LAN up and running in a home environment. The rationale was to find a solution that is generally deployable and therefore not to have to buy any special hardware or require hacks, as well as discover which elements had shortcomings. It transpired that problems were mostly related to applications insufficiently supporting IPv6, but the primary issue proved to be a lack of AAAA records that effectively disabled IPv6. Whilst there are workarounds such as NAT64 and DNS64, there remains a question mark over how these can support DNSSEC as we highlighted last week.

On a similar theme was the presentation on How to Make Trouble for Yourself – You Build an IPv6-Only Network in 2016 from Roger Jørgensen (nLogic). This was about the challenges of building a next generation network serving the Norwegian county of Troms which is situated in the Arctic and requires the deployment of IPv6 to ensure it can support future requirements for the next 25-30 years. Given the remoteness of the region it’s essential that Customer Premises Equipment (CPE) is reconfigurable and IPv6 manageable, but the first challenge was a lack of DHCPv6 support which meant static IPv6 addresses needed to be configured via an uploadable config file which allows the CPEs to then be registered with the Junos Space Management Platform which does fully support IPv6.

The IPv6 Working Group session was rounded off with the results of a survey about which open source code repositories were available via IPv6. As of the end of 2015 there were 25,522 ports located on 5,344 hosts in the FreeBSD ports collection. Of these, 3,925 hosts only had an IPv4 address whilst not one host only had an IPv6 address, meaning there were 1,419 hosts with both an IPv4 and IPv6 address although 359 of these did not have a resolvable DNS record. Just 10,308 ports could therefore be downloaded with IPv6, although if you add in dependencies then this rises to 17,715 ports (69.4% of the total) that cannot be built by an IPv6-only user.

It’s worth balancing this up though, with the presentation from Jen Linkova (Google) during the final plenary session about Google’s public DNS64 server that is currently in beta. More information is available at https://devsite.googleplex.com/speed/public-dns/docs/dns64

Over in the DNS Working Group there were several presentations related to DNSSEC. First up was Duane Wessels (Verisign) who summarised the changes to the Zone Signing Keys (ZSKs) for the root zone that is planned to change to 2,048 bits, followed by rollover of the Key Signing Key (KSK). This was followed by presentation on ZSK controlling from Paul Ebersman (Comcast), with the session rounded off with a panel discussion on the issues to address with the DNS. The DNS Manifesto summarises much of this, including the issues related to DNSSEC and the lack of data encryption.

Last, but not least we need to highlight a couple of appeals made during the Routing Working Group related to Deploy360 technologies. The first was on RPKI Validation from Alex Band (RIPE NCC) which summarised RPKI update in the RIPE region, as well provided a review of existing RPKI validation software including the RIPE NCC implementation. The RIPE NCC validator had been built somewhat as a proof of concept, but suffered from high CPU and memory usage with the growing data set, and did not leverage data from the Internet Routing Registry. They therefore wish to redesign this, and are asking for community feedback on the feature set.

The second appeal was made by Job Snijders (NTT) who asked network operators not to accept route announcements from external neighbours containing ‘bogon’ ASNs. NTT will adopt the policy of not accepting ASNs 23456, 64496-131071 and 4200000000-4294967295 from July 2016 as these numbers are variously reserved for private use, documentation/code examples or other reasons and should not be routed. They are normally seen due to misconfigurations or bugs, but can also be used maliciously and should be eliminated from the global routing table.

So that’s it from us for RIPE 72 which proved to be a week that broke all attendance records. All the presentations from the meeting can be found on the RIPE 72 website.

The next RIPE meeting will held on 24-28 October 2016 in Madrid, Spain. We look forward to seeing you then!


‹ 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