The next session is commencing at 4 p.m.

CHAIR: This is the IPv6 Working Group. If everybody can go and sit down as quick as possible, because we have a very full agenda and we would like to start and move on quickly.

I will quickly scan through the agenda, so people have an idea what's, what we are going to do today. Also to catch up with changes because there were still a few changes we made this morning, etc..

First of all, the administrative stuff. The good news is we can basically skip that all because we already have scribes and everything aligned, so that will just work out fine.

What's very important for people who want to comment or speak up about the issues in this Working Group, please go to a mike, state your name and then say whatever you have in your minds because we have a lot of remote participants and if you don't use the mike, they don't be able to know what's going on, who you are and they won't hear you.

First up on the agenda is something that we typically have all the way at the end, but since we have a very full agenda, at the end some people might miss we decided to move it upfront. The first thing -- I won't go through what actually will happen. We will just hear a little later.

After that we will get an update from the RIPE NCC regarding the IPv6 capable services there and also a little bit of outside of that, as I understand it correctly. Normally, this update is called a quick update. This time it's actually not called a quick update because I have been told they have a little bit more to report. So we shall see.

Then we get an update from Lorenzo on what is happening regarding IPv6 at Google, because we got a very nice presentation about all that last time and I am pretty sure people are interested in what's happened since then.

Then we have the useful topic about IPv6 measurements, traffic reports etc. We always allow people to basically stand out there and give us some idea what they see happening. It's not necessary to have PowerPoint but if there is something interesting that you'd like to share with us, then feel free to do so. We have already one speaker lined up, Martin Levy from Hurricane Electric.

Then we have the traditional routing table update from Gert Doering.

Then one topic that I really cannot predict yet how much time we will spend on is something we recently had a lot of discussion on the address policy mail list about the aggregation of /32s and whether that was a bad or good thing. I had my own opinion about that but we'll leave that to the discussion and see what other people think about that.

Finally we have some longer agenda topics. The first one is an overview from ISOC on IPv6 surf rated and also ISOC IPv6 related activities and finally, we have a talk about survey that that EU is planning and we got a story about that and also a request for input.

Let's start the first agenda topic; that is the questions reports from, stuff that's happening in the European region and we have our first speaker about the IPv6 peering BoF that is being organised.

SPEAKER: Hello, I am head of the community network in The Netherlands. Tomorrow at four o'clock, there will be a peering session for IPv6, so if you have got an active IPv6 network and would like to meet your peers, or would like to meet new peers, please come to the session tomorrow at four o'clock, it will be held in the, near the cloakroom at the end of the hallway on the right at the same time as the NCC services Working Group. Thanks.

CHAIR: So, just to be clear. This is an informal session that you organised and of course it's fine at a RIPE meeting to organise informal sessions but it will probably not be with an agenda. It will be there at four o'clock.

We had Rumy who wanted to say something, looking for people. Is she in the room?

SPEAKER: I just wanted to briefly make a little announcement. We are this week very busy -- I am Rumy Kanis from RIPE NCC the training manager. My name is on there. My department is very busy this week recording testimonials from people from the community who have hands-on experience deploying IPv6. We have already interviewed a couple of people from the community. Thank you for that, by the way. But we are still looking for more people. If you have some practical experience deploying IPv6 that you would like to share with the community or maybe hurdles you encountered and that made you stop your deployment or any other experiences you think that people might learn from, then we'd be very interested in filming you. It doesn't have to take long. We have our room set up with cameras and everything ready and I can show you the questions that we want to ask, or if you have a topic that you think is interesting to talk about. And that's fine too. And it takes about half an hour and we will send you what we want to publish before we publish it of course, so you can still back pedal if you don't like what you said about your company on film. So, if you are interested or if you know someone, you have a colleague, because we can also come to you after the RIPE meeting with our material to film you, if you are interested, please contact me at rumy@ripe.net, or just grab me if you see me walking in the hallway or you can also send a mail to training@ripe.net, it may be easier to remember. Thank you, David.

CHAIR: Thank you. The next agenda topic will be the RIPE NCC service update. Erik Romijn.

Erik: Hello, good afternoon. I work for the RIPE NCC, I am a software engineer there. I usually work with the routing information service, and I like statistics. I work with statistics all the time so I'll start with one, and the history of this presentation is that I went to the Linx IPv6 workshop a few months ago together with a colleague, James Aldridge, and we did a presentation and I am afraid I copied most of the slides for this, so 3 percent of the people in this meeting will already have seen everything and can go back to reading e-mail.

So, at the RIPE NCC we consider IPv6 to be very important. First it's a production service, it must be kept at a production level. It's not just for testing. So, this is the late information services orchid which used to sit in our office and was also equipped with IPv6.

So, as we have so much IPv6 support, I'll keep it to the services that don't have IPv6, which is a very brief slide.

So, we promised this somewhere last year and indeed all our external services are available over IPv6 since January this year.

So, I will cover a bit of the network. I will show some of the collections of IPv6 data that we have, we have all this nice services that do routing analysis, traffic measurements and things like that. So we have a fairly simple network with our servers and our things. We have three locations where we spread our machines and this week we have a fibre to fourth location, which here.

The triangle looks like this, with our three locations in Amsterdam. And we run on a /42 assignment from SURFnet since quite a few years now. The reason we have that is that we cannot get our own IPv6 block, so SURFnet has been kind enough to assign a /42 to us which we use for our IP physics.

We have a network with layer 2 switches with Foundary switches. Routing on Juniper. A set of net screen firewalls and our IPv6 is all now dual stack carried on the same routers and using the same M6 connections. For a while we actually had a separate 10 megabit M6 connection which carried our IPv6 traffic but that's been discontinued since 2003 I think.

We have quite a few IPv6 peers, about one third.

And as IPv4 was of course well known by our routers and route defenders, he is everything was quite stable there. IPv6 took us a bit of work. So there was initial lacking of features such as fear RR P, that has mostly been fixed now. On the firewalls, we had some more painful issues. We used to occasionally, randomly, unpredictably crash and stop forwarding IPv6 traffic. But also crash such that they would not trigger a fail off between each other. So this cost people to be woken up at night to then manually reboot the firewall after which everything would work until the next time. We reported this and got a patch which caused to crash. That caused a fail offing between.

After quite some many months of debugging, this has finally been fixed with a later software version and since then, all our firewalls intruders have been properly behaving for IPv6.

We have a set of Foundary, F5 low balancers for some of our services that do low balancing like you would be used to. Originally they did not support v6, they only did v6 to v4. In the meantime that has been fixed and we can actually do complete IPv6 load balancing. We do have some v6 to v4 proxying intentionally for some web services that depend on all their software and are difficult to upgrade in that case we stick our F5 in front of them to do translation to v4 and make the service available over v6.

Most of our servers run a Linux distribution, we have quite a stack of Debian and some older slack wear machines. There is also a bit of Windows here and there and some FreeBSD. I don't think we have any external Windows though. And our experience is that the mileage will vary.

There were various hard to define issues with handling, routing advertisements by different operating systems depending on different kernels and the position of the moon. And our experience is that most systems will actually accept a link local address gateway. However for some they will not accept this and it's been statistically configured. Our experience is, as you would expect, that with newer software and newer concerns this software problem occurs much less.

For most of our servers, we have enabled routing advertisements managed address configuration, so most of them manage to have a statistically configured IP address. All our work station and laptop are out of configuration and that just works.

As you notice, there is IPv6 connectivity at the RIPE meeting. The RIPE meeting runs on two Juniper J 2320 routers. They do for resilience. Occasionally we use older CISCOs for other purposes. How we connect is difficulty. It's just plug into the NCC network and we part of the NCC AS at this moment. Some remote hosts can provide us with native v6, otherwise we have to tunnel through Amsterdam over v4.

In Berlin at RIPE 56 we ran experiments with IPv6-only networks. We used net NAT-PT and DNS ALG to we could still access v4 hosts and we ran a full hour without our IPv4 networks.

About a third of the people here were actually there so I'll brief mention how this has been set up. There was our network at the time. There is a Cisco 7301 in the middle doing IPv6 only, and we have two different networks of which one had also RC 1918 for resolving. This because Windows XP will not do resolving over IPv6. It will over connect to hosts over v6 once it knows servers.

We have a host, it's called Frank and we have Todd, which is our resolver. It runs a software called Todd D. And Frank only has IPv6 so it will ask for the quad record of /A dot net, and Todd, in that case, will also ask that question. Our normal will answer with an v4 address because /dot doesn't have v6 address. It thinks then I have to, Frank can only access v6 it makes up IPv6 address which doesn't look entirely like this, but this keeps it easy and then it answers that to Frank. So Frank connects to an IP address, it doesn't know the IPv4 and the router translates this.

