Transcript

Thursday, August 27 - 0900-1030

MARTIN LEVY: Well, good morning, everybody. Sunny, do you want to say something? OK. I have the mic, officially. It's day three at APNIC. This is the plenary about IPv6 and it's the plenary about IPv6 in 2009, and in keeping with the mindset out of the industry, we're going to hear from four speakers, four excellent speakers about what's happening with IPv6 from a practical point of view from real and not theoretical point of view, of dealing with real requirements in the industry. They all have business overtones, they all have a requirement for allowing business to continue, and to grow. Obviously, that encompasses quite a spectrum. We're going to start off with Professor Li to talk about work that is going on in the research environment that has to be done in order to go into the real world, to serve real world problems.

We're going to hear about content from Tomoya-San and the practical issues of bringing content into the v6 world. Tomochika from NTT is going to talk about the enterprise requirements. That really is a business point of view, 100%. And then Christian is going to talk about the backbone, the ISP, the issues involved in the players that have to bring IPv6 to the end-users.

So the key part here is to hear four different points of view all trying to go to the same end point of business. And business continuity. We've got that full range, and just to remind you of one last thing before we start hearing this, this is 2009. At this point, it isn't about the theoretical talks and the conceptual talks - it's about doing business and that's what we're going to hear today. So, I'm going to ask Professor Li, first up, to talk about his IVI test.

XING LI: Good morning. OK, today I would talk to talk about the transition to IPv6 operation experiments and our prospective. And welcome to China, because I'm located in this China running the China Education Research Network, so I would like to talk a little bit about our IPv6 history and operational experience. Then I will focus on the transition to IPv6.

Actually, we have a IPv6 backbone, or a IPv6-only IPv6 bone. And we try schemes, and finally, our hope is the translation scheme and some remarks.

So, our IPv6 history back to 1998. So, about 12 years ago. And currently, we're part of the big work sheet in China called CNGI. Yesterday, many Chinese speakers mentioned that, which is actually the China Next Generation Internet. That involves the China Education Research, China Telecom, China Unicom and China Academy of Sciences and other networks. However, I would like to mention one thing. Other networks are seen by backbones as dual stack. But only CERNET is pure IPv6. I will give you the reasons. So, this is the CNGI CERNET 2 backbone.

We have 10 G and 2.5 G links dedicate. In the country, we have about 200 networks connected to our pure IPv6 backbone. And the design philosophy of CERNET 2, CNGI, CERNET 2 backbone. First, the unique feature is that it is a pure IPv6 backbone.

By the way, actually, we have another backbone called CERNET which is IPv4. So, when we started CERNET 2 project, if it is dual stack and we believe nobody will use IPv6. They will keep using IPv4. Both on CERNET and CERNET 2. So, we decide that we will build a pure IPv6 backbone and find new things. And the second, actually, that's quite different from yesterday's presentation. The design philosophy of CERNET 2 is that we try to get multiple vendors. The reason is that IPv6, if you test bad, it's no problem. However, a real, completed, complex network, you will find problems in that CERNET 2 is a test. So we need chaotic situation to test IPv6.

Also, it is a multiple AS network, and we tried something unique. The transition, actually, we tried two things. One thing is that others doing IPv6 over IPv4. But in CERNET 2 backbone, we are a pure IPv6 backbone, so we tried IPv4 over IPv6, and that turned into one of the solutions in the IETF software. And the recently, we try IVI. I'll go back to this later, and we are quite actively involved in the IETF behaviour working group. And in the architecture, we do something called source address validation improvement. That's another story, I will not discuss that.

And then the original design of CERNET 2, actually, we thought there are three possibilities. One is native IPv6, the top one. And the second one, we can do IPv4 over IPv6 if users are running IPv4. And the possibilities translate from IPv4 to IPv6 and they translate back. And you may be wondering, what is the traffic pattern of CERNET and CERNET 2. For CERNET it is IPv4 and for CERNET 2 it is IPv6. The overall the pure IPv6 traffic, and the traffic allows video streaming and there you can see the video streaming there.

By the way, in this room, actually, you can access IPv6 and you can try the CERNET 2 IPv6 videos.

OK, let's go back to the main thing I'm going to talk about toad - the transition to IPv6. The IPv4 address depletion problem - yeah. And dual stack is not practical, because at some stage, if you want to run dual stack, you do not have enough IPv4 addresses. Then, how about net for IPv4? In that case, you reach most parts of the IPv4 Internet and you do not have the motivation to using the IPv6. So, no way for transition. And the IPv4 over IPv6, as I mentioned in the IETF software working group, that can solve part of the problem. However, still, you can not bridge IPv4 and the IPv6.

However, translation is quite difficult because IPv4 and IPv6 are different particles. So, depletion problem - and also, yesterday, many people mentioned. This is quite, quite important for China for the four depletion problem, because the number of Internet users in China has reached the number one in the world. However, the Internet penetration is still about average, so, probably in the next three years, there will be double or more than three times the Internet population. Definitely, there is not enough IPv4 address for China. For example, China Telecom, they told me that they would have about 10 million ADS users every year, so that's the number of the increase.

