These are unedited transcripts and may contain errors.

---

The Plenary Session resumed on the 6th October 2009 at 2 p.m.:


CHAIR: I hope you have all enjoyed the lunch break. Welcome back to this Plenary Session for the RIPE meeting in Lisbon. This session has got a very heavy emphasis on DNS issues because, as I am sure most of the people in the room realise, we are living in interesting times as far as changes to the domain name system are concerned, specifically at the root zone, so we have three presentations on that followed by updates on the IPv6 studies that Maarten Botterman has been working on over the last few months. The presenters who are discussing the DNSSEC things will also be discussing things in the DNS Working Group sessions on Thursday. So, I'd appreciate it if you would try to contain any comments until the working group session later on in the week. If any questions come up at the microphones could they please try to be on issues of clarification rather than Niitti grit re technical detail. Which could be dealt with in the working group. Having said that, if you want to discuss it here and now, by all means do.

Before we get started, could I ask everyone please to switch your cell phone and pagers to silent /?RS, or set them to stun. If you do have comments to make, please identify yourselves and speak clearly into the microphones so that the people out there in we object land can figure out who is saying what and also for the benefit of the stenographers who are doing a fine job of transcribing proceedings.

So without any further comments from myself, I'd like to introduce the first speaker for the afternoon session, that's Sara Monteiro.

SARA MONTEIRO: Good afternoon everyone. As Jim said, I am Sara Monteiro. I am from the FCCN and as my colleague, Carlos, yesterday afternoon said, FCCN is involved in many projects but as the registry of .pt, we have the DNSSEC.pt project and I am here to speak about it.

This is the main topics that I am going to speak on. As the .pt, I think for any registry that wants to implement DNSSEC, the main mission is to prepare the Internet community for DNSSEC users, and I think in our case, we want to prepare the Portuguese Internet community to be aware and to use the DNSSEC.

As our national strategy, we are promoting the implementation. We are trying to facilitate the DNSSEC usage with providing the documentation in the national language, in Portuguese, as also in English, and we are sharing our knowledge and experience with other registries, and we are learning from the other registries and TLDs experience and we hope we are doing the best practice with regard to the security and data protection that we hope that everyone has this kind of concern.

As our action plan, we have created DNS policy and procedures declaration; that is also available in English on DNS.pt. And the declaration, the main objective to give some information what we intend to do to have the .pt signed.

We are acquiring a high?secure infrastructure. We hope that we'll achieve level 4 of physical security. RIPE are right now testing test bed under DNSSEC.pt. We already have some registrars and users to start testing it. We are promoting initiatives and the main focus for our initiatives is the .pt registrars, because they have almost 40 percent of our domains. We are publishing news about DNSSEC on our country and in other countries, and we want to sign .pt in the beginning of the next year.

About the policy and the procedures declaration, as I said, the proposal of this document is to serve as reference to the end user and registrars and giving them some kind of confidence to bring entities on how the process will be described, and we also want to clarify which kind of participants and which kind of areas of responsibility they had.

We want to explain the procedures and operational schemes on our implementation on .pt, how we were going to manage and store the keys, and the main purpose of this document was to give some kind of trust and integrity to all the process that is the signing of .pt.

As the new infrastructure model, as I said, we will try to achieve level 4 of physical security, so this these machines will be inside the technical room with cameras and with security. Beside that we will want to acquire an IT security safe that will have our primary server .pt hidden, and the HSM that will generate and sign the .pt. And then the other machines, the public primary and the secondaries, our database. And then there is the backup key we want to ensure that if something happens to our infrastructure, that we'll have the key stored in a very good place, very far away, and with all the security that the actual key has. So, we'll have external entity with security certificate that can store our key and put it safe away. But we will choose the best entity that will provide this kind of service.

As the DNSSEC.pt test bed, we have the DNSSEC.pt, that is assigned, and the DNSSEC is also configured on and is free, and under this menu you can ask it for free for testing purposes at the mailing list at DNSSEC.pt. We already have some registrars and end users that have already tested and we have their domains actively running and signed. So that's good. And from our information, you can search on our website that it has an English and Portuguese version.

As the initiatives system, the registrars and the end users don't know very well what DNSSEC.pt is, and they are not ?? they are starting to learn it and starting to sign their own domains. We have our own clients and we already signed some domains that we have, like FCCN.pt, etc., and the ones here, so we are signing these domains to show them to give the example to them that this is useful and they should do the same.

We also made a survey, the first was directed to registrars to see what we should do to persuade them to adopt DNSSEC. We promoted some workshops, two years ago was our first, and it was not very famous because we invited some registrars and just a few appeared, but we are hoping the next one will be a bit more with more registrars. We have sessions about DNSSEC. We have also the participation of these that help us how to inform the registrars and to tell them that it is useful and it works and they should adopt it. And also jaw dam as as a senior programme manager at ISC. Now we are trying to enforce, to persuade the bank and judicial and Government entities to do it, because it's important for them, as the ?? as they have this kind of critical service and they should adopt it this way. It's one less worry they should have.

At DNSSEC.pt survey, we have a few questions. We'll speak about the main ones. And 25% of the registrars replied to it. So it's not a major percentage but at least we can understand what they know about it.

So, as the benefits of the service as DNSSEC: 36% said yes because 60% don't know yet what is DNSSEC. But they are open to it, so that's good, they will, as soon as they know what DNSSEC is, they will adopt it.

About the question if they were interested to adopt it? 20% said yes, and 80%, as in the other question, they said they would wait for new developments and more information.

At the question about what were the essential ?? what they would consider essential for them to adopt this service, the main answer was that they need Portuguese documentation, so we are working on it. We are viewing the documentation and it was useful to them, and they'd like to have more workshops about it, and a good team with technical knowledge.

About the main question, if .PT develop DNSSEC? We have a about 70% of yes and the ones that really didn't answer, they really don't know what DNSSEC means. So we hope they will change their minds.

As the next steps, we want to ?? we want to give the infrastructure as high security and establish as possible and put it together and running. We want to sign .PT, provide a web interface. This way end users will have a more friendly interface and a more easy way to submit their keys and their DS records. We would like to put together the signing of .PT and also the dynamic updates, and we would like to integrate it with EPP. That was launched in .PT last week. So it's also new for the registrars but we are hoping that you will embrace it, the EPP and DNSSEC.

So thank you for your attention. If you have any questions...

CHAIR: Are there any questions for Sara?

JOHN SCHNIZLEIN: John Schnizlein. You mentioned using the DLV to publish the public keys for .PT. What about the ITAR? Will it be there also?

SARA MONTEIRO: I mentioned the DLV at the DNSSEC.pt, our test bed because ??

JOHN SCHNIZLEIN: It's already in there for the test bed?

SARA MONTEIRO: It's already in there and running and we have a whole chain of domains.

JOHN SCHNIZLEIN: So, it goes without saying that when you actually sign .PT ?? and I notice you didn't give us a date ?? that that would be then, it would have, its trust anchors in the ITAR and if it comes after the root signed, in the root?

SARA MONTEIRO: Yeah, yeah.

