IPv6 Working Group
Thursday, 19 May 2022
At 11 a.m.:
RAYMOND JETTEN: Good morning. Welcome to the IPv6 Working Group. If you are supposed to be at the DNS Working Group, your DNS is broken, sorry, go there, fix it. A few things. This is a hybrid meeting, so if you have any questions at a certain point, please add them to the Meetecho so we can make sure that everyone gets the turn when it's his turn or her turn or whatever. And the minutes were on the website and on the list for, I don't know how long, and I haven't heard any comments or complaints about them. Is there anyone in the room who wants to say something about them? No. So the minutes are now accepted then. Thanks for the RIPE NCC for doing the minutes again and then we have the microphone etiquette, once you go to the mic, and please state your name and affiliation if you have one, and I think that was the most important part.
So, you can see our agenda, we have a couple of presentations, one of them is going to be online, the second‑last one, everyone else is going to be right here. So, let's start with the first one, Wilhelm Boeddinghaus, please come over.
WILHELM BOEDDINGHAUS: Thank you very much. You can hear me? Welcome to Berlin, the city where I live. I have been living for the last 30 years. We had some bad speciouses with walls in this city but luckily enough this is over, it has been over for a long, long time. And today I want to have a look with you together into the IPv6 Windows 10 firewall.
So in terms, what is a firewall? Usually, if we network or speak about firewall we talk about network firewall, we have terms like outside, inside, in the wild, friend and foe, we have controlled and trusted areas so we divide up our network from the inside to the outside and we have the trusted part on the inside. I know there are many, zero trust initiatives who want to take that, typical enterprise firewall you see something like this. You have behind this, completed trusted environment. And because it's so trusted, this environment, we have many measures for security on our switches, we have router advertisement guides and snooping and binding tables so I don't see any trust here behind the firewall in our so‑called trusted area. What we are talking about today is down there on the PCs, it is not a network firewall, something completely different even if it has the same name.
Let's have a look into the context of Windows 10 firewall, how does this beast work? .
Your firewall rules and this firewall, Windows firewall are tied to prefixes, so you have a private profile and a public profile and a domain profile, you get your firewall rules from your company and the other two are self‑administered. And whenever you change places, your interface changes the profile and your firewall rule set changes so you have to look out, if you do IPv6 you have three different rule sets for different situations.
And to make it worse, you have local rules, the rules are given to you by Microsoft; then you have rules that come from your active directory server, by a group policy, so the admins of your company give you these rules; and then you have a makes tour of both that makes it even easier so you have the option to say, just use exclusively the rules coming from the AD server or you can say use the local rules and, in addition, you have some more rules, you get from your company.
So you have a mixture of profiles, sources of rules, responsibilities and this makes it all very, very easy, doesn't it?
And today it, we usually use two of the profiles, because if you are at home or if you are in a conference like this or maybe if you are in train you have one profile for your physical interface, you are connecting to the Ethernet and the wireless LAN and you get a second on your VPN interface and usually the admins of your company just care about the VPN interface, the domain VPN and the firewall rules there and it can happen you are totally unprotected while being connected to your company. .and the admins of the ‑‑ of your company should be responsible for the other rules as well but most of the time they are not, so you have two rule sets when you have a secure connections, you have two sources of rules and you have two administrators responsible for those rules. One of the sets, the responsibility lies at your hands and for the other rule set, your company is responsible.
So this is a mixture, I don't think it's very secure.
Okay, now. I said we want to talk about the IPv6 firewall rule set so let's have a look at this rule set, and let's start with default policies of your three profiles. We have the domain profile, the private profile and public profile, all three are active. All three are enabled. Here in this example just one is active, if you have a VPN connection then two of the profiles are active. And the first thing to note is that all inbound connections that do not have a specific rule are forbidden. And we, as network and as security guys, say usually on a firewall, everything that is not explicitly allowed is forbidden, the default is drop the packet. But here in the Microsoft firewall, the default for outgoing connection is allowed. Don't ask any questions. Allow it. So this is not very secure, in my view.
But this is the type of rules we have here and I think this comes from the Microsoft that they say everything has to work because they have so many customers worldwide they just want the PC to work, security is of second concern. Maybe this is not what we want today. So it is open at this place.
And then this fire well is not network centred, it is very services orientated, so if you see this example here, you have some Microsoft services like Microsoft edge, Microsoft pay, Microsoft store, of course you have to chance to spend money and it is open for all local addresses, for all remote addresses and any protocol, and any means here IPv4 and IPv6. So we find rules in this firewall set that are not specifically for IPv6 or IPv4, they are for both because they are tied to an application and they are not tied to anything that we networkers that we like to have, like a port number, like source address, like a destination address. So this is just open, for all of the profiles, it just says "allow" so you don't have this IPv6 firewall on a Microsoft system, you have a mixture of a dual stack firewall and some rules apply to both IPv6 and IPv4 and some are specific for IPv6 or for IPv4.
Then we find in the rule set, a rule says IPv6 out, here called networking in the core networking group. We have some firewall groups, rule groups in the fire well, and here is one that says IPv6 is allowed, any any. So, besides of the profile that opens up outgoing connections, we have a second rule that allows everything from IPv6. There's no restriction at all. And if you click on this rule, you get an explanation, why it is so. And the explanation says "outbound rule required to permit IPv6 traffic for ISATAP and 6to4 tunneling services." This is the reason why we have this general outgoing allow rule. So this ‑‑ for me, it looks like this firewall rule set has been designed many, many years ago and has never been renovated, that has never been ‑‑ they have never changed anything and suppose this came in out ‑‑ with Windows 7 and at that time maybe we had IPv6 in islands and we needed this firewall rule to connect these islands but today we don't have, if you look at any IPv6 Windows guide, they tell you to turn off Teredo and 6to4 but we still have this general allowance rule in our firewall rule set.
So, maybe this is just old. We find some rules for neighbour discovery, this is fine, we have to do neighbour advertisement and neighbour solicitation, and we need that working in our local network, this is absolutely fine. I put my computer to the English language because Microsoft translates everything and this is really funny. If you want to have fun, turn it into the computer in your language, look at these rules how the translations ask, ask some popcorn and beer, this is ‑‑ so they translated it. I put it in English because of you. So this is absolutely fine. This is an inbound rule and we have default behaviour of the firewall, inbound is allowed if I have a rule for it. And so here we have the rules and this is absolutely okay.
But then we have some more inbound rules, so we can get a router advertisement. This is absolutely okay. If you are in a server environment and you have static addresses then you might want to turn off router advertisements because you don't need them, you configure everything statically, but in a client environment accounting, marketing, whatever you have, getting a router advertisement is absolutely critical. But why I get a router solicitation? A router solicitation is usually sent to the all routers multicast group, and I have on this table on the right corner, shows the joint table of the Microsoft table, you can say show joins and you will see which multicast groups you are in and we are not in the F.F. 0: 2. But the firewall rules allows incoming router solicitation. Then Teredo is allowed, great idea if we turn off Teredo we should deactivate this rule as well.
These are the first rules where I could say we could be a little bit more strict.
And then we have outbound rules for our computer. Remember, the profile allows outgoing, we have got a general IPv6 outgoing rule but we have now a third allow rule for router solicitations, we need that because we have to find the routers in our network, but we are allowed to send out router advertisements. Are we a router? So luckily enough, we have router advertisement guard on switch, so we are allowed to send out router advertisements. I suppose this is again a very old feature called Internet connection sharing and if you turn on that and share your connection with the whole network, then you basically turn your Windows 10 box with IPv6 into a router. And then it would be okay that you send out a router advertisement. But in our modern environments we don't have Internet connection sharings, we don't turn our PCs into routers so there is no reason why we send out router advertisements. So we should block that and we should block the general outgoing rule and change the profile to disallow everything that we are not explicitly allow.
So this is again a very old firewall system that has never been changed from I don't know when. But Microsoft still claims, if you read the Windows there, claims it is advanced security. So I doubt this, to be honest.
The same is true for multicast. Here again we have the multicast listener query, this is the packet that is sent by the router to ask on the network when anyone wants to have a multicast group, if we are not a router we don't have to send out router only packets, we just have to answer to multicast packets so this rule could go away. Again, I suppose it is connection sharing again, why they have this in the rule set.
Then I found something completely strange. We have the core networking diagnostics group of rules and we have have got the file and printer sharing group, and both have rules for ICMP echo requests so even if you turn off that in one of the groups, it can happen that you have an open rule and allow rule in another group so they have two places in one rule set to allow the same packet and in this case, they do it for IPv6 and IPv4, so it is ‑‑ both is possible, but this is not security; we need one place for each rule and not two of those. I have not checked whether they have other duplicates in it. This comes, I suppose, that two departments of Microsoft put in rules into this firewall rule set, and nobody really made a quality check whether this is a good idea or not.
So, I was an a little bit astonished to find something like this in advanced firewall. Don't forget, this is millions of users on this planet use this default firewall rule set and everyone gets the false sense of security. So it's not about IPv6, IPv4, it's as insecure as IPv6 on these kind of firewalls.
So, as a conclusion, here we have a host firewall, we have not a network firewall like we are used to it in the usual way of firewalls. The firewall is generally very, very open. So we have three allow rules for router advertisements, the allow rule itself, the profile and the general IPv6 outgoing rule. Then we have a multi‑purpose operating system that is not tailored to your use; you use it at home, my mother‑in‑law uses it, maybe your father, your mother, whoever has no idea of Internet, they use this firewall, and it is used in the enterprise where you have admins who should know what to do but this multi‑purpose operating system has to serve all of the clients.
The firewall is ready for the PC to be used as a router, great idea, today you had we don't do this any more so I think we can turn this off. We don't do connection sharing, we can forbid these packets that are sent out by a router, because we don't want to make it too easy for an attacker and want to open everything and yes, if you have malware and you have this general outgoing rules, all malware is allowed to leave your PC. There is no protection but then it goes to the switch and maybe something happens there. But the firewall rule on the box does not forbid anything.
This firewall is quite application‑orientated so you have rules that are tied to an application and that's not to network protocol, like we have seen with Microsoft services, but there are many more. And if you install new applications on your PC you sometimes get the questions, shall the firewall allow incoming or outgoing packets and if you say yes you get a rule that is tied to the application and not to a protocol.
But I think this firewall should be part of your overall cybersecurity strategy, because we teach the users using these PCs and this firewall not to click on e‑mail attachments, to use strong password and multi factor authentication and let them run in the wild with a firewall like this and let them go to Starbucks cafe, and they have this open firewall and they are not protected on their physical interfaces, maybe a little bit better on the VPN interfaces but usually the firewall admins just take the default rule set and give it out via this group policies. So there is much to do for security on the end host and we have millions of them out there in small companies and in large companies.
Thanks for your attention.
(Applause)
WILHELM BOEDDINGHAUS: I see on this clock we have roughly seven‑and‑a‑half minutes left so I will bit faster than planned. Any questions?
JEN LINKOVA: We have questions in the chat from RIPE NCC... "nice presentation, should we expect improvements on the default firewall rules for Windows 11?"
WILHELM BOEDDINGHAUS: I don't think so. I have not looked into Windows 11, I don't think this will be any better, maybe we as a community have to come up with something but I have not looked into the Windows 11 firewall so far, it has not improved over the last year, why should it now?
JEN LINKOVA: Another question from Christian: "Is there a tool which firewall rules actually are used causing traffic?" Is there a tool which might be used ‑‑
WILHELM BOEDDINGHAUS: I don't think so. No. You have got the ‑‑ of course, you have got the administration interface that Microsoft brings with you and there you will see which rules are active and are not, most of these rules are not needed because outgoings everything allowed so there's no other tool I'm aware of. Maybe have other host firewalls that are a little bit better, maybe, maybe not, I'm not sure.
JEN LINKOVA: The last question in the chat, I don't know if it's the last question, from Kurt Kaiser, it's hard one I'm telling you." Why is there only slides link local /64 and not /10?"
WILHELM BOEDDINGHAUS: Because I think they are used at 64 in Microsoft environments. I think was it default, I just took it over. So no real answer.
JAN ZORZ: 6connect. So you are saying that this is still a good idea to protect the network with the centre firewall and not rely on this?
WILHELM BOEDDINGHAUS: You cannot rely on this but you have to use it because your central firewall does not protect your local LAN as we all know, and if we want to have a secure environment, then we need to use all possible firewalls, packet filters, all places, we cannot leave one out and Microsoft, in my opinion, left this out. So this is not really secure. And most of the admins and the users get a false sense of security because they have an advanced security firewall.
SPEAKER: This is ‑‑ plus telecom. I never expected I would would be on the mic for such a topic because I'm not a Windows user for as long as I can remember. However, I believe a default rule set is a difficult problem, so would you have a suggestion about what the default rule set should be on all Microsoft Windows PCs and we are talking about and user PCs, not servers on the network?
WILHELM BOEDDINGHAUS: It is very difficult to come up with a real new default rule set because it is so application‑centric. I have no idea what software you would install, but I would be more strict but maybe we as a community can build a better rule set or have some suggestions, but it really depends a little bit on where is the PC used, is it very strict environment, let's say in the government, or is it a very loose environment at your home, and I know many of you have Apples and Linux and not Windows users, out there in the wild we have so‑so many Windows and all this false sense of security, this is why I came up with the idea of this presentation but maybe we should work on this, yes, there is work to be done.
SPEAKER: Perhaps you should raise the subject on a mailing list, or ‑‑ yes, something that can raise, let's say, a discussion.
WILHELM BOEDDINGHAUS: There is initiative ‑‑
SPEAKER: It is a difficult problem as you mentioned because there is lots of different categories and needs, and Microsoft needs something to work out of the box for everyone
WILHELM BOEDDINGHAUS: Yes.
SPEAKER: Very difficult.
WILHELM BOEDDINGHAUS: It is absolutely difficult to please everyone here.
SPEAKER: Thank you.
WILHELM BOEDDINGHAUS: There's another question.
MARIA MATEJKA: From cz.nic speaking for myself. I would like to say that one problem is a do open firewall and the other problem is a firewall that asks you every time you connect to the Internet and you are trying to send an e‑mail whether this is in approved connection, and I'm afraid that the area of do open firewall and the area of the two closed firewall is in fact overlapping so that we can't find any useful solution to have the firewall not to open and not already too closed, which if the firewall is too closed, the users will get used to the thing that if something happens, if Windows pops up, is that connection okay, they just click okay and they don't think about it, which is, I think, maybe the same kind of problem.
WILHELM BOEDDINGHAUS: They cannot think about it because they have no idea, my mother‑in‑law has no idea about packets and ports and networks. But maybe the enterprise admins, they can do something and they can have ‑‑ make better rules for their environment and they are attacked, they have the random ware on their systems, it's not the user at home, it is the enterprises and they are in the responsibility to do something here.
MARIA MATEJKA: Thank you.
JEN LINKOVA: I am trying to put myself in the queue, I just don't have a button. I have not been using Windows like for years also, and I am just wondering if those rules especially related to neighbour discovery might be use if doing virtualisation and have multiple machines on the same device, I don't know,
WILHELM BOEDDINGHAUS: I don't think so. You don't need to send them ‑‑ these packets to the outside and virtualisation is enterprise feature and admins should know what they do.
JEN LINKOVA: I think a lot of random users who don't have Windows in any domains just play with virtual things on laptops
WILHELM BOEDDINGHAUS: I don't think you need the advertisement there.
JEN LINKOVA: I never looked into how it's supposed to work.
WILHELM BOEDDINGHAUS: Okay, thanks very much.
(Applause)
RAYMOND JETTEN: On the second, next is Paolo Volpato.
PAOLO VOLPATO: I am with the European standards department of Hugh and as you see from the my talk is about IPv6 deployment. IPv6 deployment status is also the title of a draft RFC, we are just publishing it, at the v6 Ops Working Group of the IETF, is almost finished, I would say. The goal of the paper for sure is to give an update of IPv6 deployment today and in doing that we trying to obsolete an old RFC, discussing the same topics but being probably 10 or more years old. And also the second call is to analyse the remaining challenges still to be addressed for the full transition to IPv6.
I think that some of you may remember that we already presented the, let's say, first results of our analysis a year ago at RIPE 82, so the goal today actually is, for sure, to give you an update of the key findings, we will continue to discuss the challenges about IPv6 adoption, but actually, we would like to listen to it, so to listen to the RIPE community and see if there is anything that is still missing or maybe there are new ideas to be discussed in that area.
So let's start from the trends. So you see here the total number of IPv6 connections is measured by APNIC, which is the blue line, which is also the measurement we have adopted in our draft, compared against the same measurements done by Facebook and Google. So you see the result there is up to the beginning of May this year, we are speaking of something between 30 and 39%, as I said, total IPv6 connection worldwide. There are two things. So the good news is that IPv6 is growing faster than IPv4, at least if, with the term IPv4 we mean the total Internet population, I would say. And the second point is that this chart is somehow incomplete, saying with different words, it's probably the western world view of IPv6. Why am I saying that? Because the route end users in some specific countries that don't get access to those providers, for example, in doing our analysis, we were contacted by a few Chinese researchers that pointed out that, for them, there are users that don't connect to Facebook or to Google and as such are not counted in the overall measurement. So, roughly speaking, they suggested you should at least increase your numbers by probably another 5%. Best case, using the Google statistics, we are approaching 45% of the total connections so you see probably that witnesses the positive momentum of IPv6.
And speaking of positive momentum, you will see at the top a sort of summarised history of the milestones associated with the adoption of IPv6, but we are more interested in the bottom part of this slide, which represents the IPv6 value chain, with that term we mean all the elements that support end‑to‑end, the IPv6 connection. So, to be noted that nowadays, probably the vast majority of users' devices do support and do use IPv6 to carry out services, and, on the other hand, most of the content provides offer content via IPv6. Probably the only remaining part you see in between is the relatively low number of IPv6 networks. So networks able to carry and transport IPv6 services. That number is our estimation looking at the BGP table, so around 40%.
So far, so good, so that is the positive part of our talk.
Now we are entering, I would say, the tricky issues. Now, is there a single driver for IPv6 adoption? And the answer probably is no. Even if you think about the expected scarcity of IPv4 addresses, well, in most cases, that is not a real driver to move to IPv6. The chart is taken from the analysis done by Dr. Huston at APNIC so you see compared the IPv6 deployment against the number of IPv4 addresses per person or per citizen in a specific country. Just look at the, let's say, European situation, compared against other economies, so you have the green dots whenever the IPv6 deployment is on par or let's say just above the trends that we have seen before. The red dot is where you have a country which is quite low, the trends.
You immediately see that there is no direct correlation between the two. Just look at countries such as Poland or Italy or Spain, they are low with IPv4, yet they are not moving to IPv6. You have other countries that are fine with IPv4, yet they are moving or have already moved to IPv6.
So what's the real driver? Well I would say in most cases, I cannot generalise but in most cases, whenever you find a green dot, it means that there has been an action, a local action, either by the government or the regulator or even the service provider that sees the opportunity to deploy IPv6 for whatever reasons and that influences the status of IPv6 in that specific country. Now, we don't have time to fully discuss what's happening there, but monitoring this kind of actions is part of our job, so if you are interested, just catch me during the break and we can further discuss it.
Okay. Another issue that we have found, just looking at the table here, you see that the growth of IPv6 capital autonomous system is quite good so IPv6 is growing more than IPv4, at least in the support of the autonomous system.
But immediately you get to the point, the ratio between IPv6 capable autonomous systems and the total is around 40%, so the question immediately pops up: Who is missing? And here, doing some cross‑analysis, the question was, it's the enterprises. So enterprises are still the say passive or inactive with IPv6, I don't want to generalise, but that is just, I would say, one of the key findings. And that triggered a question quite discussed in the mailing list of v6 Ops, so how do deal with that, how to cope with the perceived inactivity of enterprises in adopting IPv6? More to come in the next slide. I forgot to mention, across the presentation you will find all the references that we have used in our paper.
Now, speaking of challenges and we are entering, I guess, the core of the discussion, we think that we can group all the challenges in four main areas, so starting from the top left, I would say the first one is lack of motivation. A player, an industry player, cannot see, cannot perceive the business justification to move to IPv6 or the market demand that pushes IPv6 adoption and as such it stays with current mechanisms. The second area is lack of knowledge or expertise to start and drive the transition. Putting these first two areas together we tend to believe that probably here carriers, they ‑‑ we have in Europe, even the public agencies have a role to drive and stimulate the market or a specific economy.
Then we have the third area, we have called it ecosystem, it relates to the lack of development or interoperability of some products or features, so maybe a route map is not complete, and we think that, here, the entire ICT industry has a responsibility to fix it. And we have the technology domain. For example, what is the proper transition technology to be applied to a specific use case to enable the shift to IPv6?
From what we can see, we believe that, here, the technical communities, such as RIPE, has a role. So can help solving the technical issues, maybe with some new activities or some new proposals.
And zooming into a couple of technical challenges before moving to the presentation and listening to your voice. So we have already seen that IPv6 create challenges with enterprises, and we have seen that, for them, again speaking in general, IPv6 is not a technical priority. They have other issues to be solved before thinking of IPv6. And when you interact with enterprises, the experience that we have seen is that they have their own view on specific technical architectural decisions on the solutions they prefer to have in their networks. One example, and I'm reporting that here because it was, let's say, quite discussed in the mailing list, is, for example, the general tendency is that enterprises want to keep net, which is something good for them, yet the technical community, I am speaking of IETF mainly, had something to say against that motivation. Actually, how to, let's say, break the vicious circle and move on? Well, we ended up seeing probably the technical community has to listen and involve enterprises more, and before taking technical decisions on their behalf, and influencing some sort of negative reaction. Probably, we think also that public agencies, through the public domain, can also influence the adoption of IPv6 by enterprises. Think of, for example, specifying some requirements to be complied in the bids that the public agency issues where enterprises are involved.
Second technical issue or challenge we would like to share with you and it could be used to open also the discussion, IPv6 performance is not yet, I would say, completely good, or at least is still a bit worse than IPv4. That comes from the few measurements active today which are public, I mean, so public domain. In the paper, we used also the measurement done by APNIC to consider, you know, the packet loss or the latency. Well, probably there is more to be done here. First because, as you can imagine, seeing good performance for IPv6, that could be a real driver for adoption because if the end users can perceive the difference, well they could be motivated, you know, to use it. And so the question: How to move on? Well this is actually a proposal, it's not a solution, but can we think of multi party cooperation here to start maybe a new or fresh measurement, just to have new data, to witness that may maybe, yes, IPv6 is better than power under IPv4 under the performance end point.
Moving to the conclusion. Momentum is good, yet we have something more to do in our industry. And what we have seen, that moving as a single player, a single stakeholder we cannot do that much but probably altogether as an industry, yes, we could. Here, I come to my point, so the one I shared at the beginning: We'd like to have your opinion, because we believe that there is a lot of operational knowledge, sometimes hidden in technical communities, but can be used to open the door for new researchers, new analysis, new proposals, that could be beneficial to enterprises and to the entire ICT world. So that, if there is interested, I would like to take proposals, so I think this is it on my side and we can move to the questions. Thank you.
(Applause)
JEN LINKOVA: I have some discussion in the Q&A, it looks like Christian when does companies in China get access to IPv6? It was an answer that currently we see ‑ to switch to v6 enabling and in 2030 run v6 only. But really, we cannot get IPv6 addresses and routing in China, we got offers from for IPv6 ‑‑ that's horrible.
PAOLO VOLPATO: The first part of the question is when, and the plans for IPv6, IPv6 only, I mean, is 2030, so that is the time, let's say timeline for having ‑‑ say a good percentage of IPv6 only networks available in China. Now, the issue of having open connectivity, well, we are aware of that, but unfortunately it's something we cannot solve here.
SPEAKER: Thanks for the talk, Maximilian, I did a plc with Huawei equipment a while ago and I have the impression IPv6 is still a second class citizen on your platform. Any comment on that or any plans to make it more, well, on par with IPv4?
PAOLO VOLPATO: When you come up on stage, you are expecting questions such as the one you have posed, so, what I can say, not speaking as a project manager or salesperson, is, well, let's discuss the result. I am quite confident that actually IPv6 is not, as I said, second citizen, but if there is something to be fixed, I would be happy to pass on your message to our headquarters for support.
SPEAKER: Jad from the RIPE NCC. You did mention at some point, you try policies that might have effect on IPv6 adoption, do you see any trends going in this area, like some sort of policies taking, having a good impact? Was it more like the stick effect or the ‑ effect?
PAOLO VOLPATO: Let's say that there is a lot of expectations, probably you heard of a memorandum issued by the US federal government asking to transition their federal networks to IPv6, they supposed some dates. That triggered a lot of further plans on how to evolve IPv6. My personal view is that probably we are not still to a kind of compelling plan to move to IPv6. So the expectation is high. I don't believe that the days they are planning, so the US that triggered 2025 for having a certain amount, if I remember correctly, 80% of the federal networks based on IPv6 only, well I'm not so sure they will, let's say, match that line. I would say it's more conservative to look at what also other economies, such as India or China, Brazil is doing something also, and do we expect also the European Union to say something about IPv6. The expectation is that probably 2030 could be sort of flag day, flag date, if you want, so from there, we may really transition networks to IPv6.
JEN LINKOVA: We have a question in the Meetecho from Maximilian. Your employer, Huawei, has been pushing a different new IP proposal, it's got a lot of press coverage. Can you elaborate on how it feeds in IPv6, the wait for something better might be capitalising IPv6 deployment?
PAOLO VOLPATO: I was expecting this question, but I don't have an answer for that. If you ask my personal opinion, that proposal, the new IP or there are also other flavours for that name, was simply a mistake. And it's not related to IPv6.
(Applause)
RAYMOND JETTEN: We were supposed to have a presentation by Justin Lurman, and Eric Vyncke, I sent an e‑mail to Erik ‑‑ oh, you are here!
SPEAKER: Good morning, so I am just in.
JUSTIN LURMAN: We have already presented this work in the IETF last month, and we did it so in two different Working Groups. So we have a link to the draft that we published, you can find a lot of details if you want to. But first let's have a look at the background of this work. So why JAMES? I am not looking by the ‑‑ I am not talking about the name, even if it's a cool name. So if you are from IETF you probably heard in six man Working Group that there are a lot of hot topics and one of them is actually about extension headers. And so they were wondering if they had to take care of that and, if so, how? And obviously they answered the first question with: Yes. Because they recently adopted two drafts. I'm not going to discuss whether they are good or not and this is not the point here, but the question was, do we have recent measurements for extension headers? And the answer was yes, so we have just RFC7872, thanks, Jen, by the way, for this work.
And the thing is that this RFC is like five or six years old, if I'm right, so this is like a million years in this topic. And so with JAMES we just wanted to provide some new results and maybe a little bit more complete than those in the RFCbecause we are going ‑‑ I am going to try all extension headers and vary the size and run a lot of tests.
And we are basing this on a different approach. And thanks to that, we were able to answer the big questions, which is: Are by HOP usable over the Internet and by Internet I mean the public Internet. And the same questions for all extension headers, actually.
And that's what we did. So, right now, we have two versions, the first one is a cooperation version, if I can call it in that way. So in the map you can see more than 20 VMs spread across the world. So what we do here is that we test each pair of VMs, we run a lot of tests, we have experiments for each extension headers, we see the results right after, and for each extension headers, we have different tests, so for instance, we vary the size by hops and destinations and so on and so forth and we also have UDP tests and TCP tests because we suspect that some policies may be applied differently based on Layer 4 and we also want the packets look more normal.
And those VMs are rated over I think 10 different Cloud providers because we wanted to avoid the trap of data centre to data centre.
So those are the AS numbers revealed for all those tests. So if you can find yourself in the list, well, I think we have got to talk.
But this is a discussion. Over these 44 ASs revealed we have nine or ten ASs that were not looking which is quite awesome already. For the others I would be happy to discuss the why and how; is it because of securities, because of performance, is it because of both or whatever reason? It would be really a chance to discuss that right after this session, for instance.
So, the results:
Unfortunately, I can confirm that hop by hop options are unreliable, if you take the smallest size possible 8 bytes you have only 9% going through and obviously worse.
For destination options we have a bit more hope. Actually if you don't exceed ‑‑ don't reach a size of 32 bytes, it goes through, but as long as you reach a size of 32 up to 56 bytes, it starts dropping. So it's still quite good, 94% going through, but that not enough to call it reliable any more. If you double the size, 64 bytes, you see that you have a huge drop, you drop to 46% and it goes worse if you double the size again, goes forward to 11% so this is quite dramatic at that point.
And so we can see here an interesting pattern. My guess is that operators don't want to push Layer 4 too far away for performance reasons obviously and so 64 seems a little bit small, but it looks like it's the trend for operators to not push too far away, so if you have a better explanation, I will take it.
For routing headers, we have listed all six types and unreliable are types 0, 1 and 4, so if you look at the scores, they are not that terrible, but still unreliable. And this is not a big surprise here because Type 0 and 1 are supposed to be deprecated and type 4 is segment routing. Type and 5 and 6 are still to be reliable they go through.
For atomic fragments only 56% going through and non‑atomic, 89% going through. For non authentication headers and ‑‑ Ethernet as header they are all going through.
On the conclusion on this results, obviously don't use them, it's a bit hard to rely on extension headers over the wide public Internet. If you do that on your closed domain, that's not a problem obviously.
We have also published a survey, so we have a bunch of operators here, so if you can take five minutes of your time to answer this survey, it would be really helpful for us because we would like to correlate your input with our observations and our measurements because it is not that easy to attribute drop to an AS depending on which router respond or not on the path. We also started probing random prefixes so that we grow our dataset and this is also a mean to make it a little bit more the technique adopted by the RFC. That's it from me, thank you very much, I will take questions if we still have time.
(Applause)
RAYMOND JETTEN: There are no questions in the queue. Anyone in the room? No. Okay, thank you. Thank you very much.
(Applause)
RAYMOND JETTEN: So the last one up is Matthias Scheer.
MATTHIAS SCHEER: Hello, everybody. Final presentation for the session, thank you for staying with us. Well, my name is Matthias, I am here on behalf of a company AVM that does these routers and so we have to, we will try to give you a little bit of insight into our world because I understand that the most people that are here today that are more like from a core part of the network and something that I have learned in the past couple of days is that there is a very distinct separation so there's a very cruel term for that, which I learned, it's called eyeball network which I really like so I will take this with me.
Let's jump right in. We are AVM, best known for our residential gateways, that's probably everybody has at home to get somehow connected to the Internet. This is like most of them, Linux based was our own routing stack, and where we come in in the IPv6 field is that there is ‑‑ there has been a very early project in 2009 with some colleagues from access for all, which boot strapped our development IPv6 and we tried to keep it updated even though it is ‑‑ was long time not really a customer demand but it's really the future so we really wanton keep ahead of this. Just a few words about myself, I started at AVM about ten years ago, a little bit more, and my initial folks was to implement mobile chip sets but I quickly jumped on going to the network protocol layer and doing network analysis and for the past couple of years I have been leading our efforts to do a rework or an overhaul of the gateway at VPN and there is, there is something I wanted to start with the before I problem I want to discuss. There is some data I wanted to share with because we have a mechanism that gives us ‑‑ gives the customer the options to give us some feedback and this is a representative example, so ‑‑ but keep in mind that the sample is not of any distinct region or access technologies but it's just our customers, so you cannot draw any conclusions to Europe or Germany or ASL or fibre but I think, nonetheless, it's very, very interesting because you can see we have already here a configuration of more than a half of all gateways that are running our software that have IPv6 dual stack and the next best thing is the transition technology, DS‑Lite, which is very popular in the ‑‑ in fact, if you would just look at the cable access technology this slide would probably make up for half of the entire chart. And then we have the red part, this is the part that is still a little bit troubling so this is what we wanted to change, and for this reason, we ‑‑ first of all it's very beautiful that we have three out of four gateways that are now running, already capable of doing IPv6. But we came to more, we have a quarter what we need this quarter that is now running IPv4 only, we need to to get somehow connected to IPv6 as well so we made this decision to switch the default configuration in our operating system of IPv6 as an access technology from opt‑in to opt out, so once you do the update you will automatically be able to have IPv6 connection and the reason we chose to do this path is that we expect that the most installations that are now running on IPv4 only is regular see setting, so you have most of the ‑‑ most of the ISPs, ship the boxes to the customer directly, gateways, and they have a pre‑configured set‑up but there is retail market and in this they of course work on the default configuration, when they bought this back in the day and never changed this, they will never get into lucky state of having IPv6 connectivity. So, we have already deployed this in a public Beta programme so far there's no major hiccups there, so we are really excited what happens with these numbers that I showed you in the slide before, once we have this release really in the field.
So, now going into the curve to my actual topic is with the expected increased reachability by IPv6, due to the new ‑‑ due to the new reachability, we have also upgraded the VPN end point that every outgoing connection will ally try to do first IPv6 connection. So, IPv6 is now preferred and we expect to ‑‑ expect the end points to behave similarly. This is also in the Beta already but there we can see first problems; for example, we have certain type of disslam that does not accept incoming SP over IPv6, that's really a pity and we also reached out to this vendor, but no success rate. It might be because we have SP with IPv6 and extension header and there might be some filtering going on there, but well, we can get this done. The problem that is really not solved yet in our situation is that we cannot send IPv6 through the tunnel but only IPv4 and the reason for that is that we have, in the gateway scenario, in the ‑‑ with the home connections, we have the situation that most ISPs change their prefixes with every disconnect so every time there's a power outage or every time there is a sin class or even some ISPs do this regularly, force disconnect every 24 hours, then you get a new prefix. So, what can you do about this?
We need to get somehow across the tunnel that the information that the prefix has changed, so, there's two informations that are essential for this, one is of course the route itself, we need to somehow know which packets we need to send into the tunnel and which not to. And the other one is the name of the DNS server because if I want to reach a resource beyond the tunnel and must ‑‑ then I must first get this address and this address might not only change the prefixes but due to some randomisation of the ‑‑ so this DNS resolution inside the tunnel is essential for the operability.
So before we get more in detail to possible solutions, we have to discuss a little bit about the problem space, so we know that we don't have VPN does not equal VPN so there's different types, there's the Road Warrior scenario, if you get a company laptop and are brought you have some type of VPN to connect to your company scenario and in this scenario you probably don't have this problem because at the Road Warrior side you can install install default route and usually the company's resources have fixed addresses so this is not a real problem, but as soon as you need to connect to a site that is beyond restating prefixes then the problem starts. So still, if you are a Road Warrior you can just do the default route and send every traffic into the tunnel but you need to have a working DNS already. In the worst case is of course if you have side to side tunnel, where both sides need to be aware of the other side's changing prefixes. So this is the first dimension, I would call it, of this problem space. And the other one is the VPN protocol.
We have IPsec for decades and we have the newcomer, WireGuard, these are the two ones that are actually relevant in the field. And we have very different ‑‑ very different principles, design principles beyond each of these resolutions. So IPsec you have of course a dedicated control channel, IKE to build up your connection and do the key exchange, and also the possibility to exchange dedicated configuration parameters, so this is already probably the solution for this problem, so you can just add the priorities that you want to and send it to the other side and the other side sends it back and you have to install the routes and the DNS servers accordingly.
With WireGuard, it's not so simple because with WireGuard, you have dedicated configuration, you make this configuration one time and then it's ticked so you cannot change this dynamically. Then there's ‑‑ okay. I will skip this WireGuard remark and just go to the next slide.
The conclusion of course is we need different solutions for different protocols.
So, the first proposal that I make is that we have this GUA approach, so you have this dedicated control channels that can be ‑‑ you have configuration elements that can be used to get this information across, meaning those two that I have ‑‑ there's two ones that are especially important, one is called internal IPv6 subnet so this is used to get across the prefix to the other side. And then you have internal IPv6 DNS. So both are defined and can be used and everything is fine. Additionally, in the SA where the key is stored, there is a selector, so‑called traffic selector which must of course matched what you have installed in the first place.
So, there's one little caveat, this is especially important for mobile networks so in mobile networks you had long time no IPv6 delegation at all and with release 10 they started doing this as well but they have this special property that they assign as 64 prefix to the LAN that's ‑‑ that's overlapping with the prefix that is delegated to the U E so you have to prevent a situation where you install a route that would also send your control channel into the tunnel because then latest with the next key exchange your VPN connection would die. So that's the scenario that I'm talking about. We have, excuse me for using these ones but I think this is okay. It is an illustration for the both sides. So you have a configuration that is dynamically installed by these messages that are sent across with everything connection establishment. So, and both sides operate with the GUA so if you have here a client that wants to access a resource here, then it will end a DNS request to resource dot RIPE dot FRITZ dot box. This will resolve this address to address from space and you can just send your because we have the proper route here and it gets sent into the tunnel.
All right. So, this is I suppose the easy part. And now we need to find a solution for WireGuard.
So, we have RFC4193, which covers the ULA address space, and there's also the explicit suggestion for use of ULAs for site to site VPNs so you means next to your prefix that is delegated from the provider, you have own ‑‑ create an open ULA address space and you use this to connect both sides. You have to do this configuration of course and include in the configuration profile of the VPN you are sending ‑‑ you are not sending but restoring it on the other side. It's because this configuration stay fixed and can never be changed.
Maybe this is also the reason because there's so many start‑ups now popping up left and right that take this dot wire implementation and build some extraction layer around it to solve problems like that. There's also a thing you need to make sure that it's working properly and this is a big problem for us, but probably not for somebody who is ‑‑ who has just two distinct sides they want to connect. You need to make sure that the source of the selection on the client that is trying to connect another source is working properly. If I get a DNS resolution to a resource that gives me an ULA address, then I need to make sure that every client that tries to reach this resource chooses its own ULA address as a source address and not for some reason a GUA address. Just problem is, that the number of clients is so vast that the number of tests you would have to do, we need to think about if we can really implement this and draw this out into the field, because we did not really control all these clients of course. There is some way to try to manipulate the way the addresses are selected on the clients by DHCP but it's still a topic of research.
Okay. I have, of course, for completeness' sake, also the same diagram here, and here, the VPN configuration is not dynamic but it's static, and the addresses are ULA. So essentially it's the same principle, but different addresses are used and some way the addresses need to make ‑‑ made available at the other side so, like you do have now to, if you install a WireGuard connection you have to somehow get across the keys and in this process you need to get across the network and the route that you want to reach at the other side as well.
So, that's it. Thank you very much.
(Applause)
JEN LINKOVA: We have two questions in the chat, which looks like question and comment. Christian bit: Any chance to any updates to 7582? Still on fritza 16 especially WireGuard support?
MATTHIAS SCHEER: Visit our website and download the current Beta, it's very far ahead the risk is minimal. If you would like to try it out, I can recommend it.
JEN LINKOVA: A comment: "Inquiry guard preferring IPv6 in DNS resolution... clients implementing as that is an effect of how the resolver is written, and it's been working on."
And I am going to use my power ‑‑
MATTHIAS SCHEER: It was not a question?
JEN LINKOVA: It was a comment. I use my power and make two comments. Strictly speaking, I don't have RFC‑‑ I will shut up for a second. Go, Jan. It says it can be used, it doesn't say you should, it doesn't use that language. Secondly, I believe for default address selections RFCis called default for a reason, does something by default, doesn't ‑‑ client to do something completely different.
JAN ZORZ: Jan Zorz, 6connect. Thank you for this. You mentioned the problem of rotating prefixes, right? Please, if you encounter the operator that is doing this, point them to rhyme 690 document that describes these things, and another thing, RFC9096 title "improving the reaction of customer edge routers to IPv6 renumbering events" this has some good advice what to do on one side and wrong side and how to tweak.
MATTHIAS SCHEER: 9096?
JAN ZORZ: I am the co‑author of this document, if you want to have a chat with this, we can have.
MATTHIAS SCHEER: Of course, thank you very much.
JAN ZORZ: Talk to Jen. She has a brilliant idea of how to take care of the renumbering events with creating the specific gateway per prefix, talk to her and make a prototype. Thank you.
GERT DORING: Old time IPv6 fan. I am happy to see this. So really congratulations on many aspects of this making v6 on the default is really good, because users don't know why they should or should not do this, and we need this. And congratulations on working on the VPN over v6. I have complained to AVM five years ‑‑
MATTHIAS SCHEER: I remember we had a bus in Iceland a long conversation about this, three years later there is.
GERT DORING: Thank you. Of course I have to tell you that, with OpenVPN, all these problems would be moot, but this is not a serious discussion as I understand that open VPN brings so much code, you don't really want it. I like the OSPF suggestion actually, to do the ‑‑ WireGuard tunnel and OSPF v3 ‑‑
MATTHIAS SCHEER: First version of the slides I had a last one with further ideas. I took it out because I had this talk yesterday and it was way too long so ‑‑
GERT DORING: I looked at the slides uploaded on the web and I saw the OSPF suggestion in there, I am not commenting on the other suggestion but the OSPF suggestion might actually be a workable thing.
MATTHIAS SCHEER: It's not a really NAT ‑‑
GERT DORING: I am not going into the details of which is better or worse or whatever, but if we can do it without Knot it helps troubleshooting, debugging, if you can see the IP addresses left and right
MATTHIAS SCHEER: I would love to have this work with the approaches that I proposed, but let's see.
GERT DORING: If you feel the need to discuss ideas just bounce them my way, you know where to find me.
SPEAKER: David: This is more of a response to Jan Zorz. I have customers exclusively asking me to rotate their IPv6 prefixes so I don't care what RIPE policy says, I am going to rotate, I am happy you are tackling the problem and accepting this is what happens so thank you for trying to tackle the problem and I think there's better solution, so if you can talk to Jen or me, we have both worked on Homenet stuff before.
MATTHIAS SCHEER: Let's have our talk outside and we will find the best solution.
RAYMOND JETTEN: All right. So, thank you all for staying until the bitter end. Please rate the talks, so we can have some ideas is this stuff you want to hear, see and feel, and see you next time, I hope.
JEN LINKOVA: I have a better suggestion, not just rate the talk, please suggest a talk for next meeting.
RAYMOND JETTEN: That's also a very good idea.
JEN LINKOVA: Thank you.
RAYMOND JETTEN: Thank you.
(Applause)
LIVE CAPTIONING BY AOIFE DOWNES, RPR
DUBLIN, IRELAND
