RIPE 85
Plenary session
25th October 2022
11 a.m.
JAN ZORZ: Hello, everybody, welcome back. All right, so, we have here ‑‑ this is the celebration of ten years from IPv6 world day and IPv6 world launch, we have an esteemed panel here. This is Jen Linkova from Google. Christian Kaufmann, Peter Stevens, we have Sebastian Becker, and David Miles, from what was formerly known as Facebook now Meta. Please give them a round of applause.
So, first, we already had two panels for the celebration, one was at NANOG in Montreal, one was in APNIC in Singapore this year, and Leslie Daigle, one of the people who started the ‑‑ and helped with the whole thing ten years ago, she recorded a video for APNIC meeting, and John and I liked it so much that we want to play it for you. It's just five minutes, because she explains the whole thing and does the introduction to the panel and to the discussion so nicely that we are sorry we are reusing the same video, maybe she mentions APNIC, but we didn't want to rerecord the whole thing, just for RIPE.
So please, can you please play the video.
VIDEO IS THEN PLAYED:
.
LESLIE DAIGLE: Good morning, my name is Leslie Daigle, I am the chief technical officer at the Global Cyber Alliance but this morning I want to talk about some events that were organised just over a decade ago when I was chief Internet technology officer at the Internet Society, namely the World IPv6 Day in 2011, and the World IPv6 Launch in 2012.
These were events that were organised because, in discussions between multiple network operators, it became clear that many of them faced challenges with the increasing scarcity of IPv4 addresses, and they knew that they had to do something about moving to IPv6. At the same time, they didn't have all the answers necessary in order to make the business case to their management and ensure that the project could be given the green light and made the top priority.
Content providers had similar challenges.
Talking through the challenges between multiple engineers from multiple organisations, it was a great opportunity to share ideas about what to do and how to overcome individual challenges in deployment. But it also identified some key sticking points that had to be addressed in order to move forward globally and these were sticking points that no single operator or content provider could address on their own.
So, in the end, the World IPv6 Day and the World IPv6 Launch were actually engineering tests at scale. The World IPv6 Day in 2011 was not a flag day. It was an actual test to see what would happen if major content providers turned on IPv6 on their front door, so to speak. At that time, or prior to that time, it wasn't actually clear whether, in doing so, they would lose significant portions of their audiences who would no longer be able to connect because of inadvertently being connected through now defunct IPv6 tunnels for instance. And this was a significant concern to content provider marketing departments.
So the purpose of the World IPv6 Day was for 24 hours, turn on IPv6 on a front door of major content providers and see what happened. Of course it wasn't just a day, there was a lot of work that was done leading up to that day. There were many travel tickets at various software development house that is got ramped up in priority, and software companies realised that the little bugs with IPv6 that they had been ignoring for so long were going to get stress‑tested on that day. And in the end, it was a very significant and successful day because it was demonstrated that in fact you could turn on IPv6 and it wouldn't cause the world to end.
Importantly, no single content provider could have done that on their own. It took all the major content providers joining together and doing it at the same time, jumping off the bridge together, so to speak, to make that happen.
.
And once the major content providers signed up for the day, of course many others content providers said, put my name on the same list as major content providers. I'm in!
.
So there was a lot of groundswell, but again it really was about the testing of the system, so to speak.
With the World IPv6 Launch a year later, it was an opportunity for ISPs to put their stake in the ground to demonstrate that they could in fact send enough traffic over IPv6 to the content providers to justify the content providers keeping IPv6 on, and clearly it worked, we still have IPv6 access to major content and we have an increasing number of ISPs that are enabling IPv6.
So why is this still relevant?
.
I will point out that the world IPv6 events happened at a point that was long after the understanding that IPv4 scarcity was going to be a real thing. I mean initially, we had cyber‑based address allocation and moved to classless addressing and the RIR system, and then also there were network address translators installed at individual end networks, all of these things as coping mechanisms to try to address the fact that there were not enough IPv4 addresses for every device on the Internet.
.
At the time we ran the world IPv6 events, carrier grade NATs were just becoming a thing and, to this day, there are more and more CGNs and other coping mechanisms being put in place to try to stall the inevitable, and the inevitable is there are not enough IPv4 addresses for a global Internet.
.
So, what I would like you to take away from the stories around the world IPv6 events is that collaboration across industry competitors is key, and it's possible and it makes big things happen. So, this is our Internet, we, as Internet engineers, have to come together and identify where are the sticking points now and what can we do to address those issues, because even if you think it's too large a problem to solve in your own engineering department, you can work with others and understand how collectively we can come together in meetings such as this one and identify what's the next thing to do.
So I hope you'll have a great session and dig in and help solve the problem of deploying IPv6 everywhere.
Thank you.
JAN ZORZ: Thank you, Leslie. So, now you heard ‑‑ my name is Jan Zorz and I will be chairing the first part of the panel, Sander will help me with chairing the second part of the panel. Originally, John Jason Brzozowski was supposed to Chair, to co‑Chair with me because it was our joint idea for this series of panels, but unfortunately John could not travel because of some unforeseen family health issues, he had to stay at home, but I see John, he is with us, John, good morning. Can we put John on ‑‑ good morning, I am really sorry you can't be with us. You are muted probably.
JOHN JASON BRZOZOWSKI: Indeed I am, good morning.
JAN ZORZ: We can hear you. We are really sorry you can't be with us, but I think that after the presentations from our panelists, at the end you will be able to tell ‑‑ John was a big part of this organisation for World IPv6 Day and world v6 launch so he should be a panelist, not a moderator, at the end of the day. Right?
.
Okay, so let's go on with the programme.
.
The first one, Jen, please.
JEN LINKOVA: I can see my slide, I'm not sure ‑‑ so, I don't think the slides are actually on the screen. Okay, cool. Wrong screen.
So, this is an obligatory slide for an IPv6 presentation, right. What we see here, first of all I have been hearing quite a lot, oh, my God, this IPv6 thing, we have been doing it for 30 years and we're still not done. What I see on the graph is that it has not been 30 years. We actually started deploying v6 ten years ago, that's what's happened on v6 day and v6 launch we basically kick‑started IPv6. Because before it was just for geeks. To get IP AAAA for Google you had to talk to us, we would look to go, check v6 is it broken and say okay, you are good enough, you can get AAAA. And this all changed in 2011 and 2012, right.
.
IPv6 for everyone basically, and we ‑‑ the industry did break that chicken and egg loop. Oh, my God, there is no content, so we are not going to have v6. Oh there is no v6 users so why do we need content?
.
So, look, v6 deployment adoption twiced in a year between launch and within the day of the launch. Yeah indeed back in 2013 we all hoped that by 2022 we are going to have 128% of v6 adoption. For some reason, not happening. But yes, IPv6 is hard. If it was easy, we would not be sitting here discussing it. We will go straight to cocktails.
.
So, what I see in the graph. Yes, deployment actually started after the launch. Back in 2015 ‑ I will put it on the slide ‑ we even started to think about how we are going to turn off the legacy protocol and launch to Google public DNS 64. But this graph also shows one more thing. You need to take it with a really, really grain of salt but it's an average, and average numbers are horrible because they never actually reflect the reality. Average person doesn't exist, right, there is old Russian joke about monitoring the temperature of every single patient in a hospital including dead ones. So, when you look at this, what does 41% actually mean?
.
Well, there are countries with ‑‑ I actually should have put France and Germany there, which is 70‑plus percent of adoption. So 70% of users in those countries actually using v6 to access v6 enabled destinations, right. In the 67, right, and there are countries where it's zero. And also, just one dimension, it just geography, and I never been a big fan of geography in terms of Internet because it doesn't really map very well. But, I think what we also found with v6 deployment, there is no such thing as just Internet any more. You have different types of networks with different types of v6 problems, v6 requirements, level of v6 adoption. You have mobile networks, which actually move into v6 only, they have moved to v6 only. We have brand ISPs, which in many countries move into v6, in some countries not so much and there are enterprises which are basically lagging behind. There are IoT networks which are a completely different thing if you talk to them their IPv6 environment is not very, very different from mine and so on.
So we cannot say yeah, we deployed v6 everywhere because we are actually talking about completely different networks.
.
What we have been doing for those ten years? Well, more or less, the same thing. Finding dark corners without IPv6 and deploying it there. Fixing broken networks, and I would say but maybe it's because I'm network engineer, I think networks are mostly done. I am not saying they are perfect. But an amount of bugs, drastically reduced and amount of time you need to get v6 on network infrastructure is now, like, 100 times less. I spent five years on deploying one single configuration line on the network related to v6. I moved to another network and I did it in two weeks. And all bugs that were on that feature were minor.
.
So actually, I think, I dare say, we did a lot of heavy lifting. So now, what is actually, I believe, blocking us is not network any more, maybe some crappy cheap CEs but it's mostly applications but we have been working on that as well. We have been analysing gaps and I say different networks have different gap situation and enterprise v6 situation is not the same as mobile operator. Well we have been promoting v6, that's why I'm sitting here.
We have been working on improving the protocol, as a result of analysing gaps, because what we knew about IPv6 ten years ago is not what we know about it today. Requirements change. Right now, if you connect to v6 only network here and you phone, take for your phone 7 seconds to get connectivity, you go oh my God I have to way for so long. Nobody cared about that 15 years ago. So actually protocol has been improved as well.
And there is another thing which we have started to do, which I probably did not even think about ten years ago, it's thinking how we can get rid of eliminating v4 dependencies, but we'll save it for the second part of this panel.
JAN ZORZ: Thank you, Jen. Please, Christian, how was your IPv6 journey in the last ten years?
CHRISTIAN KAUFMANN: Hi. So, first of all, I have to admit that all the slides are stolen by our IPv6 person, Erik, so thanks for the slides.
Akamai is a technology company, right. So we started with v6 actually very early. I think when the protocol was specified and came out we were one of the first having an internal Working Group talking about it, and then as we got the impression that the rest of the world ignores it and as we are a big company we got sidetracked and ignored it as well.
So it was actually very convenient that the world launch and world day and launch day came around because that was suddenly a reason to actually do something instead of postponing it for next year because otherwise your usual answer is next year it will be better, somebody will implement it and then we will react to it, so we started in 2011. But now we have rolled it out on most of our product lines and features, including the Linode part.
And we encourage our customer now to do both. They said we do not own the content right. We transport it for our customers, so if he they don't want it they don't enable it.
.
You see on the bottom a couple of stats, and you see them in the second again. We now ‑‑ well, in total, we have a peak around 250 terabits, so 41 terabits now is the v6 part, so a fifth‑ish. And that's interesting because you see in a second as well the geographic distribution, similar like with Jen, and it doesn't mean just because you have a good distribution in a country, that you also, you know, have a lot of traffic necessarily.
Otherwise, we have rolled it out as much as we could. So 120 countries, 650 cities, so I guess, I don't know, 80, 90% easily is done, probably more.
Launch day, I think we had roughly a gig, kind of cute. So now 2022, as I said, 41 terabits, we went from 3.9 billion a day to 4 trillion a day as requests and the IP address amount, like 19 million before, now we see roughly 7.5 billion. So you see orders of magnitude difference, right.
The ten years have made quite a big difference. It's not just, you know, working a little bit on it. I think it is suddenly here now and not just a geek thing on the corner.
That one I found interesting, one has to say the presentation was made originally for Spain, that's why we picked them out, but whoever comes from Spain, 4%, not so impressive. These are the top ten countries, and it's interesting because I saw Jen's slide yesterday and our distribution is relatively similar, but, you know, in some countries, it actually various of 5, 6, 7%, so that was interesting as well.
Some countries like the United States, Japan, especially also India, you see a jump, right, it's not a relevant growth, every year a couple of more you see that they were jumping, which I assume has to do with some big eyeball provider enabled it or, you know, something like that.
But what you also see is, and I guess the United States is a good example, but also India, the one in the middle, things slowed down. You get to a certain percentage, around 50, 60, and then people lose, apparently, interest in it, and it is not continued to grow in all of the countries, unfortunately.
This is the adoption around how big a network is, and you see that the bigger a network is, the bigger the chances are actually that they have enabled v6. If the country ‑‑ sorry, if the network gets smaller, and into the long tail, the chances are also going down that you are actually have deployed it, so the big ones are more interested. Probably they were running out of v4 space quicker, buying new one with a larger amount is probably more expensive, I don't know, they have more engineering capacity, but they are certainly leading and the small ones behind.
That's the dual stack growth on the host names, which, you know, kind of goes smooth to the right. No big jump. So this is what we are finding.
That's pretty much it. We have a block, you can have a look, we have a website where we actually show multi‑typographic stats, how we deliver v6, so if you want to have a look what we do, then you would find it there. Thank you.
JAN ZORZ: Thank you very much, Christian.
He Pete, you have been been on quite a journey with IPv6 and your data centre and your running hosts services. Tell us more about it.
PETE STEVENS: So I think the first thing to mention is, Mythic Beast is a little bit smaller than the other companies, just a little bit ‑ close, but not quite. V6 launch day, from the point of view of a smaller provider, it's a little bit harder because if we turn v6 on and it breaks, it's definitely our fault. We can't say, you know, this was a thing that we are leading the industry, because we're not quite big enough to get away with that. So on v6 launch day we did nothing.
We have v6 on our main company website and our control panel that people have been using for a while. But other than that we just ignored it for the time being. Waited two weeks, and it appeared that everything was still okay, people could mostly still get to Google and Facebook and some other very large v6‑enabled things. So, we then encrypted the switch and turned it on by default for all of the customers on our share hosting platforms. So thousands and thousands of website picked up v6 in one go, and nobody noticed. And almost nobody looked at the sites over v6 because there weren't any v6 eyeballs either.
At this point it was a case of, well, we have done a load of work and we have achieved practically nothing, so, nothing has really changed.
And fundamentally v6 isn't actually solving my problem because my problem is I am going to run out of v4 addresses and how do I continue to sell things once that happens?
.
So, a couple of years later we decided the thing to do was sell a service that doesn't have any v4 whatsoever. In our VM platform we allowed you to buy VMs that didn't have any v4 configured at all and almost nobody bought them because they are not very useful because nobody can connect to them because there is no v6 eyeballs. So, it proved without a doubt that there is no customer demand, you can't sell that product.
Still haven't solved my problem. Done a load of more technical work. So next thing is, can I think of any service at all that I can sell that runs in a v6‑only environment? We started with WordPress, because we already had a lot of people using it, and that drives what, a third of all the content enabled websites on the Internet. If I can make WordPress go in a v6‑only environment, then I have something I can sell when I run out of v4 addresses.
So, we enabled NAT64 in order that you can get outbound traffic and a proxy inbound that forwards HTTP and SSL by services. It uses SNI to switch to the correct back‑end. I got lots of questions about what about non‑SSL enabled services in, and my answer was: Don't do non‑SSL enabled services. Like, you should encrypt everything. So we just won't support you if you don't want to encrypt. Like, go buy v4 address from someone else.
We started doing that, and gradually, we ‑‑ again, initially there was no direct customer demand, they didn't know they wanted it but we are selling managed WordPress sites to ourselves and we started doing v6 deployment our self for our back‑ends and there is now thousands and thousands of websites where the server ‑‑ the origin is v6 only and has no v4 whatsoever, and then we have got a proxy layer in front that does dual stack to help all those legacy v4 people. Some people don't use our proxy, apparently some other content provider and CDNs are available that support v6 origin, so people use that will as well. But it means suddenly this is a real thing that works. You can go and buy a v4 ‑‑ you can go buy a virtual machine that only has v6 connectivity. You can use it as an origin service for global CDN and host a high volume website on it.
And hurray, I have got a product, I have successfully disabled v4, I can sell things in the absence of v4 and running out of v4 will not completely constrain the growth of my business. So that was kind of the target.
Where this got more interesting is, in 2016, this is the very first one we launched our Raspberry PI Cloud and so this is our first implementation. It's a bit slicker and condensed now. You get your own dedicated Raspberry PI completely hardware dedicated to you at about 6 quid a month, which is an incredibly low price point. And obviously it's not quite as fast as a modern Intel server, but it is very cheap and it does run on natively, which, if you are doing things like on build services, gets you a massive performance advantage over emulation.
However, you very quickly run into a problem, which is, my friend will sell me a computer that costs $5 but the IP address cost $50. How am I ing to solve that problem? The second is, I only have a limited number of IPv4 addresses, I am going to run out and that means I can't sell big expensive Intel services because my cheap Raspberry PI users will have burnt through my address space. The answer is, let's not implement v4 at all in my Raspberry PI Cloud, so it does not support v4. You get a v6 address, you get a /64 allocated to your pie, there is no v4 connectivity. You can't have it. Some people get upset about that, and the answer is go buy a Raspberry PI in someone else's Cloud, and there isn't one, so tough!
And then the next answer is: But I really want this. This is an education, Raspberry PI is about education, congratulations you are being educated, I know you don't want to be but you are about to be.
So, now, we have got ‑‑ so for density‑wise, we now get 96 Raspberry PIs in every 3 rack space and they don't consume any IPv4 addresses and I can keep rolling these things out. The thing is you can't buy computers for love nor money. If someone happens to own a silicone, fab, I have friends who would like to talk to you. I can roll Raspberry PIs out, they are v6 only. I can go forever. I don't need any v4 addresses. I have solved the problem.
So, and we're steadily educating more and more users. So we're getting there. And that was my last slide. So I finished slightly early.
JAN ZORZ: Thank you very much.
Sebastian, Deutsche Telekom, tell us about stuff. Oh, okay, you can go first. Sebastian you don't have slides, right. You go last then.
DAVID MILES: Hi, I am David, I am from Meta, or once was Facebook. Meta makes me think ten years ago went really quickly. I was somewhere else with a capital G, and I remember when that launch day happened, I am going to focus a little bit more on what's going on under the hood at Meta, looking a little bit more about infrastructure. And talking maybe less about how we are promoting IPv6 adoption and how we're starting IPv4 retirement.
So, we may have missed June World IPv6 Day by a few months, but something was celebrating internally and as we are finally a hundred percent IPv6 enabled by default on all our hosts, including in our POPs. This milestone just happened this month, October the 6th, and more IPv6 by default or IPv6 host only means everyone of our servers requires no v4 address to build, to boot, to manage, to operate, and to deploy.
Now, that's a big achievement and I don't mean to imply by that that we don't run IPv4, right. Clearly we are a content provider, clearly there are a lot of IPv4 eyeballs and I'm sure those graphs that Jen presented are very, very similar for Meta.
But what we're trying to do is figure out how do we eliminate IPv4?
.
And so I wanted to kind of get into some technical detail, be a little bit nerdy here, I am a network engineer, so let's dive in and look at how we are actually doing this.
What we wanted to do with our IPv6‑only host it is not run effectively IPv4 stack on their zero. Just under the hood what we're doing to enable this is we're using RFC 546, it allows a sing will multiprotocol session over v6 to carry our v4 address families with v6 next hops. And so for those hosts ‑‑ and there are obviously quite a few of them, the POPs that need v4 addresses, for those hosts that need v4 addresses we will BIND a /32 v4 address to their interface and make use of their 5549 connection to advertise that. That's nifty. From a network engineering perspective it's scary, should IP up, doesn't show anything because we're not Arping any more, we're using neighbour discovery to figure out how to forward out IPv4 traffic to our IPv6‑only host.
In the POP, the reality is that, you know, we connect to the Internet, I think 50% of Internet is still v4, and so, right now v4 is something we expect to remain in our POPs for quite a long time. So, from a networking perspective, as a network engineer, we're not as quite far along as maybe these server guys are with their hosts.
So, we are running dual stack. And we expect to see v4 in our POPs for the foreseeable future.
So, looking beyond our POPs into our data centres, you know, being able to control both ends of the connection, the origin server as well as the edge CDN, we have a few options available to us, and one of those is the ability to truly eliminate IPv4 from our data centre network, from our data centre hosts and potentially from our backbone, and so we're on this path in v4 no more. One of the ways we're trying to enable that is to use stateless IP and ICMP for data centres, and that will allows us to have a host in the DC, really and truly with v4 ‑‑ with v6 only address. And then make use of translators that reside at our POPs, right where we are going to retain that v4 for the foreseeable future.
The luxury that affords us then is a v6 transport network between our POP and our data centre.
And then just finally a few other IPv6 milestones or celebrations.
Our internal container networking technology is built on the concept of an IPv6 address per tasks or per container. Obviously solving that problem of, hey, I have a service and I want to buy into a particular worth. There is just no v4 involved in this any more, and so, you know, it's built on top of this concept of the v6128 per container.
IPv6 by default is enabled for our management plain. So, SSH netconf, S this is all via v6 for all our network devices.
As a developer/network engineer, all our work stations are v6 only, right. So my work station living in the Cloud, I don't have a v4 address, I don't need a v4 address. Now, there are some legacy devices from some vendors living out there that are v4 only, but we're working with them and I think that leads me to the final point.
As we introduce new network vendors into our network, they require v6, not just v6 dual stack but they'll they need to be able to support v6 only operation. And so, you know, we use that leverage with them to really promote a v4 no more network.
Thank you.
JAN ZORZ: Thank you very much. Now, Sebastian, now, it's your turn.
SEBASTIAN BECKER: So set aside that small local ISP in Germany, we got our ISP v6 address space around 2005, our /19, the basic challenge for our network was just a brief history how we brought IPv6 into our network was also to get our controllers to the point that now we may not earn more money with that but we do not lose customers. I think that is one of the basic points, bring that to your network, so anyone that goes to whatever content maybe in the future there will be IPv6‑only services, these must be served, so do IPv6.
In 2008, around, we started for the backbone, the v6 rollout, or the engineers were all what needs to be done that the backbone itself is IPv6 ready? And yeah, bigger challenges were obviously things in the IT systems that you can also document what you do in your network. At this stage I think the situation nowadays is much better because of there are a lot of tools right now that support, also document everything with IPv6.
.
And on the other hand, there are people maybe still up to now that ask us who does IPv6? So ‑‑ and we tell, you know, ask, it's about 70% of our traffic with them. So, this understanding, this education I think is still missing also within our company, and that's something we need to bring into each and every hat in our company, so educate people why we are doing IPv6.
Later on also security guys came around and said okay, please turn off IPv6 because we are unsure about the security risks that are there, but we know that in IPv4, so we didn't turn it off. Since the end of 2011, until beginning 2012, we started to roll out end customer connectivity in dual stack, so we now serve with the actual product each end customer with a possibility to have dual stack IPv6. So if they use that, obviously it's their thing, but every end customer, DSL customer and so on, or transit and peering connectivity is dual stack.
Only some legacy services are still IPv4, maybe IPv4 only but we are fading them out.
On mobile, that all started in 2015 with making backbone also ready, finally beginning IPv6‑only rollout to the mobile end customer started in 2020, and they just told me that the mobile network for the end customer basically is finished right now, so the German mobile customers are on IPv6‑only there. And that's basically the short story in DT's IPv6 journey, but again, do IPv6.
JAN ZORZ: Thank you very much, Sebastian.
All right. It's really early morning in US, I hope John is still with us, John is with us? Thank you, would you like to say a couple of words?
JOHN JASON BRZOZOWSKI: Yeah, I have...(echo) several of the folks up there on stage. Christian, your hair was much shorter and a slightly different colour in 2011. I just checked my travel schedule when you and I first met, and I cannot believe it has been that many years since we have all started this conversation. I I mean, I think, Jan, it's fair to say that the message has changed substantially, and I think that's a good thing. I think my hero, if I may, and this is meant to be very complimentary, is our friend Pete. I love the message. I am glad that I didn't hear anything about Hugh Duke (?) and its lacking support for v6 because I think I have heard plenty of that over the years, and, you know, I am looking forward to the back head of our discussion, and of course, you know, Jen, it's always a pleasure, you know, it's been so long, and David, I was looking, when we went, first met, I think you were several companies ago, not just the capital G, so we have all been on quite a journey my friends and it's an honour to be here with you and I am very much looking forward to the rest of the conversation, and, Jan, of course, all this, you know, brought to us by you, my friend, so thanks to you and Sander for your hard work and making the magic happen here.
JAN ZORZ: Yes, thank you. Well, again, sorry you are not here, we wish you were, but it is what it is, right. So, Sander, we are three minutes early, would we like to open the floor for one or two questions or would you like to take with the second part? Any questions, any suggestions? Please...
AUDIENCE SPEAKER: I have a question for Meta, if possible. My name is James Rice. Operational issue. You said you are using stateless on your data centres; is that for globally routable public IP addresses using /64s?
SPEAKER: I am not from the data centre networking team so that will get me out of half the answer. Stateless, we are referring to, it's still a one for one NAT, so it's stateless in terms of ‑‑ we're not tracking plots, we are not creating dynamically. The initial intent with the stateless NAT, as I understand it, was to facilitate outbound and inbound communication between, you know, stuff, right, so it was basically what we tend to do for outbound to the Internet is use application proxies actually, we find that those offer kind of more security, but there are applications that would require inbound connections to the v4 only hosts and so that's where the idea of a stateless 141 NAT has been used and we have a mechanism by which like the applications can actually request a lease effectively like a v4 lease for some period of time, and then use it for, you know, our service.
AUDIENCE SPEAKER: What I was getting at was essentially how have you mitigated IPv6‑enabled discovery exhaustion attacks and it sounds like the answer is by ‑‑ that you're stateless /64 is actually not a globally routable /64?
SPEAKER: It is a globally routable /64 but maybe I should catch up with you afterwards to understand the concern, yeah.
JAN ZORZ: Okay. So, we heard what was done. Let's celebrate these ten years ‑‑ we have a question on Meetecho. Do we? .
SANDER STEFFANN: Must be some v6 thing, right! So, yeah, that was the history that was celebrating ten years of World IPv6 Day, World IPv6 Launch. But as you have seen, we're not there yet. So, the next half of this panel, we actually want to talk about what should the next steps be? Where do we need to put our energy now? Do we need to have a world no more IPv4 day? I don't know.
So, yesterday, we already had some chats amongst each other and there were several things that came up, and one of them was actually the complexity of v6, because all the flags and options and combinations you can use, and I think Pete had some really interesting insights into that one. Because we talked about this and this is also from an educational point of view, you are educating your customers in v6, so what things do you run into.
PETE STEVENS: Well we got the simplest v6 configuration we could get working and then used that, and I don't really know what many of the other options are. So we build VMs, we statically address them with v6, I don't know how SLAAC works very much, because we just deployed them statically; it's easy, it works and, in a controlled VM environment, that's straightforward to do.
And I don't have to deal with end user devices, which also makes life much easier, but essentially, avoiding complexity is really desirable. I just want a simple thing that goes. I have got some v6 and now my packets flow, the job is done, the network is finished. I can go on and worry about the application. And certainly from the client side device, like when I try my v6 go in my house, attempting to get the things to communicate and be happy is a bit harder. If we could make that as straightforward as possible, which may involve deleting as many options as we can, that would be really helpful.
JEN LINKOVA: I have been always wondering how people who have been dealing with RSVP, traffic engineers complain about v6 being hard. That's a big mystery to me. But anyway, I think actually you can make v6 deployment very simple, right. There is a complexity but most of the complexity is about coming from some needs. I don't think people really love writing RFCs and then writing implementations just for the sake of it. Normally some peoples have some problems so solve but fortunately in IPv6 I don't think you need to use all possible complexity. My network is pure SLAAC only, I am happy, one less service to run.
DAVID MILES: Maybe to reply to that, it isn't the engineers that are running BGP and OSPF that are the problem. The challenge is maybe more these end devices, and so, you know, compared to Pete who has maybe one the simplicity IPv6 implementations, I have one of the more difficult ones, I deal with plc controllers and air conditioners and you name it, right? And so maybe the complexity ‑‑ I'll describe some of the challenges I have. When I ask a new vendor, please, let's do some IPv6. They say okay, can you help us? Where do we start? What does the end bit mean? Do I start DHC 6 when I get it or when I don't? What happens when I have more than one address? Of course, you know, we know every v6 host has at least two addresses but for them coming from a v4 only world for these new implementers, it's very foreign for them. Even inside of Meta, we are a little bit, sometimes on different sides of the fence, sometimes we use SLAAC, sometimes we use static, sometimes we want to, I think, use stateless DHCP v6, but we're not super clear on that even internally. Then the confusion of on link, right, is there such a thing as a sub‑net mask from a hostess perspective for v6 or is it really just an address that has got an O bit or not. These are things that are challenging for the implementer that isn't the network engineer, right, to try and figure out. And the reality is that IPv6 is not as similar in that host implementation processes as it was in v4. And I think that too many engineers think that it is a bit closer to v4 than it really is.
SANDER STEFFANN: Just to get back to the questions we got on Meetecho. The first one we got was that Africa is, if you looked at the map that Jen showed, Africa is extremely lacking in v6. Is there anything we can do to help that? What's going on there? What are the missing bits?
JEN LINKOVA: Anyone from Africa in the room?
SANDER STEFFANN: No response. But just somebody noticing that Africa is behind in this and what could be the reason. But yeah, we would need somebody local from there. From Google analysing point of view you don't see any single reason that it's lagging behind?
JEN LINKOVA: Well, I guess they have IPv4 addresses here.
SPEAKER: Marco d'Itri, Seeweb. I can answer from a similar perspective. Italy is like 5, 7% of IPv6, and the fault is of the three, four large telcos that don't care to implement it. That's it. That's all where the problem is.
SANDER STEFFANN: Thank you. The second question we got on Meetecho is actually people still running into bugs in different networking gear and router switches, firewalls, from personal experience, software is also always a big one. How can we help that further?
SEBASTIAN BECKER: Talk to the vendors obviously and I don't think that we do not have bugs in IPv4 in implementation as well, so I don't see a reason why you have a bug in IPv6 and just whatever, sis admin say I turn off IPv6 because it's easier. Fix the problem, and get your vendor to do it right and not just ignore it by not doing IPv6.
SANDER STEFFANN: David, I think you mentioned that all the stuff you buy has to do v4 only, right?
DAVID MILES: To the first part, absolutely there are bugs, a major networking vendor this year I raised a bug against their IPv6 implementation actually referring to DHCP6 an on link. The address is a 128 guys, not a /64, unless you tell you it is. And it was causing some real problems for us. You know, this year, I have worked with two new vendors to implement their first IPv6 stack, and, you know, it's very slow, it's very piecemeal, we start with static IPv6 addresses, static next hops and we kind of progressed to router advertisement processing. What was your other question?
SANDER STEFFANN: I mentioned that you require v6 support from vendors now. So, all the vendors in the room, if you ever want to have a chance of selling him anything...
DAVID MILES: It has to do v6. And just to reaffirm what I said in the first presentation, not just dual stack but v6 only, right, so it has to be able to operate without a v4 address whatsoever. I mean, just my network, which is a subset, like I think I have 400,000 devices attached to my network, hosts, and so I really can't afford to have RFC 1918 address in any reasonable way attached to all these devices and like all great web scales do, roll my eyes, we're a router network everywhere and so those RC1919 address would go all the way to the Tor if I wanted to use them, which I don't. So it's really important to be v6 only and v6 capable and we're here to help. What Sebastian was saying, right, we are here to help you guys out, talk to us, talk to the network engineering folk, we'll help you along.
SANDER STEFFANN: Thank you. So, JJ B, one of the things that you have talked about also at the previous iterations of this panel was the need for IPv6 by default, IPv6 as the basis. Is there anything you want to add to the ‑‑ to this discussion here?
JOHN JASON BRZOZOWSKI: I'd love to, Sander. I think some of the comments I'll make cross some of the words that we heard here in the past couple of minutes. As I listen to discussion around complexity and bugs, David, in particular, about Mbit, Obit, on link and the kind of the reverse of that with Pete, not even caring about any of these things. You know, I kind of think back to the days when, you know, we were trying to arrive at some uniformity in the hubs. So, you know, one the things that ‑‑ you know, I was involved with was lighting up v6 across 30 million homes here in the United States, and it really kind of points back to, at the time, lack of consensus from an operating system point of view. You know, in many cases the folks on stage there have a lot more control over their operating systems, their behaviours, ZTP, and what have you. But in the wild west, you know, we noticed that, as broadband networks, we often have had little control around what actually people intend to use in their homes, right.
Fortunately, through World v6, we made very dear friends across all the operating system vendors, you know, Android, Apple, Microsoft, and we were able to really provide some level of kind of, you know, structure to kind of make for a successful deployment of v6. But I think the comment I would kind of end on here and welcome comments is, you know, a decade plus later, you know, I think back ten years ago the OSs were really part of the challenge for us. I remember the days where, you know, we didn't have DPP 6 on Apple, and I couldn't get a DNS server to some ‑‑ DNS server IP to some devices over an RA. I still hear in kind of David's voice, you know, things are starting off pretty, you know, basic, fundamental. I have to admit probably David would agree, a little disappointing, you know, ten years later, but glad to see people like David still care and are leading the charge to help those folks build deployable implementations.
SANDER STEFFANN: Thank you. Questions, anything you want to add from a CDN he is point of view? Because this is ‑‑ like, those are two completely different worlds, like on the one hand, the users, the eyeballs, on the other hand the CDNs and the content. What are the issues you see? How can we make things better?
CHRISTIAN KAUFMANN: First of all, our life is easier, right, we control our own servers, the routers and stuff like that, so nobody puts random stuff in our network. So, we have the technology part under our control. Probably randomly a couple of comments to what people said. When it comes to IPv6 bugs, I don't see them more than any other bugs, if at all. You know, whatever one wants to thinks about vendor software, very different thing but usually v6 bugs are not my biggest issue so, I'm not worried about them, certainly not with a big box vendors.
The interesting part I think is, that came back to the comment about that people believe v6 is similar enough‑ish, but then often not. Putting your v6 into your own processes and in your own systems is probably a bigger problem, right, because it works in some aspects very different and we have this mapping software which tries to figure out where you are located so that we attach it to the next closest server, and all of that, and if the underlying part works different and has different fields and stuff like that, it's not a copy, paste, replace or something like that, right.
So I think that was probably one of the bigger issues, to be honest, than the vendors, where we have an limited set and not so much variety.
.
I found it interesting that people already talk about switching off v4. An interesting statement. I am fine for the time with dual stack, I don't have to kick out v4. I see the fun in it, but on the other side, you know, as we have customers which want to probably connect via v4/v6, I don't control my own content, right, I don't own it, I am perfectly fine for the time being to be dual stack and to transport it, so I have no switch‑off date.
JEN LINKOVA: So, I should say want to comment on the three things at the same time. First of all, as Pete mentioned already, just v6, just dual stack doesn't solve any problem, it just creates more because your operation complexity goes up to the roof, through the roof, because now you have to manage two protocols at the same time and so on.
CHRISTIAN KAUFMANN: Very quickly, that's true, but I already have it.
JEN LINKOVA: Yeah. And I have had it, I hated it, I am getting rid of it. And back to the comment: How can we make vendors better? All those bugs exist because we haven't discovered the various operators. You discovered them ‑‑ you did not use the feature. It maybe existed in the router but nobody used it. It was buggy. Let's use it. So, it's what we have been doing. And very quickly, on my slides I said okay, we have been doing ‑‑ we have been getting v6 experience for ten years. Actually, no. I stand corrected. We have been getting some dual stack experience, and you have no idea how your v6 network works until you turn off v4, because I have been sitting here, I have v6 everywhere, I am done I get retired, then I start turning off IPv4 and a lot of very interesting surprises came to my view from protocol perspective, like protocol design perspective, like, ah, we did not think about that. Or from operational perspective. Things which were hidden by happy eyeballs and nobody complained. So yes, to make v6 working better we need to use it and we need to use v6, not the dual stack.
SANDER STEFFANN: Anybody want to respond to that?
JOHN JASON BRZOZOWSKI: So a couple of things. So, Christian, one of the things in response to your comment, I think back to NANOG 85 where Jan and I got this party started. The day after world v6 ten‑year anniversary, there was a panel about buying and selling IPv4 addresses, and I remember when I was, you know, a good friend of mine contacted me for ‑‑ to kind of rejoin NANOG in the fall of last year, talking about v6, and I remember the first reaction I had was, are we really still talking about this? And that kind of sprung‑board into this conversation during the summer in Montreal, and this kind of dovetailed something that we have all heard from Pete earlier today and in preparation for this panel, the value of an IPv4 address is ridiculous now, in a good way, I think. And what I think what I am seeing is there are people who are particularly interested in v6, you know, using more v6 in the interest of, frankly, monetising their v4. So when I think back to this panel, which consisted of, you know, many good friends and colleagues, I think it's a commercial aspect to something that we have all started, you know, from a logical perspective that really needs to be more of the conversation.
SANDER STEFFANN: Thank you. So, happy eyeballs got mentioned. One of the things that I have seen being discussed, happy eyeballs definitely was necessary ten years ago for World IPv6 Day, World IPv6 Launch, because just turning on v6 without it was considered to be too big a risk. But, is it still helping us today? Is it happy eyeballs still part of the solution or is it now, like Jen said, hiding the issues from us where we now don't see if there is an issue until we really turn off v4 and don't give the host a chance any more? So, I'd like to the opinions of the panel. Like, happy eyeballs, good or harmful?
SEBASTIAN BECKER: Maybe I can add something to that. Because of a big end customer cone, obviously just turning off IPv4 where devices are to home equipment, for instance, like Smart TVs that are not that smart maybe, basically need to work and just to retire them because of someone switches of something that has not directly to do with the vendor, so it's just mentioned because they are sitting here, Google turns off IPv4 to the YouTube player on the Samsung TV does not work any more, obviously may cause a certain kind of problem and blame the wrong people for doing something that should be the way forward in the industry.
So, on the mobile network, it works quite good, just to have that IPv6‑only with 464 ISLAT or Apple is forcing v6 connectivity. Maybe you see it already on end customer routers that is also maybe one step too hide that part that is maybe still for a long time IPv4, maybe IPv4 only in the home equipment of the end customer until people really get also for a smaller devices like IoT and so on, do it IPv6‑only. So it's not that easy just to turn off IPv4 because you retire a lot of stuff, you have no direct influence on, or should not have.
JEN LINKOVA: I'd like to quickly comment. As I said at the very beginning, right, there is no such thing as "we", we don't need happy eyeballs. There are different networks, at different stages of v6 deployment. Happy eyeballs was our make‑before‑break thing. At some point of time you will need to turn it off if you are going v6 only because otherwise you will never know how good your v6 network is but obviously on the early stages of deployment, it's necessary.
DAVID MILES: So, my view on happy eyeballs is that maybe we're looking, from a content providers perspective, right, I believe that we have to support v4 for as long as we have the last users. And John mentioned kind of the elephant in the room kind of money, revenue, turning or v4 tomorrow and losing 50% of the Internet is not a very attractive proposition to any content provider. So I think we want to focus a little bit more on the devices themselves, right, Sebastian you talked about v6 only mobile devices. Here is a shout‑out to the 3 GDP community for going all in on v6 only.
I come from a broadband world, John will remember this, and he is right, like the home network sucks, the home network is full of random stuff. I would actually say probably my network of data centre air conditioner controllers, because at least I can tell them please go and do v6 and I have a check to right if you do. But that's not the case for the home network.
So, my view is happy eyeballs, or its equivalent, right, is going to need to be persisted for as long as the devices in the home are (inaudible), I think that's the reality, they really are v4 by default, and so maybe we need to steer the conversation towards that space, like how do we help those integrators and implementers get v6 and get it standardised.
JOHN JASON BRZOZOWSKI: If I may, before you pass the mic. Happy eyeballs was absolutely essential from my perspective. Jan and I were talking to Stuart Chesire from Apple, who basically gave us the green light to kind of quote him to some extent. Apple, being one the inventors, if not the inventor of happy eyeballs, even to this day, I am certain, protects many user experiences on a daily basis. I was talking to somebody last week about video streaming on Roku [phonetic] devices that lack happy eyeballs support. Shocking how people are trying to reinvent the wheel. There is no need. And frankly, it's pretty simple, well documented and pays dividends, like there is no tomorrow. So, it really saved the day on many fronts, and if I could point back to the beginning of this, Leslie's video, probably one the top three things that came out of World v6 Day was happy eyeballs, still saving the day today.
SANDER STEFFANN: Thank you. We still have about 20 minutes to go. Is there anybody in the audience who has a question for the panel?
AUDIENCE SPEAKER: Benedikt Stockebrand, speaking for myself. Not so much a question but a comment. And the point is, right now what we see is we're ‑‑ we have deployed IPv6. It's there. And we can't go back because if we under do IPv6, we break IPv4 these days, except for people like Sebastian, who works for one the few providers who doesn't have to do that.
So, in a way, we are done. The question now really is where we go and my understanding is, say that as a technical person really, now it's a money issue. Somebody has to pay for the complexity of dual stack that Jen mentioned. Somebody has to a pay for all the stuff you need for DS‑Lite, including first devil support, for end customers who don't have a clue what this is about and the Internet is broken and the mail as well. And I think this is the way that we should really retire IPv4, basically on an economic basis, much like we have mostly ‑‑ I mean, we're not even done with IPv4 these days, there are still people doing IPX or SNA in some networks, but it's hidiously expensive and you don't do that at a large scale and we need to go the same way with the IPv4. We need to do our technical stuff on it but it's now becoming more and more not a technical issue but an economic one.
PETE STEVENS: I'd go with that. To be blunt, we're never going to run out of IPv4 addresses. You can always buy one. The question is how much is it going to cost, and one thing people should be aware of is find a company that has a lot of v4 addresses, divide its market cap by the number of v4 addresses it's got. If that number is lower than the current market price of a v4 address, it's in someone's interest to buy your company, shut it and steal your space. And there is lots of publically available figures you can do and run those over some very large companies and you can get figures as low as $85. Do that for your company and you can work out how much v4 price depreciation you have got before a lot of redundancies start happening.
So, I once bought an ISP at $10 an IP, I got a free hosting company thrown in. You will always be able to buy v4 addresses. Secondly some of the people who want to buy v4 addresses. If a bank wants to buy v4 addresses, it can and it will pay more than you. The question is how do you continue to run your business in a world where you can't get any new IPv4 addresses? What's your expansion plan to keep going when you cannot get IPv4 addresses at a price that makes your business model work? And ultimately, there is two solutions, one of them is v6 and the other one is NAT. And so the question is, can you do it with either or both of those technologies and which one is less painful? You know, pick your choice.
DAVID MILES: Just very quickly on the NAT right. Being a developer/designer and selling carrier‑grade NATs in a previous life, because that is ‑‑ I wanted to draw the attention that does cost, right, so even if you do have that one or two IP addresses it still does cost. The question was what about v6 adoption in Africa earlier? I am sure carrier‑grade NATs are employed and we have to help educate the carrier‑grade NATs, those stable NATs, that was the bane of my life right now over a VRL, I'll tell you more, but these do cost money and v6 is a cheaper alternative. So I just wanted to make that point.
AUDIENCE SPEAKER: Hello. Kostas. A quick comment, first of all, based on the Italian friend that spoke earlier, I can totally verify that just enabling IPv6 in some very key, few telecom operators can make a huge difference, and we made it happen in Greece with just a bunch of friends that enabled IPv6 and put Greece in the top five at that time era, so it works really well in some key players and I wish to thank all the big players ‑ part of them are in this room ‑ for enabling it.
I would also like to mention a comment regarding removing IPv4 completely.
Just a small example. There is an RFC 7439, gap analysis on operating MPLS only IPv6 networks. I guess we're not the only ones that operate MPLS networks. Last time I checked, the gaps are still there. So, is there any push from the big players towards the vendors, and even if the obstacles were removed, do you think it would make sense, cost‑wise, to do this transition and rearchitect the network to remove IPv6 completely? I would definitely love to do that but I'm not really sure.
SANDER STEFFANN: I hope you mean IPv4 there. Anybody want to respond? Next question.
JEN LINKOVA: I am just commenting on yes, it's very sad the situation we have is MPLS stuff and v6. However, practically, just for practically, right, I guess infrastructure might not necessarily be the main consumer of your v4 space, right. So we all know our industry well and I am afraid the ship has sailed. I mean that vendors in the industry seem to be very fond of ‑‑ something ‑‑ for some reason.
AUDIENCE SPEAKER: I would be really interested to know. I understand some big players have implemented the service X or whatever, but for smaller networks, to do such a huge redesign and jump completely, I'm not really sure that business case is there.
AUDIENCE SPEAKER: My name is... from Huawei. I would like to add a little bit to the conversation as I am also the co‑chair of IETF v6 Ops. First just now somebody is asking about IPv6 in Africa. As it was their equipment there we can tell you that Africa now, many governments have actually pushed very strongly operators to do IPv6. So in two or three years, Africa may do better than Italy or Spain here in Europe. So, I think that's the first point.
I think the second point is, I think that we discussed IPv6‑only, and I would like to say that in order to discuss IPv6‑only, we need to divide the scope and get, you know, who exactly is IPv6‑only? Because IPv4 service is going to be there for a long time. But IPv6‑only can still make a lot of sense in that, you know, if you clearly define a scope, and lately in the v6 op we have a draft defining like, you know, when you talk about v6 only, you must have a clear scope. It's very important that this scope, sometimes a box, part of the box can be IPv6‑only, for example, if you have your mobile, then that can be IPv6‑only and the customer facing part can be dual stack only. I think that this is very important in that we can start IPv6‑only in a specific scope and then grow it. Otherwise, if we don't clearly define the scope, I think that then, you know, people will immediately challenge you that, you know, how do you support IPv6‑only? I think that, you know ‑‑ so from my perspective, no operator are going to deploy IPv6. This is probably not a big concern, but the real concern is how we get the small and medium enterprise to deploy IPv6 as they don't need it that much IP address.
I believe that one of the important things is that we really need to start this education process. For example, even the top academic conferences people really don't care about IPv6. So, this is something that we need to change, and I would like to say that, you know, Brian Caddington (?) Is leading the effort to free IPv6 telecommunications book, he is putting it, you know, on GitHub, and if you can, we really hope that you can contribute, because this is one of the key things to educate people eventually to deploy IPv6. Thank you.
JOHN JASON BRZOZOWSKI: May I comment? With all due respect, that's a slightly alarming comment, and again it's been a while since I have been engaged with the IETF. I mean I think ‑‑ and Brian is a lovely man, I have known him for a long time, but kind of a theoretical academic book about the deployment of v6, I think we're past that, right. And I think at this stage, even the IETF, to a large extent, and, Jan, you and I have talked about this as, you know, a mission amongst friends, you know, for you and I. I think at this stage of the game, and I'll kind of point back to a comment David made, and even others on the panel. We have got the tools, right. So, you know, and right now if you look in the home, in many cases like it's protocol super and you you have got to stand on one leg, rub your belly and pat your head to make it work in some ways. I think it's really an operational concern, and if you look back to Pete's comments around, you know, kind of commercial motivations, I struggle to see how, you know, more RFCs, and across the panel, I'd love for you to challenge this, I struggle to see how yet another RFC that does not focus on one particular business case or use case is going to move the needle.
MR. ROBERTS: Haven't we got a demonstration of what it means here. If you connect to that you get a v6 address and if you go ping dot 8 dot 8 dot 8, it says no reacher host. That's v6 only. That's the answer. Give me one of them.
SANDER STEFFANN: If I understood correctly from the NCC staff, we have the NAT64 network, but the actual network runs the same setup; it's now NAT64 by default.
AUDIENCE SPEAKER: Hi. I am... from the NCC, the RIPE NCC. So, here in Europe and in North America we enjoy comparatively strong support for IPv6 and, like some of you mentioned... technologies, leading technologies that are going v6 only, and so ‑‑ but in the developing world v6 is at almost nearly no adoption in the a lot of places as we have mentioned before. And so do you foresee an inherent knowledge gap between the developed and TTL developing world that is implicitly being built by rolling our eyes at v4‑only networks? Really, maybe to no fault of the people actually wanting to learn there but neighbour network providers are perhaps too lazy to flick the switch.
DAVID MILES: I would say I don't think it's just the developing world. The knowledge gap, having interviewed probably 100 network engineers over the last two years and asking everyone of them let's talk IPv6, because it matters to us, the number that can't get beyond it has 128 bits is surprising. So, I think there is a knowledge gap. I think that part of that knowledge gap is driven by the lack of v6 in their home, and I think that's ‑‑ you know, like obviously we have some operators here on the panel who have done big things, you know, I have heard people come up to the microphone and talk about how they have enabled IPv6. And I think it's really that, it's the exposure to it in your home that is the most fundamental to driving wider v6 adoption in the smaller or developing regions, right, just people don't have exposure to it and they don't understand it enough.
AUDIENCE SPEAKER: If I just may add to that, we actually have access to the technology and we have the funding to test and play around a lot easier than people who might not have that access as well. Just by looking at v6‑only networks and kind of promoting those very aggressively, we are kind of building a gap between our development and maybe the development that we wish for others, but they just can't afford it. Maybe you guys have some comments on that?
SANDER STEFFANN: I think one of the things that already got mentioned by Pete, I think at some point IPv6 is going to be the affordable one, not v4.
CHRISTIAN KAUFMANN: A quick one. I think so too, right, then the IP address price goes even further up and they run out of their current space, then training people is actually cheaper than buying new ones, so I think, in the medium term, that fixes itself, but I also think that training and the lack of a need to do something is probably the biggest prohibitor.
SEBASTIAN BECKER: Maybe to end customer devices or network gear, obviously there is cheaper gear around that is not handling IPv6, probably, but until now I think there is enough stuff around if you look good enough and educate yourself that you get that to do IPv6, but you need to be aware of and what you want to achieve for your network. Obviously sometimes it's a bit hard, but we are a community and we are exactly for that here, that's what we as a panel to help people and to say okay, please come to us if you want to have additional information, if there is something you do not know, there are a lot of people that are willing to help.
JEN LINKOVA: And I'd like to point out that it's actually yeah, it's a problem of mentality change. You ask a random network engineer, please ‑‑ something ‑‑ the network connectivity and write a document and we'll use v4 addresses. Even in this room. I used to do that I stopped going to the mic and asking at the end of the presentation, did you do it for v4 or for both protocols? Even here.
DAVID MILES: Let me wield the stick. If you want a job at Meta, I hope you know how v6 works. I think I just said that we're running ‑‑ we intend to run a v6‑only network, right, so to all the network engineers in the room, it does matter. And it is important. And educate yourself if, you know, if you want to stay current. So I think there are going to be some places where v6 really does make a big difference and we're hoping that we are encouraging you all to learn.
JOHN JASON BRZOZOWSKI: One comment for everybody who just had some thoughts. In a past life, we actually looked at procuring IPv6‑only egress routers. David, Paul, probably a very dear friend of both of us, and speaking with Paul, you know, many moons ago from Meta, we were seeing a substantive amount of traction that was v6 Openflow heading to our largest destination, Facebook being one of them, and we found that cost of doing business and the cost of infrastructure, we could buy commodity v6 only equipment that materially changed economics around how, you know, communications flowed between large broadband networks and companies like Meta. I'd love to hear if yourself or Christian, Jen, you know, Sebastian, have thoughts on that topic, but it was ‑‑ the calculations were real and the dollars were as well.
SANDER STEFFANN: I just notice some more people joined the queues, we're running short on time, so please keep it very short.
AUDIENCE SPEAKER: Thank you... Speaking for myself. I have a really quick question for the representative of the Deutsche Telekom. Sorry, I can't help it. You spoke very well about implementing IPv6 and offering all your customers the IPv6 address. When are you going to implement fiber and overall offer all your customers a fiber connection instead of ADSL via the phone line? Thank you.
SANDER STEFFANN: That's off topic for here.
AUDIENCE SPEAKER: Hi. I am Veljko Kos, I am a local and I am speaking for myself. And just speaking from a different paradigm, usually giving up on technologies is the purview of companies like Apple ditching, you know, 3.5 mm plugs on their phones and that forces a whole paradigm shift for everybody else. Is a push like that something you can do in the protocol world?
PETE STEVENS: So we have subtly done this on a few other things. So, does anyone in the world still have a browser that doesn't support SNI for secure SSL certificates which means we don't need a v4 certificate for any more? That one went. We forced a shift. It used to be you needed a v4 and we didn't encrypt anything. Then Windows XP went end of life and everyone went if you get a certificate on Windows XP, we don't care because it's not secure. Then we implemented SNI and SNI became a standard and that meant that I can have a v4/v6 proxy that handles 10,000 SSL connections on one v4 address that allows me to do v6 only at the back‑end. So that was an important step.
And we also did Internet Explorer 6. Does anyone build a website that is compatible with that? That one held us with for five years, then one day YouTube turned or that support my is make and the rest of Google went if they turned it off it must be okay. Then when Google turned it off and everybody else turned it off. The answer is you are using IE6, well you need an e‑browser, the Internet doesn't work for you any more, fix your computer. And so, I mean, we don't have anywhere near high enough take‑up of v6 to do that now. But at some point we are going to be in a position where v4 users are in the ten, 5% region in some networks, and we can start saying, well, they can just get a degraded experience and, if they want a better one, they can upgrade, go talk to your ISP and get it fixed.
SANDER STEFFANN: Ten seconds, please.
AUDIENCE SPEAKER: Hi. I am Pollyanna. Talking about education and IPv6‑only. How we can take the next step in the layers like developers, database admins and everyone. For us, as network engineer, it's very easily talk about v6, but as a survey, for example, if I want to made something like that only IPv6‑only, that means lots of thoughts of all the teams who don't care and user of Cloud servers provider is the price for me to create a v6 or v4 is exactly the same.
SANDER STEFFANN: I think what you just said is just true, I don't know if we have a solution for that right here, but ‑‑
JEN LINKOVA: It's a long way, you need to start now and you might get it in, like, a year's time, yes, but it doesn't make any sense to wait.
AUDIENCE SPEAKER: I have kind ‑‑ I am... I am working at the RIPE NCC, I have a very similar kind of a question so you I think you already answered. Also, like, we keep on hearing that it's enterprise networks that are kind of making IPv6 deployment, lagging behind, and like, what kind of incentives do Cloud providers provide in terms of giving differential services or especially in terms of price for enterprise networks to give them that push to support v6 for their applications?
PETE STEVENS: So we itemise v4 addresses. So you have to pay for every single one you use. And the large enterprises don't care because it's not expensive enough and we'll take their money.
DAVID MILES: And for enterprise, if anybody has ever done that wonderful mergers and acquisitions problems where you have got your ARPs, if there is an incentive for a network operator, it's to avoid that. V6 GUA is pretty useful when it comes to mergers and acquisitions.
SANDER STEFFANN: I see we are already three minutes over. I want to hand the microphone to Jen because you brought something.
JEN LINKOVA: It's not ‑‑ don't make it my fault. I was just thinking that we are celebrating and you know that IPv6 is hard, and we ‑‑ I was talking about educating people, so yes, I got some motivation, at least for people who have done something, who is not deploying IPv6 is not drinking champagne.
(Applause)
(Champagne popped)
SANDER STEFFANN: So, pictures first, the Internet needs to know. Thank you for attending the panel. I think a lot of important things came up that we can still work on, but for now, let's celebrate ten years of IPv6 World Day and World Launch. Thank you.
(Applause)
LIVE CAPTIONING BY
MARY McKEON, RMR, CRR, CBC
DUBLIN, IRELAND.
