APNIC home / Meetings / APNIC 24 / Program / Plenaries / APNIC / Transcript

24th APNIC Open Policy Meeting / SANOG 10

APNIC Plenary

Transcript

Thursday 6 September 2007

0900-1100

PAUL WILSON:

Good morning. Welcome back to the third day of the APNIC Open Policy Meeting. Thanks to those of you who are here on time. I guess the rest had too much dancing last night. We have a few housekeeping announcements to go through before we get started. I'd just like to go through a couple of details which will help you today. A couple of reminders about sessions that are on later today. We have a special Birds of a Feather session about MyAPNIC. For anyone who might be interested in the latest developments of MyAPNIC and helping to determine where that goes in the future with suggestions of feedback and so on.

Also we have Lightning Talks at 6pm. The Lightning Talks are for short and informal as implied, sort of lightning-style presentations about current issues.

There is an APNIC 24 feedback form which we would really appreciate you to fill out by the end of meeting and there will be a prize draw of an MP3 player will be given to the lucky selected person who has filled out that feedback form. Please think about filling that in as you're sitting through the sessions today.

This evening we have a closing reception for the combined APNIC and SANOG meeting. That's at the Terrace Plaza starting at 8pm tonight. That's it for housekeeping. If anyone has any questions or inquiries or needs any help, you can see there are quite a few APNIC staff here who can help with any questions, anything you might need help with during the day.

Now to move on to the business of the day. This first session is the APNIC plenary session. And we are looking at - one of the major themes for this meeting, which is the future of IPv4 addressing. We have a few speakers. The session will be chaired by Akinori Maemura, who's the chair of the APNIC Executive Council. I'd like to hand over to him right now to get us started. Thank you.

AKINORI MAEMURA:

Good morning. My name is Akinori Maemura from JPNIC and the chair of the Executive Council. Before we go into the discussion, we would like to invite Ms Tulika Pandey for the opening address, presenting for the Government of India. Please come up here, Ms Pandey.

TULIKA PANDEY:

Thank you. Good morning, and greetings on behalf of the Government of India. I'm happy and thankful to APNIC to give me a chance in its plenary session this morning to put forward the Government of India's views on the issue of the future of IPv4. Together here with APNIC in this session, we express our enlightenment on the thought that it's time now that we're all seized of the fact that only 10 percent of the 20 percent left over IPv4 address space is going to be available for the world. This means that we may run out of the existing resources in two to three years time from now.

Looking at the pattern of IP addresses, it doesn't seem any nervousness or scramble for IPv4 address space. However, the worrying point here is that there is yet no effort on the part to move to IPv6 address space.

I'm given to understand that if any ISP today has an IPv4 address block from APNIC, they can apply for IPv6 addresses at no extra cost. The Government of India believes the Internet industry in India should take a prominent role in the adoption of IPv6 addresses and educate their customers in the benefit of IPv6 usage.

The Government of India has taken a stand that all Government initiatives would be IPv6 compliant. The Government has in the past welcomed the participation in utilising this for an effective adoption of IPv6 in India. We're glad the Internet Service Providers Association with its partners, with APNIC and SANOG, have come to India. Both the important issues of technology and policy on the status of IP address space is being discussed at length among all stakeholders and experts in the area. Please join me in showcasing India's eagerness by successfully holding the event during these 10 days.

On the platform of this Asia Pacific forum, I'd now like to seek your kind attention on the related subject of Internet governance. Internet will be hosting the ITF in 2008. It has been established as a multilateral open discussion forum on public policy issues of openness, security, diversity, infrastructure, and access of the Internet. Overlying focus of the WSIS is in providing equal opportunities to the Government, the private sector, the civil society and the Internet community for inclusion of the concerns in public policy from use on the formulation on the Internet and its governance so as to bridge the divide. The meeting of the IETF was held in 2006. The second meeting will be held in Rio De Janeiro. These meetings are opening to all registration on each side.

We in India, with our multi-lingual, and diasporas and wide geographic terrain have been successful in launching initiatives such as a national e-government plan, the Internet Exchange Points, the establishment of the registry, we have about 270,000 domain names and we also have three root servers - I, F and K. We also have the brand image of an IT destination for IT and IT neighbourhood services. There are a lot of expectations on implementation and regulation policies on Internet from India, in the areas of e-commerce, international AS domain names, e-governments and so on. These are some of the deliverables of this knowledge house called India. On behalf of the Government of India, I call upon all stakeholders in the industry, the civil society, the international community to join hands with the Government of India's endeavour to hold the IETF 2008 with all its expectations in place and leading the calls of the development of a public policy issue with the inclusion of the concerns of multi stakeholders.

I also take this opportunity to invite all of you here in creating a framework for the development of industry standards, interoperability of tools and technologies, promotion of tools and expertise and sharing of expertise. The Government of India believes that this will allow for a mutual sharing of best practices among the member countries of the Asia Pacific. Once again, I welcome you all. I'm sure you will come again and again for more and more to India. Thank you so much. APPLAUSE

AKINORI MAEMURA:

Thank you very much, Ms Pandey. We would like to go in to discussion again and, good morning, everyone. This is the APNIC plenary. And the title is the future of IPv4. As you already are aware, we will be running out of IPv4 space in this three or four years. The year 2010 or 2011, according to Geoff Huston's analysis. And this year is a quite impressive year, that where we have a civil action from the RIR, ICANN or some other entities to make some announcement or statement about IPv4 address allocation. So we need to do something to overcome this IPv4 address allocation. And this session is to discuss about this issue for the better resolution, to retain the sustainable operations of the Internet. Today we have three speakers. Geoff Huston, APNIC. And then Randy Bush from IIJ and I think he is soon coming up to the stage. OK. I see you, Randy. And then Kusumba Sridhar. So with these three speakers, we would like to discuss about this issue. OK, the first speaker is Geoff Huston, the chief scientist from APNIC.

IPv4 Unallocated Address Space Exhaustion

GEOFF HUSTON:

Good morning, all. My name is Geoff Huston. I'm the chief scientist at APNIC. All of you know me already, I think. Thank you for coming so early in the morning.

This morning we're talking a little about IPv4 unallocated address space exhaustion. If that's too much for you to think about, it's IPv4 run out. As you're well aware, I've been looking at this for quite some years because we knew, almost as soon as we built v4, we knew there was only a finite amount of address space is there. And if the wildest dreams of our early youth, the computers would be ubiquitous, if it ever came to happen, 32 bits would be enough. But 32 bits isn't enough. We're now confronting a little bit more dynanicism in the environment because quite frankly life is interesting. Don't you love that slide? I love it. We have a representative of horsemen of the apocalypse, a representative of Valhalla and someone else along for a good time.

Firstly, though, I want to go back and expose the way in which I've been doing some of this predictive work for years. And looking at the current status of IPv4 and trying to understand just how close we really are to that wonderful apocalyptic event. So where are we? If you look at the v4 address space, you had 4.4 billion addresses. 4.4 billion /32s, 256 /8s. Of those 256 discreet blocks of addresses, where are they?

The IETF has reserved just a little over 36 of these blocks. They're the private use address space, they're multi-cast and right up at the top end is actually what used to be called Class E. That little bit up there which is experimental. 36 of these 256 /8s, we can't use at this point. The IANA has actually handed out just a little under 174 blocks. So 174 blocks, 174 /8s are in play somewhere and somehow today. And there are 46 left in that great big address pool in the sky. So the real question is how long will it take - those 46 blocks - to become zero? That's the question we're looking at.

First to understand that, let's actually understand what we've done with those 174 /8 blocks already. Have they been used for? Where can you find them? If you look in the BGP routing table, you won't see them all. You'll only see around two-thirds of them. You'll see, if you looked exactly a month ago, 104.344 /8s in BGP. Two-thirds of them are actually being used in the public Internet and being actually advertised.

The RIRs do have a certain amount of addresses that they handed out. They don't get them from IANA the second before they give them to you. They get two /8s these days, work through them, get another two and work through them. How many blocks are sitting there about to be allocated or otherwise sitting in the RIR holding pens? And the answer is if you look at every single rock and look inside every single hole, you'll find 21.5 /8s. Not all of them are actually usable. There actually are some very, very small blocks of space that these days are well beyond the minimum allocation size. But, as I said, if you add up everything, you'll find 21.5 /8s inside the RIR pool system. That leaves 48 /8s that I can't see. They've been allocated. People have them, they're out there somewhere but they're not in the routing table.

If you look hard, you might find Network 7 /8 has been allocated. It's out there somewhere. If you look in the routing table and look back over the 10 years, you'll see it's never been advertised. There are a whole bunch of legacy Class C and B addresses that have been handed out many years ago that aren't advertised and there are a small number of blocks that aren't advertised. Total space - about a third of the space in play.

