• Home
• About Us
• Contact Us

• Home
• About Us
• Program
  • Workshops
  • Keynote Speakers
• Venue
• Travel
  • Hong Kong
  • Tourist attractions
  • Accommodation
  • Flights
  • Getting around
  • Visas
• Remote Participation
• Call for Papers
• Fellowship
• Social Events
• Sponsorship
• FAQs
• Contact Us
• Spread APRICOT-APAN

• Home
• >
• Program
• >
• IPv6 transition conference
• >
• Transcript

Transcript: IPv6 Transition Conference

Tuesday, 22 February 2011 at 09:00

Tony Hill: Good morning and welcome to this segment of the joint programme for the week. This has been titled the IPv6 Transition Conference.

My name is Tony Hill. I'm chair of the Asia-Pacific IPv6 Task Force. Together we've been working very hard over the last few months to bring you a programme today that will give you a definitive idea of where IPv6 is up to.

I just want to make a couple of short comments and then pass over to our programme representative, but the first thing I want to say is that the by-line for our conference here today is final countdown to IPv4 exhaustion in 2011.

Those of you who are kind of watching this closely will say hang on a minute Tony, that happened on 3 February, it's already over. Well, it's not quite over yet until it's over. So there's some RIR -- Regional Internet Registry -- pools of addresses yet to be allocated. I hope that you walk away from this meeting today not getting any comfort from that fact, because the urgency of IPv6 is getting very, very close, and you'll hear that from a number of speakers today.

You should be able to get from our range of speakers a story about the economics of IPv6, about what it means for service providers, about what it means for governments and what it means for ordinary users. So I hope you draw those conclusions.

I also want to provide a welcome at the moment for all of the people who are watching us streaming around the world, whatever your time zone is, I'll say to you "good morning", because it's good morning here, but you might have just got out of bed somewhere in the middle of the night. So welcome to all those people who are watching us streaming on-line.

Right now I want to welcome Che-Hoo Cheng to the podium to talk about the programme committee's perspective.

Che-Hoo Cheng: Thank you Tony. Actually I don't have much to say, I just want to say a few words. I do it on behalf of the program committee. We have Kenny Huang from Taiwan, we have Prof Ma Yan from China, we have Tony Hill from Australia and me from Hong Kong, and Miwa, of course, she's helping us very much on the program. I want to thank them. And without them, we won't have such a rich program. This program actually is a joint effort of APAN, IPv6 Working Group, Asia-Pacific IPv6 Task Force, and also IPv6.World.Asia and we wanted to do it to encourage the Asia-Pacific community to move forward with the IPv6 transition.

It's been held in a very good timing because we are doing it right after IANA IPv4 address exhaustion. We have very good speakers to share the experience and knowledge, including Dr Vint Cerf from Google and we also have many other good speakers. I'm sure you already know quite a bit about IPv6 and this is the time to move forward with the actual implementation, we are talking about action.

Don't stay behind, do it now. I hope your weekend have very good IPv6 network going forward.

I would like to thank APNIC for the support especially the webcast side, so that remote participants can participate remotely from their home or office, and I hope this session will be very interactive, so I encourage you to ask questions and provide your comments.

Also remote participants, actually you can also participate remotely by asking questions. So feel free to do so. Without further ado, I want the program to start, and just one small look about the network. I worry about the network very much. And if you are using WiFi of course most of you are using WiFi, if you can see the SSID ended with 46A, please use it because it goes to dot.11A, that's running on 5 gigahertz. If you see it, use it.

Leave the 2.4 gigahertz for the others, and I think the network will run much better.

Anyway, that's it, I'll pass back to Miwa.

Tony Hill: Now I think I've probably got what is one of the most difficult tasks I'll have to perform today which is to yet again introduce Vint Cerf. You seem to have been sitting through introductions to Vint Cerf quite a few times, at least I have. So I wanted to try and pick up some points that haven't already been covered in introductions to Vint Cerf this week. You heard yesterday from the plenary session just how many awards and how much pioneering work Vint did. Of course that stands almost without parallel I think in this area.

But the point that I wanted to bring out was not just that Vint worked very hard on developing the technology of the internet but for a whole decade, particularly during the 1990s and into the noughties Vint worked very hard on guiding the policy direction of the internet. He did that particularly through his roles as the founding chair of the board of trustees of ISOC and later as the chair of the board of ICANN, and that was where I first got to introduce Vint.

So I think I won't take it much further than that.

Welcome Vint very much to give us his perspective on IPv6 and where we're going.

Vinton Cerf: First of all, thank you very much for another welcome here. This has turned out to be an extraordinary combined meeting, APAN and APRICOT. I've been very impressed by the quality of the sessions that I've been able to attend and by the people that I have met, some old friends and some new ones.

One thing I'm sort of standing up here thinking why does anybody care what this old guy in the three-piece suit have to say about IPv6, particularly given the history.

Bob Khan and I chose 32 bits of address space at the time that we wrote the first paper describing what the internet would look like. It was almost an arbitrary choice.

The host identifiers in the ARPANet were 24 bits long, so we knew we needed more than 24 bits because we had to identify networks. At the time we were doing this we thought maybe there would be a couple of networks per country because they would be big national scale nets.

We thought 256 networks would be enough for this kind of a system.

So we picked 32 bits as the address phase. Then later as the actual implementations of internet began in 1975 and proceeded into 76 several things came very apparent. One of them is that there might be more than 256 networks, and second that there was a need to split the Internet Protocol out from PCP.

So in this time period around 1977 or so there was a one-year long debate after this plan to split the IP packet format out from TCP, the question was how much address space should we assign to the internet protocol.

Some people wanted variable length addresses and they were shouted down because everybody thought it would take too much computer power to find the fields of the packets. Remember this is 1977 when computers were expensive.

Some people thought 128 bits would be appropriate because they thought correctly that there would be a large number of local networks. Ethernet by this time was about four years old. But 128 bits of address space is, as you know, 340 trillion trillion trillion addresses and when I was running the program in the Defense Department, I didn't think I could stand up and with a straight face say that this experiment needed 340 times 10 to the 36 addresses in order to carry out the work.

So no-one came to any convergence on the debate between these three alternatives, so I thought we're not making any progress, we're just arguing over address space, let's just stick with the 32 bits and get on with the experiment.

So here it is, 2011 and we realise that the experiment is coming to an end, and we have to implement the production address space which is IPv6.

I was going to suggest that if you're counting how long it will be before we really run out of the four addresses, when an ISP asks and gets the answer no, I'm sorry we don't have any left, we should probably plan to hire a fat lady who will sing on that day, because you know the expression: It isn't over until the fat lady sings.

The term "transition" is being used in this discussion.

I would like to suggest that this is going to be such a lengthy period of time when version 4 and version 6 addresses are in use, that we should really be looking about simply parallel operations. So the notion that this transition is something that will happen in a quick way I think is unlikely, partly because v4 addresses will still work, it's just that we won't have enough of them for everyone.

The other thing I wanted to observe is whatever I say this morning will be fairly lightweight compared to what you'll hear from the panelists, so I'll try to be fairly brief.

What I think is important here is to concentrate on getting the job done. Getting this job done is not deeply hard, but it is very meticulous. It has some relationship to the Y2K problem that some of you will recall and some of you probably lived through, in that particular case there was a very well-defined threshold, December 31, 1999. If you didn't have four digits for the year there could be confusion about whether 0 meant 1900 or 2000.

There was also a fairly meticulous task which was to go through all the software and find every place in the code that thought the year was represented with two digits and had to be replaced with four.

I recall hiring people who had long since retired to come back and go look at the code that they had written 40 years ago find the places where those two digits had to be replaced with four. Some of you may recognise the name Alan Greenspan. Alan was the head of the Federal Reserve in the United States for many years. I remember having dinner with him in 1999 before the Y2K deadline occurred. I learned over dinner that he was in fact a programmer as a young man, and he'd written software in the 1950s.

So I said: Well, Alan, why didn't you put four digits into the software back then and save us this trouble? He said: Well, first of all, memory was expensive and saving two digits was actually significant, and second he didn't think that any of his software was going to be running 50 years later. So it occurred to me that we also had made a mistake by insisting that we only increase the number of digits by a factor of 2 to four digits. Someone in the year 9999 is going to be really angry that we didn't use 5 digits. So there may come a day when somebody says 128 bits isn't enough. But that day is some ways off, I think.

So this is just to remind you that the number of hosts that are visible in the public internet seems to be doubling about every five to six years which is slower than before when it was doubling every year. However, an awful lot of machines are not visible on the public net, they're hiding behind firewalls or they are episodically connected.

So this is clearly just a lower bound. The actual rate at which machines need address space is probably going up faster than this, it's just that it's very hard to get a concrete figure for that.

The number of people on the net, as you know, is on the order of 2 billion and the mobiles are somewhere in the 4.5 to 5 billion range. A lot of you are here in Asia and we all know that the primary allocation of IPv4 address space from the internet signing numbers authority exhausted all of its available space. I thought it was February 4th, but Tony said February 3, is it really?

doesn't matter, but I should correct it.

Tony Hill: It's what part of the world you're in.

Vinton Cerf: Thank you. That's right. Good point. We have this international dateline problem.

Tony Hill: Both dates are right.

Vinton Cerf: What a mess, OK. So the run out of the RIR address space is probably not simultaneous, probably some RIRs will run out before others will. It's almost certain it will be during 2012.

I'm looking at Geoff. He's saying no. You think it will be before that?

Geoff Huston: Way before, July 2011 looks very likely for the first RIR.

Vinton Cerf: For the first one to have run out, thank you, Geoff. Do you have a big sign up that says: The world is coming to an end? Make your peace, because yes.

The Mayans are probably right, the world does come to an end in 2012 anyway. So thank you, Geoff. I appreciate that input.

One thing which I think has been missing from the whole story of getting IPv6 running is that the internet service providers have seemed to me to have been very slow to implement IPv6 and the explanations that I have heard are things like well, no one is asking for IP version 6. I would suggest to you that most users should not even have to know that there is a v4 or a v6, it's hidden behind domain names, people don't type IP addresses anywhere. So the fact that users are not asking sounds like a pretty weak excuse to me.

Another excuse is: Well, we haven't run out yet. I think this is very short sighted, because if you're an ISP one of your jobs is to make sure your customers can get to everyone who is on the internet. Even if you have a version 4 address the other party might not, for the reasons that Geoff implied just momentarily, moments ago, some people will run out in July of 2011 and have to start assigning IPv6 addresses. Those people won't be reachable unless the rest of the net has IPv6 capability.

So neither of those excuses strikes me as being very valid and it only motivates me to say that we should be asking those of us who have service from internet service providers, we should all be asking what is your IPv6 plan.

I've done a number of interviews over the course of the last day or so, and one of the things I've asked the reporters is that they should ask the Internet Service Providers what is your IPv6 plan and anything we can do to expose either the lack of planning or expose what the plans are so that the rest of us can prepare, seems to me a useful thing.

Many of you will know that there is a World IPv6 Day which is now planned for 8 June 2011. I think the original idea was June 6, because that would be 6/6, except I think that fell on a Sunday or something and that seemed like it might not be a good operational time to try this out.

I think if you're part of the IPv6 Implementation Working Group, task force, team, it will be very important for you to look at all the various situations in which a remote user might present themselves to you and your system. So that means not only someone that might be IPv6 only, but it might means someone who is coming to you through a tunnel or coming to you through other kinds of means of translating maybe through NAT boxes, every one of those different cases I think needs to be considered and once again we're back to very meticulous step-by-step evaluation of the various cases to make sure that you have covered all of them.

I think some people are worried that because we don't have a lot of operational experience with IPv6 that there will be some risks, that there will be vulnerabilities that haven't been uncovered. That's probably true, but the argument that we should not proceed with IPv6 because it's immature is a circular argument because if you don't do anything it will stay immature. The only way that we will get IPv6 to become more mature is to implement it, discover the problems and fix them.

I mentioned yesterday in my opening remarks that there are many changes going on to the internet today. IPv6 introduction is only one of them. There are many others.

So this is in the midst of the v6 introduction, you have to worry about these other things as well, but don't let the IPv6 problem hide itself in the midst of all these other changes. It is so fundamental to the ability of the net to continue to grow that it really has to be addressed with high priority.

There are lots of things that are part of the internet environment and there will be more of them. I think that this is another reason why IP version 6 has turned out to be so important because there will be this proliferation of devices, appliances.

I used to joke that every light bulb would have its own IPv6 address. Probably the light bulbs won't, but the light sockets might because they will want to be visible and controllable, you might want to be able to tell whether a light is off or on. I don't know if you're like me, when you go on holiday, when you're about a mile and a half away from the house, you start thinking did I leave this thing on, did I turn it off, can I fix it?

And in fact I remember at one point I was in Germany at a cocktail party in the evening, I got an e-mail from my wife saying that one of the circuits in the house was not working. It was the important one, it had the television set on it. And so I was thinking, I was trying to talk her through the circuit breaker panel. This is an artist, so this is not the first place that she would comfortably go to throw a circuit breaker. I remember thinking, if the circuit breaker panel state could be visible through the internet and I could throw the circuit breaker it would make life a lot easier. On the other hand, my 15 year old next door would have a wonderful time flipping the circuit breakers.

So once again, I would be smart to do very strong authentication before I would allow some of things to happen. So as you introduce IPv6 and a large number of appliances and devices on the internet, you should also be thinking very hard about strong authentication to make sure that access control is a part of the design.

I've already shown this slide before, so not only in this meeting but in other meetings. You've probably all seen it. I just want to emphasise that you can't predict what people will decide to put on the internet. We used to tell jokes about putting a toaster on the network. We called it toasternet and we would, you know, elbow each other in the ribs saying that's pretty stupid isn't it.

Until someone at an interop exhibition actually put a toaster up on the internet, you could remotely determine how burnt you wanted your toast. And we all thought that was pretty amusing. Here we are 2011, there isn't any question a large number of devices will be part of the internet environment.

I've already talked about my sensornet at home. The thing I want to emphasise it's a working IPv6 LOPAN radio based network. It's quite reliable, it's a commercial product, this is not something that I soldiered together in the garage. The fact that it is a mesh network makes it even more interesting. Every sensor is also a storing forward node.

As an experiment after it was installed, each one of the devices uses a AA battery, so it's a 3-volt system with two AA batteries. I decided to let it run until it stopped working to see how low the voltage could go before the nodes failed. And to my surprise, it went all the way down to 2.24 volts before it failed, which took about ten months or so.

Even the guys at Archrock I think actually didn't do that experiment so I feel like I contributed a small amount of information to them about the reliability of the net.

The Smart Grid is a program in the United States to put all kinds of electrical devices on the net and to allow them to get information about the cost of electricity, so that you could program the device to decide not to run like a water heater or washing machine at times when electrical prices are high. This is just the beginning of a larger number of systems that will be networked and will be tracking resource usage. So for example we might also be tracking not only our use of electricity but oil, gas and water and other kinds of resources.

Part of the idea here is to provide feedback to people about the lifestyle decisions that they make, because often we can't connect our decisions with what the costs are from an economic point of view. So this kind of feedback is only possible if systems are networked and can be measured and can report their results, which can be analysed and presented to you in some useful way.

Of course some of you will remember C3PO from Star Wars.

We'll also have the need for a lot of intercommunication among these various devices. Here's C3PO saying yes, I speak refrigerator, range-top and alarm system quite well, along with other languages that C3PO that is designed to deal with. We will have those problems with devices that collect information about different kinds of resource usage, we're going to have to be able to capture that information and understand what it means in order to analyse it successfully.

So here are some of the things that I believe people will have to do, maybe you will have to do, in order to achieve implementation of IPv6. One is of course every place in the software that thinks an internet address is only 32 bits will have to change to know that it could be 128.

Second, you'll have to be able to operate in dual stack mode, especially for servers. This is on the surface not necessarily terribly hard, but there's also network management that has to work in both modes. This is actually harder than if you were only running an IPv4 or only running an IPv6. If something goes wrong in the net, like a fibre cut or power failure, or some other kind of configuration problem, you may get error messages from both the v4 and the v6 components of the network and you have to be prepared to understand that this collection of errors may be related. So making sure that you have a system that can deal with both v6 and v4 errors and status reports and alarms is also a challenge.

I think one of the most visible problems, which will arise, is going to be problems with configurations at the edges of the net. In the residential environment people have network address translation by the devices, they have routers, they have firewalls, and these devices often don't know what IPv6 is at all. They may have been purchased some time ago before v6 was on the horizon as an issue, and they might actually break if a v6 packet shows up, or maybe just throw it away because it doesn't know what to make of it and thinks it's a corrupted transmission.

So figuring that out is not something that most users are going to be capable of doing. So if you happen to be a network service provider, or you happen to be like Google a provider of applications, helping a user figure out whether they are capable of doing successful IPv6 interaction is a non-trivial exercise.

So Google along with many others, is going to be spending a good portion of 2011 working with ISPs to do pair wise testing between that ISP and Google and the ISPs customers in order to at least surface what some of the problems are. If we're lucky we'll be able to categorise the various configuration problems, the various types of failures, maybe even find a way to help the equipment providers identify what users could do to remedy the problem. It might involve a download of new software, it might involve the acquisition of a new piece of hardware, but whatever it is I think we need to help those users because they aren't themselves experts in any of this detail configuration.

Another element of all this is that we're doing routing both in v4 and v6 statement which means that we have to run both protocols, routing for both of the protocols or packet formats. The routing may not be parallel, it may be the v6 connectivity and the v4 connectivity are not the same, they're topologically different and the result is that route failures of various kinds in v4 will not necessarily reflect in v6. So you may have connectivity in one protocol and not in the other.

Finally, I mentioned user training and bug fixing already. I think that ultimately we're going to have to make sure that our service systems in the case of Google will work with a party who only has v4 or v6, today we know they work with v4. But for somebody who's only running v6, there are questions like can they get to a resolver that will resolve with a v6 query, a query that comes in using the v6 protocol only. What about the domain name system, will it respond to both v4 and v6 queries?

There are all kinds of potential hazards when you look at proxies. So there are many different devices that could be a part of the chain between the user and the other end of the system, or between peers and in order to make sure that we've done all of our homework, we have to answer the question: Does it work when parts of the system are only capable of running IPv6?

This is not a complete list by any means, but when this panel is assembled which will be shortly after I shut up, one of the things I hope you'll get into both among panel members and between those of us who are participating in the audience is to listen for and ask questions about the problems that people have already encountered so we can learn from that so we can transition into IPv6 use.

There are lots of other problems here that I don't want to spend too much time on, not because they aren't important, but because I want to get to the panel.

I think that we will probably need ways of validating equipment that claims to be able to do IPv6, so their interoperability testing places like the University of New Hampshire in the United States and here as well, we will need to help users understand what's going on so if strange things happen they will at least be forewarned that some connectivity problems could arise.

I think it would be very handy if we could develop software that would help analyse for the user what steps they can take to recover if they aren't getting good connectivity in IPv6 or getting any. There are just so many different things that could possibly break. We have to think through every single one of the cases in order to make this work.

So the end game, I think that the NAT box that is around, even if you consider carrier grade NAT boxes just postpone the necessity to run IPv6. Another thing which is really kind of interesting because IPv6 allows the same device to have multiple IP addresses, we may have some interesting multi-homing effects that are a consequence of that.

In the long-run it would be very nice if it were possible to simply connect devices together and have them generate v6 addresses if they need to in order to communicate.

This, by the way, leads to a possibility of not having any routers in between, so the possibility of using IPv6 for two devices that simply have adjacent connectivity would be a very interesting outcome if we could figure out how to do that. That would have benefits for emergency services where people show up, there isn't any network except for the devices that are able to directly talk to each other. The mesh network that's part of the sensornet in my house has that characteristic because the devices serve as routers for each other.

And finally I think there will be certainly years if not decades of dual mode operation. It will be quite interesting to imagine when the last IPv4 address disappears from the internet. It's conceivable it simply won't until something replaces the internet itself. I don't know what that is either, but I can imagine that it will happen some day. Something better will be invented.

Maybe we'll use quantum communication or something like that, or some other interesting means of linking systems together.

But for a long time we're all going to be living with v4 and v6. Let's make sure we can live with v6, please.

Thank you very much.

APPLAUSE

Tony Hill: I'm told that Vint is on a very tight schedule and we're also on a pretty tight schedule today because we've had to pack in a lot of presentations for the day's session. So your chance for participation in questions will come with the panel sessions later on today.

What I want to do now is move on to our second keynote speaker who is Chris Fung from CPCNet. Chris joined CPCNet in April 2000 as a network engineer and was promoted the the director of the network in February 2009 leading the network team to ensure optimal operation of business core networks and hosting services including TrueConnect, the internet IPLC and the Internet Data Centre. Mr Fung also oversees different network development projects from planning design implementation to ongoing operational issues.

Can I welcome Chris to the podium.

APPLAUSE

Chris Fung: Thank you, Tony. Good morning. The topic of this seminar is final countdown to exhaustion of IPv6.

ICANN has actually handled the last five /8 IPv4 addresses earlier this month to all the five RIRs and it is predicted that sooner or later this year or next year the RIRs will be running out of IPv4 addresses.

The industry has been prepared for this day to come, but it has actually come a little bit earlier than what we have expected.

I still remember two years ago when I attended a similar event in Hong Kong hosted by the Internet Society Hong Kong that production was like later this year or next year. Actually when we look at the IPv4 address consumption in the last five years the consumption is very rapid, and it takes more addresses maybe compared to the last decade.

Why? I think there are two main factors that take up the consumption. The first one is the internet population.

Last year, the total internet users just bridged or exceed 2 billion. When we look at year 2000, it's less than 500 million, it's four times more when we compare in this 10-year period.

It's mainly due to the rapid internet in developing countries. As you can see the users in developing countries has been three times when it's compared with 2005.

Let's look at the figures. In China and in India the top two countries with the highest number of populations, when we look at the percentage of the people that can get connected it's still far below than the average, the developed countries.

Imagine that when these two countries keep on developing their internet and more and more people in these countries are going to get on-line. And suppose let's do the maths. If the percentage goes up to 70, that means that we'll have another 1 billion users going to connect to the internet.

Another factor is that every people will consume more than one internet IP. Let's take a look in your home.

You have your TV able to connect with YouTube and stream all the videos. And playing games with their friends in your home. If your kitchen you have different kind of appliance that can be able to connect to the internet, say to retrieve some recipes for your dinner.

When you are on the streets or in this room you can use your laptop, your mobile phone to connect to the internet to check your email while you are listening to the speakers. Also people are taking some photos and uploading to their Facebook account. This device and the number of users keep increasing such that we need more and more IP addresses in order to have them all connected to the internet.

So IPv4 is running out, but the internet will keep on growing. What can we do? Can we keep on using NAT? NAT was invented to solve the problem of v4 storage years ago, but we all know that NAT is not a good idea because it does not scale up, and many applications just don't work well with NAT.

Can we reclaim all the historical address space, can we do some training for those free IPs that someone else is not using? Well, it may help, but it just can't keep track with the internet users, the interest in the internet users. We are talking about 1 billion or more users and they have multiple devices to be connected.

So heading to IPv6 is the only solution that we can do.

The future rests with IPv6.

So IPv6 has been invented or deployed for more than ten years. One of the major differences with IPv4 is that address size. We have 128 bits, that means that we will have 340 trillion trillion trillion addresses for all our devices.

What does this number mean to us. If we are going to hand out all the IPv6 addresses to everyone in the world, everyone will get that number of addresses. So that means that we have a huge address space.

So what can IPv6 bring to us? It has a few benefits.

Nowadays, people get on-line for different kind of activities. They go on-line for e-banking, stock trading, learning, shopping, and people are checking with their friends, their workmates with messaging. They go on Facebook every day to keep updating their status and writing their comments in Twitter or blogs. Internet just plays an important role to our life and it would be hard to imagine what will life be if there's no internet.

In order for all those people to get on-line, IPv6 provides solutions because we can have enough addresses for them. Our life is connected, no matter you like it or not.

For enterprise users internet not only means that the communication is enhanced with their partner, it actually extends them new business opportunities. Like Facebook is founded in 2004 and it has more than 500 million users and the numbers keep on growing.

Like Taobao, an on-line shopping platform in China like eBay is doing 60 billion transactions in the last year.

It also helps promoting other related business industry, like logistics, transportation, payment settlement system.

So for this kind of enterprises, given the fact that some people will be given IPv6 connection only in the near future, that means that they can keep on growing with IPv6. And for new comers, if they can start providing services on IPv4 and IPv6. That means that they can start capturing that new market.

IPv6 can, of course give many other benefits like all the devices can have their unique IP, we don't need NAT. So we can simplify our design in hardware, software and network. We can develop more direct peer-to-peer applications for, say video conferencing, IP phone and gaming.

One of the concerns that people have when they are getting on-line is related to security. Is my transition safe? IPSet is a mandatory implementation. We can develop further applications with security in mind and people can do more trading or more transactions on-line.

That's another new applications.

So as Dr Vint said, IPv4 was invented as an experiment.

We were getting machines connected and now people are getting connected. In the future we can have all our things connected.

We can have tabs and sensors being attached in everything surrounding us. They keep on sending out their data and they are interconnected. It actually opens up a new way for us to see how the world will be and develop some new applications, like in the grid network. Actually it's being done in some of the countries and some of the companies. They are putting some sensors and meters in different parts of their grid network all the way from the plants to the household and buildings. They keep on measure the power consumption and trying to control the demand and supply over the whole power network. It actually can help increase the power efficiency and save more energy. We can make the earth more green.

Another area is in the health care. Sensors are being put on the patients or in the environment surrounding the patients and collecting data going back to the hospital.

So doctors can keep on continuously monitoring the patient's status. It can help develop the electronic diseases and cure them earlier.

Imagine that one day when all our vehicles on the streets are connected. Maybe we can reduce the total traffic to zero.

Another hot topic in recent year is about cloud and cloud computing. People supporting more and more the data and even the applications on the cloud. Actually, we can work and we can retrieve our data anywhere we like with any device we have with our laptop or with our hand-held or with our mobiles. It actually changes how we work and how our life will be.

Let's talk about the company. CPCNet is a wholly owned subsidiary of CITIC Telecom International Holdings Limited. We are headquartered in Hong Kong providing communication and security solutions to MNC and business enterprise. We are offering services like the MPRS IPVPN for 3G services, internet connectivities and data services. Last year we started to offer some cloud related applications.

Most of our applications are IPv6 enabled already, like we are offering IPv4 and IPv6 connectivities in our data centre.

So in summary, IPv4 is definitely running out and the only solution is going to IPv6. For those of us who are service providers or vendors, have you enabled your IPv6 in your network core. Are you offering IPv6 services and products to your customers. For content providers and enterprises, have you revealed your code to see if they are compatible with IP. For end-users like us, do you know if your service providers are offering IPv6 and when if not.

It's the right moment to deploy IPv6. Are you ready?

Act now. Thank you.

APPLAUSE

Tony Hill: Vint, if I could have you up here for a second. Chris, don't go away. Come back. I just have a small thank you gift which -- I don't know what's in there actually, but I think it will get through Customs.

Vinton Cerf: It's probably an IPv6 packet. Thank you very much.

Chris Fung: Thank you.

Dean Pemberton: Good morning. If I could invite all of the speakers for the next panel session to come up and take their seats. There's names written on the front.

That would be great.

While they're doing that, I'd like to introduce myself. My name is Dean Pemberton. I'm an ICT consultant from New Zealand. I'm also the chair of the New Zealand IPv6 Task Force Technical Special Interest Group. I'm one of the trustees for the New Zealand Network Operators Group.

It's really great to be here for a number of reasons.

I've been doing v6 presentations and v6 panels for a while now, and seeing how the presentations changed is a very good indication of where we're at with our v6 deployment. They all started off with every single talk being about what is IPv6. Then they kind of changed to IPv4 is running out, have you heard. Then they changed back to what is v6 again so everyone could work out what was going on. Now very slowly we're getting into case studies, so it's not just telling people about how great v6 would be, but also saying how many people have actually done it.

So in this panel session today I'm going to be moving through a lot of separate areas. So the first area is looking at infrastructure and really enabling capability.

Then we're going to break for morning tea and after the break looking through not only enabling capability but delivering on, and looking at the CDN networks and other content providers. Finally moving into extending that capability with looking at enabling v6 across mobile networks and academic networks as well.

