‹ Back
Deploy360 26 May 2016

RIPE 72 – Highlights from Day 3

Kevin Meynell
By Kevin MeynellSenior Manager, Technical and Operational Engagement

RIPE 72The RIPE 72 meeting is happening this week in Copenhagen, Denmark, 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 are several interesting presentations to highlight. Most of the discussion in the Address Policy Working Group was about policies for managing the remaining IPv4 address blocks, which offers another indication that IPv4 addresses are reaching depletion and obtaining more is starting to attract significant cost. Network operators therefore really must have deployment of IPv6 at the forefront of their thinking.

The IPv6 Working Group was the focus of the day though, and once again featured a thought provoking presentation on Large Packets in IPv6 from Geoff Huston (APNIC). Packet fragmentation is allowed where a router cannot forward a packet due to a size mismatch, but this causes significant problems in the Internet and nearly 50% of fragmented IPv6 packets are lost. This then requires the entire packet to be re-sent, whilst fragments represent a security vulnerability as they are easily spoofed and also consume resources at the destination.

IPv6 capable links are supposed to offer a minimum MTU size of 1280 bytes, but this appears to encourage fragmentation, whilst increasing the MTU size encounters risks with MTU mismatch and the possibility that fragments are lost. Experiments undertaken with DNS queries over IPv6 clearly show this, and would appear to account for the number of unresolved IPv6 addresses that have been observed. This might suggest the need to revisit the deprecation of fragmentation support in IPv6.

We’ve mentioned this before, but John Jason Brzozowski (Comcast) provided an update on the Internet Draft draft-ietf-v6ops-unique-ipv6-prefix-per-host-00 which advocates the use of unique IPv6 prefixes for hosts. A community Wi-Fi service allows hosts to connect to a shared network providing Internet and/or other services, and in a typical network they’d acquire unique IPv6 addresses from a common IPv6 prefix through mechanisms such as SLAAC or DHCPv6. However, this can introduce some performance issues related to router and neighbour discovery, as well as security issues with numerous untrusted devices belonging to lots of different customers. By allowing allowing hosts to be assigned a unique IPv6 prefix (typically a /64), this would provide each subscriber with more flexibility to utilise IPv6, whilst ensuring traffic can be directed to a default wireless LAN gateway.

Another interesting issue was raised by Jen Linkova (Google) on using DNSSEC with IPv6-only networks. The problem on such networks is that the host does not have an IPv4 address to initiate a query to an IPv4-only DNS server, and whilst NAT64 can facilitate IPv6 to IPv4 communication, if DNS64 is needed to synthesise A records into AAAA records, then DNSSEC will fail. It is therefore important for DNS operators to ensure their servers support IPv6 and AAAA records, but that DNSSEC-aware and validating stub resolvers also to be DNS64 aware and able to discover the NAT64 prefix.

Following on from this, it’s worth checking out the RIPE Atlas measurement updates on IPv6 and DNSSEC-aware resolver deployments.

The Connect Working Group also had something of interest, with a presentation about RPKI Validation at IXPs from Daniel Kopp (DE-CIX). The aim was to promote acceptance and usage of cryptographic validation of IP prefixes in order to increase the security of the routing system by reducing prefix hijacking and route leaks. RPKI deployment was currently running at just over 8% of advertised address space, and was largely reflected at DE-CIX where 7.35% of prefixes could be validated which represented 12.78% of data volume. Conversely 0.75% of prefixes were found to be invalid.

There is an Internet Draft proposed by DE-CIX, AMS-IX, France IX and others to the IETF Secure Inter-Domain Routing (SIDR) Working Group that would allow RPKI validation results to be signalled from a route server to peers. This aim is to support legacy hardware and therefore encourage take-up by customers.

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

The full programme can be found at https://ripe72.ripe.net/programme/meeting-plan/

‹ 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