So, we got this running in RIPE 56 and everyone was happy and it worked. That took about 20 hours of hard work by two experienced network engineers. And also a Cisco engineer who could access the people who actually wrote the code in our router, and after a careful match of all the settings and the software versions, everything worked. Quite a CPU load, but there can probably be improvements there. If you want to know about it, there is a lot of detail in the tech meeting presentation we did at RIPE 56 including snippets from our configure software that we ran, and things like that.

So we have these various services. I put them all together, but, of course, they are very important services. Our main website and e-mail, for example. About 2 percent of the visitors on our website currently use IPv6. Or they connect over IPv6.

Our e-mail took some more work because we used quite some home written software for spam filtering and some other things but that's now all off the shelf software.

FTP we also had issues with our firewalls regarding passive roads but that's all been mixed in later software versions.

The LIR portal does not directly support IPv6. So it proxies through load balancers. Of course that he is load balancers are also redundant so we are quite safe in a case of hardware failures.

The RIPE database sometime provides native IPv6 access and it gets about 0.27 percent of queries over IPv6.

For the DMS department, they one of the K-root server and of course we all now the AAAA for a K-root and the other IPv6 supporting route server has been there for a bit over a year now. They get 1 percent of their queries over IPv6. However, 25 percent of their inquiries is already for AAAA records. Not all notes of K-root support IPv6. There is currently 8 on line and we are trying to work on improving that.

For the first delegation we see about similar numbers, about 1 percent of the queries is done over IPv6.

When we look at the amount of queries received by K-root over IPv6, week see the point at which the AAAA was added and it's crossed into 100 queries per second. Apparently before that, several people had the errors in their machines. And also this was being monitored by one of our monitoring servers.

When we look at the queries it receives, most of it is still A, but AAAA has actually out grown PTR records.

Their general experience that it just works. They switch it on and it works and there is really nothing exciting actually about it. Of course their notes are relatively simple one router switch and some machines. So their biggest challenge is to get IPv6 transit for the nodes. Also, we continuously monitor all our K-root notes and various other route servers through DNSMON which is our global measurement network from test traffic measurement and we check whether they will respond, whether all the routing is good and things like that.

So, we also have Hostcount ++, it's a service that counts hosts in the RIPE region and it does it by walking through parts of the DNS tree. It has done so for about 15 years I think now. And we get to a stage by doing some transfers, so we ascertain deal for transfer and then refer down and try to get as much as we can. For IPv4 we also walk the entire reverse tree. For IPv6 we don't because it's slightly too large.

This also means that without the zone transfer, we cannot count IPv6. So if you want us to help count that, you can add our added range for zone transfer and they will be included in the next one of the count.

If we look at the overall result of this, Hostcount sees 20 thousand IPv6 hosts on 125 million IPv4. If you look very carefully, you can see a few blue pixels which the IPv6 world.

This can easily be explained by the fact that 71 percent of our zone transfer fills, which means for those zones we do not see any v6. With if we look at the data for .UK for example, we note that 518 IPv6 hosts. If we look for .NL, there are no IPv6 hosts in The Netherlands according to Hostcount. This is easily explained by the fact that we tried one zone transfer and couldn't get the .NL zone. So it ended there.

So, onto the routing information service. The routing information service collects BGP routing data using various collectors all over the world. We have done IPv6 for seven years now, almost seven years. Most of our collectors do IPv6. We keep this historical overview forever, so we know of almost all IPv6 routing updates that happened in the last seven years.

The data I will show after this is only based on a subset because I didn't have enough time to do it on more, so this is based on our Linx collector.

Based on that we see over 300,000 IPv4 prefixes and 1,800 IPv6, Gert will also show you some other numbers on this. Our numbers are higher because some people announce internal prefixes to us, which also explains why we crossed the 1,000 earlier than that. This is not very surprising, we have also looked at the average number of updates generated per prefix per day. We see IPv6 prefixes generated one-and-a-half times more updates than IPv4. This is also corrected for the amount of peers we have. So it's still less stable.

When we move onto the TTM. This measures one way delay measurements between various boxes hosted. We currently have 77 on line which 36 measure IPv6. These boxes measure data about the performs of the network that hosts. So you can get one as well if you are interested.

Also, we have DNSMON as I mentioned before which uses a TTM grid to measure the reachability of root and TLD servers on IPv4 and IPv6 using all these boxes.

When we look at the data using RIS, we see five years ago when the grid was significantly smaller, only 18 boxes in the TTM grid, we saw 38 percent higher latency in IPv6 than IPv4 on average. That's based on a ten day period in which we took 600 measurements between all the boxes. When we look at now, we can see that the difference is significantly less. You can see that both latencies actually increased but that is due to the different composition of the grid. It's now 36 IPv6 boxes. Of course we only took the boxes for -- IPv4 we only took the boxes into account that also do IPv6. This is all between the same machines. And apparently the difference between IPv4 and IPv6 latency as perceived by TTM is lowering as you would hope.

TTM also does MTU measurements to estimate where there are tunnels. In 2004 our grid looked like this. Green is native, yellow is tunnelled and orange is broken.

And -- that slide is missing, about it will be there, the grid is now almost completely green. So from the TTM boxes, there are almost no tunnels any more used for connectivity. What we should now see TTM is that people with bad connectivity and that don't really care for their networks are not likely to buy a TTM box to stick it in their network. So TTM may be a bit bias to people who do properly and accurately care for their network.

So that was my presentation. For TTM, as I briefly showed, you can also see more demos of that at the IS demo stand which is in the hallway during most breaks of the meeting.

Are there any questions?

CHAIR: I cannot imagine that there is nobody with questions. There must be somebody, because I do have a question. Maybe Lorenzo.

AUDIENCE SPEAKER: There is one service that does not support IPv6. Your socks proxy.

SPEAKER: Do we have one?

AUDIENCE SPEAKER: Yes you do. But it's internal only. So it's not a public service.

SPEAKER: I am only looking at public services for this. So...

AUDIENCE SPEAKER: We see client networks. And we -- so we see how many users are in each network. So that's why we know.

Patrik: I presume that you also count ROSIE as a non-external service?

SPEAKER: Well, yes, that's a very good question, I should have expected that one.

AUDIENCE SPEAKER: So the definition of external services might be the ones that are accessible over IPv6? Sorry, just kidding...

SPEAKER: No, this is -- you can actually access all ROSIE content over IPv6 through the ripe.net web page which features some content from ROSIE, so you can actually see everything from ROSIE without having IPv4.

AUDIENCE SPEAKER: I am kidding. You are doing a good job. Thank you.

AUDIENCE SPEAKER: Mohsen Souissi from AFNIC. Just one comment for kidding, there is something missing for IPv6 support. The AC L for zone transfer for Hostcount ++ is IPv4 only. Shame on you. But that was for kidding.

My real question is: How do you think you can insent the operators managing the reverse delegations for IPv6 to get the transfer active for you so that your Hostcount ++ work in IPv6? I am really very -- I mean, I don't know how you can get them do that for the sake of the community and IPv6, blah, blah, blah. So do you have any strategy for that? Now it is zero. So how getting something better than zero?

SPEAKER: Well the first step in that is to get a zone transfer from a TLD. I am not actively with that but of course TLDs are restricted in what they can do for us.

AUDIENCE SPEAKER: I am sorry it's not TLD. It's IPv6 reverse delegation.

SPEAKER: But, yes, yes...

AUDIENCE SPEAKER: It's operator thing, it's not THDs.

SPEAKER: I am not sure -- I am also not actively involved in that.

SPEAKER: I can try to answer that question. For IPv6 we are not using reverse, because reverse, what we are doing for IPv4, just to improve the quality of the data, because we can't transfer all the forward zones, we just numerating all reverse. We can do the same in IPv6 because IPv6 reverses [BIC] and [] sparse. So, the real problem here is that we have difficulty in actually transferring forward zones and therefore, we have difficulty counting IPv6 addresses there.

Our strategy here is convincing operators to open the ACLs for IP address so we can transfer the zones and for those operators who have problems with some, or have some privacy issues or some considerations, we have developed a do-it-yourself kit. So we have developed a piece of software that we are willing to give ccTLD operators who are willing to use that and this stuff will count the hosts, anonymise it and ship data back to us, so that's our strategy.

AUDIENCE SPEAKER: May I just add one question? Since it is now related to the forward DNS, do you think it's a good thing to collaborate directly with TLD operators, let's say ccTLD operators, just write an e-mail, the ccTLD operators may relay to their registrars, their domain name holders and maybe in that strategy, you may have better results. I would suggest that.

SPEAKER: Thank you, yeah. We are using this strategy. We are not a hundred percent successful though.

AUDIENCE SPEAKER: Okay.

CHAIR: So this is David Kessens is a regular Working Group member also asking a question. I was wondering about a huge number of AAAA requests that you are seeing. Do you have any explanation for that or?

SPEAKER: No, I don't know the explanation for that. Maybe there is someone from the DNS group in the group that can comment on that.