So first up I'd like to call Satoru Matsushima to come to the stage. Miwa has just reminded me, can I invite all the other speakers up. Matsushima-san has been working in telecommunications since 1991, and leading Softbank's IPv6 architecture as the Deputy General Manager of the Network Strategy Promotions Department. We're going to hear now about Softbank's strategy of and delivery of IPv6 across their access network. Thank you very much.

Satoru Matsushima: Thank you very much. Good morning everyone. My name is Satoru Matsushima from Japan.

Today I'm talking about the Softbank Group's IPv6 deployment experience to share with all of you. It could be useful for you I think.

Let me start my presentation. The introduction is you will not be able to get additional IPv4 addresses any more. Of course you can have transfer, but it is limited and very expensive maybe.

You cannot get any additional revenue by IPv6. Some people may say yes you can, but it's old, maybe obsolete, a trick to promote IPv6. It is mandatory cost for your business continuity, so like replacing aged equipment.

So this is to figure out our portfolio to IP network. So we have broadband network and also a 3G mobile network.

In broadband network we have existing IPv4 only network and this year we have new IPv6 only network. Also 3G network it's IPv4 only, but it's divided by global network and private networks.

So we have now provided IPv6 service via 6rd, a new framework IPv4 or v6 technology. The other thing is, this year we've started IPv6 only network, but our current measure of application for IPv4 for connectivity to the customer, so we have to consider about the IPv4 connectivity to the customer in IPv6 only network.

So my headache is how we provide IPv6 service on the 3G side and also we have to prepare the exhaustion over both of the global IPv6, IPv4 and private IPv4 for others.

This figure shows the whole strategy of the IPv6 services. We disclose our concept IPv6 everybody, our customer can connect to both IPv6 and IPv4 internet through all of the kind of access networks. So this is our vision to the near future.

Let's start our existing IPv4 network deployment. This is pretty much, you know, all that you will understand the current status, we can skip out. But the important thing is we can monitor the CPE to put it on some technique over v6.

So yesterday some guy presented in the plenary about 6rd, so deployment to connect to the IPv6 customer. So 6rd can provide the prefix delegation automatically from IPv4 address. And it is reasonable to mention this phase of the initial IPv6 deployment.

Why we choose 6rd is the most reason is that cost. So any kind of stay true technique is expensive, but 6rd is like 6to4 technique, so not much reasonable compared to the other solution.

So anyway, we have to convince our business guys and board members to launch IPv6 service, so we have to make evidence of the IPv6 service starting.

So let's continue about comparing the cost efficiency for the subscriber. So this is really simple formula can be used, so we can always observe following result is the cost efficiency over solution is always a reason for the technique, so we can choose the stateless solution, 6rd for example.

This graph shows the comparison of 6rd to other solutions. It's really cheaper than stateless solution.

80 percentage less than ... solution.

We usually use, make a business plan to talk and convince our business guys and board members. So you know, our president Mr Song is famous in his success story in business, but really strict to spend money, so we have to take care about really much. So we make that graph simulation. So if we can have 300 yen per month from each customer that's really big business, but it's not realistic. So we have to make a less revenue to provide IPv6 service. But it's a good number, it can be achieved by a customer from 10 yen per month. That's a good number from a profit and loss point of view.

This graph shows the cash flow. For software cash flow is really important because the Softbank enlarge its business is every time. So when we provide IPv6 service, so we have to talk with our business guys, IPv6 does affect to our Softbank cash flow. That's a very important thing.

So our total expense also is important. So that's one simulation, it's not a real number, but we have to prepare the number of the total expense.

So finally we compare the other solution to the typical business plan evaluation method, NPV, net present value business.

So 6rd can make always much other solution. So we can talk to the business guys, with this graph, it's good material to convince those guys.

The result, we studied IPv6 service, our customers through the monitor CPE using 6rd, the service specification is, customers prefix delegation is /56.

The most important thing is the monthly charge, that's free, no additional charge for each customer. Of course that's limited to IPv6 point of view, the total internet connectivity service should be charged.

So this is a timeline to release the 6rd service. So we found 6rd in 2008. By 2008 November, we didn't have any short-term strategy to provide IPv6, but when we found 6rd it's good for us, because we can manage CPE and also we have to convince business guys it is a reasonable choice to do that.

So we started with an adjustment and product development, that's done in 2009. So that's the timing to convince our business guys, so we have made such a business plan at that time, so we have much discussion internally and then start the project to provide the 6rd.

2009 June is a real development scheme we started, so the other result, 2010 April, we had started that 6rd service.

Most of the time to spend development is the CPE, but of course 6rd is really small stuff, but the whole thing to provide IPv6 service is much bigger than 6rd. So 6rd is small but the whole thing and testing is pretty much to test all these things.

So the most interesting stuff on the next -- our issue is how we provide IPv4 connectivity on IPv6 only network.

So some people know in Japanese IPv6 circumstances, so we can provide IPv6 service through the NTT network. But we cannot control others assignment, prefix assignment directly to our customers. But also a customer can increase but we have to save the consumption of IPv4, how quick is a question, how to provide IPv4 service over a v6 network and also how to share IPv6 service with many customers.

So we had a study over IPv6 service deployment over IPv4 only network, so we want to have the same thing on IPv6 only network. The idea didn't come from 6rd but which is server protocol, which protocol is opposite. So IPv6 only network, IPv4 packet bring in IPv6 network. But stateless sharing should be deployed. So use a unique part of v6 into the IPv4, and also TCP, UDP port number.

That's the idea of naming 4rd, that's not joking, that's consistent wording with 6rd.

So this is how 4rd works. So if we have an IPv4 network we have /24 prefix on the whole of the IPv6 access network. A customer can get a delegated address to forward their account to ... CDF, that's a seed of the generate IPv4 on the port range. If that prefix CP get CP generate 10.255.AB.CD for its global IPv6 for others. EF can be used to port range. Actually we have to take care about avoiding using a very known prefix. That's the fundamental idea to share how IPv6 network use it, to use IPv4 for other sharing technique.

That's an example we have, but it's really simple but difficult to explain in this limited time so we can skip this description. But stateless solution can employ on the IPv6 network without IPv4 sharing. So this means not only 6rd can split over with IPv6 with others sharing.

Overview and some use cases are described in SAM and 4rd.

So CPE can automatically configure its shared IPv4 for others and port prefix based on delegated IPv6 prefix.

Border relay router can automatically form encaps header to subscriber with single tunnel configuration. So NAT 44 function and states only within CPE, that means the same thing for 6rd.

So another thing is mobile case. Mobile network we already mentioned about we are facing circumstances in which exhaustion of both IPv4 private and IPv4 global address, so global exhaustion by smartphone, private other solution by push application. So address uniqueness in SP network is much more important in mobile service. The question is that which scenario can be the most effective. So remember again, architecture dominates business plan, so we want to use stateless solution in mobile network hardware.

So this is a diagram of how 4rd works in mobile side, so just change the way to bring IPv4 packets via this translation instead of encapsulation. That's the same thing over a broadband case, it's really interesting, the stateless mapping can be used to both voer the translation and encapsulation.

So conclusion. The transition costs is mandatory for business continuity. Architecture dominates business plan, so nobody can help v4-v6 transition for ISP in business. So we have to take care about spending money.

Our case, a stateless address mapping might be helpful for both Softbank's broadband and mobile IPv4 to IPv6 transition. The issue is that no standardised stateless solution for IPv6 only networks deployment with IPv4 address sharing function.

That's it for my presentation. Thank you very much. APPLAUSE

Dean Pemberton: Thank you very much. We've got time for a couple of questions. I'd like to start one off.

How have you found the support in the end-user devices for v6 plus any of the transition technologies that you're hoping to use?

Satoru Matsushima: I'm sorry?

Dean Pemberton: How have you found support in the end-user devices for v6? Have you found that it's widely supported or --

Satoru Matsushima: Yeah, widely supported this time, from this time.

Dean Pemberton: Have you got any questions from the floor?

Vinton Cerf: Let me not suggest that you respond to the question now, this could be a discussion among the panel.

I'm interested to know how the 6rd solution affects the other panel members especially if they are serving customers that are coming to you by way of 6rd. I don't have any immediate evil problem in mind, but I am interested that this question be addressed.

Dean Pemberton: Thank you. I'd normally say that when you come to the mic to introduce who you are and where you're from. I don't think we needed to do that for Vint. I think that's fine.

I'd like to go on now and introduce Mark Newton from Internode. He's been with Internode for 11 years, and been responsible in the past for such jobs as writing their billing software and designing their MPLS VPNs.

Also overseeing construction of their data centres. He's currently team leader for their core networks and infrastructure group, taking care of their global long-haul networks and he's in charge of co-ordinating the roll-out of IPv6 across their company. He's going to show us the progress that Internode's made with their IPv6 infrastructure deployment. Mark Newton.

Mark Newton: Thank you for that, Dean. So I'm going to run briefly through the state of IPv6 at Internode, but I'll start by saying a few words about who Internode is and how we fit into the Australian marketplace, that's where we come from.

Our network and what we've needed to do to it to transition it to v6 and the broadband trial that we've had operating for about a year now that lets any of our customers opt-in to dual stack IPv6 if they so decide that they want to. And I'll finish up with some points that we've learned about how the roll-out has gone and what we need to do next.

Internode is an Australian broadband ISP. We're privately owned, we're actually owned by the guy that did the internet toaster that Vint was talking about. We've been in business for about 18 years now, so the company's old enough to vote.

We have a fairly good mix of business customers and about 200,000 residential broadband customers. Lots of eyeballs but enough content sources to keep the traffic mixes fairly good for most of the time.

We also have a bit of a reputation in the marketplace as an innovator and a thought leader. We've brought things to the internet marketplace in Australia that haven't been there before. We were the first ISP to deploy ADSL2+ in Australia for example. IPv6 is one of the places where we've tried to maintain that reputation.

The Australian marketplace has some things that make it different from a lot of other marketplaces around the world. Most residential broadband is ADSL+ on PPPoE.

It's where everyone brings their own CPE. We can't send everybody out new modems and routers. Everyone has their own, when they switch from one ISP to another they take it with them. Bit of an upgrade issue there.

The way that the customers come on to ISP networks is a combination of LL2P wholesale and about 7 or 8 ISPs of which we are one who build their own ADSL infrastructure.

The business models behind residential broadband services in Australia have fairly strong accuracy requirements on usage accounting.

ADSL services in Australia aren't sold on unlimited plans like they are in a lot of other marketplaces, they're sold with quota caps. So when you sign up for a broadband service in Australia you might get a limit of 80 or 100 gigabytes worth of monthly downloads. Every ISP has to make sure that they accurately measure those downloads because otherwise you get billing disputes that eat up the gross profit that you would otherwise be making out of those services. This is something that a lot of equipment vendors haven't quite got their heads around accuracy of billing is an interesting point.

There are also significant customer support issues associated with departing from any of this legacy.

Because the entire Australian marketplace expects that they're going to be connecting to ADSL on PPPoE, if we go to market with an IPv6 product that doesn't run over PPPoE and everybody who is intending to use it needs to reconfigure their CPE, that isn't going to fly. We'd burn our help desk talking people who don't know how to spell ADSL through reconfiguring their modems.

Our network, it touches North America, Europe, Asia, and Australia. The Australian portion is about 60 milliseconds wide. It's from Perth to Brisbane. We have at least two major POPs in each state capital and at least one B RAZ or LNS per major POP. So we run a dual POP architecture for fail over services. If a data centre goes dark we can usually service customers out of the upper data centre in the same city.

Looks a bit like that. That shows the pairing points. This slide is downloadable from the APRICOT website. So if you want to pair with us that's where we are.

Our owner and founder has always wanted to do IPv6 right from almost when the company started. I think it was called IPNG back then. Geoff really kicked us into gear when he predicted in July 2007 that the growth rates of IPv4 were a little bit higher than everyone thought. He predicted that we'd run out in 2009 though. So maybe we shouldn't have listened to him after all.

We did an outside in transition. So we started by turning up IPv6 at appearing edge router in San Jose, we had one router in our IS talking IPv6 and then we progressively brought it through the rest of our network over the course of the next few weeks. So getting our core network enabled for IPv6 took a grand total of about 3 or 4 weeks. That's every router except for the customer edge routers.

We killed bugs as we progress. We found, for instance, one of my favourite bugs was a CISCO 7200 running an IOS which would for no apparent reason inject IPv6 prefixes into the IPv4 rib. You'd see the first 32 bits of an IPv6 prefix in show IP route. Automated BGP config helped a lot. The way we do BGP at Internode we never touch the router configs with human hands, it's all done out of a routing registry database with a combination of the RA toolset and a bunch of pearl we've written in-house. That means we can change a pearl script somewhere and rebuild all the BGP configs, and if we want to add a feature it's really easy to do it that way. We make one change and it happens all over the network. Have to be careful, though, because it's also a good way to destroy the whole network at the same time.

So the core network was done and we had our first commercial IPv6 dual stack customer in January 2008.

That was Mark Prior who many of you might know. He has a colo box in one of our data centres. We also set up a trial LNS that we could multi-hop ADSL PPPoE sessions on to so that our staff could get dual stack IPv6 at home.

And this means that within the organisation, you can start building up expertise because people will have proper non-tunnel native dual stack ADSL at home, and start playing with it.

Bit of a digression. Is a /32 big enough? One of the religious laws that you often see on places like NANOG is whether everyone should get a /48. There are 65,636 /48s in the /32 that we qualify for under APNIC rules, which is a bit small for an ISP with 200,000 customers. So maybe not every customer is getting /48 unless the rules change.

It also means dynamic IP for us probably isn't going away. We are looking at the moment at in all probability providing end-users with dynamic IPv6 prefixes using DHCP 6rd and hopefully it will work. If it doesn't we'll probably have a little bit more work to do. It's in our customer trial at the moment, so it seems to work already.

So we're hoping a /32 is big enough because we're committed to it now. One of the other things that we've found talking to APNIC is that if we say we've got this /34 but we don't think it's big enough we'd like the mask changed please, the first I think that APNIC says is you'll have to give back your old prefix, re-number out of it. No, we're not going to do that. Yeah, it's either going to be big enough or we'll need another prefix or there'll be a policy change and the mask can get changed.

Broadband customer edge. Australia uses access methods that aren't widely considered by people who are described as IPv6 boosters. I think a lot of people expect that broadband subscribers come on to a layer 3 access network and they use stateless auto-config and neighbour discover and router advertisements to find out how to get to the rest of the internet.

We're using PPPoE with link addresses assigned with IP6CP and stateless auto-configure. We use neighbour discovery and router advertisements to allocate addresses for broadband CPE. We end up providing each customer with /64 for the link drawn out of a dynamic pool and we then use DHCP v6 PD for prefix assignment. Whether that prefix is static or dynamic depends on the type of customer. We sell ADSL services as residential grade or Soho grade. One of the features Soho gets is fixed IP addresses, those customers get fixed v6 prefixes.

We've actually described them for the purpose of the trial as stable rather than fixed because we reserve the right to change them whenever we feel like it. Most customers are on dynamic.

So as it turns out that deployment mode has been rather difficult with the vendors that we use. We first found that Cisco 10 Ks are a little bit IPv6 challenged. And support for those was going to be a long time coming.

But we switched to the ASR 1,000 series running IOSXE 2.6.X and that had its own bugs. We've been working through those with Cisco for about a year now. So we're running like a second generation engineering special of 2.6.2 at the moment for the ASL 1,000 platform. That seems to be working OK.

The customer facing trial that we've been running has been on Cisco 7200s which believe it or not seem to be the most mature IPv6 support. So what we've been doing for the trial is customers log in to our normal B RAZ LNS systems and if they're participating in the trial they get L2TP multi-hops to a CISCO 7200 that runs the IPv6 bit. And we've been running that on 12, 233 SRD builds, that's been working pretty well.

So to opt into our trial, all a user has to do is change the user name with PPP. Normally our customers log in as whoever at Internode.on.net. If they want to run dual stack they log in as whatever the user name is at IPv6.Internode.on.on.net same password, then they end up with a PPP session that negotiates IPv6. Several purposes for the trial, for CPE vendors, the trial provides a test bit that they can test their CPE against. This has borne fruit in a fairly spectacular way. About six months ago we got a phone call from someone at netcom. They said we've got this ADSL2+ CPE, we want to you test it and see if it works. OK, FedEx it to us. When it arrived, it still had their netcom at IPv6.internode.on.on.net user name configured into ti.

They'd been using our trial platform to develop the software to run dual stack IPv6 on their netcom CPE. So that's the netcom NB 6 plus 4 W, that was the v6 capability in that was developed on our trial platform.

A lot of the other vendors have done the same thing.

For some of our geek users, providing a trial that they can opt into provides them with the same benefits that our staff have. They can start playing with it, see how it all works mess around with it, they've been pretty happy with it.

For our own experience, it provides sort of an operational test bed, we can do debugging on it, and we can use it as a place where we try our provisioning systems for IPv6, address allocation, how is billing going to work and all those other things that ISPs need to care about.

A few bugs that we've found. IPv6 accounting support, we've found is fairly poor. I said that accounting we needed to be fastidious about. One of the interesting bugs that we found in I think alternate releases of IOS, it's one of those bugs that goes away and next time you operate it comes back, is not getting radius accounting for a PPP session, until all the protocols involved in that session have come up.

There seem to be two schools of thought. One school of thought says the session is up as soon as it's usable, another one says it's up when everything is finished negotiating. So if the B RAZ tries to negotiate ip6 CP within the PPP session, and the customer doesn't respond to that negotiation, the B RAZ says, I haven't finished negotiating yet, I'm not going to start accounting. You don't get any byte counts at all for that session, which is a bit of a problem if you're trying to provide people with quotas and caps.

DHCPv6-PD is a DoS vector on IOS at the moment. The B RAZ will emit a query on your radius server every single time a DHCPv6-PD is received from an end-user. End-users can send as many of those as they like. Every single one of them hits your radius server, there is no caching. I think that's a bug. I'd really like it to go away.

The D server also occasionally forgets delegations.

There's a bug we've found where an end-user will need to re-request their prefix delegation in order to get the B RAZ to remember that it already allocated it. That doesn't happen very often but it's enough to be annoying.

Bug roulette, it's the usual thing you get with pretty much every vendor. I'm picking on Cisco only because we use them. I'm sure we'd have a similar experience with anybody else. Finding software that works well with everything you want to do at the same time can be a challenge sometimes.

The current status, we're intending to migrate our trial platform from 7200 to ASRs running our 262 engineering special this week. I think it's actually happening today but I haven't followed up with the team that's doing that yet.

We'll leave it that way for about a fortnight, two weeks, and we expect that that's going to be reasonably smooth because we've been doing a fair bit of testing with it already. If our users who are involved in the trial, customers who have opted in don't uncover any new problems then we will move the IPv6 trial to our production B RAZ flat form in about two weeks after we, two weeks from now. So that means we'll stop multi-hopping.

Things that we still have to do, our address IP address management system is, to use a word from the Australian vernacular, agricultural. It needs a bit of a work. It needed a rewrite anyway, now the rewrite will have to include IPv6.

There's no ISG support on the Cisco platform for IPv6 and there isn't expected to be any for about another year.

So if you're doing anything with dual stack at the moment on the Cisco platform you have to do it without ISG.

DNS is a great big barrel of bad, but I work in networks, other people work in servers, so that becomes somebody else's problem, so I'm pretty happy with that. And the VPN v6 address family in our MPLS layer product we haven't really started with yet. That's another example of something we automate all of our configuration, so rather than having to go to every customer service and every router and making changes, we'll just be able to change a pearl script somewhere. I don't envisage that's going to be a huge problem once we have the v6 broadband bugs ironed out. In the meantime our NPSL layer remains v4 only.

Lessons. Automate everything. A couple of times during this talk I've said that we automate configs and that makes things easy. It really does if you're not doing it now, you should be thinking about it. But don't use v6 as the reason to automate, otherwise you won't start doing v6 until after you've got the automation bedded down. We probably don't need that right now.

Be practical. Religious laws on mailing lists about implementational details are really boring at the moment.

We're at the stage where we have to get on with doing things and we could have been having religious wars five years ago, oh my God, we were and we're having exactly the same ones now. I'll let those people do what they need to do in the background, meanwhile we'll get on with building it.

Vendors, no more excuses. Stop stalling and do it. We will not talk to any vendors who try to charge us extra for IPv6. We will not talk to any vendors that don't have IPv6 on the road map, preferably right now or within the next six months. There are no more excuses.

Shipped products and running code, everything else is detail.

Be incremental, it doesn't have to be all or nothing.

We've carved out a small part of our service offering and said we're going to make this dual stack. We don't need to touch all the other bits, we don't have to do dual stack DNS and dual stack MPLS, VPNs and all the other bits yet. At the moment we're focusing on consumer broadband because we have 200,000 customers doing that, we can clean up all the other stuff later.

That's it. Any questions.

APPLAUSE

Dean Pemberton: Do we have any questions from the floor?

Tony Hill: You were talking about how you like to automate a lot of your network management stuff which sounds like sensible advice. I was just wondering if you could expand a little bit more on the v6 implications of having that world. When you've had to take an automation product from the v4 area into the v6 area, how has that been, produced complication, how much work has that been?

Mark Newton: Because we've written most of the automation that we use ourselves, it's fairly easy to migrate it to v6. In the BGP example, for example, we use a routing registry database for the VSL to describe our routing policy. IRD for better or worse already supports v6 features. We just adjust the RPSL accordingly. Then the tools that we wrap around that database to generate the configurations we re-factored them a little bit.

So for instance I have a configuration file that lists all of my BGP speaking routers and the features that need to be enabled on each one and whether they're a member of a peer group and which protocols they run and so on.

Adding another field to that configuration file for an IPv6 loop back address and a few flags to say turn it on in this router was relatively trivial. Like a couple of days' work.

So I can't stress enough that automating network configuration and management makes all of this so much easier. If we had to log in to every router and turn v6 on it would have been a nightmare. But by running a few pearl scripts and making sure they're right first it accelerates it a lot.

Vinton Cerf: It's consistent on every router.

Mark Newton: Yeah. If we don't know it's right we'll make the same mistake consistently on every router.

We've never actually torn down BGF on every router at the same time yet.

Dean Pemberton: Any more questions?

New Speaker: My name is ... from Globe Telecome Philipines. My question is about how do you manage the security in terms of intrusion detection and to protect on the DOS set up and everything about security. How do you manage let's say, do you have already found out such as a firewall that can run v4 and v6 at the same time.

Again you name some if you have any.

Mark Newton: Yeah, so we do have dual stack IPv6 on our internal office networks now, so all of our staff have it at their desktop. The firewall that we're using for that is various variants of the Cisco ASAs, they do dual stack IPv6 now.

For residential broadband users running v6 over a PPP session isolates them from all of the other PPP users.

So we don't have to worry so much about things like RA spoofing, and the issues that we have to face to secure that are very similar to the issues that we have to face to secure IPv4 anyway.

So for the most part we've done security with v6 as a direct analogue to security with v4, like for like access lists and like for like features turned on on firewalls and so on. Does that answer your question?

New Speaker: Yeah. The same thing with Mr Satoru. How do you manage these things, security, prevention and everything? Do you have such a priority firewall system that is embedded in your system?

Satoru Matsushima: Actually we only have security system for the IPv6 service, but it depends on the security for IPv4 service. So 6rd is based on that v4 system. We can't keep the security issue with IPv4. So sorry, we don't have that worry about our specific issue.

Dean Pemberton: Thank you. I'd like to just pick up on one point that Mark said before about vendor support, and the recent questions's a good example of it. Not only is it high time that vendors supported v6 but it's also high time that they went a little bit further than claiming that their support was just putting an IP address on an interface. So plenty of firewalls I've seen claim they have v6 support. Trying to get feature parity across there is not always the case.

We've got a break now, so we'll let you all go away and have some morning tea. If we could be back here as close to 11 as possible, that would be great. Thank you very much.

(Break taken)

Tuesday, 22 February 2011 at 11:00

Dean Pemberton: Thank you. We'll get underway shortly.

If I could have the speakers back up on stage, we'll make a start. Thank you. Next up we have Christian Kaufmann, who's a senior manager of network architecture at Akamai Technologies.

His responsibilities include peering and capacity planning. He's also a RIPE working group co-chair and Chairman of the DNSSEC Executive Board.

Now we'll start to see how IPv6 is going to be used in content delivery for customers.

Christian Kaufman: As you have seen how the other side works and how the ISPs are doing certain parts. Now let's look at the other side how the CDNs see the whole thing. One or two sentences up front. In the last two, two and a half years since I work for Akamai, I was basically asked on every conference I was going to, so what is Akamai doing with IPv6? Normally that is when I try to change the topic either to weather, made a slight joke and say: Yeah, we're working on it, in a way, more or less. So I'm actually quite happy that today I have more dates and more details how we will do it and what we will do it and share it with you.

One marketing slide to just give you an overview how many service we have and how big the whole platform is. To basically make it easier for you to understand what that actually means to turn it on. So it's not just a script you run on our side and you know everything is enabled let's go from there. You actually have to do, well we on our side have to do a lot of things. This is not just including the network part, it also includes as you will see basically servers and mapping systems, it's just the logic how we distribute the traffic and how we actually send you to the closest cluster and all this distribution mechanism in between.

So, in general, when we looked at IPv6 and, yeah, what we actually can expect from, where is most of the traffic coming and how will this look like, we identified three big sources. We identified the transition technologies like the tunneling and carrier grid net, net 6to4, of course you have dual stack to a point. Most of the technology I think should be familiar, so I'm not going through them itself, but I will show you actually what the different transition mechanism and technologies actually mean for us from a CDN perspective.

So what we see is if you actually start looking at users which are coming either from tunneling or from carrier grid net then we see different problems if you compare it with IPv4. So one of the things we see is that every geoIP, every database about geoIP, every geolocation things which different of our customers are using either for licence content, which we should just deliver in a certain region in a certain country, every kind of abuse mitigation like black listing, white listing, or even website analysis to figure out what is my audience, where are they based and all that kind of stuff, does not work very well with carrier grid net and all these net transitions. Because as you know suddenly you have thousands, hundred of thousands of these users behind a couple of boxes and you actually have now really problems to identify where they are.

This then has certainly impact on the performance, because what we do is retry to figure out where are you based and send you to the next and closest cluster so that your traffic is basically staying as local as possible and it's not travelling through half the world.

That doesn't work too well with all the CGNs.

Another thing depending on the protocol and depending on the service you are using, we of course see broken applications. That includes the voice over IP, pair to pair traffic and makes everything with troubleshooting for example much more complicated. Because suddenly you're not just have one side and the other side, for end to end you have these magic boxes somewhere in between which is not really transparent. So at the moment what I'm seeing is broken you have to talk to the person who is managing the CGN box and try to figure out what the problem might be.

All these kind of things certainly lead to latency problems, either because the CGN box you just have a few and the traffic is travelling between them and then to you. But you also see MTU and latency problems when it comes to the tunneling part.

In a worst-case scenario at least for us you have multiple of these technologies behind each other and then you can't really see anything any more. So if something is then broken have fun figuring out what the problem is and fixing it.

But even if you think someone has dual stack and suddenly all the problems are solved, because there is no transition mechanism in between, it's not as easy actually. So what we see with the tests and I will show some of them later, that even if you have dual stack and a person is connecting directly to one of our servers, then the performance is actually much lower.

I think there are different reasons for that. One of them is all the interconnects, the pairing and the public pairing, private pairs, what you have normally between the networks are not as dense as you have them in IPv4.

Most of the people who have IPv6 sessions have less of them than they have in IPv4.

Another thing is just because you get a request for quota, actually doesn't mean the end-user really has good connectivity. So what we have seen is because of broken home gateways or operating system bugs, even if people ask for it and you actually deliver it, it doesn't mean that it really gets to them.

Another point is even if people have enabled IPv6 also like in a backbone or in the provider network, that actually does not mean that they also support it and monitor it in the same way. A lot of monitoring and reporting functions in networks and backbones is still rather looking like after the IPv4 packets and the performance of IPv4 and IPv6 just the next layer on top of it, but it does not get measured and reported in the same way.

So if something is broken or doesn't work as well, it is not really getting detected until someone actually has a problem and probably sends an email or complaint.

The last part is actually even if you have hardware which tells you that it has IPv6 support, it does not mean that it has the same performance. So you still see some of the equipment where the IPv6 part is rather done in software than hardware and just because it has an IPv6 sticker on it, it doesn't mean it gives you the same performance.

