Plenary panel
Wednesday 6 September, 2006
09:00 - 10:30

PAUL WILSON: Thank you very much, Mr Chen.

OK, I'd like to now move on into the next session, which is a plenary panel session. And so I'd like to invite the speakers for that panel to come forward. The panel session is about the exhaustion of IPv4 address space and that's something that, well, it's been on people's minds for many years. I think the first that I really heard about it when it hit the press was back in 1990, and I don't think there was much of an Internet press at that time. The story that we heard at that time was that due to class pool addressing, the IPv4 address space was being exhausted very rapidly and it was going to be exhausted within four or five years, which of course would have been well before the end of the 1990s, and that is something that took some concerted efforts by the IETF and others to re-architect the IPv4 address space and introduce different addressing and allow the addresses to last a lot longer.

Probably since the later time in the '90s, we heard a lot more about the exhaustion of addresses as the dotcom boom went ahead and I think at that time, ever since maybe '97, '98, the end of the road for IP addresses was always three or five years ahead and it didn't matter when you heard the story, it was always going to be exhausted within three or five years. And that was something that was a sort of rumour that endured for a long time, in spite of the analysis that some of us did which projected a much longer lifetime for IPv4. In spite of the dotcom boom at the time, the addresses were being deployed at pretty much a linear rate and there wasn't really any evidence of an acceleration coming along.

Things have changed a little bit now, in terms of what the research is showing and these days, we're seeing a bit of an increase, an acceleration in deployment of IPv4 and so people are starting to say, based on real hard figures, that the end of the free pools held by the IANA and the RIRs could be somewhere around 2009 to 2012, so, once again, we see that three- to five-year time frame. I think the difference this time is that we're really seeing in the hard figures that this project may well come to pass.

So we've got, within the RIR world, we've got quite a lot of thinking to do about exactly how to proceed forward from here between now and the time when those last blocks are allocated from the IANA to the RIRs and then from the RIRs to ISPs. And we've got - we can do a lot of thinking about what might happen after that point as well, how will IPv4 address space be managed, how will it be distributed, how will people who need IPv4 addresses get them at that time. And that's what this panel session is all about. So I'm joined up here by two colleagues from JPNIC and also by Geoff Huston from APNIC. And the first speaker will be Tomoya Yoshida from the JPNIC Expert Research Team and he'll be presenting an overview of the issue of IPv4 address exhaustion and the issues around that, so I'll hand over now to Yoshida-san.

TOMOYA YOSHIDA: Thank you. My name is Tomoya Yoshida from NTT Communications. Also, this time, I'm from the JPNIC Expert Research Team. This team was launched last year and we had the IPv4 exhaustion point. And this time I'd like to talk which is title - 'Confronting the IPv4 Address Exhaustion'.

So currently, almost Internet users and services are on the IPv4 network and, when there is sufficient IPv4 address space available, users can obtain IPv4 address space. However, if the IPv4 address space is exhausted, we cannot obtain a new IPv4 address space any more. So, since the IPv4 address space exhausted, new IPv4 address space will no longer be assigned from registries to end-users. Then the IPv4 address space, the IPv4 Internet might be stop deploying, so we should realise this fact and take necessary measures.

So is it really running out? And if so, when? So this graph shows the consumption of the IPv4 address space at August 2005. And you can see that the blue is the concentrated prefixes in the routing table. You can see that upper side shows the IPv4 address space and the left side shows the prefixes of IPv4 addresses.

And, when you see, paying attention to the dotted red line, you can see that many IPv4 address space is increasing among one year. This one shows August 2005, and last month. So many IPv4 address space is increasing. We can see the routing table is increasing that space.

Since 2003, many annual consumption at registries are increasing for the IPv4 address space. Especially last year, about ten /8 IPv4 address space consumption is increasing in 2005. In each registry, there is this consumption in IPv4, consumption is increasing in each registries.

And you can see the two main forecasts of the IPv4 address exhaustion. One is by Geoff Huston of APNIC. Thank you very much, Geoff. So this report in December 2005. So most recent report, we can see that the exhaustion point of the IANA reserve address will be forecasts to 2011 and the RIR pool will be exhausted in 2012.

In another one, big forecast, from Tony Hain of Cisco, so this report in November 2005 and we can see the most recent forecast, so the RIR pool will be exhausted at 2011, so we can see that these two forecasts is very similar and very near the exhaustion point of the RIR pool, when the RIR pool will be exhausted.

So we can get information on when the IPv4 address space will be exhausted, but we don't have - we didn't have the how to prepare for exhaustion of the IPv4 address space in the what is recommendation of the exhaustion of the IPv4 address space.

