______________________________________________________________________ DRAFT TRANSCRIPT IPv6 technical SIG Wednesday 23 February 2005 11.00am ______________________________________________________________________ KAZU YAMAMOTO So it's 11 o'clock. Hello, everybody. Welcome to Japan. This is IPv6 Technical SIG and my name is Kazu Yamamoto. I am chair - the chair of IPv6 Technical SIG. So let's get started. Well, first of all, let me explain housekeeping issues. We will provide video streaming to provide this content. So, if you ask questions or answer, please use microphone. Also, this is APNIC web page and, if you gain access to this page, you can find, you know, chat system. So, if you want to use that, please visit to this page. Now, also, we have - as you can see - the conversation of this session will be printed on that screen, so we know that most of the audience are not native speakers so, if you miss the conversation, please look at that screen. So, let me review the action items. There is no open action items. That is very good. And I have one news. As you may know, Jun Murai have retired from the chair, OK? We have two new co-chairs. One person is Tao Chen. TAO CHEN My name is Tao Chen from CNNIC. My English name is Edward. It's my honour to serve the APNIC Internet community. And I will do my best to help you. Thank you very much. KAZU YAMAMOTO Thank you, Edward. The next person is Tomohiro Fujisaki. Would you say some words? TOMOHIRO FUJISAKI Good morning. My name is Tomohiro Fujisaki. I have been serving IPv6 for a few years and actually it's my honour to be a chair of this IPv6 SIG. Thank you. APPLAUSE KAZU YAMAMOTO So, let's go down to presentation section. Well, today, we have four presentations like this. So let me call the first speaker. First speaker is Arifumi Matsumoto and his presentation title is "Source address selection policy distribution for multihoming". ARIFUMI MATSUMOTO Hi. I am Arifumi Matsumoto and I am working for NTT PF Lab. Actually, I just changed the title just before this presentation and the new title is "Source address selection in multi-prefix multi-service network." And, first of all, I talk about the background of my research. (Refers to slide) Here, in the red figure, an access line and a device are used to be bounded one-to-one for service. For example, in this example, the telephone service provider is bounded one-to-one. So a telephone cannot connect to the television network or Internet. And, today, this situation has drastically changed. Everything over the Internet, every service, every media, is getting on the IP network recently. And, in this session, there are some issues to think about. And the first one is how to let them - how to let each services to co-exist in a network, in one network, happily. This means, for example, how to associate a - one device with an upstream network correctly. I mean, when this telephone uses the service provided by telephone service provider and also the Internet service provider, how to let the connection associate appropriately to the upstream network. This is one issue. Also, we have to provide not only one-to-one binding, but also one-to-many binding in this type of network, in this coming age of network. And next issue to think about is how to apply network control policies to a device and to a network. I mean network control policies such as quality of service control and authentication and filtering. I think, for example, if we want to make a phone call to someone, the telephone packet have to be - have to have high priority than any other packets, I think. So we have to, we have to handle these two main issues in this type of network. One-service one-prefix model is proposed in IETF and in some papers. This is a model that provides multi-service network. And this model is based on the address and prefix based service separation. In this model, a service provider assigns an IPv6 prefix - the size is /48 or /60 I think - to each customer. In IPv6 specification, one network can have multiple IPv6 addresses. So a host, such as telephone and TV set or computer, can use - can have multiple services, so can use multiple services at the same time. And, in this model, network policy control, such as QoS or filtering - I just mentioned in the previous slide - can be implemented to each network prefix separately. And, also, by controlling the address assignment, a service provider can control which appliance can use its service. One drawback, may be that this model consumes many, many IPv6 address space. This is one drawback. And this is the example of address assignment in this one-service one-prefix model. As you see, the telephone service provider has the address block of A /32 and TV service provider has B /32 and ISP has C /32. the service provider delegates one IPv6 prefix to each consumer so, in this case, if this telephone uses both telephone network service provider's service and also the ISP's service, so this telephone has two addresses delegated from each service provider. The TV set only uses the service provided by television service provider, so TV set has only one address. And, on this computer, you can use every service, so this computer has three addresses. I want to say that this model has a serious problem in source address selection. I talk about in the next slide. In this model, source address selection algorithm, that is defined in RFC 3484 may choose a wrong source address. If this telephone uses A 1 for the address to communicate with this host in the Internet, the return packet won't be reached at the telephone. That is because the address A 1 is delegated by the cross network. Telephone service provider's network is closed, usually closed, so the return packet won't reach at the telephone. So, each appliance cannot communicate, connect appropriately. And the next example is in this case, in this case, a telephone has a closed network address and Internet ISP service, but, if ISP is not involved, this problem happens. Telephone service provider or TV service provider acquires another IPv6 address space. And this is a brief description of our solution to this problem. In this solution, each service provider distributes "source address selection policy" to its customers. As you see, this service provider has an address A /32 and it delegates address block A /48 to its customers. And here, the service provider also notifies its source address selection policy, the policies that, when you want to communicate with A /32, use source address A /48. This is the source address selection policy. And this provider, This provider delegates B /48 to this consumer and it also distributes the policy that, if you want to communicate B /32 or /0, please use B /48 for the first address. And this home network gateway combines these policies and notifies to the downstream end nodes this policy. This is just a form of these policies. RFC3484 also defines a policy table. This policy table is not used by the - if you don't configure manually. And, in our solution, we use policy table and, by receiving these new, this information, this host stores these policies into this policy table. By using policy table, end host can choose appropriate source address. And we propose DHCPv6 and route advertisement as an option to implement this mechanism. Now, we are standardising this mechanism in dhc and IPv6 working group in IETF. And we have implemented DHCPv6 client service in FreeBSD and a client for Windows. And, for route advertisement we have implemented on FreeBSD. So I welcome any questions and comments. KAZU YAMAMOTO So, if you have a question, please go to microphone, please use microphone. QUESTION FROM THE FLOOR Hi. Im Robert Elz. If you have many services, how much data is likely to be wanting to be added to, say, a router advertisement to supply the policy to allow the selection of addresses to be handled by the end node? Can you realistically put enough data in a router advertisement or even in a DHCP option to supply everything that might be needed by a potential device? Or is there something indirect that I missed out in listening to your presentation, where you're only supplying information about how to get the policy? ARIFUMI MATSUMOTO You mean that all the information can be stored in one (inaudible)? ROBERT ELZ Yes. ARIFUMI MATSUMOTO Somebody asked the same question to me and I think that, in route advertisement, the maximum size is very small, so that case can happen. So I think for that case, you know, we can use route advertisement - so, it means that, if it has very much data it falls back to DHCP to verify the source address selection policy. ROBERT ELZ Can you even really put that much information by DHCP? And even DHCP options are limited. ARIFUMI MATSUMOTO Yes. I think the DHCP option size is also limited but it's much larger than route advertisement. Even if we don't want to carry such a global routing table, so I think this is an operational issue. So I think this is not used to carry all sort of things, all the routing information. So I think it's an operational issue. ROBERT ELZ OK. KAZU YAMAMOTO Any other questions? QUESTION FROM THE FLOOR I have two questions. One is - how is that system - what kind of information are you using for all syndications to get the source address for each services? ARIFUMI MATSUMOTO This is the work to carry the source allocation policy. So this proposal doesn't cover the authentication part of this system. QUESTIONER Which means, if someone wants to get some specific address for specific services - so, if that means anyone can easy to get that information, that source address using your proposal of that DHCPv6 options. ARIFUMI MATSUMOTO I mean the authentication issue is part of the proposal. QUESTIONER OK. My second question is do you consider about address spoofing issues? So maybe someone can use a source address trying to link with some specific services. So, if that kind of system does not have to check some kind of address spoofing, maybe anyone can get into any specific address for DHCP attack or something. ARIFUMI MATSUMOTO In my opinion, the address spoofing issue is also a matter of authentication so in our proposal, we don't, for now, think about the authentication and address spoofing prevention. QUESTIONER OK. Thank you. KAZU YAMAMOTO So a possible answer to the first question is DHCP itself has an authentication mechanism. And also DHCP packet never gets across routers so ait connects to the same physical link. Any other questions? OK. Thank you very much. APPLAUSE So, let me introduce the next speaker. The next speaker is Annaliza Mulingbayan, APNIC. Her title is "IPv6 allocation status report." ANNALIZA MULINGBAYAN Good morning, everyone. I'm making the IPv6 allocation status report. And, just to give you a brief overview of what I'm going to cover in the presentation, I'm going to give you some IPv6 statistics from each RIRs. Allocation and assignment statistics, and the Whois database registrations. OK, let's start with the allocations that IANA has given to APNIC. Currently, we have four /23s and last November we had two large requests that qualified under the expansion of the existing IPv6 policy which was approved in the last APNIC meeting. Under that policy, we have given /19 and /20 allocations. This is the graph(refers to slide). After that policy was implemented, that was a big amount of allocations that we got from IANA, we got 25 /23 allocations. OK, here's the data of the total number of allocations from each R IR of various sizes because, at this stage, some RIRs are already assigning larger than the minimum allocations. Currently RIPE NCC has 443 allocations, APNIC has 191, ARIN has 132 and LACNIC has 13 allocations. Here is the number of allocations by economy. Japan still has largest number of allocations, which is 80, followed by Korea, which has 31 allocations. Taiwan has 16 allocations, followed by China with 14 and there are some other economies that are growing, like Malaysia, Hong Kong, Singapore and Australia. This graph shows the total number of allocations APNIC made for each year. As you can see, we have a large allocation in 2002 but it drops down in 2003. In 2004, we have 53 allocations, I would say because there were two policies that had been implemented - the v6 allocation policy and the expansion of existing v6 allocation policy. OK, here is the information of our large allocations. We have made /28 allocation to VECTANTNET in Japan. They qualify under the v6 allocation to v4 networks policy. We have made /21, /30 allocation to NTT. Initially they got a /20 allocation. Since they have assigned, like, a number of /48 assignments from that /30, they decided to give the /30 allocation and the original /21. Telstra also qualified for a /20 allocation. They have an initial /8 allocation but they decided to just announce one /20 prefix. OK, from these companies that we have made large allocations, we actually send them a few questions to get some survey on what's the current status of their v6 implementation. And we have this information that we got from Telstra so I'm basically presenting this on behalf. If there's any specific technical questions that may come up, I am happy to get those questions and get back to you later. OK, so, for their current v6 implementation status, they have enabled v6 on their core network using v6 and v4 ships in the night routing. They have assigned /64 prefixes for loopbacks, point-to-point links and local area networks. They're also deploying v6 enabled IGP, IS-IS or OSPFv3 for topology distribution. They also use M BGP4+ address family for IPv6 for prefix distribution and they are following existing IPv4 routing policies for implementing their IPv6. They also enabled selected edge boxes for their dual stacked connection. V6 native from client service to network edge is supported by Ethernet, POS, ATF, Frame and Serial. They also deploy tunnel terminators on each POP, so that clients cannot have native connections, can use IPv6ip tunnel to their local POP, which avoids any unnecessary overlay tunnels. And also acquire multiple tunnelled transit paths until native is offered because, according to them, native v6 in US and Europe is currently an issue. So once the national network is IPv6 enabled and bedded down in a 6-month time frame, they believed that, when IPv6 is enabled, barrier to entry for internal products can be reduced, such as consumer products for DSL/Cable. We have also asked them about the issues and difficulties that they see in the future for their implementation and, according to them, they have to logically rebuild the entire network in IPv6. Operationally, the existing topology needs to be recreated in IPv6 and separate IPv6 I GP needs to be deterministically set to recreate existing IPv4 forwarding paths. And operationally it's difficult to debug if forwarding path behaviours differ between v4 and v6 protocols. They feel that there are also a lot of requirements for training staff and other operational matters. Another thing that they see is the upgrade of operational systems to allow consumer v6 prefixes, like allowing AAAA records in DNS via client GUI and integrate IPv6 syntax in IP allocation systems. OK, recently, we also have made an experimental allocation for WIDE Japan. This v6 allocation is for their field test of v6 DNS service with anycasting. At this stage, the detailed documentation about the experiment is not available from the Web yet, but it should be published on this URL. OK, this shows the IX assignments that were made in IPv6. We have two from Korea and Japan, also in New Zealand. And other economies, like China, Taiwan, Vietnam, Indonesia and Hong Kong all got one IX assignments. For our critical infrastructure assignments, currently we have four assignments in Japan, one in Korea, one in the Asia Pacific - so it's like a multi-national company member - and also in China, Taiwan, Vietnam, Indonesia and Hong Kong, we have made one /32 assignment each. Here is the graph that shows the v6 prefixes that we see in the routing table as of February this year. It's basically similar from the last presentation that we showed last time. There is only additional two /20s that has been added in the routing table. This graph shows the APNIC database registration of v6 prefixes or IPv6 objects. If we were to compare it from last year, as if February, we have around 1,000 /48 assignments and then it went up to around 4,265 /48s in August and we're happy to see that it's going up to around 4,478 /48 as of last February. That's it. TOMOHIRO FUJISAKI I have one comment for your presentation. Thank you very much for showing that. Can you show the slide that shows the number of allocations? (Annaliza Mulingbayan displays the slide) This one, yeah, here. Last APNIC meeting, this graph was shown by the unit of /32 allocations and this time this is number of allocations so I think it's very useful so, if possible, I want to show both informations - to see the unit also. ANNALIZA MULINGBAYAN We actually divided the sizes into /48. Unfortunately, we had some problems at the last minute so I cut down that slide because it's not very accurate but, yeah, we will take that comment next time so we can add accurate allocation size for each RIR. Thanks for that. KAZU YAMAMOTO I'd like to point out a very minor issue. Would you show the slide that's titled "large IPv6 allocations". (Annaliza Mulingbayan displays the slide) OK, the word NTT should be 'NTTWEST'. That is a different company in Japan. ANNALIZA MULINGBAYAN Alright, sorry about that. It should be NTTWEST. KAZU YAMAMOTO Thank you very much, Annaliza. Let me call the third speaker. The third speaker is Ethern Lin. His presentation title is "ASIX6 six status report. ETHERN M.C. LIN (Refers throughout presentation to slides) I come from Academia Sinica in Taiwan. There are two company names here. Actually they are two divisions. I belong to this first division. I am very honoured to be here presenting the Internet exchange v6 status report. This is the outline of my presentation, there are four parts. The first one, I will introduce all these. The first I want to do is the NICI introduction. What is NICI? It is a variation of the two initiatives of communication and information, of the government agency in Taiwan, the further direction and the future of IT, information technology in Taiwan. This is the URL for your reference (On screen). They are aware of the importance of the IPv6 so they organised their steering committee meeting in Taiwan. The committee are chaired by the DGT. There are four divisions here. You can see the research and development. The second is standard and testing infrastructure. The infrastructure development, application and promotion. The five years project started from 2003. This is the ASCC role in NICI. You have seen the first page. We are APAN-TWNOC. We provide an access service for academic and research domain in Taiwan. We are the co-founder of NICI IPv infrastructure development division. MOECC, NCHC and CHI. We have two projects in the past years. This year we will continue the project from 2004. In the past two years our project has focused to minimise the preliminary construction and promote the IPv6 construction for commercial domain. We provide domestic IPv6 interconnection for academic and commercial domain. We try to build IPv6 allocation for academic and commercial domain. Here is the NICI IPv6 steering committee table. You can see here, we are - the structure here (Indicates screen). Let me introduce you to ASNet IPv6 status report. AS net means the academic service network, maintained by the ASCC. We have IPv6 address allocated. Here is what we use. Here is the architecture we provide. Protocol, BGP4 plus, RIPng, and A SPF/3. We also implement IPv6. Then is the point of today's presentation. The ASNet Internet exchange version 6. We try to provide - - to provide the global IPv6 connection for participants of IX To provide the mature of IPv6 infrastructure for IPv6 development and implementation in Taiwan. To share the IPv6 experience with IX participants. I think the most important thing is we fry to minimise the cost for IX participants in initial IPv6 construction. This is a schema of our IPv6. We try to - we want the participants to focus on the native and dual stack. We will provide any interface they need for interconnecting. We also provide needed gears and gears and interfaces which we have for the participants. We provide several career choices for the participants to connect to the ASIX. We provide IPv6 address route. This is IPv6 peerings right now. We provide to commercial and academic and research parts. You can see this is address block. There are six members of the ISPs. There will be another member to our ASIX in this year. This is the logical architecture of our ASIX 6 architecture. There is another router here that provides for some participants. This is the international group. We have two locations in Japan. The first - one is in JP, one is SPIXP-6. Before I came here we also were in Singapore, SOX. And AMS-IX. Most of the major peers. The second is NSPIXP-6. There are 23. The next is in the US, the one is in StarLight. The other is in PAIX. The M6Bone connected to - we are the first in Taiwan. There are members in Taiwan. This is the ASIX6 global infrastructure view in domestic and international. You can see here these are the exchange points. We are in this SOX, we just do it in the 19th February. So that's our project. We also provide IPv6 cooperation with the whole country, all the countries all over the world. This is the tunnelling peers information here. There are total 36 peerings here. This number is decreasing because some peers are transferring to the networks of their peers. This is the native/dual-stack peers information for your reference. This table continues from the last, so you can match this to the table's last side matching it with the left side. These are the services we're providing. In the ASIX6 we provide layer 2 switching. We use /46. You can see the address number. We have divided it into commercial and academic and research zones. Layer 3 routing services here. We also provide our server here. These are the services we provide here. I have a brief introduction of the M6bone. Multicast IPv6 back bone. There are 21 countries in this and 45 IPv6 peerings in here. We are the third site. This is the global architecture of the M6bone. This is the architectures of the M6Bone service. In the domestic peering we have netted here with hi net and the others. We provide 3 kinds of peerings with members in Taiwan. We use the Cisco, Juniper. This is the members of the telephone site. You can see the HiNet is with us. Taipei Giga PoP screen. (Referring to the screen.) We hope we can have IPv6 peerings on this path. This is the architecture of Taipei Giga PoP. They had to interconnect with each other by the ASIX. We also have policy 192 here, but this is changed. This screen shows the affiliates here. If you need any information detail or if you have any questions you can contact me. Thank you. Any questions. (Pause) TOMOHIRO FUJISAKI I have one question. Do you have any information on the traffic aspect? What kind of application or KAZU YAMAMOTO His question is probably are you measuring the traffic in that IX? ETHERN M.C. LIN We have IPv6 traffic measuring system and I don't think the people should be compared with the traffic because they have a large range in difference. KAZU YAMAMOTO Can we watch the status of measurement through web page or something? ETHERN M.C. LIN Yes, but this is member only. Sorry. In this project we also have some trial, IPv6 or even the SIP, but that is in another division. Not in this division. KAZU YAMAMOTO Any other questions? OK. Thank you very much, Mr Lin. APPLAUSE KAZU YAMAMOTO Let me call the last speaker. He is from the IPv6 promotion Council of Japan. Mr Hashimoto. GAKU HASHIMOTO Hello, everyone, my name is Gaku Hashimoto. His name is Kosuke Ito. Today we will talk about our large space IPv4 trial usage program for future IPv6 deployment. First, I will introduce you about authorised - out line of this program. This program authorised at the 11th APNIC Open Policy Meeting. It was originally planned to be closed at the end of 2005. This program - provided the challenge field for coming IPv6 era. Explore new services and boosting up the end in to end application. Make transfer trial to IPv6 Infrastructure under the real service operation and form IPv6 address administration scream. Another goal is revitalising the historically allocated address spaces. This program is run by IPv6 Promotion Council of Japan under supervising of JPNIC. We have been updating the activity at the every APOPM so far. When we reported that this program faces an issue in ending the program as planned at the last APOPM at Fiji we received a comment from APNIC that the program continuation could be allowable if necessary. The current active participants of the program - nation wide ADSL/VoIP service provider. Nationwide always on FTTH service provider. Public wireless-L AN access service provide. L3 connectivity/IP-phone service provider and content distribution network service provider. Unfortunately one participant has dropped out. Individual active participants status and that will come from Kosuke. KOSUKE ITO First of all, from participant nationwide ADSL/VoIP service. We achieved the deployment of one of the least expensive " Always-on" service nationwide, in Japan. They're the most - there the most traffic is the P2P data sharing and multimedia contents delivery, also one of the key applications was the less expensive IP-phone service. These The IPv6 deployment plan based on these foundation. Nationwide service. They just announced the IPv6 service launch this year. They will start their service from the trial level this year then they will go after the commercial level step by step. Our program pushing up their very wide and stable foundation then making up towards the IPv6 deployment service. Current IPv4 address they are using are still quite important for the time being. Since the IPv4 address is the base of their service. Instead of - They could start either vi 6 over vi 4 tunnel or before IPv4/IPv6 dual way. One our programs, the evidence of this service was we assigned the large space of IPv4 address space, they could - that many users rapidly in that short period. So this evidence makes them aware that once they put into their service into the v6 large space area then they could play it more around this kind of service instead of v4 implementing. Another one will be that nationwide always-on FTTH service. Their trial was - they achieved starting fixed IP address assignment to the users, which is /29 per user. So far in the v4 regular assignment way they couldn't afford this much of the IPv6 service for individual users but since our program is available they could try this program. Then they could enable to put individual IP address for a home server, at the home users and also monitoring camera to be accessed from the Internet. This is kind of a new way of usage that was introduced. Then their IPv6 deployment plan - IPv6 ready core routes in place. They just going to make the request - replace the edge routers to IPv6-ready ones gradually. Also starting preparation for sending application to APNIC to having IPv6 address allocation. And they plan to start IPv6 service in the limited service area. Very limited area. But try to make it in this year. They expressed also that IPv4 address they are using is important for the time being. This service is available only at IPv4 at the moment. They would like to start this kind of service. Evidence is a rapid increase of users acquired in a very short period based on our program. Also they monitor the traffic that they also know that P2P in yellow traffic was much larger than. They could know that the future usage of the Internet will be changing from the past towards the future, so they are supposed to know they need to be ready for this kind of new usage by the users for supporting the users service level - for the ISP level to keep the users. They can know the conventional way is not sufficient enough for the users and their usage. Public wireless-LAN access. They achieved starting a city-wide wireless info service for vitalising a sight seeing city. Such as in Kyoto. So-called miako net. This service is also available, so if you'd like to have a temporary ID you just go to the demo area and they'll provide you with a demo. This service is also making it - made possible by our program. They needed wireless mobile connection, area-based information delivery and also wireless VoIP Service through that. You can connect it at the station, or along the river. They also achieved at trial the ballpark, wide wireless multicast service. User can watch info and close-up view of the camera via the PDA. These are based on our large assignment. Still under R and D for wireless IPv6 connectivity service. They are trying on high-speed authentication and hand-over by MIP S v6. And also they try on the MIPS plus LIN 6 for smooth mobility. It's still under the technical level investigation for the service. As you know, they couldn't start it up the v6 service yet, so the current IPv4 address are still important to keep their v6 level ongoing. Another one is this service provider is providing L3 level connectivity such as VPN level and IP-phone service. Especially in the business forum, business service forum. They started the IPv6 IP phone service in commercial in Japan right now. They found IPv6 ready IP phone terminal is available now. They found IPv6 phone is much less cost to install than the IPv4 phone. Because of the - it's a less technical issue for the installation by IPv6 RA. Especially they found that about 40 hours installation work necessary for IPv4 phone, 140 sets, was reduced to about 6 hours work for 140 IPv6 phones. So they could know much - the large scale service, is much further than done by the IPv4. IPv6 deployment plan - done for IP phone service. Still planning for the fixed IP service, which is VPN level. Then they are still planning for fixed IP service. The address, IPv4 address was - returning to us since they could know. They return IPv4 addresses used for IP phone service. They needed the addresses for the fixed IP service for the time being. This is a kind of a unique participants, which is content distribution network service provider. They achieved - they could deploy the large scale service in music delivery depending on the domain name, which is every artist's name. They could use the large number of addresses they could assign each domain name per address, something like that. The IPv6 deployment plan - IPv6 ready load balancer is now available. So they started to investigate for real usage right now. Once those kind of equipment is available for the service then they will switch on to IPv6 way to distribute the contents. Maybe it's very early stage for the v6. They found out IPv6 is more responsive than IPv4. So it could be a value-added service by IPv6. It's not fully available yet so they still need IPv4 addresses they are using. But once they found they could do the v6 way they may not be using IPv4 much for the future. Maybe two to three years they still use - they need IPv4 addresses. Summarising the program status - We achieved raising ISPs' motivation to - to motivate for IPv6 service. So we achieved that, one of the focuses. We also achieved the revitalising the historical IPv4 Space for very useful - a good foundation of that kind of address space. We also achieved a low cost operation scheme and developing the IP address management tools, which is, I'm going to introduce next slide. And since a couple of the members are still expressing that IPv4 they are using is necessary, we need to continue this trial. That part will be proposed tomorrow in the Policy SIG so if you are here think of this trial then we are updating this kind of information is useful then please support this continuation of this trial in the policy SIG. The last one is we are developing IPv6 address management tools. IPv6 address space is pretty large and also we are in the policy /48 assignment is forced to report to APNIC one by one, so that kind of operational scheme needs to be very unusual especially for the non ISP people. So we are trying to support LIRs IPv6 address resource management task to make the lower barrier to step into the IPv6 service development. Also we make these tools in a cost-free way, so we kind of give away a source code. This tool is web based architecture. Also function - this has functions like assignment management, which is not duplicating each other, and also assignment report to APNIC, Whois information is also linked with APNIC database. Sub-allocation management also implemented. Also the delegation setting of reverse DNS. So if we have a IPv4 management address system maybe you can incorporate this part, integrating your system or maybe you can try out this - these tools for reference to develop your own system. Either way we are really happy to give this kind of information to you. We have some information in Japanese and English so if you like please pick up the papers. Also you can go to the demo booths at our Promotion Council place we have this information as well. One of the things we have to apologise is the manual is still in Japanese. So if you - anybody wants to translate in English or any language in your own country's language we would be happy for that. We are trying to make it English on our own. We started this project in 2001. So far we achieved a lot of things. We felt that our program has contributed to boosting IPv6 service in the current IT field. We also found that 1-2 years delay from the original expectation of the deployment level. So maybe this is one part we are kind of need to. No DNS support, I say there, but it's gradually getting the support but it's not sufficient so we have to wait for this kind of infrastructure to be ready for IPv6. Also, another thing is we originally think - saw that once they started up the v6, v4 can be unnecessary to using any more, but in reality many of the participants thinks that once they introduce the v6 service they have to keep the v4 as a fundamental level - at the fundamental level for the time being. They don't know how wrong it will be, but - how long it will be, but maybe a couple of years or maybe ten years or I don't know, nobody knows yet, but this way is the way for the time being, so we found at this point. Maybe many of you are thinking of the v6 deployment, just that web designing of your web site is really important. The last things are - as I said, we still need to keep this program to see the real deployment of the participants for the v6 way, started off their service. So we are going to propose our program continuation in the policy SIG tomorrow and then we are trying to keep this activity upgrading to give you information from now on. Any questions? QUESTION FROM THE FLOOR Can I give you two questions. The first one is - you mentioned about the implementation of IPv4, if I remember correctly, when you were implementing for 140 units IPv4 required 40 hours, while IPv6 required only 6 hours. What do you think was the key factor to make the difference? KOSUKE ITO First of all, this is what I heard is for the IPv4 phone there is the network technician needs to be there at the site along with IPv phone technician. Then individual handsets needs to be manually set or manually checked IPv level of the configuration will be set. Then that kind of a connectivity check, what kind of DNS information are you putting there, those kinds of things need to be checked from at the site level, so it is very time consuming work to make the phone sets correctly work. But once it's in v6 there is the network technician needs to be at the level, they don't care, they just plug into the line, then they can control the individual houses from the centres. So at the site only the phone technician just plugs in and makes it switch on. Then they could reduce the whole configuration work. So it's Internet level setting is much different between v4 and v6. KAZU YAMAMOTO Is that because IPv for phone - KOSUKE ITO That's one of the factors, yes. QUESTION FROM THE FLOOR I think it's very important to get the actual figure based on the field implementation. It is very informative, thank you. The next question was about one of the individual cases, CDN. I think it was about music. I could not get the whole picture of the IDS. Is it kind of equipment based service? What was KOSUKE ITO It's a service based in a data centre. They assign an individual IP address for the individual domain name. Then they are controlling the access controls or charging controls, that kind of things. That's what they are doing. So as many as the domain names they like to have IP addresses individually, or multiple IP addresses. QUESTION FROM THE FLOOR Sorry, I revise my question. I just wanted to know if this was, um, based on PC-based service or is it aiming - KOSUKE ITO User side? QUESTION FROM THE FLOOR Yes. KOSUKE ITO User side, maybe it's the PC. QUESTION FROM THE FLOOR Does this also include the non-PC. KOSUKE ITO So far I don't know. There is no PC devices for the music things. So far maybe it's PC-based. QUESTION FROM THE FLOOR Thank you very much. KAZU YAMAMOTO Any other questions? Thank you very much. APPLAUSE I think we have had all our presenters. (Pause) KAZU YAMAMOTO At 5 o'clock in the next room we have IPv6 Fix working group. This is organised by WIDE Project. The purpose of this activity is to fix the floors of IPv6. To fix IPv6 specification, to fix implementation and to fix operations. So if you are interested in this activity, please come. OK. So that's it. Thank you for all coming. Let's close this session with big hands. Thank you. APPLAUSE