Archives

Next session at 4 p.m..



SHANE KERR: Welcome everyone to the IPv6 Working Group, my name is Shane Kerr. This is my first time actually being at a RIPE meeting as the co?chair for the v6 Working Group. We have also got Marco and David here as my fellow co?chairs. As I said, we have got a full agenda so I'd like to get started.

So, we are going to start off with the introduction, finalise the agenda. I am not going to read through this. You can see all these online, or on the RIPE meeting page. So we have got a few talks. And we are going to end up today with the policy proposal, and then open microphone. We are the last slot today, so as I said, we are pretty full. It's possible we might run a little bit over. If you have something else to do or need to leave that's okay. You can just leave. We'll try to stick on time as best we can though. So, of course this is our mailing list. The archives are there. This is all available from the normal RIPE doth net page. And then ?? so that's it ?? without any further ado. Unless there is some questions or any other comments before we get started here about our first presentation?

Okay. We'll start off with experiences from an IPv6 only world.



SPEAKER: Good afternoon, I am going to talk about IPv6 only networking, that is turning off IPv4 entirely. And this is work that I have done together with my colleague Jari Arkko who is sitting over there. Some of you may have seen my earlier presentations on this topic. Today mime going to focus on measurements we have done on this environment and around it.

But just very briefly, at the beginning a little motivation on why did we do this first of all? It's ?? we really wanted to go beyond the comfort zone and also we had some customers who were talking about going IPv6 only in their networks and we obviously wanted to find out what that means and so on. So we had several goals. We wanted to understand what works, what does not work. We wanted to understand when can we recommend this particular configuration and when should we recommend something else, dual stack or some of the other deployment models? And we also had a few prototypes and products in the work, so we obviously wanted to test those as well.

What we actually did, we had three sites, sort of one global site, which is just using mobiles. We had part of our lab, nomadic research lab, Ericsson researching in Finland, that was converted to IPv6 only and in my home that were being tested. And the basic set up was very simple, so we built alternate networks for this, sort of experiment, it's really a permanent change, not an experiment, but we built an alternative network that runs IPv6. As our networks had done before but this time we had no IPv4,. And we added NAT64, we added DNS 64 so make sure we can still read the IPv4 Internet. And the outcome was actually quite positive. So I for instance left the v4 Internet six months ago and I have not seen the need to go back. Browsing just works, e?mail just works, many other things just, you know, software updates, streaming, most of the chat systems, things like that, so that's working. There is no real issues. On the handset phone, if you do the mobile thing, I was not all devices support IPv6 to begin with but those that do, or support IPv6 only, they generally tend to work quite well after that. So if it does work in IPv6 only, then everything basically works, all the applications work.

We did have some number of issues of course. Some operating systems have issues. Lack of testing maybe in this particular type of environment. Not many people have done this in the past. Usability on a Mac for instance, if you move between 2004 network and IPv6 only network in then you have to do a manual thing which is of course not nice. Some appliances that I had at home in my home network, they did not support IPv6, that is something that you are likely to see elsewhere. Firewalls had some issues. Even if they supported IPv6, maybe not with a feature parity with with v4. And we had some issues with applications and that may actually be the issue, the biggest problem that we had in this particular test at least. So most applications, everything that I normally use during the day would actually work, but there were some classes of applications which did have problems. And messaging and gaming were the ones we had some issues.

Messaging for instance, anything that run on web, and xMTP just works. A few other things don't work, Skype in particular was a big issue for some of our users, it doesn't work natively at least. We can work around many of these things by setting up proxies and such, but if you just look at the native thing it doesn't work. Gaming, I had my kids do some testing with, by plugging their computers into the v6 only network and having them go through the games that they had, and if it's on the web, they worked very well, if it's not on the web recollect the stand?alone application has a network mode, it's probably going to have some issues.

So that's that. And now to the measurements that we were doing. So just starting from the very basic. First of all, we downloaded the Alexa top most popular websites and wanted to understand which part of that actually has IPv6 in it that is AAAA records. And this, the figure that you see here is a plot of the probability of finding an AAAA, at the very beginning of the plot, you have Google and they have an AAAA so the probability is one, just one. But then further on in the list, it will drop down to something else and overall, over this 1 million, you have about 3% AAAA. However, if you do eliminate Google, YouTube and black spot, you end up with 1% and if you eliminate Google's prefixes and from the answers as well, then you'll find out that, you know, excepting Google it's far less, about 0.4%.

And the conclusion from this of course is that if you going to do IPv6 only, just like that, nothing else, then you are going to have a very limited Internet experience. But NAT 64, if you plug in that that, that helps, then you get to go to the legacy IPv4 Internet as well.

We also looked at failures and the objective here, or this particular test we did TCP dual stack exchange with sites that had dual stack or both v4 and v6, tested IPv4, tested IPv6, and tried to see which one worked and the first observation here was actually that the IPv4 Internet actually works pretty badly. So even on this most popular list of websites you get 1% failure rate. And it could be due to routing, you know, temporary glitches with servers, they went out of business, you know, the police is after them or, you know, if you ever looked at the Alexa list you'll find some interesting content there. It could be that someone is moving around pretty rapidly.

Then we did the same thing with IPv6 and we found out that it's going to generate more errors. So about 2% in this case and the specific numbers may not matter so much. But the sort of difference that, okay, in IPv6 you get a little bit more errors than IPv4 and that's important. In the past we have seen content providers complain that, okay, if you turn on IPv6 on our end, then the end users will have broken IPv6 in their end, and they can't get to us, but it actually works the other way too, that there seems to be some content providers on this top list that we can't really get to and we don't fully understand why that might be the case, broken routing, temporary glitch, you know fire wall misconfiguration, you name it, but it seems to happen.

And then we also did the same thing, so that was for dual stack, or for native IPv4 and IPv6. If you go to the NAT 64 device, then you probably end up seeing roughly the same ratios of errors as did you for IPv4 and IPv6, and that's because IPv6 test goes through, it doesn't go through the NAT 64 at all and IPv4, unless the NAT 64 device somehow miss behaves, then you should see the same error rate words to the destination there as well. There is however one difference that, if you are IPv6 only and your NAT 64 devices are obviously compliant, then you actually always have to do IPv6 if they had an AAAA to begin with. So you can't really have a fallback to IPv4 like applications could have on a regular dual stack situation. Although in some cases that fallback is impractical if it means a long wait in the application code. But that's a difference. It could be done different. I think our device for instance allows a special configuration where you could synthesize records anyway even if you have an AAAA.

That's one thing. The other thing is that there is actually ?? or we used for other reasons we used in one of our networks the very special configuration of NAT 64 where you have IPv6, as normal, IPv6 only on one side, okay. NAT 64 and then IPv4 only on the other side. So you never ask for AAAA. You always translate. And it's really silly because you are now using IPv6 all the way end?to?end. But the thing is that if you only look at this failures, then that's actually a better model, because as noted previously, with IPv6, you are likely to have a little bit more errors than with v4, so here you go back to IPv4 after the device and then it's IPv4 error rate after that.

We also looked at delays. So, here the idea is to compare TCP in sue knack exchange with with v4 and with v6 and what the difference is and this funny figure here on the Y axis you have the difference in the round trip time and it's kind of mirrored for negative values, so on the left side of the figure you have v6 going faster on the right side v4 is going faster and sort of over all impression from this, is they are roughly the same. There is no big difference and that's roughly what we found.

You can look at more details. We had some percentiles here about, you know, cases where IPv6 was going slower than v4. And the difference is really minimal for 90% percentile. It's 2 .5 or 2.6 milliseconds. You can't really detect it I think for most Internet traffic, which is probably far beyond those numbers. But there is one, sort of, at the very end of it, you have a 5% or 10%, that is going quite slowly. Tens of milliseconds more time. And we don't really understand why that's the case. It could be packet drop, just showing up on this graph, or it could be bad IPv6 routing.

And then ?? again, that was dual stack. If you go to NAT 64 and do this IPv6 only thing, what happens then, well the graph moves to the left, and that is because you add this one HOP, and the exact timing here I have note it had down, but it doesn't really matter, what the exact numbers are. It's roughly in the category of adding one router or forwarding a HOP or net 44 HOP or something like that. So it's what you would expect. And that's why it moves to the left, but it's not really a big difference. And the other thing is that this graph here is using the funny configuration that I mentioned previously, where you have IPv4 only on the outside of the NAT 64 and this shows up in this percentile, that the last 5%, the last figure we had tense of milliseconds of variation there are more delay. Here it's very little. Just a couple of milliseconds and that's because you covet of eliminate, by going to v4 you eliminate some of the failures but you also eliminate some of the variation on bad IPv6 routing or due to bad IPv6 routing.