So we, JPNIC's expert team, released a report called 'Analysis and Recommendations on the Exhaustion of IPv4 Address Space'. And this document was written by a team of nine network operations experts. So we released in April 3, 2006. And finally, the English version was released on July this year. You can get from this URL and also you can get the book - we prepared a book - from the registration desk, so you can please get the whole document of our report. And this document does not focus on the day of the IPv4 address exhaustion. Rather, we offer various recommendations for many people who are concerned about the Internet, like the vendors, or registries, and ISPs, etc.

So this is a part of the recommendations in this report. For registries, each registry involved with IP address space should share a consistent policy throughout the world. For ISP s, they should prepare to provide connectivity with IPv6 when or before IPv4 address space is exhausted. So we put in to this report a variety of recommendations for each Internet users.

So who will be in trouble when the IPv4 address space is exhausted? So you can see the current Internet map, so the upper side describes the servers and the lower side describes the clients. And in the centre, you can see that dual-stack clients and dual-stack servers. These clients and servers are connected to both IPv4 Internet and IPv6 Internet. This is our view of the current IPv4/IPv6 Internet.

So who will in trouble after the IPv4 address space exhaustion? For the client side, so new Internet users can use only the IPv6 Internet because we cannot receive IPv4 address space after the exhaustion. And we cannot access the IPv4 single stack servers that have a wealth of the information and services. The convenience of the Internet for users is provided by that servers, I mean the IPv4 Internet servers. So new Internet users will not be able to enjoy the convenience of the Internet. In other words, the users will not connect to an Internet that doesn't offer any convenience.

So who will be in trouble for servers? So new service providers, on the server side, can use only the IPv6 Internet and they cannot provide services for users of IPv4 single stacks that form a volume zone. Consequently, it has no importance for business and their business will not develop.

So what is the possible scenario for the transition to the IPv6 Internet. So there you can see the IPv4 network and dual-stack servers and dual-stack clients connecting to the IPv4 and IPv6 Internet. After the IPv4 space is exhausted, you can see the IPv6 single-stack clients and the IPv6 single-stack servers there.

But you can see that we have two recommendations for access from the single-stack clients to IPv4 Internet. One is the dual-stack for IPv4 single-stack server. So for the IPv6 single-stack clients, they can access to this current single-stack server, because... these IPv4 single-stack clients can connect to these servers. Another solution is the translation from IPv6 to IPv4, they can access through the translator. And for the single-stack servers, IPv4 single-stack servers, after the dual-stack of the IPv4 single client, so they can access to the IPv6 single-stack servers after the dual-stack.

And also they can access through the translation between IPv6 and IPv4. So these two solutions - one is the dual-stack, the IPv4 client servers to IPv6 and the other one is the translator, through the translation.

So this is conclusion, so please be aware of the exhaustion. So it will come in several years, five or six years, so we need to prepare for the exhaustions and especially ISP operators and vendors need to realise and plan for the ISP to be a dual-stack service and not only the ISP network but the application servers, etc. And it's a pure problem of the Internet operations. So we can coordinate and have collaborations. This is the keys, the coordination and collaboration. So you can get the document from this URL and also you can get this document from the top of the JPNIC webpage. You can get the document.

Thank you.


PAUL WILSON: The next speaker is Akinori Maemura, who you all know as the chair of the APNIC EC and someone who has been involved in APNIC meetings for a long time. He is also a member of the JPNIC expert group for IPv6 and has been involved with work on this topic as well. So Maemura-san.

AKINORI MAEMURA: This is my first time to make a presentation with this PC. It's brand new.

OK. Good morning, everyone. My name is Akinori Maemura for JPNIC and also France Telecom. And I was involved in compiling this report of the IPv4 address exhaustion.

And Tomoya Yoshida has already presented the content of the report itself. So from me, I'd like to present a couple of ideas which I personally think in my mind for the policy considerations during IPv4 address exhaustion period.

Again, as Tomoya said, English version of the JPNIC report is already available in English and it is available on JPNIC website and also the hard copy of this report is available at the registration desk just outside of this room. Please pick it up and have a look and if you have any comments or questions, don't hesitate to make it to us. Just catch me or Tomoya or some other Japanese people, then you can find any comments or answers on that.

First of all, I'd like to review the principles of IP address policies. In APNIC, we have the IP address policy at the APNIC website at add-manage-policy.html you can find that. And the five principles of IP address policy are uniqueness, registration, aggregation, conservation and fairness.

Then first two, uniqueness and registration is quite inherent for the IP address management so the uniqueness is quite, you know, necessary, indispensable for the IP identification and also the registration is enforcing the uniqueness and registration itself. So these are just as important as each other.

