IPv6 session transcript

Wednesday, 27 August 2008

IPv6: Does it work for you?

0900-1030.

Ready, set, go IPv6!

MIWA FUJII:

Good morning everybody. Just before we start this morning's session... OK, so a housekeeping note for today's program and briefly for tomorrow's program. We would like to thank you for our session sponsors, Hurricane Electric. The Helpdesk, if you have any queries go there and the prayer room is next to Hall C. Lunch is provided and is located at Crowne Plaza, Victoria Cafe. Hostmaster's consultation is available for booking via Helpdesk. The culture night, experience the night of Maori culture with traditional Maori performance and a hangi. Transport will be provided. Please assemble at the Convention Centre main entrance. There will be several buses leaving from 6:50pm. The last bus will leave at 7:10pm. There will be several buses leaving from 6:50 pm and the last bus will leave at 7:10 pm. The bus will leave for the Convention Centre around 10:20 pm. Please wear comfortable shoes and warm clothing as we will have a short tour around the village.

Information dinner on Friday August 29. We will be heading to the restaurant on and you can experience the contemporary ingredients while taking in the extensive changing panoramic views over Christchurch and Banks Peninsula. It will cost NZ$70.

There are lighting talk sessions tonight between 6:00pm and 7:00pm. Anyone who would like to submit your idea to this program, please send to program at APNIC.net by midday today. Anyone can participate in it.

Program review for Thursday, Policy SIG. What you say or don't say can influence the outcome of the proposal discussions and change APNIC policy. APNIC policies can affect you and your network's number resources. APNIC vendor reception starts with a reception and enjoy the relaxing Christchurch nightlife with a game and finger food and beverages.

Now we'll start today's first program - but once more, good morning everybody. Welcome to today's first program, IPv6: Does It work for you? Ready, Set, Go IPv6!

I'm Miwa from APNIC. In the next 90 minutes, we will try to experiment to connect to the IPv6-only network and in the next 10 or 15 minutes, George Michaelson from APNIC will provide a presentation to explain the background of this experiment.

By the way, the material we will use in the next 10 or 15 minutes is available from this listed website.

If you click this link, you will see - you come into this website. The APNIC 26 website and you click this link under the sheep and you come into the website and in this website, it's showing the users with IPv4 address over there and if you hover over your mouse on to this dot and move around the sheep, if you stop your dog in here and hover over your mouse on to one specific sheep, you see IPv4 and you may be able to see your own IPv4 address, if you're using a IPv4 network. Then underneath, there is the Kiwi field and we have about eight Kiwis here using the IPv6 address. By the end of the program, we would like to see as many Kiwis enjoying this beautiful Greenfield, so hopefully you can find your own address. - it's a nice sound, I'm hearing it, please enjoy it!

The body of this experiment is basically, everyone attempts IPv6 connectivity, enjoy the experiment and share knowledge and information.

So, in the next 90 minutes, we will do experimental IPv6-only network after we switch off the dual stack network. I will introduce and invite George Michaelson GGM to come over to the stage to give a presentation about previous experiences in current APNIC IPv6 connectivity. This session is proudly brought to you by Hurricane Electric. Thank you for your great sponsorship and support. When you connect to the IPv6 network, please raise your hand and APNIC staff will come around to confirm your IPv6 address and then an IPv6 address exhaustion clock is yours, like this tiny credit card sized holder, counting down the exhaustion, the date and time to the point of exhaustion of IPv4 addresses. I asked Mr Martin J Levy this morning, when is the starting point of this.

He said that is Geoff Huston's prediction, January 27, 2011. But if you have your own formula and want to put your numbers in here, you can set this clock with your own time too! So, it is really neat and this is yours if you connect to the v6 network.

So, how to confirm your connectivity to the IPv6 network. You can go to the website. Once you connect to this website via the IPv6 address, in the top right-hand side corner will appear and showing the IPv6 tab and showing and indicating your IPv6 address, or you can go to the APNIC 26 meeting website and on the top right-hand side corner again, a small Kiwi appears and drops an egg and IPv6 will hatch. If you see this, you are successfully connected via an IPv6 address.

So, how to enter the IPv6 prize draw. The prize is two Apple Airport Soho IPv6 wireless routers when you successfully connect to the IPv6 network, you can enter the IPv6 prize draw. What you need to do is go into this website and please write down the website on your note pad right now and click the image right now listed on this website. But before 10:20. I would like to ask one thing for staff from RIRs, IANA, ICANN, NRO, ASO, ISOC and speakers - please refrain from entering this lucky draw so we can maximize the opportunity for delegates to win this great prize. And we appreciate your great understanding and co-operation.

So the winners will be chosen before the morning tea. We'll do the lucky draw before the morning tea at 10:30. Big thanks to Hurricane Electric. Now, I would like to briefly explain about the APNIC 26 network infrastructure. We have two IPv6 SSIDs. One is APNIC 26-26.

This network has local IPv4 ply weight space providing the IPv4 transport to a local dealer server. As a large number of you are aware, we have been experiencing persistent radio frequency problems. To isolate the problem was quite challenging and in order to simplify the situation, we decided to run APNIC 26-v6 for 20 minutes after it is turned off and the following 30 minutes, we will turn on APNIC 26-v6-xp. So we really appreciate your co-operation and understanding for these circumstances and thanks a lot.

The applied transition mechanism is NAT-PT. We set up a DNS server running the software so that it generates records for the DNS entries which have only A records. And we chose this transition record because it is easily deployed in this conference period and also, there is no need required to change the end-user size. As you know, there are so many different transition mechanisms available, and simply because we are using this in year, it doesn't necessarily mean that we are endorsing this method, mechanism or... you just need to find out your own transition mechanism if you're planning to make a transition to v6.

And this is APNIC'S 26 network diagram. It's a bit small, but in the centre, there is a Cisco router 7204 on this router, we enabled NAT-PT. If you need more help, the instruction materials, printed out materials, the PDF version is available from this link and also the material we used yesterday - v6 at your finger tips - and also this material will become available soon again from that material. And also a very good resource website.

I would update and applaud these materials we use for this v6 experiment as well so you would have access to diversified resources from this as well.

APNIC staff are on the floor so please raise your hand for further assistance if you require it. In case, definitely absolutely you need access to the IPv4 network, the dual stack network, on this, we don't have any dual stack available but level one, room 1-5 has the SSID APNIC 26 dual stack coverage, so please feel free to use that. And a big thanks to Jonny Martin and Neil Fenemor. They worked really hard and Jonny and Neil and associate friend supporters, we really appreciate your help in preparing this IPv4 infrastructure. Thanks a lot.

Now, we're going to turn off IPv4 switch, we'll turn off the IPv4 dual stack. APNIC 26-v6 will become available for the first 30 minutes, and then APNIC 26-v6-xp will become available in the next 30 minutes. The dual stack wireless network will be turned back on at the end of the morning tea break, so the countdown starts now. 5, 4, 3, 2, 1, off you go.

Now I would like to introduce George Michaelson - GGM.

GEORGE MICHAELSON:

Hello everyone, I would like to say thank you again to everybody who stayed back last night with helping what we're doing. It really made a huge difference to be able to go around and see the experiences you're having.

I want to just give you a brief summary on some of the previous experiences that have gone on in the previous networks. These may not actually reflect things you've seen if you've been attending the meetings because there's been a range of different feedback we're gathering from people. This is more a summary from the provider side, the people implementing the experiments, what we took away from them. You know how physicists say they like to stand on the shoulder of giants and discover new things. In computer science, we say we're standing on each other's toes, but this is an experience where we're wanting to learn from peoples' experiences and learn from that. The NANOG meeting, it had some teething problems and that tended to detract a little bit from the experiment and it made it harder for people to see coverage and the availability of proxy services.

The APRICOT meeting in Taiwan in February actually had really quite good onsite network infrastructure and the NAT-PT was working well. There were other connectively problems and that probably also interfered with peoples' experience.

IETF Philadelphia worked well. That was the event where Google were able to show that they had a commitment to IPv6 in the public eye, and I think for a lot of people, certainly for myself, that was an amazingly rewarding experience. It was the first time that there was a visible participation of a major external physical player and the experience from the network doing a v6-only hour was very positive in that time because you could get a lot more information than you could in previous experiments. The RIPE meeting in Berlin suffered bad meltdown problems with their hardware and the way they converted from the v4 SSID to the v6 SSID. That was a profound experience for the guys running their network and that caused a bit of disruption and as you saw last night, this building is presenting us with some challenges so we're still not quite sure how this is going to go today.

To give you a bit of information about how APNIC itself is using this technology, this is a diagram of the local connectivity that we have in our back office. Almost all of the APNIC activity has services face, the provision of registry, the services we offer you in training and the website is based in Brisbane, and we have a back office in Milton, a suburb of Brisbane. As you can see from this diagram, - sorry, the writing is a little slow, that we are actually tunnelled from the back office to the facility. We are not yet running native v6 on that trunk, that's something we're going to have to investigate soon. At the Colo facility, they don't have a lot of native v6 and I'm sure a lot of you know if you don't have native v6, the only way to get there is by implementing the v6 and that has definite consequences for what you see.

We have tunnel connectivity to Telstra who are the largest provider in Australia, and we also have tunnel connectivity to a tunnel broker that we deployed recently in this facility to encourage more update. But recently, we have got native v6 connectivity in Brisbane on to a local IX and that has made a very dramatic improvement in the quality of the v6 service. So if any of you are currently using tunnels and only tunnels, I really strongly recommend you try talking with Exchanges and providers to get native connectivity. The quality of difference is very, very marked.

The international connectivity we get from this facility basically is from Japan, Hong Kong. You'll notice they are all tunnel mediated services. If we go to the broader picture of APNIC as a whole, we have Colo facilities in three other locations. The USA, Hong Kong and Japan. The USA is currently only a data and research facility and it currently doesn't have v6, it is at the Ashburn facility. I think there is v6 availability in the world. Japan is extremely well provisioned and we're extremely grateful to the wide research facility for assistance in connecting into the v6 community. They have been a very important partner with APNIC for a number of years and this is an ongoing relationship which is very valuable to us. We're in the facility. We're also cross-connecting Japan to OCC Aid. This is quite a rich mesh of v6 and the observation is that you wind up doing things like this when you are stuck behind tunnels. It would be lovely to only have one point of reliable connect, but because v6 is still growing technology, it just turns out to be necessary to get a few more connections around the place to try to increase the visibility of isolated pockets of v6, and you may well find the same thing happens when you bring up your own v6.