SPEAKER: This is RIPE NCC DNS manager. Those AAAA queries are actually a little bit anomalous. We sometimes see storms of queries for AAAA as well as A6 records and these originate from particular broken versions of bind, which -- we can't explain why they send these queries but we suspect that, you know, somebody is abusing them and sending these queries to the route. So they are not entirely genuine queries I think. I hope that explains...

AUDIENCE SPEAKER: Gert Doering, I actually have a question. What about your internal office network? Like, all the work stations, since you are using Mac, they are v6 capable, are you turning it on so that traffic going from people working there to your internal service is v6 or are you afraid of that?

SPEAKER: I am not sure about all our networks. I do know that on the wireless, on the guess network that we use for most of the laptops, it is definitely knell switched on after an initial trial period. I don't know whether we have it on all the work stations. But there is, our experience with the laptop work stations is that it's just fine and there is almost no problems.

AUDIENCE SPEAKER: That's basically our experience as well. It will just work. You have to eventually tweak something and a patch here and there to tell it about v6, but it will just work.

CHAIR: Okay. Thank you. It's time for Lorenzo. So just for the records in between -- so, we have a very full agenda so I do expect that we will run a little bit over time, but we will definitely make sure we won't miss the buses at a quarter past six, just for your information.

Lorenzo Colitti: So, I apologise actually for this presentation. The numbers that I got, I just got them, just calculated them today, I had to rewrite some code to get some numbers that were more useful that were requested recently.

So, it will be a little bit hurried. Also I'd like to save time and a lot of you have seen a lot of this before, but when talking to a few people, I keep hearing that they are not aware what have we are doing. So I am trying to keep talking about this.

So, I can't believe nobody has shown this graph before. We all know what it means. We need to find a way to either -- basically it means that if we want the Internet to continue working as we know that it's been working so far, we have to find a solution that does not involve IPv4, because public IPv4 space is going to go away. So that either means the Internet will change its model a little bit or that we have to move to IPv6.

There is a business case for IPv6, at least the way we see it. The way we see it, alternative to IPv6 will be expensive. Buying addresses are expensive, if you want to do logging for legal intercept, you are going to have to essentially log every SIN packet that enters your network. That's going to be expensive if you have a lot of traffic. The debugging costs are huge in that.

There is also an opportunity here if, if you heard Alexandre's talk earlier, there are a large number -- there are a huge deployments with a large number of devices which are only accessible via IPv6. Free set top boxes are only accessible using IPv6. Comcast modems and presumably their set top boxes will only be reachable over IPv6. Why? Because there is simply not enough address spaces to assign to these devices. And in Free's case I believe one of the reasons is that they couldn't do NAT at wireless speed on their fibre net home devices because the CPU is too small to do it and CPU has to be small because the -- because it has to meet the power efficiency requirements set by the EU.

So there is going to be a large pool of devices that's only available using IPv6 and if you are a content provider, then you might want to talk to them which means you need to have IPv6.

End to end. Users are not asking for IPv6 because they don't know what it is. But they do know that they want to talk to each other, because they run stuff that -- they run applications that you know in Geoff Huston's word leap tall buildings in order for them to talk to each other. Skype is extremely sophisticated example. All these applications talk to each other and these applications would not work in a world where everyone of behind two layers of nap because there is no way to make them work.

So, we need to think about happens if Intern goes away, if the Internet moves towards a more garden paradigm, more towards a TV like paradigm. Given the fact that people come to Google to search for things, to look for things that that are not easy to find, we think it's important that they keep, you know, that they stay able to find these things and that the richness of the Internet is not diminished. So we don't want to see this map happen.

And let's not look for a killer application. The killer application is the survival of the Internet as we know it.

So, for all these reasons, we see it as being important in the future and it's better now for a small number of people, there is not a lot of IPv6 out there, but when it is there, sometimes they have better connectivity to us over v6 than v4 and we use v6 then.

Of course the problem is that -- these numbers are a few months old but I'd be surprised to see them change very fast. Yes at option is climbing but no it's not climbing fast enough.

The good news is that adoption can appear overnight when people turn large networks on and the same way as traffic can appear overnight. We have seen that.

So, some of you already know this. But we can't enable IPv6 for dub-dub-dub.google.com today because our statistics use that a small number of users won't be able to reach Google at all if if we do that and that's unacceptable for us. Even if it's one in ten thousand or one in a thousand, it's simply too high. We can't do that. Also latency would be higher for a lot of people, and we don't like that. Because everybody likes the searches to come down fast.

We are trying to fix the problems for the users that have proper v6 connectivity. We have built -- we have a production quality IPv6 network. We try to avoid the problems of bad routing that are getting fixed now but we were sort of one of the first in the game, so we had to look at, you know, long paths, tunnels, in through the main tunnels, all these things. So we basically said that we would manage all our own routing and basically not take transit and stop people by announcing us full tables by simply dropping BGP sessions. We peer with as many people as we need to to get close to the users. And we only serve IPv6 to production quality networks.

So, this should be working. I don't know if the IPv6 connectivity here is working now. It was broken a while ago. Did somebody check that? Is it working? It's not working, okay. Anyway... so, if the IPv6 connectivity were working you'd be able, you would be reaching Google over IPv6. So, since it's not, you are probably reaching it over v4. But anyway, so if -- basically, if you request the service, we are able to provide almost all Google services to you over IPv6. That includes the web search, it includes gmail, it includes maps, it includes docs, all these services are available.

And we have had a very enthusiastic response. We have had the last day over 50 organisations participating. Universities, research organisations and entire NREN, the Australian research network, and anyone who is on that network, will receive Google over IPv6. There is a large French RSP that we talked about earlier. We see more than 250,000 unique addresses over IPv6 today. Nobody has ever asked us to turn this off and everyone, so far, has been very happy. Some networks see better routing, lower latency. When the IPv6 was working here it was faster than v4.

And there is enough IPv6 traffic and enough people care about trying to get to Google that if there is an IPv6 problem in your network, tell get reported, off a at least this is what people have told us. And if you are v4 congested and you have separate routing infrastructure, you are going to be using that.

So, if you have a network with a substantial number of users and you have production quality IPv6 and are willing to support your users, then please let us know and which can deliver IPv6 services to you if our connectivity is good.

So, how did we do this? Well, we started as a 20 percent project -- why am I saying this? Because, the lessons that we learned are that this is not hard. And that -- so we are trying to tell you how we did it, so that you might be able to learn from us successes and from our mistakes. So we started as a 20 percent project and people just came out of the woodwork, there was a lot of enthusiasm. This didn't come from top down. It didn't come from management requirement. It basically started from the engineering and all the managers really had to do was get out of the way and allow us to start small in a lab environment and then scale it up when we were ready.

It took us about a year-and-a-half to go from zero to being able to serve most services over IPv6. And we keep adding new ones. So, and this is a very, very small team. Just a handful of people.

So, your mileage may vary but basically the lesson here is it's not rocket science.

A few lessons here: Try to make it as similar to IPv4 as possible. If you can dual stack, because then your operation staff, everyone says training, training, but if it looks the same as v4, your operation staff will look at it, they won't see anything different, they'll just see this v6 address, oh yes that's a v6 address, that must be it. That's it. I mean, in my experience, if the designs are the same, then it's really easy to support. We have not had major issues in supporting it in asking our support people to accept it.

There is a few gaps in the standard, in particular VRRP, it doesn't exist. I know that Juniper implements it, I don't know what they implement since there is no standard, but for those of us who run load balancers, having VRRP might be useful. And for lots of other people as well.

Licensing: This is still not fixed. Some vendors still charge separately for IPv6 licensing. Some vendors do not. Kudos to those that do not. But if you are a router vendor, you are probably not here but if you are an exchange point operator, if you are an ISP, please do not charge accept separately for IPv6. Please absorb this cost in other ways because charging separately will hinder at option. We have seen exchange points ask us for significant amounts of money just to assign us an IPv6 address. That is not the way to encourage the adoption.

A few numbers: And these are the new numbers. So, a while back we were talking about the fact that IPv6 latency is worse than v4. So the first numbers we had showed, and that was in I think October, showed 150 millisecond gap between the peaks of these two graphs. So basically these are v4 requests going to a number of data centres, not all of them, to a number of data centres around the world. V6 requests going from the same clients to those data centres and later v6. So again a few months ago, there was 150ms gap. Now, the gap is more like 100 milliseconds and if you count native, it really isn't that big at all. Native v6 is actually pretty good. In particular, the people that the networks that talk to us over IPv6 often get better latency because of our emphasis on direct peering to ensure quality.

So, latency is getting better and the message here also is that a large part of it is actually tunnelling mechanisms. You see that if -- the difference between the blue and the green, see the peak here, this is a distribution across -- we have a number of -- not a number of clients, it's number data points on a per client basis, so it's number of people that happen to get our random link to verify their IPv6 connectivity. It's a piece of Java script embedded in the search results page that gets served to about one in a thousand users. So, basically number of these -- number of users here and this is the latency calculated in a complicated way that's not indicative of the response latency. But anyway. So the difference between the blue and the green, which is basically native IPv6 compared to the total IPv6 is about 100 milliseconds peak to peak. So...