So that's the basic facts of where we are today. And the real question is how long will those 46 /8s last the world? So you need to do some kind of prediction. And the beauty about predictions is everyone can make them. They're really easy. The tough bit is getting it right. The only way you know if you got it right or not is wait. Let's make a prediction. The technique I'm going to use and have been using for some time is a principle that says yesterday and today are largely similar. You're sitting there listening to fascinating presentations and people are up the front giving them. It happened yesterday, happened today and possibly happen tomorrow. If you take that principle and you add one other view, that we as a society are generally creatures of habit. Change takes time. If you think about that, change taking time, then any change happens in little increments every day.

Add some people you look back and go, "Wow, my hair started falling out. At this rate, in two more years I won't have any." It's that kind of technology we're looking at here. The change that drives today is evident in our history. If we look hard at what we did, we understand what's going to happen. So here is the first of the pictures of what we did. Now, of course, all of you are sitting up the back. Bad move - can't see a thing. In general, what I have are lines that start in the bottom left, OK. That's there. And go to the top right. So up the back - these are a whole bunch of coloured lines from the bottom left to the top right.

For those of you who are more privileged to sit up the front, let me share secrets with you. You're seeing two parts of a history because the RIR system wasn't invented with the Internet, it came along afterwards. We did allocate addresses long before RIRs existed, somehow, God knows how. It was done effectively through IANA and the Internet. These allocations, we have decent data that starts at 1990. The stuff before that, the dates are pretty furry. We did have data that starts at 1990. And the first set of allocations between 1990 and 1994 were done effectively centrally by the Internet. And we were doing the whole Class A, B, C thing. I'm old, I remember it. You all look really young. We had these things called classes. Really big, too big, too small. We started doing the too big and we started doing a whole lot of them. We would run out of addresses at about 1997 if we continued to do Class Bs. Big panic. What are we going to do? Classless, let's stop worrying about /8s, /16s and /24s. Let's allocate what people want. That's more complicated. You need to understand network deployment and deployment plans. You need to converse with folk and need to understand needs. It's a much more complicated thing. Can you do it centrally for free? No. So around that same time, not accidentally, we actually put an infrastructure in place to do a far more complex allocation task. And we started to do classless network allocation. Classless address allocation. All of a sudden the massive consumption of addresses tapered off. So it's not just a big line from top to bottom. It's a flat and a steep line too. The RIR system did manage to impose, I think a far more conservative view of addresses. But there are allocations generally were much slower than the previous system. And much more attuned to actual need. What we're finding is the real growth in address space allocations is really only been since the Internet boom. The boom was a boom in people's heads. Real deployment has happened afterwards. And the growth that we're seeing recently is a growth in the last three years. So that's the long history here. Let's look just a little bit closer at the RIRs themselves. Again, these are these curves and I've broken up the five RIRs. Interestingly, the world is kind of in two modes. We start slow and we get faster. ARIN, RIPE and APNIC started in the mid to late '90s. And over the last 10 years have got faster. There's a lot more activity. The three are largely doing the same amount of address space. They're actually not servicing the same total population by the way. Each of these RIRs have effectively done today 20 /8s. LACNIC and AfriNIC started more recently and so far their total allocations are in the fractions, 1 to 2 3 /8s. There is ARIN, APNIC and RIPE and LACNIC and AfriNIC. They certainly are different here.

What I want to look at is looking at the BGP table because this is a wealth of data. We've been looking at the total amount of address space advertised every single hour for the last 13 years. God, we're obsessive. And this is the graph of the amount of address space we see in the routing table and the amount of address space that we see not in the routing table. The space that isn't advertised. That's an interesting curve. That starts at the year 2000 and stops now. Here's the end of the Internet boom, relatively flat, but by about 2002, broadband deployment started kicking in. Now we see a little bit over 100 /8s being advertised in the address pool. How much space is dark? We started around 30 /8s not being seen. These days it's up around 50. In the last two years, the amount of black space hasn't grown at all. Everything we allocate is advertised. So the system is astonishingly efficient in making sure we push out addresses. The real issue is what's the trend?

Here are the maps. First order differentials with exponential things - for everyone else, don't worry, it's trying to figure out what's the curve there and can we extrapolate it forward? The two curves - the total amount of address space in play and I pushed it forward. There is today this red line going forward. If you think that curve looks a lot like that curve, then that's the model. Tomorrow is a lot like today. What does that mean?

What I really want to know is when the RIRs run out. So I don't really want to know that number, I want to know the date when the amount of address space held by IANA goes to zero if we keep on doing what we're doing today? So I analyse the way in which RIRs do their work and make predictions. Then I analyse from that what IANA would have to do to keep on feeding the RIRs. You can then predict quite cleanly to satisfy that, IANA's got to do this, the red line. At some point those 46 /8s become zero. What's the date? On August 6, a month ago, the mathematic said 22 April 2010. The model gets updated every day - new data. It looks at the last three years. The data keeps moving. If you look on the website today you might find a different day. If you look again tomorrow, you might find a different date. That's the max. This is simply a mathematical model. It says the crunch time happens around about April 2010.

How should you interpret this? Well, it's difficult. Because in one stage you say the numbers are rubbery. But you've also got to understand that we're not modelling just technology, we're modelling people. Most of you, middle-class, average engineers have money in the bank, don't you? Yeah? What if I was to tell you, secret just between you and me, look, I know your bank is going to go broke in exactly three weeks time. Not tomorrow, it's fine tomorrow, not next week, three weeks time from now. At that point your bank is going to go belly-up. You have two choices. If you believe me and let's say you do because I've always been right, yeah, yeah, yeah, will you wait for two weeks and six days and then line up at the bank going, "Please, can I have my money out?" Or will you run down there right now? Every single time this has happened historically, runs on the bank, "You run down there right now, all of you." You panic. This model doesn't assume typical human behaviour. Any scarce resource under competitive pressure is going to be subject to panic. That's what competitive pressure is all about in scarcity economics. This model doesn't model reality. It assumes there will be no panic, no change in policies or the underlying dynamics of demand, no rationing, no withholding. It assumes tomorrow is a lot like today and you're as polite to each other as you were yesterday. You won't be. The industry won't be. We're already seeing some of those politics at play and they're ugly. Because the politics of scarcity are ugly. And if you think 2010 is nice because we're all going to be nice to each other, that's fine, but it's your money. This is an industry, this is an incredibly valuable industry. What are you really going to do and when are you going to do it?

So we've got a problem. What I want to emphasise is that the maths will tell you the problem is going to become critical somewhere in the next 2-3 years. The human factor engineering says somewhere in the next one to two years, depending on how much people and industry behave. I can't tell you the mathematics of panic, not many can, it's a difficult piece of mathematics. What I can say is this is not something which will happen after I retire, damn it. It won't happen after you retire because you look younger than me. This is your problem.

So the next thing is, is the real problem the fact that the falling brick hits the ground or is the real problem what do you do when the brick has shattered? Is the real problem the point of exhaustion or what happens after exhaustion? The date when things run out, the date when things don't happen doesn't happen that much, it's what happens afterwards. What then is the real question? So far we've built a massive network using network address translators. We actually don't know how much of the network sits behind it. Various academic studies have been done but the true count of the size of the Internet is unknown because we really don't know how many folk live behind NATs. You simply do more of them? When we run out of addresses it's pretty above that the industry hasn't run out of its need. The fact you're accelerating into the wall which means when you hit the wall you're going very, very fast. Industry will not then all of a sudden say, "That's it, whoever has addresses, whoever has them and whoever doesn't, that's life." No, there will be a phenomenal demand for IPv4 addresses. Where are they going to get them from? Because the RIRs will have none. IANA will have none. So if you want addresses, who's going to give it to you? Look around you, look to the person on your left, the person on your right, that's where the addresses are. And you will have to do this because there's no other source. So if you still are addicted to IPv4 at this point, then you're going to have to figure out where the addresses are going to come from to feed your addiction. When you start trading, you're going to start fragmenting and doing the slicing and dicing. The routing system is going to become fascinating. If you think fascinating means fantastically big and a bit of a problem because the routing system will become fantastically big and a bit of a problem. And/or you might have a look at v6. You might because it might be useful. So there's certainly the option on the table to do the right thing here in the long term. I'm not talking about the long term, I'm not talking about a bit in between after exhaustion.

So NATs, how do they look? NATs are wonderful. NATs are one of the most fantastic bits of technology ever invented for this industry. Who buys the NAT? The customer! Not the ISP, you put it on your edge, it's in your box, it's in the boundary of your home, you buy it and run it. What does the ISP do? Nothing. You can't get a better example of externalised cost. That's why NATs are so massively deployed. It's fantastic. You pay. Customers buy and operate them. The applications, well, I'm sorry, they've had to figure it out, ISPs don't pay. ISPs do DHCP. If you really want an address they charge you. What's the market price for IPv4 retail today? Well, the real thing is if you want a static IPv4 address in a mass broadband service, how much a month does that single IPv4 cost you? You're consumer said, you know as well as I do. I have heard and seen tariffs that were around $10 per month per /32 but you're paying for it too if you're buying this. You know too. The retail price of addresses is not mythology, it's out there already. People are paying. Addresses have a price at the retail level. Static addresses are out there.

