APRICOT 2010 APNIC 29 Banner

Transcript: APNIC Plenary

Disclaimer

Due to the difficulties capturing a live speaker's words, it is possible this transcript may contain errors and mistranslations. APNIC accepts no liability for any event or action resulting from the transcripts.

0900 - 1030 (UTC+8) Thursday 4 March 2010

SRINIVAS CHENDI: Good morning ladies and gentlemen. Let's wait five more minutes and we'll start the session. Thanks for your patience.

OK, I think we'll start the session. First of all, I would like to thank you all for being here this morning so early, even though we had a fantastic night last night sponsored by Hurricane Electric and Google. The social event. Just a reminder that the ITU, IPv6 comments are welcomed until tomorrow, 5 pm ?KL time. So if you have any comments about the session that we had yesterday afternoon, please write to IPv6 at APNIC.net. A reminder for those approaching the microphones, please speak clearly and your name and affiliation. Otherwise, if you were' speaking individually, please just say your name so the captioners can get it and so that the remote participants are. I would like to invite Martin J Levy who is the chair.

There's Matthew Moyle-Croft. Srinivas Gudipudi. Lawrence Hughes and Lorenzo Colitti and Muhammad Kamal Zahiri. So Martin, please.

MARTIN LEVY: Good morning. We have a whole bunch of different talks this morning which range over, I think the appropriate balance of v6 subjects. And the thing that I want to talk about, even before hand and just do as a simple introduction is one important stat you'll mind. Let me mind the appropriate file here.

My simple view of the IPv6 world in 2010. It's not based on numbers. It's not the detailed stats that we'll hear from other speakers. It's not based on an extensive, an expensive study done by some large body in the world. It's simply a point of view. And it's a point of view that has substance in this session. Because we're going to hear different talks. We're going to hear about broadband deployment. Not from a point of view of - this is how we will do it, but this is how we have done it. We're going to hear about applications in the real world that can take advantage of IPv6 and have that work under way. We're going to talk about applications from the commercial world and products that are specifically based upon the value that IPv6 brings to the market place.

We're going to hear about content that's available in IPv6 that has made a marked difference on the popular press's perception in the v6 world. And we're going to hear about the transition world. What it takes to look at something at a large scale and do a transition. Now, this is a pretty good set of subjects to cover. Unlike other, either the tutorials that sometimes can get very detailed, or the talks that can sometimes deal with policy, what we're dealing with here is the real world aspects of IPv6 in 2010.

There are a bunch of us that would say, I wish we were further. But let's look at this graph. Highly scientifically generated graph! And it's very simple. The shape of the graph is not important, but the direction is. And we can all turn around and say, "Yeah, I can relate to that graph." "Oh, I want to adjust it somewhat?" That's not what I want you to do. I just want you to accept it. And I know it is very early in the morning for me to say this, but in a warm, happy feeling of acceptance. And just say, "OK, that's good." That's the only thing I'm presenting on my side. I'm going to introduce the rest of the talks for today. But I just want you to think about what you're hearing today and realize that this is all coming from the real world, that we've moved past some of the theoretical things.

I'm not discounting the work that's still being done at the standards bodies like IETF. And absolutely not discounting the great work that's done at a technical tutorial to bring more IPv6 networks up and running. But what we're going to hear about today as I said is some real world stuff. Let's start, Matthew Moyle-Croft at Intermode in Australia is going to talk about their broadband experience. And I'm actually going to just mention one thing about what they did. They got the popular press to understand what they were doing, and this, again, moves it away from the technical community into the real world. Gets it to the eyeballs and the attention of various corporate entities. So, from that point of view, that I think we should all be very interested in the story from the inside as to what they did and how we can take that back to our respective companies.

Matthew.

MATTHEW MOYLE-CROFT: So, that leads, I guess, nicely into what I have to say. It's probably a bit relevant to say who we are. We're an ISP and technology company that's been around since 1991, so we've been in this game for a while. In Australia we're the fifth-largest broadband company. That makes us big in Australia and really small worldwide. So, you know, don't necessarily discount anything you do on a larger scale. We are an infrastructure owner. We build our own international network, which is very useful for what we're doing here, and we're a technology leader in our market. We're a privately owned company, and the guy who owns us is a techno geek, like I guess the rest of the engineers in the networking site like me. If you use your favorite search engine to have a look at Internet toaster interop, you'll find him having built an SNP-controlled toaster in the early '90s.

So we have a guy like that who owns us, who is our sole shareholder, who allows us to do these things. And in fact, more than allow us, he says, well, get on with it.

So IPv6, when we started, one of the problems in Australia is buying IPv6 transit. At the end of the day, you've got to connect to someone else. It's the Internet. so we had a network, that at the time, we had POP in LA and we were told to pretty much get on with the dual stack thing, and we started. And yeah, October to February, it's a little while. But we're not talking about a major project. There were a couple of us who started, OK, we'll anticipate turn on some transit and turn on peering command and OK, yeah, we've got it to the edge in the US and we've got a server there and we can ping things. And then we started moving backwards all the way across our domestic network, all the way to Perth. So, that took us a couple of months. And it wasn't a big project.

I guess, our network isn't as big as some people's. But once you get the hang of it, you can do quite a bit more in the change window.

Meantime, we dual stacked some customers, so it was actual traffic. So those were some of the first v6 customers in Australia. Because at the time, no-one else had a national dual stack network. We put it on our content servers. Obviously like a lot of other people in the Asia Pacific region, there's a lot of cost to get outside of your country, and sometimes inside your own country is very expensive. So we have a lot of mirror servers, so we mirror various Linux distributions and patches and we put v6 on those, which was a pretty easy experience. You put a v6 address and people start using it. Sometimes very unexpectedly. There were some unexpected results, we found. People assumed it was v4 and wondered why it was going via some tunnel broker in the US.

Then, 2008, we built a POP in Tokyo to take use of one of the submarine cables out of Australia and made that dual stack from day one, it's easy. A couple of lines in the configure and away you go.

So, the edge. It's harder. The core and transit stuff, the core networks are pretty much sorted. Lots of people were doing v6 in various ways on many of different platforms for a long time. That's pretty easy. Our experience was that we only had to upgrade a couple routers on older servers. It wasn't a hard thing to do. But the edge thing is hard. When you start touching customers, it's harder. I don't want to get you despondent at this point, but it is just harder. So, we had a Hexago Tunnel Broker, which is one of these appliances that allows to have a client fire up tunnels and everything, basically to give customers a way of doing it without having to change our production edge. So we did that and we put in a 6to4 gateway as well. That's pretty easy. And then time passes, all within a year.

And the rest of it, we were trying to work out what we were doing. Luckily, Simon gave us a bit of a kick along and gave us a deadline, and that's a good thing. And so, we started last year, a broadband trial. And we did it in a very simple way. Our production LNSs are fairly large things and they don't support v6 at the moment. We're working on that with our provider, but we just multihopped on to another set of older LNSs that do it just fine, and we released it as a trial. And you know, people start to sign up, and you get a lot of experience. I recommend trials like this. You know, if you have to turn everything into a product from day one, it's a bit hard. This way, we did the absolute minimum we could to make it work, and that included trying to get in between our billing system and our radius system to be able to insert v6 records without having to change the billing system, and a whole range of stuff.