A lot of latency here that you see in IPv6 is due to transition mechanisms, which is one of the reasons that I personally don't like them.

Oh, and yes, traffic can appear overnight. As I was saying, users can appear overnight and traffic can appear overnight. When a large network turns on IPv6, even if they do it in a staged manner, then you'll see something like this. So it's kind of hard to see in this graph due to these measurements art facts the. But this was our base line v6 egress traffic about here. And then we turned on map tiles and traffic jumped about 2 to 3 X and that was overnight. So one lesson here also is do not point to the abstinence of traffic to justify the argument that nobody is doing IPv6. Maybe they are not -- they haven't turned it on everywhere yet, but when they do, it will -- there can be large increases.

So, I was hoping to show you a little more data and some demos, but I don't know if I can -- if the v6 networking is working, no, okay...
Well... one thing I can show you though:

So this is a chart of basically using the same engine as Google finance. This is a chart that shows the percentage of IPv6 that we measure using our experiment. So, we see that currently about 0.2 percent, the sort of type light blue line is the amount of IPv6 that we see in the whole world. Most of it -- oh, sorry, that's the top line. This intermediate blue line is a little bit darker is native. So, where native is defined as anything that's not 624 and Teredo. It's not really native. It's stuff that doesn't use relays, and that is -- those are the host that is we try to reach, assuming they are good connectivity. So you can see that native is about a third, just over a third of all v6 connectivity, so there is not a lot of native v6 out there.

The red is the proportion of requests that we serve as Google over IPv6. So, basically just over two thirds of the native IPv6 Internet appears to be enrolled in our Google over IPv6 programme, which is a good sign.

And that's it. Seeing as I can't show you Google over IPv6 because the v6 network is down. So... any questions?

CHAIR: Okay, any questions?

AUDIENCE SPEAKER: Matt Forde, ISOC. So this is great work, Lorenzo, and thank you very much, I hope my question doesn't sound as if I am trying to pick on you, but -- so the Google over IPv6 programme doesn't scale, as I am sure you know. At what point do you say, you know, whatever fraction of your users are going to have their connectivity broken when we turn on a AAAA for dub-dub-dub.google.com that we don't care with this any more? Is there a number that you have in mind or are you just going to wait to see how things progress or do you hope that that number gets to zero?

SPEAKER: I don't know the answer. Part of the answer is that this is a decision that's above my pay grade as people like to say. Part of the answer is that we don't know what the Internet is going to look like, six months, twelve months, two years from now. I don't know. The -- usually, if you look at the adoption of things like Fire Fox, usually what happens it that the magic number which things have to be fixed is about ten percent. I don't know how long it will take to reach ten percent and I don't know whether we want to turn on a AAAA for dub-dub-dub.google.com, before, after or at ten percent, I don't know. But it depends how the situation evolves. And we also need to get better data on the brokenness. I mean, I have seen this personally, I have seen this happen on my laptop. But it's very hard to measure because it's a very low number, it's a small proportion of a, a very low number and it's hard to measure because it basically, it shows up as a time-out that you can't really -- that could be confused with any number of things like user navigating away from the page or the user closing the window or unplugging the network connection or a time-out on a wi-fi. It's very hard to -- it's very hard to understand when this happens. So the number is very noisy. So, when we have better data on that, I mean that's also one of the conditions we need to have better data on how much is broken out there.

AUDIENCE SPEAKER: Hi my question -- I am Kostas Zorbadelos from OTE SA in Greece. I ask the question to the colleague from Access for All: I want to know more about your load balancing mechanisms? Do you use the same load balancing mechanisms for IPv6 as in IPv4? Or have you implemented something different?

SPEAKER: I am afraid I am going to have to punt on that. We tried to use the same infrastructure for everything. Yes, the load balancers are the same. In general, attempting to deploy IPv6 specific hardware is not a good way to do it, because it doesn't scale because it's hard to justify, because it will break by itself and you won't maintain it. The way to do this is to, you know, accept perhaps more limited functionality on your existing boxes and only put in place separate infrastructure if you really have to. And talk to your vendors. Request -- lots of people, you know, lots of vendors don't know that there is demand for doing this stuff properly and simply a matter of getting into their sort of release schedules and on their road maps.

AUDIENCE SPEAKER: If I may get more technical. Do you use virtual IPs and NAT stuff on the IPv6?

SPEAKER: I can't remember.

AUDIENCE SPEAKER: Or is it an NBA agreement and --

SPEAKER: We do not like to reveal by our private infrastructure.

AUDIENCE SPEAKER: Okay.

AUDIENCE SPEAKER: Fergal Cunningham from RIPE NCC. There is a question on Jabber from Jasper. He asks when will Google [] butt start crawling over IPv6 when AAAA is available?

SPEAKER: I don't know. I know that we are working on that. There is a project in Dublin to work on that, but I don't know -- actually I don't personally know what the status is. I see the changes flying past in my e-mail but I have never asked them you know exactly how much is left to do. We are working on it.

AUDIENCE SPEAKER: Hi, Casey here. I just want to make a comment here about your claim that just because we can't see traffic, doesn't mean we shouldn't -- doesn't mean we should believe that IPv6 isn't really happening. I have to object to that as a scientist, because traffic is really the only measure of grand truth that you have that IPv6 is really being used. I know how hard it is to get traffic numbers and maybe this is a reason to send a couple of people off in the corner and have a conversation about how to navigate that problem because this isn't the first time we have had a question about traffic numbers, and believe slides on PowerPoint that has led us into a global telecommunications crisis because we believe numbers like traffic is doubling every 90 days, we have had a global example of how it is to get real traffic numbers and what happens then you don't.

A fact that resulted in several billion dollar accounting error resulting in the biggest bankruptcy the United States ever had until the financial sector put us to shame in that regard. So I just want to repeat because I know the EU is going to try to do a survey of this and I know we tried it a couple of years ago. I want to make it clear that a survey is a substitute for the ground truth. It's not actual --

SPEAKER: Let me rephrase that actually: You are correct. Let me rephrase what I mean.

What I mean is do not expect growth in IPv6 traffic to be smooth and organic. Expect that it will initially have large jumps and large spikes as people turn on large networks because, again, the issue is that you are not creating traffic out of nowhere. The issue is that you are moving traffic from IPv4 to IPv6 because the user stacks, all else being equal will prefer IPv6 to IPv4. So take a large network, imagine that you roll out IPv6 in this network using a rapid release schedule like free did, sort of very quick, very aggressive schedule. What happens is you get you know percentages of growth that do not, simply do not occur in more established, in v4 traffic numbers. That's what I meant.

AUDIENCE SPEAKER: Then I think it would be really good if your graph about IPv6 traffic being really bursey had a Y axis with numbers and labels so that I could tell it wasn't going from 0 to.002.

SPEAKER: Noted. Other people have numbers, but... Randy I think?

AUDIENCE SPEAKER: Fergal Cunningham from the RIPE NCC, I have a question on Jabber.

How does Google define production quality? When is a network good enough to be allowed on the IPv6 platform?

SPEAKER: Does that mean -- I take that to mean a user network that would like to participate in Google over IPv6.

Essentially there is -- it means that we have good connectivity to this network and that this network is willing to support its users if they have any issues. That is mostly -- that is mostly what we are looking for. We also -- we'd like to see that its infrastructure is common to that we don't have IPv6 specific failures. The issue is that we do not want to see -- networks that don't properly support it which means that IPv6 is probably unreliable and we don't like to see IPv6 breakage and other networks stop our users from reaching us, because that is a bad user experience. But we do not look at people's networks in detail. We ask them to support it and we verify that our connectivity to them is decent and that's mostly what we care about.

AUDIENCE SPEAKER: Randy Bush, IAJ. Nobody believed any numbers about 90 percent every three months, etc.. That's fantasy. We do see measurable spikes as Lorenzo says as large customers, change something, it doesn't even have to be new connectivity, it's, they change the way the DNS resolves. They change client roll outs, they change to the way they are doing their gateway services, etc., etc.. But in reality, all these discussions about measuring v6, we are discussing what form of electron microscope you want to use, there is very little traffic. There will be more traffic, but I think Google's measurements are as useful as any other that I have seen. Thank you, Lorenzo.

SPEAKER: Thanks, Randy. The obvious answer -- the obvious sort of corollary to this, Casey, is that traffic is necessarily capped by that 0.2 percent number, at least traffic to us, because that's what we see. So no more than 0.2 percent of the global Internet will come over IPv6. If we enabled all our services which are not, the video is a notable exception, we don't have video over IPv6 yet, if we had all our services enabled over IPv6, we could expect about the linear extrapolation of that in v6. We don't have that yet. And so -- that is basically that is a traffic number. However we don't reveal our v4 traffic numbers either because it's our policy not to do so, so we -- it follows that we don't reveal these ones either.