So what we did. We started a test with roughly 9,000 name servers in the world and measured against them.

Because end of the day the name servers, the resolvers of the ones you are using, is basically how we figure out from where you are coming. So we measured against them and we have seen that just for North America, for example, the latency between our clusters and the name servers is basically twice as much than you would see for IPv4.

One of the reasons is because we didn't have as much measurement points like we have in IPv4, so the test is not easy to compare, it's not apples by apples. But even then, double the latency, probably not a good start. For tunneled IPv6 traffic because of latency and because of MTU problems, the timing we have seen was actually even higher.

What we did then is we did the usual beaconing. So we put in this invisible gift on akamai.com and waited that people actually started to download it. That was just a very small sample, but again what we have seen is that the speed and the latency was actually nearly twice as much.

From other users which actually came to us, just roughly 10 percent where it was working had dual stack in the native IPv6 address. All the other people came via tunnel or one of the other transition mechanisms. So you see there's not so many IPv6 out on the eyeball side.

So how does the whole thing actually look like? So we have two big components. Like in comparison with the provider, he's updating his router, get probably dual stack on it, conficker is probably the DNS part and more or less he is done. For our side, as I mentioned before, we have to take care about all this mapping logic, to actually find the closest cluster for you. And we have to upgrade the servers. So when we looked at IPv6 in the beginning we, or it was really clear relatively fast that you have to have dual stack on the servers. So you can cannot just work with some kind of abstraction or transition layer on the servers. You really have to do it dual stack on routers and servers.

The other part, the mapping system, instead of just adding a little bit v6 support because the IPv6 topology of the internet and the speed is completely different, we basically built a complete new mapping system for IPv6.

So for us the internet now consists of an IPv4 world and an IPv6 world.

As the IPv6 part is in comparison to the IPv4 part actually changing a lot, and not as stable, it also needs a lot of manual work. So we actually have people like on a daily base looking into it when we have significant changes, or we see changes in the routing table or strange behaviours and then we have to investigate by hand and probably find a work-around or fix for that. But there is not just the point that you actually, or that we are ending up with two different tables like the v4 and v6 table because we want to give the customers -- this is what we get paid for -- the best performance. We actually also have to figure out which one of them we want to use. So actually we need a comparison between both tables and then make a decision from where we want to serve them.

The router part or the network part, was actually the easier part. So we started to dual stack first all the Internet Exchange Routers and some of the Transit Routers and as you can see, we are kind of half way through and the idea is to have actually the network part ready by end of Q1 this year. So by then all the Internet Exchange and the Transit Routers will be dual stack capable and from then on we got to figure out how we get all the sessions together.

As you might know, the Akamai part is a little bit different. Instead of just having pairing and transit to deliver the content we also actually put servers in the network of the eyeballs. So we build little clusters, he places them somewhere where it's convenient for him and then these clusters, these servers are delivering his downstreams or eyeballs exclusively.

So to actually do that and be able to operate them for IPv62 we started to contact them one after the other and ask them for IPv6 space, so that we can enable these clusters too. So if you have one of the clusters in your network, you've either already got a request or you will receive an email soon maybe ask for IPv6 space to enable it on these servers too.

So how does that actually look like from a customer and content perspective? So we put the whole IPv6 development into different transition phases or into different parts. So, I talked with Miwa before, there is no big switch which has IPv6 on it, you have one magic day and you switch it over, we have these different phases.

So phase one actually already started. So for a selected set of customers, customers which are interested, we started to either enable IPv6 on an own IPv6 site, like ipv6.customer.net, or enable beaconing on his content on his website to actually enable him to get a feeling for it and to start some measurement. So this is something we already do. This gives us then the opportunity obviously to test it but also give the customer some feedback how many people are using it and reporting and log files so that he actually can adjust and adapt for it as well. So the customer basically can start offering IPv6 like on a different URL, but he is not breaking his existing website or his existing services.

Show a picture for that. IPv4 clients obviously go to the normal cluster as before. The IPv6 clients then there's a different URL, like ipv6.example.com will then get the specific IPv6 website.

Later in the year, second half, the idea is to offer the customer basically IPv6 and IPv4 on the same website. So instead of having a dedicated host name, he then can do both of it on the same host name.

So how does that look like? If a dual stack customer actually makes a request to the customer site, the mapping system which has built up a topology for IPv4 and IPv6 before and measured the performance, makes then a decision how to deliver the content. It isn't IPv4 only customer, it's easy. If it is an IPv6 customer, we actually will look into it where we think we can deliver him better. If our mapping system and our measurements have shown that the performance is either much worse or might be even broken, then we try to deliver him via IPv4 instead of IPv6.

Our customers will then in the second part of the year have actually the opportunity to influence how aggressively they want to use IPv6 or not. So they have the opportunity to say even if the IPv6 speed is significantly slower we still going to deliver it, or if it is too much worse like double or triple the time, then please don't do it.

Picture for that. Depending on what he is requesting IPv4, he gets IPv4 content and for the IPv6 we then try to figure out how we can serve him best.

Afterwards beginning of next year the idea is then to actually enable IPv6 for the origin. We have to get the content from our customers somehow. Until then we will basically get it via IPv4. Afterwards we basically offering IPv6 as well. So the current status is that as of today we actually already delivered various IPv6 traffic, not so much for customers but for test sites we set up and as I mentioned before the beaconing for our own website where we did the download and the speed tests.

We are also supporting our customers if they want to attend the ISOC IPv6 day on 8 June. So for customers who are interested they can opt-in and then we will deliver their content on this particular day.

A couple of comments about the experience we had either with the mapping and the DNS part, and with our routers.

So what we basically did is instead of just make a search and replace and add all longer fields for IPv6 and all the software we have, we basically had an abstraction layer add a IP as a generic thing to the software and then different check between IPv4 and IPv6 later.

We're still finding actually a lot of bugs when it comes to the operator system or the browser, at least we can see it when they connect to us. But when it comes to the underlying linux operating system which we just use like everyone else we haven't actually found any big problems or errors.

The router part. As we basically just started to do that for the dual stack part, something like three, five months ago, and we have relatively new operating systems, enabling dual stack and having a standard config you basically can find with explanations all over the place on the internet was not a big thing. So that part was actually the easiest part to enable.

When it comes to network interconnects, it is actually quite interesting. So even if you would think that most of the backbone providers by now offering IPv6, you will actually figure out when you trying to audit in exotic places even in Europe, Eastern Europe or so that not every backbone provider gives you IPv6 in every city.

Another point, this is actually from our perspective, from our department perspective one of the biggest problems is to enable all these sessions to have comparable density of peering and transit. So basically comparable capacity.

We are right now at 46 internet exchanges and we literally have thousands of sessions. So basically bringing that up to the same level like IPv4 means you have to open a ticket, send them an email, wait, configure it, close the ticket. Even if that just takes 5 or 10 minutes, if you have thousands of these sessions you have an idea how much work that might be. This is something where script doesn't really help too much.

Last part. One or two comments about the allocations we have. So we will use for IPv6 two allocations. We will use an ARIN space, /27 and a RIPE space.

Akamai does not really have a backbone. So all these thousands clusters you have seen on the first page and all these servers are actually not connected with each other. They are single islands which are attached to the network, or to the internet either as an on-net server in an eyeballs network or on an Internet Exchange.

So then actually means that we have not an aggregate announcement, because all the different internet exchanges will have a different /48 or /32. So we might end up being the biggest de- aggregator for IPv6 soon.

Good, so far. Any questions?

Lorenzo Colitti: I have two questions, actually. I'm interested in whether you sort of separated the performance loss between native and non-native clients and, if so, what you found. You said IPv6 has twice the latency as IPv4. What is the impact of tunneling on that? You said only 10 percent of your users were native. Do you know how much, what the difference was in latency?

Christian Kaufman: You mean for the difference between the tunnel and the native part?

Lorenzo Colitti: What you said is IPv6 is two times slower; right? I'm curious if it's two times slower for everyone or if it's much lower for the 90 percent of users that are using tunnels and it's not much lower for the 10 percent of users that are native.

Christian Kaufman: No, the twice the late tenancy is mainly for the tunnel people. So the native part, it is -- I don't have any figures now to back that up, but what we have seen it is slightly slower, which we think has something to do with not as many interconnects and probably travel to another country, city, before it goes back. The main latency issue is certainly the tunnel part.

Lorenzo Colitti: The follow-up to that is I wonder what -- you're saying, as I understand it you were rolling it out gradually. I'm wondering how you expect the latencies to change as you roll-out more v6 to more clusters.

Christian Kaufman: As I mentioned before, one point is that we -- the speed, even if it was twice like the latency the comparison is not really fair because we have less v6 clusters. So it's having more customers. It will certainly be faster. The biggest point was the tunnel and CGNs, not so much the lack of having IPv6 clusters deployed in the same way like the v4 clusters.

Lorenzo Colitti: Can you reveal the name of one of the customers that is trialling this or is that confidential?

Christian Kaufman: That is a good question.

Lorenzo Colitti: So somebody can measure it.

Christian Kaufman: Actually I think that is under, yeah -- I'm sorry.

Dean Pemberton: Do we have any more questions from the floor?

New Speaker: As you mentioned there are a lot of transition mechanisms. From civilian point of view do you have any recommendation for ISPs, service provider, which transition mechanism may be better than the others?

What kind of, you know, in other words what kind of transition mechanism the ISP adopts mainly either for you CDN to run your overlay services.

Christian Kaufman: I have not really any recommendation, because to be honest it also depends on how the whole thing is set up. So my recommendation is really dual stack, or if you really go for like, just taking one example the carrier grade net, then please have multiple of these boxes, see they're not overloaded and in different geographic regions, so that the traffic is not going half the network and then back, which adds another latency part.

But I think when it comes, you know like tunneling versus VGN or versus any other technology, the set-up is actually more important than the transition technology in itself. So I can't not recommend one or the other better.

Dean Pemberton: Thank you very much.

APPLAUSE

Dean Pemberton: OK, next up I'd like to welcome Donn Lee who is a senior network engineer at Facebook. He's in charge of designing networks, evaluating products and optimising performance. Prior to that he worked at Google with their network architecture group and at Cisco as a consulting systems engineer. He's also the author of "Enhanced IP Services for Cisco Networks". Thank you.

Donn Lee: Thank you for the intro and thank you for the invitation to speak and discussion some of the IPv6 initiatives that we have here at Facebook. I'll walk through a variety of topics so you won't see three sections from me, you'll just see a bunch of random slides. I hope that's OK. I hope to give you an idea just kind of the -- an overview of the various things that we're thinking about and that are important to us.

So the first piece is World IPv6 Day which was announced by ISOC and at the time there were four, five anchor companies. This was the work of a lot of -- this was the result of a lot of work in 2010. Primarily in taking the idea from just well this would be a really nice thing to do to a reality.

So I want to thank all the companies in ISOC for making it happen, it's going to happen in this June.

It's important to us in several ways. First we believe that it's good for Facebook. Because if we're going to get serious about IPv6 we need to start testing it. You can test all you want in the lab, but the real test is when you put it on the internet to real users.

It's hard to do that unless you have good awareness to all of the users and to the folks that connect the users to the internet.

So the first part is having, for us, a stage where multiple companies from various parts of the industry can work together at the same time with the same awareness so that Facebook isn't just testing in the dark or underneath the covers and making changes without notifying ISPs or notifying users. So that's really important to us.

The next piece is that we believe it's good for ISPs. We want them to know when we're turning it on because we don't want the ISPs to be surprised. We don't want their call centres to get any unusual volumes of service requests of users having any issues.

We have been approached by ISPs who say, you know, Facebook, you're 20 per cent of my traffic, you know, we want to deploy IPv6, what are you going to do about that?

When are you going to make your content available on IPv6 so that my users can browse and supply content to Facebook and share without us having to go through some type of work around? Essentially we want native v6 connectivity.

It's good for users because we care very much about user experience like many web companies. So we want the users to have as much awareness and help if we're going to make some change, like dual stacking the website. So we believe that if there's awareness with all the good folks, all you in the room, that if you're close to the user then you can participate on this day and you can make your users aware, your call centres prepared and we can all do this together with a co-ordinated effort.

So synchronisation is important, synchronisation of our operations with ISP operations with users with, if any users are affected, where will the users get help? All of this, I believe, are good for the global internet ecosystem if we're going to truly test IPv6 at the next stage.

OK. So at Facebook, we have these World IPv6 Day initiatives. Of course, it started with the idea and then a press release in January with ISOC to make it known that this is going to happen and these companies are committed to doing this. And to invite anybody who wants to participate to sign up for this day and participate on June 8.

We are gathering user statistics to we had to code our own instrumentation of users and it's much like what you've heard already about are they coming native, they are coming over 6to4 tunnels or some other transition mechanism and what users may be vulnerable to any dual stack brokenness or complications.

And, of course, we have to do adequate messaging, so I'm here today as part of external road show to let all of you know that World IPv6 Day is very much a huge initiative for Facebook's v6 strategy.

Also, we have to work internally with our group. Our user support department as well as departments such as sales have to know that this is going to happen, what's going to change on this day for 24 hours, how it could impact, for example, the launch of new advertising. You certainly don't want to launch a massive Facebook ad campaign on June 8, that would not be a good idea. We want to make sure that everybody internally knows that June 8 is a special day.

On the code side, we do have to make changes internally to ensure that our systems are prepared for World IPv6 Day. We continue to augment our network capacity redundancy, just like any good network provider should.

And we want to do things like create places where users can self-test their internet connection before the day and then be identified and have How To pages and How To Connect or how to diagnose their connection. So a little bit of the most common issues that could be out there and how users can change their settings so they won't be affected by this day. Then user messaging. If we can identify these users and we have identified some of these users that are broken, what's the best way to let them know that they could have a day, say on June 6, two days you're going to possibly, very probably have problems. These are things that you can do, test your connection and how to fix it.

Then PR. So you'll see some more IPv6 PR from us and I'm sure from a lot of other participants a few days or a week leading up to the event.

I talked a little bit about instrumentation, so a big part of knowing the impact of dual stacking Facebook as well as World IPv6 Day which we dual stack for 24 hours, is this project called check6, which is our code that determines if you, a Facebook user, are broken or if you'll have any difficulties.

So we provide a non-invasive check for users that are selected at random to provide data on their v6 connectivity and it provides feedback as to how well their v6 connection is working if they have v6 or if they have some type of vulnerable operating system that's been subject to let's say, rogue RAs that are passing before checks, they're before only, but because of the dual stack connectivity or the dual stack destination, they have a loss of connectivity.

So what we're finding is that it's a very iterative coding process, requires a lot of help and collaboration with other websites and operators. In learning about how they're analysing data versus how we're analysing data, what's the best way to clean up the data so that we're really truly measuring dual stack brokenness. We're finding, within this huge ocean of data, that there's a lot of odd client behaviour which I'll walk you through.

Actually, I don't have specific examples, but in this talk, but there's strange things that will happen that I'll mention in the things that we've coded.

And what's really critical about this, what we're finding, is that you're really mining tiny, tiny, miniscule numbers from a huge data set. Any time you do that, if you happen to mis-filter or capture the wrong data, it can throw your numbers way off. You could possibly not be aware that you're capturing certain pieces of data and number numbers can be completely off from what is reality. That's the hardest part. But I think that part of one of the objectives of World IPv6 Day is to do a "for real" and get as much real data as we can. So that it's not just simulated, for example, like with a non-invasive test in the background of a page.

So the way we construct these tests are that we have a Java script client that runs on the browser and we provide a server side, what's called a bug, which is a small invisible communication or connect, TCP connection over HTTP between the user's Java script end point and our data centres.

We started by serving small or invisible images, for example a 4 by 1 image, if the user reported that they see a 4 by 1 image, that means they're v4. If they reported a 6 by 1 image, then that meant that they have native v6 connectivity.

What we found in this part of the odd client behaviour is that users and Java script and browsers will report all kinds of strange numbers. The majority were what you would expect. For example, you see numbers like 7 by 1 images, which is nowhere in our code, or 8 by 1 or 12 by 3 or prime numbers like 17 by 3. We don't know why this happens, but because of the fact that clients are out there, they are in all kinds of environments, proxies or translators, Java script could have bugs, you get all kinds of bad data which screws up your data.

We said images aren't going to work for us, so we went for a JSON load, which is very lightweight. That worked well. Although our data looked too good. It looked like there wasn't too much brokenness out there. It wasn't until we noticed we weren't counting the time-outs that users were experiencing, the common time-out of trying v6, timing out and then trying v4, if you did that you would succeed, you wouldn't be counted as broken. We added this duration, which is how long did it take the user to run.

And so we run this test on a percent of users. There's a very large percentage of our users, so we have over 500 million users and we run way, way, way over like a one per cent of users. So it's a very large amount of data, but it's also we feel very exhaustive data. We are capturing more data than we need. 1 to 3 per cent would give us a good sample size. There's more development to do. There's a lot of iterative coding we have to do. So the numbers that we want to get into is like world global brokenness, what percentage of users are broken.

Ideally it would be nice to have it by country. I think that's interesting data to see how it may vary depending on v6 penetration. There are OS version, having a time-out. A histogram here of the time-out values that you see. An estimate of the number of v6 users.

This is a graph, a histogram of the time that it took a user to complete a test. So what happens is most users complete the test in one second or less, two seconds, so those numbers are huge. There's no reason to graph that.

If I put the histogram, this bar would be as tall as one of these skyscrapers out here.

I looked at what about clients that took five seconds or longer to complete the test. You'll see it's nice long tail type of graph you expect, natural exponential curve.

You can see here at 75 seconds, there's like a tiny, tiny bar right there.

So I'm just portraying how small the data is that we're trying to mine, because you can't even see the data, the broken users in this graph because there's so many tests that fail on because maybe the user's logged out, defragging his hard drive or something.

The next graph I'll zoom in, in about 20 seconds. You see here if you look at 20 seconds, you cannot tell with your eye if there's any important data in here, but when you zoom in, you start to see peaks. So you still see this exponential curve, this looks like the previous one, now you're zoomed in, but you still see this noise floor of just long tail random data. Now, you start to see the peaks. These peaks indicate broken users. So a human can say look there's definitely time-outs, 75 seconds, one 65 seconds, those are the users you want to identify, those are the users timing out on a dual-stack website, in this case dual-stack bug.

I zoom in further and these are the peaks that we're seeing. There's huge peak at 75 seconds. These were Mac OS users who are vulnerable to dual-stack brokenness in conjunction usually with things like their home gateway having bugs.

One 65 seconds we believe that's Linux based in talking to Lorenzo and looking at his data and his knowledge that he's collected over the years. Then you see these other ones that appear to be perhaps Windows users.

But you'll see here what we want to do eventually is to take out the noise of this curve and just reveal the broken users only. It's a prolonged process but we're going to get there.

This is a chart of the Mac users, so we take all the samples of the users and we just look at the Mac users because Mac users are the most vulnerable, they account for the largest population of user brokenness. If we fix the Mac users essentially we could turn on dual stack today, because the numbers would be low enough.

And we have been in dialogue all of us with Apple. Apple has many reasons why they can't -- oops, that's my old slide set, OK. So essentially what happens here is that if you're 10, 6, 4 or lower you're extremely vulnerable.

So the biggest contribution of brokenness is right here, this red piece of the pie, this green piece of the pie and this blue piece of the pie and this kind of purple piece. That accounts to about 40 per cent of Mac users, which is a huge population if you think about that.

40 per cent of Mac users are vulnerable to bugs, usually with their home gateway. Not a good situation and in those older releases of Mac OS, Apple currently does not have plans to implement those changes that are in the other pieces of the pie.

But we're working with Apple, they have their own strategy and company plans for how they're approaching the v6. They definitely have v6 advocates and architects within the company, so it's a long process and it's always very complicated every time you get to something like a huge user base like Mac.

So switching gears, large scale NAT. I don't like carrier grade NAT as a name, because, first of all, I don't believe that large scale NAT is carrier grade. I think the name makes you feel warm and fuzzy and I don't think, at least right now, that large scale NAT is a warm fuzzy type of thing we should subject users to, at least in this current stage.

Also carrier grade implies it's only for service providers but it's not true, it can be used for enterprisers as well. Anyway, I will use LSN. I don't like CGN. The strategy for us is to provide an end point for new v6 users to access directly. V6 provides a model of today's internet, today's internet has grown to success because it's open and it was essentially free for you to join and it's direct. So open, direct connectivity is a model that has been proven operationally and to support users. I believe that that is the road that we should go on. And it's good to see there's so much traction this year.

Our production backbone, we've had a few initiatives here, I don't know how this interesting is for you guys.

But essentially we have our edge of the network, our own private backbone data centres that are connected as well as elements inside the data centre. For us these are the v6 solutions that were deployed. ISIS initially, then go straight to dual stack, BGP, and then make sure we have of course v6 transit appearing. Then in the data centre we have deployed v6 load balancers that provide address translation. We're not touching the servers or the hosts for v6 at this time.

This is how the load balance era dress works, it's been a nice solution for us. Essentially we can serve, we're able to serve Facebook to v6 users with very minimal changes to the Facebook infrastructure. That means not touching the host. So you don't touch the host, you put the LB in front of it, you put a v6 address on the LB and all the LB does is provide a v6 VIP, virtual IP, that's in DNS. So the user connects to the v6 VIP, do I have a web server to hand this connection off to? Yes, all right, I send it off. Do I care if that web server is v6 or v4? I don't. But if it is v4, I've got to send the packet to a v4 web server, so it's automatically doing address translation and we can do this because of the fact that it's a full proxy model that we have to the load balancer.

Then we have this dual-stack backbone of course.

So what does it take to open the floodgates to where we could get raging amounts of v6? Because then all the users can -- that have v6 capability can use Facebook natively. Well, it goes back to instrumentation and understanding the blast radius of dual stacking the website. Then the testing, communication internally, with the users, and doing v6 in production in what I call small leaps. It's hard to do things in very small incremental -- to make progress if you're constantly doing very tiny steps. Eventually you have to take the next step and serving more and more v6 and providing greater exposure to v6 to the users. Then you have to iterate. So World IPv6 Day handles quite a lot of this -- these key points, testing and taking this leap for 24 hours in a dose.

These are the sites that are set up as sidecar sites for v6 users. Sidecar, yeah, that's what I call it, yeah.

You've got to know the secret URL, it's like the secret handshake. These are the sites if you have a mobile device you can connect your laptops right now, I saw v6 was working just fine in the room. Then we have another project that didn't have time for this talk which is using lisp to serve Facebook to v6 users using lisp instead of native v6. If you're interested in that do a search in Facebook. These are testing websites, of course on June 6 you won't have to type the v6 -- sorry June 8.

So with that I'll thank you for your attention and leave it open for questions.

APPLAUSE

Dean Pemberton: Awesome. Do we have any questions from the floor either about Facebook or World IPv6 Day? New Speaker: Have you managed to do any corporate v6 deployment to support your production engineering?

Donn Lee: Yes, when I was leaving the plane, we were putting a corporate on the network so we could get white listed.

New Speaker: I was about to send you an email.

Donn Lee: We have deployed in a matter of a few days v6. We just had to get it to the right router that had the core connection.

New Speaker: So engineering desktops and wireless.

Donn Lee: That's right.

New Speaker: Sweet.

Dean Pemberton: Good to see, yeah. Awesome.

Next up, we have Lorenzo Colitti from Google. He's performed extensive research on IPv6 interdomain... both in the academic world and during his time at RIPE NCC. He's now a network engineer and research... I'll hand over to Lorenzo.

Lorenzo Colitti: I wanted to use my laptop because I want you to a give a demo as well. Sorry for that. So I'll be talking briefly about not just about what we have done, I think you know the demo will kind of speak to that. But a sort of more general thought as well on how we as an industry need to approach this transition.

Start with the problem, so at the top are two of Geoff's graphs, you know, and the bottom is one of ours. The two graphs at the top shows that v4 is basically all out.

The graph at the bottom shows that v6 is not here at all yet. So our numbers say that v6 is -- that 0.2 per cent of Google users have v6 today. The graph at the top right also shows that APNIC is going to be out of IPv4 space around about July 2011 if I'm reading the graph right. So we have six months to figure out what we're going to do.

So obviously after APNIC hits the wall six months from now I'm sure you'll have lots of pools of v4 address space lying around somewhere that you've ordered over the years hopefully. New entrants won't be so lucky, but then again they never are apparently.

So what's next, so assume you run out of your pools as well. So what happens you buy space or you steal it from other parts of your network or you do, I've heard some ISPs say we have this legacy product that we like to keep users off of, we're going to move that to large scale NAT take the IP addresses away and put them on a premium offering so that will incentivise people to move to the new one. Then there's obviously large-scale NAT and then there's IPv6. So buying is going to be expensive and my feeling is that nobody is going to be able to afford it really. Because if the black market rate is $4, it's probably going to be a little bit higher than that, there's all these legal issues about who really owns the addresses. So it's really, I don't see it as an option for residential users that are paying $15 or $10 a month for internet access. I don't think you'll be able to afford to buy IP addresses for these people. That's where the highest growth is.

So what about NAT. So this is how it works. As Donn was talking about this, we already, quite a long time ago, reached a point where we couldn't assign dedicated IP addresses to each of the devices on the internet. If you have two or three devices at home you have your laptop your console your phone, you really don't get IP addresses, public addresses for themselves. They share an IP address, but it's yours, it's assigned to you by the ISP, you don't have to share it with anybody, it identifies you.

So the user on the left get 1.1.1.1 and the user on the right gets 1.2.3.4, who knows today these are real users because 1/8 has been allocated.

With large-scale NAT or carrier grid net, you have this big NAT box in the middle of your network or multiple small NAT boxes in the middle of the network that effectively do the same thing. The important thing is every connection to the website or any connection to another user outside your network goes through this big box or through these lots of small boxes.

So that's going to be expensive, so first of all where is eight NAT going to be. So if you're running it on an existing device you're going to have to burn line card slots or install blades if your root already supports it. You're going to have to log TCP UDP sessions for legal intercept reasons I believe Softbank P B had some numbers on that.

So there was five terabytes a month, and you can reduce that by statically allocating ports or allocating ports in blocks but that's a lot more complicated. Then you'll have to deal with application breakage, you'll have to support your users and you'll have to simply, some applications just won't work and you'll have to say to your user sorry this is not supported it's not going to work. So that's a support cost. And possibly churn cost if your competitor has v4 addresses and you don't then that might be a reason for a user to switch.

The key point here is that large-scale NAT, carrier grid NAT will not get better, it will only get worse as we put it more under pressure, if we put more users on the NAT boxes. There will be no more IP addresses. So this is a problem, it's a solution that has no way out.

What's the impact on content, for people like us, like Donn, what's the impact on that? First of all, and Akamai, first of all, let's accurate geolocation, in many cases, there are legal restrictions on the content we're allowed to serve. In some cases we obviously can't offer the most tailored content to you. If you search for flowers, if you search for sushi, we won't be able to find the sushi restaurant closest to you, we'll something in your city or your region.

Abuse identification, if some IP address attacks us then the standard practise today is to block that IP address, and if we do that we'll take out 100 users, 1,000 users, and then of course our application also start to work worse. The more you intercept IP connections... the applications will just become more fragile over time.

It's going to become an arm's race between the NAT trying to close the connection and the applications trying to open more connections in order for them to keep working.

It's just going to put the system under pressure.

New applications, obviously really we can't deploy any new applications in a fully double netted world, it's just not possible. Or rather the barrier to entry gets so high that it's really, most of the application development will be devoted to traversing the NAT. So we have all these issues.

So where do we go from here? V4 is not going to go away, the long tail of consent is going to stay v4 for a decade at least. There are certain ISPs who have that but everyone else they're going to have to install some NAT.

The question is how much traffic is your NAT going to carry? So if you look at the people who are listed on -- as a participants of all IPv6 day right, there's Google, Facebook, Akamai, there's Yahoo, Bing. These players account for, if you look at the recent internet traffic reports, they account for a double digit percentage of internet traffic. So if these players move to v6, then they can -- it has the potential to lighten the load on your NAT substantially.

So one possible way out of this mess is if sort of big large-scale sort of heavy content moves to v6 and long tail content stays on v4, your NAT suddenly has to become half as big or only 30 per cent as big as if it had to carry all your traffic. That's a cost reduction. I don't know the math, but it sounds like a cost reduction to me.

