Transcript
APNIC 23
IPv6 technical SIG
Wednesday 28 February 2007
14:00 - 15:30
This is agenda, and this time we have five presentations and one explanation from SIG chairs, okay? So because in total we have six presentations, each presentation should be finished within 15 minutes. okay? Let's get started.
Let me call the first speaker. First speaker is Elly Tawhai, APNIC. Her presentation title is 'IPv6 status update'.
ELLY TAWHAI: Hello. Can everyone hear me okay?
Okay. My name is Elly Tawhai. I'm here from APNIC and I'm here to give you an IPv6 status update.
So here on the screen you can see an overview of what we'll be covering through this presentation. So I'll give you some RIR allocation statistics, along with some APNIC allocation and assignment statistics, and also give you an outline of the assignments that have been registered within the APNIC Whois database, along with showing you some data from the representation of the global IPv6 routing table.
So here - this pie chart represents the number of allocations that each of the RIRs have made to the LIRs, ISPs. So these statistics were taken as of - from the 30th of December 2006.
So now we'll show you the number of allocations APNIC has made, so the number of v6 allocations APNIC has made from 1999 up till 2007. So you'll notice this year we've only made three so far.
Now here you can see the number of allocations that APNIC has made to members that are greater than the initial allocation size of a /32 and there's a total of 18.
Now, this pie chart represents the allocations we have made by economy. So you will notice the three largest number of allocations we have made is Japan, Korea and Taiwan.
What this slide represents is the economy uptake by year for IPv6 allocations. So you'll notice last year the most recent economy uptake was the allocation we made in Bangladesh.
Now you can see the amount of IPv6 IX assignments we have made. So the most we have made is in Australia, China and Japan.
Now, what this pie chart represents is the number of IPv6 critical infrastructure assignments that we have made and the size of these critical infrastructure assignments are a /32.
So now here you can see the APNIC Whois assignment registration, so you'll notice the most people - the most common sizes that people have registered are in /40s and /48s.
And last of all, this represents the data that we've received from our Brisbane routers. This was taken from the 20th of February, so it's quite recent this year. So you can see here the most common prefix size that's being announced is a /32 and a /48.
Does anyone have any questions at all?
TOMOHIRO FUJISAKI: I'm Tomohiro Fujisaki. I have two questions. Can you show the routing table? I'm sorry. How many percentage announce their roots?
ELLY TAWHAI: How many APNIC holders?
TOMOHIRO FUJISAKI: I want to know the percentage of announcements.
ELLY TAWHAI: So in this here, you would like to see the percentage of the people?
TOMOHIRO FUJISAKI: Yes, please.
ELLY TAWHAI: Okay. Well, I can see in this case the size, even though it's not quite that large, the largest percentage, the number of largest amounts being announced as a /32 is 502. Does that answer your question?
TOMOHIRO FUJISAKI: How many percentage have theirs announced? And how many percentage announce their routes?
ELLY TAWHAI: Okay. Well this data has just been taken from the Brisbane router, so, yeah, there's no way I can define it to you here and now. I'd have to look into it more.
TOMOHIRO FUJISAKI: Okay.
I have one more, sorry. Can you show the registration?
ELLY TAWHAI: Yeah, yeah, sure.
TOMOHIRO FUJISAKI: Is the number of registration increasing?
ELLY TAWHAI: Yes. Yes. There is. Bear in mind some of this data actually we've taken from the NIRs as well, so that's why the amount looks a lot larger, yeah.
TOMOHIRO FUJISAKI: Okay. Thank you.
KAZU YAMAMOTO: Probably in the next presentation in six months later, you can bring the actual number, how much organisations are actually in the routing table and are responding.
ELLY TAWHAI: So in comparison with APNIC members in the Asia Pacific region, compared to...
KAZU YAMAMOTO: Organisations who have IPv6 address versus actually announcing.
ELLY TAWHAI: Okay.
KAZU YAMAMOTO: Do you have a question?
ELLY TAWHAI: Thanks very much for that feedback. I'll take it home and pass it on.
KAZU YAMAMOTO: Any other questions?
If you have a question, please use microphone, because this session is broadcasting to the Internet. OK. Any other questions?
So thank you, Elly.
ELLY TAWHAI: Thank you.
KAZU YAMAMOTO: So let me introduce the next speaker. Next speaker is Mei Wang and Tao Chen, Mei Wang from Cisco and Tao Chen from CNNIC. Their title is 'Evaluations of growth-based address partitioning (GAP) algorithm with real data'.
MEI WANG: Good afternoon, everyone. My name is Mei from Cisco Systems, and Tao Chen from CNNIC and myself are going to talk about an alternative address allocation for IPv6. And today we're mainly going to focus on the evaluation of this algorithm using real data from APNIC and CNNIC.
This is a joint project between Cisco Systems and CNNIC. And this project and results here are not possible without the great leadership from Dr Larry Dunn, who is heading the architecture group within Cisco Systems and Chairman Mao from CNNIC.
Here's an outline. I'll give a brief introduction about what kind of problem we're looking at and the key focus of today is to show you the performance results from real data and software we jointly developed to give you a visualisation of the allocation using GAP algorithm and I'll briefly touch on the future work.
Research has shown that address allocation is key for the routing table size and routing table structure, which in turn has great effects on the scalability of routing and the whole network. That's why good address allocation is very important.
And now here's a question that people would naturally ask - what would be a good address allocation solution?
One key factor is to reduce fragmentation. When we say 'fragmentation' here, we mean a customer or an entity in the address space is unnecessarily represented by more than one entry in the routing table. So we are trying - the goal is to try our best to aggregate addresses in the routing table so that we can control the routing table size and thus increase the scalability of the network. There are many factors affecting the address allocation. That's why it's not an easy problem. Usually we have very limited total amount of address to allocate and each customer would request different size and have different request frequencies, also with different growth rate. That's why we need a systematic method to guide address allocation in practice and hopefully once we find a good algorithm, it can be applied at all different levels.
The online optimal is hard, as we all know, so the goal is not to find an absolute optimal solution but it's to reach a good balance, as in all practical problems - balance between simplicity and being close to the optimal. We proposed a new algorithm called GAP, Growth-based Address Partitioning, about over a year ago at APNIC and it turns out around the same time Geoff Huston also proposed a similar idea in his IETF draft about IPv6 initial allocation size unit.
So here's a brief introduction of the overview, a brief overview of this algorithm. The key idea here is to - when you have a customer who comes in requesting an address block, you don't treat everybody the same. We don't say, "OK, no matter who you are, no matter what the current allocation situation is, we're going to put you here anyway." But instead we're going to look at the size and the potential growth rate of this new coming-in customer and all the existing allocations currently occupying the address and we look at all the possible available slots and pick a slot that eventually will give everybody the longest time to grow before anybody runs out of space. When somebody runs out of space, we call it a collision and collision is a big source of fragmentation.
Here's a brief example. When usually customers come in with different rates and also, for example, there are big ISPs and there are small ISPs and we are trying to distinguish them. If you look at the last line here, for example, a new customer comes in with ID '6' and then we look at all the possible address space available indicated by these five arrows and through caplation, we found that even though this is a small space, it's the optimal one to put customer '6' here.
On this algorithm, we have done laws of theoretical analysis and simulations that were presented here before and today we're going to focus and try out this algorithm on real data to see how it performs.
Here's a - I'm not going to bore you with all the theoretical analysis, all the math equations, but here is a very brief review of the simulation results we got before. This shows that, in terms of space occupation, that a GAP algorithm here compared to analogy rhythm without using the growth rate information, the number of - total number of customers given a certain total address space, the total number of customers conserved by GAP is dramatically larger than with the other algorithm and the same thing with the total address space utilised without any collision happening.
And this is from a different angle, similar idea. In terms of fragmentation, if we keep allowing new allocations to come in, even though somebody runs out of address space, we will find a new space for this customer, we call that fragmentation and this shows that depending on the space utilisation rate, we get different performance but, in either cases, with different total address space, we can show that GAP dramatically reduces the fragmentation compared to the algorithm without using growth rate.
This is the focus of the talk today - so the question now is we hope to have a good algorithm for IPv6 allocation but right now we don't have enough data to try any new algorithm. So we look at IPv4 and we ask the question - because we know the history of IPv4, we know all the requests in IPv4, so the question we are asking is, "What if we use a different algorithm, say a year ago or two years ago or ten years ago, what the result will be compared to the existing allocation?"
So this is an example of APNIC data we used in IPv4. Because APNIC has a large database, here is just a chunk of the IP address in APNIC address pool and we were looking at the very latest address allocation from last June to last December and this is on the address block of 122/7 and the minimum amount of address allocation unit is a /21 so we have an equivalent unit of 214 here. So using a GAP algorithm compared to the existing algorithm, we can see that fragmentation is reduced from 150 to 16. And this data is - this result is achieved without any additional information. All we had was the sequence of the requests from APNIC database and how we estimated the growth rate is because usually each customer would request addresses multiple times. So we used the historical data, tried to project its future growth.
So we would expect actually when a customer comes in to request address, we might be able to achieve larger enhancements here. Actually, we are working with a different theory group trying to come up with a mechanism to give incentive for each customer to give us a relatively accurate growth rate.
And we also did some statistics analysis on the data we used. Here is just an example as I mentioned before. This one shows how many requests each customer comes back to APNIC. It shows, like, the maximum number of requests is about 39 for a customer. We totally have 24 customers requested addresses during this period of time on this address block. And this graph shows example of one customer's requesting pattern in terms of time and the requesting block size. So we can see how often he comes back to request more addresses and how big of address block it asks for each time.
And we used similar method on CNNIC data and this is a smaller address pool. It's about 213 address space. It also shows the fragmentation is dramatically reduced from 124 to 30.
The second key point of this presentation is that we jointly developed a software tool for address allocation. We think it's very important to be able to visualise the address blocks and the address allocation and right now - through this software, we provide a platform for more studies and experiments. Right now a GAP algorithm is implemented in the software but any other algorithm can be easily implemented in the software. We are hoping to be able to add, inspect more features and make it more practical for real allocations in the future. I think Tao Chen now can do a demo on this software.
TAO CHEN: I'm Tao Chen from CNNIC. We need a real system to assist an ISP to allocate IP address. Next time we will show the real demo and you can have an experience to use the GAP allocation method to get an IP address block.
This is our demo system here and I will show allocations. If a new customer wants to get a /19 IP block, we can input the size of a block and the customer ID.
Let me explain this to you. If a full customer and the customer has a different growth rate, the allocation demo system can automatically select IP address for the new customer and they select a third position because the customer's growth rate is lower and if we select that, the possibility will lower, so we can avoid more and more fragmentation.
Then, if the same customer applied for an IP block. We can't record the IP allocation history. If the same customer applied for another /19 IP block, let me show you, you can see even though they applied the IP block two times, but we can get a continuous IP block. That's the program and if you - if you are interested to see the IP block software tool, you can access http://gap.asrc.cn.
MEI WANG: Thank you.
Here is a brief summary of the current address allocation methods, one that's used very commonly in practice today, a sequential, is basically every time a new customer comes in, it's put right next to the first available spot right after the existing allocation. It turns out - this is popular in practice because it's very simple. And it turns out it can be optimal if every customer comes in is not going to grow any more and it knows its exact total amount of address it will ever need, lifelong.
And the second one is bisection, which basically just uniformly partitioned the total address space. The benefit of this one is to give everybody equal amount of space and the maximum potential growth. But we all know in reality not every customer is the same as all others - there are fast growers, there are slow growers. That's why we propose GAP, which leverages customer's growth rate information and tries to balance performance and simplicity.
So here is the future work we have in mind. We hope to get more people interested in this topic because IPv6 is taking off, we think that, as Vince speak at the keynote speech yesterday, this is a lifetime opportunity for us to do something dramatic and beneficial for future network. So we hope to get more participation and have more people to discuss and contribute and for more simulations. We hope to have joint efforts to try to search for a balance to solution, which gives good performance and is also easy, simple to implement and also tailors different requirements from different organisations. For further studies, we also need to do more studies and verifications using real data and hope to provide a software package that can be used in the real world.
So the overall goal is we hope to be instrumental to make address allocations more systematic, efficient and easier.
Thank you. Any questions?
MARC BLANCHET: Have you looked at RFC 3531?
MEI WANG: What is it?
MARC BLANCHET: It's actually about an algorithm to do optimal allocation of assignments of ISPs.
MEI WANG: Is that the one Geoff wrote?
MARC BLANCHET: No. It's a previous one. RFC 3531. You should look at it.
MEI WANG: I don't remember that number. Maybe I have looked at it. Maybe I can look at it.
MARC BLANCHET: Yeah. You should.
MEI WANG: Thanks.
KAZU YAMAMOTO: Does that RFC conflict with the proposal?
MARC BLANCHET: Can you repeat again?
MEI WANG: I think he's asking does that conflict with what we're proposing here?
MARC BLANCHET: Well, I haven't seen the algorithm but it seems very similar and the goals are identical. So, you know, on the surface, it looks very, very similar. I don't know. I haven't seen the details of the algorithm.
RFC 3531.
MEI WANG: Thanks.
KENNY HUANG: Actually, I have two questions. Right now it's one question because one has been asked. I'd like to hear, because probably there are other comparing algorithms that can be discussed.
The second part of the proposal actually regarding to how we deploy the allocation policies, so I would recommend, if they are appropriate algorithms proposed by IPv6 SIG, probably can refer to the Policy SIG because actually Policy SIG can discuss allocation policies. Thank you.
MEI WANG: Thank you.
KAZU YAMAMOTO: I should have mentioned this before, but IPv6 Technical SIG can accept only informational presentations and this is a very good presentation at this moment but, if you make a proposal, please go to the Policy SIG. OK?
MEI WANG: Thanks
KAZU YAMAMOTO: Any questions?
So thank you, Tao and Mei, and please, big hands to them.
APPLAUSE
I forget to - you know, I should ask also big hands to Elly. Sorry about that. Can you give a big hand to Elly? Sorry about that.
APPLAUSE
KAZU YAMAMOTO: Let me introduce the next speaker. Next speaker is Jordi Palet from Consulintel and his presentation title is 'Enabling efficient and operational mobility in large network'.
JORDI PALET: Hi, everyone. I already introduced this project in the last APRICOT in Perth, so what I am going to do is a quick presentation of the overall project and then look at two specific areas where the project is doing the work.
Basically to say the project goal is to enable deployment of efficient and operational mobility as a service in large scale IPv6 networks, taking into account also the speculated transition from IPv4. So, to this, the project is doing research and contribution to the standardisation effort being done in IETF and 3GPP basically and then we do validation through different experimentation in laboratory, some prototypes, some testing.
So what are the main areas of work of the project? We are looking at the enhancement of mobility, mobile IPv6, to enable transparent mobility in large operational and heterogenous access networks, which have an interesting growth in the number of users and enrichment of the basic mobility services provided by Mobile IPv6, with a set of what we call premium features, last fast handover, quality of service, and some others. And then finally an analysis of goals and design principles for the evolution, looking to, let's say, what we call the beyond mobile IPv6 in the long term.
OK, so this is the long-term vision of the project. Basically, you see the status today where we have dedicated radio access networks, which typically are optimised for specific services, like cellular, wireless, WiMAX. Then the next step is the integration of these heterogenous radio access networks to offer efficient and cost-effective ubiquitous mobility and here mobile IPv6 seems to be the key. And then the following step is the migration to an all-IP network architecture where all the services are offered over IP and mobile IPv6 with fast handover support as a must. And then the final step will be full mobile Internet when we expect tremendous growth in the number of terminals and users and maybe in this case, mobile IPv6 maybe is not enough to cope with this situation.
OK, so what are the key research objectives of the project? We are looking into improving mobile IPv6 scalability, improving reliability, control of mobility service, enabling offering the premium network features, integration of mobile IPv6 in real-life environments, analysis of protocols and architectures for long-term network evolution. And this is more or less what we call our reference scenario, where we have different access networks belonging to different operators, connected through networks and different kinds of access networks also.
OK, what's the expected impact of the project? Basically, mobile IPv6 seems to be not suitable as we have it today to implement these reference scenarios. It's not enough. And ENABLE will try to fill the gaps, working with standardisation organisations like IETF and 3GPP as I mentioned before. And we expect that the research of the project will increase the ability to deploy a future-proof mobility infrastructure for the high-demanding user expectations that we foresee in this reference scenario.
We expect to somehow also contribute this way with the development of this long-term vision, to let's say all IP future mobile Internet, investigating also all the transition paths to this novel model, including technologies which today are not fully understood yet.
OK. This is the project system architecture where we have the Mobility Service Provider, what we call the MSP. We have different services like quality of service, SIP, the DNS, AAA servers, the home agents and then this is connected obviously, to Internet or other IP backbones and have you the different access networks. And, in addition to that, you need to collaborate with other MSPs, other Mobility Service Providers, to be able to have the users moving from one network to the other in a seamless way.
OK, so up to now, what I have done is a very generic interaction of the project and now I am going to start with one of the key topics, which really needs some research because otherwise, it is different to implement.
This topic is what we call bootstrapping. The goal is addressing the operational requirement for dynamic provisioning of the configuration of data on terminals and home agents and mobility IPv6 service - mobile IPv6 service authorisation. The configuration data includes, from the home agent address, which is required on the mobile node, it's used for registering the binding updates with the home agent. From the mobile node home address, it's required on the mobile node itself. It's used for communication with other nodes and could change if the home network is going to be renumbered and then there is the keying material, which is required by both the home agent and the mobile node and is used to set up the security association, which are talking obviously about IPSec, between the mobile node and the home agent.
So the service entities involved in the bootstrapping process are in this picture. We have the Mobility Service Authoriser, what we call the MSA, which has the AAA servers. We have the Mobile Service Provider, which has the home agents. Then we have the other Access Service Authorisers, the access points and the Access Service Provider, what we call the ASP.
So how we can do the bootstrapping? Basically in IETF right now, there are two architectures being investigated. One is the split scenario, where the Mobility Service Authoriser, MSA, is different from the Access Service Authoriser, ASA, and the assignment of the home agent is done using DNS. Then we have another scenario, which we call the integrated scenario, where the Mobility Service Authoriser, the MSA, is the same as the Access Service Authoriser, the ASA, and the assignment of the home agent is done by means of DHCPv6.
If we look into the steps done for the split scenario, we have getting the network access, using DHCPv6 or IPv6 stateless address auto-configuration. We have the home agent assignment done by DNS request from the mobile node. We have setting up an IPSec security association between the home agent and the mobile node, the assignment of the home address to the mobile node and the update of the mobile node DNS entry with the new home address.
In the integrated scenario, we obtain the network access using DHCPv6 or IPv6 stateless address auto-configuration. The home agent assignment is done by the DHCPv6 request from the mobile node and the rest of the steps are done the same as in the split scenario.
OK, so that was one of the key problems or topics in order to get this complete mobile IPv6 scenario. And then we have another problem, which is the handover problem. Basically the authentication in wireless networks usually is based on EAP. Cryptographic material is derived by EAP methods in order to establish the security associations between the mobile nodes and the access network. And there are some drawbacks. The EAP authentication is usually a time-consuming process and it is expected to be performed each time the mobile node moves to a new EAP authenticator, even when it has been authenticated recently and owns unexpired keying material. In addition, the home domain is contacted each time the mobile node must be authenticated introducing an additional delay when the home domain is far away. So both drawbacks produce undesirable delays during the handover process and actually what you want to do is the handover really, really quick, right?
Possible solutions. One of them is what we call the context transfer, which means the transmission of the cryptographic keys from the current gateway to candidate ones. This is widely criticised from a security standpoint, obviously. Another one is the pre-authentication, which means the mobile node authenticates itself with candidate access devices - access points or access radios - before attaching to them. And the last possibility that we haven't studied until now is the fast re-authentication with different approaches. One is avoid running a full EAP authentication exchange. Another one is support efficient re-authentication for the EAP peer locally within the visitor domain and the last one is using a generic service authorisation architecture proxy as a key distribution centre to push the keying material to the network access equipment without running EAP.
And that's it. I stayed within the 15 minutes. Basically, the idea is you know something about the project and you know within the time I had a couple of the key points or problems so, if you have more interest, feel free to visit the project website. There are lots of documents of the work that we are doing and they are really extensive documents so if you are interested in knowing more about that, you will find a lot of information there. Maybe we have time for any questions, but...
KAZU YAMAMOTO: I'll take questions quickly. So I live in Japan. How can I join the ENABLE project? Is this possible?
JORDI PALET: The project is funded by the European Commission, so the funding is available only for the European partners that since the beginning of the project joined the contract. But we are open to participate and collaborate with third parties if they are interested.
So the best is to write me an e-mail and we can see what kind of cooperation we can establish and we have already a partner in China, which is Kuo Wei, and they're having an interesting contribution to the project, so we are keen to support other partner corporations.
KAZU YAMAMOTO: So can the WIDE Project include Japan...?
JORDI PALET: That could be an option, yeah.
KAZU YAMAMOTO: Any other questions?
OK. Thank you.
JOHN SIHAR: Hello, everyone. My name is John Sihar. I am representing IPv6 task force of Indonesia. We have IPv4 since October 2006. So the deployment of IPv6 is in the early stages. (Pause).
KAZU YAMAMOTO: So change the presentation. Give preparation time to him. Takashi Nakamura, are you ready? So, next speaker is Takashi Nakamura of IPv6 Promotion Council of Japan and the Mitsubishi Research Institute. His title is IPv6 Deployment Status in Japan.
TAKASHI NAKAMURA: Okay. Thank you. Thank you for introducing, I'm from Japan, IPv6 Promotion Council of Japan and also belong to Mitsubishi Research Institute. It is a consulting firm of Japan.
Okay. Today I like to make an update of our Japanese situation - IPv6 deployment status. What I'm going to talk about is one: government activities. And I would like to introduce some IPv6 application and service right now in Japan, and then the conclusion. And I think I don't have to introduce about us because we come here every time and talk. So, I will cover the first one.
In Japan, there was a development strategy starting from 2000. It is well known as promoting IPv6 in the government strategy. The new IP reform strategy, I think it is a little bit strange English, but it is started from 2006. It takes from the e-Japan strategy.
In the IP reform strategy, saying to the fiscal year 2008 the government system will move on to IPv6 compatible. For action move, the priority policy program was decided in 2006.
It is - priority policy program, one is IPv6 guideline for e-Government system and each ministry agency makes the transition plan. They investigate the IPv6 correspondence of ISP. Those menus are in the policy program of 2006. The result these strategic programs will be maybe done in the end of May of this year, but I am not sure about when. It is in negotiation inside of government. But this program will be in March of this year.
There is government expectations for IPv6. The biggest one is the end of analogue broadcasting. The TV broadcasting service, now of course, in Japan, was serving with digital and analogue, the both ways. The TV broadcasting service will completely shift to digital. That means analogue TV will stop in 2011.
For movement from analogue to digital, the gap area will become, so the government is planning the IP multicast for the multicast service for those kind of substitutions to fill up that gap area.
Right now, they are doing a trial of IP multicast service. They are already using IPv6.
Second one: social health insurance problem. There is a big scandal by the Social Insurance Agency. The government will make some revolution on the social insurance system in Japan. For actual movement, their medical fee claims will be online. So in those networks, it should be the securest network and, of course, the government is looking for IPv6 to use for the one option.
We have another governmental government. The elimination of broadband zero areas. That is one of movements for the cleaning up digital divide in Japan. Bringing the broadband to every area of Japan.
This slide is, I use it every time. We have three transitions models, a smooth transition for deployment and solution-orientated deployment. We have two IPv6 areas. One is for the closed network and one is IPv6 Internet. But we are very focused on the closed network service because in Japan the closed IPv6 network, business on the IPv6 network is now increasing.
This is IPv6 market in, a real IPv6 business in Japan. We have the first network service provided by East and West for the base network service. We also have IPv6 Internet connectivity option provided by LCN. Application on the closed network, we have media and on-demand TV. It is a service provided on the main FLET network. It is for the consumers.
We have another two IPv6 terminals that are provided by one of the major company stores in Japan, the Family Mart. They built a management system, provided by Panasonic and other companies. Those are two serviced - the two big services. They are systematically easy to move on to IPv6 Internet.
We also have an application on the IPv6 Internet, for example, the IP phone, it is not a business phase.
I like to explain the IP for these businesses. The first network service is a base network. It covers each part of Japan. It has already 5.4 million-plus subscribers in January. It also has optional service that is called FLET service for the east. Those users are right now almost 100,000 subscribers in March.
We - there is broadcasting service, multicast service on the IPv6 is very fast migrated service on IPv6 in Japan.
We already have 50,000 subscribers for each 4th Media and on-demand TV.
This is IPv6 kiosk family service provided by Family Mart. Formerly, they have many contractors between the carriers because they use ISDN for their own kiosk or systems, of course, the regular phone, but they merge it to the FDTH service in FLETs provided by MVP. They reduced the cost and they are using multicast service for sending advertisements to the convenience stores.
This is a building facility system, management system. I think I have already introduced this case in summary - maybe last time.
I like to skip this one. I already talked about it on Monday.
Okay, users of Japanese IPv6 service. We are calculating like this. There is a FLET network users in the top two, NTT East and NTT West. They actually don’t have IPv6 address in the default. If they make a contract with data net service IPv6 service then they will get IPv6 connectivity, but they don't have, but they can have. So we are counting these users as IPv6 ready users.
Of course, the network service and IPv6, Appli, we are not sure how many users are provided. We also have 4th Media and on-demand TV. We totalled them up to the IPv6 users. What we have is 540 million in Japan are IPv6 already. 110,000 users in IPv6 users already.
I heard about the news that NTT East provides IPv6 addresses in default for FLET users. I don't know details about that, but I will check details about it. I will check for the next time. If there that is - if that is true, it may be the truth, but it will count to FLET's users of the 300 million will be counted to the IPv6 users. I don't know - maybe.
We have also IPv6 solutions, IPv6 getting closer to the home. IPv6 routers, home router now in Japan is in a major electrical store, about $120 or so, maybe it is getting more cheaper.
There is a camera also in some stores or we can supply it from the web. About $480. The IPv6 connectivity option that I explained, I already explained is provided by OCN is $3.60 per month. We have IPv6 multicast compatible TV, LCD TV - HD TV. It is mainly for the 4th Media service or on-demand TV - I mean 4th Media service. Now about $1,200.
So, I like to conclude this presentation and in Japan, there are whole commercial IPv6 services for corporate and home users now available. For the consumer of IPv6 connectivity is getting closer, it is open for somewhere. In this I'm calling it will be IPv6, IP market, that is non-IP now, but should be using IP in the near future, like building maintenance or something like that will use IPv6 in a sturdy period. We will contribute to spread IPv6 worldwide. The Promotional Council will focus to ASIA area in this year. That is our objective.
I like to cut this. So thank you for your attention. I like to close this presentation. Thank you very much. APPLAUSE
KAZU YAMAMOTO: Very quick questions?
TAKASHI ARANO: Yeah, I make a small correction to that. 5 million customers of IPv6 of the site is over-counted. So the reality is that two million of sites IPv6 ready. It means two million are going into, to be on site. This is a reality.
KUSUMBA SRIDHAR: You have got a very good model for a transition strategy. I would like to know if you could share more documentation on the three types of strategies that you have published which you have adopted for transition - if yes, where you have published such information?
TAKASHI NAKAMURA: You mean the transition strategy by the Japanese government?
KUSUMBA SRIDHAR: At this moment, to also let the government know the importance of transitioning process.
TAKASHI NAKAMURA: Sorry, we are doing some work belonging to that survey, but right now, it is under construction and I don't know the exact, when will it rebuild exactly - but maybe in the summer or something. We can, of course, provide information about that. But right now, we don't have that much about it. We cannot say not much about it.
KUSUMBA SRIDHAR: Thank you.
KAZU YAMAMOTO: Do you have ability to translate the document to English.
TAKASHI NAKAMURA: That is, um, we cannot say exactly but I think that documents in from Japanese company, some are translated so I hope.
KAZU YAMAMOTO: Sorry, time is running out. Please ask question directly after this session.
TAKASHI NAKAMURA: Yeah, I am waiting. Thank you very much. APPLAUSE.
KAZU YAMAMOTO: Let's get back to John's presentation. His title is IPv6 Status in Indonesia.
JOHN SIHAR: Okay, back again. Sorry for misunderstanding. My name is John Sihar, I'm representing the Indonesia IPv6 task force. So like I said before, we just starting up the IPv6 task force in Indonesia since maybe 2006, middle of September.
What we are trying to do, we really know the urgency of the transition from IPv4 to IPv6. We are starting to set up the IPv6 task force, so the task force is combining with the APJII, the Indonesian association, director general of Postel. We are trying to make some coordination activities to supporting the IPv6 implementation in Indonesia. The main task of encouraging telcos, the operators and also the manufacturer to gain benefit from implementation of the IPv6.
We like to promote the IPv6 as the address for future and we are ensuring the participation of stakeholders, and not only the government, but in terms of interoperability equipment with a lot of cooperation with the association of telecommunication, the founders.
Now, actually, we are in the early pace of IPv6 native network deployment. Because this is really important in terms of national strategy. We try to promote the awareness that IPv6 will replace, maybe, coexist with IPv4 and we try to be aware the ISP network and the IPv4 will be exhausted in the near future, not far from now.
The target is actually, this effort, we like to provide the first IPv6 native network and to perform the function test, of course, DNSV 6 and other services running. And to perform interoperability with equipment and give the opportunity to other network provider or ISP to get connected.
So now, the supporting activities are just maybe, I don't mention some others, just mention some information in the early session, especially for APRICOT we now have the XL operator, provider of 3G services, Indosat, primary backhaul international fibre provider, NTT, BIZNET, and some others, and also our Internet exchange. The design is actually simple. We have some routers and distribution so every ISP can get connected to the facility. They are located in the Cyber Building in Jakarta where the building itself is filled with many ISPs. So maybe half of the ISPs running in Jakarta, they’re centralised, they have networks to other regions in Indonesia so we have a facility on the first floor of the Cyber Building. So we designed it, but what we have now is based on our sponsorship support.
We use not 7206 but 7506 router as the main server. We have some sponsor from Cisco and other participants. Everyone gets connected to this facility.
This is one of the perspectives from one of our trials. XL is the - they have the networks based on Cisco's 726. They have a web router here also. They try to get some ISP Internet, the ISP and CBN and also APJII.
What they do, what they did, I mean, they tried two things. First, they tried tunnelling to the 3G facility, streaming to the 3G network. It is between XL and the other ISP. Since then, everything works well and the second trial is the, based on the network.
They tried to make a tunnel and native network.
So the result is that they succeeded to connect for services of browsing and video streaming. From their direct peering with the other ISP they had success to browse their content located in the other ISP. It is mentioned that the peering connection to Internet, to CBN also is successful for the streaming. The services went well. Also the 3G phone access to Indonet was successful.
They have difficulties in 3G because of lack of equipment, still, cannot have success for that.
The readiness of IPv6 is - since we have a little effort in the last several months, so at least we have now some several ISPs and network operators ready for IPv6. Now we are running the Xchange. This is one of the perspectives from Indosat M2. They have, now they are running. They have connected to the EX and the tunnels to the on-site operator. It is already set up with IM2 Internet.
This is the last one, so this is one of the biggest affordability for IPv6. You see that below is the configuration to this facility in Bali, actually. Now all the network here and WiFi, the dual facility. You see we have IPv6 running on this site also to support us.
I can say that now we are in the first set and in the effort to work through participating between the ISPN operators and work in progress to provide more better and IPv6. This is my short presentation, thank you.
KAZU YAMAMOTO: Any questions? Thank you. APPLAUSE
Let's go to the last agenda. Last one is about draft SIG guidelines. The background of this is we, APNIC, would like to give a chance to be chair and a co-chair to everybody. The SIG chairs and SIG co-chairs have discussed responsibilities of the chair and the co-chairs and the panel chairs and co-chairs.
Already new draft appears. This draft is available from this area. How many of you have red this draft already? Raise your hand? Only a few. Okay. Please read this draft. Please pay attention to these two subsections, electing a chair and a co-chair or removing a chair or co-chair.
This is valid from today. It is not a policy proposal so we don't have to make a policy SIG. I say again, this is valid from today.
Let me explain how to elect a chair or a co-chair. A chair serves for two years. Also, co-chairs serves for two years, basically. We take the staggered chair and co-chair election. This means that co-chairs are elected in the different year of chair election.
Probably, this figure explains it well. This line is chair and this line is co-chair. The chair served for two years and the co-chair serves two years. They are in different years. Understand?
Just one exception. If in case where the chair and the co-chair both started their terms at the same time, the chair serves for two years, and the co-chair serves for one year. Suppose, you know, chair called Alice resigned this time, and co-chair called Bob nominated himself to be the chair, then he will win. Bob will become chair and we call another co-chair called Chris to implement a staggered election system. Chris serves only one year. This make sense? This is just one exception.
How about IPv6 technical SIG? I am chair and for this, please raise your hand? They are co-chairs. We three guys agreed that IPv6 technical SIG will implement the two-year cycle in the next meeting.
That means I will resign, six months later. So call for nomination for chair in August this year and the chair election in September. I mean, in the next meeting. So after IPv6 technical SIG in the next meeting, new chair will be born. Then called for nomination for co-chair in next year and election also in the next year.
Any questions?
I will repeat again: everybody has a chance to be a chair for this SIG or even other SIGs. All SIG of APNIC take this two-year cycle. Everybody can be a chair or co-chair. Understand?
Okay. Again, any questions?
Thank you very much. Lastly, let me explain housekeeping note. As you may know, we have APNIC open reception tonight. The time is 7p.m. at the Jungle Pub area. I believe it is in the same hotel.
It is sponsored by Afilias, thank you very much.
Do not forget, please bring your tickets.
Any questions about open reception?
Next one is you have a chance to win iPod Shuffle. Okay!
Two ways to win. Please visit APNIC service lounge or helpdesk. You can see MyAPNIC and the policy flash demo all day, and if you are lucky you win the iPod Shuffle so please gain access to the APNIC web page. There is a big chance to win an iPod Shuffle. That is it. Any questions or comments at this moment? That is it.
Okay, thank you very much.
Let's conclude IPv6 technical SIG with big hands. Thank you very much. APPLAUSE.
(End of session)