CHAIR: Any other questions? NO. Okay, one question I think I would like to ask myself then, since I have got the chance, is to pick up on John's comment about timings. I think it's a little bit unfair, Sara, but I'll ask anyway.

Do you have any feel of a timescale yet or when you anticipate you might actually have a signed .PT zone in production use? When do you think you'll have the zone, the TLD signed?

SARA MONTEIRO: As I said, we are waiting that. We have all the new infrastructure model complete and with all the security that we want and and working with tests and after that, because we already start the process of perch, but we don't have the machinery yet, so, after that, and all the tests that we will make with ESC helping us, we will launch as soon as possible. I don't know precisely, but I think we are talking months here. So not so ??

CHAIR: Thank you. Another question.

AUDIENCE SPEAKER: Lars Lyman. Are you going to have some differentiated charging for subdomains that are signed and subdomains that are not signed?

SARA MONTEIRO: It's a free service. We just want that everyone will adopt it. We offer the service to them because we will think this is the best way to go.

AUDIENCE SPEAKER: Excellent.

CHAIR: Thank you very much. Another question?

SHANE KERR: This is Shane Kerr from ISC. I was wondering, you had a note there about a web interface and about using maybe DNS updates to change, I guess DS records, is that the idea?

SARA MONTEIRO: Yes.

SHANE KERR: Do you already have a relationship with the registrants or do they all go through registrars today?

SARA MONTEIRO: We have direct relationship with the registrants.

SHANE KERR: In all cases?

SARA MONTEIRO: No. Some cases it's the registrar. Other cases it's ?? because we are a registry and also a registrar. We don't like it, but we are.

SHANE KERR: Okay. So would you also provide some sort of way for someone who is going through a registry to update in these ways or would they have to go to their registrar then use EPP or whatever?

SARA MONTEIRO: If you are a registrar, you can be using EPP and also the web interface, but for now it will be the web interface will be the same for a registrant or a registrar, but just registers can use EPP. So this is the main difference between them.

CHAIR: Any more questions? Thank you very much Sara.

(Applause)

CHAIR: Next up we have Lyman Chapin. Lyman has been involved in various initiatives with ICANN. One of the pieces about the ICANN's asked to do was some of the issues arrange scaling the root zone to deal with things as TLDs and other concerns such as what's going to happen when the root zone gets signed. And the introduction of internationalised domain names and the need for IPv6. And we are quite fortunate most of the members of the scaling team are here and will also be at the working group on Thursday, where we go into a more substantive discussion about the technical aspects. But I'll leave the floor to Lyman now.

LYMAN CHAPIN: Thank you. I'll describe the findings of study that we conducted, the six of us that are shown on this slide conducted a study of the effects on the root of adding new TLDs and a number of other factors. I want to point out that all six of us are here at the RIPE meeting this week. So you should feel free to, you know, call, not just me, but any of the people that you see listed here for further explanation of anything that I might say here.

As Jim pointed out, we will be having another session on the same topic in the afternoon slot of the DNS Working Group on Thursday.

A little background:

The idea of doing a formal study of what happens to the root when you change things, when you add things and make other changes to the root, first started to be tossed around in 2005. So it's been quite a while that people have been concerned about this. The request from the ICANN board that led to the current study was actually formulated as part of a resolution in February of this year, and a steering group was formed shortly thereafter consisting of members from the security and stability advisory committee, the root server system advisory committee and ICANN staff, and that steering group, in May of this year, asked me to put together a team of experts to conduct a study. We had about three months to conduct the study, the announcement was made at the end of mid?May. I was able to, at the last ?? for those of you who were at the RIPE 58 in Amsterdam in May, I gave a brief introduction then of what the study was going to be about. We completed it over the summer and the report of the study team was delivered to the steering group on the 7th September, and the URL up there is the text of the study.

To give you a sense of what we were looking at, we were looking at scaling the root as an issue not just of making the root larger, but also of changing the dynamics of the way in which the root changes over time. So, we are looking at the effects of, the combined effects of signing the root, of adding the DNSSEC, signing the zones in the root, adding internationalised top level domains for CCTLDs. Adding support for v6, both quad a records and glue and then, of course, adding new GTLDs. This is overlapping time frames of one sort or another. But they have the effect of increasing not just the size of the zone, obviously the root zone becomes larger when you add these new records and larger records to it, but also the volatility of the zone, the rate at which things change and the way in which things change. So the study was intended to look at the effect of doing all of these things in combination.

The model that we developed. We actually developed both a qualitative model, which is diagrammed in this slide, and a ?? the beginnings of a quantitative model in conjunction with a research organisation in Netherlands call TNO. The qualitative model occupies most of the current study report. The quantitative model has recently, the description of it has recently been posted and the expectation is that the utility of that model will become apparent over time in the form in which it's currently available, it's very clearly a first step.

The root system model that that we developed consists of four domains of activity and six actors, six players, if you will, in the process of maintaining the root zone. The four domains are, first of all, the TLD registries, which are the source of both new information, new entries in the root, and the source of all change requests to change our update information in the root. And to the extent that those registries have internal operations that are not particularly of concern to us from the standpoint of their impact on the root itself, we didn't try to model the way in which TLD registries, for instance, make decisions about how frequently they are going to update their main servers, or in a DNSSEC world, how frequently they are going to roll over their zone keys.

They exist in the model only to the extent that they generate requests. So there is a request load that shows up at IANA. And that's the point at which the model starts to consider them as a variable.

The provisioning system is the system that starts with change requests arriving at IANA and ends with the insertion of new or revised information into the authoritative root zone database that's maintained by Verisign. And it's provisioning in the sense that it provides the information that then gets distributed in the publication process to the root server and root server instances around the world that actually respond to queries. So the provisioning and publication sides of the root zone managing system are the separate parts of the model. There is, of course, the fourth domain, which is the domain of the DNS resolvers that exist throughout the Internet, that are the source and sync of queries and responses respectively, and again, we model them not from the standpoint of any internal operation of either a particular resolve or resolvers in general; nor do we try to model the Internet fabric that intervenes between any given resolver and any given instance of a root server, but simply reflect their participation in the model in terms of the query load that they represent for the root server operators and the way in which they formulate those queries and either respond to or don't respond, to or the reaction from them.

The six actors, obviously the TLD operators are one, IANA and TIA and Verisign all play roles in the provisioning side of the root system model. The root server operators, the twelve organisations that operate the 13 letter?designated root servers are clearly the actors in the publication process, and then the DNS resolvers are the sixth. So again we are mostly concerned with the four actors in the central part of this model, IANA and TIA and Verisign on the provisioning side and the root server operators on the publication side.

The most interesting aspect of the characterisation that we developed in each of these actors is the difference between the actors on the provisioning side, which, for a variety of reasons, have to include in their processes, a step that involves human inspection or human intervention in the process. True both before and after the advent of the new root zone work flow management system that is going to automate most but not all of the processes that exist on the provisioning side. So a key feature of the way in which the actors behave on the provisioning side, is that there is a human step involved in everything that they do. In many cases, more than one human step and in many cases a human step in each of the three actors.