So the content providers don't have to suffer all the wreckage that's due to CGN. The ISPs don't have to pay so much for CGN boxes everybody wins. And as over time, IPv6 matures it rolls out and the long tails start getting v6.

Obviously the barrier to this is -- so far it's sounding like content is going ahead and enabling v6 and to some extent that's true. But obviously we have our hands tied. As long as IPv6 is as unreliable as it is, we can't turn it on for our main websites. That's what World IPv6 Day is all about. Donn has talked about it.

Leslie will be talking about it later. I won't talk about it here.

But the key point here is that if 0.03 per cent of our users have broken v6 connectivity then and if we have 1 billion users, the math is wrong, but one of them was an old figure, but that's still several hundred thousands users. If you're Google, it's leaving several hundred thousands users with multi-minute page load times is simply not an option. Just forget about it.

And in particular, if Google are the only website doing this, then it will be Google is broken. Actually know it's the user's home router that's broken, but it's not easy to understand.

So the only way that we can make progress in such a situation is to do DNS white listing and to talk to IS vendors and also to as part of all their IPv6 data try to raise awareness of the problem and hopefully get the IPv6 vendors to fix the problem, because they're the only ones that can help us at this point.

So yeah, this is how it works. You probably know how it works. I just want to give a brief demo. So this presentation was brought to you over v6. This is a packet sniffer, all these v6 packets. You'll see that the maps, Google Maps is coming over v6. You'll see that Google has a v6 address as well as a v4 addresses. This is really how it's supposed to work.

We have the technical capability to do this today, we just can't turn it on because of all the broken users who would not be able to reach us any more. It's not a scaling issue, it's not a capability issue, it's just we'll just break stuff and we can't do that.

But you know hopefully this is the way it will go and we'll just be able to dual stack things when the time is right.

So even my own mail is hosted by Google and, therefore, it is reachable over v6. So we have our hosted services as well.

So to get back to what we were saying, a lot of people in our white list, it's a very painful process to get white listed. It's painful for the ISPs, for us, but frankly at the moment we don't have a better alternative. Part of the problem is that even if we implemented some fancy automatic white listing method using measurement data, we would not be able to find the labs that ISPs need to be white listed to test v6. So even if we did that. It will work for large scale networks, but it won't work for -- a lot of the questions we get, we have this lab, we're working on a pilot -- can you white list us. We don't see another way to do that manually. We don't have enough data for those cases.

IPv6 day, yes, we'll be participating, we're among the founding members. Most Google properties will become dual stacked for 24 hours on 8 June. .... at least users that have this problem, they won't be able to reach Google, but they won't be able to reach Facebook, Yahoo, Bing and a lot of other sites. Hopefully it will convince them their internet connection has a problem and they'll call ISP. To be fair, we don't expect a lot of users to actually go in and fix their issues. We do hope that it will serve as a routing call and get the application of vendors to do something.

Before I speak about how we approach transition, it's worth figuring out how we got into this mess. One of the interesting things that I got out of a conference in Paris a couple of weeks ago, was that this Portuguese ISP was saying we've been working on IPv6 for three years, we've not ready yet, we're getting there, and I said what about this large-scale NAT presentation that this vendor gave with all these details about the scaling limitations. He said it's inevitable we're going to have to install it. I said why. He said well, it's too late.

As an industry we don't have time to deploy IPv6 any more, we have to do this NAT thing.

So how do we get here? So it's a combination of lack of business case, as Geoff points out operators, everyone is more -- companies are driven towards new revenue compared to away from loss because, hey, the new revenue will make up for all that loss anyway. We don't need to worry about it any more. We don't want to touch it. There's no real sayings of how long it takes. It took 18 months to get to a state where we were comfortable releasing most of our services over v6. Even to the white list.

IPv4 is running out in 6, 12 months away, so if you're starting now it's all over.

No vendor support, if it's supported doesn't mean you can actually use it. And obviously there's no demand. These are some of the things that I hear: We'll deploy IPv6 when users ask for it. No, they will not ask for it.

We'll be forced to go to IPv6 when IPv6 only uses a...

will be forced to use IPv6.... we will have to deploy IPv6 once v4 runs out. This caught out a senior Google manager, a very smart man, he didn't know there was a third option. No, we don't have to deploy IPv6 once v4 runs out, it will just start to suck. All our gear is ready, we just need to turn it on. Good luck. There are bugs and some of them are show stoppers.

So taking all of the elements of the value chain must have v6. The weakest link is the users and until the users are done, there's nothing that can be done. So until the users have v6, the complete value chain isn't there and nothing will happen. So doing it on your backbone isn't enough, it has to make it all the way to the content and all the way to the users.

I don't have time for this. There's some lessons learned here. The key point here is that you will not get any more revenue from this. So it has to be either zero cost or there has to be a solid business case that you'll have to take home.

Fortunately, if you look at the surveys of people who have done something for v6, it's not expensive, the cost is not the issue, followed it into your normal upgrade cycles. Lots of bugs, we took the time to do it slowly, it took us 18 months, we had a couple of people working on it. Now if you look at Yahoo, they say they have 100 to 150 people working on it. Which one would you prefer?

Of course it's getting late, so you might not be able to do it with two people any more.

We started, this is one interesting lesson learned. We found that going from the outside in was crucial because we needed to get to the users, otherwise there was basically no justification for doing anything. If you can't provide your core service, none of what you build is useful because it will just be bit rot, it will be trashed, it will be seen as unimportant. Until you're actually providing your service over it, it's not useful.

One thing that we did which was interesting is that when we have code that supports only v4 you can take the v6 address and stuff it in the multi-cast range or whatever reserve range you have and your application will keep working.

So that's it really. Be warned that once you turn the floodgates on the traffic will appear instantly because that's the way DNS works. So be prepared and don't do it wrong, it doesn't have to scale immediately but it has to be production quality.

Dean Pemberton: Thank you very much. Great stuff.

APPLAUSE

Dean Pemberton: Thanks for that. Does anyone have any questions?

New Speaker: My name is Mayan from BPCL Pakistan. My question is to Google. Do you have statistics about performance similar to Akamai on customers using dual stack or tunnel? Second question what is the impact on the Google cache ISP implementations on the IPv6 and the....

Lorenzo Colitti: We have data, we connected a while ago, it shows basically 50 millisecond penalty and the data that we had. Don't use them, really don't use them.

Fortunately our data shows that only about 10 percent of users are actually using tunnels. But yeah, don't use tunnels. Don't use our managed tunnels, fortunately we've been partially successful in convincing the operating system manufacturers not to use tunnels even if they're available. As regards the impact on Google cache there's the presentation today you might have the answer that you want.

Dean Pemberton: One question from over here. With World v6 Day, you mentioned that quite a lot of the problems will be from users of and broken operating systems. Are you aware of any effort to engage the operating system vendors before that date and try and get it fixed or do you think it will take that day and take some brokenness to get it to happen?

Lorenzo Colitti: Do you want to take that, Donn?

Donn Lee: When we started World IPv6 Day, we had the operating system folks in the same room so they have rules about how they -- they were involved, they have rules about how they do the software, they have to make decisions about how they apply patches, when they apply patches. It's not really where I can tell them how to do their job, that's where they have to make a decision about. We do believe that having a date set in stone was going to help them, the folks that really need to figure out or drive IP V of the companies, work with other departments, then they can say there's a World IPv6 Day, maybe we should start thinking about doing other type of initiatives.

So we think that that will continue to be an important element and that v6 will continue to grow and so -- then those users of course will eventually have to upgrade.

That's inevitable. Can we do something before then? I don't know. That's really up to the OS vendors to make their own decisions.

Dean Pemberton: Thank you.

Lorenzo Colitti: One thing we've also told them, we've observed other days in the past have resulted in stuff being left on. They also have to do a sort of cost benefit trade-off. If we have to apply this patch and do all this work just for 24 hours of broken stuff, maybe it's not worth it right. But one of the things they're trying to explain is if things go well, then somebody might decide to leave some service on, in which case, the brokenness that day would keep on going. But we have not -- we don't know what their plans are

Greg Shepherd: I work for a large equipment vendor.

Just a question about the OS upgrade. They have cycles, but at least it's getting more and more automated. Seems like a bigger challenge is the home gateway issues you mentioned. For example, I use my parents is litmus, they don't even know they have them.

Lorenzo Colitti: There's no hope for the home gateway.

That's a seven-year life cycle. But the OS is in control, they can say, hey, this gateway is bogus. I'll just ignore?

Greg Shepherd: So the solution is ignore it?

Lorenzo Colitti: There's no hope to get the home gateway fixed in time. Yes, we're teaching them to ignore it, in particular OSX the most recent version of OSX already depresses 6to4 which is most of the problem there's a couple of bugs left. So things are getting better.

But, yeah, one of the things that we're trying to do also, I mentioned in my presentation yesterday, we're trying to work with equipment manufacturers, home gateway manufacturers and I think so forum and U and H and the standards maker so that we can actually come up with a v6 CP standard that will work, we're trying to do that for the days, that's a very ambitious goal, but we're definitely working on a test plan

New Speaker: I work for a provider in Cambodia. You say large-scale NAT is something that's going to break your network in the end, many services don't work. But the World IPv6 Day is basically the same day when we in Asia run out of IPv4 addresses. If I deploy IPv6 I can only use it for one day and you turn it off again. I need to deploy or not, you're forcing the operators to do so, why not just leave it on? Yes, it's broken, but that's the only way it's going to be fixed.

Lorenzo Colitti: What's forcing operators to deploy large-scale NAT is that even if all of the participants on World IPv6 Day they leave IPv6 on there will be 10 websites that are accessible over v6 and the rest is going to be v4 only. So we can't fix the problem by ourselves right. So sure, it would be nice if we could leave it on but there's also, we also don't like to leave half a million users out in the cold. So it's the trade-offs we have to make.

Dean Pemberton: Thank you very much for that.

APPLAUSE

Dean Pemberton: Moving right along, I'd like to now introduce Kasu Venkat Reddy, who is a senior solutions architect in CISCO's worldwide service provider advanced services team. He has extensive experience in the architecture of NGN networks and specialises in v4 to v6 transition strategy for mobile and wireline service providers. He's a regular speaker at industry conferences in the APAC region, including telecommunications industry standard bodies like the MES.

Kasu Venkat Reddy: Hi everyone. Today I'm going to talk about IPv6 transition for mobile operators. As part of that, I'll be covering on key motivations for mobile operators to look into IPv6 and I'll be toughing on IPv6 and mobile architectures as per the standards.

Finally, I have a few slides which talk about some of the key transition solutions.

You'll see the key motivations like soft mobile internet, increase in smartphones, we are running out of E P addresses in IANA. All these things are well discussed in length, I don't want to spend too much time here. One thing I'd like to highlight here is the new trenw what we have seen is currently, even from the infrastructure point of view, especially with the new architectures like LDE where we are talking about eNode base. And even if you see femtel kind of deployments where we are talking about home node visa for every household.

We end up assigning an IP address or a block of IP addresses for all these eNode base and the homenode base, so 10 dot network is not sufficient for that. This is one of the key motivations from the transport point of view. Every mobile provider has to look into IPv6. From the standards point of view IPv6 is well-defined.

If you see the latest standards IPv6 is kind of mandating. From network architecture point of view this point also was discussed by other speakers. That you know by having an IPv6 we can get rid of NAT. We have a lot of scalable issues with NAT and even some latest applications like your point-to-point or mobile to mobile applications simply doesn't work.

So these are the key motivations for any mobile provider to look for IPv6. So if you see the 2G and 3G architectures here, if you talk about the PD P contexts is the logical link between your mobile to go, GSN. So here if you see, if you have a net book with your gateways prior to release 9, so you end up establishing two different sessions. Two different PD P contexts.

If your gateway is on-line compliant, the single system is good enough to take care of your IPv4 and IPv6 traffic. So this is a very important issue, like from scaleability point of view, like for example if you have 10K users, if your gateway is release 9 complaint, you just have to have a 10K systems established for both your IPv4 and IPv6. But if your gateway is prior to release 9, then you end up kind of establishing two sessions per user, one for IPv4 and one for IPv6. What that means is from scaleability point of view the gateways are unstable, with this approach, and the second important challenge is if you see every vendor right, they sell the boxes, I mean and the cost is tied up to your licence.

For example if you are having an X licence you pay per wire mode, if it doubles upright you end up paying more amount there.

So these are the key challenges we have to take into consideration especially for 3G providers if they're seriously considering to move to IPv6.

IPv6 on the ran and SGSN point of view. Ran is like your transport from your eNode base to the RN C. There transport is very mature. It's all done tunnel traffic.

So the IPv6 requirement is not a very, very key thing.

But from gateway point of view it has to support IPv6.

So for example I mean if GGSN replaced back with the...

IPv6 centres. That information has to be relayed downstream to the mobile nodes.

And of course the AP N selection, AP N is nothing but a DNS of your GGSN. These are the things we have to take care.

For 3G network providers, if they're seriously considering to migrate from IPv4 to IPv6, these are a couple of touch points they have to kind of be aware of.

Like from eNodeB and RNC point of view it's not really mandate to have an IPv6 support, but if you see from starting from your GGSN and upstream, your HLR, your firewalls, your DNS all this equipment has to support IPv6.

If you see the 4G architecture it's all end-to-end IP.

So here from IPv6 point of view two things I want to talk about. One is on the transport side. Like I said, transport side is not a burning issue at this point of time. But at the same time if you are getting into like a national wide problem where we are talking about... are something like a femtel kind of a deployment where every household we are providing home note piece we have to definitely look into IPv6 from transport point of view also.

But there are some challenges with the roaming, like if you see G R X or IP X in networks, currently there only are four compliant. So what kind of progress as far as IPv6 is concerned?

From applications point of view it's a no-brainer, every mobile node has to be enabled with at least to start with the dual stack. With respect to that you have to have your complete system supporting IPv6.

On the E PS bearer type, I mean that is from -- it's by default dual stack. You are required to set up only single session as far as the L D architecture is concerned.

So these are some of the key features we have to look into, if every provider wants to start with IPv6 for LTD architecture. From transport point of view as from the applications point of view.

Like I said, applications definitely is a very burning problem, so every provider has to look into. But as far as the transport is concerned unless until we kind of are running into nationwide deployments with a number of eNode base and we kind of are offering femtel kind of employments then definitely IPv6 is the way to go from the transport point of view also. If you see the transition solutions, this topology is kind of way back like 5 to 6 years back. If you see the net books we see most of the mobile networks or any kind of networks with IPv4 addresses, I'm talking about public IPv4 records as your -- for your transport network as well as for your N 6. This is kind of an ideal case.

The second step is before we're looking into IPv6, the best way to start with this preserving your existing public IPv4 registers. What we can do is we can go for a large-scale NAT and we can enable private IPv4 addresses on your transport network as well as for your user equipment.

That way you can separate for some more time. Like the other speakers, NAT is not a very great option especially when you are talking about the latest services with your mobile node to mobile node or peak to peak kind of services.

So when you say large-scale NAT we have two different options here. We can do that at every gateway. If you see from L T architecture point of view we can -- the gateways are to take care of the NAT themselves. That's kind of a distributed model. You have an adoption, you can have a centralised high end router, which can perform all flavours of NAT, whether it can be NAT 44, it can be NAT 64, all the flavours.

What approaches have advantages and disadvantages. If you see doing that in the gateway it's like a distributed model. You get good ... and it's subscriber aware, that is the key thing.

On the centralised side, if you don't have enough public pools where you can assign a region then the centralised option is better. You can segregate them further with the VPN approaches.

So this scenario is like even when we say using private IPv4 addresses within the network, especially for larger deployments, we are seeing a couple of cases where they are running out of addresses from the private IPv4 addresses point of view. So what that means is you have to use here an overlapping approach. You end up using the same private IPv4 addresses in different parts of the network.

So we have a new approach here called gateway initiated dual stack approach. So this is currently in the draft stage. It soon will become standard. What it does is, I mean if you see the mobile architecture, the beauty of any mobile architecture is it's all tunnel based. The tunnel starts from, if you take an LT architecture the tunnel starts from your eNode B, the GP tunnel ends in your S gateway. From every S gateway you have a GTP tunnel terminating on the BGP.

What is DS wide gateway initiated is it will extend your tunnel from your P gateway to the carrier grade net router. So at any point of time you are not routing based on your user equipment IP address. So you just route based on your GRET or map to the port. That way you can use the same IP address across all the mobile nodes with this concept.

So these are a couple of deployment solutions with respect to your IPv4. But definitely no doubt we have to, every provider has to look into IPv6. When we say IPv6, you know, the first approach we can think about is, the easy approach is on the transport side. Like I said, transport side things are very mature, every vendor, including, I mean all the leading vendors support your routing protocols with the v6, that way you can have end-to-end v6 starting from your axis to aggregation and then to the code.

On the dual stack handset, I mean this is the good start for any provider. Once they start looking into IPv6. So here, I mean you can have a dual stack on your handset, and you can limit IPv6 only in the code. So when I say core, the core starting from your P K 3 to your internet gateway. So the core can be enabled with IPv6, and all your IPv6 traffic can be natively routed. There will be gateways anyway packets or tunnel, so it really doesn't matter. So starting from your P gateway it can be natively routed to your internet, or targeted for IPv6.

But saying that, like we all know, internet is 99 per cent is currently populated with IPv4. So that's where we can leverage gateway initiated actual stack like approach, or a straightforward IPv4 routing and get into your... and you can very much perform NAT44.

The same thing, it's exactly like you know, if provider decided to go with the IPv6 only on the hand-sets, so we have two approaches here. One thing is to build a native v6 across the network starting from your axis to aggregation code and the second approach is if you want to get out to your public internet, IPv4 is the only way, right, I mean at this point of time. At least I can say for 90 percent of your counting.

So for that you can enable NAT64 on the routers. NAT64 is one of the flavour of your NATTing. So like your NAT44. So which converts your v6 to v4, the public v4 address and get out to the public IPv4 internet.

Of course this is the ideal thing, everybody wants to look into, like to have IPv6 everywhere, starting from your user node, to the complete network, your access network, your core network.

So the key message here is mobile network architectures if, you see it's all tunnel based. That way it's well suited for your faced with approach. You have tunnels starting from your e-node base to your S gateway to B gateway. So that portion you need not really worry too much in the starting. You can start enabling IPv6 at your user limits, then gradually you can get into your services then followed by the transport.

So that's all I have. Any questions?

Lorenzo Colitti: I have a question, actually. So as the guy who wrote a lot of the code that makes Android v6 capable and as looking into the future of these deployment scenarios.

The question I have is what should a mobile S do? On one hand I hear all the carriers say we can't do dual PDP context because it's too expensive, it doesn't scale, we have to buy more licenses. On the other hand we have today v4 only applications in Android, take Skype for example, there's Google ones as well, we could fix those, but there's a lot of third party applications that require v4. We don't want to put an operator in the position of having to choose between a device that supports v6 and a device that you can use to run Skype, because the product guys will say what do I get from this v6 thing it doesn't make sense?

Then the final piece of the puzzle that every carrier I talk to says we want to do this, and this is the best way to do it. Then I talk to another carrier and say we really want to do this, there's your NAT46 and gateway initiative stack light. Some people say let's do v6 only and we'll break the applications. Do you have a feeling of the consensus, and there's 4rd as well. Do you have a feeling on the consensus among operators of which direction we should go? I know we don't have time to implement all of them. So we may end up implementing none of them just because whatever we do is going to be useful to one or two carriers only.

Kasu Venkat Reddy: From the Cisco point of view, we recommend a 3G approach ... then the second phase is you want to get ready for your IPv6. When I say ready for your IPv6 that means to get into your dual stack approach.

Lorenzo Colitti: That's a non-starter right, until release networks are commonplace that's a non-starter.

That's putting the cart before the horse. All the operators I've talked to say we have to do v6 only first.

So how do we do that?

Kasu Venkat Reddy: If you look at, if operators or especially I can share an example recently we were working with one of the greenfield providers in India, so he's planning to roll-out L D, right. So from day one, he want to go with IPv6.

Lorenzo Colitti: Greenfield is easy, though.

Kasu Venkat Reddy: I want to highlight here a couple of challenges, especially from the, if you see from complete ecosystem point of view still we are not there. We have a lot of challenges with IPv6. So that's where we are recommending to go with the dual stack approach, that is with both IPv4 and IPv6. Wherever you can go with IPv6, wherever you have to go with IPv4. That's the philosophy we are selling to the customer, at this point of time.

Lorenzo Colitti: For operating systems that are always connected always on like Android, do you have to keep v4 around all the time?

Kasu Venkat Reddy: Correct, it can hold, it's like a dual stack, the elements can be in the dual stack.

Lorenzo Colitti: That means you keep two PDP contacts.

OK.

New Speaker: Telstra. If I may ask a question of the panel overall, but sort of based from where some of the discussions we've just had, as you say the long-term dream is to get to IPv6 only and I think we're all agreed that's at least 10 to 20 years off before we really get into that direction. Equally we all seem to be fairly sure that we're starting off with a dual stack approach as the major way of getting IPv6 introduced.

One of the interesting questions is that there ends up being that vague bit in between those two phases, where we start talking about, OK, maybe the traffic gets small enough we can start manage it by translation and other mechanisms like NAT64, et cetera. But I'm curious as to the opinion of the panel as to when we can get -- start moving away from, realistically start moving away from that initial dual stack phase into the next phase of IPv6 deployment where we start reducing reliance on IPv4 because I suspect while we're still doing dual stack there's still -- that's where all the pressure on IPv4 will remain.

Kasu Venkat Reddy: One thing I feel, it depends on what services you are talking about. If your services are heavily depend on accessing the internet then obviously dual stack will stay. Obviously your internet definitely will be there with IPv4 for a good number of years.

But if you are talking about hosted services, there you have the control of the eco system, so there if you can make the complete ecosystem with IPv6 that's a good start.

Lorenzo Colitti: My initial reaction to that question would be let's get into the dual-stack phase first and then figure out what works and what doesn't. Because at the moment we're not in the dual-stack phase at all, we're in the 0.2 per cent dual-stack phase.

New Speaker: I suspect we're all in the same -- we've accepted that as the premise and indeed I think everybody's planning has been heading around the dual-stack phase, it's starting to wrap our heads around the next things from a strategic perspective as distinct from a deployment one.

Lorenzo Colitti: Let me rephrase that. When we have the technical capability, for example Google are serving potentially all the traffic over v6 -- what was the question again; right? So there's nothing really that we can do; it's all up to you guys. I mean, you tell us, right?

Mark Newton: The demand for v4 addressing is going to be driven largely by the applications that haven't migrated to v6 yet. And the usability of v4 will, over time, get worse and worse as conservation measures steadily are more onerous, are needed to deal with the fact that there aren't any more of them.

So I can see as you wind time forward, there's going to be an individual pain point for each application provider where they'll be saying we actually need to do an IPv6 transition now, because IPv4 isn't working out so well for us. Each application provider's going to have a different one of those pain points.

New Speaker: I think I agree with that degradation scenario, but I'm curious when you bet on that point, the relative point coming.

Mark Newton: I think there'll be lots of them, is what I'm saying.

Satoru Matsushima: From an operative point of view, the difficulty to deploying IPv6 in mobile is not technical issue, a financial issue, so we have to solve that problem. Then IPv6 only network is really easy by now, so trying to IPv6 connectivity to the tunnel, then making IPv4 connectivity over the IPv6 interact is the way to provide IPv4 and IPv6 dual stack services.

Geoff Huston: I have a question about this dual stack transition. I keep on hearing folk talking about decades or longer. I observe that last year, we consumed 250 million IPv4 addresses and the second derivative of growth is 10 percent, so next year if we still have addresses, we consume 275. That's a reflection of the underlying growth rate of this industry. So I have a question to Satoru about dual stack and how long he thinks it's going to last. Let me just add a data point here. If you think that dual stack in this world will last for five years, just five years, somehow we need to number in v4 another 1.5 billion things that we haven't numbered today.

Lorenzo Colitti: Use dual stack light. You can give every device the same IP address. It's the ultimate in conservation.

Satoru Matsushima: I think the difficulty is solving, preserving IPv4 others to the new greenfield or new network, so IPv4 for others is needed, so yeah, sharing IPv4 this is pretty difficult. I hope just five years to keep both of the dual stack. Geoff Huston: My point was: Do you think you can get it all done in five years? Because I don't think the technology gives us more time than five years, no matter how you push address compression, you know, at some point, the task gets really hard. Therefore, the time we've got left to do anything dual stack is starting to shrink pretty dramatically. So this is why I was sort of looking at particularly your plan as being one of the pointy edges of the problem. And it happens as well in mobiles because mobiles is driving this. When I hear these comforting words about dual stack and, you know, we can continue to sort of offer the user both protocols, what disturbs me about this is that the numbers don't seem to prop you up, that realistically this industry is growing at such a pace -- a quarter of a billion units a year is a lot, that all of our assumptions about dual stack have a frighteningly small amount of life in them.

New Speaker: Hence my question in the first place.

Lorenzo Colitti: What's wrong with dual stack light then, right?

New Speaker: As you observe, there's a lot of scenarios for these sort of transition mechanisms which are under consideration. It's not going to be possible to implement all of them, and especially when we're talking about there are some scenarios like mobiles, it's quite an interesting challenge working out the steps beyond what is in the initial phase.

Dean Pemberton: Awesome. Thank you. We might leave it there. We're running a little bit short on time, but thank you very much.

APPLAUSE

Dean Pemberton: OK. Next to the podium I'd like to welcome Xing Li. He is a professor... he has over 200 papers in statistical single processing, multi-media communication... former member of the APNIC Executive Council.

Xing Li: Actually, I realise I'm eating into the lunch, so I try to make it shorter. However, I believe my presentation just addresses the question you discussed, so I like to make it here. OK. Google take 18 months to deploy IPv6 and it may take 12 years, still we cannot get there. So I can share you our experience. First in 1994 we start CERNET as IPv4, the first PCP IP networking in China. In 1998, we join six more because in that time in China there are 320 million students, we want them together. So in 1998, we realise we run out of IPv4 address. In 2001 actually we start to do stack deployment. That's the first G S Rs router in China.

Later in 2004 we, realise dual stack doesn't work, so we deploy IPv6 in the networks. In 2005 we realise still customer need IPv4, so we run IPv4 over IPv6 the opposite way, that's actually turned into IT F working group.

Later in 2007, we believe it doesn't work, so translation is the must. We have to do, we have to bridge IPv4 and IPv6.

So that's the stage, 12 years we are still discussing if we need dual stack or not. That's a shame.

OK so IPv4, that's the first backbone, and we have 2,000 universities connected and end-users more than 20 million. Later that's the 6 bone, that's the first IPv6 site in China. By that time actually if you take a look of that we have /24 6bone address, we divided in two parts. One is official like operator running, another is we just set up internal blockers. So any student and professors if they want IPv6 we gave them a feed. But OK, but the traffic is mainly -- no other traffic, only IPv6.

Later the dual stack, we have seen that in Beijing area.

Still there are very very few IPv6 traffic. Later we realised we need to go to IPv6, that's some kind of old Chinese saying. If you put your foot into two ships or boats you cannot win. So just go to IPv6 only.

So that's the thing we are doing. And the country actually we have about 200 universities connected to CERNET2, IPv6 only. There are about 2 million IPv6 customers. The promotion technology when we design CERNET2. OK, it is a pure IPv6 network, and the equipment from multiple vendors from June per Cisco highway, even Hitachi. That's a multiple autonomy system network because multi-homing is something in IPv6. So each hub has there independent transition members.

We try IPv4 over IPv6 and also translation later. I will discuss, so that's the thing we run IPv4 over IPv6. So the backbone we can build a single stack IPv6 backbone.

The border router. So P router is IPv6 only, but the P router is dual stack.

To encourage transition, for CERNET actually our business model is CERNET is congested. Even we are academic network, however we're self funded, so we collect money from end-users, professors and even students.

For CERNET2 actually it's also a 2.5G to 10G backbone and free of charge because that's the funding from the government money.

So our promotion strategies, if you want to use a high quality free network port your application to IPv6.

However, OK, some sort of success, however actually fortunately we realise the people do not really want free lunch. They want to pay for using IPv4, even IPv6 is free. What's the reason?

