RIPE 92 Daily Meeting Blog

Choose RIPE. Choose A Job. Choose RPKI. Choose not putting <marquee> tags anywhere near your trust infrastructure. Choose tutorials, newcomer sessions, Plenary presentations, WGs, BoFs and the hallway track. Choose coffee strong enough to get you through the week. Choose Edinburgh, where RIPE 92 opened on Monday. And of course, choose to follow this Daily Meeting Blog, where we’ll do our best to report on what happened at this meeting and what mattered, and where no pun is too bad, no joke too lame, and no reference too obscura.

Friday: Infinite Monkeys

After an exciting evening of bagpipes and a ceilidh, we started the morning with an extra long coffee break before diving into the first (and penultimate) plenary of the day.

First, a presentation from Patrick Sattler, Technical University of Munich, about the current state of “happy eyeball” implementations; according to the measurements, the browsers show varying behaviour in this area. The presentation also included a demonstration of a self-service website where users can do their own tests.

Next, Dhruv Dhody, IAB Chair, and Warren Kumari, Google LLC, gave a quick overview of the IP geolocation workshop they organised in December 2025, including a general overview of challenges regarding IP geolocation. Then Ondřej Caletka, part of the RIPE NCC’s team working on the RIPE Meeting network, explained a curious case of ASPA validation working as intended in the field - yet affecting the reachability of the meeting network. This short presentation also resulted in a lively discussion about the underlying issue.

The time came for our final plenary session of RIPE 92. Ginevra Fabrizio, University of Twente, kicked it off with a dive into the complexities of quantum. Specifically, the talk covered transitioning from TLS to Post-Quantum Cryptography (PQC) in complicated scenarios like Federated Identity Architectures, with a quantitative analysis of the technical challenges involved in adopting the Hub’n’Spoke model in particular. Did you get all that? This writer did not, but Ginevra fortunately shared some clear conclusions: the current SAML standard is not strong enough, and quantum-ographers should instead consider more lattice-based schemes.

We then heard from Alexander Männel, TU Dresden, who shared how you can use Hilbert curves to visualise how much address space an ASN is announcing. These curves are particularly fit for this purpose as they maintain the locality of the data while mapping it into two-dimensional space. Alexander introduced the React framework Hilby, which renders interactive Hilbert curves for IPv4 and IPv6, and explained how to set it up for your data.

Next, Warren Kumari, Google LLC, explained bitsquatting and the infinite monkeys theorem (this is about how if you put them in a room, they’ll eventually produce the complete RIPE Document store, right?). Turns out bitsquatting is actually a form of cybersquatting that exploits hardware bit-flip errors during DNS requests, posing significant operational risks. Worryingly, these errors appear on average once every five days, so keep an eye out!

Andrew McConachie of the RIPE Code of Conduct Team gave an update from the team. There were no reports during RIPE 92, and the Team shared results from their 2025 survey, where we were happy to see most respondents reported feeling safe at RIPE Meetings. Next, Rob de Meester, RIPE NCC, took the stage to give the RIPE 92 Tech Report. Despite a few hiccups with shipping and Wi-Fi, the meeting went off well technically.

Last but certainly not least, RIPE Chair Mirjam Kühne closed the meeting by thanking all the different teams involved in delivering the RIPE Meeting. Then, the RIPE NCC’s Gergana Petrova, on behalf of host Bulgarian Internet eXchange (BIX), invited attendees to the next RIPE Meeting, RIPE 93, which will take place from 26-30 October in Sofia, Bulgaria. We hope to see you there!

Thursday: Don’t you forget about the WGs…

Day 4 brought another packed agenda, with IPv6 Cat GIFs, space-age addressing, and comments that may still be going as we speak.

The IPv6 cat is out of the box!

In the IPv6-WG, Ondřej Caletka (RIPE NCC) introduced us to the IPv6 Cat (with GIFs!!!). He pointed out that while we will have Linux on the Desktop by next year for the last 20 years, it might already be time for IPv6-only on desktop.

He then gave an historical overview on efforts to roll out IPv6-only on the RIPE Meeting network, explained how IPv6-mostly works, and gave some numbers: a whopping 85% of clients at RIPE 92 do not request IPv4 addresses anymore!

Next Wilhelm Boeddinghaus (CEO Route 128 GmbH) talked about the state of IPv6-mostly in enterprise networks and the state of IPv6-mostly on Windows 11. Support is currently in a private beta release and needs a bit more work. He then gave a comprehensive overview on how micro segmentation using a /64 per device and layer 3 switches solves a lot of security problems by removing the traditional flat layer 2 network. Every single device is in its own network segment and cannot talk to any neighbours. ACLs and policies are then implemented on the layer 3 switch. This makes zero trust designs easy.

Maynard Koch (TU Dresden) gave an update on their ongoing study of IPv6 routing loops and invited people to use their online checker. And then, the session wrapped up with a short presentation by Benedikt Stockebrand, who has found "The Killer App for IPv6": It lets us fix all problems we have with layer 2 networks by going for layer 3 switching by employing VxLAN, segment routing and micro segmentation. It also also lets us get rid of spanning tree protocols and use dynamic layer 3 routing protocols.

Database: Yes, Yes, Yes, Yes

After giving a brief update on the different NWI’s by freshly re-elected co-chair David Tatlisu, it was RIPE NCC’s Edward Shryane's turn to give a wide-ranging operational update covering security fixes, RDAP adoption, UTF-8 support, and ongoing database modernisation work. A major theme was improving security and usability: the RIPE Database has now fully phased out MD5 password authentication, introduced API key expiry warnings, and fixed a cross-site scripting vulnerability after collaboration with community member Sasha Romijn (also discussed in Monday's plenary session).