But you know, we've got real customers and we're learning a lot from them. And I think the important thing about a trial and about doing this stuff is that it shows you're doing it. I think the other thing, which I really need to get on with this slide, is the last two points which is how the broadband side of things, "how" a v6 dual stack broadband service works, has been, up until recently, quite fluid. Everybody goes, well, there's some RFCs and some people from TNT wrote some a while ago and the broadband forum was talking about all sorts of options and it is recently with prefix delegation and so on, become a lot more stable. Everyone is starting to go, this is what we're going to do. And sometimes, that experience and customer experience with this stuff is really important.

I think the important thing about that is that with the customers, you can't buy CPE, some are running small Cisco 800 routers which do v6 just beautifully, except they're a little out of reach. We've got very sophisticated customers who have these things at home so they can dual stack themselves in a matter of minutes.

So the lessons we've learnt. I would suggest you start. Don't just talk about starting, start. Because it's actually not that hard, and if you keep talking about it, you're going to convince yourself it's really hard. And when you need to do it, you're going to convince yourself it's really, really hard and you're not going to get on with it. It becomes easier. IPv6 for us, dual stack is just business as usual. We rolled out a new set for the customers so they could do business as usual and we just dual stacked them. We didn't need to. We didn't have IPv6 customers but there's a well known address on our server now that you can use with v6. But you know, it's exercised other things.

And I've been told by a few people at APNIC that we're a fair chunk of their v6 queries in Australia, because our servers are v6, their servers are v6, that's preferred. So suddenly, our v6 traffic has gone up because of it.

I think the other really important thing is credibility with suppliers. When you talk about it, "I'm going to do v6 sometime soon.", They go, "Yeah, so are we. What do you want? We've got a plan. Can't show you the plan yet, it's commercial and confident." Blah, blah, blah. When you go to the supplier and say, your v6 here does not work. Where is the v6 for this, this, this, and this. And they it go, ah, you've got a lot of credibility. You can push them fairly hard. We're lucky with our major vendor that we have a good account team, and that's been very useful, but we've been able to push our vendor quite hard to admit that they had no plan in certain areas and to actually come up with a plan and to actually prioritize this stuff and not just to talk about it.

The other thing that this trial has allowed us to do, which I think is very, very important is, we've actually got CPE manufacturers using the trial. We had one send us a bit of CPE. Something you can buy easily in Australia for around AU$80, which is average for a thing with wireless and Ethernet and so on. And they said that they are v6 coded. And we said, "Yeah, OK". Because a lot of them say that, but you know what, these guys had actually been working. We plugged it in, turned it on and it still had the log-in to the trial. And we plugged it in, and you know what, it worked! And it was a bit of a hallelujah moment for us. Somebody sent us something that worked with v6 that I could deploy in a customer's house. So I think the future, and I can go back to Martin's graph, is actually looking pretty bright.

People are actually starting to buy into this and we're actually starting to see things happen. I'm very positive for this year about v6 for small and medium enterprise. People are starting to cough up CPE. The vendor has actually got working code for doing dual stack on the large LNSs. So it's all working.

The other thing that's really important is, don't stop or fail to start because of a single road block. You know, there are road blocks. There are servers that don't do v6. Ours doesn't at the moment, but you know what, we didn't stop. Because if you stop, then you might as well not have started, and if you didn't start, you're going down a bad place. But with the v6 side of things, we've really used that to beat up on the vendor a fair bit and go, "Well, where is it? You said it would be there. Why is it slipping, you said in public in the marketing stuff that v6 is important." So you get to convince them that they're doing the wrong thing pretty well.

That's pretty much it for me. But look, the only things you really need to start this is a v6 allocation from an RIR and some dual stack transit. And I know that dual stack transit is tricky. Certainly in our part of the world down here. But you know what, it's becoming less tricky. And if you can get it or you can start beating up on your transit supplier to supply it, then you're going to start moving and it doesn't matter that you move slowly. It means that when you actually have to move quickly, you've already got experience. You've already started. You've already got credibility with your vendors. The other thing that you need is the will to do it. We're very lucky, we have a shareholder who gives us the will! But, you know, sometimes it is harder for people.

I think if you concentrate on it as, "How can I make money out of it?" I think you're going to fail. I think the important thing is, "If I don't do v6, how will I make money in the future if I don't sign up more customers?" Thank you.

APPLAUSE

MARTIN LEVY: If there's any questions, we have time in between each talk. But I want to actually ask one simple question that I talked about in the introduction. How much feedback did you get from new customer base after you did your quite well covered IPv6 announcement a few months ago?

MATTHEW MOYLE-CROFT: um, it's actually been pretty good. The reason being is that people are actually out there quite interestingly playing the v6. They're the people who run corporate networks and government networks and a lot of them can't get access to v6. And we've had a lot of people who might have a DSL service at work for testing and so on. And a lot of them have moved that across to us to run dual stack, to get experience with it. We set up an e-mail alias too, for people who are using the trial, and that goes to me and a few other fairly senior people in our organization. And the good thing about that is, the e-mail addresses you see coming through the companies say, "We're trialing this at work and we've got a problem, and can you make a suggestion? " It's pretty good. And as a company who sells stuff to corporates who is now getting credibility in the dual stack space, it's a pretty good thing, really. So as a marketing exercise, you know, maybe coming back to the previous thing, if you get in first, first mover advantage in your region, you know, you might have a bit of a success on your hands. Especially in our region where a lot of people are, a lot of governments are putting a lot of money behind v6. You might find that that is a very good thing to align your direction with doing some v6 to government policy. It might allow you to talk to government officials, ministers you wouldn't otherwise. Corporate customers that you wouldn't otherwise talk to. And it's a good thing. You know, in Australia, there's a lot of tenders that come out for government and so on, connections that require dual stack.

And it was always a bit of a, ah yeah, whatever, dual stack. Yes, we've got a policy and we'll have dual stack. But if you actually have dual stack and you're selling transit and so on to government and corporates who require it, suddenly you're ahead.

MARTIN LEVY: OK. Any questions? Then we'll move on, thank you very much.

APPLAUSE

I was going to interrupt Matthew because I had a personal issue that was not v6 related. Anyone got an iPhone charger? I forgot mine! Oh, there's one on the stage!

Srinivas is joining us to talk about IPv6 from the rural healthcare point of view. And there's a lot of really interesting points about this, because if you really want to talk about real world issues, health is about as real world as it gets. And so, as you listen to this, you'll see where there is a solid place for IPv6 and a credit that needs to go back to the mind set from even writing the specs and all the early work of getting IPv6 into the early world. And now we're going to see how that has a benefit in this case, in India, of course. Srinivas.

SRINIVAS GUDIPUDI: Hi, everybody. So, over the next few minutes, I'm going to share with you a few thoughts about the IPv6-based emergency rural healthcare.

If you see the slide, there are two graphs. The graph on the left-hand side, basically on the Y axis we have the number of disasters. And on the X axis, the number of years. And if you look at this graph, the number of disasters have kept on increasing year on year and the graph on the right-hand side basically shows on the X axis, the economic impact and on the X axis, the years. Can we do something to prevent these things from happening? The tsunamis, the cyclones? Maybe, maybe not.

But can we do something to stop the economic disasters, the economic disaster in 2008 happened to around 80 billion. Can we do anything to limit it? Maybe if we can sense it and reach the site of the disaster at the earliest, maybe we can do something and if you do something in that direction, we need a few enablers, and those enablers would be technology enablers and that could be tech information technology. If you look at the keep blocks of the information technology that we would need, it would be, one, to sense the disaster. The second part would be a communication infrastructure that would help the information sensed about the disaster being conveyed to the central surveillance center or the observation center.