And finally, we looked at IPv4 literal, so IPv4 literal is something that appears on the web, on a web page, HTML code, you have an IPv4 address which is of course not very easy to use in IPv6 only network. And what we did, we downloaded the top sites from the Alexa list and tried to see ?? not just the top page, but everything that is needed to render the top page, which means like probably tense or hundreds of individual files. And try to see if that succeeded if we had IPv4 literals in them. And it's funny that on the sort of of the very top of the list, or the most popular websites, there aren't too many. So I don't know, maybe Google has done a good job, maybe something else, but there aren't any real issues with v4 lit relevance there. Beyond that you get 2%, which is a relatively big number, although I don't really know what the practical effect that have S I have my personal experience which is that in six months of browsing, entirely through this system, I have run into this issue twice, and in those cases it was not too bad either. So, my thinking currently is that that effect is really not a big deal. I could be wrong, maybe other people will have a different experience.

So that's it. And if a few concluding remarks. Hopefully this will give you some thinking about the different configurations or deployment models and how they behave, what kind of error rates, delays and so forth you could expect. And hopefully you can use that information. At least it seems, so that the choice of your, whether you are doing IPv4 only, dual stack, NAT 64, different configurationings of NAT 64, you can have some amount of impact at least on your failure rates words to Internet destinations.

And I think, based on our experience, dual stack is probably still the default deployment, the one that we should recommend for most people, that's the one that is most likely to work with all your applications. But we can also recommend IPv6 only, particularly for early adapters, mobile networks, people who care about the failure rate, if you want to use that particular mode of operation. And of course we hope to improve on this as time goes by. I mean, we are doing certain things to fix you know some phone models and such, how are networks and our devices, but the industry in general needs to do better, so I don't know, you know, if all you go to John on this rosen bearing and tell him to fix Skype perhaps, maybe they will help, maybe not. But we certainly need to improve on certain classes of applications at least and maybe in a year or two we can be here and say yeah, IPv6 only is the best deployment model to choose at that point in time and it has no issues, or less issues than IPv4 Internet for instance.

So with that, that is the end of my talk. I'd be happy to take questions or other comments.

AUDIENCE SPEAKER: We tried IPv6 only on the server side and well, there are some stuff that didn't work and the biggest problem was the DNS. So, we just ?? the domain was only resolvable over IPv6 from the ?? downwards. A lot of people can't resolve it and there is success, which is where you can get the tunnel for IPv6 and they have the stress route application from all of the points of presence and like, 14% can't resolve either. So specifically go the IPv6 way and they can't resolve over IPv6. So I think U yeah, we had the biggest problem there.

SPEAKER: That's interesting. I guess we should dig into the details of why that actually was the case but in general, I think ?? whether it's the client side or the server side, we found that it's very useful to enable this communication between the old and the new Internet, so it's sort of have to build for that. If we had tried to force on our users this idea that you can only go to, I don't know, Google and Facebook, I don't know, maybe half of them would have been happy but the rest of them would have been a little unhappy. So you really have to enable communication from the rest ?? from the old Internet to your systems as well. I don't know if you had that in your plan or...

AUDIENCE SPEAKER: Yes of course, we didn't expect it to work, but well it was kind of funny that it failed at that point.

SPEAKER: Yeah, the DNS definitely has to be looked at.

SHANE KERR: You did all of your traffic through the NAT 64 for this experiment?

SPEAKER: Those that were in the ?? a handful of people, but we did all our traffic and obviously in a particular network like my home network I could not move all of my device there is because some of them were v4 only.

SHANE KERR: I see. Okay. I guess the reason I ask is because since everything ended up translated to the v4 network, we really don't know how much of the traffic was intended for the v4 or the v6 network, right?

SPEAKER: I mean there is different configurations of NAT 64, so you could go v4 only on the outside. Most of our users were actually in this mode where they were going through NAT 64 for their v4 destinations but anything that was on the v6 Internet they would actually go end?to?end IPv6. So ?? and that actually worked quite well for us, but maybe it was because we already were in that mode of operation for like ten years, dual stack running and no problems. So... my company servers, the IETF servers and the RIPE servers and Google and Facebook, what else do you need?

SHANE KERR: I am with you, I agree. Well thank you very much.

(Applause)

SPEAKER: My name is Tore Anderson, I am from a content network in Norway called Redpill Linpro. We are not content provider. We are a content network and it's our customers that are the content providers, so we host their servers and maintain their applications and that's basically it. The customers need to decide whether or not they want to deploy IPv6. So, I was trying to push them words to that. And I contacted two of our most high profile customers, A?pressen and Digitale Medier and asked them did they want to do v6. They were a bit concerned about the broken issue that Google had been talking about. But we didn't really know too much about it, how many users are affected by it, and is this a problem really for us who are only in Norway?

So, we decided to do a test. The test basically includes a hidden i?frame on our customers websites. In that i?frame, which are loaded over IPv4 only from my test server, I link to two small images which are also invisible for the user. One is hosted over a dual stack host name and one over IPv4 only host name. The assumption is with everything else equal, we should see an equal amount of hits to the both PNGs and if not, there is something wrong that is caused by the dual stack itself. So, what I define as broken as our client loss, is the difference in percentage points between successful loads of the dual stack PNG versus the single stack PNG. I am counting hits, not unique users or unique IPv4 addresses. So as you can see in the graph here, I have a 99% success rate words to the IPv4 P N go,, which could be because the user has disabled image loading in his browser or it could be temporary errors of some other kind. But I am seeing only 98 .5% hit rate words to the PNG. So that's where I considered the brokenness.

And we saw, after we set this up, that there was a brokenness of about 0.22, 0.3% with just made it out of the question to go and deploy. And there was some problems that were standing out in the logs as I processed them. I'll be talk ago little bit more about them and we also saw that a large majority of the traffic was transitional IPv6 like Teredo and especially 6to4. That surprised me because there is no reason to use transitional IPv6 to contact a dual stack host. Because at that dual stack host has IPv4 so you can just use that. And the opera was the first problem we tackled and especially when it's running on the Windows system which automatically enabled treat owe and 6to4 if it can. However, Windows is will deprevious transitional IPv6 to make all the other applications prefer native IPv4. However, shipped around, did not know anything about transitional IPv6, so we reached out to them and they fixed it. (Opera) as you can see from the graph, the top line there is the actual measured brokenness and the other one is the brokenness where I first exclude all hits from opera from my data. As you can see, as opera released their fixed version, the actual brokenness soon approached the brokenness without opera, which ?? and by now those two lines are practically overlapping. So, that in very instant and very good effect on the brokenness.

Mac OS X which also has the same problem as Opera in that ?? or did actually, it had the same problem that is did not prefer to use IPv4 over 6to4, Teredo or any kind of transitional IPv6 really but 6to4 is the main problem. Marks OS X does not automatically set up any local 6to4 connectivity. However, it is easily fooled into using it by so?called rogue router advertisements, which are other nodes on the network that are announcing themselves as IPv6 routers to the Mac OS X host. And that will automatically configure up a 6to4 address on the OS X host which it will prefer to use over IPv4. So it talked to them about that. They are actually ?? that was a one way conversation, I told them about this several times and just last week, they release add fixed version that deprevs IPv6 completely if there is a 6to4 prefix present on the system. So not no many of their users have up grated yet but I expect that to help significantly with the brokenness. As you can see this is the same kind of graph as it was in the last slide. When they released just a couple of days ago, you can see that the actual brokenness started dropping while the graph that were excluding OS Xs remained constant. So I am really hoping that the red graph will approach the green one within a month or so. And it won't overlap completely unfortunately, because the fix is only available for Snow Leopard 10.6 version of OS X, while the older two, like 10.4 and 10 .5 don't have available fix other than to disable IPv6 completely.

So, I'll talk a little bit more about the rogue RAs, which are the main problem now which are remaining.

Is that many networks will block 6to4 outright and I know that the first presenter on IPv6 security recommended that people do that. And I can understand, I can simple thighs, I don't.want 6to4 on my network. So I understand you don't want it either. But your users will continue to try to use it, even though they don't know they are doing so. So, I have been talking to some of the networks, asking them if they want to unblock it. Some complied, some said that this is not acceptable according to our security policies. You can't look inside of the 6to4 packet, we can't selectively allow ACT P so we have to block all of it. But most of them, they didn't respond at all so reaching out to those networks is not a scaleable solution to this problem for us. And the rogue RAs, as I said earlier, a system that nounses it self as a router on to a network even though it really is not. It's not the native upstream router that the ISP or the network operator has provision there. And usually this is Internet connection sharing on Windows hosts. If you have a network with blocked 6to4 and one single Windows host with the Internet connection sharing active, all of the Mac OS X hosts on that LAN will break. Because they will try to route their packets to the Windows host, the Windows host will encapsulate them and send them right to the fire wall where it will be dropped. From some these networks I have seen 10% brokenness which is probably the same amount of Mac OS X hosts on the network. There are some work?arounds. You can use RA guard if your equipment supports it. That may not work on all kinds of networks. You can filter the whole hosts multicast address, so that they won't be able to send periodic advertisements, combine with jacking up the rate of advertisements from your router in order to make sure that it will win that competition. You can have a mole kind of solution where you basically look forth rogue RAs and you retransmit them also but all the lifetime set to 0 and there is other things you can do, but none of them are really good solutions to this problem and they might not work on your network.

