Tuesday

Note: Please be advised that this an edited version of the real-time captioning that was used during the RIPE 56 Meeting. In some cases it may be incomplete or inaccurate due to inaudible passages or transcription errors. It is posted as an aid to understanding the proceedings at the session, but it should not be treated as an authoritative record.

RIPE 56 Opening Plenary, Session 2 11:00am, Tuesday, 6 May 2008

CHAIR: Welcome back everyone. Being a short person, I probably bet stand up here. We will start this session by having Detlef Eckert from the European Commission coming here and telling us a little bit about the current discussions that are going on in the Commission.

DETLEF ECKERT: Thanks for the welcome. For sometime talks about IPv6 have sounded like waiting for Godot. Occasionally Alice in Wonderland.

Basically, or in essence, IPv6 has become, from a technical problem to an economic problem. Or more precisely, it is an incentive problem. And this is what we need to change and I believe this is what is going to change, and I would like to speak about our ideas and proposals in the following 20 to 30 minutes about it. And I'm particularly looking forward to your feedback.

Good morning. My name is Detlef Eckert from the European Commission and more precisely from the director general information society and media. So this is what I am going to talk to you today about.

First of all, a brief introduction, who we are, European commission, yes, but more specifically, our department. Why do we need or why we are believing that we should have an EU initiative about this? What are we going to propose? And how are we going to proceed? So these are my points that I would like to share with you today.

So, who are we? We are Director General, this is part of the Commission the Commission is organised according to socalled DGs, Director Generals, a little comparable to ministries in national governments. So we have a foreign office, industry office, so on and so forth. And we have one for information and communication technologies. We employ in our department about one thousand people in all different functions. Our budget that we manage every year is around 1.5 billion euro throughout various programmes. What are we doing besides managing budgets? Mainly, we were responsible for the whole mobilisation of the telecommunications, going back to the '98, where we set the European framework for a new telecommunications framework. Today we are not talking really about telecommunications. We are talking about electronic communication services in order to encompass all the new technologies because when we started this process, we were talking about mainly telephone networks.

We we are also responsible in the area of broadcasting frequent, spectrum allocation, media law, and certain aspects of electronic commerce.

We finance, as I said already, with some substantial amount of money, some projects, mainly in research and development, new technologies, those are called technology companies or technology service providers are welcome to join those codes, and submit proposals.

They are also a number of other programmes which I refrain from presenting to you today, because this is not the subject of my talk. It's just to give you the framework, what is the background from which I am talking to you guys.

Then we have a number of policy initiatives that combine various aspects. We have initiatives regarding I CT and ageing population and what have you. We have a policy initiative or we are going to launch a policy initiative on IPv6.

Area we doing that? What is the background? Well the background, I don't need to tell you much about it here. It's about the IPv4 address problem. And what we see is, in a nutshell, two options: One S we don't do anything anything right now and continue with IPv4, manage the scarcity as it comes by for trading and other options and once it becomes unsustainable, too painful, we introduce, where needed, the new protocol, or maybe by that time, we have found something else. The alternative is that we decide to actively to introduce IPv6, to make an investment, to make a move, to decide we are going for it, even the economics may not be too supportive today. But we expect economics to be supportive and convincing tomorrow.

The arguments in favour and also against for both options. The discussion in this community has shown that this community is largely in favour for proactive approach. I would like to tell you that the European Commission shares this view and would like to take part in this activity to proactively promote IPv6. That's, if you like, the first policy like statement for you.

We already, back in 2002, launched an initiative which was by and large not effective enough to bring IPv6 into the mainstream, but nevertheless, it had some effects. Our research network at European level, I think you know this, gee aunt, is IPv6 enabled and provides us a number of statistics and experience. We have launched about 30 projects in research and development. Looking at all kinds of aspects, even a number of large scale trials.

So, in Europe, we have made a move in the basics, in the technology. We haven't made a move in the economies, in the business, in the real lives of people. Can we change this?

Well, it's difficult to change for an individual organisation. Even the United States Government or national governments in Europe and not even the European Commission is able to say we are now introducing IPv6. So, we have a globalised decentralised process where there is no centralised, if you like, decision. We are now moving to a new protocol. However, in this global game, if you like, public sector and public policy play a role, an important role but not necessarily a decisive role. So how are we going to use that? This is our point of today.

The incentives, and this is why I started, it's an economic problem today. The incentives for individual actors to embrace IPv6 today are not strong enough, because they depend on each other. Not so much from a technical point of view, you can a lot of things today with IPv6, you can connect, you can do it today, but you have to be knowledgeable and there is not much benefit today you get out of it. From an economic point of view, we would call it a public choice programme, and whenever you have those kind of public choice programmes, incentives or public policy with make a difference, they don't have to but there is a chance for them to make a difference. And this is why we have decided for an initiative.

Another initiative, which is slightly different than the previous one. First of all, what we are going to do is, we are trying to establish a strategic objective and this strategic objective is something that we need to agree with all 27 member states. I will explain to you how we are going to proceed what it actually means, what is the instruments at our policy level in order to do that. But the objective would be, by 2010 we should have made a visible step forwards. It doesn't mean that everything is solved, but it should be that we know that we are on the right path. And we put even a quantitative objective to it, we call it a 20 percent target. 25 percent of users should have a good experience when they use IPv6. I come back to this later.

We have, in the pipeline, an action plan which will set these objectives and then we will have four major target areas of activities. The first one is to make the Internet IPv6 visible. That means even you technically connected IPv6, who is out there? Who can you call? Where can you connect to? And this is where we would like to put the emphasis on to get websites at a large scale IPv6 ready.

The second area of activity is timely preparation of the introduction of IPv6. So get ready early; this is what we mean by proactive.

The public sector procurement, where we can do something in our own camp. And monitoring security and privacy implications.

Bun by one, so the four areas besides the strategic objective. So how to stimulate IPv6, reachable content.

First of all, we have to look at the public websites. So this is where we are going to discuss with the member states very soon. How does it work? Well, it works that we meet in what is called Council meetings in Brussels, 27 representatives or more from the member states are coming, and we are trying to reach a policy agreement which finally will be acknowledged by ministers, mainly in a document. But of course we like to have those agreements not as a kind of declaration, but we like to have some hard facts so we would like to commit member states to a certain target, to certain direction and even quantitative objectives. We would put our own website, Europa, and for research programme projects specifically Cordis, where you all find information about our research policies on IPv6 as soon as possible.

We would like to work with the top websites, with couldn't vent service providers in order to get commitments. This means we will have one to one talks with them, we would like to bring them together in kind of networking. We would like maybe to support them in one way or the other, not financially, but through know-how, we are launching a number of projects in order to come up with some, let's say, blue prints for medium-sized websites. We also need to talk to web posting, to those ISPs and network providers that host other websites in order to get a critical mass.

The point here is to get critical mass. There are a number of greenfield IP networks, mainly we are talking about sensor networks but other people also talk about specific application in health or applications in environmental protections. And it is not evident that those networks actually go on IP, and it is not evident that they actually will use IPv6. So we would like to reach out to them in order to make them aware of IPv6 and the advantages it may have for them.

And last but not least in this area of reachable content, we will incentivise projects that are financed by or will be financed by our research programme, we call it Framework Programme 7, those 1 billion euro per year to use IPv6 whenever possible, that means when they have an IP stack and when they face a network protocol choice. Because in some areas, they don't need it, so we are not forcing people to use IPv6, but we are going to encourage them to, incentivise them to do T at least when they don't do it, they should make a conscious choice not to do it and not simply ignore T that's the difference, from ignoring to make conscious choice to use it or not to use it. I think we are running a couple of hundred research projects and that means also, that technologies that are developed with a time frame of five to ten years, will have those technologies in mind.

We need to prepare timely for IPv6. When you are a service provider or even you have your company network and you would like to migrate, when in fact it's not really migration, but, if you like, to introduce IPv6 and then run it with tack, it can cost some significant amount of money. If you want to do this within three months or six months. But if you do this now or if you start now with the objective to be ready in two or three years time, then whenever you have a network upgrade, whenever you touch a database, whenever you upgrade your software, you also think of how do I do this with IPv6? Then, over time, you learn, you invest a marginal amount of what you would have to invest if you do this at once. So timely preparation is key. But that means awareness about it, because you have a lot of different people involved who would not think immediately, when I touch this database or my customer relation bank or whatever, I need to go to IPv6.

We have already, since 2002, launched a number of projects for dissemination large files, 6 disc for instance is one of those projects of we are going to continue with this kind of projects. However, they are not forced by us. They will be judged on merit. So once we get a very interesting deployment projects, we will finance them. If they are not convincing enough, we won't finance them.

We'll have talks with ISPs, so I think this is a good audience here, and probably for a number of ISPs, we don't need to do much convincing, but there is, in let's say at European level, we have a kind of policy leverage and we can make certain things happen and we hope to get a clearer view on where we are going with network providers.

Last but not least in terms of preparation, and this is also something where your feedback might be quite interesting, whether this is really a convincing idea or just a nice idea. We believe, when we look at the five to ten years time frame, we should educate, teach students but also in vocational training, engineers and software developers about IPv6. That means we would like to discuss with member states where in their institutions and training institutions, but also with associations and big companies, where they could add something in their courses, whether it's a separate course or whether it's just an enlargement that people think about IPv6 in those curricula. So what we are looking at is a few partnerships here to maybe launch some projects. We are already launching a study about it. It will be a kind of method study to see who is doing what and we will have second half of 2009 a conference bringing member states and stakeholders together in order to discuss education and training. It is a little bit similar with like security, five years back nobody really cared about secured, well some did, many others didn't, and now it becomes more or less mainstream to introduce security curricula in computer courses and for everyone to become its business. There is a problem in incentive. If something is everybody's business, it's nobody's business, and this was the case in security. So you have to break it through to make it everyone's business.

What are we proposing next in public procurement? Well, we do the same a little bit with the public websites. That means we need to get member states together, and we need to have their agreement, their network contracts and their equipment, similar to the procurement policy in the United States will also be IPv6. We know from a number of member states, this one where you are here as a guest in Berlin, is moving towards IPv6 in their federal network. Tomorrow and the day after tomorrow, 20 KMs here there will be a conference about the German IPv6 summit. They are discussing, amongst other things, how to introduce IPv6 in the federal networks. And one of our concrete proposal is that we would like to set up a round table of the member states CIOs, the chief information officers or system administrators, plus the Commission ones, so that we discuss amongst 27, what are they doing in their federal and regional networks, and I am really, really looking forward to that discussion and I hope we will have the first one in June.

For our own network, we are requesting already IPv6 capability in all network contracts. We are going to ask for an IPv6 address space, and we are starting very soon with internal trials and projects in order to see how we are going in our own networks, apart from the websites, Europa and Cordis.

Security and privacy issues, we are not going here to say we need IPv6 for more security. Our focus is rather introducing a new protocol like IPv6 and the new equipment which goes with it require some attention, because for sometime you raise some new issues because the way you architect your security in the network is different to a certain extent from IPv4. New opportunities but also new challenges. So we need to look at the features in security products such as fire walls and the support, so we are going to study this, how it's going to develop.

We would also like to disseminate some best practice. How that significant remains to be seen. We have a number of projects. We have a number of contacts. So we will see which is the best way to move ahead.

There were, as regards IPv6, a privacy problem in the sense that there was a unique identifier through the [unclear] address. And this has been solved in the protocol in the meantime, but the privacy or the data protection officers in the European Union both at European level, but also at national level, have still raised concerns, and somehow wherever you go you will find why isn't it a privacy problem if you can be identified always with your IP address and see what is happening with all the surveillance and your freedom, what have you. Personally I believe much of this concern is overstated. Certainly it can be dealt with, but definitely we need to monitor this and to be ready to answer questions and to address problems as they may come along. So what we are going to do here is to monitor the development and have some consultation with data protection officers and when needed, with law enforcement people.

This, by and large, are the action points. Behind all this is a tremendous amount of work, because when we talk about partnering with, or raising awareness amongst, for instance, developers, software developers, or network administrators, system administrators, what does it mean? We are talking about a couple of hundred thousand people in Europe. How do we reach them? So, this is our problem, how do we reach them? They are not going to read a policy paper from the European Commission with all our euro jargon. So what we need to do is we need to find partnerships with big companies, for instance, associations but also organisations like you to reach out to the community, and to organise the right way to bring it around. But definitely, I hope that our policy support is already a certain backing for those of you who are actively promoting and introducing IPv6.

So, my last point, how are we going to proceed? I already indicated a few things, how we get into reality what we have been putting on paper.

So, first of all, everything I just talked about to you is part of a policy paper in euro jargon, it is called a communication. I always smile when my colleagues talk about the communication, because this doesn't mean anything to people outside our environment. So it's a policy paper; it's a paper that says what are the European Commission thinks it should be doing and others should be doing, favourably others should be doing, in the coming years to solve a certain problem. So we have foreseen the adoption for 22nd May for some particular reason, there is no reason not to adopt it today, but it's just we set this date.

We have a launch event in Brussels on the 30th May, having some panels, discussing some issues amongst interested parties. So have a look at our website and maybe you even want to join us on 30th May.

We will have this discussion on common actions together and I already mentioned the framework to do this, there is a formal framework; this is what is called Council, so this is where member states meet and discuss the proposals of the European Commission. Normally this takes place in Brussels in a specific building, and we go there through a number of points. So we hope to get a formal agreement, which is written, with commitments from member states. And then it doesn't become only declaration of will of the European Commission; it becomes an EU declaration with 27 member states behind it, and that is also something.

I already mentioned that as part of this discussion, we are going to see a kind of networking amongst the CIOs of the member states. We have already launched a number of studies. One study about curricula, it's not really launched yet but we are going to publish it soon. Another one about matrix and there are already a number of projects on the way as a result of our first calls in the research programme since 2007 and 2008.

Then, we are trying to do something. It would not be that ease he but not difficult either. It's measurement progress. So we envisage a 2010 time frame and we don't want to continue endlessly with a promotion activity, so we have set a target, okay, let's see 2010, what is happening. But by 2010 we have objectives. And we would like to measure progress towards this one, so we are launching a study about those matrix, a service that helps us to see whether our activities have any impact against the development in the marketplace. And we will, in particular, do two implementation tests and your reactions might be quite interesting to that and my thanks to Daniel because this kind of implementation test came out of a brainstorming meeting in a Dutch cafe. I was about to say coffee shop, but that might... that might have some other associations with that. Hopefully you are not going to say that proposal looks like it were coming out of a coffee shop.

So, it's becoming a kind of test where we would like to see, something like you are doing tomorrow and the ITF did recently, and that is to see how it looks like when you go IPv6. And if we can measure that randomly picked users to a 25 percent degree, can go on line and enjoy most of their services and websites, then we have reached our target.

And last but not least, we will then do a stocktaking in 2010 and we'll ask ourselves was it worth the effort? Where are we? Can we say, okay, now it's done, we can do something else? Or do we need to do one, two you three years more? So, we would like then to take stock and see where are we going from there. And I really hope that by working with us and sending us an email, or participating in our events, maybe even participating in some of the projects and hopefully today with some your comments and suggestions, you help us in this process. In any case, we would like to help you in your objectives to make IPv6 a reality and no longer a waiting for Godot. Thank you.

(Applause)

Thank you very much for that presentation. Anyone have any questions or reactions?

AUDIENCE: I am Rob, in the first place, Detlef, thank you very much for a very interesting presentation on a very challenging programme, I think. This presentation was sort of introduction to your programme of action for the next year and a half or two years or two and a half, 2010 has an early date and a later date. I think realistically, if you were to achieve your goals by the end of 2010, I think everybody is still very happy.

I will be very interested in coming to a few RIPE meetings in that period to have a regular progress report, do you think that's feasible?

DETLEF ECKERT: That's definitely feasible, yes, we can give whenever you like a progress report. No problem.

AUDIENCE: It should be of interest to this community, but it should also be of interest to you and your team who are working on this project to have the opportunity to report what you have been doing, report stumble blocks you have found especially I think we are interested in that, and in general, keep the flow of information going.

DETLEF ECKERT: No problem. We will be, at any time in your meetings and report whenever it's good for you and for us.

AUDIENCE: Well appreciated. Thank you.

(Applause)

AUDIENCE: I look at this, you know, it certainly seems like a warm breath of progress which is excellent and good to see, but I can't help wondering that the situation we find ourselves in today is not a situation because of ignorance, or a situation because of lack of information. There is something inside the dynamics of this marketplace, the dynamics of what we sell to whom and how that has created this situation, having a short time to do quite a lot. Does your study and your work here include some effort in your research of measuring and understanding, but some measure also of understanding why are we here, and to what extent there are mechanisms at a public process and public regulatory area that would assist industry out of the hole that it's manage today dig itself in? I suppose I am saying, is it more than promotion? Because somehow, where we are seems so anomalous for an industry that prides itself on information, prides itself on understanding what consumers wants, prides itself on actually being consumer focused, yet somehow we seem to have miss [unclear] do you envisage studying any part of how we got here?

[unclear] this is an interesting challenge to us. First of all I agree with you that it's anomalous situation we are here and I tried to explain it very broadly by saying it's an economic problem today and it's an incentive problem in particular. And the fact is that the individual incentive to move, to do something right, if you like, is not strong enough, because we all depend on each other. Now, how do you get this public choice problem solved? It's not easy and there is no guarantee that we will succeed. We will make one contribution. If others don't follow, our contribution will fail, absolutely. However, we believe we see, and this comes to your analysis, we see now an increasing awareness and willingness to go ahead. So we would like to support this development.

Now, we haven't specifically decided to study exactly what you said, to a certain extent it sounds to me like finding better business cases and convincing arguments to move in itself. We thought that has been studied and published very often; that's why I was saying this was this kind of waiting for Godot kind of things. But your suggestions make me think that we may put more emphasis on it again, instead of only measuring the matrix or the progress, that we also measure the underlying factors which is driving us, and see whether we can find some better answers. I take this as a take away because in that clarity we haven't thought about it. Thanks for that.

AUDIENCE: Excuse me for dragging things to layer 7 and below. You said the challenges of security are different in IPv6 and other than the weak vendor support, which is across the IPv6 spectrum of course, what's different about security in IPv6 than IPv4?

DETLEF ECKERT: In essence, that's what I am saying, in essence there is no difference as such, it's in the deployment. Today, I mean, people are used to deploy IPv4 and sixth on IPv4. And they have a change of security products and when they go to data in the marketplace you won't find the same range of products and you don't find the features necessary and so on and so forth. And, in addition, what you have is a possibility, through the wider address range in IPv6, addressing network interfaces in one device, you can segment a security architecture, let's say, more targeted to your application and to your users than you have. Today you have one security policy for a company, by and large. Increasingly you have different security policy for the move privileged, both for the management board and for the, for those that are really knowledgeable about it.

AUDIENCE: Thank you.

AUDIENCE: Michael Dunne, BT. I think that if you went to the CEOs of most of the companies which we work for and ask them what kind of a business are you in, most of them would say, we are a telecoms company. They wouldn't immediately think of the company as being an ISP. Now, part of the senior management team at all these telecoms company is somebody who is concerned with all those databases you mentioned, those servers where you suggested that there was a possibility to do incremental improvements over time. Those people who are in charge of this in the telecoms companies gather something it's called a Tele Management Forum, last year they had IPv6 on their agenda, interestingly. The forum is going to happen then at the end of this month in Nice, and there is no IPv6 on the agenda. And I would suggest that, you know, it's nice that you want to engage with the CIOs of the various countries in Europe. I mean, it's probably a good thing. But I would suggest that one of the real problems with IPv6 is that there isn't enough engagement with the people who make the decisions about deploying technology within companies, and that includes the Telecom companies and, which, let's face it, have the majority of the Internet provider market in Europe.

