RIPE 91
Main room
23 October 2025
9 a.m.
IPv6 Working Group
CHRISTIAN SEITZ: Good morning. Welcome to the IPv6 Working Group in Bucharest. I am Chris, one of the co‑chairs, and we also have Ray here in the first row in the room, the other co‑chair. And we put together an agenda for you. The first session is some administrative matters, and also a co‑chair change, and then we'll have two great ‑‑ three great presentations after that. And first, we have a Code of Conduct here for the RIPE meetings, and this is designed to make everyone feel welcome, so please treat everybody with respect and be polite to each other. This is a hybrid session. So, remember this is being recorded, so, please turn your mobile phones to silent mode.
Our thanks to the stenographers, as always, and to the scribes, who are taking the notes for this meeting. We sent the minutes of the RIPE 90 meeting to the mailing list some, a month ago and there was just a small fix, but no further comments. Are there any comments on the minutes? Also online? Okay, then the minutes are approved. Thank you.
And for the newcomers, just a few words about the IPv6 Working Group. It exists to promote IPv6 adoption, and these are the activities of the Working Group from the Charter, which is also on the RIPE website, and we always try to find an agenda that covers these activities. And it was formed 30 years ago, yes, and I think it's still necessary to promote IPv6 adoption because sometimes when I talk to people at organisations they think they don't need IPv6, or when I talk to vendors, they still don't have feature parity with IPv4 because they say the customers don't demanded it. Okay, let's continue to promote IPv6 adoption here.
So, how can you participate? We like to participate you in this session, if you are in the room you can just go to the microphones, state your name and affiliation and ask your question. And if you are participating remotely, or if you are in the room and don't want to go to the microphone queues, you can log into Meetecho, ask your question in the Q&A window. Please also state your affiliation and we will give your question to the speaker after his presentation.
This time, we also have a co‑chair change. So, the term of Raymond ends at this meeting. We sent an announcement to the mailing list looking for new co‑chairs, we had three people who were interested, and after the deadline ended, we sent an e‑mail to them and asked them if they are still willing to co‑chair the IPv6 Working Group, and after that we only had Wolfgang left, who is still willing to co‑chair the Working Group.
(Applause)
So, I would like to welcome Wolfgang to the co‑chair team, if there are no comments or objections, Wolfgang already got some support on the mailing list. Thank you Wolfgang.
Then Nico Schottelius resigned from his co‑chair position, and as we do not think that changing two co‑chairs at the same meeting is a good idea, we decided that Raymond will take over his remaining term until RIPE 94, and then we will have a new co‑chair selection then, a regular co‑chair selection, and are there any objections or comments?
No. Okay, thank you Raymond.
Then I have some organisational parts from the NCC. Please remember to vote on the Programme Committee election by 5 p.m. today. If you have registered to vote in the NRO NC election, remember to vote by Friday at 9 a.m. And you can chat with the NRO NC representatives from 1:30 to 2 p.m. today at the meet‑and‑greet desk.
So, let's start with the interesting part and why you are here.
The first speaker is up now. He is talking about IPv6. What does it cost to do nothing. The floor is yours.
DIMITRY MELNIK: Thank you. Good morning everyone. Thank you for coming and welcome to our session. Today, we are discussing an interesting topic, how to not do anything.
So, simply relax while I delve into the cost of CAPEX or OPEX and Internet service providers and network and ‑‑ are you ready? So, let's start.
Before we start, let me share something with you. It's going to cost you a lot if you don't implement IPv6 in your network.
Firstly, let me introduce myself. My name is Dmitry Melnik, right now I work at the RIPE NCC as a technical trainer and development officer, and before joining the RIPE NCC, I operated B‑Line Network and I was a responsible for the development of IP connectivity and MegaFon in Russia. One of the latest projects I worked on was RPKI, and also training colleagues, and I actively participate in the project to launch IPv6 on their mobile network.
.
So, our agenda for today. We will discuss traffic. Later we will talk about IPv6 today. Of course, we will talk about NAT. We will discuss cost and at the end we will summarise and highlight the key points.
So, let me start with the global Internet traffic.
On the screen you can see some graphs which show you that Internet traffic growth from year to year. I am not a fortune teller yet, but we can assume that the Internet traffic will increase by 1800 percent each year or more.
So, talking about IPv6.
You are experts in this field, right, and I have an interesting question for you.
Is IPv6 the future or not? So, IPv6 is not the future and look at the screen. You are seeing a statistic of IPv6 adoption from APNIC, also from the Google, CloudFlare around the globe, and Google shows approximately 50% IPv6 adoption in the globe. So, IPv6 implementation is not just the future. It's already here.
So, if you can't see this high result in your network or even in your country, if your customers don't receive IPv6 from their operators, if another company has that large result in the globe, let's try to implement IPv6 in your network.
This is my third part, network address translation.
Let's say this is the typical situation in a network. There is already NAT here in the operator and also the customer has a router with a NAT also. People used to recommend buying more expensive model of the home routers which was able to ensure packet processing and high speeds. So we're paying for NAT at the provider's network and also at home because we don't have enough IPv4 address space. We are paying for NAT despite NAT has challenges, right. So, some of these challenges I would like to emphasise.
As you saw before the traffic grows every year. It can complicated, troubleshooting and diagnosing problems sometimes, and also you need to invent resources to dedicate to your team. You need more public IPv4 address space than ten years ago or more. And I presume that you have not redundancy in your network if you provide commercial services. So, of course NAT breaks end‑to‑end communications, and we have to use work‑arounds, but who pays for these work‑arounds? And the last important point that the NAT devices has a lifecycle, and one day your vendor will end support.
So, NAT has a temporary solution. Is it a really temporary solution if we have been using it for over 25 years? Capital expenses is invested in a temporary solutions: NAT. To solve the problem that we don't have enough IPv4 address space despite having enough IPv6 address space. Strange, right!
So, costs. Let's he check all types of costs associated with the NAT as a pie, and then widen this pie into the pot. The first part is IPv6 ‑‑ the first part is IPv4, and if you don't have it, you can rent it.
On the screen you can see some prices for IPv4 network /21. And I could say that the average cost of using an IPv4 network /21 will be around $10,000 per year.
The next will be operational cost for NAT. Let's look deeper into this. Operational cost can contain subscription for support services, also training for colleagues, implementing monitoring and logging, NAT maintenance. So, operational cost is sent on maintaining NAT functionality.
And the final part of this pie I want to highlight the equipment you need to install for NAT.
So, let's consider an example of a middle to large size operator.
The operator has 1 terabit of traffic during peak hours. The current NAT infrastructure due to end of support requires this operator to swap all equipment to new equipment, and of course the operator needs redundancy if one of the chassises breaks.
We will consider two scenarios. IPv4 only network and dual‑stack. In the first scenario the operator chooses equipment which can solve 500 Gbts per chassises. And let's assume the cost is between 400,000 and $700,000, and in this scenario 2 chassises are not enough. This operator has to buy 3 chassises plus one minimum chassises for redundancy and the total, it will be four chassises. In the second scenario in our case let's assume that IPv6 traffic will be 42%. Of course it depends on the country also and the content and the level of prefix adoption, and of course IPv6 traffic can be different from one country to another.
We need the same number of chassises in IPv4 plus IPv6 deployment scenario, I'm talking about dual‑stack right now, what do you think? The same or less?
Okay. In this scenario, we can say the operator in the first scenario will have more IPv6 traffic and in the second scenario, the operator chooses the same equipment with the same price, but just a small but very important difference, this operator already implemented IPv6 and has 420 gigabits IPv6 traffic. And another part of this traffic in their network is still IPv4, 500 Gbts during peak hours and this operator has to buy two chassises plus one minimum chassis for redundancy. In total it will be three chassises.
Let's check the cost for the first year. In IPv4 only scenario, first scenario, you have invested more money. It's just an example. We don't buy the equipment for just one year. And the traffic grows approximately 1800 percent a year or more. On this table you can see how IPv4 traffic will increase in these two scenarios. So, after the five years in the first scenario, we will have approximately 2 terabits IPv4 traffic, but in the second scenario, we will have just 1.1 gigabits IPv4 traffic. However, I don't have good news for you.
During this five‑year period, we also have to invest money in the NAT again due to growing traffic.
In the first scenario, we will invest in the third year due to a need to serve more traffic. And in the both scenarios, we will invest in the fifth year again due to growing traffic.
So, you can see the calculation here on this slide with the five‑year period in total is 1 to 2 million in CAPEX with just IPv6, just IPv6. It's a small but very important thing in your network. For the next five years this situation with equipment and overspending will be repeated, right.
So, also I have an interesting proposal for you. When you next upgrade your NAT IPv4 infrastructure, check how much cost, how much money you are going to save or lose.
What are the other benefits of reducing IPv4 traffic in NAT? You can terminate existing IPv4 address leases, or even offer your IPv4 addresses to others.
Let's assume that you are a large operator and you free up your /18 IPv4 network, and you may save or even earn $400,000 over a five‑year period.
.
So let me sum up. I promise it will be short. Only you can continue investing in NAT IPv4 or invest your money in something new in your network.
So, today, I tried to say why do nothing cost a lot and I will be happy to answer your questions.
(Applause)
RAYMOND JETTEN: Thank you. Are there any questions? I see in the room a few.
BENEDIKT STOCKEBRAND: Benedikt Stockebrand, IT. I think you are going way too easy on IPv4. If you could go back to slide 27 please. These numbers ‑‑ you assume a traffic growth of 18 percent, right? For both IPv4 and IPv6? But we still have an increasing part of the traffic being IPv6. So, these numbers are actually rather in favour of IPv4, because we are moving away from IPv4 even at a surprisingly slow rate, but the actual cost is higher. So, the actual cost for IPv4 is higher.
DIMITRY MELNIK: This is where costs ‑‑ this is the traffic, and after that I calculated the cost only for the NAT infrastructure. And only for IPv4 traffic which is going through the NAT system. IPv6 traffic will go, not in the NAT infrastructure.
BENEDIKT STOCKEBRAND: Exactly. And the point you assume they grow both at the same rate but IPv4 is growing slower. So if you don't move towards dual‑stack, it will cost you even more money because then you have to pay these 18 percent increase for all your traffic, whereas if you do dual‑stack, you have less than those 18 percent increase for IPv4 that you need NAT for. You can even save ‑‑ or you will say even more money than what you have shown. So, just ‑‑ it's even worse than you say for IPv4 only.
AUDIENCE SPEAKER: Thank you for your presentation. Although I am a bit conflicted I must say. I mean I I thought that we were not trying to convince people to deploy dual‑stack at 2025. Your example mentioned an operator with 1 terabit of traffic. So you are clearly talking about existing operators. If we are trying to convince existing operators after 25 years. Then we haven't done our job in the past 25 years. I think that most if not all operators, at least have deployed dual‑stack, and I believe that we should try to convince new operators to get into IPv6, but not through dual‑stack.
DIMITRY MELNIK: Thank you very much for your question. Good point. But also this calculation will be true for another type of, if we are talking about slot, and also if we're talking about migration for IPv6‑mostly, because the goal of this presentation is to show that what will be different, because if you don't implement IPv6 in your network or even if you implement it. Thank you very much for your question.
AUDIENCE SPEAKER: Just to give you a bit of perspective from our side of the world. Typically when we are seeing people deploying either dual‑stack or 464 mobile networks or whatever a lot comes down to the profile type of the users they have. If you have got a high residential mix we're seeing upwards of 80% IPv6 because it's all content. Most of the traffic is content. Enterprise is and will continue to be everyone's bugbear because, as I say quite often, an enterprise admin would rather pull his own teeth out with no anaesthetic than deploy IPv6. And this has not changed. So whilst the operating community have it together, it's the enterprises we need to actually do things.
DIMITRY MELNIK: Thank you very much for your point. Yeah, this is a presentation mostly for large operators, or middle size operators. If you are asking about my opinion, I definitely agree with you that firstly we have to implement IPv6 in the content operator and the large operator, middle/large operator, yeah, and we have to engage and try to influence people to help them to implement IPv6 in enterprise network. Thank you.
SEBASTIAN BECKER: Sebastian Becker, Deutsche Telekom. I totally agree about the enterprise part, but also there is that nice little thing with all the home appliance or Smart TVs or something that simply cannot do IPv6, and so still there is a lot of communication on that part. So, even if NetFlix or whatever doing IPv6, as the TV or the client cannot do it they cannot adapt that, so you have also these weird traffic figures here, even if you have fully deployed IPv6 or dual‑stack as we did. Still a lot of traffic is IPv4 because all the stuff people buy at home is not IPv6 ready. So, please stop buying shitty things.
RAYMOND JETTEN: I think we have a question online. We'll take the one in the room first.
AUDIENCE SPEAKER: Just wanted to pile on the administrator needing to get their teeth pulled. I would like another point where I think as a community we are weak, not a community, our industry, it's on the teaching side. As long as we have the young people will getting the cursors explained by v4 addresses, we are not going to solve this. And that's a plea for everyone who has contact with any school or is able to conveyance teachers to update their cursors, I think that would be something to do in the long run and maybe not needing no anaesthetic.
RAYMOND JETTEN: We have two questions online.
AUDIENCE SPEAKER: The first question is "Can investments in IPv6 be seen not only as a technical upgrade but also as a strategic step towards the financial sustainability of network operators?" The second one: "What initial steps would you recommend for companies that want to start IPv6 deployment but are limited by budget and infrastructure resources?"
DIMITRY MELNIK: Yeah, thank you for this interesting questions. I will start with the second one. In my opinion, if you already a network, and in any way you have to upgrade your NAT infrastructure. And if you have to upgrade your NAT infrastructure, you have to find resources for this. And the good point what you can do, you can change your internal procedures be and use internal procedures to implement IPv6 in your networks. And for the first one, can you repeat please?
AUDIENCE SPEAKER: The first one was "Can investments in IPv6 be seen not only as a technical upgrade but also as a strategic step towards the financial sustainability of network operators?"
DIMITRY MELNIK: That's obviously yes.
BENEDIKT STOCKEBRAND: I'd like to add a couple of things. First, when do most good people go to the dentist, when they can't stand the pain anymore, which usually means it's too late. Second thing about, what to start with? I have got that question over and again, and there are basically two answers to that that I have come up with.
First, if you have a certain need for IPv6 in some certain area, you have to solve that first somehow. So, if you have some business partner or whatever who insists on IPv6, you sort that out first. But other than that, you go for the low‑hanging fruit. Just start somewhere where you don't need much budget, much people, much anything. If it's just a student working part time for your company, tell him, see about IPv6, that already gets you started. I have heard stories about things happening where one student basically deployed IPv6 in a data centre. That's where you can go. And there is no need to go for a big global plan for everything which always grinds to a halt, but just start somewhere where you need it or it doesn't take any particular resources. That's something I have learned aside from what you say.
RAYMOND JETTEN: Okay. Any other questions online? Okay. Thank you.
(Applause)
.
Our next talk now.
WILHELM BOEDDINGHAUS: Good morning. Thanks for being here. I have done a lot of IPv6 projects in large organisations, some of them being in the commercial field, others are in the federal programme of Germany, in the IPv6 programme of Germany, which has been running for the last few years and just I think quite successful. We have learned a few lessons, what happens if you go to large organisations and try to move them to IPv6.
A few words about me. Not much. I would like to connect on LinkedIn with you. The rest is in the slides.
So, I want to look at four different areas in this presentation. This is training, the inventory of your stuff, this is the address planning and always the question, where can I start? We had this in the discussion after the last presentation. This is always a question where to start, and how much equipment, how much networking do I want to choose for a start?
So let's start with the training part. We also had this in the discussion. And I want to comment on the last presentation. There was one comment about education in universities and schools. My son, who is also here in this meeting, he had a course in his university, first year of university about networking, not about IPv6, about networking. And in the end they had one slide about OSPF and one slide about BGP. That's it. So we don't like IPv6 education, we like networking education.
So, we wanted to change now IPv6 programmes, and we went to our customers and said, well, everyone has to learn about IPv6. Your whole IT department has to learn, everyone has to be an expert, because then you as a customer can make an informed decision about how to implement IPv6 in your environment. And you are not depending on us as consultants, you are not depending on other consultants, but you can make all the planning, and you have the freedom of IPv6. And we need your whole IT department and everyone has to listen to us for five days of training minimum, and absolutely make sure that all of your developers know about IPv6. That is very important because they have to develop IPv6 software. And the customers reaction was, we don't have the time, We have other things to do during our daily work, We don't want to spend that much time, and we don't want to spend that much money on IPv6. IPv6 has to be cheaper. So we are not booking your training.
And if we had the trainees in our courses, they said, that is too much detail, We don't need that for our daily work. So please shorten your courses and make sure that we just get the necessary information that we need for our daily work. We don't want to do all this planning, we don't to be honest make an informed decision. Tell us how it goes, but don't bother us with training.
And this was especially true for the software development part and I am speaking about enterprises and I am speaking about public agencies, I am not speaking about software developers in this room, they are not interested in IPv6. They want to know how to open a socket, maybe they want to know the name of the library that they can parse IPv6 addresses. That's it. They are not interested in anything more. When we say we have segment routing and the developer has to create a packet already with the segment router heading pre‑filled, no, they don't want to do it. They just want to send out their traffic, that's it.
So, we had to learn that we had to shorten our courses. We cannot get the IT department for many many days out of their daily work, and not everyone wants to be an IPv6 engineer, and the server administrators don't want to learn BGP. Maybe they should for redundancy in the data centre, but they are not interested. They are not ‑‑ here this audience in this room is not the typical IPv6 guys that we find in the enterprises and in the State agencies. And the management has a budget constraints, they don't want to spend the time and the money, and don't want to send their people on training.
So, we have to cut this down to make it, let's say, edible for enterprises and for public agencies.
About inventory. The first questions we have to ask, do we have a configuration management database? And very often the answer is no we don't. We have no idea what's running in our data centres. We don't know which software revisions we are on, we don't know when we have done updates the last time. We don't have this one single source of truth. Maybe they have an excel sheet. This is quite typical. Hopefully they have a backup. But the great advantage of Excel is that you have different versions on many laptops throughout your IT department. So, nobody really has an overview of what is running in your network.
Then you are going to do IPv6. No. Usually not.
We need at least a rough inventory that we know what is in the IT, but if you do the inventory for IPv6, don't be too detailed at the start. Of course you have to be very, very detailed, as soon as you want to implement IPv6 on a device, but for the start, it's okay if you have a rough inventory.
You have to answer two questions. One is: Where is my starting point? Where do I start my IPv6 adoption? And we tend to speak about IPv6 adoption because most enterprises and agencies want to run dual‑stack first, or they have to run dual‑stack first, because the migration always means we have to turn off IPv4, but this is not realistic as a goal for them.
The second question is: Does my gear run IPv6? So you need some kind of inventory. But for IPv6, it needs just to be rough. You just have to get an overview.
If you don't have one of those configuration management databases, IPv6 might be a good reason to start one. And a number of companies and organisations who started with this type of database and used a professional tool, when they started with IPv6, but this will delay IPv6. Because if you take IPv6 as a good reason for starting another project, and a configuration management database is a large project, then it will delay IPv6. So we have to make sure that it doesn't get in our way too much.
If we implement IPv6 in a network that has no documentation or no proper domains, then we have more chaos after the IPv6 implementation than we had before.
So, some documentation has to come first, and you cannot believe it, you go into all these organisations and you don't find proper documentation. I'm not talking about the last 3% of the documentation missing. Sometimes they have nearly nothing.
The second lesson we learned is you can spend years doing an inventory. It's a very, very good excuse for not starting IPv6. Everyone thinks we started IPv6 by doing the inventory and we just need two or three years for this. If you have consultants in your company working for you, these guys are sometimes interested in having long running projects. So, beware of this. Have a rough inventory, get IPv6 going and don't delay IPv6 because of your inventory that you are doing. It could take a few years, of course, in large organisations.
The same is true for address plan. The first question is, do you have an IPv4 address plan? And some companies don't have one. Do you have an IPAM tool? No, it's too expensive. We don't have the knowledge to run one, we don't have the time to fill in the details. And some even advanced from a sheet of paper to excel sheet. So, they have something digital, but again they have many versions, nobody really knows how IPv4 is implemented, and then you want to start with IPv6. Maybe not a good idea. Some say the DNS is always a single source of truth. No it is not. Because that would mean that everyone is documented in the DNS. Usually it is not.
So, again, companies say let's make a detailed address plan. And then they try with the address planning, they have no idea where to start and they do address plan, the first revision, the second revision and the third revision, and they still have no real clue how IPv6 should be implemented in their organisations but they do address planning, and they are active and IPv6 is going forward. No it is not. It is again a very, very good excuse for not implementing IPv6.
And then you have got these consultants, I have seen them in many projects, and some of them have no real include how to write IPv6 address plans, but as long as the customer knows less than you do, everything is fine.
And again it takes a long, long time. We had planning times of ten years and the organisations wanted to do planning and have everything ready in nine years, and then in the 10th year they want to implement everything. This will not work out.
The second lesson that we learned is if you have large organisations, you have got all these little kingdoms in your organisations. And if you ask any of them, and they have no clue, but they have an opinion, then you will delay IPv6. This is quite easy, and everyone wants to have a larger address block than the guy from next door. It's not about technology. It's about, I have more addresses. And then you cannot plan your IPv6.
So, what we think that you have to do is that you have to give yourself a few rules, quite easy rules, for the AP location, nothing unusual. Use half of your addresses because you have to leave room for change. And some organisations don't want any change. They say okay we make our IPv6 address plan and that is valid forever. They want to chisel it in stone. This does not work out. The world changes. And this is where artificial intelligence comes into play because it's a good argument for you, you can tell them you didn't know about AI two years ago now you are planning for it, so what will be the next wave of technology, the world changes, you have to adopt to this change. Don't use AI on the address planning, this is just an argument that new technology is advancing and is coming to your networks and is coming to your organisations, so you have to make sure that you can can adopt to these changes.
But some organisations, well they don't want to have any changes.
Don't spend years on your address plan. Do a rough address plan. Get into detail at this little starting points where you start your adventure. Assign IPv6 prefixes in your organisations. You, as the IT, you as the networking department, and answer any questions later.
So, ask for excuse later and don't for permission before you start. Don't build the next committee please.
So, where to start:
Look for a very small starting point. Don't start with the whole network. A few years ago I had one example on one of the German NOC conferences when they were asked how long does it take to implement IPv6 in a European backbone, and his answer was "a quiet Saturday afternoon". This usually is not true for enterprises or for agencies, they need a very small starting point. So you don't plan for the whole network. You don't plan for the whole data centre, and then start IPv6 everywhere. Because if things break, and usually things break if you implement a new technology, then you don't how to troubleshoot it if you have done too much in one go. So, find a very little starting point. This is what we recommend to our agencies in Germany when they start with IPv6. Maybe just two routers, put IPv6 on one router connection, and if you love the adventure, do OSPF at the same time. Not just two addresses, but start somewhere, show your organisation that IPv6 does not hurt, that IPv6 does not bite. That you can do it. And if something goes wrong, the explosion is not that large. You can go back and everything works with IPv4 as before.
Maybe a database synchronisation could be a good place to start. And we had one organisation that develops a lot of software so we want to enable IPv6 in our software development environment, and that I think was a very good idea because then the developers have access to IPv6 in the development environment and can get used to IPv6, can learn, can break things, it also would be a very good starting point.
So we have to look for a very small starting point.
If you have no idea where to start, of course the network is a very, very good starting point. The network connects everything. And you can bring IPv6 to all of your departments, to the routers, to the edge routers of the departments. And then they don't have any excuse anymore that they cannot run IPv6, because it is at the routers, you just have to get into their office space, into their data centre, into their production environment, whatever they have.
The network connects everything, and the network hardware usually supports IPv6 quite well. We had one case where they had 200 ‑‑ they have 200 Layer3 switches, and the management doesn't support IPv6 properly. The first good idea of this company was that you can register the switches by IPv4, this costs one licence. If you register the same switch with IPv6, it costs another licence. So, doubling the licences is always from a commercial perspective, a very, very good idea. And then this management system does not support a NAC with IPv6, network access control. They went to the window and said, okay, can we have this feature please? No, you cannot. Our Cloud version will support this.
Okay, German federal agencies and management in the Cloud. No. It will not happen. So they have to at least exchange the NAC radios window but maybe they put out all of the switches, but taking out 200 switches is also quite a lot of work just because a vendor doesn't support this one feature, this very important feature. So, most of the time the network hardware is doing quite well.
So we can start in the network.
And very often the IPv6 adoption is started by the networking team because it is a networking protocol, we all know that all other IT departments have to work with IPv6 as well but it is a Layer3 networking protocol.
If you start, don't forget DNS and monitoring. And then these organisations come to us and ask then we have to enable IPv6 in the networks with the monitoring and the DNS dual run and we don't have a small starting point, it gets large for the first step. And the answer with this protocol is no, you can transport all this information, even IPv6 information via IPv4, so you don't have to enable IPv6 in your very first step. It should be quite early in the programme in your project that you enable IPv6 as a transport protocol on DNS and monitoring, it makes everything easier, but for the beginning, you can get the IPv6 well use via let's say SNMP from the router via IPv4, and you can show them in your monitoring. So this is nothing that can stop you, that should stop you.
Of course don't run IPv4 DNS and IPv4 monitoring for many many years, or using it as a transport protocol but you can do it for the beginning.
So, to wrap it up. Lessons learned. Large organisations tend to start Working Groups, debating clubs because everyone is important. You have got these little kingdoms. And if you run these Working Groups in your organisation you are doing something about IPv6, but you don't have the responsibility that you really have to implement it. This is quite important for this organisations, make sure everyone sees that you are active but don't do any real work.
Large organisations want to write concept papers for years. We had one organisation where we did a workshop in February, and they didn't know how to distribute their IPv6 addresses in the organisation, and we scribbled that on a flip chart. Maybe we talked an hour about this topic, and then they needed another nine to ten months to write this down. Great idea. So no IPv6 implemented, but they have they have nice paper and they discuss topics for too long a time. They ask everyone in the organisations, and these guys have no clue because they have not done IPv6s so far. So you don't get a real good opinion from them, or maybe you get an opinion but no real information. And then it's quite important to have steering committees and IT boards, So everything that helps you to delay IPv6. And they are very good in delaying IPv6, these large organisations. What else do you need for IPv6 that is also things that we learned?
.
You should have management attention. You can start your IPv6 as a grass roots programme. Like, one student, I think Benedikt you said this, this can work, usually it will not work for a very long time. You need some good organisation behind it, you need management attention, maybe your CTO, maybe your head of IT, whatever your people are called in your organisation. You should have some budget time and money of course to get IPv6 up and running, grass roots works for the beginning, but it does not work in the long term.
It is absolutely easy to delay IPv6, and we have seen this for the last 30 years, as Christian mentioned, this Working Group has been active for 30 years, and we are still struggling to get this education into universities, and we still need this Working Group, our work should have been done but it is not.
Do just enough planning and training to get yourself started. Don't ask everybody start IPv6, get going. It is possible, but the organisations like to delay it.
.
And then with many organisations, we have done the three parts at the beginning: Training, we talked about inventory, we talked about the address planning, they said okay now everything in theory is done, can we start with implementing? No. Why? Can't we do a little bit more planning?
So this is a big step for these organisations. And maybe the big step is that now someone is responsible that IPv6 is up and running and working and that your organisation, the IT of your organisation does not explode or implode or whatever you want to do, now it gets real. And this is such a big step. Maybe for us it is not because we are networking engineers and we say okay, put the address on there. But for them, it is a really big step. Even if you do test labs before and they have trained everything and they have tested everything, they say put it into the production network, they say no, no, no, nobody wants to be responsible, so the step from theory to practical use is larger than I ever imagined in these organisations, in large enterprises, and in large agencies. So, we see this all the time, and we have to get our customers and our clients over this step so that they really start implemented, and then they will see that IPv6 does not bite and does not break things and that they should advance and they should have IPv6 in the networks.
This was a few lessons that we learned. Most of these lessons are about people, are about humans, and not about technology. Technology often runs quite well, but then the humans have to say okay, I really want to do this, and we don't find this in too many of the organisations.
.
Thank you very much for your attention.
(Applause)
RAYMOND JETTEN: Thank you. Any questions, comments?
AUDIENCE SPEAKER: Jan. Sorry if I missed it while I was getting my mic set up. Have you actually mentioned, or do you have opinions on long term infrastructure replacement plans? Because from my experience, especially in the picture you paint with very slow moving orgs, you might get a situation where oh we'll just replace the hardware on the system and we are not going to replace anything in the next ten years and that doesn't support v6. So I think it might be rather important to, in the early stage, make sure that you know about any upgrade plans and make sure v6 requirements are incorporated early so you can stop the bleeding while you are focusing on fixes existing infrastructure and making sure that at least new stuff does what you want by the time you get there.
WILHELM BOEDDINGHAUS: Usually some of these organisations say yes if we buy new stuff it has to run IPv6. Of course it has to run IPv6. But it's just a check mark. They have no possibility to do anything in the test lab. Even it's worse in software development if you don't have IPv6 in your software development plans, either buying or writing software. Then you get stuck and you get stuck there. You said something about using equipment ten years. No, they use it longer. We all know about end of service, end of life, end of software development, end of security patches. Whatever the vendors call it, but I learned about a new category, it's end of eBay. If you don't get any replacement equipment on eBay anymore, so this is a new category some organisations use, I have seen that in enterprises and I have seen that in estate agencies, we say no, you cannot run your IT on this old equipment, but they do. So, sometimes the ten‑year old equipment is the newest they have. Of course, you have to make sure that the ‑‑ that if you upgrade that you get IPv6 capable material, but they have no test labs where they can prove what the vendors promise and they of course promise everything.
AUDIENCE SPEAKER: Thank you for the talk. I would like to ask whether you also see what we see with the RIPE NCC, and that is our suppliers that are supplying our internal systems are slowly discontinuing the OnPrem solutions in case of III S. And usually those are v4 only. For instance, we have been managing our company laptop with something call Yamouth, it has been running dual‑stack for ten years, then they say this OnPrem version up to date work anymore, they save you have to switch to our Cloud version. The same thing with Confluence from Atlassian, I like to name them because that's a shameful for them, but it's like, you know, so basically we have been even earlier to this game, we have tried to run everything on v6, but somehow with the new product we are sort of late because switching either WIKI or internal mobile device management is hard. It's sort of like, we have forced to go back to v4 only. Do you see this also with other enterprises and do you have any help with this?
WILHELM BOEDDINGHAUS: No, no, no idea without violence, so, I'm not going down that road. I think it has nothing to do with IPv6 and IPv4, many vendors want to force you into the Cloud, and there are international companies who say okay, this is the way to go, we have our Cloud programme, we already run a lot of our stuff in one of the major clouds, and we don't care if it is an American Cloud. But you cannot put management for federal agencies of Europe into the American Cloud. You should just not do it because it can be turned off, and we know that the Americans at least have the right, I don't know whether they do, they have the right to read everything you are doing there. And maybe shutting down is even worse, that if you lose your management or if you lose your internal documentation. So this is no way to go. But we see this for many vendors who want to force you into the Cloud. And Atlassian Confluence is just one of them but there are many others. As I said they switch vendor, they are also forcing you, I think if you go to Cisco, they will tell you something about the Cloud‑First or Cloud only strategy, so it is all of the vendors. So the only way I see is either using a European Cloud, and now alternatives are coming up but they are not as far as the American Cloud providers are, or use OpenSource, if possible, for your project, and run it OnPrem, if you don't want to present all of your data to the outside world. Usually if you are a company like RIPE, maybe nobody it really interested in your data, so nobody reads your data, but if someone in Washington decides we are not going for tariffs, we are going for Cloud shutdown, then it doesn't matter whether they are interested in your data, you are offline. So, if you want to take this risk, well, you are invited, but maybe you want to be a little bit more careful there. But this has nothing to do with IPv6, but it has to do with development in the Cloud and new features. This was enough of ranting.
STEFAN: Stefan. As was mentioned laptop and labs. We have seen some zero trust stuff which reprioritised the addresses so that IPv4 was on the top of the list, and IPv6 was at the end. So, if you are going into the ‑‑ if you start to implement it, it's a good idea to be to the labs and look at the traffic. So, use your Wireshark, check if it's really IPv6, or if they prefer IPv4, or else you can have a really, really bad day as soon as you switch off IPv4.
MICK O'DONOVAN: Mick O'Donovan. Have you come across the idea of enterprises being lobbied by their cybersecurity firms to potentially not deploy v6, or moreover even pull back from using public v4 and just NAT in everything as a protection mechanism?
WILHELM BOEDDINGHAUS: You said about lobbying. Yes, if you have cybersecurity companies, if you have IT companies, who have no clue about IPv6, they always tell you, this is insecure. It is insecure because they have no clue. But you see this kind of lobbying quite often. The IT service companies that you employ have often no clue about IPv6, so they try to avoid it at all costs.
MICK O'DONOVAN: I genuinely think that that's part of the problem here, certainly in the enterprise field where there is a kind of scare mongering going on and IT directors are being potentially warned off, if they haven't deployed v6, potentially warned off it, because oh, you know, there is a, or maybe there has been a cyber attack, and the cyber insurance company come in and they say, hey what's all this v6 lying around? Let's just NAT everything and stop using kind of any public addressing.
WILHELM BOEDDINGHAUS: This is of course possible, and I think we see that in the background, maybe nobody really talks about it, but these companies maybe don't want you to implement IPv6. There will be the time when you have to, we talked about the dentist, didn't we. So, eventually they will come to IPv6 and then of course they have to do it quickly, and maybe they don't have enough time for planning, by I remember this argument, do it now, then you have time to implement. These arguments were on this stage for the last 20 years. But nobody moved. But yes of course, if these companies don't want IPv6, then they try to make the customers stop the IPv6 programme and, well this will not help the customer. But we recommend everywhere that if your support company does not work with IPv6, send them out. I think we have got this RIPE document about IPv6 procurement and then we have a chapter about consulting companies, and I think it says send them away if they don't support IPv6. And you have to do this. If you have the choice. Sometimes you don't have the choice.
BENEDIKT STOCKEBRAND: Disclaimer, I have been involved with the route 28 when it came to project management for IPv6 as well, we have pretty much the same opinion. One thing I want to add. This problem about a lot of people wanting to plan things for the next, until they retire, so they don't have to actually do anything on systems, there is one thing that also helps to deal with these people. 20 years ago, there was always one or two people in an organisation who actually wanted to push IPv6 where everybody else didn't care about it. These people still exist and if you find them, there is other ones that actually want to get things done and they will make things possible, so if somebody shows up, are you the guy who is supposed to deploy IPv6 in here? Yeah. Mind if I join? You keep those people at any price, they are absolutely invaluable and they put pressure on those people talking about oh we have to plan for the next 20 years. It's unbelievable how important these people are are.
RAYMOND JETTEN: We have some questions online.
AUDIENCE SPEAKER: One question again. "On page 17 of your presentation, you highlighted several issues large companies face when implementing and training for IPv6. What would you recommend to overcome these delays caused by over planning and lack of training?"
WILHELM BOEDDINGHAUS: Well we have ‑‑ if you talk about training, we have a conflict of lack of training and too much of training. They don't want to have too much training because they don't want to pay this. Maybe do enough training and get a good consulting company who can really help you with IPv6. They can show you the way how to do it and then you can learn on the way. And then you get the training by doing test labs, but not too much theory, not everyone wants to be an IPv6 engineer.
AUDIENCE SPEAKER: Then one last question from Monica it: "Do you know of any universities that are doing a good job in educating IPv6 SAVley network experts?"
WILHELM BOEDDINGHAUS: No. I don't have, I don't know about the curriculums of many universities but I think from what I have seen is that networking is not a real part of the education, they learn about databases, they learn about software development, but they don't learn about server administration, they don't learn will running operating systems too much, they learn learn the theory of the kernel of course, but not running the operating systems in the daily work, they don't learn too much about networking. And I am not sure if this university stuff, is it for other educations, so, are what are redoing there? But a little bit more of networking and networking theory and protocol theory would be nice, because as we all know, there is a lot of theory behind routing and routing protocols, it's not just turning it on, if you run it large scale, then you have to know what you are doing.
RAYMOND JETTEN: Okay. Thank you.
(Applause)
.
Our last talk.
JEN LINKOVA: Are hello. Thursday, I have not seen any single comic ASNs slides, so far, so I need to change this.
So, first of all, I have to apologise because I suspect some people might know thinks about I'm going to talk about already, but I do see some new faces so hopefully at least one person finds it useful.
Secondly, I will be mentioning certain client platforms, but I have nothing to do with them. I just found it very interesting block article and I decided the community might want to know about that.
So, this is a blog post which was published in September about Android supporting DHCPv6. Can you imagine. This might be note might not be the DHCPv6 you were looking for, so let's go back to the problem statement.
IPv6, it's not IPv4 with longer address space, right. So, it has some fundamental differences and one of the beauties, at least in my opinion, is that an IPv6 host fundamentally could and almost always has multiple addresses. So, this is a real scenario when my machine obviously lived local, yes, it has two prefixes on the network, so it has addresses in each prefix, stable address, temporary address, CLAT address, so I can count, I can only count to two, but this is definitely more than two. So what's the problem with this? Because this is actually useful, might be beneficial for applications for example, there is a clear reason why CLAT needs a dedicated address, at least for performance reasons and because you cannot do it stateless if CLAT doesn't have a dedicated address. All good things normally come with a cost. So let's say I have a machine, a laptop which runs multiple VMs on it. Each VM would have multiple addresses and the host system would have multiple addresses, it means that your network might need, well not might, will need to run state for all those addresses and most likely in multiple places. So, your smart wireless access points and switches might maintain some client table and check what IP addresses each client has. If you run VXLAN fabric, that's a router address. So think about your feed but your routing table size. And then obviously the first hop router will maintain a neighbour cache mapping each address to the MAC address.
So, it might not be a problem with your home network when you have, I don't know, 10, 20, devices but if you are talking about tens of thousands, it is becoming a problem, right. They just enter large price networks. I know some people in this room do not like what I'm going to talk about, but I'd like to point out that it's one of the possible deployment scenarios, so you don't have to implement it if you don't like it. It's something which some people might find useful.
So, what could we do about all of this?
.
By the way, I know that a lot of people like to be in control, right, I am a control freak myself. So while SLAAC and multiple addresses do provide some benefits to applications, and it allows end‑to‑end communication and so on, it might introduce challenges for network administrators besides the scale. We know it might be complicated if you have a SLAAC addresses and you need to maintain ACOs we will want to know what exact address was used in that moment of time. So, hard choice, right.
To be honest, about two years ago I promised myself I'd never ever go into participate into the discussion about SLAAC verse DHCPv6 ever again, but I keep doing it but I do hope it's the very last time I'm talking about this because we might to try to find a rough consensus here.
So, what can we do? We can actually do things which mobile operators have been doing for a long time. We can give a host a prefix. The whole prefix, /64. 64 bits ought to be enough for anybody, right. So, if your host acts like a CPE or like any host in a mobile environment and HTTP prefix gives them a /64, what does it mean for us? Is it first of all hosts still have unlimited number of addresses, as many addresses as the host wants to have and capable of having, taken into account our performance limitations on the host, not on the network anymore, right. But on the network we now not scale it to the tense of addresses per host. Your network like VXLAN fabric will have one type to route fully local, as before, but it will also have one type route for the delegated prefix. That's an improvement, right. Because I have seen VXLAN fabrics falling apart because of multiple addresses per client, and this is basically drastically reduce the load. The same for neighbour discovery cache. Now you need to maintain a single link for local address and one prefix coming from delegated ‑‑ one route coming from the delegated prefix to the link local address.
So, can we do this? Again mobile operators have been doing this. If you connect your phone, your phone connects to a network, it normally gets a prefix. So it's not like something unique.
So, what's happening? Android 11 soon ‑‑ well some people already noticed they even start putting blog posts about that, might now will support to most of the devices, but obviously not all of them because there are some vendor specific things ‑‑ will, if notice that router advertisement send the B flag to one, it's a new flag, evenly standardised, Android will see that flag as an indication that the network actually wants it to use prefix instead of prefix coming in PIO. Instead of assigning normal SLAAC addresses from the only unique, Android instead will ignore it and ask your DHCPv6 server give me dedicated /64, I would like to use it. So, in this case again, you will see benefit from scaleability, perspective for new clients, while obviously old legacy clients, because not everyone needs a prefix. If your host does not run VMs, does not seed extend network activity downstream, it just needs a couple of addresses, it's fine for it to use SLAAC.
So, at least it will as I say reduce the load on the network in terms of maintaining state.
So, B flag in RA, you think I do ‑‑ I'm not a aware of any implementations by vendors, we do have feature requests, how long it takes to get a vendor to add new configuration options for a flag. What can we do now? Why am I here talking about theoretical stuff? I'm sure that some people loves DHCP so badly that they actually want to run DHCP only v6 networks and because Android could not operate in such a network, they had to create a separate segment just for Android. I have good news for those people because now if you enable BT, Android will be happy on these networks because the heuristics built in this system now even if the B flag is not present, if device detects I am seeing v6 router but I'm not seeing any prefix, SLAAC prefix and POE suitable for forming addresses, let me try PD. Maybe this network doesn't want me to use SLAAC, but it may give me PD because it looks like it supports DHCPv6. So if you, in addition of giving providing addresses could give the host a prefix, it will just work.
So, we kind of tried to get the best of two scenarios, right. You still let host to get as many addresses as the host needs but on the expenses of the host. You need many addresses and you you are willing to maintain state for them, go for it, network does not need to pay for it anymore. And obviously, the host now extends activity downstream and statement you can getting all the these beauties of manage the network in terms of you know which addresses were used by the host because this prefix was just for this host and you control what prefix you give it, so actually if you want to build ACLs for example, per host you can do this.
Again you remove the scaleability of multiple addresses from the network, it's not network problem anymore, because yes I agree it was unfair, the host and application developers benefit from multi addresses but it's the network paying for it.
So, in the meantime, if you do not support BD, there is one more thing you might get if you running DHCPv6 server on your network.
A new feature, new option has been added to the DHCPv6. It allows the host which gets addresses via SLAAC or manually configured, the DHCP server by the way I know you did not give me those addresses but I have them. So you can log them and use them later for statistics or whatever you want. So basically there is a new registration option, so if your client notices that there is a DHCPv6 server it will actually tell that server about all addresses it's been using. This feature will be added to Android I believe around the end of the year, so it's actually pretty close, so it's implemented, it's just a matter of rollout. Obviously, it's not a silver bullet in terms it of it assumes that your host is not trying to do anything malicious, because obviously if there is a malicious intent on the host, the host might not just tell you anything. But for normal hosts you trust, it reasonably does give you additional information for troubleshooting and forensics when people complain they have no idea what addresses hosts were using an it's hard to troubleshoot and obviously unfortunately, streaming telemetry does to the scale very as well from the routers. I have tried.
So, readings. If you want to know more. And questions. By the way we are talking about education, I spent 45 minutes yesterday trying to convince AI to put the correct IPv6 address on the picture. It kept like a normal apologising, it did not do what I asked. So, no IPv6 addresses on this slide.
RAYMOND JETTEN: We have about a minute for questions.
(Applause)
AUDIENCE SPEAKER: Hello. Jan.
JAN ZORZ: Are there any plans to put the prefix delegation into SLAAC?
JEN LINKOVA: You want what, the prefix in ‑‑
JAN ZORZ: Being delegated with RA.
JEN LINKOVA: I have seen some discussions about that, about ‑‑ you know, how things happen, right. Someone has a problem, someone tries to solve this problem in a way that most people find suitable. If you think you have a problem which could be solved that way... it's not easy actually, because are you talking about the Comcast document about unique prefix per host where it was advertised. I did not want to write the draft, I was hoping I can use that, but I did not find any way to configure it. How my CISCO peer router going to give me unique prefix per host? There is no ‑‑ I don't even understand how to do this. You need client validation, you need configuration on your router to know that each client needs to get a new prefix. I have so many questions about how to do this, but if you have a picture of how it should be done, I am happy to talk.
RAYMOND JETTEN: All right. Thank you very much, Jan.
We have now come to the end of our session. And thank you all for participating after a heavy party last night, and time to go for a coffee. But please remember to rate the talks. Thank you.
(Coffee break)
.