On the publication side, things are considerably more automated. The root server operators differ widely in the way in which they draw information from the root zone database, which VeriSign makes available in the form of a serial numbered root zone file in a distribution Master, or a set of distribution Masters. So the root server operators have a number of different ways in which they obtain that information and then distribute it to their root server instances, including Anycast instances. But for the most part that's a process that does not require human intervention, in particular the root server operators do not perform any inspection of the root zone file that they pull from the distribution Masters. They publish what they see there.

A summary of the findings: I encourage all of you to read the report, the executive summary is only two pages long so you have no excuse for not being able to read that. The most important finding is that the root is a very highly dynamic and decentralised system, and this is important for two reasons: It's important because the root zone does not change in a predictable way. The decentralised way in which the root zone management process is implemented means that each actor in the root zone management system behaves independently. There is no central coordination. There is no attempt to do global resource optmisation or management of the system as a whole. And sometimes when I say that people's reaction is, well, that's a flaw and we ought to just fix that and then things will be better. But of course, the decentralised aspect, or the decentralised nature of the root system is one of its biggest strengths. The resilience and survivability of the root system as a whole is enhanced dramatically by the fact that it is operated in a decentralised way. There is no single point of failure. There is no single point of coordination that could be exploited by attacker. As long as everyone does what they do independently and without any attempt to coordinate it with the rest of the system, there is a lot of benefit that accrues to the DNS and to users of the Internet from that feature. So, it's not one that we would want to toss aside lightly.

It's also extremely important to realise that any increase in the size or volatility of the root zone involves some risk. If the only thing we were interested in were the stability of the system, we wouldn't do any of what we are trying to do to the root. We wouldn't be doing DNSSEC, we wouldn't be doing new TLDs. We wouldn't be doing any of this if stability were the only concern. But clearly there are other concerns, in particular the security of the system, the ability of users to express DNS labels in scripts and languages other than English and Latin characters. All of those are benefits that we believe justify taking a certain amount of risk as long as we understand what the risk is and take steps to mitigate it.

But what that means is that the right question is not is it safe to do something? Because anything that you do to the root is going to create some instability, either short?term or long lived. The right question is: How do we ensure that we know what the consequences of taking a particular step are going to be and prepare ourselves to take additional steps to mitigate those consequences in any instance in which they turn out to have a negative impact?

So our conclusion, as a study team is that the right focus is not on trying to figure out where the thresholds are, where are things going to break, what are the numbers that tell you exactly numb new TLDs you can add or how quickly you can roll out things like IDN TLDs. But instead to focus on developing what we are calling an early warning system, which is a mechanism for ensuring that as a community, as a community not just of people who are directly involved in operating the root, but also people who are concerned about the Internet as a system, can see what is going to happen before it becomes an issue, before it becomes a problem that requires people to take extraordinary measures to deal with it. One of the metaphors that I use which works well in some environments and less well in others is: What we are trying to do is to arrange to not overdrive our headlights. And if you are familiar with that metaphor, what that means is that when you are out on the road, in an automobile in the evening, your goal is not to anticipate every possible obstacle that might be on the road so that you can imagine what preventative measures you might take if something showed up, if an animal suddenly appeared in your path. Your goal is to ensure that the area of the road that's illuminated by your headlights is large enough that you will have a chance to react to anything that appears in that headlight field. That's the idea that we are talking about here. How can we arrange to measure and monitor aspects of the root system in such a way that we have sufficient early warning of impending stresses on one part of the system or another, and that we also have in place the mechanisms that we would need to coordinate our activities to effectively respond to any of those things that happen.

And it's pretty obvious, it should be clear that in order for this strategy to be effective, the changes that we intend to make to the root should be done gradually. And this is where we'll get into the distinction between DNSSEC as a change and the other three types of changes.

Essentially what we are talking about is operating the system so that we don't force any of the actors, any of the four core actors, in particular, in the provisioning and publication side, to have to move out of what we are calling their normal operating region. All of us, as members of organisations, I am sure, are familiar with the fact that every company, every organisation has a normal mode of operation in which things like upgrades to equipment, upgrades to software, new hiring and so forth, happens in a way that is relatively straightforward. It doesn't require that the president or CEO of a company personally sign off on doing something differently. It's part and parcel of the way the organisation does business. And we found that this is a very important concept in the root system. In part because many of the activities of the root system management are undertaken by organisations that have other purposes; you know, that are not necessarily one hundred percent dedicated to maintaining the root. So ensuring that those organisations can continue to fulfil their responsibilities in the root zone management system, it's important to let them maintain the level of head room, and resource resiliencey that they need to perform those operations without having to move across a discontinuity into what we are calling a replanning region. And there is a lot of detail about the way in which we have implemented or the way in which we have elaborated this idea in the report.

Essentially, if you are looking at a change to the root that's going to require one or more of the actors to experience this kind of a discontinuity, then you'd better plan for it ahead of time because although normal changes, there's a normal update cycle that organisations have, can be done in the normal course of business, if you are going to require changes to the way in which any of the actors operates, you'd better allow 6 to 18 months, depending on the actor, for those changes to be put into place.

On the provisioning side: As I alluded to earlier, the ability to increase the size of the root or increase the volatility of the change rate is completely dominated by the steps that involve human interaction. So, if you are looking at where are the bottlenecks? The bottlenecks are very clearly at the points in which human beings have to touch a particular update or listen to the root.

On the publication side the effects are felt primarily on the long thin pipes that extend out to Anycast instances that are either in poorly connected or poorly provisions locations. And we did conclude, after looking at all of the data on how quickly or how ?? how much resource has to be devoted to each of the steps in the process, that an increase in either size or volatility, on the order of hundreds, annually, hundreds being a deliberately fuzzy term. It doesn't mean one hundred, it doesn't mean 900. It means hundreds, could be readily absorbed by all the actors without pushing any of the actors across one of those discontinuity into a replanning region. But that the risks associated with an increase on the order of thousands, again a deliberately fuzzy number, would require that at least one of the factors, and in fact probably more than one of the actors, to undertake a replanning exercise and essentially do something differently.

Now, the problem is that at that point, doing something differently takes many different forms. And one of the limitations we found in trying to do quantitative modelling of these issues is that the combinatorial effect of the different choices that each of the decentralised actors in the system might undertake, quickly become interactable from a standpoint of trying to do predictive quantitative modelling, so in the case of NTIA, for instance, in response to an increase in load that was greater than could be absorbed through their normal processes, might decide to hire more people in order to perform the same process, might decide to change the process to automate part of it, to change the policy that dictates which requests have to be examined and which kind of examination those requests have to be subjected to.

Just NTIA, just looking at one actor responding independently to an increase in load, you end up with five or six or seven different paths that you can follow. If you combine that with each of the paths that other actors might follow, you discover that this quickly becomes an interactable problem from the standpoint of building an actual useful predictive quantitative model.