One notable milestone was the introduction of UTF-8 support in free-text attributes, allowing users across the RIPE region to use non-Latin scripts such as Cyrillic, Arabic, and Greek in the RIPE Database. Ed joked that emojis are "unfortunately not supported", but "it's for discussion" if there's strong demand from the community.

The session also sparked lively discussion about cleaning up the RIPE NONAUTH database. Job Snijders described removing duplicate or cryptographically validated objects as the “low hanging fruit”, while Stavros Konstantaras joked he would “be the first one to vote green” if the RIPE NCC ever proposed shutting it down entirely.

After this, Sasha Romijn presented progress on NRTMv4, the new IRR mirroring protocol designed to improve reliability, integrity checking, and automatic recovery for IRR mirroring. Explaining the limitations of the older NRTMv3 system, Sasha highlighted how the new approach adds cryptographic verification and better synchronisation handling, joking that with NRTMv3 “it doesn’t know what’s going on” when mirrors fail.

The session drew strong community interest, with a show of hands revealing many operators already running IRRd. Sasha described the collaborative development process, noting that implementing the protocol independently helped uncover flaws early: “I thought I had written one thing … and no, it was actually me who wrote something very different.”

In a shorter follow-up presentation, Sasha introduced new draft work aimed at improving RPSL set member resolution and reducing ambiguity in AS-SET expansions across IRRs. The proposals received enthusiastic support from the audience, with Stavros even responding simply: “Yes, yes, yes, yes to all of these questions.”

Address Policy 1: One small step for IP addressing

Leslie Nobile was appointed by consensus as the new Address Policy WG co-chair. Leslie shared that she first came to a RIPE Meeting back in 2001 and has spent her career in the registry world. Franziska Lichtblau also thanked Leo for his work with the WG, which was met with really warm applause from the room.

Hervé Clement then gave an ASO AC update, including the ongoing work to update ICP-2 into what is now being called the RIR Governance Document. Angela Dall’Ara followed with the policy update, running through open proposals in the RIPE region and beyond, and noting that a review of the PDP document is coming up.

Marco Schmidt gave the Registration Services update, where leasing once again took centre stage. NWI-21 has now been deployed, meaning around 33,000 entities have their company registration numbers published in the RIPE Database. Legacy outreach is also underway, though only a small share of contacted holders have replied so far. The more awkward question was how leased address space should be reflected in the database. The RIPE Database is not meant to document commercial relationships, but operators still need to know who to contact when things break at 3 a.m., which is usually when things choose to break.

Then Tony Li took the room to outer space. With the IETF TIPTOP WG looking at how to extend the Internet beyond Earth, the question was: who gives addresses to the Moon? Or Mars? Or the asteroid belt? The idea of one block for space was floated, possibly with one prefix per planet, which is the sort of sentence that makes policy work sound much cooler than it usually does. The room liked the ambition but immediately found the routing, governance, aggregation, IPv4, IPv6, IANA, NRO, RIR, geopolitical and “please don’t infect other planets with IPv4” problems. So, straightforward enough.

The general direction seemed to be that space addressing probably needs coordination at the IANA/NRO/global policy level, not just one RIR boldly going where no registry has gone before. Also, IPv4 in space did not get a warm reception. Some things should perhaps remain Earth’s problem.

Address Policy Part 2: Ghosts in the machine

The second part of the Address Policy WG had a nice "things come back to haunt you" theme going on.

Antonis Chariton from Cisco opened with the problem of reassigned ASNs that arrive with unwanted baggage: old RPKI ROAs left behind by previous holders. IRR cleanup exists, but RPKI cleanup is still missing a tidy ending. Ideas from the room included longer quarantine periods, monitoring ROAs that point at unassigned ASNs, and more proactive nudging of whoever left the mess behind. One remote comment on ROA maintenance and the risks of re-allocating identifiers came close to becoming its own lightning talk, which prompted the very sensible suggestion that questions and comments should ideally not be longer than the talk they follow.

Tobias Fiebig updated the room on Policy Proposal 2024-01, the revised IPv6 PI assignment policy. Version 2 is shorter and cleaner after Clara Wade apparently took a chainsaw to it, in the best possible way, making the proposal much more compact. It now seems ready to move toward impact analysis, though not before some familiar RIPE wordsmithing.

Finally, Clara Wade and Peter Hessler tested support for a future proposal where legacy resources would lose legacy status when transferred. Some people liked the idea; others saw legal traps, due-process dragons, and plenty of reasons to tread carefully. The mailing list awaits.

The WG also squeezed in a bit of AOB on whether people at the mic should state their name and affiliation. The feeling seemed to be that it is useful for context and transparency, but maybe not something to police too aggressively. Sometimes people speak for an employer, sometimes for themselves, and sometimes, at RIPE, the answer is inevitably: "it depends."

“If you’re in this room, you know what DNS is.”

In said room, DNS WG co-chair Moritz Müller opened the session and announced that Mark Feneral would be taking over as co-chair now that Moritz’s term has ended at RIPE 92. Fellow co-chairs Yevheniya and Ulrich thanked him for his work, while Moritz pointed attendees to the DNS mailing list, where a, erm, lively discussion about the co‑chair selection process is happening.

How many is many? Ondřej Surý kicked off the session by asking the important question: How many DNS queries does it take to resolve a single domain name?

The answer, it turns out, is: a fair few.