With aggregation, aggregation will be less important because of the smaller available space.

Now, regarding conservation, maybe regarding conservation, conservation will be important not only for new assignees but existing ones, especially who hold early big assignments. So conservation has been used for new applicants for the IP address space, but right now we - I think we should also take into account the earlier assignments.

And the last one is fairness. And the fairness is the most important because of very limited available space.

So I will review the latter three points. The first of them is aggregation.

The concept of aggregation is to have the larger block to be advertised to the Internet. So if we need a more efficient aggregation, we will need larger allocations. On the other hand, if we think after larger allocations with limited address space will result in a smaller number of allocations. So some will obtain an allocation and some will miss the allocation. So lucky ISPs will hold and unlucky ISPs will miss in the case of limited address space. So first aggregation will be respected less than the fairness and conservation.

Conservation - also I would like to say efficient use. The current policy allows an assignee, an Internet user, to hold "as many IP addresses as the assignee actually needs" if they can demonstrate their needs. Then, when we are running out of IP addresses, can we ask applicants, "Please get less IP addresses than you actually need"? This is the question. But, in that case, I think that should be asked after an enabling technology is available. Then, the answer would be no, we can't. And on the other hand, Internet operators are aware of the hoarded-up IP addresses. So when we release the JPNIC's report in Japanese in April in the JANOG meeting, some Internet operators voiced their opinion - "Oh, IPv4 addresses will never exhaust if the class-A addresses are returned to registries." That's one of the many, you know, famous rumours. But we know that that is not true.

Fairness. Fairness is very, very important when we share a limited resource. It will be unfair if lucky ISPs hold and unlucky ISPs miss. Then, and also it will be unfair if someone needs to struggle to squeeze the efficiency of the IP address space use while some others do not need that, do not need to struggle, but just put them into their infrastructure.

So here I have the two ideas to present in front of you and I'd like to call for your thoughts. It is not so much a discussion, but just a primitive idea. I don't want to urge these things.

One thing is how about charging for all IP address blocks? So charging for all IP blocks in a uniform fee schedule, even for the earliest assignments, like class-As and class-Bs. So I mean that, for example, in the case of a class-A, that's a /8, that is in the case of the APNIC membership structure the /8-holder is an XL, a large member and it is charged at US$40,000 per year. In the case of the /16, they would be the medium member, and they are charged US$5,000 in the case of APNIC. I think this will bring the consistent sharing of the cost of the IP numbers management. So that means if we can obtain fairness between earlier and later allocations. And also it can make an incentive to return unnecessary IP addresses and it makes efficient use of the unused IP address space which is already assigned to the assignee.

I know that this idea cannot be shared or cannot be agreed on by everybody. I mean I've already had objections on this idea. But I think this is - still I think this is a good idea. That's why I am presenting this.

And the second thing I'd like to present is the last-minute fairness.

OK, let's imagine the last block allocation. What should be happened? I think that, you know, maybe the many IP address users want to have another blocks, so the interest of obtaining IPv4 address will conflict. And actually, IP address is needed for the IP network installation so the network plan is almost with the same with the investment plan into the network should take into account the amount of available IP address, if they know that IPv4 address is quite limited, then adjustments will be done much earlier than the last minute.

So I think of one - this is also a primitive idea - but how about a patent office model? So, in the patent office, they accept a lot of patent applications and such a patent application will be pending till that patent will be accepted by the patent office. So, in this case, I imply by the world patent office model, that all applications will be disclosed more or less, for example, the address size and the date and the address site or something like that. I don't think that disclosing every information is not so reasonable. But anyway the existence of the application itself will be disclosed in this patent model, in the patent office model. And then this will help the applicants to see the trend of the consumptions earlier than the address space is consumed. Then it should be working for - working to have carriers realise the exhaustion and to be cautious about the IP address consumption to the exhaustion and so that they can plan their network design with the amount of the available IPv4 address space.

So here I presented my two primitive ideas and, based on my considerations on the five principles of the IP address policies. Thank you very much.


PAUL WILSON: Thank you, Maemura-san.

Geoff Huston is next. As I'm sure you know, Geoff has spent many years with Telstra and ARNET in Australia before joining APNIC two or three years ago and he's continuing his wide range of research work with a new hat on, with an APNIC hat on and that's including, of course, the ongoing analysis of IPv4 address space and consumption. So Geoff is going to present something about bones for us.

GEOFF HUSTON: Thanks, Paul, and good morning, everyone.

As Paul mentioned earlier, this discussion about the consumption of IPv4 addresses has been going on for an awfully long time and inside certainly the Internet Engineering Task Force I seem to recall that it was around as early as 1990 or 1991.