Well, you know, you can just do more of it because if you haven't got any more addresses from the address pool in the sky, maybe it's more NATs. You can do fantastic complexity in NATs. And some applications might survive, but not all. Not all the time. It is going to get just a little bit interesting. All of a sudden the ISP itself might have to take the leap and run NATs as well. You have a NAT with the customer and the ISP, maybe two or three NATs. All of a sudden you have multi-level NATs being deployed. The folk whose are trying to do VoIP Have done a lot of work. If you've ever put your poor brain through the stuns, ISIs, Toredos of this world, and understand how it relates to some tiny little phone, you will realise it's pretty complicated. If you're starting to put five NATs in a run, it's an interesting issue whether the phone will explode or find its way through all five at once. The cost of the application with multi-level NATs is pretty high. As addresses become scarce, the other option, $10 a month per /32 in v4 is probably going to get pretty cheap. And the price will probably go up. So static IP addresses that currently cost that much will cost a little bit more probably.

But how long can you run a network in NATs? We don't know. And there is one way to find out and that's experiment. What you're experimenting with is how many NATs can you deploy until you destroy the network? How do you know when you've done too many? When the network is destroy under yes, that was the question. The only way you can find the answer is to destroy it. You can continue down this grand social path in Internet networking and figure out how dense the NAT deployment can get before the network breaks and the answer will happen the day before or even the second before the network breaks. But, yes, you can find out. The danger is we've already started this experiment and we might well be on a path to find out. And I'm not sure you and I want to be there. Because there are a whole bunch of critical resources even behind incredibly dense NAT deployment that aren't infinite. Those private address pools are not infinite. The Net binding capacity only gives you 16 more bits. Private address pool sizes aren't going to expand overnight. The complexity of applications is not infinite. And the routing space is definitely not infinite. There are real problems there. You'll hear proposals today in the following area to expand the private address pool by putting the Class E space in there. It is a proposal. It may or may not work. You can muck around even more by combining the DNS and application level gateways and NAT behaviour. It's just software. You can do anything in software. You can hang yourself five times over. If you want to play with DNS and NATs and do bi-directional source and destination translation, feel free to experiment. The only thing that will break are applications. Or the applications themselves can give up completely and start doing their own addressing behaviour and try and survive as overlays. Already we have seen that most of the applications over the last five years have become NAT-tolerant by making them overlays rather than fundamental transports. G-mail doesn't care how you get to it. It's a web application. Most of the world is now glued together over HTTP. All this complexity starts to bite at some point. You can find out, when does this whole complexity break? When does IPv6 start looking interesting? You can bite the bullet. But this is not a pleasant option. Why hasn't industry done anything in the last 10 years? Because it's not backward compatible. If I speak v4 and you speak v6, we can't talk, no matter what you try, we can't talk. Because v6 is a backward compatible with v4 on the wire. If I want to speak to you and you're v6 and I'm v4, we have to be the same. We have to do dual stack. I can do v4 and v6 on my own machine or someone else can do it for me. NAT with protocol translation. The IETF even described it and put out a document, an RFC, saying this is how you do NAT with protocol translation and three months ago they decided it was so even and ugly that they decided, "Do not use." Whoops. It's dual stack or nothing. Interesting.

So you have probably seen all these slides. The initial idea is you have a very dense v4 network. We understand it and use it every day. You have a few v6. You tunnel the v6 together and form an overlay network. The hosts that play dual stack. This is pretty standard stuff. The theory is everyone sees the enlightened option. The theory is we start deploying v6 all over the place and the v4 networks get retro-fitted. You see more dual stack lying around and less and less tunnelling. You might actually get to the end point. You might actually get there. We have legacy stuff flying around but it has to start doing its own work. Most of the rest of the networks are done in single protocol. Not only v6. We might get there. But, you know, it's great slide ware. But you haven't done it.

You haven't gone down this path. And you're leaving it awfully late to start. Because the entire dual stack argument was factored, built 10 years ago. And the theory was that you guys were all going to do this long before we were running out of v4 addresses. You could still fuel the dual stack growth with new v4 addresses. The whole assumption was you were going to start this process well before you absolutely had to. The other assumption is a transition would take a small number of years to complete and everyone would magically see the light and do it on their own accord. There was no orchestration and you'd get to this magic end point well before disaster had bit you. This was the plan. A wonderful plan. What you'll actually see is the run down of v4 and the size of the Internet. And the theory was long before v4 had got critical, you started to deploy dual stack.

As the amount of dual stack increased and the v4 ran down, you got to the point where most of the network was v4 well before you slammed into that wall. You have red and green and blues. Lots of colours. It all looks extremely logical but you didn't do it and it's too late. Way too late. And you didn't do it. We were meant to have done this by now. And you haven't started. There are 233,000 entries in the IPv4 routing space. There are 850 in v6. You haven't done this. So there's another problem. You guys don't believe. You've been hearing about v6 for 10 years and you've never bought it. The business case doesn't match the rhetoric. Why? For some reason, you don't believe in faith. You have no faith. You want the cold, hard facts. You want a business case that justifies spending the money in v6. And we, the technology side of the industry, can't give you it.

Why should you spend a whole bunch more money to put in a second protocol when your customers will keep on paying you the same $15 a month for DSL that they were paying you last month? How are you going to cover that investment when there's no additional income? What's the business case for v6? Is it faster? No. Is it better? Not really. Is it cheaper? No. You haven't bought it. We've asked you to believe. We've asked you to have faith and you said, "No, we're going to wait for a clear message. Faith isn't enough." And you're waiting, and you're waiting, and you're waiting. So am I. Next slide.

Come back. I have lost machinery because I've lost power. I'm going to need to reboot. I'm terribly sorry about this. Paul, can you? Yeah, it's a bit like v6. This is what happens when the transition goes horribly bad. Now you're going to see Windows Magic auto-resume function. I haven't got power by the way. Thank you. No. Thank you. Leave that. Don't touch! Stay there. Keep holding it.

So the point I'm trying to make is that transition is now too late. But you're going to have to do a long dual stack process without any ability to actually need v4 addresses in. So how are you going to expand your networks over the next 8-10 years with no v4 addresses to fuel it? That's the problem. And in that particular case, it's going to be hard to help. So from this perspective, the real answer is you are in a very, very hard place. You've left it extremely late. You cannot complete a transition to v6 before you run out of v4 addresses. So now we're doing two things inside the RIR world. We're trying to figure out how to ration what's left. So that you're trying to make the April 2010 date become the August 2010 date. What we do with the last /8, the last five, what's the rationing policy?

Quite frankly, it doesn't matter. Quite frankly, it's not going to make an ounce of difference to your long-term business. Whether you adopt a policy to allocate the three /8s, whether you ration them out and slow down the allocation process, will make no difference. It doesn't matter. The problem is bigger than that and longer term than that. What we really need to understand is what happens afterwards through this protracted transition. So, really, what the issue is is how you're going to fuel about 8-10 years of Internet growth in dual stack without any dual stack v4?

Who has the knowledge, experience and understanding of how to do that? There is no magic. You can't make those 32 bits in to 33 or 34 or 35. If you want addresses, it's the person next door who has them. What do you need to do? We've seen this problem before. If anyone remembers, it's called Spectrum. There's not a lot of Spectrum out there. We used to hand it out as an administrative process and all of a sudden came along mobile telephony and we stopped doing it as an administrative process. We started doing it how? Auctions, markets, trading. We priced a competitive good that was under scarcity pressure. Working through the fact that the only way that we could do the distribution was by using market mechanisms. We live in a deregulated industry. Most of us live inside economic regimes that we can actually call capitalist.

We actually believe in markets. That's where we come from. This is what we do when we go and buy things at the store. If we don't understand markets are going to be applied to addresses, there is a disconnect going on here. So in effect, what we need to understand are disciplines and understanding beyond where we have normally been. Now if you follow me for a second here, I'm just trying to get my machine back. It's stuck there. I think I'll press on with talking. What we need to do is to understand that we, the RIRs, do not control all of the answer. None of us are economists. If there are, there are only a couple of you here. Most of you are engineers. Very few of you here are regulators.

Thank you. Yep. Next one. Yep. Too late. Keep going. What's the revised plan? You've got a problem. So, addresses - keep going. Right. Back. No, back, back, good. Next one. All of the efforts for rationing, how can you make this last longer? Realistically, it becomes a difficult problem. Let's ration before addresses, let's make it last for one more year? Is that good enough? Two more years, 10 years, 20 years. What's the objective? What's fairness? Is fairness a case of global fairness between economies or give everything to me, is that fairness? No-one can understand these questions. What's the cost? Who pays? Who is the beneficiary? We can't produce anything. Next.