So this is how a network would look like. You have at the top the Windows host with ICS enabled, Internet connection sharing, that is and as you can see that host itself has no problems because the resolvable library on the host will make sure not to use its own 6to4 connectivity. So the user that are responsible for creating this breakage, he doesn't have any problem yourself, he is usually not aware of what he is doing. And also you can see that the other Windows and Linux hosts etc., will have no problems because also them get a 6to4 address but they won't Professor to use it. While the Mac OS X host, excluding the latest version, will then attempt to use 6to4 and break. And that is precisely content providers are so upset about, because this is a time?out of minutes before a web page with with lots of elements will load, if at all, and the user will probably go elsewhere by the time it has loaded.

So, a little bit more about Windows and ICS. ICS is kind of like to turn your computer into a home gateway type of thing, where you enable ICS on the within an interface of your computer that you want to share the connectivity of to the other interfaces, which then take on the role of a LAN interface. However, Windows, ICS will transmit a router advertisements for its local 6to4 prefix own though the ICS enabled interface isn't even active. So, it's actually not sharing the connectivity provided by the ICS enabled interface because it's not even enabled. It's share ?? it's looping back the 6to4 derived connectivity back on to the same LAN as it got it in the first place which, in my opinion, this has to be a bug. It can't (looping) possibly be by design. So, I have been talking to Microsoft about this, they are looking into it, they told me yesterday in fact. I don't know if they are going to fix it or not, but I hope that maybe some of you, if you know people in Microsoft can push a little bit as well.

If you deploy native IPv6 on your LAN, that will stop Windows 7 from doing this. It will not enable 6to4 on a LAN with native IPv6. But, Windows Vista will not. And you have also lots of home gateways and CPs and so on that enable 6to4 by default. At least I heard from a guy in CISCO that LINX does this because Microsoft has encouraged them to do so. And that's also causing problems because the filtering might happen further out in the network than the CPE.

So, I would have thought, or I honestly believe that if I deployed IPv6 on these networks, that should solve all the problems, because then they can just use the native IPv6 connectivity, right? There is no need to use transitional IPv6 over native IPv6. But, it didn't turn out that well. Because while deploying native IPv6 connectivity will make the other operating systems prefer IPv6 using the native IPv6 source address, they don't really know which gateway to use for their out bound packets. So, the packets might get transmitted to the ICS host anyway and it will not forward them at all. It won't even try. So if ?? even if 6to4 is allowed on that network, you are using the wrong source addresses so it just won't work, and when we did this, deployed a native IPv6 on the university of Oslo student villages which had this problem, the brokenness levels just doubled up into 20%. And we tried also to set the router priority in the RA packets high, which did not help either.

So here is the illustration. The native router and the Windows router, or the rogue router, will compete for being used as the default gateway, while the other users on that LAN will use the native IPv6 addresses, but they will send them to the ICS host which will happily toss this on the floor and you get the time?out issue again.

So, in any case, we found out that we couldn't really get any further with this other than just complain to the vendors, and I agree completely with Lorenzo saying that the vendors need to fix this. It's the only way, the only way to do it. So, I am ?? I know that Mac has fixed, the only thing is left is the older version of the Macs and the Windows with the ICS that I can see, and also the vendors of the CP boxes need to start shipping them with 6to4 off by default. Because, 6to4 is really, really killing us.

Anyway, we tried production test, similar to the one that Lorenzo has announced and Heice already did, we figured out if we couldn't get anyfurther without trying to actually get it out there, just passively observing it didn't really seem to have much more potential at that point. So we tried to deploy. We put out a test site where they could check their own connectivity, get suggestions on how to fix their own connectivity if they were indeed the broken user or were using 6to4 when they shouldn't be using it. And as you can see, on the screen shot of the page there, there is a little warning that basically says "You have broken network connectivity, please go to this site for more information." It turns out they didn't really help that much. And this is still on by the way, even though we are now IPv4 only but it doesn't really have much of an effect. Users are mostly ignoring it, although some get by it but they are mostly ignoring it. And the same with the effect of the test day itself, they were probably, for the most part, suffering in silence. And we also put out an article on the front page of the customers websites saying that we are going to do this, to make sure that we informed them as well as we can that didn't really have much of an effect. But since they weren't complaining, that was the main thing that my customers were worried about, that was complaints. And bad press. And that didn't really happen. And the press we got was mostly positive. Like we were so cool that we are doing this thing. So they are no longer afraid of actually publishing the AAAAs at this point in time but we have decided to, since we are now expecting to see an improvement in the brokenness, thanks to Mac OS X, we will wait until kind of the bulk of the marks OS X 10.6 users have been able to upgrade to 10765 and we see in our logs that we are with down to mostly, or a few 10.6.4 or lower users of Mac OS X, we will deploy T so that's probably before early December, or early December, maybe even next week or something like that.

That also means that I can't really measure brokenness any more because the broken users won't even get to my ?? to the customers I am trying to measure them on. Which means I will have to shut off that system and, I hope that many of you had found it interesting to see that page and, but I think that by now it has done what it was intended to do, if I actually get these customers up and running on v6 within the year. And when I do that, because these customers are large websites in Norway, I get about 5 to 6 million hits on the test site every day, which is large for a small country. I think that anybody else in Norway can also do it, because these are not technical readers. This is mainstream news. So, if they can do it, then anybody can. And I am hoping for a kind of a, what's it called ketchup bottle effect with this.

This is basically a summary of what has been happening. We are starting out at 0.3 and it jumped up to 0.3, I can't remember why. I think it was maybe a broken 6to4 relay that lost its default or something like that. I am not sure. You can see there is a drop where up rise is being fix and also I talked a large mobile broadband provider in Norway, actually the largest, to unblock 6to4 which they didn't really know that they were doing or hadn't really given it any thought, and you can see that it dropped considerably. And also in the summer, it goes down and that is because the brokenness I see mostly in enterprise networks and university networks and so on, when people go on holiday, the student villages, they empty out and the offices empty out and so on, which makes the brokenness drop. So Christmas is a good time for us to deploy because we expect the same effect then.

As you can see we got a little small bump in the test day. It actually went almost down to 0, but this is a smoother graph to is doesn't really show. And then right after the test day we had the university of Oslo deploying IPv6 on their rogue RA problematic network which you can see made the problem worse. The final drop there is OS X 10.6.5. So this was from this morning I generated this graph. And also, there is a comment on Lorenzo's talk about the brokenness being in old operating systems in China and other places that weren't getting patched and I think you were saying, 0 .05 as well, so it shows this this is not a problem that's isolated to the developing world because we get exactly the same numbers in Norway too, and that's a developed country, as far as I am concerned. So...

That's basically it. There is some people that I'd like to thank, especially Steinar from Google who has been helping me a whole hot and of course my customers, all named here, that allowed me to play with their users in this manner. And also the Netalyser team for providing a Java application which I can just tell the broken users that contacted us to go to and we will get lots of useful debugging information from that application, which the user probably isn't able to get for himself, so, that's a very useful if you are trying to debug a user's problem. And last but not least, everybody that actually fixed something in order to help this get better.

So that's all I have. Any questions?

SHANE KERR: I have been following this work for a few months now and I think it's really ?? Shane Kerr again ?? I have been following this work for a few months and it's very cool, I'd like to say thank you for doing this.
(Applause)

MARCO HOGEWONING: Welcome. I am one of the co?chairs of this Working Group for those of you who don't know me. This is a bit about running native IPv6 on a DSL network, a residential DSL network. A bit of who we are.

It's a small Dutch ISP, we are a hundred percent owner of KPN, we are just a local incumbent and we operate the network with about 270 thousand DSL subscribers, mostly residentials and we run IPv6. So, a bit of the history for those who are new here. Please have a look at the archives for RIPE 08 and RIPE 59, it boils down to we started off with closed pilot invite only back in May 2009, deploying native IPv6. After a year we were confident enough that we basically put out a public announcement and asked our sub vibeers to take part in an open pilot and after a few months, and without much complaints coming from our pilot group we made IPv6 a standard offering. So, this was announced in August 26th, roughly three months ago, and the feature is optional. People ask me is it by default? No it's not at the moment. The reason for that it we don't have much experience in support yet and we don't want any surprises. We have seen Tore a shown what happens if you deploy IPv6, all of a sudden brokenness gets up. So we want to make sure that when the customer activates IPv6 he knows that he changed something, if he runs into trouble, he knows that it might be IPv6 doing weird stuff.

