The 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 https://ripe73.ripe.net/programme/meeting-plan/