Walking through delegation types including in-domain, in-bailiwick and out-of-bailiwick, Ondřej showed how resolver query chains can quickly spiral when caches are cold. CNAME chains, PTR records and DNSSEC all also add complexity, and sometimes hundreds of queries.

Jim Reid, unaffiliated guy who just wandered off the street, (his affiliation, not ours!), made the good point that the presentation deserved a RIPE Document.

Next up, Elizabeth Boswell took us through some AS112 network black holes - who runs it? Where are they located? Do they effectively capture leaked queries as they’re supposed to? Elizabeth covered measurement results in answer to those questions. Spoiler: there seem to be 469 visible AS112 sites, run by 97 operators!

Lars-Johan Liman then introduced DNS TAPIR Policy Processor (POP), a new open source tool designed to give resolver operators better information for filtering and threat analysis.

Block the bad domain name xyzzy.evil.empire.tld!

Petr Špaček followed with a debunking session on NSEC3, explaining why its security benefits are often really overstated. Confident in the audience in the room, he skipped through some slides with a reminder that “if you’re in this room, you know what DNS is” [dear reader, I’m not sure his faith in the room should have extended to this Blog writer…].

Florian Obser wrapped it up with a quick RIPE NCC DNS update covering AuthDNS hosting, automation improvements, ISO27001 work and resilience measures for K-root and AuthDNS.

And because Florian kept things short - as is the RIPE NCC tradition when standing between attendees and lunch - there was enough time for a quick talk from Maynard Koch introducing an ISOC project focused on measuring DNS resilience.

IoT: Smart Homes, Wild Devices

The IoT Working Group session at RIPE 92 had a bit of everything: DNS misbehaviour, hostile traffic at scale, smart lamps gossiping behind your back, and more!

To start, Jim Mozley (Infoblox) put on his DNS hat to present a newly adopted IETF IoT OPS draft on DNS security and privacy guidelines for IoT devices. The work, building on research presented at RIPE 91, shows that around 40% of tested devices actively overrode the DNS resolvers assigned by network operators. A handful of devices behaved very badly indeed when it came to generating DNS transaction IDs. The message to manufacturers: "Please, please, please conform to the RFCs that are there!" The talk also explored encrypted DNS transport - DoT, DoH, and friends - and the trade-offs these introduce for constrained devices.

Robert Thomas from the Global Cyber Alliance followed with a candid tale of what it took to build ProxyPot, a global IoT honeypot platform. ProxyPot began life as a passive proxy sitting in front of real devices to assess attacker behaviour, but a 2022 deployment soon exposed the gap between lab conditions and the real Internet. Systems struggled under the volume and complexity of real-world traffic, forcing the team to rethink much of the platform. Lessons were learned, the entire stack was eventually rewritten, and the team went on to build a packet capture engine achieving around 99.7% capture success. He noted that sensors are crops, not houseplants - honeypot infrastructure should be automatically provisioned, easily replaced, and never dependent on continuous, hands-on maintenance.

François De Keersmaeker from UCLouvain - fresh from defending his PhD just three weeks ago (congratulations François!) - got into smart home communication patterns. Using examples like motion sensors triggering smart lamps, he showed how seemingly simple setups actually involve multiple linked network events between devices and cloud services. Francois' work extends MUD (Manufacturer Usage Description) models to better capture these interactions inside smart home environments.

Finally, Michael Richardson joined remotely to update attendees on the Device Identity Forum launched at RIPE 91 under the IoT Security Foundation. The group is trying to improve how the industry talks about device identity and cryptography, replacing confusing "public/private key" metaphors with more intuitive concepts built around seals, stamps and signatures. The forum is now producing white papers and shared visual "stencils" to help communicate trust and identity concepts more clearly across the IoT ecosystem.

Community: RIPE on RIPE!

The RIPE Chair team, Mirjam Kühne and Anna Wilson, started off by providing an update on their activities. They highlighted the new RIPE Fellowship Programme and thanked the coaches supporting RIPE Fellows, the mentors, and the first-ever community Meet & Greet team. They also opened two important discussions with the community: the first on bringing clarity and harmonisation to the various RIPE Working Group Chair selection processes, and the second on the pricing of RIPE Meetings. Both topics had the audience queueing for the mic with plenty to say.

From the community, the session moved on to two presentations on ICP-2. Andrei Robachevsky and Hervé Clément presented an update on the ongoing discussions around the RIR Governance Document. Questions were raised about whether ICANN should play such a prominent role in RIR governance, and there are clearly more discussions to be had here. Athina Fragkouli then gave us a 101 on EU Competition Law, explaining that “undertakings are prohibited from concluding anti-competitive agreements, either directly or in the form of decisions of associations of undertakings”. If this is likely to give you sleepless nights, don’t worry – RIRs are neither undertakings nor associations of undertakings, and they do not meet in smoke-filled rooms to conclude anti-competitive agreements. We leave those rooms to another Working Group that we do not name…

Robert Kisteleki brought up another sensitive topic: how should individuals who provide digital services manage their digital legacies for the future? If you run an email or Mastodon server for friends and family, consider following these discussions, which are likely to make their way into a BCOP document.

“Most communities fall apart because they start to take themselves too seriously.” This was Remco van Mook paraphrasing the first RIPE Chair, Rob Blokzijl. Luckily, RIPE has a Working Group that has taken on the important task of ensuring some sessions are “exactly as cringe as they should be”. He presented the results of a survey and offered to mentor those interested in ensuring the right levels of cringe continue to manifest at appropriate moments in the agenda. If you want directions to the smoke-filled back room, find Remco.