Another major thing to make is optimum is that most if not all of the CPE firm wears are still better or in better stage. It's available for all current residential products we have, discovered about 80% of the DSL base, we are working on a business offering. Again this is more of a safety measure. The business lines come with an SLA. We don't know what happens if we turn on IPv6, break our SLAs, we are in trouble, so we hold off that. We toad move legacy projects because we can't secure that network. So for them unfortunately it's not available as a native. These customers can still use other channel servers which we are operating for the last ten years.

One of the design goals of keep it simple. Have the customer go into our service portal, push a button and be done, or maybe flash or replace the modem with something that understands IPv6.

So, this is actually the activation page. There is the button. It says no IPv6 address ?? that's none, and once you push that button, within seconds, it assigns a lash 48 to your line and it's done. After you reboot your modem, and you try to open up IPv6 CP, it will get this prefix assigned via the I S IPv6. So that's for what we are offering. .

Now for the more interesting part. The results:

First of all, the number of activationings per day, and this is only the first month, the graph would have got a bit crowded if I plotted everything. It comes up for a few days which we were testing, then on August 26 and 27, you have the initial spike over press release saying we introduced IPv6. A couple of weeks later we release add company newsletter. It went out in two batches this time, also because people were afraid that IPv6 might draw a bit of too much attention in one go. And again you see every time we do this, you see a little spike. So, every time we make a noise about IPv6, whether it's in a company newsletter, it's a press release, some people will actually go out and push that button. These are the statistics from last Sunday. Over 4,000 people have activated IPv6. That's about 1.5% over install base, which I think is pretty amazing in a few months time since it's still opt?in and IPv6 is not yet known to the greater crowd.

That makes an average of 45 per day. It's slowing down a bit. I think we took care of all the earlier adopters. So the last 30 days it's still 25 a day average. And we don't do any advertising. It's somewhere along the web site, mostly it's press coverage. Every time there is an article in a magazine or in a newspaper about IPv6, we see that number go up again.

Now, these are the people who push the button and activate it, like I said there is more to it because you are actually have to get yourself a working CP. So, if I take a look at how many customers we have online, and this is done by pulling data, life data from the DHP server. Unfortunately it's not an automated process so we don't have all the data points that we get on the first graph. You see it's gradually rising, but it only is about 300. And in fact, this strength continues. So, every time we take a look, every couple of weeks, it's gradually growing and at the moment it says November 24th, and that should be 14th I think, that thanks last week, there were 426 customers live. It gross, but there are a couple of people missing.

If you actually divide the numbers, then we started off back in August with about 50% of the users who activated IPv6 were also actually online, passing traffic, they requested their DHP prefix. It dropped down to 10%. This is fairly strange. This is interesting data because apparently the early adopters, the guys who were there on the first day, put much more effort in getting it working as the one that read the announcement in our newsletter after a week, because it dropped. So, again, what is it with me and November 24th? So, 4048 people activated. 426 were online last Sunday. That's standard 5%. So we have lost three and a half thousands of our brand new IPv6 customers. Lucky for us we didn't receive three and a half thousand support calls.

So, what are the possible causes for this? Well, from what I have heard and talking to people, some of them go out there, push the button, after they have pushed the button, realise that they need a new mode em, or flash the firm wear and they are just too lazy to do it or forget about it. We do supply people with IPv6 capable mode em, but it's only available upon contract renewal. There are people who are still in their first year contract and can't renew the contract just yet. So, that might be another loss. And some firm wears default to 6to4 and that might also be the case. People not recognising 6to4, so they activate IPv6, they go to one of those test websites and it says you have IPv6, because they don't recognise the 6to4 prefix, and it's working for them. But for us, they are invisible. And one of the other major factors, the firm wear for the mode em we supply at the moment is partly broken, it works on v? DSL lines, which run PP T P, over Internet. It doesn't work for ADSL lines which still runs ppp over ATM. Somewhere in the ATM reassembly there's a bug there. The vendor is trying to solve that. That might trigger an extra part of that loss.

So, conclusions for this:

It's pretty clear that the moment you go out there and tell the people they need IPv6, sure the number will go out and get T it's a small percentage, but if you do it and keep repeating it, every time somebody will activate IPv6. But it's also clear they don't want to spend much effort. We have lost three and a half thousand customers and nobody gave us a call. Some did, a handful.

So, they either can't tell whether it's working or not. They think that pushing the button they are done, they have IPv6 connectivity. Or they can't be bothered with fixing it. And another learning point is don't roll based on a bet affirm wear. Things might and probably will break. It's always the question whether the vendor comes up with the right stuff at the right time.

So, possible fixes for this?
Well first of all, make nor noise about world ending. Apparently it works. If we start screaming, people go out and get IPv6. Other things we are thinking of is to actually get them to finish it and get it working, to get some exclusive content somewhere online which is only reachable over IPv6 or for instance, Hurricane Electric example, if you finish their certification programme, by actually showing you have working IPv6 and the whole lot, you get a T?shirt. That might be the trigger for those other 3 thousand people to go out there and fix their stuff.

Talking to vendors, I think it hooks to what Tore a was saying, 6to4 seems like a nice transition mechanism, but all those vendors put it on by default actually break this stuff, the moment you turn on native and there is still a box out had there that runs 6to4 you get into a mess, stuff breaks, you don't know what they are using and clearly people don't recognise it's 6to4. They go out there, they see the dancing turtle, they are IPv6. It's slow, it might break after a week or so, but they have IPv6 and it's not native. And of course push the vendor to actually deliver a working firm wear and a working modem to us and our users.

So this is about it. Any questions?

AUDIENCE SPEAKER: Lorenzo, Google: This is very interesting. I like it that only 10 percent actually managed to get online using IPv6. I suppose you can blame the firm wear for that and their requests for a firm wear upgrade. The question is mostly, ?? and this is great by the way. It's one of the few sort of residential deployments in any scale that I am aware of fully native IPv6. The question is how do you see this scaling from 300 to 300,000? What do you think? Because, fast forward two years, right, this is what we as an industry have to do, right. So how do you see this happening? What are your thoughts?

MARCO HOGEWONING: At the certain point we probably feel confident enough to put it on by default for all the customers. I think that's the biggest trick. As I said, we are now offering v6 capable modems, current life?span of these box Yours sincerely two to three years. So I expect within the next three years to have replaced most of the current install base of the ECP. So if we have that fixed and we are confident enough that we don't break anything, pushing the button and turning this on for the other 250,000 customers, is an option.

AUDIENCE SPEAKER: War of attrition on all CPs and when they all go away it will just happen by itself.

MARCO HOGEWONING: Help for a lot of thunder storms, because a lot of thunder storms we get a lot of broken CPEs.

AUDIENCE SPEAKER: Speaking as one of the 3535 hundred. I had it working and then the rest of the family complained that the telephone had stopped working. So... not every combination of hardware and mode ems and phones and things works.

MARCO HOGEWONING: I might add the better firm wear we use for the images, not only introduced IPv6, but it's a generally better image so they occasionally also fix things on the telephone system, so you have a mode em that does run IPv6 but your voice?over IP system breaks.

AUDIENCE SPEAKER: My mother?in?law couldn't call me any more.

MARCO HOGEWONING: There is a benefit there. There is your scaling. But I think it's mostly a vendor issue. People at home can't do much about T it's pushing your vendor, telling your vendor to fix it and get out there and get, take v6 serious and get a proper firm wear out there.

AUDIENCE SPEAKER: Lorenzo: Interesting question, I think, mostly for the benefit of the floor. How long did it take? You started ?? you took up your pencil and you said I am going to design a v6 network, when was that?

MARCO HOGEWONING: The actual design was in 2008. It did take sometime, because we ?? you want time to test stuff, actually man hours? It was pretty easy. We did, as I showed in previous presentations, one of the issues we had was with lawful intercept by Dutch law we are required to tap into Internet lines, whether they are v4 or v6. We spent quite sometime waiting for that system to get fixed and get v6 ready. But, yeah, that's basically means sitting there waiting for your vendor and that's what takes most of the time.

AUDIENCE SPEAKER: Let me rephrase that question. If someone were in your position and some manager type had fallen upon them and said you must implement v6 in our network today for all our users, how long would it take?

MARCO HOGEWONING: If you were a bunch of cowboys, a week ??

AUDIENCE SPEAKER: No, no, including like waiting for vendors and things.