DETLEF ECKERT: What are you suggesting what we should be doing? Because this belongs to the part where we are engaging with ISPs or Telecom companies. Should we join this meeting in Nice?

AUDIENCE: Well, for instance, yes, that forum would be a good way to engage with these people, with the people who are at the sort of top level of decision making but of course it's not the only way to engage with them. It's just that well... you know, this is something where you need to work from the top down I think as well as the bottom up. So, engaging with the senior management of telecom companies who operate within Europe.

DETLEF ECKERT: Okay. So that is your recommendation is really to go to the senior management of the telecom companies that we engage on a high level and not only on the technical level.

AUDIENCE: Indeed and sort of having a dialogue about IPv6 and where it fits in and the sort of more longer term issues as well and from the possible economic upheaval of a poorly managed transition as well.

DETLEF ECKERT: Many thanks for that because you have seen the general action point of engaging with ISPs and Telco companies and the question is about what and how and so, we are addressing, mean the typical way we do this in Brussels is our first approach is to go to one of those associations, for instance in this case, ETNO, European Telecommunications Network Operation organisation and through them, reach out and so we will then probably ask at a high level in the Commission in order to reach out to those people, yeah.

AUDIENCE: Good morning, Peter White, HP, you mentioned you were working with your vendors and other partners in terms of IPv6 products. Are you going to change your procurement procedures to embed that, you know, like we are seeing in our countries or what's the process for that moving forward?

DETLEF ECKERT: Yeah, two things here. First just to repeat what I said about public procurement. First, Commission has already decided to change the public procurement procedure for equipment and service contracts. So we are going to require the same as in the US. And we would like, where it has not happened yet, that all member states to do the same. And this is one of the reasons to meet those 27 CIOs from the member states which means they handle, they operate the network or they oversee the network in their countries, at least at federal level. For the regional level, for instance in this country it's something different but they also have an internal organisation. So we would like to trickle down those kinds of dialogues. So that would be a requirement for equipment vendor, that would be a strong message I think and that is exactly the purpose of it. This is where we are going.

The second thing is actually also interesting to partner with big vendors like HP, first of all in the dialogue in on the features on products. You also as HP have security products in your portfolio. But also in your service practice, because HP, I take your company, for instance, HP has a huge service offering, and you have you're out reach to customers, you speak to thousands, to tense of thousands of system administrators, developers and network administrators. So you are exactly the kind of accelerator we would need. So through your news letters, through your events and through your training activities, and this is where we see partnership in terms of early preparation and it gives IPv6 a kind of scaling up. Of course it's not that because of us you would do this. It would be, let's say, an additional incentive you would get from this. So you would tell you could tell your customers: Look, this is a general move, we believe as a company in it and by the way, there is also European Commission and European Union countries are moving in that direction. So this is the kind of dynamism we want and also this is the kind of mechanism that may break through what Geoff was just referring to, namely this kind of situation we are in.

AUDIENCE: It's not so much a question I think well, it is a question a question at the end. It is not meant to be cynical. If I take your presentation and I travel 20 years back in time and I substitute IPv6 with OSI, then I have something that we can probably trace back in the archives, if not in Brussels I think in my old office in Amsterdam.

We all know what happened with such programmes of, full of incentives and information dissemination and the industry decided for something completely different.

The question is: Do you think you can avoid the outcome of the other experiment in a way are you aware of such a large scale exercise in this area 20 years ago and the outcome of it and do you think you have learned from that to do it better this time?

DETLEF ECKERT: Well, we have learned about it

AUDIENCE: This is not a cynical question.

DETLEF ECKERT: No, no, no, because actually we have learned about it because we are now listening to people like you. You are saying IPv6.

AUDIENCE: Touche.

DETLEF ECKERT: And this is the answer.

CHAIR: Thank you very much. Thank you.

(Applause)

I hope that we will see progress reports all the more and continue to work together.

Now, we have a three second and [unclear] bullet or the item is a report from the Certification Task Force and if I understand correctly it's [unclear] at this timely, Trudy Prins and Oleg Muravskiy that the do the presentation in some order.

NIGEL TITLEY: Due to a moment's inattention after lunch I find myself presenting the certification authority task force progress report once again, only this time I am aided in this extravaganza by Trudy and Oleg, who will be adding to the remarks I shall give.

Okay. As some of you may know the RIPE NCC has been working on well together with the certification authority task force to implement a solution to provide certification objects for various objects in the RIPE database, and there are various drivers to this. The RIPE NCC actually picked the non-technical short straw, as it were. APNIC and ARIN are both implementing RPKI engines, the technical side and RIPE decided to take the option of following up the business process side of the project, which nobody else was really looking at.

So, what we are looking at is enhancing the registration processes, so using certification objects to enhance registration. We are also looking at improving the robustness of transfer mechanisms, should such mechanisms actually come to take place perhaps sometime in the future.

We have been running since November 2006. And I have been giving these presentations since then basically, and back in November 2006, at RIPE 53, we decided that we would kick off this task force to look at how certification could be brought into the RIPE NCC, and on February, in February 2007 we had our first meeting, our initial meeting. And the goal of that meeting was to understand the context in which certification authority would work in the RIPE NCC. And at that meeting, as it says here, we discussed high level viewpoints. We realised that it was actually a dam sight more complex than we thought it was. We decided that we'd start in typically techie fashion by looking at the technical feasibility of actually building an engine and to keep people's interests up and so forth. And we actually did agree that we would move forward with a certification project, which was, I suppose, a good thing.

And our general plan, oh dear you can tell these plans were done by somebody else, decomplex the project by defining impacted areas, which I think means trying to keep it simple. We were to look at what knowledge was around, talk to other people, talk to ARIN, talk to APNIC who had actually done quite a bit of the work and also make sure everybody else knew what we were doing and have a look at how the technical standards and so forth were progressing.

Then we went on to May 2007, at RIPE 54 where we had our next meeting. And this time we decided we would publish a progress report and started this series of reports. And we decided to assign the various areas, green, amber and red notifications, and pretty well the only one that was greenish was the policy area. We were pretty well sure we understood some of the issues with policy. The services area: Well, we were thinking about it. The services guys were actually looking at how certification would impinge on their internal processes.

Technical area: Well, they thought they roughly knew how to implement a certification engine.

As far as the RIR wide area was concerned, how the other RIRs would deal with certification objects, well we didn't know a lot really to be quite frank. Also, we weren't too sure about the application area either despite having built an engine.

Anyway, the next step was to focus on the technical feasibility and how we would actually apply these certificates when we had them.

On to October 2007, RIPE 55, last meeting: We had a goal of reporting on the progress to the task force, which I did.

Discussion on high level prevent us moving ahead: I think what this means is that at the top level in the RIPE NCC, we had some blocking objects that we needed to discuss before we actually could move further on and they were discussed at the task force meeting in March.

And finally, we decided we'd actually try and develop an example portal to show the sort of things that you, the members, would actually be using to interact with the certification system. And we decided that we could probably do that.

In March of this year, we had a meeting at Schipol Airport and we discussed the progress. It was quite there has been quite a lot of progress actually on what the status was. Daniel and others presented us with some nice white papers describing applications, and so forth, which are no doubt available. And we decided we really ought to produce something that we could present at RIPE 56, which is now. And there was a policy proposal that had to come out of this, because to in tell people how we proposed to actually make certificates available. So there had to be a policy document produced and I shall be outlining that at the Address Policy Working Group meeting tomorrow and high level planning which was presumably presenting this presentation, this progress report.

Okay. After that meeting, we decided we did actually settle on the business value of certification for the wider community and how this would establish ownership of address resources and so forth. And we also decided to go ahead with the next phase, the pro production testing phase which you will see a demonstration of later on in this talk.

And our plans were that we will announce this preproduction version, as you will see, and we will kick off the policy, the provisioning policy proposal in the Address Policy Working Group which will happen tomorrow.

Finally, we looked at the sort of added value that certificates would give us, and there was a thought, somebody thought that maybe certificates could be a interregional exchange standard between RIRs, this is probably something way into the future but you never know. Certificates also can facilitate automated provisioning because they can actually enable people to establish ownership of resource, an address resource rather than having to trace back through detective work and check through RIR records and so forth. And we also decided that the certification information should be made available in an easily parsable format, again we shall see later on.

And of course there is always the longterm goal, goodness knows how far away that we can actually use certificates to secure routing.

And finally, of course, there is the old demoral spectre of IPv4 and IPv6 ASN transfers for which certification is a real must.

We have already been over some of this. We have had a look at the business value of certification which I think Trudy will talk about a little bit more later on. We started the implementation and we are taking part in active technical discussions with other RIRs, with other implementers of certificates. We are looking at the real realisation of how would actually use certificates. The internal business processes are being developed to sort of support certification, that's right within the RIPE NCC itself. And the RIPE NCC is talking a bit more closely with the task force rather than wandering off on their own, which is nice. And finally again, we are preparing a test version, which you will see later.

And I think I will hand over now to Trudy.

TRUDY PRINS: Hi everybody, for the ones who don't know me I am Trudy Prins, I am the manager of the business applications department of the RIPE NCC.

What's the value of a certificate? That's of course the key question here. A certificate is a digital certificate; that's what we are talking about here, and the information in it is a party who the certificate belongs to; the resource, which is the certificate has or which is sort of part of the certificate; and a signature of the party issuing.

So, the party holds a resource. Basically, because the RIPE NCC said so. And this is really important in the whole story of the certificate and the value of it, that certificates are not really the trust anchors. The registry really is. So, do you believe the RIPE NCC?

What's it all about? Of course, it's all about allocations. These are the RIPE NCC's core concept, and that is what connects a party to an IP resource.

So, when we are looking at certificates versus allocations, keep in mind that it is merely another presentation of an allocation. We have a couple already of course like our internal database records, and also the public RIPE database that holds the OPS and RSL format. So it's just another presentation, and therefore, the value of it is only the added value of our other presentations.

So, going back to the slide Nigel had already, what is that added value? That's the key question in the whole certification effort, I think. It's good indeed to become some sort of a currency, some sort of interregional exchange standard in the future.

The automated provisioning is facilitated highly by it because now this is really time consuming, a lot of manual work, a lot of believing people on their pretty blue eyes and stuff like that. So, if you could really prove the holder ship, that would make things a lot easier.

The format, I don't of course have to explain the added value in that.

Longterm: Yes, secure routing. I mean it is longterm, we are also highly dependent on the hardware vendors as all of you know, and we don't know how this is develop or how fast this will develop, but at least we are sort of ready for it then.

We already could, like, offer some filter lists, which are easily read in routers and routers configures. That is doable in the shortterm.

Yeah, the transfers: In the near future, this might be a thing we want to do: Transfer resources from one ISP to another, maybe from one RIR to another even. If it will ever become reality, this will facilitate it.

I want to step aside for a moment to show you the structure, the recursive structure of the certificates. There is something we call an RPKI engine which generates certificates for lower level. So, you could see this in a recursive perspective like the RPKI engine of the higher level generating certificates which is used to sign resources of a lower level which RPKI engine can also generate a certificate for an even lower level, etc., etc..

The how and when and where of it, I don't want to elaborate on this right now, but briefly I want to explain to you that this is meant to be a recursive architecture, structure.

The wider picture: I mean, the fact only that the three of us are giving this presentation, Nigel, Oleg and me, means that we really want to collaborate on this effort. It shouldn't be an isolated effort of RIPE NCC business application team building something. I hope that people will use it.

Our primary goal may be getting to implement it, but we cannot do this in a vacuum. There is the policies, which are really important in this perspective. But there is also our internal RIPE NCC processes. How does it fit in? Does it change the processes? Does it change any business processes?

There is a very strong interdependence between the technical side, the process side and the policy side, and that makes it also quite interesting, I think.

What I wanted to mention to you, if you are interested in this topic, and also in the wider picture, please attend related discussions in the address policy and the routing working groups, because they are sort of connected.

Okay. I'll give the floor to Oleg.

OLEG MURAVSKIY: Thanks Trudy. This is more tangible part that we are going to show you is the real life scenario of an ISP, in this case the name of Blue Light and their client Mini Corp, and Mini Corp wants ISP to route their network because they have one from RIPE NCC, and you could see that Blue Light has some licence, and in this case the good behaving ISP should think of is really the Mini Corp has these resources from RIPE NCC but the legitimate holder of this, and how do they usually answer this question? You might know that this is not really answered especially when we think about allocations done in really past fast area or in so-called ERX zones, when we don't really have the full information of whom we allocated these resources. So how do we find it? Most probably we will go to some of these databases but not all information is available there. And first you have to know which database you have to go to because there is not only RIPE NCC but others as well. So all this takes some you need some good emergency about it, which means you have to have educated people to do this, and basically it is not cheap. So when you value whether you want this client now or tomorrow or you are going to invest some money in investigating whether he is the good guy, there is always a balance between this.

So what we propose is the, how to to it in automated way. And to help this certification has already an answer: The route origination authorisation.

So what it is, is it's actually a message, signed CRYPT graphically which says that the holder of this IP resource authorises holder of IS number 2 to originate this prefix. And this is digitally signed so it means it's secure. What is important here is it's only one way of authorisation. It doesn't mean that the holder of IS number agreed to do this. It doesn't mean that it's actually doing this, it's only one side from the IP resource holder to IS number and this is really important to understand, so not do something that is not there.

Another thing that you could allow multiple prefixes within the same message and same AS number. So how this message is connected to the resource certificate? You could use direct link between them. But technically this is not the best solution and what is proposed and what is used now is some intermediate ate certificate specifically for this through the message. This certificate is linked to the resource certificate of the IP resource holder, and why we are doing this is basically to be able to discard the message, so if you no longer to authorise holder of IS number to provide this service, you just remove the intermediate resource certificate and you still from your resource certificate for your address space, you could generate other RS, so this is technical way to do this. Also when you validate, you have to validate it, there is the certificate which has the same address space as your own message states. There is parent certificate of intermediate certificate which also encompasses the AP resource you have in both, and you then have to wake up all the change of these recursive model of RPKI engines and the certificate that Trudy just showed. To it really looks a bit complex, but it works.

So what is, in our case, the answer of Blue Light, yes, please sign with my ASN number and then we will talk further.

Now, let's go to the demo part. So, this is our prototype interface. It looks like a LIR portal so it is really not a LIR portal yet. So please do try to find it.

What we have here is, we logged in as Mini Corp user and we could check what resources we have. So that's the resource we have and we already have a certificate for this, and you you can see here, just one word, status: Valid, actually means that if we go back to a couple of slides, what the engine does, it actually validates all the chain of resources from this. So supposedly we have a certificate at this level, it validates all the chain of certificates back to the trusted anchor that everything is, all the certificates are valid and IP ranges, they are all okay.

Basically what you see is just one word here. What you could also do is, you could download the certificate, and if we try to open it with some standard tool, this is the standard key chain. You could view the certificate and the result is basically expected. It could not validate it. Because it has unrecognised the critical extension, as it says. So what we see here, you could seal the certificate parameters, but the resource certificate, something has really specific to RIR PKI, resource PKI, these tools are not supported these extensions are not supported by most of the tools yet. But what we could do, we could use, open SL, the newest version you could download and compile specifically with this extension and the credit for this goes to the team which does this for ARIN, Rob he is sign, I believe is here in the meeting as well. What we could use is the version of open SSL so, well this is normal presentation, I don't think you'll know what it is about, but basically the interesting part goes here, this part is the critical extension, the critical means it should be there and it should be understandable. It holds this resource that we have certificate for: And let's go back to our interface. What we could do now with ROA is how difficult it is to create a ROA. You saw this chain of certificates, intermediate certificates, parent certificate. What you will be able to do is just to specify your resource and IS number, you want to use and with one click of the button it is just there. So it's created by the system. Now, what, in our real life scenario, the other part Blue Light would do is basically using the other page, we will have to just see whether there is such a ROA. So, you could see here that there are no two ROAs assigned for this number. One there was there previously for a old Blue Light in use and another one we just created now with our IP prefix. What is also interesting here, you could see two columns, one of them, whether it's valid: Yes it's valid. So system validated all these certificates in the past and they are all okay. So certificates are valid. And another column in RIS means that we could use our other service routing information system which shows us whether this routing is actually announced on the BGP and the idea for this is to stress fact that the ROA itself doesn't mean this is the real life situation, it doesn't mean that that has been announced, it is just authorisation, so from here you to see that it is not actually happening because Blue Light haven't done anything yet with it. What they could do is, to export this list in some format and we we are actually looking forward to which format will be most usable for you, so here you could see some example out that the disc could generate, that you could just feed to your routers or databases or whatever you use for your own needs. And then after this will be done, we will see hopefully that in RIS, mark will become green tick and everything will work.

That's the part I wanted to show you. And Trudy will continue I think.

TRUDY PRINS: I really want to invite all of you to join our test programme, or if there are any people in your organisation who might be interested.

What is in there for you is of course a question that is interesting, I would presume. Well, you can have a sneak preview of whatever we do through web interface, we will use a member portal look alike structure. Also, your input is taken into account for any further development we are doing, which might be valuable for you. We will help you in any possible way. You can always talk to me of course or Oleg, but we will also release some screen costs on a regular basis and some documentation.

There is a mailing list we will subscribe you to it. You can share experiences with other people.

What do we expect from you? Well, first of all, please enroll to the test programme. Send your request to cert [email protected] and then you should be prepared to send sometime, let's say one to two hours a month, depending on how busy you are, I mean half an hour would already suffice if you are a very busy and important person, but a little more would be appreciated. And of course, give us your feedback, so we can do something with it and keep you updated.

What's the period we're talking about? Well May till September. This is the functionality we intend to build which you could test.

First of all, we want to enable the member access, the software Oleg already showed you guys, but then like accessible from the outside world. So, you could, like, issue a certificate for your PA allocation, view your certificate. The next step would be stuff like key management like revocation, key rollover, all that jazz. ROAs, of course. Transfer support: Really interesting, we could already test the functionality and get your input from that also so we are ready once the policies are accepted and this all becomes reality. The recursive model, we could also give you something on that and let you try out differences between the hosted and nonhosted flavours.

So, this is the time line. Let's say in a week or two, three, we will enable the member tests to everyone who is joining the test programme can then log in and do their first basic stuff. From then onwards, every month we will provide a functional update with new functionality, accompanied by a screen cost, explaining to you what's there and what do with it. And we are aiming at RIPE 57, of course, to have a production ready release. The scaling might not yet be like perfect for total production, because there are, like, interests hardware issues here, security, of course most of you will understand that, that the server storing the certificates will have some specific security restrictions, but at least the software should be production ready by then, at least that's what we are aiming at.

So, the team, I once more want to introduce the team to you so you know who you can talk to if you want to know more about this or enrol.

This is Andrew, the CEO, and he is the driving force behind this project of the RIPE NCC.

I am the project manager of the project.

And Oleg, our software architect and senior engineer.

That's it basically. Thanks for your presence and any questions.

CHAIR: Any questions from anyone? Another eleven minutes to lunch. Okay. I guess that means that we will have early lunch. Thank you very much.

(Applause)

CHAIR: And with that we conclude this morning's session and see you all after lunch. Thank you.

(Lunch break)

The session continued at 2�p.m. as�follows:

SPEAKER: All right. So it's about two minutes past two so you had your academic quarter.

Welcome to afternoon session. And the first presentation here was is employment in the likes of economic through security, I forgot the title. By Ms.�Jean Camp. There you go. Thank you.

JEAN CAMP: Thank you. All right. So I am looking at I have not been part of the history of IPv6 so I am come to go this fairly new and with a different perspective than most of you have on it. I looked at IPv6 diffusion with basic Scurve model, let's just say it's not rocket science. I looked at data from ARIN and in fact, this was presented at ARIN and they asked me to present it here and the reason there is no data from RIPE is in between them, those two times there was the end of the semester and midterm so I would like to do this for RIPE but I don't have that data and I haven't had the time to do it.