So we try IPv4 over IPv6. By the way, that's a very famous figure of the IPv6 road map. Right, originally, we have IPv4 only and the IPv6 test. And in the future, at some stage, we will have IPv6-only network. OK, IPv4-only. Good. IPv6-only - perfect. However, in the intermediate stage, we will have two networks. That's the problem. Like, if you won't have a bright future, then you have to have a natural way to go and the past the intermediate stage. However, if there are two networks, ISPs how to decide if you have enough unlimited money, no problem. We can deploy dual stack. However, if you have limited resource and if you run dual stack or whatever IPv6, you spend money but you do not have customers. You do not have information resources.

So, definitely for the perspective, the ISP, we will spend money on IPv4, even using the net rather than go to IPv6. So, that's the problem. We need to have a bridging IPv4 and IPv6. Not really the bridging in networking thing, but like we need to make IPv4 and IPv6 communicate. And for CERNET, as I mentioned earlier, we have CERNET, which is IPv4, and we built CERNET 2 which is the IPv6 network. Pure IPv6 network.

The original promotion strategy is, OK, CERNET IPv4 - we have many customers. More than 2,000 universities connected to CERNET. So, CERNET is quite a congested network, and also, we are self-funded, so the university, even Professors and students need to pay for using CERNET. However, CERNET 2, we got money from the Government. It is light-loaded, so very high performance, and actually, it is free. But, it is IPv6. Our original idea is, OK, we give you a free network, and it is light-loaded, so high performance. How about you convert your application from IPv4 to IPv6? So you can enjoy a free lunch? That's our original idea. However, in reality, our users, rather like to use the congested IPv4, and they would rather to use the network and pay for that rather than using the free high-performance IPv6.

What's the reason? Because the network is for linking people, for communication. If we have something new, we can use ourselves. No problem. You can enjoy the free lunch. However, you need to communicate with something else, and the other end of using IPv4, definitely, your purpose is communicating with IPv4, if that is it, I with use IPv4, not IPv6 so, our original plan does not work, and that's why we get into the idea. We need a translator to link IPv4 and IPv6, so, even the users using IPv6, however they can still communicate with the global IPv4 Internet. The other one is that if you have the CERNET 2 IPv6, the server can be accessed by the global Internet. That's another direction. Both directions are important.

So, it is a very difficult problem, because the extremely huge of the IPv6 address space, compared with the limited four billion IPv4.

However, in this process, at some stage, we realize actually, we do not need such a huge amount of IPv6 address at the initial stage, because we have very limited IPv6 users. How about we use a subset of the IPv6 address. However, this subset of the IPv6 address, we have a unique relationship with part of the IPv4 address. So, actually, we can use that part of IPv4 as the represented of the subset of IPv6. And well, the other side we can have is the global IPv6 address into a subset of the IPv6, and use that IPv6 as the representer of the global IPv4. So, that's the idea. In that case, actually, for subset of the IPv6 address, through a translator, we can communicate with IPv4 in a stateless fashion, because there's a unique relationship.

Also, this part of the IPv6, it is the real IPv6 address, so that part can communicate with the global part of IPv6. Then, this subset of the IPv6 is very good address space because you can communicate with IPv4 and IPv6.

By the way, you may be wondering, what is the meaning of IVI? So, IV means 4 and VI means 6, so it is going between IPv4 and IPv6. My students got that idea! So, the scheme is very simple, because IPv6, a huge address space, and the we're using the service provider specific IPv6 address, and it's an embedded global IPv4 into that potion, so that's the idea you can see, and by the way, you can download the slide, so I will not go into the details to give you this example. Rather, there's a conceptual thing. OK, so you can see the global IPv4, and you can see, you can have a global IPv6. However, we are focusing on the ISPs. IPv6 space. Generally speaking, that's a /32 of the ISP address space. So, we can embed the global IPv4 into the service provider IPv6 address.

That's a one side story. The interesting side is that for ISP, you have your own IPv4 blocks, and that IPv4 blocks are located from APNIC, for example it's part of the global IPv4. So actually, it's two parts of mirroring or a mapping process. One part is - actually, you can use, you can not use this part of the IPv6 address, because that's the representer of the IPv4 address.

OK, on the other hand, you have your own IPv4 block, probably a slash /24 or a /16. You can not use that, because that's the holder of the IPv6 address. So, you use that part, convert it into IPv6 and use that address in IPv6. So, part of the IPv6, you can not use. That's the holder of the global IPv4. And the part of you with the IPv4 address, you can not use that in IPv4, you use that in IPv6. So, that's the idea. And the practical translation is simple. We need the transport header to check the update. We need to hand over fragmentation to MTU and those kinds of things. You can see the drafts in the working group there.

Then, routing is quite simple. Actually, the IVI gateway between IPv4 and IPv6, it can speak BGP. IPv4 BGP and IPv6 BGP, and the nice thing is, actually, you can see. This IPv4 address, actually, you can not use that. So the IVI gateway announces that gateway from IPv6. That's the holder of that. If your destination is this part of the address. That's the IPv6 address, and the global IPv4 actually announced - like in the example, it is a /40, so, that's the holder of the IPv4 state list. Very nice routing. And the DNS, there are two DNS schemes. One is called DNS 46 and the other is called DNS 64. So, because the original IPv4 address, for example, if you are using IPv6, then you need to convert a record into a record, that's the use of DNS 64.