Timekeeping and mic etiquette were among the other topics discussed under AOB. Our speakers wear different hats, and finding the right title can be complicated. A first-time attendee in the room kindly stated the obvious – it helps to know who’s speaking and what their background is. Randy Bush (IIJ, Aarcus, RIPE NCC Executive Board) was a bit blunter, saying, “It’s just good manners.”

The session wrapped up a little late, despite RIPE Chair Mirjam Kühne’s attempts at enforcing German punctuality.

And now back to the stars, with the RIPE Dinner at Edinburgh’s Planetarium!

Wednesday: "The night drave on wi’ songs and clatter…"*

*Tam o' Shanter, Robert Burns

Fresh-faced and full of enthusiasm after a night of socialising at the Edinburgh Dome, we’re back for day three of RIPE 92!

Connect: Peers gonna peer!

Time to make a connect-ion (yep: same lame Wednesday morning gag every RIPE Meeting blog...)! Leo Vegoda (PeeringDB) took us down the happy path of the product committee process behind PeeringDB. What kind of information ought to go in there? Who'll use the info once it's there? These are the questions the committee grapples with. Leo and the team are also considering developing client access to their ticketing system - he asked the room whether this would be useful, and some of our attentive attendees were actually wide awake enough to answer and share feedback.

Next Guillaume Mazoyer stepped up to talk about Peering Manager - an open-source, vendor-agnostic tool that allows people to do all sorts of peering stuff, like managing BGP sessions, keeping track of peering autonomous systems, and so on. He asked what we want from a peering portal - lots of auto discovery (of mutual IXPs and facilities, possible and existing BGP sessions, etc.) is the answer - then went through some of the things that ought to matter for anyone in the audience who might want to make their own, like picking a proper peering portal API.

James Rice (Jump Networks Ltd) took us through a peering-LAN case study where a networking glitch that was supposed to fix itself just didn’t. Instead, thanks to an edge case in RFC 4861 neighbour discovery, it kept secretly broadcasting people’s Internet traffic to lots of other networks, making sensitive communications and even emergency call data visible for years. James asked the room: is this fine? And the audience replied: no! But this isn’t a new problem. Part of the issue here is that the knowledge of how to fix and avoid these mistakes gets lost over time. The point was echoed: we need to pass on old lessons learned as new generations come into the community.

Stefan Wahl (Route 128 GmbH) stepped up next to tell us how IXPs have evolved far beyond the simple "single peering LAN" model still assumed by PeeringDB and IX-F, and why the industry’s schemas are struggling to keep up with modern IXP operations.

And then over to Nina Bargisen (RouteViews) for a lightning talk about RouteViews - a much loved project out of the University of Oregon that lets you look at the BGP table from different places all over the world. Having collected BGP data year on year on year - chasing route peers at the edge of the Internet - there’s a huge demand on storage. So Nina went looking for a way to see what new information, and so what value, each peer brings. Running through some favourite favourites - she showed us the unique edges, unique paths, unique prefixes different peers bring. In short: the most valuable peers are often the busy peers who do lots of peering.

Open Source: The vibe code bird doesn't fly

Over in Routing WG, we had Barry O’Donovan (INEX) on how IXP Manager approaches web application security, what it learned from an independent ENISA-backed penetration test, and why regularly re-examining long-held security assumptions is essential for mature Internet infrastructure software.

The Nominet DNS Fund is aimed at addressing a problem: open source DNS software is often underfunded, which brings about security and resilience risks that can affect LOTS of Internet users. Amy O’Donnell (Nominet) talked us through what the fund has learned so far and some of the challenges of supporting essential Internet infrastructure. Dave Knight (Nominet) introduced successful funding applicants for 2025 - Quad9, Bind 9 Testbed, OpenSSL Library, Cascade, validns - who then got an opportunity to share their (very positive) experiences through the process. What stood out in particular was the focus on developer requirements and the need for funding of software maintenance.

Containerlab can be used for deploying networking topologies for testing, continuous integration and labs. Gordon Gidofalvy (Nokia) told us all about it, sharing some of the challenges that they face in the development of Containerlab and how they are successfully dealing with them.

Maria Matejka (BIRD | CZ.NIC) then talked about “How much of Bird is vibe-coded”. She asked the audience for a show of hands from people who had tried using an LLM, tried using it to generate C code, and tried using it for multi-threaded C code. The number of hands quickly dropped and the remaining two hands (Maria included) concluded that the results were not useful. So, we got the answer to the question in the title 5 minutes into the presentation. The longer version of the presentation ended with: "We do not vibe code bird - it doesn’t fly".

Robert Kisteleki (RIPE NCC) introduced a hobby project "Netiscope" written in Go that can be used for local network environment debugging and exploring. He declared he would not take questions as to why it was not written in Rust.

Routing: Getting a grasp of ASPA

Post-coffee, the Routing WG kicked off with the chair re-election procedure. If you are interested, join their mailing list for the most up to date announcements. The session started with Bart Bakker from the RIPE NCC explaining Delegated CAs and their revocation process. If you use publication as a service, the RIPE NCC is going to do the heavy lifting. The RIPE NCC RPKI team started to monitor delegated CAs. CCR is the new format that contains the validated state of the RPKI - compact format, great for archiving! There is a procedure of revoking CAs, this is still a manual process… Bart called for the community to help delegated CA operators to debug possible problems.

Discussion saw the usual suspects take to the mics, with Job Snijders pointing out that if your CA is revoked through this policy - you might get a slice of cake! Tom Strickx, Cloudflare, noted that tracking availability, latencies, and metrics would be a great addition.