What I am interested is in IPv6 not as a protocol but as an economic agent that is it has a certain incentive structure inherent to the way its built and what it's offering, just like any other thing you might purchase or adopt. I am going to talk a little bit about the related scholarship particularly so when economists say network they do not mean a physical network; they mean a network in fact is anything that has the effect that the end plus one person who uses it creates value for the one to end people who use it, so for example, the English language has a network of fact if, I only spoke Welsh and Spanish, we'd behaving a hard time understanding each other, so and I want to talk about parallels from network insecurity particularly patching and privacy.

All right. So there are two kinds of benefits, intrinsic and network benefits and any good if you bought your computer you could still programme, you could still do word procession, if you wrote your own word processor, right? But if you use word, there are benefits that come from other people having used Word. I am not advocating Word, it's just a good example of network benefits.

So OK. Let's because it's so widespread and I think most people agree it's not a great programme but everybody uses it and why does? Everybody uses it because everybody uses it. Right. And it's network effects, like a QWERTY keyboard. So IPv6 also has this intrinsic network effect that is if I adopt IPv6 in my own network I can get and get [unclear] of NATS, I have a better idea what devices I have, I can expand more easily, so those are the intrinsic sorry. My machine telling me to speed up, my inthe network values are derived everybody adopting IPv6, so I can talk across a network to you and I may be able to better identify those devices that may be hostile. So one of the problems with IPv6 is the network benefits seem to accrue mostly to late adopters. And if you see not everyone who can benefit from adopting IPv6 appears to have adopted IPv6, and I don't think that is a wildly radical statement. It's also through not everybody who benefits from patching their machine has patched their machines even in businesses. I mean, here you have this thing where if you don't patch your machine you are you can become you are participating in spamming, denial of service attacks. You may genuinely be helping organised crime and the same people who don't patch, wash out their disgusting cat food cans because they want to be good neighbours, right. So why don't people patch? And to what and can we learn from this from IPv6? All right. Well, one of the problems is an incentive problem, vulnerability are an extra, yes, I can lose my data if my machine is not patched but I can also hurt your machine if my machine is not patched, so just like pollution and unpatched vulnerability is extra and all the value to patching does not accrue to the person who has to do the patching. OK. So similarly, I talked about IPv6, all the value that accrues from IPv6 doesn't go to that person.

Osmond in Cambridge, the English Cambridge, talks about how we need subsidies and main dates and how bundling is is a problem with patching because you get stuff you don't want along with stuff you want, and of those I think the issues of subsidies and mandates are the ones that are applicable to IPv6. And Hussien who is in Toronto talks about the problem of lack of standardisation and inoperability. That is to say, every network every network is kind of unique, we all run the same protocols but they all have different distributions and different requirements on it and so maybe, I don't know, if your adoption experience is going to match mine. There is a need for testing and concern for kind of local unique things, the travel system that so-and-so wrote that we have used, you know, since 1989, kind of thing. There are also even more parallels in patching, in privacy, and here is the fundamental one. Of. The risk are invisible, the cost of privacy is high. You can't do things if you want to maintain your privacy, and the risk to your privacy are invisible. When you type your data into a merchant machine, when you are browsing without tower, you know, there is nothing that comes up and says, this is hazardous to you. You can't see the risk of loss of autonomy, you can't see the risk of identify theft right. The risks are invisible, the benefits are at the cost are extremely visible. Very clear that there is going to be a cost. And it's much harder to see the cost.

Rachel green stat talks about how privacy is a lemon's market, that does not mean it is a fruit basket. It's a lemon here is a used car so when you buy that you are only willing to pay a certain price [unclear] used car and you assume that there is something wrong with that car because why else would you be selling it? Right. Which means that if you have a really good car, you are not going to sell it because you are only get the price for a bad car. There is in general, this means there is this kind of information asymmetry, the people don't know fully what they are buying, they don't know what they are experience is going to be when they adopt IPv6, and the claims for benefits just like, you know, when you go to a website and they have the trustee seal and oh by the way, that is positively correlated with incidents of and spy wear, right? I mean it is. It's just so, it's like the trust me seal, right? I really have a good privacy policy, here is my seal, but you don't know if they have a really good one, IPv6 is this really great thing but if you don't know and you haven't had experience with it, you don't know that it's a great thing.

OK. So, one of the other things and you see this in a lot of risk, human beings do not implement theical includes of risk when take it a risk. How many of us in the past two days have jaywalked across that street? Right. Didn't we really say I am willing to die? Taking across that street and so this may be a little bit more quantitative set of humans than most. But people tend not to behave rationally and organisations don't behave rationally about risk either, so Alexander did this thing here is your privacy risk and some choices you make. He found not only do people discount privacy, they the discount rate increases over time, so they start with a high discount rate and then it increases over time. So, similarly, people are like yeah, IPv4, know, the talk this morning he was like well, if we start now, you know, put not guilty [unclear] maybe people will know about it more so when four months out and I was thinking no if you had started ten years ago, right. So people discount risk.

And the costs are visible, it is more complex standard, there is a concern of interoperability with some of your applications, there is arguably a lack of maturity in some of the ship stacks. People also don't like unknowns, is there going to be a routing table explosion? Are there going to be terrible routing storms? I don't know, you tell me. What is the total cost? And also, and I think this is very important, tacit knowledge is lost. People like to be good at what they are good at, at what they do, sorry and if you are the master of NATS, how many senior network engineer have just really no NATS, they really know, you know, how to time share, IPv4 addresses, they have this mastered. And with adoption of IPv6 that is lost. You go from being the master to being the new be, and that is a huge incentive to stick with what you know, to the value of your own expertise.

So we have all this cost but the benefits are invisible, right? There is a long-term advantage in tacit knowledge for early adopters. That is very hard to communicate, and illustrate. And some of the security issues can't be captured by early adopters, they are captured by the people the early adopters communicate with. My security is better, you are welcome. And the other areas like mobile devices, you guys all saw that [unclear] Kevin about the pacemaker, the blue tooth heart attack pacemaker? They don't authenticate. They encrypt it, the communication to the pacemaker but the pacemaker doesn't authenticate so isn't that just excellent?

So nobody is allowed to use remote now, it's one of these see receipt service phones going to take out Dick Cheney if they dial. No. Oh, this is being recorded. Oops. So, the monetary costs are really high. There is a guy named Rove who did a benefit and he said it would cost 25 [unclear] over 25 years. I think what he means there is additional cost, right. Obviously Cisco will probably sell more than this in routers alone, but just the additional cost.

Personnel cost and you want to adopt IPv6 after everybody else has adopted it basically.

So, IPv6 might increase security vulnerabilities. There is this paper again by moss met called if code milk or wine. Does go sour with age or does it improve with age? And they tracked security vulnerabilities and they said code is more like wine; that the number of bugs goes down over time, even as the code becomes more complex. So, since you are shifting from a very mature code base in stack to a less mature code base, that might go up. Also, misconfiguation, if we have router misconfiguation now, imagine when we have large scale IPv6 adoption. So how what is the core that is kind of that is why I want to look at IPv6, as someone who is interested in economics of security. And so when I decided to look at it I thought let's see who is taking it up, who is adopting it. So in the first thing I thought I would do I will do a probate model which is a classic kind of simple statistical model where you look at early adopters and say these are how they are alike and different from most other adopters. And then there is an Scurve macro economic model it aggregates over time and addresses different kinds of adopters. Well, I got the data set for the probate modelled and I found, large network providers in government have adopted. Well that was interesting. Not really. I mean I can do it, right. I didn't have there is not really enough adopters to come up with some good results.

So, yeah, like I said, it's just not there. The early too early in the adoption cycle for an effective probate analysis. What I did was an Scurve model. It's nice and has non-constant rate adoption and assumes there is a low level rate and much higher rate of adoption. It has been very well tested over time, extremely well tested. I mean, it applies to applications on the Internet, Internet you know, Internet connection adoption, television, telephones, beany babies, pretty much anything that has been adopted, follows this pattern very well.

And it's very easy, it just says you know, in time T plus one, you will have the number of adopters you had in the previous time, plus a coefficient innovator coefficient and a follower and as we go through and you look at the shape of the curve you will see why this is the case.

All right. So, I started out by looking at routes. I thought oh, we will look at routes. Given the current adoption rate, when might IPv6 have full market penetration? OK. Well, let's do a best fit to the curve, and see what we find. And then I did a second set with autonomous system numbers because the first time I present this had people were like you are crazy, you can't compare four routes to six routes and leaving aside the question my general sanity, I thought maybe doing networks would be better because it would be a better comparison. So I am not when I start to tell you my findings, I am not pretending that I am resolving real world uncertainties; what I am doing is saying is here is a window that this model gives us. Here is some information that we might find useful from that I come up with some recommendations. All right.

Here is our best fit: 2019. Oh, that is not good. That is way after we run out of addresses. Yeah, 20 percent diffused in 18 years. Wow. But so, I guess I thought I saw that and said well, there will be other things, maybe this isn't capturing kind of exogenous forces that will force adoption, so let's look at what the DOD says they are going to do because they have lots of routes and this is the routing data, and let's see if we can push this data a little bit. Let's assume let's seriously truncate the data so we don't have this huge long tail, so part of the problem I thought might be that we had this ten-year long tail and that is suppressing it and that is not an unreasonable thing to do, right? The first facts the first thing that we recognise as a facts was sent in 19th century in England, the first Transcontinental fax I want to say in the 30s, it may have been the 40s but when you do diffusion of the fax machine those studies always start around 55 so maybe if we really cut the tail off we can find something cheerier. We found in this, yeah, major adoption still doesn't occur until 2019. And then we said suppose there is annex on news force, the DOD, and good name for a force, and they have a big chunk of network and they really shift entirely to IPv6 and let's put that shift at three different points, right? I think we went with 11, 12 no, we went with 11, 13 and 15, 2011, 13 and 15. Well you can see even with this very serious exogenous kind of forcing function, we still don't get anywhere near there unless in less than about eight years. So...

Well, here is the here is the argument for here is what we did. I cut off this huge long tail here and we just used kind of the end points. Because I was like, it's true though, if you have too long a tail you will mess up your diffusion curve and I think a good question of when the question of when to start isn't crazy, and I will come to reason why I think that was not an insane choice, so to stop comparing routes which is apples to oranges, or apples to pine nuts, we decided to do the autonomous system network and what you see here are two results, we because the coefficients have huge amounts of uncertainty the curve is in here, this is one standard deviation and this is one standard deviation because we don't have much data about adoption and this is with the longer tail, so this is with the five-year data set. So we found you know, 40 years to, I don't know, 2262; there is a lot of uncertainty there. So, that seemed to me a little crazy, 2262, so I said, well, the results are really sensitive to the beginning point, all right? They are very sensitive to that moment of initial conditions, so what we did was we took IPv4 over IPv6 and we got this data, right? And around here you can see six bone, I think this is six bone terminating and then I said well, this is this is when actual diffusion has started. Because before that, you had this government entity and also having this big dip really screws up your coy [unclear], so I have a rational argument for cutting off the tail, it's not an arbitrary choice, although the DOD points were close to arbitrary. This is far less so. And so we truncated the data on this. And then we did the curve fit and you can see, yeah, 2011, wow everybody do the wave. But that is one standard deviation for the coefficient, that is not, that is one starred deviation off and still you are talking about, what is this 70 years with one standard deviation the other way. So there is a lot of uncertainty in the data and the initial conditions really matter.

So, the route data is the worst case is 20 years, the best case is 2016 which means truncating data severely and pushing the uncertainty. And route numbers are arguably a better fit. Worst case more than 200 years, which is so long it's funny, yeah no, you put it in, you get the results, that was basically my response. So then we set data to 2004 and if you do one standard deviation, we find the coefficients and one standard deviation above and below of the coefficient, not of the data because there is so much uncertainty here that this gives us more of a win dove adoption than saying, I want you to to know it will be 2015, right? Because I can't say that. So, best case 20 [unclear] which truncates [unclear] to six months and a standard coefficient longer. So not insane, not likely, either. So why so long? Well I talked about invisible benefits, network externalities against the early adoption, not at a tipping point. What is the tipping point? We don't know. There is a misaligned incentive structure, both at the individual level and I think it's very easy to underestimate the implications of this, that you are going from the total Nat master and network jockey to the person who is using this new protocol and doesn't know what they are doing. And there is also something called, it's like an endowment effect, if people have something they don't want to give it up. I have a bunch of four addresses, I perceive them as valuable, I don't want to give it up.

So, we see a lot of government supporting adoption, they are doing subsidies, they are demanding it so we were talking at dinner last night and I said if you want scientific universities to adopt IPv6, put SFN calls up, you have to have IPv6 to get to them. The entire faculty would run into the IT services guy with our we are not really violent, we wouldn't use like forks and matches instead of pick forks and torches right. But there are things you can do to force adoption right now, the DOD requires the US DOD requires certain bidders to have IPv6 capability, so I don't know if this is true because I have read this and as an academic you believe things you read, except for on the Internet; because I have heard some people are wrong on the Internet. So, the Chinese, Japanese and Korean governments have claimed a lead in IP, I think it would be very interesting to do exactly what we did here with the Asian Pacific data, with that data. And on a global scale it seems that 6 benefits would outweigh cost especially with the coming exhaustion, but in the US and Europe where we had this big endowment of four addresses, we we have much less incentive to move, right? OK. We already know that effect of IPv exhaust Sean will be highly variant. So, one of the problems I think with IPv6 is some of the good stuff got taken out of it and moved to IPv4, DNS Sec is much more adopted than IPv6. You don't think so? OK. There is there are data sets illustrating more adoption of DNS secretary than 4. How is that. IP Sec. You think that that is come on, more adopted at this point than IPv6 is like can I jump this high. IPv6 and emerging services, maybe it could be lack of near term, lack of interoperability with four, could be a service like the heart attack example. Let's look at the human problem. I believe a huge amount is the human problem so one of the things, there is a CISSP in the States, it's a great business. Are there CISSP certifying people in here? I bet so. Why [unclear] did that come from? They developed the course and then they went to industry went to leaders in industry in the academe like Jean [unclear] Ford and said here is your certification. You are so good, we know you have this. And then it was perceived as valuable and other people went to get the training to learn what they teach them, right? So could do you the same thing with v6? Could you go to leaders in the network community. You know if everyone in this room, if awful you were had a v6 certification, it would become a desirable thing to have. So can you solve the human problem? I read this slide before this morning's talk where he said we need to team with universities. I think that that is true. Here is something else:

It turns out, after long study, we have determined that engineers are people too. And it really matters, usability really matters. Do some formal studies of the IPv6 configuration software. Make it make it easy. Make it a positive experience, you know. So, you are looking at me like you don't think engineers are people but I am sure. We have biologists in our department.

So, information availability. Do some case studies. Is there a third party that could be trusted to do case studies or is there a feeling that there is kind of two camps? Right. Get some total cost of ownership. Look at some coexisting studies I know there is a lot of talk about the market and what problem is solved with the market and what problems are created with the market. You know, I mean, would it be interesting if these empty seats are were filled with financial speculators, would that be good or bad? How do you design a market? That is a huge, huge issue. What is your bundle of rights, your mechanism for market clearance, how do you I saw yesterday that there is work to ensure exclusion, and what if it's an illiquid market? I mean, when you get to unavailable four, it's terrible because there is a barrier to entry and that creates a regulatory imperative but it forces you to six, expensive four can be a barrier to entry. Endowments may encourage people who have lots of 4 addresses to keep them because you may be saying to a company when it has a value, oh stop using this stuff that has value and use this other thing that doesn't have any value, which may seem like giving away an asset. I think that a possible outcome is if you build a market, governments know markets, governments know how to regulate markets and I think that that is a risk that you should of which you should be aware, think people like to do what they know. Governments know markets. I mean the governments feel like they are not coming in and saying we are regulateing this because there is the sense that the that the Internet has been we don't want to break it, we have this golden goose and we don't understand it and we don't want to accidentally break its neck but if you have a market then it's something they understand, they are going to feel much more comfortable stepping in. That is what I meant. And that is it. Thank you for your time. And I hope that I got you to think about something you have been thinking about for a long time in a slightly different way.

(Applause)

CHAIR: Questions?

DAVID KESSENS: David Kessens Nokia networks. I was listening to this talk, I actually took a piece of paper out and I was writing down all kind of stuff about every slide that I saw with all kind of stuff, I simply didn't agree with or I think was wrong or whatever. I ran out of paper.

JEAN CAMP: You only have a little tiny piece of paper.

DAVID KESSENS: So I am going to prioritise on Daniel's request. So basically what it comes down to, I mean any time you take an economic model or what kind of other model, the real important thing is garbage in and out and what I see here is a huge case of garbage in. I mean it's all nice, I have seen a lot of nice words about yeah, we might get IPv6 adoption in 2000 and something or whatever. In the end, it's based I mean, this whole thing is based on nothing. There is just so much stuff that is just not true that you are presenting here that is just, we cannot even start there. Think about talking about patching computers. Patching of computers happens automatically, people don't do that because they want to it, just happens for them. In this whole room there is people using IPv6 who might not know simply because their operating system does it behind their back. I mean this is infrastructure and it's designed to happen behind your back so it's not always a question about whether you even want to adapt it or something like that, it just happens. Yes, it's very interesting to get economic models out but it's at that takes way more effort to really get a serious model here because I mean, the thing that we see here there is no relationship to reality in any kind of way or form. And that is my real problem that I have with this.

JEAN CAMP: OK. And I appreciate your honesty and I appreciate the attention that you paid enough to take notes, such as they are, but you know, I really wish infrastructure just happened, I really wish that the magic patching fairies made everybody patch their machines and we didn't live with the Internet with huge armies of bought nets and people don't plumb their own well, I mean, probably a bunch of us in here have done this; most people don't plumb their own links. Everybody let's up their us router. This is fundamentally different

DAVID KESSENS: You are comparing something to completely the wrong thing. You are talking security. It's not about whether the whole Internet adopts IPv6. If half of the Internet documents IPv6 it is already success and if the other half is affected with both nets and whatever crap that doesn't change anything to the fact that IPv6 has been deployed at that point?

JEAN CAMP: Do you think IPv6 will stop both nets?

DAVID KESSENS: It has nothing do?

JEAN CAMP: Yes. I didn't understand your comment. What you are saying it all just happens, it's all just magic like a catalytic converters and I am saying we have huge home network configurability problems, we have when people they do just want it to work. Right now it doesn't just work and in terms of adoption rates, what I showed here were extremely high coefficients, so it I think it came out not insanely and it's true, I used the data that I had. And that is why I presented this vast uncertainty and I didn't come up here and say 2015

DAVID KESSENS: But basically it's so fast there is no value any more because it basically starts at I mean, in the best scenario eight years from now, that will be a huge success for most people [unclear] scenario 200 years from now is so you are basically telling us well it might happen fairly soon or it might not happen. I mean we already knew that. I am sorry.

DANIEL KARRENBERG: To be slightly more constructive and it's garbage in and out yes and Jean was quite frank about that so I think the presentation was pretty well done. Just a suggestion about the garbage in. One of the things we need more data and you said that. One of the things to observe, just occurred to me, is actually how many services are available on IPv6. Because yes, I can be in this room and switch my computer to IPv6 with the click of a button and I can do all my quote serious work, access the machines at the NCC, access my home machines and do stuff but I can't brows the web. I am not finished�

DAVID KESSENS: You were not Daniel�

DANIEL KARRENBERG: I am not finished. Jesus. The thing there is a better measure might to be actual look look at what kind of services are on v4 and not on v6 and how things that are actually available on v4 get available on v6 and how may be some stuff that is appears only available on v6 in the you know in the service area, in the stuff that users might want to access not just how many users go there but see that kind of stuff as well. Just a suggestion into the question.

JEAN CAMP: That is a great idea. Thank you.