OK, IPv6 applications, we have lots of videos in CERNET2, and also you may know we host the first official Olympic IPv6 website back to 2008, also some other things. They want to request IPv4 traffic versus IPv6 traffic for CERNET as IPv6, v4 network you can see it's about one 70G in peak hours, and for IPv6 only it's about 30G so more than 20 per cent compare with IPv4 traffic. We believe we reached highest ratio IPv6 over IPv4.

The curves you can see that's the newest curve, and you may wonder in the valley. That's the Chinese New Year two weeks ago, so every student went home.

So the conclusion, upgrading network to dual stack does not mean transition. The IPv6 traffic is still very small. So that's the NSFCNet. Promoting IPv6 can help but does not help to fully solve the transition problem.

That's IPv6 only CERNET2. And people always ask what's the killer application of IPv6? We always keep our finger crossed and try to find the killer application of IPv6.

We think if we can find a killer application of IPv6 then we can make the transition.

So at the beginning we thought video is the killer application, however like YouTube can surf with NAT quite good. The P2P but still like BT passing through the net.

And internet of things, probably but that's maybe two or three more years.

And finally actually we realise the the killer application of IPv6 is the intercommunication with IPv4 internet. If we can communicate, if we build IPv6 in the network and that can communicate with IPv4, then actually we naturally transit to IPv6. So that's the top Tower of Babel. That's the thing we try to do. But it's not easy, right, because IPv4 and IPv6 are not compatible.

So in summary we have two networks, IPv4 CERNET and IPv6 only CERNET2, and later OK, IPv6 network we have servers, we have clients and that can talk to -- actually there is no global IPv6 network. We build a translator which is a state list translator and a connected CERNET and CERNET2 and the IPv6 only kinds in the servers can access IPv4 global internet. We call this IVI. The reason is like if you see the raw implementation of numbers, IV means 4, V I means 6. My student invented this name.

So if we think transition technologies dual stack, we have IPv4 address depletion problem, so we need NAT.

Also if you think dual stack, actually every layer 3 and above equipment you have to upgrade, that's in square problem. For tunnels actually you still need dual stack if you want communicate with IPv4 and IPv6 networks. So tunnel itself is not independent.

And for tunnel the next thing is actually you only need to upgrade two tunnel points. However if we can have a translator then we just point a translator between two address families and you are done.

And you may think this translation technology is not mature, but it's not true. In the past two years we are working very hard in IETF behave working group. You can see those RFCs. RFC 6052, that's the address translation, RFC already and 6144 to 47 as in the other 48, you will see these numbers later. That covers state list translation, that's the one I mentioned in the next 64, that's the state for translation.

So actually if you take a look of IETF people talk about dual stack light, it's still in IETF drafts, it's not RFC, still need revision. And the net 444 it's even not the working group draft. So actually, translation technologies is the most immature translation technology now.

OK, there are scenarios in the framework document.

Actually the most attractive one is greenfield deployment, I talk I mention IPv6 only is good. How to start for your new users, build IPv6 only network.

That's the thing you can control and the builder put a translator there. You can talk to both IPv6 and IPv4. That's a single stack you have 40 control, you can control the performance. So there will be no doubling of the RT T.

The idea is quite simple because actually IPv4 and IPv6 are not incompatible ports. So in IPv6 you need some kind of address to hold as repenter of the global IPv4 internet and IPv4 you need some kind of holder to prevent the IPv6 network.

So the idea is we have IPv6 address is 2 to the power of 128, that's too big. However, how about let's use a subset of that huge address, use that address first, then later if eventually internet evolve into IPv6 use rest of the addresses, actually we did that for IPv4. Originally like Vint Cerf mentioned it's only Class A address later it extend to Class B, then Class C then introduction of sideers. IPv6 currently we use IPv6 address too randomly, we need some kind of restriction, use a subset of that and that subset has maybe in relation to IPv4 internet, then actually stateless translation can help.

So that's the address translation and the routing, because it's the stateless translator is stateless. So just like the router you do not need to do load balancing, except you can use BGP to do these kind of things. So asymmetric routing no problem. Actually you can deploy it independently. For you you can deploy stateless translation and you build IPv6 in the network and through translator talk to global internet. The content provider like Facebook, Google, and Akamai, they can build their own translator, move to IPv6, still even we don't know each other move our content or users to IPv6, still through the IPv4 internet you can talk and it's transparent.

However because both sides move to IPv6 there is a shortcut if there is a direct link. So that's the promotion strategy and the DNS and ALG. You can download the open source code from this website, that's on-line for three years. Currently we are working on address sharing. So actually one single IPv4 address you can use -- can be used for many many IPv6 hosts. For example if multi-packs and ratio is 256, if your ISP, your lack of public IPv4 address you can use like a 256, then if you have Class C address then, actually that's the equivalent to /16, so you can have like a Class B. So you can re-use that and the limitation is your user can only have 256 current sayings like NAT44.

Also because we are doing stateless translation, so you can translate back. State 4 you cannot do double translation. However, stateless because it's everything based on them, you can translate back. Actually, do you not need DNS 64 you do not need ALGs. So all Skype or those kind of things is transparent. You can either use CPE or you can build the certain translation into the operating system then 3G mobile, you can still use the IPv4 natively in your mobile device.

Also actually we have some kind of thing called the NAT66, so you can mapping, because you need a subset, however that does not work for slack, like auto address configuration. You can translate a specific subsetback to IV 6 address, it actually gives you four freedoms.

Also we need the IVI test in IETF79 in Beijing, that's the test. And currently we deploy IVI in 100 campus networks in mainland China. You can see that's the traffic increase. Currently we are using Linux box and the peak is 400 Mac BP S that's the peak hours. Also Cisco, Juniper, Huiawei are big vendors, because it's RFC already, so all deploy stateless translation.

So that's something, the idea, that's my final slide. The idea is OK, we have IPv4 and IPv6, it's not compatible. And if you want to communicate with IPv4 you need holders of IPv4 internet. You do not use this IPv4 address for the IPv4 device through a translator you use it in IPv6. So you already transit to IPv6, those only IPv6 device can talk to both IPv4 and IPv6, and if ISP move those IPv4 address into IPv6 and use there, gradually everybody move. If all the IPv4 address use the IPv6, then we finish transitions.

So that's my presentation, thank you very much.

APPLAUSE

Dean Pemberton: Do we have any questions?

Satoru Matsushima: I run about the IVI many times ...

sharing for many customers. But the difficulty to make standards in IETF is so difficult to do that. So how do you make progress in IETF or any other standardisation body?

Xing Li: OK. Because that's to share the port, that's something, OK. That's some new concept. However, I still believe IETF is the place to go because IETF believe running code, like no kings no voting, the running code. IVI address sharing is running, and we are using that also China Telecom is trialling the Z province. So the running code and the softer problem, sooner or later IETF will accept that.

Satoru Matsushima: So you mean you have already running code for IVI.

Xing Li: Yes, it's running and China Telecom is running that and it's working. Actually in previous IETF you can take a look there is a draft both by us and the China Telecom to describe their trials.

Satoru Matsushima: We also have implementation for 4rd,... to make the sharing techniques.

Xing Li: We can collaborate.

Dean Pemberton: Any other questions from the floor?

New Speaker: I'm Justin from B networks, a Sydney based services provider.

This is an open question for anybody. Given that we've seen pioneers, such as ComCast and Internode, pioneering IPv6 adoption, do you anticipate that perhaps in the future there will be some form of agreement from large both consumer networks and content providers where you can reach some form of agreement to actually retire IPv4? Obviously it's not going to be in the next five years, maybe five years. Is it possible for people to reach agreement and is it ethical for a large perhaps coalition of users and providers to do something like this?

Donn Lee: I completely understand, but we would still have to run the v4 service for all the other providers, or other users

Justin: I'm actually talking to provide some form of impetus. If you gave the internet community at large a date in the future, let's say in four years time everything's running smoothly dual stack and then you take that opportunity and you do somehow reach an agreement that you set a date, you know, 2016, June 30, this large coalition of providers and consumers will be -- I see Geoff shaking his head.

Lorenzo Colitti: We'll be leaving a portion of its users in the cold. Would you say a portion of your customers: Sorry you can't be my customers any more, go away? Would you do that?

Geoff Huston: Is that what you said?

Justin: Do you see, so you're saying that's not a useful tool to provide impetus for the rest of the people to catch up.

Donn Lee: You're saying we would just have an agreement with one provider

Justin: No, I'm talking about trying to get a coalition of large --

Lorenzo Colitti: Did you say pull records from IDNS?

Justin: Attempt to retire IPv4.

Lorenzo Colitti: So you said leave your users in the cold, tell your customers to go away? OK.

Justin: Give them --

Lorenzo Colitti: It's difficult.

Mark Newton: Maybe I can help Justin. One of the predicates of your question was that we're several years down the track and everyone's already rolled out dual stack we're all happy and everything's ticking along nicely, so if we're going to turn off v4, to what end.

Everyone's happy Y would we.

Lorenzo Colitti: There is a burden with a dual stack network. Once there are no users who depend on v4, we can turn it off.

Dean Pemberton: There are some precedents in this.

We're not the only community that deals with moving from one technology to another. Australia especially has moved from analogue hand-sets to digital, analogue TV to digital. Maybe there's some learnings there.

Mark Newton: Adelaide Uni got rid of Apple talk from their backbone by claiming it wasn't Y2K compliant.

Donn Lee: The reality is for us probably the providers will independently decide when they can turn off v4, and we can independently look at that too. I think your point is if by collaborating or making a project it could like help speed it up or provide some more market aware type of a force.

Dean Pemberton: Awesome. Well on that note, thank you.

APPLAUSE

Dean Pemberton: We're running very short on time sorry.

I'd like to thank all of our speakers this morning and we will come back for an equally exciting afternoon session at 2.20. So thank you very much.

Session 2

IPv6 Transition Conference.
Final Count Down to IPv4 Exhaustion in 2011.
Tuesday, 22 February 2011.
S221.
2.00 pm.

Mark Levy: OK. We are back in the afternoon.

Yes, we are running a little bit late, but no complaints from anybody, please.

Just to make sure you're in the right place, this is the v6 discussions for the afternoon. Anybody who thought this was something else? No? OK.

Three talks this afternoon and we're going to deal with various different implementation issues and other issues involved with v6.

Dr CK Ng from the Hong Kong office of government -- this is the office of government chief information office area and this is, to give you an example, a very large staff that has around 70 different agencies, government agencies, and that's a pretty big area to go look at and to talk about, both what they can do with v6 today.

He's got this -- the government here is set up with a backbone, so that in fact, so you can operate this nearly as the way an ISP would operate this.

The thing you want to realise -- I'm going to say this ahead of time -- is that in all the years that I've been coming to Hong Kong, this is a location where there is some great networking going on. I'm actually really interested in hearing what we're going to hear, as far as what the government is doing, because I think you'll be pleasantly surprised and hear some very interesting things.

Anyway, Dr Ng, we would like to hear from you.

Chi-Kwong Ng: Good afternoon. In the presentation, I would like to share with you the experience on connecting Hong Kong Government to the next-generation internet.

First of all, I will talk about the support of the government in the IPv6 deployment in Hong Kong.

Then I will describe the government central IT infrastructure and services and how IPv6 is implemented in the government central internet services.

After that, I will share with you our experience during the implementation and the benefits achieved.

The support of IPv6 deployment by the Hong Kong Government can be described in four aspects, with the strategy in the core, with specification, facilities and lead by example surrounding it.

In 2008, digital 21 strategy, we aim to promote advanced technology and innovation and the next-generation internet is one of them.

Two major drives for the IPv6 deployment are clearly stated in the strategy.

That the address capacity of IPv4 will soon be exhausted and IPv6 will generate a new horizon of business opportunities for ICT and other sectors.

We also brought out the determination of Hong Kong Government to take the lead in the adoption of IPv6.

So what's the situation now?

The global pool of IPv4 addresses eventually exhausted earlier this month and this is a hot topic. Hong Kong Government has also enabled IPv6 support in this central infrastructure and IPv6 deployment activities are undergoing actively.

In the specifications for network communications and procurement with the government, both IPv4 and v6 are included as recommended specifications for network communications in the interoperability framework, which facilitates effective and effective communication and interoperations of government systems with other systems, including those external to government.

IPv6 support is also a mandatory requirement in centrally organised contracts for providing network equipment to government departments.

Servers and other products available in government agreements are also capable to support IPv6.

Project teams are highly advised to select products that support IPv6 in addition to IPv4.

We also facilitate IPv6 deployment in the industry and public, as well as government departments.

The IPv6 forum, Hong Kong chapter, was established to provide the ICT industry with guidance for the deployment of IPv6. Our department, Office of the Government Chief Information Officer, also has theme pages on our website for IPv6 deployment for reference by the public.

Internal to the government, we have set up a website in our IT information station to provide government departments with technical guidance to prepare for the IPv6 transition. We also organise training and sessions on IPv6 for our colleagues.

On our knowledge platform, we have set up a broad and discussion forum to raise awareness of policy and facilitate discussions on the issue.

IPv6 has become one of the hottest topics in the discussion forum.

so we enable IPv6 support in our central IT infrastructure, like the government backbone network, connecting all government departments and services, the central computer centre network, connecting systems within the data centres, the central internet gateway, connecting to the internet and the government-wide internet system, offering information and common services for all government departments.

The government central internet services consists of the following major services: the domain name service hosts over 1,000 web domains and 200 mail domains, the web hosting services hosts over 240 websites for access by the public and with more than 180 million page views per month.

There are over 46,000 internet mail users, with more than 4 million email exchanged per month, over 38,000 users use the internetk a sess service to access websites and resources, with over 2 billion web page requests per month.

We have conducted a technical study before the actual implementation with the following objectives, review of current IPv4 network infrastructure and application architecture, design of new level infrastructure, application architecture, network security, administration, operation and support.

The project road map for the implementation and best practices, not only for the implementation, but also for ongoing network management.

We have adopted a strategy to break down the implementation into many stages for each system or infrastructure, including the high-level proof of concept, local design, preparation, pilot, deployment and operation and optimisation phrases.

One point I would like to highlight is that every feature should be tested before adoption and verified before production and ongoing support is a continuous process.

These are the approaches for our implementation.

Procure IPv6 ready equipment during natural technology replacement and capacity enhancement exercise. This is to save one solely for supporting IPv6. Don't dual stack approach as far as possible.

This is to avoid equipment we will use more money, web space, electrical power, et cetera.

Activate IPv6 by actual user demand. This is for security and system management concerns.

Focus on external service provision instead of internal infrastructure adoption.

This is to realise the benefits as soon as possible.

Implement by services phases and data centres.

This is to ensure the stability of production services, while adopting new technologies.

For the road map of implementation, we firstly enable the IPv6 support of the supporting infrastructure, like the internet connection and the computer centre network.

Then we enhance the external services, like those of the central internet services to support the IPv6 protocol.

After that, we can also enable the IPv6 support of government backbone network and government internet system for government internal services among departments.

During the implementation, we have to ensure our internet infrastructure can support IPv6. The Hong Kong Internet Exchange for local internet traffic and Hong Kong domain name registration for resolving .hk domains can support both IPv4 and IPv6, in green colour in this diagram, however, during the implementation, our ISPs for the overseas traffic can only support IPv4, shown in the yellow colour here, so we need to acquire another ISP for IPv6 connection, as shown in the blue colour here.

Our border gateway, computer centre network and government backbone networks are enhanced to support both IPv4 and IPv6 at the same time.

Our domain name server supports resolution of both IPv4 and IPv6 addresses for incoming queries.

Outgoing service requests are also able to select automatically either IPv4 or IPv6, depending on the targeted internet communities.

Web servers are enhanced to handle requests on both IPv4 and IPv6. Government websites are accessible by both IPv4 and IPv6 with the same domain names. There is no list for IPv4 or v6, only website, like some website has www.something.com for IPv4, but IP6.something.com for IPv6.

The implementation is also transparent to webmaster, as they can still access the file servers, database servers and active servers using IPv4.

We have enhanced the internet mail system by enabling dual step for the mail transfer agents for outward mails and adding new IPv6 mail transfer agents for incoming mails, as the current ones do not support IPv6.

Mail users can exchange emails with both IPv4 and Since this is automatic IPv6 to v4 conversion before sending into networks, which are still running IPv4 and also automate IPv4 to v6 conversion before delivering to the IPv6 internet recipients.

Internet access proxy servers are enhanced to access both IPv4 and v6 websites. Users are also transparent to which protocols or websites they are accessing, as there is automatic IPv4 and v6 selection in accessing IPv6 websites by protocol conversion in proxy servers.

For future optimisation, where more ISPs are ready to support both IPv4 and v6, with more effective solutions, we can combine the ISPs for both IPv4 and v6 traffic. Also, for the mail transfer agents for incoming mail, we can merge the two sets of MTs when they can support both IPv4 and v6 protocols.

You may ask what experience we have gained in the project and what advice we will give. It can be described in five aspects. In the project management aspect, we advise to plan early for IPv6 deployment, it will take much longer time than expected.

To focus on external service provision than internal. To start simple and grow incrementally.

To review IPv6 support of current infrastructure.

As not all equipment and software support IPv6 at this moment, especially for those purchased several years ago.

An important point is that you need to empower your staff and also support staff by suitable training.

In the network and system management aspect, we are going to implement new technology and there will be new security considerations.

We need to be aware of the readiness of system and network management tools. We also need to be aware of extra efforts on administration and troubleshooting for both IPv4 and v6 configurations.

In the network aspect, ready IPv6 support for backbone network equipment and infrastructure with first priority.

We need to be aware that not all ISP support IPv6 and the nature of support may be different.

In the server aspect, we need to be aware of the product functions supported for IPv4 and v6 may be different.

For example, can proxy servers support all required protocols under IPv6?

We have to check whether statistics and reporting functions can accurately interpret IPv6 access logs.

We advise to test IPv6 support through different perspective, for example, by external organisations and websites.

In the application system aspect, we need to check whether applications are making use of IP addresses or assuming the IP address format.

IP address independent should be considered in application design.

To conclude my presentation, I would like to mention the benefits of the IPv6 implementation by government central internet services.

We have connected government services and users to the next-generation internet and surprisingly, we observe IPv6 traffic from the public in day 1 implementation.

We are ready for the opportunities for future types of government applications and services.

We have set up a successful example and gained valuable experience for reference by government departments, industry and the public.

The implementation is transparent to government users and the public and it is very important for the adoption of IPv6.

We have used the most cost-effective approach to minimise the cost in the implementation, as well as ongoing maintenance. And this also aligns with our green ICT initiatives.

You are welcome to visit our websites and email to me for further information. Our website and email system supports both IPv4 and v6 with the same domain name.

You have seen this "2406" many times on my slides and this is our IPv6 address prefix.

Thank you.

APPLAUSE

Mark Levy: Thank you very much. I have a question for you, while you're still up here.

Sorry, let's me explain. I'm going to ask -- I'm just going to pop in one question and then we'll take the rest of the questions at the end.

But you had a slide you talk about training your staff and empowering your staff. Of the IT staff that deal with networking, how many people is that and how many of them will you run through training that includes v6 as part of their network training?

Chi-Kwong Ng: We run many different kinds of training and in different depth of the training.

Some are very technical, for the network support people, and some for the applicant staff or Because it is -- IPv6 is not just on the network, on the technical side, but also on the other side, for example, the applications and the management.

Mark Levy: Thank you very much.

It's always impressive to hear a government moving forward with this at this type of depth.

Absolutely correct. If you go to the website from here, brings it up under v6, as happy as can be. So congratulations.

Ayuma Yasuda from NTT East. He's a network engineer with NTT East in Japan. He's in charge of the operational management of NGN, the next generation network, which you will hear about in the -- it covers the whole of Japan.

He has been involved in both the NGN and also the IPv6 side of NGN.

Ayuma Yasuda has also been engaged in the IPv6 promotion council in Japan to deal with IPv4 exhaustion, so that's an interesting subject now that we are finally in runout area.

Before joining NTT East, he worked at NTT Communications, an operating OCN, which if anybody knows, is one big network and it's actually the largest in Japan.

Ayumu Yasuda: Good afternoon. Thank you for the opportunity to present in this APRICOT-APAN meeting.

I am Ayuma Yasuda, representing the IPv6 Promotion Council Japan and Task Force on IP Address Exhaustion. Now I engage in NTT East Japan also.

Today I introduce Japanese public activities for IPv4 address runout, which operated by IPv6 Promotion Council and Task Force on IPv4 address exhaustion.

IPv4 address will finally run out. On the other hand, in Japan, we have considered about the program solving method for 10 years or more. Let me move onto the activities in Japan. To promote IPv6, there are many multi-stakeholder organisations in Japan. One is IPv6 Promotion Council and the other is the Task Force on IPv4 Address Exhaustion. IPv6 Promotion Council was established in October 2000 and we have more than 200 organisations and individuals as members.

The Task Force on IPv4 Address Exhaustion was established in September 2008 and has 23 internet-related organisations like ISP associations or such, including the Ministry of Internal Affairs and Communications as members.

Both organisations are promoting IPv6 from various aspects in separate working groups.

IPv6 promotion council on the task force have almost same purposes. Those are solution for the issue, technology issues, operational issues and management issues.

Support move from v4 to v6, human resource development, pursue international leadership role for Japan in the internet field and promoting e-business and existing business in hardware, software and service network and devices.

Then I introduce our many activities. Basically, we have five different activities for promoting IPv6.

Number 1 is status check. We always like to ...

current status around IPv6. What should be done in the future change depending on the current status.

Status check is important.

Number 2, enlightenments and publications.

We have to read and support the organisations, especially which don't have enough resources to investigate and verify by themselves.

Number 3 is building guidelines and authenticating IPv6 ready activities.

We have already made some guidelines for introducing IPv6 and also have authenticating programmers IPv6 ready.

Number 4, technology verification. This is one of the most important activities for us and for everyone, to improve IPv6 environment. Later, I will talk about this in more detail.

Number 5 is human resource development. This is an important task for us, too. We have had a lot of seminars about the IPv6 to develop human resources.

We will regard them a bit more in detail.

First, I talk about IPv6 transition status in Japan. We are connecting with IPv6 introduction status introduce IPv6 in the companies. We have asked approximately 350 organisations and as you can see, 90 per cent of the ones know that the IPv4 address ran out, but about only 25 per cent of those organisations have actually introduced IPv6 services and products.

So many companies are still waiting to see what is the right time for introducing the IPv6. This is ... in last year's data. Sorry.

... introduce IPv6 to organisations. The answer with most number is cost calculation and preparation were difficult. A lot of people related to business of the internet could not calculate the cost of introducing IPv6. Actually, it is difficult to on the current status which could judge.

Many kinds of prior node already have IPv6 and router switches and other network equipment will already have IPv6 functions.

Even for IPv6 does not run or your router, maybe it will work well for you in its function. The cost depends on the scale of the network. In many case, almost all the network needed service to the function. You introduce IPv6 in at that time, you don't need additional cost for IPv6 in ISP.

What you have to spend money on is technical education and technical verification in your organisation.

Task force for every organisation.

Other answers knowledge and information about v6, lack of products and services for v6 integration.

Lack of human resources. Lack of general knowledge for IPv4 depletion from the users.

Lack of knowledge at the management level.

These focus on lack of knowledge, so we are working on this issue.

We have decided concrete action plans in 2008 to recognise the IPv4 exhaustion. As part of the enlightenment and publication activities, we are proposing action plan for ISP, IDC, ASP and business users to show what are the steps they should take to introduce IPv6.

We are publishing this action plan on the web, so the people who want to participation can utilise this action plan.

This action plan say that it takes about two years to integrated IPv6 in a company's network, after ...

However, since NTT is starting with IPv6 services in this April on the network, it seems some of the companies are targeting that timeframe to integrate IPv6 to their network.

In the future, like it or not, users will be using IPv6 network and if your company or organisations need to work is not ready, then your network might have bad problem, that users cannot connect to certain website or services that they use if they use your network. So you have to be very careful to deploy v6 before then to avoid bad damage.

Then, I explain about there are many in the internet of Japan and Japanese network direction.

So I'm going to talk about this with NTT.

NTT has been divided into east and west communications as a company in 1999. After we start several IP services, NTT group have been re-directed to advance services.

In Japan, in many cases, ISPs are different from access line companies. Similar ISP have theirs own access lines. In this environment, NTT East and West have provided this line between ISP and end users. We have not been able to behave like ISP.

NTT East and West start IPv6 connectivity service from this April. We have two methods to access to the internet. One is tunnel method and the other is native method. For an ISP take this method and users will be able to access to the internet by using IPv6. I describe the detail of this to anyone the native method now. We will make a speech about the NGN, NGD tomorrow. Close and open network.

The explanation of NTT and Japanese background of the internet ends.

Back to the activities of IPv4 exhaustion in Japan.

It is one of the entitlement activities. We are also connecting management level people and operators to share the information of IPv4 exhaustion.

Explain about the status of IPv6 services and products.

We are also preparing list of IPv6 services and list of IPv6 technology certification programs.

With this, people can see what kind of IPv6 services there are there and how they will satisfy IPv6 ready services.

Taking our guidelines and authorisation activities. We are creating a model that is much examples for ISP CATV dual stack network.

We are also creating the guideline for building IPv6 home routers that can support v6 services offered by NTT.

We are satisfied ISP education programs as IPv6 ready.

I know that IPv6 forum is also started to certify education program and give IP6 ready logo and we will provide collaborate with those programs also.

We authorise examples ready for IPv6 promote developing engineers for IPv6.

Introducing our test bed. As technology verification environment, we have built two test beds in Tokyo and Osaka. We have global AS, addresses and /32 IPv6 addresses, multi-vendor devices so any organisation can test their network service or devices before putting them to commercial level.

The test bed environment is offered and is This means we do not charge the users for utilising the test bed. This test bed is actually open to anyone, even from the overseas countries, and we have hands-on seminars using this test bed in Singapore and Thailand so far.

If you are interested in this test bed environment, please contact me after the session.

We are also conducting testing for IPv6 devices and applications.

Now some examples of verification using our test bed. First, middle scale ISP ... verify their network with IPv6.

On our test bed, you can simulate large-scale ISP.

We receive a lot of cooperation from many vendors, so you can construct various type of network as you like.

I introduce the example of verification. For ISP, they construct same network as their own network and configure BGP, OSPF and other network parameters for only IPv4. Then configure all parameters for IPv6 ... then check whether it works well or not in this environment. Then making basic network server and they confirm that there is no affect to IPv4.

... make everything possible happening and then they make sure that the status of reachibility to the internet by v4 and v6.

Finally, they may proceed to migrate to networks.

You can change the topology according to our customer. We have many equipment and flexibility.

Then verification of CATV ISP. Our test bed correspond to CATV network also. Network structure of CATV ISP is greatly different from usual ISP.

They have network, use CMTS and cable modem, which are not on usual CATV. On CATV, you see another platform and protocol from usual ISP, for it is called ... however, 3.0 is not perfect for their own implementation. We need some debug and improvement.

We have two CMTS ... and lots of kinds of cable modems, several CATV companies use our test bed to verify their own own network.

There are a lot of kinds of modems, so they have to test many numbers of times.

Data centre provider need to migrate to IPv6 also.

They have to verify service network, for example, layer 4 and layer 7 switches before translator, proxy and ... networks.

After verifications, they migrate to v6. To migrate to IPv6 is not only way to serve IPv4 address exhaustion issue.

Actually, there are many cases that we cannot migrate to IPv6 directly because of several technical issues.

Especially in case of ITC, we assume that they take translator approach for their users. We operation team assume about this situation. We prepare translator equipment and support verification for ITC provider.

Case 4, I explain the verification of application developer. Network application developer should consider about transport layer and network layer.

The application need to correspond to IPv6, especially various network devices and required to work correctly in various network environment.

Many applications developed device make the best use of our test bed. On the other hand, application developers do not take care of network. They don't need to consider version of before v6 ...

Application developers need no effort to consider about IP addresses.

It is wrong to make many application programs think about IP.

There are two important things for us. First, we should make an effort that they get correct information about IPv6. Building comfortable environment for verifications.

Last case, security appliance developers.

Many also on IPv6. However, the capability of IPv6 in the security is not completed enough. The v6 network is not often found without filters for v4 and users not hidden by router like private network before.

Some security vendors use our test bed for following usage. Check the behaviour of protocol and implement around security issue for IPv6. Check the behaviour of IDS/IPS for IPv6. Collect malwares for IPv6 and develop signatures for IPv6, and so on.