However, if you really want a network and you want a network over the next 10 years, you have to do a lot of work on preserving the things that actually work. We have to understand application still works and routing still has to work. That growth still needs to be fuelled. And you need to fuel it in dual stack. And the integrity of the network architecture still needs to be preserved. So what can we do as RIRs? The first thing we can do is information, not hyperbole, not rhetoric, Information. Clear information. Concise information. And coherent information. We need to understand the implications of choices, in a more global sense than we've tried so far. We need to appreciate that as RIRs we're not natural regulators. As technicians we're not natural economists. The market factors call in people and sectors, call in folk who have never traditionally been part of our circle. We need to think more broadly. We need to under the wider audience. The Internet is no longer a research program. It's a global communications undertaking worth trillions. Understand that what we do impacts each and every person on this planet. There's a very big audience out there. And understand the broader context of where we're playing. It's not an inter-RIR problem. Understand that some quite pragmatic choices need to be made that allow players to work in their own time scale under their own motivations. It's not going to be pleasant. Like all change, it gets a bit disruptive, it's going to be a little bit disruptive. It won't be seamless or costless, it's going to be a bit of a crisis.

Last year, when I did a similar presentation, as humans we've coped with crises so often, we've actually analysed what we do when we see a crisis. The sky is falling - denial. "The sky is not falling." Panic - "It really is falling. Run." Anger - "Why is it falling on me? Who made this happen. I'm getting angry about this. The sky shouldn't be falling. I'm very, very pissed off about this." Then you get on to blame shifting. "Yes, it's falling. I understand that. It's your fault." After a while blame shifting doesn't help either. You get in to bargaining. "Make the sky fall on her and not on me. I'll be good. Can I get through?" Once you go through all of those phases, you've got to accept the sky really is falling and you recover and deal with it. You have the luxury once you've built the new sky, that you can indulge in a little bit of revisionism. "Knew all about it. Wasn't a problem. Those other folk were panicked. I was quite cool through the process." This isn't life as we know it forever. You need to understand where you are. Where are you? You're just there, pointing directly at panic. Thank you.

AKINORI MAEMURA:

Thank you very much. If anyone have any questions at this time, one question, OK.

MUTHUSAMY SIVAS UBRAMAINAN:

The transition from IPv6 to IPv4 to IPv6 presents a very good opportunity to, a great opportunity for the standard bodies to come up with new policies. It's like going from a building that can't fall apart to constructing a whole new building. Are you looking at new policies, allocating IPv6 address spaces for attending people? What if they want to take IPv6. If Coca-Cola wants to take up that name under such policies, can they? IPv6 policies and authentication issues and so on.

GEOFF HUSTON:

For a long time, right up until today, we run an allocation policy which is based on abundant supply and we allocate according to need and allocate without, if you will, exposing other costs. It's not a competitive situation. The supply chain is infinite. If you need it you can get it; if you don't need it, come back and get it when you do. There's no point artificial pricing or constraining what is abundant. It's a waste of everyone's time. The allocation policies we had for v4 were spot-on. They fuelled a revolution in networking and v6 has the same capability. The address space is massive and we can make that policy work as long as we have abundance. The breakdown that's happening in v4 is the imposition of scarcity when our policies are based on abundant supply. I'm not sure the lessons we need to learn from that are lessons that fundamentally impose artificial constraints on v6. If you want the same conditions for the Internet revolution to continue, that was bloody good, it worked really well. I'm pretty sure you don't need to change the v6. But it's the v4 issue that's causing us the heart ache. Thank you.

AKINORI MAEMURA:

IPv6 transition & operational reality and IPv6 transition: some to dos

RANDY BUSH:

OK. I'm going to abbreviate some parts of this presentation.

This is reality therapy.

We will transition to IPv6. Get over it! We will. OK? The issues are when and how, and how ugly it is.

Part of the problem is the marketing fantasies by the people who are desperately trying to push us to IPv6 make it hard for us to deploy. So this presentation at first may seem negative, but think of it as taking off the glasses which are distorting our vision so we can see what the reality actually is so we can actually make deployment decisions.

I'm an operator. I know we have to do this, OK? In fact, I work for the operator that first deployed IPv6. But I want to get rid of the fantasies, OK.

What should have happened? What should have happened was IPv6 deployment so that, when the IPv4 free pool ran out, we were prepared and IPv4 space, of which there is, and will be, a market, is low-cost.

What is happening is the free pool's running out, IPv6 is not being deployed at any rate. There are people who have seen this that says that inflection is optimistic. It's not happening. And therefore the price of an IPv4 piece of address space is going to go up horribly.

Why did it happen? No transition plan. We declared victory before the hard part had even started. There was no long-term plan, no realistic estimation of cost, no support for the folk on the front lines and everybody's going to transition next month. They've been telling us that for ten years. Does this describe the invasion of Iraq, IPv6, DNS security or all of the above? It's all of the above.

OK, I'm going to tell you some IPv6 myths. IPv4 is running out. It isn't. What's running out is the IANA free pool. This is almost exactly in line with the graphs of Frank Solensky ten years ago, who said 2008 through 2011. Geoff has it down to what hour of what day it is. We really don't know, but it's coming. Get over it!

IPv4 is going to go to a trading model. OK? Period. That's what will happen, whether we like it or not. It's already started.

The registries will become title agents, i.e., your space will be certified in a formally verifiable way with X.509-based certificates. The purpose of this is to take a hidden market - we can't stop there being a free market in IPv4 space. What we can do is try to make that market visible, open, transparent, and fair.

To that end, the registries will be making title-tied IPv4 space. ARIN is developing open source software that you can run. APNIC also has software they're going to be running, etc, etc. The registries will be doing this towards the end of the year.

Myth - IPv6 transition is easy. If it was easy, you'd already be there. IPv6 was designed with no thought to operational transition. They made words about it, no reality. IPv6 is on-the-wire incompatible with IPv4. It could have been avoided. One of the proposals was turned down was variable-length addressing, so that IPv4 could have become the 32-bit variant of IPv6 and it would have been compatible on the wire. They didn't do it.

So there is no useful, scaleable transition and translation mechanisms out of the IETF today.

IPv6 eliminates NATs - look, since an IPv6-only site cannot reach an IPv4 Internet because it cannot source packets from an IPv4 address, there will be significant IPv4-only Internet for a decade or more, so IPv6 sites will need IPv4 space and will have NATs with application-layer gateways. IPv6 increases NAT use in the short and medium time. Get over it. It will. We don't like it. It's horrible. It's disgusting. It's reality.

IPv6 reduces routing load - multihoming in IPv6 is the same as IPv4. Routing didn't change. It should have. It didn't. Traffic engineering in v6 is the same as v4. There is no new traffic engineering paradigm. Enterprises will slice and dice their IPv6 /32s to handle branches, etc, etc. The routing table is going to fragment more and more over time. Get over it!

IPv6 transition will be easy on routing. If there are market-based BGP advertisements - in other words, "Hey, you want to advertise another stupid little prefix in the routing table, you have to pay me," but who's me? It's a distributed global problem, so it's operationally complex because routing something global, so it's a whole global settlement problem. This could push back fragmentation, but I don't think it's a technically solvable problem.

Another myth - IPv6 space is infinite. 64 bits goes to every LAN. That's not half of the addresses, right? That's half of the binary power of two address space, OK? Half the bits are gone! Some folks are using /64 for point-to-point. That's like we used to do in the early '90s before we got CIDR and we had to give the /24s to point-to-point links, right? In 15 years, we're going to think of these as we now think of /8s in IPv4.

Another myth - IPv6 has better security. It doesn't do anything that IPv4 Doesn't. IPsec is the recipe in either case. IPsec was supposed to be mandatory in v6 but that's not what happened. OK?

Watch out - IPsec does not work well in a mixed v4/v6 environment. Think about if you, your home is v6 and your laptop is v6 and you're in this hotel, up in your room, where you only have v4. Your VPN is not going to work. OK?

It's true that address space scanning will be harder. It will be harder to attack because scanning this vast enormous space will be harder, but think about botnets scanning for one year, finding the juicy parts of the space and selling that to each other.

Myth - IPv6 increases battery life. Somebody said that up here yesterday and the laugh about that has gone round half the Internet. That really comes from John Loughney, who was comparing a v6 cellphone it a v4 cellphone operating through a NAT. What he was really comparing was NAT versus no NAT, because it was a poorly designed NAT, that the cellphone had to talk to the NAT every two seconds to say, "Remember me," so it wouldn't lose the translation table. The NAT could have remembered the Association of The cellphone binding. So if one had compared v4 without NAT to v6 without NAT or v4 with gnat to v6 with NAT, the results would have been the same. So this tells us more about IPv6 marketing than it tells us about technology.