So the next steps: Obviously we are going to be talking about this in a bit more detail, in particular on Thursday in the DNS Working Group session, I am going to try to focus on how we might go about defining the stress points, the measurements that could be made, or the measurements that could be collected and coordinated to give us an actual early warning system. What would be an effective early warning system? How could we relate the kind of measurements we make on the various parts of the root system to stresses that are about to occur so that we will not overdrive our headlights?

A presentation on these topics will be made at the ICANN meeting in Seoul at the end of this month. There is a public common area that ICANN has set up for comments on the report, and as I said, a further study, the quantitative model that's available today, is a first step. It may turn out that the quantitative model, even though it's limited to relatively short?term simulation for the reasons I described earlier, may turn out to be a useful point of an early warning system. It's too early to tell yet. That's going to be available to anybody who wants to play with it. As I say we are going to be defining what an early warning system would look like and how we go about building one.

So I'd be happy to take questions.

SUZANNE WOLFE: I have just got a quick comment. Suzanne Wolfe, Internet policy hobbiest, and the hat I am wearing at the moment is a member of the steering group that Lyman alluded to that will now have to carry this work forward in some form, make some recommendations or comments on it to the ICANN Board of Directors and the community as input to these ongoing policy processes.

If you are interested in these issues and haven't read the report, please read the report. If you want to comment, I see several members of the steering group and as Lyman said all of the members of the study group are here, so, if you want to comment, please do feel free to grab any of us in the hall, we want to hear from you.

CHAIR: Any other questions? Okay. I have got a question again for Lyman and again I am being a little bit unfair.

The scoping study was focused primarily on many of the technical aspects surrounding scaling the root, particularly the concept of introducesing new TLDs. There are a whole bunch of other factors involved in the generation of new TLDs, out from the purely technical focus and they are also going to have an impact on how quickly the impact to be scaled or growing and those include things like contractual terms for any registry operators with ICANN, contractual compliance issues with ICANN checking the registry operators on doing their job properly in accordance with the contracts that they signed, the actual cost of the application fees and how that's all going to be processed, how registrars, if they going to have the rental statutory how it's going to be applied, how registrars are going to be geared up with TLDs coming on with one or two a week, rather than the case of one or two every four or five years. Is ICANN looking at any of those kind of issues? Are there any other studies that are looking at those particular aspects of this problem?

LYMAN CHAPIN: Yes, very much so. There is a sort of an overarching activity. One of their overarching issues has to do with the effect of introducing new GTLDs in general. As Jim said, we focused on this study on the typical impact of the operation of the root system itself. The other impacts and the other effects that Jim just described are very much topics of discussion. Although they weren't part of the scope of this study, and they are not part of the scope of the steering group that Susanne described, they are very much on ICANN's collective mind and there are ways to comment on, or contribute to the discussion on those issues under this over arching issues umbrella. Beyond that I am not sure what the resolution of all of that will be. Some of those issues certainly have features that make them seem to be intractable, but they are certainly not being ignored by ICANN.

CHAIR: Thank you Lyman.

(Applause)

CHAIR: Concluding the DNS flavour to this session but not the actual session itself, we have two for the price of one, Matt Larson and Joe Abley are going to discuss plans for signing the root and how that's likely to unfold over the coming months.

JOE ABLEY: Good afternoon. We are going to go back and forth on this presentation. We are going to present different parts of it. The general project of signing the root zone is a collaboration between ICANN, VeriSign and the US Department of Commerce. This ongoing project involves various amounts of disclosure and publication of our various plans to the community and this is one of the early publication events in the plan. Towards the end of this, we'll see I think the first published airing of the time line for when we expect the root to be finally signed.

So the project is being driven by a requirements document that was put together by the US Department of Commerce. I believe there are people here who have seen that document. It's been circulated amongst various interested parties, people who are interested in seeing it can ask NTIA for a copy and I believe they will receive one. It hasn't been entirely openly published at this time.

The key headlines from that requirements document are transparency; that processes and procedures should be as open as possible.

That we have a high level of auditing for all the processes and procedures that happen surrounding the signing of the root. And that we have high security for those procedures and policies as well.


MATT LARSON: Good afternoon everybody. The first of our tag team here. Lyman's presentation talked about the actors. But we want to go over the roles and responsibilities here in somewhat more detail. You may be familiar with this, but we are going to add the DNSSEC responsibilities that are coming up that you may not be familiar with.

So ICANN is the IANA functions operator in the design that we are proposing, they will manage the key signing key and all the security that comes with that. In addition to the other information to change name servers and Enda dress records and address records for TLDs that ICANN does today, they will also accept DS record changes from TLD operators.

So ICANN as part of its standard process verifies and processes the TLD request and then it sends the update request to the DoC for authorisation and to VeriSign for implementation, which means publishing at the root zone.

So then, US DoC, NTIA, that's the mouthful of what it all means. They are all here to authorise changes to the root zone. Today they authorised all changes to the root zone. That's going to extend to the design when DNSSEC is implemented and the changes specifically encompassed by DNSSEC include of course, DS records from TLDs when those are submitted and also root key sets. And by this I mean the DNS key record set for the root itself which will include zone signing keys and key signing keys. When either a zone signing key changes or a key signing key changes that will also be authorised by DoC. And the important thing to note here is that this is not any different to what's going on today. It's just an extension of the current process to cover new information going into the root zone.

And one of the other things that DoC does, as part of the their authorisation process, is to check that ICANN has followed their agreed upon verification processing policies and procedures.

And finally, VeriSign: We have the root zone maintain err role, and specifically from a DNSSEC perspective, we are going to manage the zone signing key. And as what we currently do here will incorporate the DoC authorised changes as they come in submitted by ICANN and authorised by DoC, and then we'll sign the root. And then we'll distribute the signed root to the root server operators.

So, here is is picture that's remarkably legible that shows that entire process just in graphical form. I don't think there is anything here that is unexpected and is not really not covered in the preceding slides. I think it's pretty obvious the process flow goes from left to right, and we start with a change from a TLD operator. We wind up with a signed root reflecting that change. Note the two boxes on the bottom that say KSK management and ZSK management. This is a new process for the signed root that have worked to develop. But as VeriSign generates new ZSKs we have to send them to ICANN to have them signed by the KSK and then they are sent back to us. So we have developed a new protocol for that, a new set of policies and procedures, all kinds of documentation, lots and lots of documentation that will be coming out in the coming weeks.

JOE ABLEY: Okay. So from the ICANN perspective, the majority of the work that we have to do is exercising the KSK and managing the KSK. Most of this work is described in a document called a DPS, DNSSEC Policy and Practice Statement. This has been based on the framework that the IIS people have put together. It was presented at the last IETF meeting and it's akin to a CPS that an X.509 per authority might publish, or at least might adhere to. It states the practices and provisions for root zone signing. In our case, because we have the split of roles between versus see sign and ICANN, we actual see have from DPSs, one for VeriSign and one for ICANN and they are compatible and complimentary.