If I can go back to the previous slide, you'll also see that we have a fairly small list of IPv6 enabled services. The writing is small but this is a lips of the mail web FTP, portal for membership and the reverse DNS which is the primary function in D NS and also the secondary services we offer.

We are trying to increase the number of services that we put on v6. There are some stability issues which emerge when they are doing this. We're very conscious that because the current application suites look for a v6 binding and try to use it, if we can't guarantee that v6 is in a stable connection, there's a drop in service quality. We don't want to do that to the community and we're looking to improve on the v6 service levels as we improve the quality of the v6 connection.

Thank you.

MIWA FUJII:

Thank you GGM. Now we will go back to the main problem

MATSUZAKI YOSHINOBU:

Good morning to IPv6 at Google so Mr Erik Kline. Welcome Mr Erik Kline.

Back to contents

IPv6 at Google

ERIK KLINE:

Thank you very much. For those of you who don't know me, I'm Erik Kline. I have been with Google for just over four years. I've been doing IPv6 stuff I think, the first v6 network I built was in 2003 and in 2005, I started doing a little bit of IPv6 in Google as kind of a 20% project and then in October of 2007, I became 100% full time on it and I work closely with Lorenzo and for those of you who know Lorenzo and have seen his presentation. I don't know if I really need to talk about this slide - I mean, hopefully there are a lot of presentations about why everybody should do IPv6.

The idea for us is that we kind of believe that it is not an option - we're going to have to do it and we'd rather do it now. We'd rather figure out in advance. The question is not if or even why, but how and when? And the when is soon and the how is what this talk is going to be about. For us, if we act now, it's going to be cheaper - it's going to be a lot cheaper for us to take our time, maybe have small breakages and mistakes that can be fixed, rather than running in a blind panic at the end and shelving out a lot of money and maybe wasting developer time and who knows what else. It's not been difficult, it's not hard, I don't know why more people aren't doing it. I suppose, there's a cost aspect, but really, it's not rocket science but it does take care of the plan.

So the history of us, there's a couple of us who have been in the IETF, some more vocal than others. In January 2008, I held a conference internal to Google, about IPv6, some external speakers, Randy Bush was there. And it was a key changing point, a change of discussion about why and if, to how and when. And it also proved a kind of a galvanising thing for IPv6 services at Google and I can talk about that later. And in March for the IETF 71, March 12, we launched v6.Google.com. And in May, Lorenzo launched in June and July we launched IPv6. So if you do a search over the cash link, you should see that in IPv6 Europe. If you go on to IPv6.Google, you can get it there. I wasn't really able to help there.

There are ways to get almost every single IPv6 service that you use out there. In fact, this presentation is over at docs.Google.com which is kind of small, but this presentation is being presented at docs.Google.com and there's lots more that we're working on. So if you can get to IPv6.Google.com, they launched this the morning of March 12 in Dublin time for the blackout time and it was only about two hours that it had been opened. We had noticed and we were actually seeing that so I don't know if someone was looking at the DNS or something, but it quickly became something outside it.

Again for us, it's not hard, there's a lot of things that need doing, there's a lot of planning that needs to be done and coding that needs to happen and testing, careful testing. It's really just about planning, timeline, which is why we wanted to start now. It did start as a 20% news like Gmail and other things and something that Lorenzo was interested in and I was interested in and a bunch of others. In October 2007, there was a bunch of us who were all talking about what we wanted to do and my boss suggested, you know, you guys should have a conference and get everybody's focus in talking about the same thing and I said, well, you know, let's see if we can get IPv6 wireless for the conference which kind of meant, you know we had to fly to Tokyo for a day and come back for a day and get things up real quick and Lorenzo and Angus, the principle engineer for IPv6 at Google.com said, let's get IPv6 services and let's try to actually do that and they did on that day, with the IPv6 maps and Lorenzo did this. It was actually surprising. And since then, we've basically scaled up the architecture. We had a number of other things that have come forth since then. It was much faster to get it up for the conference, it would have taken too long to qualify all the new OS images we need to run and so on and so forth and it was lower risk but since then, we have been steadily converting the infrastructure back to our native, to everything being dual stack. The complexity of manages 2 OPS and 3 OPS. One of the things we did was tapped into enthusiasm. It is kind of in a ground swell. I remember we were deploying IPv6 to several engineering offices and I kind of designed a tunnelling system in the internal IRC and I said I want to do this basically in 6 or 4 but it works in RT 19 space (sp?)

I wrote it and I think we built and sourced it and tunnels for any user who doesn't have native v6 right now inside the company can get a v6 tunnel. It comes up, the script is automated and comes up every time you open your desktop. We made it easier for contributors to get initial results, it is very important to get and experiment things.

Part of the roll-out was to enable that and once we fixed the testing infrastructure and we could test for IPv6 and make it possible for people to just try turning it on and turning it off, turning it on and turning it off and see what crashes, fix the next crash! And it's important to do it in stages. Your v6 doesn't have to be as capable as the v4 infrastructure on the same day but it should be designed with the same quality. We didn't skimp on the design plan. I know Lorenzo went through the views and it was designed to be production just small scale from the very beginning. It is not hard but I guess, this is August, it's about 10 months now since we started working on this. It's important to be consistent operationally. You should dispel the notion that IPv6 is experimental, it's not. It is running on XPs, Linux and a bunch of people who don't know that they have v6 and then they tell me they figure it out later on because they saw some dancing something or another, and that's the way it should be. Mostly it does just work in the operating system. We do have a fairly controlled network, we don't have any random Windows 98 or Windows 95 out there, so there is not extreme brokenness out there.

On the whole, it is written and you can do it and it turns out that the first thing that is needed to get the v6 from an application layering is the monitoring. You should fix it so it can monitor the v6 infrastructures and from there you can support the service. Once it is monitored, it can become a supported service and you can transition it. As we said before, it should be designed to the same quality standards as v4. The NOC needs to be made aware of the IPv6. The first people have flown around the world for training, and if you build it on a small skill and don't skimp, do it to the production quality standards, to a high quality, you can start with a small infrastructure. And design it closely there.

It is important to make the principles of least surprise work for us to the extent that IPv4 and IPv6 are the same, you should be able to reason logically about your v6 network from what you know about your own network.

Speaking of surprises, there are of course differences and security issues being one of them. End-to-end is back - I was definitely panicked for five minutes when something said, should I be able to trace it to the desktop and I went "Oh my God" and ran around like a chicken with my head cut off and went, "No, it's OK, we have to do real host-based security"!

We found that the device was adequate for the most part. I know Lorenzo wants to do feature parity which is not there. If you're doing IPv6 only stuff, NAT-PT can be temperamental, there are other options out there but we're only really working towards the dual stack at the moment.

6to4 has been recommended by a number of people, Tony Hain included. The TEREDO hardware, the users can talk directly. Our particular vendor doesn't have to do this in hardware just yet so it is not important in configuration, but it is definitely do-able and on the table for discussion. Load-balancing is not where we would like it to be. The vendor does not do IPv6 straight through to the back end but it does you do IPv6 on the front end and IPv4 on the back end. It's easier to make the services look like they're talking to IPv6. So the reliability is not quite ironed out. There were some problems on the day of the launch. Random networks and certain sizes and I know we shouldn't worry about it because we'll have to reboot when the memory runs out every month.

I think we were rebooting about every 36 hours. We had a router crash the same day. Lorenzo was able to call our somebody at the IETF and get us fixed on that very same day. These aren't really showstoppers, they may sound bad, the router crashed but there was a query of death packet, but not the case. Another memory problem. Nobody has said no, nobody has said, you know push pushed us off and said, we'll get that in two or three years, meaning that they won't do it at all. Instead, our vendors want to help and want to figure out how to prioritized. Everyone has been very co-operative.

But, as we said earlier, you may want to start with dedicated devices. The Internetworking is kind of patchy. We were announcing in 2001, 386043 /4. Google just wasn't visible from the IETF network I'm told but again, people want to help. And report this to other people and find the BGP contacts, you can get it fixed. Peering, peering, peering, peering, we're growing our IPv6 infrastructure to be as connected as the IPv4 infrastructure and we would very much like it if everybody else did the same thing. IPv6 is highly variable. Not surprising but if you can interconnect to production networks, we can launch production ready services on the Internet, it is not there and there are people there right now.

So, random slide about some stuff that we need. Lorenzo and others, we would like /127 on point-to point would not be a bad idea or at least make it possible to not have an internal ping pong DOS for the router links. Various NAT solutions for IPv6 networks, you know NAT-PT depricated but everybody uses it anyway. We're ready to run in the dual stack world. It's not quite so critical at other things like the VRRP for IPv6.

Sooner or later, some big customer is going to want to advertise longer in the free zone. Be prepared for maybe having a 48 in the DFC (sp?) And deployment. With the ISP, at the very least, please offer services to your customers, Teredo services. The 6to4 and it was wonderful but kind of slow and I figured out that the packets were going from Los Angeles to Milan in Italy, so now I'm happy to report that it goes from Los Angeles to Chicago, but halfway across the US is better than halfway around the world. But it would be great if my ISP would give it to us directly.

One problem thing we have a problem with is the licensing, some vendors require software licences for IPv6. This is not helping with adoption. We have the price of $10,000 per router for extra v6. You know, you could build a network out of goodwill. Your manager could take a deep sigh and say, this is for the good will of the Internet and so on and so forth and we'll do it for three routers and build a small network but if you want to do a full roll out, you could look at seven years or more, so there has to be another way to absorb the cost with hardware or something like that. Tony mentioned yesterday that maybe v4 should cost more than v6! That would be great. The Internet will keep the abundance going and people will buy more devices and do more things and if it becomes an issue of scarcity, it will be hard.

So the real challenge is, how and when can we launch without sacrificing quality of service at all. Because we have to have the right answers to our user and they have to have it quickly because if we don't have either one of those things, they're not terribly useful. The right answer that comes several seconds later, we'll never get to you then. Breakages are just not acceptable for us. Even if is 200 and 300 seconds, people wonder why their browser is taking so long and Google was fast and it is not fast any more, what's happening.