And then the intelligent part of the other location information so that we can understand better the impact of the disaster and have help reaching the right places and also being able to reach the sites that were impacted earliest.

In the last two slides, we saw that, one, there are disasters. There's an economic impact of it. In order to contain the economic impact, we need information technology. Now, one piece of technology that we possibly can have help us ease and make the responsible part of it more efficient could be IPv6. And why would that be? In the real world, we basically have a few elements of senses, that is that we can smell, touch, feel and basically, if you're to really look at this, to be connected to the cyber world, we would basically look up at sensors, and basically, if you look up at sensors in the cyber world, IPv6 happens to be one unique protocol that strikes to being from the communication protocol for the service providers to the radius networks where we have v6 low band being the protocol for communication for these senses.

So IPv6 happens to be the one unique thread of communication right from the networks to your actual entire service provider network. And therefore, we're able to connect the real world to the cyber world. And the other aspect is whenever a disaster happens and you have teams reaching, basically the site of the emergency or the disaster, they would basically set up the medical equipment and the communication equipment. The technical support infrastructure. The moment you reach that particular place, what you would like to do is that you would like to be able to get that equipment up, have it connected, and then you would like to work across. And in order to do that over the v4, you would have to configure IP addresses and all types of routing and other things being brought into the place and making things happen.

But if you're to use v6, you have the auto-configuration that helps you to get the network connectivity and the addressing part of it into place so that you can get your infrastructure up at the earliest and you can serve the particular emergencies or the disasters there. And the other part of it, in case when you have health-related support happening on the field, and you basically have from the field, the communication, the radius health aspects being connected, either through the biosensors or the hospital access, for the communication to be secure. And that particular part is addressed by the fact that we have some of the security aspects being brought up into the IPv6.

And the next part over there being that we have seamless crew mobility coming up through the IPv6. Because when we have patients on the field being taken up through the ambulances and we have IPv6 infrastructure into the ambulances, and when we move across the regions or the zones, we would like to have seamless connectivity without it being dropped down, and IPv6 brings in that seamless connectivity. And then, the other part of it that we have, support for a real time transport. In the sense that we have jumbo grams which help in real time transport and the flow level part of it. Yes, a few standards need to be put in place about that, but still, it would help in basically having the real time transport for the radio being provided accordingly.

So I think, basically these particular features help in basically providing a more efficient technology for the emergency or the disaster management and helps ease the challenges there.

As I just mentioned, that sensors happen to be that particular piece that connect the real world to the cyber world. I think to help us with the sensory elements. Touch, feel being connected up and IPv6 through the low pan part of it happens through the one single element connecting everything, and that gives us seamless information access to every small piece of the nitty-gritty and the details. In this particular section, I'll show you the broad area of emergency or disaster management and how it is working.

Basically, we would have emergencies or the disaster of the various types. Either they could be natural or any of those cyclones or tsunamis. Or they could be originating because of terrorism or they could be biological in nature in terms of the season or others. Or there could be transport-related incidents. And when we have the emergencies or the disasters, we would want them to be sensed and then basically we would like to have a communication infrastructure so that we can have appropriate communication going across to the place where the incident has happened and the support is being provided. And the communication infrastructure needs to be robust and reliable and providing all of the features that we require in terms of a secure environment, connectivity, mobility and others.

And this can be provided up by an IPv6 enabled communication infrastructure. And this communication infrastructure could come from any place, be it the government, the public, the private, where you have the broadband, cellular, 3G. Any of the communications mediums making it happen. And when we have the emergencies or the disasters, the IPv6-enabled infrastructure and the related technologies being put into place, we would be able to put in place an efficient crisis management center where in we have the medicine, the intelligent transport or other aspects being handled and managed in a better way.

The slide shows basically our emergency or disaster management system implemented across a city, and the key stakeholders over there would be one, yourself. The second part is your home and office. The factories, the schools, the governments. All of these happen to be the key stakeholders over there. And what happens when we have an emergency or a disaster? First we need to sense it. It could be that we have the sensors placed in a building and we could have the earthquake or the fire sensed there. And the emergency response team happens to reach there faster. And the second part of it, we could have an intelligent transport. So that when you're going on a highway, and the speed goes beyond a certain limit. Based on the speed limits over there, the speeds could be tempered or it is a rainy environment, the sensors could sense that and temper your vehicle speed.

Or telemedicine, at the places where healthcare is not immediately within reach, you could have the technology providing that for the individual to basically be provided the required medical healthcare by being connected to the hospital or the medical care facilities.

In this section, I'll give a brief overview of the rural healthcare scenario in India and how it is that this particular, what was the solution that we put in place? Or we are working on putting up this particular solution in place.

The background, over there being that in India, most of the rural areas are located far from the cities and that would result in the fact that if you're to look at any of the premium healthcare facilities, it would take a bit of time, where you would have to travel across a distance to get access to them. And the second aspect over there is that the number of hospitals or the primary healthcare centers in the rural areas are few. And even if they're present, the medical personnel over there, the doctors or the nurses are fewer, because most of the doctors or the nurses prefer to practice in the cities because that's where more opportunities lie. So we have a scenario where in the rural areas, we have a lack of the required medical healthcare facilities.

And in this scenario, we have the national rural health mission being launched and one of the key aspects of this particular health mission to succeed is to provide an optimal rural medical emergency healthcare. The rural emergency healthcare in India is provided by the Emergency Management Services Institute. This was a subsidy of Tech Mahindra. And Tech Mahindra and the software and the technology for the emergency management, we do it for free, entirely for free, as a corporate social responsibility. And basically, the services run up across both the rural areas and in the cities.

Let's just have a brief glimpse of how exactly current rural healthcare runs up across in India. Whenever we have a patient or an emergency happening at any place, we would have one of the near or dear ones call up the number, 108. And what happens is the person at the call center picks up the call and asks for the location. And then the person at the call center, he tries to locate the nearest ambulance, which he has basically noted down the current ambulance location on his current sheet, or the piece of paper. And what he then does is, if the driver knows that particular location, of where the incident has happened, he would basically use his own abilities or his knowledge of that location to drive down there and be able to find the location. Or else, the person from the call center guides this person in the ambulance to reach that particular location. And once the ambulance reaches the patient, he's basically into the ambulance and the person from the call center again guides him up on the fine to the nearest hospital. And when the person is into the ambulance, the emergency technician up over there, he calls the call center where he's connect today a doctor and he tells the condition of the patient. And this basically has a limitation because the emergency technician is not a qualified medical professional where he can basically give all of the appropriate information. And also, the information shared across is limited to the perception or the knowledge of the emergency technician, and the doctor over there has to be basically providing guidance to the emergency technician to manage the patient while he's being moved to the nearest hospital to the amount of information that's available to him by phone. And there could be scenarios where basically, things could go very wrong, or there could be scenarios where things could be managed. But we have a challenge over there in the sense that first we have to get the ambulance to the place of incident the fastest and then we have to be able to provide the best care to the patient where the doctor gets continuous visibility into the patient's continue and then manage the scene there in.

In order to basically resolve this challenge, we basically thought of enabling the technology enabling the ambulances, so we brought up the IPv6-enabled devices where we have got biosensors. We have got vital statistics gathering units. We have got video conference units and then all of the communication infrastructure therein. And because of this particular aspect, we now have the scenario where, as soon as the emergency call center gets a request for be serviced, immediately we have the driver basically going down up over there being able to vied himself through the GPRS-related enablement. And the second aspect is that as soon as the patient is into the ambulance, he's basically connected to all the equipment from the biosensors and everything, and what happens is that in case the patient is having a heart attack, the doctor is able to see through the ECG that OK, he's having a heart attack and he has the technician administering him the medication.