So in terms of auditing and looking at the process as it takes place. On the left?hand side of this diagram, we have what happens at ICANN. This is the KSK management box. You will see here at the bottom of that box we have this DPS, that DPS is a reference for these two boxes at the top, the Global Internet Community and Third Party Auditors, what those people do is they participate in those processes, which are actually carried out largely by ICANN staff, so those processes are, for example, to bring on new HSM hardware online, initial eyes it, generate new keys to published trust anchors, to actually use the KSK, which is what we have to do when we get a key signing request from VeriSign with a set of ZSK bundles that use signatures and ultimately to destroy a key. Within this we can roll keys, recover from compromised keys, all the things we need to be able to do are contained in inside this left hand boxes.

Both are linked in content and in terms of references to this protocol that Matt mentioned and VeriSign has a corresponding box on the right, the principal difference here is that the interaction with the global community happens with the KSK. So the trust that we are trying to instill in those whole system from people watching what's going on happens with the KSK. The ZSK is managed in ARIN internal manner. The other is only in the public portion of the zone.

So within that left hand box specifically, as actually part of the protocols that are exercised when we use the KSK. There are two principal roles for people who are outside VeriSign and ICANN. First of all as CRYPTO officers, people who hold the smart cards and interact with the HSMs together in order to actually exercise the KSK; and secondly as people who are nominated as being key shareholders. These are a group of people, a number of which, if they collaborate, could reform a backup of the KSK, if we ever needed to disaster recovery.

So most of these things and that thing in particular, we expect never to exercise in terms of actually having to recover the key. We are building out two facilities with different vendors in geographically separate places. We expect to have copies of the KSK materials in those secure facilities which are separated. So you'll see as a theme through this, when the DPS is made public and people are able to read, there are a lot of what ifs that we hope never to use but for completeness they are all there.

And the other aspect in both those boxes was third party auditors. We will have auditors trusted by the community who follow the guidelines and confirm that what's carried out in these facilities when the KSKs are used conforms to all the policies. And once that confirmation has been acquired and people have written legal attestations that were procedures were followed correctly, that documentation will be published along with the trust anchor.

MATT LARSON: Now for some of the really specific details about the DNSSEC implementation itself. The KSK we are going to use a 2048 bit RSA key. The plan is to have that last on the order of 2 to 5 years. We will roll it when necessary, when we believe that level of security is no longer sufficient. We are going to be using RFC 5011 so the appropriate protocol will be followed, so somebody with RFC auto 1 compliant will see the role and in theory it would be seamless for them.

We are also proposing using signatures based on S H A?256. This code point has just been assigned. It's actually not in our CE yet, it's impending, but imimplementers want to write code that supports it. All they need to do is plug in the protocol number assuming they already have a code number. The idea here is we know that we are headed to SHA?256 eventually anyway, and we are just interested in getting it over with right out of the bat. This also has the advantage of, if you will, flushing out old software. So we'll wind up with only new software because only the most recent software will support SHA?256.

For the zone signing key, we are going to use a 1024 bit RSA key. We intend to roll this once a quarter. Obviously four times a year then. We are going to sign the zone with NSEC. I don't know if anybody was worried that we might sign it with NSEC 3, but no. Likewise these signatures is the proposal is to also use SHA 256.

This is actually what happens at ICANN, the key ceremony are going to be really very elaborate, well documented, transparent, open ?? I am running out of adjectives, they are going to be these ?? fuzzy ?? warm and fuzzy, you should feel warm and fuzzy, yes, so there are two principal certainly niece that have to happen, both of which Joe mentioned. The first is key generation. This is going to be required by most people because those backup shareholders are going to have to be all in place, and that's when a new KSK is generated, but that we intend only have to do every two to five years.

On the other hand, processing of what we are calling, we made up this new term called a KSR, a key signing request, or in this case, a ZSK signing request. This is comparable to a CSR in the X 509 world. When you want a certificate from a certificate authority, you generate a CSR. You put your public key that you have just createed in that CSR. You send it to the CA and the CA generates a certificate and sends it back. So then this process is very similar, and the interaction between VeriSign and ICANN, we are using at this similar terminology. So basically once every quarter, VeriSign will generate a new zone signing key and send a request of signatures that we want to ICANN. ICANN will verify that what we have asked for is within the parameters we have agreed on. They will sign the ZSK and send it back. The process is more elaborate than that. It's not just one signature, it's several signatures because they have a validity period that's shorter than the quarter.

One of the other documents that we have in addition to the DPS documents, each of which are quite long, they are about 40 pages each, we have a ten page high level architecture document. I also expect that to be coming out around the same time as the DPSs within the next few weeks I hope, and that's a document where if you know about DNS, DNSSEC, you can sit down and read this document and come away with all the specific technical details in much more detail than recovery.

Then as for the root trust anger itself, this is the root trust zone KSK. The intention is to make this available several different ways. ICANN would publish this in the websites in several different forms. Both as a plain DS record, like we are all used to looking at it, and also in an XML wrapped version. So we have defined and XML format for a DS record that specifically describes each field. And this just makes it somewhat easier to machine pars that.

Also, we are going to publish the key signing key in an X 509 CSR. So this might seem a little unusual, because you know, X 509 and certificates have nothing to do with DNSSEC, but by blushing the KSK within a CSR, this will allow third party CSA, as well as CA as that ICANN intends to use for this purpose to generate certificates. This will allow third parties to attest to the validity of the KSK and it will let them do it in a standards based way that they already have infrastructure and tools for.

JOE ABLEY: So we don't have much time left. I am going to talk briefly about the way that we are thinking of rolling this out in the public DNS. The details of this we are going to go in much more detail on Thursday in the DNS Working Group. So this is a fairly high level sketchy sort of coverage of it.

The general idea here is to role roll the signed root out incrementally. In this case we are thinking that rolling it out one letter at a time. So there will be some root servers at any time that are serving a signed root and others an unsigned root. The reason for doing it this way is that as many of you who have participated in these discussions over the past while know, we are expect much larger responses to come back to a lot of resolvers that haven't been consciously configured to be validators by virtue of the fact that the DO bit was used in a way that wasn't necessarily intended. As soon as a validater or a resolver is non validating it's exposed to a signed root , the response size will be bigger. Fire walls and and other such things are not capable of receiving big responses or by default might crop them. This is hard to predict, we propose this incremental model so that we can measure the damage incrementally as we go over a period of time and try and assess exactly what the impact of it without necessarily breaking the whole Internet at once.

The other factor, the other feature of the what we are thinking of, proposing for rolling this how the is that initially we will make signatures based on a key set that is not published. So the DNS key, in the root zone, will not correspond to the key that's used to make the signatures in the zone. So the consequence of this it will not actuallies possible for anybody to validate answers from the root zone. The reason we are doing this is because if at the end of day it's decided that there is sufficient damage from the larger responses that we need to unsign the root, then at that point we can unsign the root without impact /?LG people who have turned on validation, who would otherwise see the DNS go dark because suddenly validation would fail T would look like a man in the /TPHEUD he will attack.

Now, having said that, we are taking steps here to be as conservative as possible with the way that we roll this out. We don't anticipate having to roll this back. However, it's very difficult to be able to persuade people that we should proceed at all if we don't at least have a plan for how we could roll it back. As I said there will be far more detail on the technical aspects of this on Thursday in the DNS Working Group.

