These are unedited transcripts and may contain errors.
IPv6 Working Group
Thursday, 16 May, 2013, at 9a.m.:
MARCO HOGEWONING: Hello, then. Yes. Hello, it's me again, and this is the IPv6 Working Group, part 2. Sorry for the early start this morning, 9 o'clock, and as you notice, it's a bit chilly but I am sure as the room fills up, that will fix itself.
So what are we going to do today? Briefly, we have got two short talks, both talking about measurements, IPv6 measurements, one of them was /SRAEU badge, RIPE cooperation initiative, the other other was Vesna follow up on fifth star followed up on Amsterdam session last year at RIPE 65. Then we are going to take most of the day or most ?? mot the day, but most of the remaining part of the session although we can probably talk about it all day, to talk about IPv6 measurements, so panelists here are George, Andrew, Steve, Heidi and last minute addition, he is not yet on the slides because I realised later on he was making his way to Dublin, Martin Levy will join us on the panel and talk about any concept of IPv6 measurements and all the rest.
So with that I hope you enjoy. Same as always, the session is broadcast sod if you do have a question, please use the microphone and for the sake of the scribes and the minutes and everybody else who is listening in, please state your name and affiliation if you do so.
And thank you Vaibhav for submitting your talk to the RACI project so go ahead.
VAIBHAV BAJPAI: Good morning, everyone. And I am a first year student at university in Bremen and today I am going to talk about measuring the effectiveness of happy eyeballs. This is part of my PhD work. This is a preliminary result from preliminary studies so please take it with a grain of salt.
So, it all starts with get address info, if you are the dual stack host and you resolve host names and get address info, you will always get end point in a particular order which is dictated by RFC 6724 and the order is meant to allow you to move towards an IPv6 upgrade path so essentially you will get end points which are v6, a list of end points and then a list of end points which are native v4 and some which allow you to go through these transitioning routes and technologies such as Teredo, you know.
So, what is the issue? The issue is, if I get the list of end points in this order and if the dual stack host has broken IPv6 connectivity, any application on top of it. CP will go through these end points in a sequential order, and the amount of fall back is in the order of seconds, so you have multiple end points in the v6 route it can take up to a minute to fall back to v4.
So, the IETF part about this problem, they identified this roadblock and came up with RFC 6555, so and the idea is very simple: The idea is, let's use the list of end points from get address info and the first end point from the first address family is let's try and initiating a TCP end point, usually it is v6 so you start at you give it 300 milliseconds to succeed. If the connection succeeds on 300 milliseconds you are good to go, you use v6 F it doesn't happen then you switch over to a different address family so you skip over all the other points of v6 so you try v4 then and then the race becomes fair and then who so ever wins will be used for the ongoing TCP connection.
So, the question that we want to ask and answer ourselves is: Definitely happy eyeballs is improving the experience from the previous slide that I showed before, but is 300 milliseconds a good timer value? So if you are dual stack and if you have v6 connectivity which is compatible to v4 is happy eyeballs ?? is happy eyeballs giving you a good user experience.
So, in order to answer that question, we define metric and corresponding implementation called happy, it's a PCP probing tool. What it does, you give it a service name and a port, and then it will get address info to resolve all the end points. What I would dictated order is and it will try to make a TCP connection to each end point and measure how much time it took. So this is thousand looks if you run happy, so this ?? these are the last value in the CSV is the time and micro seconds that it takes to initiate over each end point. This can be, this creates floods so you have service name which has ?? which is long if you have and you run happy on this this can create, between each service name we give the time out value of 25 milliseconds so that this doesn't happen.
So far, so good. So the next question was: What list of service names should we use for this measurement. So we first looked at Hurricane Electric, so they maintain a list of top dual stack service names. They use the one million service names list from Alexa, which is owned by Amazon, try to further out the top 100 dual stack service names and the issue is some of the service names only give you v6 end point when you append www to them, so if you go to Wikipedia and don't put that in you won't get v6 end point. And the issue is Hurricane Electric does not take care of this so you won't see some of the services in the top 100 dual stack list so Wikipedia is not there which is very surprising. They don't follow C name and don't see v6 end points if this info is giving you a C name back. What we do is take the input from Amazon, the one million service names list and create our own script which takes care of these two issues.
So this is the top ?? top service names list and from where do you run this measurement? So, we have some flavours of v6 and v4 connects, so native v4 and v6, native v6 means connecting to the ?? some transitioning technologies like Teredo. We measure the data captured from happy dual for a month and let's see what we got. The first question we wanted to answer how does v6 compare to v4 in terms of performance. These are the mean and standard divisions you see from, two different measurement points, connected to DFN by the way so, it does not completely correctly residential gateway so as to say.
What you see is in the middle, most of these things that you see are actually Google clusters so they are actually not different service names but similar service names but if you look at other service names which are there, most of the time the means are higher over v6 that v4 and the variations are higher as well.
So the second question: We know that v6 has higher mean and higher variation, to what extent is v6 preferred if you are dual stack and this is the preference level. So this is in terms of percentages, this is the first one is measurement point connected to DFN and you also also almost 99.9% of the time v6 is preferred and only one for v4. In case of the Teredo 100% of the time v4 will be preferred. If ?? so Teredo is essentially only useful to going to an end point which is only v6 only so if you have a serve which is only v6 then use Teredo, otherwise don't use it.
How slow is happy eyeball win tore that of a loser. We have seen from previous slides that v6 has higher mean and variations but how slow is it in practical scenarios. So this is the slowness. So, these are all the happy eyeball winners so red is v6, blue is v4, so what you see is, whenever v6 wins it is always slower than v4. And whenever v4 wins it will actually twice as fast as v6. It is not showing you how many times v4 is winning so it could be only that ?? only one% of the time that v4 is winning which you are seeing on the negative, but it shows you whenever v4 wins it is faster, whenever v6 wins it is slower. And one of these should get a prize where v6 is winning so I am not sure which these services are but we can look into it later.
And the last question: What are the repercussions of reducing this IPv6 advantage which is dictated in this, what happens if you reduce to 10 milliseconds? So this is what you see. So you still see that v6 is actually getting 99% preference over most of the Google services and most of the other services which provide you good dual stack end points. So in only some of the cases like some of the Indian websites which give you v6 end point but not v6 connectivity, only in those cases v4 is being preferred.
This tends to show you that most of the cases by the ?? by reducing ?? so this was, this time it was my mistake so it counts, right? So, you see if you can ?? if you move from 300 to 10 milliseconds you see you are able to reduce, you were able to out most of the out liars that you see in the previous slide. Had some out liars which was really slowed, if you reduce it to 10 milliseconds you reduce those but still prefer v6 most of the time.
Higher connection times and variations over v6 if you are dual stack end point going to these top 100 service names. If you are Teredo v6 you will never use to go to any of these services. 300 milliseconds only leave one?percent chance for v4 to succeed. And a happy eyeball winner is really a v6 happy eyeball winner is really faster than v4 route and a ten millisecond advantage helps you remove the outliers. And this is my personal request. We are currently running it from a really small standpoint; we have some agents in Amsterdam. I see there are many operators and big leaders out here; if you have native dual stack connectivity and like to participate in this experiment, please, please send me your shipment address at the this e?mail address and I will ship you some Sam knows probe so it will be on first?come/first?served basis but you can participate in this experimentation. Thank you.
MARCO HOGEWONING: Thank you.
(Applause)
SPEAKER: Lorenzo is not here so I have to ask on his behalf. I would like to comment on the point that eyeball winner is in most cases slower. It's actually a kind of action item for most of ISPs because unfortunately for v6 experience are not in sync currently, yes, so I am personally trying to get most of ?? dual stack but unfortunately it's still the case when you see like 10 PP peering sessions and only half of them dual stack with the same ISP. I know it's gradual and nobody wants to do it, we all have more interesting project, but I still ?? we need to get it done. Thank you.
VAIBHAV BAJPAI: A comment I would like to add, we were doing this measurement for three months and in the first month we saw Google services had higher means and standard divisions but in the last month they have really gone down so like you guys did something internally, yes.
MARCO HOGEWONING: Which were those three months, any relation to IPv6?
VAIBHAV BAJPAI: Last three months starting from February to April.
Jen: One more comment, what I observed from practice sometimes you might see some v6 issues because of let's say vendors bug in transport network T might be because of quality of service for some vendors for v6, you could see v6 is behaving differently for v4.
AUDIENCE SPEAKER: Just a quick question: What operating system you are, from where you are measuring on ??
VAIBHAV BAJPAI: I didn't ?? I should have put that in the slide itself so. Some of the measurement agents are running only W R T so it's a Sam knows probe and the mean and standard division that I showed, it is running from list and server in University of ?? machine, and the ? box running Linux.
AUDIENCE SPEAKER: Any Windows tested?
VAIBHAV BAJPAI: No.
AUDIENCE SPEAKER: Is it possible to get the source code of the happy tool and nought to Windows, I would like to have some Windows measurements.
VAIBHAV BAJPAI: That would be nice.
AUDIENCE SPEAKER: I will send you an e?mail.
AUDIENCE SPEAKER: Martin Levy, Hurricane Electric, page 5 of your presentation I have owned a ticket to fix the C name problem for you. It's a good point. My real follow?up is to the, actually the first question here: In looking of the measurements of one of your stuff off /TK?PB you have a radically different routing for v4 and v6, there are different peering partners and different propagation of routes, and that is not uncommon, in fact actually it's quite common so I would turn around and say if you can find a particular measuring point where you can in some way guarantee the, at least the begin of the route propagation maybe through 2 ASs then I would go back and look at the measurements on this and this is separate from is there a tunnel involved or something on v6 causing a difference but that first stage which addresses the first question, would really be something it would be worth searching out and then redoing these results on, because there is quite a definitive difference.
VAIBHAV BAJPAI: There is a very good point and I did not mention it in the slides, right now we are /RAOEUG to do, in addition to doing happy tests also alongside both over v4 and v6 we get the AS path information to see how defin /TKEU fintive v4 and v6 route, some ? in our measurement as well.
Andrew: First of all thank you very much for this presentation. It was very nice to hear the reassuring news that it actually works. And one question/suggestion: I think running this kind of programme the RIPE probes would give fantastic data. Have you talked about that?
VAIBHAV BAJPAI: Thank you so much for this, the happy tool is single file with 800 lines of code so if anybody who is actually writing the source code for RIPE Atlas and would like to review the source code I would be very happy to send it over and it would be nice if we can understand from RIPE Atlas measurements.
AUDIENCE SPEAKER: We have heard you.
MARCO HOGEWONING: Actually, Andrew stole my question because I was about to ask the same question. Thank you.
(Applause)
That brings me to the next speaker, Vesna, do you want to grab the stage and mike. So Vesna is here presenting the work, basically the who will ?? the the RIPEness 5th star, another way to get a free T?shirt.
VESNA MANOJLOVIC: We humans are attracted to the stars for their beauty, which leaves us breathless, and we use the stars for navigation to help us find direction in this world. Also, we consider the stars to give us a sense of perspective because compared to them, our joys and sorrows relatively insignificant. So this is why I came up with the idea to award the stars as the rating for the organisations who are deploying IPv6. And that is called IPv6 RIPEness.
So, my name is Vesna, I am community builder and this is the story about the fifth star, but just like all the good stories, it starts with once upon a time I was a trainer at the RIPE NCC and I wanted to be prepared for the IPv6 courses that we were giving and I wanted to know these people, these LIRs that are coming to the courses how far are they with their IPv6 deployment that we can adjust the course to their level of experience.
So, we wanted to answer some questions like do they have IPv6 allocation already? Did they register their Route?6 object in the routing registry? Did they register domain objects for Reverse?DNS and finally did they announce their address space? And can we see it in RIS our routing information service. So all these four criteria would give them a star each and if they have four stars then we would tell them, congratulations, you have four stars, and we would bring them a T?shirt. And it's amazing how much incentive it is to like compete for the free T?shirt and so to quote Olaf Kolkman, how does this actually help deployment of IPv6? Well, it's very simple and we made it easier by actually teaching them during these courses how to do it and we wrote articles on RIPE Labs like how to reach the stars and they could try it out, and they could try out the T?shirt and and if it's not good enough they can ship it back and replace it for a different size, and how ?? how observability? It actually put them on a public list so their organisation was listed on the IPv6 RIPEness dot right .net as having four stars, so we have this listing per country and, also, if they are wearing a T?shirt they could show off in the conferences so we saw how they were to have this T?shirt, and also, it's like speaking to this competitiveness in people and they always wanted to see oh, how is my country comparing to the neighbouring countries and they wanted to see is their competitor also on this list of organisations with four stars. So, this was actually quite an interesting tool for promoting IPv6 and moving them towards deployment. However, it was not a measurement, so we have been hearing from lot of people that they want the measure of the real deployment, all these four stars are just a prerequisite to actually having v6 working in your network. So, we moved towards the fifth star, so already at the previous RIPE meeting Emile presented how is he planning to implement this and now he actually did it, so thanks, Emile, he is following remotely, so if there will be some difficult questions later then he can answer them.
So he wanted to figure out how much IPv6 is in actual usage, and so he also wanted to find some fair criteria so that people couldn't fake it so easily. So, with the metric that he presented last year, he thought, OK, let's see if 1% of their clients is doing IPv6, then let's say that they are IPv6 ready but this year we moved to 2%. So I will come back to that later. He also thought it would be more fair to look at different criteria for different organisations so for the content providers and access providers. So we are doing this periodically once a month and publishing a separate list on the URL here so the five star LIRs are listed, together with four stars on another page. So you can still like show off and say, well yeah, I am almost ready, so you can say well yeah, I have the fifth star, too.
So, in Ireland, there are these five Irish organisations that actually have all five stars. And on the web page, you will see a lot of other companies that also offer services in Ireland, but I just wanted to stress these five. So, I will be probably coming back to this slide to illustrate like what do these mean. So the content providers, the access providers and the different criteria.
So, for the content providers we look into how many of the websites are on IPv6. So we only look into the Alexa one million, resolve that to their IP addresses, find out from which LIR are those addresses coming from and compare the v6 websites with the v4 websites. And we also use some other thing which is weighting, which is like divided by the rank, actually, so to give more importance to the most visited websites rather than some less visited websites.
So this is kind of simple. For the access networks, we are cooperating with AP?nix, who is using their flash ad experiments and they have been explaining how does that work for a long time so I am sure all of you are aware of that but we actually try to figure out who has seen these advertisements. We collect or AP?nix collects this information and we then map again those addresses to the LIRs, compare again v4 and v6 and then consider all the users of specific LIR over the last six months and over the last month.
So, this is the measurement, and now for the really detailed minded people, yes, there is some limitations to this so currently we only do it once a month. It's sometimes tricky to figure out to which LIR these addresses, these IP addresses of these end users actually belong to, especially if an LIR has multiple organisations and only some of them have IPv6 allocation and others IPv4. For the content measurements, yes, we only look at the Alexa list, I heard there is a possibility to look at some other listing so maybe we are going to consider that and we look from our point of view.
For the access measurements, well, it's a bit of luck, so also, so if you are a small LIR, then maybe we are not going to catch your customers when they are looking at those ads or maybe we are just going to catch one of your IP addresses from knock and actually you don't have any end users running ?? using IPv6 but you got lucky and you got on to our list. And that luck can change actually unless you bring more end users to the, to IPv6.
We were also considering, well we can actually try to figure out how many of your end users go to the www. ripe.net over v6 but that is also biased so this is kind of ?? a balance that you are trying to strike.
So how to get a fifth star? Well just do all the things that I already described. And go on with IPv6 deployment.
So these are the questions to you, I hope we will have five minutes to actually go through some of these. Do you agree at that we should be raising the threshold every year and make it more difficult for you to have the fifth star?
If you did not make it, if your website is not that popular, do you want to somehow let us know that we should measure against your website anyway, how would you let us know that?
If you want to see this fairness more publically we could also show how many of samples have we seen in the mouse over or somewhere. And yes, there will be a T?shirt but only at the next RIPE meeting.
So for now, stick to your IPv6 act now T?shirt and make sure that until the next RIPE meeting you actually get a fifth star so you can gate new one.
Give us feedback on the RIPE Labs, there is an article, talk to us on the mailing list or tweet to me and any questions.
MARCO HOGEWONING: If you zip one back. There are the big questions, now the big thing is, are there answers.
AUDIENCE SPEAKER: When you visited the v6 website, do you also check if the content is similar to the one of the v4? Because we have seen a lot of occasions where you end up with parking page on the v6 site.
VESNA MANOJLOVIC: Yeah, well that is an interesting idea for, I am going to plug it Atlas now, for http fetch measurements, we do actually do that. I don't think we are doing it right now but I am sure Emile is listening and will be able to give a more precise answer or at least consider it as an idea. Thank you.
AUDIENCE SPEAKER: One last question. Will you also check for MX records?
VESNA MANOJLOVIC: No, not yet, that is also a good idea.
AUDIENCE SPEAKER: Just a kind of small request. Could you put the presentation, because my colleagues would be interested in it, in a PDF format on the RIPE, it's in keynote.
MARCO HOGEWONING: That is logistics, it was late, people are working on it as we speak probably so it should pop up.
AUDIENCE SPEAKER: Just a follow?up on the question, so we were also curious whether the content over v4 and v6 is the same so ?? the similarity has of getting the from v4 end point and v6 and similarity show you some of the times the hashes are so low that they are as low as.2 so the content is so different if you want to incorporate into RIPE Atlas we will be happen' to provide the tool.
VESNA MANOJLOVIC: Question back to the audience: Do you suggest that if the content is not the same so it's just a part URL, those people should be taken out and not have a fifth star? So yes, I see a lot of nodding, OK.
NIALL O'REILLY: UCD. A suggestion for RIPE 67: Could we have a graph, please, showing how the propress is for the v6 and also, how the ?? how many T?shirts have been issued, how many have been returned and we can make ?? we can make correlations.
MARCO HOGEWONING: Watch it Niall because I am also going to do a distribution graph of the T?shirt size.
VESNA MANOJLOVIC: Anonymised.
MARCO HOGEWONING: Thank you all. Just to show number of hands, as Vesna said we have been discussing this internally; how many people say like, you know, slowly raise the bar because it could mean at some point you will lose your fifth star again. A quick show of hands. Who says raise it? Who says stick with the plan? That is your answer then. Raise it quickly then.
Daniel: Anyway, all the graphs but the T?shirt related ones are actually on the NCC website so how the distribution of stars per country and so on you can actually find. They are already there. Well, the T?shirt ones, we will see...
MARCO HOGEWONING: Thank you. Thank you, Vesna.
(Applause)
So, as we are talking about the fifth star, that makes us a nice lead in to the rest of our sessions and to our measurements, so if I can get our panelists up here. I can already introduce them here, so it's Steve Nash from Arbor Networks and Andrew Yourtchenko from Cisco, George Michaelson here from APNIC, Martin Levy will join the ?? as always Hurricane Electric, you do something about IPv6 and Martin shows up. And also, from a consumer perspective, if I may say so, very happy that Heidi the FICORA, the Finnish regulator could join us. It lists me as moderator but I do want to say a big thank you to Meredith and Channa from Google, who helped preparing this, this was originally set up as a measurements panel running together with Google, well theoretically it still is as they did all the communication, but some miscommunication meant Meredith had to fly back to the UK this morning. I hope she watches the website from her boarding area or something.
So, format, what we are going to do: A quick run down through all the presenters with ? I'll ask them to briefly give a short overview of who they are and actually measurements their gathering and then we will open the floor and we have got some questions and discussions to explore, what is being measured and why it's being measured and what else could be measured. So, if I can ask George to step up and open the ??
GEORGE MICHAELSON: Geoff sends his apologies, he really wanted to be here to do this but unfortunately couldn't make the meeting so you have got the under study, I gore instead of the made scientist.
So, we were quite interested in what is the good question, what do we actually want to ask about the transition to 6. And when you put it on the table it turns out there are a lot of things that we could ask about the 6 transition. There are traffic connection questions, things that go to ISPs and exchange points and people providing the technology and the infrastructure, there are DNS questions, that is about a different body of people in the industry sector, they don't necessarily play with routers but they are really important for making things visible. That is the end device questions about volume and scale and questions about who consume the information so the whole thing, what do we measure, who are we /PHAOURG for, that was actually quite an interesting question for us. And when we talked about it, we kind of got to this position that they don't actually get to the big question, they kind of within certificate, of the problem they are targeted and they are specific to people's knowledge and what they bring to the people but they wanted something that got to the all encompassing the view, the whole game, so when we did that we kind of thought the whole point of this is to actually get bits to fly, it's not about the bits flying in transit, it's about the end points, the people with the content that are the syncs and the source of the clients trying to connect there, do they have a complete functioning v6 story.
So, that led us to a sense that what we wanted to measure is how many people can actually get full v6 delivery in the system to content and back again.
OK. So we are now talking volume problem, how do you get to the millions? Well, you can either be someone like Google who has got a core role in the whole of the story and you are going to see things in flight and in transit and a great place to do a measurement but that kind of business intelligence is really valuable and the thing about that valuable business intelligence it tends to stay with the people who has got it. The other approach we had: How can we get to get this data about a lot of people? And we came to this place of advertising. If you look at this, that is typical newspaper page. I have spread out the view of the screen. And in fact, these things, elements op the screen, they are ads and flash based ads, even that background panel that is not part of the core story is essentially an ad. This is bottom piece of a video stream, that is an ad, has been embedded inside the YouTube video stream. They are everywhere. And most of these adverts have been implemented using Adobe flash, it's not just an animated jiff there are moving, there are active elements here that change when you interact with them because your mouse moves and this has been done using flash and action script and the great thing about action script it's a fully generalised mechanism that fetches objects and to invoke DNS functions.
So we have crafted flash ads which do measurement transactions in the back and we are able to do a whole series of tests, and these get down to some of the nitty?gritty about the different aspects of v6. We can measure dual stack capability in preference, get an RTT base measure, we can do literals so even bypass things like happy eyeballs and understand if the capability is there and then we do a result fetch which is just a way to get the clients view of what went on and we have been able to do this at three points. And I would like to acknowledge it. Google have been extremely generous in helping to us use the advertising channel. But also ISC, who provided a host in America. And you, the RIPE community, through the RIPE NCC have helped us with a serve located in Europe so we are collaborating in this collection exercise and we really appreciate that help. Cisco have provided some assistance and I some have provided this measurement.
Summaries of browser capabilities for instance, you can get a break down of the differential behaviour that you might get from a Windows or Mcplatform. And it's a kind of a bit like the v6 RIPEness things, people really want to know how they are doing compared to somebody else, am I better than the guy next door. That is kind of where are and we have been thinking that putting up visual presentations like this help to give a sense of competitive behaviour in where people are placed. And we have been doing per provider and per country reports and some statistics that amalgamate other sources of information: This is a ranking based on v6 ratio and you can see some of the players who are doing quite high levels of penetration, there is a high understanding of capability but if you resort this data by population and the inferred on?line population, you get a subtly different view of the numbers of v6 /KPAEUPability. I would stress by the way that the number of people who are already using v6 is really very large. In a global con /TERBGS yeah, it's a low percentage in absolute terms that is lot of people.
So we also can provide a /PAOEUDer view, if you are interested in your ASN and where it places in rankings, we have got data about that. And these time series actually get to some of the sense of what I think we might want to be talking about. These graphs, for instance, show global and European trends and they are very encouraging in the sense they are a class I think up and to the right measure so that is aspect that says things are getting better. But if you start to look at the breakdowns on a per economy level, you start to see that the dynamics are actually very, very different depending on the economy you are in. Romania, for instance, this is a representation of a large single that has achieved a certain level of saturation in the marketplace and then essentially there is no more visible growth if v6 uptake. If you look at France, this is another one that is dominated by single provider that has done a 6 RD deployment so the traction is a slightly different place, in Italy and Ireland the rate of uptake is very, very different and we think graphing and understanding and providing feedback on this is going to form part of the decision?making about IPv6. And that was kind of the big picture question for us that we were interested in: How can we inform the discussion, who can we get to and talk to about the nature of the deployment?
That is my introduction.
MARCO HOGEWONING: Next up Steve Nash, Arbor Networks, taking a slightly different view of what is happening with IPv6.
STEVE NASH: Good morning. So, Arbor Networks primary business is creating software and systems for you guys as operators to deploy, to deliver denial of service protection services. That involves collecting a lot of data from you, in two forms: One directly data from the systems that are deployed out there; and number two is an annual survey that we have been running for eight years now that many of you in this room have responded to, thank you very much, the worldwide infrastructure security report. That report in its most recent edition produced this pie chart of people's statement of where they were in v6 employments so a quarter of you say you are done; half of you say you are going to be done by the end of the year; and a about a quarter, it's over the horizon.
Another interesting perspective was: What are your major concerns about v6? And the interesting thing about this is, number one, is traffic floods in DDoS, that is why Arbor exists, so that is sort of encouraging but actually what is most important about this chart is that v6 chart is pretty much the same as the v4 chart. And that is important because last year that wasn't true. Last year, the number one v6 concern was IPv4 v6 feature parity. That has dropped to number three this year. So our impression from the results of this is that you, as operators, now view v6 as more like a normal service, more like the v6 service, your concerns are similar for both of them, which speaks to a level of maturity of the service.
What do you think is going to happen next? Well, it's nearly half of you think that IPv6 is going to maybe grow by 20 percent over the next year. And about a quarter say it's going to be way more than 100% and, a good chunk say I haven't a clue. So that is measuring is kind of important in trying to figure out to extrapolate. In fact, what we saw was, last year, v6 more than doubled. So only a quarter of people are actually predicting what is actually happening, so there is some problem with the prediction here. It is growing. Our observation, however, is that it is currently .2% of v4 traffic. And we are going to get to a bit more detail on that.
So, we see 45 terabits per second of IPv4 traffic around the globe. That is the sort of level we are monitoring at. From 265 operators globally and 80 of them are in the RIPE region. So, but from the RIPE region we see one gigabit per second of native v6 traffic. That is a fairly recent month average type of figure.
55 of the are reporting no native v6 at all. So, our guess is that actually what is happening, even the 25% who say they have rolled out v6, haven't turned on instrumentation. So there are a lot of people out there that have got v6 in their networks, net flows still running on v5 so it doesn't report any v6 data, that sort of issue. We will discuss that a little bit more further on, I think.
So that is the end for me. A lot of the data that we are talking about, I have talked about in those slides come from the WISR report and you can get it from the Arbor website.
MARCO HOGEWONING: Really want to leave some room for questions here.
ANDREW YOURTCHENKO: So I actually don't have any slides, I just have a little demo. And I want to show the website that we built that aggregates all the wonderful data sources that and exist and some of them that were not visible before.
So, that website is available on the Internet and I will just try to show a couple of interesting things. So first of all, how do we treat the ?? how do we measure the IPv6 deployment. So the information type has a fairly long presentation about how exactly things are measured. But we split the v6 deployment into several phases. So first it all starts with IPv6 prefixes, so you need to get the prefix allocated, you need to get it announced. Then, of course, to get from address to address you need to have transit, so we measure the ASs from the route you use, we measure which AS numbers have IPv6 routes, which number have IPv4 routes, which has number are more frequently in the AS spots. And by that, you can make some correlations and some conclusions about which ASs are transit for v6, which are transit for v4 and which ASs are v6 enabled.
Then finally you get the web content and this is the data that has been original work of the intern who was doing this website so that is a very talented young gentleman who made this website, and he created the formula which proximated the position in the Alexa ranking with the amount of page views. So, if the website is lit up, then the certain percentage of the page views is over v6.
And finally the users which we take data from, APNIC data and Google data, thank you very much.
So a couple of interesting observations that I wanted to share with you.
So first of all, for example, prefixes in Ireland. And so the back line is the allocated prefixes and we see that the around May 2012, there was a big jump in the allocated prefixes so probably that was v6 world launch that people reacted to. On the other hand, the number of announced prefixes didn't jump too much, so that shows, just getting the prefixes is not enough.
Another interesting thing is, eyeballs?wise. So, for example, in Germany, if you click on the user's data and if I scroll, well, you can't scroll on your screen, but you will see that IPv6 had very little eyeball network penetration until the autumn last year, and at that point, it started very, very steady growth. And as an exercise after today's Working Group, I am curious if you can find two countries in Europe where IPv6 eyeball deployment has doubled over the last two months. So and I think that is pretty much all I had with respect to that.
MARCO HOGEWONING: Last one with few slides is Martin, try to be brief and then we will hopefully leave sometime to discuss all this.
MARTIN LEVY: Hurricane Electric. This is a measurement of a v6 network. It's a real v4 network that interconnects with 44,000 other ASNs and normally if you saw this diagram in the v4 world, you would see one bubble for its ASN and its announcements and I think around 15 or 20 other networks that are part of the propagation before the routes finish, so to speak, that tier one space where there is absolute guarantee of global connectivity. But this network doesn't do that, and I have graded out the AS number for obvious reasons although it's not from this region by design, but there are 100s of these, so slowly within the website bgp.he.net, the we have tried to work out which programme atically how to build a listing so that we can compare v4 complete routing to that lack of routing that exists with inside the v6 world.
Now, Marco did introduce me on the panel oh it's a very 6 panel so therefore, I should join it, but we have been at this game for quite some time and hounding and hounding and hounding networks to turn up v6. It is amazing that we are still at this point dealing with this type of lack of global connectivity. Yes, there is a route there but it just can't be used. And in fact, one of the nice things I loved about Vesna's talk is that it actually sort of takes that testing of v6 two stages further than is there a route there.
I am going to be very quick and say there is still a lot of measurement at the BGP and peering world, which is truly where we focus on, where we need to go out and complete for 44,000 and counting ASNs that we need to get there and complete their routing and give some parity between the v4 and v6 space. Short and sweet. Thank you.
MARCO HOGEWONING: Everybody snug he will up to the microphones. Hide /TKAOERBGS you didn't have any slides but if you can quickly introduce who you are and why you got on page.
HEIDI KIVEKAS: From FICORA, Finnish communications regularly authority. I didn't make you any slides as you can see, but I was asked to tell what, because I come from the sort of user side of these measurements, we inside FICORA we don't do that much ourselves. Of course, we do some surveys every now and then. Last year we did a survey inside Finnish operators to get information on where we are today because the last one was in 2008, I think, but we mainly rely on other measurements, as has been seen today. We are very interested in those. We especially want to know what are the reasons why ISPs made the decision to do IPv6, where are they? We also want to know why some ISPs have decided not to do anything, at the moment at least. But at the same time, the measurements that are, how would I say, we would like to promote, are the measurements that help ISPs solve their problems. We don't operate networks ourselves, we would like the ISPs to do them and we would like to see any measurement that helps in finding problems and finding, resolvements to those. So I think that was in brief why I am here today.
MARCO HOGEWONING: Well, thank you. So, thank you all for being here and you actually touched upon things. And I am glad that Steve actually in his slide showed. When we first started this we had a bit of a run, what is measurement? And you can see that, for instance, yeah, in the terms of this panel, if you want to contribute, take it as broad as possible, that is what we try to do. Of course, there is the hard?core technical data as RIPE Atlas and all stuff, but there is also the soft sides of measurements as part of what Steve has shown, why do you do this and how do you do this. So to start off, and actually, I think George already mentioned somewhere in between the lines, it wasn't your presentation, but of course the big question now is: Who do you measure for, who are you actually targeting?
GEORGE MICHAELSON: So we had a very strong sense that we were trying to break out of a dialogue specifically with network providers. I don't want to imply that is not an important conversation; I actually think the Arbor information and the stuff that Martin is talking about is an inside the club conversation, absolutely has to happen. It's really, really important. But we thought that there was a level of strategic planning and decision?making that really isn't about technology; it's about long?term business investment, and it's about long?term national strategic directions and it gets to that what kind of a network do we want to make. You know, if your vendor comes to you and says we have got this amazing CGN and it's a really cool device and you have to buy it anyway so why don't you buy it now and then you don't have to do v6, there is a whole body of practice that can kind of walk down that path and we were interested in the idea that if we got to that question, what kind of a network do we want to have, do we want a v6 network that has got those end?to?end properties that we were going to need data about where the gap was, what is the problem and missing link and how many people out there could do v6 if we made the capital investment decision?
So our motivations in a way was, actually, we were targeting Heidi, we wanted to get data that ultimately wound upcoming back into the business decision in the industry and government planning decision about what kind of a network do we want to have. That was the one that we were aiming for.
MARCO HOGEWONING: Thank you. Martin, you are already sort of mentioning it, trying to convince the world to ??
MARTIN LEVY: George, you used that sort of insider wording. And I think it's true within inside the outsiders, but when you go out to talk to law makers and regulatory guys, you can actually explain that there is technically more v6 out there than they think. But that is from their point of view, that is from the really past even the general public but back into law makers or regulatory folks.
Unfortunately when you come back to us when we look at real numbers and the ability for real bids and your measurements which are near on absolute, we then realise all these flaws. We have a long way to go but it's interesting to look at it from a completely different point of view and explain to some people in some places around the world there is some pretty active v6 deployment that needs help, but is actually there. So the insider point was the first thing you talked about.
But it's inherent to what we measure, at the BGP level and what we are interested in, versus access, that we know we still have a long way to go. We know that this is preaching to the converted and that we have got to go out there and find more and more networks and get them to finish the work that they have', sometimes started but most of the time truly haven't started.
Somebody mentioned yesterday about the sort of measurement, sorry, no, it wasn't yesterday but was talking about what would it be like just to run pure v6. And I personally would love to see that, but as a practical person from these measurements know full well that there is a long way to go before we get to that point. But take that as the ultimate measure, putting your hand up, and saying I am running pure v6 and actually surviving, we have got a long way to go.
MARCO HOGEWONING: Thanks. Steve, anything to add like this like target audience or basic question of why do you start doing this?
STEVE NASH: The data really here is an off shoot from with a we do day?to?day on all sorts of other data so it's very much, it's gathered from you, the operators and fed back to you the operators and it gets used by the press and various other organisations as well. So the slightly worrying thing is that maybe the statistics that we are showing are perhaps slightly lower than some of these other guys are showing which says you, the operators, know less than what is going on in v6 than some of the people measuring the end points which is worth considering.
MARCO HOGEWONING: So that is ?? indeed you see a lot of different measurements and I think that is where Andrew, in this encompassing view, you basically measure it all.
ANDREW YOURTCHENKO: We mostly aggregate but we also do some additional measurements and I wanted ?? sometimes as we go around talking v6 we, it's important not to forget that well, in the end it's about the not just the protocol per se, it's about ensuring the continuity of the Internet as a structure, right, so the protocol itself, it's kind of more technology, but the measurements that we do all collectivity, that is something that can help make decision and understand. OK, so how can I move my network to ensure the continuity of the connectivity with our networks?
MARCO HOGEWONING: Yes. And Martin, you just sort of mentioned it, like IPv6 is less of a thing and, from a regulatory perspective, Heidi, how are you ?? are you actually looking like raw numbers, just take a look at the number of networks that do IPv6 and how many ?? or do you actually as Martin tipped on like also explore the quality of the network? Are you actually concerned about what Martin touched on this, like the connectivity side of things or the resilience in the end because connectivity is all about resilience.
HEIDI KIVEKAS: Yes, from my perspective there are two levels in this because I am an engineer myself and my main responsibility is to maintain technical quality inside Finnish networks. So I am interested in what is happening inside the networks as well. But you know, I talk a lot inside Finland with politicians and stuff like that and they are interested in when the end customers receive via v6 access lines and services, perhaps v6 only services and stuff like that. They are not that much interested inside networks per se. Does that answer your question?
MARCO HOGEWONING: Yes. So in that term, just ?? so we know why we measure and we know who we measure for, but is this actually enough?
GEORGE MICHAELSON: I think there is lass point we have to make, which is there are some gaps in what we are doing. There is actually a pretty big information gap out there and more work we need to do. We know, much we would like to it to be better wave poor understanding of capability in the mobile sector and we know the success store eaves the /PAOEUDers have thank have gone there and we don't have good coverage over emerging Internet economies, transitional states, sub is a /HARPB after can and they are important because they are the long?term future markets that need to understand future capability in /PWRO*ET. So I don't like to say the thing has got flaws but it does, we actually need better measures, we have got some gaps here and I do wonder about what are the questions we are not asking. I think we might be driving one way. I made a crack about big intelligence in Google, it's very unfair, if there has been any company, they have done an enormous amount to publicise v6 capability worldwide and have Yahoo and Comcast, I think the industry as a whole is doing a good job at sharing the information it's got. That was unfair jibe. The guys are doing OK.
MARCO HOGEWONING: What Vesna has shown, this RIPEness thing that started off, we are going to do a training course, let's see how far they are. That, of course, being done over the last five years where this big IPv4 run out was still some future event and the Internet kept running as it should. We are heading for a different world right now. IPv4 run out is a fact, should that change the way we measure or issue ?? change the measurements we do in terms of, yes, of course we look at progress on IPv6 but should we start exploring the state of IPv4 more in terms of netting performance there because that obviously, in the end, and that is where ?? there is a per forrance began between v4 and v6; should we explore and if we should, how can we explore that balance gap? Anybody? Any takers. Feel free to contribute. If one of the others ?? I know Steve is looking at packet flow so in terms of performance, would you be able to tell performance data, could you spot a NAT in your ??
STEVE NASH: Definitively, no. But I think you know, bear in mind all the panel you have got here are the people doing the measuring of what the audience is actually achieving. So for us to turn around and tell you what you should be doing is changing its ?? is perhaps the wrong way around. So, there is clearly, there are things that we know still need fixing, I hinted at the measurement aspect itself, I think people are not paying perhaps as much attention to gathering data. Is that because ?? I guess for the operators, so long as it's working, I mean if the phone is not ringing, it ain't broke so don't fix it.
MARTIN LEVY: So, that hits a nerve.
STEVE NASH: I noticed.
MARTIN LEVY: Good. But it hits a nerve where, annoyingly, you are right, and yet, ultimately, that is the problem. We have come across many operators, you mentioned that the Net flow five issue, that is about as simple and basic I think. There is a complete lack of instrumentation and differentiation between what is going on within inside their network, any part of their network, in the v4 space v6 space, they still believe it's just a few bits and the like and yet, we can turn around to pick sort of and I have to highly anonymous example, where there is, you know, 30, 40 gigs' worth of v6 traffic coming out of CBN's video being delivered to eyeballs, as networks are implementing 6 I'd or even native v6, true native v6 down to CPE and starting to ship millions of new CPE devices, definitely the refresh mindset, not touching old but hitting new, yet they don't have the measurement to realise that that traffic is moving in that direction. Go back to the business reasons, George mentioned the carrier great NAT side of it, well if you are pulling that much traffic and/or much more off of your CGN infrastructure, you are inherently are saving money but if you have no visibility into that, then you just can't tell the value that v6 is bringing to the table. Now, you can measure up to the one percent and above time graphs that Google has presented, which are brilliant from the source data point of view but when you get into some of these operators and realise that they haven't dealt with their own internal structure to see the value of v6 and the fact that it is in fact actually working, you have put millions of CPE devices out there, the traffic has changed, then you have a problem. So, when we see issues on the routing side, we actually then realise the operators have no visibility because, unfortunately, the percentage of v6 still is still very flow and it is in the noise, because of a happy eyeballs type environment, the end user doesn't actually know and doesn't complain. And that is either the brilliant answer to that or the mind?bogglingly annoying answer to this. And I don't know which one it is.
MARCO HOGEWONING: Any other panelist that wants to respond to Martin? Otherwise I would like ??
ANDREW YOURTCHENKO: I think I have to respond to Martin. And yesterday, in the presentation, I have heard very interesting sentence where talking about v6 enablement and enabling the applications for v6, there is quite a lot of boring bits that you need to do. And a lot of people, when they do v6, they do all the cool stuff, right, so assign v6 addresses and get v6 connectivity, fantastic, but and ?? and that works for a while. But as you said, the monitoring is not necessarily in place which is kind of a bit boring or sometimes it's hard, it's changing the systems and incorporating all of the necessary processes in place, that is the boring part and hard to do it. But that is something that needs to be done. But as someone who is, I would say, more than a decade of troubleshooting, experiencing and fixing networks, I think it's 2013 and maybe it's time to try to move on from having user as part of our troubleshooting tools and maybe to have better tools, because my car shows the light that I need to go and repair it long time before it blows up under me.
MARCO HOGEWONING: I am with that, because you are also leading like, OK, maybe we should stop using the user as your measurement tool and it was following up to Martin as you mentioned business intelligence, I would actually like to start throwing it into the room so feel free to line up at the mic row phones and contribute. But as a start there, when we started like who do you measure for and I have got Heidi up here who explained why she from regulatory perspective is, but I think the two things that got mentioned here, was A, you are providing the data in terms of NetFlow and Martin ?? Steve mentioned it's not everybody is there yet. At the same time, who here is looking at the data and why do you look at it and do you actually take a look at the stuff that is produced and either, for instance, take a look at Martin's stuff and fix your network, do you ?? anybody from the room that says like, ah, yeah? Silence. It's still early. Anybody have an opinion here on this?
MARTIN LEVY: You could measure the ?? could we measure the lack of questions as the v6 Working Group should be complete and finished?
Jen: First of all I'd like to say yeah it's very valid point that we need to, first of all, think about think data we need because sometimes we just look on the data we got used to, like can I get my trace router work, do I have enough ?? so on, but about peerings, for example, again, can I be sure if I shut down this particular router for upgrade, does it mean that I lost connectivity of some IPv6 networks? Because it's only point where I peer with them. I did some analysis based on what I am seeing and sometimes in some regions, not in the RIPE ?? not in the Europe unfortunately, it is very disappointing, we should be encouraging the situation and be very careful which links you can down for maintenance because it could badly affect v6 connectivity and it's something for the whole community, for operators to look at.
And I have one question, to Steve about the concern people have. So, the second on the top is misconfiguration. I wonder if, how it's different from v4; does it mean we need to educate?
STEVE NASH: No. It's number two for v4 as well.
Jen: It's actually good news. It is good news, yeah, because it means people is confident and can figure ??
GEORGE MICHAELSON: I would like to come in on that because I am historically the worst admin in the world. Every company has one, somebody that looks into system and network admin and then you really wish they hadn't done it. And in sixes like a nightmare because I can't remember seven numbers in a row so no one is starting a digit sequences with whole new syntax it's easy to misstroke it, the auto config stuff was working well enough could. So it kind of balanced out. And you go into it thinking 6 is much more complicated. It doesn't actually have to be true. A lot of HP printer ship right now doing stateless and Apple device discovery and you find them faster than your admin can put them in v4 by hand. There are effects like that that are really interesting. The misconfig thing, I could believe it's the same because it kind of equalises out.
ANDREW YOURTCHENKO: I wanted to add a little bit to that and continue, where we in the industry have been working with the cars where the car comes with the manual how to build your own accumulator before starting it, and I think v6 moves us a little bit further from that point, not where ideally we should be but I think it moves a little bit further. And George, you just said automatic configuration, it does work better in some cases than v4. And that is something where I think the biggest challenge in that is that we, as professionals, are so used to the fact that the systems don't work and we need to fix them by hand, that we don't trust them enough that they do work.
MARCO HOGEWONING: And fixing them by hand ??
GEORGE MICHAELSON: I also liked an aspect of what you said about do your own measures. Be surprised about how much 6 you might have. Go look at your own counters and your own numbers because you may well discover opportunities you didn't know existed there. It's worth doing. There has been talk about that con grewence between v4 and 6 and the idea 6 mismatched to the 4 reality and happy eyeballs can't be be happy. If we did a better understand between the 6 and 4 routing we could take ourselves to a really better place and that is a equality in measurement. You measure to find out where you are and use it to find out where you want to be. Hog had gone and well, yeah, go ahead.
MARTIN LEVY: I went through an exercise with a vendor about two years ago, leave the vendor's name out of this but sat with a product marketing team and the like where out of 12 chapters for the device, chapter 7 was IPv6. And I chastised them because why isn't every chapter, as as you introduce the different features, sitting there with the v4 example and v6 example, such that that v6 chapter does not need to exist? And that mindset is pervasive, unfortunately, throughout many things. We will bring up a link and a system, we will bring up v4, because that is what we do by default and this comes down to why, if you take a single router out you could suddenly lose your v6 connectivity. The example on that manual for a brand new device, was frightening that that might sent still existed inside a pretty savvy network company not sitting here on the stage.
But the second example I give is ?? goes back to the whole measurement thing, is that we have found CDNs that exist in many, many, many locations around the world, and we measure half a dozen of those locations that have no v6 traffic trickling into our network, whereas the others do. And we continue to go out and say, by the way, you are not creating any v6 traffic in city X or Y or Z, and we can't get traction on that. And then maybe three, four weeks later in this particular case, oh, yeah, v6 has been broke then that city for ages. Pull your hair out with stuff like that. Measurement pretty much, visibility is what we push back on that. It's an absolute requirement. But I am not going to use it as a, by the way their operations team should we should turn off this v6 stuff until we can measure it. It does work, it doesn't work in this half dozen cities, trust me, we can help you with this.
MARCO HOGEWONING: And I am going to wrap it up here because we are heading for the coffee break and I don't want to deprive you from morning coffee. This is a nice lead in and that is where we had this dead silence fall into the room, you mentioned like maybe the IPv6 Working Group is done, we are reaching for the requirement and that is delivery of those reports because a lot of stuff that has been shown, oh here is our website and you can look up your ASN and as you said, sometimes you have to go out activity pushing for it and it's the same as George led into, we do this to convince policy makers. But OK, apart from a few rare exceptions I don't see many in the room; maybe they are all watching the video stream. So as a little wrappup, I would go around to say, like, in the ?? in delivering the results, should we really go ?? become active and chase down those people, as Jen pointed out, like you are lacking peering; if we can tell you now that if that link breaks your IPv6 goes down, and should we actually go out and go out and chase them and say like, hey, guess what, instead of oh congratulations, you did the fifth star, phone them up and "hey, you are bottom rank"? How can we reach out to those people who are not in the room and those people who are not looking up the data and actually don't know what is going on.
GEORGE MICHAELSON: So I would say briefly is, if you are doing a round up wrap is that it's a better industry if you are competing by talking to each other rather than competing by chasing the bottom. So talk to your competitors about what you do and don't do and get to know your local regulator, because you know what, they are your friend, it's not all about telling you obligations, sometimes they can do incentives too, so talk to each other and to your regulator and give them data because it helps them do planning.
ANDREW YOURTCHENKO: With respect to that, I had one question, and it's again very easy to throw in ideas, but as someone who measures the various points on the Internet and various networks, the eyeballing for the short?term event networks, I almost see zero variation in v4 round trip times over the period of this duration this networks are up but Iy giant variations in v6, as Jen said that was probably somebody doing maintenance for a couple of hours there and I wonder if, if we have this large networks like RIPE probes, would that make sense to have some kind of ongoing background probing between the end points that do have v6, low low bandwidth, low?key, really just checking that v6 round trip between Brussels and Dublin doesn't double ??
MARCO HOGEWONING: If it doubles, should we go and find out and go and hand them down? Hey, we see a spike.
ANDREW YOURTCHENKO: Yeah, something where we can could graph significant deviations in round trip time. I know it's very easy to give ideas.
MARCO HOGEWONING: Well, just going to go down the line. Heidi, anything to add?
HEIDI KIVEKAS: No, George, you stole my reply to that because that is ?? one of the reasons why I am here because here, I hear from ISPs what is going on and what are the main issues and then I can go back home and tell those people that are not here and are not following forums like this.
STEVE NASH: Not much for me, we will just keep watching as things change.
MARTIN LEVY: From memory I can tell you what is in our ticket queue. We have sent out e?mails, dear AS number, whatever, we notice that your v6 routing is incomplete or has a problem. We recommend you do the following, which in some cases it's as simple as add transits to your existing transits. And we get responses, still to this day, ah the v6 guy, he is on vacation this week, he will be back on Monday. We get responses, such as: Oh, no, we are just doing testing on v6 so we don't need it to be complete. And think about that one for a second, that is the one where you realise they are about to test something, realise it doesn't work very well and put it back on the back burner. The last thing you want to do in the v6 world, you need even for one or two bits it needs to be right.
I could continue down the responses, but I don't want to continue this process of ?? network we would like to see you fix your v6 and here is some of those responses so we have still got work to do.
MARCO HOGEWONING: Sooner or later it's going to be their network, fix your IPv4. We are just on the coffee break so I will take the two questions from the room, Niall, stay standing. We are left with one last comment from Daniel.
DANIEL KARRENBERG: RIPE NCC. Just to the suggestion to do these kind of background measurements, at least a little bit of it has already been running for a couple of years, is where we in Atlas actually take from every probe that does IPv6 go to the route name service, so if someone wants to look at at data set like this and see what is in there, it's certainly there. And the second thing is that we are in the process of deploying RIPE Atlas anchors, there is a Beta, just going on and certainly the anchoring measurements will be in v6 so that will expand that data set. If there are suggestions as to do what particular kind of mesh to test, get ?? get some credits and just configure it, it's all there, it's easy and can be done.
MARCO HOGEWONING: So, well, going to wrap it up here then. Thanks for our panelists and I am sure we can continue this for the rest of the day which I hope we do during the coffee breaks and everything else. So thank you all for your contribution. I know some of you got called in late as a replacement for somebody who couldn't make it. Before you all run out of the room, we are still have somewhere on the bottom AOB. I know there was somebody ?? in the meantime while you walk up there, I have been asked by the Programme Committee to point you to the fact on Friday, there are elections for the Programme Committee. So please go to the RIPE meeting page and you will find more information and the candidates and vote. You need RIPE access account for that and please do, but that will help and we have got some volunteers.
AUDIENCE SPEAKER: Thank you very much. Wilhelm. I have a short issue about the RIPE 554 document. There have been errors in this document and we can't change it without getting a new document number. Having too many document numbers confuses our audience, so I would suggest that this community votes for ?? section somewhere on the RIPE NCC section where this document is published where we can post comments, errors, corrections of these errors and maybe a list of translations in other languages of this document because there are countries who like to have their own versions. I just wanted to know how does the community think about this? Should we ask RIPE NCC to do something like this.
DAVID KESSENS: I think it's a little too late to have a discussion about that right now but I can promise to bring to the Working Group chair collective that has a meal actually this afternoon or lunch. I will take it up.
MARCO HOGEWONING: Take it up on the mailing list.
AUDIENCE SPEAKER: So we have a place to discuss it. Thank you very much.
MARCO HOGEWONING: Thank you all for being here, for those who haven't yet queued up for the coffee and hope to see you again at RIPE 67 in Athens. We are looking for contributions to our next meeting's agenda, so if you have got a bright idea or want to do ?? discuss some things please contact us. Thank you.