Now, there are two kinds of presentations on this subject. There are real ones and there are fake ones. The real ones you can always spot because somewhere in the presentation they predict the imminent death of the Internet. So I would humbly suggest that this is one of the real ones because you've got to start right up front by saying the end of the Internet is indeed predict and it will be on bit torrent tonight at around about 11. So with that done let's move on to what I'm trying to talk about.

I'm trying to have a look into the future and try and understand in my own dim way what's likely to happen within a relatively short period. It would be really nice for me to say, "Look, you're going to have trouble and you're going to have trouble in the latter half this century and I'm going to be dead. I don't care." Unfortunately, I don't think I can make that prediction. I don't intend to live that long but I think this is going to be trouble not only before I'm dead, but before I'm even able to retire. So, yes, this is a me-and-you kind of problem.

So we need some tools to try and figure out what's going to happen. And we have a rich history. Excel spreadsheets are one way. In the Cameroons, one of the ways is to whack a mud crab inside a pot and then put a few things around it, let it out and see which way it crawls, which I think is pretty cute. And there's Tarot as well.

But up here in the National Palace Museum in Taipei there is a remarkable little section of the museum which is one of the earliest forms of writing - oracle bones. It's interesting. You write down some potential answers on a bone. Tortoise shell was used, I think at the time. You hollow out a little bit of the bone so it's slightly weakened and throw it on the fire. At some point the bone will get hot and with a dramatic snapping noise, a crack will appear in the bone. And the crack will point to the answer. Because of all the possible answers, there will only be one crack and it will tell you which way it's going.

Let's try it. The first thing we need to do is set up some questions. So I've got a modest set of questions here which I think encapsulate most of the problem. You know, when is this going to happen really? Why are we worried about it? If it really is a problem and we should worry about it, what are the options? What will happen? And what does it mean for you and me? So those are the modest questions. I'll tackle them and offer some potential answers to scribe on your own oracle bone.

When? Well, there are still people out there running Fortran, God bless them. I'm sure there are people who keep the ghosts of IBM 360s still supplied with electrons. I'm sure that v4 will run for decades to come. It's certainly going to exist for a long, long time. So the death of v4 is not on the table for any time soon.

So it's not really the death of the v4-routed network that you're really concerned about. We're here in an APNIC meeting. APNIC's an RIR. A genuine stock in trade here is we hand out addresses. When will we have no more to hand out? Currently, the way we're consuming them over the last three years, it looks like, across the RIR system, the first RIRs to exhaust will exhaust some time between 2010 and 2013. Hard to say. A lot of it depends on you. If you feel you need more addresses tomorrow, we might exhaust faster. If you're happy with what you've got and don't need any more for a while, it will last longer. It's your call. But the way you're behaving collectively says that some time between, say, four and seven years from now, APNIC will have nothing more to give out.

When you come to APNIC and say, "Please can I have some addresses?" the answer will be "Like to say yes. Nothing to give. Sorry."

But APNIC itself and the other RIRs get their addresses from a pool in the sky managed by IANA. So the next kind of question is, well, when does IANA run out? When does the entire framework of using unallocated addresses and deploying them start to exhaust from the top down? IANA will probably exhaust about a year earlier than the first RIR. So some time between three and six years, we're going to see IANA run out. So this is looking relatively soon. You know, six APNIC meetings away if you want to look at it that way. It's not a problem that you can ignore.

Why is it a problem? Because the distribution model that we have chosen to use assumes this infinite pool of space in the sky that effectively meets demand, this large reserve. And if you don't have that reserve, you can't meet demand. Unmet demand will increase. Folk will need addresses and they won't be able to get them. In classic marketing terms, in economics, this is in effect placing a scarcity premium on IPv4 addresses.

So it's a problem because, even as Akinori suggested in the previous suggestion, the classic way that you express scarcity is pricing. Where demand exceeds supply, price escalation is a common outcome in classic market theory and indeed in classic market practice. What's happened to the price of petrol in the last year? Hmm, demand exceeded supply, the price went up. It happens all around you all of the time.

I'm not sure that this is any different in terms of classic distribution markets. When price goes up, costs to suppliers go up, costs to users go up. Some folk will no longer be able to afford them. This is not a good thing. This is going to cause additional costs, ultimately, that some end consumers will have to pay and other consumers will be unable to pay.

So then when you start talk about equity of distribution, about efficiency of distribution, effectiveness of distribution systems, of fairness, it's highly likely that the outcomes are going to be undesirable, they're going to be unfair. That is probably not a good thing. So that could be a problem for you.