GEOFF HUSTON: I would like to put the data that you have produced with data that I suppose is similar but other folk have produced and we put the two together. So we have models of consumption of v4 address that is point to exhaustion about 3 years plus or minus about 18 months, pretty tight and we have this extrapolation model of adoption which as you point out even with dramatic levels of uncertainty have an adoption of N years where N is a lot greater than three

JEAN CAMP: Yes, I think that is the critical observation

GEOFF HUSTON: I am leading to the N minus three period, the bit after the three years and before the N, and what I am trying to understand and I think a lots of people are trying to understand is that we seem to think there is a lot of drivers around v6 adoption because of exhaust Sean in v4, because at some point we won't be able to get them and this will drive us to v6, but like you I see a large industry that moves relatively slowly and adoption is hard and there are a lot of drivers, economic, logistic, you name it, that make this a slow process. And it seems that the combination of these two observations is that, somehow, this industry has to cope with an exhausted v4 pool yet still make things [unclear] v4 for N minus three years, where N is still quite large. I wonder, at that point, what the drivers are to keep pressing on and what the drivers are to try and perfect a very imperfect world at that point. And it's that degree of uncertainty that keeps on keeping me awake at night, because I am not sure that we will maintain the thrust of v6 when all of a sudden we have got this other problem of trying to figure out how to make this rather broken bit over here work for the next N minus three years. I am wondering if this has parallels in other areas of economic study? I am wondering if we are entering something that is completely novel or something other industries have manage today go e oh, yeah we did that, do us a bit of a stuff up but we are still alive. I don't know. Do you know?

JEAN CAMP: Well, no analogy is perfect but I do know one of the first and most important things that the continental congress did in the US was to pick a single real gauge, that was like if they were they had but then they couldn't get everybody to adopt it because they picked one State's real gauge so when trains would hit a State line they would have like a freight car of different rails and they have to pick it up and put the rails on it so there you have an industry where the cost of this, lack of interoperability is very obvious, and it's very much a net worked industry right, how good is is a railroad if you can't get to where you want to go. So and there is a very interesting book about railroad investment coming out by Andrew lest coand I think it may be coming out, so I would recommend that.

LORENZO COLITTI: Yes. Very briefly Lorenzo, private citizen. I appreciate the intention behind this work, I find it very interesting. I near it might be too early to tell because if we look back to three years ago, the or four years ago, the best available predictions for v4 were 2035, so I would caution, you know, a word of caution against extrapolateing from data that is too early. I would look forward to seeing these studies further on and different matrix and seeing how those evolve.

JEAN CAMP: Thank you. I mean the one thing that I found in this is despite the uncertainty, there was no case in which there was no model that said we will have serious significant 6 adoption before 4,

LORENZO COLITTI: That was the case with the predictions of which I speak, as well.

CHAIR: We have used up way more time than we are supposed to.

(Applause)

CHAIR: Next up is Paul Francis, the presentation of possible methods for production. So Paul.

PAUL FRANCIS: Thank you, from Cornell. Sort of like yesterday it's my students who are doing the actual work so I may not be able to answer every question as well as I would like.

So, let's go back. The title is that, it's an approach to reducing the size of the FIB that involves only configuration of systems, it doesn't require any new protocols and of course, FIB reduction has been important in the past, that is why we have limits like /24s and so on but I think and lot of people think it's going to be a lot more serious in the future as we run out of v4 addresses and fragmentation gross and even if IPv6 actually takes off.

So I am going to present to you the technique, mainly and a little bit of data, virtual aggregation, a [unclear] the things in here you will see are familiar in other context. It's an approach to shrinking FIBS but not necessarily the RIB, so the focus of this technique is really on the FIB inside the line card, versus the RIB on the you know on the control card. And you will see what I mean by that as we go. But it's really trying to address a specific pain point which is ISPs periodically have to upgrade their routers, hardware can't deal with it and it's really that particular thing that we are focusing on, trying to give ISPs a little more flexibility. It works with legacy routers so it's only a configuration thing not a protocol thing.

A single IPS can autonomously deploy this time so you don't need coordination between ISPs for this to work, single one can do it themselves without any coordination from their neighbours. It works equally for v4 and 6 [unclear] is a hierarchical, and you will see towards the end there is a FIB size versus sort of load and latency tradeoff, I think it's fairly favourable, but that is the nature of the solution, that you have to play off these things for each other.

OK. So by way of an outline, I will quickly tell you what the status of our project is. I am really here in order to try to finite piece one experiment with this leading towards you know, some decent capability to do this sort of thing in one or two-year timeframe. Mostly I am going to go through the mechanics of the technique and then I will present some evaluation results we did based on data from IPS.

So the status is this: We don't have it, we have been using the Wisconsin router test bit but able to deploy this on small test beds of about ten routers and on Linux as well, we haven't played with other routers.

So we have tested with large routing tables, a little bit with fail over, we have not test this had on any kind of a live network, and we have not done any testing for IPv6 but to the extent that we have tested [unclear] real and it certainly works.

OK. So let me talk a little bit about the technique. This is a bit of a content free slide but what I am showing here is a singlised and all of my examples, doing this themselves, some POPs in that, some routers in the POP, I know this is not how they are really configured but actually the technique we use doesn't distinguish between or doesn't have to kiss I think it [unclear] between core routers and edge routers and that sort of thing, I will talk about routers quite generically in this talk. And of course the situation [unclear] that every router has to have a complete copy of the routing address space, I mean, I know it's not exactly the same everywhere but as a baseline that is the case.

So in virtual aggregation we carve the IP address space up into virtual prefixes and by that I mean you can take /6s or 7s but these are prefixes certainly not topologically aggregatable at all just virtual. And what we do we partition the address space among different routers [unclear] some responsible for all the address space in one virtual or it could be more than one virtual prefix, other routers are responsible for specific prefixes in other virtual routers, so in this picture I show it by colour and divide the address space up to four and assign routers, one router can cover more than one virtual prefix and I have shown it in such a way that not every virtual prefix is covered in every POP. I think in practice they would be but they don't have to be.

And as a point of as a point of notation, a router that carries all of the prefixes wan certain virtual prefix is called an aggregation point for that pre figures, I showed the red aggregation point, green aggregation points and so on.

So, given this, a path through an IPS that is using this technique really has three components: The first component is just to get a packet to an aggregation point that covers the virtual address space within which that prefix falls. So for instance, imagine we are going to send a packet to an address in the green virtual prefix, the packet would fist be routed to a green router which can take care of the rest of it and this would be done just through normal BGP aggregation. Once it gets to that router that will have is a specific routing entry for that prefix and then a tunnel is used to get the route packet out of the IPS to the appropriate exit point. And the second part of the path, the green part, this is specifically an MPLS tunnel and that will strip the MPLS header but just statically route it to the right peering router, 1.1.1.1 in this case.

All right. So, you know, going back, this is all fine and good. The problem of course, is that I am assuming in this picture that the neighbour ISPs are not using virtual aggregation, so the neighbour is going to have a router which expects to get the full routing table and obviously if you know just to pick an example, if the green only has the green prefixes, it's not in a position to give the neighbour the full routing table. So we have a couple ways of doing with this: One that exploits route reflectors and one that doesn't. This shows the case of the route reflector. So essentially what we do is set up route reflector, nominally one per POP maybe more and can use multihop BGP, this doesn't mean this is where the packets are going to go, they are not but this is just for peering. The neighbour on the right is exchanging the full routing table with the route reflector, the route reflector just using normal filtering will filter away the prefixes that the individual data path routers don't need, because they are not carrying those. So it will peer IBGP with the data path routers giving them whatever part of the routing table they need. It will peer IBGP with other route reflectors giving them the full routing table and in turn that will be exported to the neighbouring ISPs.

OK. We have another trick which I will show new a bit that doesn't require route reflectors. It can be done with the actual border routers. In that case, we deploy a trick where we keep the full routing table in the RIB on the control card but don't load it into the FIB. OK.

I am being a little loose with terms. When I say FIB, I though it's on the control card [unclear] this is referring to the FIB that is on the interface cards.

OK. So this is this drawing is of the actual topology that we set up when we tested this on SISCO routers and I am going to walk through this in a little more detail with respect to one of the actual experiments we did. We have nine routers, basically on the very left this thing labelled POP 1, the pop of a neighbouring IPS, pop 2 and 3 running virtual aggregation. The two routers on top labelled RR are route reflectors in this case. The two labelled AP, aggregation point. These are aggregation points for a specific prefix that we configured which is 170.168/16. So what is going to happen is that the peer router on the far left is going to originate two routes, 1707168/16 and 203.250/16. But only 17.168/16 is going to be loaded into these aggregation points and then the path will take place pretty much like I described before.

So, there is a number of configuration steps required to make this work and I will tell you what they are. So the first thing is that we configure what I am [unclear] the egress here, that is the router in POP 2 which is the border router with the neighbour in IPS 16789 we just give it a static route which is to the IP address, the /32 of the neighbour so that the interface address of the neighbour is 198.18.1.1, we establish a static route in the border router with that specific /32. This is the show commence showing how that has been done and then what happens is that OSPF and LDP kick in and that is /32 is made available to every router inside the IPS as an MPLS tunnel. OK.

Next, of course, the peer router advertises these two prefixes, 170.168 /16 and 203.250 /16 with of course annex top of its own interface address. This goes between the two route reflectors who then filter out the 203 address but pass on the 170.168 address to the two aggregation points and the next hop critically is still that of the external neighbour 198.18 .1 .1 and this little snippet down here shows that particular entry in the BGP table of the aggregation point on the right.

And you can see the next hop is the address of the external neighbour.

So this shows I guess this starts to show what would happen if a packet is going to actually be transmitted. So imagine that a packet is coming from this lower right-hand corner that are router is pretty much covered up but it's coming into the aggregation point at POP 3 so that aggregation point looking at the data on the top will look into its BGP table, match up the entry for that packet, and see the next hop is 19.18.1.200 and go it sees LP M S tunnel to that particular address, 198.18 [unclear] hundred about a tag of 26 and inserts that into MPLS tunnel which terminates at the border router on the left.

When the packet gets to the border router on the left, that router will look into its PPLS tunnel forwarding table based on the MPLS tag of the incoming packet and because of the static entry, it sees that it needs to ship that packet over that if I can interface to the peer router, but it sends it untagged so basically it strips out the MPLS header at that point and just delivers it to the neighbour. So what is important here is that of that entire, basically, four router paths through the IPS only the first route they are an it entered had an actual BGP entry for that particular prefix. All the remaining routers just forwarded the packet based on their MPLS entry, either tagged or at the last hop, untagged.

OK. I guess it's not easy to well, anyway. I will get through it and you can ask me questions later. So that was one way we did this. This is the way with route reflectors. We learned a week or so ago, maybe two weeks, that there is actually a way we can do this that doesn't require the route reflectors, in the case of SISCO routers specifically although we think others have this as well, I think we looked at foundry but there is this trick in SISCO where you can set admin distance from routes heard from a particular place, a particular protocol. It turns out if the you set admin distance to the max minimum which is 255 what the router will do is suppress loading that entry into the FIB at all. It will still treat it normally in a protocol sense so it will still run BGP as normal, it will simply suppress loading that entry into the FIB. So using this trick we did pretty much the same thing but without route reflectors, the border router was peering with the neighbour, suppress loading the appropriate ones into the FIB but nevertheless pass them all on to other routers. So I mean obviously, in doing this we are not reducing many things like the number of routing updates that go across the IPS border. We are not actually changing anything about inter AS operation of BGP. We are simply reducing the amount of entries that are in the hardware FIB online cards in routers, thus hopefully buying ISPs additional time with the hardware that they have today.

All right. So, the bugaboo in all this, if is as I said before paths are longer and this [unclear] additional latency and additional load. So I want to look a little bit about what the actual numbers are on that are going to be.

So the main way that we deal with that extra load and extra latency is by exploiting the fact that traffic distribution across the Internet follows something like a power law where 95 percent of the traffic goes to 5 percent of the prefixes. And this is, I mean obviously we can't guarantee this will always be the case but this has been the case as long as people have been studying this sort of thing. So essentially what we really do in virtual aggregation is we take the high volume destinations which I called popular prefixes and we load those into routers so the majority of traffic is taking normal shortest path routing and it's only the majority of prefixes but the minority of traffic that actually takes the extra hop required by virtual aggregation. The way this is configured we can do this on a per router basis if we want, I mean decide what the popular prefixes are, you can decide it on a per POP basis or just make the same across the IPS. In some measurements we have done we do notice a different POPs do have different there is a lot of overlap different popular prefixes so you might want to do it on a per POP basis and we have observed popular prefixes tend to stay popular across weeks, at least, so this is not something you would have to do daily or hourly or something; it's something you could probably do weekly as a configuration task in order to keep the load and the latency down.

All right. So what we did we studied how the load and latency and FIB size would go, we had traffic matrix data as best they can measure it, we had topology data and what we did, that is little while ago actually before we had this style of configuration, and it's a fairly naive study; but basically, we did an aggregation point deployment where either all routers in a POP were aggregation points and every virtual prefix was covered in that aggregation point, or no routers in the POP were aggregation points and they would always just route the data to the nearest aggregation point if they didn't have a popular prefix for that destination.

And as far as popular prefixes go, we made them the same across all routers in the IPS.

OK. So, some data, so this is a table showing, on the X axis the percentage of POPs that were actually aggregating POPs so we went from the left which is only a single POP in the entire IPS had all of the prefixes to the case on the right where every POP had all the prefixes. And one is stretch and that is measured just in absolute milliseconds, and this is not an actual data, this is just a model, so the stretch here is in terms of speed of light stretch so it's not in that sense it's pessimistic, you would see something more, but anyway, just keep that in mind. And we looked at the FIB size. So there is I should say that in this particular set of tests, 1.5 of the most popular prefixs were installed in every router. OK. There is a couple of data points I want to look at. So the first one is on the far right where every POP had the entire routing table partitioned among its routers and the green line is the worst case FIB size. The FIB [unclear] is different in different POPs because if a POP mass more routers than the routing table entries are partitioned among more routers and so each has a smaller but the worst case would be the routers for the smallest POP and the smallest inside this particular network had only four routers and we made the virtual prefixes redundant so every had two aggregation points per POP and so we could only reduce the FIB size by about 50 percent in this particular POP so that is why the worst case is 50 percent whereas the average which is the red line is somewhere a little bit below ten percent.

On the other hand, the worst case stretch and the average stretch at that point are basically nothing because every POP has at least one router for every entry and so the packet simply takes, at worst case it hops to another router in the same POP and from there takes the shortest path and that is, by the way we measured latency which is speed of light. I will show you some better numbers in a bit with load. But anyway, so we cut the FIB in half and pay virtually no penalty for that and if you look at the thing on the bottom, this is one of Geoff Huston's graphs showing BGP B table size over the years and this sort of, you know, brings us back in a sense to 2004 levels, and the reason I put it that way is I think what is interesting for an IPS is to see how many years this approach would buy you. The other data point I want to show is this sort of sweet spot really with FIB size is quite low but the worst case stretch hasn't really shot up that much. And here we see that the FIB size in the worst case is cut down to about one fifth of the total FIB size ate worst case stretch is just a few milliseconds, again measured the way this pushes you back to 1996 FIB levels, so it's buys you some number of years' performance.

OK. I think this is, in a sense, is the most interesting graph. What I am showing here is actually take Geoff Huston's sort of worst case predictions for routing table growth, OK. And I am assuming that if an IPS has sort of the last generation of routers, so these are routers that can only about 240K routing table entries, how many years would they be able to operate with these routers and what would the load look like and the increase in path length look like over those years? So essentially how you can think of this is the following: So in, this starts at 2008 but you would start doing this and you have, you know, 240 K size FIB sate routing table isn't [unclear] more than that, you fill up your FIB mainly with popular prefixes and almost of all of your traffic would be shortest path and virtually no increase in load and latency. As the routing table gross over the years you would have fewer and fewer popular prefixes in your FIBs and you would have more and more non-popular prefixes. And so slowly, load would increase and the path length increase, this is just after average, would increase over time but if you look at this graph, load doesn't really pick up significantly, again a, best estimates which we know are not good. It could grow much faster in the pretty much feature. A good decade could you go before you really start to see load increase as a result of the extra hops that you have to take, because of virtual aggregation and if you look at the path length index on the right, I mean these are just fractions of a hop. Basically what happens happening is most of your traffic is taking shortest path and some small traction are taking one extra hop or maybe a couple of extra hops.

So that again, the bottom line here is that this technique buys you a certain A flexibility with respect to when you role over your hardware base.

How am I doing on time? Five. OK. And this is a sort the same kind of data but with a slightly different take. This, basically, is saying, on the X axis is the percentage entries that are or the percentage of popular prefix that is you have loaded I am sorry, the percentage total prefixes which you consider popular prefixes and load into your routing table and this shows the percentage of traffic that is impacted, the percentage traffic that takes an extra hop or more because of this and the red line and the green line which you can barely see is the increase in load and it shows the as you increase, the push the load way down but if you look at, say, five percent you have already pushed it quite low to probably a reasonable point.

OK. So, this actually my last [unclear] I mean this is what we have done so far: We have tried it on a ten router test bed. We know it works insofar as the mechanics of it. What we are really interested in trying to explore, we have take then as close to we can take it without getting an IPS involved so we are working on a planning tool so this is just, it's similar [unclear] a traffic engineering tool. This is something that would take in the matrix and the FIB sizes and the you know loads on links and so on and decide what the best configuration of virtual prefixes and popular prefixes should be and try to estimate what the performance is going to be out of that. We are working on, you know, as we have it now, we are still exchanging the full routing table between ISPs because each ISPs is doing this autonomously. We are quite sure that if ISPs cooperate then we no longer have to do that and if every IPS did it or you had a group of ISPs that were doing it, together they would have you know, much smaller, between pairs of routers a much smaller fraction of the routing table they would have to exchange and this might allow to you to deal with smaller prefixes as a default or crank up the timers a little bit so you can converge a little bit faster.

But mostly, we want to deploy it on and start experimenting with this thing. Anyway, there is URL here which shows a white paper that describes the deployment and the data that I have shown you, we are going to update it pretty soon with the non-route reflector variant of this, but in any event, you can read up more about it here.

And that is it. Thank you:

(Applause)

Questions?

LORENZO COLITTI: Interesting. Lorenzo, private citizen again. How do you push prefixes to route [unclear] do you just filter out the ones that you are not going to use, using the admin distance hack, is that right?

PAUL FRANCIS: In the case where we are not using route reflectors so yeah, the admin distance hack let's you basically set admin distance to 255 value for everything from a particular peer and then using a filtering table, then you specifically select prefixes that are going to go into the FIB.

LORENZO COLITTI: So you have to manually push the table to the routers?

PAUL FRANCIS: Yes, yes, there is who this whole configuration table, which is the size of the routing table today, that you are working with respect to this. We have I mean, we have experimented with that. It works, but yeah, there is a significant configuration chore that is added when do you this

LORENZO COLITTI: And can you set up a BGP feed from a random Linux box that just announces those rates with the fake admin distance? We can?

PAUL FRANCIS: Yes, yes the admin distance purely local configuration thing. It doesn't show up in BGP. So�

LORENZO COLITTI: One more: How much band widths did you use, because Yes, sir stretch zero that is because the speed of light helps you inside a POP but inside a POP links have limits, so I was can you remember I couldn't say about how much band width you used?

PAUL FRANCIS: So that I mean that would be related to the extra load, right, that you so, we have shown this data both in terms of latency which I admit is weak, [unclear] terms of extra load, which is simply because you are talking an extra hop some routers seeing extra load and we have also looked at the number of extra hops but that is also incomplete information because that is not really telling you what that is going to do do the queues on a specific router so we haven't [unclear] at full band width, we have configured it and past packets through but you know, the load numbers, depending on how many popular prefixes you use, are in the few percent range, so you can imagine what that means in terms of band width, it's a few percent additional traffic.