Or if the patient is unconscious, he's still able to monitor the vital statistics and guide him as to how the patient should be managed. And in case the patient is conscious, the same still happens. And the other aspect over there is that in case of accident victims, the doctor gets the opportunity to see him through the eyes of the patient and be able to guide the related emergency healthcare. And all of this basically happens up to the fact that we have got some of the key features of the IPv6 helping us over there, and also the communication backbone over there providing the required technology being conveyed up to the central command at the surveillance center. And basically, the eventual vision is that we have the three parts of the emergency healthcare that is the sense, reach and the healthcare being brought up to the optimal levels. Where in a sense it could not just be a phone call, it could be through an SMS, an e-mail or any other means that we could have a an emergency requested. And then, care being provided with the emergency healthcare therein. And basically, we have EMRI serving 12 States and we have currently about 100 lines a day. And towards the end, I would like to say that if you were ever to get into a situation where you needed any of this emergency healthcare, but if any one of your near and dear ones happened to have that. If you had this particular technology, and possibly it was v6-enabled, you probably would have had a better chance and a provision of providing the emergency healthcare. So, with that note, I would like to sign off. But I would like to thank a few people who basically provided support.

Hemanth Dattatreya from IPv6 forum. He's been a tremendous support. And R.M. Agarwal from the Department of Telecom. And BK Nath was helping. And thanks to Srinivas Chendi and APNIC for providing a lot of help over here. Thank you.

APPLAUSE

MARTIN LEVY: The... I was going to ask you a very simple question, which is, not said from a critical point of view, but, so the IPv6 side of this? We all know that if we were really pushed to it, we wouldn't need to worry about certain new technologies, but there are certain things that you've been doing That do make a difference because of IPv6. And can you talk a little bit about the value of IPv6 from a technology point of view, or can you also talk about the value of, again, the thing that I talked about earlier. The visibility of using IPv6, because it's brought you a lot more interest out of other places in India?

SRINIVAS GUDIPUDI: As I mentioned probably in one of the starting slides, the aspect that really makes it, the IPv6 as a preferred choice up over there, was a seamless connectivity to get the information. For example, sensors, typically run on many of the other industrial protocols like ZigBee and others. With IPv4, we didn't have the chance to get in there with IPv6 LOPANS, we were able to basically have the information, the entire network from sensors to the entire infrastructure. Everything connected to one single thread of IPv6. And that's unique, because it's not just a band protocol, everything running on one single protocol up over there. And the other aspect of it was the auto-configuration because in ambulances, you have basically technicians who are completely networking. They're basically just general users and you would basically like to have them basically being able to use the entire equipment or basically the infrastructure in the most simplest manner. And so, if there was anything, if they were required to set up that particular infrastructure through any part of the networking part, or even if they were to bring small equipment into the particular system by connecting up, connecting it up into the environment, you would basically like them to do it in the simplest or the easiest manner and the auto-configuration part of it helped over there. And the other features therein, one thing that I would like to say is that in the security part of it, yes, we can still do the security through the normal software, but the fact that the protocol eased it and made it happen in a better and a simpler way helped many things. It's not that IPv4 can not make happen all of the things that I just mentioned, but probably, IPv6 makes it happen better and easier. And I think that's what is critical when you're in a situation of emergency. That you should not worry about the networking infrastructure or basically how you will get connected, but probably focus more on the emergencies. So thank you to all of those who basically made a few features into IPv6. But it has definitely helped in this scenario.

MARTIN LEVY: Thank you very much. OK, Lawrence Hughes. We're going to deal with a different point of view now. The items that are needed, the hardware, the products that are needed to solve some of the nitty-gritty problems in the IPv6 world and I'm happy to introduce Lawrence to talk about InfoWeapons.

LAWRENCE HUGHES: A site I've put up and you can go to is us1.v6 home.org and it was running in my home with full dual stack. The IPv4 service from my ISP to my home was so poor, I had to move it in to my office ISP. It was running for about a month in my home. If I had a better ISP where I am now in the Philippines, it would still be there. Basically, I've got three email addresses on here. One is my legacy address at InfoWeapons. The other two are dual stack. One is running on Microsoft Exchange server 2007 on top of Windows server 2008. The other is an open source type server. Basically, this is an example of what you could do at home with existing technology, within a couple of years, anybody will be able to do it with off-the-shelf units. This is also kind of a do it yourself kit. This is everything you need to bring up a dual stack email server I encourage you to go ahead and do so.

And using all free open source tools and so on.

Basically, once you bring up a dual stack network, what next? It's not rocket science anymore with the existing operating systems mostly supporting IPv6 and a lot of applications already have been imported in to it like Apache and so on. So, basically, once you've got it up and you've surfed and watched the total dance and a few things like that, what do you do next? Most people bring up a web server and that's nice. Really, for the most part, there's not that much you can do with a web server with IPv6 that you can't do over IPv4, so it's not that exciting. It's interesting to know you can get it at over IPv6. The next thing that occurs to people is email. And if you're doing web mail, you basically get it for free, once you've got your web server running. The more interesting part is SMTPPOP and iMap.

This is going to discuss that. Both open source mail servers do support IPv6 but it takes a little bit of digging to find the actual configuration necessary to make it work. I've done that digging for you. Exchange Server 2007 says it supports IPv6. When I started to deploy it at home, basically I started searching on the Internet and every reference to Exchange Server 2007 and IPv6 was a discussion of how to turn IPv6 off. Apparently, sometimes it confuses people and if they don't actually have an IPv6 network, it's not really that much of an advantage. But let me tell you, if you do actually have a real IPv6 network going, it works and there's almost nothing to it.

Anyway, basically, why would you want to use email over IPv6? The big win is you can do client access from anywhere that you've got IPv6 connectivity. These days, with things like Googlenet and Tunnel Service, you can typically get IPv6 service wherever you are f you have IPv4 to tunnel it over. When I'm on the road I can access my mail server over IPv6 and it works beautifully, without having to have tons of expensive and very scarce IPv4 real addresses.

If you are going to be doing this in an organization, you are typically going to have at least one IPv4 mail server to exchange mail with the legacy world, as I like to call it. But typically there may be many internal servers that don't necessarily need to exchange mail from the outside world but you might need POP and inetnum retrievals. And IPv6 is dual stack and you're home free and people can access their mail on any server in your organization without having to tie up lots of IPv4 addresses.

OK, basically, some day there's going to be mail servers and networks that are IPv6 only. You would want your mail server to be dual stack so you can talk to both of them, of course. OK, I'm going to skip over Exchange Server 2007. Let me reassure you it does, in fact, work and it's not particularly difficult if you are deploying it in a real dual stack network. It basically works. Microsoft has done a beautiful job on supporting IPv6. My kudos to them.

OK, as far as open source, you can pretty much choose any open source operating system these days to run it on and that's an original alert. I don't want to go in to FreeBSD and Linux and so on. Most of the open source operating systems have now been certified IPv6 Ready Gold. I happen to choose FreeBSD and on SMTP MTA, they will work. I happen to like Postfix. Again, on the retrieval servers, all of them support IPv6. Dovecot and Cyrus and so on. purplehat.org shows you how to put together a really sophisticated open source email server using FreeBSD plus Postfix plus Dovecot and Squirrelmail. If you want to do this, go to the organization, print out the thing, deploy as much of it as you want and follow my instructions.