So OK, let's ask the oracle, inscribe it on the bone, what's going to happen? At the time when APNIC can't give any more out and you're still going to want to route IPv4 - you're not going to shut down your router on that day, absolutely not. You're not going to turn away your customers, absolutely not. You're not going to shut down your business, absolutely not.

Where are your addresses going to come from? I've put down here three options and I think all of them are going to play out in their various ways. We're going to start using addresses more parsimoniously. We're going to use them more strictly. We're going to try and conserve them. We're going to use NATs. We already use NATs like crazy so this is simply saying reality will continue.

I also suspect that when the RIRs have nothing more to give away there are still folk who will need and require addresses in v4 and their demands will be met by money. Trading markets will appear.

And of course the third option is, you know, you might deploy IPv6, truly.

Let's have a look at those in a bit of detail. NAT port translator - will we deploy more? Well, highly likely. How much will it cost? This is a very interesting question because right now most Internet service operators don't pay for NATs. Customers do. They put it in the router. NATs are now consumer commodity devices. The cost of NATs in terms of service provision of an ISP's budget are externalised. They're free. Customers pay for them. Service providers don't. That's pretty cool.

What services can or cannot be offered? Well, this is interesting because, if you and I sat down in a little room somewhere and thought about some great new application and it didn't work through NATs, we might as well forget about the conversation then and there because if you can't deploy an application today that works through NATs, you can't deploy the application.

Applications today, popular applications, applications that are deployed, are NAT-agile. So the real question with this is how long can we last on NATs? Hmmm. Are they viable in the short term? Well, if you said no, I think you're in reality denial mode. The reality is that NATs are viable today. They're extensively used around the Internet. They support a viable subset of Internet services. No you can't do anything with a NAT, you can do only some things with a NAT, but that happens to be the same things that some folk appear to want to do and already right now NATs influence the way applications are being built. You're already seeing rather than me and you and an application, it's me, my agent, your agent, the rendezvous broker, the tunnelling application and so on that works through this.

If you've ever used some of those 802.11 phones you'll find a huge amount of the software inside the phone is all about traversing the NAT. We're already influencing application architectures right now. NATs are the reality in the short-term Internet.

Let's look further - long-term. I mean decades, not years. Are NATs viable for decades? Centuries? Wow, interesting question. Most people, certainly in the IETF, abhor NATs with a fervour that can only be described as religious. NATs are evil. In fact worse than that - NATs are satanic. Why? What have these poor things got to do that deserve such an amazing amount of approbation? What's going on here?

The real issue is not the NAT as far as I can see. It's the fact that the IETF many years ago refused to standardise NATs. NATs are random devices on the wire and they do random things to packets, depending on when you bought the NAT and who you bought it from. The application designer is living a nightmare. How do you know what type of NAT it is? How do you know what it's going to do with your packets? That's why that poor little phone has to do such an amazing amount of work.

Could this be fixed? Absolutely. Standards are there to help new this respect. But I don't think that's the long-term problem with NATs. The long-term problem is a deeper architectural issue and it's about complexity bloat. Once you start trying to ring other people's doorbells in the presence of NATs, you've got to make application-specific identity domains. You've got to do a whole new set of application-level technology. You've got to start making the NATs aware of the application, that is, traverse them. I think then about trying to deploy a new application if every NAT in the world needs a software application. Life becomes tough. It's damn difficult, and difficult to run reliably, let alone securely. Once you start threading your NATs - so it's me, my NAT, your NAT and all the others - your brain will explode, as will the network. As far as I can see, the long-term future of NATs is relatively depressing because they can't be deployed ad infinitum.

What about trading markets? How will they operate? How much do v4 addresses actually cost now and how much will they cost in a market? And are the outcomes of such a redistribution function routable? Well, you know, trading markets exist everywhere in the world. It appears to be human nature. It's the way you equilibrate demand and supply, buyer and seller. "I have some addresses. I'm not using them. I can convert them to capital. You want some addresses. You have capital. You might be prepared to buy them." This happens in all kinds of commodities - oil for one, water, electricity, all kinds of things work in markets. But markets aren't perfect. Markets can be distorted. You can try and corner the market, hoard it, raise the price. There is price uncertainty in markets. Buyers can be made captive.

You may have players who actually don't want to use the resource, but speculate on it, buy it, wait for the price to rise and then sell again. There is probably regulatory intervention required. Most markets inside national economies are regulated. What about international markets? Markets where there is no national regulator around? How do you phrase regulatory intervention? Controlling the market? Trying to minimise the risk? Underneath that, how do you route the resulting address redistribution. Will these small fragments of addresses be routable?

Same two questions - short-term, long-term.