AUDIENCE SPEAKER: I don't mean to be specific about Google. I mean in yen traffic numbers. In the survey the people who said they were engaged in IPv6 traffic activity admitted routing or ping traffic or maybe a couple doing DNS. Like Randy says there is very little v6 out there. The traffic in your spikes was testings and making sure things were working. In fact I would argue that by that token you need more than traffic numbers. You need to know when legitimate v6 user traffic is broken.

SPEAKER: We are past that point. We are at the where we have predictable daily patterns at least for us, because we have a number of networks, not extremely large, but substantial size using us everyday.

If you look at this graph, there is you know, these are not spikes, right, these are days. It's starting to look like a real traffic pattern. So, ignore this and this. These are measuring errors.

AUDIENCE SPEAKER: There are no numbers in this data.

SPEAKER: I have told you why there are no numbers in this data.

AUDIENCE SPEAKER: So that's a limitation. So I am glad that you are making the state -- it's great you are making this available but I think we need to acknowledge what is the limitation of the data we are making available and what data we would need to answer the question for real.

SPEAKER: I think traffic, client penetration is also a reasonable measure, or at least a measure we want to track. There are people who are measuring traffic, the M6 has traffic I believe.

CHAIR: If you have a very important question, then feel free to stay at the mike, but we don't want any more people to show up at the mikes at this point. So --

AUDIENCE SPEAKER: Mohsen Souissi, I personally congratulate you with this presentation and the dates you keep doing. Yet, I have a strong recommendation for this presentation, even though you had a methodology slide, I believe that out of this context, this presentation may be not serving in the community at all because it's not your fault, I mean -- people will take this presentation out of context and say hey, Google, who is seeing everything, who knows everything, says that IPv6 penetration is not evolving. That is not your fault. But I think that you should strongly insist that this methodology doesn't see all traffic for example. All servers being deployed everyday are not seen at all by Google. And I mean, I don't have a magic solution, but that, that's very useful for the community so that this is one measurement tool, it's not the only one, and I think it needs to be we will stressed and I don't think it is well stressed in this material, not your -- your talk is very clear.

SPEAKER: Yes, it's true that niece numbers, if that wasn't clear, that these numbers only reflect IPv6 clients that connect to our website.

AUDIENCE SPEAKER: A question on Jabber: He asks: Will the Google IPv6 team roll out IPv6 for YouTube, and if so, when?

SPEAKER: We are working on enabling IPv6 to as many of our services as possible. We run into -- there are limitations in hardware and various places. There are limitations in the developer time we have, we are working on all services. It will come at some point.

CHAIR: Okay. Thank you very much. I appreciate the time that you spent here answering all the questions.

(Applause)

CHAIR: Martin. So the next agenda item is a traditional item that we have, just showing, giving a chance to people to share with us traffic statistics and other issues regarding traffic that they see regarding IPv6 on the Internet. Martin already volunteered. If there is anybody else who wants to show something or just talk about it, it can be done after Martin's presentation.

SPEAKER: While that comes up, I'll start. Mime Martin Levy from Hurricane Electric, I am going to show some stats on a different subject than raw absolute bandwidth, but to answer Casey's's question and anybody else's, use your favourite search engine, go look forth Google IPv6 conference about a month ago and go look for my slides because there is real traffic measurements off of our network for full traffic and a few other things in there. This is actually going to be an update on one specific subject. I am not going to talk about overall traffic on our network. If you go look at those other slides you will see we are moving about a gig and a bit. There is one key phrase for us as an IP backbone which is very different than Google as a content company. In our network, we don't have the same customer base for v4 and v6. We have a large overlap. But we don't have the same overlap on usage. So we see our stats for v6 not being very easy to measure against v4. There is a percentage there, but it isn't relevant. And that's explained more in the slides. So again use your favourite search engine. Google IPv6 conference about a month ago.

So, what I am going to talk about is one small growing worrying percentage of that traffic and show some stats. Try and get this done in under ten minutes or better and I am going to talk about 6to4 in Teredo traffic. Lorenzo said he already hated it and if I had a show of hands I think I'd get a majority of people agreeing with him on that one. The catch 22 is that it's out there. We are starting to see a lot more of this traffic than we thought. We are starting to see where it's coming from and that's one of the stats I want to show and I am going to at least put my thoughts on trending out there which everybody can agree or disagree with, and try and as I said keep this within a few minutes and also a few numbers of slides.

One subtle point about 6to4 and Teredo. 6to4, not a bad protocol. Teredo, sorry to be on record, horrible protocol. You know it's bad when the WIKI page is easier to read than the RFC. So then it isn't easy to read.

Okay. So what we did to talk about this was not only looking at our flow data and starting to see this but we also, we wanted to do a lot of things on our network. So because we saw all this customer based traffic -- we ended up with on our backbone, taking six or seven locations and putting 6to4 relay service. Prior to this, we were letting 6to4 traffic on our backbone flow wherever people were announcing it, whether it be peers, customers, it would change on a regular basis. The BGP MON web page if you have got, if you know that URL will give you a good idea of just how this flows over.

What happened the day that we turned this on, which is now about four or five months ago, is that we took a large percentage of traffic that we saw flowing from the US, Asia, into at this point in time into Europe, suddenly change. And that traffic which does have an X and a Y axes on it, so this is showing about -- even I can't see it -- so this is just over the -- this is summed over the various trans-Atlantic links, this peaks at about 20 percent traffic. This is the v6 traffic. And this was the first week of January. So we did this after the lull after Christmas.

Localising the traffic made a big difference. We saw a lot of traffic that was originally moving across ocean or oceans suddenly become localised. Teredo was a different story. We saw that off our backbone and others Teredo in Amsterdam, occasionally in Sweden, we could see some others out there but they were the predominant ones being used and we were seeing hundreds of megs of Teredo traffic moving around. We were seeing you know daily spikes so we could tell that this was sort of "Real traffic," user based traffic and what we did was we deployed over the whole network a Teredo service. We started with three and then very quickly went up to whatever that count is, twelve, 13 machines, ye graphically dispersed. Again I show the graph here which we built over the trans-Atlantic link where we were peaking around 150 megabits here. Sorry this graph is inverted just based on the direction here. Occasionally, we'd see peaks above 200 so the scale here is 0, 1, 2, 300 megabits over about four or five weeks ago.

We hadn't done this work when we did the Google conference stats so you'll see the pre-stats there and I'll share some of them with you because it was quite frightening. But what happened here was not only did we geographically spread it around but we had to go back to the RFC and understand the Teredo protocol even more because it made no sense, what was going on. And the reason is made no sense it will given away by a couple of these graphs I have got here. This is a measurement taken at some random date, 15th April, a couple of weeks ago, and then this one was taken over the weekend for these slides and the pie chart is showing different locations around the world, we are starting in Hong Kong, going through the US, from a northwest to a southeast modus operandi and then through Europe and this changed rather dramatically. In fact, this was quite surprising that so much was in California or the west coast. And what we have done is, over various measurements, we realised that this changes all the time. And the reason it changes is partly due to the protocol, but this is the key part of about it. Look at the traffic levels here. We are sitting there with about 2 to 300 megs of traffic. I didn't do the flow stats to show that this is not ping traffic. This is not trace routes. This is user traffic coming in and out of real ports, it's in some cases web access, in some cases it's use net news access. But it's predominantly end user to end user traffic.

The reality is that we found a large amount of this was very transitional traffic. Coming out of v4 hosts that running Teredo, going over to a small percentage of native IPv6 and some going to other islands of Teredo traffic but we were able to measure it, see this change. Could I continuously put up pie charts, each one looking slightly different and understanding why that change is, is a lot to do with the way the protocol works.

This is not the location of the client who is trying to access something via Teredo from a v6 only site. This is the location of the source of that data. When you go back and read the protocol that, the protocol back and see how this works in real life, it is the Teredo servers that use a very convoluted method, which is actually called faking the source address of a packet, and generating a packet which will detect the closest Teredo relay to the source, not the client. Net result is as the viewership changes, you start seeing these big jumps one way or another. This is a very, as I said, reversed protocol than what we expected.

We also saw this, this is a historical graph from about a month past ago before we turned ours on. Just to explain the problem. These are different relays, relay A, B, in one location, happens to be in Amsterdam and we started seeing the jump between different Anycasted relays. We saw a slight thing here but we started to see the slow success curve, because when when we swap out a relay you turn out to have to reset part of the protocol. It also showed us this which was the amount of 6to4 traffic which this was generating. We could tell you whatever was running relay A had a 6to4 relay next door to them, relay B did not and they were using ours. Putting those together was a key part of making sure the traffic had a better way of flowing.

Finally, the trends and why we care. These are my thoughts. This is based upon the traffic that we are seeing and basically, this is a protocol that I would be happy to see go away. It won't yet. The key part is the yet.