Basically, one of the things to watch out for when you're deploying open source dual stack software is make sure that the underlying operating system supports it. There's a few changes you need to make that I've documented in here as far as giving it a real IPv6 address. Of course being a mail server, you want it to be a static address and publish it in DNS and so on. There's an IPv6 option you would need to check in the configure screens. Check that, obviously.

Once you've put it together, you should use something like Tillnet and connect to port to verify that it's working. If you have already got your dual stack DNS up and running, you can use domain names. Otherwise type those long, hard-to-remember IPv6 addresses. I have examples of those later.

If you want to make it secure, that's completely independent of IPv6. That will run over for TLS over IPv6, go ahead. Basically, in your gateway firewall, it's quite easy to allow IPv6 incoming traffic to go through a hole to an inside server. You don't have to worry about setting up the missing problem, BINAT and the ARP problem. It's much easier to expose ports on internal servers through an IPv6 firewall than it is an IPv4, there's no net to worry about. You can wrap your own firewall using FreeBSD and pf. I use the InfoWeapons SolidWall product. There are very elaborate extensions. It includes V6 and port tunnelling and you can get service from Martin's Hurricane Electric to get yourself service through that product.

These are basically configuration screens for how you would actually assign IPv6 addresses in FreeBSD, set up the ETC host file, tell it where its DNS servers are in both IPv4 and IPv6. There are things in Linux you can use as well or in a number of books. For Postfix and Dovecot they're hard to find. In PostFix, there's a main.cf file. There's no real IPv6-specific items in the master.files. The one line you need to know in the main.cf is a command most people have never seen which is inetnum under bar protocols and set it to IPv4 or IPv6. And it means the same as the previous. So I said inetnum protocols equal all; he will listen to both IPv4 and IPv6 connections. You can add in some new things to the 'my networks' line. Watch out, the IPv6 stuff has to be in square brackets because the passing mechanism gets confused by the colons.

In Dovecot, there's one thing you have to add in--a less than equal asterix. Add in a comma, left square bracket, right square bracket. It tells it to listen over IPv6. That was a lot of fun to find. OK, we're not going to go too much also tine how you would open holes in a PF firewall. This gives you an idea of how it would work. I have defined email ports here and basically passed in inetnum proto. It allows the incoming port to. And it allows the IPv6 protocols. The DNS records get to be a little more interesting. Some of you have deployed email before. You may understand you not only have to let people know what the address of your email server is, you have to tell them what's the preferred email server for your domain and you typically have to provide a reverse DNS record. This is getting a little more obscure but you have to do it in IPv6 also.

There are mail servers out there who attempt to get rid of some spam by checking reverse DNS look-up to make sure you are who you claim to be. If you're not, they assume you're a spammer and reject the connection. If you want to exchange mail with anyone, it would be to provide a reverse record. In IPv6, that's a little more interesting. But anyway, these are the DNS records that would work with BIND. They are generated with my Solid DNS which is an appliance using BIND. You can view the BIND configuration files. I've printed them out for you. We have basically the US1 has both an A and a quad A record and those are the real addresses. You can actually check them. But, they're published on a pair of servers at our facility in Atlanta which has direct IPv6 service from NTT America. Those are visible from all over the world.

The whole thing is actually very easily connected to.

On the DNS, you need to register your name servers to the DNS Top Level Domain. That's a bit of a trick. One of the things I recommend is you use a domain from godaddy.com. Many like register.com got hopelessly confused when I asked them to do it. I went to go-daddy.com and had it done in five minutes. Not all registrars understand how to link it to the route. Highly recommended to do that. You will need to publish the IPv4 and IPv6 addresses at your mail servers. If anybody wants to do that, feel free to get in touch with me. I'll be glad to publish your records for you. Just send an email to one of those email addresses there at the beginning and ask me and I'll be glad to publish those for you. I'll need to host the domain you do, so don't use your main domain.

And I'll be glad to host it.

Again, there's the information on the reverse DNS look-up. That's trickier with IPv6. You need to get your ISP to delegate those ISP addresses to manage and set up the reverse PTR records for them. Or you might be able to talk your ISP in to doing the reverse record publishing themselves. Again, with some ISPs, good luck with that, but it can be done.

But basically if you have a DNS appliance that's fully dual stack, that will simplify the creation and management of both the necessarily IPv4 and IPv6 resource records in the reverse zones. Here are what the reverse DNS records would like generated with my Solid DNS. This would work with BIND. You have the second one from the bottom there is the reverse one for the US 1.v6 home. When you go to test it, you can do a tellnet. I used the node name to port 25. It comes back and says, "I'm trying to address 20 0 1" and it comes back and says I'm connected. So I do the typical handshake, the EHLOX.com and it comes back with what its capabilities are and says "You seem to be alive. Quit." Same thing on port 110 trying out the POP 3. I connected to the same address over port 110.

Comes back and says, "I'm a POP mail server." "Looks like you're live to quit." Same with the Postfix and Dovecot. You can interact with it and verify it's working. So, the final thing here is basically the mail headers that actually prove that I sent mail from one of those dual stack systems to another, over the Internet. The received headers are the proof of that and they basically get put on in reverse order. So the most recent one is the first. So let's start down at the second one. Received from LEH. That was my node at home. And it says the IPv6 address on that is and it happens to be a stateless autoconfigured address. And using TLS, with the figures and it said received by US 1.V 6.org and it happened to be an IPv6 address also and it didn't spell it out leer.

The top one is saying I received a connection there at 2001 - by and then the name of the Exchange Server which happened to be at ::b. There you go, email headers from an email message that went from one dual stack mail server to another out over the Internet, over though the two happen to be in my home, just a few feet apart.

Basically, it is possible to do things like real email and so on today with what's, this was not a major project. It took about two days to get everything together. One of the reasons I did this is part of my IPv6 home project. This is an attempt to show it's possible to do typical IT-type things without a great deal of trouble in a fully dual stacked environment, taking advantage of IPv6 today.

Again, like I said, within a probably a year or two, you'll be able to get D-link products and do this without having to use things like our products for home. It's a little overkill to have several thousand dollars worth of appliances in your home but I get a good price on them since I own the company.

Anyway, basically, you can connect in to v6 home and I'll try connecting in here in just a second just to show you what it looks like. But among other things, there's PHPBB on there which is a bulletin board system. If you click on that and register, that will automatically register you my accounts on everything including the email. If you have always wanted to have a dual stack email account, if you attend the IETF meetings, when they turn it off, you can continue doing the email while everyone is twiddling their thumbs. Go to that address and click on the PHPBB icon and you're off and running.

OK, now, let's see, let me see if I can connect to this. I hope I've got connectivity here.

That's what it looks like. Look at that. Even though we're an IPv6 conference we don't have dual stack connectivity. We have an IPv4 address. Normally it should come back with an IPv6 address if you had connectivity and the v6 home should be there with some pretty colors. I have my certificate from Martin's company. And I have an IPv6 world wide web certification and a little meter showing how much at the time people are connecting at v6. So that's basically what it looks like. Feel free to connect. Have fun. And unfortunately we're running a little bit shy on time, but if you have any questions, I would like to encourage you to email those to me and I'll be glad to respond. If you happen to have done it over IPv6, I'll be glad to respond and recognize that, yes, you're one of the first people in the world to send email over IPv6.

Right. Thank you very much.

MARTIN LEVY: Thank you. There's a phrase hit by the demo gods. That would be a good example of it. Lorenzo, what company are you from? I know that. He's from Google. We can swap laptops.

