Skip to content

Opening Plenary Transcript

Chaired By:
Massimiliano Stucchi, Jan Žorž
Session:
Opening Plenary
Date:
Time:
‐ (UTC +0200)
Room:
Main Room
Meetecho chat:
View Chat

RIPE 93

Main hall

26 October 2026

Opening Plenary

2 p.m.

MIRJAM KUHNE: Welcome everybody. Take your seats.

.

All right, welcome to RIPE 93 in Sofia, I am Mirjam Kuhne, I am the Chair of the RIPE community and I want to guide you through the first part of the Opening Plenary today.

For the future speakers, the screen in front is not working, but this one is.

Just to give you some impressions, we are here in Sofia, we have almost 750 people registered actually online and on site, which is great. From 57 countries, we will see the statistics at the closing also and also you will see the countries on this chart as well.

A lot of newcomers also, we saw a lot of newcomers also in the newcomers tutorial earlier today, I am always happy to see newcomers at the RIPE meetings of course, and also would like to highlight that we have three local hubs again this time, one from Poland, from Vilnius and one from Amsterdam.

So, let's move right along.

Everything was working fine during the newcomers, now nothing is working, it's stuck. I don't know what's next, because nothing works.

I wanted to ‑‑ I know what's next. We have never actually been in Sofia before for the RIPE meeting, it's the first time we're here in all those years since 1989 when we started RIPE meetings, don't worry about social events quite yet, we are just starting.

So, even though we didn't have RIPE meetings here before, we had other events in Sofia. Actually last year we were here for the southeast European meeting, and then we had one other SEE meeting here before a few years ago.

So, this is the next slide. There were also some other events here in the country and as you see, in Sofia, and this year there was an Internet measurements day which is always a good way to get the local community together and almost, you know, prepping them for the RIPE meeting that comes to town. So, here we are for the first time.

As a reminder for you all, we have a RIPE Code of Conduct. You can tick the box when you registered, and as the full Code of Conduct is also online, and if you want to report anything or there is anything that you feel, that makes you feel uncomfortable we have this wonderful time of Code of Conduct team members here, I believe all of them, but most of them are here on site. You can find them in the hallways, and there is will see being posters outside you can scan the code and you see the contact information if you would like to report anything.

Related to this, I just want to mention this year, I had this also in my last Labs article, there was some concerns, you have seen this in the press about these smart glasses, people were concerned about this. We have a media policy also in the Code of Conduct that says recording any communications like your fellow community members without consent. It's not allowed. Having said that, if you are using one much those glasses for special purposes, that they are supposedly meant for, I'd be really curious to find out how that, works and how you are using them and how we can incorporate that.

Moving right along. The Programme Committee, they are going to have a bit more of a a detailed presentation later on, but I do want to highlight here, this is the current Programme Committee and they are responsible for the programme on the Plenary today and tomorrow and on Friday. They are all volunteers, and they put together this fantastic programme for this meeting here of the Plenary talks.

We also have of course, the Working Group Chairs, who are then responsible for the topics for the rest of the week, all the Working Group sessions on Wednesday and Thursday, and a little bit on Tuesday, so you'll see here the faces and I think most of them are also here on site.

There are a number of governance things going on, elections, selections, the Programme Committee usually has, they have terms and some of the terms, the members of the Programme Committee terms ends and there will be elections, you have already seen a number of nominations come in, but you still have until tomorrow afternoon to nominate either yourself or somebody else, and then they'll be put on the list if they confirm.

Also some of the Working Groups have, the Working Group Chairs terms ended and there are some selections going on, you'll hear more about this during the week and by the end of the week we'll ‑‑ this picture I showed you will look slightly different.

This is the meeting plan. As usual, you can see it online. It's also on the back of your badge there is a code you can scan and you'll see it and you can click on it, it's an interactive plan and you'll see the agenda of each session. One thing to point out, there is the NCC Services Working Group is scheduled to be slightly longer this time, because last time we ran out of time and we want to give it a bit more time this time. So the break between the NCC Services and the GM is going to be a bit shorter, so, you'll notice that.

Then, just a few more highlights of the, of this week. There won't be a BCOP, like a best current operational practices session this time. So we have four BoFs to take those slots. So there are two today, one is organised by some IETF members and then the other one is about Layer3 Internet exchanges, so they want the IETF BoF I believe is in here and the other one is in the side room around the corner. Then on Thursday, we also have two BoFs in parallel. One is kind of a continuation of some activities where we were trying to include researchers in our community. You have heard about the RACI fellowship, the research academic RIPE academic something initiative. Cooperation. Yes, thank you.

So we have these poster sessions and you'll see posters again. This time they are really popular, this time there will be a BoF to bring operators and researchers together and find some common topics to work on. In parallel to that, on Thursday, you might remember last time we had a BoF on AI and networking, like how people using LLMs and other tools for network configurations, software development and so for the and this one will be the second part of this it week.

Also again this week on Tuesday, we'll have the diversity or a DEI. We had a bit of a theme, this time it's going to focus on the I in the DEIs, we had D and E and now it's going to be I, you might not have noticed but if you look back on the presentations you'll find the continuation there. It's always a really inspiring session so I hope to see many of you there Tuesday afternoon.

Something a bit unusual here, we are unveiling a part of the Secret Working Group. The Secret Working Group, we just learned in the Newcomers Session, doesn't really exist, it is a secret but they are asking for contributions. So if you hear anything noteworthy, funny, kind of, during the week, you can join us, and they are meeting everyday in this room on the second floor, and if you don't know what the Secret Working Group is, maybe because you are new or because it really is a good secrect, talk to your fellow RIPE meeting participants and maybe they can shed some light on that. I am curious what comes out of that in the end of the ‑‑ at the end of the week.

Now, we come to the socials. Of course, we always have socials. It's something organised almost everyday. Just note on Thursday, the dinner you need an extra ticket for that. All the other event of free of charge for you because they are sponsored and I hope there is something for everybody there. It's like a party and there is also board games. You find more information there on the website and also again on the back of your badge, there is a code for that.

Last but not least, all this could not happen without our generous host and sponsors. I would like to have a big shout out for our local host, that's the Bulgarian Internet Exchange, and ‑‑ (applause)

‑‑ and our diamond host, the RIPE NCC, and platinum host AWS, and gold sponsor, IPXO and a number of service sponsors, Meta, InterLIR, AMS‑IX, VeriSign and the Internet Society. The reception tonight will be hosted and sponsored by BXBG together with DECIX, the German Internet Exchange point. A big thank you to all the sponsors.

