These are unedited transcripts and may contain errors.
IPv6 Working Group ?? 26 September 2012 ?? 2 p.m.:
CHAIR: This is the IPv6 Working Group session. I believe next door is DNS. So, if you're interested in domain names, you are in the wrong room.
Okay, let's get it started. A bit of logistics. This session is being webcasted, smile, you are on the Internet. If you don't want to, now is the time to run and hide. It also means that we have got people remote listening to you, so if you decide to ask questions or place comments, please use the microphones, and state your name and affiliation. If you place a comment, for the people watching remote or listening remote, we have got chat rooms available and a Jabber scribe, so Sander will read out your questions where needed.
Please switch electronic devices, especially the ones that make noise.
Logistics. There is an extra session, it was optional. It's no longer optional. Tomorrow, Thursday, nine o'clock, sorry about the time frame, we didn't have a choice. Back here tomorrow for the second half of our agenda.
I'm Marco. You might have seen my face before. I am one of the co?chairs, the other two are Shane who sits up front and I have lost track of David somewhere over there. That's David running around. We can be reached at IPv6?WG?chairs [at] ripe [dot] net. You can also post to the mailing list. You will find our page in the green section on the website as well.
What have we got lined up? We have got quite a full agenda, that's why we need the two slots. Sorry for all things, for all the speakers for submitting their talks, sorry about pushing back in times a bit. We only had two times 90 minutes to fill up. We hope you like it. And what we have got is quite a lot of operational stuff, people who are actually deploying IPv6. So, we have got Liviu, from RDS, you may have seen Romania pop up in the Google statistics, he is going to explain how you get yourself or your country visible at RIPE 66, just follow his example and I am sure you'll be mentioned.
At the same time, we have got two Greek operators, both deploying IPv6 right now as we speak in their problem networks, so that's interesting to see how competitors act amongst themselves and interact with each other and learn from each other. And and to finish it off today a quick glimpse of the new IPv6 server which we are about to launch, and my colleague from the RIPE NCC is going to talk a bit about RIPE net measuring IPv6 deployment and possibly how to get the fifth star.
Wrap?up. Tomorrow's session then, a lot of idea of work, more about work and technology. I have invited, from Cisco to talk a bit about layer 2 issues, routing, announcements and how to secure those separating customers, follow?up of that we have got Mirica talking about Op?sec work and some other talks from Andre. You can see it here. Martin Botterman will be flying in tomorrow morning early, so we hope that his flight is not delayed and he'll make it and he'll show you all about the results of the IPv6 survey.
Two announcements before I stop. First of all, is there is going to be an IPv6 summit in Slovenia again, Jan Zorz is involved and he asked me to point out there is a key note by Bob Hinden, and there are seats available, so if go to that URL now you can get one, it's 18 and 19 October in wonderful Llujiana.
The second one is there is an ITF interim meeting in this hotel on Saturday and one of the sessions includes v6 ops, together with Op?sec and SIDR. In case you are interested, here is the URL to register. And you can be here back on Saturday discussing that topic.
With that, that's all I have to say for now and I would like to introduce our first speaker, which is Liviu from RDS who is going to show us what he did on implementing IPv6 in his network. Good luck.
LIVIU PISLARU: Hi. First of all, thank you RIPE for inviting us here to tell our story about IPv6 deployment in our network. My name is this Liviu Pislaru, I work an architect for about two or three years. I am officially involved in IPv6 deployment in our network.
First, let me tell you a few words about our company. One of the most important telecoms in the region, providing telecommunications services in eight different countries. We are the market leader for broadband and TV services in Romania and Romania is only qua provider of broadband, TV mobile and phone, we are the most competitive prices for all services.
Why we did it, why we did implement IPv6. As you can see on this slide, our last allocation from RIPE was /14 was about half a year before, and obviously IPv4depletion wasn't the trigger. Actually, if you provide dual stack to a customer you won't solve IPv4 depletion problem because you need an IPv4 address as well. We did it mainly because when it comes to I MPLS network in RC S RDS we build almost everything in?house and when you have a do it yourself business model then you have very experienced engineer and an open minded management to any ideas. We considered that the most important ?? the ideal time to gain experience as an engineer is when the RBKI of affecting customer service Yours sincerely minimised. That's why we just implement IPv6 when the size of the Internet, of the IPv6 Internet was less than 0.5%.
So, I have read an article written by Geoff Huston, "The end of IPv4" and inspired by that article, I have drawn this graph that represents our hopes and expectation regarding IPv6 evolution. As you can see, marked with the blue line, is the IPv4 pool size for RCS RDS. We hope that based on our calculation, we will have enough IPv4 resources for another two or three years into 2015. And by that time, the size we hope that the size of IPv6 Internet will be big enough, close to 80, 90%, so, we will be forced to use carrier grade NAT for a small amount of traffic.
I will skip some history details regarding IPv6 evolution in our network because I don't have too much time, but I'll mention that it all started in July 2003 when RIPE gave us the first /32. In July 2009, we decided that it's mandatory to have the full IPv6 BGP table, that's why when we renewed all the contracts with the upstream providers, we put this on the list.
In 2010, we tested qualified and short listed IP routers with dual stack supporting our network. We have a dual vendor policy in backbone, we are using only Cisco and Juniper. The only routers in our network, IP routers that we enabled dual stack on our Cisco 6500, 76 hundred S R 9 K CRS and Juniper MX is 916 special.
2011 in June, World IPv6 Day, we started to act. Four months later in October 2011 we started a pilot programme based on signup. I'll give you more details on that on my next slide. Our goal was IPv6 to every residential customer. It's important the fact that we are providing now IPv6 only to residential customers, because we are using BBB reauthentication. We build up a virtual team for several highly qualified engineer from different offices in Romania, our main goal was IPv6 deployment in our network. We kept the same IP routing policy as before. We are using CPE prefix delegation.
We have a data sell business model and we have a distributed and redundant BNG system that gives us a lot of flexibility when it comes to IPv6.
The biggest issue was the lack of IPv6 support on CPEs. That's why we modified the Linux version for embedded devices like open WRT to do what we need. We needed IPv6, PPP O E and prefix delegation and then ask for the similar firmware from different vendors like Links?IX, who o A, dry tech and freeze box and son, and in 2012, all of them have CPEs that support what our customers need in terms of IPv6.
So we started a pilot project in October 2011. We announced it with a press release. The programme was available in 20 cities in Romania and was based on signup. And our big surprise was to see that in less than six months, 12,000 customers haven rolled to IPv6 trial and as you can see here on this graph, a third of them actually succeed to connect IPv6 in our network.
Six months later, we ended up successfully, the pilot project and decided to give IPv6 to every single residential customer. That's why as you can see on this graph here, adoption rate percent was around 0.2 in March. All the customers that haven rolled to IPv6 trial then around 1% in April and starting in May, the adoption rate was 10% and at world IPv6 launch this year in June, we had 18.6% and that placed us on the first place among adoption rate, among all ISPs. The percentage has been growing ever since because as you can see this month in September we have 25%. Meaning that one out of four customers in our network are using now IPv6.
(Applause)
Let me give you some more details about world IPv6 launch. This is our IPv6 CDN traffic. As you can see, most of the traffic is Google and 5% of it is Akamai. The traffic as you can see didn't increase after world IPv6 launch mainly because we already have our DNSes what listed by Google. The traffic actually decreased because Google started blacklisting some of our DNS servers and that helped us a lot because we identified and isolated some problems in our network. It was a problem with some BGP flapping between Quagga an our B N Gs and 76 hundred from Cisco. And we had also a link local problem. Both solved, so we decided to measure IPv6 brokeness ourselves. Ignore the green line. The blue line indicates the IPv6 brokenness with more than 50 second delay in our network and the average is around, I don't know, 0.07, 0.05 or less. So, we don't have any problem with brokenness right now in our network.
So, it was a success story with Google and let's say a different story with Akamai. Mainly because Akamai traffic was not entirely surfed from our data centre, and we had to pay for it. As you can see here in this example, when a customer ?? when a v4 only customer is in our network tried to access Facebook dotcom, then all the content is served from the Akamai cluster in our data centre. If we move the customer from v6 then part of the traffic, marked here with a red spot, is surfed from different Akamai clusters in Europe. That's why the Akamai, our traffic increased, our v6 traffic increased in European peerings and we have to pay for it and also the latency also increased. As you can see here, we have the measuring TCP latency since June and Akamai, Cisco and Binges, all served by Akamai, have way too big a v6 latency compared to v4, and Yahoo, Hurricane Electric and RIPE have no problem with TCP latency.
Here are some measurements made by APNIC regarding adoption rate per SIP. As you can ISP. As you can see we are in first place at June world IPv6 launch day, we're at 18.6 percent. The percentage has been growing ever since to 24.92 right now.
The second place is K DD I in Japan, proximate add free from France, AT&T and so on.
We almost reached 20 gigabit of IPv6 traffic in our network, which, in my opinion, is huge, compared to, let's say, IXs in Europe like LINX, DECIX, which are huge but only have 3 or 5 gigabit of traffic. Half of the traffic is CDN and most of the CDN traffic is Google. But we have also 6 gigabit of IPv6 peering and I include here also IPv6 from transit providers. And about 3 gigabit of traffic is traffic flowing between customers within our network, most of it I have to admit is peer?to?peer, that's why you can see 4 gigabit of upload as well.
Some measurements from Google. IPv6 adoption rate per country. Remoan an is leading this top with 8%. I hope the line is flat because of, I don't know, the summer holiday and I hope it will increase sooner.
IPv6 adoption rate per country. June world IPv6 launch, remoan a was leading with 7.4 percent. Now we have, in September, almost 11% IPv6 adoption rate.
IPv6 adoption rate in Romania, RCS RDS 25%. Romania 11%. If you take into consideration that the market share for broadband for RCS RDS in Romania is around 40%, then you conclude the other networks or ISPs in Romania have an adoption rate close to zero, unfortunately.
Conclusion:
IPv6 transition in RCS RDS was very, very smooth. I can give you a short example here. I have a personal website with a pool. The question is are you using IPv6 with different answers? Okay, I'm not using IPv6, I don't know what IPv6 is. I'm using IPv6 for RCS RDS and so on.
12 plus 28, meaning 40% of the people answered that they don't know what IPv6 is, or they are not using IPv6, but when I looked into my website log, I saw that most of them voted for an IPv6 address.
Short?term plans: By the end of this year replace the /64 with a /56 for residential customers. And provide IPv6 to all customers of RCS RDS including MPLS customers and also business to business. They are not using ?? we are not using PPP over ethernet for this kind of customers.
Long terms plans: Delay as much as possible any sort of ?? grade NAT. I know there is a presentation about how good is Grade NAT, but this is my personal opinion. Maybe we'll succeed to change my mind, but I am pessimistic about that.
Thank you very much. If you have any questions, feel free...
CHAIR: Lorenzo.
AUDIENCE SPEAKER: Congratulations of showing the rest of the world the way, but that's what I'm not ?? you know, who I got up here to say. It occurs to me that given that you have real working v6 and your IP address needs will come mostly from new customers, if those customers are equipped with IPv6 capable CPE devices you can use something just like map instead of doing NAT and use stateless solutions, because you already have v6. That's just an idea.
LIVIU PISLARU: Thank you.
AUDIENCE SPEAKER: Martin Hannigan. Thank you very much, that was a very excellent presentation. I was particularly interested in the traffic numbers, the Google numbers are very impressive. A little bit easier to measure. The Akamai platform is fully IPv6 enabled but on IPv6 days customers opted in so not all properties would be served over v6, would you still see even with v6, the v4 enabled properties as well. With regards to the latency, this is the first time I saw the presentation. I am going to take the presentation and see if I can figure out what happened there. There is probably some valid explanations but I'll get back to you on that. Thank you.
GERT DÖRING: Thanks for showing the world that it can be done. And it will just work. Because I'm sitting in one of these funny countries that have IPv6 since 15 years and no large broadband provider is providing v6 and I hope that this example will help make things happen. Thank you.
LORENZO COLITTI: The question to Gert was, do you happen to know if said large broadband provider happens to use the same access technology that they use?
JAN ZORZ: Thank you, as everybody has told you great presentation, I hope to have more to come from different countries.
My question actually is, you said your short?term plan is to move from dynamic /64 prefix delegation to /56. Will you manage to make it static or will you continue to use the dynamic madness?
LIVIU PISLARU: We will continue to use the dynamic /56 address for this kind of customers, residential customers. For business customers, we will use a /48 staticically.
AUDIENCE SPEAKER: Tahar Schaa, consultant for German administration. Excellent presentation, thank you. And you said you adapted DD VRT and open VRT. Where are these implementations? Are they available, because it's horrible to look for open routing implementations.
LIVIU PISLARU: I can give you the image if you want, we installed it for example on our Linxes WRT 54GL.
AUDIENCE SPEAKER: By my impression is the maintenance of these projects are stacked to IPv6. It's not publically available.
LORENZO COLITTI: Can I follow?up on that? If you are looking for IPv6 CPEs, you can buy them, you know. You can buy a Linxes, you can by DELINK, they will support IPv6. It's coming up later on.
If you want an IPv6 CPE, go to your favourite online retailer, by a DELINK or Linxes and it will support IPv6. You don't need to implement your own version or DD WRT. If you go to the world dot picks launch page you will find linking to all the manufacturers pages where they implement IPv6 in their products and Marco I am sure has even more information on that.
MARCO HOGEWONING: Somewhere later in this session we'll show some more information on that topic.
LORENZO COLITTI: You you don't need to customise your router to get v6 support.
AUDIENCE SPEAKER: But I would like to.
CHAIR: Thank you for your wonderful presentation. Let's hope in Dublin we can see 100 there.
Next up, moving slightly down south into Europe, it's OTE from Greece, and Yannis going to show us the work he has done in doing IPv6 launch day, stuff they have learned, things that worked, expectedly, unexpectable, things that didn't work, expectable or as expected, failed...
YANNIS NIKOLOPOULOUS: Hello. My name is Yannis Nikolopoulos. Yannis is quite easy to remember. And I am here ?? well amongst other things, I am trying to coordinate a group of very bright engineers for my company also known as the IPv6 Working Group of OTE. Which is a company I work for of course.
Just a few numbers. We supposedly were the largest ISP in Greece Telco as well. Almost 4 and a half million broadband ADSL subscribers with video sell on the way. Some 3 million landlines and well a few IPv subscribers, we are getting there as well and we are also an IMS provider mainly for the public sector but also for some large customers, banks and stuff like that.
So, just a few important dates on your IPv6 timeline. We started around, just before 2004, which was already a bit late. The proof of concept lab, just, a couple of Cisco routers and tried OSP v3, it worked so we just put it to rest for another four years.
Okay, around 2008, we laid down our first addressing plan. And then well things started to role. Well, we introduced the Working Group in the company and then we did our dual stack, the core, we did our peerings, and then we did our first trials, broadband trials. Just before the world 6 day we started our internal BRAS trials and we were supposed to do, to go public with your BRAS trials right about now. But we're not just there yet.
We hope, we hope to be able to launch our commercial portfolio of dual stack services somewhere in 2013, maybe a bit optimistic here.
Just a quick few slides about our deployment so far. We chose dual stack as a transition method. We started from the core, worked our way words to the edge. Dual stack in the core was the easiest thing we had to do. Then we did the peerings with our upstream provider, with the local Internet Exchange. Went on did the aggregation layer, no problems. And finally, did the access layer. At least the core facing side. Because the customer facing side is not there yet. Well not fully anyway.
A few words about our broadband trials. Well, we thought we'd dot easy thing. We didn't want to mess with our production setup, which was termination, PPP termination at the BRAS so, what we did was we left the BRASes alone and we tunnelled a new domain, namely IPv6 OTE.GR to a group of IPv6 capable LNSes, Cisco, 7301s I think. And where we could terminate the dual stack PPP sessions. We introduced dedicated cluster of servers for the basic dual stack Internet services, like web port hole and some DNS, which was white?listed by Google, and AAA. So, this was, this is still ?? I mean this has been going on for the past two and a half years and it's still going on.
The latest flavour in this trial is the static flavour because I forgot to mention that we assign a ?? well, up to now we assigned a dynamic /56 to the end customer. Now we have a static flavour where we assign a static 56 to the customer. We don't have a reverse DNS support yet. We are thinking about that. But we are still considering the static offering to be the commercial offering as well, not just the, not just for the trials, so we're thinking of a static model where the customer is static per port hole or maybe better BNG device or whatever, we are not thinking about the a roaming static. We did that mistake in IPv4 and we're still paying for that.
So upcoming trials: As I mentioned before, the upcoming trials is the BRAS trial where we just, where our users already terminated the BRAS, so, they are going to terminate the dual stack PPP session at the BRAS. As I said we're not there yet because we had to install and try a new OS version, but hopefully in the next month or so, we'll deploy two or three BRASes from the production network.
So, this is just your basic service. Which is going to be enabled by default. No configuration will be needed from the customer side. All the customer will need is an IPv6 capable CPE. Turn on IPv6 and you're good to go. But we're still considering a couple of scenarios where things could go wrong, so that we will be able to sort of fallback the device or maybe the user to an IPv4 only state.
So, what's next? We are trying to involve the rest of the organisation, that's not very easy all the time with the IT people, for example, we need the basic IPv6 functionality implemented into our OSS systems. When I say basic, I mean really basic like an IPv6 address. I mean that basic.
Product development: We have been to discussions in order to convince them that there is no product involvement required. And also we are trying to educate the sales people, because quite a few of our customers are requesting IPv6 because they have heard of the trials. VPN customers or lease line customers, so we need to make them aware that we can provide the service, at least on a trial basis. And last but not least, the call centres. We need to prepare them, and actually, we have done some steps into the right direction because in cooperation with the Helenic IPv6 taskforce we have organised open sessions with call centres representatives and that went really well and we also organised some internal sessions with our own call centres people.
So as I said, we need to see if any justments need to be made for products and services, hopefully not, but you never know. And no rebranding as well. Actually the next 12 months are quite critical for us because as I said, as I mentioned earlier, we need to make 2013 for commercial services launch.
So, the future was forever. But it was a big deal as well. It was a big deal because, well as you all know, companies, I mean people like Google and Facebook and Cisco and Akamai just turned on IPv6 and let it on, which means loads more IPv6 traffic was possible, well is possible.
So, what we did in preparation. Since we ?? well, to be honest with you, we knew that we wouldn't be able to formally participate in the launch because we couldn't reach the percentage of broadband users needed, I think it was something like 2% and we had less than 0.2. So, we just thought, well, instead, we'll educate people. So, what we did is we tried to spread the word both internally and externally. You know, our users and the people that would be called upon to hear the complaints that would be maybe related to the launch problems.
And what sort of problem are we talking about? Well IPv6 brokenness. Well ever since Tore Anderson did those really nice measurements for the World IPv6 Day, we just trying to find an excuse to do the same. So the launch seemed like a very good idea. So what we did, is we attempted to measure those broken IPv6 connections ahead of the launch, about a month earlier actually. The methodology used was Tory Anderson's methodology and again in cooperation with the Helenic task force, and of course two major Greek sides that were willing to help, we did finally get some web statistics. Before I forget, of course we had the country wide Google stats that hinted some issue, some issue. What issue? Well that was the issue. The issue was that especially ?? well, from our AS system there was an especially high number of broken IPv6 connections and, yeah, okay, I mean we did have Google contacted us straight away for the matter, and we tried to work things out. I mean Google had a different opinion, I'm sure Lorenzo will tell you all about it. But we did what we thought we should do in order to resolve the situation.
So, what was the issue though? What was the issue? That was the issue. I mean, the issue was that you get a CPE, which has IPv6 disabled by default in the one side, but has IPv6 enabled by default in the LAN side. That advertises a 3 FFE prefix to its LAN interface for no reason. That was definitely a non?issue for our dual stack users, because when a dual stack CPE ?? when the dual stack user got, you know, the prefix from the network, it would just use that correct prefix. But it was a big issue for our v4 only customers, a big issue. Because they couldn't access dual stack sites ?? sorry ??
AUDIENCE SPEAKER: Just to clarify comment. My name smashing Townsley I work at Cisco. You said that this first point was an issue for your dual stack customers. It sounds like it's an issue for your single stack customers.
YANNIS NIKOLOPOULOUS: That's exactly what I'm saying.
AUDIENCE SPEAKER: Just give everybody dual stack and the bug goes away.
YANNIS NIKOLOPOULOUS: Yeah, sure. Easier said than done. Okay. So ?? right, so, as you can probably imagine, that CPE was a v4 user and Internet explorer not supporting the happy ?? some flavour or happy eyeballs was a disaster.
How did we not notice this issue? I'm sure that people wonder about that. I mean we are still wondering. Well, not many dual stack sites existed in Greece before the launch. So, even if there were some customers complaining, they wouldn't know that they were complaining about a v6 specific issue. So, even if some complaints reached our call centres, they wouldn't ?? they wouldn't be able to relate it to IPv6. But more importantly, we were a bit unlucky because the IPv6 features set on the specific, on that specific CPE was optional because that CPE has been on the network for OTE for more than two years where the IPv6 features was just optional. So, at the time, we thought that this was a bonus that, you know, we have an IPv6 feature set on a non?mandatory request for IPv6.
Well in any case, for the past two years, we do have a mandatory IPv6 feature set for all our CPEs.
So, what we did to resolve it. The first thing we did was the obvious thing to do. We contacted the vendor straight away, requested for a new firmware. To be honest with you, at the time I thought that this would take maybe one or two weeks or maybe three weeks at most. Well, it took a bit more than that. So, in the meantime, we needed to implement and work around that would sort of protect our v4 users. What we did is ?? well we implemented DNS work around, basically filter out AAAA records, when they came from v4 only transport. So that didn't affect our v4 only users ?? sorry, that didn't affect our trial users, and it really didn't affect our ?? the rest of the IPv4 user base.
We do know that ?? well, before that ?? we do know that this is a temporary solution. It still is.
Anyway, as you can see, the DNS work around, when applied, it resolved the issue, or at least it masked the issue, right.
So, yeah, let me just again stress that this is a temporary work around until of course the the new firmware arrives, which is yet nowhere to be seen. We did have a lot of ?? can I finish my presentation first or would you like to ??
AUDIENCE SPEAKER: Just a quick comment. If you can't find new firmware, change the vendor.
YANNIS NIKOLOPOULOUS: I have no comment on that which means I agree with you. Anyway...
So, the other problem is that the DNS work around will be masking other possible issues and when we do finally get that firmware that will resolve the issue, then we'll find out new issues and we'll have to deal with them as they come. There is no moral ?? I mean, there is no lessons, according to ?? well, in my opinion, there is no really ?? there is not a lesson to be learned here. It's just things that can wrong usually go wrong. We just experienced something unexpected.
And to finish up in a more optimistic note. If you can call that optimistic. Well, at least we see it as optimistic. We do see that there is an ex pang, albeit slowly expanding, user base, and we do know that we need a boost, and that boost will be the CPE and we are almost there because right now, we do have 3 IPv6 capable CPEs that have passed our tests excluding the one that has a problem. So, hopefully in the next six months or so, we'll see that big surge in the IPv6 user base we're longing for.
That's it for me. Any questions?
LORENZO: So, assuming that the evil CPE never gets fixed because we know that BGP was a temporary solution, right, so it lasted for 20 years and there is no replacement in sight, so assume that it never gets fixed. You know, can you move words to IPv6 or not? Does it completely block you?
YANNIS NIKOLOPOULOUS: It doesn't completely block us, first of all I have to say that the latest firmware we have resolves this issue, but breaks some other things.
LORENZO COLITTI: So you do have an update for that CPE, it just has different bugs than before.
YANNIS NIKOLOPOULOUS: We do, but it still breaks other stuff. It breaks DNS in a whole other way. But it's not blocking because this CPEs are getting decommissioned. We are getting brand new CPEs and in the next six to eight months, we are going to have around 300,000 new CPEs, all IPv6 capable and tested.
LORENZO COLITTI: Are you going to replace all the ones that are evil and broken and still in the field?
YANNIS NIKOLOPOULOUS: We are, if the firmware does not fix the issues. But that's not going to happen overnight. As you probably realise.
LORENZO COLITTI: Right. The question S. If you can update those CPEs, your v6 deployment will basically never happen, because you can never get ?? unless you get ?? when you get the last CPE out of the network, then you can turn it on.
YANNIS NIKOLOPOULOUS: I don't see it exactly like that because we are talking about 80 CPEs but we are moving towards VDSL at the moment. I know we are not going to have a 50% penetration in the next six months. I know that for sure, but what we're looking for S we're looking for around 50 to 100,000 customers.
LORENZO COLITTI: So you abandon that old network and the new network will work fine.
YANNIS NIKOLOPOULOUS: We don't abandon.
LORENZO COLITTI: For now. You separate the two networks. You leave the filtering in place on the old network.
YANNIS NIKOLOPOULOUS: Even in the old network as you call, it I assume you mean the ADSL plus ?? we have another three IPv6 capable CPEs. It's not just this one.
LORENZO COLITTI: My question is how can you roll out ??
YANNIS NIKOLOPOULOUS: Just one final thing. It's easy to blow the things out of proportion here in order to, you know, to put things in perspective, we are talking about several thousand CPEs. We are not talking about 100,000, we are talking about 20,000 CPEs out of 1.4 million.
LORENZO COLITTI: Yeah, the question was only, you know: If you can't get rid of them, what percentage of breakage is acceptable for you to throw that number of users under the bus and roll out v6 anyway? Because there will be a number of users that will break unless you separate the networks, unless you separate the DNS service, so that's kind of ?? I'm sure that you're thinking about it but just for the other people in the room, when you're here, now have way out except separating the DNS servers or breaking users.
And another question I don't suppose you can, and I am sure you would like to but maybe you can't is, suppose that some other network had bought this device from the same vendor, on some other continent had bought this same device, you know, maybe he don't know that you had this problem. Maybe they have the same problem and they don't know how to fix it. Can you say who it is?
YANNIS NIKOLOPOULOUS: No.
LORENZO COLITTI: Thank you.
AUDIENCE SPEAKER: Sander branch RIPE NCC on chat monitoring, there is a question from Alan Steel: Wouldn't be it easier to just enable IPv6 in that particular CPE setup?
YANNIS NIKOLOPOULOUS: Yes, that's an option that we have considered and we are still considering if you know things don't go well with the firmware.
AUDIENCE SPEAKER: Eric Kline, Google. Has the ?? you said you were working with the Helenic IPv6 task force. Have they considered having some kind of a Helenic IPv6 launch event to help sort of you and other people in Greece?
YANNIS NIKOLOPOULOUS: We did talk about it, but I'm not sure what you mean by event. What happened was there was a big press release. There wasn't ??
AUDIENCE SPEAKER: There is always a press release.
YANNIS NIKOLOPOULOUS: Of course. But the participating companies, the participating I mean in the Helenic IPv6 task force were not officially participating in the launch, you know, as service providers.
AUDIENCE SPEAKER: I mean, an event like next year, Japan is another situation they have their own thing and there is a discussion about whether or not there should be a Japan IPv6 launch event as a way to focus socially the energy around deploying v6. I was just offering it up as an idea, maybe the Helenic IPv6 task force would be able to organise something for 2013.
YANNIS NIKOLOPOULOUS: We are always, as a task force, I mean, we are always on the look out for new ways to promote IPv6. That was the main reason we got together in the first place. So, we'll take ??
AUDIENCE SPEAKER: You should challenge each other to deploy.
YANNIS NIKOLOPOULOUS: We'll take it up.
CHAIR: Thank you Yannis. And of course everybody in the for their comments.
(Applause)
CHAIR: Looking a bit at the historic Helenic IPv6 launch day, I see all kinds of images with wooden horses. It could be interesting, possibly. Next up, here is Anastasios Chatzithomaoglou from Greece.
ANASTASIOS CHATZITHOMAOGLOU: Hello everyone, my name is Anastasios Chatzithomaoglou. I am from I am going to say some words about the IPv6 deployment in Forthnet. In some things that we met issues and some experience that is we got throughout trying to implement IPv6 in our network.
This is us. This goes for Geoff and Lorenzo because we have here a lot of comments about Greece and Greek people while you are here. So, I say we are not leaving from RIPE. I don't know what happen with the European Union, this is a gift card that they won here, so this goes for Greece.
This is our agenda. I am going to say some things about Forthnet. Why we started IPv6, when we started and how deployed. Some things that were done with experiments and experience and things about nan bots and game controls.
This is us working. As you can see we are very IPv6 addicted.
This is something that we always pushed our vendors this, came out in April. We tried to make that a formal document inside our company for every kind of network that we use.
Forthnet is the largest fixed operators in Greece. We have around half a million broadband subscribers and IPv6 is, this is how we are currently. We have around 100 dual stack pilot subscribers, these are subscribers that all, that are friendly subscribers. All subscribers ?? we started one year ago. We usually have around 1,000 dual stack active subscribers, this means they are already active in using IPv6 and IPv4 in order to access the Internet. Most of them are using ?? because we haven't still IPv6 CPEs. So some of them from already found their way to enable IPv6. Other of them have their own CPE which supports IPv6.
We have also 5,000 subscribers that are ready to be activated. These are subscribers that have an enabled IPv6 CPE, but IPv6 not enabled, we are going to enable it through the D R 69 platform throughout next days and I am going to explain later why we are delaying it.
And we have a lot of ?? more than 100,000 user subscribers, these are subscribers that have modem and CPE, that firmware doesn't support IPv6 but a firmware that we are already testing, a better firmware is going to support IPv6 and we are planning to roll out that during the next year.
And these are the numbers that we're expecting until the end of the year, or one week before, and these are the numbers we are expecting through the end of next year. If everything goes well and we don't meet any problems.
Everything that have to IPv6 agreement network and ??
Just some max. Before roll out IPv6 day, we made the formal document that every CPE that we buy and provide to customers must support dual stack. Support is with or without firmware upgrade. We didn't ?? at that time, we didn't want it to have IPv6 but we wanted to be sure that it will have that in the future.
Since that year, we have added that as ?? we added DS?Lite as the requisite and for the next year we are going to add PCP unless something changes and DS?Lite doesn't work the way we want it.
Now, this is all the reasons that we are discussing, why we should move to IPv6, why we must implementation IPv6 in the network. The one in the red is the one that cost approved by everyone, so our main reason for moving to IPv6 is, we are running out of IPv4 addresses.
SHANE KERR: I had a question about the PCP requirement, because isn't PCP still being standardized? So you are leading ?? you are hoping for the best in the standards process.
ANASTASIOS CHATZITHOMAOGLOU: We already have better firmware based on drafts and we hope the PCP Working Group will finish the answer. So to ??
SHANE KERR: I think they hope the same thing.
ANASTASIOS CHATZITHOMAOGLOU: I have some other slides later about some other...
This is how how we started. We didn't start very early. We started with the test documentation network. We did some things with IPv6 when we, when we decided okay it's time to look at it. Three years ago we officially started IPv6 so we go /8 from RIPE. One year later we started implementing dual stack. We finished most of our network. Or at least the core parts of the network and we started the official, the IPv6 pilot with the subscribers, the pilot was started at the time there was the World IPv6 Day. This year we have started enabling IPv6 on our production peers so we started getting dual stack access and we started also doing DS?Lite tests and we're going to provide the tests later. Currently we are in the situation that we have got a new expansion of our network, our IPv6 for RIPE. We have already started setting IPv6 to your subscribers and we plan to fart DS?Lite after we finish ??
Hopefully, the next year being to start doing some PCP tests, probably, if we have more information, we'll probably start earlier.
This is how network is very high level. Green is good we have already enabled v6, is enable IPv6. There is a sign that says ?? this is where the sign dot IT is blocking us from doing IPv6 there.
I am going to skip that. What we have done regarding our experience and our education, inside our company and outside.
This is the major issues we have had in the previous year and the same measures how do they change in this year, CPs got lower, because we have CPEs we haven't any bugs. Authentication also got lower. But systems packet got much higher because IT didn't hear that so we are like in a hurry. Back in one year we had the question of using tunnelling and translation and sometime before the end of 2011 we chose DS?Lite.
This is what we have done some tests in the pilot in streaming during the IPv6 world day, we had the streaming site and we also started the official pilot for subscribers.
This is the first week after we started our pilot. The blue line represents the subscribers of dual stack. The subscribers that happen only had the dual stack. This graph now is the blue line has reached almost 100 while the red line is almost the same so we are happy that almost 09 percent of our pilot subscribers have managed to enabled users with IPv6.
This year, we decided to enable IPv6 during world IPv6 launch. We decided to enable IPv6 on our production BRAS and we saw an increase in traffic the but we are quite low before.
And this is a measurement we took one day in July when we had, we tried to choose a day which I pick, and we tried to find out what kind of traffic our subscribers were uploading and downloading and we found that around one third of subscribers are downloading or uploading more IPv6 traffic than IPv4, which is quite good. And we also had subscribers that almost 100 percent of the traffic was solely IPv6. Also on the other side we had subscribers who only had IPv4 but the amount of traffic was much higher.
Some things about us and our address. This is a fairly high level of how we split our /69. We are still doing summary addressing. We haven't look for infrastructure. We have three types of POPs regarding depending on number of customers and services on each POP.
And this where you can see this thing. We have two types of customers, businesses and residential. Businesses get a /64 as usual. Home customers get something lower, currently we are thinking of changing that since we got the larger space and we go to the subscribers we get 156 for the LAN, that's. You also have two types: Dynamic and static. We chose to go to the dam I can scenario and give the option to users to choose how dynamic they want to have that. And this is what we're seeing and what issues we met before deciding that.
So we had the issue of, we wanted to have the subscriber keep IPv6, the same as IPv6 prefix as much as possible, due to the number of users but also we were afraid of the deaggregation, not currently, but in the future of IPv6 on bra. Also marketing department doesn't like a static scenario. Because IPv4 and static sells more and it costs more. Some subscribers, when did have some that looks like stack scenario, these subscribers are the ones that are having some scripture that fills us downloading from free sites and they are able to disconnect and change IP. Well, as technical people, we don't like the dynamic scenario. We have some limitations. Every user can log into more than a BRAS because another a BRAS cluster. We don't use any DHCP server currently. While doing authentication a server cannot know if the subscriber is IPv6 enabled, something that the DHCP server doesn't know. So we had to improvise. This is an ugly hat that I will say it works so we'll keep it for a moment and we are trying to change in the future.
So what we have done: We created a bunch of prefixes stored them in a database where they registered, and we have a ?? ?? a unique prefixes reserve by the subscriber and the first time he logs in and that prefix is tied to a subscriber for a specific period of time. That time is configureable by the user, before this one week so the subscribe can choose to keep that prefix for as long as he likes. As long as the time hasn't expired, the subscriber regardless of how many times he logs into any BRAS to the class he belongs he will get the same prefix. If the timer expires and the subscriber disconnects then the next time he connects he will get a new prefix.
We had to do a lot of tuning on the side base because we use the standard base. The increased communication times, you can see the timings that go from 10 millisecond to 100 milliseconds. We used 128 proximate per second. With one database cluster. We did a lot of ?? we got it down to 30 minutes. Still not good enough for our experience. So we are trying to optimise, change the ?? most probably ?? or move to static.
Some things about this console. The user in or network. This is our topology, so we have FDR, we have ?? which is dual stack. Everything in the record is dual stack but if the arrows is using an IPv4 link in order to access that before Internet. This decision was taken last year when this seemed like the best solution to have for solving our problem.
We have tested with Juniper F D P router, 3 CPEs. FDR are going to be sold beside some limitation that is we expect from Juniper to get from our customers. CPEs when do have a lot of ?? regarding a through?put of MP U ?? fixes can be made easily, that's what he feedback we get from our PC E vendors so, we hope that we'll have them fixed at the beginning of next year where we are planning to officially have DS?Lite.
Sometimes we did it. Most things worked as expected. Like utilities. Some things don't work. Okay recollect everything regarding services stuff doesn't work as expected. Torrent doesn't work initially, but after a while some can find the server and work. So we think that might be solved by updating the Torrent programme. Of course again we have to miss a lot of online gaming.
Just some output established for the FDR. You can see the antennae flows where that is happening and that's an interesting output because, there is one source the number ports used it a bug, we are expecting from Juniper to have more details on that.
And these are the issues, the red ones, that we hope PCP will provide some kind of solution. The thing that PCP doesn't support multi?requests so we expect things to be not optimal way like we'd like them. But it's something that we said we'll follow at least. And we have ?? ratio of 1 to 6 again in the public for private address.
Thank you. We accept donations.
(Applause)
CHAIR: I see a line at the mike, so Jan.
AUDIENCE SPEAKER: Jan Zorz. Thank you for this great presentation numbers and everything. Okay, I think that the decision with DS?Lite is a terrible idea, you have better options now available, but I don't want to go into this discussion now. What I really like from all three presentations that we heard today, Romanian and yours and the other Greek, is the timeline, right. That we started in 2008. That we started 2003, we started 2006. Today it's 2012 and this is a really good message for everyone, for everybody that did not start implementing IPv6 yet, the operators, that this takes time. Implementation and rollout of IPv6 does not happen overnight. So everybody ??
ANASTASIOS CHATZITHOMAOGLOU: This is something that we had to persuade our shareholders to okay you need to accept that we need to go to IPv6.
AUDIENCE SPEAKER: Jan Zorz after four years you have a working pilot. So, you know, it takes years.
CHAIR: So your message is you're too late or start now?
AUDIENCE SPEAKER: Start now.
SHANE KERR: This is Shane Kerr. On one of your slides you mentioned that you don't have a DHCP server and that's ?? why don't you have a DHCP 6 server.
ANASTASIOS CHATZITHOMAOGLOU: Currently we don't have a service using it so we don't have one. We don't want to go with custom hardware and with just a desk top and a free DHCP server. We are looking at DCP appliances, but we are also trying to find a way to avoid that if possible. Currently we are not doing our best. We have that issue. If we don't solve that, we probably move to IPv6. We us the BRAS as a DHCP server for prefix delegation only and we pass the information to another users. And we need to find a way to correlate after, if we decide to move the DHCP 6, to correlate subscriber with DHCP prefix because on the DCP server, you don't get the user name, you get something else. So we need somehow to correlate those attributes.
AUDIENCE SPEAKER: Mark Townsley. I'm going to say the thing that Jan didn't want to say. If you saw my presentation on Monday, I do think that there are better alternatives available and that you are not alone in running into some issues with DS?Lite and maybe it wasn't as baked adds you were led to believe and you have to go back and do PCP or this or that and have version 2 in the CPE or this or that and maybe it's a moment to step back and say, hang on, maybe that was not the right technology to choose, maybe there is something better.
ANASTASIOS CHATZITHOMAOGLOU: It probably would do that if we had more time. But I don't know if we have more time to experiment, because it took us around 18 firm wears, CPE firm wears in order to find the right one. And we haven't finished. So we'll start testing map and all this stuff, we probably have another eight months. I don't know.
AUDIENCE SPEAKER: Given that you're having all these problems with the DS?Lite deployment and waiting on PCP and things like that, it seems like it's providing you time to evaluate map that doesn't need any of that, right, and might actually work better.
CHAIR: Sander, you had any comments?
AUDIENCE SPEAKER: It's been answered already.
CHAIR: Thank you. Now I have got to split myself. David do you want to introduce me then?
CHAIR: Here is the next speaker, random participant in the RIPE community, also happens to work at the RIPE NCC and he is going to do a version of a new version of the IPv6 CPE survey. As all of, you know, CPEs are a hot topic.
MARCO HOGEWONING: I also work for the RIPE NCC, and this started before I joined the RIPE NCC when I was working at ?? roll also challenged with how to find CPE. A lot of people ask can you do an update? It's already I think Lorenzo pointed out things are for sale, so at first we thought, like, yeah, maybe not. It's clear, you can go out to a shop and buy an IPv6 ready CPE. But still people seem to be like, yeah, but where to go and what to buy. So, we did another run and we basically went back to where it started.
We contacted all known or at least the CPE vendors we knew that are doing IPv6. And we asked them, can you give us a brief overview of what, which models, which firmwares and which technologies do you support? And and we put it all on the website.
So, it's basically back. Well, we removed all the usual feedback for now. We removed all the testing and as you have seen in the previous three presentations, every network is different. Every network has different demands and it's almost impossible to test all iterations. So, discussion internally, what is it worth if we test a scenario? We know that it works with provider A but it doesn't say anything about provider B.
We also moved it, it used to live on lapse.ripe.net. We moved it to IPv6 Act Now. And we did some, together with the web team at RIPE NCC made some improvements on the user interface, you can now actually filter results and compare results, we hope it makes it slightly easier, for instance, one of the things we'll show you in a minute is that we added something about regional availability. So now the big question, where does it live?
Well, there you go. IPv6actnow.org/CPE should take you to that website and ?? there we have it.
There is a brief introduction of what it does, how it works. On the top you see four tabs right now. It's organised per vendor. Cisco, dealing, try tech and technical were the ones that responded earlier enough to be included in this presentation. I need to mention that we have got results in from NEC and from AVM just basically this week, we are working on getting them online, those will probably be added next week. Our work load is pretty much overload with this meeting so somewhere next week and we'll probably tweet about it and post another message to the mailing list.
There is also another note we did receive a response from the people from go go 6, they built a device that sits on top of existing CPE. We tried to fit it into the matrix but there are too many functions that depend on which CPE you plug it into so we decided to give them a separate space as is mentioned here in the bottom. So they are not included in the CPE matrix as such. Because it too much depends on the host where you plug the device into. So...
What do you have if you go to a random vendor? And here we have the Cisco one. You will see that it mentions a lot. The big thing is show matrix and filter options. Once you have clicked that you will see that there are a couple of extra tick boxes. What I particularly find useful, let's say you live in North America, you can just say I want all the devices that are in North America, and you would filter /compare and it should only list the ones that are in North America. You can also, lets say you are not interested in VDSL yet, you can tick the box, and again filter and the results should be gone. It's a bit unclear, but as you may have noticed the VDSL line is now gone. You also can compare, so let's say you want to have this D link version compared to a Cisco model, I can tick both boxes and the moment I hit compare, I get them both listed side by side. It's an a very basic interface. It's only the start. We are really hoping for your suggestions on improvements, if you say like can you add this, can you add that. As we move down you see that mostly access technologies, VDSL, ADSL, DOCSIS, if anybody is building DOCSIS mode elements, we haven't found anybody yet. It talks about LAN capabilities there, what's here. You might notice that there isn't anything mentioned about transitions techniques. And it's almost the same as with testing. There are so many technologies out there and everybody seemed to aim for something differently, everybody is inventing its own wheel to a certain extent.
To include a model is impossible, we really want it to be lightweight. It's easy, it's a bit of a handle to start looking somewhere. We couldn't decide on what would be the dominant technology which of the transitions technologieses should we list, would it be DS?Lite, would it be maps, would it be 6to4, so the base result right now was we leave them out. They might get added but it depends a bit on your user feedback.
So this is it. Have a look at it. I already see people waving to me that I should leave the stage now. Together with this on Lapse, I have published a bit of an article on what we have done so far, why it's there, why certain things are left out or not. So, feel free to come and look at the Lapse articles, find me or my colleagues, please tell us what we have missed. If you are a vendor and you are building IPv6 capable CPEs, please drop us a note.
Here is the survey. If you are building CPE, please contact us, IPv6 act now at RIPE dot yet. We will send you a sheet that you can fill in after which we can add you to this matrix. So, there is still a plan to keep this updated and add information as we go. And that's it. Unless you have any questions. And of course Lorenzo is walking to the microphone now.
AUDIENCE SPEAKER: Lorenzo: Feature request: Consider adding two fields: Past interpretability test. You would link to a page where the interability test is stored.
MARCO HOGEWONING: We'll think about it. If you know an authoritative source about interpretability tests, pick one, yeah, that's the point. Pick one. And then we have a discussion whether they are right or wrong, okay.
AUDIENCE SPEAKER: Mark Townsley again. Comment about the transition stuff. I would highly suggest focusing only on transition technologies that deliver IPv6 and deliver it from a service provider, that IPO, EPP OE are kind of ways of delivering IPv6, 6 RD is a way to deliver IPv6, could have a way to deliver IPv6. Map, DS?Lite, those things they are ways to deliver IPv4, keep them out of of your list. My suggestion.
MARCO HOGEWONING: Point taken, thank you. Anything else?
AUDIENCE SPEAKER: Sorry for repeating me, but ??
CHAIR: Can you state your name again.
AUDIENCE SPEAKER: Tahar Schaa, again. But perhaps it's a good idea to include these alternative firm wears because there is a big community, especially in Germany, and they are independent from a certain hardware.
MARCO HOGEWONING: That's one of the discussions we had. We deliberately focused on stuff that's ready off?the?shelf and ready to go. This really aims at what do you do with end users like my dad who don't know how to flash his firmware.
AUDIENCE SPEAKER: But will your dad look for this website?
MARCO HOGEWONING: We will include a link to the website somewhere in the comments, I guess. Thank you.
CHAIR: It's time for the next presentation by Emile.
EMILE ABEN: My name is Emile Aben from the RIPE NCC. I am going to do a presentation about IPv6 ripeness and...
So, how many of you don't know IPv6 ripeness? How many don't know IPv6 ripeness and are using the CPE survey right now, so they are not paying attention?
Any ways, one slide on what IPv6 ripeness is. It's basically something we, a colleague of ours, Vesna, thought of like, what IPv6 stuff can we easily see in our LIRs, and we just having IPv6 space allocation, are you visible in routing, and two things that you can do in the RIPE db. What you get out of this is a listing on a web page, so, it's basically a carrot. And you can get a T?shirt for this and apparently that works really well if, from what I understood from our training department, is if you have a training where one half has four stars of the participants and the other half doesn't, then the next day the other half also has it, or pretty soon afterwards they will have it.
So, this works pretty well to get people, take the first steps in IPv6. So, but what it isn't measuring is actual IPv6 users at the edge, so I mean you can do all the stuff that, to get your four stars, and not really do IPv6. So, how do you message that in our LIRs, and because we don't like people cheating on this we actually want it to be heart to...
So, then one thing immediately obvious there is, there is so many different types of networks, how ?? and they all do different things in their implementing of v6. And so ?? but there is two broad categories that are quite easy to look at. Access on the one side, content on the other side. So, the current idea ?? and this is sort of a proposal of what we currently think of for this fifth star, and I hope to get some feedback and there is probably no time to do it here so in the end there is a nice RIPE Labs article that you can read. But, access and content are the two categories that we looked at for this and they can obviously be more categories added to this if people think this is a category of things and this is how to measure the IPv6 deployment at the edge.
We are very open to comments here.
So, access networks. People are already doing a great job of measuring this and Google has excellent measurements and we are actually cooperating with our friends from APNIC on this one where we have a Google flash ad experiment. We get a nice aggregated data feed from that. We do something very simple. We map the IP addresses, or we actually get a feed of the IP addresses on the boundaries of the delegated files that the RIRs produce. And we just count the number of how many v6 capable clients they measure in an LIR, in LIR address space versus non v6 capable. And of course if you look at this and you want it to be fair, you have to ask yourself, what's the bias of this? And it's wherever these APNIC Google flash ads are shown, so it's YouTube I guess. But it has a bias, Google is warping reality there a little bit by serving more ads from one country than another probably, but it still, it gives us order of magnitude.
So, I actually looked at two aggregates, one a monthly aggregate from the data that we get from Geoff and George. We see roughly 3,000 of our LIRs out of a total of 8 .5 K, roughly, so one third, and 12% we see any IPv6 eyeballs detected, any means if we saw one, we count them. And if we actually go over this, this mythical 1% limit we have for the IPv6 launch, if we look at that, then it's 10%. If we look at the half year aggregate, of course we're going to see more; roughly half, a little less than half. 16 percent with any IPv6 detected, 13 percent with more than 1 or more perspective detected. And so, my proposal for doing a fifth star on the access side is to be either in this monthly category or have yearly category, because for instance, if one of our big networks turns it up next month big, they will show up in the monthly aggregate, but they would still have this half year aggregate where they didn't have too much IPv6 going on that is working against them. So, we both want to see a lot of people which the half year has and the monthly aggregate shows us like people who are deploying right now.
So, what does this number actually mean? And I mean we have small LIRs, big LIRs, people address space, big address space, I wanted to make is clear what this actually S it looks a little bit when you through in a plane over the Netherlands, you see this nice farm land and some people have this yellow acres where they don't feed it with water and there is these nice green patches. There is one in France, there is one in Romania, there is one in the Netherlands and if you have visited this session before, you probably know who those networks are. So, colour is how, how much IPv6 we measured there from 0 to 10% and what is green on my screen, but black?ish there is 10% and over. And the size is sort of how many measurements we got from that network.
So, that's, for instance here is Saudi Arabia and here is Germany, these are the not same size of Internet users, populations, but it's just that you get more Google ads in Saudi Arabia than in Germany, I think. So it's to give you a rough indication of (Saudi Arabia) what big and small are doing, but there is still a lot of yellow, too much yellow for my taste. But there is ?? but the big green patches here show that it can be done in large networks which we have already heard.
So that's actually not news.
So on the contents side. There is this wonderful list Alexa 1 million and what we did for the content, we just looked at web for now. You map the host names to IP addresses and map these to LIR address space and spare v4 and the v6 space. The bias is we use the Alexa side and because some people give you different results in, depending on where you do your query from, different address space, it's also the location of the resolver so we did this from the NCC address space so we hope to get back as much RIPE delegated address space as possible.
So results for a single run on the Alexa, we see roughly half of the LIRs. 10% with any IPv6 contents. 9% with over 1% of domains in the Alexa 1 million and then I did a little bit of weighting, because I mean, you can weight Google, number 1, at the same ranking as the RIPE NCC, which is at number 5,000 or so, but Google obviously has more weight. It attracts more traffic. So, I decided to weigh this by one over the ranking in Alexa and that actually is a good fit to the Alexa data versus websites reach. I don't have a lot of time I guess so I won't go into this. If you are interested, this is reading material for the coffee break.
So, this is the IPv6 consent landscape. See a difference? So, the LIRs for Google and Facebook are actually in Ireland, so this is Ireland, yeah Ireland. As green as it really is the country. So, this looks different from the access networks. It's sort of the same methodology, but consent ?? I mean if you make a contest out of this, content is clearly winning.
So grand total combined stats F you just say you get your fifth star if you are in one category or in the other or both. We see a total of 6,000 LIRs out of 8k E, 8 .5 K. 14 percent with any sign of IPv6. 12 percent with this over 1% metric, so, 12% of the measured LIRs would qualify for the fifth star and which is 9% of the total number LIRs. There was this 3% difference is because we didn't not see all of our LIRs here.
Of course rough edges. I think ?? there is the article. So, reading material for the coffee break if you're bothered.
So a couple of questions there, is this 1% the right limit and should we raise this over time (you're) so right now it's 1% qualifies you but next year 2%, 4%. It's an open question.
If you're interested in this, read the article, talk with us (you're) comment on the article, and that's it.
CHAIR: We are slowly moving into the coffee break but I am sure we can handle a few questions.
AUDIENCE SPEAKER: Jan Zorz: Thank you for considering bringing the weighting into the system. I don't say that it will be more fair, but it will be less unfair. Thank you.
AUDIENCE SPEAKER: I'm not a friend of this weighting, because you always have Google and Facebook in front and we know that they are IPv6 enabled. I work with a company that has 4 million domains on IPv6, but nearly one none of these domains come into the Alexa list because we do it for residential homes and small companies, they are only active in Germany just regionally active, so, I think the sheer number of domains could be important as well, so I'm not a great friend of this weighting mythology. Just the weight the numbers you have in the countries.
EMILE ABEN: Maybe to clarify for a big hosters ?? that's one of the concerns, but what you actually do is, we weigh inside of your ?? I mean you have probably 100, or thousands hosts in the Alexa 1 million and we just weigh these. And off line I can show you the numbers what we got for Strada if you are interested.
AUDIENCE SPEAKER: Yes, I am very interested. I'll approach you.
AUDIENCE SPEAKER: I will each from Ben im. So, why are you considering changing this limit?
EMILE ABEN: Because everybody should really deploy IPv6, and I mean, this year is 1% is next year's 2%. I mean, why not?
AUDIENCE SPEAKER: Okay. I'll answer that for you because then cannot compare the levels between years. So I don't think this is a good idea.
EMILE ABEN: Okay.
CHAIR: Thank you well I have got one question that I'm always asked. What about PI, what about those people that are not a member? It's slightly off topic I know but that's what a lot of people ask me while running around.
EMILE ABEN: We can measure separately if people are interested in that.
CHAIR: It might be interesting, but I'm not ?? maybe I'm the only one.
EMILE ABEN: Okay.
CHAIR: Any further questions? Then, well thank you. That article is on the labs. We'll ask for your comments.
(Applause)
CHAIR: Which means that we are at the end of our session, our first session. Next up after the coffee break is the NCC Services Working Group, and this IPv6 will continue tomorrow at nine o'clock. Please be there. We will. And we'll be in the room next door tomorrow morning in case you are still suffering and looking for us. Thank you.
(Applause)
