IANA Workshop: IPv6 28 October 2007 ICANN Los Angeles >>LEO VEGODA: Hi. We're about to start -- Hello. Good afternoon, everyone. My name's Leo Vegoda. And welcome to the IANA workshop at the 30th ICANN meeting in Los Angeles. I think this is the third workshop we've done focusing on IPv6. As before, anyone who wants to use the chat area from the remote participation Web site at public.ICANN.org to ask questions, post comments, or to use the blog facility on the public.ICANN.org Web site, feel free. We'll try and monitor that throughout this session so that we moat participants can interact with the people who are going to be on the stage today making some presentations and participating in the discussion. This is the agenda we have for this afternoon. We've got two sessions. Session 1 is going to be focused on policy, and there will be a coffee break after session 1. And then session 2 will have an operational focus. Okay. Right. So that's the agenda we've got today. We'll be here until about 5:30, hopefully. And then break for drinks and stuff you like that. The first session is going to start now. We've -- we're going to have three panelists, Paul Wilson, to my right. Paul Wilson is the director general of APNIC, the Asia-Pacific Network Center. Also Mark McFadden, to my left, your right. Mark McFadden is the naming, numbering, and addressing strategist at British Telecom. And he's going to talk on behalf of ETNO, which is the European Telecommunications Network Operators Association, of which BT is a member. And to my far right and your far left is Joel Jaeggli, who is the Internet technical architect -- is that right? >>JOEL JAEGGLI: Yeah, and Internet technical architect. I'd rather (inaudible). >>LEO VEGODA: Okay. And Internet technical architect at Nokia. Well, I think we should probably get going with Paul Wilson's presentation. And -- >>PAUL WILSON: Thanks, Leo. I'm Paul from APNIC. I should apologize in advance, I arrived here this morning at 7:00 a.m., five hours before I left home, with a 12-hour flight in between. So making sense of anything is a bit of a challenge, let alone IPv6, right at the moment. So I'll also see if I can get my computer to reflect on the screen as well. I had a minor technical problem with this laptop hitting the road outside the airport this morning as well. But it has been working since then. Supposed to come on automatically. It worked just a minute ago. >>LEO VEGODA: While Paul is getting the presentation to present, I'd like to make an announcement to let people know that this session is being translated into three different languages. If you don't speak all three of those languages in addition to English, there are translation headsets available at the back of the room. And if you want to ask a question in one of the languages that the translation will be provided in, if you could pause after making your first statement, that will allow our stenographers to switch the channel on their headsets so that they're getting the English from whichever language you're speaking. And then if you could then continue so that we can get a good transcript. Okay. >> (inaudible) please make those announcements in the different languages as well. >>LEO VEGODA: I'm afraid I'm not able to make the announcement in other languages. >> You don't need to. We have interpreters here for that purpose. And they're -- so whatever it is you want to say, they will each interpret into their own language so that if somebody needs a head set, they can go and get one and follow along. Do you have -- is there a microphone that we can -- >>LEO VEGODA: Any of the microphones up here. >> Any of the microphones. Oh, over here. >>LEO VEGODA: Go ahead. (Translation). >> I will now make an announcement for the Spanish-speakers who might be in the room. (Translation). >>PAUL WILSON: Okay. Thank you very much for that display problem start, apologies. It at least gave us time for the crowds to amass, which is nice to see. I'm from APNIC. APNIC is the I.P. address registry for the Asia-Pacific region. This part of the panel is about policy issues, and in our community, we tend to talk about policy as in address policy. I'm not going to be talking particularly about address policies in any detail, but, rather, trying to illustrate that the current state of IPv6 deployment, which as we all know is fairly slow at the moment, actually has very little to do with I.P. address policies. It has to do with other issues, such as industry policies possibly and industry behavior and so forth. But if anyone particularly wishes to talk about I.P. addressing policy, it's not really going to be a topic here, but maybe we've got some time for questions afterwards. I'm really going to be looking at the evolution of the Internet under IPv6 as we see it today. And as an I.P. address registry, I can at least talk with some certainty about one thing, which is where the IPv6 addresses are today. So I've got a few charts here which show us as of yesterday where the I.P. address -- IPv6 address distribution is happening according to the shared data that is available from all of the RIRs. In these slides, I'm showing you a distribution of IPv6 address space by region. And you can see here on the left that the RIPE NCC in Europe is responsible for nearly 50% of the IPv6 prefixes that have been allocated, APNIC in the Asia-Pacific for just under 25%, under a quarter, ARIN for just over a quarter, AfriNIC and LACNIC a little bit behind. This chart shows the number separate independent prefixes which have been allocated. And each such allocation is made for a particular ISP or a particular purpose. So it shows in some -- to some degree the extent and the distribution of IPv6 activity around the region. We can break that down according to country codes. And I think some will be a little surprised to see that the United States is way up in front there, with just 391 separate prefixes having been allocated to it by its regional Internet registry, that is, ARIN, followed by Germany, Japan, Britain, Netherlands, et cetera. As I say, this is -- a chart illustrating the number of prefixes. If we actually look at the IPv6 address space distribution, we get something very different. And that's an artifact of what's happening with the size of address prefixes which are being allocated by the RIRs these days, where we have most commonly, we have quite small prefixes being allocated, and just in a small number of cases, we have some very large prefixes being allocated, of at least a thousand or more times the size of the minimum prefix. So if you look at the distribution of the number of prefixes themselves, then you get that quite distinctive spread with the U.S. out in front. But if you look at the amount of addresses which are actually allocated in each country, you find quite a different distribution. But this is a little illusory, because the locations to which the very large prefixes are being allocated at this time, I don't think they show any particular useful trend. For instance, in A! ustralia, there are two very large prefixes which have been allocated. And that puts Australia up in the third country on this list. And in any one of those countries, we might have applications coming in for a number of very large prefixes, which would change this distribution quite heavily. So I'm focusing, actually, on the number of prefixes which indicates the number of organizations who are receiving IPv6 address space and the number which -- whether it's a large or small prefix that they received, would be likely to be participating as an IPv6 provider or participant. The historical trend shows some interesting growth patterns as well. We're not seeing IPv6 take off in really significant ways yet, as you can see here. In fact, we've had some up and down years over the past years, with 2003/2004 being, in some respects, busier years than -- certainly than '05 and '06. And still the amount of activity that we have in 2007, which is only several hundred prefixes in total being allocated around the world, is really a tiny amount of activity. And we would hope that in future years, very quickly, we would see these levels of activity really accelerate to the extent that these early trends actually become quite meaningless. So what I've shown through with respect to I.P. address distribution actually doesn't -- also doesn't show you where I.P. addresses are actually being used. And what we have to do is look at the routing table to see whether IPv6 addresses are actually appearing in the routing table at all, and if so, to what extent. So here is a chart showing since the beginning of 19- -- sorry, 2004, the size of the IPv6 routing table. And we've seen in that period, since 2004, the IPv6 routing table growing from a total of 400 to an extremely underwhelming total of just around 1,000 IPv6 routes at the moment. Compare that with IPv4, and we've gone in the same period from 120,000 routes to 240,000 routes. So that represents the number of independent address blocks which are appearing on the routing table. And you can see the difference in style between the V6 and the V4 networks there. Likewise, we can look at Autonomous System Numbers, which represent the number of independent networks which exist, which have gone up from 300 to 800 in the IPv6 network, from 14,000 to nearly double that in IPv4. So it's quite interesting that you see similar sorts of growth curves in IPv4 and IPv6 -- in the IPv4 and IPv6 Internets. Without looking at the numbers, you might think things for IPv4 -- for IPv6 are going quite well, because the growth rates look healthy. But when you consider that we have something like less than 1,000 prefixes in IPv6 compared with 240,000 in IPv4, we've got a very long way to go before this IPv6 network becomes the predominant network that's going to take the Internet to its next phase of evolution, which is what we keep hearing about IPv6. So I think the question we would ask is exactly why is this happening, why is it taking so long for this much-needed upgrade to actually eventuate. And it's really got to do with the fact that the Internet today, which you could call the interNAT, is engineered for very low rate of consumption for IPv4 addresses through the use of network address translation primarily. And the entire Internet, in fact, is engineered for the use of network address translation. You've all probably had to configure a peer-to-peer client, like Skype or something else, to access the Internet through your firewall, in other words, to access the Internet through your network address translator. The popular applications which are in use on the Internet today are all architected and designed specifically to run on the network address translator-dominated Internet that we see at the moment. And one of the things that Jordi and others who are advocating strongly for IPv6 are talking about very correctly is that the use of NAT on the IPv4 Internet is -- imposes a huge penalty on the performance of the Internet itself and the flexibility of applications on the cost and the complexity of the applications themselves. But the critical problem we need to face here, or the critical question we need to ask is, exactly who is bearing the cost and the pain for the so-called supposed problems on the Internet. And quite critically, it's not the ISPs who are bearing the costs for network address translation, and even, therefore, for the IPv4 address shortage. You know, the end users, yourselves, by your NATs and your firewalls, and your struggle with them to make them work, and you don't really have any choice but to do that. And luckily for you, the applications are pretty good at making everything work through those translators. And it all seems to work. In fact, one of the downfalls of IPv6, if I can call it that, is that the major effort towards IPv6 transition is precisely to make the Internet look exactly the same under IPv6 as it does under IPv4. So if anyone's waiting for a user demand, it's not going to happen on that basis. So the other thing is what's happening in the ISP industry. I mean, things have changed quite dramatically over the last ten years. There's really no more competition or no intensive sort of competition in the ISP industry. They've shifted their focus, the Internet industry itself has shifted its focus away from ISPs and into content services and applications. The mass market deployment of the Internet itself has got really marginal rates of off return. ISP products aren't really differentiated these days. We hear a lot of sort of value-added talk through triple play and NGN and those sorts of things. But those new technologies in the ISP market have failed to really achieve any differentiation that would help to aid competition in that area. So we've got a situation of stasis in the ISP industry at the moment with very low margins. And poor capital return. And pretty conservative and sluggish industry, frankly. So they consequently, and understandably, are quite resistative to really doing any major investment in evolving the I.P.-level services that they provide. The problem is really the reality. The IPv4 Internet works well. IPv6 is also stable and well tested. There are plenty of technical issues being debated, but -- and what that is is providing, I guess, a certain level of uncertainty as to where IPv6 is actually going. Meanwhile, in the business side of the industry, the network address translated dominated IPv4 network is working perfectly well. The industry has externalized the cost of address scarcity and of the need to cope with the Internet as it's evolved, as its architecture has evolved. There's not much investor interest in developing more architecture. Some people are saying IPv6 is something we have been talking about for a long, long time now. Maybe there was too much v6 promotion too early and it's sort of tired rather than wired these days. So the result being that the short-term business pressures just support the case for deferring IPv6 deployment further and further. There just isn't a linkage between the added costs and complexity and the fragility of the network as it's on NAT-based applications. There's not a linkage between those costs and the costs of actually deploying the infrastructure of IPv6 because those costs are borne by entirely different sectors. And at the heart of it we are not seeing the expected evolution that was going to happen, supposed to happen from IPv4 into IPv6 in an elegant, sustainable, transparent, invisible sort of manner. And it's arguable that nothing much is changing or about to change in the foreseeable future in terms of this evolutionary approach. So in this part of the presentation, what we have been -- what we have been trying to do is to promote what the IPv6 Internet could look like and where we might go from an evolution -- How we might go from an evolutionary to a more revolutionary transition to IPv6. The IPv4 revolution really corresponded with huge advances in the 1990s to, in terms of silicon technologies, density of silicon, the cost of bandwidth and the cost of operations of ISPs. The fact that we had a PC revolution, which again was funded by the users. It wasn't a cost that the network itself had to deal with. So the Internet boom sort of happened for free. It was the cheap and dumb network which allowed everyone to participate. Technical and business innovation happening at the ends of the network. And huge rewards for new services and innovation at that time. But these days, the 2000s, we've got commodity lean and mean Internet service provision. We do have massive reduction continuing in the cost of electronics. You only have it look at the cost of DVD players and almost anything that you use in your home these days. And we have really got a network-ready society. So the promise here is for a boom, not in terms of the Internet for everyone, as the Internet society likes to say, but more like the Internet for everything. And where we have a device dense world with device populations, possibly a thousand times the magnitude of today's Internet, we also have the possibility for an Internet that is that much larger. Unfortunately, there's not a hell of a lot more money around these days so we have also got to look at costs being two or three orders of magnitude lower per packet, and that's something that the Internet industry certainly needs to face if it's going to fuel an IPv6 revolution of this type. But, really, we could be looking at billions or even trillions of devices. Geoff Huston found this thing called the iPot, which he called the iPot, an Internet connected water pot or coffee pot that he found in Japan and he thought it a very good way to check to his parents to make sure they were okay in the morning and making their tea on schedule. But the prospect of having this level of connectivity, this level of ubiquity is really what we should be promoting within the discussion about IPv6. So in conclusion, the challenge that we have is there still really are not enough features or revenue levers in v6 to drive these new investments in new service platforms. But the silicon industry had made its shift from value to volume years ago, and this is where the Internet industry itself must follow. And which will be enabled by IPv6 if only we -- that is, the industry -- can get on with that job and provide, work towards a true utility model of ISP service provision. So that's all I had to say. And as I mentioned in the beginning there is very little there in terms of I.P. addressing policies. We don't hear that I.P. addressing or address policies are any kind of a barrier or any kind of an issue these days in terms of how the IPv6 Internet is growing. If there are any questions about that, I would be happy to answer them, but I should probably hand over to my next panelist. Thank you. >>LEO VEGODA: Thank you, Paul. Before we hand over to the next panelist, maybe I can ask you if you could let us know how you think what seems to be a market failure -- that seems to be what you described. If you could let us know how you think maybe that should be addressed. Where is it appropriate to address that market failure? >>PAUL WILSON: You want me to answer that now? >>LEO VEGODA: Yeah. >>PAUL WILSON: I'm not -- I think you do hear commonly that this is a market failure. But I'm not sure that it actually is a market failure. The market is doing exactly what the market is supposed to do in terms of looking at where costs and benefits lie. The market is not very good at looking to the future. And this is a question of short-term costs versus what are actually quite long-term gains relative to the speed or the expected returns on these things. So I think it's not correct to call it a market failure but it is an outcome of the markets acting as they are that could go on for some time unless there's some, maybe, regulatory intervention or some much more effective call to arms and call to action on the part of the ISPs. Now, the issue that we do have, as I think everyone knows, is that IPv4 addressing, as the available address space is running out over the next three or four years, there's going to be a real necessity to move. And that necessity could be rather chaotic. So I think this is a time in which, in accordance with probably more expected periods of foresight, reasonable planning windows is where ISPs really definitely should and could start moving much more decisively toward IPv6. At least I hope so. >>LEO VEGODA: Okay. Thank you. In that case, I think, yeah, we should move to our next speaker, Mark McFadden. As I said, Mark McFadden is the naming, numbering and addressing strategist at British Telecom. And he will be speaking for ETNO, the European telecommunications and network operations -- operators Association. That's a long name. And looking at what is a successful policy for IPv4 exhaustion, which is obviously one of the key drivers for IPv6 adoption. Do you want to present from this laptop? >>MARK McFADDEN: Or I could just have you press the buttons and follow me here. >>LEO VEGODA: Excellent. I will be your button-presser. >>MARK McFADDEN: It's a dream come true, Leo. [ Laughter ] >>MARK McFADDEN: Excellent. My name is Mark McFadden. As Leo said, I'm from British Telecom, but today I am representing the European telecommunications network operators. This is an organization of 44 different network operators in Europe. In many of the countries in which they work they are the dominant or largest ISP. And it's great to follow Paul because, really, one of the last things he talked about here was that there is a transition that is coming between the old protocol, and I really do mean very old. IPv4. And IPv6. And in an IPv6 workshop, it's really helpful to have someone sort of point to the existing statistics and say, "Well, look, we're not doing very well here." And what's happening is we are not getting the take- up that we are expecting, and what kind of drivers could be out there that would actually change the rate that we would take up IPv6. One of the last ones Paul pointed to was the idea that the available address space, or what we call the free pool for IPv4 is being depleted fairly quickly. And the time line for that depletion, depending on whose models you believe, is between three or five years. In that time, we certainly have a period of transition. Now, the IPv4 Internet, as we know it, will never go away, or I think it will be many, many years, and certainly the four panelists up here will be long gone before it ever goes away. But in its place I think what we will see is an Internet where IPv6 and IPv4 share the stage, if you will. And there will be a transition period here as we move from today to when the free pool is actually exhausted. It's that period that I want to talk about. And it affects IPv6 and it also affects the way that we do policy work for IPv4. And so let me talk to you a little bit about that transition period, if I could. And this is a failure of my button-presser. I lived so long for this -- look at that. The numbers for IPv4 exhaustion in this transition period are actually pretty well understood. There are many independent models. Several of them very famous. Several of them being done by individual companies. But almost all of the models point to a very similar conclusion. And that is in the next three to four to five years, in that time frame, the available free pool for IPv4 address space will be exhausted. It's a transitional period. And it's a period in which, when any finite resource comes to the end of its supply, you could expect many, many different actors to be interested in that period. It's very important for European telecom operators, though, because, again, they are, in many cases in Europe, some of the largest ISPs who are in operation. Now, my goal here is not so much to talk about the exhaustion models themselves. There's lots of public sources for that information. And while both Paul and I can give you pointers to that, and Leo as well, this talk is not so much about the exhaustion models. It's what to do in that period of transition as we move from now until a period in which we have no more IPv4 addresses to dole out of the free pool. And using that as a means to sort of coax the uptake a little more broadly in IPv6. So one of my goals here is not really to rehash the exhaustion model but to simply move forward and talk to you about some policy issues that Paul didn't talk about. One of the things in this transition period is that you can imagine that the people who work with addressing policy have come up with many, many different policy proposals for dealing with IPv4 exhaustion. And I can say, although at a recent meeting I had this question, I can say that I think really, right now, there is no global consensus on any single proposal. And what we see is, we see sort of a gradual development of an attitude towards perhaps a combination of proposals and approaches should be used to meet the needs of these intervening years in the transition. Now, obviously, this is a good conversation here at the ICANN meeting, but it's also a topic of discussion at every RIR meeting around the world. There are five Regional Internet Registries, and it feels like I have been to all six of them recently. But at the most recent meetings last week and the week before that, this has been an important part of the conversation that that community is having. One of the things to realize, and one of the things that's important to me in this last bullet, is that while we continue to talk to each other, while we continue to work in the bottom-up processes that these RIR organizations are so used to, the pool continues to get used up at nearly a /8 any month and a half or two months. In the European Telecommunications Network Operators organization, there have been discussions for the last year and a half, almost two years now, and the discussions are led by a group of experts, a group - - (tires squealing). >>MARK McFADDEN:That's my car. A group of people who are interested in numbering and addressing issues, who are very concerned about that. One of the ways in which ETNO works as an organization is different from other organizations that we're used to in the Internet. In the Internet, we have a concept called rough consensus that many of our organizers -- organizations use as a means to gauge agreement. That's not the way things work in ETNO. When ETNO has a common position, absolutely everyone has to agree to it. It's a very intriguing way for an organization to work. But a common position inside of this organization means that 100% of its members agreed to it. So when I talk about the five principles for which -- that we should use in the period of transition, what's intriguing about it is that these -- all of the organizations who are members of ETNO have agreed to these. Now, I'm going to go through, actually reasonably quickly here, five principles that we should use to manage the transition between IPv4 as it stands now and the exhaustion of the free pool. The first of those principles is this one. Each of the RIRs has, for many, many years, an existing policy development process and an existing IPv4 allocation process that has been in place and served our community very, very well. What ETNO thinks is that a key principle in the remaining time for the v4 free pool is to not abandon the RIR processes. There are other organizations who would like to step in and help. I mean, anytime that you have a period in which people say, "Oh, we're coming to the end of the lifetime of X," there are always people who are willing to come and step in and help. But ETNO doesn't support that. ETNO would like to see the existing RIRs who have done such a good job of shepherding the IPv4 address space for so long be the organizations that take the lead here. So we don't want to see this move outside of the traditional I.P. community. Also we would like to see, if we can arrange it, a government intervention in the allocation of I.P. addresses. This is a hard thing to arrange because sovereign nations are interested in their own nation's needs, and rightfully so. On the other hand, as addresses become in short supply, we can expect that governments and regulators would want to express an interest. That's natural. On the other hand, what we would like to see is that the processes that the RIRs have for doling out addresses remain the same. The needs-based allocation that we're so familiar with. The next thing that ETNO says is that the existing RIR processes, as they currently stand, work just fine. There are lots of IPv4 exhaustion proposals that suggest set-asides or count-down periods, and all of these actually have the effect of exhausting the free pool even quicker than if we simply followed the existing RIR processes. So what ETNO believes is what we should do is in this period of transition, simply use the allocation processes as we always have for the IPv4 pool. There should be no special processes, no special rules put in place, and no set asides. Because the set-asides only stand to exacerbate the problem to make the date closer. One thing worth noting here is the IPv4 policies, the v4 policies that the RIRs have, are actually proven. Things like CIDR have served us well for years, the needs-based allocation processes have worked well for years. And there is no reason, at least from ETNO's point of view, that we should change those. This slide has been controversial every time I have put it up in front of people. And it's intriguing why that might be. Let me explain what some people's point of view would be when a commodity becomes scarce. As a commodity becomes scarce, what can happen is that people will actually -- the value of the commodity will gain, whether that's monetary value or some other valuation that you could put on that commodity. If the commodity becomes liquid in some sense, or fungible that you can actually trade it, sell it or things like that, then what emerges is a marketplace. And it seems natural to think that what could happen in the event of a shortage of IPv4 addresses -- and what I mean here is a shortage of free addresses available in the pool for further allocation -- that a marketplace could emerge. That people could buy and sell I.P. addresses. Now, the RIRs, as a matter of policy, say that IPv4 addresses are not property. But if we stepped into a world where they became scarce and people wanted to trade them, or they started to become -- start to have value, we would be in a world that is very, very much different from the world we are in today. ETNO believes we should resist entering into a marketplace for I.P. addresses and for addressing. That a marketplace is actually contrary to the principles of conservation, the principles of fair play, and the principles of restricting the size of the routing table that Paul showed you a few minutes ago. You can see that the routing table for IPv4 stands at nearly a quarter of a million routes. Now what you can imagine is people would be injecting new routes at a rate much higher because the value of small bits or small prefixes would be much greater. We think -- ETNO as a group thinks that marketplace ought to be resisted for the reasons that are in the first bullet. But also, the entry of a marketplace for IPv4 could really cause us to gain the attention of folks who have not been part of the addressing community in the past. The ascension of a marketplace might mean regulators could get involved. Speculators could be involved as well. So what we think is that we should avoid that. That that's actually contrary to the basic principles under which the addressing system works. And that the RIRs as a group, and their membership especially, should identify actions that meet the goal of resisting the entrance of a marketplace for addressing. In support of that, ETNO is very much in support of needs-based allocation from now until the end of the available free pool. Just as we have always done. We don't believe there's any need for set-asides, either geographic or political. And what one of the things that this does is actually prevent a situation where, towards the end of the free pool, we see I.P. address shopping amongst the five RIRs. We don't want to see certain RIRs punished because the needs in a certain region are greater than the needs in another region. And so what we would like to see -- and that would invite even further intervention than the intervention that I talked about a few slides ago. There are competition issues there as well. How would we ensure that there was a free marketplace in the absence of needs-based allocations. So ETNO as a group is very supportive of sticking to, for now until the end of the free pool being available, sticking to an approach that continued to use needs-based justification for allocations from the IPv4 pool. Finally, the fifth of the principles deals with address policy. And I'm glad that Paul didn't take my fire here. He certainly could have. But one of the things that we want to work to ensure is that if new IPv4 policy emerges, it should be done in the same context, using the same policy development processes that we already have in the existing RIRs. There shouldn't be, because we have this period of transition between now and the end of the free pool, and as we try to encourage people to take greater use of the IPv6 space, we don't need to have special processes, we don't need to have special policy development activities inside the RIRs. The RIRs can use the policy development processes they already have. For my community, for the ISP community and the telecommunications community, one of the things that we need is predictability. And one of the things where the set-aside proposals sort of fall down is that you don't know when that date is going to actually appear. If you follow carefully the allocations of /8s from the IANA into the RIRs, you have a much better view of when the free pool is going to be exhausted than you would if you had to watch for a particular set-aside date to emerge. One of the things that we think as an organization is going to be crucial is better and better information sharing. All of the RIRs do a very, very good job of setting aside statistics. One of the uses of those statistics are the models that we have talked about. And the visibility of exhaustion is certainly increasing. What we need to do is actually do better outreach to the communities who are not here. Better outreach to their regulatory community. Better outreach to governments, better outreach to media, so that they understand, as they hear the story about this transition period and they hear the story that Paul is telling about IPv6 take-up, that they understand the background to it and what it really means. The emphasis here is that we need to talk to more than the addressing community. We need to talk to more than the group of people who is in this room. We need a much wider community who we reach out to. One of the things that ETNO has suggested in Europe is that there be an independent model for the IPv4 exhaustion activity. What we have is a collection of many, many independent models that really verify against each other fairly well. But perhaps the RIRs could take on as a joint-commissioned activity the development of RIR-sponsored model. There is also the issue of leg it was is I blocks. And some of you have heard of this story, that people who have IPv4 address space but who are not using it could perhaps recycle it or return it. The rate at which that could happen is actually relatively slow. In fact, I would call this sort of picking up nickels in front of a steam roller. What's happening is that you would get small pieces of space that you could recycle, but in the end, the date at which the address space is going to run out is still going to be very close. You are not going to change that very much. The recycling activity, though, is definitely consistent with the mission of the RIRs. And ETNO as a group would like to see it continue. One of the things that we would like to see is, besides a continuing effort to recycle unused addresses, the potential to reach into the pool and add other /8s to the global free pool. Finally, two last slides here and then I am done. One of the things is that, sitting up here and talking to you from the point of view of ETNO tells you something very important about what's going on in the European telecommunications community. That they are talking about this. They are talking about the issues that Paul talked about. They are talking amongst themselves about how they are going to move to IPv6. And they are especially talking to each other about how they are going to manage this transition period between now and when the IPv4 addresses in the free pool are unavailable. But one of the things that ETNO is very, very determined is to actually work within the RIR communities that are actually working on this. It's a very broad group of people who are working on this transition period during this period of IPv4 depletion. And so ETNO is going to continue to be at RIPE. We are proud to be here at ICANN talking about these principles for how policy should be developed in this period of transition. And finally, those five principles are the ones on this slide. And I won't re-read them to you, but basically, what we're talking about is that in our community, we have this period of transition between now and when the IPv4 exhaustion of the free pool takes place. That's a period in which we have to be very careful about the policies that we bring to the table for IPv4 users, and it's a period in which we have to do repeated encouragement of the community to start to move to IPv6. Paul said that very eloquently. And so we need to work on both hands. ETNO is working in the IPv4 space, and has released a communal statement, really. All of its members have agreed to these five principles, and will continue to work both on this transition period and also on the period -- during the same period to enhance IPv6 take-up. >>LEO VEGODA: Thank you very much. That was a reasonably controversial, I suppose, presentation. I think I would be failing in my duties if I didn't ask whether there are any questions for Mark from the floor. >>MARK McFADDEN: Thank goodness, there aren't any. >>ANDY LINTON: My name is Andy Linton. I come from New Zealand, I work for a metro service provider there but I am also involved with the New Zealand -- the .NZ name space. And I am also involved with Ron and the Internet exchanges in New Zealand but I am totally not wearing any of those hats, really, at all. I have a couple of questions. I missed Paul's talk, I came in at the tail end of it, but one of the questions we have, in relation to the sort of marketplace thing, we have got a block of v4 addresses which is relatively small. And would have us normally in the small membership category. When we apply for v6 addresses, we move to the next tier up so there is a financial disincentive for us to take some v6 space. So that's one little one. And the other one I would wonder about, would it be useful for -- when v4 allocation is done from now on, you just got v6 address space with it, because if you have justified having v4 space, then you really should -- then you should be entitled to a relevant block of v6 address space so that you can make that transition without having to go back again and go through the process of having to do allocations. On your topic about why people hold onto IPv6 address space and the marketplace, they are holding onto it because they think it's going to have value. And I know you say you don't think a marketplace should appear. A marketplace is already there. People do trade IPv4 addresses and exchange money for them and it's done sort of under the counter and so on. But you get people who say "we have taken over this company" or "we're now looking after their networking," and I know it goes on in New Zealand and I'm pretty sure it goes on everywhere else. So that marketplace is already in existence in an under- the-table sort of fashion. And the final one, I would think, ISPs should do this and do that, and the other with making sure the address space isn't traded, because I think that's the implication here, that if address space is traded, ISPs should say, "Oh, no, we won't write that space for you." There's really no incentive for an ISP to do that. An ISP will say if somebody rocks up with a piece of address space that's been traded and moved around, they'll say, "Yeah, we will take your business and write those blocks for you and we really don't care what the registries say or don't say." The registries might like to think they have some clout there, but in general, they believe with ISPs. They don't really have that clout at all. So the v4 stuff, as you say, is going to start to run out. I believe that people will trade it. And the v6 thing will not happen as quickly as people believe it should do. I am not convinced of that. So that's my ten cents on it for you. >>MARK McFADDEN: Maybe let me just say something about the marketplace. Definitely this has been the most controversial slide out of the this group of slides. And I think every time that I have given this presentation, someone has brought up the fact that the marketplace already exists. And I would acknowledge that a black market probably does exist in IPv4 addresses, but I would say that it's small. And one of the things to know about that is that I think ETNO's position is that we should do nothing to encourage it getting any larger. Because you could imagine a venture capital -- if you believe the scenario that people buy and sell companies for the IPv4 address space, which I find -- which I find apocryphal would be the polite word, imagine a company that had several /8s that was an ISP and then a venture capitalist came in and bought the company and got rid of all the customers, increasing the shortage for IPv4 address space, upping the value of the space, and then turned around and sold the prefixes as /20s, the danger to the routing table there is really significant. So I think we should do what we can to discourage that. There is nothing we can do about an existing black market. On the other hand, I would not like to see the RIRs, for instance, sponsor their own version of eBay for address space. >>ANDY LINTON: I agree with you entirely, mark. I'm not saying this is a good thing. I think it does exist. But the question, really, for me, was -- sorry, I've lost my thread. I'll leave it at that. >>DAVE PISCITELLO: Dave Piscitello, ICANN security and stability advisory committee. I think it's very dangerous to characterize people who are going to create a market or take advantage of, you know, existing class A addresses as an example, as a black market. There are a number of Fortune 100 companies -- in fact, I've consulted for some in my prior position -- where the company actually set itself up so they would have an Internet registry of its own for whatever class A it had. And the purpose was to be able to manage what they consider an extremely important concept of add, drops, and deletes of business units, acquisitions, divestitures under an umbrella of addressing. And in that process in some cases they would add B's, they would add another A. And what they're essentially doing is stockpiling because they were anticipating the future and they want to minimize the harm to their own organization. So it's not strictly or exclusively a blackmail. And I think that once you get to talking about this, you have to be very careful to identify what characteristics you consider blackmail versus self-interest. Or black market. Sorry, black market. >>MARK McFADDEN: Blackmail is what the next speaker would like to do to me. I think -- let me acknowledge again that I think a black market does exist. It's the size and scope of that marketplace that I think I would challenge. And the folks who think carefully with what a marketplace might mean about prolonging the period of transition, I'm not sure that a marketplace is going to have a significant effect on that transition period. >>DAVID CONRAD: David Conrad, ICANN. I actually have a question related to sort of the future. The ETNO position appears to state that things shouldn't change, things should go as they are until free pool runout. It leads to the question of which free pool are you talking about. And, second, what happens after the free pool runs out? >>MARK McFADDEN: The answer to the first question is that the ETNO position talks about RIR free pool. So the point at which no -- to put it more bluntly, the point at which the RIRs are not in an ongoing position to allocate requests. >>DAVID CONRAD: Okay. So ETNO is stating that, as I understand it, there are regions that will run out of address space much later than when the Ripe region will run out of address space, so ETNO is stating that they will not be obtaining address space from other regions? >>MARK McFADDEN: Yes to the first of those statements. But I see a distinction between the first and the second. So say the second one again. So does ETNO think that there will be different run rates in different regions? The answer is yes. Does ETNO have both global and regional organizations that are members that would have networks in various parts of the world? Certainly the answer is yes there as well. Would -- >>DAVID CONRAD: Would they use address space from the other regions to provide for -- >>MARK McFADDEN: There's nothing in the ETNO position that talks about that. But I would imagine -- and now taking my ETNO hat off and taking my BT hat and putting that on, I can certainly imagine if BT had a subsidiary in Uruguay, that it would apply for space from LACNIC. >> (Inaudible.) >>MARK McFADDEN: No. >> VINCENT NGUNDI: I'm Vincent Ngundi from Kenya, KeNIC. I'd like to disagree with one of the five principles of ETNO. And that's with maintaining a status quo when it comes to the policies in the different RIRs. I don't think the current policies we have -- and I'll zero in on the AfriNIC region -- are efficient when you're looking at getting the IPv4 exhaustion. I think we need to make changes to the current policies. They're not sufficient. We really need to think about that. And from -- only have five principles to say that ETNO wants to maintain a status quo when it comes to the current policies, how do you think that will help? >>MARK McFADDEN: It's -- how do I think it will help. I think what it does is it preserves -- it preserves a predictability about the end of the transition period. It does not insert any new policy for that period. So I think it helps -- I think it helps in those two ways. The second thing is that it ensures the addressing community who is watching the free pool deplete has a much better view, rather than having a set-aside where we say, "At a certain moment, we're going to distribute around the world address space," it gives greater predictability to that end game. >> Vincent NGUNDI: I agree with you about the predictability. But we need to encourage the community to deploy IPv6 at the same time. If the policies are predictable, that's one thing. But policies that encourage the community to deploy IPv6. >>MARK McFADDEN: I think that has to go on in a parallel process, that it's -- that's a separate task from managing the IPv4 depletion transition. >>LEO VEGODA: Okay. I can see Jim and Andy at the microphone. I think I need to close the microphone after Andy has spoken so that Joel can make his presentation before the break. And we will be back after the break. But if -- after Jim and Andy have spoken, I'll give the floor to Joel. >>JIM REID: Thanks, Leo. Jim Reid. I'm not wearing any particular hats in this particular discussion. I've got to disagree very strongly with the question, two of the points that you've made, mark, and I think first of all I'd like to say I think it's unfair to characterize the existing trading in I.P. address space as a black market. It's certainly being done without, say, the RIR system. And there may be elements of addressing going on within the RIR system, say, for example, where one RIR is brought over by another. So there may be a trading of this kind of stuff going on just now, so I don't think it's really fair to characterize it as being completely a black market in the sense that it's illegal or wrong. It's maybe something we perhaps feel wasn't happening, but we will see more and more of it as address space becomes more scarce. So I think one of the challenges for the Regional Internet Registries is to figure out how they can legitimize this trade, but to try to put it into some kind of altered state. And there obviously is also kind of public confidence issues there, too. For instance, if someone's selling address space, how does the buyer know that the seller has the right to use that address space and vice versa? So there's all those kind of concerns that would also come into play there. And this is also for the schemes that have been proposed for address certification. That could have an impact on routing issues, too. Talking of routing, you're quite right to say that the potential for treating an address space could create problems with growth in the routing tables because of lack of aggregation or the increased amount of deaggregation of addressing. But that tends to happen anyway, even within the RIR system. And, again, there was a study that you might have seen, you might remember from Amsterdam last week, where Niall (saying name) models tend to suggest that any kind of trading of address space even between the RIR-allocated blocks is likely to be lost in the noise as far as routing the aggregation's concerned. Now, maybe we could question his numbers, maybe we need to do more there. But if Niall's predictions and suppositions are correct, this is maybe not such a big problem as we think it is, but perhaps, again, we have to do some more analysis about it. So I think it's unfair to say that this is going to cause the sky to implode. One final point is to give you a really hard time here, mark, is to pick up on what David Conrad said, I find it very, very hard to believe that if BT cannot get I.P. address space with ripe NCC that they would not find some way to game the system by setting up some kind of operation in another part of the -- there are plenty of addresses available and user's addresses, and route them globally. I think it would be very, very surprising if they got addresses from LACNIC and only used them in South America. And I think that's another aspect also to look at for any future use of a market, if there is going to be a market in address spaces, how we can try to prevent people gaming the system. So perhaps not talking about a black market, this is how we must prevent it, but perhaps we have to recognize it is a market, but have it operate in way which is reasonably fair and reasonably immune to abuse so you don't have the kind of things you spoke about where a venture capitalist! comes along, acquires a company to get ahold of the address space and then auctions off chunks of it, /20s to the highest bidder. And this was something that our market had a degree of control for the RIR system could perhaps prevent. >>MARK McFADDEN: Oh, don't leave the mike. Let me talk about your third point and then your first very quickly here, because I know Leo wants to move on. As far as -- I won't personalize this and pick on my own company. But as far as an organization that ran a global network, any organization that runs global network is aware of the statistics that are in Paul's presentation. And any organization that runs a global network is aware of what's happening with exhaustion. It's far more likely, it seems to me that those organizations are going to, in the very, very near future start to make large requests of all of the places where they have networking requirements. And it's -- I think that is what you're much more likely to see than a redistribution of the use of those addresses. I think a run on the bank is much more likely. >>JIM REID: I agree with you, mark. But I think there will be circumstances where, say, for lack of strategic planning or unexpected growth that's come about because of some new service that's evolved, there could be an unexpected need for addresses. And an organization - - not to personalize it -- but an organization can find they can't get the address space from the regional Internet registry, but there's another RIR in some other part of the world that's got addresses and they'll go and get them there because of no choice. >>MARK McFADDEN: Okay. And point taken. And the first point of yours about the black market, I'm going to stick with the term for the time being. You haven't talked me out of that. But one of the things that I'd like to challenge you on is the difference between the existing marketplace that takes place as a result of mergers and acquisitions and the potential for formalization of a marketplace. I think there's a big difference between the two. What we're talking about here is the potential formalization of a marketplace. That's -- I think that the existing -- for instance, in the RIPE region, the existing policy that's on the books for transfers works well in the cases of mergers and acquisitions. It makes sure that the RIR has records that WHOIS can answer to for who actually is using the address space and so forth. What I'd like to avoid and the place where you see as a real difference is a formalization of that marketplace with active traders, arbitrage, and so forth. That's the difference for me. >>JIM REID: Okay. >>ANDY LINTON: I'll be very quick, Leo. Just to come back on this market thing, which is, I agree with you, pretty controversial and important that we sort of try and get some framework around this. The thing that drives -- you know, you are saying this market isn't -- I'll use the word "market" and not "black market." This market isn't well developed at the moment, that's because going to a registry and getting a block of address space is still relatively cheap, a few thousand dollars a year. It's not hard to do. One of the things that will drive people to pay more for that is as the address space gets depleted and it's harder to get them from registries. People will weigh up, if we get back to the -- they will weigh up the cost of acquiring address, V4 address space by whatever means against the cost of transition to V6. And for a lot of organizations, the cost of transition to V6 is extremely high, because they have to buy new equipment, they have to do training, they have to hold -- they have a whole set -- if you're an ISP, it's hard enough to get help desk staff that understand anything about V4, and it just doesn't get multiplied by 4, the difficulty, becau! se the address space is four times bigger. So those are the economic drivers here that will prevent this. And the one thing that really makes address space interesting and useful is whether it can be routed on the core of the Internet. That's the only lever there is to say you can or can't do this thing. Because if I can get my address space routed on the Internet, it doesn't matter what the RIRs says. As long as the ISPs will do that. That's the key to T I can give you all the V4 address space you want right now. But if you can't get it routed on the network, it's no good to you. So that's the place where the lever has to happen, not necessarily with the RIRs. It has to be done in conjunction between the two. >>LEO VEGODA: Okay. That was a good discussion at the mike. There's opportunity for more discussion at the end of this session. We've got one last presentation now from Joel Jaeggli, who is an Internet technical architect at Nokia. And he has some thoughts on IPv6 deployment in enterprise and ISP networks. I'll pass the mike to Joel. >>JOEL JAEGGLI: Yes, I'm going to try and keep this pretty short. The last time I gave this presentation, it was 90 minutes. So blissfully, it won't be that long this time, I hope. So my presentation may actually come across as being -- You know, having a slant against public policy, but this is really originally aimed at operators. And I think it's really important for the public policy community to understand what it is that operators are going to face, because operators are the constituents of, you know, the RIRs that are going to actually use address space and assign it to end users. And they're the ones that are grappling with IPv6 transition issues. So please do debate me. If we don't have time at the mikes, corner me in the hallway or get me on e-mail or something. This discussion is very important to me and to our business in the future. That's why I'm here. So the agenda is aimed at understanding the current environment, transition, or lack thereof, deployment, what a deployment looks like for a large Internet service provider or an enterprise network, some conclusions on that, and some surprises, things that we didn't expect with IPv6. So understanding the current situation. Predicting the moment of IPv4 exhaustion has obviously become a fairly popular spectator sport. You can see a presentation on it in your local gladiator arena or professional wrestling venue anytime you want. Any business that consumes I.P. address -- I.P. addresses in the process of growing has a problem with IPv4; right? It doesn't matter when or if or how much in the context of runout. Shareholders and customers will likely be fairly unhappy when told that this new liability affects the ability to grow the business. IPv6 is not the only solution, of course. One possible alternative is not paying attention at all. Banking on the IPv4 runout and the creation of a market is obviously another approach, if you happen to be the Hunt brothers. So to steal a Geoff Huston quote from his article, the end of the IPv4 world is NIGHer. This is not one of Geoff's famous graphs, this is one of Bob Hinden's famous graphs. As you can see in the bottom right-hand corner, we have around 48 /8s remaining. And this graph goes back all the way to January 1981 because, of course, Bob's memory is a little bit longer than most ISPs. So the RIRs are, by and large, doing their job. Their job is to hand out I.P. addresses to constituents based on need. And, in fact, they've been doing that. So you can see the growth of the IPv4 Internet reflected in /8 allocations from IANA to the RIRs. The provocative but boring statement here is, we actually ran out of IPv4 addresses in 1992. Andy Linton, who is probably old enough to remember numbering point to point links with /24s. CIDR allocation was at least partially in response to the assignment of lots of /24s from the swamp into the IPv4 default free zone. But the reason that lots of people got /24s at the time was because there weren't enough /16s and /8s left to hand out. So we would have actually run out of IPv4 addresses in 1994 in the absence of CIDR. So here we are 13 years later, and we still have some. If you're new to this situation and many network operators are in fact new to this situation, they've just woken up and discovered that they're going to -- the fact that they go back to the RIRs every six months for IPv4 addresses is not going to hold them in good stead. If you're new to this situation, the best place to learn about it is not RIR public-policy mailing lists. There's a lot of acrimonious debate about the runout. Mostly this is fighting over the remains of the corpse. Operators are unable to divine future direction, if any, from the content of the mailing lists. And that is actually, I think, a serious problem, because what I -- what businesses look for in a regulatory environment or a public-policy environment is some degree of certainty. They can manage change if they can predict it. So as an operator, obviously, don't throw up your hands because there are 70 messages titled "those pesky ULAs again." Focus on the things that you can do. And this is critical. Secure resources that you need for your business to grow and prosper. The liabilities that ISPs are faced with immediately are an inability to secure additional IPv4 addresses due to exhaustion, changes to RIR policy pushing the date at which securing new addresses becomes harder closer to the present day. Right? So that means, you know, instead of looking four years out, you have to look two years out and start worrying about it. Widespread IPv6 deployment never occurs and IPv4 is what we're stuck with. That's a serious liability. Transition. Dual-stack deployment is not going to slow the consumption of IPv4 addresses. Full stop. The fact of the matter is that more devices will have to share proportionally fewer IPv4 addresses. This reflects how you're going to build networks. That means NAT, multiple NAT layers, and NAT boxes with the same addresses in use on both sides. And if you think that's fantasy, you can find it today in many enterprise networks. There's a knob in our firewalls to enable it. The killer app for IPv6 in ISP and enterprise networks is 96 more bits. It's not applications, it's not some new wazoo feature, it's not IPSec. It's more bits. Increased use of NAT in correspondingly shorter leases in the course of dynamically assigned V4 addresses seem inevitable in growing IPv4 networks. Greenfield deployments are getting more challenging when large amounts of V4 addresses cannot be acquired. So if you're a cable MSO or a DSL provider or a telecommunications company that deploys these cell phone things, the fact that you have somewhere between 10 and 100 million devices to connect to your network over the next five years is going to be kind of a problem. IPv6 addresses are available in sufficient quantity to produce stable bindings for as long as a host needs a particular address. Peer-to-peer applications, which is not just file-sharing, mind you -- that's any application that needs end-to-end connectivity -- benefit from IPv6; right? IPv6 can preserve, if desired, end-to-end reachability. There are a lot of situations in which end-to-end reachability is not desired, particularly in enterprise deployments. The first order of business for all enterprises is, continue to fly the airplane. When you're debugging a problem in an aircraft, the thing that the instructions continue to remind you to do while you're looking through the manual is fly the airplane. Many airplanes have been flown into the ground by people troubleshooting relatively minor problems. For ISPs and enterprise operators that are growing their operation, that means maintaining a supply of IPv4 addresses based on RIR guidelines. So in the ARIN region, for example, that means going back every six months when you need more; right? So keep your documentation up-to-date and continue to engage with the RIRs as long as possible for V4 addresses. It is widely presumed, though not inevitable, that address allocation policy will change sometime between now and the last allocation of a /8 from IANA to the RIRs. So in the -- in the case of set-aside policies that might push the deadline where policy changes occurs, you know, up rather dramatically to, say, something that's rather close around the corner, like 2009 or 2010 as opposed to, you know, a projected runout date that was, like, 2011 or 2012. A substantially amount of the histrionics and specter -- whoops. -- and specter that V6 deployment is engendering on operator and standards process working groups, that is, you know, issues that are coming up regarding flaws in deployments, a lot of those are the product of experience gained through the operation of the 6Bone and early IPv6 networks. So those are not necessarily issues that you would expect to see in new deployments. So that would involve issues like disconnected IPv4 dual-stack hosts on IPv4 networks, not being able to reach V6 hosts. There are people on the basis of these sorts of problems willing to suggest throwing out all V6 work and starting over from scratch. Obviously, there's no timeline for that. This is sullen inertia and foot-dragging. One of the things I look at is the Everett Rogers diffusion of adoption model because I think it's highly applicable here there are a lot of people in the late majority and laggards who are -- for whom early deployment is going to cause cognitive dissonance. And it's not until we get well into the early adoption stage or the early majority stage of a given technology adoption that perception of the possible success of this deployment becomes widespread. And I think we're still very much in the innovation and early adoption phase for IPv6, despite being ten years on, more or less, in deployment. So a safe and sane deployment plan for enterprise looks pretty much like this: Secure resources, focus on the core, work on transit and peers, that is, actually getting the thing announced; eat your own dog food in your deployment. Work on early services, deployment to the edge, and applications. And I have at least one slide for each of these. What I'd say here is, for enterprises and ISP networks, you can experiment all you want, but experimenting only gets you so far. You know, you can fire up a tunnel broker on your laptop and get IPv6 addresses today. But that doesn't really tell you a whole lot about how it's going to work in your network. Secure resources. Most large surprises, large content providers, virtually all ISP networks, are going to qualify for address space under existing RIR rules. So in the ARIN case, for example, you can become an IPv6LIR, which is going to give you a minimum of a /32 allocation, or you can qualify for IPv6 addresses under the existing IPv4 number policy. There's no reason to explore -- experiment with provider-allocated space if it's not going to be suitable for deployment. If you have a multihomed network, there's no reason to start with provider-allocated space, because you're going to have to renumber. Focus on the core. And this gets you into, you know, where you start dealing with equipment. Vendor support for dual-stack IPv4, IPv6 routers varies. In many ISPs, it might have been a requirement in the last upgrade cycle, even if they weren't planning on using it. And it may actually just work. Some deployments have chosen alternate approaches -- for example, 6PE over MPLS -- because their core doesn't support dual-stack IPv6. In fact, it barely handles I.P. It's not a good excuse in and of itself to convert to NPLS. Congruence between IPv4 and IPv6 deployment is desirable. It was not possible in some early deployments because you had to deploy a parallel set of routers in order to support it. Congruent dual-stack deployment does keep back-bone engineers and your internal gateway protocol sane. Neither of those is a strict requirement. But they help. Let's move on. Come up with a rational address allocation plan. This is something that most ISPs, that I have dealt with, didn't think of initially. But in part because back when they got addresses from ARIN, or from RIPE, they didn't have to provide a huge amount of justification other than their existing network resource consumption. So organizations that were IPv4 LIRs already became IPv6 LIRs relatively easily. If you have a /32 -- that is, you are becoming an LIR, a large portion it have should be reserved for future use. Tunnel brokers are fine for experimentation but not for real work. So, you know, you can get transit from a tunnel broker provider and build a toy network, but that's exactly what it is. ISPs are going to be successful in treating IPv6 like v4. Most large transit providers can actually provide you with IPv6 now, even if their sales reps are not familiar with it. Typically, it's delivered as part of the same service that you get your IPv4 on. This is, I think, critical. Put your engineering staff on dual-stack networks. And because you clearly need a large amount of experience within your organization in order to be able to competently achieve the next steps. Early application services get built on top of the network to provide numbering, address, DNS-like resources. These are things that, by and large, applications and the end-user host need not be aware of but they are critical for your deployment. And they are where an enterprise builds some experience for future application deployments. There is some dependence on what kind of an enterprise you are, whether this is a wholesale transit and business ISP, consumer broadband deployment, or enterprise network deployment, as to how you deploy to the edge. And the key distinction here basic for this group is how do you assign I.P. addresses out to the edge and how much of a resource do people get. So there's a lot of debate going on out there as to what RIR recommendations for edge allocations actually look like. There's a lot of people who believe that /64s are ridiculous and no one will ever need that much address space. There is some substantial belief that auto configuration is a good thing and /64 boundaries are a minimum for subnet allocations. And that most end sites, including home users, need more than a /64 allocation so that subnetting is possible. I want to touch enterprises a little bit here. Enterprise networks by and large these days use a lot of private address space, and for a number of reasons. Mostly because they want to obscure what's inside their network or because they don't intend to route it. But also simply because they haven't gone back to get more space in quite some time. And this produces real challenges in the IPv4 world when you start doing things like mergers and acquisitions where you acquire someone who has a very large network built using the same address space that you are already using. They want to preserve that functionality. Enterprises also have proportionally lots of devices to manage per user. Stable bindings for devices make a heck after lot of a sense in this context. And when you have things numbered in net ten, you know, several times over, that could be a serious problem in terms of device management. So enterprises are sort of ripe for IPv6 deployment. Modula issues that they have with moving applications to that space. There is no point in using private address space in any large enterprise when you don't have to. This is something key with IPv6 deployment, and it may change who comes to RIRs for address space. It's quite easy, for example, to an nuns a covering prefix, null route, longer prefixes that you are only using internally on your border; right? This is more unique than unique local addresses. If you leak it someplace, you should end up black-holing your own traffic on the network. Which is a very good thing in this context. When you have to, ULA-L local is a sufficient replacement for RFC 1918. So practices that use private address space inside the enterprise can continue to do so if they desire. So one of the things that people talk about when they talk about killer applications for IPv6 is how do we move content providers and applications over to them. You do that by putting quad A records in the DNS. Large content providers are probably the last people who will do that. So the killer applications are actually within the enterprise and the ISP network operators. They are not in people's end-user perception of the Web. That's okay. The address space needs for content providers are rather finite and they can be served by even small blocks of IPv4. But that's something to realize in this context, is that they are going to be the last people who put records in the DNS so that, for example, you go, well, I don't need to use V6 because Google is not using V6 because I see no quad record for www.google.com. That's the lace last place you are going to see a quad record. And I am not picking on them in particular. Peer-to-peer applications, for example, VOIP would love to be able to assume that the target can be used without the use of a proxy which is known to have a public I.P. address. That's usage. That's the way the Internet used to work before all of these NATs. Before all of the disconnected, incongruent pieces of I.P. address space that are not publicly routed now. The enterprise case has very different issues for applications. And new applications will likely be deployed in the enterprise. IPv6 enabled once addresses are available. Some applications will never migrate before they are turned off, and enterprises are by and large used to this case. They used to have IPX, DECnet, SNA transport inside their enterprise networks. They used to route all those protocols. It doesn't matter, it's their sandbox. So I think that's a key consideration, is there are lots of networks where the traffic is not intended to reach the outside world, and so how their deployment goes on the inside really has no bearing on what we see. What we see from them is we see their IPv4 and IPv6 prefix announcements. In some cases for those applications, ALGs will be crafted. In other cases, the applications will migrate. IPv6 roll-out is not a transition. Right? And by that I mean you are not going to be able to turn off your IPv4 in virtually all cases for quite some time. Decades, perhaps. IPv6 addresses can be used to support end-to-end reachability. The same property continues to erode in IPv4. Scarcity in IPv4, which has been present for virtually all of the life of the commercial Internet -- and that is something that I would emphasize -- affects our perception of how we should allocate and use V6. And I see that debate a lot in the public policy forums. And I see that a lot on the Internet where people complain we are using far too many bits for a subnet. It was actually designed that way. And we should take that into consideration when allocating it. If IPv6 lasts as long or longer than IPv4, we should consider it a resounding success. So if we're having this discussion again in 2035, I hope I'll be there, but I would not be at all shocked if, in fact, we are. It is presumptuous to assume that we solved the address space issue for all time. Solutions were designed by humans, and inevitably entail compromise. We didn't address routing scalability at all except as a consequence of better aggregation. And that actually has to do with address scarcity as it exists now. I don't get contiguous blocks when I go back to an RIR. I don't get blocks adjacent to the ones I got in 1994 the first time I went there. Some surprises. NAT-PT is back. And it's likely at some point that IPv6-only hosts will be speaking to IPv4 hosts using such a facility. This discussion is ongoing in the IETF. Genuine NAT. Surprise, it's not going away. If a mechanism isn't provided to delegate a prefix to end devices in IPv6, then those devices will NAT in IPv6 just as they do in IPv4 in order to preserve the layer 3 boundary that they have. There is a solution for this in standards known as DHCP-PD, but there is obviously no guarantee that Internet Service Providers or enterprise networks will choose to allocate addresses in that fashion. And that will lead to the existence of NAT in V6. Teredo tunnels IPv6 to your customers even if you aren't providing them with IPv6 services. Enterprises will just turn Teredo off basically by blocking UDP port. It should shut itself off when IPv6 becomes available locally, but it's a real challenge in terms of debugging. If you are looking at an end user, you have to decide where they got their IPv6 addresses from. Unique local addresses. Unique -- ULA central, which would be centrally assigned unique local addresses is currently the subject of some debate both in the RIRs and in the IETF. ULA local is just like RFC 1918, and you can expect people to use it in a similar fashion. Thank you. This is my e-mail address. I'm certainly willing to entertain questions, but I think you have probably suffered with me for long enough. And I'll leave it at that. >>LEO VEGODA: Thank you very much, Joel. If anyone wants to ask questions, we've probably got time for a couple of very quick questions at the mike. Otherwise, we can break and resume in -- well, at 3:00 -- no, sorry. Not at 3:00. 4:00. At 4:00. And we have three more presentations. In fact, if I can have the cable. Thanks. So after the break, we are going to talk more closely about operations issues in IPv6. We will have a talk from Takashi Uematsu from NTT who is going to talk about a -- the Flet service, which is a deployed IPv6 service that people are happy to pay for. Jay Daley from Nominet will talk about IPv6 deployment at Nominet and some of the issues and problems they have seen there. And Dave Piscitello from ICANN's SSAC will talk about IPv6 firewalls. And there should also be time for some more discussion. So if there are any questions at the mike right now, then we have probably got time for a couple of quick questions. Otherwise, there's coffee outside, possibly with little cookies and Danishes and things like that. Coffee wins. We will see everyone back hopefully in about 15 minutes. And thank you very much to our panelists. [ Applause ] >>LEO VEGODA: Paul Wilson, Mark McFadden, and Joel Jaeggli. And thank you very much to our stenographers and translators as well. [3:46 p.m.]