And because that's a IPv6. When the global IPv4 needs to access that, then you need to translate that. Because in that case, that's your own IPv4 address. Because you do not really need translation, you can do configuration, you can do it like you configure dual stack. And actually, the simple mode is 1:1 mapping, we call it stateless. The mapping between IPv4 and the IPv6 is based on the algorithm. You can may argue that there's no use for that, because we have a limited way, and you borrow the IPv4 and using IPv6. Still, we are facing the depletion problem, and you can not solve the problem, right. So actually, we have another scheme called IVI (1:N). That's similar to what we're using. We use the address, plus the transport port number to do the mapping, so several IPv6 addresses can share a common IPv4.

And because we have a big IPv6 address, actually, we can not only embed the IPv4 address into IPv6, and in addition, we can embed the port, encoding information into the IPv6 address. So, we do not need a signalling scheme. We do not need anything. If you have a IPv6 address, you know which port you can use. Which port you can not use. So, these skills can be used in implementing your home gateway. As an additional layer operating systems. So, this draft is not released, but definitely, we will upload and post into the IETF website before the next IETF meeting. And so, what we are doing currently, we are implementing IVI in CERNET 2 in a larger scale.

Basically, we're trying to move forward to implement IVI for 100 universities, so that ace the scheme, and that's the mappings address. Real IPv4 address block, and we're not using the IPv4, but using IPv6. You can see the universities there. Sorry, it's Chinese, but you can have the feeling.

So, it's back to the discussion. Transition mechanisms. There are several things we can do. The first, the possibilities, IPv4 plus net as a short-term solution. You introduce the state form scheme. Scalability is a problem. And the second is pure IPv6, that's our original design. However, that can not reach the global IPv4.

And dual stack, another discussion for this is the cost when implementing dual stack to actually increase, and the ISP wants others to deploy dual stack. What does this word mean? Actually, imagine if everybody employed dual stack, then, you, yourself, do not need dual stack. If you have IPv4 and IPv6, you can communicate with others. So every ISP is actually waiting. Waiting for others to deploy IPv6, and then I can get a good, I don't need to do it in the first stage. And we believe that IVI is the good approach because the cost is the same as a single stack operation, you do not need to run dual stack. But the host can be reached by global IPv4. So, that's the thing. Somebody employs dual stack. Dual stack can communicate with IPv4 and IPv6.

However, the cost is high, and v4 and v6 can not communicate. If IVI, then, actually the subset of IPv6 can talk to IPv4, IPv6 and the dual stack, so that's a good thing. And that encourages translation. So, our idea is - the current approach is IPv4 is IPv4, and IPv6 is IPv6. There is no natural link between v4 and v6. However, in your mind, we should borrow or use part of the IPv4 and translate into IPv6 and use IPv6. So, like the IPv6 address is a natural extension of IPv4. There is a relationship. If an ISP can do this kind of process, incrementally and you do that and you do not need others to do it. And you are using in IPv6 to translates the address, it to communicate between IPv4 and IPv6. If every ISP moves the IPv4 into IPv6 there. And finally, maybe the whole IPv4 address are using it in IPv6 within the translation, and this may take ten years, 20 years.

It doesn't matter, because this address can communicate with IPv4 and IPv6. And by the way, in the IETF, you are working interesting with IETF, activities actually for transition. The translation scheme of transition, there are eight scenarios. Scenario one is IPv6 to IPv4 network and the approach of IVI and the shrinked version of net PT. And for scenario two, the IPv4 network to the IPv6 network. IVI can work. So you can see those kinds of scenarios. And the document structure, there will be a frame work to describe the IPv4 and IPv6 translation, then it is a translation scheme to require the address translation document. And the DNS one, and for that like NAT four. Also, there are FTP 'ALG multicast. And if you're interested, I encourage you to go to this URL.

You can download it which is a part of the links. And you can get the source code and try and you can have some tech servers and some links to the IETF drafts. And by the way, I heard, Internet 2, they run five workshops already to provide access in using IVI scheme. So, two remarks... actually, that's the thing that bothers us a lot, but finally, this is our conclusion. We're always using for applications of IPv6. Video, P 2 P and my the current understanding of IPv4 to IPv6. If you deploy your IPv6 network and the users do not have any problem, they are thinking that they're using IPv4. There's the killer application of IPv6, nothing else. So, that's our understanding at this stage, and secondly, actually because we're in the APNIC meeting so actually, we suggest that you use the remaining block for the IPv4 to IPv6 translation.

That's the stage where we have to make a translation. Otherwise f we still stay in dual stack, I can not see the increase, the dramatic increase of the IPv6. Thank you very much.

APPLAUSE

MARTIN LEVY: If you're wondering, yes, we are going to take a few extra minutes for this session. I think that is the norm for the first sessions of the day!

Thank you, Professor. Toyama-San from JPNIC is going to talk about content and more, so, we're now moving to a different area of the IPv6 world.

KATSUYASU TOYAMA: Good morning, I'm from JPNAP and today I would like to talk about the IPv6 deployment on the content side and today's talk is based on the trial, the joint trial with a Japanese newspaper company. And some of my talk is on behalf of the Nikkei people. So, maybe you know the name of the Nikkei, the famous newspaper and media group. Especially famous for the economic or business side.

And Internet multifeed is providing exchange point services in Japan.