MARCO HOGEWONING: Anywhere from, my rough is guess three to six months if you want to do a proper job. From other work I have been doing, scanning for v6 capable CPE, which are out there, more and more vendors are putting v6 in their equipment. The biggest problem they have is there is not enough deployment to find all the bugs and that's every time we do this, every time my vendor pushes out a new firm wear, there are only about 4,000 people who may be able to test this. So, you get very little feedback on stuff that breaks. If you get the bigger base, and its much easier and also for the vendor it becomes much more urgent to fix these problems. If he pushes out a firm wear that breaks, for instance, for Hank and three other people, he doesn't consider it an urgent problem. If he pushes out a firm wear that breaks for 200,000 people, he will make sure he considers it an urgent problem.

AUDIENCE SPEAKER: So, basically six months plus baking time. So you are still baking it, right?

MARCO HOGEWONING: Yeah. Mostly or technical infrastructure, the basics are done. What we are lacking for instance, is reverse delegation, that's something we need to fix. We still need to push a lot of services for ourselves for IPv6, but yes, this is still baking recollect it's still waiting for the vendor. When the vendor actually comes out with a production quality firm wear, which has the right default and we are confident enough to ship modems by default to the customer with v6 turned on, and we know when we ship one, so we can actually make a hook in that system to activate IPv6 the moment he gets a new mode em, then it might deploy. But as far as the network is concerned, we are pretty much done. It's all in the CPE and it's all waiting for the vendor.

AUDIENCE SPEAKER: It's all waiting for the vendor.

MARCO HOGEWONING: Again. It's going to be the next monster. Any more questions? Then I think I am done.
(Applause)

SPEAKER: Hello, I am Emile Aben, I work with the RipeNCC, and I am a happy customer for access for all native IPv6. My mother?in?law still calls me.

And I am going to give a talk here about IPv6 and the indicators that we are measuring at the RIPE NCC tracking deployment basically.

Everybody knows this picture. We are going to run out, doomsday. So this is what you all have been doing, get your address space, it's free, start routing T enable it on servers and then provide to to end users. I mean it's a gradual process, or you can take it as gradual process. Take one step at a time. And we were interested in looking at the steps here. Where are people in their steps? And we did a couple of measurements. Also presented at RIPE 60 and I want to do a follow?up on where we are with these.

The first one is IPv6 RIPEness, it's a rating system where you get stars based on a couple of criteria that we actually can measure at the RIPE NCC. The first one is have, as an LIR you have an IPv6 allocation, so, I forgot to mention that this is something that the, measures the LIRs, so this measures the first step, the LIRs getting an IPv6 allocation. So you get one star if you have your address space and you get additional stars for having it visible in the global routing, having a Route?6 object and having reverse DNS set up.

And this is where we are currently. So, it's a rather depressing picture if you ask me. We are still at 70% of the LIRs where we have no indication that they are doing anything with IPv6 really. This is down actually from RIPE 60. There we still had 72%. So, we are improving, but it's not very fast.

So, some stats that we have taken with IPv6 RIPEness is that we made a list of the people that have, that do it right or that have these indicators. We make the list publicly available. We published it today or yesterday. So, this is sort of a carrots and sticks thing. You promote IPv6 a little bit by making the people that do it right or that at least have the indicators to do it right, to make that visible. And you promote IPv6 and also the correctly registering it in our database.

And of course we also have per country stats. That's also nice, so you can start comparing. And Mirjam put this on the mailing list today and we already got a little bit of buzz about something we started thinking about last RIPE meeting which is a fifth star, because the problem here is these are all indicators of people ?? of LIRs doing IPv6, but no traffic is involved at all. So you could have all four of these indicators that I mentioned, and you could still not be exchanging IPv6 traffic or doing IPv6 traffic really. And that's something that we could fix with a fifth star. We had a couple of ideas on that, based on traffic to our website, traffic to the LIR portal, the main concern there is that it has to be fair. I don't think it's fair to ask of an LIR to actively come to our website or actively do something extra to gain this star and to do that periodically just for this system. So that's where we are with that.

But we are certainly going to look into it some more.

RANDY BUSH: Is there a privacy issue in there?

SPEAKER: Which privacy issue. We already ??

RANDY BUSH: Go to your website and all of a sudden it's published I have come to your website and with what protocol.

SPEAKER: Is there a ?? it's for the ?? we are not going to publish IP addresses obviously, but we could at least have our lawyers look at it of course. That's the easy way out. Or the hard way out, depending on how you look at it.

So, second thing is that we looked at is the number of, or the percentage of ASs that actually have IPv6 ?? have announced an IPv6 prefix out of the global routing table. This actually is a spin off of a cooperation with did with the OECD who wanted to know something more about the state of IPv6 per country, so we provided them with some raw data but also thought it would be nice to have people be able to compare countries themselves so we built a little bit more around it, wig the URL I put on this slide here. And we also made it a little nicer than the usual plots that I tend to produce.

So ?? what we are there are country and regional level statistics, so you can see per country if, what percentage of ASs announces an IPv6 prefix, and we do that because at last RIPE meeting, a couple of ?? it was mentioned a couple of times that decision makers really like this type of information and it also allows people to compare themselves to other regions and it's something I learned this morning, that there is actually, from John Quarterman's presenting, there is actually a researcher that looked into this, Leon Festinger, is a name. That doing stuff like this, make people compare, be able to compare themselves to others, makes them do things and, or makes them act on the things they can compare themselves to.

So, the thing looks something like this. And I am going to try to give a live demo because that always ?? there is no problems in trying to do live demos. ...

So,... this is the info graph that we created. What you see here is basically Y axis is percentage of ASs that have an IPv6 prefix. This is the global view that we have and as you can see, we are currently at 7.4 percent of ASs. If you want to compare your own country, for instance, if you want to do Italy, you see Italy is actually doing better than average. So great for Italy. Germans are very thorough is they are probably also doing pretty well, and they actually are, so they are at 19% here, and there are always countries doing better. This orange coloured country, the Netherlands, my own country, is actually at 31% right now. So, as you can see, it's a nice way to look at the data and interact with it a little bit. There is also a permalink so you can share, if you have somebody in a neighbouring country, you can say, ah my IPv6 is bigger than yours and stuff like that.

And the third thing that we started last RIPE meeting is looking at IPv6 traffic for resolvers and end users. This is basically similar to measurements that Google has done, that APNIC has done and that the Tore has done. It was presented at RIPE 60. I won't go into the details of the measurements. And we cooperated with Geoff and George on the details here. It's basically putting a Java script on a website and then have that Java script fetch objects over v4, v6 or a dual stack and we also look at DNS, we do a similar trick where you allow browseers to get to content that is only available if their resolver is v6 capable. Of course this is bias bias by website audience, we are going to measure a techie crowd which will have a higher IPv6 capability.

URL has all the measurements that we have and this is what we see on our network. So the red is the web clients, the preference so, on a dual stack, how many web clients will go ?? will fetch their ?? over IPv6 and we see it over up to 2%, probably others that don't have our base of users will see it slightly less. But the nice thing here is that we have a time series, we are building a time series and we keep building this time series. Last RIPE meeting it was at one?and?a?half and now it's at 2%. So there is some increase. The capability, so that if you offer v6 only, we also see that increasing, so that is the difference between the green and the red is basically due to all the transition technologies that are not used if you offer dual stack, or hopefully not used. We also see an increase in that, but the nice increase is actually in the DNS resolver, so that's the ?? things that are actually in operators infrastructure typically. If you look between ?? or between May, RIPE 60 and now, you see 5 is 5 to sometimes 7, 8 percent, that's actually a nice increase.

If you look at the picture overall, so if you look at LIRs getting their allocations, 28% have, 30% have at this meeting. If you look at IPv6 enabled ASs, 6.2 at the last meeting. 7.3 at this meeting. Resolvers, 5 .5 to 7. Web clients 1.5 to 2 for our techie crowds. So, the question here S are we ready for IPv4 depletion? And next year is going to be an interesting time. And we are going to keep all these measurements up and we are going to keep all these URLs updated, this IPv6 RIPEness list, we plan to update it weekly or even daily so we can, so you can have an up to date view on the state of things, at least for these parameters. And if there is any more things that you would like to see measured, please ask, please ?? or grab me, I'll be here all week. And it's also important to have these measurements because we can act adds a couldn't pit to the organisations like OECD, European Commission, so, we could speak there for you.

So, that's it. Any questions?

AUDIENCE SPEAKER: You still take the suggestions for the fifth star?

SPEAKER: Yes.

AUDIENCE SPEAKER: Mine would be, it must not be scriptable, and I suggest you call the help desk of of RS P asking, I have an IPv6 question and if answer is "Yes, how can I help you" you get the fifth star.

AUDIENCE SPEAKER: Ruidger: You mentioned somewhere, well, okay, this is stuff that decisions takers like to look at, and assuming that any decision takers actually look at this, do we have a disclaimer that this is easily measured external behaviour and of course being IPv6 ready, includes lots of things that usually are not externally visible, and stuff that actually is important at the decision taking level, including things like process rules, we are not allowing to go any new project along if it doesn't come with an explanation how it is going to work with IPv6 or what the transition is.