There are various reports at the level of deployment, they all seem to be in the 0.1 or 0.X% range. Broken IPv6 in some senses is far worse than no IPv6. And if you go to Google.com and find out that you can't get there and the Google reel is not spinning, that's considerably unacceptable so we're looking at situations where we can release the quad As to the connectivity and go to the networks and connect directly to the users because we would like partners who are interested in fixing their customer's problems because there are also the user's problems. So networks of networks of networks of users can solve the problem for some people. This is one way we're sort of hoping to transition to the records out there.

There's a number of other options, how to actually turn it on to the whole world is another issue. Thank you.

MATSUZAKI YOSHINOBU:

Some questions that I have noticed for you. APNIC 26 v6 is turned off and the APNIC 26 v6-xp is now on. So if you are on our network, then please switch your configuration. And any questions for this great presentation?

JASON SCHILLER:

Jason Schiller from UUNET. You talked about how you would enable IPv6. I'm wondering when you think that might be?

ERIK KLINE:

It's definitely coming. Right, it's something that we can do right now, it's something we're doing Internally. But, whenever we do it or non-trusted, like actually, when we do have a trusted network is dependent on the experience of the trusted network, but we're not talking 2015, or 2014 or 2013 and we're not talking any further out than that. It's definitely conceivable that it can be done in a finite number of months, double digit months and single digit years. And we could also do it in 2009 or 2010.

MATSUZAKI YOSHINOBU:

Any other questions or comments? OK, thank you.

APPLAUSE

Next one is the panel session and - How much v6 is really out there? Nathan from BrainTrust and Martin J Levy.

Back to contents

Panel discussion: How much v6 is really out there?

MARTIN J LEVY:

Good morning, my name is Martin J Levy from Hurricane Electric. I have to talk in 5:55 minutes and I just can't do that, so we'll see how good I do and we'll get through this stuff quickly. What I'm going to talk about is just a few stats that we've gathered off of our backbone and we've done a set of measurements that are specifically on a set of users that we have scattered around the world on our v6 tunnelling service. So the core backbone where we provide IPv6 native transit to many different companies, we just went off and looked at a select set of users and there was a reason for that. It's that these v6 tunnel users are motivated IPv6 users, not just the general public, they were the ones who have sought out connectivity for v6, had to build a tunnel because they provide a cable DSL, corporate or wherever have not given them connectivity. So, there's only one point about the history of our company that's important to this talk, which is the fact that we put v6 tunnel brokers in basically, 14 US cities, European cities and we've actually literally, as of last night when we saw an e-mail, all the hardware got powered up in Hong Kong and went into the site in Asia.

So, there's the 12,000 users, what are they motivated to do? That's what we set out to try to find out and more importantly, to find out from the geography, whether there was any difference. Now, there's going to be a whole set of extra data which I will throw up on the APNIC website where the slide set is, but I want to show you a couple of things about motivated IPv6 users and if this helps understand where the - or why you need to do IPv6 infrastructure, it is probably the most valuable take away from this.

There's two things. As I said, we've got about 12,000 tunnel brokers over a set of areas. That's grown over the last year from about 3,500 users and it grows pretty well.

In the back of the slides here, I have the information about what happened when Google announced their IPv6.Google.com. We saw a psych on the two or three days around that announcement on the number of people who sought out and found tunnel brokers. They found ours and they turned it up but I want to show you a different spike. What I've got here on the bottom graph is, I think the opposite spike. It's a good spike, but it is for maybe the wrong network. RB Networks said there was no v6 traffic, it was maybe 0.5% of traffic and it was not very successful. It took seven or eight pages to say that, so I've given you the quick version of that.

What's interesting is that on the day that that was announced, it got a lot of blog entries worldwide and this was a week or so before AUSNOG, we ended up with a spike of the number of people turning up the IPv6 tunnels, so I think it is the complete opposite. It turns out that there is an interest there, even if it comes out of regular boring white papers.

So, what did we do? And I'm not going to have time to go through all of the data so I said I would put this up on the website. We've taken all of the users and if you notice the break down of countries where we have users, the United States, Netherlands, Germany, etc, we have a fairly low set of users out of Asia which is good, that means that they probably have some form of natural connectivity. But this was the method that we used. We took a two-week time period where we collected everything and anonymized the data and I'm going to show you a couple of things with the information I'll refer you to the web for the rest of it.

The question we had for a couple of things were, were IPv6 users normal users? Look at your neighbour, make your choice! But in reality, they actually are. From the UD side of things, over a day plus period here, we saw a fair amount of UD traffic and every now and again as we show in red here, we're seeing spikes of completely other traffic and whether it is nefarious or simply other protocols, when they started doing further analysis without wanting to get rid of the anonymization of this, we said this was no different from the traffic we see in the v4 world. Whether it is good or not, it means that v4 is amazingly similar in this measurement.

The other measurement I wanted to show was the whole issue about 6to4 traffic. The comments were made earlier about travelling all the way to Milan to go to get a 6to4 or to Chicago where we see a very large amount of traffic flowing to one particular provider to Chicago which a well connected 6to4 tunnel. When we look at the amount of traffic, we're only measuring the v6 traffic because when we look at the tunnel broker, it is pure v6 at this point in time. You see here a fairly low percentage in the region of 4, 5, 6 and occasionally a spike, maybe a little bit higher percentage of traffic going to a 2002 /16 address. That's the stuff searching out a 6to4 tunnel somewhere in the world.

Now, the question we've had is, is that our duty exactly to the comments that have come up earlier here, is it our duty as an IP backbone to place 6to4 tunnels throughout the world and alike? And I will turn around and say - for us as a backbone, as a wholesale provider, that it's very unclear and I would welcome anybody who wants to provide information on that.

The other thing that is sort of interesting, just for the people who look at numerology and the like, is that we started splitting out the traffic, the further data is to split it out by country and where it is going. However, on this graph, if you look, you will see that the majority when I split it on a /16 majority, the absolute majority was there and the extremely small amounts, the blue line at the bottom of the graph is where we're seeing stuff coming to all of the other addresses out there. It is just interesting numbers and nothing much more.

I'm going to refer most people to IPv6.HE.net which is on the countdown clocks. The TLDs and other things like that.

The final stat that I want to show you is on the network and a show of hands if anybody knows what happened. This is the AMS-IX, Amsterdam v6 X flow stats for the last umpteen months. And something happened mid to late, mid-April. This is not related to an IPv6.Google.com announcement. We politely without asking for too much information asked Google, is there your data and they said "No". So we don't have much and say, hey, not a lot of this is ours so we don't know where all of the v6 traffic is coming from, but the good news is, look at the spike, look what happened? Something is happening out there and that's good news. By the way, as a percentage, AMS-IX is peaking at 400 or 500 gig at the present moment in time. This a normalized in a monthly graph peaking at 400 or 500 megabits on a daily bit or an hourly graph at 600 or 700 megabits as measured by the stats. So this is just shy of 1% traffic. It's just the stats. I wanted to make sure that I got it out there. It is not from us, just from AMS-IX website and this is the publicly available AMS-I X website.

That's it, it's a panel discussion so we'll leave the questions until later and hopefully I've only gone a minute or so over my time.

IZUMI OKUTANI:

That was perfect timing, thank you, Martin. Well, since we are, you know we have limited time, we would like to move on to the next speaker and after all the speakers have presented their presentations, we'll move into the general discussions. So the next speaker will be Nathan and he'll be introducing about peer-to-peer traffic in IPv6.

Back to contents

NATHAN WARD:

OK, I'm talking about peer-to-peer over IPv6. I've been - I've got a whole lot of slides, Teredo and 6to4. Right, so - this is skipping through it! All right, so Teredo in 6to4 the tunnelling mechanisms with Windows and XP and some Linux and map and things lake that. And in Vista, they're on by default, you have to turn them on in XP. Teredo is used by people who are behind NAT. 6to4 is used by people who are outside of NAT, so people who have a public address.

The people have been saying, what is the killer app for IPv6? And so, it's almost similar to peer-to-peer, right? Yeah!

So, what I did was say, right, we've got the peer-to-peer stuff, what the v6 support so I'm going to turn it on with a couple of addresses. The Teredo address and start capturing packets and start analysing packets. So, the BitTorrent, it has the hash table and what DHT does is, it will connect a whole bunch of clients, Azureus clients together over IPv6 or IPv4 and do client to client so you don't need Torrent downloads to go. So it wasn't capturing that. So yes, Azureus had IPv6 support for about several months. Azureus, you run the Azureus client, if there is an update available, it will install it so the IPv6 was deploying pretty widely. It doesn't do Teredo on Windows, so to do Teredo for the Windows application, you have to see the specific software option.

It works with 6to4 onwards. There's another one called uTorrent so that has IPv6 support as of two weeks ago. It is enabled by default and it will do Teredo on Windows so the early versions of it actually turned IPv6 on. It was Windows XP, but the release version, at one point it doesn't. So you go into the preferences and say, "turn IPv6 on", but if you're in Vista will always do IPv6.

So, I was running Azureus on three different addresses, an IPv4, an IPv6 and a 6to4. I counted packets for about three hours or so, about six hours!

So, this is the Distribution Hash Table. So the IPv4 packets, there was this many hosts. From my 6to4 address, I did this many packets and talked to this many hosts, which is interesting when you compare it to the IPv4 number. And then on the Teredo interface, I talked to this many hosts and then I have a stat here which says, you know this many were established by directional conversations worth. So DHT is a UDP thing, so you send off a packet but it is supposed to be a request response, so I should send a request and get a response.

In terms of the number of bidirectional hosts, they talk to versus the number of total hosts, it is similar to IPv4 and IPv6.

Now, it is interesting here, the way Teredo works is when you want to talk to a non-Teredo host, it will send a packet to that host and get a response. What happened was the 990 - someone talks to me and I didn't respond. I didn't respond because when I tried to ping them to get their address, I didn't get a response which was interesting.

If I had got a response back, the number would have been more like 16.

So then I looked at it - so this one was based on the address at my end - OK, so I started looking at it based on the address at the far end, whether it was a Teredo address or a 6to4 so the IPv4 addresses are the same. 6to4 is pretty much the same. And then Teredo is sort of a lot less, so you can see this sort of difference here. And then, these - this problem here where we had the ping packets Not working shows up here again when people talk to me and I wasn't responding.

What I found interesting here was, from the tunnelled stuff, this was the tunnelled stuff, the 6to4 and Teredo stuff and there was only 10% of the total v6 host were non-tunnel, so there was a lot of people with stats of total v6 traffic, locking at that graph and that sort of thing, and when in reality, most v6 traffic right now is being tunnelled, probably by the machines doing All of the tunnelling.