With that, I think I would like to hand over to the representative of our local host, eve owe, the CEO of DE‑CIX, who would like to welcome you.

IVO IVANOV: Thank you for the kind introduction. That's a great crowd. I am very good afternoon, ladies and gentlemen, and dear friends of digital infrastructure and the Internet.

Now, you might ask yourselves why I, as DE‑CIX CEO, are speaking on behalf of the local host BIX. They have two reasons. So, the first one is as from February 2026 this year, BIX becomes legally part of the DE‑CIX group and as of today, also technically integrated into the global DE‑CIX system. We will celebrate this tonight so you are all he very welcome to join the welcome reception.

Now, I want to thank two great Bulgarian Internet enthusiasts. Dear friends and partners of myself and a lot of others in this room and beyond this room, diamond and Harry from BIX.bg. With all of unprecedented life for connection, digital infrastructure, BGP and all the magic behind it, they have created a vibrant digital ecosystem in Bulgaria that as of today originally the largest one and not in Bulgaria also but also the entire Balkans and south eastern Europe. A big applause, guys, to two local heroes, Internet heroes, Dimo and Harry, Harry is not here today but dim owe is here and a big applause to the BIX team, amazing team they have here. Dimo, I want to ask you to come on stage just for a nice appreciation. Please.

(Applause)

.

So, what should I say now about the second reason why I am speaking here. I had a birthday last week, I turned 50 ‑‑

.

Happy birthday ‑‑

.

And I had been born in Bulgaria 50 years back, I spent 20 years in Bulgaria and 30 years in Germany. So welcome to my first home country.

I am really proud to be here on stage organised by the association like RIPE NCC, thank you so much for that stays so strongly for the freedom and independence of the Internet. For open access to networks and digital services in a lot of regions, Europe, Middle East, very important regions today. I personally see every single day for this as well, every single millisecond and I believe this is even more important today in days with a lot of conflict and wars, to fight for free, open, let's call it open, and unlimited access to digital services everywhere for everyone.

(Applause)

.

So, no politics, just great Internet. This is what we call deserve for open access for innovation and information everywhere.

If you ask yourself do you like great digital infrastructure, vibrant ecosystems, fantastic community, and amazing food, beer and wine? And if your answer is yes, than you are in the right place today, Sofia in Bulgaria, congratulations for this decision. And my last thought, I still have two minutes but I'll not use all those.

For years we have been talking about the big flap, right. Frankfurt, London, Amsterdam, Paris. But now we see, over the years, there are new raising digital ecosystems in Europe, a lot of tech became relevant and important. We give you one example with the Iberian peninsula, with Madrid, Lisbon, Barcelona, the Iberian peninsula we write it with I at the beginning. If you try to now add an I to the flap, it will be called FLAPY, it doesn't sound that nice, right. Another example, great ecosystem developed here in the Balkans in Sofia, Sofia is written with an S, do we want to call it FLAPS? It's also not that nice. So, my point is, FLAP is not enough anymore. We have to build more distributed, great digital ecosystems everywhere, and this is the mandate. Now, I want to wish you all an amazing time, great talks, beautiful experience in Sofia, Bulgaria, in one of the new digital capitals of Europe. Have a great time and thank you for your great attention.

(Applause)

MIRJAM KUHNE: Thank you very much for this those inspiring words. Next I would like to ask on stage Hans Petter Holen, the Managing Director of the RIPE NCC and our diamond sponsor of this RIPE meeting.

HANS PETTER HOLEN: Thank you Mirjam. Welcome everybody. No picture on the screen here, is that just a test if I know what I'm going to say or...?

.

Anyway. My name is Hans Petter Holen and I am the Managing Director of the RIPE NCC. So, I am going to try and take this.

What is the RIPE NCC? We're the secretariat of the RIPE community and the community was formed in 1989 while within '92 the community figured out with needed a secretariat. Later on we become a regional Internet registry. The founder figured out that we should do more than just being a regional Internet are registry. We should do things like measurement services that we are going to hear more about.

We are run by a staff. It's a membership organisation, so there is a General Meeting on Wednesday, so you can come there and take part in governing of the organisation.

Logistics. So that's why they sent me up here, to just tell but this logistical things. So Meetecho. That's a crucial part of this meeting. Not only if you are doing it remotely, but you have gotten an e‑mail today and there are multiple links in there. If you are here the second one may be the one you want to use, it's a nice little web interface on your phone so you can raise your hand or rate the chat or at the QA and As there. It's a useful tool to take part in the meeting that you are now part of it.

Live‑stream on the RIPE 93 website. So you don't have to log in or register for anything, if some your colleagues want to watch them back home, share that with them. Don't share your Meetecho link.

All the sessions are recorded. So, everything you say is on record and will be public, so is the chat. So, remember the Code of Conduct is not only for the physical but also for the virtual part of the meeting.

In the Meetecho app, you have the audio/video queue if you want to talk. There is a Q&A, if you have a question but don't want to read it out yourself, the chairs of the session can read it out for you. The chat, if you want to chat with people, and then of course stenography. So if my accent is too difficult for you, we have some stenographers here that hopefully understands what I'm saying and somebody interprets what I was supposed to say, so you can follow that online.

Please wear the badge at the site so we can see that you actually paid to be here and it's easy to identify who you are. Wear it to the social events. It does have the wi‑fi password on the back and you can scan the QR codes for the meeting plan, the social events and the other parallel events we have here.

If you prefer not to be taken a picture of, because we have a photographer here that will go around and take pictures of anything interesting, you can put on a yellow lanyard and then the photographer will try to avoid taking pictures of you, but even more so, when staff goes through the pictures to see what we published on social media or otherwise, they will also be a second line of defence before this gets published, if you don't want your picture out there, wear a yellow lanyard and be nice to the photographer.

Registration desk. If you have questions, we have staff there.

IT support desk: If you want to test your presentations upfront, talk to staff so that you make sure that it actually works here.

Assisted registry check. If you want to schedule a way of going through all the registration and the accuracy of your, what you have in the registry, feel free to use the opportunity to have a registry, assisted registry, it can be in person here. You can also register to take the academy certification exams while you are here.

The RIPE NCC since 1993, not only do we organise this meeting, we also use it as a very important venue to interact and communicate with you, our community, our members, and you can see here all the session that is we are presenting. You will hear a couple of my colleagues later today talking about some new interesting stuff in RIS. We have an update on the measurement services in the MAT Working Group tomorrow. And I am sorry, but MAT in Norwegian means food so I always get the wrong annotations there, but anyway.

.

Routing. We are working on RPKI. So there will be a update on the latest and greatest in RPKI and ASPA.