We are strongly promoting products of v6 to security developers.

I talk about holding hands-on seminars. It is another exciting challenge for us.

We are conducting hands-on seminars to develop IPv6 ready operators, since it is operators, after all, introducing of IPv6 technologies. We are conducting this hands-on seminar using actual devices like Cisco, Alaxalia, ARRIS and other equipment prepared for each topics. Our topics are ISP network, IDC network, servers, CATV network and IPv6 multicast.

We have had the seminars over 50 times only last Some of the materials translated into English and you can download these materials at the mentioned URL.

I talk about holding hands-on seminars and it is a -- the first internet hands-on seminar was held in Singapore technology university last year. 12 people and assigned one router per one participant.

Alaxala is one of the most famous in Japan. As network shown, we connected between Singapore and Tokyo through some networks.

In this seminar, they experienced configure IPv6 service and OSPFv3 and shooting virtual trouble.

We also held the same seminar at Bangkok, cooperated with CAT Telecom. We have 16 participants and the content is the same as Singapore.

I introduce our internet relationships. We IPv6 promotion have a strong to make wonderful relationships on IPv6 field with countries, especially Asian countries.

This shows the list MOU IPv6 introduction. We started our activities on our test bed since 2009.

We have signed MOU with Taiwan, Thailand, Singapore, Malaysia and India and trying to sign with Indonesia. Talking about the past MOU, many professors of Taiwan came to our test bed this Tokyo and we had a useful discussion at that time. After that, Japanese task force signed MOU with Taiwan.

Interoperability and certification of next-generation internet project, this is first MOU for us signed on October 2009.

SingAREN, Singapore advanced research and education network is a nonprofit organisation. They have a national project founded by the government and work to next-generation internet.

Thailand, we sign with IPv6 forum Thailand, Thailand ISP association, Thailand research education network association. Malaysia, we signed with national advanced IPv6 centre of excellence.

India, we signed with telecommunication engineering centre. And lastly, in this session, IPv6 promotion council in Japan just signs MOU with Indonesian IPv6 forum, look forward to our ceremony.

If your country doesn't conclude MOU with us and you want to conclude the MOU to do it, please contact me.

This is signing ceremony.

Last, I summarise our activities. Our purpose is we should be clear that we are going to the next phase for IPv6. We are sharing the information, knowledge and experience, but it's not enough. We should work together to create common infrastructure such as DNS and connect interoperability testing for internet.

We should collect traffic data to analyse the data for better internet usage. Last but not least, the society as human being and we propose exchange of human resources for creating the better future.

Thank you.

Mark Levy: I have a question. What will be the mission of IPv6 promotion council in Japan after the global v4 address exhaustion?

Ayumu Yasuda: In these few years, we have had several action items, on the assumption that address run out, so our viewpoint will not change in this moment.

Mark Levy: Thank you very much.

There was a great line in one of the slides which talked about discussing the cost of v6 introduction and I always like to point out to people, there's a cost of not doing a v6 introduction and it's a different way of doing it. You know, just a different way of thinking about it.

We have Leslie Dagle. For those that don't know Leslie, she has been involved in the IETF in the IAB, internet advisory board, you were president for two years?

Leslie Dagle: Eight.

Mark Levy: Eight years? I wasn't very good at math. I have the dates, I didn't do the math.

Anyway, yes, it's exactly there. It's right in front of me. I apologise.

2002 to 2007.

And you're going to talk to us about World IPv6 Day, a non-trivial subject.

Leslie Dagle: Indeed. Thank you, Martin.

So, uncharacteristically for today, I'm not going to talk about our organisation's activities in deploying IPv6 in our networks or on our content providers, I'm going to talk about everybody else's efforts and to give some context to that, I suppose I should say about two words about the Internet Society.

It was formed in 1992 by Vint Cerf and others. It has acted as the organisational hub for the internet engineering task force, but it has a lot of its own activities in promoting different development activities the world over, supporting technical coordination and activities which is where I'll policy and other activities on the global stage.

We do have several chapters, over 90 at the moment, I think, including, of course, the Internet Society of Hong Kong, you've already heard from this week.

In that context, I'm going to speak a little bit about what we've seen the world over, in terms of IPv6 deployment and its importance, because after all, we're all in it together.

The internet was built with standards, intended to facilitate interconnection in exactly to allow internet working.

We have seen global growth and development, but not ever such that it was particularly planned uniform or paid for by some central authority, which made it all together very different from previous networks and has been great for innovation, but very problematic when you broach something like running out of IPv4 addresses and the need to move on.

So what to do?

IPv6 development and deployment, the early years, you're heard it all before and you've heard how nobody paid attention, but lately, well, the internet continues to grow, it continues to get smaller, the devices that are connecting to it are smaller and people tend to have more of them, so even if we could reuse every IPv4 address that was ever allocated, there simply aren't enough, because there aren't as many as there are people on the face of this planet.

So in the interests of a future internet that is globally connected, supports innovation and provides us everything, the platform for the kinds of things that we have seen to date, IPv6 really is the only answer going forward.

So we've talked today a lot about individual organisations efforts, their experiences in deploying IPv6, their ongoing concerns. But I think it's important to take a step back and have a look at what's been going on the world over through the course of the last few years.

We have seen movement on the global stage in 2008, there was an OECD ministerial held in Seoul, Korea.

The output of which included a statement from the OECD countries creating a policy environment conducive to supporting the timely deployment of IPv6. It was clear on the global stage that IPv6 is important and governments should do what they could do to support its deployment.

More recently, APEC TEL, at the meeting last year, completed some recommendations as well.

Fairly lofty stuff, but important, nevertheless.

As we have heard already, just now, governments have had an important role to play as well. In 2008, for instance, the European Union issued a call to action looking for 25 per cent of European traffic to be IPv6 by the end of 2010. In case you didn't read the news, it didn't happen. Not that I think that anybody was necessarily surprised, but the important thing was to establish a stake in the ground and try to direct motion towards IPv6.

We've heard already in some detail what the Japanese government has done. The US Government has done various events over the course of the years to try to stimulate IPv6 deployment while remaining in a hands off position.

The usual sorts of things that governments can do, namely calling for procurement to supply services over IPv6. One of the interesting things -- a couple of years ago, I was listening to some folks talking about the Australian timeline for IPv6 deployment, the government timeline and this is a case where some of the global stuff that I was talking about a moment ago, actually has an impact.

The Australian strategists looked at the OECD output and realised that their timeline was too far in the future and they actually moved their dates up.

Even as recently as last year, increasing effort from the US Government, calling for accelerated IPv6 operational deployment and various other governments stepping up as well.

This slide is starting to be far too small and I'm very happy for it.

We've seen some motion over the course of the last few years, Free in France is fairly famous for its 6rd deployment in 2007. 2009, Hurricane Electric upped its IPv6 offering. Last year, it was certainly a banner year. I guess, Geoff's messages were finally hitting home and a number of service providers started announcing v6 trials, announcing customer trial, announcing equipment trials and this is all over the world, in the US, here in Asia, in Europe.

This here, Comcast, has already announced its dual stack v4, v6 offering and a number of other service providers are looking to come on-line.

I put all these things together because I think it's important to realise that there is a global momentum that it isn't just onesies and twosies, and to the point that for all the talk that there's always been about v6, some day, there really has been some background motion and maybe now we're seeing some kind of momentum. We see it in the content providers as well, of course, it was I guess three years ago now that Google led the way with building out its IPv6 services and flipping the switch at an IETF meeting and 2009, Netflix and Limelight started their activities over IPv6 and plenty more expected this year, of course.

So that's some notion of where the momentum has been, but there's still a but. As we heard on the panels this morning, ongoing measurements show that enabling dual stack for web content results in some users experiencing connectivity issues and from the standpoint of making IPv6 viable for commercial offerings for commercial content offerings, although it's a very small percentages, it's still a large enough numbers to get the attention of the business folk at content providers, which basically provides a disincentive for those large content providers to turn it on and certainly to turn it on and act unilaterally.

Again, the internet is deployed by individuals and organisations building out their equipment and their networks for their own reasons, so it's pretty important to listen and understand when large segments of internet content and service providers have an issue.

The internet is an exercise in collaboration and we thought, well, we can essential help provide a platform, help build confidence and try to get some measurements around this particular deployment issue.

Which brings us to World IPv6 Day.

So what it is. June 8 of this year, for 24 hours, counted on universal time, major content providers will turn on IPv6 access on their front door, not just on a side door using special host names, and the goal of this test flight, really, is to -- well, first and foremost, motivate more organisations across the industry to step up and be ready to take the test flight on June 8 and certainly also to take an opportunity to test IPv6 readiness and we're expecting that this will help lay the groundwork for large scale IPv6 adoption in the future. But in the first step, this is some of that testing and piloting that was referenced a moment ago, done on a global scale.

It's not a first. There have been similar efforts in particular regions in the world to go ahead and turn on IPv6 for a day, but here, with the major players involved, we're happy to see it happening on a global scale for a day.

So at the Internet Society, what we have seen already is lots and lots of interest. We've heard from content providers, service providers and any number of other organisations expressing a lot of interest, more than 210 entities contacted us within the first month and you can see -- I'll give you the URL for the web page in a moment. The list is growing in terms of entities that are signing up and committing to actually take the step and have IPv6 available in a meaningful way for their customers on June 8.

It's not happening in one particular region. It really is happening across the globe. People around the globe are organising their local region and we're certainly interested in seeing more people join in from across the world.

So this is what we hope to see on the 8th: nothing. It's all going to work, right? It's just going to be smooth sailing.

Well, hopefully.

So you can test your IPv6 readiness at test-ipv6.com. There will be various measurements and tests and other activities undertaken to see what actually happens on June 8 and an important point there as well, we've turning it on for a day, we're turning it off, in part really to take the step back and see what happened. It's not the sort of thing that you can, you know, turn it on and if you don't get any customer calls, assume it all worked and keep it going. Maybe your customers aren't able to reach you.

So here it is, the URL for our organisation page.

It gives you information for what to do if you want to come play. If you're a website owner, there are some requirements. If you are an access provider or a hosting company and so on, some requirements there as well. We're looking for entities that are providing commercial IPv6 offerings. So do contact us if you're interested in participating. There are details on that page.

Do contact us if you're planning to do some measurements, because it's really a great opportunity to get a global perspective on a major event in the internet.

Do help us make it truly a global IPv6 day.0 various expressions of interest in terms of World IPv6 Day itself. It's been an interesting process already. Certainly interest is snowballing.

A number of entities are using this for the purpose, we hoped they would, which is to say to their management: you know, look, we really do have to move, because there's this day and people will be able to tell if we played or we didn't and it's great to see that happening, because as we've heard all throughout today, IPv6 really is where we need to go.

We're supporting this as part of our efforts to help accelerate IPv6 deployment from our perspective, 2011 is a pivotal year in v6 deployment. V6 is in essence must work, it has to work for existing companies, it has to be business viable. We need to see an awful lot more actual traffic usage. To push this out of the realm of the hypothetical.

It really needs to get to the point where it's perceived as not only business critical, but also business viable. Not necessarily in that order.

Part of the challenge has been so far, IPv6 deployment has been a bit of a moving target. Yeah, I'll get to that some day. With the World IPv6 Day, we're really hoping that a number of entities will move up to making that some day on or before June 8.

Our general take aways for IPv6, standard, we generally recommend that v6 -- you make v6 a top priority for your organisation, with visibility and awareness to the senior executive levels, we generally recommend you accelerate IPv6 deployment plans.

And an important one and an important point that sometimes gets a little lost, it's also really important to communicate publicly what your plans are, because we are all in this together. The more decision makers can see that everybody else is getting ready to dive into the swimming pool, the more they will continue to support and prioritise IPv6 deployment in their own realms.

So this is not a time to be quiet about your actions, but step up and make it known.

Thank you very much.

APPLAUSE

Mark Levy: Thank you, Leslie.

So I'm going to ask you this question. Where are you going to be on World IPv6 Day?

Leslie Dagle: There's a small island in the Bay of Fundy ...

Mark Levy: Seriously?

Leslie Dagle: Undecided, but it could happen, yes.

No, the point is it really should be pretty -- it should be pretty smooth and a lot of it will come down to having a look at the data and seeing what actually happens before, during and after.

Mark Levy: I agree. Thank you very much.

You know, you hear three different perspectives on this. There's deployment at the government level and I have to make this comment, I was less than a month ago in Washington DC listening to various government departments talking about what they're doing. You're way ahead of curve here. This is a good thing.

You can listen to what providers are doing at the infrastructure level, non-trivial aspects of infrastructure.

Then you can look at it from an organisation involved in the standards in the policy and education and look at what happens for them.

There's a wealth of questions that you guys can ask. You have a large array here.

So I want to see about 10 deep at every microphone. Let's see if we can start from the audience.

Speaker: My name is Wong Kong. I also work for the Hong Kong Government. So my question is to be answered by Dr CK Ng. I read from your slide that the government employ a very sophisticated IPv6 proxy, so that IPv4 hosts can access the IPv6 as well. Can you comment on the performance of such kinds of equipment? I know that this kinds of equipment is quite new in the market, when I say new equipment in the market, I mean they are very spendcy equipment. In what way can these kinds of equipment help the transition to IPv6? Will they lower the pace of transition to IPv6 or they accelerate the pace for the IPv6 transition? Thank you, Martin.

Chi-Kwong Ng: What we are using is the proxy server, I think many large enterprise organisation use proxy server for their staff to access the internet. It's not any new type of equipment, but I think we use the proxy server for many years and what we have done is the proxy server can support the IPv4 and IPv6 protocol and you do a protocol conversion.

As an expert in the morning session have already talked about, some large-scale proxy or network1 case, I think we, as the enterprise level and we used to use the proxy servers to access to internet, so we don't think there is any difference in the performance in accessing IPv4 or IPv6 websites.

Mark Levy: Thank you.

Speaker: I'm Prashan from India. My question is to all three of you. As for vendors, there are hardly any providers vendors who support DSL type of technology, who have IPv6 ready equipment and. Are you doing anything so -- there are no service providers who are see in foreseeable future that they will be able to procure the equipment in large quantity so that it will force vendors to go, produce, manufacture IPv6 equipment. So are you doing anything from that point of view? Because in Asia, as far as ISPs are concerned, to go for IPv6, one or two years horizon, so those are the factors which are hindering to switch over faster to IPv6.

Mark Levy: Leslie, you actually know what some of the providers in the US have been doing in this area.

Leslie Dagle: Well, I want to make some rather general remarks. There is general equipment available for most types of access networks, although the challenge is when a service provider has particular requirements that require their own special run of equipment, let's just say it that way.

In terms of what we're doing, the people that have the best -- who are in the best position to influence these equipment manufacturers are the large networks themselves. So I think that our best effort is to provide this opportunity for access providers to turn to their equipment providers and say, you know, we have to move. What are you going to do to help us get there?

So it's not direct, you know, it's one of those things where it would be nice if somebody had a magic wand and could enforce some movement, but it is at least an opportunity to stop -- essentially to get people's attention focused.

Speaker: Joshu Isaki of the white project: Regarding that topic about CPE business, as Lorenzo said, we are discussing about certification for CPE devices including the so-called routers, DSL routers, we realise, as we said, that's very complicated, almost impossible to certificate, using the exact same, you know, technological specifications.

So what we discuss as the IPv4 within our team is probably national labs is going to specify working request providers, specify what is the common specification for the large access network such as cable or ISPs and so on.

So in that line, as it was said, we define the sort of implementation guideline for the IPv6 NGN.

That kind of thing we need to do.

Mark Levy: This question, it's a great question.

This question gets asked and has been asked for years. But I will throw back a request to you.

When you go to your local electronics shop or to your service provider and you have to buy a new router for home, a wireless gateway or whatever you buy, ask the question: is this ready for v6? And if you can, vote with your wallet and only spend the money to vendors that actually have that, or pick a new telco, if that's in any way possible. That's just a personal mindset.

OK. Anyone else?

Speaker: This is Rocky Cheng from Hong Kong Polytechnic University. This question is for Mr Ng.

At the end of the slides, you mentioned about this IPv6 deployment is aligned with green IT initiative.

In what way is it related to that? Can you elaborate?

Chi-Kwong Ng: During the implementation, we don't new approach and we deploy the IPv6 during the natural technology upgrade or capacity enhancement exercise and this avoids us to add additional equipment to our system or network. In that sense, we add additional equipment, we make use of more web space power, et cetera, so the implementation is adhering to our green initiative.

Speaker: My name is Prem. Good afternoon, everybody.

I work for a telco in India and I think while going through the presentation made by Leslie, while we are trying to build up and have this IPv6 day, but my observation is that very few countries and a handful of ISPs and organisations that actually, at the moment on board, if we talk about, you know, having some sort of a kick-off on 8 June.

So what are we actually thinking in terms of building up our mass moment around it? I think that is the true success that IPv6 would see, otherwise it will again remain an activity, you know, centred around a handful of service providers and users.

Leslie Dagle: I think that's a very good point.

I think one of the key things that we need to keep in mind is the point of June 8 is to make it real.

It may not be the mass deployment or the mass2 later, but it is going to be far and away the clearest sign that we've had that IPv6 is not just slideware.

I think we need to get through the June and see where we are actually at on 9 June before we figure out what can we do to get even more momentum behind it.

I'm hopeful that 9 June will inspire more uptake from the standpoint of seeing that it is viable.

Mark Levy: I have one quick statistic for you.

Keep in mind that when you look at the global routing tables, that we're sitting -- and this is the count that we did and we have been doing now for a while -- we're sitting at about 123 countries where some legitimate v6 deployment has occurred.

Sometimes only in service providers and not towards end users or broadband users. But that number is up by -- it was about 90, 91 a year ago at APNIC in Kuala Lumpur, so there is a growth there. So this is not just a small amount, this has got a pretty wide potential for very widespread coverage.

Ayumu Yasuda: Do you have any fall back if some trouble happens?

Leslie Dagle: Yes. There obviously is a lot of background coordination going on and the operators -- I'm not an operator, which is why I can be on an island on 8 June. But the operators will be coordinating and planning what they need to do if they need to back out. So this is not just a jump in and hope it all works out kind of event, but rather, what is it, like ducks, calm and unruffled on the surface and paddling like heck underneath.

Speaker: Good afternoon, my name is Michael.

I just wanted to ask you, if you have any feedback from governments that there is something more than just talk, some government in the region, in Europe, going to actually mandate IPv6 at some point in the future, OK, in five years, everybody sold must be IPv6 capable?

Leslie Dagle: I think it really does vary the world over. We heard in some detail the Japanese plan. In most cases, governments are reluctant to mandate, because they have not taken a stance of mandating anything for the internet and the internet's deployment. Quite honestly, I think we would like to keep it that way, which is why the OEDC framework for instance talked about how to stimulate and recommend and support IPv6 deployment without making it a question of mandating.

There are specific actions taken, whether it's in countries where it's possible to lay out a national plan for how do you bring your ISPs up to IPv6.

There are more detailed proposal as from different governments like in the United States that went from acquiring that equipment sold to it would be either v6 capable to now requiring that their own internal services will be IPv6 capable. There is discussion of having a CEO -- well, a board level checklist, so that organisations could review boards of organisations could review the status of the organisation in terms of IPv4 run out and v6 deployment. That sounds a little vague, but at least it's stimulating at the business level, making sure that your industries are aware of the seriousness of the problem and giving them some kind of a concrete action to follow up in their own organisations.

Mark Levy: Thank you. Actually, thank you very much for the questions.

I'm going to respond to the mandate comment.

I think there should be a mandate and the mandate is that if you are here and you represent an organisation that is yet to implement v6, I have a mandate for you: find somebody in this room or within the conference, you have another three days, and speak to them about what you need to do for v6.

That's my mandate.

Thank you for the panel. Thank you for everybody else.

A couple of housekeeping notes or one really important one. We will resume at 4 o'clock here and continue with the last session of the day. Thank you very much for attending and thank you everybody.

APPLAUSE.

Session 3

Kenny Huang: Good afternoon. Welcome to the session.

This will be the last session for today's IPv6 Transition Conference.

We have pretty much a lot of content reported this morning and this afternoon from ISP IP V, so this session will be specifically focused on IPv6 operation issue policy issue.

The first speaker will be Geoff Huston. Geoff Huston is a famous one. Most time use IPv4 exhaustion predictor.

Let's welcome Geoff Huston to give us a talk on the company perspective of IPv6 transition.

Geoff Huston: Thanks, Kenny. Good afternoon. I'm

Geoff Huston. Most of you sat through the presentations today, didn't you, this morning. I must admit at the end of that, I felt really good about v6. I was almost an optimist, but unfortunately it's about to come to an end.

Because I don't actually have such a rosy view of transition in v6.

I'd like to go through some of the, I suppose, thought processes that have led to that view that where we are is

actually a rather terrible state and getting out of this hole is going to be extremely difficult and the problems are actually not technical.

Hopefully all of you sort of appreciate this slide here about what was meant to happen. Because this is a slide that goes back, at least in theory, to about 1992 or 1993 when we first thought about how we were going to transition the internet. Certainly sort of the green line was this ever up and to the right curve of the internet growing, growing, growing and the blue line was the pool of available v4 addresses which, over time, was going to decline and it obviously has.

While we still had enormous amounts of time, we were going to start deploying v6. We were going to plan, we were going to think forward. And long before we ever got to the last address, everyone was going to run dual stack, in which case we didn't need v4 any more.

It seemed like a really good plan. It seemed like a really good plan to folk who worked in the telco business. I worked in the telco business for ten years.

It was great. I loved it -- not. One thing I did find,

I joined the telco in 1995 and the year 2K bug was a

really big issue. Being an IT kind of person, what's the year 2K plans. Ah, they said, we've been planning.

We held our first Y2K committee meeting in 1987. This is an industry that loves forward planning.

For them this is all just piece of cake, plan ahead, there we are. So let's just look at where we are with the plan. So let's look at the red line. The one that's meant to be coming up to 100 per cent any day now. The first thing I looked at was our web server at APNIC.

When I started looking back in 2004 when we still had lots of time, we were getting about 0.02 per cent of users were coming in on v6. We thought this is cool, we've got time. 20050.02 ^ per cent, 2006 as you see.

Nothing much happened for many, many years until around

2009 when the interest in v6 started to happen. By about a year ago, we're getting about one per cent of users coming through on v6. We felt pretty good about ourselves. This was happening.

Lorenzo has released some figures coming out of Google about the number of folk who visit Google using v6.

That's 0.25 per cent coming in on v6. Those two aren't the same, where did all these people go? Aha, the people who visit APNIC are loonies. They're running dual stack.

Because the great unwashed masses don't.

When I looked at the same set of tests as Google basically on a much larger site that is not techo, it's just mainstream website, I see the same in that green line down the bottom. The folk who come to me in v6 are

0.2 per cent. The line is flat. It's not up and to the right. I suppose you could feel good that it's not going down, but it's not moving.

Because I can play with these customers a bit, which is very nice of the website to let me I can also hand them a v6 only U RD so that even if they prefer v4, I can flush out the folk who are actually capable of doing v6 but prefer not to.

Now that's a higher number, that's 4 per cent of folks.

But it's not up and to the right. It's actually quite erratic. If you look harder actually it's higher on weekends than weekdays. It's still not very high.

So we were all meant to get this done before we ran out of v4. So I've been modelling when we really run out of v4. This is a model of about a week ago and life changes quickly. It was saying that about a 50 percent

probability APNIC was going to run out of addresses in

August.

When I do the same model today with a 70 per cent probability APNIC will run out in July. We are getting through addresses at a frightening rate inside this region.

The business is allocating and moving IP infrastructure faster than we've ever done before.

So let's just have a look at what the plan is now.

Because this is where we have to get to. From 0.2 per cent to 100 per cent, and if we want to avoid using that last address in this region you've got exactly four months.

So what have you got to do in four months, you know, for those of you taking notes, here's what you have to do.

Why are you all here? Go and do it.

Because you have to across a world of 2 billion users today, with at least a billion end hosts, I don't know how many router Cisco have SWALT, Juniper and Huiawei and all the rest of them, but they have sold a large number

and all the firewalls, middle ware ^ , all that accounting stuff, all that radius, everything has to change and you've only got one 20 days to do it.

Feeling good? Anyone still optimistic? I'm not either.

It's not feasible. That is not going to work. There is no way we can avoid hitting exhaustion. Just simply not.

So the real question before us is not can we scrape it through, can we avoid going over the cliff, you've off the cliff, you're now in free fall, what now?

This kind of led me to a few questions here. Normally large multi-billion dollars businesses almost the biggest enterprise that humanity created in the 20th century, normally they're not stupid. Normally we employ professionals, folk who know what they're doing.

Normally we understand the technology and the business we're in.

So how have we managed to stuff it up so enormously? How has an industry worth so much to national economics and indeed human well-being across this planet, managed to wedge itself so badly ?

So I don't think this is technology problem. I actually

think this is a business problem. So what can we learn?

A lot of what I keep on hearing is rosy-eyed optimism.

And when I start to question it they keep on telling me that we took on the entire telco industry 20 years ago and slammed it. The internet attained complete supremacy of communications inside of 10 years without any kind of business savvy. We can do it then; we can do it now.

That's the theory I keep on hearing.

So I started to think about this. Why did v4 work when v6 obviously hasn't? What's the difference here that is causing this to be a problem?

So let me do a quick digression into economies and the market supply and demand model. Hopefully some of you can remember this. You might correct me.

Basically if you make something more expensive, you'll probably buy less of it. And if you make it cheaper, you'll probably buy more. I know with me and capped data plans from my service provider, if they give me a few gigabits more per month for the same month, I'm just here. If they up the price on me, the bastards, I will use it less.

So like a natural consumer, if you up the price, I will consume less. If you reduce the price, I will consume more. All of you do it as well.

What about from the other side, from the ISP side?

Obviously they like to sell Rolls Royces not Hyundais.

Obviously they like the margin. You actually notice these days that no one actually advertises broadband any more. The only thing you see on advertisements are these things, iPhones and so on. This is where the margins are. This is where the price is. Obviously as price increases, suppliers want to supply more. So basically as price increases, incentivise right.

And in any natural competitive market, the theory goes and it's decent theory that between demand and supply you equilibriate ^ , the price comes down to a natural point where demand equals supply and everyone is happy -- yes?

This is cool.

So how do things change? What happens? Because what I wanted to look at was why and how did v4 take over the telco business? What happened in that shift from circuits to packets? Why was that such a natural that

loonies like me who knew nothing about business at the time were able to bring up an ISP and make money out of it bizarrely, probably you did too. What happened in that environment that made v4 so natural?

The first thing is that the architecture of IP itself compared to the circuit architecture of the telco was radically different. We were buying cheap crap from

Cisco, they were buying really expensive five V S S time switches from Bell Labs and it was costing them millions of bucks per card. Our supply costs went through the floor. We could build networks for a fraction of the cost of the telco, because in the IP model intelligence was not in the network. All the network had to do was flip the packet.

All of the business that the telco did with time switching was gone, and all of the cost went with it. So in that economic supply and demand curve, as an internet provider I could do largely what the telco was doing for much much lower cost. I was able to drop the supply cost curve radically.

But at the same time I was switching data not voice. All of a sudden computers could do more than just simply talk

down them. All of a sudden there was a whole new world of applications that the telephone network could only dream about. All of a sudden the demand curve would increase because users love this stuff, they brought this computer and without a network it was just an electronic typewriter, dull boring. All of a sudden it could do things like sex, drugs and rock and roll, demand increased. The combination was phenomenal. You didn't have to have a business plan, the business plan was there.

Moving data was 1,000 times cheaper using IP. The telcos had no chance. It didn't matter how lousy I was at business, that was always going to win inevitably.

So with v4 that whole switch fromcircuits to packets was a slam dunk, it just had to happen, the economies was there.

So all of a sudden an entire new market opened up. At the same time, I find that one of those remarkable coincidences of history because I think it was just serendipitous chance just walked into the room, all around the world regulators were going let's deregulate the telco, let's introduce competition into telephony.

All of a sudden, there was an exposed technical opportunity and a regulatory environment said yes, I too can be a carrier. I just choose not to switch time.

So all of a sudden new capital entered this market.

Private capital, agile capital, venture capital. Because all of the money, the telco used to make, and it made so much money, how many employees did AT&T have at its prime? About 600,000 I believe, BT in the UK I think