Myth - there can be incremental deployment, OK? For an enterprise, the entire application chain, from the database backend all the way through the applications, through the firewalls to the border router and the customer's client, must all support v6 or the enterprise cannot deploy that application. You are talking about their application with millions of lines of code. You're talking about Oracle. You're talking about SAP, etc. For ISPs, provisioning systems, monitoring, measurement, billing, all have to convert, and everyone needs support from the vendors. And that's a big part of the problem in this story.

Myth - routers fully support IPv6. Not 100% in hardware. Especially not when you add in ACLs. When you add complex ACLs a significant number of today's routers take it off the hardware path and put it on the software path and your performance goes under the stage. OK.

And, because there is no big demand, the vendors are not spinning the ASICs to solve this problem yet, and the ASIC spin cycle is two to three years for these vendors.

And not all v4 features are supported over IPv6 in the routers - MIBs, SNMP, etc, over v6.

Myth - no static numbering, everything's going to be auto-configuration. It isn't. Because, in an enterprise, security policies wants known addresses. In an ISP, I have to report to the CIA what address you were at, who you were, right? So DHCP is ruling.

Myth - IPv6 is deployed. Yes, pioneers are still moving cautiously. Early adopters are just starting to enter the game. Lockheed has done it, etc, etc. A fair number are here. But you notice if you went downstairs yesterday, TWNIC is supplying for all Taiwan a tunnel broker because the ISP s, a significant number of the ISPs do not supply dual stack backbones yet, OK? The actual measured traffic is very, very small. But we do - we're starting to get some success stories and we need to listen to them, OK?

Myth - IPv6 will replace IPv4. Not given the current lack of universal vendor support. It's far easier to use NAT. This is the real enemy to v6 deployment. V4 NAT, because v4 NAT requires no new expense, no conversion, no training. Nothing. You plug it in, it costs $1.25. OK, the only problem is it's horrible!

OK, so as Gaurab said, 96 more bits, no magic. But we need those more bits. So how do we use them? How do we transition without losing anyone or anything? What can we do?

What we have to do is make the transition to v6 easier. What's in the way? We need to identify the current transition problems and see that they're fixed. We have to get the IETF to fix the outstanding protocol issues. We have to get the vendors to support it. This is a massive problem. And the registries have to prepare to issue titles to v4 and v6 space. This is actually happening well.

OK, there is some success here.

What shouldn't we do? We shouldn't pretend there are no problems. We shouldn't pretend that v6 is magic and will just work for you. OK? Ask the people who have actually been deploying it and they will tell you how difficult it is.

Do not give away IPv6 space to 'promote' IPv6. You're going to make a mess that we will live with forever and it's - what's promoting IPv6 is v4 running. What we have to do is make it easier to deploy IPv6 instead of NATs.

So I've been, in cooperation with a whole bunch of folk, including ISOC, etc, been studying the areas that - what technology issues are blocking this in all these areas. I have foils on each of these and I'm going to go through them and skip most of them. You can help. There is a website, a Wiki, where we're accumulating information on all these areas and the URL's at the end, don't panic - where we're accumulating the data on what's happening with - well, I'll give you some examples. This is a global issue of course. Does a user at a v6-only site get to the Internet? They don't.

OK, administrative infrastructure. BIND 9 seems to support, the registries, the registrars.

Layers 1 and 2, the details of DOCSIS and the cable standards, the 02 standards. The protocols support it but the vendors are not.

Backbone engineering - conversion to dual stack is slow. This really has to be fixed, OK? I can go on in detail, last kilometre - PPPoE, not going to support it, because you first have to do - it's bound to hard addresses in the exchange to get you an address. I'm going to skip through lots of this, watch out. 50 DSL modems don't support v6.

Enterprise I already talked about. Server farms are in serious trouble because there's a limited selection of load balancers which support v6? Hardware. Storage networks are in trouble. Back-end, all your back-end, etc, etc. And they're having trouble getting v6 transit.

Exchange point - one exchange point put IPv6 in the switch requirements and half the vendors declined to bid, right?

Applications - where's the webpage that has a matrix of application by platform showing which is v6 capable and for those that are, a clickable Lincoln how to turn it on and manage it? This is silly!

What's sad is many applications which support v6 due to the application itself or the v6 infrastructure, have such poor performance that the users are being told to turn v6 off. That is grim. OK?

This is a great example, thanks to Jeff Streifling. E-mail/SMTP is a mandatory application. Everybody wants it, OK. Everybody needs to be able to send mail to everybody else. To spam, you cannot run an open SMTP relay. We all know the net police will come and get you if you run an open SMTP relay. So all IPv6 sites need the ability to SMTP to arbitrary IPv4 sites. Therefore everybody needs a private - it cannot be public - dual stack SMTP relay.

That works for an ISP with DSL and broadband customers because the ISP will provide the inbound and the outbound relay. Enterprises don't have that luxury, OK? So everybody enterprise that thinks it's going to run v6 is actually going to have its own v4-to-v6 SMTP gateway, OK? Which means they need v4 space. They cannot be a pure v6 site. It doesn't work.

OK, why is Japan - and I believe some other places like, for instance, Korea and China, but I know Japan so this is my example - why is Japan in better shape? Murai-sensei convinced the Government that early movement to v6 was wise for Japan. The Japanese Government supported with yen - excuse me, the yen symbol wouldn't have worked - IPv6 research. Government supported IPv6 deployment by the industry. It supported IPv6 conversion by the hardware vendors.

So you can buy v6 equipment in Japan for your home. And the Government gives tax incentives to enterprises which become v6 compatible. The Government, instead of talking about regulation, instead of talking about, you know, controlling IPv4 space or DNS or all that stuff, the Government put its money out, OK. This is what governments and the IGF are good at, OK? Providing the incentives to go forward.

I raised my children on a farm. When my son was five years old, he came back from milking some cows and he said, "You know, it's easier to lead them from in front with a can of grain, than behind with a stick." This is the can of grain. This is the reason that Japan is one of the most advanced IPv6 deployments in the world, OK?

This is the URL for that site. I can give it to me. Just write to me or yell. Thank you to all these people and I'm sorry but you get another presentation.

I can't manipulate this laptop.

AKINORI MAEMURA:

Thank you very much, Randy.

RANDY BUSH:

No. Good try.

You get five more minutes. Free. No extra charge.

So what are the real simple 'we need to do x'?

OK, under no circumstances can we allow the Internet to fragment. We cannot have an a v6 and a v4 Internet that can't talk to each other. It would be good if the end-to-end principle could be kept as much as possible because we like the innovative Internet.

The core needs to be IPv4 v6 during transition or horrible kludges will happen. The further the dual stack goes towards the edge - enterprise, net services, consumers - the easier it will and the configuration management and measurement need to be simplified to allow this.

There are five phases-of-of the transition. Denial is the first face. People say we can ignore v6, it's brain dead. The other half says v6 is perfect and those stupid greedy people just need to deploy it. Both of these are wrong.

This is the phase we are in. The next phase will be dual stack with IPv4 dominant.

The next will be dual stack with both very strong.

Then there'll be dual stack with v6 dominant and then finally there will be the v6 Internet, for my grandchildren, and they'll be ready for the transition to IPv10.

NATs - the end-to-end principle is very desirable but because IPv6 is incompatible with IPv4, there will be NATs. Get over it! OK? But we need to make it so that they can fade away and not be there forever. We need NAT-PT, protocol translator.

At the edge, the enterprise, the consumer, need to run v6 but need to talk to v4 and v6 services. When v6 becomes dominant, the v4 people will need to talk to the v6 people. The IETF needs to standardise 4/6 NAT for ICMP, UDP, TCP, RTP and maybe also how application-layer gateways plug in, especially DNS and they need to standardise this so that we don't have to chase across, "Mine works, yours doesn't, yours doesn't," all the reasons we standardise.

Lovingly, the Internet vendor task force in July 2007 published RFC 4966, "Reasons to move the network address translator, protocol translator to historic status." As Geoff said, they said, "Don't do it." This tells you a lot about the IVTF and their level of reality. This is being fixed. In Chicago, I and a couple of others went to talk to the chair of the IVTF and the IE SG, directors responsible for this stuff. This will be fixed, OK.

NAT-PT DNSSEC has to terminate on the NAT. This is a small problem. IPsec will work through NAT-PT and DNS, SMTP and HTTP ALGs are critical because these are the applications that 99% of the use is. Well, there's P2P stuff but those PTP software developers are smart. They'll make it work.

OK, there is going to be serious pressure on routing. IPv4 address space price escalation and the NATs will put serious pressure on routing. If it takes a $10 million router to deal with two million routes and the consequential BGP churn, then 96% of the ISPs will die, because you cannot form multiple - all your BGP routers to cost $10 million. And enterprises cannot be multihomed in the default-free zone. An enterprise isn't going to spend $10 million on a router to talk to the DFZ. So all sized routers, from the enterprise border to the ISP core, need to be handle a serious number of routes with children. Period. No choice.