So, if I sort of make some numbers up and I assume that 95% of hosts are behind NAT, OK, so 95% of the hosts of v6 turned on and can't do 6to4 and they'll do Teredo. So, if I say, right, Azureus can't do Teredo so I was only talking to Azureus 6to4 and said that's 5% of the total 6to4 users, so I take that number and the total v6 users I should have been talking to is around about this. And if I compare that to the number of v4 hosts I was talking to, it is that. So there are a whole lot of assumptions I've made here. One is about how DHT works and things like that and things do I don't necessary will know. But I think that the interesting thing is how much and how many different hosts there are on the tunnelling things, and people that are using these things for peer-to-peer and that sort of stuff.

So, I also looked at a couple of other things. I wanted to look at Teredo and 6to4 health stuff, so what I did was get all of these packets and I can look at the TTL of those packets to find out how far the remote host was away from relay when it was trying to reach my 6to4 address for my Teredo address. So, what I'm doing is, there's a nod trying to send me some traffic so I'm these guys over here. The IPv6 TTL, the host is going to have a decrement here, but it's not going to decrement here over the tunnel. So when I looked at that, the host will start off with a HLIM of 64 or 128 in most cases so I did some guesses to figure out what people started at and that sort of thing. And so what it looked like to me was - most hosts had three or four hops to get to a 6to4 relay.

The 6to4 stuff seems pretty good, three or four hops is OK, but Teredo was significantly worse, so there was, you know 10, 11, 12 hops for most people to get to a Teredo relay. So, that's v6 HOPS and I imagine that most of those are over tunnels. You know, the amount of tunnel people, tunnelling people are doing around the place, most of it is going through tunnels.

So, in the peer-to-peer community, I went around and I thought, you know how many people are actually talking about using v6 or peer-to-peer, so the uTorrent people had all these things saying, the big picture is Teredo but all of the users were saying, oh, it's not deployed and no-one uses it and we don't have a v6 router and my ADSL router doesn't work. But the reality is that it is going to tunnel over that because it is tunnelling over v4, but the interesting thing is that the end-users who were using this were doing so unknown and in fact, they specifically thought they weren't using it.

So conclusions, you know it's very real today. There's a lot of people using it. There's a lot of people who don't think they're using it but actually are.

You know, a lot of the people who don't think it is happening when it is and they're probably, sort of the more power users so the guys downloading a lot of data and pirating movies and this sort of thing. So the 6to4 relays are all right, at least in the 6to4 network to 6to4 client direction. They're not so good, like Eric was talking about with the 6to4 client to the 6to4 Internet direction. And to deploy some Teredo, deploy the relays.

I want to start releasing some of the numbers periodically to say, if there's this many hosts that I'm talking to and seeing how tunnel versus native versus whatever changes. And I'm open to other things for evaluating quality, so I looked at the TTL stuff, so if anyone has any ideas for the quality of v6, please come and talk to me. All right.

IZUMI OKUTANI:

Thank you, Nathan. It was an interesting experiment and observation that v6 is starting to happen, especially in terms of 6to4. So, the next speaker would be Geoff Huston.

GEOFF HUSTON:

Thank you, I appreciate that you're all burning to ask questions and the 47 slides flashed past so quickly, and if they did, it would be a movie. I'll do it straight away without slides. If any of you played with this in MP, you would have figured out that it is bloody easy to measure the entire universe. Every router has approximately 100,000 measurements or more and you can fling a measurement machine at it and do 1,000 probes a second. It's not the data that's the problem, it's actually figuring out how to interpret it.

So inside all of the exercises, if you're really trying to understand what's going on, the best thing is to phrase a very, very simple question and see if you can gather some data to answer it. So, what's the question? What's the really, really simple question people are asking for? What are we after?

Well, there's one way of phrasing it that is germane to the problem. Given the voice with IPv6, how do you phrase an experiment that simply answers that question? Given the choice, what percentage of hosts would prefer v6?

Oddly enough, dual stacked web servers which have both v6 and v4 and the records allow you to have the choice, so the really simple thing is, look at the web logs and figure out on each day, how many different source addresses visited you and how many were v4 and how many were v6?

So, in 2004, approximately two in every 1,000 source addresses were v6. And in 2008 - on August 19, approximately three and a half of every 1,000 visits. So you know if the question is, why is the universe and v6 today, the answer is not 42, it is 0.0035. Thank you.

IZUMI OKUTANI:

Is it working? I don't know, impressionable statement, Geoff!

So, we like to move on to discussions from the floor as well and if the panellists have any questions or comments to each other's presentations, please feel free to make comments.

IZUMI OKUTANI:

Sorry to interrupt. I actually have a housekeeping announcement to be announced before 10:18, so sorry to interrupt. There will be IPv6 draw entry which will be closed soon. That will be closed at 10:19, so if you haven't entered your v6 address yet, please do so from www.APNIC.net/meetings/v6.

MARTIN J LEVY:

Sounded important to me. I have a quick question to Geoff, so I just have a quick question for Geoff here. The comment was, if a host has a v6 and a v4 address, it has the ability to go from either or in either path. Is there an easy way to have measured how many clients had a choice but didn't make the v6 choice? And is that a bad thing? In other words, if they had both choices but used the v4, is that a bad thing?

GEOFF HUSTON:

There's no way I can tell.

MARTIN J LEVY:

Great.

GEOFF HUSTON:

Because I'm looking at the side from the web server so the question floats up into the space of, let's hypothesize a little bit.

MARTIN J LEVY:

Can you do that, can you hypothesise.

GEOFF HUSTON:

Does it matter to the question. It is a question of, does it matter? Given the choice of how many hosts use v6? I simply said, what you're saying is not the question I'm answering, right. Because realistically, if you have this capability if your stack and you decide not to use it, it's as if you never had it.

MARTIN J LEVY:

OK.

NATHAN WARD:

I do a similar thing and I mention one by one transparent or whatever, and the host names, you know, there's three or four. One of them has IPv4 only and one has IPv4 and IPv6. One of them has IPv6 only and so I do that and take the time, how long it takes to load so I can see whether it's trying to go on IPv6 and then falling back to IPv4 and things like that. And then we'll send a report and it will load I think every 10 seconds or so.

IZUMI OKUTANI:

Was the observation similar, if people had a choice, people did prefer not to use it?

NATHAN WARD:

I didn't use it.

IZUMI OKUTANI:

OK, so the observation is that if people had a choice between v6 and v4, then most people use v4. I would like to move to the comments from the floor.

TONY HAIN:

I would ask that Geoff put up the graph that you showed in Berlin of, you know just the one slide graph because I think it has some useful data if you could do that.

While you're doing that, I was going to go ahead and comment upon Martin's point. I don't know exactly what happened at that point in time, but what I was going to ask in the question is, if anybody knows if the uTorrent capability got fixed at that point. It had been put in earlier in the year and was there a fix that occurred earlier in the year to suddenly get it working.

NATHAN WARD:

No, it came out on August 9.

TONY HAIN:

That's when it was officially released but Teredo was released in January. Somewhere between January and the release, was there a fix that caused it to start working?

NATHAN WARD:

Not so much a big spike like that.

TONY HAIN:

Unless it was broken, they fixed it and suddenly you see the spike. That's the question I was going to ask when I got up earlier. Is that something to investigate?

NATHAN WARD:

What I suspect it might be is a Teredo relay came on close.

TONY HAIN:

The Teredo client coming in...

NATHAN WARD:

Instead of as an absolute number, but as a percentage of local traffic, because maybe there was some peering changes that happened at the same time.

MARTIN J LEVY:

No, the traffic at AMS-IX has been growing.

TONY HAIN:

So Geoff has the graph up that I was asking for and if you notice, there's an inflection early in 2007, right. Late 2006 and early 2007 and so, when I was asking the question because at least at the time this graph was originally put up, gone back and done a study as to what set of machines that came from. But if you just step back and take the big picture view, what event occurred late 2006, early 2007 and it is Vista released. Right. So, there's not necessarily a correlation, but there's a question to be asked, if you're looking at your web server, what client is coming in and looking at whether there's an impact on that curve? Because if you look at that curve, that inflection time is timed with Vista release.

GEOFF HUSTON:

um, I haven't looked at that, obviously. I'm not precisely sure if we have that data, Tony. But if we have it, I'll certainly see what I can find.

TONY HAIN:

I understand that you may not have the data now. But I was suggesting that anyone who starts looking at that kind of data for their web servers, trying to figure out what clients are going on because there may be some significant client event that comes along later if you're tracking which clients are there, you may come back and say this client changed and all of a sudden it picked up.

GEOFF HUSTON:

The problem with this particular piece of data is that these two websites, www APNIC.net and www.RIPE.net aren't the most popular and the people who visit them are the slightly more geeky. We're not exactly measuring the broad population when I look at these two websites and in that respect, I think I'm taking a really biased sample. The other thing about this too is that NATs perturbed the v4 number.

TONY HAIN:

Sure, I'm not discussing...

GEOFF HUSTON:

You're right about the inflection point. Something certainly happened in 2007.

TONY HAIN:

If we could figure out exactly what that was.

GEOFF HUSTON:

Do more of it, do we! If we knew what happened, do more of it!

TONY HAIN:

It would be useful to know. That is actually I think something that was the title of the topic, how much is there and this is a good data point of how much there is and at least for the two websites which are primarily geeky and what not.

GEOFF HUSTON:

Primarily geeky! Thanks.

JAMES SPENCELEY:

Just a comment that the report looked for tunnel brokers. I think one thing I noticed is that the more bad news about v4 depletion, the more people uptake IPv6. I don't know necessarily if it is just people trying to prove Geoff wrong, but certainly in Australia, we have seen the last AUSNOG talk which was Geoff saying it was all Geoff saying it was doom and gloom and then talking about the NAT user base, so more an observation of doom and gloom, and that it is actually good news.

MARTIN J LEVY:

There was a very large follow-up and getting into the rough measurement and statement. There was a lot of comments in the IT press that simply said, you know nothing's happened or it could take ten years. A lot of glass-half-empty comments versus half full. My point of putting the graph up there is that we look for any major event, whether it be Lorenzo's out of Google or v6-only days that hit the press. And we do see an optic. I don't think that having an extra 40 or 50 users a day sign up for tunnel somewhere in the world is a consolidated attack against Geoff's numbers. But, it's good to see, it's good to see any update, that's all I'll say. It's good to see any uptake.

