IPv6 for Registries and Registrars 26 June 2008 Paris, France. >>LEO VEGODA: Hello. Is this on? Hello? Okay. I think this mic is actually on. I was just talking quite quietly before. So hello. My name is Leo Vegoda and this workshop is about IPv6 deployment and the focus of this workshop is IPv6 -- support for IPv6 within domain name registries and domain name registrars, and I hope that we've got an interesting session lined up for you today. All panelists are now here, and I'll introduce them to you. We've got three hours scheduled for this, 9:00 until midday. I have a feeling that we might finish early, and if we finish early, then everyone can have an early lunch. That's not a problem to not run the whole three hours. I think especially after that great gala dinner last night. So let me introduce the panel to you -- oh, actually, before I do that, I should let everyone know that we have simultaneous translation in this room. If you don't speak French, English, or Spanish and you want to be able to understand people speaking French, English or Spanish, or you want to speak in a language -- another language, you can grab one of these headsets at the back. Channel 1 is French, Channel 2 is English, and Channel 3 is Spanish. When you start speaking using the -- when we get to the discussion section, if you could make sure to say your name slowly and clearly. Also, to help our stenographers make a transcript of this session which will be streamed live and archived on the Web site. So let's start with the next slide. Ah! So, yes, this is our agenda: Introducing the panel, a quick overview of the status, and then our panelists will speak and plenty of time for discussion. So our panel, to my far right, Raúl Echeberria from LACNIC, who will be introducing the subject from the perspective of a registrant looking for IPv6 glue. To my direct left, your direct right of me, Mohsen from AFNIC, talking about implementing IPv6 in a top-level domain name registry. Jean-Claude to my far left, your far right, who has implemented IPv6 at BookMyName. And to my immediate right, your immediate left, Michele from Blacknight, who has also implemented IPv6 on his network and is both a registrar and a hoster. So let me start off by just looking at the problem, and this is a little graphic I created to explain why IPv6 is necessary from the perspective of looking at the IPv4 address space. A portion of the IPv4 address space isn't available for use by regular desktop and laptop computers. It's reserved for things like multicast use, for things like loop-back addresses, and so on. Also, there's a block of 16/8's. That's 16 of what is sometimes called Class A blocks, although they're not actually from Class A, that are reserved for future use, and that future use was never defined and looks like it never will be. But we've got 39/8 blocks left, but we're allocating a little bit more than 1/8 a month, so we haven't got much time left before we're out of IPv4 address space in the IANA pool, and the result of this is that the RIRs pools will then run out shortly afterwards and then any ISP or Web host or company will have the finite capacity of their own pool of addresses, and growth will be constrained. It's not that growth won't be possible for a while, because not -- the address space isn't 100% efficiently used, but continued growth will require a new set of numbers simply because there are only 4 billion IPv4 addresses. So if we look at the next slide, this is a graphic I took from Takashi Arano's Web site, which is the number of days left until the IANA IPv4 pool is depleted. It's just a little bit over 900 which isn't really very many days. This is all based on mathematical projection, though. It's taking the curve of address consumption over the last period and projecting forward. It doesn't take account of human behavior and the human tendency to go and say, "Oh, that's useful, I need it, I better get some of that before it runs out." So although it says 935 days on there, it's entirely possible that 935 will be less than 935 because the curve will change as people get a greater understanding of the fact that this resource is about to be fully consumed. So where are we today with IPv6? Well, IPv6 as a protocol is defined as essentially complete by the IETF. The IETF is the group that defined the protocol. They've closed the IPv6 working group and opened the IPv6 management working group, 6MAN. So what they're saying now is IPv6 development is done, IPv6 tweaks and maintenance work are what is left. So from a protocol standards point of view, the work is done. IPv6 address space has been available for production allocation since 1999 as well. So almost a decade. And we've got some networks out there, but only between 3 and 5% of the number of networks that you see in IPv4. So it's only a very small fraction of the IPv4 Internet size, and one of the problems is it's difficult to get IPv6 all the way through, partly because of problems getting IPv6 glue for domain name registrations, which is something that Raúl will be speaking to in a moment. So, in fact, let me introduce Raúl again and pass the microphone to him, and Raúl is going to describe the situation at LACNIC from the perspective of a registrant of a domain name that wants to deploy IPv6. So Raúl Echeberria. >>RAÚL ECHEBERRÍA: Okay. Thank you, Leo, for that introduction. Good morning, everybody. I will make a short presentation, only for sharing with you the experience of LACNIC trying to register our DNS servers in the -- through our registrar system. While I'm not the person that is in charge of doing that in LACNIC, I hope that I can anyway talk with you and answer any question from you. LACNIC is the -- LACNIC's domain name is LACNIC dot net and our DNS server is NS.LACNIC.net. We have secondary servers in different infrastructures, different organizations, three of them hosted by ARIN, APNIC and NIC Brazil. And so while we have servers outside of our domain, our main DNS server is NS.LACNIC.net, and so due to this situation, we need the register -- to update information on our servers with the registrar, what is known as the glue record, that I assume all of you know what is that. So we started in March of this year with our registrar. The process -- we start the process for including the information of our DNS server in the IPv6 format. The first time that we contacted the registrar, they say that they don't need to do anything regarding IPv6, that it is not under their responsibility. So they say, "We don't need to do anything about that." So -- but we have some informal talks with some people, and we started a new ticket. Before that, exploring the Web site of the -- of that registrar, we realized that they offered the glue record in IPv6 format for the customers, the people that have hired with this registrar the DNS resolution. So it motivated us to initiate a new process, a new ticket with the registrar, so the first answer that we received was the instructions for going through the system and updating information, and we did that, but at the time of typing the IP address, we realized that we were really frustrated when we realized that it didn't serve the IPv6 format if that field. Probably it is one of the things that it is interesting to remark, because probably it is only a problem with -- minor problem in the code of the program, but the fact is that it didn't accept IPv6 format. So we insisted -- we informed the people from the registrar that what happened with us. Finally, in June of this year, the ticket was closed as we were told that the -- the registrar didn't support IPv6 format. I have here the image that we received from the registrar saying, "Thank you for contacting online support in regards to your request for information on how to utilize this format. Please be advised that we are not able to assist you in this matter, as we currently do not support IPv6 format. There is nothing more that we are able to assist you with regarding this." So what is the situation? For LACNIC it is not really a big disaster because the domain remained being accessible over IPv6 because the servers that we have on the other domains, but it works -- while it works, it is not the right solution. You are people involved in this business, so we can guess that we would like to have this problem solved in a different way. While LACNIC can survive in the situation, other people probably could not because they probably don't have the opportunity of having secondary servers offered by other organizations, so we will need to have the DNS servers registered through the registrar system, so the question is how to do that. I say that it is a short presentation. Thank you. >>LEO VEGODA: Thank you very much, Raúl. Does anyone in the audience have any questions, requests for clarification, from Raúl? In that case, I'd like to hand the floor to Mohsen, who is going to explain what AFNIC has done to introduce IPv6 support in the top-level domains that they run. So if I can have the cable. >>MOHSEN SOUISSI: Hello, everybody. My name is Mohsen Souissi. I'm going to just disappoint you. Actually I'm the R&D guy and an if you have technical questions about IPv6, go to the operations guy. IPv6 is in production at AFNIC, so R&D is far from that. So I'm just going to present you this point of view of dot fr, the French registry which has been working involved actively in IPv6 for more than ten years now. Okay. I'm going to stress something before my presentation. If you are a registry and you are going to deploy IPv6 today, you are really very, very lucky because you are not going to undergo our issues. Everything is there. If you want to summarize my presentation, it's: Everything is there to deploy IPv6 in your registry. Yet there is a methodology. I'd like to give you some feedback from AFNIC about our way we deployed IPv6 and the way we are still involved in IPv6 deployment in the French Internet, more specifically, and in the Internet more generally. So it's not a goal in itself to deploy IPv6 at the registry level because the goal is to get IPv6 deployed. Maybe it's my militant point of view of IPv6. Okay. So the presentation, actually AFNIC is also a registry for other ccTLDs like dot fr, Reunion Island, dot WF, et cetera, and also IPv6 is deployed at AFNIC at two levels. The first level is the company, the enterprise level. We do networking and we're networking every day, so we have -- as all companies -- firewall equipment, routing equipment, workstations, servers, and we have to get them to speak IPv6 at one day or another. And the other point of view, of course, which is the core of this session is the registry. As a registry, AFNIC has to give and to provide registration service with IPv6 capability, and this is very important for the community and not only for AFNIC as a registry. Just one reminder. When we talk about DNS, it's very important to see it as a two-phased thing. The first phase is the database, which is the most important thing. And thanks to this database phase, we managed to get IPv6 deployed before even the DNS protocol itself got IPv6 capable. It's very important to think at this. In 1996, the first deployments of IPv6 in networks happened thanks to supporting IPv6 only in the DNS database, and fortunately we didn't have to wait until the DNS protocol itself got IPv6 transport ready to deploy IPv6. This is very important. So the second phase is quite -- it's a basic thing. DNS as a protocol, like HTTP or SMTP, is a protocol and it has to get IPv6 ready one day or another. For instance, it -- the first implementation of IPv6 ready in DNS servers got in 2000, thanks to BIND 9.0 if I'm not wrong. Maybe people can correct me if this is not correct. And so whatever phase you are seeing of the DNS, you have mainly two constraints. For the database, you have the database actually is IP transport agnostic. That means that the database will serve the same information, whatever IP version transport is used to get to that database, and the second thing is, if you consider the transport, if you get to a server over IPv4 or IPv6, you have to get -- you deserve to get exactly the same information, and actually it's a null debate. One -- two or -- I remember two or three years ago, there was a proposal at IETF just to see, hey, actually we are going to propose some simplification. If the client asking for DNS is IPv4 only, maybe the client deserves only the IPv4-related information, supposing that -- actually assuming that it doesn't that care with IPv6. And it was a very wrong idea, because it didn't suppose that there may be some middle systems which are IPv4 only or IPv6 only, and we cannot assume that the end -- actually, the top resolver is IPv4 or IPv6. So, yes, if you -- if you provide DNS service, you don't have to have any assumption about the IP version of the end user -- actually the top resolver -- which is needing this information. Just a reminder for people of you who don't know what is new with IPv6 regarding -- in regard to the DNS, actually mainly two extensions. The first one is for the forward DNS, adding a new type record which is pronounced AAAA, and the second one is for a dedicated sub-tree for the reverse delegation, and once again, if you are going to deploy today IPv6, you are really very lucky because you are not going to undergo a transition because -- between IPv6.INT and IPv6.ARPA. It was really messy to say the less. And today, actually, IPv6.INT is completely deprecated, so you start directly with I IPv6.ARPA. And just another point. Actually, five or six years ago, there was a controversy with the AAAA records, and an old -- which is experimental today -- A6 record. So you don't have to care of that today. A6 is also experimental. Maybe one day it will show up if it is useful for renumbering or anything. So just AAAA records for the forward DNS and the same PTR record and only for a dedicated service. Of course there are too many guideline documents over there on the Internet. If you just type DNS IPv6 you will find everything you need to configure and to get your nameserver up and running. It's not rocket science today. It's very, very easy to do. So to get back -- because I think mainly it's the feedback, maybe, you need from AFNIC, why actually we choose to deploy IPv6 from the beginning, why are we an early adopter. Actually, it is mainly the registry point of view. As far as we are an enterprise, we could have said, "Okay, we will wait until IPv6 is mature and we will adopt it as everybody." If it was only that point of view, we could have done that, but as a registry, we couldn't afford -- it was actually our duty to say, "Hey, we don't" -- actually, we didn't want to get in what we call the "critical path" for the IPv6 deployment. So actually today, there is a chicken-and-egg problem, saying, "Okay, users are not demanding IPv6, so it explains there's no providers giving an offer of IPv6." And, on the other hand, when you ask some ISPs, there is no demand so there is no offer. And we could have thought at another chicken-and-egg problem with DNS deployment if, for example, people who want to deploy IPv6 in their zone, DNS zone, and if the registry didn't -- hadn't provided DNS -- IPv6 support in the registration, they could have said, "Okay, actually I'm waiting for the registry to give it to me," and also we could have said, "Okay, there is no demand. People are not asking for glue registration in the DNS, full stop." And we could have been, also for a long time, in this chicken-and-egg problem. So for us, it was a priority not to get in that critical path and say, "Hey, we have done our job." Dot fr is ready for registration in the DNS, but it -- as I said at the beginning, it's just one step and I'm not actually saying that the key for deployment is only DNS. And I think we can Have some basis of evidence today IPv6 is not really very deployed. So it is a necessary condition but not sufficient at all. So this is the main point for AFNIC getting involved as early as 1998 in IPv6 deployment, just not getting in that critical path and push deployment for -- under dot fr zone. So about our experience, as I said, we -- actually, before even the foundation of AFNIC as an association, which is today in charge of dot fr. It used to be a service at INRIA, which is the French Institute for Computer Science and Control. And, yes, people at INRIA did care about IPv6 and I remember I used to be at INRIA and we were very involved in IPv6 deployment experimentation at that time and deployment step by step in France. And as soon as AFNIC was founded, it got actually involved directly with the French actors to make IPv6 deployment as early as possible. So our first -- I'm sorry. The first involvement of AFNIC was the support -- about the expertise of IPv6 in the DNS. And, of course, as an enterprise, we got connected at that time to a test bed. It was the French part of the 6bone called the G6bone. It was very, very experimental. We didn't have any production service in IPv6 all over the world. And we got, of course, to troubleshoot everything about tunnels getting down, connectivity, poor connectivity, et cetera, et cetera. And, of course, we didn't have any choice. We had to be patient. You don't have to do that today. Everything is ready. And, of course, our objective was, of course, to provide IPv6 support in our services as registries. So as soon as we got the first implementation of DNS server IPv6-capable which is, for instance, BIND9.0, we started a test bed experimenting the client server, experimenting also the database thing, having first idea about the robustness of that thing. And we got actually some unofficial secondary service just to see the transfers and, of course, we started with dual stacks and still today we are in dual stacks so we don't have any IPv6-only service. And, actually, I don't think it is a prudent thing to have IPv6-only today for many reasons. Maybe you heard about in this meeting dual stack is the most recommended today because the IPv4 base is huge and we don't want to get IPv4 just as second cities. So, yeah, IPv6 and IPv4 have to coexist for a long time and I don't think the DNS is the right candidate to give IPv6-only service. Maybe you need to do that for other services, but DNS has to be available -- the most available possible. So after that, we started integrating step by step IPv6 in our production. And, of course, as a registry, the first question which was posed is, "What to do with these glue records?" There is, let's say, foo.fr asking for delegation for ns.foo.fr and whatever other service. So, yeah, they need to put this glue in order to break this chicken-and-egg problem. And we have to handle that at the registry level. And at the beginning, actually we didn't have any tool to deal with that. The first candidates, the first customers actually we just did it manually. Okay, you need a glue. Tell me what are your servers, and actually it pushed us to support IPv6 in our zonechecking tool which at that time didn't support IPv6. So, actually, we did many things in parallel. Our information system, step by step getting towards IPv6 readiness and also the services step by step. The registration system was ready -- fully ready in 2003 and we have some release. Here you can read them. So, actually, it was a choice as still today we have some checking before delegation under dot fr. So we couldn't afford saying, "Okay, for IPv6 capability, actually we just -- we are just going to be very kind with people." So if you have IPv6, there is no checking on IPv6. It wouldn't have been a good thing to say. So we insisted at the very start of IPv6 deployment to do the same checkings. IPv4, IPv6 must, must be equally treated at your registry system. So it pushed us to implement actually from scratch our new version of zonechecking tool. By the way, it is not used only for dot fr, it is world -- it is used today all over the world. It's an Open Source. You can get it. You can download it, run it to check whatever you want as a domain name, not only under dot fr. And, yeah, we kept putting pressure on ICANN and IANA because at that time, the IPv6 glue wasn't in the root zone. So this is also you don't have to do it. If you come today -- actually, if you came after 2004, you don't have to put pressure on ICANN/IANA. I'm saying that with ICANN/IANA people. But you know that, Leo. [ Laughter ] That pressure was just to say, hey, we are a registry and actually we didn't -- we weren't the only people to be honest. There was also Japan, of course, and Korea. And we jointly put pressure to say we experimented, we deployed in production each one on its side and we can confirm to you that there is no security or stability issue with deploying IPv6 at the registry level. And we believed at that time and we said it very firmly that we didn't think there was any problem with getting our glue records for dot fr, dot jp and dot kr, for instance, in the root zone and, of course, fortunately, we got that in July 2004 and three first ccTLDs were dot jp, dot kr and dot fr. Once, of course, we kept putting pressure to put the glue records now for the root zone servers themselves and we, fortunately, got that and I'm not saying this is only thanks to the ccTLDs lobbying, not at all. It is the whole community which kept putting pressure and I think that from IANA's perspective -- and, of course, there are people that did, of course, experimentation for themselves and they had -- and they got that piece of evidence, the EURSOC, et cetera. There was a sort of unanimous thing which is IPv6 is not at all -- there is no problem issue in getting it in the root zone. If you don't care today, you don't care about support of IPv6 in the root zone. You are very lucky. You don't have to, to expand your timing in that. Once that's done, our responsibility is not just saying and waving and listen we are done, we are going to let people do it. It is very important and I would say that in the recommendations to say in touch with your community because it is important to raise awareness about other actors who are at least as involved as you in IPv6 deployment. It is not actually the end. We have to, all of us, to be more and more involved to get other things than just DNS IPv6-capable. This is my militant -- IPv6 militant. Please forgive me for that. Okay, so if you are not supporting IPv6 yet, I'm not going to criticize. But maybe it's high time for you. And, yet, you are very lucky. You have everything and, please, go for it step by step. You cannot and you don't want to get it -- there is no such IPv6 transition per se. I mean, you are not going to switch on Flag Day your IPv4-only network to an IPv6-only network. Nobody says that. So it is very important to consider in your own environment what is going to get in IPv6 and how to do it and, of course, in which timeline. And if you want to go for it as a registry, there is actually a bare minimum, which is for the community. As I said earlier, you have to support are AAAA records as glue in your registry zone. You have to publish it in your DNS zone, especially on your authoritative name servers. So as bare minimum, you are done. And actually you don't have anything to do. Almost all name server implementation today supports native IPv6 in transport and database. Of course, you have to have connectivity -- IPv6 connectivity towards your DNS servers. But this is another issue. It's not directly related with the business itself. This is, of course, to care about because you are not going to publish IPv6 on the IPv6-ready service if there is no IPv6 connectivity as transport. But the database, of course, it can publish IPv6 no problem. The DNS has the specificity to have two phases. Once again, you are lucky. And if you have done that, you are going to continue because you are also interested in getting your information system -- the whole information system IPv6 ready. You certainly have some hidden scripts, some tools in your back end, in your middleware, et cetera, which doesn't support IPv6. You have to have the sort of mission -- exploration mission to find each space of software or hardware which doesn't support IPv6. Identifying such pieces of software or hardware doesn't mean you have to do it now. It is just an exercise to know actually the amount of things, of work you have to do and, of course, to schedule it. This is very important, to know actually the state of deployment of IPv6 in your network and services. So, yeah, if you are done with WHOIS, with DNS, maybe you are interested in your own services, if you have, for example, SSH, Web, SMTP, et cetera, et cetera. And you have to do that on a service basis. You cannot do everything and there are certainly some specificities. For example, for SMTP, you have to have some more testings than Web. The Web, for example, it's almost as easy as saying, okay, I ran the server. It will detect IPv6 addresses and it will listen on and that's all. For SMTP, it is not as easy as that. So you have maybe to go more in-depth with it. And, of course, the nice-to-have is you could be attempted to set the example to show you are supportive of IPv6 and to work with the community to analyze the gaps in terms of deployment and, of course, you can do some trainings because you are going actually to acquire expertise. At least when you do that for yourself, fortunately, you are going to acquire a certain level of expertise in IPv6 deployment. So you can share that with the community. If you are involved in what we call today the multi-stakeholder approach of managing registries, so in that case you are actually in touch with registrars, with end users and you can, of course, attend, for example, conferences in the national -- on the national level and say this is the way we have done it and this is the way maybe other actors have to be involved. It is very important to give that point of view as a registry. And it may really raise awareness in your community because not everybody is interested in IPv6 and, yeah, the end user doesn't care. Actually, the end user can say what is IPv6? What does it actually bring to me that IPv4 doesn't bring? It is important to know that you are the driver and you are not going to wait until all the other actors get there by their own. So, yeah, if you are in actually good relationship with other actors, you can also put pressure very gently and kindly. It is very important to say to your partners, actually, in the community that actually they have their role to assume and they have their work, too. To explain that from your point of view, you're done. It is very important because sometimes information doesn't get very reliable. People think that maybe you are not ready and they even can say if their registry doesn't push for it, I'm not going to do it. I am still on time? Okay. So some general operational requirements and recommendations for registries. It is progressive and smooth integration. And, actually, I don't like the term "transition" even if it is very widespread today because "transition" is some idea of switching. So integrating IPv6 is very important because you are going to do it in a smooth way. So this is very important when you do it on a service basis. Actually, the DNS is going to help you publish this information that, hey, this service is now IPv6 ready and you can reach it on IPv6 transport. So there are many things you have to think about before publishing in the wild your IPv6 glue. Just an example. If you have foo.example.gov which runs three or four services and only one of them has got IPv6 ready, so are you going to add the AAAA record for the DNS entry foo.example.com. Please don't do it unless you check all the other servers are also IPv6 ready. Otherwise, actually, it is a sort of denial of service. I mean, people will try to reach your other servers on IPv6 but the service is not running on IPv6. So there are many recommendations. Of course, you can read the guidelines. For instance, in this example, you may be cautious and just add an entry for the service itself and not the equipment. This is important. This is a very well-known mistake. Sometimes when we discover that by the DNS, we can give some recommendation. Please put the AAAA record only for the service which is running and not for the whole equipment which is running other servers not supporting IPv6. And keep in mind that actually we are going to undergo and stand a long, long time coexistence between v4 and v6. Actually, it is not your fault. It is not mine. I am not going to say whose fault it is. It is just reality. In that case, actually if you are supporting DNS for your zones, please today don't put IPv6-only servers for zones because you may have an assumption that only IPv6 clients are going to ask it. So if you are considering IPv6 deployment for your DNS servers, I'm speaking about the authoritative name servers, please, please put them dual stack and don't put IPv6 only, which may be seen as zealous. And if you have -- you are managing a zone, the second recommendation is it has to be supported at least by one IPv6-speaking server. Why? Because there is out there somehow some IPv6 only clients today. This is reality. And they need to reach every DNS zone on IPv6. And this is important also. So for you as a registry or registrar, I urge you to get your zone or your zones that you manage at least on one IPv6-capable service so that you can allow IPv6-only clients out there which you don't know actually query your servers. Otherwise, actually you deny to them the server. And actually today, after the glue records of the root servers are there, published, every client is capable of querying directly the root servers in IPv6. The TLD servers which support IPv6 and IPv6 only, answer one. And if it gets to, for example, your zone as an end user, it has to also be supported by IPv6. It is the whole DNS tree, which is going and it must support IPv6, not only the root zones or the TLD zones. It is also the responsibility of the domain name holders to ask for support for their IPv6 zones. Actually, it is not the responsibility of only domain name holders. It is also, I think, the responsibility of registrars who may raise awareness at the registration service level. But, I mean, my colleague at my left maybe will say something about that in his presentation later. And there are some documents if you want to know some really operational issues you may run into if you don't have some guidelines beforehand. So to be very concrete, a typical set of steps for IPv6 deployment in your service, whatever it is, DNS or -- actually, you have to identify the services you are going to port to IPv6 and you have to put some priority, you are not going to integrate IPv6 in all of them at once so you put priority. You schedule that and you be careful of some roll-back mechanism because sometimes you can get mistakes. So if it is important to know how to go back if there is any problem with, for example, IPv6 glue for IPv6 address which has mistakenly, for example, been published in DNS or whatever, it is important to have its operation. It is as serious as IPv4. As I said, if you are going to support IPv6 in production, it is not experimentation any longer. It is very important. So you will be responsible of the view you give to your community of your seriousness in taking IPv6 into account. This is very important. Of course, you can announce that that specific service, for example, is under experimentation. It is very well-done in that case. If you announce to your community IPv6 is in production, you have to assume that -- actually, you provide the same service level, quality as IPv4. And you have to keep an eye also on your IPv6 -- new service running in IPv6. Sometimes, for example, I remember something which happened to us three years ago, if my memory serves me well. We put an official DNS server, which is c.nic.fr now, and we put it on a Linux box and actually runs BIND service and actually we found that each week it got frozen, not the name server itself but actually the kernel. And actually we discovered that there was sort of magic combination between the Linux version, kernel version, the software we were running, et cetera and it was related to fragmentation. And each time your service is down, you have a monitoring saying, hey, your service is down or yourself, of course, you discovered. And it may be really embarrassing for you. It is important and it happens, of course, even for a registry. It is, of course -- the things we had to do and, of course, we upgraded everything and also it is very important to share that with the community because sometimes the community discovered that at the same time as you and help you to find a patch or whatever, new release of that. It is very important to share that. So yeah you have to keep an eye on your so-called IPv6 production service. And also, as you are serious, you are going to document your service. So it is newly a fresh service in IPv6. You have to document it internally and also you have to communicate with your partners. If you are a registry, maybe you need to say to registrars and the end users, "now from now on, we are supporting IPv6 on that server, those servers, et cetera." So also, if people get in trouble, they know they can explain that to themselves and also go back to you and say, "Hey, since you have -- since you put IPv6 in production on that server, the service, actually I'm getting in trouble." And it helps you as actually an actor deploying IPv6 also to know what people perceive from your service. It's very, very important. You cannot claim just it's in production without having any feedback. And you have to troubleshoot things when it gets wrong, and also you have to assume that things may get wrong even on your side. Share your experience with other people. Of course at the first level, your partners, and if you are a registry, actually you are in touch with the whole community, and giving some press release and saying -- or forums or whatever channel you use for communication, it's very important to share it. So actually, you can get benefit of it, because people get to you and give you some feedback which may help you accelerate troubleshooting at fixing any potential problem. It's very important. And as I said, you can, yourself, get in problem with IPv6 production and I mentioned one example. One other very famous problem is actually we can say that as a registry, it's out of our scope, but it is actually getting us in trouble. This famous MTU problem -- because there are all -- not all IPv6 networks today are native, so there are some tunnels out there, and not all people are aware of where tunnels are in that network. So sometimes you can get some denial of service for IPv6 clients who want to access your server, but somewhere they are stuck, and this is very -- as I said, it's a famous problem and maybe I will just give some details about it. When you are actually dealing with TCP -- for instance, let's say you are getting to some Web page on an IPv6 registry server, so the first time, as it is in TCP, the first handshake is just a few bytes so it gets TCP connection is up and running. But suppose you put the "get" command for the Web page, and the Web page, for example, is -- exceeds, let's say, your MTU, the -- some MTU, the path MTU and the server tries to send you the page. But actually the packet is stuck somewhere because there are some routers filtering a certain ICMP with a too-large error and if you don't get that error, you are stuck and you are actually hanging on until some time out and getting maybe two or three minutes later the page in IPv4. So it's perceived as a service degradation, and the whole service -- I mean, from the end user point of view, he doesn't care whether it is the registry or the network operators between them. For him, actually he can say, "Okay, IPv6 sucks. I'm going to turn it off because actually I don't get the same service quality as in IPv4." And it's really very sad and this is reality. And maybe for people who are using IPv6 in this meeting, maybe they have run into that problem once. I mean, you can get, for example, to some Web servers in IPv6 just to get the TCP connection down, and afterwards you are stuck and sometimes you have to wait for a long time to get the IPv4 fallback. This is a real problem, and I mean I'm not getting you afraid of IPv6. Of course not. Please don't understand that. But just to say if you are going to do it, please have in mind that you may run into some problem, and today those types of problems, issues, are dealt with even in documentation, so you are very happy to find that you have -- to find even the way to sometimes make some work-arounds or even get the best solution. And, yes, what we also have had at the time, in some acquisition of equipment or software, actually we had to struggle with providers who say, "Okay, actually I support IPv6, so if you want it, I get it." "Oh, hold on. What functionality you are supporting?" And you discover after that they actually poorly support IPv6. So, yes, at that time we didn't have enough software and hardware pieces to integrate them. Today, you have many more, but you may actually accept some short-term trade-offs, because you need to see that in the long term. So if you are getting to IPv6 today, please consider your whole investment in equipment and software. Don't say, "Okay, there is nothing in IPv6, for example, so I'm going to IPv4." Maybe you have to struggle for getting IPv6. Maybe you have to pay some extra money today to have more sustainable solution. This is important also to have -- to make some trade-offs, not based on your six-month, for example, short term but on a much longer term. So as a conclusion, IPv6 is really ready today on the standards perspective and also in the availability of products, as long as -- as far as you -- as registries and registrars are concerned. Everything is there. Believe me, everything is there. So I don't think today that there is such a pretext from the registries, and even the registrars' point of view, and I'm maybe getting some enemies on my left from the registrars or registries. I don't believe there's any pretext today to say, "Actually, I'm going to wait for IPv6." There may be some pretext arguments in other fields of deployment, but I don't think -- I don't believe today that you may postpone IPv6 deployment in your network as a registry or registrar because everything is there and actually I don't think you are waiting for anybody except maybe your IPv6 connectivity, if you don't have, but I believe today there are many people who you may get in touch with and offer you even an interim thing. So the work-around, even for that, is available today. And if you are interested in some documentation about what is available in software, everything is there. So you can try one of them, if you don't have, and if you have some, you can just get the latest version and IPv6 is there. Actually, IPv6 has been there for years now. Since 2000 you have software supporting IPv6. And that's all for the moment. If you have any questions or maybe there will be the presentation and questions afterwards. I don't know. >>LEO VEGODA: I think it would be quite nice to invite some questions now before the next presentation, so if anyone has any questions that they -- or comments they'd like to make, then please feel free. We've got a mic. If when you speak, you could say your name slowly, just so that our stenographers and translators can get that. Thank you. >>BLAISE THAUVIN: Hi. So I'm Blaise Thauvin. I'm just worried about the spelling. T-h-a-u-v-i-n. That's fine. I'm a CTO at MM, a French hosting company. Since December this year, I think, we're the second largest ISP in France that started offering IPv6 to all its customers as standard in its ADSL box. Have you seen an increase in IPv6 acceptance in France, s'il vois plait? >>MOHSEN SOUISSI: Actually, I'm going to straightly answer yes. The long answer is: Actually, I was very curious to know the new view of dot fr zone, because for years, the IPv6 -- let's say it in another way. We cannot have the complete view of IPv6 penetration, either in France or in other part of the world. We have only a view on what we can see through the DNS, so if I get to FR zone today, I get to the delegations, and I ask which NSs in the delegation have some AAAA records, whether we are glue in FR zone or published elsewhere, I can see here there are many progressively -- especially for three getting IPv6 deployment, there are more and more IPv6 addresses from within that address space, yes. And it's not only -- to be fair, you have also the competition which is from OVH, who has some dedicated servers called (non-English word or phrase). "It's enough for me," in translation in English. And, yes, I saw that many, many DNS zones are delegated on some dedicated servers who, yes, for instance, support IPv6 and, yes, it's very -- I was very glad to discover that through FR zone. I don't have details, statistics today. Maybe you are going to talk about statistics later, but the answer is yes, yes. >>LEO VEGODA: There's a lady over there. If we could share the microphone around. >>ROSA DELGADO: Yes. My name is Rosa Delgado from Wisekey Company in Geneva. I'd be interested to know about the customer base. You mentioned all your clients, and who are your clients, how many clients you have since you started, and, you know, what kind of client you have: Governments, academic institutions, private sector. Especially in private sector, I would be interested. Thank you. >>MOHSEN SOUISSI: Very interesting question. For registries, actually their main clients generally are the registrars. So in France, we have almost 1,000 registrars in very different sizes, and among them, of course, there is the private sector and the public sector, and among the public sector -- actually, for example, the leader in IPv6 deployment is Renater, which is the French network for research and education, so actually Renater has been supporting IPv6 in the DNS as the beginning -- actually, it was the first tester of -- the first glue records we took into account manually were in Renater. But of course there are others who do support IPv6 today in their registration system. Just to give also some detail on that, the registrar may support IPv6 in their specific network, but sometimes they don't support AAAA records glue registration with AFNIC or dot fr. Let me state it in another way. For our registration system today, which is actually going to evolve in the next months, we get registrations by e-mail forms, whether it is directly with e-mail or through a Web form, and in the template, there is room -- there has been room for IPv6 glue since 2001, if my memory serves me well, and not all registrars have depicted that -- actually have transferred that in their own registration system, because the end user actually doesn't get directly to AFNIC. He has to go through a registrar. So actually, typically the end user goes through a Web form of a registrar and unfortunately not all registrars make it possible for end users to state the glue record. So actually, there is, I think, a lack of support of end-to-end support. From our point of view, the glue is supported, but it's not actually propagated up to or down to the end user. Does that answer your question? >>LEO VEGODA: I think that's a great segue to our next speaker, Jean-Claude. So Jean-Claude, do you want to use your laptop or mine? Okay. Lovely. If I could... >>JEAN-CLAUDE MICHOT: So I will start by a quick context about the experience of IPv6. Mainly registrar experience. BookMyName registrar is a subsidiary company of a French ISP called FREE. We are more than 3 million end users, ADSL end user, and since December 2007, around 80% of this 3 million user are able to use IPv6. I just say "able to use" because hopefully they are not all using IPv6. I'll start by important things in -- when we speak of IPv6. The first things to remember is the market is driven by customer demand and not by technology. Technology is just the tools and not a goal. So actually, except from big user or IPv6 militant, there is no end user request for IPv6. We could ask the question why. During the last three days, in the second meeting, I've read lots of things about IPv6 and some of them are not true in France. There is no demand because there is no offer. That's not true in France. So the next step is why there is no demand. There is no demand because there is no service and no content for IPv6. No IPv6-specific demand -- service, sorry -- and content. The good news is actually there is more and more hosting services providing IPv6, and I think in the next year there is really more content available for really end customer on IPv6. Okay. So as a registrar, we need to use -- provide capability for user to register a glue record. What is a glue record? A glue record is an IP address of nameserver in its domain registry. Lots of registrars say that they support IPv6 AAAA records for customer zone service, but only a very small number support IPv6 glue. The list is at this URL. Actually there is more than 1,000 ICANN accredited registrars and only a very small number supporting IPv6 glue records. So maybe you can ask the question why there are so few registrars supporting glue record, and the reply is probably in my first sheet. It's between market and demand. So we just note that all registries does not support glue record. That does not help full implementation of IPv6 glue. About the registrar implementation. BookMyName is a fully in-house software, so we are adding IPv6 glue support really quickly, and only a few changes has to be done: Database update to increase fields size; web interface increase, and a few ICANN software. There is no more than 2 days of work for analyze code and test registries. So the question is why only a very small number of registrars support IPv6? So it's really not a technical problem but a market problem. As a stock-exchange listed company, I can provide lots of figures on your customer database, so I just extract one data. Actually, since December 2007, we have one IPv6 glue for 500 IPv4 recorded in the customer database, so it's a very small number, but that's a beginning. That's all. >>LEO VEGODA: Thank you very much, Jean-Claude. It's a small start, but you've got the effort into updating your software to provide support for IPv6 glue. Can I ask you: Was that a regular software upgrade that you were going to do anyway and you put IPv6 into that software upgrade that added other features that you were planning for anyway? >>JEAN-CLAUDE MICHOT: You speak about service directly from glue records, so the service approach is really the difference. I think in the next two months we will provide IPv6 service for all the registrar services in your database, in your service, but actually we are just focused on glue record, so maybe as doctor say, smoking doctor say, "Don't smoke, do what I say but not what I do." [Laughter] >>LEO VEGODA: Okay. Well, thank you. Thank you very much. Does anyone else in the room have any questions for Jean-Claude? Let me come over to you with the microphone. >>GUY De TERAMOND: Thank you. De Teramond from CR domain. Jean-Claude, all your clients are ADSL clients? >>JEAN-CLAUDE MICHOT: Yeah, FTTH on ADSL. >>GUY De TERAMOND: Okay. Then we can have a bias somehow because ADSL clients are typically very different from fiber connected clients that -- for example, universities and the like where typically there is much more R&D, so I would expect that ADSL clients would be the last to go to IPv6, so it's difficult to judge from, you know, an ADSL basis somehow. >>JEAN-CLAUDE MICHOT: Yeah. In France, we're known as a geeks customer database, so a lot of your geeks customers are technology addicts. I'm really sure that there is really no difference on your customer from ADSL on FTTH. >>GUY De TERAMOND: Yeah. But probably you don't have research programs at computer centers and the like, which are typically where you have more demand at this point for IPv6 because of research and several things. >>MOHSEN SOUISSI: Let me please add a word about that. I don't think there is any research in that. If it is viewed from the DNS point of view, and as Jean-Claude said, I mean, if their customers have, for example, in their DNS zones hosted at -- on their computers at home, I don't see any research and development that the DNS has been working fine, ADSL has been working fine for years, so I'm not sure -- this is really the point about DNS -- IPv6 penetration in the DNS industry, and I think it's the core question. Maybe I am wrong, but maybe -- >>LEO VEGODA: Let me come over with the microphone. And if I could ask you to state your name clearly so that it can go in the transcript. >> Okay. I am (saying name). I would ask a question related to the service which you offer to your customers, which is based on ADSL. Have you introduced IPv6 connectivity on your infrastructure so your clients are about this IPv6 service and can ask for register, for example, BookMyName related to their, I think, their name. Is it what you have done? >>JEAN-CLAUDE MICHOT: Naturally, I can't speak from FREE. I can just explain also FREE. But I can speak about registrar. And the choice to deploy IPv6 at registrar level was originally launched by of course the FREE choice to provider, end user, customer, IPv6 service. >> So concerning what you have said about the demand and the offer, so I think you are at the right place to see if we -- if you can introduce more IPv6 service for your users. >>JEAN-CLAUDE MICHOT: Sure. And we are doing -- no later than yesterday, your FTP service was up on IPv6. >>FRANCK MARTIN: Thanks. Franck Martin. Yeah. Nearly there. You said that there's one part which is the demand of IPv6 registration, but what about DNS queries? Have you seen a growth in IPv6 queries to your registrar/registries -- >>JEAN-CLAUDE MICHOT: No -- >>FRANK MARTIN: -- and since the beginning of the year, because that's when the root glue just happened. Have you seen this growth? >>JEAN-CLAUDE MICHOT: No, we don't see really significant change. >>LEO VEGODA: We have another question back here. >>THEO KRAMER: Theo Kramer, CO.ZA. Not really a question, just a come comment. We adapted our systems for IPv6 to take IPv6 glue registrations about six months ago. We also adapted our systems so that we could eat our own dog food essentially. We are IPv6 visible. We announced this to the various registrars, and up to now we have had no registrations for IPv6 registration. Just a comment. >>JEAN-CLAUDE MICHOT: As I said at the beginning, we have very few IPv6 registrations. >>THEO KRAMER: Just to add to that comment, I think it is important for the registries to be ready for it so when it does come, we don't hit a roadblock. >>LEO VEGODA: Okay. I think this is a good point to hand over to Michele. So while Michele is plugging in, Michele is from LACNIC solutions and island and black knight, all IPv6 steps and offer IPv6 registration and hosting services. >>MICHELE NEYLON: Is this thing working? Hello? Okay. Right. As Leo -- is this thing on? Is it on or off? It is on, okay. As Leo was saying, we are a hosting company primarily. You have to excuse me, I have had a throat problem. We decided to put out IPv6 on our network for a number of reasons. One thing, of course, is it is inevitable that the number of IPv4 addresses is going to dry up so our philosophy was very simply the case of well, we're going to have to do it at some point, let's do it now. We can do it now when we have the time, when we have the choice, we can take our time. We can do it properly until we -- so that we don't end up in a situation where we're running around chasing our own tail. Another thing which from my perspective was attractive was the idea that if we were to deploy IPv6, then we were going to be doing something that other people weren't doing. And as the demand increased, then hopefully people would come to us for services that they couldn't get elsewhere. So if somebody wanted to experiment with IPv6, they could come to a company such as ourselves. I'm sure some of you can appreciate the logic behind this. And there goes my laptop again. Sorry. We had a certain amount of customer demand as well as we've been one of those companies that has always maintained a certain number of hard core geek users. So a certain number of these people are coming to us saying, look, we are getting a bit tired of tunnels. We want to do funkier stuff using IPv6, can you guys help us? So we looked at it. Because of the nature of this, we have also got a lot of very technical people working for us, and they all thought this IPv6 thing was really, really cool and they wanted to play around with it. So 3:00 in the morning, they break my network completely because they try to test out IPv6 but we couldn't do it properly. So it was kind of a progression, as it were. If anybody has any difficulty understanding me, please let me know. Some people have problems with my wonderful accent. Anyway, so our first attempt we were not a RIPE member at the time. We were using a data center's network and they were giving us the bandwidth, so we went to them and said "okay, look, we want IPv6, what can you do?" They are like, IPV what? Okay, that conversation went really, really well. So we thought, okay, we'll try the CGO. Same conversation. IPV what? We kind of went, okay, move on. We played around with a bit of other stuff and then got ourselves organized with RIPE. So we got our RIPE membership. RIPE gave us an IPv6 allocation. So next little problem we had was, okay, we have these IPv6 addresses, what about the upstream. So we go to some of the upstream providers and say, hey, we want IPv6 connectivity and they go, IPV what? And so on. So it was -- it was a bit interesting to say the least. So my CTO was speaking to some of the bandwidth providers. We are looking at other options. We are talking to pierce in the industry. Eventually we got to a point where we had managed to provide upstream providers who had a bit of a clue and knew what IPv6 was. And so we started getting that sorted out. So at this point now, we're getting IPv6 across a number -- from a number of our upstream providers and we're also peering at the Internet neutral exchange in Dublin with several of the other ISPs over IPv6. But, of course, it's still kind of a funny situation where a lot of these bigger companies, they played around with it maybe two years ago. The one employee they had on their staff who understood us, he's moved on. Boom, no more IPv6. Or maybe they have the IPv6 up and working for three, four months, somebody moves on, it breaks, nobody gets around to fixing it. So it is still a bit of a battle, let's just say. It's been interesting hearing the other speakers talking about it from a registry perspective and from a pure registrar perspective and DSL and all this because we ran into very similar issues. At the moment, we're able to offer certain services over IPv6, no problem. Certain things, it requires slaughtering of small animals, dancing and all this kind of thing to get it to work but you can make it happen. But the problem -- one of the problems we ran into was with DNS. At the moment it is good practice to have DNS separated, to have DNS servers in different countries, et cetera, et cetera. So we're looking at deploying IPv6 across the name servers. Problem. The upstream providers in the various countries we're in, they don't have those. So we go to them and we ask them, can you give us IPv6? And they are all just shaking their heads. So it is another interesting little issue that we've run into. If anybody thought I was going to give a wonderful hey "IPv6 is working beautifully for us," terribly sorry. Let's see if I can get this to move on to the next screen. Right. So IPv6 address space, our next problem was putting it out on the network. So the hardware was something that we ran into. Finding compatible hardware, yeah, sure, you can do it but you have to sit down and look at it very, very carefully. We are -- we had to replace quite a bit of our network equipment, like everybody does. So we -- but we ran into a few interesting issues: The Juniper routers, for example, no problem, give them IPv4, give them IPv6, boom, works great. Cisco switches we were using, no problem. Then when we started looking at the firewalls, we ran into an issue. The Fortinet firewalls we were using only supported IPv6 from a command-line interface. The impact on that is, that means that with my technical staff, only the hard-core geek, more senior technical staff who are happy with a command-line interface are able to interact with the system. So I can't get one of my more junior technical staff who might be more comfortable with a Web front end, I can't get them to do the stuff because the Web front end doesn't support it. Then, of course, you have the charming issue of the hardware vendor who promises you support but hasn't really got the experience on a live deployment, I suppose. We ran into this issue with the Ciscos. We were raising Cisco ASA firewalls and we discovered much to our delight, let's just say, that things like stateful failover just doesn't work. The firewall will quite happily pass the traffic but when you try to get it to do certain things, it falls flat on its face. It doesn't know what to do. From a security point of view, it means that you have to double up as well because if you've got a whole load of rules for your IPv4 network, you have to implement them for your IPv6 as well. It makes it a little bit more interesting. The other thing, of course, was getting usage out there both for our own stuff and for that of our clients. We do share hosting, dedicated servers and co-location as well as domains. So in some cases, we were working with clients and saying, look, this is available if they're interested in doing stuff. Here, it's possible. So kind of simple little things we discovered. Okay, Apache 2-point whatever, perfect, no problem, full IPv6 was available. But Apache 1.3, not really supported. I've heard rumors that you can get it to work but it's incredibly awkward. The problem we had was if I've got 50 or 60 servers that are live and working and there's nothing wrong with them, do I take the risk of potentially breaking them by upgrading from Apache 1 to Apache 2? Sure, I get the IPv6 but at what price? With the -- on the mail side of things, we didn't run into any issues. The more recent versions of the mail software had full IPv6 support so it was just a matter of configuring the servers to listen on it for IPv6. It wasn't really an issue. As has already been mentioned, there is no issues with DNS. The BIND and other software supports it fully, so it is not really a problem. The thing we've had a problem with, and something we've been working on, is the customer-facing part of that. Our clients can have AAAA records -- obviously they need them -- but the customer-facing part of that has to be completely reworked. At the moment, we have to do it manually for them. We've been working behind the scenes, but unfortunately my technical staff have been a bit -- you know, they get tied up with other things so the development cycle is a bit longer than we'd like. Since we don't have a million programmers working for us, we rely on third-party vendors. And unfortunately we've run into -- into a bit of a brick wall with them. While they may have all heard about this IPv6 thing, none of them seem to have done anything about making it available. So one of the things we've run into is in certain areas, the hosting control panel side of things, none of them seem to have done anything to make it compatible. So what at the DNS level we can create the AAAA records so that the IPv6 is there, you can't get stuff to work so that the server con figs are updated which is a bit of a problem. Sorry, I don't do long presentations with lots of slides. So our current status is a bit of odd. The network is fully IPv6 working and capable. It is up and running. We have the upstream problem sorted out. The switches are all working. The firewall things are all working. On the firewall type some things are working perfectly, other things, of course, unfortunately aren't. In terms of the customer demand side of things, we're seeing people playing around with things but the demand isn't exactly huge. So let's pretty much our experience on this to date. So if anybody has any questions, feel free. >>LEO VEGODA: I think if I could start off by asking if any of the panelists have any questions. Raúl? >>RAÚL ECHEBERRÍA: Very interesting presentation. Congratulations to all the speakers. When I spoke before, I forgot to mention that organizations like LACNIC is fully IPv6. As you said, we provide all our services over IPv6 and we have been doing that for a long time. So it is difficult to understand how the registration of domain could be an obstacle for something after spending huge efforts inputting everything on our level at IPv6, having problems with registration of the glue record is something that is difficult to understand. So I have two questions, one for the people involved with the registrar activities. How difficult is it to implement that -- to make the changes in the system to accept these kind of things? I am not speaking about connectivity because you can do that over IPv4. It is just the route of the information. I'm not involved in software development, but it seems something very easy to do for people that is not involved in that. The second question is for you, Leo. From the perspective of Internet user, this is not that the registrar should do, this should not be part of the service that the registrar offered to the community? ICANN is not involved with these kind of things, the supervision, oversight of the things that the registrars should offer to the community? >>LEO VEGODA: Maybe if we could go with the first question first, which is how difficult is it to update the registry and registrar software to insert an AAAA glue record into the respective databases? >>JEAN-CLAUDE MICHOT: From registrar point of view, there is no problem. There is just a little work at glue support for AAAA. As I say, it is two days' work, no more. It is many registrar does not do this work because there is no demand. >>MICHELE NEYLON: It depends on the software you are using as well, of course. For example, if somebody asks -- if somebody asked us for glue records for a COUK domain about a month and half ago, they want IPv4 and IPv6. Fine. We had a Web interface pop it in and got back an error message back. We are scratching our heads going what the hell happened? It is one of those scenarios, we never tested a particular scenario where we are putting in so many data into the little form on the screen so the guy who had written it had been a bit clever and was interpreting anything over a certain length to be a line break. So it was breaking it in two. It took us about 20 minutes to get it fixed, but it was a silly little thing. Until you try it out, you don't get to see the problem. >>LEO VEGODA: Okay. So going on to question two, is there something that all registrars should be doing? We would like to encourage registrars and registries to provide IPv6 support, at least at a minimum for the registration of glue. Providing more support is better and less support is not as good, obviously. The first part of that is talking with the registries and registrars in the communities. So to that effect, we've been talking through meetings that we have. For instance, there's a north American registrars community meeting in April and as IANA, we went along to go and say this is something we would like you to do. Similarly, this workshop here today is to hopefully encourage those registries that haven't implemented, at least, minimal support for IPv6 and the registrars to go away and say, "oh, maybe it is not so difficult to at least put in minimal support so the glue registration is possible." And that is something that we would definitely like to encourage so that registration of DNS glue does not become an obstacle in the critical path of IPv6 deployment in the networks of those organizations that want to deploy IPv6. So what we want to do is we want to start by making sure that there is a when there is need. I think that's the appropriate first step for us. Back to you, Raúl. >>MOHSEN SOUISSI: I would just like to add a point about the whole registration process. Actually, the registrars have sometimes double responsibility. Of course, the first one is to take into account this glue record. As in the DNS industry, not everybody is familiar with the editing some zone file, et cetera, et cetera. There are many interfaces for the user, for example, for populating their zones. I mean, when you have a DNS host professional, a DNS professional, generally they can provide you with an interface to fill in your zone. Say, for example, my Web server is at this address. Many of those interfaces don't take IPv6 records into account. I mean, they have -- this sort of appliance has a restricted set of the type of records. And many of them haven't even taken into account these records. So it is also important because the glue is only used for the delegation. But people who want to populate their own zones as end users, they need also these type of records be supported by the interface provided by their provider. It is important also to mention this lack of support in these sort of interfaces. >>LEO VEGODA: Thank you very much. I think we've got some time now for an open discussion with participation from the panel and everyone else in the room. So I'm going to grab the microphone and wander around the room. If you are interested in making a comment or asking a question, please pop your hand up. And, also, if you want to make a comment in a language other than English, we've got translation services and you can speak in French or Spanish and it will be translated so people can hear the question in English, French or Spanish through their headset. So any questions? Or have we covered this -- >> Excuse me. Yes, I have -- yeah, my name is (saying name). When you mentioned that -- we know that the United States in the plan of migration to IPv6, you know, the government and state agencies, so it is a really big plan of migration right now. What happened with the registrars and registries in the Asia region, do they have, you know, already migrated? Because we know that Japan and other countries, China, they're really this that process as well. Are they already IPv6? Is there any news on that, please? Anybody from the Asia region? >>LEO VEGODA: If there is anyone from the Asian region who can speak to that, I can bring you a microphone. >> WENDY ZHAO: Hello. I'm Wendy from CNNIC, actually the dot cn registry. I'm actually in the IP allocation, so I might give you a little bit of information, experience of IPv6 in China. As everybody knows, the CNGI project which has successfully closed, partly closed probably last week, what they do is they have put IPv6 support into the backbone router, which we can see we are totally ready for the operator project. We are totally ready for that. But probably people know IPv6 in China will be more, we will find out that. There is not much demand, as the gentleman from islands said. That is because it is actually the egg-and-chicken issues. There is no demand from the end user or the smaller ISPs to the bigger upstream or operators. So the operator finds out there is no reason to actually though -- even though they support IPv6 in their backbone router, there is no point to open that to the -- to the ISPs. Probably just pull them up to the table because that will cause -- apparently costs a lot of money. So, currently, the situation in China is including CNIA and other organizations which relied in IPv6 really rush. And we have reporting to our government or organization, which actually controls or measures these kind of issues is the Ministry of the Industry and Information. What we do is we'll say the IPv6 will need to be on the table because apparently everybody knows IPv4 is not going that long, probably two, three, four years. No one knows how long that will be lost. But we have been talking about the IPv6 issue to all the enders, the operators at ALAC. I was in there for a certain time. But everybody shared the same experience, saying we have no fully successful example to let everybody copy or learn from because no one say, hey, in my country, we are fully successful of the IPv6 deployment from the commercial perspective. And no one say, I'm very successful from the governmental perspective because we are working on that. But I think in Asia, we are trying working on both ways. One way is trying to let government to realize they need to put attention and more effort to deploy IPv6, at least at current time, the operator won't see the profit from it. And then that's why the government should take the leader position. From the other side is we are trying to let the operators to realize, even right now they don't have the profit from IPv6. But if they don't, like the gentlemen say, we are not rushing to it because there's not lots of demand. But we're not starting doing that, we will probably pay more so that will take you even long time to get profit it if everything is on demand but you are not ready for that. So that's a little bit experience or situation from a China perspective. Hopefully that will help someone to know a little bit more about IPv6 deployment in China. Thank you. >>LEO VEGODA: Thank you. Would anyone like to respond to that comment or ask a question? Have we -- >> LORENS KOCKUM: I am not sure I am to respond to that question. My name is Lorens. I won't even try to spell in my family name. I would like to ask you -- because I haven't been able to find the answer on the Internet in the one minute of searching. What are the legal address ranges in IPv6 for registering glue name servers? >>MICHELE NEYLON: The legal? >> LORENS KOCKUM: Yeah, the legal address changes. Today, you wouldn't register a name server with 192.168. >>MICHELE NEYLON: Oh, I see what you mean. Sorry. Which IP ranges are not reserved, basically? >> LORENS KOCKUM: Yeah. >>MICHELE NEYLON: You're probably better at answering that than me. >>MOHSEN SOUISSI: It really depends on whether you check or not at the syntactical level or even the meaning of it. For example, dot fr we have zone check which is -- actually says, okay, you are telling me to support IPv6, prove it. So if you give me any -- whether it is in valid range or not, we are going to try to connect in IPv6 transport to that server and say, okay, you are not supporting it. So this is, for example, for the dot fr point of view. And, actually, if you want to check that, there is the very basic verification which is verification of valid IPv6 address which is eight words separated by colon. Otherwise, it may be dangerous to decide to hard code some meaning of valid address because as allocations go further, some reserved space today may be unreserved and you may get -- run into trouble with that. So I think the thing which is valid today is just syntactic and you cannot really tie it to specific policy of today, otherwise you may run later in some problems. So maybe it is not legal but some valid in syntactic level. But if you want to check, you may even ask those servers and get answer. Otherwise, you would say this is not serious. This is my point of view. >> LORENS KOCKUM: I was thinking along the lines of not checking that the server does respond because that's one problem. >>MOHSEN SOUISSI: But it is the same problem -- >> LORENS KOCKUM: Not authorizing, colon colon 1. >>MOHSEN SOUISSI: It is exactly the same problem as authorizing 117.001. Are you checking that? >> LORENS KOCKUM: Yes. >>MOHSEN SOUISSI: So check the double colon one in that case. >> LORENS KOCKUM: Yes. I was looking for lists. >>MOHSEN SOUISSI: Oh, in that case you may need to go some RFC which talks about some specific ranges like, let's say, Net 10 for IPv4 and for IPv6, you have many ranges. Let's say, for example, FC::/7. And you may find this list -- there is a draft in DNS today about the local zones. It is Mark Andrews who has this rough draft, and you can find the comprehensive list of those local -- what you call local prefixes. That may help you. >>MICHELE NEYLON: If you look on IANA Web sites, you will find lists of which of the blocks are reserved. I just brought that up just now doing a quick Google. IANA.org/assignments/IPv6 address -- you will find it there. There is a full breakdown for the different reserve spaces, if that's what you're talking about. >>LEO VEGODA: If I could add to that. Leo Vegoda from IANA. As well, we've got a number of IPv6 registries because IPv6 being a bigger address space is more structured than the IPv4 address space. As well as the registry that has just been mentioned, there is a registry of unicast assignments which is the allocations to the RIRs. And there is an IANA special registry which is where things like Torado (phonetic) which is the addresses reserved for a kind of tunneling are registered. Basically, you can go and look through our Web site for that. And all of those registries will be made available in XML format so make them easily computer-passible in the next couple of months, but as well as that, there is an RFC that is written by Mark Blanchet from Viagénie which is the equivalent of RFC330, which is the RFC for IPv4, which defines special-use addresses. Now, I can't remember the number of that RFC right now, but I will do is I will put a link to it on the page for this meeting, so that you can grab that later on. I don't know if anyone wants to go through -- ah. We've got a question from Theo. >> No. Just a comment in terms of our policies. What we -- and this is for the CO.ZA registry. When we receive a glue, an IPv6 glue registration, what we do is we check that the IPv6 is just syntactically correct, and then what we do is we query -- we put out an IPv6 query, and we determine that it is, indeed, correct in terms of the domain names and the nameservers, so we -- we've had to make sure that our policies on IPv4 are the same as our policies on IPv6. That's the approach that we've taken. >>LEO VEGODA: That sounds great. So are there any more comments or questions on this topic or any other? >>MOHSEN SOUISSI: RFC5156. >>LEO VEGODA: Lovely. [Laughter] >>LEO VEGODA: It likes like we may have reached a natural end to this session, so -- oh. >>BARBARA ROSEMAN: Hi. I'm Barbara Roseman. I'm the general manager for IANA. I'd like to thank you all for coming today. This is a really good turn-out for a session that we weren't sure was going to be a big draw. Our intent in organizing this session was to sort of bring the operational elements of v6 into the ICANN community, right? You know, it's been talked about in a lot of the operations groups around the international community, and the RIRs clearly have been dealing with this issue for quite some time, but, you know, now it's becoming a reality and we need to make sure that the DNS will support it end to end, and that means getting registrars, registries. You know, we've got it at the root now. The idea is that v6 should be as functional as v4 for any of our services. And I think that the turn-out today has been really good evidence that this is recognized within ICANN, so thank you all for coming. [Applause] >>LEO VEGODA: Thank you. Thank you all for coming. I'd also like to thank our panel, Raúl, Michele, Mohsen and Jean-Claude, and I'd like to thank our stenographers and translators for their work today. We very much appreciate it. We've finished early, which means there's more time for you to drink coffee and enjoy the really great patisserie that we've had out this week. Thank you.