The RIPE NCC Services it is probably the most important Working Group to attend if you are interested in what the RIPE NCC is planning to do next year. There is a draft activity plan out. There is a budget that comes with that. That is draft because we want feedback from. So please come to the Services Working Group. We will have ample time to get input and discuss there, and then this will also continue into the General Meeting where we will discuss matters of the budget in general and also some large investments that we are proposing in a new infrastructure so it's really important that you pay attention and give us feedback on this.

One thing that you may have seen is that the Board has made a decision to freeze registration of new multiple LIRs right now because they believe that the discussion of whether you should get more IP addresses or not belongs in Address Policy. So please go to Address Policy to do that suggestion there. We shouldn't have a work around or a back door into that. Will now, there is also research going on into what is multiple LIRs used for and we have some interesting research to present there and we have some staff here, I think Fergal and Ilke, that also talks to people about what function amount is needed to replace the multiple LIRs for access control and so on.

DNS, we have have an update on that. Community Plenary, the RIR governance document and in the closing Plenary there is always a very interesting tech report, so if you are wondering about how to pull off the network and all the AV and whatever happened during the meeting, we will show you that there.

And I forgot database, where there will be a regular update about what is happening in the database development.

General Meeting: On Wednesday, you need to be a member. Please register, please pick up your badge. If you have questions about any of the changes to Articles of Association that's been proposed now, feel free to reach out to our Chief Legal Officer, Athina, she will be around the registration desk or the support desk for that during the week, and please collect your general stickers for the GM, otherwise we will not let you in.

We also do user testing because the LIR portal is your way of doing things by self‑service, and the my resources page is now up for renovation, so to speak, these are here to do testing of different ideas on how to improve that. Ling Ang from our RIPE NCC Academy team is here to get input on some of the trainings and ideas we have to develop them.

That was it from me. And I guess there isn't room for questions, is there?

.

(Applause)

.

MIRJAM KUHNE: Maybe I can ask Max to make his way up here, the Chair of the Programme Committee, who will give you a bit of a detailed impression of what the Programme Committee actually does during the week and we will also take over from there afterwards for the rest of the Plenary.

MASSIMILLIANO STUCCHI: I think I know what's in the slides. So, maybe I can follow here.

Good afternoon everyone, I am Max, I am the Chair of the Programme Committee.

Maybe you know what we do but these are always the same slides. We compile the programme that includes Plenary talks, BoFs and tutorials, so if what you already participated in this morning, the two tutorials, if you liked them, that's because we got the choice and then the same goes for the rest of the programme. We work with the submitters to improve their material. There is a procedure for that that we established over the years. Then we prepare the agenda. And that's the tricky part. I'll talk about it if in a moment.

Then last, we moderate. So we make sure things stay on time. And I can tell you now we are a few minutes late so I need to hurry up a bit in my presentation.

So who are we? There were already the pictures earlier in Mirjam's presentation. They were actually nicer. But one thing that I should mention is that we have a new person on the Programme Committee starting at this meeting and it's Mickhail on the top right. We have a new representative from another meeting, from the central Asia peering forum. So we have him and both Jan and also Osama representing different parts of the region and giving us different perspective. So those are really points of view that the rest of the Programme Committee usually understands and sees and to prepare a better agenda for you.

So, what are the statistics?

.

They are in line with what we see normally. The so as you can see, we had roughly a good 15% of acceptances for the Plenary talks, which the usual number, but the BoFs were four, they were all four good so we accepted them all. We made space for them because usually there is a BCOP session. This time we understood that there wasn't going to be one, so we took the space for that. Tutorials, we had two submissions and they were both good, hopefully.

Then for the lightning talks we have had 15 submissions but still so far we have accepted seven, and we still have a few in the line. So we will be sending out acceptance or rejections soon this week, later today hopefully, but also we have some remaining slots that are available for Friday, because I will explain in a moment the why.

But, we still have slots open. If you want, you can submit, just go on the submissions website, and please when you do so,,ing send us some slides, even if they are drafts, very simple, but give us an idea of what you like to present, how long it is, so we can also guide you maybe in making it better, since we can be here physically, we can come over to you, have a quick chat, maybe discuss briefly how we can suggest how you would improve those slides and hopefully get you to present them on Friday.

But, I wanted to spend a few minutes this time talking about the challenges for the Programme Committee. The first one, first and foremost, is scheduling somebody on Friday. There hadn't been a meeting in the last few years where we scheduled ‑‑ we presented the schedule with everything is fine and then a few days later we get an e‑mail, sorry, I won't be there on Friday. So we have to swap around people. That is the, one the biggest challenges we have, because then there are very, very few people, especially in places that are a little further away from the rest of Europe, like here where flights are earlier in the morning, where we can schedule people for Friday, especially the last session.

I am sorry, but we have that part of the programme that we have to fill, so, we'll always be looking for people to present then.

And then the second challenge that's arising, it's AI generated slides and the people on the Programme Committee has improved their capability of understanding where they come from. So, we tend to be spotting them relatively easily, but they are also improving in making it harder to do so.

What are the changes though? I mentioned that we are accepting more lightning talks because we have seen so many submissions, so we decided to swap one Plenary slot, which is 30 minutes are for one presentation with three lightning talks. Why? Because some of the common issues we see? Submissions are small fonts. We have our ‑‑ he is no the in the room but Amadeo is our go to, he spots always the smallest and the different problems. There is one problem that's dedicated to that in the Programme Committee, too much text, which comes together with usually small fonts.

But then one of the challenges we have seen most for this meeting was that we have received a lot of submissions where we would look at it and think that the content didn't look enough for a 25/30 minute presentation, so we suggested the person who submitted it, to resubmit it as a lightning talk, reducing a little bit, trying to fit it into ten minutes. That's why, after that, because there was a large number of those, we decided to add a session for three lightning talks, so that we could accommodate all the potential additional submissions, and we have a good number of submissions for that.

So, a couple more things. The PC keeps providing an explanation of why your talk was rejected, your submission was rejected. We have received a lot of positive feedback about it. Will we don't do an academic review. We just give you a couple of paragraphs about why we have rejected the talk. So that you can improve it and especially if you submit it in the first deadline, then we give you an opportunity to review your presentation, review your material, think about it and then resubmit it and hopefully get it accepted in the second round, which, we have had a few cases of. So that's always good to see.

Then last, we have PC elections. So, if you see that you are interested in the work and you would like to join us, you have an opportunity, submit your willingness to join us up until tomorrow and then votes are going until the 29th. And the winners ‑‑ well those who will be elected will be announced during the Plenary on Friday morning.