So today, let's talk about these kinds of things. And first, I would like to talk about the background. So, if you think of Japan as an advanced country regarding IPv6. A lot of people are using IPv6. This is true, but to some part, this is a myth. Because this IPv6 is not for the Internet, but for the closed service by NTT East and West. And there are some ISP which provide IPv6 Internet, which will be there. But still, the users are very few.

, So when, does the IPv6 Internet come in Japan? I think it will start increasing from 2011. This time as NTT East and West will begin the IPv6 Internet access service for all of the ISPs. And, I think it will take a few more years before IPv6 becomes popular in Japan. Many users, many people are using IPv6, they need nor years. So, in this environment, content providers can not be positive to support IPv6. But maybe, the content providers feel that they have to, but from the business reasons, they can not do that kind of thing, OK.

So, the motivation of our trial - so, from the content provider's view, it should not affect current IPv4 service because this is currently a cash cow. They earn money from the users. For example, they have to look at the end-users and look at the delivery of the content. Especially that they earn money from the ads. And also, they have a system to produce and manage their content, so, with the IPv6 support, it may impact on their systems, but then they have now no motivation to invest in the modification, so, this is the current content providers' view. So, they also know - I think, they have to in the future, and in the final goal, they have to be dual stack. But, they like to touch the current IPv4 system. But before that, there's a period in this area.

So, there are very few, but then substantial IPv6 access from the end-users. So, we have to fill in the gap. So, this time, we think that one problem approach. So, content providers using the current web servers system on the IPv4, and put some translator or reverse proxy in front of the web service and accept the access from the IPv6 area.

So, our motivation I'll describe on this slide. The Nikkei group, they are as a content provider, trying to try some possible ways to support IPv6 in the Nikkei Net. The network services. So, their concern, one of their concerns is the complex content is affected by the user of IPv6 or not. And sometimes, they want to use the different URLs for IPv4 and IPv6. So, sometimes the reverse proxy must see the URL. And with an area feed with the data centre services, would like to explore the possibilities of the IPv4, IPv6 translation services or reverse proxy services to our customers. So, it is kind of working well and this is valuable to the customers or any resolution about the content, so we like to know such things. So the Nikkei group and we agreed to do a joint experiment on the deployment of the IPv6 on the content side.

So, we do the two experiments in parallel. The Nikkei's experiment is from the content providers so they use different URLs for IPv6 and IPv4. But because, as I explained, the current IPv4 services is very important to them, so, when they when they use the same URLs, it may affect the current IPv4 services. So, at this point in time, we have to choose this approach. And the experiment is based on the reverse proxy with rewriting URLs.

On the other hand, the multi-experiment is using the same URLs for IPv4 and IPv6, and we tried to first use the translators. So we do the two experiments in parallel. So, to explain what is on the slide. These are the current IPv4 services and usually users are accessing from the IPv4 Internet. And you know, in the data centre, we put the translator and the reverse proxies in front of them, or in front of our network and these are accessing through these boxes from the IPv6 clients. And at this time, we assume that there is IPv6-only involvement, because maybe in the near future, this involvement will be a dual stack, or maybe a large scale NAT or some kind of thing, but only IPv6 involvement is a most severe situation for involvement, so we tested this environment.

The Nikkei's content is complex. So, why is the Nikkei content is complex? I would like to explain. The Nikkei's content is comprised of multiple URLs, approximately 160 parts, including pictures, CSS, JavaScript and so on. And also, the use of the ASP services from other companies. Just where we can log analysis and ads and movies. And also, they have a lot of JavaScript or AJAX content in the program, so they're making the content dynamically, and they're using the Flash and communicating with other sites dynamically. And so, this is very complex, and it may be affected by IPv6 deployment.

So, the Nikkei's experiment started, as I explained. They would the current IPv6 and IPv4 contents and the URL, just like in Google's IPv6 Google.com. And they would like to avoid IPv6 to four fall back programs. And, no modifications on the current content management system. And, the URL for IPv6 is there. Think prefix the IPv6 to the current URLs. And they implement their own reverse proxies, which translate, which rely on the URLs in the htmls to modify the URLs. So, this figure shows the sequence. There are sequences. Of reverse proxies.

And our experiment, assuming that Nikkei.NET is a customer of one of our translation services. And we use the same URL for both IPv6 and IPv4, so we prepared two types of our experiment. One is using the DNS service, which replies IPv6 addresses and the other one is using the DNS 'LG.

So, this is a rough sequence about our experiment. And our translator used these translators.

So, this experiment is ongoing. We started this project in January, but we will continue this experiment for more time. So, at this point in time, this result is a kind of an interim.

So, the Nikkei's findings is the content. The content is very complex but there is no big difference between IPv6 and IPv4 and they're almost the same content. So, the dynamic content using the Flash or the JavaScript or AJAX. So the kind of things that mainly do not affect it. OK, and the separate URLs for IPv6 is generally OK. Mainly the content under our Nikkei.co.jp, but sometimes we're able to write the URLs in binary code of Flash. So, this is one of the important things to be careful about IPv6, OK.

And also, handling ASPs is an unsolved problem. So, if the outside ASPs do not support the IPv6 at the time of this approach, sometimes it does not work. And, on the other hand, on the MF's side, the experiment, also, we can get the same result as the Nikkei. The Nikkei content can be almost without any issues. But, under some other domains, the content of some other domains, sometimes can not be displayed. For example, this one here. This one should be - the advertisement should be this one here, but this one is not displayed.