GEOFF HUSTON:

Do you want to throw more numbers around? We can throw more numbers around. Around about one to two part per thousand and if I am brutally honest, one or two per thousand. Of the 29,562 - we're talking numbers. 3,738 of them are actually transit and 25,424 are stuck. The reason why I say this is that it is not one AS per 1,000 which is doing some v6, it is actually 3 per 100, 3% of the ASes out there are advertising prefixes and you think, that's better than hosts but then I want to divide it between transit and stub. So of the folk moving other peoples' traffic, who is actually announcing a v6 prefix? So that's amazing because that number is 15.1%.

MARTIN J LEVY:

Lonely.

GEOFF HUSTON:

No, 15.1% is amazing so I look at this room and go, that sort of section over there are actually doing it. Whereas, at end hosts, of the 100 and so on people in the room, none of them are.

MARTIN J LEVY:

I'm going to counter that. 15% is low because it is the 15% measured of the transit networks out there, and if I can use the phrase - they're meant to the small ones.

GEOFF HUSTON:

15% of them are meant to be smart! I'm actually doing the glass is half full at this stage.

MARTIN J LEVY:

OK, I would expect it to be higher, that's all.

NATHAN WARD:

You would hope.

MARTIN J LEVY:

No, I suppose from a business point of view, I'm happy to be one of the 15%. But that's not a fair way to look at life. That's a business way to look at life.

IZUMI OKUTANI:

Well, I'm sure that there are different opinions on whether 15% is high or low, but thank you for providing the numbers and a comment from Paul.

PAUL WILSON:

Yes, Paul Wilson here from APNIC. It seems to me that this is quite a useful session, and it seems to me that it would be useful to have more in future, but everyone in the meeting here will have the chance to give their comments on the meeting feedback forms.

I'd just observe the one thing that you guys can't measure with your operational matrix and that's what is going on in everyone's heads in terms of plans and perceptions about IPv6. And I think it is - it has become quite important at APNIC for us to understand more and more thoroughly what are the perceptions amongst the members of the wider community about the need for IPv6 and the lines for IPv6 and at the same time, what are the perceptions about IPv4 and plans for use of IPv4 and retaining IPv4 addresses after the IANA pool has run out? I mentioned a couple of times in this meeting that the next round of the APNIC survey is coming up, that's the survey that's done every two years to really update the Secretariat of the EC about the views of the members about the present and the future, and in addition to doing the standard survey, I would like to add to that survey, a fairly comprehensive survey about those questions about perceptions of v4 and plans for v6 deployment. And I'm interested to hear any views about that.

I'm not sure if John is still in the room, the guy who carried out the surveys for us, he's here in Christchurch this week and interested to talk to anyone about the survey and how which phrase it and what's the most important issues. In addition, as I'm saying, in addition to the standard survey, I would like to be surveyed fairly comprehensively on these matters. I would like to know what the general view is.

IZUMI OKUTANI:

So Paul, you're suggesting that in addition to the regular standard survey that APNIC makes for APNIC services in general, you're planning to have more of a survey on the general situation on how the communities prepare for IPv4 address exhaustion as well as preparation for IPv6?

So, you want to have a show of hands from everyone in the room or you just want people to talk to yourself or John Varls individually.

NATHAN WARD:

I think a survey like that would be interesting to do with non-ISPs so businesses and things like that.

PAUL WILSON:

The surveys...

NATHAN WARD:

Universities and things like that.

PAUL WILSON:

Sure, the surveys we're conducting in particular is wider than the APNIC membership and we prefer them as member stakeholder surveys so anyone who has an interesting in IP addressing, hopefully would get to see the survey and have some motivation to respond. That point is taken and has been made.

IZUMI OKUTANI:

OK, so is that clear with you that OK, the scope is not just limited to APNIC members but anyone who is interested.

So, I would like to ask for a show of hands on how many people you feel is useful for APNIC to conduct a survey on its members as well as anyone who is interested to see the situation in general in our region, Asia-Pacific region, how people are aware about people address exhaustion, as well as how prepared they are for the v6 deployment.

If you think such a survey conducted by APNIC would be useful, please show your hands. OK, thank you. So I guess the Secretariat got the general feeling?

PAUL WILSON:

I think I did, thanks.

IZUMI OKUTANI:

So one last comment from the floor.

JASON SCHILLER:

My question is for Geoff Huston about the number of ASes advertising IPv6 and I wonder if you have any statistics on the number of ASes that are IPv6-only with no IPv4 prefixes? And the number. Why I ask is because at least in our business, our strategy was to build an IPv6-only overlay to experiment before we rolled it in to 701. So I'm wondering if some of the transit ASes which are not announcing IPv6 have a separate AS that they're using?

GEOFF HUSTON:

It was a really good idea that you had, Jason, and you were the only one who had it. So the answer is one!

IZUMI OKUTANI:

OK actually, the time is up for the panel. So, well, if each panellist has any comments that you would like to make about your statistics or anything in general, please feel free to make comments. It is not compulsory. If you don't have anything, you don't have to.

MARTIN J LEVY:

I highly recommend going to your local book shop and picking up a Penguin Press Book published in the UK when I was at high school called 'How To Lie With Statistics'.

GEOFF HUSTON:

I highly recommend you don't get it.

IZUMI OKUTANI:

To all of the panellists and APNIC will hopefully take your show of hands in consideration and conduct some survey in the future.

APPLAUSE

SRINIVAS CHENDI:

I would like to ask Martin to stay here.

We all know how important it is to have sponsors for a successful event like this so please join me in thanking our sponsor for the day, Hurricane Electric, Martin J Levy, thank you.

APPLAUSE.

So what Martin is going to do, is as we can see from the screen there, the numbers will start totting up. If you have participated in this experiment, we have your IP address! If you raise your hand, one of the APNIC staff will come to you and verify your address. Miwa did mention that we do apologize for excluding some of the members in this audience from this draw. We think that you've been there and you've done it and we want to give you the opportunity for those who have been there and want to do it.

Thank you very much. OK Martin.

MARTIN J LEVY:

Press one, once!

APPLAUSE

SRINIVAS CHENDI:

So, is IPv6 really working! Oh no! It's just randomly picking up the numbers from the log file, so whatever is in there. So please check your IPv6 range! You nod any help, please raise your hand.

APPLAUSE

The price is Apple Airport Soho IPv6 wireless routers which is IPv6 enabled.

APPLAUSE.

OK, we have one more, so Martin, please!

MARTIN J LEVY:

Anybody still running on the 3 ffe space, I'm pretty sure that the software will not pick it. Now is a good time to hand it back!

SRINIVAS CHENDI:

There it is. Please verify your address. There it is. So will we run it again?

MARTIN J LEVY:

It's not yours or mine, is it?

SRINIVAS CHENDI:

NO, I KNOW MINE!

MARTIN J LEVY:

OK, going once and twice and again.

SRINIVAS CHENDI:

It's the same Apple Airport Soho IPv6 wireless routers again.

MARTIN J LEVY:

The number that's so important!

APPLAUSE

SRINIVAS CHENDI:

Thank you Martin and thank you for your sponsorship. I think it is time for the break and the tea is served outside the room. Thank you everyone for participating in this session. Please go for the tea break and there are more sessions continuing after this.

(End of session)

IPv6 in New Zealand

Wednesday, August 27, 2008

1100-1200

IPv6: Does it work for you?

NATHAN WARD:

Onward, I suppose. I am doing a lot of promoting IPv6, sorry?

SPEAKER FROM THE FLOOR:

Inaudible.

LOUISE FLYNN:

We had a couple of bottles of wine from last night we missed out on drawing. I'm going to get the last three panellists to dig a card out of the bag. Nathan is the most illustrious. Someone who needs more wine, Skeeve Stephens. I'll hand deliver it.

MATSUZAKI YOSHINOBU:

Braintrust?

NATHAN WARD:

Yes. So I'm doing a lot of promoting v6 throughout New Zealand, helping teach training courses and things like that. So this is my view of how IPv6 in New Zealand is going at the moment, I'm sure I'm missing parts of the picture and all that sort of thing, any of you guys, if I get something wrong for whatever, please yell at me, while we are going. So, here is our rough New Zealand IPv4 topology. We have got a bunch of the parent exchanges around the place and most of the providers that peer at the Auckland peering exchange and the Wellington one, here we are in Christchurch. Some people peer at the other ones. It all goes through Auckland right now.

So the v6 topology is pretty similar, except there the tunnel here, does the tunnel still exist? Andy? There is a tunnel between Auckland and Wellington peering exchanges for v6 only traffic, if you advertise it in Wellington, it will pop out an ad in Wellington. The difference? We have peering exchanges in v6 and all the good stuff. So the way that we get v6 transit now is all over tunnels. We don't - I don't think there is any of the carriers here have v6 natively running over the networks to their routers in New Zealand, let alone to customers in New Zealand. There is no-one getting native v6 here?

ANDY LINTON:

There are some of the second-tier providers, often a v6 experiment service, but it is linked back to the rest of the world, all over tunnels, but they are offering it within country.

NATHAN WARD:

I have a v6 native over ON a server in Auckland, they did it over a tunnel from AS 703. So the domestic connectivity is pretty strong between providers that are connected to the Auckland and Wellington peering exchanges. There is the tunnel between the two exchanges and that sort of stuff, a good amount of connectivity there. There is, you can also, if you are not a direct peer on the exchange, you can tunnel to the exchange. So Andy is running a couple of little tunnel servers there so if you have your own lab network you can connect to the tunnel servers and there you go.

There is quite poor connectivity between people who are not connected to the exchanges directly or on the tunnels, tunnels from say, HE or whenever and they their connectivity is going visa the US and all sorts of crazy stuff. It is pretty bad. So offshore, we have these main sorts of v4 providers, sorry if I miss anyone else out who has v4 international.

Now, two of these guys, in my understanding, offer v6 service experimentally over tunnels only. They might have a native v6 service somewhere else in the world but not here, so we have to get stuff over tunnel.

SPEAKER FROM THE FLOOR:

Telstra (inaudible).

NATHAN WARD:

So there is the tunnelling protocols I was talking about before, the 6to4 and Teredo stuff, some have 6to4 relays that are used by the network only and my understanding, there is one publicly available relay. So they are advertising the 8821191 address to domestic transit customers or something. And there is Teredo. There is hardly any Teredo relays, I hardly know of any v6 that are running Teredo relays except for the ones that have turned them on in the last couple of days while I have been nagging. There are no publicly available Teredo relays, it doesn't appear on the exchange or anything like that.