So, hopefully I have given you enough data to understand, but if you want to know more, you can check out the RIPE PC Charter, RIPE‑853 or e‑mail us if you want to understand more. Or stop me or one the people with the Violet signs on the badges.

That's it. Will are there any questions? Quick ones, because I am running late. The we have one.

AUDIENCE SPEAKER: Hello. I am the first presenter on Friday morning. Regarding your first concern I'll be there so you can count on me.

MIRJAM KUHNE: One addition and thank you for bringing up the challenges that you are facing as a Programme Committee. I wanted to make everybody aware we do have some material there for speakers. We have a training course on public speaking, we have some tips and tricks for slide layouts, but we realise maybe they are not as easily findable and accessible on the website so we are actually looking at making that a bit more ‑‑ combine all the information and make it easier for you to find and therefore also hopefully making it easier for the PC in the future.

MASSIMILLIANO STUCCHI: We as PC should also be pointing more to those materials. I don't see any other questions, so thank you very much.

(Applause)

.

So, after this, we have the first presentation of the day and it has a pretty interesting title. When it came into the submission queue, we were looking at it and thinking, okay. But it is, these are two presenters, Francisco was also part of the Programme Committee until recently and Tobias is actually one the candidates as well. So please tell us what is important to tell your friends.

TOBIAS FIEBIG: Usually it's important to tell your friends to check their file systems, but because we learned from an important member of the Programme Committee that the introduction presentation always sets the keynote for the conference. It can also be important to tell your friends to fuck off.

FRANZISKA LICHTBLAU: Wake up everybody. Go back to your personal history, especially those who have been in many of these rooms so far. You just started at one of your first positions, you were still a junior, motivated, you had a lot of architecture ideas, you learned all the networking protocols, you want to work on cool ideas. They put you, an experienced colleague to your side, you pitch your ideas, you are super motivated and they tell you no, that's just not how it's done here, you are like fuck! You say yeah, I never want to be that person, and I am never going to be that person because I have experienced this.

So what's the catch in the story? The catch is, your colleague back then might have been right: You were still a rookie, so maybe your idea wasn't that great. Or they might have been wrong. Who knows. The boring question is: How should you have known back then? It the more interesting one is how should they have known? And this is one of the focus questions we want to raise in this presentation. How do we, as seasoned community members and experts, remember that we can be wrong and how do we notice when we are.

TOBIAS FIEBIG: Which is actually not that easy because expert is going to expert, we all know experts. There is like high achieving knowledgeable people and they are usually right, right? Like, if some people say something about take it like DNS, IPv6, you know they know their stuff. And their success is usually 97% in their area of expertise. In convergent areas it usually kind of works out, v6, v4, maybe, they kind of do well. As soon as you get to the further edges of their experience it becomes more and more fuzzy, and if you are an expert you also have to reiterate over the same arguments all over and over and over again because people always have these ideas.

Next slide.

So, underestimated failure mode, failures of fun as you just saw, if these experts are wrong in like 3% of the cases, it might be because they just got very quick as this missil if you have explained the same things ten times over and the 11th person comes in and has the same idea, you say go away. Sometimes you just don't follow these funny ideas, right, and you get impatient with the people and you are like I explained this a one times already, you don't have a new idea. But still, everyone's success rate will decline over time. There is new technologies you haven't worked with, I mean I don't mean IPv6, that's an old technology, you might have a different focus. I mean some people actually become managers, and there is also the reduce the neuro plasticity, so we always had this fun joke about Professors have the attention span of an average gold fish, which I always found very funny. I am a full professor now.

This might look like a people issue to you right now but it makes tech issues. This is a quote from the practice system network administration. We have these people that build the new fancy things, and they usually fight the stallers and they stallers that are like no, we don't need IPv6, like we still have classful routing, those persons back in the day used to be the bleeding edgers and then they were right a lot and then they become a staller. When you are fighting a staller you might figure out that you actually kind of well after some time become the staller and deal with a new bleeding edgers that way.

So, first claim: When we are right for too long we forget how to be wrong.

FRANZISKA LICHTBLAU: With that, let's pick at one the elephants in the room.

So, if we forget that we can be wrong and how that feels, we let familiarity guide our decisions. What does that mean? It means we pride ourselves about our technical expertise, if somebody comes with an idea, we look at the technical details. We don't make emotional decisions, we are tech people. That doesn't work anymore if you forgot that you can be wrong as well. And again, it's nothing that only happens to other people.

If you have a tradition of being right a long time you tend to be very certain and I think many people in this room have experience of that if we feel we are right we will fiercely defend what we think is right because we all want to make good decisions. That's not a great way to make good friends and find good collaborators.

So second point, forgetting how to be wrong can happen to literally anyone. All they have to do is to be right a lot for sometime and to make the problem worse, smart and accomplished people have a tendency to be very, very good at rationalising their thinking. You keep telling yourself your good ideas and reinforcing them so it's very hard to counteract that.

.

TOBIAS FIEBIG: How does this happen? How do we forget to be right? When we are right, people at some point actually start to trust us. I know it's odd but people actually trust our judgment. We might also start to monopolise certain knowledge, right, that a little bit of documentation you didn't write because you are always the person that actually does that change anyway, that is kind of a good way to always be right and not let anyone be right in your place.

.

You also if you are doing a good job you become the default choice for projects because if you touch a project, the thing is actually getting done. You know what you're doing.

You actually make a lot of things happen and like for that you are highly respected. Which is a bit odd because it's getting more difficult to tell you that you are wrong then because you are highly respected and telling a highly respected person that they are wrong is kind of disrespectful especially if you are not a highly respected person yourself.

So, how we usually think about it as highly respected people is this: We are sitting alone in the fire and think this is fine. Well...

An environment full of people used to be right converges to consist of people only who are right.

FRANZISKA LICHTBLAU: Which sounds great, right? You have a room of very smart people who have the right ideas about the right things. Sounds great, right?

Well not always. We are going to illustrate two admittedly pretty extreme examples but I apparently have seen both.

The first thing is, group think. If you are in a room where everyone is used to be right, you agree on the concepts, you are friendly not at each other and everyone is happy you are in agreement because things are following the way and nothing new ever gets built. The opposite is you have a lot of people who hold strong opinions on stuff and they will continue arguing with actually well crafted arguments. So everyone is very uncompromising making their points. Everyone in the room is right but disagreeing and nothing new ever gets built.

TOBIAS FIEBIG: So, which brings us to a false claim. If you have forgotten how to be wrong, nobody will tell you that you did have forgotten to be wrong and actually getting new friends that then might actually considering telling that you you are wrong becomes harder and harder because you are... well... difficult.