MATT LARSON: Here then are the dates. I hope nobody read ahead. So, December 1. The good news is the root going to be signed. I won't say the bad news. I will just say the additional news is that it's going to stay internal to ICANN and VeriSign. So, it's going to stay internal while we do the, roll out that Joe mentioned. Also during this interval for the next seven months, ICANN and VeriSign are going to begin the KSR process, and we are going to run this process twice actually because in that seven month period, our two 90 day intervals which is the exact interval that a ZSK role will take. So we'll be rolling the ZSK, ICANN will be rolling the KSK, so we want a bunch of real world happening at the right timescale experience with this before we go, sort of release the root zone to the community.

So then, up until July is the incremental roll out that Joe mentioned. Finally on July 1, the KSK is rolled over to the actual real KSK and the trust anchor is blushed and the consequence of that is that the root zone is signed.

(Applause)

That's the most unusual applause line ever.

So if you want to know more, as Joe said, come to the DNS Working Group session, the second session. There is more time set aside there for QandA and in particular what we are going to talk about in more detail is the incremental roll out.

CHAIR: Okay. We have got time for a few questions. Start with bill first.

BILL MANNING: Are you guys nuts? I had to do that. I Am Bill Manning. There are two things that stand out in this that are a bit disconcerting and I'll put this up to Joe's inability or his lack of public exposure at the mike. One: If you guys have a fallback mechanism, if you do not exercise it on a regular basis like throw somebody under a truck and use the backup facility, I am less confident in that backup ability to actually function when it's needed. You better exercise it regularly.

Number two: That the key size of 1024 has got at least in the US Government parlance, has got a very limited shelf life left, so are you going to be contemplating changing the key sizes in the next couple of years?

MATT LARSON: The CRYPTO focus at /TPH*EUS are still very comfortable with the 1024 bit key used for 90 days at a time today. Certainly when 1024 is not viable any more, we'll definitely increase it as necessary. What we get from the people who claim to know is that this is well within the current bounds of safety today.

CHAIR: Next question.

AUDIENCE SPEAKER: Olaf, this is an incredibly important milestone, thank you for making this happen. But, the previous presentation and this presentation together made me come up with a question which is: There seems to be a delay in the provisioning system when it comes to manual validation of data that goes into the root. I can expect a situation of high crisis where a TLD had its private key compromised, its KSK compromised, or lost it in another way. I am not sure if you guys can answer this question, but is there some sort of service level for TLDs so that the process of validation can be expedited in those cases and you can actually call somebody in the middle of the night?

MATT LARSON: Yes, absolutely, the idea is ?? well, I can't speak to the IANA side, I'll let Joe do that, but the idea in the requirements that we have been given is that DNSSEC introduces the possibility of real emergencies, a situation that we don't really have today, and I unfortunately can't remember the timescale that we are committed to but it's a very short timescale. It's like in the order of ?? I don't even want to quote, it's like a day or two days, very very short relative to ?? relative to the signature for any period.

JOE ABLEY: I'll add that IANA already supports a 24 base 7 emergency line. That has been exercised in the case of catastrophic failure for example in host infrastructure, floods and such things. So that line of communication already exists.

STEPHEN KENT: Steve Kent, BBN. I just want to reiterate what Joe and mat said in response to bill's question. The 1024 bit RSA key size recommendation from anti?spoofing need to be read in context they are dealing with longer term signature issues and because of the short?term relatively speaking use of signatures with a three month key lifetime. That's not really a big deal. So I think it's completely fine at this point in time. (/TPH*EUS)

AUDIENCE SPEAKER: Two questions about when. On the slide about changing the zone signing key quarterly, the other parameters I am used to seeing about that point is the repetition rate for actually generating signatures. Is that decided? I thought it was in the draft.

MATT LARSON: That's a good point. That was left out and that's an omission. So, the signature validity period for the DNS key set is going to be ten days. So in a 90 day period there are going to be ten signatures that will be put in at the appropriate time. And then the signature validity period for everything else in the root zone signed with the ZSK is going to be in the order of seven to ten days. We haven't come up with the exact number but it's that order of magnitude.

CHAIR: Is that going to be discussed in more detail on Thursday?

MATT LARSON: We can. There is not a whole lot more than that but we are happy to answer whatever questions.

AUDIENCE SPEAKER: The other when question: Understanding that it will not be possible to validate the contents of the root zone, but there is a question of when will you start putting the DS records from TLDs in the root zone? Sort of prompted by my questions about PT. When will there be a mechanism so they can put that information in the right place?

MATT LARSON: Well, I think I am going to have to defer on that one, since I am not sure that I can remember the answer to that part of the design frankly.

CHAIR: Maybe we can pick that up again on Thursday. I have one question just before we close off the discussion here. Sorry...

All this issue around the processes that have been been developed by yourselves and with VeriSign and with NTIA and ICANN and IANA to handle all of this stuff, it all looks very good and I am sure that you have done a fantastic job on that. But has there been any discussion of any independent analysis of that or bringing in consultants brought in to check all this, and for example, the considerations that Bill was mentioning about what happens if one of you guys falls under a bus?

JOE ABLEY: Well, if we skip right back near the beginning, one of the requirements that came out of the NTIA was that the system be considered a high impact system. And if you actually look at that document, which is a fairly long, good for a five hour flight or more, you can actually see what the implications of that are. That document goes into detail of what these parameters are. The requirements documents that NTIA present was in collaboration with their collegues at NIST. The requirements are in that document. The design, the entire thing from the ground up, has been based with basic level of publically understood security constraints. Once the documents are published, NTIA's intention, if I understand it correctly, is to seek technical input from the community before the operation actually goes public. So there remains, after internal review, an opportunity for many people to actually go through the entire documentation set and become involved. We are just not quite there yet.

CHAIR: One last question. Then we have to close things off.

AUDIENCE SPEAKER: In a sense, you have kind of answered this question on the edges but I think it's important to hear what's going on with respect to the following question. My name is Glen and I was a participant in this study that Lyman just reported on. In that study it identifies that the move to signing the root is a bit of a square waive in terms of the size of the root to the effect of two or three. It also identifies if you have to make any changes in the four enlargement factors that Lyman identified, that it's kind of DNSSEC or the others but not both at the same time. So, at the same time. So at the same time, there are also issues about the square wave, whatever order the changes happen in the expansion of the root zone, there are questions as to whether or not the root server operators have been in the loop so they can handle this growth. So I am curious where you are on that process. I realise it's a little unfair to put the cart ahead of the report for you guys because the report still just came out. But I think it would be good to speak about that.

MATT LARSON: The root operators have been involved and one of the first thing they asked was can we get a copy of the signed zone in advance so that we can test all aspects of our system to make sure that it works. The intent is that as part of really the testing precedes the deployment that we spoke about, that the root servers are all involved and feel very comfortable but the incremental roll?out that we mentioned starts.

CHAIR: Thank you very much Joe and Matt. Thank you.

(Applause)

