Main hall. 11.am.
RIPE 91
Main hall
24 October 2025
Closing Plenary
11 a.m.
BRIAN NISBET: Okay, hello. Welcome to the Closing Plenary session of RIPE 91. And before we kick off, I just want to announce the results of the PC elections.
Huge thanks to everyone who volunteered, it's a big thing to put yourself forward, and it really is appreciated and we need ‑‑ there will be more chances for those who were not successful or those who looked at it and went maybe I could do that.
Huge congratulations to Anka Hannig and Mat Parker for being elected to the PC. And I want to give equally huge thanks to Valerie Aurora and Franciska Lichtblau whose terms have ended and have been wonderful, as you would expect because they are wonderful people, for the last four meetings and they will be missed.
(Applause)
So, we are going to move on to the first talk, and Maynard is here.
MAYNARD KOCH: Hello everyone. Welcome to my talk about transparent DNS forwards and their misuse potential on DNS amplification attacks. I am a Ph.D. student, and this is joint work with these guys.
So, I assume that everyone has ever heard of DDOS attacks, so nowadays they are a common threat and often DNS is misused these attacks, so an attacker tries to craft some light way queries that create large responses and then flood the victim with unsolicited dance responses. So the OpenDNS infrastructure is often misused in these attacks, as these components with conserve as reflectors or amplifiers.
To run the distributed attack, the attacker, for example, if he has a access to a botnet, he can misuse open recursive resolvers and issue queries that are spoofed requests and they be the open recursive resolvers amplify the queries and flood the query with amplified DNS responses. But we consider botnets are costly, and we want to show that they are authoritative in the misuse. For example, open recursive forwarders. So forwarders are usually globally distributed and they enable distributed attacks without a botnet. So attacker could issue spoof DNS requests to the request forwarder. The recursive forwarders initiates a new connection to their configured recursive resolver. There is the amplification that comes into place, and of course, the IP address is the the address of the recursive forwarder so the recursive forwarders has to handle the amplified response and then sends back the amplified DNS responses to the victim.
So of course, there is no need for a botnet in that case but the recursive forwarder has to handle the amplified response and the problem here is that forwarders are often constrained devices, so the question is can an attacker be more efficient?
Yes, he can. That's where I want to introduce to you the transparent forwards. First of all they are misconfigured devices. They are not intentionally deployed but they are mostly vendors that have transparent forwards, they are mostly ship them without knowing that they are transparent forwards. So, an attacker could issue spoof DNS requests for the transparent forwarders much, what happens next is the transparent forwarder initiates a new connection, but they do not rewrite the source IP address. So that means they forward traffic that has a spoofed source IP address through the network, and the recursive resolver then allegedly receives the DNS requests from the DDOS target, so it just amplifies the DNS requests and floods the victim with DNS responses.
So, there is no need for a botnet. And there is also no need to handle the amplified responses. So, the question is what is the actual misuse potential in DDOS attacks and DNS amplification attacks when an attacker would use transparent forwarders? Because if the past, the little attention that is been made to transparent DNS forwarders and several monitoring campaigns that are well known, they still do not monitor transparent DNS forwarders, they only monitor open recursive resolvers and also recursive forwarders B no transparent forwarders. The problem is they provide an additional attack infrastructure. They are more than 30% of the OpenDNS infrastructure are actually transparent forwarders. So in total numbers, we measure about 540 thousand transparent forwarders in the wild per measurement, so that's not a total over time, that's just one measurement. And what you can see here is a world map of the global distribution of transparent forwarders per country, so we find them in about 175 countries, and most of them are actually active in Brazil and India, so there is a regional bias of course.
And apart from just providing additional tech infrastructure by their existence, they also enable access to what we call shielded resolvers, so these shielded resolvers should only be accessible from the internal network, so firewall route at the network borders they filter questions there. However, if there is a transparent forwarder in that network, you can just target the transparent forwarder and the transparent forwarder then relays the DNS request to that shielded resolver, and sometimes they are not properly configured, so, that means that they have no firewall route at the resolver because they just assume every traffic that receives these resolvers is legitimate because they are some firewall route at the network borders, so that means with transparent forwarders you can trigger remote responses from without the network where it should be possible.
So,s in our measurements, we find about 30 thousand shielded resolvers that are accessible through these transparent forwarding devices, and they are distributed in about 1.9 thousand autonomous systems.
But they not only provide an additional attack be infrastructure. They are also way more efficient in potential attacks.
So, we tried to fingerprint these transparent forwarding devices and we find about more than, way more than where micro take is the most prevalent device type. They range from constrained IP cameras up to powerful data centre routers, so, the majority of transparent forwarders, at least that we finger print are CPE devices. The question is can they be misused efficiently in DDOS attacks?
.
First of all, the niche thought was that of course, he they are way more efficient than recursive forwards because they do not need to handle the amplified response. To verify that we have set up a test using a microtech router, and we set them up as a transparent forwarder and we also set them up as a recursive forwarder to compare them how they both perform in an actual attack. We did this in a lab measurement setup, and what you see here is on the X axis the transmit traffic, which means this is the DNS queries we issued towards the router, and then on the Y axis, the attack traffic that is received by the victim after the amplification is resolved. What you can observe here is that the recursive forwarder quickly reaches its maximum attack rate, so the router already runs into resource limitations at about 1.5 M bits because it has to handle the amplified DNS response.
But the transparent forwarder reaches like six times more attack traffic at the victim because it does not need to handle the amplified response and therefore it does not run as quick into resource limitations as the recursive forwarding version does.
So transparent forwarders possess a serious threat on their own, but what happens then attacker starts to orchestrate them, to use them in service attacks.
That's where an attacker could try to avoid these local rate limits by orchestrating these transparent forwarders. So, to start with, we assume the attacker controls a single vantage point, no botnet. Without the botnet if the attacker tries to misuse Anycast DNS infrastructure, he only reaching a single point of presence of this Anycast infrastructure. For example, Anycast infrastructure of Google's quad 8. Then there are some local rate limits of course that prevent an effective amplification attack.
So, we also measure the rate limits at several locations for several public DNS providers, in this case Google resolver for example rate limit between 500 to 3,000 queries per second but that was dependent on the location where we measured and the time of the day, what was the actual load on these resolvers.
So, of course, an attacker can, if he has a botnet, control the botnet. Circumvent this local rate limits by just having a globally distributed botnet and attacking multiple instances of the Anycast infrastructure.
But we found during our measurements that more than 75 percent of the transparent forwarders actually relay their requests to Anycast infrastructures. Such as Google's AAAA, CloudFlare's quad 1, and for example also OpenDNS.
So, an attacker could just orchestrate these transparent forwarders to circumvent these local rate limits by just hitting multiple points of presence, instances of the public DNS providers. For example, Google. So the attacker could carefully select a set of transparent forwarders that hit multiple point of presence, and then the victim of course receives a flood of DNS responses. So, we try to verify that in the wild, by conducting some measurements, but we did not use any amplification here of course. We showed that you can reach an amplification factor easily of up to 14, because the rate limits vary, by orchestrating 10 transparent forwarders, which means of course we, due to ethical considerations we only issued lightweight DNS queries. So no amplification here, we only did it for ten transparent forwarders just as a proof of concept and we of course rate limited ‑‑ we limited the experiment time and so on so that no overloading of the network paths was happening.
So, what can you do against that?
As soon as we noticed the problem with the transparent forwarders, we started to contact network operators. And we actually succeeded by reducing the impact by responsible disclosure removed about 250,000 devices from the threat landscape, because a large European firewall configuration, as mentioned earlier, with the shielded resolvers, so they started to prevent access from other devices without being in their network, so that was, that is in first main key takeaway here. So, verify and update your firewall rules if necessary.
And of course, these transparent forwarders initiative a new connection to the resolver, because they just use a spoofed IP address there. So, that's a clear indicator that all networks, or most of the networks where we find transparent forwarders do not follow BGP 38, which means they do not Internet inagrees filtering. The solution is please use ingress filtering in your network, so that you can ensure that only traffic from allowed ranges passes through.
Mitigation is possible of course by strict rate limiting. So, of course local rate limiting of public DNS resolvers and also global rate limiting in case of the orchestrated nature of such an establishing, so, there should be monitoring, global monitoring strategy to detect such anomalies.
So, I know it's late, but it's time to wake up, I think. Here some statistics for the RIPE region.
These are the top ten ASes that host transparent forwarders. I find in 74 out of 76 countries of the RIPE region, I find at least one transparent forwarder. And in total, we see about 47 thousand transparent forwarders. And there are also some dense regions, so the top ones are located mostly in eastern Europe and in western Asia.
There is also, that's quite nice because in the attendee list, there are some ASes listed, so I checked all of them and I find that outside of RIPE 91 there are actually 32 ASes that host at least one transparent forwarder. What can you do now?
Of course, check if your network is affected, but how. We of course provide all our measurement results publicly, under odns.secnow.net. We also provide an access via API. Now it's time if you want, you can put out your laptop and copy and paste these API call, because we do weekly measurements, we update our open resolver list once a week, it's easy to integrate. You can add our API to your monitoring setup. The data is returned in JSON format. Of course we are open for feedback. What you can see here is temporary API key, so you can actually just copy PACE the query for now. It expires on Sunday. But we we have a nice edition to have a working API keep so you can test it out immediately. We require pagination, but it works smoothly for up to 100,000 entries per page, which should be enough for most of you.
And you can just replace the queried IP ASN value here with your AS number. You can also check for a complete list per country. There are many more features are, but of course yes, please, check your, if your network is affected. Why? Because transparent forwarders are misconfigured devices. They allow for significantly higher attack traffic, and they can be orchestrated to circumvent local rate limiting.
Of course they allow access to, or they allow to pie pass shielded resolvers, which is not good. And eliminating the impact of the transparent forwarders requires little changes. So my call for action here is: Please check your firewall rules and update if necessary. Implement network ingress filtering and check if your network devices are affected. So, use our API or reach out to us.
And if you want to know more about the details of the measurements or the methodology and so on, you can check out our ACMCCS paper.
And with that I would like to conclude my talk and thank you for your attention.
(Applause)
.
MASSIMILLIANO STUCCHI: Do we have any questions? I don't see anyone. Oh Will is coming.
WILL VAN GULIK: Just, it's not a question, it's a comment. I think there is ‑‑ I am Will, user of resolver and funny stuff like that.
Just, I think there is a document ASNs that can be used in documentation for the API thingy there. I think it was Anna signed, it's still RIPE region, please don't do that. Thank you. But rest of the doc really cool. Thank you very much.
MAYNARD KOCH: Thank you very much.
MASSIMILLIANO STUCCHI: I don't see any other questions, I didn't see any online. We still have a few minutes.
PETER HESSLER: Unfortunately the ISPs at home does do transparent DNS hijacking occasionally, and it ruins my day every time they do this. So, my call to action to the community is don't do that. Turn this off. You are hijacking and making everyone's life miserable when you hijack DNS requests. Allow them to go to the server.
TOM STRICKX: I am an operator of resolver. I can only speculate on what kind of the potential legitimate use of like a transparent forwarder is within these ISPs? Is it just oopsy whoopsy, fucky wucky configuration, or...?
MAYNARD KOCH: More or less. I think there is no such use case for transparent forwarders, maybe it's cheaper to just forward the queries, instead of having to resolve the query ending, the amplified response, so you just have a forwarding rule, put in your resolver and then give it a go. But, yeah, theres no actual use case for users or users of the ISP to host transparent forwarders.
TOM STRICKX: What you are saying is IP tables were a mistake?
MAYNARD KOCH: It depends. This case, maybe yes.
AUDIENCE SPEAKER: Andrei. I am an implementer of DNS resolver, but speaking from experience, people don't know what they are doing with their DNS. Like, there is a configs from the guy who left ten years ago, and I have seen compilation options where there has been no longer operational for 15 years and still being in the config. So, this does not surprise me at all because there is not enough knowledge out there for people running stuff. So, we are ‑‑ this community is like the exception. The rest of the world is like waving hands, screaming around and hoping that this stuff works. So, I'm not sure we can do anything about this because those people are just oblivious.
RUDIGER VOLK: Okay, we had a couple of sessions where know your customer was a request, actually the even more important thing is know what you are doing and in this case I think essentially the usual residential customer cannot really be blamed because my grandma is not supposed to figure out what's happening there, but the know what you are doing of course is a requirement that we should be imposing on the equipment vendors if they decide that they are, for whatever commercial reasons the implementation of transparent forwarding is to their benefit, they really should be required to do proper default configuration. Because that would essentially prevent grandma's net to operate bad.
MAYNARD KOCH: No network operator needs to do anything. Thank you for your comment.
AUDIENCE SPEAKER: Dave Phelan, APNIC. As the token Australian in the room I felt attacked by your graphics.
MASSIMILLIANO STUCCHI: I see no one else in the queue. So thank you very much.
(Applause)
Now the next talk. The she presented about this at the previous meeting, but she wants to give us an update on it.
VALERIE AURORA: Internet resilience club update. What we're doing for grass roots emergency preparation in the Amsterdam specifically.
A little bit about me. I work for this company, a systems software consultant about 25 years of experience, doing Linux, file systems and networking. I am the special rapporteur for the Cyber Resilience Act standards and operating systems and network interfaces. This was a huge mistake. Never do this. I am also the founder of Amsterdam Internet resiliency club, here is some under sea cable spices from the museum of communications in Lisbon.
Background:
The Internet and power disruptions are a concern. We all know why. That was amply proven this year. So, if you are concerned about losing both power and Internet, a measure network using low power radios could provide text communication during power and Internet outages. You can use that to get your power and Internet back, which would be really great.
.
So, the estimated date for the government in Amsterdam and the Netherlands as a whole is to get around to doing this is 2028. I think we might need it before that. What have if a bunch of Internet experts decided to buy low power radios and connect them with some kind of mesh network. We had our first meeting of the club in January 2025 and we managed to accomplish some things. We now have monthly in‑person meetings. We have almost 20 members, many of whom can definitely fix the Internet. Also a lot of hams. We have actually sent each other messages over our private meshtastic channel, it's 8 bits. So here is what we ‑‑ the conversation here in Bucharest. Wolfgang says, I couldn't attend the reception. Wolfgang says beer and food is okay, but nothing special. Little did he know how special that beer was. This is a common kind of communication ping pong ACK. Somebody forgot their node and I am going to add Wolfgang's sense cap card to my lightning talk if accepted so you have something to look forward to.
We managed to get Wag future lab to join forces with us. They have been wording on Meshtastic and Meshnetworking for quite some time in Amsterdam. Various members of Amsterdam, IRC, have applied for around €50,000 in grants. We have received 10,000 so far and there is 5,000 in progress. We had a reporter come and interview a best of your knowledge of us. When that comes out I am hoping a lot more of these clubs start up. We're now in touch with the city of Amsterdam and the Dutch defence ministry. Again they are like, well, we were thinking about 2028, but they are interested in supporting us.
How we got here. So this is where all of you I hope you are thinking about starting one of these is mostly networking human kind. Just know a lot of people. Talks were helping. RIPE 90 lightning talk, I did a talk at an open source conference near Eindhoven. Lots of direct personal invitations. So you just have to go out there and talk to people and say please come to the Internet resiliency club. In person meet ups, you have to use doodle. You can't be just hey folks, when do you think is good? Just try to keep is fun and pleasant. Nothing doom and gloom or competitive.
I made an actual web page with HTML, that's available ‑‑ I bought a mail has been mailing list, it's like €5 per month, it actually works great. We have a private Meshtastic channel. We have a signal group chat for organising and debugging, I am going to make the matrix fallback having learned signal dependency on AWS east 1. Posting on the fediverse. If you are look to go get people involved in decentralised mesh networking the fediverse is a great place to do it.
I had frankly decided which LORA node to buy, is the giant hurdle. This is the huge barrier that most people will not get over. So, I just bought a lot of nodes for people, and fully willing to just donate them. Almost everyone paid me anyway. I paid the bill at our in person meet ups, whatever is left at the end and I send a link to pay in the group, I usual make a bit of profit. So I recommend. But we need more cash money. Meshtastic in Amsterdam is fairly unreliable. But we weren't really sure why until a bunch of us went to the WHY hacker camp and It worked great there during their power outage. That was really fun. So, we feel pretty confident. We just need more nodes. A higher density of nodes in Amsterdam to make that work. We had the two grants in progress, they are to buy more nodes and give them away, also to do some work to improve the Meshtastic ecosystem. Basically the solution to all our Meshtastic problems is money. Money to pay people to do stuff.
I have some new hardware recommendations. The Wismesh repeater mini is an awesome solar power already to go cluster for €100. Tracker nodes in shape of these thick credit cards are good for everyday carry, so, ask Wolfgang Tremmel to show you his. I bought a T beam for a home station, it's really good. People are really attempted by the T Deck, but the keyboard breaks very easily. In general the hardware gets better every month. Things I wish I had done. I wish I had time to speak at NLNOG day, I wish I had understood how much European governments like giving grants. I didn't realise my local cinema was funded by grants. I wish I had asked for help organising sooner. And I wish I had picked a repeating monthly meet up date sooner.
Lessons learned. Running and Internet resiliency club requires about 1‑2 hours a week. About €200 of cash to start out with. A large personal network and frequent use of doodle.
In person meet ups are really chaotic, don't take it personally, sometimes there is a few people, sometimes you run out of chairs. Meshtastic is the worse software for mesh networks except for all the others.
You can start and Internet resiliency club too, it's worth it just to make friends. If you have a LoRA Meshtastic node. If you are willing to talk to other people. You might ask your employer to give LoRA things to your staff members. There is instructions and links here, thank you.
.
BRIAN NISBET: Thank you very much, we do have time for a couple of questions.
WOLFGANG TREMMEL: I am a Meshtastic user. Just a short remark, there are a number of communities around Europe using these devices, you don't have to travel to the Netherlands, for example in the state of Hessen in Germany, there is Hessen mesh, you might Google for that. In Germany there are other users and if your device doesn't work check what kind of back channel communication your local community uses and ask them for a configuration parameter. Some communities use a different than the standard configuration and if you use the standard configuration your device won't work.
VALERIE AURORA: I think that's a good point. We needed to do a lot of debugging over the group chat.
PETER HESSLER: In previous parts of my life I have been involved in disaster scenarios and assisting in disasters, I am curious how many of this work is dependent on LoRA itself and how much of it is portable to other possible communication methods like V ham or wi‑fi mesh networks etc.
VALERIE AURORA: The great thing about Meshtastic is low power and no licence needed and the, there is a web page that you can use to flash your device. So, it just lowers the barrier, and allows you to power it for much longer, then you want to have people who are ham radio experts involved to be a bridge. So, I think the technology is key.
AUDIENCE SPEAKER: Great effort. Just a quick check, you mentioned the grants. I am not sure which source it is, then you mentioned making a profit. I know you are not doing this for profit but it looks like... just to understand the devices of course are not that expensive about you may need more than one per person but do you estimate any other expenses.
VALERIE AURORA: I was joking about the profit, like €5. Could you summarise again the ‑‑
AUDIENCE SPEAKER: What's the other significant expenses of the hardware you foresee for this deployment?
VALERIE AURORA: It's pretty much just the hardware. You can get a a working setup with back up battery for €100. So...
AUDIENCE SPEAKER: Did you include the redundant power because I know in case of the war with Russia you probably would have that loss first.
VALERIE AURORA: The power bank yeah. I have a set up that's €100 for a power bank, a 15 watt solar panel and the super cheap hell check 3. The nicer thing is that stuff also powers your cell phone.
AUDIENCE SPEAKER: So, I am also doing some Internet resiliency work, but more in the Pacific focus. And one of the things we're focusing at the moment and you kind of touched it it on your slides but I don't know if you were looking into it as much, is looking at maybe what your service dependencies on things like outside of the Netherlands and stuff especially for emergencies so as you found signal is hosted over in the US and stuff, obviously in the Pacific there is a lot of places only one or two cables. But I never thought about signal being a cut out if submarine cables are lost. But especially because of the local infrastructure could still be okay, so I don't know if that's something to maybe consider.
VALERIE AURORA: So, we have a local matrix server that I have been meaning to set it up, again there is a giant barrier to using matrix so it's a fallback to a fallback. We're trying to get as many different ways to do it as possible. I have a domain name that's a .nl, so it's not resolving outside the country. We are working on that for all the failovers as well.
BRIAN NISBET: Okay. Thank you very much Valerie.
(Applause)
.
Okay, so.RIPE Atlas is pretty cool and you may have seen the cool visualisations and Stephen is going to tell us all about Khipu and what's going to be ought some about that.
STEPHEN SUESS: I am Stefan, I am the UX, UI visualisation guy for Atlas, to everything that's related to all that, that's me. And here, I want to talk to you today about Khipu which is our new visualisation primarily for traceroutes but also for DNS and ping.
.
So we had this idea a few months ago that it was really difficult to work with large measurements that contained many many hundreds and sometimes thousands of traceroutes, and to really have a visualisation which allowed you to compare and filter and look at things in a simple way. So was that the sort of impetus for creating anti‑spoofing. We have called it Khipu because it resembles the accounting systems that they would use in South America to keep track of things, it bears a visual resemblance to that. Use cases include detecting outages, troubleshooting latency, validating routing paths, checking DNS resolution or looking at the answers or responses, filtering IXPs and a lot more.
So, the key features of Khipu, like I said it works for traceroute primarily, this is really its primary use case. But it also works quite nicely for DNS, although it's a simpler visualisation, and for ping.
Within the traceroute views, we have several visualisation modes. The main one is the IP view, and there you see really detailed hop by hop analysis with individual IP addresses, and in the IP view, you have either hops or RTT distance mode. If you are looking at hops mode, really you get a sense of very quickly visually of which are the paths that have the greatest number of hops and if you switch to RTT view, you can really tell quickly, oh which is the one that has the greatest latency. I should say that in RTT distance mode, we also sometimes we have anomalies on various points where let's say the node has an RTT which is greater than the last hop at the target. So we note these and mark them on the visualisation so they are easy to identify.
Then, you could flip over to ASN view and really get a network level topology showing your AS pats and IXP interconnections. This is great for checking if your routing is working the way you think it is, if your paths are actually following the traceroutes are following the paths that you expect.
And then finally, there is a country view that shows a similar kind of visualisation but trying to mark the paths through various countries. It's currently derived from a combination of sanitary information, IXP information and IP locate cache, as you probably all know, IP location is an extremely difficult and complex thing to do. So, we don't guarantee that it's perfectly accurate, but we think it still has a use case and it's still useful for kind of just doing a quick sanity check.
We have two main allow out modes. The main one which is this radial view, and is the default, but we also have a horizontal view. I think you'll find that depending on the measurement type, the number of traceroutes, the complexity of it, that you might, one view or another might be better to use in a particular case.
There are a lot of interactive capabilities with Khipu, so realtime panning, zooming, node selection, it's all very high performance, it's very rapid and quick to us auto. It's responsive. We have various to go else depending on your view, so you have, if you toggle the successful toggle for instance, you could filter out all of the traceroutes that were successful, successfully made to their target and just see the ones that fail. So you can isolate the failures.
You could also toggle on or off the target, showing a little window for that. If you are looking at the traceroute visualisation, mostly the source nodes are all at the outside, and they are labelled with a little flag for their country, and for, and the IP address of those probes. But you can actually toggle that so it just those the probe ID instead of the IP address. Then you can also toggle labels in ASN view or IP view, or country view, to actually see the information around each intermediate note, hop along the way.
We have pretty nice hover pop‑ups where if you are hovering over a particular node, in particular let's say the source nodes which are the probes, you'll see a little pop up window like this which shows you your whole traceroute. If you click on the probe ID, it will take you to the SLAs probe detail page. If you click on the IP addresses it will take you to RIPEstat to give you the information about that. If you click on the ASNs it will take you to RIPEstat for information about those ASNs.
There is also a little copy button there, if you click on it you can just very quickly copy all the information in the particular pop up and paste it into an e‑mail or whatever communication.
Finally, it's quite useful that as you filtered all of these various things within Khipu to really get your view to the way you want it to be, all of the links can just be copy and pasted from the URL to someone else and they will see the filtering that you see. I should say the filtering itself, there is a pop down for country filtering, so you can collect the countries that you want to see and this will filter out probes that don't fall into those countries. You can also, there is a slider for RTT ranges, so you can say I only want to see the probes that are between let's say, they have a greater RTT than 50 or 100 or something.
And a little bit under the hood.
There is a lot of data enrichment going on. We are enriching the data with ASN information. IXP information, country information, reverse DNS look‑up, Anycast target identification, and we also support multiple targets. It's interesting that if you put in a measurement domain instead of an IP address, many of you know this, some don't, that when you make a measurement like that within Atlas, each probe will actually resolve the IP itself. So if you have a target let's say start at Apple dotcom and each probe will actually resolve that, and so, that might mean that you have many many targets for a particular measurement set, and in Khipu, you see can see multiple targets in the visualisation.
Quick overview of the technical foundation. It's built with view, the same framework as the rest of the SLAs front‑end. We have these pre‑built data cache which comes from RIS Whois, IXP information which we get from PeeringDB. ASN from country information which is all delegated stats from the RIRs. IP to country which is using IP locate database for kind of accurate country location. And these are all built once a week and it's about 15 megabits or so of compressed data so once a week Khipu will download that to your local storage and use that local cache to do its look‑up. So, instead of any particular visualisation taking thousands and thousands of API calls, everything is looked up locally which makes it responsive and quick.
D3, we're using for the data processes and the hierarchical layouts. And Web GL for high performance rendering, because it really enables a smoother interaction. I originally started building this with SBG and after about 100 traceroutes, it became unusable. So, changing it to Web GL really bumped it up and made it quite responsive so the combination of the caching and the Web GL really has quite high performance even for hundreds or thousands of nodes.
There are resources that you can look up. You can take a look at the docs. You can take a look at these Labs articles, the earlier one that's talking about the prototype goes through the sort of initial reasons for Khipu and how to use it. The docs are pretty in‑depth and then the Labs article was just released last week which gives you six use cases for Khipu.
This is supposed to be an animation playing, but it doesn't seem to, for some reason, so, if you would like a demo later, I'm happy to give demos and encourage you all to try it out and if you have any questions about or feet requests please contact us on the Atlas team. Thank you very much.
(Applause)
MASSIMILLIANO STUCCHI: We have time for one quick question.
PETER HESSLER: At a previous job I was running a global Anycast cluster and you mentioned you have multi‑target support, and that sort of thing would have been very, very interesting to me at that job. Does your tooling support the multi‑target for detecting Anycast DNS clusters for example?
STEPHEN SUESS: It doesn't do that. When I talk about multi‑targets it's where each probe is resolved to and we are taking those IPs that the individual probes are resolving to and putting multiple target points. I had a question similar to that earlier in the week, and it's something we need to look into.
PETER HESSLER: You can easily do a BIND a host name look up and match those together because that would be the encoding of the location so that when you say for the Anycast cluster in X location versus Y location and then make understandings based on that. Will that would be wonderful to see.
MASSIMILLIANO STUCCHI: Thank you very much, Stephen.
(Applause)
.
Now, the next talk.
ERIC VAN UDEN: Good morning to you all. I am really great that I may do my presentation for this audience.
Let's first of all start where we want to talk about. It's more or less speed, and speed and how to improve speed, because we have several times, if you look to what's happening in Europe, that we are delivering more and more speed, I had yesterday a chat with a guy from Swiss, I already have 25 gig at home. That's interesting, about you how to prove that you have those speeds. That becomes more and more a problem, because we can't use the hardware, if you look to the common user at home, they don't have a sophisticated hardware to prove those speeds because of bad wi‑fi, the cabling system might be not so great if you expect it and last but not least is the whole NIC, the network interface not really handle those speeds. So just to prove link speed we have to do something else, in this case get rid of the whole internal stuff.
Even local authorities are pushing their customers to do some tricky things on their networks, and so they can show yes, I can reach my promised for the Internet operator. So, if you look to the German, this is from Germany, it all related on a PC, so you run an AP on the PC and yes I reach my speed, this is fine when you have let's say 100 hundred meg, the average speed you see in a lot of parts of Germany, but if you compare this in other countries who run about 4 gig of speeds, you can't use those tools. They are far ‑‑ they can't reach all these. We have we have to do something else.
What solution? The solution is first of all,s we want to use UDP. We use you know for those tests in this case they are open broadband UDPST, you can build this easily. This runs a very simple method, it's not so complicated, it's a sender, it sends out meshes to the other side in this case, you can prove the upload and download and do all the measurements with jitter and what type of speed can reach and so on and so on.
So, from my point of view, maybe I am a little bit too optimistic, it's quite easy.
But again, then the OB‑UDPST has to run into the broadband form. The broadband form is running on standards, in this case we use the standard TR 471. That's more or less the broadband form name of the open broadband UDPST. Nowadays it's called Fritz, is a member of the broadband forum and we find this very important to run it, so we run this on our CPEs, the modern CPEs and again you are aware you are running a speed test so it depends on the the SOC you are using in your CPE. Older ones can have a problem running those test. From my point of view it's important because as I already said, more and more local governments are pushing their customers that they check the speed from their Internet provider.
In the past, we have some other methods to do this, it runs on TCP as you know for those types of tests, it's a little bit complicated because the performance is related to the SOC might be a really big problem. That's why the industry is moving more and more from TCP for running those test to the UDP standards. This is in a really first AI generated picture, I never did this, because I am not an AI, but I managed. In fact this is the whole picture. This is it. As I said not to complicate but from my point of view very important to do this. Most of the things already mentioned, so, in case of time, I will speed up a bit.
The last sentence from my point of view, one the most important ones, we are run our networks and we deliver our speeds to our private customers higher and higher and higher. 10 gig is not so unusable anymore. In Switzerland they run 25 gig and we had last week we discussed already the 50 gig, the 50 gig delivery to the end customers in the European market. This will be more relevant to show and to check okay, is it still the speed what I requested, is it still possible to reach those high speeds.
I see it's way too small to read it but it's just a few sentences, you have to plug it in in your USP controller, the USP controller can automatically do those tests. I hope you use USP and not DR 69, because this is legacy stuff, so please move to USP.
And this is what it brings. So it gives you a very clear overview, and this is just a line at my office, so don't be surprised about the speeds. But it promises and it shows you more or less everything you want, up, download, jitter and so on. So, last thing is go forward, use it, test it, and make it possible. Thank you.
(Applause)
.
BRIAN NISBET: Thank you very much. Do we have ‑‑ we do have questions.
TOM STRICKX: I am kind of wondering this is only validating speed within the ISP's network, right?
ERIC VAN UDEN: It is validating speed between the server, so in this occasion the content server, and where it's located, so most cases yes within the ISP. And the CPE. This path. As you probably all know, within the broadband thing we are running things and it was mentioned that we go to the end‑to‑end solution. But this is not covering the end‑to‑end solution, it's between the ISP network and the CPE.
TOM STRICKX: Thank you for that explanation.
BRIAN NISBET: Anything else? Okay, thank you.
(Applause)
.
So, this is the first ending of a number of endings today. That is the end of the submitted Plenary content, and we now move to the end of meeting reports. And first up I am going to ask Franziska to give the report from the Code of Conduct team please.
FRANZISKA LICHTBLAU: Hi everyone. So, as you are by now accustomed to I will give you our transparency report since RIPE 90. This is short so I will escape what is the Code of Conduct team. You can find all of this in a newcomers presentation and also in the opening.
Let's dive into it.
So, what have we been doing since RIPE 90 and what has roughly taken place?
Since RIPE 990, we received four different reports, but they related to two distinct incidents, so multiple instances of the same thing. Of the two things we could successfully conclude one report, we deemed it was indeed a violation of the Code of Conduct and we applied consequences. We tried to give you rough categories of what kind of incidents happened so that you have a feeling of what is going on in the community, but obviously due to confidentiality constraints, we can't divulge details. In this case there were instances on multiple mailing lists on very strongly insulting communication. And we decided that this warranted a ban for three months from the relevant mailing list from the Code of Conduct side. In the aftermath, in case you were confused, this was handed over to the Working Group Chairs in case they wanted to deal with this further in their respective lists and positions.
.
Since RIPE 91, we had one new report received via e‑mail. We formed an assessment group, team members who had a conflict of interest recused themselves and we contacted both parties. We asked for your understanding that for the case that is we are still evaluating, we can't give categories or details yet because that may or may not influence how we can handle this case and this is something we are very aware of.
Very, very dear to us, I know we report this every time. But you can report to us if you experience in whichever shape or form behaviour that makes you feel uncomfortable. You can just come and talk to us. I would very much like to highlight that if you are not sure if this is worth reporting, A) you can always report it and we will evaluate whether we deem it a Code of Conduct violation or not. You reporting to us does not automatically mean an outcome. This is our responsibility, not yours, and obviously you can always come, find us, talk to us off the record if you have any questions and want to know anything about what we are doing or maybe about your specific case or someone you know about.
In general, you can reach the whole team by the form, the reporting form that the linked on the respective meeting website and also on the RIPE website, you can reach us on the conduct report@ripe.net and of course individual team members are around, you can find our faces on the page of the Code of Conduct team, we have it all on our badges, and in the Opening Plenary and also in the newcomers presentation, we are presented, so you should be able to find at least one of us and then we can deal with it further.
Otherwise, we also have dedicated e‑mail addresses if you, for one or other reason, only want to contact individual team members.
If you want more details, the URL is there for you and it should have everything.
Other than report handling, what have we been up to since last time? We had two new members joining, which is great, because that gives us a more diverse perspectives, more opportunities for load sharing, so in case you are also interested, reach out to us and/or to the Chair team.
We had the RIPE Labs article published, I think many of you already saw this because we are doing a survey. On a serious note, we were slightly concerned that we don't get a good picture of what is actually happening. I mean, it's great, we don't receive that many reports, and either we are all angels here, or something else is not exactly going how it should be. But please go, fill this out, give us your honest feedback, because we want to know what we can improve for the process, what we may still need to learn because this is very much a learning journey. So far, we had more than 50 replies, which we actually considered reasonably good, so we close this end of October, and on top of that, we are working on a list of frequently asked questions that we can just compile based on our experience so people have a very low barrier way to understand a little bit better what we are doing.
And again, this is our team. These are my excellent colleagues, many of us already needed to leave, but you can still join us. So, reach out to the Chair team and to us.
Questions?
.
(Applause)
PETER HESSLER: Long time fan of the Code of Conduct team, and the activities you have been doing. Would I like to encourage the community to keep in mind that the Code of Conduct team is here to help you have a good time and to assist with us being professionals and enjoyment for everyone who attends here, so, anything that you are even unsure about, please go talk to the Code of Conduct team and bring it up to them, we want to hopefully end any whisperings and end whatever may have been happening.
MASSIMILLIANO STUCCHI: We don't have any other questions, so thank you very much.
Now the next presentation that we're all waiting for from Sjoerd, the technical report from the meeting.
SJOERD OOSTDIJCK: Hello everybody. My name is Sjoerd, unless you Dutch you can't pronounce it, usually people don't even try.
As you all know we have been here before so I thought I would give the technical report a little bit of a twist and show you some of the differences that we have been going through over the past ten years.
This is what it used to look like. As you can see, that's Menno there on the floor, it's not very clear on that one but I think he is wearing the same clothes. So, I don't know, he might have been time travelling, and as it was pointed out on the left, that's Colin, and on the right that's Marco, they look the same, but you can tell them apart from blue and orange, right. That's the only difference. We now need six people apparently, to install things. Who these other people are, they are just there. Actually, they were installing one the fibres. This was last Thursday, so it's a bit last minute, but fiber came online and it just worked.
This is the hallway. I mean spot the differences. I think that monitor in the wall is the same monitor, they just slapped a metal plate in front of it and called it a day. Main differences are the door is now closed, and there is chairs next to the little table. And there is a guy on a laptop. I don't know what this is. Somebody has been messing with my slides I guess. I suppose I won't mention it for fear of my own life. But some of these things have changed since the last ten years.
Terminal Room is no longer terminal, it's just a work space. We have been working with Meetecho, I actually don't know how long, but we used to do it our self on a Newtec tricaster. Airy high turned into ubiquites. A gig turned into 10 gig, it turns out we don't need it. And we're doing wide screen now, which is very advanced.
And we're doing IPv6‑mostly, which is mostly the work of Andrei, but we'll get to that in a sec as well.
So we already had two redundant fibres back there. Now we have a 10 gig and a 1 gig. So, I had to put my art work up here because it's just that good. So, traffic is more, not that much more, it went from 120 Mbit to 200, so, you know, all this Insta doomscrolling is not really making a dent. That's just assuming that the M in this MRT graph is actually M bits, but yeah, these are the access points. So the square access points are back, they were in the side room now. Next time, I hope to have some more. And it's actually a lot less work, so if you can look this map, we used to have 18 access points in this room alone. Today, we have eight, and next time it will be three. And we used to have 12 in the side room, and it will be two next time.
So, it's a heck of a lot less work for us.
Actually, associations on the wi‑fi have gone down for some reason. We were talking about it, it's gone from 1,000 to 7 hundred‑ish, I think it's Europeans not bothering to put their phones on the wi‑fi anymore because 5G is a thing and roaming is a thing, so, I like Europe because of that.
We had music again at the beginning of the week, until it drove people crazy and it also had some issues. The whole intent was for the web team to be able to tell when the session started because the Chairs would have to ask hey, can you turn off the music. But, yeah, like we had two songs in our play list, and we sort of stopped doing it after a while. Just to keep sanity.
The other thing is, I am sure we talked about this in the past, like I have a monitor here showing like notes and stuff. We also have an HDMI cable over here if you want to plug in your own laptop and that has been running on little boxes that do HDMI over cat 5 cable, not IP, just the cable, just the copper, and it gave us a massive headache this time around. I think there is interference going along the wall to the back corner there, but one of them worked fine but the other one just didn't. We redid the cable, nothing helped. So we tried the same box but it uses IP, and that ran into HDCP which is the bane of my existence which is high definition copy protection or something. It's a is piece of shit!
.
But, luckily, you can get splitters, HDMI splitters that remove HDCP, they are our friend, we have many of them. We have convinced many many other people to get the same ones. They are great.
.
Next thing is actually IPv6 network was taken into production on RIPE 71. It was requested at 66, but we didn't feel like doing it right then and there on the spot, because it was too experimental. On 67 we introduced the experimental SSID, and on 71, we called it production, and, you know, gave it to the world.
So, these graphs just look the same, they are actually completely unrelated, but since they look so similar it made sense to put them on the same slide. The top one is the legacy SSID today, which is like if you have trouble with your device because of reasons, yes, I see you nodding, you can go on there and your problems might go away. The bottom one was actually the NAT64 one at RIPE 71. So I think the tables are turned now finally ten years on. I mean it's taken a while, but it's getting there. Legacy is replacing what used to be 64.
Of course, we couldn't have done it without all of the good people doing all of the technical things. Meetecho team, the steno team and of course the tech team, they are all hiding in the corner over there. So, I'd like to ask you to give them a big round of applause.
(Applause)
BRIAN NISBET: Awesome stuff as always. Please.
JEN LINKOVA: Thank you very much. You said that the slides are not related. I actually think they are. You basically show first of all it took RIPE ten years to declare IPv4 legacy, right? It's actually the same graph.
BRIAN NISBET: Which is faster than most people.
NIALL O'REILLY: I have to put my hand up as one of the long tail of legacy users, but I am planning to upgrade my phone before Edinburgh.
SJOERD OOSTDIJCK: There are ten people on there or so, so that's a good chunk.
BRIAN NISBET: There is going to be somebody to stay on just to be the last.
AUDIENCE SPEAKER: I have a theory why your HDMI return doesn't work. Either one of the power supplies is malfunctioning or the sender and receiver are on the different phase power and this creates the blinking thing, it's not the cable.
SJOERD OOSTDIJCK: OK, we are trying ‑‑ we are going to get, because our audio guy had HDMI over fiber cables, which worked great. By no coincidence he is a reseller, so, you know, we might look into them.
JIM REID: I want to say thanks to you and your colleagues for all the amazing work you do to bring up this network. The network has been rock solid this week, as it is pretty pretty much every RIPE meeting, a huge amount of work goes on behind the scenes to make that reality. I am very, very grateful to you and your colleagues for making this happen so smoothly, you do a fantastic job, also because of the fact that infrastructure is so stable and reliable it makes the jobs of the others who happy and facilitate the other things, the Meetecho and the stenographers, they get an easier time of it as well. So thank you to everybody for this. We couldn't have these meetings without you, so thank you.
AUDIENCE SPEAKER: I should say congratulations and thank you to the team. Great job. And as you mentioned, there is a lot of progress but also many similarities, but the spike on Tuesday at the same time almost, have you investigated what was going on?
SJOERD OOSTDIJCK: No.
AUDIENCE SPEAKER: It is amazing. The profile of traffic is the same but the spike. If you could roll back to the slide ‑‑ it was a specific presentation the same, maybe update on the same thing? Anyway. Thank you.
TOM STRICKX: A massive fan of statistics. Can we get a public dashboard during the RIPE meeting that we can just kind of look at things and then you get people doing competition, we might actually get a full use of the 10 gig if you show people. You are only using 200 meg, please use more of it, the easiest way of doing that is showing us a Grafana dashboard.
SJOERD OOSTDIJCK: Those new access points are also on 2 and a half gig, so we'll have hopefully like 5 or so out there next meeting. If we coordinate things we might get the 10 gig.
TOM STRICKX: Excellent. Thank you.
PETER HESSLER: Very brief comment on that. So, I am wearing my hat from the CCC congress, we have a public dashboard, people do interesting things with our traffic graphs. So that would be dragons.
BRIAN NISBET: Anything online? No? Okay. Thank you very, very much and to all of the people involved.
(Applause)
Okay, now the Programme Committee are done. Do you want to say something so, thank you to everyone who submitted content for us this week, the call for papers submissions will be open relatively soon again, two weeks, and now we will hand back to Mirjam. Thank you.
MIRJAM KUHNE: Thank you. Thanks for running this last Plenary this morning, on Friday morning, a really interesting presentations.
We are almost at the end, just a few more announcements and thanking people.
This is just the statistics I showed you earlier on on Monday but these are the final numbers. We had 665 people checked in in the end, both on site and online, which is great. And I am always pleased to see so many, people from so many countries actually who presented here, 47 countries this time, and also a lot of newcomers. You heard a presentation here but I would like to thank the Code of Conduct team once more the important work that they are doing behind the scenes and they are available to you and please don't hesitate to go and report and don't go like maybe it's not so serious, just they know how to handle this.
The NRO NC elections were going on during this week, this is the result. Constanze Burger was elected again for another term on the numbers Council, so congratulations Constanze.
.
Of course, also, thanks for all the other candidates who were running and make this a proper election actually.
.
Some announcements on changes in the Working Groups. Also, there are some outgoing Working Group Chairs. William Toorop is leaving the DNS Working Group as a co‑chair, Willem are you here? Just a little sign of appreciation for your service as DNS co‑chair. I don't know where the gift is...
(Applause)
We also had Nico Schottelius from the IPv6 Working Group has stepped down from the v6 Working Group in between the meetings and has been replaced, we'll come to that, with somebody else, and hen Rob Evans in the NCC Working Group, his term ended, he is running again and he has been selected again in the NCC Services Working Group. As you can see here this picture hasn't change changed so the other two, so Ulrich has been selected in DNS to take over from William and then Wolfgang Tremmel has been added to the co‑chairs for the IPv6 Working Group and together with Raymond and Christian. So welcome to the team. They already participated this week also in the meeting that we usually have with the Working Group Chairs so they are kind of on boarded already.
This is the new kind of page with all the Working Group Chairs, you can find more information about each Working Group and their selection procedures as we have discussed yesterday on the website.
And a big thanks again to the RIPE 91 Programme Committee who put together the Plenary part of the meeting, so thanks for your great work during the week, and also ‑‑ I know there is a lot of work going on in the background to make sure people are showing up on time and make sure we have session Chairs in place and so forth, so, well done. Thank you all.
(Applause)
A special thanks to Franziska and Valerie, I believe you are both in the room. Could I ask you to come up and give you a little gift bag as well. They are stepping down from the PC as Brian has already announced, but I want to just put them ‑‑ give another thanks to them as well. So, thanks.
(Applause)
.
And these are the two new members on the PC, as Brian has already announced. We put a picture here so you know how to find them. They will start working with the rest of the team soon after we open the call for presentations for RIPE 92.
More thanks, I would like to thank not only the tech team but the entire RIPE NCC staff and especially the events team who are here, Kajal over there in the back, I wanted to thank you.
(Applause) She never wants to come up on stage, so...
.
Also the other events team members who are behind the registration desk and were helping out during the week and everyone else who was here in the background helping out.
And then last but not least I'd like to thank the host, InterLAN, do you want to come up.
(Applause)
Of course, we would also like to thank AWS for their sponsor, platinum sponsorship again, I don't know if anyone is here taking a plaque ‑‑ Clara is still here. Thanks for your long term support for the RIPE meeting, not only individually but also with your AWS hat on.
(Applause)
And of course thanks to all the other sponsors here as well that have supported us.
And last but not least, another reminder, please rate the talks, we heard yesterday some feedback and it is, we could make it a little easier to go into the system and rate the talks so we'll look into that, but in the meantime we'd still like you to give us your feedback and feedback in general, also the RIPE NCC has set up a survey and a feedback form that we would like you to fill in if you have anything to contribute, tell us if you liked it or if there is anything you could improve, we would like to hear you from on that.
And last but not least, this is the next RIPE meeting in Edinburgh, RIPE 92, and registration is open. The website is open. You can go in there, you can maybe become number 1 registrant of RIPE 92, no, it's already gone. Some people were fast. Great to see we already have three registrations. And so by that I would actually like to ask Linda to come up for who will be the host for our meeting in Edinburgh to give us a quick introduction and encourage you all to come to Edinburgh. So that's all from me. Thank you. Have a good trip home. See you next time.
(Applause)
.
LINDA SHANNON: Hi everyone. I am Linda Shannon from IPv6 Hillco IPv4 dot global we are invited to invite you to bonny Scotland for RIPE 92. Edinburgh has a long tradition of engineering from building the great bridges of the 19th century to the steam engine, to advancing the networks that connect us all today. It's a mix of rich history, innovation and a vibrant tech scene make it the perfect place to bring the community back together in May.
Just briefly about us, your next local hosts. HillCo Global is a diversified financial services company. We have over 800 employees operating across four continents,s including our Scottish office. I think many of you might be most familiar with our intellectual property and our IPv4 dot global practice areas. We operate a leading brockerage helping clients to navigate the transfer markets, and to lease addresses and raise capital against IP assets. We also provide world class IPAM and DDI software. With our recent acquisition and relaunch of Provision built by 6connect. We have sponsored RIPE meetings for many years. We sponsor other events in the community such as Net UK and Linx events in the UK, our European team has been out and about this week, and we have more than likely at some point give you a CIDR glass or poured you a drink at the whiskey BoF which we will have to make extra special in the home of scotch whiskey.
Edinburgh is a really beautiful city and a UNESCO world heritage site. It's really walkable and compact. In your spare time you could hike up Arthur's seat and inactive volcano right in the heart of the city with amazing views. Of course you could visit Edinburgh castle.
If you stay on, if you have got time, which I would really encourage you to do, it's so worth exploring other parts of Scotland. You could take a trip out west, to Glasgow where I am from, a city known for its architecture, its music scene and its friendly folk, you'll definitely make a new pal quickly. St Andrew's, the home of golf and the university town at the seaside is also not too far. On the west coast, Loch Lomond is lovely and could you head on up to scenic Glencoe and even the Isle of Sky or so much more.
.
So, how should you prepare. Kilts are obviously highly encouraged, traditional not to wear anything under them, but we might need to consult with the Code of Conduct team on that one.
Contrary to the stereotype, Edinburgh receives less rainfall than the rest of Scotland, maybe just bring your umbrella to be on the safe side, although we do hope for pleasant weather and long nights in May.
.
Please check if you need a visa, check that early, note that EU nationals and others might need to get an electronic travel authorisation, you do that online, it's usually pretty quick, at most three days. Edinburgh is very well connected. There is direct flights to very many parts of the serviced region. There is also a direct train up from London, it takes about four and a half hours, or you could try to walk 500 miles like the Proclaimers song goes.
I mean overall it's just a well really welcoming and inclusive and diverse country, and we really can't wait to extend famous Scottish hospitality and we'd love to see you in Scotland next year. So, yeah, any questions in the meantime please any recommendations that you'd lining, please don't hesitate to reach out to me or any member of our team and see you there. Cheers!
AUDIENCE SPEAKER: Ondrej, when are you joining EU again?
Jim Reid: Jim Reid, just in response to what Ondrej said. Some of us felt we never left the EU. One more thing, Linda, thanks for that very good introduction for the upcoming meeting, another few words of advice for everybody here, if in the unlikely event you have any difficulty at the border with the immigration people, just remember these six words: "That ball never crossed the line!"
MIRJAM KUHNE: No other questions or comments. Thanks Linda, looking forward to the meeting. That ends my show.
See you in Edinburgh!