And another important issue is the MTU. So, we used the translator and sometimes the MTU becomes a very big problem. And this is not a Nikkei service, but we tried some other real IPv4 servers on the Internet. And these kinds of approaches is there. And some of the servers on the IPv4 Internet, it does answer or respond to the ICMP message about our MTU. So, some of them are still the same after receiving the ICMP message, still using the large MTU. So, the communications can not be down.

So, if we take this approach, we have to require translators to see it. This is not written in the RFCs. So, what do the content providers do? So, if they have not the motivations to support the IPv6 now, at least they should do their analysis of their risks about the IPv4 depletion. So, what if IPv4 addresses can not be obtained? What part of your system should be modified for IPv6 if IPv6 access is increased. So, it is kind of a risk analysis which should be done on the content slide. And from that point of view, the content providers should do and start discussions with upstream ISPs, because they provide the content providers with the other resources and also, they show the road maps to IPv6.

So, of course, inside the content providers, they have to analyse the production system or the management system of the content should be checked, OK.

And if this Nikkei case, this Nikkei case, they have to choose a separate URL. But they want to use the same URL. This is better. This is now a very big issue here. And for that, they expect ASPs to support IPv6 in the same way and at the same time as the content providers do. Oh, especially if they wish the Google to start IPv6.

And for the data centres, the translator or reverse proxy would be an option for the data centre customers. This service is kind of a temporary one but this is an option for the data centres. OK, thank you very much.

MARTIN LEVY: Compatibility? OK. Um, Christian will talk from the ISP and backbone area. We have talked about access methods. Now it's time to look at the ability to bring IPv6 in to commercial reasons with inside the primary method that end-users use to connect to the Internet, through the ISPs, through the backbone. Christian, your time.

CHRISTIAN DWINANTYO: Thank you. I'm Christian from D-NET. I work as a network operations manager. Today I'm going to talk about how D-NET Jakarta implemented IPv6. I will share my experience adopting IPv6. And how we decided IPv6 adoptions, transition plans, and our future plans regarding IPv6 in a practical point of view.

D-NET is one of the first ISPs in Indonesia. And we're based in Jakarta. We focus on corporate customers who need what we call dedicated Internet connections. And other services include wireless. Right now, you can see D-NET is allocated with/32 IPv6 allocations. In Indonesia, that's a glimpse about D-NET.

In 2006, we are not the first to deploy IPv6 but there were only maybe three or four ISP connected to IPv6 at that time. Maybe it's different in other countries, but in Indonesia, ISPs are struggling to convince their board directors to deploy IPv6. But what happened at D-NET was the opposite. They seem fully aware of IPv4. Only a /8 of IPv4 remaining. We feel we stay ahead of the game. The resistance actually came from the engineers. From the engineers' point of view, we knew that IPv4 is near exhaustion. But we also knew that IPv6 is completely separate and it works and it's not an extension of curing IPv4.

When we run out of IPv4, the Internet will stop working. Back then, we didn't see any reason why we have to deploy IPv6 immediately, as there were no customer demands, no applications known to support IPv6. Because the decision was made by our board, it was agreed we had to deploy.

So, the first step, of course, is to request for IPv6 allocation. We had our first IPv6 allocation in 2006. And then we made an inventory of our current assets which currently support IPv6. Ones that will be upgraded and so on.

Basically, what we have to do is do this. In the link in the slide, you can see.

OK, that's that. Choosing transition method. We know there are at least three methods in IPv6 transition and I think there are many debates about which methods are better for our own environment? But in my case, in our case, IPv6 network is not possible at the moment. Maybe in the next 5-10 years, we still cannot live without IPv4.

IPv6 tunnelling is not scalable for production purpose. It has more complex configuration and we have to monitor our tunnel for IPv6 traffic.

So my methods are different from Xing 'Li's. We think if we provide smoother IPv4 to IPv6 transition because we can still maintain IPv4 compatibility and if you decide to run full IPv6, you just have to remove the IPv4 configuration.

The next step is human resource. We have to get our engineers' knowledge about IPv6. We send our engineers to attend some meetings, groups sharing about IPv6 different options. And there were a few recommendations, and we used these. They're not only technical training, but non-technical discussion and group meetings about IPv6 adoption improvement. Using IPv6 for their companies.

Then we just, our company, - IPv6 in the near future, at least get the compatibility and in their future projects. We don't want to add something in our network and then later find it can be used thin dual stack environment.

Configuring this in the interface. It can be done in protocols. I can say it's possible in implementing dual stack.

Planning transition phase. This is the transition phase. We divide them in to three phases. Basically, the first phase is to implement it on our network. The second phase is DNS and web services. And third phase is dual stack on our end-users.

This is our global topology. We have routers connected to IPv4 transit and distributed to customer gateway and we have Internet services.

OK. First place, we only need to set up dual stack on the router interface and then set up IPv6 connection through provider in and reality it only took 5-10 minutes on each router. And the second phase is our server and networks for them experience IPv6. Some are using Windows XP and Windows X P do not support IPv6 DNS because we have a dual stack, so they can access DNS through their IPv4 stack.

My firewall - only partially supported IPv6 in 2005. Routers and access lists and better support IPv6. Then we set up an AAAA records for our domain. They already support IPv6 for a long time, I think.