Don't hack! Do not accept hacks around the route scaling problem, such as tunnelling from the enterprise border to some $10 million core router. Of some of the historic crap they did and then think ten monopolies ISPs and be very, very fearful.

OK, forwarding - packet on the data plane. Because lack of markets, it can be five years before all major router vendors support dual stack at line rate with ACLs. Some vendors are not even spinning the ASICs. It needs to be all vendors because I cannot be vendor-locked to one vendor who can do it and the others can't. I have to have vendor choice. So I'm not interested in, " We can do it and they can't." They all have to do it.

ULA is a problem. I'm not going to go into this one.

Why is Japan in better shape?

So what has to happen is the IETF has to fix NAT-PT and get a serious standard behind it and kill the kludges. Router vendors, dual stack on the FA path, lots of routes. The ISPs have to bring dual stack and bring it to the customer edge. Government - provide incentives, not regulation, thank you. And there's the URL again and thank you.

And NOW I'm done.

AKINORI MAEMURA:

Thank you, Randy. Due to the constraint of time, I'd like to have, OK, one question only. OK.

ROJENDRA PODUL:

Regarding - regarding it doesn't support VPN, what you said. We have, in Japan, we have a product for the IPv6 over IPv4 tunnel. We can create it easily with a new product that is brought forward by a Department of The Japanese Government with the support of the Japan soft DL (?). And this IPv6 over IPv4 tunnel is converting IPv6 packets into IPv4 packets.

RANDY BUSH:

This is a marketing presentation. Thanks. We go with the standard stuff. IPsec. We don't need the marketing presentation. Thank you.

ROJENDRA PODUL:

Just, I want to say that it is supporting I'm version 6. So you say it doesn't support v6 in VPN.

RANDY BUSH:

I didn't say that at all.

ROJENDRA PODUL:

In VPN.

RANDY BUSH:

I said IPsec. The standard stuff we all use, not weird propriety products. Other question.

AKINORI MAEMURA:

No questions.

I would like to go ahead with the next presentation. Is that OK?

ROB SEASTROM:

I don't care. It's your decision.

AKINORI MAEMURA:

Thank you very much for your understanding. So the next presentation is from Kusumba.

Thank you very much, Randy. Japan is in rather good shape thanks to the Government's support. But still it is not sufficient to be ready for the end of IPv4.

In Japan we have a couple of projects to deal with the IPv4 exhaustion issues by the ministry and JPNIC and also the IPv6 Promotion Council. But they are all starting their discussion to find the program when the IPv4 address is exhausted, not just direct transition to the IPv6, just for your information. And this project will be just started so we will have the result, maybe in six months later, maybe some Japanese people, it might be myself, can present something in the next APNIC meeting with APRICOT.

OK, can you advise me when you're ready? Alright.

IPv6 - A positive approach

KUSUMBA SRIDHAR:

I'm going to do some marketing now for IPv6.

So the company name is IPv6 here.

Before that, I am just hoping that every one of you is enjoying their stay here and is comfortable and you're finding the host facilities by ISPAI very comfortable to you. Should you have any problem, please do come back to us and please let us know. We are there to help you.

I'd like to look at a kind of positive perspective for the IPv6 at this moment and also probably try and give a direction as to how we are going to do with an example as how we are trying to work around IPv6 and the processes that we have tried to put in place for achieving the IPv6-ready.

What is an IP address? I think this is one of the old slides that we have been seeing. It's an Internet infrastructure address. It's a public address number and we have 4 billion addresses, but this was yesterday.

We don't have it any more and Geoff was saying that we don't have it after 2010 any more.

So IP address at this moment is no longer an Internet infrastructure alone. What we're talking here is IP address is actually a company for business continuity. If we all have to be in business, we need IPv6. If we all have to be in the business of networking, we need IP address to be there and, if we have to have the IP address, we don't have address space, so it is important that we have to go to the IPv6, as explained by Randy and Geoff and everybody is talking about it.

Why are we having this issue? IPv6 is an issue with the situation that we have.

We have already looked into a couple of other questions, which I'm going to quickly run through. What if the OIL is just over across the world. What if the ice around the Arctic is no longer existing? What if the rivers dry up and we don't have to travel by boat. What if electricity because unavailable in time. So is the case, what if Spectrum runs out and we cannot put new networks. So the case if IP addresses are exhausted around the world. Are these all looking like similar questions? The answer is actually yes, they are all similar questions.

But we have been addressing other questions as what we have. Oil - the estimated time is 50 years from now, but we have already started working on other technologies.

Electricity - is estimated at 44 years, as one of the reports said, but we have already started working on alternative technologies, right from today.

IP addresses - two years from now, but we are not ready yet. We are not talking about it. I can tell you that 95% of the folks sitting here in this room are actually on IPv4 networks. But it is these folk that actually should have moved to IPv6 by now. Unless we don't do it, I don't think so the other networks are going to do. And it is important for us as the community, as the core of the community, that we actually move first to IPv6.

Please understand - the business perspective of IPv6 may be later, but R&D and technology perspective of IPv6 is on today's basis.

So here it is. These are some of the mathematics. Some of you to clearly understand where are we standing on IPv6. So we have about 4.3 billion IP addresses against 6.5 billion population in the world.

The solution we had was NAT, but as explained by Randy, we had issues with complexity. We have problem with security protocols. We have poor client access.

Someone has said that NAT is very good. Please understand that it actually restricts the legitimate access to your peer-to-peer networking, so it is actually not good. And performance reduction is something that we have, we are worried about.

As asked by Geoff in the morning, what is the size of the Internet today? If you go back to your network, you have one router, which is having a public IP address, but behind that, we have 100 hosts. But when we talk about IPv6, those 100 hosts actually are going to be part of the network.

So how many networks have been actually hiding behind the network? It's absolutely impossible to estimate at this moment.

Now, if you look at IPv6, these are the total number of IPv6 IP addresses we are going to have. I'm just trying to put the number here. So that is 340 trillion, trillion, trillion, trillion addresses is the total number of IP addresses that's going to be possible in IP v6 and this is the reason why we have to go for IPv6. You look at the earlier statistics, 4.2 billion is the number of IP addresses against 6.5 billion world population.

But is it just that the world, the human beings need an IP address? Today, we need an IP address for everything. But the perception somehow of IPv6 has been not good among the folks. We have been trying to debate this in India quite a lot. And I was surprised that the current perception of IPv6 is something very different what I'm going to show you here.

Now, what is IPv6? Well, again, this is a past question. We are no longer supposed to be asking what is IPv6. What we are supposed to be asking now is why to do an IPv6, or how to do an IPv6. And please understand that IPv6 is not a software fix. It is just not a software fix. It is a large address space, it is an improved efficiency in routing and packet handling, it's an auto-configuration and plug and play, as we know, and embedded IPsec, enhanced support for mobile IP, elimination of NAT - which actually is a huge cost saving, it's a substantial cost saving. I have to tell you at this point here that the - we were having discussions with Paul yesterday informally on some of the subjects. India, though being a large network today, we insignificant in terms of address space in the Asia Pacific region.

Reason - you know why? Reason is very simple. Majority of the networks in India, or 80% of the access networks in India are on the NAT. 80% of the networks are under NAT in India at this moment. We use NAT extensively. And we are being investing huge on the routers, NAT boxes, for just doing NAT.

And, of course, IPv6 supports routing protocols, WIDE routing protocols.

Now, these-of-these are something that we have been already talking about. More, - I'm quickly running because these are not my slides which I'm going to do. This is a couple of processes I'm going to talk about here.

Neighbour discovery, router configuration - of course, we are going to talk about ICMPv6. Router discovery, stateless auto-configuration. These are some of the things that people are getting, again, please understand the focus is that IPv6 is a matter of technology and not of policy. It is not a policy. It's not somebody going to come and mandate you that you need to have an IPv6 address or you need to migrate to IPv6 address. It's your problem. It's your network problem. If you are not migrating, you're just out of the business. I was just explaining one of the largest companies in India recently who are running the largest VPN network who are not IPv6-ready at this moment, but they run large corporations of India on the network which are having foreign investment. What if that company has decided tomorrow to migrate to IPv6 and the service provider is not IPv6-compatible. You're just out of the business.

He takes about 24% of your business out from your box.

So, again, the myth, as explained by Randy here, is that please understand that it is not migration. It is an adoption. It is just not migration. It is an adoption or transition. That is what exactly is the perception of IPv6 is. We are very surprised when I looked at the current IPv6 perception by many even now, I have to refer to - unfortunately, one of the news articles that have been published recently which we had to send an explanation to the editorial about the understanding of IPv6. The heading said, "Doomsday ahead: Your monitor's gone blank." This is what the heading of the IPv6 article in one of the newspapers was.