What's the short term? Will it work? My guess is probably yes. Trading in address markets is viable. It's a conventional distribution function that we actually understand quite well, interactions between buyers and sellers. The price reflects the scarcity and the price reflects the ability to increase the efficiency of an address. In other words, if I buy an address and it costs me a lot, I might use it in a NAT situation simply to make it work across more customers. Now, the problem is that you might start fragmenting the existing aggregation of addresses. Routing could suffer. And it's not really clearly understood what the interactions are here. But in the short term, in a few years, I think trading is probably a viable outcome. What about the long term? Hmm.

Certainly trading exposes an incentive to reuse it. The buyer will be highly incentivised to use it very, very carefully but there are cost elements going around. There is uncertainty of price. How much will the price of oil be next week? Who knows? If you're an oil company now, price uncertainty is a massive factor in your business. If you're an ISP in six years' time still doing v4, price uncertainty might be a massive factor in your business.

Because there's one thing markets can't do - and that's called magic. You can't make the finite infinite. There is only 323 bits of v4 address. There are only 4.4 billion unique tokens. There are no more. No matter how much you buy and sell, you can't make it 4.5. Markets can't make the finite infinite. In the long term, trading markets can't keep the v4 Internet alive indefinitely.

What about v6? Well, you know, how much will it cost? How long will it take? When will customers and services transition? When can we stop doing a two-network model? When can I stop the legacy cost moving to v6? Those are the kind of questions that I hear from industry. Is it short-term viable? I don't think that's a question I can answer with any certainty. If you deploy v6, will your customers out there in customer land pay you more money simply because they can colour their packets red or green? Will they pay you more money to have v6 as well as v4 on tap? Highly unlikely. So as a service provider, if you choose to deploy v6, you will do this without revenue. You will not be doing this to gain greater share of the market or charge your customers more. You will be spending today's money for a future for tomorrow.

Now, in a heavily regulated communications industry with government players, those kind of arguments play beautifully. When I joined Telstra, the ex-monopoly player, I was amazed to learn that in 1986 they had started planning for the year 2000. My God. Know, regulated players with monopoly positions can afford to think very long term and splash their money around. I'm not sure many industry players are spending money for problems that are going to happen the year after next. Competitive markets are tight. Discipline of competition leads to short-term focus. There is no long-term money. Almost every major telco in the world have shut down their research labs. They are no longer investing in a future.

So is a revenue-less investment in the future going to happen from industry? Short term is a damn hard problem for this industry. I'm not sure they can do it. Long term, if you can get there, it's a nice place, you know, if you actually ever manage to figure out how to get this, it appears to be OK.

I suppose one of the reasons why it appears to be an OK place is there isn't a viable alternative. You can't run NAT PTs forever. You can't do address trading forever. The only thing hanging underneath your nose happens to be v6. So in an act of desperation, that's all you've got. It offers really compelling levers and I'm sure many of you have heard these already. The IPv6 demonstration of what you can do has been around for a long time and the slide packs are well used, heavily coloured and highly animated, but the message underneath it is probably real - utility networks servicing massive user bases, it will, work. The gains are long term.

What are the implications then? You're not going to turn off v4 and turn on v6 on a massive day in the future. There is no flag day. There will continue to be IPv4 demand well beyond exhaustion. That's obvious. But the mechanisms of address distribution will change and being able to influence outcomes in some way and try and create outcomes that are fair, that are equitable, that preserve the routing state are not necessarily there once you start buying and selling between yourselves. The mechanisms of management of that address distribution function will change. And the co-existence that you're going to be sitting in is going to be more expensive than where you are today. Running IPv4 markets, deploying more NATs in more critical ways, putting in more infrastructure inside your network and trying to deploy IPv6 adds up to dollars, cost.

So for network managers, you really do have a problem and you should try and grapple with it. Understand your projections of growth and try and match that to when do you think addresses will be available and how much will they cost. What kind of forward planning over the next, oh, four years, are you going to do to understand what this transition is all about? For product and service vendors, this is going to require something that I think for them is amazingly novel, something they've never tried before - trying to figure out what customers will need rather than trying to figure out what customers wanted last year, actually trying to think ahead of the market rather than lagging behind it. This will be a big challenge for that sector. It's not something they're used to doing but they'll have to do it because you need different services and equipment and you need it now.

And for regulators and policy-makers, if you thought the other two had a tough job, I'm afraid, jeez, you're up the creek here. Phrasing clear objectives in a regulatory framework with clear and unambiguous signals to industry players will be an extremely difficult challenge. The existing efforts we see in a number of countries to try and figure out how to guide industry through what has the potential to be a relatively savage disruption is not easy. And so far I am not highly confident that these folk are actually managing to grapple with the problem in meaningful ways. More work is required. But, you know, the major key to looking at the future is actually understanding the past. And if you look at it, what we're looking at is no different from many other crises.