Then we set up on our virtual hosts on our web. And it's to make the stack a standard, to build a customer gateway. And we - it's not going to be easy and cheap if you do it all at once. And we plan to secure a budget and of course for new customers, we will use ISPs that already support dual stack.

OK, there are security and challenges. Security is one of our major challenges of deploying IPv6. As IPv4 and IPv6 are separate networks, we have the same security for its network, the same security rules must be applied. So far if someone or otherwise you're very much welcome to share if you have any ideas.

There were times of fear for security breach and we turned off our IPv6 stack every time we finished experimenting with IPv6 in our network.

Next IPv6 management. IPv6 is abundant. We can't manage them or treat them the same way as IPv4. RFC spp 3177 /48, is suggested for most customers. We define our /22s in to a /40. We have many /48s as you can see in the slides. We have different opinions and different views. And we are interested in learning.

I'm not going to speak much about this. I think maybe it's not a real problem because we still have time to allocate them.

Now what did we do after we deployed IPv6? We tried to list our website with several IPv6 website lists because we feel by obtaining this logo, it may enable ISP with IPv6 and can mostly increase our staff confidence for D-NET's future group.

A recent example is www.ipv6 forum.com. You have to have several tests before you can use it. But once you have the Logo, and prove the website can be seen in IPv6 network.

These are some examples of IPv6 enabled website list. If you're an ISP in this list, perhaps you can let people know your ISP is IPv6 ready and to adopt IPv6 as well. We also educate our staff so they can share their knowledge about IPv6 and to increase their visions about the future Internet business model. OK. This is the screen capture of our website. You can see the IPv6 regular logo on it. If you visit our website from IPv6 stack, you can see your IPv6 in the upper right of the website.

And this is the screen capture from www.sixxs.net. Our future plans - we do multiroaming and there's only a few providers that have the connectivity. Once they're available, we will plan to upgrade them and we will plan our connections to dual stack. I haven't seen many mail examples of this with IPv6. It's a much complex system, so deploying IPv6 in our system will take some time.

And our IPv6 traffic is not monitored. This is because we use the same interface in our routers for IPv4 and IPv6 and our firewall does not support IPv6-snmp. Currently, we can't separately manage its traffic. This is something we're working on.

I have slides and it appears that how to define IPv6 DFZ yet. It's not clear yet. And the problem may be, will be the future of IPv6 routing table size.

So our conclusions - after we experienced adopting IPv6, our engineers realized there's a lot of problems we still have to face to adopt IPv6. If we do not start now, it will take longer to adopt IPv6. However, for starters, it's very easy. And deploying IPv6 is not about customer demand. If you wait for customer asking for it, you probably will never get any. Why? Because we think most customers do not know or do not care what version of IP they're using. As long as they can check their emails or whatever they're doing on the Internet, I don't think they care. It's about readiness of our network, to secure our future growth of our business.

And dual stack in my opinion is probably the best option to start migrating to IPv6. And small-medium size ISP is usually easy in the budgets. It's good we don't have to migrate our hardware all at once. If your hardware that you're using is not IPv6 compatible, you can do this.

OK, I thought there are not many people in IPv6 networks right now compared to IPv4. But that doesn't mean that we can underestimate the security aspect in designing IPv6 network. Applying IPv6 in the network could result in a system. Educate your staff in planned manner, in technical and non-technical issues, to broaden their knowledge. APNIC has a website that contains very useful and very comprehensive information in to IPv6 migration that help us a lot through this process.

For some reflections, we have no idea how the future IPv6 routing table size will be like in relation to prop-076. Require aggregation for IPv6 subsequent allocations with purpose to suppress IPv6 future table size. It creates other problems such as limiting ISP's multihoming capability.

Another thing from the ISP side, to promote IPv6 transition, I think we need to widen your IPv6 network, then you will have more traffic in IPv6, so in the end you can prove to the community that believe IPv6 traffic does exist. We hope that somebody will be motivated to start migrating in to IPv6.

The last question would be, after D-NET is IPv6 ready, what now? How can we approach our enterprise customers? I'm interested to hearing your comments and thoughts as well. Also, from our next speaker, about ISP support to enterprise customers. After the session, if you'd like to have discussion, you are very welcome. Thank you.

APPLAUSE

MARTIN LEVY: Christian, I want to repeat something from your talk. You said "It's not about customer demand, it's about securing the future growth for your company." Can I repeat that one more time? Have people heard this before and want to hear it again and again and again until everybody's heard it? Take it back to your management. "It's not about customer demand. It's about securing future growth for your company." This is the point when that should be ingrained. At our level, at management level, at every level.

OK, our final talk out of this session from Takeshi'Tomochika. From NTT, takes us now to the final level worth talking about - the enterprise customer. The enterprise customer obviously is a good revenue base for a lot of companies. But also it maybe one of the harder things to address in the IPv6 world. So we're going to hear about a company that has addressed that. How they've addressed it and some of the lessons learnt.

TAKESHI TOMOCHIKA: I'm sorry, thank you, Martin. I'm Takeshi'Tomochika. I'm a manager and and I, many ISPs have already supported IPv6. However, few enterprise customers have supported IPv6. Then today I'd like to talk how ISP support for enterprise customers during IPv6 deployment.

This is the outline of my introduction. There are 31 slides but I have only 20 minutes so I focus on important parts. I can introduce NTT 'communications IPv6 activities quickly.