PAUL WILSON:

Your screen has switched off.

KUSUMBA SRIDHAR:

This is what is happened, I've done that. This is what exactly they have tried to do by telling the people that Doomsday is ahead and your monitor is going to turn blank.

But only those who have actually understood the IPv6 perception properly, this is what they're looking at.

It is not Doomsday. It is actually all bright. It's quite a lot of happiness. Quite a lot of interesting things are going to happen on IPv6.

So, if so, do we make our network IPv6-compatible now? It's actually asking, like, "Do I construct my house tomorrow? Can I build my house tomorrow right from the foundation?" answer is no. Not going to make your IPv6 networks compatible now, or tomorrow.

It is going to be a long transition and more like being part of network evolution. Please understand, we have taken many decades to evolve this network that we have, so when we are doing a network of IPv6, it's actually we are laying foundation for our future networks. Our children, grandchildren, great grandchildren are the ones that are actually going to talk about this. We are laying the foundation for those networks today and if we are not acting to lay these foundations properly, we cannot be having a network that is viable.

The current network, as you know, is designed in 1970s. Security is something that we're talking about in IPv6, but please understand the default switch of security in IPv4 is in switch off position. In IPv6, it is in switch on position. And whatever we have been doing on the security in IPv4, we have been actually trying to plug in all around IPv4. It's not part of the protocol. Otherwise it's just a part of the protocol in IPv6. The core for the next-generation service. It's a new challenge. It's a great new challenge that we have as folks. And it's about enabling new capabilities, as what we have seen.

And fundamentally, it is a cultural change that is happening as how we are going to conduct the networks. I mentioned to you, I'm not talking as a marketing talk. It's a fundamental cultural change that is required on how we look at the networks at this moment. It's a new evolution process, like Always-on oxygen, it's going to be Always-on IP. Don't have oxygen, you die. If you don't have an IP address, you're not part of the world. That is what we're trying to do. And more importantly, very, very important is IPv6 actually is your friend next door. It is just your friend next door, as important as it is. Many of the engineers I'm still instructing in India, I can tell you it is one out of 50 who understands what is IPv6, one out of 50 engineers that I'm trying to instruct in India, they understand what is IPv6.

That's the kind of scenario we have.

Now, we have done a small analysis on the investment perspective on IPv6. Do I need to invest additionally. For me, the answer is no. This is how we looked at it. The IPv4 today, we're looking at investments in security, we are doing substantial investments on NAT, we are doing investments on maintenance, we are doing investment on network management. These are the complex routing structures that we have.

But in IPv6, we have lesser investment on security, because IPsec is in switched-on condition. NAT does not exist. So you don't need too much of kind of NAT boxes that we're using. Your route certificate not going to be loaded. Maintenance - very less compared to v4. Network management is much less, because you never need to go and touch your routing tables too much.

So what we feel out of our exercise that we have done as part of the economic study in one of the forums, we have felt that it is actually getting balanced. If perception is that we're going to do substantial investments on the IPv6 alone just to adopt the technology, the result is you're going to lower your investment on the other aspects and we have done a kind of mathematics which we can share it with anyone on request.

OK, here is what I have summarised.

There is an easy part of IPv6. Dual stacking, as explained by Randy. IPv6 functionality in modern operating systems, establishing basic IPv6 network services, such as DNS, SMTP and some commodity services, such as HTTP. These are the most easy things of an IPv6.

But a little more challenging are the getting the addresses plan right. Operating and debugging a dual stack environment. Multicast we have been talking about but still there are questions on multicast and of course we have some hard parts here. That is the security, working around the broken functionality, DHCP is still a question mark. Incentives for upgrade to IPv6 - the incentive is it's your business. Getting the vendors to fix bugs or incorporate necessary features. These are some of the hard parts there are going to be.

So what do you do? You watch. You study. You plan. And you execute. Under these four guidelines, we have again taken up an exercise in one of the companies and the process that we have evolved to put this is something like this.

I'm going to skip this particular slide, because this talks more on the kind of perspectives on the issues of IPv6 in business that is product perspective, the solution perspective and also the application perspective. So when you're looking at IPv6, you have to split looking at IPv6 under these three different categories to actually arrive at a solution.

So we're doing the IP address, networks alone. That's again past. Your watch, your TV, your refrigerator, your mobile phone, your house or building, your car or any vehicle, even a soldier on the battlefield would need an IP address. So why do we need 340 trillion, trillion, trillion, trillion IP addresses is for all these things, not just for human beings. And in this that case, we talking about the kind of scenario where the network is then and there itself. Just imagine there is a fire in the building, the building is having an IP address, the systems in the building is having an IP address. The emergency vehicle has arrived. It is able to connect to the building database, then enter itself, download the blueprints of the building, check where are the exit points, be able to share with the other emergency teams then and there itself. Now, please understand this is what exactly is possible with IPv6 if you actually put it in practical deployment, which you cannot do today in IPv4, because it's a subnet network. With IPv6, it's quite practical and that's where we're going to need it.

We're going to make a difference in logistics, dispatch, location services, emergency vehicles, the way their systems are handled. And mobile with increased security, which is a great challenge that we are trying to address today. More importantly from the business perspective, you must not get surprised when I say that the mergers and acquisitions are actually going to become more easier.

Today, you know, the companies spend about a year or two years for the systems to actually get integrated, but if you have IPv6, that integration becomes very easy because you're on the same kind of network. That's how simple it's going to be.

Now, my final two slides. Where is that you have to start your thought process from? This is where it is. Actually, you should have been doing this by now if you are serious about IPv6.

One - make your vision. What is it you want to do? Understand the implications, possibilities, threats and opportunities.

Two - talk about timelines, be very practical when you're talking about timelines and your migration of IPv6. Inventory - have your inventory list ready to talk about IPv6. You do an assessment, identify the vendors and that is when you're going to declare a mission IPv6 statement.

These are all the kind of thought processes that actually have been taken from one of my Y2K documents. We have more or less a similar scenario, but here we have an option to transition and it's going to be a long transition but the process is same. Going to talk about plan. You're going to set up a test environment. And you're going to talk about transition and in your test environment, you're going to have each and every person on your network as a example. After that, you're going to talk about your training, declare IPv6 ready and then have a procedure and a certification. This is a detailed process that we are trying to put on our website. The URL is coming up. It's called go6.in.

OK, what do you do? Go back to your company. Go back to your office. First, establish a task force for IPv6, very important. In the task force, have technical, marketing, finance and management teams and what are you going to do next? This is what you're going to do next. It's a five-process. Infrastructure assessment, adoption plan, transition, education, certification. And then you are IPv6-ready.

There's a detailed process for this, and I'm not going to go into the details, except for I'm just going to leave you with a lead on how we are doing infrastructure assessment.

Here we start. When you do an infrastructure assessment, we have done an exercise over the last one year now and categorised the whole infrastructure available on the Internet into these categories - we call it as core, border, access, second level, user, support, software and others. And I have given some examples as the infrastructure that's going to be there. Core infrastructure, you have firewall, IDS, core routers, switches. And then have you border, you have routers and switches. Access, you have RAS, VPN concentrators. And when you come to the user, you have desktop, laptop, PDAs. Support infrastructure, you have your PBX, video conferences, broadcast, etc, etc. This is how you first do your categorisation.

I'm going to show you one sample spread sheet which we have done, which I have just downloaded to my database in the morning.

Once you have done this, then you have a further four more steps to do. So please understand that the process for migration has already started evolving amongst the folks. It's all is that time for you to start working on this. We have to stop talking about it now. Now, in that scenario, I would like to put a question. This is possible.

Where is APNIC 35 going to be held?

(Pause)

This is actually, I would say, my vision. I would like to carry it this way. Is APNIC 35 going to be? If I had had two years of Geoff Huston and three years for our preparedness and the current rate which APNIC is working on this technology, so where are we going to have APNIC 35 meeting going to be? Answer could be it's actually at your own holiday home. Why? We are all going to be IPv6 ready. We're going to have a converged IP network. We're going to have a huge bandwidth. We means the IPv6 makes it all possible because we have high bandwidth, security, online collaboration. That's what the world is going to change over.

So I would not be surprised if we say APNIC 35 is not going to be in Delhi again, but it's going to be on the Internet. You're going to be part of APNIC 35 meeting probably right sitting on your holiday home, right sitting in your airport when you're travelling, right in your office or wherever you want to be. And that's possible when we have IPv6 assembled. Probably I'm trying to exaggerate things but, yes, this is practically doable And this is how it's going to be.

Here is a word of caution. Security is what's being talked. I'll just leave you here with one line. IPv6 takes care of your poorly configured security is a statement. But, again, it is not that it is perfectly secure. It is that it is not less secured.