SPEAKER: We currently don't have that disclaimer, but I think it's a good suggestion to put it on. But it's really hard to actually get data on stuff like that. So...

AUDIENCE SPEAKER: No question, we can not get measurement of that, but actually pointing this out very explicitly.

SPEAKER: We could definitely put a disclaimer on it like that, yes.

AUDIENCE SPEAKER: Lorenzo: So, the 2% figure is ??

SPEAKER: Far higher than yours.

AUDIENCE SPEAKER: About 10 X higher, 10 times. Our number is 0.2%. And ?? so, I mean, they were 0.1% on the 1st Jan, so that there is 100 percent growth there ??

SPEAKER: We also had 100 percent growth so at least the trend is the same.

AUDIENCE SPEAKER: Yes, but if this is something that decision makers see, please put a very, very, very disclaimer saying that the population is highly self selecting and highly, extremely more likely to have IPv6 than average users, sort of the average technical ??

SPEAKER: Yes, actually this was only one ?? we measured five more sites and there we see numbers more close to ?? yeah, far under a percent.

AUDIENCE SPEAKER: Because I am very worried about people saying, and giving the decision makers numbers like 8% when really it's 0.2%, because the hype is well, okay, yeah, it's growing, it's small recollect it's fine. 0.2%, okay, it's nonexistent.

AUDIENCE SPEAKER: Geoff Huston: We have been doing a similar sort of measurements as you are aware, and certainly we do the same self selection, that the folk who constantly use WHOIS tend to have relatively high amounts of v6 capability and, you know, secondly you see the same visitors all the time. So you are actually measuring the same bunch of people. Recently we have got on to a gaming site and 0.2% seems fantastically low, and the real issue here is rather than playing with sort of closed figures, I'd really like the folk who are doing this to openly publish what her saying because realistically it would be good to understand what is truly happening out there and the more data is published on this, the better. A few surprises ??

Of the folk who can do v6, whether they prefer it or not, around 70% are running 6to4 to get to us. And the real message is if you are looking at doing dual stack, whether you like 6to4 or not, putting the reverse relay back and actually routing 2002 /16 back through a local relay helps those folk. There are an awful lot of 6 it 4.

The other thing that surprised me is that firstly there is very, very little Toredo. Secondly, it's really slow. And thirdly, when I put Maredo locally to help them, half of them disappeared on me. Teredo is remarkably strange and I wish I knew what was going on with it and if someone does, tell me because I am really desperate to understand why Teredo is so stuffed.

SHANE KERR: I am going to close the mikes here because we are running a little bit late.

AUDIENCE SPEAKER: Just one little comment. I just checked to see our four star status, and I found we have not got it, but then I had a look further and that's because we are not advertising the EU blocks, because we have EU customers, we are just advertising the US blocks so we have a fully working v6 network that doesn't come under that and therefore I get a sneaky suspicion that there are quite a few others out there.

SPEAKER: We could look at it later.

AUDIENCE SPEAKER: It can't be hard to pin up an aggregate I am sure.

Tore Anderson, in response to Geoff Huston. All of my numbers are available on my sites, if you just go to the site and add / ?? you will get the hit numbers and so on. So, make your own graph if you'd like.

Second, about Teredo, Teredo is basically only done by Windows, by default, and no CPE does it that I am aware of, and Windows ICS doesn't share it out using those RAs either, which means that it's basically only applications running on Windows that will try to use Teredo. And the thing is that Windows implements RFC 3484 which depressed Teredo, so that's why you are not seeing too much Teredo traffic.

GEOFF HUSTON: The test that I am talking about actually ex or sized that bug by actually offering these one by one gifts v6 only. Even if it's deprefed in dual stack, you flush out the capability by saying here is something that only translates with an AAAA and I was hoping to flash Teredo out with exactly that mechanism. That's why I get some rather than none at all.

AUDIENCE SPEAKER: Lorenzo: You just want the raw numbers ?? you just want a graph, because I mean, that wouldn't be too hard to publish? It's mostly a question of what do ?? do we have time to? So a graph would be fine? Okay.

And it will be interesting to see if 6to4 ?? I mean we are basically secretly hoping that 6to4 will just go away, but the jury is still out on that.

(Applause)

I am Freddie Kunzler from Init. Thanks for the opportunity to talk here. I am supposed to talk about native IPv6 on your LNS and so this, as we have showed, I'll skip the marketing slide. Quickly, area we here in this community talking about IPv6? There is basically one reason, because these three elderly men keep continuing it for years and years and years and years. And it happened this these three fellows are actually in the room. And I am apologising for making jokes.

So disclaimer: These slides show how inity 7 implemented native IPv6 on xDSL customers, and it shows how it worked for us, and there is no consideration that this is the only way or it's correct or right, actually there are many ways to roam and as we are in Rome, we can certainly argue this. Also, addressing can be argued, the examples give an indication, there is no guarantee that it will work in your environment, and there are plenty of of different ways to implement it. And just the last note, we are not able to support you on your infrastructure. But we are still are happy to add corrections or comments.

So, the chicken and egg discussion, we had two years ago is gone. Especially in the German market, because www.heise.de is actually v6 capable so there is no excuse any more to put that, or to leave v6 for end users on the pending list.

So, make a move, go ahead, and unfortunately v6 on ethernet blocks, it's easier but unfortunately on L2TP infrastructure or radius infrastructure, it's a lot more difficult.

I make some assumptions before we start implementing v6 for xDSL users. I assume you did your homework, your LIR that you got your /32 or bigger address block from RIPE, that your backbone is ready, dual stack, hopefully. If not, there is a link. You probably cannot read it, but this link refers to my earlier presentations I gave on various occasions. How we implemented v6 in our backbone and it shows some examples how do configure routers and stuff.

So, we also assume that you are a wholesale partner of your local incumbent. And you have a working xDSL aggregation on L2TP, so you have an LNS and this is a Cisco brand. Then these slides are for you.

It shows also a configuration example for a CPE device of Cisco on the very end.

When we decided to implement v6 on xDSL infrastructure, we had a discussion how should we do the addressing. We decided for a /48 for every customer, so, this is how it works for us. I am not going into the discussion whether they should get a /56 or a /52 or a /whatever, so I skip here to the next slide, and we use the existing v4 address scheme to basically give out the /48s for every customer. So we need a /40 v6 for every C class in v4.

So, this is basically how it could be done. Of course the addresses are anonymised with NAT or the documentation prefixes. And I am not going to read all the figures, because we don't have too much time. Basically what we did is we just used the last octet of the v4 address and converted that to HEX and then figured out the net block, so... of the customer.

Here is the second example, I am not going to stay too long on these slides because you can download it for the reference.

Then, we also need point to point link for the so?called within a port of the CPE device, which is actually another /48 we set aside for this purpose

Point to point link addressing is also calculated out of the existing v4 address we assign to the customer. And this example calculates from the third and the fourth octet.

So we come now to the network itself. XDSL aggregation, I mean, this is common practice for several years now in our industry, we have the LNS up here, the aggregation box. We have radius server and then we have delayed to access concentrator which is operated by the incumbent, and last but not least, the CPE device, which is either managed by the ISP or by the end customer.

The good news: You can implement v6 in such an environment without interaction or support from the incumbent's help line. So, you don't need to call them up and they don't tell you IPT v?. And this is really good because otherwise it would take ages until we have v6 deployed in our network. L2TP is completely transparent and this makes it easy to get that done. So you don't need to change any of the inter?connection parameters with your incumbent if you remember back when you implemented this, it actually cost caused a headache and we don't want to go through this again.

There was, as I gave this presentation already at the DeNog two weeks and at SweNog last week, there was a question what version we are using of the Cisco IOS and so this gives an indication. We actually didn't reboot the LNS when we got that implemented, so we didn't update the IOS version. That means that Cisco actually did their job several years ago and it's known to work. It's stable for us. It may or it may not for you.

So, we are going enable v6 on the LNS. I skip quickly through the slides to you still can download is and use the examples later. We address our interfaces. We enabled OSPF and we check connectivity of OSPF, that everything works fine. Then this is probably a bit more important. We enable picks on DHCP or AAA, this says basically every IPv6 peramter which is required by the client should come from the radio server, so we delegate everything to the radio server.

Then we have some virtual template interface, we initiate v6 there.

That's it all right. Almost, actually, we need some redistribution. As the client gets a /48 and the /64 for the point to point link from the radios, we need to let the network know that these client networks actually exist, and there is also a disclaimer here because this is on our pending list to do. We didn't aggregate the client networks yet. So as we have not many clients using v6 actually, today, it wasn't a necessity to get this done, so we, at this time, redistributed the /48s of the clients into the backbone and this is not what we want. So it doesn't scale for more than a couple of dozen customers or clients. But this is not a big task and, so we are going to do that whenever we have time.