So, in terms of commercially available service, there are a few providers that will do v6 service, like Andy was talking about, they will do v6 service but you can only really get it if you know their tech guy, he is the only person in the company that know they have it.

It is an experimental thing and playing around with it and that sort of thing. So if you have problems with it, helpdesk can help you out. It is experimental, the service I get is OK. It doesn't work terribly well, there is hacks I have to do to make it work better.

There is one provider that was doing v6 over ADSL. ADSL is our predominant connecting of homes in New Zealand and there was one provider doing IPv6 over PPP but they had to stop, because their bearers couldn't convert anymore for some reason so they have turned it off. Is it still on? Yep.

So in terms of the IPv6 policy type stuff, the ISPs that I have talked to say you should roll out IPv6, let's do it, they say there are no businesses asking for it yet. Most of the engineers who build the stuff play at home, have a bit of a lab at work if their provider has a lab, and some of them have v6 nodes.

So there is not a lot of it going on in SIG ISPs in any commercial way. There is no-one doing a supported v6 service yet, if they are they are in the room and would have told me otherwise to now, so there you go.

So there is an interesting thing, the ISPs are saying, "No-one is asking for it." And the businesses are saying, "When ISPs offer it or demand it, we will say yes, can we have v6 service." There is a lot of businesses that don't know they need to get it. They have heard about the v4 but they say, "When the ISP comes to us, we will do it", but the ISPs say, "When the businesses ask we will do it". So it is back and forth.

There is a problem when if a business in New Zealand wants to get tunnels and v6 over tunnels and that sort of thing, they will end up getting a /48 from HE and a tunnel and that sort of thing and then a letter, when they start off, with v6 they have to renumber, they are not going to start rolling out the v6 and coming out until the ISP does it because they don't want to have to renumber.

And, you know, there is ways around that. There are ULAs and things like that but so few of these businesses know what v6 addresses even look like, let alone ULSs exist and there is ways around the problems and that sort of stuff. So the Internet exchanges, there is very little v6 traffic. Andy, do you have a number of the traffic over v6?

ANDY, LINTON:

The tunnel that links the two exchanges in Wellington has a massive 1 megabit per second and it is nearly out, it is BGP announcements going forwards. There are no services for anyone to be looking at. It is more sort of engineering staff can work out what they need to do to get the stuff working.

NATHAN WARD:

There are 74 v4 peers and 10 v6 peers and WIX has 16. There is not a lot. One will be the exchange and peering to the other exchange over the tunnel, around about 10 tunnels for tunnel servers. So those are for people who don't have native v6. Sixxs have a POP here. I don't know if it is how you pronounce it. It is an ISP in Wellington. A bunch of people have started to use it. They have been playing with that. That is all good.

Then there is the Tui thing, which is a sort of pet project of mine. It started off as a - I saw this need for more Teredo and 6to4 relays. So we went and built a appliance to build 10 megabit, which is more than enough for New Zealand traffic. We started giving them away to get them installed. So this thing it does is it will build a sort of full mesh with the other Tui boxes automatically, so if you have a Tui box and another ISP has one, it will build a v4 tunnel from one box to the other box and advertise prefixes back and forward and that sort of thing. It uses 6to4 magic for that.

I have got a picture of examples. This would be a v4 only network. This would be a v4 and v6 network. So the idea is instead of sending this traffic via the international Teredo and 6to4 relays, we are sending it over the local exchanges and that sort of stuff.

So, then there is getting the stuff built. I don't think there is anyone who has gone, "Let's build the IP network project", let alone funding for it. A lot of stuff that is built right now, yesterday afternoon we sat in a room and sat on the phone to some people who are not here and got a bunch of stuff done and that is how it is happening right now. There is no manager saying, "Get on to the v6 project or anything like that". I think I'm about done. Thank you.

MATSUZAKI YOSHINOBU:

Questions? Nothing so far? OK, thank you. The next presentation is no?

DEAN PEMBERTON:

One of the problems you mentioned is the lack of native transit providers bringing v6 into New Zealand, some of the providers aren't doing v6 anywhere, some of the providers are doing v6 but only POPs. Are there transit providers here that can give some sort of hand-wavy, fluffy indication of when they are thinking about providing native POPs here or native transit providers?

JAMES SPENCELEY:

We at Vocus are focussing on building a link. Once we launch the v6, we are happy to offer v6 services to special projects and a customer basis.

MATSUZAKI YOSHINOBU:

The next is preparation for IPv6 in Japan, the speaker is Izumi-san from JPNIC.

Back to contents

IPv6 transition: perspectives from Japan

IZUMI OKUTANI:

Hello everybody, my name is Izumi Okutani and I'm from JPNIC, just to briefly introduce myself, my area of expertise is the policy area so what I am going to introduce here today is preparation of IPv6 in Japan, but not in terms of operations but what are the measures that are taken by measure Internet bodies in Japan to prepare us for the world after v4 exhaustion and deployment of v6.

Before going into the details of the measures taken, I would like to briefly introduce what are the Internet players in the Internet industry in Japan. Firstly we have operators, Community Journal, which is a Japanese version of NZNOG or NANOG in North America and several industry bodies such as IAjapan, JAIPA, that represents ISPs and you have similar promotional bodies in other parts of the world, we have the same thing, the IPv6 promotional body and a national Internet registry, which is where I'm from.

Some might wonder why the ministry in charge of Internet area is Ministry of Internal Affairs and Communications, you might wonder why it is listed here but we have quite a well balanced relationship with the government in terms they don't really try to regulate us or control the industry. But they observe and take interest in what is going on and they are also happy to fund, if there are any projects that are necessary or facilitate, things such as working groups where you can't do it on your own, like efforts of individual private companies.

So that is the general major players in Japan in the Internet industry. So now I will try to introduce what we did last year in 2007. A notable thing is both JPNIC and MIC have published a report on IPv4 address exhaustion issue and it did an analysis of what exactly it is and the issues we will be facing, possibility solutions and issues as for each solutions. Each report is really long. But they are available in English and at least for MIC's report, if you look at the third URL, it is an overview, so you might be better to look at this one, rather than the over 100-page report. Both reports, JPNIC Japan is known as trying to promote IPv6 and proIPv6 but we try to be opened minded about possible solutions after exhaustion of v4 and try to think of other solutions such as NANOT and other resources. But after analysing the issues for each solution, we still feel that IPv6 may not necessarily be the best, but out of the currently available solutions, it seems to be the most reasonable and effective solution in the long term.

So that was the conclusion that was stated in both JPNIC's report and MIC's report, which were made independently. MIC report also makes further sure what are the action items necessary for each stakeholder, such as system Internet, ISPs, vendors have to take to address this issue. A particular thing that was noted it is quite important to address, urgently, fixing certain specifications between ISP's infrastructure and what we call access-line providers which we call providers that provide connection lines between ISPs infrastructure and end sites. So making sure that these two networks interconnect well in terms of the v6 world is important in ensuring ends sites will have accessibility to IPv6 network. It was a statement made in MIC's report.

And there are also other bodies starting to look at more, into the details of what they are specifically doing to address the problems. For example, in IPv6 Promotion Council, they have a working group called IPv6 and IPv6 coexisting Working Group. They feel that after the exhaustion of IPv6 we won't move immediately to the IPv6 world, there will be a period when people have to run both IPv4 and IPv6 but issues of Internet connection between the networks hasn't been listed enough. So the group is trying to list the issues and think of solutions on this.

At JANOG we have been handling this issue on v4 exhaustion as well as v6 transfer since the meetings two years go. They have been constantly discussing this. For JPNIC, we set up a specialized website to collect all the information focussing on v4 exhaustion.

We don't have too much information on v6 itself but we have a link to necessary, other necessary bodies such as v6 Promotion Council. So as you can see, we haven't really, like, reached a clear conclusion or good solution on the issue itself but other bodies in general have started looking into what they can do in more details to get us ready into the v6 world.

And this is just a diagram showing what, well, the top shows the stakeholders in Japan, not just Japan but Internet industry in general such as ISPs, vendors, system integrators, end-users etc. The vertical column shows what other issues they have to address. And if you look at the diagram and the stakeholders, you can probably see that in general, the recognition of the issue, the v4 exhaustion and get ready for the v6 is pretty much high among most ISPs that provide connection lines as well as servers. I don't know what is the correct term to say this but providers that provide, like, hosting or collocation people, they recognize the issue and they feel they have to do something about it. But, it is at this stage, I think our situation is not so different from the rest of the world where only a small number of large ISPs have started looking into it and seriously trying to test or look at the issues on what they can exactly do about it.

The others are just aware but don't know what to do. And for other stakeholders, such as vendors, end-user, corporate users, etc, etc, at this stage, they are not even aware of the issue existing in the first place so we need more promotion and raise awareness and outreach on the issue itself on other stakeholders.

So the overview of the year 2007, would be as a result of reports from MIC and JPNIC, which is government authority, well, a notable body in the Internet industry in Japan. The fact that these two bodies have published a report has really helped raise awareness within major operators and LIRs in Japan. But it is still at the personal level so at the corporate level, like management, I think there is still not awareness of the issue. However, it did help in raising awareness campaigns before the report was released. So people have started to look into what they can do on a personal level. That is the state of the year 2007.

And the future direction that we would like to head, this is, again, a diagram of what remaining issues we face and I wouldn't go into the details of each of the issues we have but it is the same diagram, the horizontal is showing the stakeholders, the vertical would be the type of, I don't know, actions that we need.

And you can see the dot in red, these are the areas we are facing issues and you can see that the issues are pretty much widely spread and various stakeholders and various areas that need action. A notable thing would be that some, I suppose, the first thing we must address is ensure that physical connection line in v6 would be available to have, to kick off the v6 but we still have some technical issues to be resolved and how to, you know, make the coexistence between v4 and v6 work, so ISPs have issues that they are still not able to resolve at this time.

If you look also at the red dots, that go across all the stakeholders, the information sharing between the stakeholders is a common issue that - it is an issue that is common to all stakeholders that we have to address. And well, that is, that was quite a detailed picture on the issues we have for stakeholders but as a general view we feel that there is not enough information sharing between different players in Japan.