And then we moved to ASPA (again?). Tim Bruijnzeels walked the audience through six months of ASPA developments in the RPKI dashboard: the strange case of AS0, dangerous valleys, and more. ASPA deployment is clearly gaining momentum, with a large number of ASPA objects appearing in the wild much faster than Tim had expected. He anticipated questions about validation, but there is still no public data available on ASPA validation yet - an interesting research topic that remains wide open. Tim also attracted quite a long queue afterwards; ASPA seems to be a hot topic!

A lot of things are happening with ASPA at the moment, and the early adopters need to be careful. But there are more ‘weird things’ in the RPKI. Job Snijders provided a detail report on his morning routine but also some things like RPKI data synchronisation, his new RPKI data collection project and what he discovered through it.

Cooperation: A hammer in the morning

The running theme of the session was resilience. We first heard from Eliza Rohotska (Attorneys Association “Axon”), about the impact of policy on Ukrainian Internet resilience. Eliza shared a metaphor that popped up in later talks as well: policy is like a hammer. When you use it well, you get a nail in the wall. When you use it wrong, you get a sore thumb.

In Ukraine, the resilience of the Internet has been heavily connected to its decentralisation, and after the war there was an increase in small entrepreneurs who were driven by a desire to provide connectivity for the people around them. However, recent government directives have put them in a bind - should they focus their limited resources on fixing shelled infrastructure or on meeting various resilience and reporting requirements. This, in addition to other factors like a change in the approach to taxes has unfortunately led to a reduction in small and medium enterprises (SMEs), which is increasing the fragility of the country’s Internet. Eliza encouraged a reversal of the trend through support for SMEs and protection of decentralisation, and greater understanding of how policy does not take reality into account can sometimes undermine its own goals.

An important side room side note: Eliza Rohotska (pictured above) and Solomiia Yaremenko won the RIPE Labs article competition for RIPE 92 with their article, Ukraine as a Laboratory of Internet Resilience. We are delighted to have Eliza here at the meeting with us to share this work with the good people of the Cooperation WG and the rest of the community!

Next, Martin Price and Edward Austin, Lancaster University, presented about shared points of failure between organisations that negatively impact resilience. The pair had been working on mapping the attack surface across organisations, and as an example actually mapped the attack surface of the entirety of the English government (what are you planning, guys?). This map showed both the amount of IP resource holdership and the vulnerabilties present. The intersection points of these two were the problem, as attackers could therefore use one exploit to target mulitple regions. Furthermore, the UK had a heavy reliance on AWS, another point of vulnerability.

Mike Blanche followed up on his talk at RIPE 91 about what might be in the Digital Networks Act, with the punchline about what was actually in it. He noted that the regulation broadened the scope of telecom regulation to also cover aspects of related organisations such as content and application providers, content delivery network operators and more. Mike noted that the definitions and specific scope were vague and said there was no market failure that justified this regulation.

And to end the session, the RIPE NCC’s Chief Community Officer, Hisham Ibrahim, gave an update on the organisation’s activities in the Internet governance space. He covered involvement in major processes like the IGF and WSIS+20 review, engagements with entities like the ITU, and country and government-specific interactions such as the RIPE NCC’s government roundtables. As the theme of the session showed, the tension between regulation and technical needs remains an important area to address, especially as technological development outpaces the rate of policy development.

Lastly, long-time chair Johan “Julf” Helsingius sadly announced that he would be stepping down after RIPE 92. We’ll miss you, Julf!

RIPE NCC Services

Over recent meetings there has been a little soul searching regarding the agenda for everyone’s favourite WG. Had we perhaps gotten a little too complacent and fallen too far into a sort of routine? Were regular status updates from the RIPE NCC failing to create a space for real and meaningful discussions about RIPE NCC services and activities? If so, then this session was probably a good step in the other direction, as it certainly gave the community (and the RIPE NCC!) a bit more to chew on than usual.

Hans Petter Holen, RIPE NCC Managing Director, was first up with a high-level overview of the RIPE NCC’s strategic focus areas for the period 2027-31. The current draft has been updated after feedback from RIPE 91 and further internal planning. We’ve also developed service-level strategies to guide our work which will help us to incorporate the strategy into yearly Activity Plans. The document is just about ready, and should be finalised once any input arising from this meeting has been incorporated.

Hans Petter then passed the mic to… Hans Petter, who explained that, in line with the abovementioned strategy, we will be putting much more emphasis on funning our own infrastructure moving forward. This means we need quite some reinvestment in CAPEX and a project to migrate to a brand new greenfield deployment. Hans Petter earned a round of applause when he said we might have gotten it wrong when it came to our cloud strategy. Though, in our defence, it must be noted that the state of the world has changed significantly since it was first developed. The long and short if it is that we believe that in an unstable and uncertain world, we need to be relying less on US-based hyper-scalers. This provoked a valiant pitch from one of said hyperscaler, to which Randy Bush replied that the US Cloud Act meant Uncle Sam has very long tentacles indeed, and so can do pretty much whatever he wants. Hans Petter pointed out that this is true of governments in general, which is precisely why we need to be thinking long and hard about what we are running and where.

Hisham was up next with an update on the operational review of ENUM under e164.arpa, which got some pretty strong views from the community about how this was handled and what the political implications might be. This humble scribe might just leave it there and back away, slowly. And to think all this started with one innocent question on the Database WG list about RDAP!