250,000. Even a tiny country like Australia had 100,000 people working for its telco. These were huge businesses and they made money by the mountain load. All of that money was at risk. And venture capital moved in and said

I want some and I'm going to have some, because I can do comes cheaper.

So that's what happened in the 1980s and early 1990s. It was the high ride of the venture capitalist. The telco was process bound. It was basically based around market constipation on steroids. New products in a telco took five YEERMS. To get something on to the billing system in a telco took a human lifetime. These guys couldn't react no matter what. So what actually happened? All of a sudden a new market got exposed that was fueled by high volatility venture capital, product every week, you're

all young, you lived through this, so did I, I can see all of you in that business. Some of you were right through there in the entrepreneurial sector making it happen. That's what fueled it.

What fueled it was this serendipitous combination of

1,000 times cheaper and deregulation.

But like all rides it always has to come to an end.

Because what happens in this business is that on the end when all is said and done we are a volume based business.

Supplying one person is fine, but I can supply a million people for a lot less than a million times the cost.

Like the silicon industry itself, the higher the volume, the lower the unit cost, dramatically so. As the market matured the residual money in the telco sector moved back. What we find now is that the entire entrepreneurial sector of this business has re treat today almost nothing.

When you actually look at ISPs today, there aren't a massive number of small entrepreneurial ISPs doing the bulk of the business, these are large scale folk who are the echoes of the old carriers and some of the more successful entrepreneurs, Verizon is a classic and in

every single country in the world you'll see the same thing that that old residual carrier business is actually now the bulk of the ISP business.

So if that was v4, will v6 do the same? Is it cheaper?

No. Is it better? No. What's the only differentiator?

We're running out of addresses. Have we run out today?

No. When are we going to run out? In the future.

There are 40 million people living in California, they're

Americans. They're relatively rich people. I assume they're all sensible people. The last massive earthquake was in 1906. That wasn't the big one, the bigger one was in 1857. It's highly likely there won't be an earthquake there tomorrow for these 40 million people, but it's incredibly likely there will be one within ten years.

Why are they there?

How well do you value future risk? Are you as good as

Californians? You are. Your estimate of the value of future risk is appallingly bad. So when you look at these in economic terms, you don't value risk. So now when I look at this demand supply curve and talk about the shift, not to v6, because you can't get from here to there, you have to go through dual stack. You have to go

through the corridor of pain. So let's do the demand schedule for the corridor of pain.

Will it get any cheaper? Get off the grass. This is two protocols. It is going to become more expensive. More expensive because you have to do work. Right, you actually have to change your infrastructure, build stuff out. It's not cheaper, it's more expensive on the supply side.

What about customers? It's IP, and they don't value future risk. They're Californians, right, they don't care about exhaustion. So as far as they're concerned the demand curve is unaltered. Their perception of value of dual stack is the same as the perception of value in v4. They're not going to pay you for this transition.

So what you're looking at is moving back up the red line.

Would any business naturally go there? Well let me phrase it another way. Has any business naturally gone there?

0.2 per cent. So the whole reason why this transition has been a failure is that there's been no natural market based incentive to get us there. We're not faster, we're not cheaper, and we don't value future risk. We're stuck.

So now we're tilely ^ at an impasse that that corridor of pain of dual stack is not somewhere where a competitive industry will go. It will sit there like a frog in hot water and be prepared to boil itself rather than go in. There's no natural market driver to propel them there. And you go hang on a sec, a bit like that earthquake, inevitability will happen. We are going to run out. At some point, your 0 per cent perception of future risk is going to become 100 per cent. A bit like when IANA ran out in February, you're all going to be surprised when APNIC shuts its doors and says: No more.

You're all going to go: I didn't know about that. It's going to happen, right? It is going to happen and you're going to be surprised.

So something has to break. We can't just sit there.

So let's look at this from a different angle. Every year at this point, around 250 new services come up on the net. The new users join the old users; yes? And at some point, we're going to find it hard to give address to those new users. Those new users really, really, really need v6 because, quite frankly, NATs are broken. You can't make stuff work when you haven't got enough

addresses. All the things you introduce, critical points of vulnerability, weird NAT-like behaviour, what you're going to do around port rationing, users would prefer not to see that. They have a need for v6. But everyone else already has an internet. Everyone else already has addresses. Everyone else, nothing changes. They don't need v6. The new folk need v6.

So needs are asymmetric. Who has to pay? Ah, if I'm going dual stack, I have to pay. In other words, the existing user base of 2 billion users at some point has to pay. 2 billion even times $1 is a lot of money and it's not $1. This is a very large internet. You've been working very hard for 20 years. The cost of putting in dual stack is huge, no matter which way you cut it. And that's going to be spent on the existing base of people.

The folk who don't value that work. That's hard.

So we're at a second impasse. The new users are the immediate beneficiaries, but the incremental value doesn't appear to outweigh the cost because the cost is applied to the existing base. Every day, we build a bigger v4 network. Every day, you're working extremely hard to make your future problem worse. God you're

Californians, aren't you? Are you building right on the

fault line? Exactly how close to disaster do you want to swing this, because you are going extremely close.

So how do we get past this impasse because, at some point, we have to break this. I don't think that every new user is the same. Because something happened around four years ago that was surprising to everybody, absolutely everybody. And it was the iPhone and the

Android. It was putting IP in the handset. That itself wasn't surprising. The fact that they were able to charge $50 a month for less than a gig of data on a network that was through the air was surprising. You guys pay extraordinary amounts of money for mobile -- much, much higher than it costs.

These folk are the richest folk on the planet and they need addresses. So if anyone is going to be a disproportionately valuable consumer, it's actually all those customers of mobiles. They have the highest revenue per user on today's planet. If they were v6 only, every major content provider on the planet would also be scrabbling to do V # services from their data centres because those folk spend money. Those folk have revenue. Those folk are the only folk that could possibly be a tipping point.

So that announcement by team mobile in the US was interesting. When you look again at those 250 million addresses that went out last year to the world in general, a massive amount went to the US, 44 million addresses. Even 9 million addresses went to Australia.

But hang on a second, Australia has about an 80 per cent connected rate. Every single person at home already has a connection. Why did a country of 17 million people need another 9 million addresses? The answer is in your pocket. It's these things. Those 9 million addresses, those 44 million addresses went to the highest revenue users. The forefront of growth, around about 50 to

60 per cent of the growth last year didn't go into the slums of broadband, they didn't go into that tyranny of commodity price, the sewerage of the internet, it actually went into the high rise apartments and the glitzy gold bathrooms of mobiles.

If anything is a demand point for v6 and a tipping point, it's actually that growth rate in the mobile market.

300 million units were retailed in the mobile smartphone network last year according to began eh ^ , very reputable.

So if any folk need v6 badly because these folk pay for service, it is going to be that. And maybe what's going on is actually a fundamental statement that money really does rule this world and that quite frankly whatever the mobile's market does dictates the terms of the entire internet that follows. Because the rest of the broadband internet doesn't make anywhere near the revenue per user that mobiles makes.

So if there is a tipping point maybe it's that. But hang on a sec, if you think these guys are nice, maybe you should think again. Because these guys already were experts in world gardens. When you look very closely at some of these devices you don't see an ethos of public networking and open end-to-end services throughout the device. Again I bring out the same device because it's a classic. Have you cracked your iPhone? I haven't. This is a hermetically sealed computer. It doesn't run anything. It only runs things that come from a single store -- where the owner and operator of that store demands a 30 percent margin. Where competition happens only on the terms defined by the controller of that market. Otherwise known as a monopoly, otherwise known as a closed world.

So that one world there isn't exactly the network that you were used to. By comparison the Android model is different. The Android model is based on a different philosophy. Which one is going to win ascendency?

Because quite frankly, where we are in v6 depends a lot on the answer to that question. Because if we go into walled private gardens we don't need v6. If mobiles don't need v6 the rest of the world can't afford v6 and we are in a very very bad place.

If mobiles do embrace open networking you can all breathe a big sigh of relief because basically the rest of the world will follow.

So why don't they just embrace v6 and move on? Why are we having this discussion? Why are we looking at the market in these terms? We're wedged. I'm really not sure how we unwedge ourselves, but we are wedged. Because cost and benefit aren't aligned. The folk who have to spend the money don't exactly get the benefit immediately. The folk who get the benefit don't need to spend all the money.

Who are you actually asking to build v6 in the

infrastructure? It's the carriers. It's the same folk who basically watched their revenue disappear out the door with the internet itself. They're now being asked to fund v6 with no revenue. I'm like can ^ you imagine why they look at this and go: No, we're not going to do that. We did it once and it failed, you know. You're asking us to spend all the money to make other folk make money. This doesn't exactly work.

So the carriers are very, very reluctant. What about the folk who if you will benefited from open networks, eBays,

Amazons, Googles of that world, surely they would be interested in open networks, surely an open network that allowed vibrancy of creativity would work for them?

Unfortunately, no. Because they're now incumbents. For them, one of the biggest risks is future competition.

Once you get big, you lose a huge amount of agility in the market. You lose the ability to react quickly to competition. You lose that essential element that actually gave you the edge in the first place.

So barriers to entry are actually part of a sensible business plan for incumbents. So why should they spend their money on open networking when they don't really need to?

What about users? Like I said before, you guys are all

Californians. You're living right on the fault line, you don't value it. You're not prepared to pay for it. So every single ISP that works like crazy to deliver you v6 you're not going to pay them. The ISP is doing this as a charity. And as a business concern using private capital, the word "charity" is not a natural word for those businesses. Because you, the consumer, aren't really reacting rationally in your long-term interests.

So where do we go from here? In my most depressing moments -- and I've had a few -- I really think that openness was perhaps a brief and wonderful moment, but it isn't an eternal condition that is natural. That folk naturally build fortresses and walls and their enterprise, they naturally construct barriers. In an open system that is embracing of competition and new entrants is not natural.

I kind of wonder here if this pendulum is swinging back.

I'd hate to think that it was. Because I loved the last ten years and I think you did too.

So if we really want to keep that, then quite frankly you

have no choice. There is no way around this other than open networking end-to-end. You have to do v6. But asking a deregulated competitive private market to act on charity is an extremely difficult ask. Almost impossible, but I'd like to think that it wasn't. But to actually address that requires a huge amount of creativity and common endeavour. I hope that we're all up to the challenge. Thank you.

APPLAUSE

Kenny Huang: Thank you. Geoff. Before I hand over to the floor, I need to declare, because I was told to convince Geoff to be more positive.

Geoff Huston: I was.

Kenny Huang: Unfortunately, I didn't do the job well.

Don't worry. We still have more competent speakers.

Any questions from the floor to Geoff Huston?

Mark Newton: Nark Newton Internode from Australia.

Geoff, your modelling of how difficult and expensive it

is to transition to IPv6 seems pretty sensitive to estimates you have made on the internal costs to an ISP or carrier for making the transition. Do you have any thoughts on how accurate those guesses are?

>>Geoff Huston: When I was working in the business, having the phone answered by someone who could speak competent tech was $50 to just answer that call. The margin on a broadband customer at the time was around about $20 per year net. And the cost of acquiring the customer was over $100, which meant that if they rang your help desk once you were losing. If they rang them three times, you might as well hang up. Literally, that's the tyranny of this business. It's really hard.

When you look at costs, it's not just the cost of the router, the cost of the this and that, it's actually the cost of the customer experience. And unfortunately with dual stack, you can get some really surprising outcomes that are not the customer's fault and not even the dual stack server's fault. It's the dual stack operation that makes the network behave in weird and aberrant ways that often are beyond what the customer can fix. Then they ring you. At that point, your costs escalate.

So when you think about costs, look at whole of business and the picture is not pleasant. Thank you.

New Speaker: Randy Bush I I J. Thanks, Geoff.

A couple of things, we did bite the bullet a long time ago. But luckily, since there's no IPv6 traffic, we don't have the support costs.

But back in the middle 1990s, the IPv6 ivory tower EE advantage lists were telling us that 3G PP was going to be the driver for IPv6 deployment and I hadn't heard that for many years. I just heard it again.

Geoff Huston: You did, yeah.

New Speaker: I am an Android user, I have my iPhone and I just think -- and I very much feel the difference between the open and the closed. And I wish to point to a movie that, strangely enough ISOC made about one of the possible internet futures is the tyranny of the lock-in devices. Thank you for tying that to the v6 issue. I don't think there's much of a way out. I'm cheered that

Androids are out selling iPhones.

Geoff Huston: Do you live in California?

New Speaker: No.^ Randy Bush

Geoff Huston: Ladies and gentlemen, what more do I need to say?

New Speaker: ^ Randy Bush I live in Tokyo!

LAUGHTER

Geoff Huston: There's this problem. You really do have a problem.

New Speaker: ^ Randy Bush before then, I lived on the big island of Hawaii. The problem is if you want to live some place beautiful and like mountains, how are they made? And if you like the front of the wave of innovation and change, there's a natural consequence of the people who want to hold the wave back and have the incumbents and so on and so forth. I don't see a clear way out of this trap, but we did deploy IPv6 in the 1990s. It wasn't dual stack because there were no vendors to supply it then. But we finally made it to dual stack in -- we ran two separate networks until 2002. The bean counters

don't know where the income comes from it, but it wasn't that horribly expensive.

And I don't know what your experience has been and how you explain it to your bean counters, but it's cheering to have a network in Australia that actually delivers

IPv6 and we'll see about IPv6 Day. At first, I said IPv6

Day, that was 1997 wasn't it? And then I realised that it's a forcing function. It's going to make my Mac operate properly. I don't think it's going to make Japan operate properly, we have a serious problem. But we'll clean up some messes.

Geoff Huston: Thank you.

New Speaker: ^ Geoff here. You mentioned business models, pricing and the failure thereof. My question to you is: Can we point the finger at the RIR model where supplying of IP addresses were based on need not on the question of price? Would it be the case that now we've got the last blocks allocated, it would be a thought to consider economic price in that model?

Geoff Huston: I'll have to speak here personally, because I really want to divorce myself from that

procedure and process when I answer you. But I was always of the view and I think I wrote it down in an RFC years ago, 1744, that the model of giving away addresses was crazed and that realistically, markets should exist even for that to express their value.

I admit I'm way out there in terms of my own view on that. But I did think, and still think, that had you been able to factor in scarcity pricing, you might have had a better reaction now, because the price of v4 addresses would be eye watering today, rather than what we are doing, which is creating a step function hiatus.

Because the current situation is we give away, give away, give away and then put in the market. And the problem with doing a hiatus in a trillion dollar industry is you can't predict what happens after you put hiatus on the track. You have no idea what direction the market is going to follow or the industry as soon as you put that impetus in their path.

So I think, yes, as a community, because the RIRs didn't invent this policy, the requires were a reflection of industry practice. This industry went straight into that path and said no, we don't want graduation of degree, we want to have a surprise. So we are going to have a

surprise. I question its wisdom as an individual. But nevertheless, that's what the industry wanted to do.

New Speaker: ^ Name right, again being membership based organisations responding to a natural monopoly.

Geoff Huston: More than membership, being an industry self-regulatory body. Because when we deregulated this industry we got rid of all this top down. We actually created the industry saying look, here are the instruments of networking, go figure. So the RIRs were an express as many other facets of the internet of the players and investors and stakeholders agreeing amongst themselves how they wanted to distribute this.

So I suppose it's hard to argue with in some ways that they didn't act rationally, I go back to my over point, future risk is bloody hard to value. I think the industry got that wrong.

New Speaker: I just want to point out, I don't think we were the only industry, I think the financial industry:

The value of the risk.

Geoff Huston: What financial crisis, sorry I must have

been speaking

Kenny Huang: We only allow one question. Make it very short.

Lorenzo Colitti: I think the financial industries was very successful. I think they achieved their objectives.

That was from that perspective well organised policy. I actually have a comment a question I'll sneak under that.

The Android which you -- I don't buy the argument on the

Android because the Android in the US: WHACHLT I'm saying

I think is that I think you're not being cynical enough.

I think that the --

LAUGHTER

Geoff Huston: I will try harder, but I will say other things. I was urged like crazy to be nice. I can try harder.

Lorenzo Colitti: My phone gets 26 dot address, I think it belongs to the UK Ministry of Defence or some such.

What I like to explore and we're very bad at evaluating future risks. It's possible, I'd like the financial industry, right, it's possible that the people making

decisions actually have an invested interest in the current system being closed, in which case it's probably history would teach us that it's just going to fail. So

I wonder if you would be willing to explore that and go further down that road. I don't have the background to do it, but I trust that you produce a very interesting insightful analysis for that.

Geoff Huston: I think the whole of this, when you open up a market into private investment and open up a market for competition then in essence the money does talk. And to distort that through regulatory imposition creates outcomes which are self-destructive. They either form into monopolies, or they become dysfunctional industries and just don't do the job.

So in many ways feeding and nurturing deregulated competitive markets is an art. It's an art that in this industry we've only been doing for 15 years. And to expect perfection is expecting a lot.

To give this industry the shock of its life in just 15 years after really deregulating is a tough one. We've certainly raised the degree of difficulty up to about

9.7, yes. But on the whole should this destroy your

faith in deregulation and private investment in the industry? No. I actually think this was the right thing to do. The internet would only here ^ because entrepreneurs and private investors went: Yes. I can do this and I can do this today. If you'd have waited for the telco to do this you'd still not even have a dial tone today.

Lorenzo Colitti: That's not what I meant. I'm not saying it was a failure of the model itself. I'm saying that you know maybe the NATs are going to work fine and the users -- no, I mean I know of -- only internet users

I know, my colleagues, they wouldn't notice. So maybe that's just the way it's going to go.

Geoff Huston: Cool. Thank you.

Kenny Huang: Thank you, Geoff. A small gift for you for promoting IPv4

LAUGHTER

Kenny Huang: The next speaker is Hiroshi Esaki.

Basically that's really easy for me to introduce this speaker, because they are famous in Asia. Hiroshi Esaki

is a professor, going to give a talk through collaboration activity to overcome IPv4 address exhaustion.

Hiroshi Esaki: Thank you. This particular slide is prepared for the APEC TEL meeting last October, actually.

Some slight modification from that. Also, I am not the businessman, so it is quite hard to discuss about economical issue for me.

I can skip this. This is a slide I shared during my serving of the board as trustee for the Internet Society.

Actually, this is basically we discussed during the workshop, the treatment among the board of trustees. We are aiming to the ecosystem toward the future internet perspective and also we realise at that time, that the real risk or fear of the internet is facing to fragmentation as we discussed, closed network, open network kind of thing. That is the real risk of the internet is the fragmentation.

Then we set the object and goal is avoiding the fragmentation using IP technologies and encourage the cooperation among systems and those making current cheap is eco structure using the ecosystem ^ structure truck

tour wide delivering the innovation. I think all of those are sharing among us, including Geoff I think, right.

Then as you know the Google and YouTube has been turned on IPv6 version about one year ago. Maybe then we can say that Sony is going to be introduce IPv6 in their own global corporate network. The reason of that action by the Sony is not by the introduction of IPv4 address, actually they succeeded to say yes to the CFO of Sony paying huge money. You can imagine their network is global. The introduction of IPv6 into the professional corporate network, I cannot say the exact number of the money, they succeeded. Why or how they pass the executives exceptionally CFOs was united Sony network, including subsidiaries as well as the partners, company like Sony Ericsson or Columbia Pictures, all of those want to be united.

They sell their own video conference system. That system never work in their private network, because of the many

NATs. That is the reason why they want to have very competitive global corporate network, so investment of that money is OK from the viewpoint of CC , if O.

I propose to the APEC TEL last October then I'm going to skip this since the time is very limited, also this is not the.... also I am not running as a chair of the program, we are introducing core specification of IPv6 as well as we are going to collaborate with the embedded system, specialist mark object. We have the MOU with the

IP SO, IP for smart object, they are looking for kind of smart test or smart VAD as I using 6... so that is one of the target or strategic corroboration with the IP version

6 form where they did the program and the IP SO people.

Also we are wondering about educational thing that is very important from the economical point of view for the capability building among the operators.

Also I propose to the APEC TEL, we may want to define common specification for criteria among APEC countries.

Many countries have their own proprietary nation specification, including Japan. Many telco like to specify their own proprietary technology, kind of reach enhancement to the nation specification. We hate right

^ , so in order to do that, we may be able to define kind of domestic specification that is aligned with global spec. So we're talking with many national domestic institute who is going to adapt global IP versions, programs like Japan or United States. We talk with N IS

T in the United States for example. Their specifications is based on the regulatory.

We announced or you know tell to the industry we should think about the exhaustion IP version 6 as kind of business opportunity. Also kind of risk management. The risk management is always hard to analyse when they are having a measure or act against such a risk as Geoff said, right? No disaster, no preparation, they don't want to pay any cents on the risk management right?

So we have to think about that, that is to send to the message of the executives in Japan.

The other interesting data from the Cisco system was in the United States, this is the who INTROE DUPSed IPv6 in their own network. Smaller company and larger company adopt IPv6 somehow some way. Interesting is energy segment is the largest one. That is smart community or

Smart Grid, smart betas. They think about IPv6.

Actually I long time talk with PACNET, they are specifying the A H back lights, control in the facility network. They finally adapt IP version 6. Since you can imagine in one of the big complex in downtown Tokyo a single facility has more than 200K sensor monitors in the

same building. You can imagine you want to control those lights using IP, using your iPhone or iPad, that is very very good to think about.

Also Geoff mentioned about the industry segment about telco. That GDP is about 10 percent of the whole of the

GG TP. The rest of the 10 percent relies on ISP. That is a new market we can is that right to think about applying the IP technology of the internet technology to innovate the industrial segment. One of the targets I'm really looking for is the construction industry as well as the developers, they are very interested about energy saving business.

So this one of the projects I'm running a the green IT, actually one of the questions in the afternoon, how the

IP version 6 rated with green. This is the actual how much energy consumption in 2005 regarding Japan.

One-third goes to the manufacturing. One-third goes to the energy generation and transportation, 40 per cent goes to the daily life, right?

So where you can get the money? You can think about.

Some people may think about Smart Grid is for the 30 percent energy generation transportation part, probably

no. Right?

For example my university is spending around $60 million US dollar per year only on electricity, $60 million USD on electricity. Right? What's going to happen when you save 20 per cent? That's the business model.

Also you can think about smart design compared with a human being. You have brain and nerves and organs. When your nerve system wrong, you'll never be able to live.

Once the brain is choked then you are almost gone, right?

So same thing. You can think about the data centre and servers or computer cluster is a kind of brain. You are going to connect those computers using internet, then effectively, control the lights and the facilities using

IP technologies.

Again going back to slide I showed at the very beginning, fragmentation is a risk over the community. When I carefully look at the industry of the construction companies they use appropriate tree technology of lights,

HVAC and the sensors, they used their own proprietary technology. Maybe they use the open technology because of the business model. They want to lock on the customers. Procurement procedure is almost closed based

on the technological lock in model.

So we can change that model. The other story I'm talking with talking with the Head Office is the strategic use of the data centre for smart city. I'm long time working with energy saving business in the environmental protection thing, I hate, right, the data centre always say it's evil. Using huge electricity, right, we're wasting a lot of CO2 emissions, that is usually you think about. That's not true.

When you have the hosting service your server or your PC move from your office to the data centre. The efficiency of the HVAC system is far better compared with the office. Your air-conditioning system in your office is about say 30 years old, not too bad. Once you change the

HVAC system to the latest one, you can save 40 per cent energy efficiency. When you have the just simple hosting, you can save energy.

How about virtualisation password cloud computing. You can depress the server itself to the latest one and also shrinking the dimensions. This is the data from the NTT.

Success to reduce 40 per cent energy. That is real story

I talking with in Tokyo. So Tokyo is one city who has a

very serious environmental measure. We have to cut

60 per cent every year of CO2 emission. It is almost impossible. Though when we use the data centre very strategically, we could reduce the carbon footprint, using ICT.

This is one story we talked with the government office, because of this they gave us the different exception about such an environmental protection role. They start to encourage ID C in order to reduce CO2 emissions in the

Tokyo. This is one of the examples how we are going to think about economical sense for that. Also since this slide is a little bit older version, we work with the

Chinese team about the facility network. Actually that is the standardised as 1888. That is the focusing on the facility network. That particular platform would be able to control the lights using iPad and iPhone. That is kind of framework to be able to accommodate back net,as a subsystem, so the backbone is basically based on the IP

XML. Data centric.

The other point of such a standardisation work was that industry never use IP, never been opened up their technology. Therefore those systems never be cooperated to each other. Stupidly the lights and H V and sensor

never be able to cooperate to each other before, right?

So in order to make those cooperation using open technologies we specify common specification while allowing subsystem be able to use propriety technologies, be able to interconnect those components or equipment to be able to more smart operation.

How about the cost? That is the most important thing you may challenge to me. Actually my building is 12 floors high. That is finishing in 2006, so it is five years old. My department decided to put the money to change whole of the control system and smart meter system. How much money we spend on those installation costs initially? It is million USD. How much power spending on that particular building? US$1 million per year on electricity. That is my office.

So actually that money is going to pay off around two years, less than three years. In order to do that, we talk with the industry, then most of the facilities system use the wired infrastructure. That's stupid.

Almost more than 50 percent budget goes to the wiring installation cost, right?

So I asked them it should be wireless. Using the GT P

for the licence band for the wireless, that is pretty good improvement for the type of investment we got in this particular business, as well as introduction of the open IP technologies in order to let cooperate to each other among those facility systems.

Yet another very interesting experience with the interest was the primary goal of the facility networking business was energy saving. But actually once we got information, all of the sensors then that infrastructure can be able to use the security management detection of the human being, you know, behaviour so as to include the cooperation among the different divisions, improvement of the line of the inefficient operations and the other applications that people start to think about. Even you can think about what -- the sensors and your fingertip it's going to be able to be connected. A wide variety of innovative application you can make it. Important thing was as I mentioned subsystem use proprietary technology as well as individual database. That's stupid, right?

So I asked them that data should be shared among the common database, then the application can be easily got those data from the common database. That is how we specify 1888. That is architecture kind of how

effectively share the data that originally separated.

Thank you.

APPLAUSE

Kenny Huang: Any questions or comments?

New Speaker: Thank you very much for your wonderful presentation. If I understand you correctly, is the killer app for IPv6 instead of ISP IPS which is internet power saving based on v6, would that be the next entrepreneurial opportunity as you said?

Hiroshi Esaki: That is just one of the examples. I work around the IP version 6 as you know. I'm looking for the area to be able to apply IPv6, then try to make a business model. The history has been started 2003, far before starting to talk about Smart Grid, right? At that time, I learned about how much money that each system spent on electricity. Based on that, I start to talk with the industry, how we can make a business model using

ICT. After that, Smart Grid comes. That's going to be more easier win.

New Speaker: My name is Luke, come from Taiwan. I just

want to ask first you said Sony tried to turn on the IPv6 and the IPv6 application. I want to know does Sony get any, for example, government funding, support, test discount or some training resource, does Japanese government do anything to help Sony or not?

Hiroshi Esaki: Sony hate government fund. That's answer, that's purely private investment.

Kenny Huang: OK. Thank you. There's a small gift for you.

APPLAUSE

Kenny Huang: Our next speaker is Ma Yan from Beijing

University. He's going to share some IPv6 construction and operation in CERNET2 member universities.

Ma Yan: It's my pleasure. I won't take much time because morning Prof Xing Li talked about CERNET. I will give different things to talk about.

First one, internet growth and requirement for IP addresses and the second one is CNGI. The second one is the traffic shakes ^ currently going on in CERNET to

member universities.

We are working in APRICOT-APAN meeting, so this is a joint meeting coming from, most people coming from Asia but also from area others, from Europe, Latin America, from Africa. So compare with other areas, you can see

Asia area is now according to the data by internet stats, internet user around world by geographical region, this is the last data, Asian people very populated and getting more and more on-line. So they require much addresses.

Not only in China, but also Indonesia, India, those big populated areas. We learned a lot during the last few years.

Just like Vint Cerf this morning talk about starting from

North America, now it's for everyone. So Asian people really enjoy this technology and are using this one very intensively.

The second chart shows we're still way behind by average.

30 percent penetration rate compared to other areas in

North America, Western Europe, they have very much penetrated. So they have sufficient IP address, IPv4 addresses and high population using those technologies.

So we have a big room to improve, to improve the lives