CHAIR: We are running a little bit behind schedule. I thought it was important we had a reasonable discussion about some of these issues about this very important issue of signing the root zone. So we have Maarten Botterman.

MAARTEN BOTTERMAN: Good afternoon everybody. After that exciting presentation, I am going to tell a little bit more about the IPv6 deployment survey we talked about in Amsterdam.

As you all know the reasoning behind this was based on a European commission thinking that it's about time to see whether things were moving ahead here. And they apologise for not being here in fact and asked me to give a short update on why they did this before I go into the results.

This is clear. There is an urgency coming up with growth in terms of users and applications on the Internet. No need to say that. In the European vision in 2008 to publish a document called the Action Plan. There is some urgency in Europe.

The reasons for primarily to prepare for the growth in Internet usage, and for allowing future innovation by taking away the scarcity that was there with IPv4. And obviously their reason to get into this is because they care about Europe's competitiveness as well as the key policy aims in the European Union.

So, what can be done about it? And actually it's pretty simple. For us, I think what we see now is that the Government does get involved in making something happen here, and we are not used to do in this community. Yet, maybe at some point we need that involvement and that support for clear public interest reasons.

Their intent is to do a significant step by 2010, as soon as possible, and the means that they have really in their hands is something like public procurement, and obviously they will take care of issues like monitoring the security and privacy issues as a Government sees its task in general as well.

But, the IPv6 transition itself will not be driven by them, it will be driven by you and the users, providers and users. So that's why in June, to the RIPE meeting, the proposal was really like let's see what we can do by informing them as well as possible on what the real problem is; identify the bottlenecks and come to useful propositions of solutions.

Now, this is all part of a larger project that we carry out with T&L, I mentioned before in the root scaling study as well. In fact the survey is one part of it. Another part is that we are trying to really measure what's happening in IPv6 take up in the net and there is more discussion with that on Wednesday afternoon in the measuring group. And we also looked at, because it was part of what the European commission thought was important, the up take of IPv6 by the web content providers.

So the information gathering was really from global resources. We all know the work Geoff has been doing in this area. But there is also many more key informants, interviews and the survey itself.

So the survey itself is really to get that view. And it is based on a survey done earlier by ARIN a year ago, that really was already collecting some useful data, and we also have to feel that by coming to a kind of survey that's global, ultimately we can have this done on a global basis, which will give us some ground for analysis in the coming years.

So this was carried out in the RIPE region, and many of you may have participated in that in July of this year, and actually APNIC also carried it out and closed its survey on the 2nd October. They were kind enough to send me a first analysis of that already done, and I have been able to include some of that here as well. So, I will be able to see, show you as well, what the differences are in the region. Now, the value of a survey is, of course, if you do it again next year, you can see the differences. But now we have the advantage of being able to compare two different regions and there is differences too, and that will lead to some interesting observations.

So, this is the outcome of the survey. First and for all, 610 of you did fill in a complete survey and contribute to this. We are pretty happy with that. I think that gives us some grounds for saying at least what comes out is not just notes from a few, but the community.

If you look to Europe, it's pretty well spread as well. Obviously some countries more than others. As we see from Germany and the United Kingdom, but that's not a surprise. But there is participation from all through Europe.

The respondent categories: Again not surprising, mainly ISP. We also see that we split it out to education, Government, and specific providers. Obviously we don't want to draw conclusions too much on too small samples, so we didn't do a complete analysis on everything that the education sector did. We kept that in one box in the end.

The presence of IPv6 from the respondents, and I don't say this is typical or in general across the world, is that only 37% said we have no IPv6 presence at all from the RIPE respondents. 31% employs it only in its internal negotiations and 49% also has some presence on the Internet. This is to give you a background of experience from which people come when they respond. So if you compare this to the APNIC region, interesting enough we see that within internal networks, apparently they deploy it much more than we do. In this region at the moment. For the rest the typical signature is pretty similar.

Just in short. 90% of the people that responded have registration service agreements with RIPE NCC. 80% work for profits companies which means that also the for?profit thing forms them in their decision making about IPv6. 75% is EU based, which is important for the European Commission of course. And from the survey, 356 ISPs, largely small ones with less than 100,000 customers.

So if you asked those people how does your IPv6 traffic today compare to IPv4, you see that actually it's still a very small part where IPv6 already today begins to be significant. Actually that's slightly more so in the APNIC region, where you see that a higher percentage for IPv6 in certain corners is beginning to pick up.

Now, this is the only slide where I put the sectors next to each other. I indicated the number of responses here, so you can make your own conclusions there. I am not trying to spin anything. Basically, what's interesting here is that if you have this IPv6 action plan that the European commission level, which is shared with member states and the Government says, well we will lead the way, the people from Government who responded to the survey didn't know.

For the rest, it's reasonably logical. I think education is relatively little, subject to the test of the profit margin, and they are pretty high in terms of considering doing something with IPv6. The professionals of course, they want to know what's going on and the non ICT is laying a little bit behind logically.

If you look to ISPs in Europe that consider having IPv6, we see that the large ones all have it. They all do something with it. They are all active with it, so this is again some logic that you would expect.

If you talk about promoting IPv6 uptake to their customers, do they think that it's something worth doing. This graph is interesting. What I was intrigued by seeing the outcome of the APNIC survey last Saturday, where apparently the preparedness to promote IPv6 is much higher than in Europe.

So, now is the questions: Why not consider IPv6? What is the reason for not doing it? And I'll throw in the APNIC data as well. Obviously don't see the business need and we don't have the customers yet. That is the driver that's generally comes up logically. What you see as well, is that there is problems still there with infrastructure, with ISPs not supporting it and the risk taking of the change. Also, remarkably, what you can see throughout, also in the other slides, is that apparently expenses is a bigger issue amongst the people replied in the APNIC region than in the RIPE region.

So, the biggest hurdles as seen are those. By those people implementing IPv6, vendor support at the moment is the biggest hurdle experienced. For those who haven't been working on it yet, we see that it's cost. It's funny to see that cost of course is much less if you really start working with it in terms of hurdle, but it's ?? if you compare that with the ARIN, the APNIC, sorry about this ?? data, remarkably, availability of knowledge is a much bigger hurdle for that region. What I have done here in the region for the rest, I don't have lots to add.

The main drivers tore IPv6 deployment, so why would you want to do it? Remarkably similar. There is a lot of people out there, and obviously we have to to remember this is a survey that was responded to by people who have an interest in IPv6. Otherwise why would you respond to the survey? But wanting to be ahead of the game is very much up to the point. But also note, it is more than 70% who really feels that there is a reason to invest in IPv6 today.

Customer demand is clearly not the leading factor yet, although for some of us it is already a main reason to do it.

Now, this is interesting too. If you look at planning IPv6 deployment over the years, we see that the upper part where there is no plan at all and this the red part, is what's currently deployed. Effectively, there is a lot of people who haven't planned anything yet. And if you compare that to the APNIC region, we see that the level of planning is much higher already today. So in some ways, there seems to be some preparedness that is bigger than here in this region.

We see that ?? well, for about 90%, it is already planned, whereas here we are only at about 65%. So that's maybe something to think about.