Gabor de Wit, RIPE NCC Chief Registry Officer, then took the stage asking if it was time for the community to start looking at three quite fundamental elements within the RIPE NCC’s administrative structure - namely how we approach multiple-LIRs, assigned PI resources, and legacy address space. This is all pretty complicated stuff developed over a very long period of time and after much discussion and debate. Running through each of this issues are themes of fairness, pressures to more efficient and reduce complexity, and ever-increasing due diligence obligations. Given all that, I reckon we need, what, like 15 minutes to get all that squared away? Let’s call it 20 to be on the safe side. Of course, this was just Gabor giving an intro and more likely, if changes are made, then they will be handled via a number of different discussions both on the community/policy and the membership/funding ends. Ideally, this will happen in some kind of coordinated fashion, and with greater awareness that actions taken in one sphere will affect outcomes in the other. TBC!

Tuesday: The Internet is running!

Day 2 of RIPE 92, over 600 people gathered for another day of interesting talks, serious discussions, and fun!

The morning plenary began with a laser show from Thomas Weible of Flexoptix. Presenting on future-proof DWDM network architecture, Thomas talked about transceivers - sharing how he and his colleagues balanced the receivers, squeezed more traffic through the fiber, and ended up doing rocket science. By deploying DIY superchannels and a flexible network architecture, he showed us how they managed to get all the way to the moon… and a little bit further.

Internet users want privacy. Privacy means invisibility. But addresses have to be seen to be routed. So what to do? Saleem Bhatti from the University of St Andrews presented an approach to packet-level addressing that provides enhanced protection against privacy attacks by guarding against passive traffic monitoring and flow correlation, among other things. The discussion with the audience got into how this approach would work with a firewall, or what the benefit of it is against other protocols.

The morning plenary finished with a talk from Fredrik Korsbäck of Meta – RIPE 92 silver sponsors joining us virtually this time. He laid out how Meta is evolving its backbone network architecture in response to huge demands, not least of which comes with the emergence of AI. An interesting look at what goes into scaling this infrastructure, such as the laying of kilometres of fiber pairs - the fundamental building blocks for their global network system.

Plenary: Collect your garbage!

In the next plenary, Antonios Chariton from Cisco took us on a journey toward obtaining an ASN with a peculiar history. What began as a simple learning exercise turned into a deeper investigation after they discovered the newly assigned ASN came with pre-existing ROAs authorising unrelated IPv4 prefixes, leading Charlton to joke that RIPE NCC was effectively handing out "free IPv4" with one in five new ASNs.

Antonios presented data showing that many newly assigned ASNs inherit stale ROAs from previous holders, prompting discussion about monitoring, stale objects and assignment policies. The talk raised a good discussion - if you’re interested in delving into the topic, join the Address Policy WG session on Thursday for a deep dive!

Petros Gigis from UCL presented OpenPenny, a new open-source tool designed to identify legitimate non-spoofed traffic with high accuracy, helping operators distinguish real routing anomalies from spoofed "background noise". He explained how spoofed traffic can create misleading ingress alerts and hide stealthy BGP hijacks, while OpenPenny uses probabilistic TCP packet drops to verify whether traffic is genuinely coming from the claimed source.

Petros was challenged by the Demo-Gods when he tried to give a live demo of his tool and his software hit "a new bug that I have never seen", prompting laughter from the room and Petros to joke: "If I tried to do it 1,000 times, it's not going to end up like this." Thankfully, he had a back up!

The last presentation of the session from Elisa Vennegues (Netflix) and Frederic Cuiller (Cisco) was about Netflix’s large-scale migration away from an iBGP full mesh architecture to a route reflector-based design supporting the company’s growing live and gaming services. The scale behind the project is quite big: Netflix operates more than 20,000 BGP sessions, peers with nearly 3,000 ASNs worldwide, and manages up to 50 million BGP paths in some regions. It was a great overview from both the vendor and the client, although the audience wondered whether they relied only on one vendor. Elisa explained that they have two control planes: one for backbone and the other related to customers.

Plenary: Full mesh!

The afternoon plenary covered a range of different topics from IPv6 in the DNS to security and privacy issues. DNS is ready for IPv6! In the afternoon, Tobias Fiebig from TU Wien shared the ongoing work in the IETF DNSOP working group on upgrading a 20-year-old standard to recommend dual-stack IPv4 and IPv6 for all DNS servers. Tobias shared the recommendations of the draft document and asked the audience to be ready for this.

Gerhard Stein from Flexoptix talked about understanding and optimising transceiver efficiency. Contrary to common assumption, the laser and thermal cooler are not the main culprits. Instead, DSP and modulation electronics dominate. The practical takeaway: shut unused ports in software to drop a coherent module from ~17W to ~1W, and favour newer-generation transceivers for meaningful efficiency gains.

James Stevenson from the University of Edinburgh talked about Childlight, a research centre dedicated to uncovering the scale, prevalence, and nature of global child sexual exploitation and abuse (CSEA). They called on the technical community to treat CSEA data as evidence for policy, platform design, and operational decision-making.

Petr Špaček from Internet Systems Consortium, raised the alarm on LLM-generated CVE spam overwhelming open source DNS and routing projects. Operators should brace for a faster patch cadence, as the same tooling could equally be used by adversaries to find genuine zero-days.

The plenary ended with Stephen Farrell from Trinity College Dublin, presented Encrypted Client Hello (ECH) that has now become an RFC and supported in OpenSSL.

MAT: What is DNS…?

Fast measurements already existed in the 19th century here in Edinburgh! Stephen Strowes, WG co-chair, explained how Edinburgh solved the issues of measuring one way latency and faster than light travel by firing a timegun and measuring the latency in the arrival of the sound in comparison to the assumed instantaneous propagation of the light of the flash.