and the children in rural areas.

So generally speaking, Africa area and Asia area will have a very least developing economies and even for

China, most people visit Beijing, Shanghai those big cities, these are very kind of developed, so not difference between Hong Kong and Beijing and Shanghai.

But you go to western part side, you can see big difference, big diverse.

So I think our people, your people need to improve their lives. They need to get connected and using the opportunity provided by the internet doing business and learning and playing around. So I think this one really need a lot of IP addresses.

The mobile subscribers you can see also around the world so many penetration rate have been increased and that during the last few years. The fixed line growth are relatively slowly compared to the fast growing mobiles.

The mobile also needs, as Geoff mentioned also, those T mobile and those other mobile service providers, they are using v4 is currently. If they didn't deploy v6 then there would be a kind of big hinder to develop those new technologies. So how do convince those decision-makers,

not only government, but also those privately run companies, all those public owned companies to use this technology. So this is also their decision and also our responsibility to demonstrate the power of this new technology. It's really not new, but it's very powerful, very nice technology for the benefit, not only for the company but also for our users, our subscribers of our communities. I think this is also our task.

As a university lecturer professor, we have the responsibility to risk our next generation students really aware of these technologies. They need end-to-end, they need the free-flow of information and they need penetration and they need information and they are doing every kind of daily life rely on technology, on the IPv6 especially.

This is a chart, 3G getting more and more, by Morgan

Stanley they have data showing next year 2012 maybe according it their data aggregated desktop computer and notebook computer, all together, less than the cellular phone, the smartphone, those kind of mobile intelligent mobile phone sets, including iPhone, Android, those kind of operating systems supporting the mobile devices.

So those kind of mobiles need IP, need telecommunication, need new business models. This is really one big issue for us. Birth rate of broadband is still keep growing, but rather slowly compared to the mobile subscribers.

Go back to mainland China, we can see according to the latest data we have something point 4 billion users, now the number one community on the internet and more and more people using mobile phones. Those data released twice a year, so we can still keep seeing the trend of the world growing, get more and more penetrated, more and more people are using internet.

One of my colleagues living just 200 kilometres southwest of Beijing, 2,000 kilometres, but within their city, less than 30 percent penetration rate. So you see we have still a very big room to improve and get more people connected using internet.

The new data is 34 per cent penetration rate. It's just a little bit above the global internet penetration rate.

So we really have -- due to infrastructure and economic conditions really those kind of people expect more and more facility being built, more and more internet be available to their villages.

So just last week, just like Google, around the world, people using search engine in the Mandarin community were using Baidu, another search engine company.

I answer one of the questions posed on the website. It says if I'm away from a centre I'm in the rural areas, there is no fixed line, 3G is not available. How can I get on-line? Get internet? So those kind of questions really posed on the internet considering to get educated, their amusement, they are doing business and they let information be flow from family members. those kind of things we really have to do harder to promoting this technologies. So we have a big diversity and more IP address needed, not IPv4 but we have no way to escape

IPv6. We have to work close on this one. Also it means opportunities.

So doing so as a university engineer or the people working in university, we educating people, no technologies, starting in 1994 we're building our first internet services, more universities now became in China can use the internet. But industry have different thinking, just as Geoff says, it's a close work out, the dominant force, if they didn't move, then the small

company, the small entrepreneurs, they have less opportunity to create their opportunity to explore the new market. So also in during the new time, Geoff also talked to Hong Kong, one of the people working in

Hong Kong Government. How to let the government make policy of pave the way to facilitate new competitors, new ways to building the new things and create new opportunities. This is a government role. For our universities professor and engineer we have to educate our people, let more creating challenge and opportunity for them and let them aware about the new technologies.

If they -- telecommunication industry, I talk those kind of topics China Telecom, China Mobile, Unicom, those big service providers in China, they complain that their revenue drop dramatically, and last year, now in

February, last year Guangdong Province is one of the developing province, they said their income internet data income already surpass more than half the income from internet business. Less than half coming from the traditional voice call income.

But they still think about what kind of advancement should they pay, how to improve their services by making more money and IPv6 would be their solution to really

making more profitable product or not. They are still debating quite intensive inside their corporation.

They think about preparing the new technology, and for example in China we have China Telecom, China Mobile,

Unicom, those three big proprietors. Only China Telecom apply for big bundle of IPv6 address space. Other two still lag behind. They are really in a very controversial status debating internally how to make real deployment when with the best time to deploy this technology. They also kind of discussing with the government about it. With the government say something, make a mandate or whatever, what should I do, or it's our decision to make this improvement. So they really, there are heavy discussions inside.

So in this way, as a university people, professors and workers we really have very intensive interaction with them to show them that when and how to deploy those kind of things. So operation not only -- I'm operating a

1-gig CERNET, so I will show some of the data in our gig, the traffic and applications. Our successful story, I will show them they can do the same thing. Although they are kind of some differences, for example accounting system is really very critical for them, but not quite

critical for us. So we have some difference. But accounting goal should be the same and operation issue, most operational issue should be the same.

So I will show you those kind of things. CNGI most of you have know we will run part of CNGI, China Next

Generation Internet Project. We already have six, seven years past, more and more people know about this project and this is a government funded project. CERNET educational part of the internet China, we are the major task force to perform this project and educate the people, develop the software applications and test that and cooperation with the manufacturers, domestic and overseas manufacturers do a lot of testing, a lot of experiment.

Today is the 22nd. Yesterday in China -- I didn't translate into English text, but just yesterday Central

Government set up one decision regulatory says Central

Government will promote IPv6 in the industry yesterday.

So this is also not a signal triggering more and more people aware about these things and in the next five year round more and more people will really practise and really promote, really doing things in this direction in the next generation internet. So this is another good

topic, good signal.

The traffic report from 6NOC, we called it our CNGI

CERNET2 operating centre for 6NOC. More than 200 universities, something around 300 are building their

IPv6 enabled cam us network. This more than 200, 260 something, only 100 universities get sponsorship from government, they get some amount of money to purchase

IPv6 enabled routers, equipment and servers. But more than half of universities they pay themselves. They upgrade their devices. They upgrade their campuses.

This is another chart to show you the backbone node distribution. So my university is contributed a lot in the total IPv traffic, so my university is BUPT. Keep the top one since last two or three years already. So we're really doing very intensive to promoting the technology and trial technology and helping the industry both manufacture and operation operators including China

Mobile, China Telecom, because my professor, my classmate and also my students work in the industry. So we have a lot of close connection with them to show them how those technologies really can benefit.

Some others from the backbone, this is my university G.

Talk about application, so you see main applications. So we're building the website and the video streaming, even this one is quite interesting, it's a central music institute. They perform collaborate with Canadian musician, a group of people working in Canada, another group of people working in Beijing. So they share the network by using IPv6. Their name, the music name is called v4 v6. They're really not the human composer tone, but it's extracted from a dynamic packet loss and time delay. So there is no regular terms, it's just random, but quite unique. They're using v4, v6 streaming over the network. They try these kind of things in 2009.

We're also building a platform for those professors invited speakers, scientists visit every university. So just in my university, like other universities, every week have a lot of speakers. We let every speaker talk be real-time stream over the networks. Other university can see my university professor talk. Also my university student can see other university talk. So this really trigger a lot of traffic. Also TV streaming, stream a lot of TV channels into the network so generate a lot of traffic.

In our applications and P2P file sharing, multi-cast, virtual reality, cloud computing a lot of applications.

Daily traffic come to 5 gig already. If we have more other high bandwidth equipment so we can really come to something tangible.

These are the visitors distribution from all of China, so many universities distribute their video streamings into their student dormitories and laboratories, those are the data status. Also the user distribution.

Also we developed network management system to monitor the interfaces, because for operation issue, really adding more headaches. Originally we only target IPv4 problems, but this time when people complain about network troubles, we had to identify which one is caused by v4, which one is caused by v6, so they're really adding more working load to those operators. So we developed a system to try to identify where is the problem, minimise the working load of the operations.

Those were the monitor of the servers and those kind of switches, the backbone and the exit networks.

So as operation process, some more and more efforts have been evolved maintaining two routing tables, and also

adding ACL control list be updated, dual stacked servers, network problem identify which one it's coming from.

Mis-configure DNS, network devices, client may also cause server side problems, network side problems, lots of different level trainings, not only the end-user training but also operator training, developers training and the decision-making training and the different level of training has been conducted. So future works and more and more work to be done, taking actions and keeping eye closely on security issues. Until now something over

2 million users already using v6, but not much were severe incident to be reported. But anyway we had to really keep an eye very closely on the issue to be developed in the future. More and more people then more and more issues. Different level of training, porting and developing applications, accounting system to be developed, migration technology research and deployment, collaboration and also tomorrow we have another future internet forum discussion, so another advertisement, so everyone welcome to join us tomorrow for Asia forum discussion. Thank you.

APPLAUSE

Kenny Huang: Thank you, professor.

Any questions? OK.

There's a small gift to you.

I will be the last one. Seems like I only have ten minutes. Luckily, my slide doesn't cover any technology at all, so there's no fancy rocket science inside to inspire you. Basically, the presentation is not for complete idiots either, because basically it's for government policy maker, government service network providers to make a decision.

I need to go back about ten years ago because I didn't give you the context you probably will misunderstand what

I'm trying to say. About ten years ago basically Taiwan government is quite aggressively to promote IPv6 either to establish IPv6 research or even establish IPv6 events infrastructure. Whenever we say go away take a residual fund, do it, take your own risk. But eventually one day as a government why don't you deploy your IPv6 within your government network? The answer I was given is Kenny you are about -- the government infrastructure are classified, it's not for your playground. So that's what

I get.

Anyway, I try to answer the question it's a really stupid question but really down to the earth I was given by the government.

For example like we tried to promote IPv6 to the government internally working. The three major questions comes out. The first question, on the issue basically it's enough for transition to IPv6. The issue is the

IPv4 exhaustion. The government asked for any policy recommendations, any recommendation after IPv4 exhaustion. So we need to generate all sort of options.

And one of the criterion is... IPv6, so talking any other visible option beyond IPv6. Second we propose IPv6 to the government the second question we ask, is that good timing, can we wait for another three years to be realised in the market then we take it, we don't want to be the first to the market we want to be the follower.

It's fine to the government to be a follower.

The third question is, last dumb question but very difficult to answer, you keep saying upgrade to IPv6, how much budget you need? Because all the government budget basically was fiscal year you need to prepare budget one year behind into operation, so what's your budget to

running into the transition?

OK, so very dumb question. I try to answer one by one.

Starting from the option or solution for IPv4 exhaustion.

The precondition is government want IPv6 excluded, so what's the solution, visible solution you know CGN, increase capex and also reduce network quality because your dilution to use an IP address block. Second solution transfer IPv4 approval, that's also doable, that's based on the cost. Cost 1 is cost of IPv4 owner

I. Cost number 2 is re-numbering cost. Cost number 3, remark one excluded, IPv6 although government is saying please do not continue solution with IPv6 as you need to remark. IPv6 will be the only practical and readily resourced IPv4 exhaustion, so I need to remark this point.

OK, we still need to separate different implication between public sector and private sector because I think there should be totally different considerations for these two contingencies. Initially indication to private sector, solution 1 or 2, even solution 3 like professor proposed, or solution 4 anyone, and basically they are all visible solutions to private sector. The corporate can choose any solution based on his own requirement and

his urgencies. So consideration from private sector. So we need to go back to the implication to public sector.

Beyond solution 1, solution 2 or even solution 3, the public sector has to provide a visible mechanism for a remark IPv6 exclusion issues. Public sector consider

IPv6 deployments is necessary but not sufficient requirement, because when you go back to answer the government officer, they are in Taiwan, the Taiwan internet basically is quite highly saturated, almost 17,

18 per cent saturated. Government have a huge IPv4 block you ask them to transfer to IPv6, they have any reason to transition.

So when they say IPv4 exhaustion they say even deploy

IPv6 cannot solve the issue come from IPv4 exhaustion, that's true. So in addition to deploy IPv6 public sector also need to choose solution one and 2 based on its own requirement. So deploy IPv6 will be necessary but not sufficient requirement to the public sector.

OK, come to the second part. Is it good timing? Can we do it next year? Or three years later? Sure. Initially the all driving force comes from IPv4 exhaustion, it's going to be exhausted some time in June this year. So

IPv6 is only practical and ready resources .

Also second time is reference to what the other government do at this moment, and so far we have several government already have IPv6 plan like it's been reported to China Government and Hong Kong Government, US

Government and Australia Government, they all have transition plan. So based on the reference we can have consider to recommend government it's good timing. But it's not good enough, we need to provide a scientific approach.

Go back to the timing table chart, we go back to the upper left-hand side. That was generated by Geoff

Huston, just go to him. Up right-hand side will be monthly ratio. Based on this chart you can, assuming he says IPv6, assuming that's the price in the stock market.

That means if you buy the stock in year 2004 and selling the stock in year 2008 you are losing money, because anything just remained as it is, it was sorry.

But right now we see the monthly curve it keep going up, for technology adoption many people for left-hand side, in the downside left-hand side there's a technology adoption curve. Most of advanced technology they only worry one thing, in the initial booming of the technology

going fast but for certain stay there is a huge gap technology will just vanish so we just need to guess whether IPv6 will be allocated in the left-hand side or right-hand side green area or red area. If you guess

IPv6 in the red area wrong choice, IPv6 in the green area make a good choice. So based on that we provide some potential growth for the future IPv6 to the government.

Second, we need to have a good compelling reason why government much deploy IPv6. OK, based on current forecast, based on the curve. The IPv6 deployment next year will be the global penetration will be reached to near 5 per cent. Pure v6 population near 3 per cent.

Based on the prediction reverse to what situation Taiwan has today, that means we almost have half million users deploy pure IPv6 on the end of next year based on the forecast.

So means the half million subscribers cannot access current internet today, cannot access government information website, cannot use any government information services.

So initial activation time we suggest issue a position statement in supporting IFGS deployment now, so hopefully

they are in the process of doing that, so hopefully next few weeks we can see that.

Second criterion is cost. Last criterion is cost. OK you keep saying upgrade to v6 give me a number. But the cost is really difficult because the cost variable for

IPv6 deployment you have a lot of variables, such as one time of phase deployment what's your coverage you want to cover 100 per cent government infrastructure, how long are you going to do it, 10, 20 years, will be cost difference. And the government officer only care the most is in the records, training security and service qualities.

The basic Taiwan market versus IPv6 allocation last quarter, the data was international trade bureau.

Eventually governments want us to provide a precise number. OK, I can only answer we don't have a general liability because IPv6 readiness vary, that varies among government agencies. Those transition costs are different. So initially we will do some sort of consultation starting to do the government survey to see how ready the governments are ready to transit to IPv6.

Sorry transit to IPv6, I should say transit to IPv4 plus v6.

Second financial risk. I don't have a precise financial measurement on hand, I must be honest. But if I measure risk can be limit acceptable range through sizing and scoping IPv6 deployment, it depends on how you're going to scope your range. The other financial risk such as security a lot of people is there any mature product provide a firewall service. OK. There is a risk. We must admit there is a risk. Apply the same guideline to manage financial risk such as ISOC standing, 27,000 series ... try to manage the risk within an acceptable range. I didn't say there is no risk, there is a risk.

OK, because I am giving the document to technology guru so I need to make it pretty dumb. We predict there is no capacity expansion in DNS so just go ahead. For web capacity roughly you can basically you need to enable

IPv6 and also you can for the expansion you can calculate based on existing AAA capacity times, 3 per cent to 5 per cent based on reasonable forecast.

Connection you can access to IPv6 network if you have a connection, otherwise you can deploy the collocation in v6 daily centre. For network capacity initially that would be IPv6 enabled, that activate in the router.

Probably if IVI is mature enough we can deploy IVI as well. Expansion and existing bandwidth time three to

5 per cent based on a reasonable forecast.

Transit we don't have IPv6 transit yet so we need to purchase IPv6 transit. For pairing we need to deploy there switch for IPv6 Public Internet Exchange initially because right now tower Internet Exchange was managed by incumbent operator. But based on the new opportunity we try to refresh this and everything start from scratch, so v6 should start from scratch, deploy internet public exchange at this moment, with a different location with a new organisation to run it.

OK. How about coverage. I list the priority matrix from left-hand side to right-hand side. The top left-hand side is external service because our audience would be subscriber. So external service including web DNS and

IPv6 Internet Exchange. We need to scope how many node we're going to deploy. We need to define the deployment criteria because there are 100 million web servers, how many of them are going to be deployed. We need to design a mechanism to have a tier deployment.

The second phase in the middle is connectivity expansion,

that expands to different access. Also the last one would be internal use for all IPv6 users. That would be not very useful right now.

We need to go back to the risk, several risk has already been mentioned in several material already. The issue including v6 v4 fall-back. We need to clearly tell government that's a potential risk you're going to have.

There's a way to prevent it if you take it seriously.

There is a DNS query . The other thing is on TCP issue.

The IP protocol was defined, the current version of IP protocol was defined... operation standard basically come after that. We don't have for IPv6 combined with IPv4 coexist transition, we need this kind of operational experience. So it's this kind of operational experience take time to create a standard.

The last one will be a cost on management for long-term overlapping period. Naturally you have server interface, that could be potentially trouble. Every action has a price. You pick up one decision you cannot say you don't have any liability. Definitely have liability inside providing you can estimate the liability precisely.

The perceived gain we can make pure IPv6 user

requirement. There is great potential this, one is not compelling enough. Including mobile internet, something like internet things going to happen but tell your children government ^ don't buy it. Anything regarding to the market it can wait until market realise.

The third one, the perceived gain like financial risk, the cost of deployment, probably very small if you are scoping enough. Financial risk like service quality as issue risk, ROEFRJS to the issue list. The other cost is most important is future management cost.

Value assessment. For external service the necessity will be a must because we need to find a reason. The have been not good enough, we need to find a legal reason. OK, you need to comply with Telecommunication

Act for example in Taiwan we have Telecommunication Act in section 20, universal access right to our citizen.

Telecommunication Act section 21 fair connection service, section 22, undeniable interconnection. So not already well-defined in the Telecommunication Act so we make and resist offer to the government .

Proposed schedule, T0 should be proposed right now, government need to make a position statement right away,

so you're probably going to see that very soon. I will let you know. Ta means we deploy external service, we recommend from T0 to additional two years. What's my reason because based on the budget plan, so it's two year, working time should be good enough. Enough for full coverage.

For Tb, T0 plus four years, reference the other country policies. Tc will be T0 plus four years. There's a condition for Tc because Tc is not mandatory.

Once you understand the liability you understand your perceived gain and you decide you want to go and take your own risk, welcome. IPv6 is not plug and play you need to understand why is it mandatory, is your infrastructure ready, do you have transit, do you have pairing ^ peering? with the private sector, what's your addressing plan.

The other issue I mention, you need to think post transition strategy first because most people discuss transition strategy but the transition only take about say 24 hours. But you need to live with the port transition probably 10 to 20 years. So you need to reverse. You think what happened in the post TLAN

significance. Can you accept this kind of working environment for next 10 or 20 years if you think that's

OK, we just go ahead. So we need to emphasise the overlapping period between v6 and v4 in the next 10 or 20 years. So I say we are not transition significanceing ^ to IPv6, basically we are transitioning to IPv4 plus 6.

It's not pure environment not a greenfield.

Next step even you decide you want to go there are several models to see how deeply you're going to be involved, going to be engaged, you can do full assessment, so that's a theory for IT maturity model depends on how deeply you want to engage your ambition.

The choice belong to the government.

Taiwan is going to have an organisational reform, so we need to propose a full restructure, to the new department for infrastructure going to be reformed accordingly, so that the basic structure tells the story. That's easy, transition model how to do assessment, structure and architecture. That's the basic inventory assessment.

So I need to cover what sort of function will be required for this kind of transition and post transition management.... for administration we're going to create

a new department called IPv6 transition office. For procurement we have public construction Commissioner.

They will take care of all the IPv 4to6 equipment. For policy making we have technology and advisory group going to take policy making. For development he we have all kind of agencies, they need to deploy IPv6 proposed plan.

Also basically we have technology support.

The other affiliate strategic policy recommendation for policy development like political return, what can be the political return like policy making, that's pa policy making return. And also we have something like a risk management. What happens the risk management plan for example like IPv4 exhaustion. In the right-hand side consultancy unit service, how you improve constitute unit value. We have IPv6 certification program, and we also have technology transfer group trying to help all the government agencies to pass the transition period.

That's pretty much of it. Value assessment you can download from the website.

So basically today I only cover what government network going to do in the proposed plan. Also we have another sector working on the private sector, how to encourage

ISP or private sector to transit to IPv4 plus v6. We have text credit to ISP to encourage use a tax return to deploy their advanced infrastructure. So that's another program we are working on. And due to the transition for all the public sector transition to IPv6 plus v4, eventually we can foreseeable a new Public Internet

Exchange will be born in Taiwan, and also due to the procurement by the PCC procurement, public construction

Commissioner, they were starting to do the procurement plan based on the requirement. So probably we can see the procurement drive new innovation based on the requirement.

That's pretty much my presentation. Thank you for your questions.

New Speaker: I'm the President of. ^ : Thank you for such a wonderful presentation. Two which can parameters.

One, on one hand, there's complete lack of awareness within the governments in the region per se on legal and policy issues pertaining to IPv6 and the transition.

Number 2, we also find that there is an existing vacuum, some IRs in a state of denial vis-a-vis trading of... what are the legal policy issues pertaining to this

sector that are being addressed at a government level, is there some initiatives being done. Thank you.

Kenny Huang: Quick answer. The first question is has been in practice a long time ago in the wrong direction.

Right now we try to do it in a different direction so everything was starting from 0 secretary, it's going to be issued very soon. Regarding to any transition within the IR you can attend the workshop there will be more discussion.

Randy Bush: Thanks, Ken. It seems to me as if you're going through a lot of structuring and layer 9 effort to make it so the incumbent can be successful. While at the same time you very well said something that ties back to

Geoff's presentation, is that in fact it's the upstart

ISPs which have deployed IPv6. It's interesting that it's the upstart ISP in Australia who's deployed IPv6 and

Telstra does nothing. When we sit in Japan -- the amusing situation, the best one, though, is Japan. Where the upstart ISPs do it, NTT is so bad that everybody is about to do a horrible hack to shield NTT from IPv6 Day.

And yet NTT in America, where it's an upstart, has had

IPv6 for five or seven years.

So maybe what we should be doing instead of saving the incumbents is rewarding the up starts.

Kenny Huang: Thank you. If I give the wrong impression, I'm sorry.

Lorenzo Colitti: It seems to me one of the motivational, let's see, one of the reasons for actually doing anything was the v6 only users. I'm worried that such a strategy is dangerous because I don't believe there will only be any v6 users at all ever, until v4 is gone. So I'm wondering if such a justification, we have to do v6 because there will be v6 only users or there'll be v6 only content will come around and boomerang and hit you the head when somebody discovers that it actually doesn't happen.

Kenny Huang: I agree.

Lorenzo Colitti: I'd be very cautious before actually using such an argument.

Kenny Huang: I'm just hereto all kind of structures have been proposed several times, but it's been rejected by the government. That wasn't the only one we accept so

far.

Lorenzo Colitti: I'm just trying to, if we use such a strategy internally, somebody would have seen through it.

Kenny Huang: Thank you for your comment.

New Speaker: Considering the application for addresses among the regions , could we think of a fair policy or whatever that can pair the cost of transition among the regions, like applying a policy to retain IPv4 addresses from the most revenue generating ISPs, or by region whatever, so we have an equal or more fair transition policy to IPv6. Why is that? Because the routers I'm applying today or yesterday I'm not going to upgrade to them to IPv6 in the whole countries. In the five or six or maybe ten years, you know. So can't we come up with a fair policy by the IRs or whatever.

Kenny Huang: I think they are doing that in IP in policy stake. Sorry, regarding to IR policy, we belong to the policy stake is not my territory.

New Speaker: To return maybe the question to APNIC, some

IPv4 addresses from the IANA from wherever OK allocate to

this region.

Geoff Huston: As I said in response to an earlier question, the RIRs host a policy. That policy is actually comprised of regional stakeholders, including

ISPs, public entities and others with an interest in address policy. APNIC hosts the discussion; it doesn't set the rules. What you're looking at is industry self-regulation in practice.

So if you have a good idea convince your peers, convince other players who have also invested in this market and are investing in a future market and convince them as to the merits of your idea as compared to other ideas.

That's the best answer I can offer, because that's the process of a deregulated large scale industry at work.

New Speaker: What would be if all the RIRs after implementation of IPv4 .

Geoff Huston: The role of IPv4s is two-fold. One is to allocate resources on the basis of policies determined by that regional community. Secondly, and equally importantly, is a registry. Because an address is just an integer it's just a number, have two, have 10, who

cares. What makes it so useful in the context of a network is its uniqueness. That nobody else is using that address. The uniqueness registry is what APNIC runs. In the same way that other bodies run registries of land, registries of other things that are uniquely associated with a controller or owner.

So in APNIC's case we run a registry and we allocate according to regional policies. When the IPv4 addresses no longer allocated by APNIC, you really, really want that registry. Because we're the only folk who are holding that registry that says those addresses are yours, and those addresses aren't. That registry doesn't exist, you've got a really big problem.

New Speaker: Sorry, but my point is.

Kenny Huang: Can I allow only the very last question?

New Speaker: The thing is this region mainly the content is either hosted in North American ISP providers or the traffic is -- they are the most consumed to IPv4 today, you know. So isn't it unfair to -- for them they will get the IPv6 more and the ISPs they will bring more business on IPv6, compared to the poor ISPs in the region

here which they will bear high cost to, they are developing countries, high cost for the IPv6 implementation and transition, while they are not gaining

RIR in a shorter time compared to others. Isn't this not make sense.

Kenny Huang: Because of the time constraint I can consider your comment, but we need to adjourn this section right now. And if you have any further questions you are welcome after the session you can come to the floor and ask a speaker here is that OK

New Speaker: All right. Thank you.

Kenny Huang: Thank you very much for attending this section of the conference and I'm happy to adjourn the meeting. Thank you, if you have a question please come to the floor. After the session we have MOU to sign belong to Japan IPv6 Council and Indonesia IPv6 forum.

Hiroshi Esaki: You guys are the witness of the sign.

Signing ceremony.

Tony Hill: Just for those who have stuck with us on the

streaming and those in the room, I think you've seen IPv6 the debate now from all sides, but one thing's quite clear, that there will be an IPv6 Day on 8 June this year when major content providers get together and I think that will put the onus on a lot of service providers to consider their position in relation to that. So that was one of my big take away messages from the day.

A message of support from the IPv6 forum comes from Latif

Ladid whose name was on the program. He deeply apologises because of some travel problems he couldn't make it to be with us today. But he does congratulate the joint hosts of this fantastic session in Hong Kong,

DotAsia and ISOC Hong Kong, as well as the organisations involved, APAN, IPv6.World.Asia, APNIC and for getting together to hold this session.

I think the level of interest we've had during the day has been fantastic. Latif says good morning from

Luxembourg because he's in a completely different time zone. He wishes he could have been with us today.

Attracting some of the great contributors on time just after IANA's announcement of the move to IPv6 being vital for the internet. He wishes to thank the leadership of the IPv6 Task Force and myself and Miwa, I want to convey

my thanks to Miwa for organising such a fantastic program.

APPLAUSE

Tony Hill: Particularly for organising this critical venue to discuss the way forward for v6 deployment in the largest internet region in the world by which he means

Asia. Consider for the moment internet as a worldwide garden where IPv4 was the seeds and fruit to feed a few lucky ones. IPv6 is the new seed to be used as fertiliser for current plants to grow bigger, and a new seed for new kinds of fruits we have not cultivated yet.

To make this happen everyone needs to be an IPv6 activist and pioneer to plant these seeds in its place and collectively with OERPS. This is the moment to demonstrate your talent and leadership he says to everybody. A French proverb confirms reality saying that talent always skips one generation. The recent events in the Arab region demonstrate that a new generation kids are mortal lented even than the older ones using internet tools to take their nations to the next level. Challenge your talent and make a difference by planting IPv6 seeds and being part of this undertakeing that will for sure keep progressing and changeing the world into a greater

world for all, cheers Latif. Thank you very much for staying with us. With that we can now change the day's events.

APPLAUSE

• ^ Top
• < Home