LORENZO COLITTI: Thanks very much.

PAUL FRANCIS: Yes.

AUDIENCE: From TU Berlin. My experience has shown that this the distribution of the most popular prefixes is not as stable as would you like to be. There are time of day shifts, there are basically, if you look at the the prefixes that are about 60 percent of the traffic in one hour, about an hour later they account for about 20 percent of the traffic, so how would that affect your results?

PAUL FRANCIS: Yes, it's going what we did with respect to that as the following: We had the the traffic matrix over a several month period, from this T U I IPS which is not Deutsche Telecom and what we would do is basically [unclear] measure the popular prefixes for a particular day, we would make our assignment based on that and then see how much that degraded over several days or weeks or months and what we found was after about a month we would have about five percent degradation, so you know, by way I mean were we to change to the new set of popular prefixes, we would have five percent improvement in the traffic. So that is what we did.

AUDIENCE: What about the small timescale effects, like what is happening

PAUL FRANCIS: Yeah, yeah, yeah, this has nothing to do with small timescale. So over small timescale you would have traffic to take this extra hop and pay that the way you pay it today in, terms of having spare capacity. But again, this is you know, we have only [unclear] we have done and we really need to deploy this, even at a small scale, we can deploy this just using one virtual prefix, using some small number of routers in the IPS, there is various ways we can deploy this on a partial basis, until we do this there are a lot of questions we [unclear] the answer for. Thank you very much.

(Applause)

SPEAKER: So next presentation is Daniel.

DANIEL KARRENBERG: Diffusion and concentration and this is another this is another bit of economics inspired talk but before I do that I promised Curtis that I would make up the time as much as possible, so I will go a bit faster.

But before I start on the presentation, those of you who were here yesterday in the YouTube presentation session, I had a small thing about results, about de-aggregation into /24s and Michael [unclear] I believe asked a question and this graph shows the answer to the question: So what this shows is the /24s prefixes over the last eight years and it's coloured according to RIR stat files types. Basically, the red ones are allocation, so roughly equivalent to PA address space, and we see that they are actually de-aggregated the locations so bigger than a /24. The green bit shows assignments, so notionally PI space that was more than /24 and we see /24 routes in it and the bottom, the flat part, shows exact assignments and their location. So the thing that the fear that I think Randy bush expressed and some other people, is actually true; we see lots of /24s that come from larger assignments or allocations. I just wanted to give that result immediately. The reason I didn't butt it in my presentation that this is based on RIR stat files and I would like it to be based on a little bit more accurate data.

OK. Having said that, we get into this one. Thank you. So, this is Bill's presentation, I am not this is actually work that Tom did, it's all Tom's ideas, but we decided that it's better that for a sort of geek engineer present it rather than somebody who is interested mostly in the economics aspect of it. So this is hopefully a little bit better targeted presentation.

And you already heard about diffusion from Jean. What this is, it's about looking at the IPv4 address space distribution. So the IPv4 address space as a measure of the competitiveness of the IPv4 IPS market. Why are we doing this? Well, I actually there are actually concerns expressed here and there and more widely, about how this whole IPv4 run route thing will close the market barriers to new entrants and force the concentration and some people were going around saying, well it's actually the RIR policies, our community's policies that are encouraging concentration rather than diffusion, and anticompetitive, to say it in a very concise manner.

So what can one say? Well, one can say, you know, if we look at the distribution of the NCC's resources, that more than 75 percent of them went to just 271 LIRs. And I have to say, LIRs here is not pure, you know, LIRs as we tend to thing of them, but what we try to do is actually group those LIRs that are part of the same company, if you wish, wholly owned subsidiaries or really the same company into one, so we are not sort of going to the artificial thing, saying, you there was a merger but they decide today keep the two LIRs alive, we tried to catch that one in order to make this a little bit more realistic.

Could you also say that 70 dozen LIRs get 90 percent, or you could say 296 or roughly 300 LIRs held 80 percent of the address space in December 2007, so this is, you know, power function, if you wish. So this suggests concentration. You can look at it in terms of quintiles, so basically saying that 20 percent of the address space in is held by only 4 percent of the LIRs, and again these are the LIRs LIR definition that takes out spurious ones. You have 40 percent of the address space is shared by just.3 percent of the LIRs and so forth. And you end up with just you know, roughly 4 percent of the LIRs holding 80 percent of the address space so that suggests a serious concentration, doesn't it?

We also looked tried to look at this data to see how the NCC compares with ARIN and that was very difficult because ARIN doesn't publish these statistics, so we had to reverse engineer that and I am going to skip over the details in the interests of time, but if you are interested in that, then speak to Tom or to myself.

Just another little finger exercise is looking at the address space, again this starts in 1989 /1990, for the RIPE data and we tried to split it off into those addresses assigned to members of ETNO, generally regarded as the old PTTs and nonmembers of ETNO and we see quite clearly that the part of address space assigned to members of ETNO is increasing. One could paraphrase this, probably not very fairly, in saying, well, to the left, the Internet was a new French thing disregarded by the telcos and to the right the telcos are catching up, so is that might be a sign of concentration.

But this is all sort of evidence that is sort of anecdotal, and we think the right way to assess this is to actually realise that you can't just look at this onedimensional thing and, you have to realise that there are a number of dimensions here. If you look about concentration or the competitiveness of a market, it's about how fast the members are growing and relatively how fast the members are growing and how quickly you get new people entering it, so how many new entrants are there over time. And yes, you can it's a very popular game to claim that a market is uncompetitive but just looking at the growth of the biggest players in the market and just say, they grow so much, you know, there is a danger of a monopoly here, but that is not quite right because you have to take it into a context; you have to take it into a context of the total size of the market, which is quite obvious, but you also have to take it into into the context of what the other ones are doing. It's only dangerous if the large growth that you know, some of the larger players are exhibiting, inhibits others, and inhibits new entrants.

So what we are saying is that we should use a little bit more formal methods for looking at this stuff and, obviously, the methods are not coming from our community, they are actually is a point for using the economists' methods and what I am going to talk about.

So Tom suggests and we suggest to use something called the HHI, which is something economists use to describe competitiveness of markets. It's quite nice, you know, like most of the economic work that gets promulgated. It boils everything down to nice single values and things like that, and the HHI is something like this. So let me explain how it works: What you do is you take you look at the market and you measure the market share. You enumerate all the paricipants in the market and say A has ten percent, B 30 percent and C 40 percent, what you do with these percentage you square them and add them up and that gives you the HHI. Let me illustrate this a little: If you have only one competitor in the market, they have 100 percent market sure by definition. You square a hundred, you get 10,000, so that is the upper bond of the HHI, that is absolute monopoly. If you have 10 players and they all have the same market share, 10 percent, so you square 10, that gives 100 and you add this up it, gives 1,000 so, just as something to keep in mind. If you have hundred participants with one percent each you end up at 100. So just looking at that.

Decreasing HHI is good, it's for competitiveness and increases other things that you gets to interest people.

Here is a few more examples just to get you into the mood of this and what we did, actually, to compute the market shares is we looked at the address space allocated, we took the LIRs, we again tried to group LIRs that are really from the same company and then we basically looked at we counted the IP addresses, the number of /32s they had and defined that to be the market share. I think that is a pretty good pressure, actually. There are there are worse ones, let's put it that way, and obviously since we are in RIR it's easy to we understand this. So, if you have suppose you have 3 LIRs which each have /24, you get 3267. If you have 12 LIRs with each /24 you are just below 1,000. If it gets a little bit more complex, you can read this in the in the minutes or on the presentations file.

Then, Tom did a really outstanding amount of detective work and tried to do some estimates at least for once comparing ARIN and to the RIPE NCC by looking at some statistics that ARIN produced produces and the reference is in the slide pack, about allocations for about the address space they gave out recently. And he comes out and then the thing is that we don't have the exact numbers; we only have categories, so he assumed the lowest amount in the category, which sort of makes it a lower on the HHI and we get a 335 for ARIN and we did the same sort of calculation for RIPE and we get a value of 311. I know you will ask ask yourselves, what does that mean well, good question. Here is what usually sort of competition policy uses. If you have HHIs that are currently less than 1,000, it's basically called a competitive market. It's less likely to have anticompetitive effects and you will not draw the attention of the competition people.

If you have if you are between 1000 and 1800, it gets to be orange and you look at the dynamic range, is it changing, how much is it changing and how much is it increasing and so forth. So, with 300 something, we are actually quite nicely in the safe zone for raising attention.

Now, this is the central slide of this whole presentation. We did this for the allocation data that we had for the RIPE region and we end up with this where the it's a logarithmic scale, so you could say below 1,000 is safe and you could say that, roughly from 1996ish, in the safe zone, and constantly decreasing. The difference between the two graphs is that the red one is taking each LIR as LIR as defined and the slightly lighter one above it is the one where we tried to group LIRs based on ownerships and company structure and we don't claim we did a perfect job there. We did as well as we could. Tom did this. And there is a few anomalies, you see on the lefthand side, well, actually, that is could be data errors, it could be just too small something, and you see the large jump there when the UK ministry of defence actually got an unusually large amount of address space in the middle of 1994 at the end of 1994. But that is not the main point. The main point if we use IPv4 address holdings as a measurement, then, actually, our the anti the competition people wouldn't, you know, pay that much attention. What we do see, however, is that it doesn't go down any further. But, OK, I don't know what to make of this yes, thank you that is unfair. I will be done shortly. So draw your own conclusions. The one thing we want to do is to continue to monitor this and OK.

We actually also did this for, on a country by country basis and here we did actually use the atomical LIRs, two slides to look at countries between 2004 and 2007, 9 last three years or so the HHI went down so they became less concentrated or more competitive, whatever. And actually, I think we are doing quite well, and I don't want to discuss any single case here, but just show you this. The opposite, these are the economies where 2004 to 2007 became more concentrated and you draw your own conclusions and you look it up on the presentations website and draw your own conclusions.

So, few observations: Two minutes, OK this study is about RIPE region, others may differ, although some detective work it looks like ARIN is at least similar for one point in time over recent history. There are concerns about concentration tendencies and people have been saying this.

Presently our studies don't confirm this for the RIPE region. I think it's quite convincing. We see increasing concentration over the last three years in a few economies.

I think it's also safe to say, although it's new so not [unclear] academic, that our studies suggest that the address space distribution policies today, what our community has come up with, how we distribute address space, is at least not a significant factor in either being competitive or uncompetitive because if you just look at these, you know yeah, they are these two, but our it's not like that our policies increase because markets have become less competitive in a majority and it's probably a lot of other factors that contribute to this picture.

As the unallocated pool of IPv4 exhausts, and we have been talking about little else, concentration and impediments to new entrants will be blamed on this fact. What will happen if we run out of IPv4, no matter what we do in a policy area people will say and especially those people who are sort of the less competitive ones will say, no, it's not because of us, it's because of this IPv4 right now, thing. So it will be blamed on IPv4 run out and transitively we will be blamed, whatever we do, it will be blamed on our policies. I am a bit cynical about that. It's your fault.

So, I think we have to keep this competitiveness, diffusion and openness to new entrants in mind when we are developing address space distribution policy. I think if we develop policies that clearly make it aggravate this, we will not just be blamed but we will be blamed badly. I think we have to keep watching trends in this area, but since we have now done this work we can continue doing it and my question is, are there other methods to study this, are there better methods to study this? And that brings me to the conclusion. Questions and answers, but the policy discussions, please do that in the address policy working group and not here.

AUDIENCE: I take it all back, this is great work and it is really interesting work, but my one, I suppose, issue with this stuff, and I have been doing similar, is that I have actually been trying to use the public data that we have and only that, and I would plea too both RIPE and ARIN and other who do publish I actually want slightly better data and I would like something to at least understand that when with you do two allocations two years apart they went to same end point. I don't care who it is what their name is but I really need a little bit more public data because I really think if you make good data available, not only can do you this work but the rest of us can apply our methods and see whether we come up with the same or different answers. So more data pubically?

DANIEL KARRENBERG: Second and third and quartered, I fully [unclear], I have set wheels in motion to see that this gets improved.

KEITH MITCHELL: Keith Mitchell, ISC. I think it would be really quite interesting if somebody did a similar analysis on the domain name market, as well, and compared market shares of registrars. Do you know if anyone has done that?

DANIEL KARRENBERG: I don't know and I won't

KEITH MITCHELL: I am not asking you. I just think it would be interesting?

DANIEL KARRENBERG: Wrong answer. A, I would agree it would be interesting. 2, I don't know. 3, I won't.

(Applause)

CHAIR: We are done for coffee break and see you all back here in 30 minutes, I guess.

(Coffee break)

The plenary session continued as follows:

CHAIR: We are going to start in about two minutes from now. Ladies and gentlemen, this is the last session, there is nothing between us and beer. Obviously, for the newcomers who don't know who beer means in a RIPE meeting context, there is still the newcomers' meeting and they will find out what beer is after that. But without further ado, Gert is going to give us the IPv6 update.

GERT D�RING: Welcome everybody. This is sort of a regular thing, so you have seen this introductory slide yet and the question has always been the same, and this time, the talk is very, very quick.

The answer is yes, we have reached 1,000 prefixes, thank you very much. That is it.

(Applause)

Well, since everybody is awake now, I can start with the real talk. [unclear]

I didn't check what AS got the jump from something like 998 to 2002, so it was five prefix that is showed up on that day. There is more exciting things about two weeks later on so the thousand wasn't really not that impressive then. That is what is in there, basically it's about the IPv6 BGP table and sort of related things, some pictures trying to [unclear]. There is nothing about the end of the 6 bone. This time, I have removed all the slides but forgot to remove it from the overview. Some slides full of numbers that I won't go into very much detail today because it's on the web and if you are interested in all of these details you can read it up. The focus is more like to see where the journey is going and to do a little bit of fingerpointing at things that should not be there.

This is a total the total number of prefixes in the IPv6 BGP table over the last six and a half years. Six and a half years ago, well I sort of, well, earned this talk by doing a stupid thing; I talked to David Kessens and I said I have seen funny thing in the IPv6 BGP table shouldn't we have a talk about it? And he said, well, thanks for volunteering, and here I am.

I promise some excitement directly after the 1,000 prefixes point. It's the most visible. Yes. So here we have prefixes in the middle of December last year, thousand prefixes have been hit and then directly before new year, we met over 1,200 prefixes, and here we hit nearly 1,300 I will go into more details on what exactly happened here, and then we had another nice league of lots of prefixes in here for about a week, disappeared again, using the mouse to point and, at the same time, getting it to click is not very good idea. Well, anyway, there is more instability. Trying to ignore all the instabilities and plotting a trend in this, is, well, not very scientific, but I just decided to draw a couple of lines and it sort of looks like the growth is speeding up while still being mostly linear of some sort, so it's not the typical exponential growth but it's definitely speeding up, so IPv6 is being deployed, which is a good thing.

Looking into the tables and sorting it by regional registry, we get the same absolute number but the individual graphs are lower. One can get an idea on where the instabilities are coming from. These two very sharp spikes we saw around new year is coming from the APNIC region and this is quite interesting because, actually, the prefixes are coming sort of simultaneously from the APNIC and from the ARIN region at the same time. They come on the same day and disappear on the same day and then there is instability coming back from the APNIC region but not from the ARIN region so I have more slides to detail what exactly happened there.

The overall trend is pretty much unchanged. The RIPE region is on top because we have the most local registries so we have the most routes, [unclear] not very surprising. The APNIC region is actually slowing down since quite a while and has been going pretty much steady, while the ARIN region has been growing again and has overtaken the APNIC region sewn that is sort of a surprise here. And on the bottom, you see LACNIC and AfriNIC, well they started later but they are doing pretty well, I think.

This is zooming into the RIPE land, Germany on top, which is also not surprising; we have the most ISPs and we have the most v6 prefixes, then the usual suspects, UK, Netherlands, France. Since there is no real nice anomaly, instability, this slide is pretty bothering and we go to the next one.

This is the promised numbers. Looking into the ASes that show up in the BGP table, we can see that there is significant growth from about 800 to over yes, over 930. Of these, most of them are original only ASes, ASes seen at the end of the BGP path and don't [unclear] seem to give transit to other ASes, but about one quarter is actually giving transit to other ISPs. So that is sort of normal to be expected, thing. There is still 34 ASes that don't originate their own IPv6 address space but are visible in transit path. This is usually sort of clusters of networks where one of the ASes is only used for the transit network and the end sites along have the prefixes that are originated.

Regarding the number of prefixes that a typical AS announces, the idea behind IPv6 was always good aggregation is possible and so one would expect that every AS would announce only one prefix and for most of these ASes this is true. Over 770 actions originate only one prefix so the routing table still is small even if there is many participants we have a couple of ASes that announce two or three prefixes, mostly due to very good reasons, and we have a couple of funny AS that is announce up to 34 prefixes, and I will go into more detail on some of those, later on. With everything that is related to BGP, it should be pointed out from which point you are looking at the data. The data is taken from a router in AS 539 which means that the number of original ASes, transit might be different if you look from a different point in the BGP table because sometimes you just don't see all the paths.

This slide is actually an old one because nothing much has changed here. There is some reasons why people announce two or three prefixes, or sometimes even six or seven, that make good sense. My favourite target for bashing is, of course, this one. They have received 35 from ARIN at some point in the past that has been extended to a 32 at some other point in the past and we have seen lots of ASes that announce both for a while and then withdraw the 35 at some point and, so this is why the slide says "temporary" here. On the other hand this example is here since two years, I think, so temporary, question mark. Then we have ASes that run different things. This is cable and wireless, they have their own local registry space and they used to run two exchange points, one in Munich, one in Hamburg. The Hamburg one is no longer active, prefix is still there, two got two exchange point prefixes and announcing them. You can argue whether or not this is a good idea if you say it's OK, then it's normal that this action announce three prefixes so perfectly fine. Then you have large networks that are worldwide that have different registry blocks per region and are announcing customer networks from their own AS so it looks pretty healthy as well. And then we have some of the funnies, some of DNS folks, I don't know, they really seem to think that they need independent addresses and lots of them because that is not the only one; the one with 24 networks is also one of the DNS guys.

On a sidetrack, you have heard this morning that 60 bit AS numbers are running out so it's time to prepare for 32 bit AS numbers. There are some exactly five, to be precise, 32 bit AS numbers visible in the IPv6 BGP table and that is these, up there. With normal IOS on Cisco you will not see them, you will see 2, 3, 4, 5, 6, because that is migration mechanism to enable 60 bit AS capable routers with to interoperate with 4 bite AS numbers. As far as I understand, most current can now handle 32 bit ASes, Cisco can do it on IXR. Cisco supposed to arrive later this year in an experimental IOS release which I am not really happy about. Well, Cisco marketing.

This slide is detailing the prefixes by prefix length and region. It's one of the slides that shouldn't really be there in the presentation because it's hitting the audience with lots of numbers and then going wishy washy about it, so I am not going into it.

Basically, it's there if somebody is really interested to see how many more specifics, less specific, things are there, how bad is the ARIN region doing and how well behaved is the RIPE region or vice versa, the material is there, OK ten minutes left, I will do that this is graphically trying to demonstrate the prefix distribution and the arrow show the instability in the respective year, so in the 48s, we see that the average number of 48s is something like well over hundred so [unclear] not so much instability but for the /40s, we have it's jumping up and down between 16 and 400, so there is much more going on. I need to work on that slide because it's not as obvious as it should be, and I am still waiting for someone to come up with a good idea how to tackle that. Going back to the allocations this is also a fairly traditional slide with updated numbers. The main point of this slide is to show the relative ratio between IPv6 allocations in a given region and the number of members of the respective registry, and when we say RIPE has 900 IPv6 allocations and say APNIC has only 366 it looks like RIPE is leading we are so great. If we look at the percentage it's actually RIPE is somewhere over 15 percent and APNIC is about 13 percent, ARIN 14 percent, so the relative numbers are pretty close. What you can also see is that the growth since the last RIPE meeting. The date is wrong here. This was actually from the December numbers. Now, the October numbers from the last RIPE meeting. The growth in allocation has been pretty significant. RIPE has increased the number of allocations by 42 percent in six months, so something is really happening there.

