Introduction
The last Monday in October saw my alarm set for 02:45 in order to catch a 05:55 flight from Manchester Airport to head to Prague for RIPE 89.
There are a number of reasons I participate in RIPE meetings. First of all, the RIPE community sets the policies by which Jisc, and other service providers, allocate number resources such as IPv4 and IPv6 addresses and Autonomous System Numbers. Secondly, it contains a lot of useful content for network operators. Thirdly, it is a member-based organisation and there is a General Meeting at each of the twice-yearly meetings which votes on items such as board members and the fees we have to pay. Finally, I co-chair one of the working groups, RIPE NCC Services. My participation in the RIPE meetings dates back to the early 2000s, also having co-chaired the Routing Working Group before NCC Services, and being a Trusted Contact before the role was replaced with a Code of Conduct Team.
It is also a very useful forum for meeting our peers, and I had a couple of conversations with some of the CDNs that want to review our interconnection capacity.
Monday
The week generally starts with a day and a half of plenary talks, followed by a couple of days of parallel working group sessions, and rounding off with some more plenary time. Following the welcome talks, including one from the local host on the three layers of public holiday in the Czech Republic (that day being “level 3”), RIPE 89 was kicked off by Geoff Huston proposing that infrastructure security is an Internet market failure [video][pdf]. The basis for the argument was that DNSSEC has taken almost 30 years to get about 10% of domain names signed. Similarly, routing security has taken a long time to seriously think about securing the inter-domain BGP system — 54% of all advertised IPv4 address space is not covered by a ROA (Route Origin Authorisation). I’ll be coming back to ROAs in a future blog item. Geoff suggests that the security has moved up the stack to the application layer through TLS, and routing security is nearly obsolete if CDNs (Content Delivery Networks) are used to deliver content close to the consumers.
Geoff was followed by Fredy Kuenzler of Init7 [video][pdf] relating their battles with the Swiss telecom regulator(s) on delivering FTTH (Fibre to the Home) using dedicated fibre pairs rather than PON (Passive Optical Networking) which is more usual elsewhere, including in the UK. Spoiler alert: they won and PON based FTTH has to be withdrawn in Switzerland.
After a brief break for coffee, we had a talk from Richard Patterson of Sky [video][pdf] on how they are delivering IPv4 “as a service” on top of IPv6-only using MAP-T. If you want to find out some of the insides of how Sky’s network works in the UK, this is worth a review.
Following that there was a talk on network management and monitoring activities inside the IETF and a brace of lightning talks. All the presentations can be found on the meeting archives.
The day rounded off with the BCOP TF (Best Current Operational Practices Task Force) session. There were two items on the agenda here, the first being a talk on how information sharing has worked for Ukrainian network operators since their country was invaded, and the second a discussion on how best to document the consensus process within the RIPE community. Like most of the ‘bottom-up’ bodies in the Internet, agreements on policy developments and community decisions work on the basis of consensus rather than voting or unanimity. Consensus is often defined, following the IETF, as when objections have been answered rather than accommodated. It’s not entirely clear where this is going next, to me it feels like it might be an update to the RIPE Policy Development Process.
Tuesday
Rather than list all the talks, I will go through a few highlights. The first plenary of the day was dedicated to RACI talks. RACI stands for the RIPE Academic Co-Operation Initiative, and each meeting subsidises the registration fee, travel, and hotel for a number of students that have interesting talks to share. The idea is to give those students experience of interacting with network operators and bridge the gap between academia and real-life network operations. The first of these was Daniel Otten talking on ‘Green Segment Routing’ [video][pdf]. Networks are power-hungry devices, but increasingly you can save power by turning down linecards, ports, and even individual chips that might control a group of ports. This presentation talked about how you can most efficiently route over a network minimising its power consumption. Power consumption is of course something we’re looking at closely for Janet too as we seek to retire some of the large chassis-based routers and move towards denser form factors for 400GE aggregation.
There were a couple of presentations on post-quantum cryptography, firstly from a general sense on its impact on protocols such as SSL, and secondly more specifically on the affect it has on DNSSEC where you want hashing protocols to be quick and lightweight to reduce impact on DNS servers and response size.
One of the highlights for the day was Anna Wilson from HEAnet, our research and education colleagues in Ireland, talking about their automation journey [video][pdf]. They’ve presented on this before, such as at TNC, but Anna took a slightly different approach to this presentation, animating it in Blender. HEAnet have spent a lot of time and effort into their automation and orchestration work, and it is something we’re following closely.
In a bit of a contrast, Johann Schlamp then told us how he’d managed to implement the old text-based ‘Hunt the Wumpus‘ game purely in IPv6 ‘traceroute’ [video][pdf] as ‘Trace the Wumpus’.
Ioannis Arakas gave a depressing but unsurprising survey of the amount of Internet-facing EOL services there are running [video][pdf].
After another break for coffee, the working group sessions started. I went to ‘Security,’ recently renamed from ‘Anti-Abuse’, and which even longer ago was ‘Anti-Spam’ and once chaired by Rodney Tillotson of UKERNA. A couple of presentations of interest here, the first an analysis of DNS blocklists [video][pdf] — how often they are maintained and how much overlap there is between them. It turns out that some are far more actively maintained than others, but the overlap between them is low, and there is probably benefit in using more than one. A speaker at the microphone mentioned they’d also done a similar analysis, but on largely different blocklists, and come to the same conclusion.
The second was from beIN [video][pdf], who are asking what more the RIPE community and the RIPE NCC can be doing to make information more readily available to help them track down illegal streaming of live events.
In parallel to Security was the Measurement and Tools (MAT) session, which I’ve yet to catch up on.
Wednesday
Address Policy
The RIPE NCC, in its role as the Regional Internet Registry for Europe and the Middle East, allocates number resources in accordance with policies developed by its community, largely in the Address Policy working group. The meeting started by marking the sudden death of one of the co-chairs of the group, Erik Bais, very shortly after the previous RIPE meeting in May.
There was an update from the Number Resource Organisation Number Council (NRO NC) [video][pdf], which oversees global address policy development and advises ICANN (Internet Corporation for Assigned Names and Numbers). One of the current tasks of the NRO NC is to update ICP-2, the criteria for the establishment of new regional Internet registries. There are currently five regional Internet registries:
- RIPE NCC, serving Europe, the Middle East, and Central Asia
- ARIN, service North America and the Caribbean
- APNIC, serving Asia-Pacific
- LACNIC, serving Latin America
- AFRINIC, serving Africa
In these days when the RIRs have little role to play in the disbursement of unallocated IPv4 addresses, I struggle to see why a new RIR might ever be needed, but we’re starting to move into layers 8 and 9 of the 7-layer OSI stack. It might be worth noting here that all RIRs are not equal. The RIPE NCC probably offers the greatest breadth of services in addition to the registry, for example the RIPE Atlas network of global measurement probes. Meanwhile, AFRINIC is struggling to organise itself after having been subject to several lawsuits that have left it unable to elect board members or even select representatives to serve on the NRO NC.
Other items in the session were an update on policy development, and feedback from the registration services department of the RIPE NCC, which is responsible for implementing the policies that the community decides. Of potential interest to a R&E audience might be an update on the Open House session that the RIPE NCC held about ‘personal ASNs’. Autonomous System Numbers are the identifier networks use to represent themselves on the global Internet. Janet’s ASN is 786, and so within the global BGP table, routes we advertise to the world have the ASN 786 in them, either as the origin for our own routes, or within the path for our customers that have their own ASN. However, quite a lot of individuals also have ASNs and that’s seen as a useful way for either doing experiments on the Internet or developing the next generation of network engineers. The policies don’t differentiate between personal ASNs and others, but perhaps some consideration might be required in the future.
The second half of the session discussed the two active policy proposals in discussion at the moment. 2024-01, on provider-independent IPv6 [video][pdf], and 2024-02 on increasing the initial size of the IPv6 allocation to Local Internet Registries to a /28 [video][pdf].
Some of the feedback around 2024-01 was that it was ‘too much text.’
For 2024-02, the current allocation from the RIPE NCC to LIRs is a /32, which can be expanded up to a /29. Jisc has a /32 and we have not asked for it to be expanded to a /29 as yet. The revised policy would have the initial allocation as either a /32 or a /28, with nothing in-between. One of the major advantages of this would be that the allocation would always be on a ‘nibble’ (four bits) boundary, which makes DNS reverse delegation easier for a start. You might ask why we haven’t expanded our allocation from a /32 to a /29, and the simple answer for this is that we haven’t needed to, and there are a few reasons for that. Firstly, there is the uptake of IPv6, I’ll say no more on that. Secondly, as our customers tend to be large institutions rather than smaller organisations or individual households, they occasionally mention that the default assignment of a /48 (65,536 x /64 subnets, but often with some structure as part of the addressing plan) isn’t sufficient.
We have had experience of requesting a /44 assignment instead, but it tends to be onerous, and it is often simpler for a larger customer to just become an LIR in their own right and get their own /32 (or /29) for the same of the RIPE NCC membership fee. If this is a path you’re considering, please remember to either vote in the General Meetings on board members and charging schemes, or appoint a proxy you trust.
Remco van Mook, one of the board members of the RIPE NCC, then talked about simplifying some of the allocation statuses used in the RIPE database [video][pdf]. This probably deserves an article in its own right, if readers are interested in it.
RIPE NCC Services and the General Meeting
My turn on the stage! As co-chair of the RIPE NCC Services Working Group, it was my turn to kick off our session. The first order of business was to elect a new co-chair. RIPE NCC Services began in 2003, chaired by Kurtis Lindqvist, CEO of LINX as I type this, but soon to become CEO of ICANN. At its second meeting, in January 2004, Bijal Sanghani became co-chair. Kurtis and Bijal chaired the working group, with me joining a few years ago, until last autumn when Kurtis stepped down, and this meeting when Bijal stepped down, very much the ‘end of an era.’ Following the last two selection processes, I’m joined by Janos Zsako and Stefan Wahl.
There is often a large degree of overlap between the RIPE NCC Services Working Group, which is intended for the community to provide feedback to the RIPE NCC on its services, and the General Meeting, which follows the working group, but is the more formal body where members vote on the activity of the RIPE NCC and specifically provide feedback to the board. The working group is open to all, but the General Meeting is only open to members of the RIPE NCC.
The presentations in the working group were largely focused on the RIPE NCC’s planning for 2025, whilst the General Meeting had an update on what the executive board had been doing, the activity plan and budget for next year, a financial update, and a report from the charging scheme task force.
The Charging Scheme Task Force was started as a result of a lot of feedback over the RIPE NCC’s charging scheme, which is based around a fixed fee per member (historically it has been category-based, but that was changed some time back). It is important to note that the RIPE NCC, when there were IPv4 addresses to hand out, allocated them based on justified need. It does not, and did not, charge per-address. That means the distribution of addresses to members is uneven. National Research and Education Networks such as Jisc/Janet have reasonably large allocations of addresses, as do many of the ‘incumbent’ or at least long-established telcos. Newer service providers have little or no IPv4 addresses allocated to them by the RIPE NCC, but have to buy them on the open market yet still pay the same membership fee. Understandably this has led to a lot of discussion about whether category-based systems should be reintroduced, as well as the scope of what the RIPE NCC does. Jisc’s membership fee is currently less than €10,000 per year, but some of the other RIRs have fees that go up as high as $250,000 depending on the resources held. Some of the global organisations are known to do “RIR shopping,” transferring their resources, at least in part, to the least expensive RIR.
It is early days for the task force yet. They are hoping to have a report and proposal available for March 2025 in order to influence the charging scheme for 2026, but this may be challenging, and we have been told by the finance director that the existing charging scheme should be able to sustain the RIPE NCC for at least three years (2025, 2026 and 2027).
Thursday
Thursday consisted mainly of working groups, and I’m just going to focus on a couple of presentations here in the unlikely event you are still reading.
During the IPv6 session, Geoff Huston took to the stage again, at least virtually — Geoff is based in Canberra and had a bicycle accident recently so has been unable to travel to the meeting. This time the presentation was “Why is this IPv6 transition taking so long” [video][pdf]. You may be wondering the same after having heard myself or Tim Chown bang on about it at Networkshop since time immemorial. Geoff notes that according to APNIC’s measurements, IPv6 is still preferred only by ~36% of global endpoints after all this time, and notes that when this was first thought of, and the plan was to have IPv6 globally deployed before IPv4 ran out, the expensive bit of the Internet was the network itself. Carrying large amounts of data across long distances was expensive. These days, optical networks can carry hundred of terabits per second across a fibre pair, compute and storage costs have plummeted dramatically, and NATs pretty much work for most applications, so all the money is going into the apps on top of the network. This doesn’t leave any investment to deploy IPv6. There are 15-24 billion devices on the Internet, sharing the 4 billion IPv4 addresses.
IPv4 address prices have stabilised, so whilst you have to pay for them rather than getting them from an RIR or your ISP, the levelling of prices suggests there is currently no scarcity. Content Delivery Networks use names and the DNS to determine where to serve your content from, and in many cases, the content will either be embedded in your network on a cache, or at most one hop away to a peered CDN.
Steve Wallace from Internet2 (the US NREN) noted that NRENs are different as many end devices use public addresses and are still largely end-to-end, but I wonder if that’s true? More than a few of our members and customers are approaching us about trading in their IPv4 addresses, and I suspect very few eduroam deployments provide public addresses to devices.
Straying very definitely up the stack, one of the other sessions of the day was the Co-Operation Working Group. One of the larger topics here was a review of where we are 20 years on from WSIS, the World Summit on the Information Society. This is governed, if that is the right word, by the United Nations, and there are 11 ‘action lines’ aligned with the Sustainable Development Goals. I don’t pretend to be deeply embroiled in this, and wonder how much Internet development has come from the WSIS and how much would have happened anyway, but I’m sure that some of the work, especially on ‘connecting the unconnected’ has had an impact. One of the repeated questions was how we, as members of the technical community, can get involved. To be frank, the answer to this was still less than clear. One suggestion was getting involved in your local Internet Governance Forum (IGF). Ironically I note the UK IGF is happening today (as I write this, 5th November), but I only learned about it last night. Quite a few years ago, the RIPE NCC funded my attendance at a global IGF in Istanbul. I found it difficult to get to grips with, but perhaps I was not prepared for it then.
Another presentation in the session was from Jim Reid on the World Telecommunications Standards Assembly [video][pdf], which defines what the ITU-T does for the next four year Study Period. The two notable items from that presentation were an acknowledgement that the ITU does not have a role to play in IPv6 address allocation, something it has tried to do in the past and allocate addresses on national rather than topological grounds, and that the proposal for ‘New IP’ which was largely pushed by what is now termed a ‘High Risk Vendor’ in the UK, appears to have been dropped.
The final session of the day was the Community Plenary, and in that the selection process for the next RIPE Chair Team was kicked off. RIPE was chaired by Rob Blokzijl for many years, but when he was no longer able to fulfil the role, he handed over to Hans Petter Holen, with the instruction that one of Hans Petter’s main tasks was to come up with a system to select the RIPE Chair Team. The first run of the process started five years ago and selected Mirjam Kühne and Niall O’Reilly as Chair and Vice-Chair. This is the second run of the process, and candidates are eligible to stand for two five-year terms. It is driven by a Nominations Committee (NomCom), which I participated in the first time around.
In the evening the RIPE meeting dinner was held at the National Museum.
Friday
With the end firmly in sight, Friday started with a presentation about how using the BGP NO_EXPORT community whilst hijacking a route can mean that it is harder to detect the hijack, as detectors are usually in other networks. This should come as no surprise as that’s what NO_EXPORT is intended to do, but the ability to hijack traffic by sending more specific prefixes into Tier 1 providers with NO_EXPORT showed the potential to hijack a lot of traffic. Fundamentally this suggests the Tier 1 providers should be filtering their customers more carefully, but ways to detect those hijacks need to use alternative methods such as MRT dumps or iBGP sessions.
Also interesting was the tech report [video][pdf]. The RIPE NCC techies build a small network for each of these meetings to handle the participant WiFi, and the live video streaming. Where I’ve linked to the videos above, they were available within minutes of each of the sessions ending. For network techies, it is at least worth a look through the slides.
The meeting wrapped up with a welcome to RIPE 90 to be held in Lisbon next May, which fortunately will not clash with half-term this time around.