______________________________________________________________________ DRAFT TRANSCRIPT IPv6 technical SIG Wednesday 1 March 2006 11.00am ______________________________________________________________________ KAZU YAMAMOTO: Good morning, everybody. It's 11 o'clock. This session is IPv6 Technical SIG. Thank you for coming. Well, let's get started. Firs of all, we should review action items. We have no action items, OK? So let's go down to presentations. Today, we have seven informational presentations, like this (refers to slide), and each presenter will come here and make a presentation. Before that, we should take notes. Please use microphone if you ask questions, because this session is broadcasted to the Internet. So you should use microphone please. OK? Let me call first speaker. First speaker is Arth Paulite, APNIC. He's going to make a presentation on IPv6 update. ARTH PAULITE: Good morning, everybody. My name is Arth from APNIC and I'll present about IPv6 allocation status update. The contents of this presentation are purely statistics about RIRs' allocations from IANA, RIRs' allocations to LIRs or ISPs, APNIC allocations and assignments details, member assignments registrations in the database and a snapshot of global IPv6 routing table. These are the current RIR allocations, the number of /23s. RIPE NCC has 198. APNIC has 65, ARIN has 12, LACNIC has two and AfriNIC has one allocation. And these are the RIR allocations to LIRs and ISPs. So far, APNIC has 237, RIPE NCC has 532, AfriNIC has 13, LACNIC has 54. And allocations of APNIC by economies - Japan has 90 allocations, followed by Korea, 35, Taiwan, 24, China 17, Australia 13 and the rest of the countries are catching up. And this is the annual allocations. For 2006, we have about six allocations as of January and, as you know, from 2002, we have a big jump. This is because of the minimum allocations of /32 has been introduced and then the /35-holders were allowed to get an upgrade of /32 without further documentations. And allocations by sizes so, since APNIC is a /32, you'll notice the big allocations are a /32. We have 217 and so far we still have four out of six /35s. They haven't upgraded it yet and two of them has been returned. And we have three /20s and we have /21, /22 and up to a /30. IX assignments - previously we are assigning /64s so, four of these are /4s and the rest are /48. We have six from Australia, three from Japan, Korea two, Indonesia two and the rest have one assignment. And these are the critical assignments, mostly for top-level domain-operators for country, NIRs, and I think it looks at the root server as well. So Japan has four assignments, Australia has two, Korea has two and the others have one assignment. And these are the assignments registered in the database. So mostly /48s and it's interesting to see that there are 3,000 /40s registered and it's actually from one organisation. They're registering mostly their infrastructure by /40s. This is the snapshot of IPv6 routing table as of January 2006 so it's mostly /32 and the /16 here is the 6to4 and there's one organisation that has a /19 and there's also one organisation announcing /64. OK. If you are interested with which IP block or IPv6 has been assigned to which RIRs, you can check the IANA website and also APNIC has statistics about the AS number assignments, IPv4 and IPv6 assignments allocation as well. So you can check the link. Are there any questions? KAZU YAMAMOTO: Arth, I have one. You know, APNIC repeatedly ask to the people to register, you know, assignments to whois database, so does it - is it increasing or - you showed just number but I don't know if this number is increasing or not. ARTH PAULITE: Yeah, it's actually increasing because, last year, the /40s is around 1,000. KAZU YAMAMOTO: Oh, really? ARTH PAULITE: Yeah, yeah, it's increasing. KAZU YAMAMOTO: Any questions? OK. Thank you very much. ARTH PAULITE: Thank you. KAZU YAMAMOTO: OK, second speaker is Sanjaya, APNIC. He will make a presentation now - ip6.int deprecation project report. SANJAYA: Right, this is a project update of a proposal that got approved in the last APNIC meeting. The proposal was presented in the DNS Operations SIG and got approved. So this is just an update on what's the progress of the implementation of that proposal. This is the overview. I'll start with the background and then just a reminder of what the proposal is and the project status and then the questions and answers. Right, the background of this proposal is because the use of the ip6.int domain has actually been deprecated with the RFC 3152 in 2001. So it's a long time ago. Then there's a new - relatively new - RFC, 4159 in August 2005, that says, because it has been deprecated, then the RIRs are no longer required to provide the ip6.int service. And the fact that APNIC also has stopped accepting new ip6.int domains as of June 2004 but, however, the query rate is still there, then we need to consider an orderly shutdown of the survey. So the proposal says, "It is proposed that APNIC cease devoting resources to support the operation of this deprecated domain and the cut-off date to be determined jointly with the other RIR." And also the proposal contains all the steps for an orderly cut-off. That consists of notifying parties, notifying - making public announcements of the projects and then notifying the root ip6.int to remove APNIC delegation on the cut-off date and then actually stopping the service. So this report is actually planned already in the last meeting, that we are going to make an update on APNIC 21. Right, here's our observations and statistics. We are seeing that most IP6 data flow on ip6.int and ip6.arpa is actually to our server - the majority of them are basically zone refresh and notification from masters on update. We have two measurement points - two days in November, so late 2005, and then another six days' measurement in February 2006. Here is the observations we made (refers to slide). This is the total number of queries we are seeing in our traffic analysis. This is the zone update and this is just a notification from master to the secondaries. So this, the one I mark here, is the actual query from end-users. So it is really, really small compared to the zone transfer and the notifications. Now, I'm going to zoom in to that and it turns out that actually, in November 2005, there's a bump in Linux version that does some PTR queries, but this is not normal. The blue colour is the ip6.arpa look-up which is there, but it's OK. But the NS query itself and the A query is just under half of query per minute so it's much less than the five queries per minute that we observed when we first came up with the proposal. So it's now down to half query per minute for the end-user queries. So how many queries worldwide? We are seeing - in November 2005, we see 36 queries. In the February 2006 measurement, which is six days - remember that, in November 2005 it's two days' measurement and in February 2006, it's six days' measurement, it's down to 29 queries only. Compare that with the ip6.arpa queries, which is much larger so it looks to us like it's a healthy decline of ip6.int queries. Right, on to the coordination work. We have been spending some time consulting with the other RIRs and NIR. Meeting with the other RIRs has resulted in an agreement to coordinate the cut-off date as a global activity. So we are going to - all the RIRs will stop operation at the same time. We will collaborate in the public communications so everyone will know and also technical activities. With the NIR, primarily with JPNIC, we consult their community if there is any issues or scheduling conflicts. It seems that, after a few consultations, we pretty much agreed that June 1, 2006, would be the cut-off date. And we are planning to then - now that that date has been set, we will start talking with the root ip6.int, which is held by Bill Manning. So this is the schedule (refers to slide). We are here now, cut-off date on the first of June. There'll be a lot of basically communications and notifications because there are not many technical things to do other than close to the cut-off date, we will notify Bill Manning about one week before and then stop the operation. Most of the work is basically communicating with the secondaries, the end-users, if we still see end-users sending queries to us, we will ask them, you know, "Why are you still using ip6.int?" That's it. Any questions? Any objections about the target date, cut-off date, 1st of June? TOMOHIRO FUJISAKI: Can I ask one question. You have put down to notify the third parties - how will you do that? SANJAYA: Look at the addresses that send the queries. Look up whois and see if you can e-mail the holder. I mean, it's hit and miss. We will just do our best. We may not actually reach the end-user that queries us but at least that's the plan. Does that answer your question? KAZU YAMAMOTO: Is the cut-off date June 1st decided or subject to change? SANJAYA: It's pretty much decided, yeah. I think we're fixed on 1st of June. KAZU YAMAMOTO: Any other questions? SANJAYA: Can you confirm that that is the understanding we have? 1st of June? Yes. KAZU YAMAMOTO: OK, thank you very much. SANJAYA: Thanks. KAZU YAMAMOTO: OK, before my presentation, we have urgent announcement, OK? An APRICOT 2006 conference bag is missing. Someone may have picked up a wrong bag from the area with chairs towards registration desk in Level 2. If you have someone else's bag by mistake, please bring it to the APRICOT registration area as soon as possible. Would you make a look in your bag, OK? Is it your own bag? Please make a double check. The owner's business card, Zita Wenzel, is inserted to the bag's name card is on the bag. If you have one, please go to registration desk as soon as possible. Thank you very much. OK, so my presentation - 'Technical consideration on deprecation of ip6.int'. I'm Kazu Yamamoto, IIJ. So background - as Sanjaya said, ip6.int will be deprecated on 1st June, 2006, OK? A rumour said that deprecation of ip6.int will make reverse mapping worse. It is true that some application servers have ill behaviour when reverse mapping is a mess. We repeatedly experience that, you know, when we login with SSH to SSH server, this login and SSHD makes a reverse look-up, then, if the DNS server hold to reply answer, login OK also holds. Then our login is hold. These kind of things actually happen if, and only if, reverse mapping is a mess. So we need a technical consideration on whether or not deprecation of ip6.int will make reverse mapping worse. What does 'worse' mean? I think there is two criteria. First one is DNS server response time will be longer. This is the SSH program. And the other one is host names will be unavailable. The interesting question is which applications use reverse mapping? Fortunately, most clients do not. And some servers do, like is SSHD, OK? And for what do servers use reverse mapping? First one is logging host names, OK? And the other is authentication. This is in two - one is the existence of reverse mapping. So server make use of existence of reverse mapping for authentication. And the other is consistency between forward mapping and reverse mapping. But this is too detailed for this presentation, so please keep in mind, one is logging host names and the other is authentication. OK. So after 1st June, 2006, what will happen? As Sanjaya explained, roughly speaking, a name error will be always returned when names under ip6.int are looked up. OK? This is too technical, so what does it mean? It seems that no new LAME delegations will be generated. Rather, the number of LAME delegations will probably decrease because bad effects from lower ill-maintained domains will disappear. So, fortunately, DNS server response time will be shorter, OK? In case where host name is resolved and even in the case where host name is not resolved. So DNS server response time will be shorter anyway, in any case. So, fortunately, an SSH server does not hold your login. So are we all happy? Unfortunately, the answer is no. Side effects would happen. Remember that host name will be unavailable in some cases. Let me explain this one in detail. Most servers use resolver libraries on local machines. And ip6.int-only resolver will not be able to resolve reverse mapping after 1 June. So if a server is using this kind of resolver called 'ip6.int only', host name is always unavailable. But please note again that response time will be shorter than before. Resolvers are categorised into four - ip6.int only, ip6.arpa only, ip6.int then ip6.arpa - this means that this kind of resolver, first tries to reverse mapping to ip6.int. If host name is resolved, the query is stopped, OK. Host name is not available, then give next try to Ip6.arpa, OK? The last one is ip6.arpa then ip6.int, OK. Only IPv6 only resolver has, you know, a bad effect, you know. Reverse look-up always will fail after 1 June, 2006. All other libraries don't have bad effect, OK. So the question is how many ip6.int only resolvers are out there. Fortunately, most recent resolvers are not, are not ip6.int only. But some old resolvers are ip6.int only. We cannot, you know, cover all resolvers but why the project pick up ip6.int only resolvers, this kind, probably the most impacted one here is Windows Server 2003 without update, OK. So, if you are using Windows Server 2003, please do Windows update to get ip6.arpa only resolver. If you usually do Windows update, you don't have to care at all. So technical expectation - if a server is using ip6.int only resolver for logging, OK, IPv6 addresses are recorded in log instead of host names, OK. This is not so bad. And host name-based authentication - so access from some legitimate clients is denied, unfortunately. But I should emphasise that these side effects are rare and not fatal. That is our expectation and to, you know, check our expectation true or not, we did a field test. This is done by v6fix Working Group of the WIDE Project since 18 January. What we did is make our server provide separate views. I mean so this server returned name error to WIDE community when the query for reverse mapping from WIDE community. Then to other Internet, host name was returned, OK. So this is a simulation for after 1st June. Fortunately, no side effect has been observed at this moment. So I cannot say this is, you know, evidence to bad things will not happen, but we can believe that side effects are rare, not fatal, somehow. OK, this is my last slide - summary. Our conclusion is a situation would be better after 1 June 2006. But side effects would happen, but they are rare and not fatal. So if you are using ip6.int only resolver, please update your resolver, OK? And for more information, please look at this page indicated by this URL (refers to slide). Thank you. Any questions? SHIN YAMASAKI: Shin Yamasaki from JPNIC. You mentioned Windows server 2003 is somewhat critical. Can you pinpoint which fix or which service should be required for ip6.arpa? KAZU YAMAMOTO: WIDE Project made a question to technical guy in Microsoft. He answered that please do fully updated, OK? I don't know which update fixes this one. I don't know. SHIN YAMASAKI: OK. Just I thought some people cannot always apply the latest pack so if they can know the base line of the fix or service that would be good but if Microsoft doesn't tell you, there's not a way, I guess. KAZU YAMAMOTO: I guess that is for, you know, user side. If you are using some specific applications on your Windows, it is not possible to fully update, but this is server side and server should be, you know, updated because of security or something, OK? So fully update is always a good thing in server side, I guess. SANJAYA. First off, thanks for a very good explanation of the potential impact. I think it's a positive message that we are receiving from you. I'm just curious - did you - because the Japanese community seems to be using IPv6 more than probably the rest of the world. I was wondering if you have done an analysis like what we've done and looking at the query rates of the ip6.int somewhere in your lab? KAZU YAMAMOTO: Yeah. You are talking about statistics, right? SANJAYA: Yeah. KAZU YAMAMOTO: We and WIDE Project checked all the detailed statistics and please - I did not explain because you explained, OK? And the situation is the same and the statistics is available in this page, so please look up this one (refers to slide) JORDI PALET: Regarding the Windows 2003 service pack, I believe in Windows 2003, there is not an isolated packet to solve this but you get it sorted out with service pack one. So obviously, you said, being a server, you should apply everything because of the security issues, but service pack one, as I can remember, solved this. KAZU YAMAMOTO: OK, so we do fully updated, right? Jordi? Yes. OK. GEORGE MICHAELSON: George Michaelson from APNIC. Thank you very much for this presentation. I think it was very interesting to see a totally independent measure of behaviour confirm what we also felt would happen. I would like to suggest that, even though you believe this is a safe activity and we believe this is a safe activity, our responsibility to the community is still to alert people and to be ready to react if there turn out to be problems that we did not foresee. I do not think this will happen but our responsibilities as custodians of the reverse address space is that we must be ready to advise people how to move on if they wind up having problems. In particular, an earlier measure that was made in the WIDE community suggested there is a functional split of DNS in the v6 community. The corporate sector keeps up to date with patches, runs more new software and so are quite likely to have code which will do the right thing and the small business cable home-user sector tends not to do this and is at a higher risk of, firstly, not understanding the problem, and secondly, running older machines. But the other side of the problem is these people are much less likely to trigger problems like the SSH problem. They would not ordinarily be doing services that demand functional reverse DNS and, as you have said, because we are terminating delegation, there will be an NXDOMAIN. Instead of it being a lame response, it will be a 'does not exist' response, which is a much faster termination. So I still believe this is safe and will have the good effect, but I do think, particularly that the Japanese community, you maybe have the shared responsibility with us to be ready to help and advise people. But this is a very good body of work and thank you for presenting. KAZU YAMAMOTO: I think we can do two things - one is write a document. So I will update my - our document, but, because we - our native tongue is Japanese, can I ask you, you know, to proofread - GEORGE MICHAELSON: Sure, yeah. KAZU YAMAMOTO: Thank you very much. The second thing, probably something else will explain but APNIC can ask to NIR - the NIR actually ask IIJ and IIJ is asking our customers. So such a hierarchy should work. Any other questions? OK, thank you very much. APPLAUSE KAZU YAMAMOTO: So next speaker is Yamasaki-san from JPNIC. His presentation title is 'Progress report for ip6.int deprecation in Japan'. (Shin Yamasaki had problems connecting his laptop to the projector) His laptop is not friendly so... he will make a presentation using PDF. OK. SHIN YAMASAKI: OK, sorry for wasting time. For some reason, this projector doesn't like my laptop. Let me use another laptop. My name is Shin Yamasaki from JPNIC. This is the supplemental presentation of Yamamoto-san's presentation. This is just reporting the progress of the ip6.int deprecation within Japan. So the background is, as you know, not all IP address ranges are managed by JPNIC. But last year several IPv6 addresses transferred from APNIC to JPNIC. Then all of those ranges have reverse DNS in APNIC that is called a 'shared zone' system. So JPNIC basically only retains records in our resource management system. That means we don't have DNS in our site. Then when we migrated IPv6 addresses, our system - we decided not to retain ip6.int zone data in our system because APNIC already announced deprecation of the ip6.int. As Yamamoto-san said, as we are one of the Internet registries, we should let our customers know about this ip6.int deprecation issue. So when we migrated IPv6 data, we counted the number of the ip6.int zones, then notified them the zone data won't be available in June 2006, at the time of the migration. We did migration three times from APNIC to JPNIC. The first migration happened in May 14. We migrated 55 IPv6 address blocks. 19 of those had IPv6 zone. Second migration happened in July 4th. We migrated nine IPv6 address blocks and two of those had ip6.int ranges. Then third migration happened in August last year. The only one range also had ip6.int zones. It's a very longwinded way, but we notified from our host masters to a members, LIRs, about the ip6.int deprecation. So first announcement was made from May to August last year. It's the same as the last slide - basically we notified each of our LIRs about the ip6.int deprecation. After that, we publicly announced about the ip6.int deprecation in our JPNIC Open Policy Meeting. Then, third time, we also announced to our LIRs in September about the same thing. At this time, we recommended to stop using ip6.int and migrate to ip6.arpa. Then, in December last year, we had another Open Policy Meeting. Then we announced this issue as part of the APNIC 20 report. And this year, we made a degree of measurement by using dig command from our end to the LIR's nameservers. Then our latest result was we still can dig the ip6.int zones without errors. So basically that shows there is no improvement since migration. But obviously, the method we did had limitations, because just submitting the request to the LIRs' ip6.int zones does not always say exactly if the LIR uses ip6.int or not. There is another issue. Since those IPv6 allocations are quite historical, most of those still have zone data for /35. That's the original allocation size. So some ranges have both /35 and /32 zone data. So that makes things more complicated. Then the next step - our hostmaster will announce to our LIRs who still use ip6.int within this month. That's the status of the ip6.int issue within JPNIC area. That's it. Any questions and comments? KAZU YAMAMOTO: I have a question. Would you show slide who is titled 'result'. I don't know what you try to mean. This is result against query to ip6.int? SHIN YAMASAKI: ip6.int only. KAZU YAMAMOTO: And you said no progress is observed, right? SHIN YAMASAKI: From the time of the migration. KAZU YAMAMOTO: But I think this is not that situation. Because we don't care NOERROR because they just provide, you know, reverse mapping and ip6.int and, after 1st June, that database cannot look up. So no bad thing happened but JPNIC should try to use dig command to ip6.arpa instead of ip6.int because the important thing is that, you know, each side provides reverse mapping database through ip6.arpa or not. SHIN YAMASAKI: So you're saying if transition was made from ip6.int to ip6.arpa was made or not? KAZU YAMAMOTO: We don't have to care ip6.int at this moment. That will be obsolete. The important thing is, you know, whether or not each site provide information through ip6.arpa, so you should check ip6.arpa zone, right? SHIN YAMASAKI: Right, right. Thank you for recommendation. TOMOHIRO FUJISAKI: I have one question. Do you get any response from LIRs? SHIN YAMASAKI: I believe we didn't. But we will individually notify if an LIR didn't migrate from ip6.int to ip6.arpa. Am I answering your question? TOMOHIRO FUJISAKI: Yeah, I just want to know the LIRs have any questions, any comments? SHIN YAMASAKI: No. No. We didn't. Any other questions? Thank you very much. KAZU YAMAMOTO: Question - what kind of message did JPNIC send to each, you know, LIRs? My intention of the question is we should not ask people, you know, to stop using ip6.int. That is not important. We should ask people to use ip6.arpa. OK? Stopping ip6.int is not so important. But usage of ip6.arpa is very, very important. So we should ask, "Prepare ip6.arpa in your domain zone," OK? SHIN YAMASAKI: OK, I'll keep this in our mind to encourage using ip6.arpa to our members. OK, thank you very much. KAZU YAMAMOTO: OK, I should explain this earlier but this is, you know, APNIC meeting page (refers to screen). If you need access to this page, you can also watch, you know, transcript, you know, you can also see transcript over there but, if you want to have such text online, please access this page. OK? And click here - it takes a little time, but you will have text here. OK. It just takes time, but anyway. OK. That is all about ip6.int. Any questions with regard to ip6.int? OK. Let me call next speaker. Next speaker is Hosaka-san, JPNIC. He is going to make a presentation on JPNIC's IPv6 registry service update report. TOSHIYUKI HOSAKA: This is the overview of my presentation. First, I would like to talk about JPNIC IPv6 statistics. And after that, I will explain our Registry System Update. So, statistics - this slide shows our statistics. This is made by JPNIC, our allocation, to our members. The blue bar shows the number of JPNIC members. As of January 2006, JPNIC has 379 members. At the same time, at January 2006, 66 members have received IPv6 allocations. So that means 17.4% of our members have received IPv6 allocation. And this is the statistics of assignment made by LIRs. The blue bar means /40 assignment to their users and the red bar shows /48 assignment to their users. This is incremental statistics. So, January 2006 - 904 assignments - /40 assignments - were made to their end-users. And 58 /48 assignments were made to the end-users. So, I would like to talk about our JPNIC Registry System Update. We have implemented a bulk data exchange system into the JPNIC Registry System. If you use that, LIR can register their assignment to our registry system at the time. IPv6 assignment - LIR will assign a lot of /48 or /- or something, at the same time. So we have implemented this bulk data exchange system. LIRs and assignment data are using SSL to our registry system and we also have certificate of authority. So using that, we can authenticate the LIRs. This system, if I compare this system with normal email system, web transaction, bulk data exchange has less overhead than email and more secure than email because this system uses SSL. And this system is already ready to provide. And one of our members is very interested in use. So we will soon begin testing. And we have a future plan. IPv6 registry service has not been IPv6 reachable yet, but within, until the end of fiscal year 2006, we will be ready. And the whole registry system will be ready until the end of fiscal year 2007. So at last, you can search our WHOIS server by 2006. So any questions? TOMOHIRO FUJISAKI: I want to go on one thing - if APNIC include this number (inaudible) TOSHIYUKI HOSAKA: I don't think so. SHIN YAMASAKI: JPNIC send this daily, so it should be in APNIC's whois. But there is an issue - our data doesn't include allocated - what is it called? Our data doesn't have that. So that's why it may not be included in APNIC's statistics? GEORGE MICHAELSON: I believe all v6 activity is done as direct assignment. So if you perform a transaction to hand something to a JPNIC member, it is automatically reflected in our registry. Whois is slightly different. Registry is our database system that we use to manage resources. So when we publish statistics, they don't come from whois, they come from registry, and I believe the assignment report that we produce does reflect these figures and our other measure, which is the total footprint of v6 does reflect this. That is what I believe. TOMOHIRO FUJISAKI: Do assignment, in the allocation, is it available? SHIN YAMASAKI: It doesn't have downstream allocation. KAZU YAMAMOTO: Thank you very much. So, next speaker is Jordi Palet. He will make two presentations. JORDI PALET: OK, so the first presentation is to introduce the activities we have been carrying out in Latin America and Caribbean, together with LACNIC. Basically, the idea of these activities has been to show the ISPs in the region are not only ISPs but software developers. That IPv6 is not just about more addresses but also about providing new business possibilities because it provides platform for possible innovation. And they can build new obligations and new services that can take advantage of that and probably generate some profit. We also try to show them that the question which IPv6 is not anymore if, but actually when you're going to do that. And the idea was to also show that it's actually better to start as soon as you can and probably it will make it cheaper for you because you can plan instead of trying to do it overnight and it being expensive. Also, going a bit into the technical data - what we have done is basically trying to explain that you need to divide different parts of your network to try to see how to approach this transition. And basically looking to your network which is most of the time basic, the core of the backbone and the access. In most of the cases, if you have already very well maintained backbone, if you have MPLS, you can probably do that very quickly and most of the time in most of the cases is good enough, modern enough so you don't need to do practically anything or maybe just the operating system or whatever. Even most of the time you don't need memory of great, according to the experience we have been doing with several in the region. But the average system has been that case. And also in this network, in the backbones, in Latin America, we have succeeded most of the situations to upgrade the backbone in just a matter of hours practically. We try to explain also in the access network that you have different situations, because depending on technology - for example, we know that today it's not possible to offer native service and the other situation typically is that you have equipment which is not native or is not supporting IPv6 natively and/or even maybe not able to upgrade this right now. Even if this is changing very fast there is also a very important dependence on which products you happen to fill. Despite that, of course you can still do some transition and advantages or the first advantage of IPv6 which is offering connectivity and to related applications which can take advantage of that. It's already able. So what is the rest of this experience? Basically, what is missing, it's basically training. 'New' not necessarily means difficult. The people are usually perceiving like that if something is new. If you don't get one brick out of the wall, you can't see, but after the wall there is nothing, right? So sometimes you need to consider a small or incremental operation on your network or operation and applications and so on. But you need to take advantage of all the new services and applications that this deployment can bring to you. So the steps that we are doing is, of course, helping them. If necessary to request, you can have contact with your providers - a small pilot if necessary. Getting up to deploy IPv6 in their network and even when they are convinced and it is activated in production stage. Curiously, we have a lot of situations where even if we know the provider is IPv6 capable, when somebody in a given country, for example, last week in Mexico, got conducted the provider, the local people said, "IPv-what?" That means that there is misinformation. The local people is not trained enough. So in that case we need to go back to the people in the country and tell the people what they need to do. After that we contact them with the IPv6 in a couple of hours. The local ISPs don't have this contact mostly at the high level. In the big carriers, it is not going to happen, at least not so quickly. So what was the LACNIC situation regarding IPv6? Until June 2005, we had about 18 IPv6 prefixes allocated. Only a few reduced number of them were being mentioned. There was no real usage of IPv6. Almost no, let's say, big interest in the region and no production service available. Maybe some services in research allocation. But very, very few competitive region in the world. So when we started this activity, basically we had one initial activity in Lima and Bogota in January, 2005, and across the rest of the year, we have succeeded to gain over 3,000 people that's key because ISPs are probably not going to get the money back until the services or applications can take advantage of that. What is going to be able to charge for IPv6 because the customers just buy services and obligations. Some of them have been creating local groups, like we call those groups IPv6 in Argentina, Colombia, Mexico, Panama, and others coming. We got from there 18 prefixes that we have in June, we have 51 prefixes and most of them are already being announced. I don't mean just getting them, but making sure there is some activities going on behind that announcement. And just explain that some of the times we need to follow the chain. If a small ISP come to us to get some help, maybe this ISP is not connected to a big carrier, a big international carrier, but is connected to a medium-size carrier from that country. So we need to convince the national carrier and then go to the upstream provider. There is also a lot of good and interesting feedback from government and organisations like regulators, enterprises, developers, even a lot of information in the press related to all this. So I think the rest is quite interesting. One interesting thing is this division of the IPv6 allocation that is done by RIPE which shows that after this, almost just six months of industry work, right now the space of label in terms of IPv6 addresses comparing of ARIN versus LACNIC is quite impressive. And I didn't make the calculations but I'm sure if I show something going on in IPv6 addresses, the figures could be even more impressive. Let's see what happens in the next six months or one year when I think we'll probably succeed to go to at least double the number of ISPs offering service in Latin America. One additional thing we found in this work is that if the ISPs are connected, I mean Latin America, Caribbean, are provided to upstream providers from Europe, all of them are offering native IPv6 services. And there are quite a few - probably about six or eight different upstream providers that have international service to Latin America, from Europe, and they're providing native IPv6 services. But there are some that hung up from upstream providers in US. And these upstream providers from the US, basically two big ones, they don't have IPv6 service in very nice situations. They are only offering tunnels and most of the time the routing is not, let's say, good enough. So what we also did was we are working together with another organisation, which is OCCAID, which is providing free IPv6 training, but what we are trying to do is try and help with the first steps, when the service is not the same as the original upstream provider. We don't want to compete but we want to compliment until there is a service ready to provide. Basically, if you see which of this ISPs or entities like TLDs in Latin America and Caribbean, you have a few of them, Panama, Portugal, sorry, Brazil, Guatemala. There is a very interesting case that the three ISPs that are of label in Cuba, they didn't succeed to get IPv6 service because the blocking from US, they cannot connect. So we succeed to get a special permission from the North American government because there is a satellite ISP which is Colombian company and based in Miami. So using a Russian satellite we connected them to get IPv6 service natively for them. So very interesting level of deployment. Probably the first country in the world that will be totally connected to IPv6. A very interesting thing. So for those that have interest in OCCAID network, we get two links from different carriers. This is the network we have now. We are extending it to Europe to offer the same service to European ISPs which don't have native service or good quality from their own upstream providers. We are trying to extend it to Asia Pacific and to Africa. In Africa, we already have one point of presence which is still not on this map. Even in North America, the level of this is becoming so interesting that part of the network which was needed to be upgraded because it's already being filled all existing pipes. And I think quickly, but I'm done with this presentation, so we still have five minutes before the other one, we can make questions at the end. OK, I'm probably not going to follow very much these slides but it will be quicker this way. A working group - there are still a lot of transitions. But we don't have enough good transition to make it simple. We have situations where ISPs typically in the access network cannot deploy today IPv6 because I just explain it in the previous explanation, all the network access itself is not providing IPv6. So what we need is to look for a way which is not expensive or even absolutely inexpensive for the ISPs and also for the customers to get IPv6 service in that situation. We have also the reverse situation. This will be the picture. We have a core network, the customer network as well. We have here, just one box is all stuck but at least there will be dual stack. Maybe one or several of the devices in the access network don't support IPv6 and maybe even in the home network is not providing IPv6. So what we want is to make sure in this network, either this device can get upgraded to the stack, or any of the lines can get easily for dual stack. We have the reverse situation. We already have some networks where it's common for whatever reasons to have all this access network or even the core network being only IPv6, but we still have some obligations with regard to IPv4. What we want to achieve is encapsulating IPv4, IPv6 or IPv6 before in an automatic fashion. So this is what Softwires is trying to resolve. Either you have a host or you have even another CPE. And the situation is, we have achieved also a consensus in the last week. In a meeting in Hong Kong last week, this technology is almost there. We don't need to do anything new. We have layer 2 tooling protocol Version 2, Version 3 to achieving this. There are some complications. For example, there is not a prefix delegation. You may need this if you have several hosts in the network to support IPv6. More or less that's the situation with this working group. It has progressed after many years of thinking on that in different working groups. We have achieved probably the rest in less than six months and now it's time to go to get the documents, and I guess that will be really very quick because there is a good consensus in the working group in the way ahead. There is another case which is being studied by this working group. It's a little bit more complicated. This case is being demanded by the China Research Network Information Centre which is only getting funding to work if the network is only IPv6. The difference with the other case, the previous case, the customer has the full route. While in this case, we are talking about full BCP. It seems the solution is quite similar which the extensions, for example, with the multicast and so on. I think more or less that's all. Questions? No questions. I was too quick. Thank you very much. TOMOHIRO FUJISAKI: I think there is - sorry. Not so popular, how many in the area? JORDI PALET: One example of that is the Chinese network, but it's a more complicated model. But also IPv6 only. Another example is at least four big networks in Europe in addition to the networks in the US which are trying to make it happen because the RIPE IPv6 traffic is dominant and they have only allocations which are using the network. I have a concrete example where we have deployed this in Spain with 5,000 schools. There is a similar example in Portugal where 8, 500 schools. Another one in Turkey and there are some others coming. It's not popular now but if you look at the long term - as soon as we have availability of services that support IPv6 and the traffic becomes IPv6 dominant, it will become more useful because at the end, managing a dual stack network may increase the operational cost. If you succeed to, in a transferring way have the core in the access, only the core or the access to support IPv6, in the long term, it could be an organisational factor. KAZU YAMAMOTO: That's all our presentations. Before we conclude with this session, we should take notes again. Morning tea, lunch, afternoon too will be available on Level 2 in the foyer. The APNIC social event - to participate in the APNIC social event, please bring your ticket. Plus we will leave from the Level 1 Plaza Deck, if you don't know where it is, please look on the back of your ticket. Our last bus is 19:10, so please don't miss it. And MyAPNIC and policy flash demo is always available on the APNIC Helpdesk. The helpdesk itself is available at the break times. And lastly, we will have a special session called APNIC fee structures today. So if you are interested in this, please join it. OK. That's all. Any questions or comments to this session? All happy? OK. Let's conclude this session with a big hand. Thank you very much. APPLAUSE