For example, vendors, they are not really fully aware of the issue itself whereas ISPs feel they have to need to deploy v6 but not enough support from vendors and also even if we feel at a personal level you have to support v6, it is very difficult to justify the cost to deploy v6 network to your management.

Not a lot of real-life deployment experience, and so there are issues like this. We feel that sharing information between all these stakeholders would help raise awareness among different stakeholders, across different stakeholders, as well as if there are any issues that you can't solve on your own and you would need help of other, like, I don't know, from the perspective of collocation people, they would need help from access line providers in order to ensure they will be able to provide the service, by sharing this information that would help in trying to address this issue in a more integrated manner.

So the thing for the year 2008, we try to make a collaboration by various industry players. And how we are going to do this is we will actually set up a task force with various different industry bodies, such as telco, cable TV, data centre, ISP associates, operators for members such as JANOG and JPNIC.

The various bodies get together and try to share issues and see what we can do to solve the issue for IPv6 transfer. MIC is also there as an observer.

So at this stage, the purpose is to share information and also it is also important to raise awareness across all the different industry players, not just ISPs. So we try to use a PR channel of each task force member to ensure awareness will be widely spread within the industry, not just a particular section of the industry.

Another benefit we feel, by setting up this kind of task force is the task force member in charge of their particular area, for example, if you are from vendors association, then you are responsible in ensuring raising awareness on what issues vendors will face and pushing actions to address those issues. So that is the purpose of setting up a task force.

And the current status is how to kick - we held a kickoff meeting in July. We had two meetings so far, at this stage we don't have system integrators in the task force so we are trying to get these people involved as well. We are going to have a press conference, next month, 5 September, to raise awareness within the industry and as the country as a whole. And the next step would be that, well, it is a bit of an ambitious plan, maybe but we are trying to make sure that each stakeholder group will come up with the plan on how to transfer and get themselves ready in v6 network within the year 2008. I don't mean they have to do anything by the year 2008, they have to come up with a plan by the year 2008 and then based on that plan, hopefully, we can get ourselves moving and be prepared by the time of IPv4 address exhaustion. That is all from me. Any questions or comments?

PAUL WILSON:

I do have a question for you which comes from some of a little experience I have had talking to some ISPs but not widely, possibly something that could come out of the survey, but what I hear is that ISPs who are planning and, in a number of cases have waited seriously for the v6 deployment have a question mark over the peering relationships with other ISPs, not in the same countries but in other parts of the Pacific, I'm wondering if there is any talk, firstly, if ISPs in Japan have the same problem and if they do, if there is any way to approach that through the collaborative and cooperative kind of approach that you described here?

IZUMI OKUTANI:

I didn't quite get your question?

PAUL WILSON:

It is not clear to ISPs in a number of cases, in my experience, when v6 peering will be available with any of their peers on the other side of the Pacific Ocean, so they are trying to plan to deploy services but finding it very difficult to plan ahead to understand how many years or when, if at all, peers on the other side of the ocean are planning to deploy v6 and therefore, be in a position to exchange traffic. So maybe that is not a common problem? It is one I have heard.

IZUMI OKUTANI:

Yes, I think it is - it is a very good question. Well, this is task force effort is trying to, at least, do what we can do within Japan. And when it comes to, you know, peering with ISPs in other countries, I think we face pretty much the same issue and our basic position is that the, at the moment, everyone is trying to see what the others are doing and just wait and not see to do anything. We try to put a bit of breakthrough to the situation by saying, "You should try to do what you can do at this stage, even though others are not doing anything." So I guess, maybe it wouldn't be good enough justification or motivation in other cases but that is, at least, an effort we are trying to make here.

PAUL WILSON:

Thank you.

MATSUZAKI YOSHINOBU:

We have a current specific link as well, we are pushing the dual stack so our, all our trans-Pacific link is dual stack already. Any other questions? OK, thank you.

Next presentation is prefix IPv6 and address mapping for IPv4, IPv6 transition. The speaker is Xing Li.

Back to contents

Prefix-specific and stateless address mapping (IVI) for IPv4/IPv6 coexistence and transition

XING LI:

Good morning, I'm Xing Li and the slide IPv4/IPv6, Smooth Migration.

OK. So, we have been working on IPv6 since 1998. So that is a long, long time ago. The reason is as I mentioned yesterday, China, when we tried to wire the population in China, there is not enough IPv4 addresses, even back to 1993, 1994, we realized it was a problem. Now, actually, the issue we are facing is IPv6 deployment is not as fast as enough to transit away from IPv4 and the run rate prediction seems believable so it will be the year 2011. OK.

What is the fundamental reasons why IPv6 cannot really move forward, even though we tried in the past 10 years? Actually, we feel, based on our experience, that, actually, this is the presentation, I borrowed somebody else's and the restoration of end-to-end principle and restoration of the address transparency, multicast, better quality of service, embedded, better QoS, those are arrangements back to the early 1990s when we tried to promote IPv6 and, frankly speaking, most of us at this table are still promoting IPv6 using those arguments.

However, based on CERNET experience, it is not correct. The address place to keep the universal connectivity. Today we tried in the APNIC meeting, the first part of this morning tried to turn off the IPv4 connectivity. However, I believe most of us, if you connected to IPv6, you still using the net provided value and connect to your web server or email server. So connectivity is the thing. If we do not turn the connectivity back to IPv4, there is no hope for IPv6. That is our conclusion. Not the fancy features.

And this always proves to be our experience. Four years ago, we built, OK, the Chinese government initiated a project called CNGI-CERNET 2, it was a pure IPv6 network, it is a single stack, the original promotion comes, we ran CERNET, as you know, which is a big, big academic network in mainland China and we have about 2,000 universities connected to CERNET and the end user is about 20 million. When we started the 2 project, CERNET collected money from the end-users, both professors and the students and, frankly speaking, they are quite expensive. When we built CERNET2, it is a pure IPv6 network, it is free and light loaded, so no congestion. There is a link between Shanghai and other cities. It is a big pipe. So free and lite loaded. The users need to export the application into IPv6.

It seems reasonable, right? You can have something free and very high performance. Unfortunately, users do not really buy this concept, they rather pay and use the congested IPv4 rather than move to IPv6, added to the load. So it has failed, the concept has failed.

So we developed a scheme called IVI, actually, IV means four and the v4 and VI means the v6, so it links the two words, IPv4 and IPv6. The requirements actually, we evaluate the existing approaches. The dual-stack approach, actually, we believe is very, very bad idea because if the dual stack, nobody wants to move to IPv6, they just use the IPv4 and if everybody deployed dual stack, then everybody can get connected in IPv4, not IPv6 and turns into nobody really using IPv6, except for technical hackers, right?

And the internal architecture, there is no communication between the two address families and the translation mechanism, NAT-PT is not scalable lost end-to-end address transparency. We tried to design a scheme which can keep end-to-end address transparency and try to make it minimum space and globally liveable and affect the use of the global IPv4 address. We have to make the translator make different requirements for service, client and P2P. It should be independent, incremental, deployment and encourage migration.

The key concepts of IVI, there are four key concepts, the first is prefix-specific addressing and the routing. That means we are not using IPv4 map address or IPv4 compatible address. The second is bi-directions and explicit mapping. That means the mapping from IPv4 to IPv6 as well as IPv6 to IPv4 are explicit. I will explain the details later.

And also we developed something called extended address transparency. So actually, we can multicast the address. It is the same as the original proposal, IOG and ICMP, extension, the multi cast extension. There are several terms, like OK, I will skip that.

The idea is similar to other translation schemes. So we use the ISPs /32 in the IPv6 family and we put flat, for example, we put FF, 16 bits between bit 32 to 39. Then we embed IPv4 address from bits 40 to 71 and if it is 1, it is 1 mapping, others, add 0.

If you take your conceptual look at this, actually the ISP has their own /32. The ISP embeds the global IPv4 space into the portion of their own IPv6 /32s. The trick in IVI is actually we ask ISPs to use part of the existing IPv4 plug, for example, a /24 and they use it in IPv6, it means extends the address, translate into IPv6 and use this address in end systems, not stay in the translator.

It is the trick. So you can have an idea, like every ISP, /32, there is a part, you are really using that because that is the mirror image of the global. Inside that part you have a real host, a small group of real hosts actually, that is your own IPv4 address, you use that as IPv6 hosts. So how about two ISPs deploy it independently, you can see there is an overlap of the global IPv4 address. However, because the IPv4 address you are holding or using, it is not overlapping, through the allocation or assignment proper, so those parts will not overlap, you have a unique identifier which will extend your IPv4 address. So that is the idea. The rest is quite simple because then you can use the routing schemes in IPv4 just as the routing scheme you are using in IPv4 and the routing scheme in IPv6, IPv4 is aggregated so there is no exceptions.

And the reachability actually is quite interesting. Now you have a block of IPv6 addresses and this IPv6 address, the addresses are global routable, you can use the IPv6 address to reach the global IPv6 world. The block of addresses can pass through end to end and turns into a real IPv4 address then it is global reachable by the global IPv4 space so you have a single stack network by using a special IPv6 block, you can reach both IPv6 as well as the IPv4. There is no need for others to do corresponding multiplications. So you are on your own. If you employ IVI you can communicate with any IPv4 address in the world. If those two ISPs deploy IVI independently, still you can talk to each other, even though you are not showing your partner you deployed IVI because it is the image of IPv4 and IPv6.

So in this case you do not have optimal routing because it passes through two IVI gateways. However, if there is a global collaboration, you know your partner deploys IVI you can communicate using an IPv6 native. The Domain Name System is similar to other NAT-PT deployment. In this case, actually the Domain Name System translation, the gateway is totally entirely decoupled. So actually the translation of the domain names can be deployed in the end system. You do not need to rely on a specific Domain Name System, perhaps in this case, you use the AAAA records, somehow, the global DS, the way, like unified or unique Domain Name System record.

The next thing is multiplexing of IPv4 addresses. It is simple, it is like the NAT-PT idea, you can use the combination of the part and those kinds of things.

The trick is actually, this method can support both IPv6- and v4-initiated communication. If we allow the - we can embed it into the IPv6 address. However, if the multiplication of the IPv6 system is allowed, in one action, IPv4 to IPv6 it is stable. However, IPv6 to IPv4 is not stable because the part is randomly generated. So the simple deployment scenario IVI in between IPv4 and IPv6.