Inspired by this, Geoff Huston (a well known DNS fan) then explained how - in the 18th century - it was established that the propagation of electricity through a wire was instantaneous by the simultaneous screams of presumably unwilling monks receiving a shock from a wire they were all attached to at varying distances. On a serious note, Geoff presented his work on measuring the use of IPv6 as the IP underlay for DNS queries and responses. The conclusion: Geoff was not impressed by DNS.

Continuing with a measurement on the other usual suspect (not RPKI yet, but IPv6/transport), Maynard Koch from TU Dresden presented his research on scanning IPv6 space using subnet-router anycast probing. Routers are required to respond to these addresses, which makes them ideal for scanning. One important lesson learnt - be mindful of routing loops - you may get more packets back than what you bargained for! And if you’re interested, tune in the IPv6 WG on Thursday for more details.

Back to the favourite topic of measurement folks - Routing! Job Snijders did the "mandatory" RPKI talk and demonstrated a novel standards based archiving tool for RPKI data. RPKIViews (yes, very original name) discovers and stores all the world's RPKI data that can be useful for the researchers and the Internet community in general. Shyam Krishna Khadka showed how DDoS scrubbing techniques can be detected by looking at BGP data.

Finally David Belson, from (formerly) Cloudflare, walked the audience through an ongoing Internet shutdown in Iran as seen by Cloudflare Radar since January this year. Some shifts in behaviour were curious, and likely caused by attempts to evade blockades (dnstt, sni-spoofing-rust). The world is quite shaky and turbulent at the moment and affects many of us in the RIPE community. It definitely makes one feel grateful for being able to attend such a great event as a RIPE meeting and make small connectivity issues some Android users experience in the room seem trivial.

Security: Botnets in your TV

Meanwhile, the Security WG had a very packed session as well. First up was Franca Bosompim from the RIPE NCC, who presented the Law Enforcement Authorities (LEA) transparency report for 2025. They discussed the requests received from LEAs as well as the capacity building activities the RIPE NCC carries out with them. Finally, Franca presented on the e-evidence package which is due to become Dutch law in 2027, which includes subscriber data held by the RIPE NCC. E-evidence requests must be kept confidential, and members will not be notified of an order, and may also affect how such requests are reported on.

The second presentation was from Leslie Daigle who reported on a round table from the previous day on residential proxies and infected infrastructure. They reported that proxy traffic significantly increased in late 2024, and that major AI companies are now the largest funders of the residential proxy market. Next steps from the workshop is to produce a report and develop a pilot with interested parties to mitigate the issue.

Next up was Lee Kent from beIN who presented on the Moving Parts of Copyright and Cybercrime. They provided a breakdown of different types of provided content, such as phishing attacks and malware, and surprisingly live TV streaming only accounted for 3% of this content. beIN wants legal clarity on the obligation of hosting providers to take down live content in real time. On top of the digital services act, the EU is looking at a number of options to mitigate these risks. Finally, Lee asked for collaboration and help across the ecosystem.

Next came Jérôme Meyer from Nokia, who presented on the €30 attack box: inside the Android TV botnet ecosystem. They explained that terabit scale attacks from millions of Android TV boxes has become a daily occurrence, and residential proxies are harder to disrupt than "conventional" DDoS botnets. They reported that blocking communication IP addresses and disruption at the network edge works, but there has to be the will to do it.

Finally, Szu-Chun Huang, TU Delft, presented an assessment of three different vulnerability scanning services. They found significant discrepancies between the three services, which raises concerns about the reliability of vulnerability reports.

The second day ended with an interesting discussion on Diversity in Tech , expertly moderated by Denesh Bhabuta. The talks focused on equity in the workplace. Denesh opened with a talk on handling toxic workplaces. In a nutshell:

Look after yourself and people around you; document interactions that feel uncomfortable and when you see someone in a difficult situation check in with them.

Henrik Haue Pedersen and Peter Madsen (Norlys) presented on how to create a safe environment for a person with a disability from the workplace experiences and needs, and a managerial perspectives. Rob Lister and Paul Ginsberg then followed up with a joint presentation about something most ADHDers suffer from - rejection sensitivity dysphoria.

If you’re filled with dread when your manager asks to have a small word - take a deep breath and know that you’re not alone! Rob and Paul have sound advice on how to manage these situations. And with that, your blogger also wanted to Break Free and go to a networking social, to enjoy Edinburgh’s hospitality!

Monday

Opening plenary

Mirjam Kühne, RIPE Chair, opened the meeting and welcomed us all to Edinburgh, noting that the last time the RIPE community came together in Auld Reekie was back in 1998, whereupon a new Anti-Spam WG was formed and somebody named Hans Petter Holen stepped up as chair of the LIR WG.

The Lord Provost of Edinburgh, Councillor Robert Aldridge, then followed to extend us all a warm welcome to this unique and historic city of Edinburgh. He urged us to try Scotland’s national drinks by way of a dilemma: Whiskey will tax your liver, while Irn Bru wll evntuly cost yu yur teeth.

Linda Shannon then welcomed us on behalf of IPv4.Global by Hilco Global, our fantastic local hosts who have helped us to make all of this possible. Hans Petter Holen, RIPE NCC Managing Director, ran through the usual meeting logistics and reminded members to register for Wednesday’s GM.

Sasha Romijn, Reliably Coded (IRRD, IRRexplorer, internet.nl), delivered an excellent opening presentation together with a few servings of humble pie when she shared her adventures in seeing how just far her favourite html tag <marquee> could take her on various websites and platforms. This turns out to be pretty far indeed! The RIPE NCC was also not immune, and she showed how this exploit could be used to gain access to the RPKI dashboard among other RIPE NCC platforms and tools. She also shared her experiences in reporting bugs to us and other affected companies, and dealing with the third-party companies who are tasked with assessing reports and awarding bounties. Overall, we might say this was ‘slightly less than optimal.’ A few lessons to learn here and a recurring pattern centred around low-sensitivity tools existing within the same trust scope as high-sensitivity tools. Eleonora Petridou, RIPE NCC, thanked Sasha for her excellent work and said we will be publishing more details here on RIPE Labs in response.