Also quite traditional, trying to understand if we have 1700 IPv6 allocations and just about 1,000 routes, where is all the stuff going? Is it specific years that are missing or is it just taking a while to show up? We have here the solid lines are the allocations in a given year, like in 2004, and the dotted lines are on the next year's January 1st and the year after and year after how many prefixes are visible? And it's actually quite obvious that even after four or five years, for example here in 2004, still half of the prefixes are missing. Some of them going [unclear] to close deployments like air traffic control and something that really are not connected to the Internet, just need unique address space, but most of them seem to be, well, sort of missing in action. If one looks into more detail to figure out where that sort of like, it's mostly ARIN prefixes that are missing or mostly RIPE prefixes. There is no clear picture, so it's sort of across all sorts of prefixes and across all regions. About 40 to 50 percent are missing. I have speculated about the reasons and haven't, well, sort of, had more insight. It's too many to chase down each individual network. Yes. So I am not going into this, into more detail now due to time constraints.

This is to give you an impression of what is going on the PI network front. RIPE don't have PI network yet in IPv6 but the other regions have. APNIC has assigned nine since the last meeting, among that very big one to HP, LACNIC has assigned four, AfriNIC has assigned two, ARIN has actually assigned 51 and that is just too much to write them all down. Among these are quite interesting one, just two weeks ago so this is interesting because Google has a 32 already and is using that for IPv6 but they got another PI network and if somebody is here who is permitted to speak about that, I am curious to hear about it. If you are not permitted to speak about it, then, well then we have new DNS Anycast assignments and a couple of very large assignments to providers. The message that have slide is if you do BGP filtering, which is encouraged, please make sure that you your filters are permitting these things that you want to see.

OK, I promised I am not sure I will try to make it. I promised more details in the new year's spikes. Actually, it was quite interesting to see how other folks run their network because it seems that this network 4787 is having aggregate rows in their internal BGP for all nibbles, so in their 32 they have 60 routes for 36s and 256 routes for /40s, but seemingly, nothing else in BGP. At least that is what they leaked. So they leaked 272 routes that should not have been there, and looking at the different paths, you can see that the aggregate goes over a completely different path than the more specifics. So the up streams, if they send it to the up streams, did proper filtering and somebody else who was peering with them leaked it over weird channels that really shouldn't be there. The next speaker, Ben, will go into more detail on these weird things.

The next big instability was, well, I termed it routing out of space because it all came out of [unclear]. NAZA that is their own network with lots of more specific in it. That is this block here. And they have a peering with Internet 2 that has a peering with some Korean research networks that have also lots of internal deaggregates and for some funny reason NAZ leaked all of these to AG Net and sent them to all the world. HE.net has received some angry emails about this and really cleared up all their clearing policies so thanks very much to NAZA for uncovering this. Unfortunately, American research networks are weird so since NAZA cleaned up their mess it was good for about one week and then the Korean prefixes came back over AC S A so research network do funny things.

The bad thing about that is that even if you look at the path for the aggregates, you can see that there is no proper path, really, to reach these Korean networks, so it's a Korean research network and a Thai research network and there is really lack of interest in getting proper connectivity, and this is a problem. More funnies some network that I am not finger pointing at, has received PI address space and nicely deaggregated it and, well, deaggregate or not, has received large chunk of PI space and announce it had in 34 prefixes from the very same router, for whatever reason. And then we have nice lack of filter here, my tools said what sort of prefix is this, I cannot match this to a given region. I said stupid tool, I have missed another thing and then looking more closely, it's missing a 0 here and the 0 is not in front where it would matter but the 0 is here where it does matter a lot. And looking at the path, it was not a hijack or anything; it was really this network mistyping their prefix and all their up streams picking it up and distributing it. Better filters. So much for the BGP stuff. Traditionally, there is an overview about the number of route 6 objects in the RIPE database and the number of routes in the RIPE region. At the last meeting, we had just about matched that was here, the last RIPE meeting and this meeting I see that there is many more route 6 objects in the database than we have actual routes. So that made me even more curious; do we have a full set of routes, route 6 objects for all routes? Or is this completely different route 6 objects, is there any correlation or not? Which is actually not so easy, because there is some route 6 objects for prefixes that are multioriginated like 2002 or 2001 /32, that just distort the numbers. Then we have, interesting enough, 43 route 6 objects for prefixes that belong to other regions, which is nice to see that the routing registry is actually being used. And if we correlate all this, I come to the conclusion that we have 358 prefixes that have route 6 objects in the type database where the original matches, the prefix matches everything is fine, so these are really nice guys. Then we have 125 prefixes from the RIPE region where the route 6 object is missing. We have 8 prefixes where there are 6 object says this should come from ASA and it's announced from ASB, this is really not so good. We have 6 prefixes that are announced from two different ASes at the same time, which is sort of weird; I didn't find time to actually contact the host and ask them. But this is something I plan to do. And we have 201 route 6 objects in the RIPE database that have no BGP route and some of them have really never seen a BGP route like somebody registering all their /48s. From the other regions we have 40 prefixes actually that have a route 6 and match and we have 3 prefixes that have an origin mismatch and most of the prefixes of course have no objects in their RIPE database. So in the RIPE database the situation is not so bad but needs more work. In the other regions interests there is still much more work to do.

Here is an example how Route6 object looks like. It's very easy, very straightforward, please do so.

Some references [unclear] to find the slide online and that is it, actually. It shouldn't click in the middle. Here we go. I think I made it with just one minute over time.

CHAIR: It's perfect timing actually. It allows a few minutes for questions. One minute.

GERT D�RING: We will have discussion about this, like how to proceed, what are useful things and not, and so in the IPv6 working group on I think it's tomorrow, yes, Wednesday after lunch, so please come to the IPv6 working group and have a good discussion on this. Thank you.

CHAIR: I would like to invite Bernhard Schmidt who is going to talk on problems in the current global IPv6 routing system.

BERNHARD SCHMIDT: OK. So, my name is Bernard Schmidt, I am from the soup computing centre in Munich and I am talking about some problems in the global IPv6 routing, we can see for the last couple of years, yes, just the key to IPv6 deployment is user experience. We don't want to run IPv6 networks to do trace roads and look at the pretty BGP path and whatever; we want to have our users to use IPv6, we want them to fire up their player at some point in the future and just keep just use IPv6 connectivity. The problem with this is most interactive traffic today is TCP based,, applications, that are IPv6 enabled basically do the same thing. They do get on the get back a list of addresses that is ordered in away, depending on the implementation but usually it's IPv6 before IPv4, and then they iterate through this list of results and try to connect, do a connect call and if it fails, they try the next address. If it works, we have a connection. So, when we iterate through this address list, there are several things that can go wrong. There are good error cases like the destination network is not in global BGP, we send the TCP packet, universe route there so it sends back an IPv6 unreachable message and the next address in the list which is usually IPv4 is immediately tried. The user doesn't notice anything.

The next is if the packet goes to the destination network but the destination host inside the network is down, most router if not all router implementations said back unreachable message, again just three seconds time out and the section is working or the usual case if the service is not listening on this port, on this address we get it back TV P reset or another IV M packet and again we try IPv4.

Unfortunately, this is not always the case. We have many situations where the initial PCP packet is just not answered by anything. It's retried and retried and retried by the local Sec, usually for several minutes, on Linux I think it's about 3 minutes on windows, usual not much less so the user types in an address in his web browser and sits. It's saying connect today www.something and no go. Even worse, sometimes the connection is established, we get back TCP and we have a three-way handshake and then the connection itself has some problems. For example the latency is extremely high, we have an extremely low throughput through their connection, or worse, we have a path end user issue which basically means we get this connect call is successful but the connection gets stuck as soon as you try to transfer any data. The big problem with this is TCP [unclear] ever recover from this problem. As soon as off connection established there will be no fall back to IPv4. Users have noticed this as well, of course, and if you try to go to any web forum from you [unclear] to windows, whatever, the usual advice on any connection problems is disable IPv6. Actually, there have been, I think, the last two Bunte releases had IPv6 disabled by default because of these problems and these changes where there were changes done just a few weeks before release due to some people asking them to do so.

So, one reason for this problem is the evolution we have seen IPv6 back when 6 bone started, people started throwing tunnels to everyone who was responsive or who was active in the IPv6 world, they were cheap, there is no fee attached to them. So, we have seen dozens of tunnels from Europe to America and so on. Later on a couple of years later, people tried to optimise their round trip times by fiddling with the BGP matrix and keeping traffic local. Even later, there were some more optimisations, for example don't send prefixes that you just learned from a Transcontinental tunnel back to another transcontinental tunnel. And in the end, we ended at the same point where we are in IPv4 today, we have business model that fits our BGP model which is transit peer and downstream or transit peer and customer relationships where I sell traffic and worldwide transit to a customer, but, unfortunately, they are still networks that either because they are on auto pilot or God knows why still operate like in the beginning.

So, I tried to find some data on how large this problem is, and there is a pretty nice BGP collector called GRH where I think about hundred so you can do some nice data minding. The idea is, you get two large AS numbers, in this case for this example I have taken 3257, and 6939, AG.Net. If there is a direct peering between those networks, AS 6939 the send are should send all his customer prefixes directly on the peering so the path would be 3257, 6939. You can do a regular expression on the BGP table in GRH and get back a result there that they are currently 97 prefixes with this path, so HE has obviously set 97 customer prefixes that are send on a peering.

Now, the idea is that should be should all be should be all HE.Net customer prefixes, so everything that is still visible through still sees in S path through 6939 is either on a direct peering or not there. Again, we can do the regular expression query in GRH and get back results of routes, down here. That are crossing through HE.Net and then through a couple of other AS in these, 6435, is 7717, I am not exactly sure I think it's chunk what Telecom and sprint and then [unclear], so those should not be there. This is basically the same thing I was telling before, 97 direct path and indirect paths, 8, which is advertised as part of a full table to a client by HE.net in this case and then leaked back to the global routing table. So basically this, path means 6939, the prefix from 2516, I am not sure who this is, advertised it as part of a full routing table to Lava.net and they just send it on.

So we have a result. Direct routes 97, indirect routes 8. Then we Mick up a few large ASNs from the current routing system, do the same analysis for all of them and then do some educated guesses. The full table looks like this. I would suggest you get the presentation from the RIPE server afterwards because I think it's pretty small. There are some interesting point in this data. First of all, as you can see in this data, from AS 1273, that is Cable & Wireless, 30071 in US there is no direct peering, no direct paths, and 56 prefixes seen by by cable and wireless. All those paths are through Tiscali, so Cable & Wireless Tiscali. Same for 6453, that is Tata, I think, today, used to be Teleglobe. Also 56 prefixes, also through Tiscali. But if you look down there, OK identify has neither direct or indirect route through the two ASNs. We know from message on the IPv6 ops May list that Okied actually receives a full table from Tiscali, so it's basically a Tiscali customer and what you see here are the first signs of IPv6 peering. We want to be tier one, we filter everyone, we don't see on a direct peering and force them to peer with us. This has caused several problems, several times in the past. There are some important websites, ARIN website, the ITF website used to be single behind Okied and this state of emergencies basically says the bad thing before, you send a TCP and it's just black holed, it's time out, the user experiences are time out. Other interesting things: 3356, that is level 3, gets a full table from it is a Callely, so it's an Tiscali downstream. But it's not advertised by Tiscali to any peers. You can see this at the moment because global crossing has, or had, I think it's fixed since about two hours, some interesting peering issues with Okied and level 3 so as you can see, global crossing had no path at all to level 3. Obviously not advertised by Tiscali.

So, there is a termed called it filler feeds it, needs some explanation. I think I just come back to this later on. There are about 50 prefixes today in the routing table that don't have any proper global upstream at all, Gert mentioned a few, they are especially common in the LACNIC region, almost every research network in the LACNIC region has this problem a few of them are in APNIC region, and some old 6bone participants have this problem as well. There are sometimes political reasons for that, I am going to outline a specific problem, a specific example later on, but most times it's just laziness.

So, now, come back to the term "filler feed." To get a path, may it be working or not, to every prefix that should be there in the global routing table, you need something I call a filler feed, that is basically a link between BGP peering to a network that sends you its full table and you visit a transit of last resort. Even if you are very large global network you still need this filler feed to have all to have prefixes to have all prefixes in your routing table. Some of them large ones do, some don't, just a list, cable and wireless currently doesn't have a filler feed, so as you can see on this slide, the total number of routes is way lower than for the others. It used to be UPC, about a year ago, I think, UPC start today clean up their network and didn't do these full table feeds any more, so since then, Cable & Wireless has essentially no full table any more. NTT uses 7660, that is Apen in Japan. Tiscali has nice set, it used IIJ, apparently a full table from 82 prefixes but among those are also peering prefixes, customer of IIJ, same for sprint. We already had level 3 gets a full table from Tiscali. Global crossing gets one from I don't know any more who some APNIC region. Tata has no fill enfeeds. Same probably goes for Horizon, I don't know there was no data, they don't have GRH peering, I don't have any full table data, so guesswork.

One example: CA.net, which is the Canadian research network, runs an IPv6 network, has IPv6 prefix, peers for example with , the European research network, and has pretty nice connectivity but they don't have commercial upstream for political reasons, because in the American region it seems to be common that the national research networks only transport traffic between their members, they don't traffic in the commodity Internet. Every university, I think it's called cluster in the Internet 2 region or supernode I am not sure any more has to get its own transit for to the commercial world. This is not happening, not easy happening because would you need to deaggregate your /32 for that, so basically what you can see here is are paths from all larger networks to and from CA.net and you can see really weird paths. For example, from level 3, we go Tescally, IAJ, white, which is in Japan. APNIC which is also Japan, 22388 is Pacific [unclear] I think. Internet 2 and then CA.net. And the path back is even worse, you have got go through all paths to the commercial world, go through Kreo.net, that is Korean, China.net, Apen, White and 4725 is Softbank I think.

That is a smoking graph, latency graph over time for the last year. This one looks pretty nice. We have stable 140 milliseconds to a host within CA.net. And unfortunately, this is from a research network in Munich. So connected and then on a direct peering. This is the same graph from the commercial world. You can see several days of outages here. Latencies up to one seconds, high gloss, the path looks weird again, KPN Sprint, IHA and we heard the rest before and Korean net, China.net, Cable & Wireless peering and Hong Kong. I did a few throughput measurements and these numbers in front that is from Germany to Canada seem to be out layers, there seems to be some software problems, we don't know the. The other direction is fine. From the commercial world, from AS 259 we got one 30th of the throughput and three times the latency and just yesterday I did the same test from the network here at RIPE 56 and, well, 56 kilobits of throughput on 800 milliseconds round trip time. The path yesterday was KPN Sprint. I don't know Lava.net, that is Mexico again so some pretty weird things.

A nice way to see problems like that is if you withdraw a prefix from the global BGP table, it doesn't disappear instantly, but the paths gradually get longer for a short period of time because direct paths disappear and peers change to worse paths so you can see paths that usually would not be seen. I did this with a customer prefix, yesterday, I withdrew it, BGP updates and these where the paths you could see. Direct peering between DFN and my upstream and there was global crossing between which is upstream for both sides and then I try KPN, Cable & Wireless appearing between Cable & Wireless and global crossing and then customer give then the prefix was gone. This would be what would you like to see. Unfortunately, 30 seconds later, we got these paths. So, basically, in our model, every ASN which is in this path is transit aft least one side of either source AS or destination AS. So if you look at the last path here, we know for sure Tiscali is not upstream of global crossing, so this is the peering. We think we can no IHA gets a full table from Tiscali, so let's assume they are downstream. Send through throughout it goes sight seeing around the world. There is an effect called BGP ghosting which basically means a router forgets to send an update or withdraw message out to peers, so these paths can stay around for weeks or even months. This was a problem with SISCO for years, I think I fix it had last year and now foundry has the same problem, very new, in their top lines which is we have ghosting. Actually the number of ASNs which are visible in these bad paths is pretty short. It's 278, that is Mexico, 2500, that is [unclear], Softbank, Lava.net, AP and [unclear] Telecom. I tried to contact some of them, no answer. If anyone has contacts for them, please try to reach them. Shut it down. I have tried to reach a few larger networks and solve part of the problem. We have had some progress, global crossing has de-preferenced their filler feed which they should have done before and applied a filler to sprint and sprint was always a source of the bath paths. Steve Powell fixed this. Has contacted and applied filters to the session with [Wyatt] so the immediate leak was fixed. Now they get the full table from Apen in Japan. Again, thanks to Brad from NTT who fixed this. And mike Lieber at HE.net has fix add tremendous amount of issues. They have apparently dropped two 6 bones ASN style completely. Let's hope. Last slide. If you look at the matrix I made earlier, there are only two peerings missing from getting a full mesh of the listed ASNs. So, if you try to call them tier one of the IPv6 world, and drop all those filler feeds. Everyone who is customer of at least one of those networks would be visible [unclear] globally with a good latency and good throughput. The problem is there are no Tier 1s in IPv6 yet. If we tried to define them, by whatever matrix, there will surely be some peering some disconnects I want to be at tier one but my neighbour doesn't want me to, I would not do this. Another idea would be if those networks think they need those filler feeds, or some apparently don't need to, they should start fit [unclear] large ASNs in all paths they get from these filler feeds. So basically this would lead to a world where you still have prefixes without global transit that have some bad connectivity but at least this issue would not reappear. OK. That is all.

Just to point us, the excellent IPv6 ops mailing list run by Daniel, if please subscribe if you do anything operational. And for tomorrow, if you want to use an IPv6 enabled web proxy that is just the latest check out of squid 3 branch as a host name and a port. OK. Questions.

(Applause)

RANDY BUSH: Randy Bush, IIJ. Two questions: First of all could you put your email address up on the screen so I can write and send a couple of the people you mentioned you want today contact to you. Thank you.

Secondly, could you react to the following hypothesis: As v6 actually scales up, these kind of problems are going to get worse and one thing which is, if done, would greatly reduce them, would be do not BGP peer over a tunnel. Tunneling to a stub is one thing. BGP peering over a tunnel is not going to scale.

CHAIR: This was a hypothesis?

AUDIENCE: I am suggesting this seems to me to be something that might solve some of these problems as things scale but he is actually done looks, has done measurements far more than I have, I am asking his opinion on that hypothesis.

BERNHARD SCHMIDT: OK. I think tunnels are part of the problem because only through tunnels networks like Lava.net and mess [unclear] so on are allowed to participate in those problem, but the root cause, BGP paths can you not control, you have no SLA whatsoever on it, are caused by broken BGP policies, sending a full table everywhere and not having the transit peer customer relationship, so actually, the worst network I have seen in all those paths WIDE is fully native sparse I know, it's a policy problem. Tunnels are bad as well but the BGP policy is the problem.

GERT D�RING: Gert D�ring, also somewhat related to this routing thing, tunnels and so on. Tunnels are bad if there are, well, sort of just put [unclear] tunnel everywhere because it's so cool to have so many tunnels and not controlling what is going where and not controlling the MTUs and all the usual things. Tunnels can be very useful and do not actually hurt connectivity if well controlled, like you control the IPv4 path, the IPv4 path is short and sometimes you need to just run BGP on there, but I think I share the emphasis with [unclear] that you really need to control your BGP policies.

RANDY BUSH: Certainly you can do more damage with BGP policy. There is enough knobs that you can blow up the world. With ATM 1 and 2, et�cetera, we repeatedly learned the lesson that when the control plane tells us information about congruence that is not really true at layer one, you are going to be in more and more trouble. Geoff is shaking his head.