NTT communications is one of the biggest subsidiary of NTT shareholder company. We're in charge of long-distance and international communications, including other services. We have two IP backbone networks. One is NTT.net. The other is OCN for Japanese domestic customers.

This slide shows NTT communications IPv6's history. We have a long IPv6 history. Now we have many IPv6 services such as Internet services, VPN and other solutions. This line shows ranking of query type from end users and growth from May 2009 and growth of this. You can see 20% of the DNS queries is AAAA.

However, the rate of IPv6 response when our servers query AAAA is only 90%. This is only one of 500 queries. That is to say few servers have configured AAA for FQDN. This shows rate of IPv6 servers is still few. From now on, I will talk about five checkpoints in IPv6 adoption plan for enterprise networks. First, let's begin considering impacts of IPv4 address exhaustion for enterprise networks.

IPv4 exhaustion records far more difficulty in getting additional addresses for public servers. Additional Internet VPN edge sites, it makes it difficult to add new branches in to internet VPN. We're bringing about growing user IPv6 and external IPv6-only users way to communicate with external IPv6 only servers. A way to use IPv6-based applications and equipment in the future.

Considering these impacts of IPv4 exhaustion is an adoption plan for enterprise networks. There are five checkpoints which this slide indicates.

First this is a matter of course but enterprise users should think about external connectivity for IPv6 external connection. Enterprise users should consider public servers for incoming access from external IPv6-only users. Third, enterprise should think about gateway proxy for outgoing access to external IPv6-only servers. Fourth, enterprise should consider IPv6 VPN connection for additional Internet VPN, IPsec 'VPN edge sites. And fifth - enterprise should think about IP-VPN/layer 2 VPN connection for using IPv6-based applications.

This slide shows mapping between the checkpoints and impacts I explained.

For example, considering public server of B will resolve the difficulty in getting new IP address for additional public servers. In this case, we should also consider external connectivity of A. Because A is based on concerning B.

So I'll talk about each of these five checkpoints in detail. First, enterprise users should think about external connectivity of IPv6 capable ISP connectivity services. Now many ISPs have already begun to offer connectivity service for enterprises and there are three types of connections. Tunnel, native, which is IPv6 only and IPv6/IPv4 dual stack. Price and impacts on existing network are most sensitive. Most enterprise customers request tunnel connection for price. Typically, they ISP customers tend to request dual stack. Enterprise users should think about public servers. As I explained, this has two purposes. There are two kinds of solutions for this. The first solution is to use IPv6 before translation box. The second solution is to make the servers IPv6 capable because of type of servers.

Translation box is useful in many cases. In some cases, it's better to make the servers IPv6 capable. When enterprise public servers use hosting services which host IPv6. Solution B is much easier. It depends.

Third, enterprise users should consider how to communicate with external IP basics only servers. For this there are two solutions. The first solution is to use translators such as proxy servers for IPv6 external contents. The second solution is to implement IPv6 which means dual stack in enterprise network, including PCs. This slide shows they have trade-off. So considering these trade-offs, enterprise users should choose the right solution.

Fourth, enterprise users should think about IPv6 VPN. Because after IPv4 global address exhaustion, adding new branches with IPsec 'VPN connection. And encrypting this version of IPv6. This solution can be quite common right now.

Finally, this is a bit of a future look. IP-VPN layer 2 VPN for connection for using IPv6-based applications. These slides indicate one of IP-VPN which is 6 VPE model. And they have already started to provide this using this model. By this model, core devices are not affected for IPv6 adoption.

Well, let me talk about the issues very quickly. This shows some of the issues when users deploy IPv6. It's more or less different from IPv4. Therefore, we have to keep eyes on these issues such as implementing of easy multi-homing. Firewall and closed networks. And previous speaker has explained this. Operational system - and management of address assignment for clients.

OK, I'd like my presentation to end up with a case study using the five checkpoints which I explained.

This video shows a structure of XYZ corporation. These companies inquiries say IPv4 exhaustion must come but what impacts would they have? We explained slide 9 - impacts of IPv4 address exhaustion for enterprise networks. And then their requirements were like this. They wanted to achieve the same activities with IPv6 as they did with IPv4. They required that public servers can be accessed by IPv6. And in addition to corporate backbone their development department wanted another connectivity for evaluation and testing IPv6.

First, we thought about external connectivity for IPv6 Internet connection. And there are three solutions - tunnel, native and IPv6/IPv4 dual stack. This customer was most sensitive to the price. We offered tunnel service for business for existing network. And we offered another cheap FTTH connectivity with cheap tunnel service called OCN IPv6. It is very difficult that the department want their own connection.

Second, we considered public servers for incoming access from external IPv6-only users. There are two solutions. This customer didn't want to make any change in servers. Consequently, we offered v6 to v4 server load balancer. Translators have difficulty in handling embedded IP addresses in payload. Therefore, checking and test or modification for contents was required.

Third, we thought over gateway proxy for outgoing access to external IPv6-only servers. And there are two solutions, as you know now. This customer didn't want to make any changes in enterprise network, including PCs. Hence, we offered proxy server. Also, there is attention, which is regarding proxy server, many of open source softwares and softwares have already supported IPv6. Why, appliance products try to support IPv6 now?

