______________________________________________________________________ DRAFT TRANSCRIPT Policy SIG Thursday 8 September 2005 9.00am ______________________________________________________________________ KENNY HUANG: OK, good morning. Thank you for coming to the policy SIG. My name is Kenny Huang. I'm chairing this session. Toshi-san is chairing the second session. Before the meeting, I'd like to give some housekeeping. First of all, we'd like to thank the sponsors for this meeting and the sponsor is CNNIC so, thank you, CNNIC for sponsoring this meeting. MyAPNIC demo is available all day so, at break times, you can go to see the MyAPNIC demo. The help desk is available at break times and also please see the onsite notice board for the updated information. OK, thank you. OK, we are reading today's topics (refers to slide). We have two sessions. The first session starts with the review of open action items and the next will be IANA policy for allocation of IPv6 blocks to RIRs, presented by Paul Wilson from APNIC. And the next one will be 'proposal to amend APNIC IPv6 assignment and utilisation requirement policy'. The next one will be 'alternative address allocation algorithm for IPv6' presented by Mei Wang from Cisco. And the last item of the first session is 'resource recovery policy - implementation update' presented by Son Tran from APNIC. Then we have 30 minutes break. The second session will be chaired by Toshi-san and it starts with 'proposal for discrete networks and national peering'. The next presentation will be 'RIR policy development update' and the third presentation is 'LIR survey results' by Save from APNIC. The fourth session is 'IP address space transfer between existing Taiwan LIRS' presented by Ching-Heng from TWNIC. The next one will be 'large IPv4 address space usage trial for future IPv6' presented by Naota from IPv6 Promotion Council of Japan and the last item will be election of co-chair. So that will be today's updated agenda. OK, so we move to the first presentation and that will be 'open action items'. For pol-19-004, the open action item was "Secretariat to initiate process to elect a new co-chair of the policy SIGÓ and the status is done. The co-chair will be elected at the end of this meeting. The next open action item, pol-19-003 - "Secretariat to amend and publish current IPv4 subsequent allocation guidelines" and the status is done. Pol-19-002 - "Secretariat to amend the policy submission form to include a CC field" so the status is done. Pol-19-001 - "The proposal to continue the second phase of the large space IPv4 trial usage program for future IPv6 deployment (prop-027-v001) To be reported at the annual member meeting to seek consensus at the next stapling of the policy development process." And the status is done, also approved by EC. So the last open action item, pol-18-001 - "Secretariat, with assistance from NIRs, to conduct a survey of ISPs' resource management practices to allow better analysis of the issues." So the status is done. So all the open action entries are complete and some are ongoing, like the election of co-chair. That will be completed today after the meeting. So I move to the next agenda to Paul Wilson, who will present "IANA policy for allocation of IPv6 blocks to RIRs". Thank you. PAUL WILSON: Good morning. OK, this is revisiting a global policy proposal, which was presented previously at the APNIC meeting. It's the presentation at APNIC previously was the first of the presentations of this global policy to any of the RIR meetings. And since then, it's been presented at other meetings and we're just revisiting this policy here to give an update and to find a consensus approval for some minor changes to the policy previously presented. Just to recap on how global policy development actually works - it's defined by the memorandum of understanding, the MoU, for the ASO and that MoU is available on the ASO website and also on the NRO website. To have a policy approved firstly requires a consensus on a proposal in each of the RIR communities. So that's what we're going through in the case of this proposal right now - seeking consensus from the APNIC community. A common text for a proposal has to be established, either by having the common text presented by all the RIRs or by consultation among the proposer and the RIRs but, in either case, when ratified, when a common text is ratified by all of the RIRs, the NRO, representing the RIRs, passes that approved policy to the ASO and it's then the role of the ASO Address Council to do a check over the process that has been undertaken to reach that global policy consensus and then, when they're satisfied with that process, to forward the policy to the ICANN board for its acceptance of the global policy. To recap: We had prop-005-v004: IANA policy for allocation of IPv6 blocks to RIRs and this describes the process by which IANA will allocate IPv6 address blocks to RIRs. So it was first approved by the APNIC 18 meeting in Fiji and because, as I mentioned, this was the first reading of this policy proposal to any of the RIRs, there was discussion about the need for some flexibility to accommodate some minor changes which might arise in the global policy process through presentations at the other RIRs. So the policy was approved with flexibility to accommodate some minor changes. The APNIC EC endorsed the proposal according to the APNIC policy procedure in November 2004. And since then, there have been discussions at the other RIRs and the proposal has evolved somewhat to - at least to the extent of having a second version of the policy proposal. So that final proposal, the second version, is similar. In fact, the APNIC EC had a discussion earlier this week about whether it was similar enough to be considered as approved under the decision of APNIC 18. So it is very close. But nevertheless, we've got the opportunity here to just clarify the differences between the first version and the second version and to present it to this meeting for a review of those differences and for consensus approval of those differences. So it's just a process of providing the opportunity for review and discussion and the opportunity for a clear consensus on the final version 2 of the policy proposal. OK, so there are some relatively minor changes in the policy provisions from the first proposal. So, under this proposal, the IANA is allocating IPv6 address blocks to the RIRs. The second version says that these address blocks should provide enough address space for at least an 18-month period. The first proposal had a 36-month period and it was felt that the shorter period was appropriate. So that is the first of the changes to the policy - that we'll be proposing an 18-month, not a 36-month period. There was also a discussion about the need for address space to be allocated to an RIR, which is less than the standard IANA minimum allocation, /12. So there's a specific provision that an RIR that has less than a /12 allocated address space will receive that allocation from the IANA. Furthermore, an RIR will receive additional IPv6 address space when its available address space is less than 50% of a /12. So this provides the RIR with a pool of address space when that pool reduces to 50% of its /12. Then it will be qualified to receive additional address space from IANA. It would also be qualified if it had less address space in the pool than is required for the following nine months based on its current allocation rate. In either of those cases, if the RIR has less than 50% of a /12 or if it has less than its requirement for the following nine months, then the IANA will make a single further IPv6 allocation to the RIR, sufficient to satisfy the requirement of the RIR for a period of at least 18 months. Now, the situation in other RIRs: (Refers to slide) This is the reading of the second version of the policy proposal, so this is yet to be finally discussed in the AfriNIC policy process but it will be discussed at the AfriNIC 3 meeting, which is coming up. The policy reached consensus at ARIN at the ARIN XV meeting and it's been endorsed by the ARIN Board of Trustees. So that, as I understand it, is actually the final approval in the ARIN region. LACNIC reached consensus at LACNIC VIII, the last LACNIC meeting and the policy proposal is now in the final comment period. So under the LACNIC policy development process, that would continue to approval of that policy process, I guess, unless anything significant comes up in the comment period. And at the RIPE meetings, this has been discussed at the last couple of RIPE meetings and it will be discussed again at the next RIPE 51 meeting, which is in October. OK, so we're quite close in fact to having a global consensus, a consensus in each of the regions for this global policy proposal and, if we have that consensus, when we have that consensus, as I mentioned, the NRO will forward the proposal on to the ASO Address Council and the Address Council would then make its determination as to whether the correct and complete procedure has been followed so that that can go on to the ICANN board and so we're getting quite close to that, to that step and I would hope that we can reach consensus on the proposal here in the APNIC meeting as well. OK, so this proposal is termed prop-005-v005. And that text was already announced to the SIG policy mailing list on 10 August so we've followed the correct process here in the APNIC meeting, we've posted it on the mailing list according to the deadline and the records are available on the APNIC website. So that's the proposal. I'm happy to answer any questions, if there are any questions relating to what's happened or what will happen in the other RIR regions and we do have our colleagues here who can certainly answer questions about the respective regions. So are there any questions about this? OK. Thank you very much. KENNY HUANG: OK, thank you, Paul. Is there any other questions or not clear with the proposal? OK, no questions. So since this is a policy proposal, we need to look for consensus in the policy SIG and so anyone who is in favour of this proposal, please raise your hands. Please raise your hands higher. PAUL WILSON: It seems to be 17 or so. KENNY HUANG: So, anyone who is not in favour of this proposal, please raise your hands. OK, thank you. So the proposal has reached the consensus so we can move the proposal to the annual member meeting to ratify. Thank you. PAUL WILSON: Thank you very much. KENNY HUANG: So we move to the next topic - "Proposal to amend APNIC IPv6 assignment and utilisation requirement policy" presented by Geoff Huston from APNIC. Thank you. GEOFF HUSTON: Thanks, Kenny. Now, I do expect lots of questions, OK. So there will be a test afterwards. This is a proposal authored by Stephan Millet of Telstra and co-authored by myself from APNIC. It actually concerns the IPv6 assignment policies. The background to this I will go through in the presentation. The work originally was initiated actually by the Internet Architecture Board some 16 months ago in response to looking at some initial large allocations that would perform as part of the policy process that allows existing v4 holders to use their existing allocation as a justification for an IPv6 allocation. So we'll go through the exact proposal and then some background to it. The exact proposal currently in the RIR policies - an end site as defined is by default a /48. You can certainly make a case that that could be larger in individual instances but the default is a /48. The implication is that the subnet ID for any site, irrespective of size, home, desk, PC, phone - is 16 bits, or 65,536 subnets for that end site. This proposal says to introduce a second end site allocation point at the /56 - in other words 8 bits of subnet ID. The second part of the proposal - it is not proposed that this be the default for all end sites but it is proposed that the /56 be the default for small office, home office and similar small-scale residential access. We are looking for a /56 for the large end site applications in the large retail space and that default would be a /56. We would expect larger and medium-sized enterprises, corporates, campuses and so on, to continue to be able to use a /48. The third part of the proposal - the current host density assignment ratio that is applied to end sites in order to establish the criteria for eligibility for a further allocation, which is currently set to a value of 0.8 be revised to a value of 0.94. Again, the presentation will go through what that implies. And currently that HD-ratio is applied to /48s. This proposal is that that HD-ratio now be based on /56 counts. So this presentation will go through the motivation for these changes, the impact analysis and some comments about implementation. If you were here at the plenary yesterday, I think you would have actually found a large amount of the motivation for this particular proposal. It's actually looking at our expectations that, if IPv6 is a success, what does that really mean? What is the life cycle of this particular protocol and what is the anticipated reasonable rounds of the deployment size; how big can v6 get? The current allocation policy is - just to remind you - if you are an ISP or an LIR, the allocation is currently a /32 minimum and subsequent allocations are a /32. If you are an ISP and you're allocating to customers, if you are absolutely assured that there will only ever be one interface ever - and in these days of bluetooth, I'm really not sure what that would mean - but if you are absolutely sure, ever, then it's a /128. If you are thinking that that customer or that end site will only ever have one subnet ever, then the assignment is a /64. Currently everything else is a /48 minimum. It also allows ISPs to assign to each of theirs points of presence at /48. Now, what we do in terms of assessing the eligibility for further allocations is to apply an HD-ratio to your end site count. This is a table of the actual 48 counts inside any particular block and the number of end sites that you would have needed to have performed an allocation in order to consider that block full. A /32, which currently has 65,536 end sites, once you have assigned 7,000 end sites, you would be eligible for a further /32 allocation. So that's a little bit over 10%. By comparison, IPv4 is, of course, as you are aware, 80%. We are seeing today - and this is merely in IPv4, so I don't think it's anywhere near the size of IPv6 in terms of potential - residential broadband networks which currently have customer populations in the millions, somewhere between 3 million and 10 million. We have seen allocations of a /20. How? If you look at that table, you will see that, once you have 5.5 million customers, 5.5 million end sites, you are eligible for a /20 allocation. That /20 contains 268 million potential /48s. So once you've got 5 million big networks, you can get 268 million /48s. The density is around 2%. That certainly is a very different world to what we've been doing in v4. And the potential is that we can run through a relatively large amount of address space relatively quickly. This was discussed at a round table on IPv6 at the ARIN XV meeting in April of this year. And there were a number of exercises in trying to understand how big we are looking in v6. When you look at the demand side with IPv6 and assume success, you have to assume the total size of the silicon industry. So this is not just eyeballs, ears and brains. This is all about devices. It's things well beyond human populations. So the global populations that a success in IPv6 would really imply is a population where you start to count households, workplace, devices, manufacturers, public agencies, anything. And what you're talking about there is not just 200 telcos any more. You are talking about thousands of service enterprises, several millions of end sites in a very low-valued commodity industry. You're talking over the next decades, possibly even centuries, an extremely large deployment. The addressing technology needs to last for certainly tens of decade. But once you have numbered every device, once you have literally encompassed an end population of hundreds of billions, it's going to be sticky. It's not going to go away very quickly. You are going to have to encompass perhaps centuries. And the end sites we are looking at are certainly in the order of tens of billions if not more. So we're talking about numbers around 1011 of end sites. Routing, by the way, is not going to get any better any time soon. I actually think these days that routing is a mathematically constrained problem and while today the routing system can contain 105 entries, it doesn't look like we can get easily beyond 107 any time soon. There are no technologies that offer any promise here. So somehow we have to squeeze 1011 into 107. The other thing we can look at is how long v6 will be around. When will anyone ever be able to readdress and re-equip those trillions of devices? We don't want to run out. Because, quite frankly, part of the v6 design was based around the scarcity of v4 as distinct from looking at a superior technology. Shifting a technology base due to scarcity simply leads to a scarcity solution, not a better solution. And one of the lessons I think we've learned from v4 is to actually say, "We're not looking at running out at the end of the life cycle. We would actually like to have ample addresses, even when we are going beyond v6." That will allow us to concentrate on what is better rather than what is strictly necessary to make tomorrow work. So part of the philosophy behind this, the motivation, is to actually have ample addresses at the end of the estimated life cycle. So with a life cycle estimated at 60 to 100 years, we really are looking at making sure the address plan readily, readily encompasses that kind of time frame. The problem is, of course, that we have to do all this in routing. So aggregation and hierarchies aren't very efficient. The addressing plan needs to accommodate all kinds of businesses from the small to the large. And large is certainly at least 100, possibly 1,000 times larger than the enterprises we see today. We're moving beyond PCs, don't forget. We're down in deviceland. So currently in the allocation policies, we have 16-bit subnet, an HD-ratio of 0.8, we have global populations that we can anticipate at 1011 or so and around 60 to 100 years. How long does that give v6? Well, the key is actually looking at the HD-ratio for very, very large networks. So here's the rest of the HD-ratio table. And I want to draw your attention - if someone's got a laser pointer. Down the bottom here (refers to slide) 119 billion - 1011. It's a /2. Because, once you get to that size, you've used up half of the unicast IPv6 address space. In other words, it starts to look a lot shorter than you think. If you multiply up these numbers, you get somewhere between a /1 to a /4. Which isn't a new answer, by the way. If you have a look at RFC 3177 where there was originally described by the IAB, they came up with 178 billion global IDs and estimated that with a /3. Their HD-ratio is slightly different. I estimate it as a /1. It doesn't make much of a difference. We're talking between a /4 - 1/16 - or a /4 - 1/2. The issue is how uncertain are we about that future. Have we underestimated as we did with v4 initially? How rampant is that industry over the time period? We don't know about the time period. You're all still listening to AM radio, aren't you? And you still have a telephone handset 100 years on. So we may be wrong about the time period. We may be wrong about the issue that addresses are valuable. Certainly in ethernet Mac addresses, they're rip-off addresses. Once they're manufactured, they are never, ever, ever recycled. So at what point do you start seeing v6 as a rip-off-the-pad one-time address that once it's used it's never reusable again? What kind of network models are we looking at? Are overlays persistent or is everything in one single domain in terms of addressing? What do manufacturers want? How simple do they want this to be? What kind of network service models? Are we really moving to commodity distribution? I would suggest in v6 that you are. So then it comes down to what kind of device service models we're looking at? Is the silicon industry really going to do ubiquitous embedding? Of course it is. In population counts, you are talking about populations of the silicon industry, not really human populations any more. To give you some idea of the scale we are talking about - how many chips will be produced this year by the world? Um, I have no idea, but I have seen estimates of half a billion; then mobile phonesÉthink about it and you're in the tens of billions this year alone. What sort of address distribution models are you going to have? Do we want cohesive uniform policies? To constantly tailor address plans and address distribution models for each particular device or application? In that kind of scale, simplicity will probably win. And what's the overall efficiency model? How efficient will this be? If we're wrong about any of these assumptions and we're underestimating, then the real issue becomes how comfortable are we looking at this? And don't think about 'we' as you in this room. Think about someone whoÕs about to make a new washing machine line and wants to put an IPv6 chip in it. How much money are they going to invest in that production cycle in they're going to invest a reasonable amount of money, millions if not more. What are they assuming? That IPv6 is stable, that the address policies will work, that when they embed these chips in those devices, that is going to be an investment that will happen, that will generate return. So if those assumptions are uncomfortable, if we think we're underestimating - and we might be - then maybe we should look again at the address policies to see where there might be wriggle room here, where we might gain back. The IPv6 address plan is very simple. There are three fields. Down the bottom is the interface ID that encompasses 264 - 4 bits. In the middle is the subnet ID. By default that's a /48. That's 16 bits. And at the top is the global routing ID, 48 bits. So what we can do is look at the density inside that global routing ID, which is currently the HD-ratio. Here's the HD-ratio of 0.8. Even at the minimum allocation of a /32, you need to achieve a 10% fill rate than the current 80% fill rate with v4 in order to get an additional allocation. At the high end of today's market Ð (stresses) today's market - the people market, with populations of around 5 million to 10 million, the inside address density is 2.1%. Again, with IPv4, it's 80%. Now, how do we derive that number? The HD-ratio of 0.8? We didn't. It was plucked out of the air to be brutally honest. Does it match actual deployment? Well, there's very little actual deployment to really compare against. So does it match existing deployment in IPv4? And the answer is clearly no. IPv4 is certainly a much higher density. Now, higher densities cost. So achieving 80% in v4 is certainly expensive. It's expensive for the provider and ultimately it's expensive for the consumer. So maybe 80% is too high but equally is that too low? At what point do you actually chew through too much address space? What this proposal does is actually look at an HD-ratio of 0.94, which says, for current deployments it would achieve a 30% end site utilisation rate and for the minimum-size deployment, you'd need to get a 50% HD density rate, so 50% of the end sites would need to be allocated before you're eligible for a further one. What does that mean? Well, it's very hard to predict what v6 would be and the only data we have is v4. So what I did was to take the allocations that were performed in v4 over the last 20 odd years and look at their size range and work backwards and say, " Well, all those allocations were performed on an approximately 80% fill rate using a /32. So if I quote that to all the end site accounts and do that back as if we'd been doing v6 for years and the last 20 years were v6 instead of v4, what would be the range of allocation sizes for different HD ratios?" So here is the blue (refers to slide). This is an HD-ratio of 0.8. And it says there would have been a few /20s - quite a lot. This is a logarithmic scale between 10 and 100, around the /22 to /24 area, and corresponding to larger amounts in the /29, /30, /31. What if the HD-ratio was 0.94, which is the white colour? You wouldn't get allocations around the /21, /22, /23. The allocations would start around /24, /25, /26. But, when I look at this a little more closely, irrespective of the HD-ratio, 80% of all the allocations are basically around the /31, /32. So for most ISPs and LIRs, changing the HD-ratio won't impact most of the allocations, because currently those ISPs sit within the minimum allocation size. Only 2% of the allocations are larger than a /27 and for these, the larger networks would be lifting the efficiency from 4% to 25% so this is the leverage to the deployments to say, ÒThe way to gain back some address space, if we're wrong about our projections, is to look at the larger deployers and say we need to lift area efficiency levelsÕ.Ó Across three years, if you simulate this, you get back about a factor of 10, because these 2% of the players actually consume an enormous amount of address space. So that if you drop them down from 4% to 25% density, you actually use one-tenth of the IPv6 address space that you would have used in IPv6 allocations. So given that there's a reasonable range there, what's the good HD-ratio to use? And, in proposing 0.94, I've thought about what is actually common practice. How many levels of hierarchy you have in your networks, how many levels of hierarchy would you have in your network in the future? Don't forget that routing internally, your interior gateway protocols, only use two levels of hierarchy, so they're relatively flat networks. Don't forget also that if you're using a very, very common technique of carrying customer routes in iBGP and only carrying your topology in your IGP then you can carry disparate route sets and only aggregate your edge. So common practice tends to suggest that networks aren't that deep and there aren't that many levels of hierarchy. There is a survey that APNIC has conducted - I'm actually not sure who is presenting that. Can anyone give me a hand as to when the survey will be presented? SAVE VOCEA: After the tea break. GEOFF HUSTON: Later on this morning, you will see the results of that survey about what networks look like, which is an interesting input to this. What is a real efficient level? What is attainable using common, good engineering practices - not perfection, but reasonable engineering practices? What are you trying to do in the longer term? So, from that point of view, that's where the recommendation of 0.94 HD-ratio for insights came from. Which is certainly lifting it up a bit for the larger networks in terms of saying, "This is realistically achievable." What do we get out of that? We get out three bits; a factor of 10 is three bits. The second part of the proposal looks at the subnet identifier field. Why a /48? The actual recommendation in 3177 is, as I've described before - /48 the default, /64 if you know there's only one subnet and /128 when there's one and only one and absolutely only one device will connect. Why /48 and why the single point? Certainly, part of it is cheap - reducing evaluation record keeping. In other words, it's trying to make the distribution function more lightweight, more uniform and cheaper. That's a good thing. Ease of renumbering the provider prefix. I think the reality has said that doesn't matter, that that /48 boundary being uniform has nothing to do with the ease of renumbering because renumbering is never easy no matter what. If you think about all the associated parts of the DNS and so on, then renumbering is expensive no matter which way you look at it. So there is no ease of renumbering in the provider prefix. Ease of multihoming? No. Again, that's been overtaken by events. Multihoming does not do a plug-in substitution of the provider bits. End site growth - well, yes, that's possible, although I do find it rather strange to understand how the low end of the market, which actually forms around 95% of your market if not more is going to grow beyond 256 subnets - subnets, not devices, subnets. I can certainly understand larger enterprises growing but I do not understand the end site growth there. It allows end sites to maintain a single reverse mapping domain. This is the whole multiaddressing problem. And, from that point of view, it's actually not clear whether multihoming and multiaddressing, multistaffing the DNS is actually going to be the way we do it. Common reverse mapping zone for multiple prefixes - I don't believe that's a compelling reason. There was the so-called conformity with site-local structure. There is no site-local structure any more. It's now called unique local addresses and to what state conformity is valuable is questionable. Of the reasons given in 3177 has been largely overtaken by event. We could go the way we've gone in v4 and do full variable - in other words, every end site is actually tailored, if you will, to some number between 1 and 16 bits. Certainly, you can get high address utilisation efficiency. We've seen that in v4. But the cost goes up as well. The processing and record-keeping functions are expensive. There's a trade-off between high density and the overhead. So there is likely strong pressure in v6 to simplify this, to try and make things uniform rather than variable, which is why the idea of actually introducing one more point here where the reverse mapping is easy - a /56 for the 95% of the market or higher which is the small office, home office, mass retail market. So you maintain the /128 and /64. Processing and record keeping are a consideration here. End site growth models for SOHO - I find it hard to find how 256 subnets becomes a big barrier there. Renumbering is renumbering. Multihoming is not looking this way anyway and there's still fixed points for reverse mapping. We get back out of the total lifetime of v6 around some six to seven bits, we estimate, of reduced total address consumption. And as I said before, there are three bits in the IPv6 address plan. The last bit is the low-order 64 bits. If you played with that, you could get back an enormous amount of address space really easily but you would be playing with the protocol, not just with the policy. We'll say that again - you would be playing with the protocol. You would be playing with deployed hardware and software, even today. You would be playing with areas that the IETF considers to be legitimately part of their area of standardisation. So there are extensive implications, not only in terms of functions, but of other related standards in the IETF area. We could play there but we wouldn't be playing alone and I suspect we would encounter some resistance. So a pragmatic view of how much wriggle room we want, how many bits we want to apply and what's the easiest way of looking at it. The current HD-ratio - if we assume it consumes a unit of one, if we change it to 0.86, you get back half of it. If we change it to 0.94, you get back 9/10 of that. Moving it to 0.94 gets back three bits of address space. Changing the subnet field gets you back around 6 to 7 bits. So given those two, you get back between 10 - sorry, around 10 bits. So total consumptions on a relatively imprecise demand models - I think they're underestimates - would say the current underestimate would consume around a /10 to a /17. You go, "Is that good enough?" And the answer is probably yes. That's sufficient error. Why am I talking about this now? 3177 basically said something completely different. What it said is, "We may be wrong. We're probably wrong. If the future net turns out the way you want but we're not going to change anything now. Someone will change it later." (Question inaudible) GEOFF HUSTON: That's precisely what we said with v4. We started handing out /24s and then CIDR blocks. What do we have today? We have a strong level of objection at a national and political level saying, ÒThere is incredible unfairness in the IPv4 space and the address distribution function has failed. It is unfair. Entire countries today have less address space than some early adopter American universities. This is a dramatic failing in the system.Ó So, if you start saying, "We'll do what we think is OK now. It might not work. We're probably going to have to change things," then what you're leaving behind is a legacy of shifting the entire structure later. The early adopters will be very happy and won't move. The late adopters are going to be extremely unhappy with us, with you and I in this room, saying, "We got it wrong. We can't get as much those other folk. We have to pay a higher price for IPv6 to squeeze into the small amount of remaining space we have. This is v4 all over again.Ó So do you really want to create, as 3177 did, early adopter rewards and late adopter restrictions? Is this a wise thing to do, not only in terms of industry policy but also public policy? Is this the right thing to do for the industry at large, not just your company? Or should we attempt at this point to actually adopt a different attitude, to say, ÒLet's actually assume success. Let's assume that IPv6 is indeed widely deployed for decades. Let's actually take it now and try and get a uniform address policy that doesn't create disparity in the future.Ó So, from my point of view, that's why I'm arguing that this should be considered now. What's the impact analysis of this particular policy proposal? Certainly, the entire aim of this is to actually instil greater confidence in address availability across the entire technology life cycle. In other words, to assure folk investing in terms of services, hardware, machinery, all kinds of applications in v6, that v6 is viable over extended periods of time, it is stable and it will be available globally across a massive deployment base. Also looking at fairness of allocations, not only now but across time. In other words, the same structures are available, even if, within your situation, in your national economy, in your own development in homes, you would not be looking at widespread v6 deployment for years, decades. We're trying to say that point at which you come in you get exactly the same - it's fair - than if I came in right now. There are certainly higher overheads in profiling end site allocations. Introducing a /56 and keeping a /48 means there is more work to do - not a lot, but there is some work to do. And there are some boundary cases where some sites go across that 8-bit boundary. So there is potential renumbering in some end site growth cases. Using a higher HD-ratio means that network designers and planners need to work a little bit harder than 2%. 2% means you don't have to work. You can do it all on an Excel spreadsheet, forget about it and go to sleep. With an HD-ratio of 0.94, it's a higher overhead in managing it, but I certainly don't believe it's unachievable or even difficult. It simply means you have to be careful. In proposing this policy statement, this policy proposal, it is not proposed that APNIC would adopt this in isolation. It is actually proposed that this is a global coordinated effort across all RIRs and substantively the same policy will be presented in the other four RIR forums and this may come back to APNIC later for possible review much as you've seen the IPv6 global allocation policy come back following consideration from the other RIRs. That's the end of the presentation. I hope I've left enough time for comments and questions. RAY PLZAK: Just a quick comment regarding your last foil. The HD-ratio proposal has been on the table and a discussion point in the ARIN region since April/May timeframe of this year and the end site allocation was put on the table, I believe, a week or two ago in the ARIN region. Both matters will be taken up at the ARIN public policy meeting from the 26th to the 28th of October. TAKASHI ARANO: Can I make a comment? My name is Takashi Arano from Japan. Your proposal is logically very good and I would agree without any question if it were made one year ago. The policy change of /56 may have some possibilities to sacrifice ISPs to only have 100 or 1,000 customers. For example, that kind of policy change may cause some service specification changes, right? And how can they explain to the customers that existing customers get a /48 but the new customers only have a /56 or something like this? Another case is the customer database. They already have a customer database, customer service system based on the assignment size fixed. So to make such kind of database system change costs. It would be a very big program. So late ISPs would not be sacrificed. They will build a system from scratch, no problem. My suggestion is that to make (inaudible word) from the ISPs in Japan, Korea, China and evaluate the impact of the /56. GEOFF HUSTON: So, if I can rephrase this, you're asking for APNIC to conduct a study with the existing adopters in IPv6 and deployers to do an impact analysis on - while it is not suggested, by the way, that existing deployments change; so, if you've already got an address and you're allocating /48s to customers, continue to do so. As you've correctly identified, it would be future allocations that would normally be based on a /56. And you're asking for an impact analysis of that to be performed presumably by the Secretariat? Is that what you're asking for? TAKASHI ARANO: Yes. GEOFF HUSTON: Can the chair note that? RANDY BUSH: The /128 /126 problem with anycast and 3627 - it's really nice to see /56 and /48. We also need a /40 so we can call them A, B and C to bring back nostalgia for those of us who have been around for a while. And for Arano-san we can go back to the CIDR working group where we had the exact discussion about the difficulty of changing allocation sizes from the fixed ones we all depended upon to the variable ones. We have been to this movie before. The movie was bad. LAUGHTER Don't we have memory? Right? I come from a country that seems to be unable to remember the war it had here, so it's doing another, so I guess we can do this too. But can't we learn from history once? GEOFF HUSTON: Randy, what would you suggest? RANDY BUSH: I have no problem with the HD-ratio stuff. It's the /56, /48, etc. Stop telling people what sizes to allocate, these fixed-size boundaries. Allocate what's appropriate for the need. This is not a religion. This is technology. It's simple. We have done this before. It was very, very, very painful. SURESH RAMASUBRAMANIAN: To follow what Randy said, he raised many points I wanted to raise. One thing is if we are not conservative in allocating IP addresses, and if we don't follow the same conservative IP policies that have charactered RIR IPv4 allocations over the last few years at least, after people have been allocating CIDRs and you had to justify how much IP space you want and get as much as you need. As far as I remember, Softbank got a /8 or something larger than that recently because they could justify it. Simple. As Arano-san said, it's not that people are going to quarrel regarding a /56 if other customers are getting a /48, if you can justify getting a /56 or /48 for single IP tunnels or smaller blocks of IP tunnels. Is there a need to give an end user site which has maybe one fridge, one telephone, one PDA, one PC, one laptop, maybe 10 IPs, a dozen IPs, 200 IPs. What's the point in giving them a whole /42? KENNY HUANG: Geoff, do you want to respond to the question? GEOFF HUSTON: In that particular case, you're touching upon issues, which delve deep into a decade-long archive of the IPv6 working group and it's address plan. They came up with in 3177 an answer of a /48. Part of the motivation for doing that was uniformity equals simplicity equals low cost. They may be right. They may be wrong. In looking at changes to that, certainly Randy is correct in saying that this has some similarities with the original 8 /24 split in IPv4 that then became the ABC split thereafter. There are some issues - how scarce is v6? What are the costs you want in the address distribution function. What are the ultimate targets you're trying to achieve? They're part of the equation. So, if you're saying and proposing "let's do this variable" then that's a final proposal and response but certainly in the proposal here what is being proposed is a minimal change to the existing policy that tries to get back some of the bits to encompass a broader consumption framework over a longer period of time. SURESH RAMASUBRAMANIAN: If I may clarify that - there is a proposal - it's not a proposal, it's a locally applied policy followed by network. People were providing IPv6 tunnels to networks. They've got something which lets people get a larger space from the backbone and allocate space based on justification to other smaller customers in their area for home networks which just need one IPv6 interface or a smaller /56 maybe of IPv6 boxes for the lamp, things like that. So as long as this can be done, if ISPs can parcel out IP space in smaller amounts, this is not getting into RIR policy, this is fitting into how much IP space ISPs can allocate to their customers. If they perform a need-based allocation there and it's not going for Whois or anywhere else, it's what an ISP is provisioning to its users. If we are looking at the political implications of this which, with due respect to the IPv6 WG have not changed in the last several years, when with the WGIG started, there were things about countries and ISPs and things started. So I hate to stay it but we have to revisit the discussion in light of this. Because it is going to be raised in the future. It's going to come back to bite us if we don't do something about it. KENNY HUANG: OK, Izumi-san. IZUMI OKUTANI: We introduced this discussion in our last Open Policy Meeting in Japan and the general feeling seemed to be we don't really understand why you feel that you need to change the policy. We understand the logic totally and as Arano-san said, it makes sense to just follow your logics, but I think this kind of thing was anticipated when the policy was first developed in the first place and I think, if it lasts for 60 or 100 years, we don't really see the need of changing this policy at the risk of affecting the existing customers, which is quite a big concern for some of the ISPs within Japan. GEOFF HUSTON: Certainly, if you plan success in IPv6, the current 550 autonomous system numbers that are routing v6 and the current 750 entries in the BGP routing table and the current 0.0002% of address space being used is a minuscule fraction of the total life cycle of IPv6 assuming IPv6 is going to work. So creating long-term industry-wide policies based on an extremely short period of history, where the policies themselves appear to offer a more limited lifetime scale necessitating later revision also has its problems as a way of moving forward. So certainly looking at that impact on the existing base makes sense, I would agree but to say not even to look at it but to say, "Oh, well, we will defer the problem," I'm not sure is the wisest course of action we can do at this point of time. IZUMI OKUTANI: I understand that logic but, if it lasts for 60 or 100 years, why is it a problem? RANDY BUSH: This is history. We've seen it before Izumi-san. GEOFF HUSTON: What Randy said is, "This is history, we've seen it before, Izumi-san," and I have to agree that this is history and we've seen it before. We can replay the movie but this time it will be a more hideous disaster with bigger players. Lots of people will - SURESH RAMASUBRAMANIAN: The plot has changed and we've got a new hero, villain. GEOFF HUSTON: That's the response. IZUMI OKUTANI: I understand. This was just a question raised so it's not like we are very strongly against changing the policy. It was just a question. And the biggest concern seems that changing the assignment size rather than changing the HD-ratio. So would it not be good enough to change the HD-ratio and keep the current assignment size? GEOFF HUSTON: Again, this is all about confidence levels and trying to understand what the future is going to hit you in the face with. And one of the slides that I had here was actually quite deliberately worded. It isn't that those predictions are right or wrong. It's all about comfort levels. And how comfortable are you in putting forward an address plan that has to span a very long time in the future across a very uncertain environment? And if you're planning for success - you're not planning for IPv6 to die and wither - you truly are planning this proposal to go from RFIDs to skyscrapers and everything in between. How uncertain are we about our predictors? If you look at the HD-ratio, you get back three bits and maybe we're all comfortable that that's enough. Maybe we're not. Certainly in proposing the two, I felt there wasn't enough comfort there. I'm not sure I'm that good a predictor of the future. I think I underestimate like many engineers. I never saw IPv4 being this big 20 years ago. If I'm wrong and badly wrong and we're all wrong, we've got a problem again. This was a case of just a minimal change that, quite frankly, for home and residential, is actually extremely minor. It won't affect them. And the /48 remains there for all other medium to large customers. Is this a conservative way of buying back a more assured future? That was the rationale for doing two. IZUMI OKUTANI: I have a few more points. I will take turns. JORDI PALET: I certainly agree with the HD-ratio point. I really think that that needs to be changed. But I don't agree basically with the rest of the proposal because several reasons. For example, it seems to me that one of the things that this is creating probably - I am not really sure because I don't see all the big ISPs' allocations requests so I don't know the exact reasons why they allocate, but it seems to me that maybe they are asking instead of a /64 in their calculations for somewhere telephony also a /48. So it may be making more sense to change the /64 to something like a /60 or /56 for cellular phones. This will mean also changing that for in RFC 3177 because probably the higher number of devices that will get IPv6 address space, the devices will be the cellular phones and certainly we agree today that they are not just going to be a single subnet probably. OK? So it may be making sense saying, OK, if it's clear there is a single subnet, keep / 64 but if it's going to be a cellular phone a cellular router, don't allocate to that one a /48. Use instead a /50 or /56 or whatever. That probably will change the picture. Then looking into the home user, I mean, people which today use broadband in their home and this will grow in the bandwidth that we have probably until 100 megabits in let's say five to 10 years, I really believe that 256 subnets may seem too much today but I don't think in the future that's enough. It's a personal view according to what I'm looking in research projects, what is going to happen with sensor networks and this type of things. It's a very personal view from experience and research that it's going to be in the market in probably five or ten years, something like that. If we go for the /56 for these home users, the point is we need to ensure that, if tomorrow a home user wants to move to a /48, it's not going to cost him a lot because otherwise, we will see the situation we have with NAT with IPv4. That is something that today is missing in the policy. I will agree to say let's go for /56 as default allocation but make sure that if anyone asks for upgrading that it's at no cost and that will shall certainly probably difficult to agree within the ISP community I guess. GEOFF HUSTON: By cost do you mean dollars? JORDI PALET: Yes. In addition to the heightened cost of renumbering if necessary or something like that. But that's something that maybe is acceptable, maybe. GEOFF HUSTON: Because it's normally beyond the bounds of RIR address allocation policies to specify pricing between customers and ISPs and I would suggest that it would be difficult for any RIR to enter into that space. JORDI PALET: That's the reason of my fear. That, if we open that door, it will happen. For example, I don't know here or in Asia Pacific in general but, in Spain, you want to have a single fixed IPv4 address, you are charged 12 euros per month and nobody is paying for that. And my belief is that, if we close that door, IPv6 will not be useful. I mean, one of the main reasons I see IPv6 useful is because the addressing space - nothing else the number of addresses itself but the number of services and applications you can open, I call it innovation in general deployment of IPv6 - it's not so useful maybe for IPv6, maybe. I know it's a lot more than with IPv4 but we're probably suffering from I will call it the syndrome of the exhaustion or something like that which I had with IPv4. I don't really think we can predict so clearly even following on the logic of your presentation when IPv6 will be exhausted or what are the risks or whatever like that. I also think that in IPv6 we have - and this is not a scientific thing because this is just a quick idea - we have something about expense so, if we move that maybe in future we can extend the sizing of the addressing space. I know it's not scientific but there are possibilities which we had before in IPv4. We have some of the doors to escape from that thing if it happens and my vision is that, if we have, for example, change in the HD-ratio, IPv6 for 60, 100 years, probably we will not really be using IPv6 or IP at all. Maybe we keep the same name but maybe it will be nothing related to IP in 100 years. So, again, it's a personal point of view. It's question also that has been raised before - how we dealt with customers - we have created rewards for the early adopters and also for the ISPs that ask it for these allocations. Are we going to claim back for those ISPs to reduce their allocations to something smaller? GEOFF HUSTON: No. Let me say no - this is not a policy about existing allocations. JORDI PALET: Yeah, but from my point of view, that would be unfair. I mean, if you have requested your allocation earlier, you have been already rewarded. RANDY BUSH: Yes, what he is not proposing is unfair. JORDI PALET: There is also some impact I believe. I think it was said already in the IPv6 global mailing list - I really note that that higher allocation has been probably against the recommendation of 3177 but that's the real situation, so that could have an impact. And the last one - I think doing these changes, even they are not protocol. I mean IETF changes impacts on the market perception about the stability of IPv6 and I don't think that is really good, making changes so late. I think I understand 10 years ago, yeah, or even maybe five years ago, but now I think it's a little bit changed and could hurt the deployment. KENNY HUANG: We have time constraints so make sure your question is short enough and we probably can take five or four more questions and with very, very short questions. TOMOHIRO FUJISAKI: I want to follow what was said by Arano-san but I won't repeat my comment - as I said in the mailing list the group has already IPv6 studies and we have a lot of customers and please consider the existing addressholders. GEOFF HUSTON: If you think you have a problem now and we're wrong with the /48 and we have to change in 30 years' time, think about the size of the existing customer base then and weep. Because you will have no chance, no chance whatsoever of changing the looming disaster then. RFC 3177 was wrong. APPLAUSE GEOFF HUSTON: Completely wrong. You're saying there's pain now. You haven't seen pain. The issue is that, if you're making an investment today, right now, right here, your money, in IPv6, you don't expect that technology to die tomorrow. You don't expect it to die even in 10 years. You expect your infrastructure, services, database, software, knowledge, capability, to last for as long as it can. If you adopt addressing plan policies that, if this is successful, cause a problem earlier than the true technology life cycle, then the only pain you're about to inflict is on yourself and on the rest of us. So the issue is, yes, the existing address plan changes, will cause some issues here. What's the long-term good of the technology versus your short-term interests today? How do you balance those? That's the question. That's the issue. IZUMI OKUTANI: I want to elaborate a little bit more on Fujisaki-san's point - I totally understand your point, Geoff, and we are not against that either. And the specific concerns we have is it's really a little bit maybe detailed but you say it's not intended to affect the existing users largely, so does that mean that the already-registered /48 assignments doesn't need to be renumbered? GEOFF HUSTON: Absolutely. IZUMI OKUTANI: OK and how about the existing allocation space? Do they have a chase as to whether to continue with /48 assignments - GEOFF HUSTON: You'll find that's not in the policy proposal as it stands today. I don't know and part of the reason in bringing this forward is to identify some of these issues and look at it a detailed statement about implementation. The point about existing allocations is well made and valid but, as I said, if that changes or if that impacts future allocations for other folk, then we're into a really big problem. So if what you're saying is, "Will existing allocations be changed?" No. "Will existing holders of allocations be changed?" That's not written here and is unlikely. IZUMI OKUTANI: But the absolute minimum thing we would like to consider is this and as long as this is confirmed, the idea or the concept behind this proposal, we think it's OK. RAY PLZAK: I'm not going to comment on the merits of the current proposal. I don't do want to ask one question though - and that's there is another allocation policy that exists in the APNIC region and in I believe most of the other regions regarding IPv6 and that's the allocation of IPv6 address space to what is termed 'critical infrastructure' and, in the APNIC region, I believe a single root server can qualify for a /32. Is this going to be taken up for discussion at some time by this forum? KENNY HUANG: Next question. EDWARD LEWIS: I want to comment about the proposal having been through the discussion in the different regions on this and every time this has been discussed, I think we talk about recommending the /56 allocation point and I think this goes through the point made here and what Izumi said earlier and I think if we try to put operational guidance at all in the proposal, we're getting into a dead-end discussion. The second thing I heard here for the first time too was the investment people have already in the existing policy in terms of their registry functions. I think that hasn't come up in discussions earlier. I think it's a consideration too. Think this proposal needs to be worded so it's a measurement of usage and not recommended ways of deploying the technology. GEOFF HUSTON: Usage rather than recommended deployment is what you're saying, thank you. RAM NARULA: In your opinion, how many hosts are useable under a /56? GEOFF HUSTON: 264 host per subnet and you have 256 of them so how many hosts are useable under a /56? You couldn't count. RAM NARULA: If I switch ISP, would - GEOFF HUSTON: Everything to IP address A has to now go to address B. You have to renumber machines; you have to coordinate the service structure and so on. Renumbering is difficulty. There are RFCs on the pain of renumbering. I don't think the story has changed. RAM NARULA: Have you considered portability issues? GEOFF HUSTON: Have you considered the routing? RAM NARULA: If I switched ISP, what would happen? GEOFF HUSTON: You get a /56 from the other ISP and press on. Renumbering is painful I keep on saying this. RAM NARULA: Would it cause an effectiveness probability in renumbering? GEOFF HUSTON: We're getting into a different discussion. SURESH RAMASUBRAMANIAN: His point is how long do you estimate it will take to fill a /56 up? OK, you have cellphones, pagers, fridges, but each of them has only one interface, one IP bound on it. GEOFF HUSTON: The issue is really about why you subnet versus why you put everything on a single layer between layer 2 and layer 3. It's difficult to conceive of small geographically constrained spaces having either massively different security domains or other reasons why you absolutely need to subnet. So 256 just seems to go "I don't understand why" but 256 is certainly better than 1. PAUL WILSON: It's not a question, just some observations. /48 assignment to any device or site that requires subnets is what RFC 3177 stipulates and I think if we think of future devices that require subnets, don't just include mobile phones but they include vehicles, robots, many, many of the sorts of devices that we're hearing about in promotional forums for IPv6 will require subnets. And at a /48 per device, if you look back to Geoff's figure of 19 billion /48s in a /2, 12 devices per person, 12 /48s per person in 50 years does not seem to be a very large number. Jordi mentioned that a /56 giving 256 subnets per household may be a little too low in some cases but I would point out that a /48 per house is not necessarily the end of it. You would have a /48 per ISP connection in your house and we don't know now how many possible ISP connections people may have in future. There are many possible industry development scenarios where there is vertical renumeration between devices and ISPs. You could have not one but multiple ISPs and it seems profligate to have that scenario. On the other hand, a /56 is a pretty small amount of address space and one can imagine all sorts of waits in which automatic request for an assignment of /56s to householders can be implemented in a way that doesn't provide overheads to ISPs in assessing (inaudible) On a more general level, I'm always amused by people today who say it's reassuring that IPv6 address space will last until their retirement and beyond or at least 100 years. We all, at the same time, talk about an IPv6 network that is going to be vast and if anyone can imagine or appropriately explain how we would transition from that IPv6 network to any other technology, I'd like to hear about it. We haven't worked out the IPv4 transition and the IPv6 - the transition from IPv6 to something else will require magic as far as anyone is concerned today. We can work that out, I don't think anyone should seriously contemplate running out of IPv6 space at all. Thanks. KENNY HUANG: Last question. RAUL ECHEBERRIA: I cannot speak higher. May name is Raul Echeberria from LACNIC. It's a comment - this is only to inform that this proposal is to go in the same direction of the same direction that was had in the last LACNIC meeting last June and we are aware that all similar proposals will be submitted for our next meeting this year. I think that what is seen as more important is the change in the HD-ratio because many people in America is seeing that as a way to avoid the same imbalance in the allocations of ISP address that is we saw with IPv4 in the past. This is a serious concern for regions in the late comers like Latin America and people like to prevent the same thing happening with IPv6 if the customers would have the opportunity to come back to LIRs in order to receive more addresses in the future, then it's a way to reduce the size of the allocations that are being made in this early beginning of IPv6 Internet. Thank you. GEOFF HUSTON: Thank you. KENNY HUANG: We can take no more questions and this is a policy proposal so we need to look for consensus in the policy SIG. Anyone who is in favour - RANDY BUSH: Can we separate the two proposals? KENNY HUANG: Can we separate? GEOFF HUSTON: Do you think it would help? I'm just asking - if you think it would help, then fine. RANDY BUSH: It would help me. GEOFF HUSTON: OK, fine. KENNY HUANG: Geoff, can you separate the proposal so people can have more understanding. GEOFF HUSTON: Can everyone see point three? "Evaluation for subsequent allocations to be based on an HD-ratio value of 0.94". That's the first proposal. TAKASHI ARANO: One question. This HD-ratio change - if this HD-ratio change is adopted - subsequent impact - HD-ratio change doesn't reduce the number of assignments, - how long do you expect - GEOFF HUSTON: The impact, as I said, is that the HD-ratio, considering the range of assignments, that change appears by simulation of history to have around a 90% change this total consumption, which is the equivalent of three bits. So rather than having the current projections with the current HD-ratio, those projections yield a /1 to a /4-ish. Changing the HD-ratio will give a total consumption of those projections 3 bits further out - /4, to around a /7. So it will give you back around a factor of 10. TAKASHI ARANO: So the implication is that IPv6 will survive 10 times, so 600 years - GEOFF HUSTON: If you think I'm a really accurate predictor, then faith in Geoff, go for it. If you think I'm bad at this job - and I think I'm pretty bad at predicting - then worrying. KENNY HUANG: OK, we can take no more questions, sorry. I suppose everyone understands the first proposal. Now the proposal is split so we have two proposals. Anyone who is in favour of the first proposal. Raise your hands. RANDY BUSH: Which is the HD-ratio? KENNY HUANG: Yeah. The HD-ratio. OK, anyone who is not in favour of the first proposal, please raise your hand. GEOFF HUSTON: That is proposal number three. KENNY HUANG: OK, thank you. The second question is the second half of this - KENNY HUANG: The first proposal reached the consensus so we can move to the second proposal. GEOFF HUSTON: The second proposal is points 1, 2 and 4. What it says is to add a /56 into the allocation points. The default for small office, Home Office end sites would be a /5 6 and for all sites, the HD-ratio allocation size that you would be using would be a /56. KENNY HUANG: So make sure people understand the second proposal. OK. Anyone who is in favour of the second proposal, please raise your hands. OK, anyone who is not in favour of this proposal, please raise your hand. RANDY BUSH: Could you think of a different question, Geoff? GEOFF HUSTON: Not on the fly, no, Randy. I would have to go back and consult, not only with the group who formulated this proposal, but also the group who would reword it. I don't want to do this on the fly. Thank you. KENNY HUANG: We did not reach consensus for the second proposal. We are running out of time. We can allow one more speaker. The next speaker will be alternative address allocations for IPv6 presented by Mei Weng from Cisco. MEI WANG: Hi, my name is Mei. I'm from Cisco Systems and I'm going to continue to talk about IPv6 address allocation. I'm going to just highlight some key points in my presentation and you can refer to the detailed slides later. The overall idea about this project is twofold. First of all we build an analytical model to quantify the effects of address allocation schemes in terms of fragmentation and efficiency and secondly we propose alternative address allocation scheme which takes the customersÕ growth rate into account and treat different customers differently. There's one point I want to make here - this work is - we're not trying to argue specifically how many bits you need to assign to each customer. Basically in any address allocation there are two key points and one is your initial allocation space, the slice of the block you give to each customer and the second part is where in the whole address space, you give out this block to the customer. We're more emphasising on the second point so the initial allocation slice can be either a fixed size, be it /32, /48, /56 or it can be variable size. What we are trying to focus here is to how - basically how you organise the whole address space into improve aggregation and efficiency of address space utilisation. This work is not possible without the board of these people. Balaji Prabhakar, Pankaj Gupta and my colleagues at Cisco Systems getting me into IPv6 to work on this problem. I'm going to give you high-level overview about this project and you can refer to the paper published this year at the Networking Conference for more details. I'm going to briefly give some introduction and background and actually Geoff's presentation already touched on many points I wanted to say and then I'm going to talk about both existing allocation algorithms and the one we're proposing. The results are backed up by both simulation and theoretical analysis and then at the end I will conclude. This is a figure we're all very familiar with. It is routing table growth for the past eight years. We can see the - as everybody knows, the routing table has been growing very fast and that is the motivation for us to do - part of the motivation for use do a good job in IPv6 allocation policy. And here are some of the points I think most of you are already very familiar with because allocation policy plays a very important role in routing and in IPv4 today, fragmentation is a problem and we're not - of course there are other factors that contribute into fragmentation and we're only trying to address the fragmentation thatÕs introduced by address allocation policies and in turn we're trying to control routing table size and improve the hierarchy in the address space. And the second motivation is even though we do have a very big address space in IPv6 but we still need to consider the efficiency usage of the total address space and right now is a good time. Since IPv6 allocation just started, it is a good time to learn lessons from IPv4 and try to do a good job from the beginning because IPv6 is a much bigger address space so we actually can't afford to not do a good job. Here's some brief background since this has been a very hotly debated topic and there's lots of non-technical factors playing in the policy decision. For this work we're mainly focusing on the technical aspect and trying to provide a framework to do some quantitative analysis. This is a problem Ð technically, this is a problem similar to dynamic number allocation operating systems back many years ago but it has new challenges and requirements. Usually the goal of allocation is threefold and today we're only going to focus on the aggregation and conservation of address space. Here's a hierarchy that we're all very familiar with and APNIC is sitting right in the middle. One thing I wanted to point out is a good allocation policy not only benefits for all the registries but for any entity, be it a company or university, whoever has a block of addresses to give out to its customers would run into this problem and a good allocation policy would be helpful there too. This is a review of the existing allocation policies for both v4 and v6. And before I get into more - before I get more into the allocation algorithms, I would like to lay out some very basic foundations to using our analysis. In research we can use a straight line to represent any available address space. For example, in this figure we're considering the 3-bit address space. So it starts from 0 to 23 - 1 and each customer's allocation block represents a space which is labelled in this block here and one key thing in this allocation is in order to maintain the aggregation, whenever a block grows out of this space it has to double its size in order to use one same prefix but with different prefix lines to represent the same customer. For example, if we are going to allocate a different customer right next to the existing one - say for example here - and if the previous customer is growing out of space, it can either carve out its neighbour and continue to grow - that will cause fragmentation because of the discontiguous of the address space - or it can choose a different address space somewhere in this address line to continue grow. That will cause fragmentation too or the third option is to move this whole customer to a different space which is not always viable and can cause lots of hassle. So this is an illustration of the existing IPv6 address allocation scheme. Basically you just - for every newcoming customer, it's going to divide the largest existing space evenly with the existing customer. So the first customer would be put at the very beginning and this is the second customer and then the fifth customer coming in is going to divide up the space between customer 1 and customer 3. This is actually a very good algorithm to give each customer the maximum space to grow. But the problem is it is treating every customer equally, which is obviously not the case in reality. So what we're proposing is to treat customers differently based on their growth rate and we're proposing several different schemes but the main idea is all about the same, which can be illustrated in this figure. Every time a new customer comes in, we're looking at all the available address spaces. It can be large, it can be small. And we look at the estimated growth rate for both existing customer and the new customer and then put the new customer in the space where it takes the longest time for either the existing customer in that space or this newcoming customer to run out of space, which we call collision. And here is an example. We have customers with different growth rate. For the first four customers we allocated the same way as the existing allocation scheme which we call bisection. And for the fifth customer - by the time they come in we can see some customers already growing a lot faster than other customers and we have four choices to put the new customer here. So the fifth customer, instead of putting right behind customer one, as in the bisection scheme, now we're putting it behind customer three because customer one grows a lot faster than customer three and for the sixth customer, not only do we have all the big slots available as candidates but also we are considered in some small slots too. For this case, both customer number three and six are growing very slowly so it makes sense to put them together. . You might have a question about how we estimate the potential growth and I'm going to address that as the discussion at the very end and for now we just assume we roughly know about the growth rate of both existing customers and the newcoming customer. So we did some simulation work based on this idea and we did some - made some assumptions. For example, the form of growth which actually can be in any form and we used exponential - the data we're going to show you is based on exponential growth and we also assumed different profile of the growth rate distribution and the random sequence of the incoming customers. In our measurement we're looking at two things - first of all we assume - we look at before the first collision ever happened, which means before any customer in this whole address space runs out of address space to grow we measure the total number of customers we have served and the total address space has been used. And the second - looking at it from a different angle, if we do allow collision, we measure the percentage of fragmentation caused using different allocation schemes. This is an illustrative figure and the X axis is the total address space and the Y axis is the time scale so at the very beginning we have one customer and then the second customer comes in and so on and so forth. We can see by the time around like 15, one of the customers is running out of space. This is using bisection scheme and we can see how many customers we have served and how much address space these customers have taken. And similarly we did a simulation for the growth-based scheme and we can see in comparison the growth-based scheme where you take advantage of the information about customers with different growth rate. You can serve a lot more customers and can make efficient use of more address space. And this is some detailed simulation data. We can see for a growth-based scheme the number of customers served has been dramatically larger than the bisection scheme. And same thing for the address utilisation. And this is the simulation that if we allow fragmentation - sorry, if we allow collision to fully utilise the address space. And this is the difference in terms of fragmentation and we can see bisection introduce a lot bigger fragmentation than the growth-based scheme. I'm going to skip the theoretical analysis. Basically we built a theory model and using this theoretical model, without the need to run any simulation - if you tell me the basic conditions of the customer growth rates and incoming time, I can tell you exactly when you're going to have a collision and also about the space utilisation, rate and the number of customers you can serve. I'm not going to bore you with all these equations. And this shows the theoretical analysis matches pretty well with the simulation. Finally, the discussion about the growth rate estimation - we actually allow any form of estimation in terms of growth rate. It can be either the percentage of occupation, it can be the projected growth rate. It can be anything. And also Geoff did some very interesting work using the different method and taking advantage of the existing IPv4 data to simulate IPv6 and pretty much reached the similar conclusion. And one last thing I want to talk about is - you might have questions about what if the estimation of our growth rate is wrong? And the thought on that is first of all you don't have to be exact on your growth rate. There is still plenty of room for you to make mistakes and still for the scheme to have advantage over the bisection scheme. And also every time you have a new customer come in you can re-evaluate the existing customer and re-adjust the growth rate. And usually there's still plenty of space for you to correct any error that was made previously or any sudden changes. For one case that the scheme doesn't work or doesn't have any benefit is if there's a fast-growing customer coming very late into the address space, which means the address space is pretty much full, and this customer is growing very fast. And for that case you're pretty much doomed for any scheme. You basically need to find a different resource to fill the need for this fast-growing customer. So in conclusion, we provide a quantitative model to analyse the facts of different address allocation schemes in terms of fragmentation and efficiency of address usage using both simulation and theoretical analysis. And we propose an alternative IPv6 address allocation schemes to take advantage of the customer information, especially the different growth rate for different customers to reduce fragmentation, increase address space usage, aggregation and efficiency. That's it for my talk. Thank you. Any questions? KENNY HUANG: Sorry, we are running out of time and sorry to rush you, Mei. We are running out of time so the tea break is served outside and we can come back at 11:10. Thank you for your time and for enjoying the first section. Thank you. APPLAUSE MORNING TEA SECOND SESSION TOSHIYUKI HOSAKA: Our first presentation for this session is ÒResource recovery policy Ð implementation updateÓ by Son Tran from APNIC. SON TRAN: We are trying to reduce unauthorised use of resources by spammers and hijackers. The proposal was presented at APNIC 17 and the EC endorsed it in May 2005 and we started to implement the policy in March 2005 and because the policy required us to implement in one year this is why it ended in March 2006. Some definitions here is the ÔhistoricalÕ - we are referring to resources distributed by APNIC without any formal agreement with the organisations or AUNIC's address space and ERX, early registration transfer address space or any address space that were distributed in the Internet. ÔUnroutedÕ - anything not visible since 1998 and unused means that unrouted and also not used in the private network. We have come up with this brief procedure when we start the policy in March. We compiled a list of affected blocks for all the IP address blocks and addresses given to AUNIC before 1997 and all the InterNIC address space that had been transferred to APNIC. Then we compare - check the prefix against the prefix advertised in the database to see whether it's visible. It's if not, then we will contact the custodian of this prefix by e-mail where possible and, if e-mail is not available, we will try to contact by other means, like phone and fax. Repeat the process every two months for one year and, if the resource is still unused and uncontactable, then we will recover the resource. We started to implement in March 2005 with over 2,000 prefixes and, in July, that's the third e-mails we sent out, there is only 1,250 that we have to contact. There are 2 /17 prefixes without any e-mail contact, so we have to contact them by phone and fax. And also there is a lot of invalid e-mails, because these are old resources that were issued a long time ago and the contact is not updated. Just some statistics for your information. Can see that, since we started, 40 prefix have been announced in the global routing table, which is equivalent to 2% of the total prefix that we're trying to reclaim and also that 160 prefixes have been reclaimed by the custodians of the resource and there are quite a lot of uncontactables and so on and of course 41 prefix returned to APNIC after we contacted them. In terms of the total IP addresses that we are trying to recover more than /10 at the moment and if you look at the total there, the total return is not much and the total routed IP address is is 0%. We examined them in detail and found that most of them are mainly class C address space that have been rerouted after which contacted them. That's all I have and I have a couple of minutes for any questions you have. TOSHIYUKI HOSAKA: Any comments or questions? OK, thank you, Son. So, next presentation is coming from Uchenna. This is a policy proposal for discrete networks and national peering. UCHENNA IBEKWE: Good afternoon, everyone. My name is Uchenna from MCI. I'm director of operations for MCI, which includes LACNIC. I'm going to talk today about a proposal for discrete networks and national peering. Now this is similar to one which we presented at APNIC 17, although we made some changes to it and basically what we seek to do here is basically as a very large ISP spanning various continents what we seek to do is have one APNIC account and then under that APNIC account have multiple discrete networks. Now discrete networks are based on countries, because currently under the current structure we have about 11 countries in Asiapac and each one has an APNIC membership and what we seek to do here is have one membership account while having 11 for example discrete accounts, discrete networks. Now, this applies to very large ISPs and is not just connected to MCI. What we are doing essentially is saying to the community, "If an ISP qualifies for this status, they can apply upon request." So it's not something that's going to be applied across the globe. So these are the topics I'm going to talk about - highlights, benefits, criteria for qualification, the actual proposal, fees and some reference material which talks about how ARIN has implemented it. These are the highlights. So we have it in two categories, the discrete networks which is going to be Ð (1) country-based, that is Japan, Australia, and different countries. And the other one will be service based, like you have different kind of networks, MPLS networks and those are going to be global. They're not going to be subjected to national regulations or national laws or national peering policies. So here, this is a kind of structure which shows an example, for example - MCI will be MCI-AP, one single account with APNIC and would have subsequent accounts like Australia would be MCI-AU and Japan will be MCI-JP - this is just an example - and then we could have service-based networks, which could be internally used specialised services. The other ones are basically customer-based networks. Now, I had a lot of comments about HD-ratios. That's not going to be affected here in any way what we're trying to do is this - the main account, the membership account, which is one account with APNIC, will want to be affected on billing issues. In other words, discrete networks, everything that applies now to every criteria now in a country will still apply on a district network level. Now, this is a kind of segmentation of the MCI network where you can see from that segmentation is that we have different market, market segments and different networks that are autonomous, having its own AS number and following what we call confederations. And based on this structure, we would like to have routed on aggregates so that each region has a routing aggregate where we do different kinds of peering. The national peering is between countries and then the global peering and intercontinental peering come into play. No, with this proposal, we seek to have this applied in IPv4 - it applies more to IPv4 than it does to IPv6 but we seek to apply certain parts of it to IPv6. I'll explain that as we go on. Now, we're going to talk about some benefits. Now, simplification of management. It makes it better for us, because we do not have multiple accounts. You have multiple accounts thank they pertain on a district network level. We have one account with APNIC. It makes it easy for us. It simplifies billing. Right now, we have problem 11 billing cycles and that's just not very easy for us to manage and like I said, this does not apply to everybody in the industry. It applies to the qualifiers and I'm going to talk about qualification criterias. Then I mention peering. For us to actually implement an IPv6 network effectively we need to use national peering and we need to use global peering because, for different hierarchies and different customers, we're peering them on different levels. Some are peering them at a global level and others at a national level and there are regulations and laws in certain countries, for instance China. In China and in Chile for example. Chile differentiates between national traffic and international traffic and there are two different traffic networks and they do not interconnect at any point. That means, if you want national traffic, you have one line for national traffic and the national traffic network and if you want international traffic, you have a different line to the international traffic network. And that's modelled - the model that China seems to want to implement. And we only have that model working in Chile today. And then there are other considerations. And the other considerations are NAPs, which are called Network Access Points. We have aggregates that compare with other ISPs. One other thing is that this is in no way affecting any policies that anybody is talking about today. Neither does it affect the HD-ratio. It only affects reassignment. All the accounts we have now would be discrete networks and one major APNIC account. So this is just a realignment. It gives us the facilities to be able to use what they call analysis, mathematical analysis, it gives us a format to be able to - the framework to be able to analyse our network better on a global level, on a national level and then on an intercontinental level. These are some other considerations that I have mentioned - legal and national considerations. IPv6 - is IPv6 going to solve all our problems? Do we need our structure. Yes, we do. And for us, discrete networks is something we need to support the IPv6 implementation. Security benefits? Yes, there are security benefits and routing benefits because of national peering, the international framework can segment networks and segment what traffic goes from one site to another and do policy-based policies on those interactions and routing between national peers and global peers. Criteria for qualification - what happens here is we copied basically what ARIN has for this. ARIN has a similar one. In ARIN's case it only applies to IPv4. Here, one of the things is a single entity - not a consortium of smaller entities. The policy applies only to organisations that have been previously granted address space by an RIR and the other important thing is that they must have at least one or two discrete networks to be able to qualify for this. Moving on, now, how are some other compelling reasons for qualification - regulator restrictions for data transmission, which is what APNIC does today, it gives a /32 as a minimum assignment and that's what we're using as a minimum assignment for a country, autonomous multihomed networks, which we have - global peering and the segmentation of our network. Then the other things which we talked about, the HD-ratios apply in a discrete network level. The actual policy is one that was done in ARIN and approved - although there were various changes to it but the one in ARIN applies only to IPv4. We seek to extend not just to IPv4 but into IPv6. Fees - all fees are going to be done on the big main account, which is the single APNIC account which is like MCI-AP. All fees will be assigned to that. It will be medium, large, depending on how many IP addresses we have under that single APNIC account. References - these are some of the documentation you can read up (refers to slide) You can see the APNIC references, the similar proposal from MCI, which we withdrew. The person that actioned it put in a proposal and left MCI. This is quite different to that one. That one was only for IPv4. I'm trying to keep it short so we can have some time for questions if you have any. So question time. TOSHIYUKI HOSAKA: Thank you. Any questions or comments? PAUL WILSON: Paul Wilson from APNIC Secretariat. I'm finding it hard to understand the fee implications of this, or the financial motivations behind it. One way to look it is the fact that we've got quite a number of organisations and a lot of accounts. There are I think 33 separate organisations holding multiple accounts and enter is a total of just over 100 accounts in that collection. So there are 33 organisations holding anything from two to ten separate accounts. Now, if all of those accounts were merged together in a financial sense, then there would be quite a considerable saving for the account-holders for those organisations holding those accounts and corresponding to a loss of revenues for APNIC, which can be analysed and which has been analysed. But you haven't really addressed that issue. So I'm wondering whether this is a motivation which is not really properly disclosed in the presentation or whether your mind is open about the impact on you as an organisation. UCHENNA IBEKWE: Yeah, well, I see your question. ItÕs something that I have considered, or we have considered but we had the option already to merge into one account so we didn't see it as a big difference per se. APNIC had offered us in some sense to have just one account and irrespective of the different countries and everything would apply in one account and it's the same billing issues would pertain to the new structure. So I didn't think that, if we had the option to go in to one account that the fees would actually be an issue. That's why I had not put it in there. PAUL WILSON: I guess this is a situation where the different aspects of your membership, that is the amount of - the fees that you pay and the way that you need to manage your accounts, they sort of have ended up with a certain balance at the moment - the number of organisations who choose to have multiple accounts and therefore pay a certain amount for those accounts and at the same time they have certain management overheads or a certain situation in managing their overheads. Now we're fully aware that the offer to merge multiple accounts comes with a serious disadvantage to the accountholder in that you then have a single pool of address space to manage. So it's not feasible for many accountholders. Some do that and are freely able to do-and-are encouraged to do that. The point is at the moment we have a certain balance which has arisen out of the individual requirements of organisations and management of pools of addresses through multiple accounts and a certain resultant fee situation, revenue situation for APNIC. So to make a sudden change which enables a lot of merging of multiple accounts would have this sudden impact. I'm just wondering, again, about the motivation. UCHENNA IBEKWE: That's not the motivation. That's not the motivation. I would think that, this is a body that has assented to severing us and processing and giving us the freedom to manage accounts better and that would mean that if I could merge them all into one account and the fees for merging them into one account is the same as having discrete networks, I wouldn't see what the catch is. But, at the same time, it's something that can be negotiable and I don't think it's a substantial loss in revenue for APNIC. PAUL WILSON: The point I'm getting it is exactly what you've said. You're asking the meeting to consider the technical aspects of this proposal and not the fee aspect and the fee aspect is something that would be determined by a different process, for instance by the Secretariat. UCHENNA IBEKWE: By the Secretariat, exactly. And it is part of the proposal. PAUL WILSON: Thank you. GEOFF HUSTON: Geoff Huston, APNIC. Have you considered why the HD-ratio doesn't meet your requirements in this space? If you go back - I think it was slide 7, where you had the world set up into a number of discrete areas and you would like to be able to aggregate within that area and present a single aggregate within that area. Is that not precisely what the HD-ratio was allowing for? Because the HD-ratio basically says that very large networks want to aggregate at levels within. And the overall result is a lower utilisation rate than if you apply it separately. From a technical point of view - I'm ignoring the business aspects here - from a technical point of view of assessing your use of addresses, why would the HD-ratio be inapplicable and why are you instead asking for a difference to the policy structure of saying, "I want these entities considered separately for their utilisation"? UCHENNA IBEKWE: Like I pointed out, the HD-ratio applies to the discrete network level. Now, what we're doing there essentially is the fact that we have different situations from country to country. Say for example - this is just for example - Singapore - the growth is not very large in Singapore. But look at Japan and look at Australia. It's booming. And if I went to combine each HD-ratio, it's still not going to meet my requirements. We have looked into this. And we find that it is better for us to actually manage it per country within geographical areas based on assignments. Because we have fast-growing economies and very slow-growing economies. And that's why we decided that we would be better to apply the HD-ratio on the discrete network levels instead of on the one membership account. GEOFF HUSTON: OK, I appreciate logarithmic relationships in. HD-ratio are never straightforward. They're always so much fun to deal with. But the HD-ratio actually was intended to deal with precisely your situation. Its background actually comes from the telephony background where, in each area code of numbering, there are multiple providers and you have to actually aggregate addresses in different areas and there are different growth rates in each area and the HD-ratio came up from that industry as a way of looking at the larger picture and, at that point, the national level. But that situation has almost precise mapping into what you're describing here, that I have a number of areas that I want to discretely aggregate who are growing at different rates. How can I measure the overall utilisation efficiency and apply a common metric across many players? And that, if you will, was the philosophy if I can use such a word, of what the HD-ratio was intended to do rather than a flat 80%. So this is why I'm looking at this going, "You seem to have described the motivation for using HD but have come up with a different answer," and I'm curious as to why. UCHENNA IBEKWE: I don't see it as a different answer. If you wanted, you could actually calculate the HD-ratio per country. You can look at the application in a global sense and get different answers. GEOFF HUSTON: I think you might find, if you did that, you would come up with an HD-ratio value of somewhere around 0.85 or 0.87 in your network. UCHENNA IBEKWE: Based on what? GEOFF HUSTON: Based on what I'm seeing in your slides. UCHENNA IBEKWE: I did not talk about HD-ratios and I didn't want to. I wanted to say that the HD-ratios apply at a discrete network level and we have one single account. How does that affect my situation now and the new structure? On my situation right now, it's the same thing. Nothing changes. Because I still have to do them per country. If I change that structure, the new structure that I'm proposing - it still does not change. GEOFF HUSTON: I see your point but I suppose what I'm saying is, take your operation as a whole, the HD-ratio applied as a whole would give you the same outcomes. We disagree a little bit here but I understand. SON TRAN: Son Tran from APNIC. Just to let you know that, in the past, we also had this kind of membership for confederations and because we have stopped allowing this sort of membership to exist in the APNIC area and how we are handling them at the moment is we are making direct allocations to each of the discrete networks rather than to make a big pool of IP address to the member and then the member distributing to each of their members. UCHENNA IBEKWE: Yeah. I'm aware of that. I'm aware of that. And that is why we have this structure, because you are giving allocations based on discrete networks within countries. ANDREW DUL: I'm the author of the original ARIN policy. One of the things that I think this is more about with regard to v6 is this sort of goes to - it's more about minimum allocations for geopolitical boundaries in my opinion than about the HD-ratio. To my mind, what this proposes is a /32 per geopolitical boundary, regardless of usage within that economy so it's sort of basically taking - and I agree with Geoff that, if you apply the HD-ratio within the hierarchy, you could obtain a similar level of utilisation measure but we're basically saying we're going to ignore that that can exist in the HD-ratio and set a minimum allocation for geopolitical boundaries. As far as the v4 part, the v4 part somewhat speaks for itself because it's such a - it's a threshold that divides networks into smaller bits. You have ones that grow faster than others and you have a very hard time making an 80% ratio in each of the areas. So I think the v6 part of this policy is interesting and, if people are OK with the minimum allocation for a multi-national company being a /32 for a national network, that's the really big question that I think we should be answering here, regardless of how well they use the network. So if you have a very small island nation and you serve 10 people, you have a /32 allocation. Is that OK? I don't know. That's what you get with this policy. TOSHIYUKI HOSAKA: Any other comments? Alright. I would like to clarify that the fee, the fee itself is determined by a different process, by the APNIC Secretariat. Is that a correct understanding? UCHENNA IBEKWE: Yeah. TOSHIYUKI HOSAKA: OK, this is the policy proposal. I would like to seek consensus for this proposal. Those who are in favour of this proposal, please raise your hands. ANDREW DUL: I think you should separate the question into v4 and v6. Think there are different interpretations of how you use a policy in v4 or v6. I don't know if that changes the result here or not. TOSHIYUKI HOSAKA: Would you like to separate? UCHENNA IBEKWE: Yeah. TOSHIYUKI HOSAKA: OK. So the first is for IPv4. OK? Is that OK? Regarding IPv4 networks, those who support - those who are in favour of this proposal, please raise your hands. OK, regarding IPv4 network, those who are not in favour of this proposal, please raise your hands. OK. And the next question is regarding IPv6. OK, sorry, before we go into IPv6, it was very difficult to say this is a consensus, since the number of hands is very limited. Regarding IPv6 networks, those who are in favour of this proposal, please raise your hand. Regarding IPv6 networks, those who are not in favour of this proposal, please raise your hands. Thank you. Unfortunately, we can't say this is the consensus, so please consider to come back again and come back again to clarify some points raised by the community. TOSHIYUKI HOSAKA: The next speaker is Save Vocea and he has two presentations. SAVE VOCEA: Good morning. I am Save Vocea. I'm from the APNIC Secretariat. And this presentation is informational, just to share with the APNIC community the policy developments that have been under discussions within APNIC and also the other RIR communities. Sourced from the - we asked the other RIR communities to share with us what has been under discussion and some of the previous discussions you have heard some of the representatives mention there. I wanted to say again - for the sake of people who are new to the policy development process - that APNIC operates on policies that are current and for any policies that need to be changed, it needs to be - I mean, people need to propose policies if there needs to be some changes to the policy. So that's what we're doing here today, having discussions, proposals need to be submitted to the SIG mailing list at least four weeks before the meeting. And we encourage the community to participate via the mailing list and then try and get consensus at the meetings. And tomorrow, the SIG chairs will summarise what has happened here today to report back to the ML and go through consensus again. Then there is a comment period of eight weeks after the AMM where it's taken back to the mailing list to see if we can reach consensus or achieve consensus for the mailing list. And EC goes through an endorsement process and implementation is three months after that. I just wanted to highlight here - the blue buttons is where we are participating as a community. You can participate in those (refers to slide). Since the last APNIC 19, there have been a few proposals that have been implemented. Recently, the ICANN board implemented - adopted the proposal on IANA v4 resource request procedures for the RIRs also, there's two proposals that are going to be reported at the DB SIG by Sanjaya, a proposal on the Ipv6 Internet routing registry and APNIC to publish address assignment statistics. Prop-027-v001 - the second phase of large space IPv4 trial usage program for future IPv6. As you heard it's been approved. These are the current proposals. They're referenced in the APNIC website. (Refers to slide) So, as you heard already today, in this SIG, there've been three proposals that's been presented here and been heard for discussions. Yesterday, there was abolishing IPv6 per-address fees for NIRs in the NIR SIG and later on, after the session today, is the DNS SIG, where APNIC has a proposal to deprecate the ip6.int reverse DNS. Going to the AfriNIC community, we have currently under discussions three policies for end user allocation policy - that would include the critical infrastructure. The minimum allocation is a /24. We're also discussing the temporary address assignment policy and what we want to do is people can have assignments of addresses to them in one-month duration and this is returnable back to the pool. And also to modify the ASN assignment criteria, where they want members - those requesting ASNs to be members of AfriNIC. \In the ARIN community, as Ray has mentioned in this morning's discussions, they have proposals to amend the v6 assignment and utilisation requirement and also the IPv6 HD-ratio. This was the combined proposal that Geoff mentioned this morning. There are also other proposals - seven of them - the AfriNIC recognition policy and also the overhaul of directory services. Moving on to the LACNIC community, as in other RIRs now, they have also the global policy on v6 allocation from IANA to the RIRs. And there was two policies that - the recovery of unused Internet resources and the v4 additional allocation policy for international ISPs that were discussed but they didn't get any consensus on that so it's been taken to the mailing list. They required more definitions. As you heard from Raul this morning, they were actually talking a lot on v6 size management. For the RIPE community, they have a proposal for applying the HD-ratio to v4, similar to what APNIC had proposed in APNIC 18 and there's a presentation coming after this that I will present on the LIR survey. The other two proposals that's been under discussions are IP assignments for anycasting DNS servers and v6 initial allocation to remove the requirement for 200 customers and that has been revised, the proposal is being developed. The other proposal that you can find - it's all on the website (refers to slide). Only last week, they formally adopted the policy process and that's to be implemented. Just to summarise the common topics that all the RIRs have - there's the global policy on IPv6 allocation from IANA to the RIRs, which you heard today. Also, almost all the RIRs and the communities in the RIRs are discussing v6 assignment management. The three RIRs APNIC, ARIN and RIPE, in recognition of AfriNIC, editing the documents - or have edited the documents to recognise AfriNIC. And the application of HD-ratio to v4 is being discussed with APNIC and RIPE. And that includes my first presentation. TOSHIYUKI HOSAKA: Thank you. Any questions or comments? IZUMI OKUTANI: I have one question. Izumi from JPNIC. I'm kind of interested to know the status of discussions in other RIRs regarding what affects our community as well - i.e. the proposal on IPv6 policy. Are people generally for the proposal or against it? SAVE VOCEA: Well, we have some representatives from the other RIRs, but what I've seen in the ppml mailing list, it's really a busy mailing list that's discussing the v6 assignment. ANDREW DUL: I think the HD-ratio change will gain consensus at the upcoming meeting. I am unsure about the /56, /64 /48 mess. I think it's too early to tell based on what I see on the mailing list. FILIZ YILMAZ: I'm Filiz Yilmaz from RIPE NCC. In our region in the last RIPE meeting, that was kind of wrapped up the IPv6 policy and the proposal is to be revised again because there are two issues there - the removal of 200 customers and moving to national /48s and these are different points. So the author was asked to revise the proposal to address the issues that were raised. So there will be a new proposal about that. ANDREW DUL: One other comment on v6 - the ARIN region is currently evaluating a couple of different policy proposals with regard to v6 multihoming. Specifically allowing for end sites to receive allocations directly from ARIN, even if you're not an LIR. There's quite a bit of controversy surrounding this topic, specifically the criteria you decide as to who is eligible to receive an end site allocation. I think there's a general agreement that large multi-national corporations who aren't specifically LIRs but have very large networks, it would probably be beneficial for the deployment of v6 to allow them to have allocations directly from a regional registry. But where do you draw the line between a large end site and a medium end site and who gets a routing slot is very controversial. RICARDO PATARA: I'm Ricardo Patara from LACNIC. I would just make a point as Raul has before. We had discussion in our region about allocation of v6 to their members but it's just some informal discussions. TOSHIYUKI HOSAKA: Thank you. Any other? SAVE VOCEA: This is the LIR survey results. It's informational and many of you are waiting for this data to be shared at this meeting and it's in support of the survey. Why did we do an LIR survey? There is a proposal called "application of HD-ratio to IPv4" prop-020-voo 1. And the feedback was that 80% utilisation is difficult to reach and you need to achieve 80% of the address space you hold to receive a new allocation. The proposal was presented at APNIC 18 by Paul and Anne and the proposal document is at that URL (refers to slide) But during that meeting there was no clear support or disagreement with the proposal. So the action on the Secretariat, which was also read out this morning, that "with assistance from the NIRs, to conduct a survey of ISPs' resource management practices to allow a better understanding of issues" to provide a better service to members. Just to recap on the HD-ratio, it states that "increasing hierarchy in network leads to decreasing efficiency in addressing" and that "HD-ratio value matches percentage utilisation which decreases as size of address space grow" and it's the log of utilised host addresses over the log of total addresses. Now, we conducted the survey. There was a set of questions that was prepared and I'm just putting up a slide to show what the survey is. There's been 14 questions. But one of the important ones was question 13, asking those that were surveyed if they had experienced any problems reaching 80% utilisation of the v4 address space and for them to explain some of the problems. Those survey questionnaires, with the help of the NIRs, were translated using our translators in the Secretariat. So, in the actual design phase, there were a number of people in the community who were consulted - the network operators - by phone and this was done by answer. So I'd like to thank those people that were consulted in putting the questions together. And the survey was done as a qualitative survey, which meant that we needed to have face-to-face interviews and that was voluntary. And this was conducted, as I say, with the assistance of the NIRs and also through the APNIC training team. When they went on training, they asked the ISPs that were present if they could be interviewed. So many thanks to all those that assisted in this survey. And it also provided us, you know, to ask extra questions on the NAT use and the v6. A lot of the responses that we got - we had 67 responses in total from the 15 different economies. And this kind of reflected the profile of the APNIC membership. So, out of the respondents to the survey, at least six of them have deployed IPv6 and 30, or 45% of them are at some stage planning to use v6. And the members experiencing problems with 80% policy - we have 27 respondents with that and 27 said they were using NAT. Just on the methodology for the analysis - using the hierarchy measures as a key to HD-ratio impacts - so it meant that if the trends show the relationship with the hierarchy, then it's very likely that the HD-ratio will address this and so we were focusing mainly on the 80% issues for the respondents that had 80% issues. And also consideration was given to existing use of v6 and NAT on the membership tier and the address management models they used - this was service type offering, geographic location and technology type. Just to give you some slides on how we analysed this data. Was the number of member categories that were surveyed - very small to extra large and the respondents are in blue and those that have 80% problems are in purple there. So you can see the - what do you call them? - the relationship. Responses by member economy - from the 15 members, it's interesting to see that some of them had 80% - Indonesia with the most amount of responses - none of them said they had any 80% problems but in other bigger economies, although they have 80% problems, some of them had already started to use v6 or are in transition to use v6. The smaller Pacific island countries, I think there was only American Samoa, Fiji, their small networks that had problems. To look at the number of PoPs, you can see that the more PoPs you have, the more problems but looking at this graph there's no clear distinction on whether that is a problem as well. And on the service category - this question here, we asked the interviewees that they could choose as many service categories that they feel they were offering as a service. So there could be some kind of link with broadband and DSL service that they could be the same and so, in their category, some of them had 80% problems. So just looking at the number of service categories offered, those who offered more than one service, you see the relationship there. It's still a big trend. We also asked questions on the distribution models, looking at geographic location, customer type and product and we asked them whether they could pick one or two or more or all of the BoF. That was the relationship that we've got. And it's just putting them all together, the number of address distribution models used in another form. The type of NATs used - those who didn't use NAT, 15 said they didn't use NAT although they had 80% problems and those using NAT in infrastructure was about four and the customers networks, there was about eight. And we also asked them why were they using NAT and many of them - for some, they said it was because of conservation, security, or lack of IPs. But that was only one. Some said there were customer service or policy issues and some said they didn't use NAT. To put them together in a scatter block, there still a big trend from the service types versus hierarchy. We asked them to draw their hierarchy levels. It seems the more the hierarchy level. There were the number of service categories offered. There was a weak trend. Also, with the PoPs versus the hierarchy, that's the graph. And the member size - as the member size grew, there's still not a strong trend to indicate that people had problems in this area. And the address deployment versus hierarchy. The number of v4 address deployment models used against the hierarchy. No trend as well. So the range of address deployment models used. So to conclude the survey, there's a total of 40% reported problems reaching 80% utilisation but, as I said, of this 40%, some of them are already transitioning to use v6 and some are using v6 now. There's no correlation between the problems and the network size or complexity measured as the number of PoPs, the number of services deployed and the number of levels of hierarchy. So, as part of the presentation, I wanted to ask these questions - what are the next steps from here? Do we need to widen the sample size? Should this proposal cease? Should this be continued for discussions on the list? Or wait and see what the situations are in the other RIRs, like in RIPE they're having these discussions as well. Thank you. TOSHIYUKI HOSAKA: Thank you, Save. Any questions or comments? No? Thank you. The next speaker is Ching-Heng Ku from TWNIC. CHING-HENG KU: We are concerned about how to transfer the IP address space of the customers to the new LIR when the ownership of the LIR does not change. The current situation is LIRs may transfer Internet services, for example, lease line, FTTH and so on, and their corresponding customers to other LIRs. Those transferred customers who have static IP address tend to avoid renumbering. APNIC policy documents mentioning about the mergers, acquisitions and takeovers of the LIRs only focus on LIR's ownership changed. So the policy refers to the APNIC policy. With will share TWNIC's experience in IP address transfer. This diagram shows TWNIC members, including the LIRs and end users. The TWNIC LIR must have IP address space allocated by TWNIC. The end users must have the IP address space assigned by LIRs or TWNIC. So with the issue of IP address transfer, we have already defined an IP address transfer application form. We have some - this table shows the application form (refers to slide). We hope to request the origin and the new LIR have signed this table - signed this application form, including the size and the blocks and the service type and then the transfer reasons. We have defined a transfer reviewing procedure. The first step - the old LIR must fill in the application form endorsed by the new LIR and submit it to TWNIC. The second step is TWNIC will approve the application, according to the following criteria - the first one is the transfer sides of the IP address space must be larger than /21. That's the minimum allocation. The second is the new LIR must be or will be the new NIC LIR. Third step is the new LIR must update the Whois date bate. If necessary, both member level of LIRs will be adjusted or eliminate by TWNIC. So the summary of the presentation - in the practical business model, the IP address space transfer will not be happened only if the LIR changes his ownership. So, in order to cover the whole situation for the IP address space transfer, we define related documents and propose the transfer reviewing procedure. We need more input and comments based on the transfer reviewing procedure from this community. That's all my presentation. Thank you very much for your attention. TOSHIYUKI HOSAKA: Thank you very much. Any questions or comments? No? Thank you. OK, Paul, please. PAUL WILSON: Paul Wilson. One thing that's not clear to me is whether the address space transfer is linked to the transfer of the network infrastructure in every case or whether there are addresses being transferred without the actual associated network infrastructure. CHING-HENG KU: Because the LIR use their IP in their infrastructure and their customers, they will - most requirement from transfer the customers. But, if the LIRs transfer all their IP addresses, we propose to cancel this with LIRs. PAUL WILSON: The question is why they are transferring addresses? Is it because they've transferred a whole network infrastructure from one company to another or because they're just selling the address space? CHING-HENG KU: Because the requirement for LIRs - maybe it's their business decision so we have the real requests from the LIRs. They hope to cross the service of this service and move the address customers to another LIR. TOSHIYUKI HOSAKA: Thank you. That's it. So the last presentation is from IPv6 Promotion Council of Japan. Sawabe-san please. NAOTA SAWABE: My name is Naota Sawabe from IPv6 Promotion Council of Japan. Today, I will report "large space IPv4 trial usage program for future IPv6 deployment". The topics: I will update since the last meeting and explain the second phase of this program and kick-off schedule. First of all, I will talk about regular hearing session. I the current active participants and there is a newcomer, WiMAX-type wireless access provider. YOZAN participated in the program in June 2005 and they provide IPv4/IPv6 dual stack wireless access services based on WiMAX technology. They started the trial service in June 2005 and they utilised the IP version 4 address space from our program because the trial is about the /16 address space. Now I will introduce the results of the hearing. This was in August. The results of hearing are summarised into three points. First - many of the trial participants are very positive toward providing IPv6-based services. Second - however, they say it is difficult to deploy IP version 6 service completely and hard to return the IP version 4 address. Most of you still demand IP version 4. Third - when we told the participants of the program extension, it was very welcomed by them and we explained to the participants the shift conditions from the current phase 1 to the phase 2. And if phase 2 starts, many of them will continue this program. I will skip this section. And I will tell you the situation of preparation of the second phase of this program. We proposed the second phase of this program in APNIC 19. And this proposal received consensus in favour at APNIC 19 and it was endorsed by the Executive Council later. The second phase of this program has two points. First - this program is from 2006 to the end of 2008. No more extension is considered. And second, we renew the rule and the contract. In this contract, it is necessary to show IP version 6 service study during the second phase trial. Here I will introduce execution policy of this program. There are three points - first, the participants of this program have aimed to achieve trial target. The trial target centred on the achievement of the business service that use IP version 6. And the need to show IP version 6 service starting plan. And second - when they cannot achieve the trial target, the allocated IP version 4 space is promptly collected back. And so, if the participants achieve the trial target and want to use the IP version 4 space, the service is provided in IP version 4 and IP version 6 dually. We will discuss with APNIC or JPNIC to find a way to make it possible for successful participants to be continuously used the IPv4 space. At the same time, we will start discussing about how to return the address block for this program to the public space with JPNIC or APNIC. This is the final slide - I will explain the shifting plan. We already announced starting second phase to participants. We explained the operation of the second phase to JPNIC and it was understood to them and also we received some advices. We will conclude the contract and the MoU with the individual participants in December 2005 and I will start the second phase in January 2006. This is how we start the second phase. If there are any comments or any advice in the second phase plan? That's all. Thank you. MAEMURA AKINORI: Akinori Maemura from JPNIC. JPNIC is having an eye on this phase 2 program. This is the extension of the first-phase program and as the entity to manage the IP address in the area of Japan, we are concerned about if this phase 2 program is proceeded as is appropriate. There is no official agreement or relationship, but we, as the neighbour to the IPv6 Promotion Council have in touch with the IPv6 PC to promote the progress of phase 2. KUO-WEI WU: I'm from the APNIC EC. In your presentation you talk about the EC and I think I have a little bit different point of view as you. I remember, the EC council, you are talking about in the phase one, we agreed to do that but, in the phase 2, it must go back to the normal procedures. RANDY BUSH: Randy Bush, IIJ. My memory of the original phase 1 was the IPv4 space was going to be returned. Now we have an - a phase 2 that extends further in time and a /8 is being held until 2008 and we will discuss if we can return it. And where is this going? I think what you're discovering is, as you say, dual stack is what's happening. So why is this IPv4 /8 being consumed by people who should be able to justify a normal IPv4 allocation to go with their normal IPv6 allocation and operate as normal dual stack just like everybody else? Maemura-san, am I misunderstanding? KUO-WEI WU: I want to add one more comment. In the phase 1, we agreed but in the phase 2 I just want to emphasise, we must apply the law. MAEMURA AKINORI: To supplement and address Randy's comment. The returned space is, in this context, I think, it is meaning that the registration of the block is transferred to the APNIC after it is verified as that usage come plies to APNIC's policy. Does that make sense? RANDY BUSH: OK. I mean, why didn't they just get normal space? MAEMURA AKINORI: That is becoming the normal space. Not experimental space. My understanding. TOSHIYUKI HOSAKA: Any other? OK, thank you Sawabe-san. NAOTA SAWABE: Thank you. TOSHIYUKI HOSAKA: Before we go in to the election, APNIC Secretariat request the feedback to the LIR survey. The last slide of the presentation of the LIR survey - they are proposing four options for the next steps. Number one - do we need to widen the sample size? Or number two - should this proposal cease? Number three - continue discussions on the list? Or number four - wait and see the situations in other RIRs. So we would like to have your show of hands to get some feedback to the APNIC Secretariat for the next steps of this HD-ratio proposal apply to IPv4 subsequent allocation criteria. So those who like the number one - do we need to widen the sample size, please raise your hand. (Counts hands) OK, those who think we should cease this proposal, please raise your hand. One. Those who think we should continue discussions on this proposal on the list, please raise your hand. (Counts) 6. OK, so those who think we should wait and see the situations in other RIRs, please raise your hand. 4 OK, thank you very much. Save, is this enough feedback for you? SAVE VOCEA: Yes. We'll take it back to the list. TOSHIYUKI HOSAKA: OK, thank you. So we've finished our presentations in this session and we are going to elect a new co-chair. We have four nominees for co-chair. These are in alphabetical order: Ahmad, where are you? Billy. Are you here now? Tom. OK. Eugene, are you there? Alright, if you wish to - would like to have some brief comment or speech from each candidate, Ahmad - do you have anything to speak? AHMAD ALKAZIMY: My name is Ahmad Alkazimy from IDNIC. I would like to introduce myself as an Internet resource analyst in APJII for four years and I would like to having some more experience for - that's why I am doing the co-chair - for the co-chair. TOSHIYUKI HOSAKA: Thank you very much. Billy? Do you want to speak something? BILLY CHEON: My name is Billy for KRNIC of NIDA. Currently I am on the APNIC AC and I think I would like to know the procedure of IP policy procedures. If I have - if you give me chance to contribute to APNIC, I would like to serve. Let me serve for this. Thank you. TOSHIYUKI HOSAKA: Thank you, Billy. I heard that Tom is not going to make a comment so Eugene. XIANGJIAN LI: Hello shall everybody. I'm Xiangjian Li from CNNIC, the sponsor of the day. I joined to CNNIC in 2002 as the hostmaster firstly and, in the year after, I became the IP address team manager and then at that time, I relooked the CNNIC IP address policies so for me to progress, I guess, because the Chinese IP address has decreased dramatically in recent years. Also chaired a lot of IP address meetings in CNNIC and got a good experience on that. Also I served some international related conferences as the volunteer and I know that the success of the conference is wanted, like me. So that's all I need to say here. Thank you for listening. TOSHIYUKI HOSAKA: Thank you, Eugene. Election is done by your show of hands. So APNIC Secretariat, could you help me to count the hands. So I will read the name of the nominees one by one by alphabetical order. So those who support Ahmad for new co-chair, please raise your hand. (Secretariat counts hands) 7. Those who support Billy for new co-chair, please raise your hand. NURANI NIMPUNO: Please hold them up high. TOSHIYUKI HOSAKA: Thank you. These who support Tom for new co-chair, please raise your hand. Alright, those who support Eugene for new co-chair, please raise your hand. 17. Alright, Eugene, you have 17 hands for new co-chair, so you are now a co-chair of this Policy SIG. Congratulations. APPLAUSE Now we finished all of the agenda in this session. Thank you for attending. See you next time. Thank you.