When we think about our nice, cosy, warm room, what we actually should think about it this. This is not fucking fine. This is a fucking huge issue. And we, indeed, do have a problem. And we should just get out the fire extinguishers and get rid of that. In the end, after we do that we might not it actually notice that we do have any friends and are sitting in a room all alone, but at least the burning has stopped. And the burning usually gets worse when you let it burn, so....

.

What is the worst that could happen? Well, this.

Does somebody recognise this? This is actually a plane crash in Tenerife, the biggest plane crash in history, two fully loaded 747s and it was basically the very esteemed KLM pilot, like front page of the KLM magazine saying no, no, I heard right, we're clear for take‑off. The co‑pilot was like, no, it came that he was too inexperienced to talk up to that senior person. Now they are all dead.

Luckily we don't fly planes, at least not in the very front. It still can get a bit bad. We can have the technological stagnation, actually when we have this culture of always right, it's not so nice if your first experience in the community is like interacting with an always right person. And this might be a revelation but we will all die one day, some sooner, but then those big shoes of an always right person have to be replaced and they might be too big. Somebody will eventually have to clean up after them. Interestingly, that somebody then might become a person who is always right because they have to go through all the pain of cleaning up for the person who was always right, therefore becoming a person who is always right. Basically it's the cycle of life.

FRANZISKA LICHTBLAU: Let's wait for the clicker. Could we try to get that fixed? Let's go where we actually can see it. I mean, hello everyone is here for the cat, right? And actually the cat comes with a very important ‑‑ we do get that as a bonus time later on, right?

.

Okay, so where are we now? Have a cute cat with it. And the big question right now is what do we do now? But also we want to raise a couple of disclaimers, because what we are not saying is that everyone who is doing this for a long time should go and leave the room. That would be awkward for us standing here. We are not asking the experts to quit communities, companies, whatever, that would be bad, because we need the expertise. But what we actually want you is to genuinely take new input in. We are not saying an idea is great just because it's new or it comes from somebody who is new. But we want you to genuinely consider it. End of disclaimer.

Okay. Now, we build up the problem, now we hope to give you a couple of strategies against that fallacy.

First is, don't take short cuts. No pushing directly to production. Everyone goes through the CI. Also you. If you ever hear somebody in your vicinity saying oh, no, we can't enforce that particular process on them, they have always done it that way. No. You are not above the rules. You have to hold yourself to the rules because for others it's excessively hard to hold you to them.

TOBIAS FIEBIG: It also means letting things fail because people need to grow. You cannot just patronise people around you. You need to let them actually make the mistakes which you made to actually become the engineer you are today. So, don't patronise them. Have their back if things fail. Another great thing. I don't know how many holidays people in this room have accumulated actually left? I think the answer is yes.

Take them. Risk being unreachable. There is really great areas in Germany where there is literally no Internet. Just risk it. Because then people notice when you are the single point of failure. Don't quickly jump in to fix what no one else can fix. Imagine junior being on‑call and you jump in before they can go through all escalation steps. Don't do that. That's a small hiccup now instead of having the big hiccup. Document things and automate things that are nibbling away your time. The amazing thing is you can give it to somebody else and they do the work and they also learn something in the process.

Fund juniors going into conferences. The age average in this room is too high. You do not need your hundred 18s on one conference shirt. Also remember responsibility and authority, they go hand in hand. If you make somebody responsible for something, you need to give them authority over how they do it. If you don't do that, it will hurt. A lot.

FRANZISKA LICHTBLAU: The next one is, it seems simple but we forget how it works. Will we must remain approachable and we need to very, very actively ask and welcome people to speak their mind around us. It is actually a cultural technique. Try to be better here. Will one very important catch, if you are already pretty high on the knowledge tree, talking to other people who may have actual new perspective might be your only avenue of ever catching on to new ideas.

.

Also, and I realise this is a hard one, the more experienced you are, the higher you are in any social hierarchy, the harsher the feedback you are going to get and must take in. Will I am not saying you must stand up for being shouted at. Nobody should be rude to you. But on a topical level you must be criticisable. There is a saying that goes around in all these communication trainings that short of you should only complain upwards and never a harshly criticise downwards. The problem is, what happens if you are on top of the tree, who can you then still criticise? Should you stop doing that? The answer is no. The answer is consider your rank and consider costs. We are networking people, we know how costs work and the thing is the cost of replying and correcting somebody for many people who do this for a long time is next to zero, because you already have the reputation, you have your standing. But for a junior to come and speak up to you, they risk their very fragile new reputation or even their confidence by being shut down so their cost is higher.

What does that mean for you? For you, it means you must position yourself in a way that is cheap and easy for others to correct you. And also, I think this has been written 1,000 times, be upfront about your own mistakes. That gives people angles to actually discuss with you.

This one is about being strong enough to be actually vulnerable in your higher position because admitting that you can be wrong, yes, make you vulnerable as well.

TOBIAS FIEBIG: Axioms considered harmful, or as we like to say at a place called INET, ah!

.

Or we call is also, it's always DNS problem. Because, like, if you read like the tense Internet routing revolutionising idea you might think it's wrong because A) someone does it again or you just know that BGP is a way because BGP is perfect.

FRANZISKA LICHTBLAU: It is known.

TOBIAS FIEBIG: These axioms like it's always DNS, they can be relatively useful short cuts to like do which can reasoning if it's needed. But if you do have these axioms you have to regularly check if they still hold. Are the facts based on which you reached the conclusions still true? Don't plainly reject some new idea based on your experience that turned into one of those axioms which you used in your reasoning.

FRANZISKA LICHTBLAU: Next one. I think everyone in this room knows the phrase: Be liberal in what you accept and also be forgetting because if you are doing all of this for a while, people around you will always be wrong all the time, and we are not saying this is not annoying, it is annoying as hell, but remember, you used to be wrong a lot and you were probably still wrong these days. So, accept that also from others. Also, don't even subconsciously, use the fact that you are around for a long time to sort of lovingly look down at other people and say hey, yeah, that's a cute idea but in the end you know you are doing this for such a long time it can't possibly challenge any of your thinking. But actually, they might have a real fresh perspective without your decade long baggage on I don't know, BGP. And again, don't hold grudges because if somebody actually dares to speak up to you, it took them probably a lot of courage, and they are actually doing you a favour. And this is about managing your own emotional reactions to that. I know we are all engineers and we all don't emotion very well, but in the end, we do, so we at least need to be aware of that.

.