Although we did this, we know we have from our external testing, managed to put a lot more geographicly diverse Teredo servers into the world and more are needed, the reality is that while you have got users, in this case Vista and Windows 7 by default by any other operating system if you decide to install it, some easy some hard, but what you are doing here is as we do transition, as we bring up more v6 based sites, we are going to start seeing more of this Teredo traffic and the easiest way, the easiest way to get rid of this Teredo traffic is take the clients and enable v6 because then the Teredo logic just disappears. So this is going to be a transitional protocol. It may be a great measure of how many people want to access v6 but don't have it. It's not the way I'd want to do it but it's the reality of the way protocols work. If you have a laptop in front of you and you are running on an IPv4-only network around here, and go look at IPv6 google.com or somewhere else, you are liable to generate this traffic.

It's that simple. That's the trending that we are seeing providing relays out there seems to be the right thing to do, and we are definitely, as I said, seeing a lot of extra traffic. That's all I want to talk about. Thank you.

(Applause)

CHAIR: Any questions?

AUDIENCE SPEAKER: Randy Bush. Martin, it's a disgusting protocol. Some of us fought to stop it in the IETF and failed. It's not going to scale particularly well and it's going to continue to grow. What the hell do we do?

SPEAKER: Well, this was our first level solution because now I could at least see the traffic and measure it. We were not the be all and end all as far as the relays, there is plenty more out there but running stable relays will get us through this transition period.

AUDIENCE SPEAKER: Do you think so? Has things seriously scale --

SPEAKER: I am a half full type kind of guy.

AUDIENCE SPEAKER: The optimist thinks the glass is half full; the pessimist thinks the glass is half empty; the engineer knows the glass is too big. We are barely seeing v6 presence when it goes up by a factor of 10, when it goes up by a factor of 50, how is this going to be?

SPEAKER: If it goes up by that factor and it goes up because of access networks helping end users get v6 connectivity, this will be partially -- I won't say fully mitigated, partially mitigated. The reality is --

AUDIENCE SPEAKER: What is the content first?

SPEAKER: Then we better scale.

AUDIENCE SPEAKER: Lorenzo, stop. Turn off v6.

Lorenzo: It's not us, right.

CHAIR: We are not doing well on time so I have to limit the number of people on the mike, so if you have something essential to say, then please do so, otherwise I would very much like it if you could defer your question and move it to mail list or deal with it privately. So people at the mike can still ask the questions, no more -- no other questions allowed from that point. Lorenzo.

AUDIENCE SPEAKER: A quick observation: As a number of IPv6 enabled the torrent clients increases and the penetration of Vista increases we can expect to see larger amounts of v6 traffic tunnelled over Teredo inside access providers networks. Can we measure that and is it going to cost these access providers something?

SPEAKER: Not commenting on the traffic, but simply whether it's protocol wrapped in Teredo or not, it's still traffic.

AUDIENCE SPEAKER: It's expensive.

SPEAKER: It's still traffic, independent of cost.

CHAIR: Final question:

AUDIENCE SPEAKER: Martin Peterson. Martin, have you done any measurement of how much traffic actually is going from Teredo to 6to4 because like we are running Teredo and a 6to4 gate we are announcing it, and when we looked at it, it was actually -- it's about 17, 18 megabit at peak but if you switched the Teredo gateway, 14 megabit of that disappears elsewhere. Essentially the majority of the traffic is between Teredo and 6to4, whereas Teredo -- I don't think you actually see that because I think the Teredo servers talk v4 to each other.

SPEAKER: The stat at the moment is somewhere around 3, 4 percent, but the graph is so ugly it's not worth showing. That this native v6 out of the back of the Teredo relays collectively. It changes dramatically because of the user base coming and going. The rest of it is all going out to 6to4 because it's going out in a direction which wants to get to v4 host.

AUDIENCE SPEAKER: So it is essentially 6to4 to Teredo traffic, the majority offered. And the reverse.

SPEAKER: And the comment I want to make and this is important, that we had to run 6to4 and every Teredo relay. If you didn't run 6to4 literally on the same box you were now going to dump traffic in and out. So moving hundred dollars of megs of 6to4 traffic around just was highly redundant. You have to run the two either next to each other or on the same box.

AUDIENCE SPEAKER: On the same box actually caused us issues, but we are running them next to each other with a dedicated next so that's not really a problem. But --

SPEAKER: Yes, Teredo generates most of the 6to4 traffic which is the question you really want to know.

CHAIR: Okay. So as I already mentioned, we are going to run a little bit over time. We also -- I mean, I asked the speakers to keep things a little short. If you can help us keeping the questions a little short, then we can keep it -- we can still run over time but not too much. Thank you very much.

Now, it's Gert's turn.

Gert Doring: Here we go. This is the, well the standard routing table overview talk. And I hope this will be the shortest version ever of it. Not that there is nothing to report, but that I am short.

That's a useful thing that's in there every RIPE meeting. The full report is on the web. This version is edited and I have left out a couple of things where the web version has the updates.

Looking at the prefixes in the IPv6 BGP table. This is no big surprise. We have been growing and I am going to look into these in some more details on some more angles.

This is the zoom in the same data, only viewing the last six months. And normally you see some sort of big jumps up and down and spikes and everything in it, but for this meeting, obviously all the participants in the IPv6 BGP world you knew that we have no time to look into funnies today, so everybody was well-behaved and things are just growing and smooth and no big spikes in here here which is a good thing because stability is improving and so on.

Zooming a bit out again, trying to figure out what the sort of growth is that we are seeing and doing some very unsophisticated extrapolation. We can sort of see linear growth here and then it sort of sped up a bit, it was also sort of linear and since about two years, it's growing faster. I think that was the point where the RIPE community told everybody, please get ready for IPv4 exhaustion but this is still not the typical Internet curve. An Internet curve should go like this and it's not. It's growing, but I have my doubts whether it's growing fast enough.

This is the breakdown of the same data by regional registry region, and it's pretty much unsurprising. There is still RIPE at the top, then APNIC, ARIN -- well ARIN, APNIC and the two other smaller or younger regions are down there, but everything is growing and quite smooth as well.

Breaking it down by countries in the RIPE region we have Germany on top, Great Britain next, then the Netherlands. All of this is pretty much the way it has been since the last couple of years, so we are really saving time today.

Looking at the different angle, looking at the AS numbers. This is the number of distinctive systems participating in the IPv6 BGP world. So we have -- this is about 1,400 ASs in total and the lower two curves are ASs that originate only prefixes but don't give transit to other ASs, this is origin and transit and there is a few that only give transit. This is basically to be expected, so nothing very unusual here.

Looking briefly into IPv4. We can see that v4 is, for some weird reason, growing quite linearly over the last about two years. And we are at about 31,000 active ASs in the IPv4 world and 1,400 in the IPv6 world, which, if put in relation, looks like this. So the ratio of v4 to v6 active ASs is growing, which is good because we need to have more people that do only v4 before to go to v6 and v4, so what we should expect is that every AS out there is running v4 and v6 eventually, or what we should aim for.

This curve looks nice, it's growing like hell, but if you put it in perspective: This is down here, and we should reach 1. 1 means that it's the same number of ASs in v4 and in v6 and we are still below 0.2. So, there needs to happen something.

Looking at another angle: The number of prefixes originated by the average AS. In the v4 world we see nearly ten prefixes. In the v6 world we see about 1.3. So regarding routing table size, the routing table just by going to v6, if the distribution doesn't change, could slink by factor of 7, which is a very good reason to go to v6.

Coming back from the ASs, looking at the prefixes again. This is one of the slides that you don't show to people because it's just a big mass of numbers, so I am trying to plot parts of it. This is actually by region, by size, the number of prefix that is you can see in this line here, /32s, we have about 2 thousand, and most of them coming from RIPE and so on. But this is all the web if you are really interested in awful these details.

The thing that I wanted to display today is how this distributes over time, over prefix size. This curve is what is to be expected. That's the /32s. Every provider gets a 32, 32s are there, 32s are growing all the time. So this is to be expected. This one is the 48s. So the 48s have reached some nearly 500 now, with 32s at 1200. The 48 is is provider independent space from other regions. Route names and remember prefixes that all that sort of non-provider stuff, which is something that I thought we might want to keep an eye on, just to see how this relates. As a 32 could, in theory, encompass 60,000 48s. And this is other sizes. So it is basically smaller than 32 or longer than 48. This is really not adding so much to the table. So it's hardly visible here. If you reason this on a logarithmic scale, it looks like these are bumping up and down like hell, but on a global scale with 1,800 prefixes in total they don't really add up so much.

Going from prefixes to the allocations. Since, in all the previous versions of this talk, I have concentrated on allocations to local registries. But since the other regions have been handing out PI space for a while now, I decided it would be a good thing to actually look at the distribution of non LIR prefixes as well. So what we have here is solid lines like this one. This is the LIR prefixes giving out in a specific region. So this is LIR prefixes in RIPE. This is LIR prefixes in APNIC. LIR prefixes in ARIN land. Interesting enough, the ARIN registries at some point overtook the APNIC people. But the most interesting thing is I think this one, that the non LIR prefixes being assigned by ARIN. So they are reaching a significant fraction of the total prefixes given out by the registries and then there is the other regions and the other stuff down here.