Now, for those of you who have experienced what comes with IPv6, obviously again the lack of user demand remains an issue. Also means that you can't always test what it means at the end. But technical problems are there too. In the APNIC region, the technical problems become relatively more dominant, and almost seem to some with more experience. More experience means you experience more technical problems as well. As we can see here.

Now, in terms of setup, what do people use? Mainly overwhelmingly, dual?stack. Not a surprise at this moment, we can still afford the dual?stack because we still have some IPv4 to do that. Tunnelling is there too. Much less than one would think. Mostly it's native IPv6 here. If you compare it to the APNIC regions, the dual?stack is overwhelming there too, but much less of native IPv6, much more of the tunnelling, the non?automatic tunnelling, which is something we can not do for the entire world but issues for now. I am curious about your opinion on this big difference because this is one of the slides that's most different between the two regions.

Now, as I said, we have also been measuring some of the progress. More will be told about that tomorrow. This slide shows is actually measuring of visitors to the TNO website, just measuring which ones come with IPv4, which come with IPv6, or a mix. I don't want you to draw any conclusions on the light of these things, although one could say that obviously the Netherlands is pretty stable line, which is the Dutch research institute comes from the Netherlands, but this is the kind of pictures that we think we can generate if more websites are going to join in sharing purely data of the visitors in terms of IPv4, of IPv6, and there will be an invite to you to helpen join that.

Now, we have been talking about the urgency as well. What we also did is collect some data on the usage, and one of the striking tables that came out. If you look to the number of advertised IPv4 addresses per 100 inhabitants, we see considerable differences in countries. We can see that most countries are at about, well, 70% in Europe. Whereas some of the countries, the more advanced like Sweden and Finland, that they are twice or triple. That means that there are a lot more amount of addresses. And another picture is if we compare the allocated indicator announced IPv4 addresses, we see incredibly how many are close to full requirement in a way. So I see much more beautiful pictures of this this morning, but these are pictures the policy makers understand too.

So, main conclusions overall: For now, and obviously a step, much more IP addresses will be needed during the coming years, if only for seeing that the same maturity of use of Internet will get to other countries as well over time, but also mobile Internet, and we had an interesting discussion over lunch, whether also the Internet of things will draw a lot of need for Internet addresses.

Whatever happens, obviously no new IPv4 addresses will be available any more at some point, and policy makers begin to see that too. And from the survey the main conclusion that is we draw now ?? well, first of all, we do need to be careful drawing conclusions. We know this is not a sample that is representative. It is from a group of people that has an IPv6 interest. And we also don't know how well informed they are on specific situations. Yet, it is a bottom line. The other reason for IPv6 must be a priority that clearly is, and we all know and expect that. The lack of the business case and customer demand, but we also very clearly see here that IPv6 vendor support is still lacking still today. And we need to look into the how to turn that around.

63% of RIPE respondents have, or consider having an IPv6 allocation and do something with it, and we saw that apparently, in particular the Government sector surprise there by being less eager to switch to that.

So 21 percent of the people are not convinced of the need of IPv6, and I think later today, we'll have a discussion in the IPv6 track on how that may be, and how that could be changed.

Well on ISPs, in particular, we see that 18 percent has or considers having IPv6. I wonder what the other 18 percent is going to do. 56 percent has it in production already in some way or another. And the other striking thing was, particularly when I saw the APNIC data, is that only 40 percent doesn't consider yet promoting IPv6 to its customers. So, one could think what arguments would you need as ISP to get on board?

On the website content, I mentioned what we did do in the project, it was not in the survey, but we checked the top 30 websites in each and every country in Europe from Alexa, and at this moment in all 27 European countries, in fact in all 52 countries, we checked there is one website in the top 30 that supports IPv6. Free.net or something, a French site. I have to check that. And it's fortunately available in three of those 52 countries. Switzerland, Belgium and France, all countries where they speak French.

And last but not least a set up today is overwhelmingly dual?stack and native. Let's be aware of the issues that come with that and prior advertise for that. We see we expect towards the future, we expect a change on that. I hope we touch on that in the slot this afternoon as well.

So, for me, the good news is that respondents did say, hey, this survey is worth it, I want to do it again next year. More than 90 percent indicated that across the world, which was for us a condition for doing it again. So, we'll be back next year and then we'll be able to show also the changes over time, which will be interesting.

The other thing I think that will happen next year is that it will be truly global.

And obviously the thanks to the commission for making it possible for the RIPE members that helped us to prepare this survey, by responding to the first versions and help us improve it. And RIPE and APNIC staff for sending out the invitations and helping us to gather the responses, more than 470, about 470 in APNIC and 610 in the RIPE region. And a special thanks to a couple of people who were useful in this process. So if there is any question, please e?mail me or ask me or approach me here. I'll be here tomorrow, the entire day, as well. If there is a question to the commission, please note the address on the bottom, which is the person responsible in the European Commission for the deployment of the action plan.

CHAIR: I think we have a question here.

MARCO HOGEWONING: It's Marco. With the risk of being kicked out of this room by a couple of Nordics, but you can call 200 IP addresses advertised per inhabitants IP maturity, it might as well be that they are very efficient in getting allocations. So there is absolutely no relation so what's actually in use, so maybe for the next time, find out what the actual assignment level is and find out what that is per head instead of just looking at allocated or advertised prefixes. That might be a more correct figure.

AUDIENCE SPEAKER: Just a comment. It's the same. I work in the same direction.

CHAIR: Your name, please, for everyone. That's Liz engine. Could you please give your name.

LIONEL HOFFMAN: Lionel Hoffman. It would have been interesting in separating both the ISP, the fixed ISP cable DSL and mobile operator, because we can observe that in fact if it was a fixed ISP today, they are starting to deploy IPv6, okay. It's not the case for most of the the wireless and mobile operator. It's totally different today. They are totally done by mode and a lot of things are missing today, so forth next, I think, survey, could be interesting in separating both, the two cases.

MAARTEN BOTTERMAN: Thank you for that suggestion. And in fact I would encourage also a proposal for even improvement of this survey before we go even wider next year. The input has been valuable very much this year and we have learned more and indeed the mobile, this new uptake that we may want to look at specifically as well.

CHAIR: No more questions? Okay. Thank you very much Maarten.

(Applause)

I just wanted to make a quick administrative announcement. Continuing the IPv6 theme ?? Chris Buckridge from the RIPE NCC. And also continuing the sort of unofficial RIPE NCC T?shirt giving out day, we have some IPv6 Act Now T?shirts to give out during the coffee break, so if you'd like one of these, come up and see us. IPv6 Act Now is a new website that the RIPE NCC is operating. You'll hear a bit more about it tonight. We are sponsoring the social events. So there will be a few IPv6 Act Now things around to just show you a bit more about the site. Might see you at the coffee break.

CHAIR: Thanks, Chris. See you at the coffee.

AUDIENCE SPEAKER: To the last speaker here. What about IPv6 connectivity here? I don't see any.

CHAIR: That's a question for the opposite team and for the IPv6 working group. It's now coffee time.

(Coffee break)