Another thing, you can cascade two IPv4 gateways. You have a IPv4 network and it converts. In this case we do not need to maintain the application gateway. Also, we can use the net chair and cascade it and extend it into IPv6. Also, in the dual stack case, we believe this will be the most of the cases in the future, we have IPv4, IPv6 dual stack inside. We suggest to use IVI address because it is both global IPv4 and IPv6, reachable to extend the dual stack core. Later maybe you can use other addresses. They can only visit IPv6, not IPv4 address, end-to-end fashion.

So actually, we implement IVI. Helping implement in two years. So you can download the Linux OS and also you can visit the home page and so that is a real IPv6, only web server, however you can use the IVI address to visit it. Once your connectivity is from the native IPv6 or from a translation and comparison with other techniques, there are several communicating techniques, one is called reduce the light. It is a carrier grade, NAT-PN plus NAT 64 plus IVI. Also it is put into historical status. NAT 64, which is a simpler version of NAT-PT and IVI.

So, comparison. OK, that is a, because of time, I won't go through the details. It is very interesting if you compare the state, maintaining it and the addresses. So dual stack lite, it is a carrier class and Randy Bush told us it is not good.

NAT-PT, actually, it supports both initiated communication, however the Domain Name System ARG is tightly coupled. For communication you just use the IPv6 initiated, so it is simpler, however, without supporting IPv4-initiated communication, there is no use for IPv6 and IVI. It is the advantage.

So IPv6 assignment policy, we believe if we adopt IVI concept, actually that is related to some kind of address policy in our APNIC community so we have to publish some kind of guidelines to preserve some of the IPv6 address as a mirror for the IPv4, for individual /32s. Also we probably need to use remaining IPv4 in multiplex and use it in IPv6 as well because this block can visit both IPv4 and IPv6.

My suggestion is probably to trial net 42, it is a good candidate to try to move forward. So the based on the idea, the top one is the conclusion from Japanese report, the image, IVI is some kind of multiplication, actually, we separate IPv6 into IVI and non-IVI.

So use IVI first and you can have all kinds of communication with using IPv4. Later when IPv6 community, when it gets big enough to reach the critical mass, use the rest of the addresses. So basically, this is my presentation. And you can try the URLs, thank you very much

MATSUZAKI YOSHINOBU:

Any questions? Comments?

ERIK KLINE:

I assume because of DNS, NAT, it means it will make DNS set not possible?

XING LI:

OK, because it is decoupled, it is possible.

ERIK KLINE:

It is possible?

XING LI:

You mean using DS?

ERIK KLINE:

Right, you are doing the 8.

XING LI:

We believe if we put this translation, the mapping and the system, we can restart and use Domain Name System. Not really tried it but that is the feeling.

ERIK KLINE:

I think despite the lack of funding it has been an inhibitor to make such proposals. If you are running Domain Name System, nobody can run in the zone but maybe it is the way it has to be to be get rid of dialling.

XING LI:

Maybe, probably you can try.

MATSUZAKI YOSHINOBU:

Any other questions? Thank you. So the next one is from IPv4 6 dual stack. The speaker is Tomoya Yoshida.

Back to contents

From IPv4 only to v4/v6 dual stack

TOMOYA YOSHIDA:

Hello, I'm Tomoya Yoshida from NTT Communications. This time I like to talk about our basic simple idea to do v4, v6 dual stack networks from the current networks. Our idea is another idea, not just from me, but we are thinking about how to deploy IPv6 and how to move to the, having happiness for end-users.

So anyway, beginning my presentation, I like to introduce a little bit about NTT Communications. So the NTT Communications has subsidiary companies. We have international community companies. We have two ASes. Another one is the domestic ISP, the biggest in Japan. This is the domestic backbone, so you can see the Tokyo, connecting to the, connecting with 200 Gbps. Japan is a long island so it is typical of the Japanese of the Japanese ISP.

From the big city, between Tokyo and Osaka there is a main pipe and the default is connecting to the big city, the east is Tokyo and the west is Osaka. The global backbone, here is the map of the global network. So assuming all the backbone is already deployed IPv4 and IPv6 dual stack network, the operational traffic is shifting to the IPv4 to IPv6, because we use the leased line.

We use the line service and hosting and the ADSL. Fibre to the home, and now the FTTP based, but a native is on the way. The transit service is, of course, a service that is more and more and more, it is ready for v6. There is our market, since around 2005 or 2006, the number of ADSL users are slightly decreased. FTTP users are growing.

IPv4 will exhaust in a few years, especially the number of broadband Internet connectivity is growing, for example, any growth of our OCN broadband customers is about 700,000. Also, if dialup customers will be converted to broadband, about 10 times larger IPv4 address space will be needed for it. So to keep the business growing we need to provide the customers with the IPv6 service, however, IPv6 is ready for network commitment but we don't think that all servers will be ready before the address completion.

So therefore, we need to provide some amount of IPv4 connectivity to the customers, at the same time for customers, we think. So even IPv4 address allocation completion before, we think we need to prepare some IPv4 access scheme to the customers, because we observed many old PCs, like Windows 2000 and the word is the Windows 98 doesn't have IPv6 support. Also, for windows XP, it uses IPv4 transport to resolve Domain Name System. So if we cannot enforce the customer to replace or upgrade their CPE router or PC laptop, so the step-by-step conversions and incentives are needed.

In that case, the left side, is today's typical setting for the Internet service, there is the backbone, access concentrator to the city with net function, through the fibre to the home or ADSL or other services. Inside the CPE, the end-users with IPv4 private address space in the home, but IPv4 address is going to be shortage, so what do we need to do in addition to the IPv6 service is have some NAT function around the access concentrator.

Some people say doing this, there is no need to upgrade to IPv6, but there is now. So because the NAT function has a serious function, so we need IPv6, for thinking about the NAT, so we have to limit the number of problems the customer has. For example, let's take 2,000 customers, share one same global IPv4. In this case, the number 64K divided by 2,000 is around 30 or so sessions can be used by each customer, this was the case.

Let's take a look at experimental research of the Google market. So this is an example of looking at the Google map from my PC using the NAT box with the limitation of the number of sessions. So this is 30 sessions, there is nothing happening. And if we look here, but if we do that 20, there is hole right on the side, so what is happening is because the AJAX technology is responding to the session to get the information host. So this is a typical way of today's contents, so the Google map is doing that. So if we do that, 15, it is hard to use and the 10... 5.

So, we do need IPv6. And from our other research, in iTunes, for example, hits the 270, the store, everything you see the connection, so therefore we do need IPv6 to let rich application and the contents, like AJAX or P2P. Sometimes the P2P exceeds 3,000 sessions. So please use the IPv6.

Also, we have done some observations in the domestic market. According to the, about 500 sessions are the average number, constantly of worldwide users. If there are several PCs in the home, there are very few people to share one single IP.

So one possible transition scenario from IPv4 to IPv4 IPv6 dual stack we will show later. This is one of the most conservative steps. The concept is very simple. The customer can be converted, one by one, and they don't need to purchase any hardware until some stage of conversion. Also, we think it is hard to enforce a purchase of a PC or CPE so we have to go step by step, we think. This is one positive scenario for IPv6. At the moment, there is global only service, on the Internet, for the router, nation-wide platform under that access concentrator and CPE router and host.

So in this case, ISP assigned to the customer one global IPv4 address. And in the end, the host, typically, they use RFC 1918 based private address for the hosting. So the most easiest part is the backbone. The so the dual stack backbone is not hard to do that tunnel IPv6 on your network, then you can have IPv6 connectivity. I think the ISPs here in this page. This is introducing NAT function.

Please, I know there is nothing to change on the customer side, so they can continue to use the equipment. And after that, introducing softwire concept. The BGP supports it. In this case, the access to IPv6 was through something, IPv4 network. After that, if their softwire line is terminated on the CPE, so it is almost dual stack, and before that, the access concentrator will be dual stack.

And probably, we think this last is wrong. So when the end host wants to go to the IPv6, they can use IPv6 subs. For IPv4, they can use the host so it is a dual stack network. Eventually, pure IPv6, will come, we don't know when it is, it depends on the market or users. So this is a scenario we are thinking about.

And last year, we already have commercialized IPv6 for over 5 million customers. Now we are constructing a Beta testing for ISP facility for a dual stack in Tokyo. And our new service, in addition to IPv6, is to start by the year 2010, in the autumn or something. We also are very happy if we could help ISPs, especially in the Asia Pacific, they will be facing the same problems. So we are trying to migrate to IPv6. Thank you.

NATHAN WARD:

I have a question, a couple questions. The slides. Any one of those will do. Can you say private IPv4 addresses, what do you mean by that? Are you talking about use RFC 1918?

TOMOYA YOSHIDA:

It is a good question. We are thinking about private spacing into the global space, so for the three or something, some big space we are thinking. But yes, some of these I know, but we are thinking to develop, we want to, we should use IPv4 and in addition to IPv6, of course we researched IPv6 but many customers need the IPv4 stack, this time, for my laptop, the experiment on the Windows XP. I couldn't access to some MSN or IPv6 sessions so I used the IPv stack, to be helpful for end customers.

NATHAN WARD:

The addresses you are talking about there, you are talking about some addresses out of your existing IPv4. And then reuse that several times?

TOMOYA YOSHIDA:

Yes. Somebody said that, this is suitable but it is not in good condition, so we cannot use the Windows PC and router. We need some other address space.

NATHAN WARD:

And so the other question I had is going back to the diagram again, that will do, in this situation, where the CPE has go to one where the CPE is before?

TOMOYA YOSHIDA:

v4 and v6.

NATHAN WARD:

In the access concentration is it v4 only and the other is v6 - this situation here, yes - without the software, if the RFC, at the airport or something, it will try to do 6to4 from that address. Have you thought about what to do in that situation? It will turn off 6to4 and advertise 6to4 addresses to the internal hosts?

TOMOYA YOSHIDA:

I think it is one transition model. Just a transition model.

NATHAN WARD:

Yep.

TOMOYA YOSHIDA:

So you mention about?

NATHAN WARD:

If, at the airport, if it has a non RFC 1918 address, on its interface, it will try to do 6to4 but if the address is behind NAT, that address won't work. Have you thought about how to deal with that and stop that from happening?

TOMOYA YOSHIDA:

We have, yes.

MATSUZAKI YOSHINOBU:

Any other questions or comments? We have five minutes before our lunchtime. Any other questions for these peoples? Can we go to lunch? OK. Then thanks for these speakers. Now we have our lunch, so please come back here, oh, 2pm. OK.

(End of session)