There was a pretty important event that happened in the last month or so which, again, hit the popular press. Which--we're getting there--which is when Google turned on their YouTube service for v6 and I for one, within minutes, ended up talking with Lorenzo and saying a simple phrase, "Whoa, that's a lot of v6 traffic." The rest of the story, yeah. OK. The rest of the story is part of what Lorenzo will talk about. I'll give you the stage. We're running a few minutes late.

LORENZO COLITTI: So I will be, I've given this presentation before, some of you have seen it. So I'll skim over them, just show the key points. The key point here is that we see this as being a point for the future of the Internet. And we see v6 as critical. Yes, we've seen the graphs. The graphs they bottom-out in a couple of years' time. This is an interesting way to look at it as well that I hadn't seen before. So in ten years, we ran through 50% mostly of the address space that we had, in the last ten years. We can, it's going to take a hell of lot of address marketing to keep us going for another ten years unless we do IPv6. That's something you might want to think about.

Just to reiterate what the reasons are, because maybe the engineers are convinced but management needs to see the business case. We do see the business case. Our management understands the business case. From the ISP side, of course, you're looking at cost increases, buying addresses will be expensive, and it will increase over time and be more and more expensive. There has been cost advantages, lots of new boxes you have to maintain. I don't know if you saw SoftBank's presentation yesterday, it was extremely interesting. They had real cost numbers of what it was going to take them to transition to IPv6 using six-RD. The expense was not that high and please refer to the slides for more details. And I think, correct me if I'm wrong, it was in the order of $100,000 per million users, something like that.

The disadvantages of that, of doing large-scale NAT included having to maintain 30 terabytes of storage you have to have 300 terabytes just sitting there and doing logging for legal reasons and are cost increases associated with that even beyond this. Even beyond the obvious. So for constant providers, having users share IP addresses is a severe limitation on the quality of server that we can provide, for these reasons. When users share IP addresses we can't do dual location as well. If you search for local content, we won't be able to give it to you because we don't know where you are because you could be sharing an IP address with someone in a different city.

We might not be able to stream particular events because of licensing restrictions. Contracts are typically very restrictive. If you want to stream baseball games in the US, you have to be in the right city. If you're not you can't receive them. So we won't be able to do that. Abuse of identification--when one user starts performing abuse, tracking them down will require logging the port on the content side but it will involve taking out 10 or 100 users just because one user is misbehaving. We don't want to see that.

There are many reasons why we don't see this as, we see this as severely impacting our service. We don't want this to happen. We see v6-only deployment. Do we want to provide services to these new devices? LT, set top boxes? These devices typically don't have v4, or they're going through multiple layers of NAT or proxy. In the French network, they go through v4 to IPv6. They have to go through an HTP proxy. And we have, and we do, we do start to see large ISPs either having v6 turned on or preparing for it. We have the French has four million users, all of their set top boxes have IPv6 and one thing that's, the interesting thing is of those four million users, several hundred thousand have clicked the check box in the gateway configuration that they want IPv6.

Several hundred thousand users have opted into their trial. It was made very easy for them. Saying there's no user demand is not true because if 10% of your users want it, maybe you want to offer it.

We saw an interesting presentation from SoftBank saying how they plan to offer IPv6 service over both their ADSL and fiber to the home networks using NTT. A lot of people are looking at 6RD because it radically changes the cost structure. The CP has to be changed anyway. But once you decide to either take the cost hit for the CP or decide only new users will use IPv6 because existing users have v4, then the cost of upgrading to IPv6 is very, is very low, because all you need to do is some simple tunnelling. Take a look at 6RD and see what it can do for you. We don't want the Internet to stay frozen in 2000. We would like to see new applications. In a world where nobody has a public IP address, there will be no new applications.

And because simply any new application will require the network to support it. Will require the NATs at every stage of the process to support your new application and that's not feasible. We will see a huge innovation on the Internet will be huge.

Oh, at least I personally I don't believe there's a killer application for v6. We shouldn't be looking for a new applications which require v6 support. We're past that point now. The application that we need to see for v6 is the survival of the Internet in its current form. We can change the Internet and move it more towards an Internet with application layer gateways. Make it more like a telco network in which all the services have to be brokered at various parts of the network and build intelligence in to the network. We can't keep continuing, you can't continue to operate the Internet in its current form without IPv6.

So, we have, what have we done? We're trying to raise awareness and we're trying to break the chicken and egg problem by creating a mechanical chicken where you can get content over IPv6. At least ISPs that are deploying IPv6 will be able to access it and be able to get large amounts. We can't do this for Google.com because we have data that show physical we did that 0.05% of users wouldn't be able to reach us anymore and that's unacceptable for us. We will turn it on for you if you ask for it.

So, if you have a production quality network with a large number of IPv6 users l you need to do is send this email. Assuming we have good connectivity, we will turn on all services for you over IPv6 and you'll be able to receive all our content over IPv6. It's as easy as that. We have about 100 institutions so far. Most of them are search institutions because it's easier to roll out IPv6 in simple Ethernet networks. And Comcast who are running trials today, they plan to run v6 trials in April, we look forward to seeing those. If you live in the US and you haven't seen the Comcast announcement, take a look. If you have it at home, please sign up for the trials. It didn't take us that long to do it. It took a year and a half. It was essentially a small project that started on a 20% basis and then gradually grew.

It's a very small project to Google. It didn't take a lot of work but it takes a lot of time. It requires going back and forth with vendors and back and forth with third party code and trying to do it quicker results in the disproportionate increase in the cost. You have to then start modifying your release cycles, operate cycles and all these things in order to get it done quickly. Doing it at this pace is much more cost effective.

So, again, just a few statistics. I'll keep it short. We continuously measured the availability of v6 connectivity on the Internet. Well, OK.

That's not good. OK. And we have long-running measurements. We've tracked v6 adoption. Those numbers are pretty low. Depending on how you look at it, that's good or bad. The numbers are very low. 0.3%. The growth is 35% growth a year. So, you can make of that what you will. You can say it will never happen because it's too low or if it's going at 35% a year it will happen pretty quickly. 35% growth is not enough to get us to 100% in five years, though. I suspect that. We can see on the right, the top right-hand side that there is essentially no IPv6 deployment at any sizable scale outside of France and to a lesser extent of China. China has the IPv6 only CERNET backbone. France, that's the effect of free spending the five weeks that it took to roll out 6RD to their users.

Nobody has done this yet on a grand scale. We expect that to change quickly with large networks deploying IPv6. We will finally, please don't deploy IPv6 the wrong way. That is, that is the worst thing you can do, because it will hinder the prospects for adoption, not help them. Providing some sort of tunnel solution, if it's not well maintained or high quality of service, it will just stop v6 adoption. It will give a black eye to IPv6. If you provide v6 at a conference, please make sure it's supported and it works. In particular, this network had rogue advertisements that were black holing IPv6 connectivity. Please fix that. Please take, make the extra effort to make it work well. If it doesn't work well, it's no use to anyone.

Finally, growth can be rather rapid. This is what happened when we enabled video streaming, YouTube over IPv6. You can see on the bottom, that is the normal daily cycle. About 1pm we turned on YouTube and traffic grew by ten times. Why is that. Because the traffic doesn't just appear from anywhere, from nowhere. It gets moved over from before the v6 and much faster than organic growth. We do expect this to happen, as other service providers roll out v6, we expect to see growth happening in spits and spurts.