And there will be disruption. It wasn't be seamless and it won't be costless. And we're going to apply the same human behaviours that have always been deployed. In any crisis, there are a number of phases. Firstly there's denial - "Crisis, what crisis?" Then there's panic - "Oh, my God. The sky is falling." Then there's anger - "Bloody hell! Why is it falling on me?" Then there's blame-shifting - "It's your fault the sky is falling on me. It's all your fault. Fix it." Then there's bargaining - "If I pay you lots of money, will you make sure that the sky doesn't fall on me?" None of this works. Ultimately, you've got to figure out that the sky has indeed fallen on your head and that's life. Acceptance. Get on with it - Recovery. And once you've got past it, shift the blame to someone else and claim you knew it was always going happen all along, you're perfectly aware of the situation and the other poor sods didn't try and figure it out - Revisionism. And where are you? You are here (indicates Denial on the screen).

Thank you.

PAUL WILSON: Thank you, Geoff. We have about five minutes for questions before the morning tea break or a little bit longer if we have enough questions. So would anyone like to start off? Do we have any questions? There is one mic in the middle of the room and maybe a roaming mic if you don't feel like standing up.


RANDY BUSH: Leave it to me. I don't even need a mic.

Randy Bush, IIJ.

When you said that the pool suffered, when there's the split IPv4/IPv6 network, you said the v6-only users won't get access but as the number of those users increase, there will be people providing services - Amazon is not going to be happy not being able to sell books to those people. So it's both sides - the v4 Amazon is going to be unhappy not being able to sell books to those people. So there's going to be a major force to move dual-stack revisioning. Do you think that? Do you believe that? Do you really think Amazon is going to sit there on IPv4?

PAUL WILSON: This is a question for Tomoya-san?

RANDY BUSH: I forget whose foils it was.

GEOFF HUSTON: It wasn't mine.

RANDY BUSH: No, not yours.

AKINORI MAEMURA: Um, yes, I will be happy if Amazon and Google service the IPv6. That's very clear. The problem is that the key will be service providers - I don't mean the network provider - the providers who provide the services on the Internet should be... need to be IPv6-accessible. To allow such service providers to enable IPv6, the network provider must equip the IPv6 to deliver it to the service providers and also the users. So the most key part of that deployment plan is to have the network service provider to equip IPv6 and provide it to the service provider and also the Internet user in a very reasonable price, just like a comparable price with IPv4-only service. So in my dream, the Internet connection service will be upgraded to be IPv4 and IPv6 dual-stack with no price increase. That's my dream., if it is realised, then the services on IPv6 will dramatically increase. But I don't have any good solution to have that network provider to equip IPv6. I think that's the key for solving this question.

PAUL WILSON: Thank you, Maemura-san. We have five or ten minutes so let's cut off the line at the three who are there.

JORDI PALET: Jordi Palet. I agree with Geoff that more and more the providers are not planning ahead and I think that's part of the big mistake because, in the transition to IPv6, if you plan ahead, of course, how much time depends on your own network. The cause can be very, very close to zero including framing cost and so on. It's a question of how is your time cycle.

I also think that, if we look for a model where maybe changing the policy now for let's say one year or two years and a new IPv4 location mandates getting also an IPv6 allocation and getting it in production, that will mean probably we will somehow push for setting up more and more dual-stack services and that will maybe slow down the IPv4 consumption if we can convince and even I am not happy with that, maybe the only solution is to start to deploying more NATs for IPv4, even at the provider's network, just to keep some basic services like those web servers that could not be upgraded to IPv6, which I doubt, but maybe there could be some situations. So this way, existing services, basic services, could continue working almost forever, which NAT and IPv4 and only new applications and services will require IPv6 support.

So this way, we have a model where we have NAT, which the old services, which we know they work already today with IPv4 but any new services will require different connections at the same time and so on can keep work being IPv6. So the question here is do you think it will be possible to suggest to the community maybe not just in this region but of course in other regions to look for a policy change to let's say push a little bit for the real adoption and deployment of IPv6 every time somebody else is coming for new IPv4 addresses?

PAUL WILSON: I think that was the topic of Maemura-san's presentation - what are the possible policy directions that we could take and these are matters, of course, for the community and for anyone who is game to make some presentation if they have a specific idea. Geoff?

