Thursday-Amal-9AM
Thursday, 30 October 2008 9:00
Database WG, IPv6 WG
The database session commenced as�follows on the 30th of October, 2008:
Nigel Titley: Right. Shall we make a start as it's five past? Welcome to the Database Working Group, we are back to the zombie slot, Friday morning after the RIPE dinner. I will do a quick runthrough the agenda. Welcome everybody. Thank you for waking up, turning up. Wilfried sends his regards, he is not here, he didn't tell me me why but he said he couldn't manage it.
I gather we have a slide� not a slide; a describe from the RIPE NCC, thank you. We also have a Jabber monitor as well. Microphone etiquette if, you want to speak to the microphone, please give us your name and your affiliation. This isn't so much for the people in the room as for the webcast. If anybody is up and looking at the cast of course. We need to approve the minutes from RIPE 56. These were posted to the mailing list rather later than usual I am afraid, it was last week, but if everybody has had a chance to look at them and has anybody got any problems with them? Anybody awake? OK. People are awake, that is good. But nobody has any problems with the minutes, so we will approve them. And get them published properly on the website.
Next item is review of the action list and we will do that in just a minute. Rest of the agenda well, we have a database update from Jos Boumans, then we have a report from the data Protection Task Force, I don't see� he is here, that is fine. And finally Denis� not finally, Denis is giving us a quick run through on database mirroring which relates somewhat to the previous item.
Then we have got input from other working groups, ASPLAIN, yet more discussion about the dot and Peter is going to do us a little bit on DNS and some items that have come up as part of the applying maintainer objects to everything in the database and finally, AOB and then we will break for coffee.
So, first item is action list and if� can we do the action list. I probably should have put the two presentations together, but never mind.
AUDIENCE: Jos Boumans RIPE NCC all the action points should be addressed in my update presentation so I suggest we do them there. If I miss any let me know.
Jos Boumans:
SPEAKER: Far it be from me to suggest a member of the right NCC should use ROSIE.
Jos Boumans: Good morning and sorry for that small delay. I am Jos Boumans database manager of the NCC. Good morning to all. Wave few things to do today one of the introduction is database group, I think you know most of us we have some new faces, we will go through our projects that we are running and the action point list and we will have an operation update for you as well to see whois among others are doing. There will be time for questions at the end, please save them towards the end and come to the microphone. There is a few things we are specifically not doing. We do know about the DPTF update which what effect us. There is DNS issues that came up and which Peter will do and more about the.as you say.
So the database group, we have had one new face, Meno, our old engineer went to a different department in the NCC and Menno joined us a few months ago. To give you a bit of idea: That is group of all the stakeholders we try to please, database department. We get input from all orange clouds which is internal departments and I think you will recognise many of the RIPE groups as� the major ones and� sorry data Protection Task Force as well.
So what has kept us busy? One of the big action points, dating back to Talin if I am not mistaken is MNT BY on all of our objects and we split that out into two: All objects should be maintained and we started out with all forward and reverse domain objects. For the forward domain objects we used the maintainer of the TLD if there wasn't one yet that was associated with it. For the reverse one, we used the maintainer of the INET num N total almost 50,000 objects were motified this way, and which is actually quite a few as you can see. We coordinate this had quite well with the DNS Working Group and we have done this silently at the 10th of October to avoid any possible hijacking. If he would have announce that had there was 50,000 objects unmaintained in the database up for grabs bad things may have happened. We have publicly announced it ever since afterwards and there is a little link in the presentation later if you wish to read it.
What is still out is the mandatory Internet by of person /role objects. All of these objects will have mandatory maintainers as well. We expect to deploy that one in December this year. This one was a little bit more complicated than the domain objects because it introduced a Catch 22. As you can see on the right hand side on the picture every personal object must reference a maintainer and that a person. If you don't have one you can't make the other. The traditional way of creating objects wouldn't allow for this so we have introduce add web form which is now available to users to boot strap themselves if they do not have any objects in the database yet. If do you already have objects you won't need this and it will look roughly something like this. We will ask you for the minimum mandatory data, and we will auto generate to objects for you one person and one maintainer and then you can use web updates or sync or whatever traditional to change them. This is a prototype this is roughly what it's going to look like.
Peter, where are you? This is your slide. Action point 54.7 it's the deprecation of the ref serve attribute. We were requested to clean up all the INET and 6 num objects, the downside there is a database scheme at change required for that. It was deemed not to be of high urgency even though still of importance, of course, so even though updates would be unavailable during the change we figured the best time to do this is when we have to do the other update that forces us to stop the database which is the MNT BY personal, so it will be released at the same time which is December this year and as you can see from the graph it's only 4 percent of objects that are affected currently. (MNT BY) another action point from Talin was the request to clean up unreferenced objects. We are currently defining unreferenced as person or maintainer who are not linked to anything else but these two objects. In the future we expand to thank to anyone who is not linked to to any operational updates so if you have a person update he were who has a Limerick object you are considered to be unreferenced. We have started to run this in monitoring mode and we found when we checked all personal objects daily and we said we would flag them after three weeks to be ready for deletion that we find about 25 percent of our current data is said to be unreferenced, so in the end he will be cleaning up 25 percent of our personal data that shouldn't be there.
As I said we are currently running in monitoring mode so we have a fair idea of the numbers. 200 to 250 unreferenced new personal objects a day and we see if some of them persist until three weeks after that date they would be flagged for deletion. So we will start in late November actually deleting objects. We will start slowly with about 100 deletes to day to make sure if anything comes up operationly we have an a chance to stop it, slow it down or address it. If you are one of the people who has what we call an unreferenced personal object or if you know someone who does please point them at the white pages, there will be a little bit more on the next slide. The white pages was an initiative specifically requested by the community to address this problem. And if you are particularly interested in how we are dealing with the deletion our project DBConstat shows that and many more things.
About the white pages: We deployed this shortly after RIPE 56 and that is way for people of involvement in the community but perhaps without operational data to be in the database and recognised as such. There is one specific organisation object which is called the RIPE community and it's maintained by all the Working Group chairs and anybody who is in or linked to this organisation object is exempt from any cleanup. If you follow the link you will see the way that you can subscribed to this organisation object and the Working Group chairs are undoubtedly very happy to have you.
I won't talk too much about the dot versus the plain notation since we have a bit more that have later from the other working groups, the difference I think is quite clear to most people and IESG has approved ASPLAIN as a proposed standard now. Operationly this means AS.will have to be transformed to ASPLAIN, we expect the final decision in late November so quite soon already but the one thing we do know we will follow any standard that has been decided upon and of course, we will keep you informed of our progress during the normal ways.
That is all, actually, I have for action points. Nigel, did I miss any? I missed 55.1, which is
Nigel: 55.1 add a feature to the LIR Portalal collation editor to include the I IR main attribute.
SPEAKER: OK. We did discuss this one last time in Berlin and it was said at that point that would be a useful feature to the LIR Portal and it would be considered in the rewrites since it was currently functionally unable to do so.
Nigel: Yes but the action point is ongoing
SPEAKER: In that case the action point is ongoing, yes.
Nigel: OK. That is fine. That is it. Yes.
SPEAKER: Lovely. Except for community projects we are also working on some resilience and stability improvement projects. One is SQL cluster which we are particularly proud of. Currently the RIPE database resides on one SIG server, obviously it's redundant many, many ways we can but it's still a single point of failure and unfortunately something we experienced just this RIPE meeting when one of our co locations Decaf last some power. The downside is that if we would lose this machine, we can't rebuild it quite quickly and we will have a service adage for updates� outage for updates and in the absolute worse case which never happens, we may /HAO lose all data after the last back up this is not something we want to do. Two objects: Make sure we do not have any data loss in any case. And the secondary one is to improve the resilience so we can be available as much as we can so you can do updates whenever you should. To show a bit of background on growth speed: This is what it's been looking over the last few times in projections for growth, currently increasing by .5 percent a year, not very much luckily. And our predictions look quite accurate until 2011 which means we are looking at a database size of about 23 gigabytes at that point which means this size will not be an issue. Here is what we have done: Instead of having the machine there is a cluster there, it's the bit highlighted in yellow. The up date path as you fellow the green /AR are working as usual except ending up at one machine may may be called DB whois one, replicated master replicated to all other machines. Now if you are actually quite interested in SQL cluster we have done a bit of research to make it more stable and robust and our dBA is in the room sitting at the front who is happy to answer any questions you would have about it. And I think you will see a little bit of time what kind of benefits we have been getting from this. Also notice that the blue line, the query path is exactly identical for everyone, still, so for user nothing changes except you get a more reliable and resilient service.
So deployment is scheduled towards the end of the year so you will see a little message from us we are putting the SQL in production. There is a small outage when we migrate from one machine to cluster so be aware it's coming up. We will most likely do this over the weekend to not impact daily business too much. On the front end we have also been changing our set up again to increase reliability and availability / FPT our current hardware is end of life for this cluster which is always a good moment to make these changes and we have noticed the whois load is growing rapidly. You will see in the operational update we have grown about 250 or 300 percent offer the last 12 to 18 months. That mean we needed a new setup, one could scale more easily. It's not only load balanced but redundant in many, many ways, we have quite a bit of experience in running services behind that. The running in test phase now at new whois.ripe.net. Try it out, let us know if something doesn't work as expected and deintend to deploy those in late November, without any outage shifting over an IP address from one set to another. Another important bit for this cluster it sets us up for the whois v4 next generation and if you looked at the picture before it's the top bit where specifically the load balancer is the quite new item and which is allows to us scale horizontally quite well. Another added benefit is you see one update arrow going to one machine but we can switch that over quite quickly so that goes away any of the other machines can take over it's task because we have a cluster at the back end and because they are all similar now.
Last RIPE meeting, we have asked you for a code freeze for who is v3. We consider the code to be stable, but hard to extend. And we have learned a lot over the last couple of years but knew features we need, bottle next in the current v3 code and requests from the community. And to be able to serve them properly we said this is the time we should not try to extend version 3 any longer; we should look at a new version, version 4. We promised at the RIPE meeting we would do some initial investigation and tell you where we think we should be going in regards of the issues that we have identified. And the first one is, information over data. We find that in many cases, when we look at queries, many people do two or three queries, rapidly in a row, slightly different. Meaning they get their� partial answer from the first query, grab a chunk of that answer, issue a second query and possibly grab another chunk of the second answer to issue a third query, effectively meaning they have to ask three questions to answer one. So we think we should make it easy for people to ask specific questions: Who is the abuse contact for this resource, where is this IP address located or could you tell me that this object is actually valid? This means we are looking much more at APIs than plain whois flags. Another request we found multiple views would have a good thing to have even though the routing policy specification language is is a good way to represent objects. But not for machines and a lot of the processing we are doing nowadays is automated so you may want to have the same data represented in a format that your machine is much more easily to deal with, we are thinking about XML RPC if, RPSL is needed we will provide it. I think our friends from the anti abuse will be happy to hear focus on data quality, in the operational sense but also in provided data and we are thinking about e mail address validation to make sure e mail address that is specified is one that works and this is specifically important for abuse contact data which we want to be up to date not only for a registration perspective but also from an operational perspective. So here is some fundamental concepts we are thinking about that are slightly different from the way things work now: Thinking of levels of access control. Right now we have one level of access control which is the amount of queries a SIG IP address can do. For different reasons, we want to disallow anonymous access to personal data, both from a data protection issue, this is important, we should not give away personal data to just anyone, but also, for those people who provide us with the data, it's important to know for them that it's only given to those people who should have it. This means it will set up an axis matrix for different user types, members should be able to see members' type whereas anonymous users should only be able to see operational data. Slightly more contentious one we would like to migrate away from e mail updates. As you will see later on in operational update, we actually get more spam than actual updates, and this is the not very spammy spam that has already been stopped by our spam filters; the bits that look fairly like a real message are still getting through as they should, and even there a majority is spam. The second problem with e mail updates is mime encoding. The largest cause of failed updates that should have succeeded is issues with miming coding. Not all clients do it proper and they are not all cases can we reconstruct the object as it should have been. This is double important if you have signed it with a PGPKEY which means if we can't reconstruct the object exactly as it was your signature is invalid and for all intents and purposes you send us a valid one but we cannot process it. There is a lot of spam and virus processing overhead. The MIME processing is error prone. We see there is a need for asynchronous updates, the possibility to give me and say let me know when you have done it I don't want to wait for T the output you have received from e mail is something we can keep on doing without needing to support MIME any more so the output work flee can stay exactly the same. Of course we will provide ashone Ron us updates and the last point and I think it's a very important one especially with the amount of German, French and Russian data in our database is uni code compliance. Currently, we hand out exactly what we received in, whatever encoding that is. Which may or may not work for you. And I think it would be much better if we are compliant with the standards.
Our project approach is that we would like to deal with the infrastructure before the implementation. We are not discussing any specific feature set here; we are discussing things that we think are essential in a framework to be able to support the features you may ask for, like, for example, asynchronous updates which may be implemented in various different ways but we should have a possibility to do so. We also feel very strongly about doing iterative development, add features if and when necessary. We would not like to go away for two years and present a big bang implementation of whois v4. So it will abslow migration away from version 3. And a slow introduction of v4. Here is the graph that we use internal three represent our server layout. It has many different colours, we will go through the colours in an easy way. The SQL cluster is here in the bottom right hand. There is a virtual cluster goes with it so if we want to make any changes we know they work before apply them to live. The new whois cluster is standing right in front of it and on the left hand side is the infrastructure for v4. The green ones have been deployed, the orange ones are new. This is the server hardware that will be standing in front of whois v4. � sorry, v3. We will handle anything anywaytively that we can, anything that we cannot we will pass back to whois v3 and we will form it back using v4. The second set of machines there is our prototype machines. This is what will adough us do the development. The idea is when we come up with new features, when we are asked new features we will deploy them on our prototype machines for the community to test and approve, if we like them rolled forward to production if not scrapped and we will keep on going. So where do we go from here for whois v4? First of all, the approach doesn't require a big bang so we can keep doing interactive discussions on features like we have been doing. We have can do live prototypes so you shouldn't be afraid to propose something to try out. We don't need a big consensus we can see how it works in real life and roll forward and back, in fact there will be a big change in the end it will be business as usual while we develop it.
Now for the numbers side of the presentation. When you contact the RIPE NCC for help on the database, you contact the nice folks at RIPE DBM. There are first line customer support. People who are help you and I think you will see from the next slide they have been doing an excellent job. The green bars are the bars as of now, and you will see in every category that the amount of tickets has gone down and in some cases even significantly. We have tried really hard to make good documentation, we have had quite a few action points on us and work with the Database Working Group to provide an infrastructure for better documentation, more up to date docksitation. We have added new documentation where we needed T every deployment we have done we have added notifications and how to the community and of course our customers services have been helping people do their job even better.
So all in all, good news, the load on DBM is going down. Now are the RIPE database. IRT objects has always been something of an interesting /TR* to this Working Group, so here are the up dated numbers:
We see IRT objects growing slowly but steadily. The amount that have an abuse mailbox specifically there for the abuse contact is growing proportionally to the size of IRT objects growing and unfortunately the IP coverage is not increasing with it, because we keep on handing out INET Nums and even though some of the new ones are covered many more of them are not so the percentage is holding stable at about 1.6 percent of all INET nums in our database covered by one or more IRT objects. The good news, however, is that returning the IRT objects as a default with all the queries are being done does not seem to be causing any operational issues. It was a concern of the Working Group before, but we can report that we have not received any tickets about this and our query log show that nobody is specifically disabling or specifically requesting IRT objects any more in their queries.
Now to some statistics: Our IPv4 average right now is about 106 queries per second on our whois, the peak is at 166. To give you a comparison, January 2007, not all too long ago, we were 33 per second. So, we are more than three times as many than we were about a year and a half ago. There is a another comparison the last RIPE meeting was 94 per second. Unfortunately, IPv6 remains low. If you are interested in these types of statistics, again I would refer you to our DBConstat project which has this and many, many more. In a more linear fashion and it is linear, this is the growth path of our queries at this point.
Now looking at axis methods, we see that most people use the what you my call the bill or TelNet client. The biggest drop off is in proxies. We have gone up about 15 percent in the amount of queries absolutely but the proxy usage has dropped. We unfortunately do not have any data on which proxies have been dropped or why they have been dropped but they went down from 42 million to about 18 million over this period. And to give you our representative idea of the slice of the pie, the whois.CGI which listed 2 percent of our axis has grown from 5 million to 6 million per month over the last six months. More interesting is actually this graph, which shows that our friends in Germany have become even bigger fans of the whois. Everybody grew roughly in the proportion that the queries grew, IE about 15 percent, but Germany has doubled its A queries to the whois service. (Amount of) just to give you example: Just on whois.CGI we got 1 .5 million hits from Germany over the last month. If you look at query distribution we see most people don't do that many queries. Most of them are in the order of magnitude or 3 or 4 per month. We have about 10 percent of our users do up to 100 but you will see that 98 percent do less than 100 so we don't have too many heavy users. We are looking at five individual IP addresses that do more than one million queries a month.
On the side of the up dates actually not much changed so even though queries are growing rapidly updates have stayed the same since last few RIPE meetings. About 2 per minute on average and in peak times about 60 per minute. We don't really experience any queuing in this case, so 60 per minute is about the speed that people are putting them in, not just the speed that we are processing them in. However, we have seen that people are doing more bulk type updates where we now have seen peaks of 60 per minute at times, the January 2007 peak was only 20 minutes and again please go to DBConstat if you like these types of numbers. Another interesting graph is the update methods that people choose as I was saying before mail updates is specifically error prone. A majority use syncupdates at this point where you can leave a message and get instant answer and still 23 percent of our users use mail updates. If you look on the right hand side you see that the amount of spam is 13 percent, and that comes straight out of the mail updates. So a large amount of mail unfortunately turns out to be spam. This also may give a good case to rethink the case we do asynchronous updates. I would like to end on a high note and it's the up date as� query and update up time. You see ultimately May and October we had 100 percent in May so did we in October. For mill /# mail updates we had 99.94 up time in May, 99.999 in October, we have down from 36 outage to only 19. For syncupdates we went down from 326 outage minutes to only 40 over the last ten months. So that means actually for us that the myth of the five nines is quite busted. We have 99.999 on all our essential services right now.
Any questions?
Nigel: Any questions from the room? If not, I have got two or three. I am slightly worried about the loss of e mail updates and obviously we are going to need to see a bit of a report and study on that before we even think about removing those. Just something of your statistics, you said in one slide that there was 23 percent updates for e mail and you said 134 percent were spam does that imply that 10 percent of successful updates were by e mail?
SPEAKER: At this point, yes.
Nigel: OK. Right. So that is less of a problem than it looked initially. Any idea why the whois queries have increased, was it three fold or twofold since the spring or is that just�
SPEAKER: Since the spring, since January 2007 we have seen a steady increase, pretty much linear increase
Nigel: That is organic growth then?
SPEAKER: Yes, it is.
Nigel: One final thing you mentioned Limerick /PROBS no longer seen as operational; Limerick objects don't exist any more
SPEAKER: They do still exist My�Friend
Nigel: In that case you have got an outstanding action point because you were asked to remove them and replace them with poetry objects.
SPEAKER: Poetry of type Limerick, am I saying it correct now Denis?
Nigel: That is one thing sorted out. So what happens when you remove�
SPEAKER: I do appreciate the grave concern�
Nigel: What happens about a poetry object whose technical or admin contact is removed from the database because they are no longer considered to be operational?
SPEAKER: I think Denis is uniquely suited to give you an answer to that question. Denis: Basically we can't remove the admin we keep the poem object so we would have to consider it as operational data.
Nigel: That is what I thought.
AUDIENCE: I know how important poem objects are to the community.
Nigel: There is quite a few of them in the database and some are extremely historical
SPEAKER: I think you will find about 100 if I am not mistaken. I think 95 by you.
Nigel touche.
SPEAKER: Right now we are only cleaning up personal and maintainer pairs which are usually either they are created by people who are playing with the RIPE database or left by operators who had a customer who they have removed from their actual allocation but did not clean up after. This is by far the bulk. The request was to clean up everything that is not considered operational data so if in the end a whole cluster, a whole cluster is not attached to an INET num or an AS number, our Database Working Group requested to look into cleaning all those up.
Nigel: Correct
SPEAKER: How we are going to /O do that exactly that is for a later thought.
Denis: So the poems are safe for the moment.
Nigel: Jolly good. I would expect a study on that before you tidy up.
SPEAKER: Any more questions?
Nigel: Any more from the room? Obviously the network is working.
SPEAKER: In that case thank you so much for bearing with me
(Applause.)
Nigel: An excellent presentation. Now we have a presentation from� this should be a report from the data Protection Task Force and there is actually one action point that was passed on to the data Protection Task Force and we will see if he deals with it.
SPEAKER: What was the action point?
Nigel: 55.1� no, 56 .1 so it comes from last meeting to consider the action to be taken when legal authority requests the removal of data from the database and in particular, whether records of such actions should be recorded. Now this, may not have found its way back to the data Protection Task Force. In which case Malcolm will have words with you later, I think, since it was his action point. The next two agenda points are actually really two halves of the same thing. Denis is going to follow up with five slides on mirroring which is actually part of the data protection issue.
SPEAKER: Good morning. I am here as a representative of the data Protection Task Force. First of all, I will give awe slight update on what we set out to do and then I will run through where we are and then we have some actually Denis will present some separate slides on the issue we want to put forward to the Database Working Group.
Well, one of the first things we looked at was to set up a legal framework. As you know the database holds lots of personal objects and we looked at what kind of framework would meet the data protection legislation. Coming from that, of course, it worked out that we had to set up quite some terms and conditions and key thing of course is the database terms and conditions. In addition, we had to develop some policies as Jos Boumans already mentioned one of them was the white pages which we came up to facilitate that people who are not linked to resource still can be in the database under data protection legislation.
Another big thing we looked at is the bulk access. There is quite some people who want to have bulk access we don't want to give them bulk access of all the personal information so we looked at that and actually we are still looking at that and we also want to ask you a question regarding that. And then the implementation.
The legal framework. Well, the set up of legal framework is done, we have done that a couple of RIPE meetings ago. There is still some outstanding actions, the privacy statement and the general terms and conditions are still open. The reason for that is that we are still� we had to wait before the database terms and conditions were actually finished and published and everything before wrapping this up so we hope to wrap this up in Q4 of this year.
Well, good news; RIPE database terms and conditions are done, published, official. The only outstanding action for us is to actually make a RIPE document out of this. We have defined the purposes of the database it, may seem a bit odd point to put on the slide here, but this is a key things for data protection legislation. When� the database has to meet actually its purposes, why we put the personal objects in there. I hope that was a bit clear what I mentioned there. Acceptable use policy; we have set it up I think the main action for us is to review it, see if we see odd things happening, people still trying to misuse it and whether it's still acceptable use. Action item which we still have to follow up on is actually the implementation of the database terms and conditions. What I mean here is actually that, probably, when you have made an update, you will get something back, which says that� am I saying it correctly, I am looking at the database people. Yes. Also the documents are object line, you can look at this URL and see the documents (are on line). Okay then for the Working Group also a bit of more information on what we did for the RIPE database. Well, the terms and conditions I talked quite a bit B we set up a procedure for implementation. We are now at the last phase to actually implement that everyone who use the database is helped through these terms and conditions. Publication of the terms and conditions is done. And as I mentioned before, last outstanding action is to fully implement them. We also have is a procedure to remove personal data every now and then people approach us and say "I have notice the my personal information is in the database, I don't want that, I want it removed." Well, this requirement, of course then that we have to remove it so wave procedure on how to do that. It's also on line and you can view it. Well, Jos Boumans mentioned already the maintaining person role and domain objects, we are almost there and the biggest thing 6 course the clean up of the unreferenced objects so that there is no reference persons in the database.
Bulk access: This is an area actually we still have to do some work in as data Protection Task Force. We have set up near realtime mirror he have non personal data. It's available for people who want to use that. We currently have about ten contracts with companies who were interested in this, there is a small fee for it, it's a contract and it's a recurring fee, by the way.
Then, the thing that still pending is the proxy access agreement that is also something we still have to work on. And then there is the mirroring and the NRTMs with personal data and then it's Denis is going to tell you about it in a minute so I won't steal his lines.
Policies, white pages, explain how it works, please use that when you still want your personal data in the database but you don't have any resources, because it will be removed otherwise. Two things we initially looked at, but at this point in time we are not really going to pursue: That is authorisation for referencing of person and role objects and the structuring of address attributes. From a data protection perspective it might safeguard data more to be in line with data protection regulation. So final actions, we have out standing, all these actions are mentioned in the presentation and we hope to wrap them up before the year end. The data Protection Task Force will still go on until these actions are done and until the bulk access issue is resolved and we hope actually we can resolve that with your input on short notice.
That is it. Are there any questions?
Nigel: Any questions from the floor? No. Well, thank you very much indeed.
SPEAKER: Yes. And of course, Nigel will take up the action item.
Nigel: Thank you. Right, we now have the second half of this agenda item which is Denis telling us about mirroring.
Denis: Good morning, I am Denis Walker from the RIPE NCC, butted to I am representing the data Protection Task Force.
As was just said most of the issues have now been resolved that the data Protection Task Force set out to do. When we met this week we could spend a little bit more time on some of these issues which have been outstanding for a while and the mirroring is actually quite a significant issue for the data Protection Task Force. Just to remind people what we remind people what we mean when we talk about mirroring, some of the other RIRs mirror the RIPE database and the RIPE mirrors some of the other RIRs databases. This means that a complete copy of the entire contents of the database are held by the RIPE NCC from other RIRs and the other way around. These copies are updated in near realtime with a constant stream of data so as every update occurs in the host database, it gets sent down to the copper. In both directions, these streams contain all the personal data and over time, these mirrored databases also build up the historical versions of all this personal data. This is a particular concern to the data Protection Task Force. There are a number of issues from a legal point of view when we are talking about mirroring. We don't actually have a valid use case for mirroring. There is no justification, really, for the RIPE NCC collecting and publishing personal data from other RIR regions, and when we allow other people to mirror our database we are actually exporting all the personal data contained in the RIPE database outside of the EU. To do this, we actually need to apply to the Dutch data protection authorities for a licence. When we do that, they will ask us a number of questions; one of them will be: Is it possible for the people who need this data to actually get the data by any other means than having this copy held by someone else? As all this data is publically available from the RIPE NCC with the RIPE database, anybody anywhere in the world can access the RIPE database and these days, connectivity isn't such a major issue. The answer is basically, yes, there is another way which people can access directly the source of this data. Under those circumstances our legal advisors tell us it is unlikely that we will actually get a licence granted if we apply for one. Other concerns is that after we've exported this data to another country, that data becomes subject to the local laws and the local legal jurisdiction, so in other words, if the RIPE NCC is no longer in control of what happens to all that personal data. We also have no legal justification for the RIPE NCC for actually� to actually store historical personal information from other regions. We store the history of personal history within the RIPE database, mainly because we need to resolve disputes over who is a registrant of Internet resource. We do get these disputes occasionally and when they occur it's usually over a resource that was allocated many, many years ago, the only way we can help to resolve that dispute is by having this historical information. As we are not the registry for other regions, we don't have a legal justification for having this history of other regions' data. The way the mirrors are operated technically is we use the same sort wear as the RIPE database and that automatically does save the historical information. If we were to run a mirror without that we would have to modify the software and run a customised version specifically for mirroring. The same applies the other way around: There is no justification for other regions to keep the historical information from the RIPE region. If we were to apply for a licence to export this data, that would be another major concern that the Dutch data protection authorities would be concerned about. The other RIR regions would have to guarantee that if they were to receive this data, they will not keep copies of historical information, so in other words, as soon as an object is deleted it is deleted from the mirror and not preserved anywhere in a history table.
Another concern is that there actually is no procedure at the moment either legal or technical, to handle a request to remove personal data from one of the mirrors. The data Protection Task Force has recently establish add procedure within the RIPE region so that if somebody requests that they remove personal data from the RIPE database we can now do that. We can't actually do it at the moment for one of the mirrors, we don't have a mechanism for deleting individual objects from the mirror database. Also, this would have to be done in the other way around as well so if somebody asked one of the other RIRs who was holding a copy of the RIPE database to remove personal data they would also have to be able to do this. One of the other problems about actually doing this is that if we remove a personal object from a mirror of, say, APNIC's database which we hold but the certainly doesn't actually ask them to remove it from the host database, as soon as that object sup dated again in APNIC's database it comes straight down that stream and we recreate the object in the mirror. So we'd have to build a filtering system on that stream of data so that we could record lists of objects which we have been asked to remove and every time one of those comes down the stream would have to filter it out. It's also been established that NIC handles are classed as personal data and unfortunately there is now case law within the Netherlands that proves now that a handle in a database is personal data. So not only do we have to remove the personal object from the mirror, we have to clean up all references any other object to that NIC handle. To maintain the reference integrity we have to create a dumby personal object and change all the reference to the dumby object. This also complicates the filtering we have to do because you have the object came down that update stream, which referenced the deleted personal object, it would fail to be created in the mirror. So we'd have to actually filter or clean all the objects that come down the stream to make them all referenced to dumby object. It's becominging quite a complex issue now to handle the mirror stream. Also, all the other RIRs that want to mirror the RIPE database to have to do exactly the same on the stream of data that comes from us and again, we would not get a licence to export this data unless they guaranteed that they would actually do all of this. So to maintain a mirroring system is now becoming a significant effort on the RIPE NCC and any other RIR that wants to mirror the RIPE database. So the recommendation from the data Protection Task Force to the Database Working Group is that we do not allow mirroring of the RIPE database and the RIPE NCC does not mirror any of the other RIRs' databases.
We would like to discuss that and take any questions.
Nigel: Questions, thoughts.
Randy Bush: The RIPE region confounds two databases in one (confounds): Let me use the ARIN or the north American terms, excuse me, the whois data and the IRR. Are you strictly discussing the whois data? In other words, the registry data not the routing database data?
SPEAKER: Well because all ours is in the one single database� Randy: I understand that.
SPEAKER: � we only have the RIPE database which is both Randy: The answer is you are discussing the routing database
SPEAKER: Both of them, yes. Randy: Then I have a serious problem or two of them: The first one, could you go back to your slide 3, and by the way this one is not� that is slide 4. Thank you. So, you are going to shut off whois from outside the EU, also?
SPEAKER: No, we are not shutting down the RIPE database; we are saying it's legal� Randy: But that is exporting the data outside the EU.
SPEAKER: This is a difficult legal question here, because yes, technically all this data is publically available, anyone in any country outside the EU can query it, the difficulty from a legal perspective is the bulk access F we actually hand somebody the entire set of personal data, when you query the database you are subject to access control. Randy: I am not a lawyer so I am not qualified to to speak to this but my family expression is do I smell cows? In the RIPE region, if I want to successfully have my prefix routed, I have to be available in the RIPE database. You do this and this now means that I cannot� I am going to have to register in the region in which, you know, I normally or private IRR in which I normally register my routing data router and register in the RIPE database as they are not being mirrored.
Rudger: OK on this. First of all, one remark to Randy: It's a feature that the authoritative registration data and the routing registry data is in one database that is having a common authorisation scheme. Randy: I was just trying to understand what he was talking about.
Rudger: Just to keep that point very, very, very clear. Well, OK, removing both directions of mirroring, as I understand you are proposing, quite certainly, quite certainly interferes in serious ways with the practices of generating routing policy that has been in place around the globe for people who are doing this. There are, of course, many ways one could do it and different ways are used by different operators, but the� but very, very common way of doing it is to say, well, OK, I have essentially one database and whether that is the RIPE database that is having mirrored content from other databases or whether it is a locally kept collection of mirrors or whether it is RADB which mirrors all garbage that can be found on the globe, it doesn't matter. For many parties the usual thing is they have one database that has all the information and they run their algorithms across that. Most people find it very hard to create modes of operation where they selectively pull information from various database servers of course that can be done but it is a pain along all of your backside
SPEAKER: But we don't actually have one single database. When we keep mirrors of some of the other RIRs, you can query our database with a whois minus A, which says query all� query the RIPE database and all the mirrors that we keep. In effect, what that is, it's kind of a joint whois, because if we said when you get a whois minus A query we query the RIPE database and we query all the other RIR database toss pull in the information, the same thing.
Randy: We understand this, we are your biggest users and we are trying to tell you we have a problem.
AUDIENCE: RIPE NCC I think Randy argues the case when RIPE database is mirrored by things like RADB where you can actually have a collection of routing registries, just go and queue for the objects that you want.
Randy: And vice versa. The point is there are big ISPs in the RIPE region which say if you are not accessible in the RIPE whois we won't route your prefix over a peering link. So if I am an American ISP who got my address space, registered in the RASD or ^verios whoever and I have a router over here and I try to peer with you, you are going to tell me, sorry, you have to be in the RIPE database. I guarantee you that no matter how much warning you give, when you make this change they are going to be people who is routing is broken.
AUDIENCE: That doesn't change you should still in the right database and right registering routing.
Rudger: The common practice is that people who are generating route filters based on IRR have one database server where they get all their queries resolved and that database server obviously has to have mirrored data of all the relevant repositories. The RIPE routing registry, quite certainly is a very, very relevant global repository, but isn't by far the only one, and
AUDIENCE: As a matter of fact if they want a single source they don't go to RIPE because RIPE won't mirror the smaller ones so they go to RADB but RIPE won't be there any more.
Rudger: Yes, well OK, I think� I think there are very serious consequences. I am not completely sure about your response, where you are saying well OK because importing foreign data into the RIPE server creates also legal problems so you are not going to do this, or are you going to asymmetric RIPE where RIPE does some mirroring of others but will not make its own data available?
AUDIENCE: I think important point here if I am not mistaken that we are talking about personal data?
SPEAKER: Yes�
AUDIENCE: Support mirroring. Randy: I started, that was my first question.
AUDIENCE: If you talk about router objects for instance they do not contain any personal data.
Rudger: Didn't I hear Denis say that from the legal point of view that was used, having even the person handles in the objects would be� would be considered personal data?
SPEAKER: Yes, unfortunately NIC handles are now classed legally as personal data but from a data protection point of view it's only the personal data that is the problem. If it's obvious that this is a service that is needed, then we have to look at ways of handling data which doesn't include personal data. There is nothing to stop� I agree with what Randy is saying, there is nothing to stop us from exporting route objecting or /A*UT as long as it doesn't include personal data. The law says nothing about /A*UT objects, it's the personal data that is the problem.
Nigel: I think I see a sort of way out. We can do what Randy says and export a routing database, which is not a registration database. That is possibility. We have Jos Boumans at the microphone. Randy: And import them please. Nigel: Yes.
JOS: One thing I think is important to note we do not have one database contains LACNIC under the same restrictions so they will not export their database either way.
Nigel: We don't receive a mirror feed from LACNIC
JOS: You only have four out of five. Nothing from LACNIC. The second one is that it is specifically the personal data which unfortunately is also in all our operational data because NIC handles and e mail addresses and are personal data so we can't export all of it. The big question is which bits can we export, would be my question for the data Protection Task Force and are we then ending up with such a small bit of data that we are exporting that it may become invaluable to do so and conversely what, would it mean if we tried to import these subsets, do other RIRs make that available? Does it even fit with the way you operate the database. Can we do anything? Randy: I can enumerate the ones you want to. Do I really need to. ENUM, 6
JOS: I was talking about the content of those objects.
Rudger: I am quite sure a filter specifying which attributes are required and which attributes are dangerous from a legal point of view looks very, very simple. It may actually� it actually amonging the objects this way may break one or two kinds of software that actually insists on the syntax of the objects being intact, well OK, that should be something� for example,
Randy: Make dummy entries. I think we are not going to design by committee here and I suggest maybe this task force should go back and talk to some other people who do routing and less lawyers.
AUDIENCE: Geoff Hughes enhad a question a few minutes ago: To what extent does this apply to personal details and to the description of a number re/SEUS and its holder, is such distinction possible in the context of the RIPE database, does this impact on the related activity of the resource certification.
Nigel: Which I think is the same question basically.
AUDIENCE: Geoff pointed out that his part about the activity of rest /SEUS certification has not yet been addressed. So I guess that might be valid.
SPEAKER: I didn't quite get that.
Nigel: Can anybody translate that.
Rudger: I somewhat suspect Geoff between the lines is pointing out in the certificate system there is absolutely no certainly data.
SPEAKER: Then that is into the legal problem then. Randy: You are a lawyer?
SPEAKER: No.
Nigel: This whole thing is going to have to go back to the data Protection Task Force anyway so let's not argue any way. I don't think we convenient a lawyer here.
AUDIENCE: Geoff has two more comments, the certificate binds the resources to a holder, the problem is that the identity of the holder may or may not be present.
Steve Kent: BBN. I knew what Geoff was getting at, and the issue will be hopefully the identities with except for the very top tier, the RIRs, are not going to be meaningful identifiers, but this is precisely an example of the database where bulk downloads are absolutely required for the system to function and so it would be critical that this database not be subject to the problems that you are describing here. So you will definitely want an authoritative opinion on that.
Nigel: Right. I think this has to go back to the data Protection Task Force.
AUDIENCE: Geoff also asks for that.
CHAIR: Who decides on what sort of data they can import and export to comply with legal but also with operational requirements. Does that sound reasonable?
SPEAKER: Yes.
CHAIR: Back to you then. Andrei.
AUDIENCE: Just maybe comment, because I appreciate this discussion about routing registries, while they have certain context and one thing is that, yes, indeed routing registries is part of the RIPE database but another aspect of this problem is are there registries of other areas that we also mirror? Now while routing registries I think operational value of the data is still high without personal data for management databases that is not true so I think another problem to thank Denis is presenting is mirroring of other RIRs. Now, if you look at other areas who is on the RIPE NCC mirrors other registries in this way and another registry that also provides a global view on this data is LACNIC who actually don't join whois, they are just proxying and doing referrals.
Nigel: Is there any particular reason why proxying wouldn't solve our legal issues and our technical issues? Is there no reason why we shouldn't proxy other RIRs' databases?
AUDIENCE: It may but maybe not in traditional whois form. We discussed this some time ago and it doesn't change the format, so it doesn't RPSL the input data which will certainly break people's script.
Nigel: Yes, I see. OK. That isn't an solution because ARIN doesn't use RPSL. OK.
Jos Boumans: Final comment on this one, we did discuss joint whois if I remember correctly in the data Protection Task Force and the answer there was if you redirect questioner Reese that is fine because you are not doing anything with personal data and Denis correct me if I am wrong.
SPEAKER: Yes. There is no problem with doing redirected queries.
AUDIENCE: Substituteing from a data Protection Task Force opinion if, we replace mirroring with joint whois we would be in the clear, is that correct?
SPEAKER: As far as I understand what the lawyers have told us, yes. Jos Boumans: Thank you.
Nigel: So that solves incoming mirroring but not necessarily outgoing
SPEAKER: No the other regions would have to do the same thing.
Nigel: Yes obviously there would have to be agreement. OK. Well as I said before, this has got to go back to the data Protection Task Force and they have got to look at what sort of procedures we can adopt to actually satisfy operational requirements.
SPEAKER: Yes.
CHAIR: Thank you. Thank you very much indeed Denis.
(Applause)
CHAIR: Our penultimate point, input from other working groups. We have something on ASN 32, that is the ASPLAIN problem, somebody was going to present on that but I can't remember who. Is there anything more to discuss about it? Andrei?
Andrei: RIPE NCC irk it's it's more a procedural question because IT have approved this RFT. I think maybe this data� this Working Group should make an action point on the RIPE NCC to implement, to make database compliant and let the implementation to the RIPE NCC, because there will be require some coordination and some roll out plan in coordination with other areas. Are we all agreed on that then action point to the� Rudger: Making sure that current� currently used client software doesn't break when the implementation happens.
CHAIR: Correct, yes. There aren't that many 32 bit ASNs in the database at the moment, I think. OK. So that action point is clear on the RIPE NCC then. OK. Good. Right, Peter, we have some input from the DNS Working Group. This is to do with domain objects, as I understand it.
Peter: Good morning, my name is Peter I work for DE CIX, one of three co chairs of DNS Working Group, maybe I prepared the slides too early.
So what is this about? It's about creating some new work for the NCC of course. Domain object in the database. Jos Boumans mentioned during his presentation that objects were found forward and reverse domain objects were found that didn't have a maintainer and there was some action taken and so on and forth and during that discussion with the NCC between the NCC and the DNS Working Group chairs, we were all involved, we thought it might be a good idea to review the use of the domain objects in the database while at it. So, it turned out that there are a couple of forward domain objects in there and first of all I should say there is no question about the necessity to have domain objects for reverse and ENUM because they serve as provisioning instrument for the reverse DNS and for the ENUM T 0 zone, this is forward stuff which is purely informational in there. Most ccTLDs in there had a single object with a attribute and I will come to that. A couple of ccTLDs that have domain objects in the database had additional material, so as you can read on the slide, some of incomplete subset all the second level domain registrations, there were even some random third level in there and more or less stuff was inconsistent or maybe outdated objects that had been sent into the database at some point in time but never had never been maintained any longer and for some top level domain it was the case that the second level objects were maintained by completely different maintainer instead of the registry itself it, turned /TPHOUT one top level domain the registrar, the local IRS routinely added the domain objects for the customers just when they worked on the appropriate� or the corresponding INET num objects so there is an issue with data consistency and quality there. Still, very few ccTLDs seemed to maintain their entries activity, that is even those that had their single domain object, the TLD object with object in there, stuff was outdated and two or three of the ccTLDs in the region maintained all their second level domains, second level domain registrations within the database more or less substituting their own whois server or using the RIPE database as their sole whois data repository.
So how does refer work? I guess this is an update, refresh for most of you; queries for second level domain.top level domain go to the RIPE whois serve and then are proxied to a given whois serve actually at the ccTLD registry and the information where to go is given in the refer attribute in the ccTLD's domain object. The purpose of this is, well, the refer object was intended to be a migration aid back then when it was decided that the domain objects should slowly be phased out here and ccTLDs would provide their own whois service and customers were used to or� yes, to using the RIPE database as the sole instrument of looking up Internet data. These times have long since gone. So to be able to deal with axis control, what happens here is that the given a certain parameter in the refer attribute, the RIPE whois server will then tell the remote who is serve he is referring the query to who the original querier was and if the TLD's whois server trusts the RIPE proxy it will then, again, subject the query to serve ACLs and use the original address instead of the proxy's address so everything is accounted well.
The query volume seems to average around four queries per second in the first half of 2008, so that is probably not too much given the figures that Jos Boumans gave us in his presentation. It it's not much compared to what ccTLDs usually see as loads on their whois servers.
So here is some input from the DNS Working Group to be considered and eventually end up in an action item. I should add there was a CENTR meeting, the Council of European top level domain registration, so ccTLDs in Europe and surrounding areas and there was a technical meeting on Saturday before the RIPE meeting started and we discussed it there as well asked whether they were eager to keep their objects in the RIPE database and those present had no objections against either removing them or having these objects removed. In addition to that clean up of remaining objects that these is these random second level domain objects in the database, well centre /PHAOEBS, ccTLD's registries were probably not too happy with that but it's seen as a matter of database hygiene and deletion or alter ration should be subject to policies set by this community. We discuss this had also in the DNS Working Group and of course, we have to confirm consensus on the list but that said, the Working Group, the people present in the room didn't feel very strongly about keeping these forward domain objects in the database because there seemed to be no benefit, people should be able to go to the appropriate TLD who is instead and there is probably no need in having the referral objects and there is especially little benefit in having inconsistent outdated data and inconsistent policy, some TLDs are in the RIPE database and not are not. There are very few ccTLDs actually actively using the RIPE database as their whois repository. Of course, these should be offered consultation assistance and help for migration.
So nobody should feel like pushed out of the database.
So here is the proposal I am kind of proxying or coming up with. Generally, the forward domain objects and that, again, does not include ENUM, of course, for TLDs should be phased out and that means the TLD objects themselves and everything that refers to� the action item would be to ask the NCC to draft a schedule, detailed work plan with time plans and what exactly to do. One suggestion would be that we expect the respective maintainers to, after a public announcement, delete the objects and then set a deadline and should the clean up not have happened until then, appropriate action would be taken, i.e. the objects would be deleted on their behalf following the new policy, and yes as I said, there should be coordination with those TLDs that use the database to come up with a plan how migration to some different repository or some continued service could be achieved.
That is basically it.
CHAIR: Any questions from the room, anybody actively use domain forward references� objects? Can I take it then that we can actually ask the RIPE NCC to what, do we say, draft a schedule and start looking at how this would be done? Everyone happy with that. Good. Thank you. Thank you very much, Peter.
Peter: Thank you.
(Applause)
CHAIR: Right, we are on to the last item which is AOB. Anybody got any AOB? Going once, going twice. Thank you very much. After coffee.
(Coffee break)
**
The IPv6 Working Group session commenced as�follows:
CHAIR: Good morning. This is the IPv6 Working Group. We have a fairly full agenda so we are going to start on time. For people that don't know me yet, I am David Kessens, I happen to work for Nokia Siemens networks. We can start and take a look at the agenda. (K E S S EN S) first of all always administrative stuff. I am very conveniently going to skip that because we have already arranged for ^describes etc., so it's just agenda bashing that is left. (Describes). We will start from a quick update from Andrei how the situation looks at the RIPE NCC, traditional very quick report. We start with our reports about actual IPv6 traffic that we will see in the Internet, we have a couple of speakers this time and in fact I am quite happy that we have a couple of speakers because when we started this report it was like sometimes who could report a tiny bit about IPv6 but we really now start to go see a collection of different speakers who have some interesting viewpoints in various parts of the Internet and who can tell us a little bit more on what they are seeing.
Then we have the global IPv6 routing stable status, /TKPWO*ERT has decide to do it a little different than we have in the past couple of meetings. He will be a little bit shorter and will just look at a few strange things that they have seen and just keep it at that. Then we have a that you can also has been in the DNS Working Group but we will get more summary, more focused on what is interesting from the IPv6 side of the world so we get a brief talk on IPv6 penetration in dot F R. We get a talk from her can electric on IPv6 peering and finally, and that will actually be a bit of our main topic at this meeting is actually IPv4 and IPv6 coexistence, the ITF is looking at this problem again because it has become clear there is still a few holes in the tool kits that are available (IETF). The Internet area director will give a talk about this topic and the we would very much like to you actually commence on his talk, interrupt him, whatever, because he really needs more input on where� how to prioritise certain solutions, etc..
And then finally, basically just the end of the agenda. So we can go to our first talk now, if there is no� nobody has anything to to add to the agenda? No. The first talk, quick update from Andrei on� regarding IPv6 services at the RIPE NCC.
Andrei: Thank you, David. RIPE NCC. Yes, that is a really short update. Our commitment that we presented at the last RIPE meeting to have all our major services being available on IPv6 still stands. We have implemented our mail system, supportive IPv6 in our mail system and we see some traffic. It's not much but it reaches five percent of our mail traffic in terms of successful connections. Bulk of it comes, of course, from sites like IETF, like ARIN, from host mailing lists. But still something. And the last piece that we are planning to complete by the end of this year is IPv6 support for LIR Portal and then we will complete will be promised to this community.
CHAIR: Thank you. Are there any questions, remarks, for Andrei? No. Thank you for the quick information, you know, update. So then we get to report of actual IPv6 traffic on the Internet, we will start with Henk Steenman on what he is seeing on the Amsterdam internet exchange.
Henk Steenman: So this couple of slides about what we measure on IPv6 on the Amsterdam internet exchange. We have been measuring IPv6 using Sflow for a last year and a half or something so accept that we can tell something about the total A traffic we also have some growth statistics on that. (Amount of).
To put something� to put it into perspective, M6 is Internet platform crossing the major area in Amsterdam. We are connecting about 305 ISPs, carriers, content distribution networks, etc., and we have a total of 560 connected routers. The peak traffic on IPv4 plus IPv6 together is in the order of 520 to 530 gigabits per second we use Sflow to estimate the IPv6 amount of traffic by sampling Internet frames with the IPv6 ether type.
This is the history of the amount of connected IPv6 routers. The red line you see shows the allocated IPv6 addresses for router interfaces, which comes up to 134 at the moment, and the green crosses show the amount of connected routers we actually see by counting the neighbour discovery� counting the addresses in neighbour discovery frames we count and the blue line is an average on that. So what you see from this is that the amount of connected routers actually very much with I think means that people use IPv6, still, very much experimentally.
This is the traffic we see. It peaks up to 700 megabits per second on a daily basis and the average is around 400 megabits per second. And this is the growth we have seen over the last year. At the last May RIPE meeting, we were just over 100 megabits per second, or something, the big jump just before that happened when a net news provider turned on its service on IPv6 but after that we have seen a pretty steady growth, which is interesting. I think this is even more interesting; the blue line you see is the growth of IPv4 over the last year, and the red line is the growth of IPv6 over the last year, and at least in this time frame, on the Amsterdam internet exchange IPv6 is growing much faster than IPv4. So that is it. Any questions? OK. Thank you.
CHAIR: OK.
(Applause).
CHAIR: Then it's time for Kurtis.
Kurtis: Right. Thank you, David. I have been trying to gather some data about IPv6 usage in Sweden in a number of ways. And the native traffic amounts from the providers, actually went out to the Swedish ISPs and tried to get the native data and it's very, very little for the few people who provide data. We managed to separate and there is a lot of data being presented in Sweden about number of address occasions but allocations doesn't say much about real traffic. So a lot of the data I have, I went to some content sites that have v6 and got data from them, instead. And I then tried to split the sources between native and Teredo. Dot S E publishing some graphs. This is the number of A to P servers that can be reached in dot S E that is going down. It's a bit interesting. This is the number of glue records, seems fairly stable (glue). There are some ISPs who actually deliver v6 in Sweden, either with tunnels or natively in you are enterprise but not to the end users. They do all� none of them as far as I know provides SLAs, there are some rumours some are /HR* start or have done it. If you ask them they are already for doing v6 to the edge, they are waiting for having some sort of D L S standardisation and available of DSM� a lot of them are waiting, once this becomes available they can role this out. In Sweden we had municipality fibre networks run by the municipalities. They also� some of them provide ISP services five have them have got v6 services that they are providing to the end users again without SLAs and mostly for testing. What is interesting is that one of them, the actually municipality has gone out and said v6 enable entire network and launch this. This happened a week ago or so. Some of these have had these addresses for a long, long time but never used them for over four years. Internal standardisation. At NetNod we have 52 connected operators, 24 of them have asked for v6 and 15 are peering it. NetNod members have said she don't want to do S flows so they can't actually see the traffic because they are afraid of us looking into peering arrangements, so unfortunately we can't provide the nice data that Henk had. I did go to two ISPs in Sweden, the first one runs� they see 100 mech get of 64 traffic is the average� is the peak, sorry, and 200 Meg peak for freed dough, they see quite a bit of traffic. This is more�
CHAIR: � not Working Group hat on, I mean, I see this stories about peak traffic. Is 6 to 2 /#4* ^in Teredo peaking at the same time or is there anything to say about that.
SPEAKER: For what I remember, they follow the normal regular using pattern, basically they peak towards 10�o'clock in the evening. I am just doing this from memory. They are both following� as we see for v4 traffic.
V6 traffic in total from all the traffic they are peering away is, well, 2 per thousand so it's not very much, it's basically non detectable. They are ready to roll out v6 to the end user as soon as possible, as soon as� other operator have input into the IPv6 is complete tunnelled network, they don't do tree dough gateways or 64 gateways. They do have some statistics on the traffic in the tunnels which is the native but it's around 50 megabit through the network and they are looking at, I don't actually� I didn't actually to get to see the raw data here, of the 50 Meg of traffic they in turn saw the type of traffic being five percent freed dough, 25 percent 6 to 4 and 70 percent of the traffic was native more or less inside their own network. RIPE stats files: The RIPE NCC has done 57 v6 delegation to Swedish providers, one is super national. Some of these are smaller allocations that are to be replaced by some of the larger allocations, so this is probably go down by the way but 57 delegations to 300 LIRs and 387 might not be impressive. Look over time, in five years we have all� well approximately double the number of allocations to interest doesn't seem to be rising exactly. But the interesting data is go to the content sites and taken data from three sources by looking at the web serve logs. None of these are necessarily v6 promotional websites and the first one is Swedish newspaper, it's a regional newspaper in the southwest of Sweden. They have actually enabled v6 in all the web servers just because they could. So this is the data from January 1st and this is� it's to September 21, I only got access to the v6 data, I haven't seen the v4 data so I can't say the relationship between them but the relevant 11004 unique addresses accessing this and spread on 55 /32s given 57 allocated to Sweden tells me there might be some international traffic hiting this website. The distribution is 83 percent of 6 to 4, 10 .5 was anyway tip of and two percent ^Teredo traffic, which surprised me go and bit because I thought that might be higher. O S distribution O S X seems to be very popular, 52 percent of the clients, 21 percent vista and 5 percent XP. In the other category, the most common operating system was /S*UPB solaris which surprised me even more. I asked all the major Swedish newspapers and the basically all came back with the Word by Word same answer saying that their current IP version works and don't see a need for a new one. Which might be an interesting view.
Swedish national radio claims they will launch this in June 20009, they plan to deploy v6 for the services.
Michael Abraham son gave me some other data, /OPS mailing list might have seen this before; he got data which is samplinging over a week where they included on part of the cluster, they included 3 pixel, Linx to 3, one with single A one dual stack and one quad A. Only half a percent of the users actually tried to use v6 for the dual stack image, the others preferred v4. And only 6 percent of all the people accession it tried to use the v6, v6 only link and for those in the v6 only category 89 percent were using 6 to 4 access 9 percent were using Teredo and two percent were using other IPv6 based native in 134 different /32s. O S distribution, vista much more popular, followed by XP and Michael did a bit more fine grain analysis. Last, I also went to the NetNod sites and this is then over almost two years, we done of course not the most popular website in the world funny enough, and if you clean the data from the NetNod's own prefixes which is monitoring and probing, etc., we ended up with this 86 percent native, 13 percent was 6 to 4 and.8 was tree dough. That is my last slide. I was really surprised to find freed dough so far down as advice at that ships with Teredo. The explanation given by Microsoft on ops list if Teredo have only have a Teredo address as a v6 address and go to access a dual stack host, it won't actually use the v6 address. If you give it a v6 literal address it will use Teredo, if it's v6 only connectivity it will but not if it only has Teredo address. And that is all the slides I had. Any questions? I know I spoke really fast.
CHAIR: No questions.
Randy Bush: Are you going to maintain this longitudinally? In time?
SPEAKER: If there is interest, sure.
Randy: I was just expressing it
SPEAKER: Thank you.
(Applause.)
CHAIR: Thank you, Kurtis. Now it's time for Gert Doering for his report on IPv6 traffic and he will follow on after it and go to his routing table update.
Gert: Thanks for the introduction, this talk is not me speaking; it's from IP exchange in Nuremberg speaking. He sort of ambushed this talk to me yesterday and I then said "I have this data that might be interesting," and I asked David and he said oh, yes, please actual traffic. I cannot answer very many questions about it because this is not my data centre, it's not my talk, but anyway.
IP exchange it's a data centre company located in Nuremberg in Germany and they have one customer that is called Avira, anti virus company� anti virus software for windows thing, and as you all know this anti virus products contact their updates servers to get new virus definitions and everything. I don't know the exact reason why they did it but they decided in August they wanted to turn on IPv6 for their update servers so why the product itself isn't doing any security checks on v6 connections yet, it will try to grab its update data over IPv6. And that brought quite some interesting results. So, this is the traffic before Monday this week. It was sort of like starting and growing to impressive 300 megabits, which is quite some amount of v6 traffic but this Monday, well, three days ago, they released sort of somewhat bigger update and things got really interesting. This is 1.0 gigabit of IPv6 traffic coming out of this update server. It's still less than the v4 traffic they have, but it's still 1.0 gigabit.
Originally, when they set up IPv6 on that update server it was using 6 to 4 relays at neighbouring networks who then all exploded so they are now operating their own 6 to 4 gateway and so they have statistics on how much 6 to 4 traffic is this, they have the ratio of native v6 going to the DE CIX and they have a little bit of data on other up Linx. They don't have a full view of where every IPv6 packet goes to because some of the up date� upstream ports are only, well, v4 and v6 and have no detailed statistic how much is which one.
So this is the 6 to 4. The graph says 800 megabit. The text says, there is some mistake in the calculations of M R T G and the real number is 438 megabits. I cannot answer anything why this is so; it's on that slide, so if you want to know details, you can e mail Robert and his e mail address will be on the last slide.
This is Teredo traffic. They don't operate their own Teredo relay but they have a Teredo relay at nearby network at the LACNIC super computing centre in Munich which is running the university network forced and they forced the Teredo traffic to go that way to be able to have statistics. They have about 100 megabit Teredo traffic. This is traffic going out of their DE CIX port in Frankfurt. It's about 500 megabits. This traffic was provided by the DE CIX operators because they have Sflow sampling on the customer ports so they can say how much is v4, how much is v6. So it's another 400 megabit� OK, it's 500 megabit in total, of toes 100 megabits go to the Teredo relay at the LACNIC computing centre so 400 megabit of native traffic going to non Teredo sources remain.
This is to other up streams, KPN got 8 which is not so much. Level 3 got some 20 Megabits. This is the traffic growth rate over the last weeks and the last months. As you can see, August, September, October were pretty harmless and at the end of this October there was this tremendous peak and the same for the weeks, big spike this week. So that is the summary of it. They peaked at over gigabit of IPv6 traffic, about half of the 6 to 4 and the other half native, some 100 megabits Teredo if you have any questions if you have any questions please contact at the Web address. He will try to be on the Jabber at the end of the session, right now he is sitting in a train running to a customer site. He will try to grab Internet and be available then. Please feel free to e mail any questions you might have. Something I wanted to say which is not on the slides, that I think actually using anti virus update thingy is a pretty good thing to get the ball moving because if some of this is is a bit slow at times and interactive responses is not so snappy, it's not a big problem because these update downloading happens in the background anyway. And if some of the more stupid paths and more weaker routers on the path explode, that is a good thing because it means the infrastructure will become more professional. So, I thank them for daring to do this and I want to see more of that.
CHAIR: Thank you. I see some questions from the audience.
Randy: I try to
SPEAKER: I try to answer to the best I can.
Randy Bush: I agree it's good to have people deploying this kind of stuff on v6. My problems with this as measurement is we don't know what we are measuring because we could be measuring an increased sales curve in their product, / PB increased size of their update package, etc., etc.. and I think it would be very difficult to normalise for that. So I am not sure that looking at longitudinal data in this one would be very exciting.
SPEAKER: Excuse me for omitting this small number here, it's actually five percent of their outgoing traffic that is v6. So they have a huge bulk load of v4 traffic but, overall, five percent of IP exchange's traffic was v6.
Randy: That is interesting. Trending the percent would be interesting.
SPEAKER: Yes. The percentage number is right here
Randy: I see it
SPEAKER: I just forgot to mention it.
CHAIR: Thank you. Any more questions? No. Then we move on to the next presentation, which is also the next agenda topic, and that is the IPv6 routing table update by Gert Doering.
SPEAKER: Here we go. The presentation itself is, well, it's mostly the usual stuff. They are slides in here that I am going to just very rapidly skip over because it's not anything surprising, new, in it, and we are time pressed. OK. This is what it's all about. It's about the IPv6 routing table, some pictures, trends, numbers and stuff. The slides are on line with all the data in it, even if I don't mention all of it today. This is total number of prefixes in the BGP table, the total number of IPv6 prefixes in the BGP table over the previous seven years. It's quite an impressive growth starting with something like 2 to 20 and we are now at about 1500 which is a good thing (220) and required me to get a new title for the presentation, because the title was will we ever reach thousand prefixes for at least three years. So now we have 1,000 prefixes, what next. If we zoom into the last six months, we see some very prominent up and down spikes and and they all seem to come from a very distinct source that I will go into with a bit more detail later on. This is trying to trend this. I know that Geoff Houston could do this much more scientifically, but I just did a few linear approximations by hand and I (approximations) and it's quite obvious that this is speeding up. So, this� I had some doubts at times, the growth curve seems to resemble more of an Internet growth curve going up like this, which seemed to be the normal uptake curve of things in the Internet.
Looking at the prefixes, again for the last six months, sorted by regional registry, you can see that the RIPE region still has the most prefixes and it was actually fairly stable, no big bumps and spikes in there. Just before the� OK it's actually 12 months, sorry. At the new year's edge we had some interesting things leaking from Indonesia, right before the last RIPE meeting we had some interesting leaks coming from NASA and it says 6939 here; at that time, 6939 was actually a bit slop eon filtering garbage coming from sites. They have really fixed up their network by then and I thank them for it because it really improves things. Since then we have pretty much only seen major bumps from the APNIC region and we have a nice little bump from AfriNIC here which is completely new and will be on a later slide. Looking at the prefixes by country in the RIPE region, nothing unexpected here; Germany upfront, UK, then Netherlands and also no big instabilities, anything worth mentioning. Prefixes by country, this looks much more exciting. Actually, this line that is producing all the instabilities that can be seen in the global table, so all of this is coming from Korea, more details later on.
Doing a short sidestep to the AS numbers, we are up at 1137 unique AS numbers participating in the v6 BGP now which is quite some nice growth, 200 more than at the RIPE meeting in Berlin so things are really pick approximating up speed. The detailed distribution, who is announcing what is in there to read it up but I am not going to read it to you. This is a new slide. It's plotting the number of ASs of different kinds over the last nearly two years since January 2007. The top line is the number of total ASs, obviously that can be seen in the BGP table. This one is the number of prefixes that only originate stuff, the number of ASs that only originate prefixes and do not give transit for others. This is ASs that originate stuff and give transit and this is pure transit only ASs. I think this is pretty normal distribution, it's there for reference.
Growth in IPv6 BGP is nice, but this time I wanted to put this into perspective to what is happening in the IPv4 BGP table. And there is quite prominent growth since the last two years. It sort of looks linear, which is a bit weird, but it grew from 24,000 active ASs to 30,000 active ASs over the last two years, which is� which I find a bit scary, actually, for a number of reasons. If I put this into perspective and say sort of I want to know how many� what percentage of the AS are doing v6 already, by just dividing the number of AS that have v6 through the number that have IPv4, not taking into account exceptions like a v6 only AS or something, just dividing the total number, I end up at this graph which seems to be sort of very nice growth, but if I look at the number up there it's 0.038, so let's put this in another perspective; the thing I want to see in the end is the ratio to be near 1, that means all ASs have v6, sort of taking v6 only and v4 only ASs out of it, but we actually need to cross the line and have more AS on v6 and we are down here, so there is some work left to do.
Yet another view to the ASs, this is plotting the average number of prefixes announced by N AS in the IPv4 BGP table and 6 table. It's using the mean average, not median. In IPv4 we have about 9 to 9 .5 prefixes per AS; in IPv6 we are up to 1.3, so one of the arguments I always used to explain why IPv6 could help routing and router vendors is that the routing table might back lot smaller and just looking at these numbers and doing the maths, indeed if the same amount of AS are active and the ratio holds, then we have 7 times less prefixes in the global routing table. I think we will see that curve go up over time when people start to announce deaggregates and do traffic engineering with more specific and stuff like that, which seems to be sort of unavoidable but right now, I am quite happy with the result.
OK, this is all stuff that I am going to skip. It's all slides, so you have seen this before and the up dated data is in the talk which is on line, but it's not something exciting new that you might want to see.
These prefixes that are up here have been shown in Berlin already. At that time� well actually, it's� D blocks that show up on the slides going up and down and up and down, disappearing, reappearing, disappearing again, these are two different research networks in the Asian region; this is Korea, this is Thailand. They both have their 32 in the table originated by the same� original AS� in that case, it's a different AS but both are belonging to the Korean research network, and then they have lots of 48s, something like between they 48s from one block and 25 from the other one which are being leaked inside the research community to Internet 2 which is these guys, they leak to NCSA, they give it to open transit and open transit tries to give it to the world. Actually, most of the world is not accepting it from open transit, but if you look in the public looking glasses you can still see enough networks that see these paths and obviously the normal transit path to these networks is completely different from this Internet 2 things.
Since ten days or so, we have the same thing coming from Egypt, so that is the first time the AfriNIC graph actually showed a big bump like that. That is all these prefixes, it's 20 of them. Interesting enough, nicely numbered in a decimal way so it's going from nine to ten instead of going from nine to A B C D E F and one zero, but that is just a side anecdote. I am not exactly sure what is happening here because this is sprint announcing the 32 and Egyptian network providers and the Egyptian ministry of communication transiting the 48s to Internet 2 NCSA open transit, it would be interesting to have some background information on which one is actually intended and which one is actually not the proper path, since there is no routing registry for that region I could use to check this, I just pointed out it's weird it's coming again over Internet 2 and these guys have a reputation of doing somewhat uncoordinated things.
Internet 2 again on Tuesday this week I think, I saw an e mail with a trace route hitting one of the IPv6 operators mailing lists, bitterly complaining that traffic from Germany to Germany went over the US and Hong Kong and it's basically research networks not really having coordinating routing policy yet again, so this is the� the target is the router from AG Net in Frankfurt which is the prefix this is sitting on is being visible at the Hong Kong Internet exchange because they are peering at the Hong Kong internet exchange. This is the Korean research network. They are giving this prefix to Internet 2, Internet 2 is giving the prefix to Jayon, which is the European research network, Jayon is given it to DFN which is German research network, which wouldn't be a big problem at all because, well, then you have DFN is actually peering with AG Net in Frankfurt so off very short path and a long path, which sort of seems to suggest that the short path is is a good way and the long path is not. But, now enter local preference. Jayon says everything coming from the research community is so great that we will local preference it and prefer it to anything else we see in the world. And DFN says everything coming from Jayon is so great we local preference it and prefer it to everything else we might see so DFN actively prefers a very crappy path, just because it's coming from research network, which wouldn't be so bad if that research network wouldn't be Internet 2, who have no clue about distributing prefixes, sorry to use these harsh words but it's always them showing up.
Completely change of topic, this is something for the smiles. One quite famous person in the network community decided that the RIPE IPv6 PI policy is being too slow. There is no policy and it is unclear at what point in time the policy would be there, so he looked at old RFCs and found one that says "if you have an OC and /S*UP address, you can use that, tack it to binary 000011 and make an IPv6 address from it. That is what he did. So 339: 7522 F: Prefix in the global routing table. It was accepted by his upstream provider and happily distributed around the world. People of course noticed and got curious and sent e mails this way and he replied that oh yes, the IPv6 policy in RIPE land is not good enough and I need IPv6 at home so I just created my own prefix. That is all in this RFC. This RFC has been declared historic because it was badly written, didn't really take into account anything and, anyway, this was sort of protest to the policy, we are working on a policy, so things get sorted out. We have some news from SISCO, I have been talking about ghost routes in the past where one router forgets to send or to withdraw to his neighbour when a prefix disappears. The previous ghosts have always been related to the operate and medelling with the filters of the router while the router was in the process of considering updates. The most recent IOS version for 6500 routers have a new one where it's just a matter of random things happening inside the box, when they will just forget to send an update. So you have router A that shows I have learned this prefix from router B. Router B says "I don't have this prefix." And this is causing lots of trouble. This is an Owen back, it has been fixed so if you just happen to be ununwill bely enough to use that version upgrade to S X H 3 A, if you have 12 .4 T versions upgrade. It's hurting you and your customers. It affects v4 and 6, I just had no v6 example here.
And that is basically it. All the rest is well known stuff and I decided to skip it before I actually saw David waiving at me. Thanks for your patience. One thing: Let's not discuss the Internet 2 routing mess right now, we have a presentation from Martin levy coming up who is bordering on the same thing and I think it would be more useful to discuss the specific thing after his talk.
CHAIR: Thank you Gert. (Applause).
There was a quite a bit more content than I expected, you said it's going to be just a couple of slides. That is not a problem. Let's be clear here. Anyway, are there any questions? No questions. Really? OK.
SPEAKER: I am also happy to discuss this off line with you. Just send me an e mail.
Lorenza: Why are you accepting stuff that is outside the unicast block, 2003 is not hard to filter?
SPEAKER: Good point, yes.
AUDIENCE: If nothing else.
SPEAKER: Yes. It didn't propagate everywhere but enough people saw it to raise curiosity.
CHAIR: OK. Thank you. Then the next presentation is IPv6 penetration in .FRTLD by Stefan. Then we will start with that right away.
Stefan: Hello, everybody, I work for AfriNIC which is a dot F R TLD registry. We have seen a lot of interesting presentations about actual IPv6 traffic on the network. My presentation will be a bit different; I will, for those who were at the DNS Working Group, it's the same talk, yes, but I will focus here not on the tool that we use for the survey, but on the results for IPv6. Because to get actual IPv6 traffic, you need to publish something in the DNS Tully, it's not completely true: For instance, bitter and tracker can distribute IPv4 and IPv6 address without the need to publish anything in the DNS, but for ordinary traditional Internet services such as e.g. D P you need something in the DNS because very few people put IPv6 in URL so you need something in the dance to direct people to your service so it's not sufficient to have it IPv6 enabled, you need to let people know about it.
So the data presented here where obtained from measurements in .FR zone, which is 1.2 million domains. I skipped� what we measure in IPv6: We check to see if there are� records for the NS and M X of the domain. We also check if there is a quad A record for the domain itself, wwwdot the domain, wwwdot IPv6 dot the domain. We also check if the machines which are announced via this record do reply or not. So let's not wait any longer. The result: 4 percent of the domains in .FR of at least one quad A for one of the three big services, web, e mail, MEM server. It seems not so bad for persons. On this domain can be regarded as having started the transition to IPv6. Sometimes, quite recently, because this are the results for October N July it was not 4 percent; it was less than 1 percent because 1 big web hoster in France decided to add a quad A recall for every DNS zone it controls. So the number overnight jumped from 0 .6 percent to 4 percent. So at this time we are 4 percent of domains with at least 1 quad A. Unfortunately, if you are looking for domains with other quad A for all of the three big services, INET NUM service, e mail and web, you have only the 0.3 percent which gives you an idea of the amount of work that we still have before every domain can live, can survive in IPv6 only world.
If you� also, many of the quad A, of course, many, some of these quad A go to strange addresses. For instance, people publish local host address in the DNS or link local addresses in the DNS, too. Opportunity test, so if you take all the addresses at the present time, 92 percent of these addresses work which means that, for instance, for web server, we have a quad A, we connect, we do get /. In 92 percent of the case we do get a reply, even if it is for 3 or 500 it is a reply which means that IPv6 work. For those that don't work, in the majority of case it's connection refused. In a few cases request� request of add work on get does not work because get requires full page which is typically over 1500 bites and then we get into MTU, ICM filtering problems etc.. this number 92 percent is if when you take every address, if you keep only distinct unique addresses, remember that one address can be used by many domains, if you keep only distinct address the result is not so good. It's 67 percent of the address that work because addresses which are used by a lot of domains are typically on good websites, well managed, etc., but small domains publish a lot of address that goes nowhere.
OK. That is all. If you want to see the complete results, the slides are on the web page, we explain about the tool and so on. I wanted here to present IPv6 results and I will be happy to reply to any questions.
CHAIR: Thank you very much. Any questions? None. OK. Then we move on to the next presentation, IPv6 peering.
(Applause)
SPEAKER: Just for the record, (chairman) we do plan to go a little bit over time, one of the issues that we often have think Working Group is two meeting slots it's a little bit too much. One is is a not enough, so we have this choice of cutting two meeting slots and making the schedule difficult for the RIPE NCC or we just decide to go a little bit over time with our presentations, so the whole meeting schedule fits much better together. So if� if you plan to� you need to go really at the scheduled time, feel free to leave the room but please do it quietly because we will go a little bit over time. Thank you.
Martin Levey: I am going to use this mike, it makes it easier for me. From hurricane electric, I am going to follow on on some of Gert's stuff but going to deal with two different subjects today. Actually, I have a quick follow on, if we are successful at the v6 side of this we will have no sessions, think about that. I am going to talk about two different things, peering and routes. The routing side Gert already started and I am going to cover it a little bit more and I will take the questions or the heat or we will jointly do it, but I will ruffle a few feathers if I K first one is about peering, some good, the bad the ugly and the good part is very simple: There is a lot of exchanges out there that are doing v6. This is covered to a certain extent in each region here in the EIX type sessions bu in reality if you go out and talk to all these guys, the good news is there is more than this but if you go through the major sets you go down to the ones that you want to go find, you find these exchanges, you find that they are doing v6, there is only two or three on here that are still a little questionable, but they are on there for a good reason and then the interesting part about this is that as we went through and we queried every one of these exchanges and I am not talking about the major exchanges we have heard from in the last couple of days but the little bit moreees oweiteric ones, we find they are doing v6 but there is no v6 on the website. So if I want to make a general comment here, if you want to propagate more v6 peering in the world at least on the website for the exchanges, say that do you v6. So what I am going to talk about for a little bit here is addressing schemes on exchanges and really quickly because it's unclear which traffic this should go on and I am trying to catch up on some time here, but what I am going to mention if you look at the various different exchangeses you will start seeing different numbering schemes. This may be a littleees oweiteric, looking at the numbers here but I am going to show awe couple of examples that are pretty simple, the 1, 2, 3, 4, 5 as people show up the use of the equivalent of the v4 address to the or the end of the v4 address to the end of the v6 address, and then the use of the ASN number. That is the one I want to point out, make sure if you are setting up this type of system or if you are running it today, make sure you can handle 32 bit AS numbers which means that you need, you know, at least 3 areas in the address to handle that successfully. Pictorially, this is sort of an example of some of the exchanges that we are at. There is other ones out there but you will see all different methods. One that is going to change, obviously, Hong Kong internet exchange which is running on a /120, let's just say that is a very historic v6 exchange, it's been doing it for quite some time, but it is, it will change to a /64 sometime soon. So, is it bad that they are all different? It's not bad but think about it from an operations point of view. If you look at this from an operations point of view, having a little bit of consistency within the /64 that is running on every V LAN segment or Mcsegment is actually� would actually be useful, not the end of the world. The interest point is even if you use the AS number inside the address, you better do it right, and you better do all of the various things that you normally do in the v4 world right. So this is, again, some of the issues that operators are coming across at the present moment. A particular exchange, I won't mention it, in Hong Kong, doesn't actually have any reverse DNS for v4. And hasn't for many, many years. That wouldn't be accepted in the v4 world so let's make sure it doesn't get accepted in the v6 world. You have some interesting reverse DNS because no one took v6 seriously and in an exchange in California. Those took a fair amount of time to get cleaned up, they actually weren't even correct, they were historic and didn't match the particular operators. That happens it, happens a little bit too often. The last point, though, is that if you are looking at websites for exchanges where the participate pant is listed and the address is listed, make sure the address is v6 and v4 listed. The world is not just singularly v4 any more. So, it gets a little bit ugly.
So, obvious recommendations from what I just said: Please if you are building an IX don't invent yet another scheme for reverse DNS. Consider making sure you can upgrade and handle 32 ASNs, if you are encoding AS into the IP addresses. And, you know, basically just the last point: Take the reverse DNS for v6 seriously. OK. Let's talk about routing.
The one slide I did not put on here and the one that Gert and I have been talking about via e mail and a few other people has been this interesting leak out of Sweden for O2100 /7 address. We filtered it, and we have recommended that anybody else doing a going on list is also adhering to (/PWO*G) RFC 448 and adding the� O2100 /7 to the list of addresses, just like six bone is now in the Bogan list and is not accepted anyway. We filtered that route, we are trying to convince as many other people to filter if or at least make sure they have got the Bogan list gets updated to match that. Did I not put a slide on it but it's been discussed publically and privately. OK. So this is the issue. It's an operational issue. It boils down to the fact of can we survive in the v6 world, are we surviving in the v6 world with full routing tables, purely because there is enormous amount of route leakage, some of the examples that were given by Gert, I have got the same ones and going to a talk about them from an operator's point of view. The reality is and we are going to pick on research and educational networks� the reality is that there are full v6 routing tables available from any of the v6 transit providers, that number of transit providers is increasing. Again that is part of the standard graphs and those /TKHARB routing needs to improve, but it needs to improve with the help of getting rid of all these various leaked routes. This is nearly close to the example that Gert used. It's just one off of the current table. In this case /AO*EUP again I am giving awe Hong Kong example but it could be different. Sorry 46 /35 is the Hong Kong internet exchange route server, which is an interesting place to go look at routes anyway. It's showing this route that was discussed but in this case, showing slightly different; China, Japan, Japan, transit provider into Japan, Tiscali. If you look at this route and I have just used this as just as an example, I am not picking on anybody in this list, it is a classic example of a research engineering network using this local methodology where they believe everything and override any existing peering that may have a shorter path in the world. Every one of the entities on this list and on others has had e mails from us talking about the operational aspects of this. The other example and I am trying to run through so we catch up on time, is that if you go look at this in various other places in the world, you start seeing this same repeated pattern, so what we have done and I believe others are starting to do this now, is to go back into all of these research environments, ask them to clean up their routing and to go back to this whole issue of you don't need to run a leak everything to everybody methodology for routing in order to be successful and get a full table. The example� again, there is a 100 different examples of this, but there is a small ones: Routes of British Telecom showing up through Korea ending up in Hong Kong for what looks like� not looks like but is commercial addresses. All of this case is the standard routing and filtering and either community management or the like that is used in the v4 world that needs to be done in the v6. If you are doing it in v4 do it in /#*6. Technically shouldn't be any different. We are long, long past the Davis needing to share large amounts of routing tables in order to get a full view. That full view is available.
There is a couple of examples in here, some of which I can't show out of our network, the example of 2001 4300 route showing up as a bunch of /48s and 32s, we just see the /32 and again, that would be no different than making sure that the v6 world has got the same filters as the v4 world. If you can go back, I am going to give one more example of something that has happened: The whole issue of the German route going all the way through gee ant and out to Hong Kong and back again, is exactly the example of the local� something would you never do in a commercial world coming into this, so filtering, cleaning it up, making sure that not only as a commercial network having the right type of routing table but actively and I may say a slow process of network by network going through and finding all these extra routes and getting rid of them. So, you know, is this a problem? Am I just, you know, talking into thin air, no the answer is it's really. It's what makes a� it's what gives you the different approach to v6 routing tables than v4 routing table. The v6 needs to be in the same mode as v4 routing table and that means this as is basis of being able to route needs to change. So, you have heard it, I am going to repeat it and I am going to just take the questions after this. We are going through it network by network trying to convince them to change. It's actually seeming now that unless all of the networks that we have mentioned here today which would be the Korean network, Chinese, G�ant in Europe and Internet 2 in the US, all of those are pretty much going to have to change their mindset pretty quickly and at the same time in order for this to have any major effect on the world. But it also means that some of them need to think about their whole transit strategy. Every network has a transit, it doesn't mean they are announcing all their routes to the transit which is why we start seeing missing holes. If they are not meant to be public routes, don't announce them, there is nothing wrong with that. This actually may reduce slightly if it ever happened, the number of v6 routes on the global routing table but as some research networks have said, they are routes that don't need to be there in the first place. The final point is we are trying to set customers' expectation. The good news about the number of routes in the v6 world is that customers are getting clever, and they are asking, how many routes do you have in your commercial network and they are using that as a measure, and what we have come back to is although we have a large number of routes, it is not a valid comparison. The important point is to make sure that those routes are understood, which need to be where and maybe that will mean that we will end up with a different number of total number of routes but it won't be much less we have got at the moment. I will take questions, I will take the heat for various roundabout routing that has occurred, at least on our backbone, but as those filters and as the changes go in, they will, you know, that will change.
Randy Bush: We are running well late so I will be brief. Could you, somebody put together a recommendation on the address assignment exchanges to AS number so we are doing similar instead of people have to search out PowerPoint?
SPEAKER: Yes� Randy: �
SPEAKER: It's maybe into the question. I can take this off line anyway because all the data is there, it can be documented, maybe� I mean documented as these are the five methods today. As an operator I have a preference but I am open to send that out to the IXs and see what they say.
Randy: The now not used was recommendation.
SPEAKER: Got it.
CHAIR: So we have a volunteer and that is you?
SPEAKER: You heard it here, folks, yes, I will write it.
CHAIR: Thank you very much. More questions? No. Then it's now� now we have a presentation on IPv4 and IPv6 coexistence, that is again a hot topic in IETF and we would very much also like your participation in giving advice to Jari for IETF still needs to do in that area because there is renewed interest in the IETF, there is work going object and we basically need your input on what needs to be prioritised, what is more important etc.. feel free to interrupt his presentation because this is really about discussion and providing inputs and seeing what is important.
SPEAKER: Thank you, David. So, talking about the coexistence between the two IP versions and I will go over some background first why are we doing this, what is the problem, talk a little bit about the IETF activities that have been happening and will happen in the near feature, go over at high level a couple of solutions and what kind of problems can be used to solve and wrap up with some next steps.
So starting with the moat vase, I think at the time that the IPv6 was designed and its trance cyst enter tools were designed I think we had something like this in our minds that by the time the v4 addresses have run out, we had either completed the transition to v6 or well under the way. But I think the reality is probably more like this: That we are nearing the exhaustion of the pools, yet we have, you know, quite a bit of implementation deployment but not so much user IPv6 for actual traffic and we hope that, you know, as we will host a pool will probably change and I see some signs of increased IPv6 usage and deployment, but it questions the assumption that is we had during the design, that the situation is now going to be different; that instead of being able to run the two side by side very easily, we actually are in a situation where one is quite constrained, the v4 is going to be very con� strange addresses and yet you have to move to IPv6 and how do you do that, that is the question. So does this cause us to reconsider whether our IPv6 deployment 2 box is sufficient or not. (Toolbox) or do with we need some new tools to do with IP address shortage without even considering 6 at all. We have had discussion in the IETF about NAT PT which was developed some years ago and then deprecated I think two years ago and we got some input that actually something that we need or we need this solution in that category and there has been some fairly significant discussions in the IETF going on since about a year ago, and we have got a lot of good input on service providers and network managers and that and basically I am here to get some more feedback.
And I would also like to say that this is actually quite important, that as we move towards even more address shortage, that the way we deploy IPv4 NATS is going to change. The current model is most likely that we have given one address for a subscriber and the subscriber then NATS himself if he needs to. Going forward that may not be possible so we have to do, you know, perhaps double NATS or triple or something smarter if we can find it. We can't deploy IPv6 in all situations where we would like to for the fundamental reason in order for me to actually or I can deploy, I can turn it on but actually using it is hard because that means that the other guy also have to have IPv6 turned on and operational before I can actually talk to him. And I can't predict the future, I see many potential outcomes of this, you know, some good, some bad but the question from IETF perspective has been. . What can we do to help the situation? Are there some new things in the toolbox that we should develop to help IPv4 and IPv6 coexistence and IPv6 adoption? And I also wanted to insert a disclaimer here that, I mean, we should not have a one track mind, that we had this religion earlier and now this, it's not like that. The existing tools still continue to be valid and even recommended for many situations, so as an example, my own network at home has, you know, v6 and IPv4 with the Nat, dual stack with the Nat, and my company does in a and it's probably something that many networks will continue to do in the future. Similarly, the various tunneling mechanisms and transition tools that we have continue to be valid. But we also need to think a little bit about this new situations or things like, you know, in the dual stack case if you don't even have that one IPv4 address what do you do? Should I go to double NATS and then together with dual stack or what is it that we should be doing. Or if we run out of private space on a large network what do we do? It's also important to sort of, not to search for the silver bullet that we all situations, it's actually quite different depending on what we need and there will be several solutions, there already are several solutions in this space and we will add a few more.
OK. So recent IETF activities: The summer we had a large number of discussions, many, many hours in Dublin on this topic. We had an entry meeting at the beginning of this meeting in Montreal, as an outcome of that or in that context we rechartered one of the groups in the Internet area to develop additional solution in software. And we are currently undergoing (interim) a proposal to add more work or new charter for the behave Working Group in the transport area for some additional solutions. I will talk about those solutions in a moment. Or some of those at least. But first to Montreal: This was an interim meeting quite well attended, I think, there was 60 people on site, and maybe 20 or 30 connected remotely, so at least in my experience that is probably the biggest IETF interim meeting attendance that I have seen. So we can say that there is a lot of interest on this topic, which is good. The meeting focused on improved IPv4 NATS, tunneling to solve solution to address RFC 1918 shortage and IPv4 IPv6 translation. The outcome of the meeting, there was strong consensus that we do need both tunneling type of solution and translating. We have to talk about when they are applicable. There is relatively clear priority if you can do dual stack you should be doing it. If you can't do that, maybe you should look into some of these tunneling solution that we are developing. If you can't do them either you have got to go to translation which implies you will lose some of the end to end aspects but that is still better than nothing. And the other take away was that before the meeting we had a big number of somewhat competing solutions, and I think we walked out of the meeting with better understanding of how they relate to each other, the authors had been working since then, I think, in a better modality, they talk about how one piece is an extension of another one rather than this is my thing is competing with yours.
OK. And then going forward towards some more of the technical stuff. I am going to go over three examples, solutions that we have been talking about in the IETF, and try to show what kind of problems or network situations they can be used to solve. And this is by no means an exhaustive analysis of this, and all of these are also moving targets so may not exactly match what is in the current drafts. I will start with dual stack light, and that is something in the software Working Group coming from and you can actually address couple of different problems, and I will just talk about one of those right now in this slide, which is running out of R C 1918 space. Here you have a large provider that has cable modems, addresses for subscribers, addresses for boxes or something like that, and they are currently using private address space for those, they are giving private addresses for customers perhaps they have double NATS or what other arrangement is. And such large network that you start to run out of the space and you are faced with a decision what to do, could you perhaps split it into different areas and it's with overlapping space, maybe that is a little bit complicated and double NAT and I don't know, or can we do something smarter. And the proposal here is actually (smarter) quite simple. You just make the network IPv6 only and since you have to deploy or provide IPv4 service for anyone, anyway, you will tunnel IPv4 over this network but you can still address your end points within this network with v6. And this is typically combined with a NAT on the service provider side, and if the NAT is clever enough to look at the interface or the tunnel addresses (caps) supposed to test the addresses inside the packets you can give the same address space for all customers, all of them can have private address space for instance and you can still do the NAT thing. The other benefit of the scheme is that you can share one address for multiple subscribers. And again this is quite simple, there is nothing new here really, it's a combination of existing tools, existing tunneling mechanisms, existing NAT and so. Maybe DHCP option is needed somewhere but other than that it's basically very simple and the good thing about this is that� it's trying to solve a particular problem but it also has the side effect if you do this you will deploy IPv6 all the way to the edge of your network, including into the subscriber DSL models or something like that, if do you that it's quite likely you will eventually also deploy IPv6 service to the end user so it's sort of� you are getting there, you are doing something for v4 but as a side effect you are also making v6 deployed further.
And another solution I wanted to talk about a little bit is port borrowing and this is aaddressing the same or other problem from the previous slide which was the public IPv4 address or� can you share one address between multiple subscribers? And this is doing it in a slightly different manner so that you basically give every customer or every subscriber gets an IPv4 public address but doesn't get to use the entire port space, they only get ports 0 to 2000 and next one gets 2000, 4,000 and so forth. And you can implement this in various ways. Randy talked about earlier this week the mapping, A plus P which maps the IPv4 packets and ports into IPv6 addresses and packets. And that is one way of doing it. You can also see there is an extension of the tunneling approach, and maybe the details don't matter at this stage so much but, again, another nice benefit of this is that you do, like in the previous one, you can� you will get v6 as a side effect. And this is discussed in behave Working Group, it's not not in the stage where we say we will work on it and develop the solution we are discussing it and I guess that is one of the things that we need to get feedback on is this relevant for your guys or useful. And the third solution that I wanted to talk about is translation. So this is basically the old NAT PT area, IPv6 host reaching IPv4 host, and an example application is in my slide here, is IPv6 host connecting over the IPv6 Internet to a network that has this translator box which maps the v6 packet to v4 packet and sends it to a server, sort of the client is v6 side and the server is the v4 side. And this could be for a number of different reasons, perhaps you have legacy servers that can't be upgraded to v6 and you don't have public v4 addresses or can't put them on v4 site either but clients are capable so why not could it v6 ways. I am told windows 7 has feature called direct access, BPN like feature using v6 only and IP Sec to connect from a client or PC to home network directly without tunnels and since they only support v6 on this feature, the way to connect to V� v4 only servers to be to deploy a NAT PT and that is what is currently being done but the question is can we improve that and that is something that� that NAT PT solution had some drawbacks and we are now looking at NAT PT attempting to develop a better solution that don't have at least all of those drawbacks. And this is happening and my slides are funny here. I don't know what happened. I am opening open office and this is mac and PowerPoint so. More on translation. The example I show you on the previous slide, it's just that the translation behave Working Group will attempt to address multiple different cases or scenarios so basically the is you idea� your network, you connect with one IP version to the other IP version Internet and then the initiation can be one or the other side so you get four different cases, so the first one here IPv6 access to a set of IPv4 servers was the one done previous slide. Then we could have let's say, if Lorenza wants to have a Google branch office that is IPv6 only for some reason, it's easier to manage, it's the right thing to do or cool thing to try. How do the people in the branch office connect to the v4 Internet. Well, they can translate. Or you could have IPv4 access to it, you know, a set of specific IPv6 servers, practical example of this may be in China they have the Surnet two large IPv6 network, the students develop something cool and the rest of us would like to access it, although we are in v4, how do with do that? We can translate. And the final case is call the last IPv4 hold, the last network on earth that is still running IPv4 and everyone else, you know, the googles and the YouTubes and CNNs are all v6 only so how do you connect to them because you still need to look at YouTube. And what do you do? You translate.
OK. So documents under development after the interim meeting, it's been changed a little bit. There were individual proposals, now they are trying to work together so there is probably going to be a framework document or there is, a packet translation document that talks about exactly how the v6 packets goes to v4 packet. There is a document on how the state is maintained, dynamically and then the DNS part and the challenges in this work are many; the primary ones I guess are what to do if DNS and DNS Sec, that is somehow break that. It's something very important to prevent dual stack hosts from accidentally using a translator and you know not be able to get all the v6 features through we don't have /UT silver bullet here, we can't fix everything that was the problem with NAT PT. We can improve on it, basically in two ways: It was a really bad specification, originally, we can write it in a much better way, specified better, and we can also focus on some of the constraints scenarios and I will give you one example: If you have the v6 Internet connect to go specific v4 servers, if you actually know what those servers are I can set up quad A records and so forth, you don't have to deal with dynamic translation of the DNS or faking of DNS, you can do it you only do the translation part and still that is tricky, too, but it's� you have to do less with DNS, so it's important to, you know, not try to do too much and get into trouble. OK. So that was actually the set of solutions that I wanted to talk about. There is obviously more detail than I had time to do here. I do want to you provide feedback, it could happen here in this meeting or catch me in the hallway. You can go to the IETF lists, which in this case behave and soft wire are the primary ones are or perhaps v6 obs for some issues and we will behaving the next meeting in Minneapolis next month and we are also planning an interim meeting for Malta in January, late January 20009, and this is actually a joint interim meeting between multiple working groups, kind of like a mini IETF so hopefully you will be able to make that. We will be progressing the specifications from behave and Softwire, so obviously it would be good to get feedback on those and we also need to make a decision how to progress the port borrowing and A plus B and so forth work which we are discussing but we haven't actually chartered yet so the question is, is that needed? And if so, exactly how should that be implemented. And that is actually� I will just show you, I am not going to talk about this, but I have a set of pointers on my slides that you can look for further information. That is the mail from interim meeting that we had, mark and myself wrote the document on the different business scenarios where you would need these new tools and there is the charters and all the list information for the Working Groups Softwire and Behave. And some pointers to the individual specifications. (Caps) no one interrupted me doing the talk maybe now it's the time for you to go to the mike and explain how we missed something or how we are going to break something else or. No one is running to the mikes.
Randy: People who are doing IPv6 transition, Jari is one of the point people in the IETF who can get you what you need. If something isn't� he has talked about isn't meeting your needs, now is the time to say it.
SPEAKER: We are not doing this just for fun. Hopefully it's going to be useful, so if you think it is useful, come and say so, or if it's not we can go home and do less work.
AUDIENCE: This is very useful, thank you.
SPEAKER: Thanks. Anyone else?
CHAIR: So to repeat again: There has been a lot of criticism in the past and about IETF doing all kind of interesting stuff that is not necessarily useful for operators, people in the real world who have problems to solve. If you really want to get the IETF to do the right thing we need your participation, either here by giving comments and feedback to Jari or by actually coming to the IETF or being present on the mail list because work on the IETF is really the most important work happens on the mail list so there is no� I mean you don't really to have to travel to all these interesting meetings, nice venues, etc., you can contribute by participating in the mailing list or you can just do a review and send even a private message with your review to Working Group chair or an ARIN director or whatever, input on every level.
SPEAKER: Yes. Let me say that probably ten or more people in the audience who have provided quite bit of feedback on what we should be doing and thank you for that and it's been very helpful. I do want to say we take this very seriously that we have to do this. Otherwise it's going to be a bad situation. So we are committed to doing this.
AUDIENCE: Just from AfriNIC. Just one comment: I am very happy with the take of IETF, the serious take of the subject and I am very happy to see things going forward. What I am not happy about, it's not IETF stuff but it's just people who are not taking serious IPv6 deployment. IPv6 is not a play any longer so people who are applying, for example, tunneling thinks they should, they must watch out tunnels and MTU problems. People who are struggling for having IPv6 decent connectivity are also suffering from this really bad image of IPv6 which is sort of toy. I am sure that many of you in this room have just switched off IPv6 because we are going in a tunnel, in a long tunnel somewhere in Europe. I mean, I am not blaming anybody specifically but this is� this is really my frustration. I am IPv6 advocate and I, like many of you, I switched off IPv6, I blame myself, but I mean, that is not serious today, not to deploy those recommendations which are already in RFC, well documented, please if you are a network engineer please watch out tunnels, please deploy in a decent way, serious way, otherwise IPv6 will blow off.
SPEAKER: That's right. Very good comments.
Randy Bush: I agree with you but there is a cheering side of this. In three years we are going to run out of IPv4. All of your competitors who were too stupid to work on IPv6, great.
SPEAKER: Yes. Let me just mention also that while there is some of the work that I presented has an aspect of breathing more life into v4, but I don't want that to be the only whatever we do, think about how that at the same time moves us us towards v6 as well.
AUDIENCE: Just one observation, a lot of this work is still sitting here in the network itself. The big test is going to comeapplication providers starting to run their applications and services over v6 and we are not there yet at this point in nigh mass way and we might also find some feedback there, which may be critical to what we are doing in the IETF area at the moment. Is there any work going on at the moment to outreach into people who are running games or other applications and software, other than directly in the IETF?
SPEAKER: I am not aware of any. I realise that this is a hard problem that the applicators have to be there as well, and maybe the most crucial thing of course, there is various ways of getting there, IP stuff from you but I guess one of the questions from my perspective is, do you see something that we could use flee do here on the applications side that would help you or help the applications that you need?
AUDIENCE: You are kind of throwing the question back at me. I am sure, the question is getting the engagement, I think. I don't have a specific application in mind other than streaming media applications and voice over IP and video and so forth, moving over to v6. Certainly we are not doing that at the moment but we are stuck.
AUDIENCE: I would like to reply to that. If I have application developer and I knew no users had v6 connections, why would I bother?
AUDIENCE: It's those in the� it's in this transition period I am talking about specifically and these transition methods.
AUDIENCE: Yes but we have to break the chicken and egg problem somehow. It's not in developers' interest at the multihome. We have to recognise that as a problem. So we have to provide seamless transition strategies or something that allows to us get there.
AUDIENCE: That is exactly the point.
SPEAKER: That is exactly right and that has been their rationale behind some of this work, we have the chicken and egg problem, I can't use this unless you are also there but, you know, some of these things make it possible, at least in limited cases for me to deploy and use without depending on the other side. So that is one� whether that is enough that remains to be seen.
Rudger: Well, obviously, application work only happens when there is money to be made and if we don't have the network set up and the consumers doing it, the one thing that would help is, well, OK, and very much in general, is well, OK, if we were actually moving to an API, that essentially hides the distinction between the two network architectures and we are hearing reports that in certain worlds, certain software worlds like Java, that is available and in other cases, not
SPEAKER: Right.
Rudger: And there are other benefits that would come out of that API thing.
SPEAKER: That's right. Thank you.
CHAIR: More questions, remarks? OK. I actually have a comment, but with my grouping group chair hat off. Dave Kessens,. One thing I am very concerned about is the situation where you have a beautiful dual stack IPv4, IPv6 network but on your host that is also dual stack you have different applications running, some that know about v6, some that don't, and I see a lot of opportunity for horrible mix up happening if you have tries technology transition into the network that tries to meddle with your application that knew about IPv6 and were already doing the right thing, while those technology were really only needed for those few applications that just can do it yet and I think this is a little bit underestimated at the moment. (Can't).
SPEAKER: I think that's right. I think we have been looking at that sort of from the perspective of the network doing something that the host IP stack isn't aware of but we haven't really looked at the sort of the application level of the distinction between different applications and that is something to be looked at, yes, it's a very valid comment.
CHAIR: Basically, if you look at IETF and the people who go there, but also like this community there is a lot of focus on the network, but in the end it's application that is need to do the work and, as we have heard also from other people there is a lot of problems there still. OK. Chairman hat on, is there more questions, remarks, issues that you would like to bring up? Then, we have one final agenda topic left over, and that is a very brief one, is there anything that people would like to announce regarding IPv6 events, things happening in the European region that will be happening soon that might be of interest for the Working Group? Nothing. OK. Then I declare this Working Group session closed. I would like to thank all our speakers for their actually excellent presentations and I would also like to thank everybody for their presence here and their contributions to the discussions and, again, thank you for the speakers because they have done a great job keeping to the time limits that we had available and we still didn't quite have to hurry things, so we really have I believe a good Working Group session. Thank you, and see you next RIPE meeting.
(Applause)