So, with that - hopefully that was short enough to get us back. Well, not really. Not on schedule. Let's see. If anyone wants to go--the bottom line is the number of users coming in over IPv6, the red line is users that come in, that are part of Google over IPv6. The middle blue line is native users. As you can see, about 70% of the native Internet we see in the measurements is coming in over v6 every day.

MARTIN LEVY: Thank you. I want to make one comment. When YouTube turned on their service on v6, there were a lot of naysayers about IPv6 on the global Internet which were silenced within minutes. This is eyeball-driven traffic. Not just random testing or other services. These were real users that were looking at videos. I think the answer is yes to this. But that's a fundamental part of what you provided on that service, correct?

LORENZO COLITTI: Yeah. This is a quarter of a million users coming in over IPv6 every day. This is real traffic. I hope that's clear. But if it's not, it should be abundantly clear. This is production quality. A quarter of a million users every day like clockwork coming in over IPv6 and not over IPv4. If that wasn't clear, I can say it again and again and again. This is real. And it's not hard.

MARTIN LEVY: Thank you. OK. Muhammad Kamal Zahari is our final speaker here. And we have a laptop change. He will talk about what Telekom Malaysia has been doing here in country. I'm going to leave the commentary very short because part of what we're going to see is in addition, the work that's been done on some of the very pro-v6 government push.

MUHAMMAD KAMAL ZAHARI: Most of what I'm going to say has already been touched by other panellists. So I will skip over those slides. Basically, thank you, managing transition from IPv4 to IPv6 is the key word. OK, some background information. Fortunately, the government of Malaysia has been very proactive in promoting IPv6 in Malaysia. Several years ago we the Government came up with a Malaysian services. An initiative to promote the--a knowledge society in Malaysia. So you have this different aspects of services infrastructure, growth and focus areas. Under infrastructure, we have next IPv6 number 4. The Government has defined implementation plan for national IPv6. So starting 2006, ISPs were requested to conduct this in respect to IPv6. And for 2007 and 2008, targets have been defined for all ISPs in Malaysia.

IPv6 network backbone should run on dual stack. This has been requested. And now we are supposed to commercial roll-out of IPv6 service by 2008. Push it back to 2010, broadband services to be IPv6 and IPv4 dual stack for all broadband users. These are the compliance audit, and there are three phases. The tests are quite simple. We don't want to make it complicated. The way the Government sees the way, the consumer, the way they're seeing it, so at the end of the day, the end-users will have the final say. You're supposed to be able to use it as easily and transparent as possible. They don't really care about IPv4 or IPv6 as long as the services are still there, then it's OK. Ask anyone outside of this room about IPv4, they don't know anything about IPv4. It's up to us to make sure the transition is as smooth as possible and as transparent to the end-users as possible.

So, these are the results of the phase one audit and the phase two audit. Phase one of compliance and phase two, end of the year last year, compared with everything, a very easy test, just to get the symbol here, IPv6 there, from Martin. And then, from forum. OK.

OK, we obtained the IPv6 block from APNIC on 24 February 2004. So we have an IPv6-enabled website which is up and running. I can show you the website here, but I don't think we have the time. These are the results of some very basic testing done using entity communications Looking Glass. What are the current status of IPv6 implementation in Malaysia? We are actually offering VPN services to corporate customers over MPLS backbone. We have one ongoing Malaysian Research and Education Network. This is purely IPv6 backbone. This is actually a high capacity network connection between participating local and international universities, research organizations, and scientific laboratories in Malaysia and over in Europe. This network is enabling researchers to run data-intensive applications, share computing power, and run advanced applications within Malaysia as well as overseas.

So during the initial development of IPv4, a lot of, www.worldwide web. During the development, a lot were participating, so we are seeing a lot of colleges, research laboratories, who were the initial adopter of IPv6. I'm going to, OK, we have this one, so the current status of IPv6 and the peering sessions in IPv6, we have IPv6 peering through public switches. London, 21 peering partners, including Hurricane Electric, and others. Fourteen peering partners in and Equinix. For testing purposes, TNZI, C & W, and Google v6 and near future connection with Google v6 / YouTube. Future connection with all PPM members and the list is growing. It might seem small right now but the list is definitely growing. IPv4 tunnelling, we have NTT MSC and Verizon US.

OK, the current status of IPv4 address pool in Malaysia, actually, we have, we are currently depleting the address that you can see here. Users at 100%, meaning basically no more. 2%, 27%. So we are currently depleting the IPv4 address pool in Malaysia. So the challenges--I say it before. End-users only care about the services, not the manner in which the services are being delivered. It's up to service providers to make sure the transition is as smooth as possible. From what we can see there are different classes of end-users and each class requires different approaches.

I think Srinivas mentioned devices using IPv6, automated--I will add something to that. All the meters will be connected to Internet, automatically, so a lot of new devices and these devices should be connected over IPv6 network. And this is something that we can control. We can ask those new customers, new service providers to use IPv6 instead of IPv4. So the providers of new classes of business, a class of services that we can actually control. We can provide IPv6 over this services, but the main concern here is the general public. Users of PC, laptop. A lot of us are still using Microsoft Windows XP, which does not support IPv6. You have to enable it in order to support IPv6. So, you see, when you talk about six billion people using all these devices, there's currently a lot of diverse ways of, for them, a lot of devices that you cannot control.

So what can you do in this case? The only thing you can do is to increase the awareness. So we have two problems here. Lack of awareness, which is causing lack of urgency in adopting IPv6. So, how do we move forward? So that's a necessity to raise the awareness of the public. And why we're waiting for the level of awareness to achieving the necessary critical mass, we need to guarantee IPv4 and IPv6 interoperability. I hope IPv4 will continue to be used for the next 10-15 years. During this long transition time, both protocols should continue to be supported. "

So this is just my opinion. There is a need to introduce a cut-off date. For the transition from IPv4 to IPv6 in order to ensure a shorter transition period of full IPv6 networks worldwide. And to create awareness among the public. This is a symbolic cut-off date. You're talking about raising the awareness of six billion people? Have we done it before? Yes, we have done it before. We define a date, a very catchy name, Y 2 K. Everybody talks about it. The paper, the government agencies. Everybody talks about it and they managed to raise the awareness. When the moment came, very few problems were reported. So can we do the same thing about IPv6? It doesn't mean anything, either you're ready or you're not for it. But at least we have something to create awareness among people.

So I think, I don't know if this is a good idea. It's up to the members of APNIC to discuss it. But maybe there's something that we need. A symbolic cut-off date. That concludes my presentation, but I have something for Martin, actually.

I drew something while waiting for my turn. You were talking about straight-line graph, why are we talking about that? Thanks.

APPLAUSE

LORENZO COLITTI: I think we were talking about a straight line graph because the graph is a straight line and we have the data to prove it.

MARTIN LEVY: Listen the graph is just as good as mine. It looks like it's bit more technically drawn than mine. And it's -t still goes up and to the right. That's important.

OK, I'm going to ask if there's any general questions? And keep in mind I have one more, Miwa will come up and have some of the survey information. While she gets ready,

RANDY BUSH: IIJ. This is not Y2K. There is no date. IPv4 is not going to stop working. Right? And the engineers who hold the Internet together through problem after problem and disaster after disaster will continue to do so. The big and important thing is that we have to make IPv6 as easy to use or easier than NATs. And nature will take its course. Right. We've heard the presentations we heard today--five years ago we heard them. This is an old movie. Playing it again is not the issue. No surprise, except Lorenzo put one more service on IPv6. And we need to make it easier to transition to v6 than that. Scaring people, telling them it's Y2K, all that is old. It's not true. Make IPv6 easier to use than NATs.