BERNHARD SCHMIDT: Something else I think we are a little bit short on time today but lots of time in the IPv6 working group so I suggest to continue or enhance the Constitution over there then and this is.

CHAIR: This is the point where I am going to close the queue at the mikes. The people who are here can stay.

GEOFF HUSTON: I don't believe it's the tunnels are the issue one way or the other. If you tunnelled across the next level down in the protocol stack et�cetera, et�cetera. It doesn't work like that. What you are finding with this particular problem we have got the mind think that all of the v6 traffic is actually paid for by v4, so that when I peer in v6 it's just a game, there is no tearing, there is no upstream or downstream, we are just playing games, so all of a sudden you start to realise that what happened in v4 when money stepped in the door was that the hierarchy that we got inside this network that created quite a lot of structure in BGP was a hierarchy built by economics and that actually makes that routing system quite tightly unlooped. It works very well. In v6 you get this arbitrary stuff where provider and downstream, your customer relationships are purely abtree, and the result is that you get astonishing instability and these filler feeds that you referred to, oddly enough if they had to pay for v6 routing like v4 that is what I think would clean things up. This is all opinion by the say

BERNHARD SCHMIDT: Yes, definitely.

DANIEL KARRENBERG: One sentence, please. It's just a different layer one.

AUDIENCE: Chris [unclear], I represent myself today: So one thing I see in the presentation and it comes in a lot of people, like oh Tums are bad or these whacky BGP paths, a lot of it is. V6 network is not anywhere near as [unclear] as v4 network so you see these are the only place to get from place to place. The other part nobody does any really filtering because it's essentially all everybody's lab still. Geoff's point about the money brought on the rigorous filtering and making sure I am close to my customer, I want to peer with my customer's network that really hasn't come into existence in v6 yet so you have this kind of crazy setup which is going to persist until some real reason to have v6 up and running exists, that has real money behind it.

BERNHARD SCHMIDT: The big problem here is we want our users to be dual stick which means we should use IPv6 but they should not notice and if the IPv6 path is really broken they do notice and they disable IPv6 in their client for the next two years.

AUDIENCE: The real problem [unclear] want your customers to be connected to the network. You don't care where it's 4 or 6 and they don't care.

BERNHARD SCHMIDT: Actually I do care if it's IPv6.

AUDIENCE: But you really don't you want them on the network and you want the services and applications to work just like they are supposed to, appropriately, some vendors make that happen, some don't, some networks there is no money behind it so there is no rigorous work behind making sure things are filtered properly, that you pass peer routes on a link to customer, not on to peers, for instance. So

BERNHARD SCHMIDT: I would say almost 90 percent of the global routing is running in this model but you still have networks that run 6bone style.

AUDIENCE: So 12702 is [unclear] test v6 network?

BERNHARD SCHMIDT: I would say it's a production

AUDIENCE: I used to work there. It's a test network.

BERNHARD SCHMIDT: And [unclear] base the BGP policy. That is the big part.

AUDIENCE: There are people there spent time making sure it's a little more rigorous. There are five people in uniform who know anything about that network I think.

BERNHARD SCHMIDT: I will we will move it tomorrow to the IPv6 working group.

CHAIR: Thank you again.

(Applause)

CHAIR: I was a little bit confused when I saw the title for the next presentation by east an. I thought it was about deep space observations of clusters of galaxies, but apparently, not.

ETHAN KATZ-BASSETT: I am Ethan, we have been working to understand routing problems and I am going to present had you been he will which is our system to continuously monitor black holes across the entire Internet. This is work with colleagues at the university of Washington.

So the most basic goal of the Internet is global reachability. If you are using Skype you want all your friends to be able to reach you not just those who are customers of certain ISPs and I think there is often an assumption that if there is a valid policy compliant physical path there will be an about path and traffic can reach the destination. For our purposes a black hole is going to be a persistent violation of the second implication and one of mac's examples yesterday from the mideast cable cut showed an example where there was a BGP path but traffic wasn't able to reach the destination over it.

So, we can ask to what extent does the Internet actually provide global reachability? It's well known there is short term connectivity problems during BGP convergence and we have a system called consensus routing that can show how to fix that. But I think from most of our experience I think things usually work, there is not long term outages and it might be natural to assume this is because the protocols are just making things work but then when I start reading the NANOG, I start seeing messages like this. There is an operator who thought that he was having a problem with one of his networks, he wasn't exactly sure what was going on, didn't have the visibility to see how widespread the problem was and he had to resort to post to go the mailing list, asking for help and other operators actually issued trace routes and then posted the results back to the mailing list. So, it seems like you know it's hard to know what is going on. You often have limited visibility of the extent of problems and sometimes there is lack of tools to really investigate it and I am sure most people in this room probably know a lot better than me there is a lot of human effort. If these sort of problems happen once in a while it might be no a big deal but when you start issuing measurements, there is problems all over the world. This map was generated using had you been he will and Google maps obviously and each of these represents a prefix that had previously been reachable and it had become partially reachable from some and not from others. The colours indicate how long the problems had been going on with darker colours being longer lasting problems, for example the light yellow colour were problems that had been going on up to eight hours and the darker colour were problems that had lasted from a day to two days and in fact at any point in time we see thousands of violations of global reachability and this map is just showing ones with certain properties those that remain partially reachability and problems only persisted for up to two days. Our [unclear] with had you been toll is to monitor awful these problems across all the entire scale of the Internet and to identify them, track them and try to classify the causes and the lesson of this talk it's possible to do this by combining multiple information sources. A problem that had you been he will actually found on October 8th of last year and this examples both meant to show the types of problems that we are looking for and also give a flavour of how the system works. So in 24 example destination D, and then X, Y and Z all advantage points around the world. Before the problem started awful the advantage points had been able to reach the destination and suddenly, something changed so, first, ex ping D and received a response. A few minutes later, Z pinged and the ping failed. So at that point we suspected some problem and we are going to launch a distributed trace routes from all of our advantage points to try to determine how widespread. X was still able to reach the destination and Y and Z both failed. Now we are going to try to figure out where the problem is. So we are going to group together the failed trace routes via the routers they termed at and paths through the are still reaching the destination whereas every path that went through Cox communication was terminating with it's last hop. We might want to jump to the conclusion with Cox not forwarding on traffic, trace work need working forward and reverse and we are only seeing the forward path even when we get responses so it's a little too early to conclude whether the problem is on the forward path 2D or back to [unclear] destination and further complicated issues the paths can be asymmetric so it's possible that the paths don't even go through Cox. In order to figure out what is going on we are so we know that the forward path from X to D is work [unclear] we are going to have X spoof probe claiming it's from Y and since that is working, it should reach the destination and then if the reverse path from D back to Y is working, then Y should receive D's response. So, in fact, we see that Y does receive D's response and we can conclude that that reverse [unclear] back to Y is working. At the same time we do the opposite, have Y spoofer probe claiming it it's X and the reverse path is working so if the forward path to Y to D is working then X should receive D's response and the probe fails again so city point, we can conclude that the problem is on the forward path and it's probably that Cox isn't forwarding traffic along to D. We do same with X and Z, the same thing, reverse path from D back to is working and reverse path is failing.

So give an overview of the system and a little bit more detail on the architecture and the first thing we need to do is defect prefixes that seem to have problems and we are going to do this by pinging prefixes that are previously been reachable to see if that has changed, ping every two minutes in aggregate from planet lab sites around the world and if one site has series of failed [unclear] we are going to report it to the system as a candidate for further analysis. Additionally we are going to monitor BGP tables from route fees and this is going to allows us AP to quote quote identify prefixes that are as potentially also experiencing reachability problems. Once we have identified the candidates that might be experiencing problems we are going to do toplogical analysis of what is going on, issue trace flouts all 35 planet lab sites around the world and we are going to keep probing every 15 minutes while the problem persists and analyse which of the trace routes [unclear] to ASes and this will let us keep from tying our reachability assessments to the availability of a particular site so we don't want the fact that we are monitoring one host that happens to go off line to let us conclude that the entire prefixes is unavailable so in addition to checking whether the address is available we can also check the prefix and AS and we make our final determinations on whether they are reached in AS, to map multiple interfaces on to routers so we can conclude which paths are going the same way.

Once we have done our distributed reachability analysis trying to classify the problem and we want to answer three questions that might help in diagnosis and repair:

First we are going to try to save which ISP contains the problem, try to answer which router is within that ISP are working and able to see paths and others not and which destinations are affected. Are the problems on the forward path or are they on the reverse path back to our sources. We are going to use 3 different components in our the current topology, historical topology and directional isolation.

Our goal is to do real-time automated classification and trying to find some common entity like router, AS, link that explains a substantial number of failed probes, we are not requiring that to ex player we could have some congestion losts or there could be multiple problems going on at the same time and we are not necessarily pinpointing exactly who is responsible for the failure, the problem could be on the link forward from there, it could be on the reverse path. I can now walk through how we do different types of classification using each component.

The first type of classification using the current topology, these are from and group together the failed and successful by the last AS and router they have. The particular example I am illustrating is a router problem. We have a prefix P and origin AS and further upstream there is another AS that includes a router R. All of the probes terminate with R as their last hop. But some other probes are reaching through and 28 percent problems looked like this. This is really something that shouldn't happen, it's showing inconsistency across that action. The second type of classification we do uses historical topology. So in order to do this we are going to issue daily probes from Planet Lab to all prefixes and gives us a baseline view what looked like before [unclear]. We can compare and see whether there is path changes and maybe predict where the paths should have gone had things been working so the example I am illustrating is next hop problem, again we have prefix with origin AS and somewhere upstream non-origin AS. Our historical working routes converged on the router R and then continued on to the destination and now all of our trace routes that previously went through R are terminating right before R. Without our historical information we want be able to associate together and say somehow R is responsible for both of them. They aren't going through any of the same routers and ending in the same AS so historical information is really helping us figure out what is going on here. 14 percent of our problems like this like and it seems something something shouldn't be happening, the routes not been withdrawn. Our third type of classification uses direction isolation so as I mentioned before trace routes are only returning routers along the forward path, I might want to assume last hop you see but in order to turn any further hops you need a working reverse path, it's hard to determine what that is the [unclear] could be asymmetric what we are going to do is isolate test them individually. Now ideally, we would have a had you been he will node in every prefix around the world and we would be able to do oneway probes from each other prefixes prefixes to Planet Lab and isolate back. Because we don't have that deployment yet we are going to use spoofing to you can spoof from a node S in order to check the forward path from S and spoof as S in order to check the reverse path to S. So in our deployment that we evaluated we used [unclear] to issue 6 of the 13 permitted spoofing and Planet Lab doesn't currently permit. An example is what we call multihome provider problem. We have a prefix P it's original [unclear] provider A and B, all of the probes that go to provider B fail and other probes are reaching through provider A and we are able to isolate the problem as being on the forward path. So 6 percent of our problems like like this, the main reason for multihome something to get some resilience against failure and here it seems the multihoming is actually responsible for the problem. To summarise architecture: There is 3 main [unclear] reachability analysis to assess how widespread the problems are and problem classification to try to give some idea of what is going on.

The key to the technique season synthesizing multiple information sources passive monitoring and [unclear] and reason and spoofing to help us troubleshoot what is going on.

I am going to now present one bit of evaluation on each of those 3 components, for target identification we are going to try answer how much of the in terms of reachability analysis what percentage the paths to the prefixes that we are monitoring are we assessing and for problem classification how much had you been he will can identify entity that seems to explain the failed paths and for further evaluation you can look at a paper we recently published.

So every two minutes Hubble is monitoring 89 percent of the Internet's address space and 92 percent of the AJSs and the remain is because we can't within those prefixes.

Now, beyond just monitoring most of the prefixes we would loose like to cover most of the paths so we know that Hubble is actually seating problems that sites where we [unclear] vantage points would experience, BGP routes from RIS so we are going to compare our trace routes to the BGP paths from 447 RIPE peers so that is made up example, we have a network originated by Intel and going to look at the BGP paths towards it, and BGP paths are generally thought to have [unclear] portion towards the tier ones and downhill towards the destination. All the ASes along the down, so that is the red ASes and the reason we are just looking at the downhill portion social security because Planet Lab's restricted size and lack of diversity limits our uphill, 90 percent of the failed terminated within two AS hops of the destination so hopefully we will still see most of the problems.

So in this case we have five ASes along the downhill portions of those BGP paths and we are going to look at our trace routes so in this case we have a Planet Lab node at, one the university of texts and one at myth, and we are going to look at the overlap, the intersection of the AS as they go through. Four out of the five are also so in this case we have 80 percent coverage for this particular prefix. This was just an example we went through all the prefixes that we monitored and actually looked at our coverage and overall we found for more than 60 percent of them were traversing all of the downhill ASes from the RIPE BGP feeds and for 90 percent of the prefixes were traversing more than half of them we are doing a good. As I mentioned with Hubble we are trying to do with real-time automated classification of the problems, to routers that seem to be causing the problems. We have nine classes that we currently use and I am not going to go through all of them here, you can see more details on the website or the paper. The particulars results are from the first week of February and we are able to automatically classify 82 percent of the problems as they occurred. So now we have evaluated some of Hubble's components some results. These results are from 3 weeks start not guilty mid-September of last year, and we consider problems where the prefix was reachable from all advantage at that stage points during the sturdy, became unreachable and then became reachable again before the end of the study. We saw 31,000 black holes during this period and this seems like massive violation of global reachability, we were amazed. This particular graph gives the duration the problems during that study so on the X axis it's the duration in hours and a log scale and on the Y axis cc D F to give example of one point on the graph the purple circle point says that 20 percent of the problems that we observed lasted for at least ten hours. So not only are there tons of problems but it just seemed like they were going on and on. 68 percent of them were cases of personal reachability when the but was unreachable from others and these seem like more of a problem we know there are valid working paths out there so we can then break up the graph and have a separate line for those that were completely unreachable and those were partially reachable so here the red line are prefixes that were completely unreachable, the yellow line remained partially reachable at all times and the don't last quite as long but it's a really similar distribution. The problem is it can't just be a hardware failure. It's not just you know a hacker out there cutting some fibre. There has to be some change, fail policy consideration change and some configuration or policy problem keeping it unreachable. The only way that a failure can result in partial reachability if there is a partition in the network and there is there is not in these cases because both vantage point that can reach the prefix and the one that can't are able to communicate with a central Hubble node so if nothing else there is a tunnel back through us.

I am going to give some other measurement results. We found most of the problems we observed can't be observed using just BGP updates. At any time during the problemate rest of the problems either occurred without BGP being involved or weren't visible from the BGP monitors that we had. Furthermore, you might think you can use multihoming to avoid these problems, it's not always working, we saw hundreds that had provider problems like that Cox USC example I gave reachable through one and not through another and all of these occurred on the forward path from the provider to the prefix. Furthermore we saw lots of inconsistent he identify AS that seemed to be responsible for the partial reachability that we are seeing, usually some paths through that worked and other didn't and western able to observe those different points just using our advantage at that stage points. Path changes tended to accompany failures, when we were able to find a route they are a seemed to explain the problem in three fourths of that case wasn't on our baseline working paths. So to summarise: Hubble is now a working realtime system that is monitoring most of the rest of the Internet. We observed tons of reachability problems and some of them lasting for days on end and able to combine our baseline host oracle Kay at that to do classification on most of these problems. In the future like to do further classification and analysis including looking across prefix and within a country within AS things like that. Currently we are only [unclear] prefix at a time. Expand the number and diversity of our vantage points and most importantly I would like to make this a useful tool: Really like Hubble to be something that can help operators. I would love feedback on what can be doing. Give access to trace routes, give reachability data, send notification when we notice problems and I would love any feedback on any other problems or causes that we should be looking for. We have this global measurement infrastructure now and like it to be useful to people. Email me or come up and talk to me, I will be here for the rest of the weeks. We would love it if you guys could help us out, if we get some validation or explanation of what is going on in particular instance toss help us refine our techniques [unclear] really like to add trace route servers into the system and [unclear] people could help us host Hubble nodes. We have a website that gives real-time updates although about an hour ago at the start of this session I started getting emails from the system telling me I was having problems and one of my friends in Seattle drove over to campus in his pyjamas and is hopefully trying to get it up, I am not sure if it's working at the moment. It updates about every 15 minutes and gives data on the number of problems that we saw, the maps like the one that I had in my fist slide, you can get information on each of the prefixes, look at the trace routes and there is a way to query for the status of particular addresses. Thank you very much. And I would be happy to take questions.

(Applause)

CHAIR: Questions anybody. Thank you again.

Vince, are you here? Update on LISP.

VINCE FULLER: Good evening, I work for Cisco, I am actually here speaking on behalf of and the others who are the LISP crew, unfortunately I am much less entertaining and an mated so you are going to have to suffer a little bit.

I realise this presentation is probably signature between you and the bar I am going to try and make this really fast. First of all before I start, can I have a quick show of hands of who has heard about LISP, who has seen one of these presentations before, who has some idea what have I am talking about? OK. That is actually pretty good I can go really quickly through the introduction. Agenda, what is LISP, you know what problem are we trying to solve, this reference here is actually to a presentation I gave at the programme last year describes what I feel the problem is what the scaling, why is locater what is locater ID accept railings, why we think it's a path forward to solving some of the scaler issues. A little bit about how LISP works and then some updates on how the deployability and how it's going, how the implementation is going now and the testing. I am also going to be soliciting new data sites to help us work on this stuff. We particularly need new sites in Europe, one of the ones we thought we were going to use fell through, if you are interested contact me, I will talk about the email address to contact shortly.

Anyway, what is LISP, for those who didn't raise their hands and are not reading their email right now, it's basically a specific instance of a general locater ID separation, it's called locater ID separate, hence, not to be confused with the LISP programming language that was a hot thing about 20 years ago. Most of you are probably too young to even remember what that is, that is good thing. I was there. But some of the design constraints that we impose upon ourselves, it's going to be a network based solution, probably a big surprise from a network solution company like Cisco. One of the particular constraints that I think is important is that we want to avoid making any changes to deployed hosts because as [unclear] Lee once said, deployability wins, everything else is secondary and if you have to go and change all the hosts on the Internet your solution probably isn't going to fly very well. That is one of the reasons why it's taken so long for something like IPv6 to deployment you have to change everything.

We are avoiding making addressing changes to the end sites, again to the end hosts again. We want top minimise the number of config changes overall to all parts of the system. Again it has to be deployable and one of the key design goals was that it be addressed agnostic, in other words it can work under both IPv4, IPv6 and some of the transition mechanisms can work in a mixed environment. The biggest take away here we are trying to minimise the number of things you have to touch, primarily the thing that has to be modified is the edge device that talks to the customer, the so-called customer premise router, that hopefully you will be able to upgrade simply through a software load rather than having to change out the hardware or make any physical changes to it.

Who here has seen this graph before? Another show of hands. Oh wow, that is actually really small. As they say in English, [unclear] they say the same, something similar similar in German, a picture is worth a thousand words. This is the graph that motivated work in this space, it's a plot of the size of the global routing system going back to the late '80s, all the way through the present day. This is actually a graph that Geoff Houston generates on his site along with tons of other really useful information, I will give Geoff of a plug, if you are interested in any of these scaling things and how the Internet routing system is working or not, it's actually a great place to go, you can look at all sorts of different statistics. There is a few different phases on this graph, the original kind of exponential looking curve, the deployment of CIDR which signed of flattened the curve out, the boom of the late 90s, a flat spot where the big bust in the high tech bubble occurred and another kind of troubling looking curve towards the right-hand side of the graph that is getting even steeper as we go forward. That is you know, if you look at what, semiconductor trends, in particular memory speeds look like, this is might be something of concern because the constraining factor on BGP and routing convergence is not so much table size as it is how fast you can update the table and while memory size is CPU speeds are getting faster very quickly, according to so-called More's law, memory speed is not and that could be an issue in the future again that other reference talks all about that problem, I am not going to get into that now.