GEOFF HUSTON: The concern I think in looking at policy proposals right now is an observation that over the last few years we have a policy process which is deliberative, thorough and slow. And you've got to ask yourself at what point does this become an overtaken-by-event proposition? At what point does a positive proposal become swapping around the deck chairs on the Titanic simply because it's too late? And there are some real issues here about the timing of these events and the way in which we do policy proposals and the time we take to work through it that appear to be sort of at opposite ends of the spectrum and I'm not sure that a mad flurry of policy proposals in the last couple of years is going to change an awful lot of the situation. So that's, I suppose, the balancing, that by making a policy process that is open, fair, deliberative and very thorough, we've made a process that is slow to react and that's a counterbalance.

PAUL WILSON: And I guess, Jordi, you're aware that there are were proposals early on that IPv4 should simply be exhausted to promote IPv6 deployment and, whether deliberately or not, that seems to be what we're doing. Tony?

TONY HAIN: Tony Hain from Cisco.

It would actually be useful to have Geoff's graph back up. I think that's probably a bit challenging.

So everybody remember back to Geoff's graph, and the state where shifting blame occurs, and I think that's something that the APNIC community needs to be thinking about. Because as we get further down this road, people will start shifting blame and saying, you know, "RIR, you didn't tell me that this was going to happen. I've run out of IPv4 addresses and you didn't give me sufficient warning." And they're going to try and shift the blame. So this community needs to think very hard about that early on and start paying the utmost attention.

To the point of fairness at the last block, we've actually been giving some thought to that and one thought I had was to change the policy for IANA to the RIRs. It's currently 18 months of pool. If that were lowered to six months of pool, then you would, you know, end up with a better distribution amongst the RIRs in that last block. You wouldn't have one that could possibly get a year or twos' worth of pool beyond what everybody else has.

I'm not sure, as Geoff's pointed out, whether by the time we get that implemented it would have an impact.

SAMANTHA DICKINSON: I have a question from Jabber chat. "Hello. I am in Switzerland. I have some ideas for a new Internet Protocol architecture. One of the benefits of this proposal would be the smooth interoperability of IPv4 and IPv6 address hosts. My question is how do I proceed in finding people who are interested in discussing and exploring these kind of ideas?"

GEOFF HUSTON: The standard response is set up a mailing list and see who comes or set up a webpage and see who comes. Ideas and fermenting ideas to gain popularity to actually gain critical acceptance to get other folk to look at it has been an age-old sort of topic and predominantly around research institutions. And I'm sure there are many folk who have a whole set of quite wonderful ideas about how to make co-existence better. We have seen many of them in the IETF in the past and certainly if the questioner wants to go to the IETF and move their idea there, it would not be the first or last time that would happen. Equally, there are many fine conferences where these kinds of research ideas are discussed. But there is a huge amount of peer review and critical acceptance to go from an idea to a working concept and that's the tough bit.

PAUL WILSON: OK. One final last question.

SPEAKER FROM THE FLOOR: This is my first time at this kind of meeting, so my question is a little bit stupid or something, but I'd like to ask some questions.

Now, I'm wondering whether we should install or support IPv6 because I think IPv6 multihomed is not decided. Have any ideas to support IPv6 multihomed - please let me know, how to support IPv6.

AKINORI MAEMURA: That's a good question. Yes, actually the multihoming provider for that address is not fixed yet.

My personal idea is that - my idea is just that Tomoya presented, that we need a dual-stack Internet network. So to realise that, we need to install IPv6 along with IPv4 network, along the IPv4 network, existing IPv4 network. Then that needs, definitely needs the provider-independent address as well as IPv4. So that's my belief, that we need IPv6 providing that service. If we have that, then multihoming is quite as easy as IPv4.

PAUL WILSON: OK. I think we'd better break for morning tea. We're running into the morning tea break. So we'll be doing that for the next 20 minutes. Just before we break, however, I'd like to say thanks to the panellists for an interesting discussion. This is something which, I think as everyone agrees, needs a lot more attention among the APNIC members and community in future.

I do have a few small tokens of appreciation for the plenary speakers, including Mr Chen, the Vice-President of Chunghwa Telecom. So I'd just like to present those before we break for morning tea.


OK. We're going to break for morning tea. We're scheduled to reconvene at 11am. I suppose we might take five minutes into the next session, given we're running a little late now. The next session will be APOPS and I can see Philip shaking his head at my poor scheduling right now. Please come back by 11:05 at the latest, sharp, for the APOPS session which is going to go for the rest of the day.

I would like to say thanks very much to the people who've come to attend the meeting online. There are quite a number in the Jabber meeting rooms and on the online webcast. So please stay with us. We'll all be back in 20, 25 minutes. Thank you very much.

(End of session)