So please be aware of this particular aspect. Don't just imagine that IPv6 takes care of everything. No, it does not. It is a new technology. So we have new risks.

I'll end now with my slides but what I'm going to show you now is an Excel sheet which I've just downloaded from India this morning so it won't be looking good but, yes, this is how we've started. As I mentioned, these are the classifications of the infrastructure we have done. The one that you're seeing here. Then we have started identifying the firewall, IDS, routers, etc.

Now, you take firewall in the core infrastructure, we have identified what are the commonly used firewalls - PIX, checkpoint, net screen, etc.

Then we have gone into task number three, where we have identified the versions in that particular mark - checkpoint, OK, these are the version. Net screen, these are the versions that we have.

Then we have started doing another exercise, which we have just concluded, which, if it is PIX, let's say, how do we check if it is IPv6 compatible, what are the expected results and we are now taking up another exercise - if it is not compatible, how to make it compatible. This is a long database, having about 48,000 records at this moment. This is just a sample, which is downloaded here. We have completed exercise for the majority of the companies. I guess this is an approach which will probably give you a head start somewhere to start into the process of talking about your network.

Thank you so much.

APPLAUSE

AKINORI MAEMURA:

Thank you, very much, Kusumba.

We have already run out of time, but on the other hand, we have some request that we definitely need the Q&A. So for this session, I'd like to proceed in this way.

First, the host would like to present a gift to the speakers. That is first.

Then the Q and A session is going now while the audience go to coffee break. Is that OK?

Then, first, the gift to the presenters.

(Pause)

OK, let's go into a Q&A session and you can go out for a coffee at any time but we still keep on with the conversation. OK, Kurt.

KURT LINDQVIST:

Yes, I'm Kurt Lindqvist from Netnod. This microphone doesn't work. Hello? Hello? Yeah, it does.

So I have a comment on the last slide presentation. I actually think is the worst kind of presentation, I'm sorry to say, but I think it spreads statements as facts without building any operational validity into it or verifying any of the statements in there and I could take quite a few examples but I'm just going to take one. You kept coming back to the fact that IPv6 brings more security and I think this is one of the most dangerous and most hyped-up comments ever. V6 doesn't do anything that you can't do in v4. It does shipped IPsec as a requirement, but shipped code doesn't build security associations, unfortunately. It's as dead as it is in IPv4 because you don't know how to use it.

KUSUMBA SRIDHAR:

Thank you for the comment. I said I'm doing a marketing talk here. I'm not doing a technical talk, my friend.

TAKASHI ARANO: Takashi Arano, Intec NetCore. I would like to make a question to Geoff, OK. According to your mathematical model, just before the exhaustion time, five /8s would be consumed for three months. It's - this rate is about twice the current consuming rate. Actually, do you think kind of, actually, big demand will be there at that time? If so, which area, in which country or which segment, such as ADSL or something like that, would be in demand?

GEOFF HUSTON:

Thank you for that. It's an interesting kind of question because what you expose is actually the other kind of prediction model. What I did is actually look at recent data, trend analysis, mathematical best-fit, project forward. There is another mechanism. And having worked at a telco for a decade, you know, I did get infected. And the other way to do this is to actually do demand extrapolation. How many telephones are you going to need in your country in five years' time? Well, that's pretty easy, actually. Population of the country, natural growth, GDP per capita, you take all of the demand factors into equation and you get an answer. You analyse the demand side. I have not done that. I've just looked at history. However, some things are evident that are interesting. In v4 allocation, the North American region, serviced by ARIN, has been declining in the amount of v4 addresses being allocated relative to the other four RIRs.

Of the other four, RIPE and APNIC each allocate approximately 35 to 40% each of all of the v4 addresses right now. LACNIC and AfriNIC, even though they're growing pretty rapidly, actually at this point don't have a large mass of, you know, a large body of allocations, a large amount of activity.

So, if you are saying, if you do nothing, who is the most likely to be dealing in those last few addresses, statistically. Statistically, it's somewhere between RIPE and APNIC.

Now, let me go - well, what would it be used for? What's the growth models in both of these economic areas? In both cases, the last four years have seen addresses being used to service broadband, retail, DSL-style deployments. In other words, it isn't business, you know, business and corporate. Most of this is actually roll-outs involving millions and it's roll-outs involving, you know, to houses, homes and so on. And the demand for addresses is actually in DHCP pools and in demand for addresses around VoIP services, which, you know, a lot of folk are very nervous about doing VoIP deployments over NAT.

So, if you then say, "Where are these last addresses going to go?" statistically, without doing the demand analysis, but just the numbers say, the numbers say it's going to be deployed either in Europe, probably Eastern Europe, or in Asia Pacific, probably Indian subcontinent, China area, that sort of - or maybe down in south east, where the growth is the highest, those three areas, and probably in a retail broadband deployment, probably with VoIP components.

You can look at populations, growth rates, demand rates, GDP per capita. I'm not sure it's going to help us a lot.

TAKASHI ARANO: Does APNIC have any plan to analyse this kind of demand? Actually, JPNIC has started with this kind of analysis. If you have a plan, please collaborate with us

GEOFF HUSTON:

Thank you for the offer of collaboration. One thing I would say right now is that the work that APNIC has been supporting me in doing, I have been as careful as I possibly can to base every last piece of this work on publicly available data. I'm not using secret data or data that's privileged to APNIC. The information that you, as members, provide APNIC is not used by me if it is confidential information. So I don't know, other than the way you know, how addresses are deployed every time. Like, I look at Whois, you know, I do the same stuff everyone else does. So if JPNIC is using more information than that, I'm not doing that, because I have actually restricted myself to say I'm looking at what we publish, because that way, you can play the same prediction game that I do.

But the offer of collaboration is, indeed, valuable and thank you very much and I will follow up. Thank you.

BRAJESH JAIN:

I would just like to say that IPv4 is going to go away. IPv6, we are not ready. Should we try to work on a model like yesterday where a speaker suggested, where we have a - where we get disconnected from the Internet world and we have all the addresses available us to us and we have our own Internet Exchange Point and all our users are connected to India, of course. Because that is what would be a response from us.

Is this realistic?

GEOFF HUSTON:

We live in a very deregulated world in the communications space. It's a very valuable world, worth a few trillion dollars a year, but it is largely deregulated. We're no longer in a world of command economies. We're no longer in an environment of, say, 50 years ago, where national objectives were clearly phrased as goals and that national enterprises clearly invested against those objectives because that was their charter. So these days, in the absence of a command economy, and in the real world of a deregulated economy of business environments, stating objectives is more a case of stating what you would like to see as distinct from stating what we have to do.

Unfortunately, in economic terms, v6 today remains a business failure, that doesn't mean the technology is bad. The technology is very good. It's not that much different from v4 and v4 worked, v6 will work. The fact that business has not invested in it is a critical observation. And the real issue comes - and it is a dilemma, not just for you and I, but a dilemma for public communications the world over, including regulatory authorities. How do we realign a deregulated business to focus on particular objectives? How do you prod an industry to look where it wouldn't naturally look? Those are very challenging questions. Yes, you can state overall objectives and say, "Let's go here." But people aren't going to invest money in that until they also see rationale. So there's a big question you're posing there and I still claim, as I said to Robert Seastrom a little while ago, the answer involves more people than are in this room and it actually does call into play regulators, economists and many other folk who also have a part to play in this. Business failures are ugly and resolving them requires a lot of work.

BRAKESH JAIN:

Thanks. We need the ambassadors to tell the economists.

GEOFF HUSTON:

I think what we're telling the economists is a subtly different message. We're telling the economists we've got a failure situation on our hands, we're about five years too late, industry has not responded, we really need a response and we've got a difficult situation. Please help. We know where we want to go. But please help. And I think that's about the best we can do but that's a very productive message, even so.

AKINORI MAEMURA:

Please make it concise, please.

KURT LINDQVIST:

To add a comment to my keynote yesterday, I actually said one of the things I tried to say yesterday was that in relation to crisis management, these systems should really, you know, in terms of crisis, you shouldn't rely on systems that work under normal operations so that in the crisis environment, it doesn't have to do anything special and that's the case here as well. You don't want to build a special network. We have to make it work, with the network resources and the network we have today and I think that was part of Randy's point earlier, was that in order to make this transition work, it has to work on what we have today. And it doesn't. And that's part of the problem.

AKINORI MAEMURA:

OK. Thank you very much. This is all for the APNIC plenary. Thank you very much for your attendance and there is some housekeeping from Paul Wilson.

PAUL WILSON:

Yes. Thank you very much for your forbearance and I hope the extended Question Time was useful. It was requested from the people from the floor. We will take a coffee break for the next 15 minutes or so. And come back at 20 minutes to the hour. Before that, I would like to say thanks very much to Akinori Maemura for chairing this session and I would like to present a small gift of thanks.

APPLAUSE

Thank you very much.