Maria Matejka, BIRD | CZ.NIC, presented on ASPA and why it still a draft technology. Her practical advice was to sign your ASPA records, cover all BGP sessions, and don't forget backup providers or failover traffic may appear invalid elsewhere. The good news: the spec is finally nearly done.

Afternoon session

The second plenary session was split between presentations on BGP and communities (communities in a strictly non-BGP sense, that is). The session opened with a presentation by Ebrima Jaw from University of Twente about noisy routers and patterns in route collector data. The volume of data (RIPE RIS, routeviews) is computationally challenging for most researchers, and Ebrima has been investigating what’s creating this volume. One idea could be that the volume of a route collector is determined by the number of peers. This feels logical, but in practice the BGP update volume per time period, per collector, is heavily skewed, and spikes in data volume come from a low number of peers. Overall, the volume of BGP messages is very unevenly distributed across BGP sessions, prefixes, and AS-paths. This impacts more than just datasets, it also affects routers and the stability of routes. In the end, the solution is to monitor for this issue and talk to the people operating the networks involved. In the Q&A, people called out that nothing gets fixed until someone complains loudly, and that the pain is not felt by the network creating the noise. This might be yet another collective action problem in BGP, where individual operators don’t have much of an incentive to fix the underlying issue.

In the second presentation, Fedor Vompe and Sebastian Becker explained how Deutsche Telekom applies route filtering at scale, and how the content of AS-sets matters. They view AS-sets as documentation – which is often incomplete, outdated, or inaccurate. Yet, they are one of the most important data sources to use to create route filters. They explained various problems in the data, with the most important being outdated or too-broad AS-sets. ASPA (the RPKI object which is still undergoing standardisation) will be another data source for this filtering. The Q&A line was split on the impact that ASPA will have. Will it improve data quality or will the benefits only be temporary and things degrade again over time?

The session ended with three lightning talks:

• Matthew Jepp introduced NetUK, a new non-profit NOG founded by LINX, LONAP, Nominet, and PTX. They’ve already held two events and seem to be off to a great start. Their next event, NetUK 3, will be held in London on 6-7 July 2026. In response to a question about how this would be governed, Matthew said this was still something of an open question. They had asked participants and for now the majority just wanted to see how it goes. Likely this will be discussed further at the upcoming meeting.
• Then back to BGP, with Remi Hendriks from University of Twente looking at anycast in under-served regions. There were cases where traffic for a user in Senegal - a former French colony, might be routed via Paris rather than Nigeria, because of limited terrestrial connectivity. Historical colonial structures played a part here. He observed that users in a former French colony could still be routed via Paris rather than a nearby PoP in a former British colony because Internet connections could mirror historical links. In the Q&A, people pointed out that issues of political control also affected the level of service in Africa, and that good people tend to move around a lot, which affected long-term maintenance.
• The final lighting talk by Niall O'Reilly, our former RIPE Vice-Chair, described how EU funding is probably more accessible to open source communities than you think. While the EU funding agency may have requirements that don’t suit your organisation (timeline, proposal overhead, budget), cascade funding allowed for an umbrella organisation to be funded which could then coordinate concrete work projects. Projects should have a “European dimension”, but this didn’t necessarily mean they had to be within an EU member state. Find Niall or his colleague Stephen Strowes at this meeting, or follow the links in his presentation, if you want to know more.

BoF: bridging IETF and RIPE - from standards to operations and back

The aim of the Monday BoF was about bridging the gap between the IETF and RIPE communities. Both share very similar ethos – no membership, participation as individuals, ideas judged on their technical merits, and so on. In many ways, the two communities are like different sides of the same coin - with the IETF focused on defining technical documents and protocols and the RIPE community deploying them (or not). Everyone seems to agree that both communities would benefit from more network operators participating within the IETF (and more of the IETF within RIPE), so what’s stopping us, exactly?

A few ideas that were floated:

More data is needed about the overlap between the communities and who is participating. A show of hands indicated that about a third of the room participate within the IETF, though somebody suggested the results could be a little skewed considering we were at an after-hours BoF discussing IETF participation(!). The number of hands also dropped precipitously when asked how many also identified as network operators. Not necessarily a bad thing, considering a wider group of stakeholders are interested in Internet matters these days. One idea could be to co-locate parts of IETF WG sessions within RIPE Meetings, or other venues, since ultimately it is about getting the right people together at the right time.

Barriers to entry on the IETF side can take many different forms. Smaller operators might struggle to justify their attendance, especially if even making it to RIPE Meetings can be difficult. There’s the time needed to follow so many mailing lists, and spending a lot of time shooting down bad ideas might not be such a drawcard for many.

It was noted that many IETF presentation submissions at RIPE Meetings were often the “high-level info-dump” variety, while those that tended to do well were often more specific presentations about how a specific topic within the IETF might be relevant to the audience. And indeed, much of this BoF had been such an info-dump, which meant there wasn’t quite as much time available to actually share ideas around addressing the core issue. All the same time, Jim Reid said the IETF was now doing a much better job at education and outreach. Even being at the RIPE Meeting and asking for feedback was positive and they should keep it up!

Thus ended day one, and attendees found their way to the welcome reception.