|
RIPE, or Réseaux IP Européens, is a collaborative forum open to all parties interested in wide area IP networks in Europe and beyond. The objective of RIPE is to ensure the administrative and technical coordination necessary to enable the operation of a pan-European IP network. RIPE has been a feature of the European Internet landscape for some twenty years now, and it continues to be a progressive and engaged forum. These days RIPE meets twice a year, and the most recent meeting was held at Lisbon, Portugal, from the 5th to the 9th of October 2009. In this column I’d like to share some of my impressions of this meeting.
The meeting uses a format of intertwined plenary sessions and more specialised working group meetings. The presentations, webcast recordings and the proceedings are all online so I will not dwell on the specifics here, but instead provide my perspective of the meeting.
IPv6 was clearly prominent on the plenary agenda and the focus was on various success stories rather than on blocking factors for IPv6 deployment. Three of the presentations at the start of the week, from an ISP, and exchange operator and a CPE equipment vendor, focussed on their deployment experience with IPv6, and their stories were extremely positive. The CPE equipment vendor reported on some outstanding questions about ISP operational practices, including whether the ISP deployment model will converge on dynamic or static assignment of IPv6 end-site prefixes to customers, what will end up as the commonly assigned prefix length for end sites, and whether or not IPv6 multicast streams will be part of the delivered IPv6 service. A presentation from a major European telco that looked at CPE and IPv4 NAT considerations and expressed a strong preference for the DS-Lite approach over Carrier Grade NATs (CGNs) in their networking plans.
A more detailed exploration of the issues of driving further expansion of ISP networks in the face of a depleted store of IPv4 addresses in a post-exhaustion world was not a major theme of the presentations at this meeting. Given that both IPv6 deployment and managing network growth in the face of IPv4 address exhaustion are now topics on the agenda of the near term future of all ISPs, it could be seen as a worrying signal that the industry still appears to be in a state of some uncertainty over the IPv4 port-exhaustion engineering story.
There was a very prominent promotion of a new initiative from the RIPE NCC, RIPE Labs. The work so far in this effort includes visualizations of allocation data in movies, some online tools to investigate the use of IP address prefixes, and the use of a shared space to allow community discussion. There is a distinct focus on community building in this program, and a strong sense that RIPE is attempting to rebuild the same strong sense of regional community that had been such a defining aspect of the early days of RIPE. The program is intended to include access to prototypes, research activities and facilitate open collaboration. I’d certainly suggest that anyone who is interested in this work should plug their address prefix into netsense and REX and let the RIPE folk what you think of the resultant reports via the RIPE Labs forums.
The other big news at this RIPE meeting was the presentation by Matt Larson of VeriSign and Joe Abley of ICANN about the plan for DNSSEC signing of the root. The joint presentation was apparently intended to provide an impression of solidarity between the DNSSEC zone operator, Verisign, and ICANN, but I was left wondering where was the IANA in all of this? The path chosen to sign the DNS root does not appear to go very far in allaying the concerns of those who believe that US Government agencies maintain an excessive level of potential influence over this somewhat critical element of Internet infrastructure. VeriSign is to perform the zone signing function and ICANN is to hold the Key Signing Key. The approach being used is interesting in that the next 9 months will see a progressive sequence of root name server anycast families deliver DNSSEC information bundled with the root response, where there is no public key that could be used to validate this additional signature data. In other words, there will be signatures over the DNS root data with what appears superficially to be an invalid key that is indistinguishable from a clumsy hijack attempt. The stated aim was to ensure that there are no early client dependencies on a signed root advance of the time when all the anycast families of root name servers are ready to deliver signed data. The current focus in DNS is now switching to the related issue of how to managed the issue of potentially large DNS responses, and the continuing saga of path MTU and UDP packet fragmentation, and the subtle distinction between IPv4 and IPv6 behaviours in this area. As someone pointed out, probably in jest, this is a sign of sure progress with the signing of the root of the DNS, in that before we were being told that the DNS root would be fully signed “six months from now”, and now the message is “nine months from now.”
The IPv6 Working Group had a presentation that reported on the recent IPv6 survey that was undertaken by both RIPE and APNIC in recent months. In one sense it was an excellent inter-regional myth buster in so far as the common myth that “they are far more advances than us” for some value of “they” and “advanced” appears to be pretty clearly not the case. The momentum for IPv6 deployment appears to be commensurate in both regions. The common theme that appears to be emerging at present is that lack of widespread deployment IPv6-capable CPE is a real issue in terms of mass deployment of IPv6.
The Address Policy Working Group held a discussion about AS number allocation policies, but without a clear conclusion. The discussion over what to do about the final IPv4 resource blocks was one characterised more by some level of confusion over intended effect than any strong common desire to create specific policy constraints. This experience parallels that in other address policy forums, where consideration of policies that attempt to ration or otherwise constrain folk in their use of addresses are always far harder than distribution policies in an environment of abundance.
The Routing Policy WG heard a report from Rüdiger Volk on a 2 day ISP operator workshop on approaches to improving routing security. The report noted a clear preference for the use of a certificate based infrastructure that allowed attestations about addresses and their use to be authenticated against a collection of issued certificates that are part of the current activity in resource certification. The report highlighted this model as a distinct step forward from the current framework of a diverse collection of routing registries and whois databases both in terms of data integrity but also in terms of the ability to integrate this data into operational support systems.
I also observed the RIPE community struggle with what guidance, if any, to give to the operator community over IPv6 minimum address sizes, and the discussion this week did not make progress. There was the concern that a position of complete silence about minimum routing prefix sizes would open up the floodgates of advertised /48s into BGP, and they are also aware that folk are already deaggregating /32 allocations into smaller fragments. The discussion was of the tenor of “we should say something” but to me there was no clear idea of what it is that they should say!
THE RIPE Database WG met and reviewed likely changes to their update path. They are concerned that a large overhang of un-used person and maintainer objects are going to need continual management, and are considering changes to make this easier, mainly around additional indexing to find unlinked maintainer/people objects, and some admission processes.
And of course RIPE meetings would not be RIPE meetings without the report from the Secret Working Group at the closing plenary session. I’d like to report on this working group’s activity, but I can’t. Its a secret!
Sponsored byCSC
Sponsored byWhoisXML API
Sponsored byVerisign
Sponsored byRadix
Sponsored byIPv4.Global
Sponsored byVerisign
Sponsored byDNIB.com