Closing Plenary
RIPE 88
24 May 2024
Closing Plenary
11 a.m.
BRIAN NISBET: Good morning folks. If I could ask you to take your seats or your conversations outside. Either is an option. You could also sit outside but you can't have a conversation in here.
So, I'm Brian and along with Max will be chairing this closing session of the Plenary.
.
So, just before question begin the main content of the Closing Plenary session, I just want to announce the results of the PC elections and thank you to everyone who volunteered and everybody who voted. We have two seats as always, and the two people who were elected are Max Stucchi and Kevin Meynell. So congratulations to both of them.
And I would like you all to put your hand together as well please for Wolfgang Tremmel who has done an amazing four years on the PC and a huge amount of work. So Kevin has big shoes to fill there.
(Applause)
And yes, just a reminder you can continue to rate the talks which doesn't form the PC of what the meeting liked and didn't like and help us continue to generate content for the future.
So, the main talk we have this morning, so Tobias, he is speaking for the first time this meeting, the second...?
.
Talking about revisiting BGP 194.
TOBIAS FIEBIG: So, good morning everyone. Guess who it is again. I'll be talking a bit about worms in the routing can. Because I think everyone likes here is a bit of routing.
The first: Imagine tranquil, perfect Internet. Everyone filters what goes in, everyone filters what goes out. All BGP speakers are secured. There are no route leaks. And first and foremost, there is only an address family to worry about, the correct one, and it is not 32 bits long.
I would enjoy that. Sadly, that my sunrise in the background sometimes appears to be a little bit more mushroom shaped. And, it's, sadly, slightly bigger than my thumb.
So, we need to do something about that. And that something is called BGP 194. So, BGP 194, RFC 7454: BGP operations and security has been published in February 2015. It has a lot of recommendations for securing external especially BGP, BGP speakers, BGP sessions, route import export filters, it very much tried to be a common ground, the best current practice without understanding the concept of your network, your rules. Overall it's a set of very reasonable relations, and honestly, everyone should mostly and with good measure and interpretation, follow these recommendations.
However, there is some minor little things that might, if read by the letter, not be as nice as we want them to be.
So, some of the nice worms in BGP 194. "Any IXP member should make sure it has a route for the IXP LAN prefix and that it announces the IXP LAN prefix to its downstreams."
.
.
"The easiest way to implement this is for the IXP itself to take care of the origination of its prefix and advertise it to all IXP members through a BGP peering."
.
This is interesting. As a side note by the way do you remember all TTL arguments about what makes a Tier 1, what is a Tier 1 and what is not? That's also resolved because BGP 194 also defines what a Tier 1 is.
Well, so, what are the practical implications of that? So, we could have our little bar IXP here, a member, and it's downstream, and if the IXP is announcing that prefix, it will propagate, we will see on the side of the downstream of the IXP member, a little route for the 2 IXP LAN prefixes, we will see the AS path containing the member, and before that route server of the IXP, and it's actually pretty simple. If the IXP doesn't want to do this, the IXP will not do this. Period!
.
Then, there is of course the option that the IXP is like, well, my peering LAN and the GRT are two things that do not want to live together. Then of course member AS 65536 could be like: Well, we could originate that, and the downstream will she those routes with an AS path ending in the member as the originating AS. And the implication of this is that most likely as soon as it hits the first route collector the IXP will probably have a discussion with that member been who originates what. Maybe involving some TAR and feathers, maybe purchase and pitch forks, depending on the flavour of IX NOG but it is basically something quite quickly resolved. More fun, imagine there is an RIR system this system has policies like restricting the assignment size for IXP LANs at least the initial one, to let's say, very hypothetically a /26, for IPv4.
Or, IXs are well not using a /48 for IPv6 but a shareholder 64. I never saw that that they just use a /64 for the peering LAN, right.
If we go back to the first case, the I originating these two, like a /26 and a /64, first of all the IX will not do that, hopefully. Second of all, AS 65536 would have to have somewhat broken filters to let this in in the first place.
So, kind of unlikely to happen.
And even worse, if the IX don't announce it and our little member feels inclined to do the origination themselves towards that cone, well, they will again have a small discussion, most likely they are not involving torches and pitch forks, or tar and feathers, but both, and best practice filters should catch this like it's a 26 and 64, it's more specific than 24 and a 48 so it should go away.
So, these worms aren't really an issue, right. It's like some things were reasonable back then. Operational practice shifted, that happens. Things change. We can just ignore these things. After you will you are supposed if you are like Regan RFC you are supposed to use your mind and like assess whether it makes sense. IX operators can always do and decide what they want to do. And the RFC is really creative interpretations, but you have to be a little bit oblivious about how Internet work routing works. And nobody would force it on anyone, right?
By for example putting something like that into a laws and regulations and forces people to do this. That would be pretty, pretty, pretty dense.
But, anyway, it still might be kind of nice to update BGP 194 to be up to date, what's going on in terms of technology. Just making them a lit bit more smooth, the forms.
And that's what I did. So, the draft IETF grow BGP upsec update ‑‑ 0 drafts a compendium of everything that's there. Lines terminology across all current draft because BGP 194 also used peer in various places meaning a peering relationship, a peering session, and well, not really distinguishing between whether it's about a BGP session and a peering relationship in the traditional sense. Just cleaning that up a bit and describe an ideal world, a best practice, doing everything right. And given that this community has been very, very vocal about it, yes, that version of the draft also included honouring GSHUT and not setting a higher local pref in the IXPs. That's the most requested feature in all of this. It turned out to be a small 55 page draft, and the brief answer to the question of what is in there was broadly yes.
I added a small visualisation of what I created in the lower right.
Generally, this was really well received. And anonymous IETF attendee commented, I read it last night, and I didn't hate it as much as I thought I would. Which I think is for IETF, that's pretty close to a compliment.
Well, let's take a little bit of a tangential route. There is laws and regulations. And there is something called the FCC, federal communications commission, it's from the small country in northern America between Mexico and Canada. And there is interesting documents like D A 18‑710, FCC, 2018. We therefore disagree with suggestions that testing should only occur within provider's own network because provider do not always control the portion of the network reaching the nearest designated IXP."
.
Well that might sound a bit odd as a statement but the background is that current discussions around measuring end user Internet access performance are revolving around putting test servers on the IXP fabric not connected with the router, on the IXP fabric. Meaning in the peering LAN. Meaning the peering LAN has to be kind of reachable from the so‑called IXP cone.
And that kind of ties in with policy making and policy makers, not really being made for ingesting long technical documents like we use them to well understand what we should do with our routers.
And also, long technical documents, by definition, are kind of not made to be timeless. We have to constantly adjust them to what has changed, changing operational practices, different requirements, new technology, I mean there is a lot going on in RPKI and ASPA. As pay is in RPKI. And those are all things that we would then have to add.
So, I came here to drink milk and to regulate the Internet and I am indeed all out of milk. So at the moment, the FCC is looking in regulating BGP security. The FCC seems to have taken a rather informed approach this time around, which is nice, they are talking to people who actually know what they're doing. There is one little tiny problem, though. If the cool kids here, being the FCC, have a fancy new toy, a regulation, European regulators usually want to have one too.
Here is the interesting question: Do you necessarily trust European regulators to always make technically well‑informed decisions?
Yes!
I would like to have some of your breakfast!
Anyway, something else that is kind of important in terms of regulation is who is being regulated? National security is a very big thing to regulate. Digital sovereignty. Well, things like computer security, critical infrastructure, communication services. Sound familiar?
ISPs and IXPs are basically all of the above. And policy makers do need guidelines to refer to. Because they are making policies. Well we also make policies but it's different kinds of policies. So, when is an entity that they are trying to regulate, when are they doing enough? When are they living up to the standards they are trying to set? What is the minimum you can expect from one of those entity you are regulating? And usually it's like, you know, could you at least please follow best practices, and I mean, I have seen customers who had like router configurations where it was like where is the rest? There is just an network statement, an ASN statement and that's about it.
So, what do we need? We need a BGP 194 that looks a bit more like this little car there. It should be short enough for policy makers to read, and actually find actionable. It should be in some way, shape or form, even if it's just by the form of well something fell on your feet and you broke it testable. So, you can say in a regulation like if this thing happens, then you didn't follow those best practices. Then you can test and assert.
And it should be somewhat timeless. And that means also being a little bit technology agnostic so. It does not start falling on our feet without needing constant maintenance, because if there is one thing you can be sure about with IT people is that content maintenance of something that should just work usually only happens when it fell on your feet.
So, that's what we're currently working on. And Nick Hilliard who is somewhere in this room, actually helped a lot in making that revision. It's a dash 02 version of this document which is brief. So, the previous version had 55 pages. This one has four. It's basically a make sure no funny packets get to your BGP speakers. Make sure nobody meddles with your BGP sessions. Do not import anything you shouldn't. Do not export anything you shouldn't. And do not meddle with things not meant for you. Like transitive attributes not related to you.
No specific technology techniques being mentioned. No extensive terminology definitions because we are all focused on being very, very simple. And due to being so broad and focused on like don't do anything stupid, it be be very authoritative in its language because it's very high level guidelines, it's hard to disagree with them.
Which also means that there is roughly 51 pages of things that got cut, right. There is all this extensive technical description terminology, that was basically left over from dash 01. The plan there is that we first create an informational available things and methods draft, which is just a list of things you can do to have more properly run network. If we make that an informational draft and not a best current practice, it's a lot easier to update. You don't need a stronger consensus for, well this is the stuff that's around, then you need for this is what everyone has to do.
It's not prescriptive or it doesn't have to be prescriptive. So, you don't have to say like hey, use the following form of algorithm approach to router filter. Instead of that, say like well if you want a route filter, you can do the following things which will have the following effects. No prescriptive portion.
And you then of course do not argue about like whether that should really be prescribed or not.
It's more like a repository not a policy. So, you could also attach a best before date. There is this RFC should be implemented before something something, 2026, otherwise please return to your local grocery store and get a new one.
And in addition, we want to create an informational terms currently in use draft. So that that is a little bit aligned to what the DNS people are doing. We currently have this DNS terminology draft ‑‑ actually it just made it into an RFC, that basically is a compendium of like all the terms you are using, when you are talking about DNS. And also Nick's idea was to go with something more living, so just being descriptive of what the community is using instead of being prescriptive of what the community should use. Again under acknowledging that this will need constant updates anyway, and that our language will shift and change depending on the BGP application and in all of this, I haven't even talked about data centre BGP.
So, what should you now take away?
.
Well, first of all, and that's not on the slide, you should implement sufficient route filtering if you can and if your vendor supports it, you should use BGP rolls, you should have RPKI in place, like for your routes, but also should validate what's coming in, you should have IR based filters, all the good stuff. However you should also provide feedback to the ongoing draft, and you should talk to policy makers when you get the chance, because even though they sometimes do not look like that, they usually do appreciate help that helps them contextualise technical documents and understand what's actually going on. So it's the Connect Working Group is just right there. I do have to confess, I wasn't at the Connect Working Group because I think it collided with Address Policy. But we need more of us in Connect. And something else to always remember: Technical documents might get unexpected audiences which might not have been that knowledgeable on how to not run with a knife.
And with that, I can assure all of you that it was a very last time for this event that you had to see a talk from me. And I am happy to take any questions.
(Applause)
MASSIMILLIANO STUCCHI: I don't see anyone going to the microphone. Oh, Rudiger.
RUDIGER VOLK: My ageing wet wear all, I think almost lost the most significant.comment that got to my mind.
The interesting thing here is, yes, I understand the issue of that we have to take care of audiences that did not show up around here, but what this feels now like ‑‑ well, okay, the IETF consensus should build documents essentially not addressing the operational community but the policy makers, and that's probably an interesting discussion for IAB and IESG and so on, and that would need to be understood. I'm not sure how the consensus will work on that.
TOBIAS FIEBIG: So, replying to that. I think we can make documents that do not fall on our feet, which is the core point here. So it is not about making a document that is catering towards policy makers. It is about picking up the responsibility, if we make a document that is labelled the best current practice, that we either have to constantly maintain it or we have to put a place holder route node there from which we branch to those technical documents.
RUDIGER VOLK: Kind of, if you do a document this way, you would have to put in a section that says: The full security considerations cannot be done here because all the technical, relevant details of current best practice have to be documented somewhere else.
TOBIAS FIEBIG: I used a slightly different formulation. I think I wrote in the document something along the lines of for how to actually technically implement and accomplish the goals outlined in this document. Please refer to the current informational drafts, or any other version thereof.
AUDIENCE SPEAKER: Will, from co‑Chair of Connect. Thank you for doing that. I think it's a really good point having something simpler for some of our audience, and that will be really helpful to go and advertise to some other people, and I will suggest that whenever we are participating in NOGs we should raise that and say there is a simple thing that we can go and present there so people can be a bit more and informed in an easy way and that's really, really really helpful. So thank you very much for that.
TOBIAS FIEBIG: Thank you, and also to follow‑up on the technical part of policy. We also have to keep in mind that if we write documents like that, we will be read, and used by junior engineers coming into the community and I think we all know how it went with getting rid of classful inter‑domain routing. So we need something that is a little bit more high level so we don't have those remnants we drag around with us.
AUDIENCE SPEAKER: Hi. Robert Carolina. Thank you very much for the presentation. As with anything technologically focused I always like, many lawyers, struggle to keep up with some of the more technical details. However, your citation of the rule making by the US federal communications commission naturally attracted my attention, and so, while you were delivering the second half of your talk, I took a look at their 38‑page rule making document, which I wasn't able to read completely. But what I found interesting in just scanning that ‑‑
TOBIAS FIEBIG: Which of the two?
AUDIENCE SPEAKER: The DA 1870. The one adopted in 2018. What I found ‑‑ part of what I found interesting about that is that in that circumstance the FCC was adopting a rule defining testing parameters specifically in the context of evaluating network operators who were claiming the benefit of public funds. You know, universal service funds. So they were adopting a rule specifically so that they could measure success of people who were claiming the benefit of public resources, not more generally than that. But the other thing that I found interesting about it is that they were constantly making reference to the desires for operators to use technical standards adopted by the technical standards community. So there seemed to be a theme running throughout that document encouraging the adoption of further technical standards and encouraging operators to follow those. So I think in that case I think you are seeing a regulator asking for more engagement and asking for more standards.
TOBIAS FIEBIG: Yes, and I will work with what they have so we need to give them something useful will. And another point, while that document indeed is more around like use of public funds to further develop network infrastructure, current efforts also in the direction of the OECD look more in for example how can you comparatively success the quality of end user access among OECD countries which I personally believe cannot be done with a one‑off measure because what is good Internet will differ per economy.
MASSIMILLIANO STUCCHI: We have run out of time. I don't see any other questions. I didn't see anything online a moment ago. So, thank you.
(Applause)
.
We will have the report from the Code of Conduct team.
SEBASTIAN BECKER: Hello and welcome to the RIPE Code of Conduct report for the RIPE 88.
I would like to give an update from the last, from the last RIPE meeting. At the last RIPE meeting we had two open cases, both cases we basically took the following actions:
.
We formed an assessment group. We talked to the reporting parties. Team members were recused if there was a conflict of interest. And we discussed the report with the reporting parties. And we took further actions where necessary. We cannot be really more specific about that. Also about the details, because you see we do not receive a lot of these reports revealing some more intel basically means we might reveal the information about either of the reporting party or the recorded party, reported party. And as these reports are confidential, this should not happen.
After the RIPE 87, we received two new reports, one of them is ongoing, the other one is passed to the responsible party of that to follow up.
We also published a RIPE Labs article. You'll find that under that link, so please read it so you have an idea how the whole process is working.
A last minute update: We received three reports in this meeting. Two reports came in via e‑mail, and one in person. Also here, we found the assessment groups for that. Teams members are recused when a conflict of interest occurred, and we are in contact with the reporting party. One incident of that didn't, did not involve a RIPE Code of Conduct violation. The two other incidents are being currently assessed.
How to report:
So, if there is something you want to report, you have the options to contact the whole team by a form that is published, or that is available on the RIPE website. The link is in that document. You can also write a mail to conduct report [at] ripe [dot] net. Or, you can approach us directly, either on site or via e‑mail if you do not want to write to the whole group but especially to one person out of the Code of Conduct team.
For more information please also have a look at the link.
.
Currently, the RIPE Code of Conduct team is a group of the following people you see here. We are happy to have more members for that. So please join us. You will also find the information about that on the website.
And that's it. Any questions on that?
.
(Applause)
BRIAN NISBET: Thank you very much. And we have a question.
AUDIENCE SPEAKER: I have a question. You mentioned ‑‑ my name is Malcolm Hutty. You mentioned that following reports you had discussions with the reporting parties. You made no mention of having discussions with the person who was complained about. Did you have any such discussions?
SEBASTIAN BECKER: Yes.
BRIAN NISBET: Okay.
AUDIENCE SPEAKER: Peter Hessler. In your discussion about RIPE 87 you mentioned that there was two that were received on site. But you didn't mention whether they were resolved or ongoing. Could you just clarify what the status of those reports.
SEBASTIAN BECKER: That's right. Again, we treat these reports confidential, so, if there is something that can be reported for the whole community, we would do that. If basically this is something could be solved within the reporting party and the reported party, we see that case has closed and do not follow up any more on that because there are different options, like it was just a misunderstanding for instance, so, it was resolved between the two parties.
PETER HESSLER: Of course I don't want details. I am a little confused because you said for the reports for after RIPE 87 one was closed and one is ongoing, if I remember correctly, but you didn't say whether the reports were during RIPE 87 if they were closed or ongoing, etc.
BRIAN NISBET: There were two open cases there. So those two open cases.
SEBASTIAN BECKER: I'm not a hundred percent sure if I remember correctly. At least I think both of them were solved.
PETER HESSLER: Okay. Thank you.
AUDIENCE SPEAKER: Hi. Tina Morris, AWS. I totally respect the need for confidentiality here, especially so close to the events where, you know, people may put pieces together. But in an aggregated form it might be very interesting a generalised categories of the types of incidents you are receiving, maybe annually or maybe even a longer duration than that so it can't be tied to the types. But I think that would be helpful for the community to understand where our challenges are.
SEBASTIAN BECKER: Yes. I mentioned that also last time in Rome already. Currently we are not able to do that because it will be too close, too specific at that point, but if we can do that, we will do.
AUDIENCE SPEAKER: Very generalised category.
SEBASTIAN BECKER: Right.
AUDIENCE SPEAKER: Martin Winter: I would love on your closing report a comparisons over the time if it gets worse or better or something or about staying the same. So something maybe can assess, maybe not the number of reports, maybe but just giving some indication how the trend looks like.
SEBASTIAN BECKER: Okay. What I can say, overall I think the community is really excellent to each other and that's a great point here.
BRIAN NISBET: Okay. Nothing online? Thank you and to all the team. Thank you very much.
(Applause)
MASSIMILLIANO STUCCHI: It appeared the moment you asked me. So, from Nico Braud‑Santoni: "Is there a way to ask the Code of Conduct team to mediate something without making a formal report?"
SEBASTIAN BECKER: Yes. You can contact us and we can try our best, basically.
MASSIMILLIANO STUCCHI: Okay.
BRIAN NISBET: Thank you.
And now, the other report you have all been waiting for, so, Ondrej to give the report from the tech team from the meeting.
ONDREJ CALETKA: Hello everyone. Thank you for being with us all the way to the end of the RIPE meeting. This is the technical report from the RIPE meeting.
Tech team RIPE meeting. These are these eight gentlemen. So from the right it's Marco, Ihor, Sjoerd who is actually the technical team coordinator for this meeting. Rob, Xavier, Luca, Andrea and myself who is just presenting it, but I'm not chairing it.
In general, we prepared this meeting three days in advance. So most of us arrived on Friday. And we brought a lot of stuff. We actually filled one big car with flight cases. We brought two super micro servers that are running all the network equipment. We brought a lot of access points, some cables. Some Raspberry PIs, sufficient for the presentation and as well as some power box and of course gaffer tape that is keeping everything together, and it's not a duct tape because that would not be able to take off. This is quite easy to take off and doesn't leave stains.
First, let's talk about power. That's a topic that appears regularly and at this meeting it was quite interesting.
So, first of all, since RIPE 84, since the first RIPE meeting that was after Covid break, we don't deploy power blocks any more to the theatre part of the rooms, but we do deploy power blocks to the desks in the front of the room. So if you are in urgent need of power please find a seat at the desk and there is power. We are not planning to do it because first of all, it's a lot of work. Also, having power blocks on the floor means that they might get spilled something into, which might trip circuit breaker, and in general we generally have problems with power reliability in the venue, so let's not make the problem worse. Also the batteries are getting better and the CPU he is are getting less hungry so maybe update your hardware to something that will last for a day and you are done.
.
Speaking of power, this hotel is apparently known for its power outages, because we sent our router one month in advance to check that the peering works and the Internet works very well, because we bring our own autonomous system and our own set of addresses, and during that four weeks, it actually went down twice. So, we are very happy that it didn't happen throughout the meeting week, even though there is this very interesting button at the front of the hotel, and I am very glad that no one from you has tried to see what happens if they press it. There is also this cable that we found when we were going to take the picture of the generator, and no one from the technical team was brave enough to find out whether that cable is live or not, so we don't know.
Speaking of generator. That's the elephant in the room, let's say. It turned out that the electricity of this hotel is not suitable enough for running the show. So, the guy from the AV company that is responsible for setting up the screens and audio here basically told us would I not even plug an iPhone charger into the hotel sockets. So, we had this generator that is running this main room and the side room, it's behind that, you can see it from the lunch area and it reports that during the break when only the screens were on, it reports 10 kilowatts of power, which if I just do an engineering calculation, it makes sense because this screen is like 1,000 pixels tall and about 5,000 pixels wide. So basically you can say that one column of pixel basically eats one watt, which sort of like makes sense. It's 5 kilowatts per each of these screens, also also lots of resource hungry technology. So one LED here should be like 1,000th of a watt, which, considering the a heat coming from this, is probably correct.
So, let's talk about the meeting network. The part we bring with. This is how it looks like from the logical point of view. So we have up to two edge routers. Right now we have only one because we somehow only got one point‑to‑point link to our upstream provider. But we are ready for two. We have NAT64 box. We have firewall, and behind firewall we have lots of access points, DNS resolvers, DNS over lance rs and other stuff like presentation kit and our stenography and everything that needs to run from our network.
The network runs on OpenSource, so there are basically everything is running on Linux servers with standard OpenSource so that you can use as well, so we don't use much proprietary things. I will not read this list because let's concentrate on something more interesting.
So some discoveries that we made. For instance the edge router which is getting full BGP so we can do RPKI validation on our side is running Oracle Linux 9. And that by default is using network manager for configuring network interfaces and it turns out network manager really doesn't like if your routing table is full of BGP feed, because it listens to net link messages and it basically eats a lot of CPU cycles just to process the fact that your routing table is full. So what we do as a work around right now is after the machine boots up, we just stop network manager because to be honest, we don't really need it. Like, putting IP IDDR into the RC local would work for us as well as anything else. We just need to set up static app addresses and that is it. We don't do anything more.
This is how the physical network topology looks thick in this hotel. It's simple. We have two big junipers which is in the server room. One micro tech switch, as a core switch. We like this device, it's a four port 10 gig Microtech switch for very little amount of money. And then we have some small switches here and there.
So, this is how the physical infrastructure looked like. So, on the left picture you see the two super micro servers and on top our core switch of the micro tech that the optical fiber is the upstream. Then on the middle picture you see our two Juniper switches on top of the rack and then on the third picture you see Marco patching access points and other stuff into the patch panel of the hotel. So basically this all the cables from all the rooms here are ending up in one room, so this hotel is very simple in that sense. And most of the cables work. And the hotel has provided us with excellent sheet of this mapping which is mapping the socket numbers on the wall with the patch port numbers in the panel. So this was like considering previous meetings when they up painted walls and then we have one working patch cable to the whole room, this is like a completely different story.
So, we deployed 37 assess points, most in the first floor, some of them also in the ground floor where the work space was. And according to my experience, it worked very well everywhere. I even tried some speed tests during when the room was full and still ran about 200 and something ambits, which is the limit of the technology that we use for access points.
We are running three or four wi‑fi networks. As you take it, so the main network is 5 gigahertz only. It uses IPv6 mostly stuff that is very fancy and works very well for us. Then we have legacy network for people with some problems. This network is actually two networks it's in 5 and also 2.4 gigahertz, and they use different SSID so they can pick one. We run this experimental network which is also 5 gig, it has no support of v4 so it's the Internet of the future.
Compared to the previous RIPE meeting, we had quite a bigger amount of dual stack users in the IPv6 mostly network. It changed during the week so I guess maybe the fact that this is the bigger meeting, there are more devices here and maybe people also bring some older devices. I'm not really sure what it can be the cause.
Speaking of IPv6 mostly network. I have run a poll on Mastadon on Tuesday, and I am sort of like happy with the subtle because they were completely wrong. I was asking this question that we have 527 devices on the network. And so people should guess how many DHCP devices we have active at that moment with the least time of 4,000 seconds. And the correct answer is 85. So definitely the lowest out of the four options that were presented.
So this is, if you are considering IPv6 mostly, go for it because you can get rid of at least 80% of your IPv4 pool and you can basically narrow it down, make it much more smaller.
Then, we have some complaints that are repeating every single meeting. People are complaining that there is not enough coverage in the toilet and in the lunch area.
And I would just say how about no? How about using these rooms for their original purpose.
RUDIGER VOLK: This is damage to a digestive tract.
ONDREJ CALETKA: Thank you Rudiger. So, no, we are not going to deploy access points in the toilets. And we are not going to deploy access points to lunch area because at lunch you should eat lunch and go away because the table has to be empty for someone else. This is not a coffee place, this is a lunch area.
And the legacy network. This is something that we really don't like people using, but we still offer it because we want people to do their work if they really want and their computer is somehow broken so it cannot work on the main network. So, this is the only network that still supports 2.4 gigahertz wi‑fi, and VP 8 too in case your device has a problem with the other one. People mostly use it for VPN configurations which are usually broken on their side, and I have to say I received during the week a report from one person that basically said yeah, we had this broken power out of a VPN client and we fixed it during the week and now it works. This is exactly the reason why we run the network like this so people can fix their stuff during the week.
But, we are always happy to hear your reasoning why you switched to legacy network. You can always drop us an e‑mail, and if it's something with your software that you are running or your VPN configuration, maybe drop an e‑mail to your IT department, let's say.
AUDIENCE SPEAKER: Actually this old network ‑‑
ONDREJ CALETKA: Let's keep the questions to the end because we are running out of time a little bit. Maybe also during the Meetecho queue, that was a thing that we have here. You are supposed to do it even if you are in the room, almost nobody did, but that's how it's supposed to be. So let me just finish my presentation and after that we will deal with the questions.
Because I have another interesting thing. Maybe you remember from the previous RIPE meeting that there was this thing that some people reported to us that they tried to open gigabit or dot dot Go in Safari on their macOS and they get this very.offensive message saying basically that this was blocked by RIPE MTG. Yeah, and then we, and by we I mean me, spent literally months trying to figure out why is this happening? The good news that I was able to sort it when I was in the office. Long story short, after a few months it is concurrency bug in knot recursive that only happens under very specific condition. If you want to play with it or debug complicated concurrency bugs, theres a bug report here link here, click on it and look at it. So far it's not fixed so we had to look for a standard DNS resolver. We resolver that could do it. That could do DOT, so Android could benefit from it and DNS for IOS and macOS and Windows. It turned out all the boxes are ticked by BIND. Who would expect that BIND is actually supporting everything we need. So thank you ISC people. Perfect. The only thing we don't have now, BIND doesn't report yet stats per DOH and DOT and UDP so we don't have detailed stats how many people are using DoH but.
We had this not so nice feature. I was pointed out on Monday that we are not violating DNSSEC and it turns out that the language of configuration is a little bit cryptic because if you want violation of DNSSEC yes, you set it to yes except if you set it to yes and you don't set‑up trust anchor manually, it will not validate. You have to set it up to auto. So, easy fix. And we are validating now. What we also did was that we did brown out of DNS64 on Thursday because there was IPv6 Working Group, Jen Linkova talked about maybe DNS64 is not needed. So we just gave it a try. For most of you you didn't notice. There were some people who noticed. Mostly people with MacOS 12 and 13, and some Linux users with specific config.
That's about network. Let's quickly go through the presentation system. We have two Mac minis playing presentations and the metric switcher that is switching slides and also showing preview in the lectern.
And we have the timer which the Chair should be setting up for me but they didn't so I have unlimited time. I will try to keep it short, because we all want to go home.
So, and I did this mistake that I just didn't switch to the right slide to I was talking about the previous slide when I was actually going to show this one.
We have this ‑‑ so, this is how it's wired in case you are interested. And we have some innovations. So first of all, we reconfigured the metrics switch err to produce full HD instead of 720. I have fixed the test button so they are now 16 by 19. You don't see the distorted circles any more. And of course this is the first meeting with this LED screen which I think is awesome. And unless you see some pixels here and there, so, I'm just pointing it now and then you will ‑‑ but now it's the end so it doesn't matter.
I think it's awesome, and I hope we will get the same thing next time as well.
Unfortunately, sometimes things don't work and one of the embarrassing moment was the General Meeting, where we just failed to play MP4 video that played normally on our laptops but on either of those Mac minis, not only did they not play, but they also locked them up in a way that they needed a hard reset. We don't know what happened. But well sometimes you have to think out of the box, so, this is Sjoerd picking up audio we have HDMI cable here but we are not set‑up receiving audio from here, so basically Sjoerd made use of this microphone to pick up the sound and play the video from his laptop. So after all it worked.
STENOGRAPHER: Improvise and adapt.
ONDREJ CALETKA: Then last topic which I think deserves some coverage and that is the stenography which we all love. It's not AI. It's actually normal
STENOGRAPHER: No, I am human!!!!
ONDREJ CALETKA: Intelligence of lovely people here. That's us. That's exactly it.
STENOGRAPHER: Lovely picture of me!
.
They are with us since ‑‑ Mary who is now typing everything I say, I always wonder if I start reading it and we will get through inception. They are with us since Mary who is now typing everything I say I always wonder if I start reading it ‑‑ I just take what I hear!
ONDREJ CALETKA: She gave a talk about this in RIPE 73, look it up in the archive if you want to know what these doing here. I have put this diagram here to figure out, so you can see how it actually works, so, what Mary is doing here is, she is typing on this interesting machine that has only 24 keys, she is typing in shorthand hand this machine is connect via USB to a box, the same box is also connected to a microphone, so, there is also feed of audio going from the hall to this USB over IP and this extender extends it over our meeting network to the back stage room, where they have the scoping laptop, and there is a second perpetual, this laptop has a client for the USB over IP so it receives the devices are connected to that laptop and the laptop is doing the translation from the shorthand to proper English, and it's being fixed, and streamed to the stream text dot not WSIS a Cloud service and this offers a web page that we should show use on the screen over there. So that's how it works from the technical point of view.
I would say, can Whisper do this? Because Whisper is the most famous speech to text model over AI that will probably will he place the job of stenographers. I don't think it will learn to break the fourth wall and put these comments there on the screen.
STENOGRAPHER: I exaggerated, I only are have 300 languages!!
.
ONDREJ CALETKA: Now we don't have very much more time.
(Applause)
That is for the stenographers of course.
The statistics. We have some hundreds and bits. We have 25K NAT 64 sessions. We have 699 wi‑fi clients in the main network at most and we have at most 146 DHCP leases. Meetecho starts 57 percent over v6, it's a little bit less than previous.
Very nice barista this time.
(Applause)
.
With that, I will just show credits of some RIPE NCC employees that are very responsible for this meeting. So, not only tech team but there is a web team technical. There is a comms team which is taking care of all the art work that you see everywhere. There is Meetecho team which is taking care of the live streaming and remote presentations. And last but not least, our lovely stenographers and our lovely coordinators that are taking care that this meeting is running.
(Applause)
So that's everything from us, have a safe trip home. Hopefully no unexpected storms and heavy rainfall. And maybe we have one minute for questions.
AUDIENCE SPEAKER: Okay. I am going to close the lines immediately because we are running out of time. But ‑‑
AUDIENCE SPEAKER: Hello, what do you use as wi‑fi controller? Is it a hardware key or some Linux machine.
ONDREJ CALETKA: It's a Debian running on the servers running the unify controller.
AUDIENCE SPEAKER: I wanted to just quick point out that wi‑fi 2.4 network was the only network that had coverage in toilets and practically in the dining room, which could probably explain why people were using it.
ONDREJ CALETKA: And that is also the reason why we change the SSID every meaning so that people don't use it by accident.
SANDER STEFFANN: Whoever figured out to make the LOL to global connect line work properly, please write an article on RIPE Labs.
ONDREJ CALETKA: Great idea.
AUDIENCE SPEAKER: Cynthia: I just have to say that that I think it's extremely curse that USB over IP for this and I really enjoyed that. Thank you.
AUDIENCE SPEAKER: So, one comment on the wi‑fi coverage. The thing is that in the lunch area there were like no reception for me at least at all, depending on what the work is that might be okay or not. So...
ONDREJ CALETKA: Yeah, it's still like you can have your lunch in a few minutes.
AUDIENCE SPEAKER: Speaking for myself. What happened to the music during the breaks?
ONDREJ CALETKA: The music? We got some complaints about it. People just didn't like it, and there was a queue saying they should start playing it. We don't run it. Well, we are still happy without it.
BRIAN NISBET: We have a few things online.
Not a question but a note. "You mentioned that running network manager on a server with a full BGP feed causes high CPU load. We ran into the same issue in March and RedHat told us at the time that we are the only customer supporting, this we received a fixed network manager package from them. To be released shortly after RIPE 89. Please let me know if you are interested.
ONDREJ CALETKA: Can you please send this to our e‑mail.
BRIAN NISBET: Next comment: "Since the network is single‑homed to SNET, would it be easier to accept the default route only? Might even use less power?
ONDREJ CALETKA: It would be easier, then we couldn't do RPKI filtering.
BRIAN NISBET: Nico: "When you said the DNS64 is not needed. Do you mean it's not needed on the local networks caching resolver? I guess the device resolver does the DNS64 translation itself?
ONDREJ CALETKA: I would refer to the channelling in IPv6 Working Group when she talked about that, what exactly it means. The answer is hopefully there.
BRIAN NISBET: Okay. That's that. We're good.
STENOGRAPHER: I have a good solution. Bring your lunch to the toilet.
MIRJAM KUHNE: Thank you Max. This brings us almost to the end of this meeting. I just want to show you some closing statistics to.
So, finally we had people from 59 countries checked in to this RIPE meeting both online and on site. In total, a bit more than over 700 checked‑in attendees online and on site, it could be more because not everybody is registering online also kind of clicks on the check inbutton. So we'll look into that. The top countries were Germany and the Netherlands and Poland. That's good to see.
Again, thanks to the RIPE Code of Conduct team. We had a good report just now from Sebastian already. And as I said we are always looking for new members and volunteers, we will work on that and we might have new people on the team next time.
Then we had a number of Working Groups doing Chair selections this time. And these four people here on the slides will actually leave the RIPE Working Group Chairs team. So they stepped down from their Chair roles. Remco and Florence in Connect, and Denis in Database and Jen in IPv6. So I'd like to give them a round of applause for their long service in these Working Groups.
(Applause)
.
Some other Chairs were reselected into the Working Group and we also have some new kids on the block, if you will, so you see here the incoming Working Group Chairs and also some of them have been reselected for the Working Groups, and they are basically starting as of now in their respective Working Groups.
So, this is the whole team of Working Group Chairs for all the Working Groups we have now. You can find more information of each Working Group on the RIPE website.
So thank you all Working Group Chairs for all the good work you have been doing during the week and putting together the agenda and some really interesting presentations and discussions, I really enjoyed it.
The other part of the programme, as, you know, has been handled by the Programme Committee. Thank you very much, I believe we have some gifts for the Programme Committee. It's time to hand out gifts and to thank all the people here. Maybe we'll do that at the end. I'm looking for within a minute here, but I don't see here. Let's do it now. Could I ask the Programme Committee members who are here in the room and to come up and we'll have a small token of appreciation for you. Some local goodies from Poland that we hope you will enjoy and maybe a photograph as well.
And also thanks to Pavel who was our local representative on the Programme Committee for this meeting.
Applause
We had also PC elections. We had two seats. So two terms ended, there was Max and Wolfgang, you have already heard that from Brian, so I'm not going to stay on this. We have Max is reselected onto the team and we have a new team member, it's Kevin Meynell so we'll be working with that group for the next RIPE meeting.
Please don't forget to rate the talks. You can still do this on Monday both for the Plenary Sessions and also for the Working Group. So the Working Group Chairs are also interested to hear your feedback about the presentations there.
And then of course we are also interested to get general feedback about the meeting, what you like, what you didn't like. There is a feedback form that we'll keep open for a little while after the meeting to gather as much feedback from you as possible so we can improve over time.
And last but not least, I would like to thank all the sponsors and specifically the host, Akamai, I believe we have somebody here from the host who can also maybe receive a token of appreciation and a gift. Patrik, are you here? Yes, please come. I understood that you were mostly interested in one specific souvenir from this meeting that we have here, and we will also have a small gift for you.
This is what you actually wanted.
(Applause)
And then we also have a plaque that you can hang in your office.
We had some great support from Akamai here for the meeting. I would also like to give a special thanks obviously to the RIPE NCC, who was the main sponsor and supporter here. And then we had the platinum sponsor, AWS, who also will receive a plaque from us. I don't know who is here to receive that gift? .
(Applause)
.
And then of course another big thank you to all the other sponsors, and we are going to reach out to you also to get some feedback and how this worked for you here to support our meeting.
And last but not least, I would like to thank the RIPE NCC and all the RIPE NCC staff, Ondrej made it easy for me because he already put the names on the slides. So I would just like to repeat that. We couldn't have done that without the RIPE NCC staff and specifically without Wan Min who was the main meeting organiser here in the background. And I really had a lot of good feedback from Wan Min and only positive feedback. In addition ‑‑ it's actually also her birthday today. So...
Happy birthday!
You did a great job organising this event. So we all thing really enjoyed it very much and everything went very well. Thank you.
And I think this brings us to the end of the closing. I would like to announce the next meeting will take place in Prague in October. And we have, I believe, a small presentation by the host, who will ‑‑ it's actually going to be hosted by CZ NIC, Andrei will say a few words about that before we close the meeting. I hope you are looking forward to come and see each other again in Prague in October.
ONDREJ FILIP: So. Good afternoon, ladies and gentlemen. I am again on the stage but don't be afraid I'm not in the role of RIPE NCC Chair, no more charging scheme talks, I promise.
I am here in the position of my job to be the most annoying guy in cz.nic, which is the host that will host you in Prague. For you who don't know them, it's a company that produces a lot of OpenSource software, hardware, movie series, movies, books, and I think I forgot one thing, maybe registry as well, it registers domain.
I have, you know, the bar is really high, I think Akamai and the city of Krakow really made a great job but I have good news for you. The transfer from Krakow to Breha, it's not very complicated, there are two main things. The language is roughly the same. It's written slightly differently, but, you know, the main words stays. For example, if they write G we write H. If they write W, we write we, if they put Z into some consonant we put that C and make a hook above some letters. There is a transformation table which will make it easy for you. Again the main words say, they say dzien dobry we say dobry den, we just swap the word. And the key words will stay. No worries about it.
Also, you know this is a city with a beautiful castle, with amazing history, a castle where you know Polish kings were crowned, in Prague you will have a city with amazing castle, not Polish kings, but others were crowned. And we were lucky enough that some of those guys became emporers of the Romain empire, so they brought the most powerful people of the medieval Europe. So because that was the house they wanted to make it nice, Extend it a little bit and expand it and at the end of the day it became the largest ancient castle in the world. So I think you will appreciate t and also another advantage of those powerful people are that they wanted to have smart people around them. So, they invited man magicians, people like that, alchemists, that's why we are called mother of the cities, also magical Prague and you go see atmosphere everywhere. But also, they invited a lot of scientists, many many famous names from the history, and also for example from the recent history, Albert Einstein said that he found the key elements of his theory of relativity in the magical atmosphere in Prague. So you can just guess which part it was.
Anyway, we will be happy to see you in Prague. We will try to use the power of Prague for inspiration and inspirational talks and I will be happy to see you there. So please join us and Prague will be your city. Thank you very much.
(Applause)
LIVE CAPTIONING BY
MARY McKEON, RMR, CRR, CBC
DUBLIN, IRELAND.
See you in Prague!