So, the next one is we talked a lot about symptoms, but the question is: How can you actually know that you are wrong? And I encourage you to read up on a couple of these techniques, there is excessive materials out there, but long story short: Looking back how things worked previously and making advance predictions are two of the most effective techniques that I have seen. So exercise to the room again take home exam: The next time you do a project, you do something new, make an honest prediction how well you think you will perform on it, write it down in a good level of detail, and in the end, honestly compare how it went and do some introspection. The other thing is if you have a some opinion about something, like a technology. Ask yourself how would a good argument need to look like and be shaped to actually make you change your mind? So, how would that functional inter‑domain routing replacement for BGP actually look like? It if you immediately swiped the idea away as impossible, this might be more personal than actually founded in facts. But, radical self reflection is extremely hard. So, utilise external resources.

TOBIAS FIEBIG: Which begs a question: Where do we get those external resources? I kind of do hope that some people at least in this room have some friends. So, how do we let our friends tell us to fsck.ofs? If you are already always right you probably get used to it we established that to you need others which is a must, this is a strict must, tell you when you're wrong.

The longer you have been right the more people will just be like I don't talk to that person anymore, or actually not there to speak to you because you are so threatening but usually they are resentful. When do people treat it as a service? If somebody tells you to fuck off it usually makes you angry, listening without anger is not that easy, which is where the friends come back in because friends usually give better feedback. They are more thorough in it and they actually care about it. That is what is making them your friends which makes the feedback about like caring for you.

As we already said, as an expert usually the only way you can still grow because you might have written the book on the thing where you need to grow, so, that input is the only thing you get which is above the top of the knowledge tree. And if you want your friends to do that to you, it's usually quite helpful if they know. The so talking with your friends about that, telling them that you want them to speak up, that is the way to build the village it takes, and you need to be part of the village, you need to care for others, you need to tell your friends to fuck off and they need to tell you.

FRANZISKA LICHTBLAU: So, let's swap perspective. If you have a friend that, who is complaining about all the time everyone is getting it wrong all the time, nothing moves forward, everything is broken, everything they touch just falls apart because maybe somebody did something wrong in the Internet. You maybe caught them unintentionally taking people down by discussing too harshly and then made all the short‑cut arguments for their longstanding strong beliefs. Reach out to them. You are generally caring about them. Might be one of the few feedback avenues they have, because again, as a society, we are not encouraged to question people who are very good at their fields, but also remember, this is hard for them. I think nobody of us would claim getting negative feedback is in any way, shape or form a positive experience. We all shape it like that. It is an opportunity, etc., etc. In that moment, we really don't want to hear it. So remember that when you reach out to your friend.

What I personally recommend, use mental language. Discuss with your friends maybe a phrase or a setting where you can say "Hey, by the way I want to give you feedback now, I don't want to judge you but I see something is going wrong there, you might want to pay attention." So do some framing so they know this is not coming out of the blue and you are not out to get them. So this can be hard, but they need a friend probably and maybe that can be you.

TOBIAS FIEBIG: So, other things you can do to tell your friends to fsck.ofs, because we usually don't want to judge, I tell my students if I wanted to judge people I would have studied law, and I obviously didn't. One the things is active listening. We usually learn in company communications stuff but this also works with friends, there is good books about that.

It's important if you discuss things to provide concrete instances of what you are talking about, you always do obscure things. I mean probably everyone's stomach turns in that phrase, and all these concrete things you should describe what actual impact their actions had without actually judging it.

Will you can use I statements in that station for example like: When last meeting you talked to the junior like that, I, in that position, would have felt being talked down to.

You can workshop actionable things together with your friends. And ideally you request them to implement the better options next time, which is like if the child already fell in the well, think about next time I'll do better.

.

So, make sure your friends know that you are a safe space for them and that you want to help them be better without judgement. Will and you calling them out is actually you being a friend to them.

FRANZISKA LICHTBLAU: Okay. We keep this super short because we are already a bit over time.

We don't want to chase anyone out of the room, but nobody benefits if we become non‑questionable. We shouldn't assume this happened to us, we regularly self assess if we know how to be wrong.

We should check in with our friends. Have a look how it's going.

We really need to consider different ways of doing things instead of just like smiling, nodding and thinking of the good old days. Not saying they weren't great but we are where we are.

TOBIAS FIEBIG: TLDR, telling your friends to fsck.ofs is an act of love and care.

JAN ZORZ: Thank you. This was excellent. I see people queue.

AUDIENCE SPEAKER: Sebastian, Deutsche telecom. Thank you, you speak from my heart.

That was an excellent presentation, and on slide 30 there is a space missing.

FRANZISKA LICHTBLAU: I didn't have you to correct it and these are not AI generated.

AUDIENCE SPEAKER: Benedikt Stockebrand. A couple of things. First, I really object to what you said at the beginning that what was the, what we do isn't life threatening.

Some people use our networks for emergency phone calls. So, please keep that in mind. This is a rather misunderstanding that is actually dangerous and yes I have had a bit of experience with people doing emergency call centres.

FRANZISKA LICHTBLAU: Fully agree.

AUDIENCE SPEAKER: Second, there is a certain ‑‑ I have done trainings for a lot of times and I hav awwn places getting IPv6 up and running within a week and I have seen places taking three or four years for it. The whole spectrum. What I found out organisations where things actually work, you have certain distribution of work. So the old farts, they have the experience, they have all the information, we did this because of that reason, what not. And the youngsters have to question you.

If you establish a culture where this is accepted, then you really get things done. It's not ‑‑ we're using sent mail because we have always done it but if you want to use Postfix, here is what we had to pay attention for. That helps a lot. While we are at that, okay, if you want to do Postfix, fine, I'll tell what you we need, what we have done before, it's your baby now. That means letting go of your sent mail, which is hard enough, but it actually works.

One more thing. A long long time ago I had a boss, every time I showed up with something like we have to do something about this, this doesn't work very well, he'd listen to you for a while. He was focusing on his management role, it wasn't easy for him, but eventually he'd ask you, do you want to take care of it? The moment you said it was his ‑‑ he said to him, this was urgent and he didn't need to understand it but he'd make sure he did blah blah and what else, but it was your job afterwards and that frequently helps to focus on the important things and get new ideas in here.

JAN ZORZ: In the interests of time can we keep this ‑‑ the questions short. I am cutting the queue now.

TOBIAS FIEBIG: Good point, thank you for sharing.

AUDIENCE SPEAKER: Stefan, for the last three years I have seen this a lot and thank you for your presentation, there is some very good ideas inside and I made a short statement, it's all about excellence, at the end of the day not about age or gender. Thank you.