Checkpoint D and E were different for customers. Their motivation to use IPv6 for VPN. Some of other customers want to merge branches. In this case, IPv4 private address sometimes can overlap. Using NAT boxes can solve this problem, even though it will make complicated network and can't ping to nodes beyond NAT. In this case, we recommend to use IPv6 which introduce future-ready network, clear view on the network with IPv6 flat addressing and IPv6 multicast supported network. This

This is the conclusion of my presentation. First, IPv4 address exhaustion have large impacts on enterprise network, like IPv4 address exhaustion affects not only the company setting up new network, but also the one having their existing IPv4 network. IT Cycle, from planning implementation may take about two years, consequently, enterprise users should consider IPv6 deployment right now.

Second, there are remaining issues. Accordingly, we have to keep our eyes on remaining issues.

Finally, I presented five checkpoints in IPv6 adoption plan for enterprise networks. ISPs and system integrators can support enterprise customers IPv6 adoption plan by consideration of the 5 checkpoints.

This is the end of my presentation. Thank you for your attention.

APPLAUSE

MARTIN LEVY: We have time for questions. Here's your motivation for questions - if you don't stand up and ask them, I'll do them. I could go on for quite a while. So, I'm actually going to go, Christian, I have a quick question on something that you put in your talk. You talked about in regards to your early stages that you turned off v6 if you thought there was a threat issue or something unknown. Has that been something that you have now moved away from? Are you comfortable with v6 on all the time? Are you comfortable with your security model for v4 and v6? Are they equivalent in your network today?

CHRISTIAN DWINANTYO: Right now it's not really equivalent to our network today. But I think we're pretty comfortable with our security for IPv6 network right now.

MARTIN LEVY: I still don't see - are you really keen on the tea break? Is that the problem here? OK. I'm sorry, I'm going to continue then.

So, and I have lots of notes - Tomichika, you talk about using IPv6 in the IPv6 world. This is considered to be one of the core offerings within inside the v6 world, without larger addressing. Any connectivity to IP-sec inside the protocol right from the beginning. Did you see for enterprise customers an advantage, even though as you pointed out, you were doing IPv4 inside IPv6 for some of those offerings? Was the v6 methodology for IPsec easier once you had the hardware and capabilities?

TAKESHI TOMOCHIKA: OK, that's a good question. Actually, it's very common for the motivation. The enterprise motivation is for example, IPv6 can use native - I mean, IPv4 needs PPT, and there is a little bit of overheads, so using IPv6 is much better. One of the reasons is IPv6 multicast using IPv6 and it's much useful because compared to IPv4.

So I believe, in that case, we should recommend IPv6 compared to IPv4.

ADI SISWANTO: I'm from Indonesia. I have question for Mr Xing ' Li. What is difference between this, and I think already there is no solution between IPv6 and IPv4. What is the difference between IPI that you mentioned and NAP? And you mention one to one translation between IPv4 and IPv6 - I don't think this can resolve the problem for IP address exhaustion. Is there any recommendations, thank you?

XING LI: OK, the current PT, that's state for translation skim. And the IVI is stateless. And it's duplicated by IETF and the current is the version. It is only supported IPv6 communications. So that's the comparison.

And IVI is more closely to IIT. But the differences are actually SIT using a prefix, however IVI used ISP prefix. So that's the first answer to the first question.

And the second, I talked, why is one-to-one and your answer is correct? One IPv4 can support several IPv6 addresses. Thanks.

MARTIN LEVY: OK. Seeing the microphone's empty, I am going to ask that we thank in the usual way our speakers and we also have a gift for each of them if you would just hold on for one second. First off - oh, you want to say something afterwards or now? Oh, now.

MIWA FUJII: Thank you. Hi, everybody. Good morning, my name is Miwa, I'm from APNIC. All speakers, thankyou very much for your great presentation. It was quite useful. I'd like to make a quick announcement about IPv6 deployment monitoring survey. APNIC will conduct an online survey to measure the IPv6. This survey is RIPE-NCC actually conducted this exact same survey in July 2009.

This survey is developed by TNO and GNKS consultant and sponsored by the European Commission. We will open up this online survey today. It will be open for next 30 days and need to be closed on September 28. The link is available from here. If you go to the actual site, it should be like this on the screen. The actual link will become available maybe by before today's lunch time. So please participate this survey, so that we can altogether measure the IPv6, so we can please participate in this survey, so we can establish the global view of IPv6 migration. Thank you very much. Now I'll hand back to you, Martin.

MARTIN LEVY: So, as I was saying, I would like us to thank our speakers today.

APPLAUSE

And I have a gift for each one of those. If you would just bear with us one second.

SRINIVAS CHENDI: Martin, thank you very much for chairing the session, as well as your generous support for APNIC 28. I'd like to invite Paul Wilson to present a sponsorship certificate to Martin.

PAUL WILSON: Thanks, Martin. The support of Hurricane Electric is really appreciated. Thanks very much for your contribution as a sponsor and also your personal contribution as a chair and contributor to the meeting. It's really appreciated. Thanks.

APPLAUSE

SRINIVAS CHENDI: OK, so it's almost 10:45. We just take a 10-15-minute tea break and come back for the policy SIG, if that's OK with you guys. We're really running out of time for the policy SIG. Is everyone OK with that? Just a 10-15-minute break. Thank you so much. We'll see you then.