So, what is this thing ID locater separation or split that people talk about? Well today, you have one numbering space for the Internet, and that is IP addresses. There are some reasons why that is problematic in particular, you know, for the addressing and the routing to scale well, you really need those things to be assigned top logically, in other words provider assigned, but provider assigned in addition to have having some negative package as a term also has some issues with address portability, if a customer moves from one provider to another, a number event or carry explicit routes for that space when they move. Homesite has be explicitly carried everywhere. Traffic engineering, tends to are done with more specifics et�cetera. Well, the idea behind locater ID separation you try to get the best of both worlds, provider independent and toplogical or provider assignment by basically using two numbering spaces. For the hosts, things you wanton configure once and never have to touch again, you use a separate numbering space called EIDs. For the network topology which you need to be dynamic, the addressing to change as the topology changes, you use locators and what LISP is and other locating solutions require is some mapping from one to the other. And that is what we will talk about next.

So what do you get with a location ID separation solution? You get lower [unclear] for sites and providers because you get hopefully improved multihoming, some traffic engineering, new features, and kind of the key motivator which was reducing the size and not just the size but also the dynamics of the global routing system because, again, because you are using locators for the actual traffic forwarding you can assign them topologically, you can aggregate them topologically, you don't have to to carry all these exceptions everywhere. For the end site well maybe you get an easier transition to IPv6 this presentation is actually a plug for a much longer than I am going to do so if you have any interest in this, please show up, I will go over all these things in a lot more detail on Friday so some of the things will make more sense there. There are some transition mechanisms possibly easier to get to IPv6 and the key one of course is because you are using EIDs for the site numbering you don't have to renumber if you move your site or multihome your site.

Parts of LISP two new network, ingress tunnel router it is the device that finds the E ID to locater mapping, host generates a packing, EIDs on it, the ITR takes that packet before it leaves the site and finds the appropriate locater to slap on and the packet it off through the routing system. There is also of a corresponding ETR, the egress tunnel router, the thing that gets the packet at the far site, you know figures out where it's going within the site, strips off this extra header with the locators on it and forwards it off to the EID of the host that is the destination of the traffic. It's the thing that owns the EID to locater mapping. You can kind of think of the ownership as being analogous to a DNS server owning the map from a name to an address.

Packet forwarding and LISP looks roughly like this: On the left you see a source, the right is is a destination. The little red numbers are the locators that are assigned at the provider edge to each site, the green or I guess they are green, they are supposed to be blue, are the actual IDs, the numbers that are assigned to the host within each site.

DNS entry returns ID, again the IDs are the things that are assigned to hosts so what is visible in the DNS, what is visible to the host level are IDs. Source wants ton sent packet, it basically takes the DNS result,, the destination where it's trying to get it, slaps on its source which is an ID, slaps on the destination, sends it off to its exit point. The source, ITR has a mapping, I will explain thousand got that mapping in a later slide, that says for this block of EIDs, these are the locators that you can use to reach anything within that EID block. It's got some priorities, weights, other sort of engineering details that you can find in a more detailed LISP presentation that I will talk about later.

It takes this you know, at that [unclear] takes picks one of the locators based on policy that it has, reencapsulates the packet putting the locater source and destination locators on the outer header and encapsulating the original host source packet as the inter data of that IP, new IP encapsulate packet, sends it off into the network and it goes, you know, since it's going from 11.0.0 .1 to 12.0.0.2 it's going to go to the provider that connects the 11.00 address, going to be provider that has the 12 prefix, off to the ETR, again we can see both the outer header, the locators, the inter header, the [unclear], the delivers it to the host so farce the host is concerned, you know, it has a source and destination address, send it, received it, it doesn't know anything about this locater mapping that happened behind the scenes.

So what happens if the ITR doesn't have a mapping, you know it gets this packet from a host that just hasn't sourced EID and destination EID. Well the ITR needs to go and contact the ETR to have it report back the locators that it has so it can use those in the reencapslation. The ETR returns what is called a LISP map reply that has that information in it. Great. How do the ETR and the ITR find each other. Well, that is where you know, one of the aspect of LISP called LISP ALT comes into play. LISP ALT if you have been following any of the RR G discussion, a lot of talk about push versus pull, how you distribute mapping information, LISP is sort of a hybrid push plus pull system where basically ALT is is an overlay network built out of Tums, the spec talks about GRE but other technologies equally applicable and BGP run on this alternate topology is not carrying the Internet routing information just carrying the aggregated prefix blocks that basically create an overlay routing path from ITRs to ETRs for the purposes of finding each other. It doesn't actually contain the mappings themselves because you want them to be a little bit more dynamic than that it does tell you whereas ETR is for that prefix so the ETR can be contacted and can respond.

There are two ways that ALT forwarding can work: In the sort of the normal case, you actually, when ITR receives destination that it doesn't know about and the creates a map request sends it ton the and discards the packet or holds it while it's waiting for a response. There is also there is bass way you can instead of creating a new map request you can actually take that original packet, encapsulate it in a request and use it as a data triggered request, forward the real data across so it can be delivered with no latency. This is actually an area of some controversy, some people love it because it reduces the latency of the system. And others hate it there are going to be performance problems with this overlay topology, performance constraints, it's an area of ongoing experimentation whether we want to support this mode or not. We haven't really decided yet.

This is kind of all ALT works in a couple of animated slides. We have a bunch of ALT routers, they are not necessarily routers at all, they be Linux PC, some sort of PC that is part of this virtual overlay network, basically a bunch of tunnels, that is the purple lines and a bunch of BGP connections between them. In the ALT BGP system the ETRs, shown here on the right-hand side of the picture, advertise a prefix that they own, for which they own the locater ID mapping. That can be aggregated as shown here on the upper right-hand ALT router into a less specific prefix and then propagated to the rest of the ALT system. By doing this you can reduce the A information that is carried, because the ALT overlay network doesn't have to be high performance, it doesn't have to give you the best path, it just has to give you a path from ITR to ETR because it's not really used for actual data forwarding. Once the EID the locator mapping has been installed on the ITR the real data actually flows across the native topology and is not constrained by performance limits of the ALT topology.

So we have an example here, we have a host that wants to send from a source EID in the 2400024 block to a destination in the 24111 block, it doesn't know thousand get to 240 /1 so it forwards send a map request across its ALT connection to the I am good. I only have about five slides work it forwards a data request or a map request to into the ALT topology over its tunnel. That is forwarded along using regular BGP rules on this alternate overlay network off to the appropriate ETR. The ETR receives it, with the locator headers here. It turns around and sends a reply back, saying, you know with the mapping for 240 /1 /1 /0, mapping 2 it's 1.1 .1.1 locator. But now the ITR has a mapping so it can forward the regular data packet using again the LISP encapsulation outside header has the locators, inside header has the original IDs, the host addresses and it goes across the native topology, not across the ALT topology, to the destination, everything is great.

I am going to go over this very, very briefly. This is something that really needs a lot more explanation in that I will talk about on Friday, but for interworking between LISP sites and non, we actually have two mechanisms that we have proposed, this is all documented in Internet draft. Essentially you can come up with a proxy that does the LISP mapping on behalf of a non-LISP site, a provider might want to deploy one of these proxy PTRs within its network so they can talk to LISP speaking customer or you can deploy on the CPE side of the LISP site you can deploy a device that acts not only as ETR but also does NAT for the address that is are non-routable EIDs when talking to parts of the Internet that don't understand LISP. I am not going to say any more about that, I will cover that on Friday. Skip over these.

This is probably the most interesting part of the presentation if you have already seen LISP before. We actually have an implementation on the NXOS platform, it's the software operating system that runs on the NX 7,000 SISCO switch and runs on Linux PC that we have, it's looks exactly like those rackmount PCs you saw in the Zattoo presentation yesterday, it is the same hardware. Again, it's based on Linux and it runs the NXOS on top of that, it's only software switching just a PC flat form. Supports IPv4 and IPv6 and also the networking mechanisms. That is all updated since the last time we talked about LISP at a RIPE meeting because things have come along quite a bit. All this is more solid and more defined than it was six months to a year ago.

There is some work on a prototype under IOS. I have no idea if or when that will ship as product. There are people working on it, hopefully it will get more official. There is also open LISP implementation, some guys at UCL in Belgium documented from this draft here. We would really like to see more implementations, LISP is not a Cisco thing, it's doesn't have any IPR on it, it's explicitly intended to be used by anyone and everyone that wants to play in this game.

This is actually just a slide that shows our test topology. I won't go into details. But basically it's separated into several regions, there is Asia region, European region and several sub regions east and west of the US the goal here is so we can test basically the latency of using the LISP and ALT system on the longest path that we can find, worldwide and also to give us somewhat realistic scenario for aggregating the ALT information on a regional and continental basis. If you are interested in playing with this, as I said earlier, we are looking for more beta sites particularly in this region, what we are looking for is is a site that can dedicate hopefully a person a week worth of time, we will supply the hardware and software and all the coordination and support, but we just need someone with some time who has some familiarity with configuring SISCO box. Contact us. This hasn't seen a lot of activity but it's basically for generic discussion of anyone interested in LISP. Contact list for people that want to be part of the beta programme. That is LISP interworking mechanisms and multicontact, it's a Dino project so of course it's going to multicast.

And that is it. If there are any questions, now is is a good time to take them. Did I do OK on time. I sprinted. Questions, comments. Anyone want to jump up on play

AUDIENCE: Are we talking about IPv4 and IPv6 or IPv4 how about the IPv4.

VINCE FULLER: We actually can do all of those things and the spec is explicitly enabled to do so a that and so is implementation

AUDIENCE: v6 network?

VINCE FULLER: It will. It's supposed to, I don't know if the current prototype implementation, it hasn't been test today do that. The code is there but all of the stuff is in different stages of testing so if there are people interested in testing that stuff, please send us a note.

AUDIENCE: Feature request to make it v6 capable.

VINCE FULLER: I didn't catch that

AUDIENCE: As a future request make it v6 capable as soon as possible.

VINCE FULLER: No it's code today do that. It just hasn't been tested.

AUDIENCE: I have a comment and as you mentioned, the deployability is a [unclear] for this and that is actually where this community might come to your help because we have had lots of discussion in the IRTF around this proposal and other with certain aspects of this are deployable and in particular the proxy tunnel router node which is basically required for the, you know, new and old Internet to talk to each other, would that be possible, and there has been a lengthy discussion on whether that is actually deployable in terms of because you have to have an extra box and you can't limit who you serve with that box and basically, a request for the room to take a look at and your presentation on Friday and try to provide feedback on whether that is actually something that could realistically be deployed or not, or what conditions

VINCE FULLER: Let me make two comments: First of all we two different incremental deployability mechanisms because we are not sure if PTR were scaled you had a you had an I think we would rather not do the Nat thing

SPEAKER: It depends where you wanton put the pain in the control points. The advantage of the Nat solution to some extent it's well understood by people who are doing Nat today. It also is incrementally deployable on a per site basis. You don't need the cooperation of anyone above you. The PTR solution as we envision it, at one point we thought PTRs would be deployed at interconnect points and anyone would be able to use them. We don't see that as a viable model. We thought about that a lot. We sought PTR being deployed bay provider on behalf of its non-LISP speaking customers, so it would not be available for anyone to use, only available to that provider's customers.

AUDIENCE: Yes that is getting too much of the details. What about the rest of the Internet it, doesn't sit behind a provider like that. Can I still connect? If I am in that part of the Internet to I have to go to the Nat thing?

VINCE FULLER: These are open questions we hope to get some idea about as part of our testing.

AUDIENCE: My point it's not just about technical stuff but really what can actually be deployed by real world providers.

VINCE FULLER: I understand. And we are trying to provide as much flexibility as possible and trying to get real empirical data by testing this stuff without what will work and what won't.

RANDY BUSH: It's safe to say LISP rules because nobody else is actually playing. I have to say

VINCE FULLER: I didn't like this slide because I was never a big fan.

RANDY BUSH: Dean know and the rest of the LISP gang stepped up where everybody else is talking. I have issues, questions, et�cetera, et�cetera but I have to say you guys are actually doing something instead of talking.

VINCE FULLER: And to give Randy a little plug and credit he is actually our test site in Japan and helping out with some of the stuff too.

RANDY BUSH: I am doing it as a sceptic. I ran Windows NT for six months so I knew what was wrong with it, I am not that sceptical about this but it's�

VINCE FULLER: It's a hard problem.

RANDY BUSH: These are the only people actually doing something instead of talking, take a look at it. You will learn something

SPEAKER: Thanks. I didn't pay him for this, by the way.

RANDY BUSH: But Marco, the stuff for v6 is there if we ever get out of silly meetings like this we are about about ready to test. V6 and v4 togethers.

(Applause)

CHAIR: Tomorrow we have the IPv4 versus IPv6 hour. What that means at 10 o'clock tomorrow the v4 network connectivity will be turned off. If you have serious work to do, like debugging your routers, then you have there will be IPv4 available in the terminal room and IPv4 available near the registration desk, the exit points there. So this is just a warning, 10 o'clock it will go off, if you are doing serious business make sure you are at one of those locations. The IPv6 stuff you can test today, just turn on SSID which ends with v6. You follow the instructions on the little sheets that were on your chair or published on ROSIE and you see if you can work on IPv6. There is a Net PT box which happens to work since this morning thanks to debugging by Philip Smith, I think, and other people, so actually, I have been working on IPv6 only the whole day and it works like a charm. That said, and with a warning, for tomorrow, not for this presentation, here is [unclear].

LUTZ DONNERHACKE: I try to come to an end because I have to go out for the peering. OK. We face a problem that was named numerous times here, it's the problem that BGP routes can be wrong. In most cases, they can be they can be broken by mistake or they can be broken by purpose. The most common for broken BGP paths is purpose, sending out spam from allocated or unallocated prefixes. If you want to send out spam, I recommend to use 16 /8 because it's allocated and unused.

So, there are a lot of proposals how to solve such a problem, how to determine if a BGP path is correct, if announced prefix is correct or not. Most of them run into classical technical problems, the problem to be too specific. If you are looking under existing proposals, you will see there is an infrastructure to certify each router on the net. To go to the very deep details is router A allowed to peer with router B? That can be very, very large and very, very uncomfortable to debug. There is another proposal: Mapping the whole information into DNS, using DNS Sec because DNSSEC is new, the proposal is about seven or eight years old, so DNSSEC was new. But it was not tried to do, only a radical proposal.

What we do now is to go as far as possible to the simple basis, try to catch config arrows after they appear. It's possible that a system does not have a valid peering policy or does not set up, but we want to try to catch them after their incident. We try to filter them out later, on transit.

In order to get deployment, we do not try to modify existing software and we do not try to modify existing protocols. We do try to reuse as much as possible. What we have to verify, what we have to prove, I take here an existing example, an example which caused me headaches on Sunday. It's a prefix and the prefix is coming about through paths. First question is is this does this prefix allow to be announced from this autonomous system? Not the question is not does the autonomous system allow to use this prefix. No, we have to come from the prefix and verify if this prefix allow to be announced by this autonomous system. Then, we have to check the peering or the upstream or the downstream paths so we have to check if they are originating in the normal system does itself allow to announce it all routes to another autonomous system and then the next question, is does this receiving autonomous system will accept this, is this the policy to accept this. It might be narrow. And then we go step to step further. It's a lot of checks. In order to prevent an unworking specification, a test is set up. Currently we simulate RIPE database. We are running about 270 servers and running about one gigabyte of DNS compresses in wire format. It's all running on a single machine, 500MB RAM.

You are encouraged to try it out, try it now. It's the starting point. Write down the starting point for the BGP, we put all the root zone and then start digging and then verifying, you can check your own information, your own peering information, use your own datas, your own prefixes, try it out. Which kind of mappings do we use? What are the questions you can send to the test bed. First we have to map autonomous system. It's very straightforward. We use AS.plus format. And make, like up for INADDR. Next prefix mapping we can get information if the origin is correct. So we need a different name space and we need a different machine. Nothing to say about this it's very straightforward. We use different name spaces and not the known name space using look ups because we do keep as closely as possible on the assignments and allocations. If we would use the current rust look ups, every customer who has its own look up zone would be aloud to become multihomed. I think most of the people here does not claim this very good idea so we have to switch to different name space and the other point is we have to extend the current name space for real prefix look ups, we do not get to the very end, we can stop in the middle because the prefix is not longer. Straightforward mapping. For each prefix we can look up the autonomous system numbers, originate them and in the second example for v6 you can see this autonomous system announces two parts of the routes, one assigned, one allocated and one assigned route. It's one of the examples that is missing from the slides. The other interesting point is how to model the peering policies, to check the path. It's the same format as ASPL using in the routing databases right now. It's only a little bit extended to get the correct information from the correct autonomous system. We had unfortunately, to introduce a new record type because in first step we tried to expand the autonomous system using text record and yes. AS set expands to more than 100 kilobytes of data. It's not possible to put it in DNS record or multiple ones. Furthermore, if we have references as with this RD6 point we can keep the data very accurate without regenerating them. It's the same path you have to do with generating filters use the IRR tool kit, you have to do it regularly to get the correct information for your router configurations, so this will be auto generated. Furthermore, the aggregated autonomous system still very large, so in order to transport the DNS protocol we use special records and we allow code them as text, use the normal representation, as simple as here, exchange [unclear] by and you are done. The fall back is triggered by DNS Sec. If it says no, I am pretty sure there is no record use the fall back to TXT, we will put it out in a few years. Furthermore we have a transition mode, you can announce that you are not willing to enter the data, claim transition, you can do it on IANA site or; LIR site. Currently transition means always allowed. It will be changed to a warning, and then it will reject. We hope that in this way, we get the critical mass deployment. Assume about 10 percent of larger ISPs using this system and about seven or eight years go to one state or reject state, then they will not drop their deployment, and if you are going to keep reachable you have to insert the correct data into DNS. You can do it right now, you can drop me an email, I will replace the outer generated data and test by your correct name service.

So I do not talk about certificates. Certificates was very important discussion point today, the last RIPE meeting and will be interesting and very important point on the other meetings. We remove the v. 509 remove records and replace them by DNS Sec simply because DNS Sec is distributed and allows local changes. So you can have different view to the database by simply applying local zones to your local . You can't do this with a large Mondaylytic database. The process here does not need any special software. Can use the currently existing software for signing, look up validating. We are into a problem from test bed. Main problem is we have about 150,000 autonomous system running out there, separate routing separate routing points. All capable to if you are inserting a route into the DNS into the BGP, BGP will be about five to ten minutes. In this time, all those routing points will get will make DNS queries a lot of queries, to get the information if you are allowed to do this. So if you are not on a very high bandwidth, your peering session will go down, right after setting up because it's overloaded, for starter.

The idea is to use the cache, if you are receiving a route from a peering, you can ask your peer and you can ask your peer's cash because it has to be validated, only a peer, so that if the origin data comes from a point it's like a shell, validating data can be got from the inner shell and put to the outer shell so the lot of requests to the inner point and rejection point will be avoided.

Further problem is to get up a new routing point, a new autonomous system up and running because they do not have any information. If they come up they can't do any DNS because they have no routes on their tables and the routes on the tables will not be injected because the routes can't be validated. So, there are two proposals, very simple one is to wait. Simply, allow the router to temporarily learn the routes but do not redistribute them. Then do the DNS validation, verification steps and then you are done. The other idea is to go to peers down in use a pea like query if you are looking for data from two steps away you ask the router to ask the router to ask router to ask solver to get the data. Both ways are possible. So I hope I was in time.

Try it out.

(Applause)

CHAIR: Are there any questions at this point?

Then there is nothing between us and beer, except for the newcomers.

Thank you all, tomorrow at 9 o'clock, I think we reconvene. See you tomorrow.