DANIEL KARRENBERG: Daniel Karrenberg, I used to be right a lot of times and some good friend told me once I should stop arguing people into submission. So, all points well taken.

The point I want to make is, do we want to take, or is there room to take this beyond just you two making us aware of this problem and giving us some tips, do we want as an industry really to attack this? Thank you for putting in the aviation example, because I am an aviation nerd and I can tell you the aviation industry from this, and a few other incidents, actually took action. Pilots have to take a training in multi‑crew co‑ordination before they are even allowed into the cockpit that addresses these kinds of uneven power differential in the cockpit and they learn techniques and even procedures to avoid this. Do we need something similar?

Then there is my hobby horse: Do we want, as an industry, to learn from mistakes? The aviation industry has systems for actually reporting and taking conclusions from mistakes that happen without attributing guilt or whatever, do we, as an industry, want to do this? And do you have any ideas how we could make procedures and a culture of being less, how to say, sure of ourselves? Thank you.

FRANZISKA LICHTBLAU: What we tried to do is actually give everyone in this room the chance for self reflection, so, everyone who might be in that position, start doing it right now and for everything else we can maybe discuss later in the interest of time.

AUDIENCE SPEAKER: I am speaking strictly for myself but I was involved with some incident response at Google and I spent five years with the incident response at AWS, and the impulse is when there is an outage, to be really strict with people who created it.

The lessen that they learned both at Google and at AWS is: It's the worst day in the life of the person who created the incident so be kind to them.

FRANZISKA LICHTBLAU: Yes, nothing to add to that.

TOBIAS FIEBIG: Thank you.

(Applause)

JAN ZORZ: Thank you. Now I believe we have an online presentation.

SAVYO DE MORAIS: Hello everyone.

Can you see me and hear me well?

.

Thank you very much for having me. This talk will be a little bit about the work that we have been doing lately to increase the IPv6 adoption. We are historically working mostly through ASN operators and now we are, through the IPv6. By the way I just checked, we are probably reached, this week, at least from what I am following, the mark of 60% of adoption from the client side according to APNIC measurements. So, we are reaching this point of nearly 60% of clients of end users accessing content in IPv6, and from my side, we are experiencing to have also content available in IPv6 as well.

So, the title of this presentation is one of the questions that I always make during the conversations that we have with our stakeholders and peers, including but not normally host companies, universities and everything, when we are talking about the services and the applications that they have online, to check if the, if it's developed over IPv6. So this is our work for now.

The IPv6 deployment paradox is this: We have a high number of adoption from the client side people consuming content online over IPv6 but actually from the measurements we made from the tests we made, we have between 10 and 50% of the national content available over IPv6. So it's dual‑stack, so most of it is IPv4 only, especially for government services and this kind of stuff from the measurements we had was around 10 to 11% and for companies, it's around 15 to 16 percent, so it's a bit lower volume.

This means that a lot of our networks have IPv6, or working on them, but the applications are not available, even though there is connectivity in the ASNs and everything, the applications often are not compatible with IPv6, or are just not deployed in IPv6 as well. So, we are trying to change be this.

.

It's a varied reason when we start these questions because it's difficult. We have, from the Brazilian government at dot golf dot BR which is available over IPv6, but they have been accessing it through IPv4, with dual‑stack, then when we go with IPv6‑only, we disable IPv4, we have some dependancy and this kind of stuff, there is static source that is come from others. Over IPv6... we are only talking about one content. This goes even further when you talk about APIs and all the other kinds of applications, not only for the Internet itself but for corporate network as well.

So, one of our main concerns is that we have increasing dependancy of online and government and banking services and we are still depending on them on IPv4 to access them. So even if only one part of our banking system is IPv4 only, there is no dual‑stack or IPv6 deployment, we still depend a lot on IPv4, we still can't shut down.

An even thouh this will take a long time, the dual‑stack should apply to services on IPv6 and dual‑stack and then you get rid of IPv4, so we have some government mandating v6 for public services, so, the United States, Czech Republic, and Brazil. Also I heard recently about Germany has some kind of policy or bill to have dual‑stack and IPv6 services as well. So there is this concern and we are working to increase increase the IPv6 adoption in the slice of the Internet usage.

.

People work over IPv6 should deploy the services in IPv6 ensuring that that services or application is ready for IPv6 is difficult to have like one hundred percent sure that's not depending on IPv4. So we have to check if server is reachable over IPv6 so the network connectivity over the client and the server, but also the DNS and the firewall and all the other middlebox that is may be involved in this communication.

If I am trying to do a tracer from my bank can I do it in an prefix solely network, for example? As in that case that I have shown, but in different cases, is there any dependance of your page, inter library from the code itself but also some logging or some firewall has some restriction for IPv6, blocking what it shouldn't be blocking on that, so monitoring, logging, everything should be working in IPv6 as well.

Just in case IPv6, you have some outage on IPv4, so, we need to check if everything is working in IPv6.

.

This is not obviously only our concern, we see a lot of people working in IETF to have concern on IPv6 beyond the layer tree. So people go on IPv6 for their service 7 as well, so there is ‑‑ and featuring this a lot of older graphs discussing the multiple possibilities that we have on IPv6 on application layer. There is still ones that I am featuring. The first one is one of the most important that we are taking into account in this presentation.

It's showing some guidelines on testing IPv6 in applications, specifically for the integration tests mostly, when you have to check not only the running code itself but have in mind and checking out the infrastructural around the application itself and includes the connectivities between client and server. The second one should bring some guidelines on how to plan the deployment of IPv6 solely data centre, not only from the technical side but also from the business side, how to convince the non‑technical people that IPv6 is important and how to plan this deployment not only if you don't have a data centre and you are planning to start a data centre, but also to migrate one IPv4 only data centre to dual‑stack and eventually to IPv6‑only so you have explaining a lot of things to have in mind not only from the networking team, but also for the development team, how to plan that, how to bring tests for that, and how to check if the libraries, for example, you have here ‑‑ by the way I see Jen Linkova here, she is one the authors of this, so thank you Jen for being here.

And the last thing in this list is trying to propose an interesting way for saying over HTTP that content only may be available over IPv6. Basically it's not available over IPv4 and you should re‑try over IPv6 to try to reach that content.

So, for the draft for IPv6 data centre, there is a list of hard‑coded IPv4 in your source code, verbal expression, validators, ACLs, maybe you have ACLs in the firewalls for IPv4 but it's broken something that is crucial for your application over IPv6, the logging formats, we see a lot of cases where, for example, people are starting to log the source IP from the communication. And code only has 15 characters which can handle a IPv6 address, where there are much more characters needed. Libraries and frameworks, so, Java , for example, has some restriction, you have to change one flag there, to give reference for IPv6, for example. And also from choices on DNS resolution on your application as well, but on the function that you use it will return IPv4 only. So you have to have this in mind as well.