Here is an example of the database of the radios. There are actually two additional parameters we have to configure. So it's this attribute Cisco A v? pair, and then you see it, it's not that difficult to do. For your information, we use free free radius as our radius server. I don't have any other experience on other radius releases or versions.

And again the second example, the second example gives /29 v4 to the client. So, this is just option. And you are not supposed to read this now. This is the example I mentioned at the beginning. We have it working with size could he 887 rerouter. Remember going to test any time soon with Dreytek version, whatever I don't know exactly, and ?? so, I probably also want to refer here to Marco's list of known devices because I mean he did all the research on this.

And this concludes my presentation. So any questions?

Am I ?? oh, Martin.

AUDIENCE SPEAKER: I don't have a v6 question per se, believe it or not. When you asked your telecom provider if they supported v6, what did they say?

SPEAKER: We didn't ask. We don't need them.

AUDIENCE SPEAKER: So, are you saying ?? I am leading the question here ?? are you saying you don't need to ask your telecom provider if you want to do v6 on a DSL setup like this?

SPEAKER: No, because it's completely transparent.

AUDIENCE SPEAKER: So third question: What is the average telecom say about v6?

SPEAKER: I don't know. Any comments to answer these questions?

AUDIENCE SPEAKER: The most typical responses that they mistake it for a question about TV and try to sell you a TV bundle.

AUDIENCE SPEAKER: Lorenzo: I am going to ask you the same question that I asked Marco. How do you see this scaling from 12 users to whatever number of users you support?

SPEAKER: I can't answer this, because we are ?? this is not our main focus in our business. So, we don't have the scaling issue. So we have not that many users that ?? yeah, I can't answer this.

MARCO HOGEWONING: Quick response to Martin. Actually, a response from our Telco was. Cool, let us know how it works so we can copy it off.

AUDIENCE SPEAKER: Martin: Are you owned by your Telco?

MARCO HOGEWONING: Yeah.

AUDIENCE SPEAKER: Another response to Martin, actually a clarification on how this stuff works, which is I think different in the European market and the US. The Telco provides the copper and provides a PP O E service which is then switched over L2TP to the ISP, so the layer 3 protocol is usually trance parents. Could you run IP IX or Apple Talk on it longs the Telco hardware isn't too buggey. So there were some interesting bugs with Cisco 10 K killing IPv6 in 2 LTP because of some short cuts. But basically it's transparent for the Telco.

SPEAKER: You probably want to ask your incumbent what kind of lack he is using and to my knowledge they use ??

AUDIENCE SPEAKER: There is an issue with BT in the UK where I understand that they have this bug that Gert was talking about, and they did not want to patch it because they do not support IPv6, so you have difficulty deploying this in the UK, if you use BT as your hot spot provider.

AUDIENCE SPEAKER: Ruidger: I am a core network expert. I am not really very deep into the access network stuff which is beyond an architectural boundary which, well, okay, is nicely dividing me from that kind of trouble. I am quite sure there are some large spots where actually transparent excess is not available.

SPEAKER: Any more questions? Okay. Thank you.

(Applause) okay. Hello. Jan George from Slovenia ?? and this is Sander Steffan. We submitted together the paper or the document with our IPv6 requirements for ICT equipment. I heard that I need to be very quick, so we will skip some stuff.

I will not do the heads up from previous RIPE meeting, what happened in Slovenia about the study and all the stuff. We'll just go to the status of the proposed document.

So, I just put on the table of contents from the document, I am sure you all read that document. And I am going to just say how it all started.

I had a conversation with a representatives of our Government asking them why are you not requiring IPv6 when you buy new equipment in public tenders? And the response was: We would, but we don't know how to request that. They said if you write us a text that specifies what needs to be requested, then maybe we'll include that into public tenders. And I said, well challenge accepted. Thank you.

And then we wrote a document, we took the U R G v6 profile and loosened it a bit, because that profile is brutal basically. This text then went through our Slovenia Working Group, it went through the roundtable at one of our IPv6 sum it's in Slovenia, finally at the previous RIPE meeting I showed this text to Sander Steffan and through Google translate, basically. And there was a rough consensus that this is the paper that needs to be translated into English and submitted to RIPE community and to IPv6 Working Group, to see if this is really needed. So this paper is now in draft stage and if we get some consensus at the next last call, we may publish it as a recommendation.

So I will just briefly go through. We have three options here in this document. First option is list of required RFCs. That needs to be deployed in the hardware. We split it, the requests in four different types of hardware. First is for host. For the old list you need to go to ripe.net at the document store and it's under drafts currently.

So, we have the mandatory part of RFCs and the optional part of RFCs. The next one is consumer grade layer 2 witch equipment. This is fairly short one. And then we have the requirements for enter rise ISP grade layer 2 switch equipment. And all RFCs that we think are there. And as the last one we have requirements for router or layer 3 switch equipment. These requirements are different from any other one before. And we also have the network security equipment. This means firewalls and other T PI equipment. And we also wrote some words for IPv6 support in software. Basically, what we wrote is user must not note the difference and software needs to support v6. That's it basically. What we wanted to add is skill requirements of the system integrate err. This means if you do the tender, if you buy equipment, you need an integrate err that can implement this equipment in your network and that he knows about v6. Just buying the boxes is usually not enough. And this just skill requirements, that their employees need to be properly trained, they need to know stuff about IPv6 and so on, and there is a small declaration that system integrate err can sign or the tender initiator can make the system integrate err to sign, and it says that under criminal and material responsibility, they declare they have the knowledge to implement v6 equipment in the network.

So, the next option, we thought of using some mechanisms that are already established. Good or bad, I will not go into that argument. There is IPv6 ready logo certification. They they set some standards for certification and we can ask, as an option in the tenders, about equipment having a v6 logo badge on it.

We wrote the proposed text for the tender initiator, you can just copy and paste it to your tender. And then we were requested to do the third option, because requiring only v6 ready logo is something that the Government can't do, because not all equipment has been put through this certification. So the third option is: Mix of option 1 and option 2. Saying very simply, well, if your equipment has been put through the picks ready logo certification, and it has a logo, it's good to go. Otherwise, you need to prove that you support all the RFCs from the option 1. So, this is ?? I suppose, this will be most used option for the tenders.

And this paper has gone through a long process of reviews. Some of the people that reviewed these documents are sitting also in this room. Thank you all you guys, you know who you are. And the current status:

There was ?? there were two consecutive versions of the draft. There was some response from the community. We added things that should be done. And the last call ends tomorrow. That's Wednesday, tomorrow. We had do the editorial tomorrow. We have more MPLS to add. That was the last comment from our slow convenient yen folio. And the chairs will decide if this is the new last call. I am just asking here, you guys think this is useful, we need this as a recommendation or not?

AUDIENCE SPEAKER: David Kessens, one of the IPv6 could he chairs. Tomorrow we will no better what all the comments are and we will sort how things look like. I suspect, based on what I have seen so far, that we will end up doing an additional brief, last call on the few set of changes that are suggested, especially the MPLS changes and then be done. That's the current status and the current thinking of the IPv6 co?chairs. And of course we'll see tomorrow, maybe more comments will come in and we'll have to do something else.

SPEAKER: Thank you. I would also like Sander to say a few words about how he felt about this.

SANDER STEFFANN: I think Jan has also said the most important stuff, so I'll keep this very short. I hear from a lot of organisations that want to do some v6 but you don't know what to ask for that there is a real need for something like this. And what I really like is that it's very clear what a device should support. It requires a support requirement that v6 should not perform so much less than a v4 performance. It includes a piece of, about the knowledge and the skills of the integrate err. So, I really think that this is a good way to request, to require v6 support. And I would recommend everybody to use this where possible, so there is one standardised way of requesting v6.

Thank you, are there any ??

AUDIENCE SPEAKER: Constance from German Government, EU dot Government is our LIR name and I agree with you, we don't have, in the governmental part, not so much experiences, so we appreciate and support your requirements because we are seeing that the vendors don't offer this stuff we need in governments and we don't know what we need in Government, and so we need some suggestions, requirements in this case. We have some comments to improve this requirement and the first is more details than an RFC level. We suggest a matrix would be helpful which matches legal requirements and policies on EU levels. And one question for the ??

AUDIENCE SPEAKER: A brief interruption. Maybe if you are going to do editorial stuff, we are very short of time. So we might be better off doing that on the mailing list or after the session come up and talk to the guys, if there is something very important you want to have discussed here, please do so.

AUDIENCE SPEAKER: One thing, we support this very much and we think it's necessary to have. Thank you.

SANDER STEFFANN: Thank you very much. I appreciate your input. At this point I would like to get this through the process as quickly as possible and maybe we can do all the more detail and everything in a second version, would that be okay? Thank you.

