Policy SIG, Thursday February 26, 11:00am-12:30 pm KENNY HUANG: This morning's agenda starts with an introduction to Doug Barton. The first presentation will be a proposal to lower the minimum allocation, by Anne Lord from APNIC. The second one will be the recovery of unused address space, presented by Paul Wilson. The next one will be the subsequent allocation criteria for DSL and cable services, presented by Yi Lee and the last one is 'NAT is evil', presented by Randy Bush. Before we go into the session, there's some housekeeping stuff. Initially, we need to encourage referral to onsite notice board for up-to-date announcements. Also, you can use the Jabber client to send questions and comments. Live transcripts. Also, let colleagues know of these services to tune in and participate in the meeting. All presentations are available from the meeting web page. The speaker is to move closer to the mic and speak. Speak slowly and clearly. Also, there's a roving mic to be brought to your seat in case you want to speak. So let's go into the first session - introduction to Doug Barton from IANA. Thank you. DOUG BARTON: Thank you, Kenny and I'd like to thank Paul and the Executive Committee for the invitation. I was asked to keep my comments brief, so I will do so. My name is Doug Barton. In December, I took over the position of general manager of IANA. This is a position that was added to the IANA staff as an example of the commitment of the CEO of ICANN to the importance of the IANA function. It's a challenge that I'm very excited about. My previous position was DNS administrator to Yahoo! Incorporated. In that position, I was responsible for all the DNS operations for the company worldwide and I was working with APNIC on IP address issues. I worked as a domain manager and so I'm very excited about being here and getting to meet in person many of the people that I've worked with in the past. Very briefly, the two things that I think are going to be most exciting for you guys to participate in coming forward are the issue of IPv6 glue for the TLD zones and the root zone where the ICANN policy development process is very close to finalising a method of making that happen. It's something that I'm very interested on moving forward on and we're hoping to have it done within 30 days after the close of the Rome meeting. It's coming up very shortly. The other thing that I think you guys will be interested in is an IPv6 allocation policy that is more or less the final form of a global policy that is something we can move forward on in perpetuity as opposed to the current allocation policy that requires ICANN to allocate very small blocks to the RIRs on an extremely fragmented basis. That was intended to be a short-term step. It was something that was designed by the IAB as part of the bootstrap process and it's a restriction that we're very interested in getting out from under and so I've been soliciting feedback from members of all the RIR communities in terms of moving forward on that. If any of you have comments or suggestions on that regard, please feel free to e-mail me. My e-mail address is barton@icann.org and I look forward to hearing from you. Does anyone have any comments. That was a very short speech and they asked me to keep it short. If anybody has any questions, feel free or feel free to ask me outside or at another time. I'll be here through the social this evening and then I'm getting on a plane to Rome to prepare for the ICANN meeting. KENNY HUANG: Thanks for that introduction. The first speaker will be Anne - a proposal to lower the minimum allocation. ANNE LORD: OK, good morning, everybody. My name is Anne Lord for those of you that don't know me. I'm from the APNIC Secretariat. I'm going to propose to you today a proposal to lower the minimum IPv4 allocation size and to lower the initial criteria associated with receiving that allocation. And this policy has a proposal number that you can track via the SIG and the meeting web pages. OK. Just before I start, I would like to make some clarifications to avoid any misunderstandings. This proposal actually only applies to the initial allocation to an LIR. So I'm talking about the first allocation - that's part of the slow-start policy. The proposal does not affect the size of any subsequent allocations that an LIR might receive. So they are actually dependent upon demonstrating the utilisation and consumption rates by the LIR and also a plan for future needs. And, as of today, every attempt will be made to ensure that the subsequent allocation is contiguous, so that practice remains the same. I think most of you are probably familiar with the RIR goals of conservation and aggregation. We have a minimum allocation and criteria that basically try and balance those two goals. We try to ensure that we promote aggregation and do not fragment the address space by making conservative allocations and not just allocations on a once-and-for-all basis. The minimum allocation criteria also ensure that the Secretariat gives access to unbiased allocations and they're all based on a demonstrated need, essentially. I think it's important to remember that the policy should stay responsive to the changing environment. The technology and the business environment are constantly changing and, over the last eight years, there have, in fact, been four changes in the policy. So that's not too many, but there've been three changes in the minimum allocation size and, in 2001, we actually introduced the criteria. So what's the current situation? We have a minimum allocation size that's a /20. In order to be able to be eligible for that /20, you have to have used a /22 from an upstream provider or demonstrate that you have an immediate need for /22. And you have to demonstrate a detailed plan for use of a /21 within a year. That's the current situation. So why put forward a proposal to change the size of the minimum allocation and the criteria. I think the Secretariat is in a fairly unique position in being able to gather feedback through a variety of different avenues, not only the Open Policy Meetings but also other avenues, like the training through helpdesk interaction, through membership application processes and also, more recently, through meetings that are held throughout the region like NZNOG, SANOG and so forth. There's numerous meetings and we're just starting to do that more. It's been a consistent theme that a change is needed. I suppose the most concrete evidence of that need for change came from APJII, the Indonesian NIR, in 2001, when they requested that the minimum allocation be lowered to a /22. And, at that time, there wasn't consensus on that policy proposal, so it didn't move forward. Nevertheless, I think their needs are still the same needs. There's also been concern expressed in other parts of the region, in different economies. But most consistently and notably by India and other countries in the South Asian region and also by some of the economies in the Pacific. So I think it's something that we're very much hearing, that there's definitely a need for a change. So what's the actual problem that we're trying to solve? Well, the feedback that we've had has been fairly consistent in that smaller ISPs are just unable to meet the existing criteria and they're finding it difficult to get address space from, in many cases, from the upstream providers. That's fairly consistent as feedback from India, but I'm sure it's happening in other economies too. And, in some cases, the regulatory framework is quite difficult. That's a harder one to tackle. But, in the example of Indonesia, the ISPs need to get a second licence before they can operate and a condition of that second licence is that they actually obtain a direct allocation from the NIR. So that's some of the feedback we've had. We've also had feedback that the allocation size is actually too much. If you consider the region is a fairly diverse one with extremes at both ends. We have 62 different economies that are served by the Secretariat and 24 of those actually lie within the Pacific. So that's one-third of the economies that are served. And many of those economies actually have much smaller needs for the amount of address space. And indeed that was actually a large part of the problem that [inaudible]. So that's some of the background. That's the problem. I tried to do a little bit of research into trying to somehow quantify this need. I took a very kind of rough survey, I suppose, by just looking at the largest economies represented by the APNIC membership. So it's just in terms of their APNIC membership and of course this doesn't exclude the NIRs because they have their own membership. I looked at India, Australia, Hong Kong and actually Indonesia too, since this was part of their concern. I looked at the number of APNIC members for those economies, then looked at the number of ISP licences. I tried to get government data, official sources of data. And the number of ISP licences - I tried to look at not just the number, but the active number of ISPs that are actually in use. So I then took away the number of members from the licences and thought this might be the potential number of ISPs that are excluded. You can see the percentage in the last column. In yellow, I've highlighted the three figures that I think, interestingly enough, are consistent. My conclusion, I suppose, from this very rough analysis is that, maybe in 50% of the economies, could be excluded. The figure for Australia is very high because I couldn't find any definition of active number of ISPs that were currently operating, but just managed to get data from the Telecommunications Industry Ombudsman. I don't know how realistic that is. I tried to look into the need and there's been concern that the allocations are too large for the region. The Secretariat allocates for needs based on that one-year time frame. I just looked at 734 current APNIC members. That was the set at the time that I did this analysis. Of those, 468 have only had one allocation - 63%. Of that, 378 - 51% - have had one allocation only and have had that allocation for longer than one year. So that's half of the current APNIC members. So what's the proposal? Well, to lower the minimum allocation size to a /21 to be the initial allocation. That's in response to the fact that people have told us that the larger allocation is too much. To lower the eligibility criteria, to basically say that you have to have had a /23 from your upstream provider or demonstrate an immediate need for a /23 and you have to be able to demonstrate a detailed plan for use of a /22 within one year. And that's in response basically to the fact that the barrier has been too high, so it's designed to allow more entities, more organisations, to qualify. And all other parts of the policy remain unchanged. What's happening in - what is the situation in the other RIR regions? In the ARIN region and in the LACNIC region, the minimum allocation is a /20. In the ARIN region, there are different criteria for multihomed and if you're not multihomed. If you're not multihomed, the barrier is a bit higher, the criteria to actually qualify is higher. So if you are multihomed you have to have already used a /21 block in order to qualify for a /20. If you’re not, you have to use a /20, so that's a bit higher than APNIC. They also actually approved, in line with RIPE, also approved a /22 minimum allocation for AfriNIC part of ARIN and RIPE respectively. LACNIC's criteria are very similar to those of ARIN, except the eligibility criteria are a little bit lower. It's a /22 if you're multihomed and a /21 is you're not. And the RIPE NCC have recently, in the last policy meeting in January, there was consensus on and they have implemented a /21 minimum allocation. They actually removed any criteria at all. So that's quite different to the other RIR regions. I'm told - and correct me if I'm wrong, LACNIC people - they're going to be initiating and having a discussion about the minimum allocation size. So far, I think, there's nothing being proposed in the ARIN region. Correct, Richard? You want to clarify? RICHARD JIMMERSON: I'm sorry. I was sitting way over there. No. There hasn't been a proposal to reduce the minimum allocation size across the board, but there was a policy discussion over the past six to eight months about reducing the minimum allocation size only for multihomed organisations. And that's recently been ratified and that moves it down to a /22. However, it has not yet been implemented, pending more discussion, and it should be implemented in the coming months. ANNE LORD: OK, so that's some of the background, the situation as it stands and the proposal. I wanted to take a bit of a reflective look at perhaps some thoughts about the impact of this proposed policy change. So the first thing that we think about are in terms of conservation and aggregation. Will conservation be affected? I think the idea behind the proposal is that more organisations will qualify, so I guess that's a certain. As a trade-off, less address space is being allocated in discreet units, so perhaps the impact on conservation won't be so great. What can we learn from past experience? Will the size of the routing table be affected, will more routes be announced and what can we learn from past changes in the policy? So I looked at the routing table, the size of the routing table, and just tried to gauge something about the impact of the previous policy changes. In 2000, in July 2000, the minimum allocation was a /19. At that time, the /20 prefixes constituted 4% of the routing table. Now, in January 2004, the /20 prefixes constitute 7.1% of the routing table. So that is definitely an increase as a result of the policy. However, I've also put up the /24 prefixes because, in comparison, they operate a greater part of the routing table. It's still over 50% of the routing table that's occupied by /24s. This is pretty much the same thing but it's a graphical view. In pink, you can see the /20s, the growth quite clearly there. The /19s have remained steady. The /22s have actually grown. So the next couple of slides actually, are borrowed from work that Geoff Huston has been doing. I think he'll present them in the Routing SIG today. This is a closer look, perhaps out of curiosity, to see what the /24s actually consist of, that 50% of the routing table, where does that come from? And it turns out that around 11% are actually RIR direct assignments and allocations, possibly a combination from historical allocations and assignments and from the current multihoming assignment policy. You can see the breakdown per region there. There's not so many in the APNIC region - 653 prefixes. And then, the remaining 89% appears to be fragments of larger RIR allocations and, again, I've given the breakdown. So I guess, perhaps, what this might suggest is that it's not so much the actual policy in terms of the size of the allocation that's being made by the RIRs, but it's more what the ISPs are actually doing with the space once they get those allocations. They're splitting them up for whatever reason. So this is actually one of the concluding slides from Geoff's presentation which just says that that fragmentation actually appears to be a major contributor to the growth of the routing table and that's not surprising, given the previous slide. And the good news is that the level of fragmentation is actually improving since late 2000 and that actually corresponds with a linear growth in the routing table. So if you're interested in more detail in that kind of analysis, you can go along to the Routing SIG later today. I also tried to take a look at perhaps the impact in terms of conservation. This table just shows, for all of the RIRs, the yearly allocations. And I think, in 2000, we had the, you know, the change from the /19 to the /20 minimum allocation. Correspondingly, we might expect in 2001 a big increase in the number of people that are qualifying, a huge jump in the amount of address space allocated. It didn't turn out it be so big and, in fact, the following year, it went down. That was the year, 2002, where we saw a lot of consolidation in the ISP industry. So it might suggest that actually, the economic conditions determine how much address space is being requested, allocated and used rather than the actual size of the RIR allocation policy. So I had quite a bit of feedback on the mailing list in response to this proposal. It was posted on 19 January. There were 14 different postings from five individuals. And there was broad, in-principle support from VNNIC and JPNIC, the National Internet Registries for Vietnam and Japan respectively. And some of the comments that I’ve tried to include here. One of them was how far we go in lowering the barrier [inaudible] how far do we go? The number who don't use their allocation may be higher or as high in the future. That's probably a fairly accurate statement I would imagine because I think, regardless of the actual size, there will always be a proportion that will not use up their address space. There was a comment that the data hasn't really been analysed for the impact of policy changes and more work is needed on routing and rates of address consumption. I couldn't disagree with that. I think that's a fairly true statement. A comment that we should tighten the criteria for portable assignments. They should be for end-users only so that ISPs apply for allocations. Yeah - more, I think, as a consequence of the current policy, we've observed at APNIC at the Secretariat that there were a number of ISPs that are trying to apply under the multihoming assignment policy if they didn't qualify for the allocation. I'm not sure about that. And there was a comment about what's the difference between an assignment and an allocation. I think that's a good question. As more end-users are able to qualify for portable allocations and ISPs qualify for multihoming assignments, perhaps the boundaries get a bit blurred. However, I think they meet very different needs, no matter how much we try to put people into one camp or the other, I think there are still very different needs that need to be met by multihoming entities who will announce a prefix. And a prefix is a prefix, so the effect in terms of routing is very similar. But I think, in terms of the administrative framework, there's quite some difference between one policy that's trying to promote or sustain the CIDR and one policy that acknowledges that it will be broken with assignments that are portable. Implementation - in terms of the NIRs, the outcome of this policy discussion should be applicable to all of the NIRs. However, the timeframe can be determined by the NIR according to their own processes and needs. The time frame for the APNIC Secretariat would be three months for implementation following the consensus and the normal policy process, which basically says that, if there is consensus, it would go to the mailing list for two months and then, if there's further consensus, it will be approved by the EC. We're talking about a change in a minimum of five months' time. So this is the last slide. I wanted to put this up just as a reminder during the discussion, but I'm happy to take any questions and feedback and so forth at this point. I just want to, I suppose, emphasise what I think is the reason for this change and it is definitely to lower the barrier for smaller ISPs in the region and also to allocate a more appropriate size for certain economies in the region. We feel this is very important. OK. Thank you for listening. Has anyone got any questions from the floor? KENNY HUANG: OK. Any questions or comments? TOSHIYUKI HOSAKA: Toshi from JPNIC. Can I assume that minimum subsequent allocation size is changed to the /21? ANNE LORD: There is actually no minimum allocation size that fits the subsequent allocation, because it's very much dependent on - TOSHIYUKI HOSAKA: Yeah, but, the current practice's minimum size is /20. ANNE LORD: It's only a /20 - there's no policy regarding the size of the subsequent allocation but what we try to do is ensure aggregatable subsequent allocations. But we also look at the demonstrated consumption rate of that ISP. So, if they used up their /20 very quickly, in three months' time and came back for more address space, chances are that they wouldn't get a /20, but a larger prefix. So it depends very much on their plans. So the size of the subsequent allocation probably, typically, would be a /21. If it's a, you know, smaller ISP, consistent growth and so forth. But there's no actual firm policy statement regarding the size of the subsequent allocation. LEO VEGODA: Leo Vegoda, RIPE NCC. We implemented our change of policy on 1 January. We’ve made 15 /21 allocations so far, as of about 10 minutes ago. And the main reason that our community wanted to change the policy was because what we found was that, with the requirement to show some existing usage, what would happen is people wanted to become an LIR and they would then go and get multiple portable assignments and they would spend a lot of time getting the portable assignments and then, they would then come back again for the minimum allocation. The whole process of getting the allocation for that was difficult, painful and didn't really add any value. So I think not exactly the same reasons that this proposal has been brought forward here, but I think perhaps simplifying the process is also a good reason for changing the minimum allocation. ANNE LORD: Thanks. TOSHIYUKI HOSAKA: This might be an operational issue, but do you plan to allocate /21s from any specific blocks, like 202 /8 or... ANNE LORD: Actually, the 202 blocks are quite full already. I think perhaps what you're alluding to is the need to, actually, if there is a policy change, to make very clear the policy change and announce it and publicise it so that other peoples are able to change their filters and that kind of thing. I think the communication is very important. KENNY HUANG: Since this is a policy proposal, I'd like to take a vote. Please raise your hand if you agree with the proposal. Thank you. Please raise your hand if you disagree with the proposal. OK, thank you. I think that can be a consensus from the meeting. OK, thank you, Anne. OK, the next presentation is recovery of unused address space, presented by Paul Wilson. Thank you. PAUL WILSON: Good morning. I'm Paul Wilson from APNIC. This is proposal 17, version 1. I'll mention some definitions of some terms which are going to be used in this proposal just so that they're clear. I'm talking here about historical address space, which is address space which is not subject to current policies. It's not subject to current policies because it's not currently covered by a membership agreement or a non-membership agreement with APNIC. So historical really refers to address space which was allocated or assigned a long time ago, during times when the terms of those allocations or conditions were not at all clear. So we say this address space is not strictly subject to current policies and it is historical address space. I'm talking here also about unrouted address space which is any address space which has not been routed on the Internet for some reasonably long period of time. Now we don't have a history of what address space was actually routed back to the beginning of the Internet for instance, but we do have records over a number of years from the RIPE NCC routing information service and we can consult those records to find out whether a block is routed at least during the history of that service, which is several years. So unrouted address spaces is address space which has not appeared in the routing tables for some reasonably long period of time. Unused address space on the other hand is address space which isn't being used for any purpose whether it's routed on the Internet or being used for a particular private network application. Now, if we look at the history of routing of Internet address space, this is a chart which shows the break-up of IPv4 address space in terms of addresses which have been reserved by the IETF spaces which are held by the IANA for future allocation. Addresses which are held by the RIRs and have not been allocated. 46% of all IPv4 addresses, 116 or so /8 blocks, which have been allocated. That latter category, the address space which has been allocated, you'll find by looking at the routing tables that a very significant portion of that address space is not routed at all. That is 17% of the entire IPv6 address space, IPv4 address space, I'm sorry or 42 IPv4 address blocks, /8 blocks. They've been allocated but they don't appear in the routing tables at all. Now, we can say quite clearly that approximately that amount of address space would be categorised as unrouted address space and a very substantial amount of that address space is clearly not used at all. About 36%, in fact, of the allocated address space is not advertised - around 42 /8 blocks. Now back in the early days when this address space was being route routed, well we had RFC 2050, which was written in the mid 90s, and according to that document it's actually assumed that address space which is allocated to an ISP is going to be connected together Internet and it is going to be routed on the Internet. So in the sense of the policies that RFC 2050, it appears that address space was really allocated on the basis that it would be routed and it's for that reason that I say much of the address space that is not routed on the address space on the Internet, is basically unused address space. There are provisions in RFC 2050. There are provisions that assignments to organisations can be made without intending to route on the Internet is if there is no alternative to that. But we’re talking about assignments in that case, and therefore relatively small amounts of address space. RANDY BUSH: When you say '42 /8s', is a large amount of the unrouted space contiguous and really appears that way, or is it teeny bits. PAUL WILSON: That’s a very good question - Geoff, these are your figures, so... GEOFF HUSTON: There are a number of /8s that sit in that block that are contiguous /8s. The remainder is checkerboarded across the old B and C space, and in general there are not huge chunks of it Randy, no, it's more checkerboarded. Little bits. PAUL WILSON: In the APNIC region, APNIC is currently has management responsibility for a total of 184,000 /24 blocks equivalent or around 2.8 /8s in total, which is historical address space. About 90% of that has come to us through the ERX project which, in fact, George Michaelson reported on earlier this morning. It's notable that probably just over half of that project is actually complete. It's an ongoing project and we're likely to receive at least another two /8 blocks into APNIC management as a result of ERX. That is address space which had been allocated quite some time ago via the old central registry system. APNIC also has address space which is classed as historical which was inherited from the AUNIC, the ex national registry in Australia which was disbanded in the mid 90s. There is also some address space in the APNIC blocks which is classed as historical and was allocated in the years between '93 and '96 while APNIC was actually operating but before there was a membership agreement that actually said specifically what the policies were under which those address spaces were being used. Overall of this address space, and as you see it's quite substantial, 2.8 /8s at the moment are likely to rise to maybe five /8s, we have no formal agreements in place regarding this space. That's why we call it historical. The address space we're currently holding as historical is illustrated here. The chart shows the year against which historical blocks have been recorded in the database. The economy to which they have been allocated and you can see there are blocks which are marked as having been allocated in 19 70. That's not actually true. That's the default date for historical blocks against which the data has actually been lost. Historical address space that we are holding was allocated between 1987 and 1997. There are some anomalous records in the 2000 years there which have to do with ERX record which have come through with dates representing an updated date rather than the original allocation date. But there's quite a substantial amount of address space. You can see here in 1992, more than 12 million IP addresses were allocated which are now classed in the APNIC region as historical and that's about three quarters of a /8 block. And just out of interest, a slide which isn't on the website version of this presentation, this slide shows comparison of that historical address space against the address space that is currently being allocated by APNIC. So in the blue, is the curve showing annual allocations by APNIC and in the purple is the earlier historical allocations. So the historical are quite a substantial proportion now of the address space which is being managed. This proposal is to put in place a system or the beginnings of a system by which address space which is not used can actually be recovered, and can be made available eventually for reallocation. And I'll state quite clearly, this is not a project which is on an immediate, urgent time frame, but it is something which we need, we feel, to start at some stage, so that eventually we can have better utilisation overall of IPv4 address space and less address space which has been allocated and which remains unused. So when I say that address space will be recovered and available for reallocation, there are quite a number of unanswered questions about how exactly that address space will eventually be reallocated. It may not be reallocated by APNIC at all. It may be more sensible to transfer management of that recovered address space back to another Internet registry, another RIR, which has got management control over the /8 block, in which the address space is located. It may also be sensible to be looking at such things as the black lists on address space which may have been the subject of squatting or hijacking in the past so we're not reallocating address space which has a black mark against it. There are of course, as you would all know, we've got quite a substantial amount of IPv4 address space remaining. It's not urgently required. There is plenty of fresh unused address space which will suffice for quite a number of years. As I indicated earlier, it is necessary at some stage to start this process of recovering unused address space, so that when it is needed, we know exactly what's available and how it should be redeployed. I'm going to go into some of the operational steps which are proposed for this recovery process. In the first case, what we need to do is simply obtain a list of all of the independent portable blocks which are held by APNIC under APNIC management. We call those the top-level parent blocks. These are the locks which would appear in the whois database without any larger block between the /8 level. Of course, under APNIC management, there is a list, a whole collection of these blocks which are independent, top-level parent blocks which we can extract from our records. With these blocks, there's an implicit step here which is to take out a consideration address space which is current and subject to current address management policies. With the historical blocks, we would be consulting the routing information service to determine if that address space has been routed ever in the history of the routing information service, several years. We would be, in the case of address space which is not routed, we would be contacting the holders of those resources and informing them of the intent, the proposal to recover this address space which is unrouted and hence likely to be unused. These address holders are likely to respond in three ways (that includes the default lack of response). But let’s say response A is that the resource holder is contactable and simply agrees to return the address space as it is unused. You'd be probably surprised at how many address space returns we do receive. It does happen from time to time. Those who have been allocated address space in the past and were not using it are often quite happy to return it for future use by Internet users. In that case, address records will be marked as reclaimed and as I mentioned, there are future discussions about exactly how such reclaimed addresses would be redeployed later. In the second case the response holder may not agree to return the address space, for whatever reason. It may be private use. It may be that they intend to use it in future. Because this address space is historical and not subject strictly to policies, it's very difficult for APNIC or anyone else to forcefully attempt to recover such address space. I don't believe we have a clear legal basis of any kind to do that, so what we need to do is simply update the records as well as we possibly can, note the status of those records and hold them for future action. The third action here, which is shown as response C, is, in fact, no response at all. That is likely in many cases where historical records have gone out of date, we’re not able to contact the holder, the holder doesn't want to respond to us. In that case the address space needs to remain on the list for later action. We don't propose to take any action simply on the basis of one attempt to contact a resource holder. Now after we have undertaken this process for all address space that is classed as historical and unrouted, we would pause the process for a couple of months, and repeat it again. Then after a longer period of time, the proposal is 12 months, we would take the specific action to actually note that address space, or those resources, as being reclaimed and put them into the pool. Now 12 months is a candidate time frame. It may be too short. There are other actions that aren't described here such as publication publicly of the list of resources to be reclaimed, announcements to operational mailing lists that this process is under way and so on and so forth. These steps will be taken as part of this process. After a particular period of time, however, 12 months in this proposal, if we have address space which is, for which there has been no response whatsoever and no information, then that again would be put into reclaimed pool for later policy discussion and decisions. This actually is being proposed as a once-off project. But what I feel the APNIC Secretariat needs to do is to roll this into an ongoing plan for monitoring the user status of allocated address space and historical and current, so that we are, in fact, able to report more accurately on which address space is used and not used within the system. In fact the latest versions of MyAPNIC includes facilities for address holders to track their own record of utilisation, that is of, for instance, of routing of address space allocated from APNIC. So that's the proposal and those are the particular operational steps. I felt it was quite important to go into the specific detail about those, perhaps more than what we would normally go into to in a policy proposal. We feel particular steps, the transparency and the public understanding of those steps is quite important in this case. I'm nearly finished, Randy, so I’ll just go through the next couple of slides. This is a regional project under the banner of APNIC and under the regional responsibilities of APNIC and it, once again, is a process which the NIRs may wish to undertake and assist the APNIC Secretariat with and coordinate quite closely, so that, as we heard before from Izumi, we don't have unexpected results for NIR members, causing any confusion in any case. The time frame for the implementation is according to our normal policy process which provides two months for comment and some months for implementation. That's the standard process. In this case, because as I mentioned, it's a long time frame involved, we might decide that this requires more opportunity for discussion. So I'd suggest that if it were approved at this meeting, we might think about a longer comment period so that all relevant concerns, and particularly so that all affected parties, have a longer chance to be notified of this proposed change. That's it. Thank you. RANDY BUSH: Could you flip backwards about four slides. That one. The little box. The penultimate word 'reclaimed' is inappropriate. You might use something a little less threatening. In other words you're not actually reclaiming the space. PAUL WILSON: I take your point. So 'recovered'? RANDY BUSH: It still maintains a in the possession of the allocate, right? PAUL WILSON: At that point in fact, after the period of time which has been defined for public notice or contact with the holder, at some stage we would need to say that this address space has been actually reclaimed and will be able for future reallocation. So maybe the threat there is actually realistic. RANDY BUSH: Then you mean that word, and I'm not sure you can actually do that. I think that, certainly I know in the ARIN region, there will be legal problems doing so. Not because of the different laws, but because there are chunks of address space which are allocated to folk who will not respond, but think they own it and are very much alive and have weapons of mass destruction. PAUL WILSON: I think that's a very good point and the fact is... RANDY BUSH: They actually have them and are proud of it! And they use them! PAUL WILSON: We don’t have any such weapons, and we probably don't have a legal basis for getting into an argument and trying to exert a claim over those. I would say that at least in our case, those address holders would be in the minority. But the address holders who do insist on retaining that address space, probably need to be left in that status. So reclaimed probably is not the right word in that it's a provisional reclamation which would probably be reversed in the case that someone comes back and says, "I dispute your reclamation of my address space." But I would suggest that in the majority of cases that it is simply address space which has been allocated and forgotten, the existing holder has forgotten, has no idea, has no knowledge of that fact. So I would expect that in many cases it is not something that would be subject to dispute at all. But you're quite right. RANDY BUSH: How do you know? PAUL WILSON: By maintaining these records for eternity. These records are always on hand, and as I mentioned before, when it comes to actually redeploying or reusing the address space, it's another discussion as to how long we should wait and what further actions might be needed. RANDY BUSH: And those funny folk have funny ways of routing and they might find out, they will react only when some innocent party is assigned the address space, announces it on the public Internet. PAUL WILSON: There are many things as I mentioned that need to be done by way of communications and outreach to ensure that this activity is well-known to as many people as possible. That will never reach everyone, but I would stress that I understand, we understand, that's extremely important aspect of the project. TAKASHI ARANO: How much effort does APNIC need, in terms of the operational cost? Will it be paid by the membership. If the IPv4 address will run out in 20 years or something like that, is it worth spending such effort on that? PAUL WILSON: If it were a case of urgent requirement for the address space, I think, and where it was necessary to recover address space within a particular time frame, urgently, and it involved a lot of manual communications with address holders and so forth, I think the cost would be quite worrying. The intent is to automate this to the maximum extent possible so that notifications are sent automatically, so that responses can be dealt with automatically in terms of administrative interface which allows addresses to be easily marked when they are returned. There are already systems which have been developed in connection with historical address space within APNIC, whereby holders of address space whose records are out of date, where they don't have a maintainer, they don't have detailed record in whois which actually corresponds to their identity, there are already systems in place whereby they will lodge documentation and that documentation will be processed and action taken by the Secretariat. So the administrative scale is not trivial, but the automation, the integration of this process within existing systems is quite feasible. AKINORI: I hope this an interesting input. JPNIC is now trying very hard to have a change in the reschedule for LIRs. During this discussion, [inaudible] somebody will pay less and somebody will pay more. In this discussion, some member of JPNIC raised an issue of the fairness in this. He raised the issue of the historical allocation. His point is that historical allocation should be handled fairly as well as the recent allocation. In this context, I am really supporting this proposal, and JPNIC - this is in terms of our daily business operation to do the fee structure change, we may need this proposal very soon. I know that we have to take out more discussion with JPNIC to acquire that. I hope this is very interesting information to you. PAUL WILSON: Thank you - I realise this issue is quite important in many other discussions of registration policies, the status of membership, the status of address space, the correct conduct by the APNIC community of managing the address space. So I think there is more at stake here than simply recovering address spaces. As Arano-san mentioned, it's not an urgent activity at all. But it is nevertheless an important activity and an important point that APNIC is seen to be managing address space in a comprehensive and responsible manner, particularly when, as Sanjaya mentioned before, we have incorrect registrations, we have hijacking and squatting and this sort of activity going on, and it's becoming more and more prominent. If there's anyone who is really responsible for at least ensuring registration and correct management of that address space administratively, it's APNIC, so I welcome the comment, thank you. GEOFF HUSTON: Arano-san asked a question about how much we had left of the v4 address pool in terms of time. There are two kind of models about the consumption of v4 addresses - the predominant model from the last three years appears to be one of effective linear growth in address consumption, rather than exponential, at a rate of around 3.5 /8s per year. Now, the totality of the pool that Paul is talking about is around about 38/8s, so in theory there’s about a decade, if you have 100% efficiency on reclaiming the space. Now, the issue comes that if you left that space dark, then we're going to run out of IANA pool. We're going to run out of the unallocated pool some time around 2026 At that point every address is worth money, because a trading registry naturally opens. So what you don't reclaim by around then in that model will never get reclaimed and will actually see the pool, good or bad. The other kind of model says we're continuing in an exponential growth, it’s an exponential growth figure, in which case, by the time we exhaust the address pool, we're consuming around 10 /8s per year, and the amount of time that you buy in reclamation is under three years and it's not worth worrying about. So, part of the, I suppose, longer-term benefit, if you're just looking at the address pool, is whether you believe that NATs and other address technologies that compress and increase the utilisation of address deficiency continue to be deployed, in which case reclamation has almost a decade of leverage, and that’s probably a good thing. But if you believe that the pressures on address consumption will continue to accelerate, then oddly enough there's actually very little residual benefit in this exercise, it doesn’t buy you many years, and the reasons for doing it would have to lie elsewhere. So I’m sort of saying an either/or bet here - in a world that doesn't actually accelerate in its consumption of addresses, you will buy some time if you do it now. If you wait, it doesn't matter. You won't buy any time at all. PAUL WILSON: The point I probably haven't emphasised in the slides hereis the usual squatting, and the potential for abuse of address space which has been previously aloocated and which is simply unused but sitting with public records in the whois database. And we've already seen many cases where address space abusers will take the registration information, masquerade in some way to gain control over that address space and use it for spamming or hacking, and again, the more we can tidy up that historical address space, the better we're doing our job in terms of ensuring the registration data is accurate KENNY HUANG: Any more questions or comments? Please raise your hand if you agree with this? Please raise your hand if you disagree with Paul’s proposal? OK, we can see a consensus from the Policy SIG. Thank you. We are a little bit behind schedule, so we need to press forward to our next presentation. The next one is ‘Subsequent allocation criteria for DSL and cable services’ from Yi Lee - oh, I’m sorry. MARS WEI: Good morning, everybody. I am Mars Wei from NCIC in Taiwan. I present this on behalf of Mr Lee. He has sorrow because he cannot attend this meeting in person. KENNY HUANG: Sorry, because of some technical issues, the presenter cannot proceed right now. So, because of time, we need to swap. And so the last section, ‘NAT is evil’, presented by Randy Bush. Randy, can you present now? Thank you. RANDY BUSH: Now everybody can watch me fool around with my laptop. Randy Bush, IIJ. Anne made the title of the talk, by the way, I didn't. You can blame her. I'm not very fond of NATs, but I have one at home! OK, first - for those who don't know, what's a NAT? NAT is a network addresses translation device. It translates source addresses, in other words the IP address of an incoming packet, to a different destination address. It could be one input interface or one output interface, or it could be multiple. And it's often used to connect a private IP network, often using RFC1918 space, in other words, 10.0 or 192, 168, etc, to public Internet or maybe between private IP networks and the domain and the range, in other words, the address used of the translation function may intersect. In other words, the addresses on the outside and the addresses on the inside might actually be the same. And an example is, here's the outside and here's a packet coming in, destined for - it's coming from this address, the source, and it's destined for 64.23.14.19 and the NAT translates that destination to 10.0.0.1, keeping the source. This gets it and it sends it out to this and it translates the outbound packet to have the outside address again. So we have the concept of the outside address and the inside address and that's what we mean by address translation, OK? The NAT has to maintain a table which maps the addresses and ports from the outside realm to the inside realm. And the mappings are created when the NAT guesses they're needed. It guesses because it gets a packet from the outside. And the mappings are freed when the NAT guesses they are no longer needed. I don't know if you've ever been in a NAT-ed world where you have a long-term session, like an SSH session going to something outside and, an hour later, it's gone. Well, that's because the NAT ran out of table space and had to say, "What mappings are no longer active? OK, I'm going to throw them away." And usually, hosts behind the NAT addresses like DHCP. OK, so the NATs translate addresses but often application-specific code for addresses are inside the packet, aren't just on the outside, but often addresses are inside the packet. Examples of that, of protocols like that, are a lot of the PTP protocols, [inaudible] I forget, but there's a long list of protocols. A good NAT has to not only translate the addresses but has to look inside the packet in the payload and translate addresses inside. That means a NAT has to understand the applications. So it has to create or delete translation entries for each application. It has to have code. These are known as 'application layer gateways'. So NATs often provide application for FTP, DNS, SIP, RealAudio etc and new application gateways are continually needed every time there's a new application. So all of a sudden, instead of the end-to-end Internet, we have an Internet where things in the middle have to be fixed for new applications, and I want to stress that. What's funny about the Internet is where the brains are. In a voice network, the edges are stupid, they're phone instruments, you know? The thingy on your desk. You can make it yourself out of wire, right? And the core, the centre of the network is very smart - SS7 switches, SS5 switches, these monstrous things that cost millions of dollars. The Internet has very smart edges, computers with operating systems, applications - when you think about how much is inside this stupid laptop, it's amazing. But the core of the network is very simple. It just does packet forwarding. It doesn't care what's in the packet. So on the Internet, adding an entirely new service, a new application is just a matter of distributing the application to the ends. The middle doesn't change. So you can put a new application on the Internet this afternoon, put it up for download and as many people want to download it in the world can use it - unless they're behinds NAT. Compare that to adding a service to the Voice network. How long did it take the telephone industry to deploy rotary dialing? Over a decade! To go from the operator who said, "What number please?" to dialing switches? And that's when the industry was small. How long did it take the telephones to convert to touch-tone dialling? We don't have the answer to that question because they're still doing the conversion 20 years later, OK? And that's because it required changes in the centre of the network, big, expensive switches. I should note that e-mail was a service added to the ARPANET - it wasn’t part of the original ARPANET. If changes were required in the core to make e-mail work, we'd have been in big trouble. The Web, HTTP, would have taken a decade to deploy if it required changes in the centre of the network, if it required changes in your router, if it required changes in your NAT at the border, OK? So with NAT it's, tomorrow's killer application will be difficult to deploy, because it will require those application-layer gateways and almost hundreds of thousands of millions of stupid little devices that we have at the borders of our houses and offices. So today's new applications are hard to deploy because they require ALGs. So the problems caused by NATs are this broken global addressability, IP fragmentation, little technical things. But the big thing is they increase difficulty in deploying new applications and they degrade scalability and reliability and they make network management more difficult. My friend Keith has a paper on that. People think NATs cause security. There's a belief that they do. Does changing my name badge stop a mugger? No. Changing the address of something isn't going to change that it's going to be attacked. NATs does not slow down e-mail viruses and what happens is somebody comes inside the company carrying a laptop and the entire company becomes infected and starts sending out more e-mail. Have NATs slowed down DDoS attacks? No. And NATs actually provide insignificant increase in security. Now, NATs are often associated with firewalls, OK? And, in that case, it's the firewall blocking certain ports, blocking different kinds of access, requiring authentication. It’s the firewall that’s providing the security - we wouldn't have to map addresses at all. That's insignificant. So why are there so many? There's a false perception that the RIRs will not give an LIR the needed, justified space. In fact, LIRs do and, if you can't get it from your local LIR, go to a different one. Right? This is a real one. The difficulty for a large ISP, especially cable and DSL, to do customer-by-customer need-based allocation. In other words, it's so much easier to set up a provisioning system for a million cable customers, give each one address. To make your process, your administrative process, you technical process, find out what they need and allocate those is more much difficult. That needs to go into your provisioning tool bill. If you don't put it in the provisioning tool bill, some poor people will go crazy, OK? And lastly, there are carrier ISPs in developing economies who will not allocate reasonable allocations because... I know of an entire country that was operating NAT-ed behind a /27 in Africa because the European carrier, colonial carrier, wouldn't give them more. Social problem. So what do we do? Get rid of them! If you have a NAT ed network, what do you do? You design the actual address space needed as if the NATs weren’t there and then contact the RIR, NIR, whatever, have a plan, and you get the needed address and you convert and you get rid of all that garbage. You can do it. And those people who want to see IPv6 promoted should like it because it will increase the consumption of the IPv4 space. And that's it. KENNY HUANG: Thank you, Randy. Any questions or comments. RANDY BUSH: Come on, Geoff! Get up! Geoff and I have worked for those telcos by the way. GEOFF HUSTON: I hadn’t actually thought of a question here, Randy, but let me actually pose one - this is this kind of issue I think around NATs being something I don't know about yet so I better not use them. Because what you're really saying here in some ways is that NATs are part of an instance, and it's quite a prolific instance actually, of middlewear in the network, mediation. The reasons why people deploy NATs are actually varied and part of it is, yes, "I can't get address space." The other part is that, increasingly, a lot of the edge is now having to assume that every packet is hostile and that very few packets are actually benign, expected and welcome. And that the traditional mechanisms of filtering and firewalling work on the opposite assumption - "here are the rules about things to drop on the floor. I will let other stuff through." So I suppose my question is if I remount the network, if I allow end-to-end packets, if I allow universal addressing, haven't I exposed my rather unreliable laptop with its rather crappy operating system to an entire new world of applications, most of which are hostile viruses? How do you respond to that? RANDY BUSH: I don't think you do. Instead of breaking part A of the network, fix the part that's not working well, which is fix the firewalls. OK? Fix the filtering to get rid of the garbage but that doesn't mean you need address translation. The address translation is a false fix. It doesn't actually fix the problem. So take that same box and reprogram it to filter ports 137, 138, 39, so your Windows box doesn't get attacked and so on and so forth. Fix the actual problem. GEOFF HUSTON: Like I said, it's very hard for me to do this without a little bit of thought and preparation but certainly what I'm seeing out there is that NATs are increasingly being deployed, particularly in the medium-scale corporate environment, as an adjunct and integral part of edge-based policies around saying, "If I hide my identities completely and let through only known applications then, yay, surely I shall be protected!" Now I understand your presentation has said that's a false dichotomy and doesn't work but, nevertheless, that's what I observe out there in the way that people deploy NATs and the reason why. The other point I should mention, at least in passing, is that we all find it difficult to understand how many hosts today are behind a NAT. I've seen two semi-serious efforts, one that described an approach but I've yet to see data from the approach. The other I saw was from research in Australia that analysed traffic going to a relatively popular game site and used the data from that. It would appear right now that around half of the network is behind a NAT and the other half isn't. And it would appear, at least apocryphally, that that's growing slightly. It would appear that, like it or not, the pragmatic view is that NATs are very much part of our current landscape. The corollary to that, which is at least worth observing, is that if I really wish to promulgate and build an application that will be popular, the next game, the next Napster, etc, then perhaps I should make it NAT-agile, rather than NAT-intolerant, in order to have it accepted in the world today as we know it. RANDY BUSH: The problem is that that's an infinite chase. There are users right now that don't understand why X does not work for them. That's because they bought their NAT a year ago before it was made agile for application Y, which they decided to run today. And why the Internet has been so widely successful is we've deployed more applications in 10 years, new applications and new ways of using it, than the central mechanism telephony system has deployed in 100. It's the end-to-end that has let us do that. Q. So end-to-end is the basic fundamental principle in the Internet. So NATs receive a lot of their challenge and a lot of problem, even in IETF, it's a short-term solution for IP address. The real situation is still about the user trying to deploy NATs. My question is how can we prevent the user to deploy or continue to use their NATs. RANDY BUSH: Make it unnecessary. You don't have to prevent it. Make it so that they can get the address space they need and show them a device that gives them the customer-premises equipment that has a couple of port filters to give them actual security instead of giving them a NAT. The customer who gets a DSL line and is given a piece of ethernet - they do not go to the store and ask for a NAT, right? They go to the store and ask for something to put on four computers, or a wireless unit, right? So what we need to do is give them the proper solution to that. One piece of proper solution to that might be that new edge devices - if I put a four-port switch on a DSL modem, the DSL modem senses that, sends a message to the DSL provider's provisioning system and the DSL provider automatically allocates three more addresses. Q. But that leads really to how to speed up address allocation. RANDY BUSH: Also, the IETF has a proposal for automating that process. The next question should realise they're interrupting lunch. KENNY HUANG: OK, Randy, do you have a proposal? No? It’s just informational, right? OK, we switch back to a previous session. MARS WEI: I'm sorry for the delay. This is my first time in this situation. Sorry. OK, I will try my best to speed up this presentation. This proposal is to talk about the status in Taiwan for the suballocation to cable or DSL services. So we can start at the current policy. The subsequent allocation issue is addressed by APNIC guidelines for IPv4 allocation and assignment questions in section 10.2. We can see in section 10.2, the following information is requested from an ISP for subsequent allocation. First - headend information specifying the number of CMTS devices planned per headend. And the projected number of subscribers within three months. The growth rate, based on average growth per month over past three months and the projected number of subscribers within 12 months, if the projection is significantly higher than that predicted by the growth rate, and the last thing is the purchase receipts for equipment if requested by APNIC or the NIR. So this is the current policy but we found in the Taiwan market, we found some problems to deal with this current policy. The problem is the criteria described in the APNIC guideline takes into account only the number of subscribers, which may not fully reflect the actual need. In Taiwan, we have some 30 listed with more than the subscribers numbered to the IP. ADSL access has managed to acquire the major share of broadband access market in Taiwan by penetrating small/medium business, SOHOs and residential consumers. These customers - most of them have more than one computer, either two or three computers. Most subscribers are ready to turn on their second computer even more due to the ISP's vigorous marketing campaign of assigning multiple IPs. The result is the IP/subscriber ratio is higher than current 1:1 convention. Also, the cable market meets the same situation in Taiwan, especially for the SOHOs and residential consumers. So we found that, to cover the necessity for the ADSL and the cable users is not suitable by the 1:1 ratio. In this line, we can see the most popular service in Taiwan, the biggest three ISPs with multiple IP services. In Hinet, they have provided four dynamic IP addresses and eight dynamic IP addresses for ADSL. In Seednet, we note here one static and four dynamic IP addresses and the 1.5M has one static and nine dynamic IP addresses. And for So-net, the largest offers one static or eight dynamic IP addresses. So we have a case study for according to a similar model. The IP utilisation of ADSL service had exceeded 80% before Seednet announced 'one static and four dynamic IPS 'denoted by 1S4D policy. Up to now, 80% of subscribers opt for the 1S4D policy and the number keeps growing. We trace our system log and we find that our system log shows 20% to 30% of subscribers turn on their second PC and even more. And the number is still growing. And Seednet must reserve one static IP for each 1S4D subscriber. So current 1:1 convention leaves no room for dynamic IP manoeuvre. Ratio of IP to subscriber was 1.2:1 by the end of 2003, exceeding the 1:1 convention already. Estimated ratio in 2004 is 1.5:1, in accordance with expected growth. So we can see the 1:1 ratio is not suited to the current model of ADSL in Taiwan. So we have a suggestion. Sufficient amount of address space should be allocated to ISP which provides supporting information. This supporting information should show the necessary for the IP allocation. Criteria for subsequent allocations should be more flexible to accommodate the changing need of ISPs based on the projected number of address space consumed by subscribers within six months. So we try to, try to suggest for the proposal to modify the criteria. In addition to number of subscribers, the following may be considered as supporting information as an option. So this is an option, not to replace the current policy. Track record of IP utilisation over past three months - for example, RADIUS/DHCP server log. So that will see the subscribers turn on even more computers. And number of the DSL/cable circuits subscribed over the past three months. This information is supplied by the fixed network provider. And projected number of subscribers within six months. And projected number of the IP addresses consumed by subscribers at peak time. OK. That's my presentation for this proposal. I appreciate your concentrate and your patience. KENNY HUANG: OK, any questions? IZUMI OKUTANI: It's not really a question but we evaluate in a similar way. We don't only base it on the number of customers, we also ask for information about the equipment, you know, depending on a case by case. It's just my opinion to express this. MARS WEI: Thank you. KENNY HUANG: OK. Any questions? OK. Although the presentation is informational, but the presentation actually comes with a guideline document so one suggestion is to see who would be interested in working on the guideline document to update the guideline document. So is anyone interested to work on an updated guideline document? IZUMI OKUTANI: Can we ask our community members if they are interested to join this, like a free volunteer? Because we probably have some cable TV or DSL providers who might be interested in doing this? KENNY HUANG: OK, right, thank you. So that will be done in the mailing list and regarding to the proposal and so, if you wish to propose this suggestions, we can update the existing guideline document. OK, any questions? OK, thank you. OK, sorry for running late. You are already past your lunchtime and I am happy to see the policy proposals being approved and, anyway, thank you for your participation. Thank you. APPLAUSE