Monitoring. The geo systems are not much used through IPv6 as well. It's mostly working for IPv4. And authentication and security systems.

.

Moving ahead for testing the application itself. Going for the connectivity scenarios.

Bring some different combinations of connectivity scenarios between the client and the server which includes IPv4 only, dual‑stack, IPv6‑only with no transition, translation or transition between the client and the server. And IPv6‑only with transition technique either of the client or on the server side. So for the client it's NAT64 and for the server SIIT DC techniques.

Then, what when you bring all this content through our peers, create with them a plan on how to deploy the applications on IPv6. People, even though they understand the task, actually in the first conversation they are not even programming the development, they are not developers involved in the conversation initially, then they have to ask for the second wing for example to involve these people to bring them as well to care about the IPv6 on the application, then when the conversation evolved, they are convinced of the need of the task of IPv6 support, they complain that leaving this both network environments is difficult, so, especially developers are not that used to working with network environment, reproducing transition technology is even harder for them and having a kernel network environment and testing scenario between the not working and the SRA teams and the developers is kind of difficult to have the kind same exact environment. So many times things work on the developers computer, even if they are home a lot environment, when it goes to production, it's difficult to have. So we try to propose a two base especially on the app testing graph to make it easier to do, to create ‑‑ to set up this environment for a test. So we created the v6 bench. It's an OpenSource tool that we are still in the early days of development. That's based on this v6 draft, the labs testing. It's an automated creation of the network environment, should do these different combinations between client and server to run the test. It allows the automated or manual integration of your testing.

It's OpenSource and you can use it, and also send some code, some improvements or suggestions on anything, so just as any OpenSource project can.

.

Well, this here is the architecture that we have in mind. So, you can even task applications that are, that you don't have control over the server.

So you are hiding someone else's service, some API or something like that. It's an external, the infrastructure of the server itself is external, but you have ‑‑ you need to have control of the client side. You run the v6 bench in normal computer, and then the v6 bench will create the whole network infrastructure, not only emulate the client itself but you also run the transition techniques and you get the v4 and the IPv6, the multiple services for the service side, using the DNS as a tool to create that.

So, we only require the server to have dual‑stack connectivity, and the client to have dual‑stack connectivity and then we can emulate all the strings using the v6 bench. From the client side we have this firewall with network configuration that allows only IPv4 or IPv6‑only connectivity, and for the server side, we have this rogue DNS server who creates like super lanes that only runs for this lab for this environment, that only has ‑‑ that has like the dual‑stack, IPv4 only, IPv6‑only, and sit domains that only have the specific IP addresses that we need to include in the test. So it creates this whole environment.

And then we can run the test.

Okay, and this, by the way, is Docker containers, so it's plug and play and also expandible environment.

So you run a comment, it creates the environment, runs the test and then for a second comment, you can delete it and you don't even need to carry out, about maintaining the infrastructural running later.

The usage work flow is made to be easy, so, the initial use case that we created was for testing APIs. So, these were for scribes, how to test for API for example, so you download the report of the v6 bench and install the requirements. We'll talk that later, it's not that complicated. The open API specification of the API that you are trying to test. It describes every endpoint and logs the conversation should be between the client and that endpoint, the kind of environment the client should send to the server and also the answer that the client can expect from the server.

You have to generates the DNS configurations on files for that rogue DNS server that we ran through, to create a different IP availability for the server.

Then you have to generate the ScanAPI test plan template using the open API file that you got. You have to customise the test plan, we only created like a skeleton of the test, just a template, and then the developers team or quality assurance team have to customise it to make it fit to the need of the application of the work flow of the application and then run the test and then check the results after that.

.

The requirements to run it: You have the client and server, on dual‑stack. For the client side you need to have root privilege of the transition techniques that's run on that. So you basically need also the Linux distribution.

I only tested on Ubuntu but it's probably compatible with any other distributor like Kathara and JOOL and Docker as well.

Okay, I have three slides for test workflow it. I have a quick video. I think share my video here:

.

Okay, so this is my video. I'll speed it up because I don't have much time left. I already have the environment ready to work and just putting in the v6 bench repo. I am getting ‑‑ I am installing the ScanAPI for to create the test plane using this ScanAPI.

For just installing the VM of Python, so it's not in the system itself, it's just on my user. So I am getting the description which I had on my machine that I already copied for my environment here.

It just sends a get request for the root of the domain testing. So the first test I am running with Google, I am creating the zone files, I am creating the task plan, and then I am setting the domain and also the variables for the test that I am going to include. Then I run the lab. This is speeded up.

The these are the results. So we have like the test from all the clients, the IPv4 only, the IPv6‑only and everything. Everything worked over all the domains, you can see that URLs, URLs that tested. Then you test against IPv4 only service for you to see the difference.

This is another page that I found that I can test over HTTP with IPv4 only.

.

Then I am doing all this setup again to create the test plane, to create the DNS zone files, setting the environment that I am using for the test.

.

Then I am going to run the test again and then we'll have the results for the test we ran.

I didn't ‑‑ keeping the video, the time of the test, I just put this, but it's like one minute to run the test. As you can see only the dual‑stack IPv4 client and the IPv6‑only with the NAT64 worked in the test. So, that's it from the demo. It's supposed to be easy to handle.

So let's go back to the the slides of the presentation.

So, as I mentioned before, it was meant to be initially for API testing, but if your client can be accommodated in a container, you can just modify the two and run for the client you have. The best part of it is that you can contribute for it as well.

So we are in the early days. We have bugs identified and we have more tests scenarios that can be done.

.

And with that, I am open for questions, thank you very much for your attention and that's it for now.

We have a couple of minutes for questions.

(Applause)

MASSIMILLIANO STUCCHI: We have one question from Jen.

JEN LINKOVA: It's actually a comment not a question. Thank you very much. Very cool.

I just forwarded your presentation to the authors of the draft so they now know there is an implementation. Thanks a lot for doing this, very cool.

MASSIMILLIANO STUCCHI: We have time for one additional quick question. No, we don't.

Okay then, thank you very much.

(Applause)

.

MASSIMILLIANO STUCCHI: With this, we conclude our first session. We're a bit late. I will see you again after the break. Don't forget to rate the talks, let us know if you liked this or not. Thank you very much.

(Coffee break)

.