This is also an old acquaintance, this slide. The solid boxing like this one is the number of total prefixes given out to local registries. That's again only provider blocks in a given year. And the dashed runs are the amount of those visible in the routing table next year, year after that, year after that. What you can see is that for almost every single year, about half of the prefixes are just not there in the routing table.

More details about the distribution where all the prefixes are that are not there are in this slide, which is in detail on the web of course.

That's basically it. On the cover page I had the question: Are we growing fast enough? And I think the answer for that is: No we are not growing fast enough. V4 is running out and we are still far away from having v6 in all networks that should have it. Thanks for listening.

(Applause)

CHAIR: So, can my next speaker for ISOC come upfront? In the meantime, of course, the advantage of not growing fast enough is that we have time to discuss this issue at the next meeting. Not necessarily a good thing though, but...

Anyway, if there is any question, I propose this time you take it up with Gert on line or after, right after the meeting, I will make sure he is here and then we go to the next agenda topic, which is on IPv6 survey and IPv6 activities from ISOC. Again, for people who might have come in later, the original plan was already to run a bit later than the official meeting time to explain actually to some people who might not know, because we always have a lot of overlapping in the meetings, I usually prefer to have less meeting slots for our Working Group than more, which means there is less overlap in other meeting sessions but it also means we sometimes end up running a little later and that is, you know the cost of doing that and sometimes you just have to make choices. But anyway, let's start the talk.

SPEAKER: Okay. Thanks David. So, my name is Matt Ford. I am with the Internet Society Standards and Technology Department. And I wanted to share with you in the next 15 minutes, some of the recent activity that the Internet Society have been doing with regard to IPv6 deployment.

I hope that most of you are familiar with the Internet Society. For those of you that aren't or need a refresher, we are a non-profit organisation that really works for the open development and evolution of the Internet for everyone across the world, mainly in the areas of technical standards, education and capacity building and public policy. We have been around since 1992 and we have over, I think it's over 100 now chapters worldwide, over 90 organisation members and nearly 30,000 individual members.

The programmatic work of ISOC has been divided into three strategic initiatives, enabling access which is where a lot of the public policy standards and technology work is going on to provide new resources to get people access to the Internet.

The Internet Works Initiative which I'll talk a bit more about in the next slide. Which is really focused on keeping the Internet an open platform for end to end innovation.

And the trust and identity initiative, which is identifying and promoting activities to resolve some of the persistent issues in that critical area.

So, we think ISOC is unique in, has a unique position with regards to tack link IPv6 deployment, because it's really uninvested. We are not an operator, we are not a vendor. Our focus is just you know the health of the network. We are the organisational home of the IETF and the IAB and other related bodies and that gives us, you know, a tremendous amount of expertise to draw upon either to inform our initiatives or you know, to help us communicate with some of the stint sees that we work in our public policy work for example. Enabling new capacity in the network and technical community in the world deploying IPv6 globally. As I mentioned we take a very active role in come of the key public policy discussions pertaining to the Internet.

So, a bit more about the Internet Works Initiative and its global addressing programme, because that's really the organisational home within ISOC for most of the IPv6 deployment-related work.

The focus is on the continued ability for a globally addressed Internet. And some of the activities that have been taking place as part of that relate to the policy development for IPv4 free pool run out, collecting and disseminating credible information about IPv6 deployment and the transition technologies. Fostering communications between impacted players and I'll say a bit more about that in a later slide because that's key, the idea that we can provide a neutral territory to bring different parts of the constituency together to address some of the outstanding issues with regards to IPv6 deployment to come to consensus about you know, where to focus our efforts and so on.

So, the next few slides just talk about some of the different constituencies that we are working with. Our partners, either you know, organisation members or chapter members can be supported through the community grants programme, examples of that are the recent Irish IPv6 summit support, we have also begin to the Taiwanese chapter in a project to deploy dual stack infrastructure to their educational campuses. And up to 10,000 dollars is available for eligible projects. I have really just picked out some of the more recent highlights that relate to IPv6 specifically. There is lots of other good work going on in other chapters and lots of other awards that have been made as part of that programme. The Australian chapter is particularly active. There is links there where you can get more information.

Working -- so public policy fora that we work in include the OECD. We had quite a big role in the ministerial that took place in sole that year and ISOC has also been instrumental in establishing the Internet Technical Community Advisory Committee, or ITAC I think is the acronym, Internet Advisory Committee for the OECD, which is really a forum to bring members from across the Internet technical community together to advise and help the OECD in its mission. And we were also recently at the ITU, both at their standardisation assembly and more recently at the world telecommunications policy forum, and again they are seeking to emphasise the importance of an open end-to-end platform.

We also collaborate and contribute to events such as the European Commission's recent event on ICT for a global sustainable future and we have also had considerable input to the WSIS and IGF forum as well.

On the subject of education, we work closely with some of the regional network operational groups, contributing to fellowship programmes to help to get operators along to those meetings, helping with other meeting costs, developing and contributing to some of the training programmes that take place at those events as well. A new initiative which I hope you'll hear more about during the course of this year is the regional Internet leaders forums where we are seeking to bring some of the key regional policy makers, the real decision makers in different parts of the world together to, I guess really to try and educate them about the Internet model and the priority for Internet, to help guide them towards you know how they can usefully play a role in their region.

And of course the IETF fellowships which bring technologies from across the developing world to the IETF.

So, ISOC and technologies more generally: So, for many years, ISOC has been the organisational home of the IETF and has you know, performed duties that relate to that. It has grown considerably. One of the areas is the standard and technologies department specifically. This is really to try and I guess convey some sense of what we see doing, or ISOC doing going forward with regards to technology. And so, the intention here is really to show that you know through our links to the IETF and the IAB, etc., you know, we are able to have our sense of what the technical priorities are well informed and then we can seek to push that techology evolution through key messages, and disseminate those either through the public policy for fora, either three educational training programmes etc. And through our links to regions and chapters throughout the world, also collect their perspectives on their use of the network, their issues with the network, their issues with deploying new technologies and that in a circular fashion feeds back into the what the sense of the technical priority should be.

One specific example of activity that we have undertaken recently and that you may have seen some publicity relating to this was the study of our organisation members. We have about a hundred organisation members that support ISOC and support our work. They vary greatly in size and the type of organisation and where they are based geographically and the sort of networks that they operate and we canvassed them towards the end of last year for information about their actual deployment of IPv6. And the results were recently published, so you can find them by following that link, isoc.org/ipv6.

So results, the response vary greatly in terms of what they had this IPv4 allocation to a few addresses to a /8. Most of the allocations reported utilisation of their address space at around 80 percent. The predominant response to the question about what to do when you can't get any more address space is not - well, we'll use IPv6, but unfortunately to use more NAT. But the predominant response to the question about what the advantages of IPv6 are perceived to be is that it has more addresses. So, there is a bit of a paradox there, I think, but my sense of what this is saying is that, you know, yes, people see IPv6 as a way to get more addresses but they don't see it as a solution in the short-term to their addressing problems.

When we asked whether an organisation would be willing to return any of its v4 allocation, almost everyone said rather unsurprisingly that they wouldn't. And the response to questions about specific business drivers were quite vague, but two high runners were that it was needed for product development and also customer demand.

Specific advice for others interested in deploying IPv6 highlighted the need to start now and the lack of skills and experience in working with IPv6. This is a theme that comes up again and again. IPv6 deployment needn't be extremely expensive. It needn't be another Y2K problem but it will be if you leave it till the last minute.

I think this is almost my last slide, and this is really to highlight what I was talking about when I made, when I referred to the sense of ISOC being able to provide neutral territory for discussions to take place to help move some of these issues forward like IPv6 deployment. So, in I think November last year, we held the first IPv6 operator roundtable where we have brought several operators together to discuss operational and technical issues facing those who are in the process of deploying IPv6 for commercial service. Trying to identify common issues that need resolution either by vendors and/or the IETF, and really, our goal is to try and build confidence in IPv6 deployment to show people who are tentative or people who are sort of half-way there, that it can be done, yes there are issues, we understand the issues, we are working on them. You know, help us understand them better.

We are convening another such operator roundtable later on this month in Silicon Valley, and that will also be followed by a summit meeting between operators and content providers to try and bridge some of the gaps between those constituencies, and particularly to understand what content provider expectations of the network are. So not specifically saying you know, what do you think about IPv6? Are you deploying IPv6? But what do you want from the network? Because it's become particularly clear as a result of, for example, the work that came out of our last roundtable and the inputs from that into the most recent IETF on the subject of shared addressing, that you know, some of the shared -- well in fact any shared addressing solution to the shortage of IPv4 addresses is inevitably going to have some impact on many content providers, and I think you know having that discussion, understanding what those impacts are and understanding what, whether contents providers are ready for that and what they would like to see from the network going forward is really a key discussion and a key milestone in getting v6 deployed, at least in the next you know, over the course of the next year.