MARTIN LEVY: Lorenzo, I will challenge you on this? How many million users?

LORENZO COLITTI: Um, per policy.

MARTIN LEVY: You did mention a number before that came up on v6, a fairly large number.

LORENZO COLITTI: It's been several hundreds of thousands.

MARTIN LEVY: OK, there was another stat you gave. A Year and a half worth of work started as 20% in Google and now it's mainstream within the networking group? Lorenzo Colitti is well-known by management and with the support of management, because they understand the issues, it's not mainstreamed in the sense we have 100 people working on it because the amount of work is not that large. It's a handful of people.

MARTIN LEVY: The amount of work you did internal to Google is one measure but the amount of work you did to help users become IPv6-enabled at the eyeball level, really that isn't your domain, so to speak. I'm thinking there's a good response here that five years ago we talked about this in a vacuum, maybe with no users or maybe the statement where there's only ping and trace route traffic may have been true to a certain extent. We've pretty much nailed that coffin shut, with the type of stats that you presented?

LORENZO COLITTI: Yes.

MARTIN LEVY: OK.

MATTHEW MOYLE-CROFT: I'd like to comment quickly on your comment. I think it's easier than NATs, I think that the important thing as other people pointed out is that the reason to do IPv6 is to maintain end-to-end connectivity to customers. That's really deeply what they want. I think what one of the panellists is trying to get at was to a certain extent, to get the mean out there to the general public of v6, you have to create a brand. And I guess Y2K became a bit of a brand and we need to do the same with the transition, maybe. I think it's a reasonably good idea. I do think with your comment about it being an old movie, it is to a certain extent true. I guess the difference is the reality from what Lorenzo said is between now and IPv4, no more addresses to allocate is within the bounds of the amount of time it's taking people to become enabled.

So whereas five years ago, the requirement to end or reduce your IPv4 requirements wasn't as there as much. Now we can see where that is.

LORENZO COLITTI: Can I follow on to that as well? To your old movie point, I have seen presentations at this conference that are not old movie. I have seen them but not in this session. And next time I would love to see them in such a session because they are--honest to goodness--deployments. Or sensible plans for large-scale deployments that indicate that the issues have been analysed and designed around and that make, that present a credible case for a service that will launch soon. I'd love to see those presentations here and I'm happy to give up my slot on the panel for such a presentation next time.

DAVE CROCKER: For my part, I really appreciate the panel. I really think that it had a number of things that hinted very nicely, making progress and directions at making more progress. It hinted at problems with making that progress. The hints at the problems were I think not intentional. So this example of the branding I think is a really good idea. Not for fear-mongering but for giving an anchor. I think in general the v6 community has done an atrocious job of putting forward a value proposition and branding the effort to provide that value. So, for example, the entire medical emergency environment example is wonderfully clear as a value proposition. It's not very tough to get across that this is a real need, especially in the last few months. This is a real need and that the statement that here is something that is much better done with v6 than v4, not because of address space problems, but because it is better to do it that way.

I don't think I've actually heard somebody put that forward as a statement or a real world use, rather than geek use. Some more of those would be really nice. Efforts to make sure it's easier to deploy v6 that way, not an exercise among experts, but among regular IT guys. A hint to the problem was--I've been in the middle this week of coming up to speed of what seems to be v6 adoption problems and have an example of a site of my mine, I had to turn it off, because I was getting mail rejected. So the whole paper on email was great because the original statement at the beginning of the was just as easy. You started commenting about DNS problems, that's why I had to turn it off. You didn't even mention the particular thing I think I found as a problem, we're still trying to diagnose it.

My point is there is a psychology in the v6 community which is just as easy. It is for the v6 experts, but not for the rest of the world. That's the gap we need to fill.

GEOFF HUSTON: Geoff Huston, APNIC. That was a really interesting panel. I suppose I'm very heartened by this. But, at the same time, I suppose I've also seen all of you for many years in these rooms. So let's go back to 1995. How big was the Internet? A cursory search on Google reveals it's around 17 million users then. Did we talk about the Internet then as a future, or as a reality? Was it going to be or was it there already? And those of you that were around at the time and most of you were, I believe, talked about it in the present tense, it was there. 17 million users out of a population even then of around 4.5 billion, 5 billion in the world, possibly 6 billion, it was already with us. So how many folk on the world's networks today, when given the choice of what transport protocols are available, flicked to use v6?

The measurements we've been doing over the last few years tend to suggest it's somewhere around 0.7% to 1% of users. Interestingly, that's the same 17 million number. Someone said, "Probably the same people." My point is, is v6 a future or a reality? The real psychology is stop talking about it as something to happen and talk about it as part of the fabric of the network we build now. Because, quite frankly, the numbers involved say that v6 enjoys the same level of use as the entire Internet did in 1995. It's with us already. And realistically this whole early adopter, late adopter thing is moving in to quite a significant issue. That if you haven't already started deploying, you're becoming late. It's no longer an early issue, it's a late issue.

So let's start thinking about not the future, but thinking about v6 as a now, because, quite frankly, the numbers involved are significant enough, it's big enough, it is the same size as where we all were the entire Internet itself just a little over 15 years ago. So where they are already is what I'm trying to say. Given that, your advice is to where to go from here. With it is being part of what we do is our steps. Thank you.

APPLAUSE

MARTIN LEVY: I'm going to close this. Thank you, Geoff, for that comment. I will close this with a question back to you and back to the community. Should this be the last v6 panel we ever do at an APNIC conference? Are we done? Can we all go home on this particular subject? We can focus on the next thing? By the way, it's Route Security. And moving on. Discuss that amongst yourselves. Send an email in to the appropriate people within the APNIC community. And let's see what happens when we meet in six months time. I have only time for Miwa and some survey results. She says she'll finish in two minutes. So let's start the clocks rolling.

MIWA: Morning, everybody. I wanted to give IPv6 deployment monitoring survey, presentation to you this morning but I'll make trader. I will finish my presentation with light speed. So in this presentation, I wanted to talk about the survey we conducted in last August 27 to October 2. The valid APNIC region responses--we received 429 altogether from 37 economies. Thank you so much for your cooperation.

In this presentation, I talked about what is the survey and objectives of the survey and questions covered in this survey. This presentation file is available on the website, at APNIC 29. So please take a look on in your own time.

A couple of findings and analysis are included too.

I will just go through quickly. Give a little bit more information about IPv6 Kickstart policy is implemented. It's so easy to get IPv6 addresses. People who responded with no IPv6 address yet, please take a look at this website and reconsider about your plan, based on Geoff Huston's explanation. IPv6 is a reality now. So we need to move on that you're network ready with IPv6 so you can secure your future growth.

More findings were covered, analysis and a couple of examples are included in this slide set. The future plan of this survey--95% of people responded, indicated their willingness to respond again in 2010, sometime around June. We organized the this with RIPE NCC's cooperation. So we would like to seek your cooperation once more to measure IPv6 implementation in this region. So if APNIC announcement reached to you, asking your participation, please take about 20 minutes of your time and participate in this survey once more. And we would like to share the outcome with you again.

The full version of this survey will be on www.apnic.net/ipv6 by the end of this meeting. Thank you.

MARTIN LEVY: I want to thank the panel. Thank you, Miwa, for the lightning speed. And just inform you that we have obviously have the usual tea at this point in time. We will be back, we will be cutting the tea a little short? Yeah. We will cut it a little short and I'm fairly certain you'll hear the bell outside informing you to come back in. Thank you all. Thank you very much.