This document, even after it will be published, it can be modified, sofurther process can go on and we can go into more details and things like this. Thanks. Any other questions or any other governments to support this? Thanks.

MARCO HOGEWONING: Trust me I will be quick.
This is a bit about a policy proposal I have pushed. Remco and I published a policy proposal. It's about registration requirements for IPv6 end user assignments. It's been out for a while on the mailing list and has gone through the first discussion phase. This is about why we are doing it and what we are going to fix. The current situation is there is no need to register any end user assignments. Not unless they are bigger than 848, the same section does require you to keep track of your assignments in your own database
Without actually specifiying what that database should look like or giving a proper definition of a database. It could be a text file or some big oracle server. It also states that it has to be accessible by the RIR upon additional allocation requests and audit to calculate the HD ratio. Again the text doesn't say anything about how that access should be done, whether it's website or interface or should send them a dump of the database. You simply don't know.

So, this is leading to an enormous amount of questions. I think it's one of the top five questions asked like, what does this mean? How does this database look? What data should it contain? It may also lead to a lot of problems. Pause if somebody actually comes to that point where you just gives RIPE access to some really awkward database system, and good luck, that might lead to a lot of discussions with host masters and stuff.

And additionalcations, a lot of people think /32 is so big, but keep in mind that there are a hot of organisations, big organisations that are now holding onto the /32 which they got years and years ago for expermanenting, by the time they deploy, they probably need more space. There are two ways to do it: Clean up your old existing allocation. Give it back. And then request a proper one based on your current customer volume. Or, grow the current one. And basically do an additional allocation request which leads to the point where they ask where is the database?

So, as a sidestep, the way it's currently solved in IPv4, it's a lot different because you normally don't register individual end user assignments, you don't go out and push out /32s, what you do is you put in a /22 and actually in the remark say this is a broad band network, and it becomes implicit that ever customer gets one address out of this /22. And well it's not in the policy, it's somewhere hidden on the RIPE website. When you have more than a /20 assigned for broadband usage, when it comes to additional assignments or allocations or audit, the RIPE NCC asks you to provide you stacks on those blocks. It be ooze MRTG graph of your T L CP pool showing how much addresses are in use. It's a straightforward solution. It's been around for years. Most broadband operators in this room should probably be aware of this, and know this procedure.

So our basic proposal is to copy this off to IPv6. So, register one big INET 6 numb containing all the end users assignments together. Now the biggest problem there is doesn't necessarily becomes implicit what your assignment size is, so we need an attribute that states in this block, it holds end user assignments and each user will get 56, 52, 48. That's why it becomes clear what you are doing. So the solution is to introduce a new status. Suggested name at this point after some discussion is: Aggregated by LIR. It kind of matches the current semantics and it actually tells what it does; it's an aggregation point.
Introduce a new optional attribute for the Inet6num called assignment size and with some business rules, make sure that when you set the status to aggregate it by LIR, business rules of the database will actually require the assignment size of attributes to be there.

So, to make it more visible, this is something as it should look like, this is one of the blocks, so you can say this, 46 Tore v6 residential users, assignment size is 48 and it says aggregated by LIR. This way, you can actually indicate what you are doing. And you can provide statistics similar to IPv4. So, if you later on, show the NCC, saying this block contains 50ey net numb customers, they can do the, work it out and they can calculate the ratio. There is no longer ambiguity or discussion on what data should be there, data form as, accessibility. It's pretty straightforward.

More benefits: Of course, everybody, who is big enough, over 100, 2000 customers probably is aware of the current v4 system and probably has something in place already to show this to the NCC, and when you are fully deployed dual stack, it maps one on one recollect the v4 customer is also a v6 customer.
Another slight benefit is completely not relevant for this proposal, in essence, but it provides for statistics to the community. At the moment, you only can tell somebody has an allocation. You can't see what they are doing with it. The moment people are starting to register assignments, you can actually see who is using it and who is actually deploying IPv6 and at what rate. You can actually see the assignments going over time and in fact as it came up during lunch, it may as well be the fifth star of the RIPEness project, based on the number of assignments.

It can also aggregate in irrigation for other purposes, for instance how to black hole a specific customer. You can look up the block and you can find that the customers has a 56 so you can immediately take action upon that same /56 instead of waiting other /64s to prop up. Also for geolocation, you immediately know which customer, it's one specific customer. This basically in essence what the proposal is about. I must add that something that came up during the mailing list discussion, it's a registration requirement. It doesn't change anything on the assignment policy itself. So you don't have to go to host masters and ask can I assign stuff? It's still, as long as you don't assign over a /48 per customer, you can just put it in. It's just a requirement to, if you do that, to register something in the database.

That's it. It says end of show here. So...

Any questions? Oh, and as clarification, as I am one of the proposers, I am not doing any of the regular chair processing on this. I'll leave the show to David and Shane to make all the decisions whether to push this forward or what happens with the proposal.

WILFRED: Two previous questions. The first one would be you mentioned the statistics stuff to be carried over from IPv4, do you really think that there is a point in doing that for IPv6? I am referring to the sort of dynamic stuff things like what's the percentage of the usage of the block of addresses compared to the number of consumers or end points? My personal feeling is that we should actually do away with that craziness for IPv6, because the majority of those address blocks will be used in a 24 by 7 by 365 environments anyway and there is no real shortage.

MARCO HOGEWONING: But at a certain point you have to calculate HD ratios, so, yeah, one might say that once it's in the database, it's considered assigned and no statistics. But..., yeah, it can be done. I think it's implementation. Like I said, in v4 land, the statistics stuff isn't in the policy. It's just you have to show that you are using the addresses. So, that's why we thought of copying it off. But if there is consensus that there is no need to actually prove that you are using it, then... WILFRED: I am referring to this dynamics component for the DSL addresses and that sort of things. I have to admit I have still to read up on all the discussions with regard to that particular policy. So this might already have been discussed.

MARCO HOGEWONING: On the v4 part, it specifically states broadband user, so I think it's implicit that those are 24/7. It's actually, you can't assign 2000 addresses when you only have 5 hundred customers. Well you can but then you can't ask for another assignment. That makes sense and I think at the same point that's Y HD ratio is there, if you run out of your /32 allocation it makes sense to have some kind of system to show that you are actually using the addresses instead of simply stating I want a 28, because in that case we can just decide here that everybody gets 28.

WILFRED: And the second command is that I am currently working on an address plan for one of our bigers customers. An it looks like we will not use the same size for all the end points. We will probably try to define three groups, three sized groups. So I would like to see either a mechanism to sort of document that stuff within the framework of this proposal ??

MARCO HOGEWONING: In the proposal text, I have to say, we finished editing it this afternoon. It should come out, we are waiting for the NCC to do an impact analysis. Then it will pushed out to the mailing list again. In the current draft version, it states that you can nest these objects, but only up to one level. So prevent people from actually going into the /128 level, but you can, for instance, say these are all /48s and this specific 48 will be split up in 64s again.

AUDIENCE SPEAKER: Wilifred. Thank you.

AUDIENCE SPEAKER: David Kessens, one of the co?chairs, as Marco already mentioned, the chairs have been discussing and will be dealing with this policy proposal, but Marco is not involved in those discussions because he is one of the proposers. The current status of this proposal, just to repeat is that a discussion phase has been finished. The document has been updated. And it's going to be published soon. The thing that we are still waiting for is the impact analysis from the RIPE NCC. As soon as that's out, we will go to a review phase and the chairs are most likely to choose a minimum amount of time because this proposal has been discussed already quite a bit. And it doesn't seem to be extremely controversial at this point. So we are most likely going to go for a two week review phase and after that there is still a last call, so we are not even close to done yet, but this is to give you a status update, how far we are in the policy process.

MARCO HOGEWONING: And this is a, well a hidden multiple Working Group Chairs, I would like the chairs to issue the last call also to the Database Working Group and address policy as it concerns them both.
(Applause)

SHANE KERR: All right. That was our last presentation discussion. So, in principle, we have an open microphone now. We are already over time. I have nothing more important to do than to be here though, so if anyone has anything to say, please come on up.

MARCO HOGEWONING: Again, this is, if you want to reach us, there is the mailing list and well this one speaks for itself.

RANDY BUSH: For those of us who have been around this Working Group for a little while, I just think it's worth thinking back of the change and the state we are in today and even though we don't see, you know, 80% deployment, things have changed in the last two years. And changed for the better. And it's pretty clear v6 is going to roll out one year ago I thought the world very likely could be Nats, now it's just some nut Telcos who are wining about having to pay the cost for their inaction for the last decade. Marco, your presentation was wonderful. We need to clone you.
(Applause)

SHANE KERR: I can't follow that up. So good night everyone.

LIVE CAPTIONING BY MARY McKEON RPR

DOYLE COURT REPORTERS LTD, DUBLIN, IRELAND.

WWW.DCR.IE