That was my last slide. So, on the subject of these operator roundtables, I hope this has brought them to your attention and would encourage you -- to date these have been invitation only. I hope that, as the year progresses, you will see useful output coming from these meetings and some of you will, that I'll see some of you at one of them in the future. Okay. Thanks.

(Applause)

CHAIR: I see no questions, correct? Okay. Then we go on to our final agenda topic, and again we will run a little bit late but we'll make sure we can make the bus.

SPEAKER: Well, good to see you at last. I was thinking that my speech would fall off the agenda by now. Basically, there is just two things I really want to share with you. One is hey guys, there is commitment from Government out there to help make this happen. And secondly, for them to know what to do best, they need to know where they can contribute best.

So basically, I think there is agreement here. IPv6 is needed at some point. Otherwise things will stop. And basically obviously we have seen today's growth in terms of users and what may even push to the amount exponentially is if new applications come in which the time IPv6 gets used wider like more mobile and more the environments and things like that.

So, the smooth transition obviously does require understanding the challenges. And that would be what the survey is about.

Why I am standing here is because European Commission contracted TNO and JNKS to carry out deployment monitoring activity. As they see that it's necessary to have IPv6 and an action plan to that. For two main reasons: One is to prepare for the Internet and growth usage and for a future innovation, the two of those. And obviously the political reason, to maintain Europe's competitiveness in that.

So, what can be done? Basically, it's pretty simple. I mean, the commitment is there to support a smooth transition, and there is pure and clear public interest reasons. It's not just power or commercial. There is public interest reasons too. And the transition itself will be driven by us, by you, by providers, by users.

So it's really about how to make sure that we understand the scope of the problem. What are the real bottlenecks? What is keeping us back from really going there, from really introducing IPv6? Is there something beyond the obvious cases at the moment that the want isn't there yet? And what usefully could be done by particularly also governments to help and support the transition, if anything?

So this is where the project comes in and basically, the survey is an important step in that. As a survey -- as they have been already, do help us to understand better what issues are perceived to be and issues that are perceived to be are real issues, and by having similar surveys over time, which for us is a reason also to have ongoing surveys and link as much as possible to those, is at least you see a trend in perception. Well next to that, that's the measuring thing, it would be great to really measure good traffic as we have seen sometime and TNO is preparing for doing measurements that will give us real numbers to put against the perceived numbers.

So, the survey itself is really to really get a comprehensive view of the present penetration and future plans. And by asking.

And I think ARIN pioneered with their survey in March 2008, which they followed up with a more recent survey at the end of 2008, and that was the starting point for us as well in setting it up. It was apparent for us that to put us hey head, close collaboration with RIPE NCC is crucial and to have response from RIPE members for that as input.

It will be kept short and focused on on the sense us only and privacy will be guaranteed. No data will be presented to anybody outside the service team. So that's a guarantee there.

What does it look like? Very shortly, what's the profile, because the response from one responder means something different than from a different one. Ranging from size to ISP or user and there are things also, because it will be good to get an impression of how this develops across Europe, what nation are you from.

And the second session is really about two things: Well either you are considering deployment and basically, the first survey of ARIN to date still gave some numbers of people who weren't. I would expect that number to be very small. But for all others recollect it's really about what motivates you to go to it, what are the hurdles that you experienced or expect? What is your experience? And what are your future plans for further introduction? And to keep the survey simple but effective, we will end that with a request like: Is there any more information you want to share? Is there a reason why we should talk with you? And last but not least: Do you feel this survey is something that needs to be repeated the next year?

So this is just one of the examples. You may have seen the ARIN survey and the outcomes yourself. One of the tables that comes out of the March survey is this hurdles perception according to our members. And you can see why something like this would also help governments to say, hey, where could we make a difference? Where should we help without interfere in the development of the Internet? Which is very much on the distributive way and that has worked so we don't want to disturb there, yet we do want to make sure these kinds of transitions will be made.

So, the proposal I have here for you is to really get involved, and by now we have a full draft questionnaire and I am very willing to share that with those of you who feel they could add and are interested in helping to look at that, to make the questionnaire as effective as possible. The option is not to get it longer and longer. The option is really to get it exactly as well as it can be, and please see me afterwards. Give me your business card and I'll send you the draft survey with the request to respond to me, would ten days be a reasonable period or would you need more? I am open to that. But we would like to air the survey on line, on obviously in the IPv6-enabled site in June and give a couple of weeks for response for that.

The questionnaire itself and obviously the results on an aggregate level will be public as well as will be used for information to the European Commission on their policy preparation.

So, we can't do it without your assistance and please do contact us when anything else arises.

There is a couple of sources you will find if you download the presentation after this, and yeah, I think this is the end of a long and a very interesting day...
Thank you very much.

(Applause)

CHAIR: Thank you very much. Questions:

AUDIENCE SPEAKER: I have one question, my name is Mohsen Souissi from AFNIC. I have -- everybody can claim today to measure IPv6 deployment, penetration somewhere, operators, Internet registries, even very small anti CCing traffic getting to their web servers, etc., etc.. Is there any initiative, whether it is in the RIPE community, in the European Commission, to harmonise all those platforms, tools, etc., to have a common understanding what we are getting measured, is that relevant? Is the methodology acceptable? And afterwards, we may even spread those same uniform tools so that everybody may use them and upload their results and you may have competitive results more than okay, I like to have IPv6 deployed, I have obstacles. I mean, it's a very good job, I encourage you but I think so far we need to have some results. And to be constructive. In last RIPE meeting, we, at AFNIC, presented a tool called DNS Witness, etc. And we'd like to spread it, because there is a uniform methodology for ccTLD or TTLD or just TLD, so they can ask their zone files and get out of their AAAA in the DNS let's say web servers, AM IXs, etc., etc.. This is only one kind of tool. We may have many others.

So, I am really feeling quite frustrated because we don't have any picture, whole picture who is measuring what.

SPEAKER: If you would allow me to take some more time and answer that. Basically, I think you are right. We have seen a lot of numbers in IPv6 over the years, it started with Geoff and now numbers come up from everywhere. That's one thing and there are real numbers there, but how do they hang together? That's not very clear.

Secondly, we have got the surveys, and I do think surveys make a difference. Crucial to surveys, particularly when things are taking off, more and more is to get real numbers this terms of responses, which is why line surveys that are sent out actively to people who are interested and motivated to respond to it are important, and indeed, KC is here, who organised that ARIN survey and we did sit together and what comes up with us is basically, when will this become really a truly global survey? And by being in line and looking at each other, I think we grow towards that. That will help.

Certainly on the measuring of real traffic data, the problem is that it's also very commercial in confidence and some of the global companies would maybe not like to disclose what really is going on there. Yet, there is also a common interest in learning what's really there. So, I guess that's an ongoing battle and all we can do there is measure the best we can, the best users will allow us, and yeah, there is issues there for improvement. I very much agree with you.

But I think now it's really about getting the real numbers of data, sorted data that are comparable. Thank you.

AUDIENCE SPEAKER: Leo Vegoda, ICANN. In the second point on your slide there you mention that the survey would go to RIPE NCC members. Do you mean RIPE NCC members only or would you also include the 15,000-odd organisations that have resources from the RIPE NCC but aren't members?

SPEAKER: Yes. Sorry for not getting this perfect, is RIPE NCC and RIPE, the full RIPE membership.

AUDIENCE SPEAKER: Okay. Thanks.

CHAIR: Thank you. I would like to make a few -- more questions:

AUDIENCE SPEAKER: Martin Levy, Hurricane Electric. So RIPE is not the only and RIPE members and users of RIPE resources by non-members, are not the only people that run networks in Europe. So, does that mean you are going to increase the study and realise that there are other people, whether you have to go to ARIN to get membership lists of people that operate in Europe?

SPEAKER: No. The scope of the study indeed is limited. We do hope to get a pretty good impression, though, and the aim is to get big numbers coming here. Ultimately, I would really like to see it to be a global survey. But, that's not going to happen within the coming two months. Sorry for the disappointment there.

CHAIR: Okay. I would like to make a few final comments also regarding this. You know, we are in operators group, we are a technical forum, but it's also important to make sure that you know, policy makers, decision makers, governments, and all those kinds of -- anything in between basically, needs to be well informed about the challenges that we are going to face in the next few years regarding this IPv4 exhaustion, and I think this is one of those projects that can contribute tremendously there, because it's basically an interface between those two worlds. So, I would very much like to encourage people to approach people from this project and fill out a survey or talk here after the meeting and come here in front and we can talk a bit further about it and that's basically all I think I need to say about this.

This basically brings us to the end of it. This is the final chance for somebody to speak up or this meeting will be closed. The meeting is closed now. Thank you very much.

(Applause)