______________________________________________________________________ DRAFT TRANSCRIPT Policy SIG Thursday 24 February 2005 9.00am ______________________________________________________________________ KENNY HUANG Good morning. We're just a few minutes after nine o'clock. Welcome to APNIC Policy SIG. You can see, from the very beginning, people can see the APNIC onsite notice board, where there is many material you can download for them. You can also join - participate in Jabber chat and join the Jabber chat for more discussion. And also there's a webcast available. So people can also see this presentation from the webcasting. Also we have live text streaming facility, so also have all kinds of facilities available online. OK, so, starting from our morning schedule. OK, you can also see the updated Policy SIG schedule from the website. Initially, we start from a review of action items, reported by Takashi Arano-san. Secondly, we have the topic of second phase of large space IPv4 trial usage for future IPv6 deployment and a report by Ito-san and Ezura-san. The second topic will be expanded address allocation for private internets, reporting by Tony Hain from Cisco. And the 41 is an update on unique local IPv6 unicast addresses, represented by Geoff Huston from APNIC. That will be the end of the first session. The second session starts from 11:00. The first topic will be IANA IPv6 policy update. The second presentation will be status update on policy implementation and the third one will be update on IPv4 guidelines working group presented by Mars Wei and Yi Lee. The fourth one, ISP survey, presented by Anne Lord and last presentation will be a survey of ISPs in Taiwan for applying HD-Ratio to IPv4, presented by David Chen from TWNIC. The final one, we, unfortunately, Takashi Arano-san is leaving us, so we have election of chair. That is the updated schedule. ANNE LORD There's one more addition on the agenda which will make it to the website, which is Ray is going to present the IANA global IPv6 policy update. KENNY HUANG That will be after your report, right? ANNE LORD Yeah. KENNY HUANG OK, thank you. That will be the agenda for the IPv6 policy presentation. So, the first one - review of action items. OK. TAKASHI ARANO Good morning. My name is Takashi Arano. I'm the chair of the policy SIG. I want to review the action items. The five action items remaining I will explain each by each. OK, first one is that the (reads) APNIC Secretariat to refer proposal 'IANA-RIR IPv6 allocations' to the mailing list and to the other RIRs with the advice that the APNIC region has accepted this proposal in principle with some flexibility. The status is done. Second one - it's (reads) APNIC Secretariat to implement the proposal to expand IPv6 address space for existing address-holders on the basis of the deployment plan or with IPv4 infrastructure, without satisfying the subsequent allocation requirements. That was done. Third one that (reads) "Secretariat, with assistance from NIRs, to conduct a survey of ISPs' resource management practices, to allow better analysis." Actually, that will be presented by APNIC and TWNIC this time. So that is ongoing. Fourth one (reads) APNIC Secretariat to implement the proposal to recover unused address space. That was done. Final one - proposer to resubmit a modified version of the proposal, which is prop-013-v001 to the mailing list. However, APNIC conducted this proposal. The proposer replied that he wished to withdraw this proposal. So this action item should be closed. KENNY HUANG Thank you. So, if there's no other question, we move to the second topic. That will be the second phase of large space IPv4 trial usage program for future IPv6 deployment presented by Ito-san. Right, thank you. YOSHIYUKI EZURA Good morning everybody. I am Yoshiyuki Ezura and he is Kosuke Ito from the IPv6 Promotion Council of Japan. We would like to propose the second phase of large space IPv4 trial usage program, which is operated by IPv6 PC. First of all, I want to explain the outline of this program. This program was authorised at the 11th APNIC Open Policy Meeting in Taipei. The target of this program - the deployment of IPv6 for future. We initiated this program with these goals. Our first goal is providing the challenge field for coming IPv6 era, such as exploring new services and boosting up the end-to-end application. Transferring trial to IPv6 infrastructure under the real service operation. Forming IPv6 address administration scheme in Japan. Our second goal is revitalising the historically allocated address space. Then, as we agreed, we have been updating our activity at every APNIC Open Policy Meeting. And at the last APNIC Open Policy Meeting in Fiji, we reported that this program faced an issue in ending the program. During the session, we received a comment from APNIC that the program continuation could be allowable if necessary. For this updating report since the last report was done at IPv6 Tech SIG yesterday. Now, before getting into our proposal, I would like to summarise the results of this program so far. We could have a quick deployment of less expensive always-on connectivity broadband service for home users. And also, we could see the new services such as area-wide wireless LAN service and fixed IP address service, voice over IP service, and contents delivery service. In addition, as our program progresses, we could see the return of IPv4 addresses by users. Since they have replaced IPv4 service with IPv6 service. In this way, we believe that the program is contributing to the quick development of the advanced IT environment in Japan. At this point, I would like to pass to Kosuke-san. KOSUKE ITO OK, from now on. However, we achieved a couple of points or many points. However, we have seen that we couldn't achieve a couple of points as well, especially - originally, we estimated the IPv6 deployment could be done by this year at the beginning in 2001. 2005 we thought was long enough to deploy IPv6. However, in reality, the real IPv6 service is not quite deployed yet. It's kind of way under our estimation for the IPv6 deployment level. So I believe that there are a couple of reasons to do so, maybe one big reason would be the global Internet infrastructure is not quite enough to deploy IPv6 service. So I guess we couldn't do much about that kind of issue, so we couldn't see much of the real v6 subscriptions at this moment. However, there is a little tiny seeds are growing in this field, so we would like to warm up that seeds to growing up more bigger trees. And also we couldn't see the genuine IPv6 service yet, so we would like to promote that too. And also, we see that, unfortunately, we haven't received a return of the IPv4 addresses from one participant, who dropped out from this program, since they couldn't make their own business real so this is another bad side of this program. OK, so, in summary of the first phase of this program per se, we analysed our program so far. Then our assumption at the very beginning of this trial, starting in 2001, was IPv4 replacement by IPv6 service would be advancing at 2005. Then used IPv4 address block would be returned. However, in reality, it's not. So many of the participants are saying IPv4 address is pretty important to push the IPv6 service for the real commercial network service. So we understand that reality. So, also, they expressed that one to two years or maybe three years delay from our original assumption of the IPv6 deployment level so we understand that kind of environment situation. It's not quite good for them to returning IPv4 addresses. And so we are kind of understanding this situation. Then come out that we like to propose to continue this program to change the original plan to finish in 2005. OK, now we get into the proposal. OK. So, to extend this program's end to the end of 2008 from the current promised end of this program at the end of 2005. So three years extension is our proposal. Then - but still keeping we are going to return the current used IPv4 space will be going back to the public space after this trial period. Then, we like to set the following conditions to the participants to keep going on this program. The first one is - we like to have their service starting plan, IPv6 service plan. In the first phase, we don't require the IPv6 service plan. However, we are asking them to showing the large - global large IP address space deployment plan. That's not mandatory at IPv6 but, at this time, we would like to mandate deployment of IPv6 during this extension period. Then we would like to ask them to return the assigned, return or ask them to say, "It's going to be back to a public space," which, currently, it's not the public space, IPv4 address, so we're asking to make it into a public space. And, if they couldn't deploy IPv6 service, we ask them to return the IPv4 address space used so far. So, by the end of 2008, if they started the IPv6 service, that's OK, but the IPv4 space will be going back to public space. Or we ask them to return IPv4 addresses if they couldn't accomplish the IPv6 service deployment. And this is the same way as we do now but we'd like to ask them to do the periodical report to us how they are acting on this program. And we would like to renew the agreement describing these conditions, then make the conclusion before getting into the new phase of this program. And also, to clear up the worry in the current IPv4 address will be used forever in the trial. So we don't like to have - make that happen. So we would like to start designing a how- to return this current IPv4 address space block to be back to the public space with APNIC. So currently our participants are involved commercial end users so without any trouble or any hassle to - don't want to make a confusion in the user's side. We'd like to make a smooth shift to the address space usage how we design this kind of shift to be the commercial way. Then also we'd like to promise that we'd like to continue the regular report as done so far and do that in the Open Policy Meeting. This is our proposal. So, that's about it. Does anyone have some questions? NAOMASA MARUYAMA JPNIC discussed this issue already. Here is a question for you. You said that in the failure of the deployment you ask the participants to return the v4 addresses. You are just asking for that? I think it should be the firm basis, a contractual basis to force them to return the addresses. KOSUKE ITO To be answering your question, that's why we like to propose agreement to describing these conditions. See, they couldn't deploy IPv6 service within this extension period, we mandate the return of IPv4 address. Then we describe that part in the agreement. Then we make the contract between the participants and us. NAOMASA MARUYAMA OK, so you are not just asking, but you employ some clause in the contract? KOSUKE ITO Right, right. NAOMASA MARUYAMA To ensure the return of the address in the failure of the program. OK, thank you very much. PAUL WILSON Hi, it's Paul Wilson. Thanks, Kosuke, for the presentation. When you presented on this topic at the last meeting, you made the point specifically when you were describing the problems that trial participants had, you said specifically that IPv6 address management or address avail APBLT/ was not a problem to the trial participants. I don't know if you made - I'm sorry if I missed it - I didn't notice that you made that point here but I think it's quite a useful one to make, that the address management issues were not, were not anything that was raised by your trial participants. That's correct, isn't it? KOSUKE ITO Exactly, yes. Yes, nobody is saying that IPv6 availability is a problem. So it's not the issue. It's just a matter of how to make the adaptation of IPv6 services into the commercial service level. It's not the address issues. AKINORI MAEMURA In the trial, the criteria for the address assignment is for the promotion of IPv6 on the network and the problem is not fair with the ordinary assignment. And I'd ask you to assure that, in this - in the extended time period, you need to ensure that, you know, the 43 /8 block would be surely returned to the public space. I can see that lot of problems, you know, for example, that give back the box with the 43 /8 from the participants of this trial to hand back to the free space. But maybe we need to ensure that the block of the 43 /8 complies to the ordinary address policy which is RIR's document. So please include that very detailed plan and a time schedule to how to design the returning the 43 /8 block to APNIC. KOSUKE ITO We would like to have that in details. But we don't have any insight of how we do in a procedural way and also what's the best way for avoiding any confusion in size, like registry size, user size and ISP size. So we have to figure out what's the best way to make that into the regular manner. And that's why we include this line, but we don't know how so we'd like to discuss with APNIC and also maybe if JPNIC can help us, that would be good. KENNY HUANG OK, any questions or comments? So the since the proposal is only a policy proposal, so we need to see where there is a consensus at the OPM and, if the consensus is reached, then we can move to the next stage. So, if you have any questions, please raise your hand. OK, there's no more questions. Then I'd like to see if any of you - who is in favour of the proposal, please raise your hand. Who is in favour of this proposal, please raise your hand. (Two people raise their hands) KOSUKE ITO Everyone! KENNY HUANG OK, two. OK, any of you who is not in favour of this proposal, please raise your hand. (Nobody raises their hand) OK, again, who is not in favour of this proposal, please raise your hand. Are we still not clear with the proposal, please raise your question. OK, there's no objections and only two agree - only two is in favour of the proposal. So I think that would be a consensus at the OPM. KOSUKE ITO We'd like to have a consensus here to be progress on the proposal. So, if there is no objection about this program's continuation, we'd like to have your favour showing up. PAUL WILSON You might need to summarise the proposal again. KOSUKE ITO OK, summarise our proposal again. First of all, the extension period we propose is three years. And also we are promising to return the current used IPv4 address block to be back to the public space in the end of 2008. And also we like to add the following condition, these three conditions to the participants for continuing the program, such as we would like to have an IPv6 service starting plan, which is implementation plan within these three years. And we also put conditions like that, if they couldn't accomplish that plan within these three years, we would like to have the IPv4 address assigned to the participants returning to us. And also we - in order that we can make the regular report at the APOPM, we mandate them to make a report periodically as we do right now. And also, we will make the paperwork to make agreement and between them and our side. Then, in order to discover how we can return that IPv4 address space to be back to the regular manner, we like discuss with APNIC and also maybe with JPNIC, how to return that the address block without any confusion at the registry side and participants, ISP sides and also the users' side. Then we'd like to promise that we will continue to make a regular report at the OPM on our program. This is our proposal. TONY HAIN Actually, I was listening to the discussion. I'm not opposed at all to the proposal, but one point that occurs to me is the reason that an organisation would develop a service is that they have an application that would run in that environment, right? So we need to get the applications out there to be able to make use of v6 so the people would move and deliver that service. But you're using a v4 block to deploy that, which means the application developer just uses v4 still. He's not motivated to build a v6 application. This is contradictory to enforcing the v6 point. I'm not opposed to it. I think it's fine. But it might be counter to a business business-up because the application developer is not motivated. KOSUKE ITO I understand. At the very beginning of this program, there is no such environment to develop the IPv6 application, one side is not good enough. The chicken-and-egg situation is there. Why not give them the large global IPv6 space. Let them know the large side's goodness of the service provider to the users. Then we'd like to motivate them to shift to the IPv6 space. That might be a less expensive operation or might be a better and more efficient way or something like that. We would like to make them figure out how to shift from v4 to v6. And that might be the side effect that everyone knows how to shift from v4 to v6, that doesn't know how to do it. That's why many of the participants succeeded at v4 already. Then we'd like them to shift to the IPv6 space from the current stage to the v6. That's the point of the second phase of the program. That clear? TONY HAIN Yes. I understood the goal all along. But there is a counter-issue there. I completely understand. We don't push IPv4 so much. We like to push IPv6 in the second phase, yes. KENNY HUANG OK, thank you, Ito-san. So Ito-san has already reclarified the proposal and many of you already understand the proposal. So I ask again, any of you who is in favour of the proposal, please raise your hand high. OK, any of you who is not in favour of this proposal, please raise your hand high. OK, I see no objection to the proposal, so we're moving the proposal forward to the comment period. KOSUKE ITO Thank you very much. So the next topic will be expanded address allocation for private Internets, presented by Tony Hain from Cisco. TONY HAIN Good morning. My name is Tony Hain and I've been working on IPv6-related things, so this is, to some people, a strange thing for me to be doing. But a few different organisations have had problems with the amount of space in IPv4, private space, so they asked me to see if I could help resolve this issue. So there may be more to it than what I've got here, I'm just trying to raise the point. As I sorted out trying to say, "OK, what's the real problem?" there's an interpretation and an expectation that, if you're doing an internal use, not to be really used and exposed to the Internet kind of network, you're supposed to use private space. But some of these organisations have grown to the point where what they were allocated in 1918 is insufficient. Youve told people what to do, they've gone and done it and used it up. Now what? We've also got an issue about if these organisations come back and say, "Well, I want public space to expand my network." Then they fall under scrutiny of exactly what are their business plans, exactly how are they deploying this. This is part of the reason they recruited me on a personal ground as opposed to a collection of people. They are at a state where they don't want to expose what business it is. That affects growing their business. If they've grown to the point of internal address space problems and they expose that to the world, the financial markets are going to notice, their costs will go up and fall back in on them. They don't want to be exposed, right? So this is wide open - if anybody wants to participate, join in. So the draft is out there, it talks about some examples and I've got a couple of slides with examples here. We have to sort out which is more important - management of the address space - which is what the registries have always been about - or management of business process - which asks what these businesses are all about and those are in conflict. s (Refers to slide) So this is the draft that's out there. It clearly needs work. I think there's, you know, a few places in there where it says their deployment plan is dot dot dot()" because I didn't have time to finish writing up the stuff, right? The bottom-line recommendation is to take some, you know, /8s that we think are not likely to ever be really publicly deployed. One is the nice example because I know of a large number of organisations that have just picked one (inaudible). Long before 1918, people were just deploying one for internal use. Two /23s had some interesting issues. That's another good candidate. There may be some others. It's not clear. 36 is another that comes to mind. /8s that may or may not ever be publicly allocated could be thrown into this pile. (Refers to slide) This is one of the examples - a corporate kind of example and this is some service provider kinds of examples and the details are in the documents so I'm not wasting time on them here. I tried to figure out, "OK, what's an alternative?" An alternative is you open up the public space and get rid of the perception network that says, "You've got a private network, go ahead and get public space." That's an alternative. We can put that out there. Part of that comes with a need to reduce the level of scrutiny, right? Because maybe these guys aren't being quite as efficient in managing their address space as you would like them to be, but they're optimising their business cost and that has to be traded off and it's not always traded off in the same way because of perceptions in which side of the business you're on and that's really all I've got in terms of this - raising the discussion point here. My original intent was to try to put together a BoF for the next IETF and I just haven't had time to get organised to do that. It may or may not happen depending on what happens between now and then. If not, I'll probably bring it up again at ARIN in a couple of months and see what happens there. Comments? I see a lot of questions in faces. RANDY BUSH Randy Bush, IIJ. Seeing as we have a long history of technical problems created by private address space in the operational areas and affecting end users, and seeing that we're constantly told that IPv6 space was designed to be so large that did you get what you needed, why are we recreating this brokenness? TONY HAIN It's not recreating the brokenness. It's expanding the brokenness that exists. I kind of skipped over this slide. Even if the applications were available today, just normal process would take them three years, right? And at least in one case, they have less than three years left. RANDY BUSH Let them use real address space. TONY HAIN As I said, that's the alternative, right? But the perception problem is they can't. RANDY BUSH They can. Let them do it. Otherwise, we should give up on this IPv6 stuff. But does it solve the one problem we say we're going to solve? Then why are we doing it? TONY HAIN It's not a trivial thing to just say they can get it. RANDY BUSH That's what this group is about. TONY HAIN I understand. RANDY BUSH They've seen that they can get it. So instead of discussing policy to further propagate a hack which we know is bad and causes problems for users, why aren't we discussing policies that remove the problem? PAUL WILSON Hi. Paul Wilson again. I don't want to speak for or against the proposal. It seems to be a need there that is being addressed and that's obviously a good thing in this policy forum. Just a piece of advice though and this is a piece of advice for the people who are asking for this, that the reluctance to share details of business practices is understandable but it's not a new thing and, within the RIR system, there's a very strong reluctance - and it's expressed quite frequently - on the part of ISPs to divulge the information that they need to justify the requests that they are submitting. There are business secrets. There are all sorts of sensitivities involved. The RIRs, APNIC and the others, clearly take that issue very seriously and we've got non-disclosure agreements and confidentiality requirements and all of the formal mechanisms that seem to be needed to provide some assurance that the details are treated securely. I really think it undermines your case or the case of these people who are interested in this policy that they are simply saying that they can't divulge anything about their requirements. What they're asking for is an allocation of a substantial amount of address space, which may, for all we know, be needed by one or two organisations in the entire world. We don't know what the need is. And I think it undermines the case quite deeply. But there may be solutions which actually involve invoking some of the RIRs' existing mechanisms for assessing the demonstrated need that is claimed and do so in some confidential manner using some of the particular cases that you have alluded to here as specific examples. And to look at the actual real need that is in detail in the actual application and so forth on a confidential basis. How exactly that can be done I'm not sure, but it's not rocket science. As I say, ISPs are doing this all the time. They are joining the registries entering into the agreements and confidentiality arrangements and so forth and providing those details. And that would be one way to approach this issue, which, as I say, I think will undermine the case if you continue to say simply there is a need out there but we cannot divulge any details of it. We just want a couple of /8s to be allocated, which is a large amount of address space. TONY HAIN I understand. PAUL WILSON Thanks. TONY HAIN And, in fact, these are already members. So they already understand the process and they are still concerned. So they have gotten - I don't know enough about exactly the relationship issues that go into this, right? But there is a point where they feel like they can't do more than what they've already done because the system is stacked against them. And, no argument that it should be fixable. It's just I got recruited because they got stuck. PHILIP SMITH Philip Smith, Cisco. I just really want to back up what the previous two comments were saying from Paul and from Randy. I really don't see any purpose for this proposal whatsoever. I am aware of lots of opposition throughout the world. I'm aware of lazy organisations who just slice and dice the address space without any - if people actually paid attention to the amount of address space they had and what they were doing with it, I don't think this proposal would be necessary at all. I'm actually quite strongly opposed to this. We should be figuring out how to deploy IPv6 or get these organisations proper IPv4 addresses. We shouldn't be adding more cracks to an already broken system. TONY HAIN Any other comments? KENNY HUANG Any questions? TONY HAIN You can certainly, you know, send me e-mail any time and, if you've got comments about more changes that need to be made or things that I should take back to the participants here. We'll try to get that done. It's mostly here to raise the issue and get the discussion on the table. KENNY HUANG Thank you, Tony. So we move to the next presentation. GEOFF HUSTON My name's Geoff Huston with APNIC. This is an update on a presentation I gave in Fiji to the open policy meeting then. Which is a report of progress within the IETF on some changes that were made to the locally scoped address space in IPv6. Which is a strange twist, I think, to the RFC 1918 space in IPv4. What they're proposing in IPv6 is an evolution of the original site local proposal. If you're aware of site local it was very close to the private space in IPv4, there was a single block that was being re-used, so that the prefix was not unique. The evolution of thinking in the IETF is to set aside some global unicast space with some particular properties. It's global in terms of uniqueness so organisations who are intending to use this space have not quite a guarantee but in theory a strong assurance the space or the prefix they are using is unique. Strong assurance is not absolute, but it's intended statistically to be close to it. But it's intended to be private in terms of its routing scope. So the way this particular proposal has been phrased the objectives are to take an address pool from the global unicast space in IPv6 and to subdivide it into prefixes each of which are 48 bits in length, which allows each site using this if they take one of these global prefixes to have 16 bits of sub-net identification space and of course the usual 64 bits of unique identifier space. Each prefix we take is not through a normal RIR distribution system. It's actually a self selection. The idea is that if you've lived as long as I have and been through DegNet not everyone's meant to pick one, you're meant to do some work and pick a relatively good random selection process and out of the trillions of numbers in that pool your random selection process is meant to zero on a probably unique number. The trick about this space is it's not intended to be globally routed and part of the reason why the process itself is intended to use this random selection process is that this is not aggregatable address space. If you pick two of them they'll be completely different prefixes, they won't be side by side, you can't make a /47 out of two /48 random selections. It's intended to be locally route end various terms of private use and even across inter-agency VPNs, so that if you and I have both done this for our internal networks and for some reason we wish to interconnect - maybe your company's bought mine or mine's bought yours - we would be able to join these together without doing massive renumbering internally. There's no hierarchical superstructure no, aggregation in this proposal and these are not provider-based addresses. Part of the issue that's trying to be solved here is that we certainly have had an architecture in IPv6 which is strongly aggregating, providers get large space and suballocate into their customer base, but think about a large corporate customer, would they want necessarily to have to renumber their internal network every time they change providers? And quite frankly, right now, in the IPv6 world the solutions for multihoming with multiple provider prefixes across their network are at best immature and developing. So this solution is one of proposing that such customers actually use two, three, four, many address prefixes inside their network but the persistent address space that's irrespective of the providers of the day would be drawn from this local address space so it's not part of the provider base hierarchy. A quick demonstration of the block. I love these laser pointers! 7 bits at the top is identifier space. The prefix is FC 00/7. One bit's reserved for the type. So you randomly pick a 40 bit number or two or three or as many as you want, you do not register it any where and as long as you use a sufficiently good random generator - number generator the number you pick is probably going to be unique. Then that gives you 64 bits for IDs and 64 bits to carve up your network. If that's not enough go and pick another one of these. The assignment type of 00FD00::/8 was self selection, no registration records, probably unique, and the recommendation in the draft is that there are no global DNS records. You might put in some AAAA records if you want but no-one else can use them. There's discussion in DNS ops about unreachables in the DNS. The draft says if you're going down this way you probably wouldn't put those mappings, those resource cords in the global DNS and you certainly, strongly recommended, indeed, in a really - really, really strongly recommended don't put the reverses in. Someone else conceivably might have picked the same prefix. The reason why this has been brought to you is two fold, one is information, but the second one was the previous Incarnations of this that actually use the other half of the space, FC00::/8 to create a space that was assuredly unique. So the draft had proposed a central registry and instead of doing self selection you went off to some common registry and said, give me a prefix. That registry would spin the wheels and give you back a 40 bit token that would never be repeated. This has generated more than a little conversation and if you've been following the ARIN meetings when this was presented at ARIN it was mildly interesting, to say the least. The IETF and the proponents of this particular proposal have thought about this a lot and the update, I think, the real substance here is that that part of the proposal is no longer inside the document. The current specification says if you use assignment type 1 we don't know what's going on, it'll be defined later. So all references to a common registration service were centrally assigned locally identifiers has been locally removed. So the only currently document out there is draft-ietf IPv6 unique local addr and it's up to version 9. Getting close to coming - coming out the other end. This specifies self selection inside that FD00::/8 that uses a truncation of an MD 5, local time, into 40 bits. A bit of crypto magic to get you back a reasonably random number. If you are deploying this inside your network then you would use an address selection algorithm, when you say, I want to speak to Paul, he's inside my private network as well as having global addresses, you would prefer to use the local prefix into a global. So that where see the two the address selections are local. How do I know it's Paul in this local space? You do have to use split horizon DNS. There's a few wrinkles about deploying this. You've also got to muck around with pointer records because you have to do reverse space if that's what you're deploying locally without parent delegation. There's also the latest draft about leakage into the public global routing space. There is no mandatories here. If you're an ISP and someone comes and says, Please route my prefix, it starts with FD00::/8, theoretically your answer should be no. As we all know, with enough money almost anything is possible and it may well be that you might convince your ISP that this is a wonderful prefix to route. As an ISP, you really should think about this very strongly. In general, this is a bit like the RFC 1918 bogon filter lists, in general we would expect that prefix to be filtered out of the global routing table. That's the characteristics of the self-generating prefix local addresses. The registry ones have disappeared. And the considerations that we had at the last report were the RIRs were certainly looking at what would be required if the RIR system were to be that registry are no longer on the table. They may reappear, but there's nothing active right now in the IETF. The current status - private use pool divided into /48s, random selection, the concept of a registry for the RIRs has been dropped. But it's been left open. So it may come back. It's used in the context of local space independent of any provider based addresses and because they're relatively unique, they certainly have a potential role in VPN-styled interconnection. Any questions? (Pause) RANDY BUSH Randy Bush, IIJ. I'm just repeating the question I asked my good friend from Seattle a few minutes ago. GEOFF HUSTON Could you mind repeating it. I'm getting old and my short-term memory is shot. RANDY BUSH There's so much IPv6 address space. Why isn't the discussion about policy to issue it to people who need it? And if there there's not enough then IPv6 was misdesigned. GEOFF HUSTON It's certainly the case in the IPv6 policy in APNIC that the consent of being required to be part of the global IPv6 space as a precondition for provider-based allocations is not there. Very careful reading of that policy says if you're deploying IPv6 and meet the criteria irrespective of whether your intended use is in contexts that aren't necessarily the global public IPv6 network you're still eligible if you meet the criteria to obtain the space. And this is good. This is not an APNIC policy proposal. This is actually coming out of the IETF. The reading between the lines is that the IETF and the proponents of this draft do not believe completely that those policies in IPv6 are enough. Now, personally, I'm not sure that there's a need for this but I am reporting on the IETF thinking in this report. RANDY BUSH After years of working on getting the RIR community out of specifying technical standards and the IETF out of specifying policy, here we have the IETF specifying policy again! Thank you. Or no thank you. GEOFF HUSTON Um, no thank you! TONY HAIN Just a follow-up to Randy. The policies assume provider based allocations in the current infrastructure, right, so I as a consumer am required to go to my provider. GEOFF HUSTON Not necessarily. TONY HAIN It's in - implicit if not explicit. GEOFF HUSTON Not necessarily. There are criteria for an IPv6 Allocation. TONY HAIN OK GEOFF HUSTON In the APNIC case if you read that policy, it is not a criteria to be a global public IPv6 provider. So if you meet that criteria even in a private context, an allocation is still possible directly from the RIR. TONY HAIN Right. At that point I need to join the RIR and get an allocation at that level. GEOFF HUSTON Well - let me phrase it another way. The RIR is able to service that from global unicast space without resorting into in sort of unique local space, yes. TONY HAIN It comes town to an issue of where people have to go to get their address space. To do things that may or may not involve the public internet, that's the fundamental issue here - organisations that are not directly involved in the public Internet need address space from somewhere and there needs to be a process for that. GEOFF HUSTON I'm saying the IETF is inventing a parallel path of so doing, not a unique path of so doing. It is possible, there are criteria out there to get space from the RIR system, so Randy's comment about to what value is this IETF proposal in terms of address policy, is a reasonable observation and a good question to ask in the IETF context. PHILIP SMITH Philip Smith, Cisco. I'm just bemused by the whole URL thing altogether. We had a routing SIG yesterday where we were talking about trying to authenticate entries in the BGP table, so on I'm not quite clear how any of the /8s are going to work at all. I mourn the passing of site local, I think we've just reinvented site local in a slightly different way and it's going to result in lots of people using v6 nets to get on to public v6 possibly, et cetera. The list goes on. Again, I echo what Randy says, I'm not quite sure what problem this really solves and we should really try and get back to deploying v6 rather than inventing yet more fancy ways around things that people perceive are broken but I dont see are broken. TAKASHI ARANO My name is Arano. My feeling is that the first choice, almost unique is - how do you say it, half down, or incomplete and not so useful thing. The application such as ad hoc extranet or something like that. My question is that what is the chance of crash, address crash? GEOFF HUSTON I can give you an answer to that, it is a statistical answer. Let me provide an equivalent problem. There are more than 50 people in this room today. At just on 50 people the chances that two of you have the same birthday exceed one half. So even though you need 366 people in the room to guarantee a clash, you only need 50 to be likely to clash. RANDY BUSH 24! GEOFF HUSTON I thought it was 50. I'll take 24. I have done some work, real work in the 40-bit space, the answer is 1.24 million if everyone sees each other. So If we use the reverse DNS space to register these prefixes, even though there's two to the 40th possible identities, it takes a little bit over a million, 1.24 million for two people on a perfectly random selection to collide. Now, as long as you don't all meet in the same room the probability when there's only two of you is extremely low. But when there are 3 it's higher, when there are four By the time it gets to 1.2 million the probability exceeds .5 so from that sense they're not very strongly unique. As Philip said, you can't do any kind of authentication or attestation about uniqueness. There's no security in this system. They are very, very weak identity systems. So from that respect, saying let's take this weak system and make it unique, still doesn't do an awful lot, when on the other hand we actually have unique global unicast being distributed in a much more robust fashion, you have it, everyone knows you have it, the RIR can attest you have it. So the global system actually services this requirement and you don't need to be a public IPv6 provider to get it. So from that respect the observation that - what is this trying to achieve? Is a very valid question. TAKASHI ARANO Thank you. And actually, the one example, one Japanese carrier and our company are doing field trial of so-called multi prefix - multi-prefix and multiservice to the home. That includes Internet, the assumption is we can use this kind of unique address. In that case, the home user cannot do anything, so considering, how do you say, the complete uniqueness is a very expected feature for that kind of service. GEOFF HUSTON My suggestion would be, there is nothing stopping you from using RIR allocated global IPv6 space for all kinds of applications that aren't necessarily routing that space into global table. You don't have to always route what you receive and the policies don't mandate you have to route what you receive. If you're trying to do these kinds of rollouts you really do need to consider very carefully precisely what uniqueness is and that random selection algorithm doesn't give you probability - sorry, doesn't give you assured uniqueness, it just says we're trying to reduce the collisions, not eliminate them. TONY HAIN It's a follow up to Philip's comment. The assumption that this address space would lead to NAT assumes only use one address, you're restricted only having one address, which is the - devices have only one address so if they want to go out you have to NAT. With v6 they assume multiple addresses so this doesn't immediately mandate NAT. So then the other thing that occurred to me as I went to the back of the room, if everybody started going to the RIRs and getting address space, that's fine. Policy allows that, but it doesn't aggregate. And that is the counterbalance that we have to continue to keep in context here, on one hand we have these strong aggregations providing hierarchy, on the other hand you have space - get the space you need and we have a mechanism for keeping those balanced. Just to throw out yet one more draft. RANDY BUSH Since the proposal is not to announce this space then the question of whether it's aggregatable or not is totally uninteresting. GEOFF HUSTON In actual fact the comment from Tony Hain was about the current policies allow global unicast space to be used for precisely the same kind of purpose and the ability then to announce it into the routing space is an option. There is an issue about route aggregation, but Tony's comment and my, I suppose, response is that to date we have actually assumed that the routing system is completely anarchic and that it doesn't cost to create an advertisement into the global routing table. RANDY BUSH As I run routers I can tell this. GEOFF HUSTON As the routing space starts to accumulate pressures and scarcity it is I think entirely predictable that aggregation becomes an economic aspect rather than purely an administrative policy plucked out of the air. And I believe that Tonys concern has self correcting properties in the industry and I'm not so concerned about the toxic waste dump as a result. I believe it is possible to use global unicast space in all kind of environments. RANDY BUSH You're suggesting it's a source of income. GEOFF HUSTON Not for me personally. RANDY BUSH You and Shaun have been doing that for some years and I've yet to make a penny. All these things have - address space kept within a site, you know, use address space, stop trying to solve routing and filtering problems by turning them into addressing problems. GEOFF HUSTON And there I think I could only agree with you wholeheartedly. Its a fundamental statement and one I appreciate. ROBERT SEASTROM Robert Seastrom, ARIN, speaking for myself not for ARIN. I'd like to point out that use of random selection to minimise seclusion of IDs is not likely to work based upon prevalence of 192, 168.1, private networks, human beings being who they are and what they are, people are likely to just grab the first one sequentially they can within the block and roll it out internally. I think that's very over-optimistic. I would like to echo the comments of other people who say why not just unique address space for this, IPv6 space is very, very large. GEOFF HUSTON Thank you. KENNY HUANG any questions or comments? Thank you, Geoff. GEOFF HUSTON Thank you very much. KENNY HUANG We only have a few minutes to the break. So I think the next speaker will be Son Tran. SON TRAN (Pause) Good morning, everybody. My name is Son Tran from APNIC as well. I would like to give a brief update of what policy we have implemented since the last meeting and what policy we move to implement in a couple of months. But I would like to use this opportunity to give an overview of the current policy development process for those it that are not familiar with APNIC process. Looking from the map here, if you believe that there is a need to change the current policy or you need to have a new policy in the IP region you need to complete a policy proposal and submit it to the mailing list. Then it will be discussed on the mailing list for a while. Then we will bring it into this sort of open meeting and we can discuss it. If it reaches consensus in a meeting we will bring it to - report it to the normal APNIC member meeting which well be having tomorrow. If it reaches consensus in the member meeting it will be posted on the mailing list for 8 weeks for further comment before the executive council here to approve it. If the executive council adopts the policy then APNIC secretary will be required to implement the policies. You might wonder why it takes so long to come up with any policies. The reason, the process was designed to allow everyone to have the opportunity to provide input into the policy process. So this is the place where you can provide your input into the process. If you need more information you can find the information on the APNIC web site which is available at this URL. The very important thing is anyone can participate in this policy process. If you want to find out where all the proposals are you can find it on the URL here. If you want to know what was proposed previously you can find it on the web site as well under this URL (Indicates) To make life easier for people to propose the policies we have come up with a web form which is available on our web site under this URL where you have to put in the detail. This one - if you are unsure of which SIGs, submit a form anyway and one of the APNIC staff will contact you and put it on the appropriate mailing list. It's quite easy to make a proposal. Let's review the policy we have implemented since the last meeting, the one we implemented in December. Proposal 018 - protecting historical resource records in Whois. The purpose is to protect the resource, when we're talking about historical, we refer to resource that being distributed before APNIC membership process. If anyone holding the resource would like to update an object in the database they have to contact APNIC, sign an agreement then pay $100 fee, but if you don't need to change the database, then it's easy to do so. We notice that when we started to implement this policy there were quite a lot of people started to request APNIC staff to update the database. You can find more information on this policy on this web site and we will give a full project update in the SIG this afternoon. There are a few policies that also implement in September as well, proposal number 7 - privacy of customer assignment record. In this policy all customer assignment by default will be in the private database, but when we implement the policy we experience some problem, so at this stage all update via email to the VPN to APNIC will be in public. But you can manage this - to put this one into private by using MyAPNIC. And the full update will also be there this afternoon. Another one on 7 October, proposal No. 4 - lame delegation cleanup. This policy is allowing APNIC staff to disable any lame servers. And to avoid, after analysing the data we realise there are quite a lot of lame servers out there, some have more than ten or twenty, So to avoid spamming them, we divided it into two stages. The first stage - we contacted the people with reference to the lame server for five or less servers. And we are still working on doing the one that have more than five lames. You will be updated in the DNS SIG this afternoon as well. Other policies that we implement in February 2005 is the expansion of the initial allocation space for existing IPv6 address space holders. This policy is generally allowing IPv6 address holder to apply for additional or extend the prefix to larger than two without the need to satisfy the ratio of the 0.8. The EC endorsed this one in November and we started accepting the requests from then. So far we have only two requests. To be implemented. The policy to be implemented - one in March is proposal 17, recovery of historical resources. In this one when we're talking about historical, as I mentioned before, any IP address including DRX, APNIC, pre-APNICs membership addresses. The global routing table. I had summarised here the process in the proposal itself. We will check all the prefixes using one of the routing data, since 1988 and if they're not being used we will send an email to the - if the email is valid, repeat every two months for one year. If the email is invalid we will try to contact by other means, eg phone. If we can't contact we will reclaim the resource. What happens to reclaimed resources - ERX, IP addresses are being spread across many regions so at this stage there are no plans for - we will try to re-use it after 12 months. You can find more information on this URL here. On the global policy proposal number 008. IANA IPv4 resource request procedures. These are procedures for IANA, between IANA and IRR. We have forwarded this one ASO and it has been approve end August 2004. ASO forwarded it to ICANN in September, we' still waiting for ICANN to make it official. That is all. Are there any questions for me? KENNY HUANG Any questions? Ito-san. KOSUKE ITO This is not a question, it's just a comment that in the form of the proposal that sounds really good, but sometimes we like to distribute to our colleagues, if I put it in these forms then if you click "send" I like to distribute it to, as in cc to our members or our groups, so we like to have a field in the cc line or something, it could be in an email distribution or something like that. That would be much useful to make the proposal. SON TRAN Thank you. KENNY HUANG Thank you, Son. The first part of the meeting is finished, take a break, come back at 11 o'clock and we'll start with the second session. Thank you for your participation. (BREAK) TOSHIYUKI HOSAKA It seems to be the time to start session 2 of the policy SIG today. Please be aware of the onsite notice board which is on the APNIC web site where you can get very useful information, including today's schedule, live transcript and jabber chat. Alright, first presentation of the second session is from Anne Lord, APNIC status update on policy implementation, followed by Ray Plzak Regarding IANA policy document. We will take questions and comments together after Ray's proposal. Anne, please. ANNE LORD (Pause) Good morning, everybody. My name is Anne Lord from APNIC secretariat. I'm going to give you an update on the IANA, the global IANA to RIR IPv6 allocation policy document. Although this was approved through the processes, the policy processes of the APNIC meeting this isn't the case in all of the RIR regions hence the need for an update. As Toshi said I'm going to present, then Ray will present the newly released document, the actual policy document and we'll take questions at the end. Just to recap the status in the APNIC region. This is policy proposal No. 5 at version 4, it was sent to the mailing list in this region in August last year, it went through to the policy SIG session where there were a lot of lively discussions, the version. Document reached No. 4 and there was consensus on the document at the policy SIG and also when it was presented at the AMM. It was then sent to the mailing list for a comment period of two months after which it was endorsed by the EC. You can find all the transcript minutes and presentations relating to the proposal on the APNIC web site at the URL that I've given at the bottom of this slide. Just to recap what the proposal actually is. It's a /12 minimum unit of allocation to the RIRs and every allocation should be a single cidr prefix, the IANA is to allocate for a period of 36 months. Allocations to new RIRs will be a /12. The RIRs are able to choose their own method of managing the address space. Additional allocations would be made when the utilisation of the block is at 50%. The size of the additional allocation will be a minimum of a /12 and increments there of to last 36 months. The announcements should be made by the IANA to the RIR when the allocation as been made and the RIRs will then announce to their own respective RIR communities. The status in the ARIN region has a proposal number 2004/8. It was sent to the mailing list in September, presented at the meeting in - on the mailing list there was quite a lot of discussion, it was presented at the October ARIN meeting, there was a lot of discussion but no actual consensus overall although there was a strong need that was recognised to have allocations from IANA that were greater than /23. Which is the current size of the IANA block. The Advisory Council were then tasked to establish a discussion group which they have done and gather input from the other RIRs which I believe has also been done. They were to report back to the public policy mailing list. This is yet to happen. Just to summarise the proposal in the ARIN region similar to that proposed in the APNIC region. The /12 again was a minimum unit of allocation, IANA is to allocate for 18 months. Allocations to new RIRs would be /12. The RIRs choose their own method of managing address space. Additional allocations at 50% utilisation. And the size of those allocations would be a minimum of /12 and increments there of to last 18 months. The announcements again to be by IANA to the RIRs, then the RIRs to announce to their own community. In the RIPE region, the proposal was submitted to the mailing list in August last year. That was based on the APNIC proposal. On the mailing list there was a lot of discussion around the size, /8 or /12 as the size of the allocation. It was presented at RIPE 49 in September in Manchester, there was no consensus overall on the document but again, it was strongly recognised it needed to approve the current situation where current /23 allocations are being made. Although there was no consensus on the /8 or /12 it seemed to be in favour. /12. There was an action on the working group to further discuss the proposal on the mailing list but as yet there hasn't been any discussion. In the LACNIC region it was presented at the last LACNIC meeting. That was based on the APNIC documentation, there was lots of discussion. Their next steps are to circulate the proposal document, discuss it on the mailing list and at the next LACNIC meeting and in principle a /12 minimum allocation size is acceptable to the region. Because AfriNIC is about to be recognised very shortly will be, I've included it in this update. They posted the document it their public policy mailing list last year. There has been no discussion so far. However, the next steps are to be discussed further at the next AfriNIC policy meeting. The issues to be resolved - the size of the allocation unit. There is a strong need recognised to improve the current size /23. It seems the most acceptable size is the /12 in all of the regions. The allocation period - it's been suggested 18 months and 36 months. It seems 18 months appears to be the most successful. That defines our relationship with IANA. The APNIC consensus documented the ability to be flexible to meet the global consensus. So recognising this is something that has to be coordinated globally that is quite a difficult task, therefore we need to be flexible in our approach to what is agreed. What are the next steps? The NRO has prepared a draft document. Ray will present this. That's attempting to incorporate the consensus so far and it's based on the IANA-RIR IPv4 document framework. It looks a lot like the IPv4 document we know. That's going to be circulated on the mailing list of the RIRs, the policy mailing list, and on the global v6 mailing list. There will be presentations and discussions of all regions, as I've said in some regions it hasn't yet been through the formal policy process yet. But some regions have reached consensus on certainly points like the APNIC region. I underline the fact that flexibility may be needed to achieve global consensus in order to move this policy forward. Because it's been on the table some time. It takes time to go through all the policy processes in each of the RIR regions and it's important to be conscious of that when trying to move forward and improve the situation we have today. Next up is Ray. Just an introduction to him, he's going to present on behalf of the NRO, policy document. We'll take questions at the end. Thank you. RAY PLZAK (Pause) line good morning. I'm Ray Plzak, I'm presenting this on behalf of the number resource organisation which is the five IRs working together jointly. As a matter of record AfriNIC has been provisionally accepted by the ICANN and, and subsequently also by the NRO as being a member of it as well. That's why AfriNIC is going to be part of this proposal. What is to be presented is a coordinated proposal amongst the senior staff of the RIRs to kind of put together a common set of language for further discussion that Anne had talked about it. Briefly I'm going to talk about the elements of the allocation policy, factors involved then a discussion about necessary space, special need space. Then an outline of what the policy proposal would be, then a quick thing about notifications and announcements Allocation policy has elements and factors. The elements are the size in the unit. And the criteria for initial space and additional space. Factors include things such as the available space the RIR already holds and also necessary space, space it needs to continue to go forward in business, routinely and in the cases where there may be a special need that is generated. Allocation factors - under available space. Looking at the free space that the RIR currently holds. Then to that you add the reservations the RIR may be having and that expire within 3 months, fragmented space. Fragmented space is that space which is the blocks that the RIR may hold that are smaller than the minimum allocation size that they would make to an LIR or ISP. Then it gives you available space. Necessary space, on the other hand, is a calculation of the 6-month allocation rate times the time period. Now, how do you determine what is necessary or special need space. If the requirement that the RIR has for an allocation from the IANA is equal to the calculation I just showed you for necessary space then there is no special need. If, on the other hand, there is a special requirement that has occurred that would exhaust the RIR's available address pool to satisfy that request there then there's a special need. Some of the things that would be a requirement to justify the special need, things that would have to be presented to the IANA would be first of all, trend data and analysis of allocation tendencies over a period of time. For example, if you look at the history of IPv6 allocations in the RIPE NCC, you would see in 2003 that the allocations there were about the same as they were in the other regions, maybe a little faster. If you look in 2004 you will see the RIPE NCC clearly outstripped the other regions combined, so their trend, if you would, in analysis would show that they were assuming IPv6 address space at a much higher rate and therefore they would generate probably some special need in that regard. The other thing that impacts it are one or more new allocation policies passed within the RIR itself. If the RIR at particular region produces a policy that would cause an increase in the consumption of IPv6 space then there would be a necessity to get more of that address space from the IANA. So the impact analysis of those policies would be part of the justification for the special need that would go to the IANA. Then looking at external factors that may be a factor. There is the current explosion in the growth of mobile operators in use of mobile space for mobile purposes. That's to take an example. There may be new networks being put in place, advances in technology. Then again there's that thing that bothers us from time to time, legal issues. In that case, you need to provide analysis. So, what is a proposed set of language to look at in regards to the allocation of IPv6 space from the IANA to RIR. Minimum size would be 18 months necessary space. And the allocation unit would be a /12. What this means is that the IANA would not just give a /12 to an RIR. If the necessary space that the RIR needs for its 18-month supply is greater than a /12 then they would receive more than one /12 unit. Criteria - it's a /12, for a new RIR the allocation is a /12 when an RIR is recognised. That /12 is given regardless of any utilisation that may have occurred within that new region from the old region. And also would be regardless of any space transferred to that new region. Additional space criteria would be if your available space was less than 50% of one /12 block or if the available space is less than the nine-month necessary space or need, necessary space, need or requirement then that would be the criteria the RIR would have to present to be satisfied to get a new allocation. Lastly, when this policy would be put into place, there would be provision that each existing IRR would receive a /12 if they have on hand less than a /12 in their available address pool. Notifications. Policy recognises that there should be notifications from the IANA to the receiving RIR and also by the IANA to the other RIRs and that announcements would be mainly possibly by the IANA and specifically by the RIRs to their necessary mailing lists. This is to allow the timely notification of operators so they can set filters and so forth. With that, thank you. And I guess the floor's open to questions. TOSHIYUKI HOSAKA Thank you, Ray and Anne. Is there any questions or comments? No. Thank you. Next agenda is an update on the IPv4 guidelines working group presented by Mars Wei. YI LEE Good morning ladies and gentlemen, my name is Yi Lee. I work for Seednet which is an ISP in Taiwan. We have been providing open access service since year 2000. It is my honour to present to you this proposal. Before we get to the topic, let me have a few words for the other presenter listed on the program guide. Mr Mars Wei. Mr Mars regret that he cannot come here and he wants me to send his regards to all of you, so I will present this proposal on behalf of him. First of all, I'd like to ask all of you to be so kind to excuse my English, so when you want to raise your questions, please say it slowly and in plain English, thank you. This presentation consists of four parts. To begin with, I will give you the background information about the proposal and then followed by a description of the problem we want to deal with. Then the targets we want to reach and then I will present to you the proposed update to conclude this presentation. The background. This proposal is actually a follow-up of APNIC. That informational proposal which Mr Mars Wei and I proposed - suggested a modification to subsequent allocation criteria for DSL and cable services. Then IPv4 guideline working group opened on August 2004. Then the mailing list started to review and modify the APNIC guidelines for IPv4 allocation and assignment requests on September 2004. The problem we want to deal with is the subsequent allocation criteria described in the APNIC IPv4 guideline takes into account only the number of the subscribers, which may not fully reflect the actual need. One of the typical scenarios that one subscriber probably would have more than one device that were connected to the Internet. So in this case more than one IP address would be needed. The target we want to reach is we want to add the support for the DSL services, then the second one is we want to add the consideration about IP-based utilisation as the criteria for applying subsequent allocation. This is the current statements in the APNIC IPv4 guideline. I have extracted the statement from the web site. As you can see on the screen there are five items in this criteria, but only the number of subscribers are taken into account. This is our proposed update of the modification shown in red on screen. The items we modified are item 1, 3 and 4. I will explain the detail of update later. This slide shows you the summary of the update. In order to save time I will skip this. This is the detail of the update for item 1. The statements of 10.2 stays - criteria for ADSL service and cable, but the description in the following items mention nothing about DSL so we added the bop address in the statement. We want to have a more accurate term for the xDSL service so the result is headend information specifying the number of CMTS or B-RAS devices planned per headend. This is the update for item 3. We added the IP utilisation as an option to consider on determining the past growth rate and add the RADIUS/DHCP log as support information. The rationale of this update is we want to have more flexible options to address the LIR needs. So the result is a growth rate based on average growth or IP utilisation per month over past 3 months (As an option, the ISP can supply a MRTG or RADIUS/DHCP server log to support the growth rate valuation.) This is the update for item 4, we added the subscribed DSL/cable circuits and consumed IP utilisation as options of the projection. Again, the rationale is we want to have a more flexible option to address the LIR needs. The result is projected number of subscribers, DSL/cable circuits subscribed or IP addresses consumed by subscribers at peak time within 12 months if the projection is significantly higher than that predicted by the growth rate or IP utilisation then additional explanation will be required. Any questions? TOSHIYUKI HOSAKA Thank you. Any questions or comments? (Pause) My understanding is that this is not actual policy proposal. Probably APNIC secretariat will revise IPv4 guideline document and publish it on the web site and announce it. YI LEE That would be appreciated. Thank you. ANNE LORD OK, good morning, everybody. This is an update on the LIR survey that is titled "current practices in managing IPv4 address space" that the APNIC Secretariat was tasked to conduct out of the last Policy SIG meeting in Fiji. By way of background for people who weren't at the meeting or haven't followed any of the history of this particular activity, the background is actually the HD-Ratio. The HD-Ratio proposal was made in Fiji and there was no consensus on the actual policy proposal at the meeting discussions but out of the meeting the Secretariat was tasked to conduct a survey of LIRs' resource management practices to allow a better understanding of the issues facing ISPs in trying to achieve 80% of utilisation of their address space. The next few slides are background about the HD-Ratio for the benefit of people who haven't been able to follow that policy process or haven't to date. So what is the problem that the HD-Ratio proposal was trying to solve? The feedback for a long time to the Secretariat has been that large LIRs have had difficulty in meeting 80% utilisation, which is required for a subsequent allocation in IPv4. So, in v6, we use the HD-Ratio as a means of assessing the utilisation threshold for additional allocation but, unlike v6, in v4, no similar allowance is made for the hierarchy that is perceived to have the effect on utilisation when managing address space. So this approach of "one size fits all", this 80% utilisation requirement in v4, is actually felt to be unfair by some people in the context of actually improving and offering services to APNIC members. So just a background on what the HD-Ratio is - it actually models the relationship between the size of a network and the numbers of levels of structure in a network and address utilisation efficiently. It actually makes the observation that, in large IP networks, there is an internal administrative and routing structure that is actually created to assist in managing and scaling networks. So, for example, POPs - there may be many POPs in an IP's network that are aggregated into cities, then into regions and then into the core network. So the larger the network, the HD-Ratio says, the greater the number of levels of internal structure and the overall utilisation depends on the number of levels of internal structure. So the more levels of structure there are, the more overhead this imposes on managing address space and the less able the ISP is to use the address space efficiently. So the HD-Ratio proposal actually proposes to use a variable percentage measure of utilisation that corresponds to a given prefix instead of the 80% fixed utilisation. There are some broader questions about the HD-Ratio and that is perhaps is the observation that it proposes about structure and the size of a network and the levels of hierarchy in a network actually correct? And what is the relationship between the network size and the number of levels of hierarchy? So APNIC has been tasked to conduct a survey of LIRs to actually allow better understanding of these issues and to inform us and put that into the debate about the HD-Ratio. So the title is "Current practices in managing IPv4 address space". The objective is to gather more information about what LIRs actually do when they manage their address space, what they do with it when they receive an allocation and to see if large LIRs have more difficulty than smaller ones in achieving 80% utilisation. And, while we're at it, we're going to ask questions about the use and extent of private address space and NAT, as a bonus while doing the survey. In terms of project timelines, the first phase is to design a draft questionnaire and, with assistance from the NIRs, and, in particular, TWNIC, who have conducted an initial survey, the Secretariat has put together a design for the questionnaire. At this meeting, we're after victims or volunteers to give us feedback on the questionnaire design. You've actually got a few responses from people that have been very good. We're still looking for feedback from other ISPs and the NIRs are actually helping with this too. So we hope to get a good spread of feedback about the actual design because this is the critical part of the survey. And to incorporate that feedback and actually circulate a new draft on the SIG policy and the APOPS mailing list, the APOPS list being the operator list, for further feedback and comment. In the second phase, we're going to finalise design with the survey, carry it out with assistance from NIRs - so this will require translation, so a little bit of time - and to evaluate the feedback and present the results at APNIC 20. And we will share the results with the other RIRs because I believe that the HD-Ratio proposal in one form or another are active policy proposals in both the RIPE and the ARIN regions. In terms of the design of the survey, TWNIC have actually conducted a quantitative survey, which will be presented straight after my presentation, and they surveyed their LIR members. They've obtained quite useful and valuable supporting information that's assisted in the design of the questionnaire. This survey will be more qualitative. It will consist of face-to-face interviews with volunteer LIR members. The APNIC training team will be able to assist us in reaching and conducting those interviews. It will be one page of questions, so it's designed to be quite short and easy to complete. And a critical part of the questionnaire will actually be drawing a diagram of how you actually manage your address space and that will complement the information that's given in the questions. So this is actually the very last question on the questionnaire as it stands right now. It asks the respondent to sketch out how they manage their address space, giving as much detail as possible as each level of hierarchy and use diagrams below. We've given three examples as a guide. The first one is just a network that's divided by services. And then further subdivided into infrastructure and customers. The second a network that's divided by regions and by services. So it's broken down from regions into cities and into POPs and then into actually deployment on to infrastructure and customers. And a network that's also divided by its services through the head office or the core of the network. And lastly, the third example is a network that's really has no hierarchy at all but is just divided up into chunks and chunks are allocated to POPs and to customers on a needs basis. So they're three examples. We're hoping that everybody won't directly copy the examples - and that's partly why we're doing the interviews face to face, because it's felt that this kind of information is better served by actually interviewing people, speaking to them and trying to tease out the information, rather than just asking them to complete an online survey or something like that. So right now, we need volunteers to provide feedback on the draft survey and the questionnaire and, if you're interested to give me some feedback, please send me an e-mail, I'd be very happy to come and talk to you this week. And that's it. I'd be happy to take any questions. TOSHIYUKI HOSAKA Thank you, Anne. Any questions or comments? OK, thank you very much. A survey has already been conducted by TWNIC and the result is presented by David Chen. You have plenty of time. DAVID CHEN I'm very glad to present that TWNIC has done a survey and some results from our survey. The survey is ISP in Taiwan for applying HD-Ratio to IPv4. Here is my presentation today. The first one - I want to introduce the survey scheme. And the second one is introduce questionnaire and the survey statistics and a brief summary. The survey scheme motivation is TWNIC Third Open Policy Meeting Address SIG concluded to conduct HD-Ratio for IPv4 survey in Taiwan. And it will be a reference for Asia Pacific region and we are happy to provide this, to share with all of you. And the survey purpose is - the first one is to introduce HD-Ratios to all ISPs in Taiwan and to know the obstacle of approaching 80% utilisation. And the third is to gather opinions from Taiwan and from LIR s in Taiwan. And the survey project period is from 5th to 31st January this year. The questionnaire is delivered by e-mails and received from fax or e-mail. The target is TWNIC's members, around 55, and the APNIC's members in Taiwan, is around two. And we received a valid questionnaire around 35 and it's around 61.4%. Here I am going to introduce our questionnaire structure. And the first part we would like to know ISP current background information, such as the content details. And the second part is elaborate of survey. And the third is introduce HD-Ratios. The first one is current utilisation is equal to 80%. And what is HD-Ratio? We want that LIRs in Taiwan to know what is HD-Ratio. Is implement in IPv6. And the third is how to calculate by HD-Ratio s. The fourth part is questions. Here is our several questions. The first one - we want to know the contact details from the ISPs. We would like to update background information and we want to know how many POPs are running in LIRs. And the third is we want to know what kind of service they have. And then the fourth is we want to know the typical factors that ISPs cannot approach to 80% and if they need IP address immediately. And we want to know what kind of factors would be considered when ISPs subdivide their services and what is their priority? And then we would like to know the IP address allocation affecting the utilisation approaching and what kind of management types did you implement if IP address is insufficient. And we would like to ask LIRs would HD-Ratios affect your company to request IPv4? And then we asked them what kind of calculating method does your company prefer? And this diagram shows the IP address distribution in Taiwan and it's around 20% is over /20. But most of the ISPs is more. This diagram shows ISP in Taiwan's preferred calculating method. There are around 43% would like to keep 80% utilisation. And they have 33% agreed to apply HD-Ratio to IPv4. And also have 21% want to lower right now utilisations. And we grouped this to show the background ISPs and their preferred and we got these diagrams. ISP-holders under /18s is prefer to keep utilisations equal to 80%. And then it's over /14s ISPs who would prefer to HD ratios. And, in this diagram, we have grouped by POPs and we have noted that the more POPs LIR s have, they more agree to HD ratios. And this diagram shows some - we want to know the factor of, the typical factors that affect the ISP reaching 80%, but we got three major reasons. One is the service's customers. And second is IP administrative management and new service come out. We find it very interesting that, if ISP hold IP address over /12, there is a big impact from new service come out. And this one is grouped by POP. And we know that in Taiwan, we have around 25 in Taiwan. So the POPs between 20 and 30, was very affecting IP administrative management. This page shows the priority of the subdivided address space. And there are three main factors. One is services and customers and the numbers of POPs were affecting ISPs subdividing their IP address. This diagram shows what to point out if the LIR s occurs IP blocks fragment. If that occurs, there will be three major reasons for this. One is marking. The second is administration management and the equipment limit. But there are half LIRs in Taiwan - no occurrence. Let me give a brief summary for this. One is services, customers and POPs affect achieving 80%. And the services and the customers are considered as major factors in I P administrative management. And the marketing change and administrative management would occur address block fragment. And over 50% ISPs support to change utilisations but there are still 43% ISPs want to keep original. And then we found out who is preferred HD-Ratio - more IP address-holders and more POP establisher. And finally we think HD ratios to IPv4 is positive for some ISPs, but it still need to gather more consensus in Taiwan. This survey is preliminary analysis. And right now TWNIC is doing further analysis for their behaviour. Maybe on behalf of APNIC to find out some actual reasons for IPv4 applying HD-Ratio to IPv4. That's all my today presentation. Any questions? TOSHIYUKI HOSAKA Thank you, David. Any questions or comments? OK, I have one. Could you go back to page 10. (David Chen displays slid) TOSHIYUKI HOSAKA Right. This survey results apparently shows that smaller ISP, which has around /20, in favour of 80% policy, but larger ISP are in favour of HD-Ratio. So I assume that it is very difficult to reach consensus among those two groups, right? DAVID CHEN So we want to introduce HD-Ratios to LIRs and we want to get more feedback from them, because the survey is just finished last month. So we need to do more research on that and, again, more feedback. PAUL WILSON Paul Wilson again. I'll just point out that the way the HD-Ratio works at the proposed level - the use of the HD-Ratio will make very little difference to smaller ISPs with address holdings of /20 up to /18 for instance. And the reason for that - in answer to a question that was raised when I made a presentation about the proposal at the last meeting - we don't actually hear in general from small ISPs that they do have difficulty with 80%. 80% and corresponding the proposed HD-Ratio value, seems to provide no problems, at least according to the evidence of general expressions of dissatisfaction, to ISPs of that size, so I suppose that the reason for this proposal is actually to make the address management over here fairer for larger ISPs and it's very interesting that the survey result is supporting the fact that the larger ISPs are seeing that opportunity. I guess the concern was raised as to whether or not this is an unfair benefit to larger ISPs and I don't think the survey really answers that question. That's quite a difficult one to answer. It's something that maybe requires more work, more technical analysis. Just finally, I'd say I think this is an excellent survey in terms of the quality, the details, the way it's been presented. I think it's very informative and useful and I commend TWNIC and say I think this is exactly the sort of work that is great to see coming from NIRs in particular who've got the resources to connect with and to contact their ISP communities, extract this sort of information. So thanks very much to David and TWNIC for this. Thanks. DAVID CHEN Thank you for that. TOSHIYUKI HOSAKA Are there any other questions or comments? No? Right. Thank you, David. Since we have done all the presentations presented in this Policy SIG - I'm sorry. (Confers with member of APNIC staff) TOSHIYUKI HOSAKA We still have 30 minutes more. So APNIC said they'd like to show policy flash presented by Champika. NURANI NIMPUNO Since there is time, we can show you something we've been working on. It's a little flash animation at the help desk. Because it's the Policy SIG, we thought it would be appropriate to show that animation. So here it comes. FLASH ANIMATION: APNIC is the Regional Internet Registry responsible for the management and distribution of Internet resource in the Asia Pacific. Internet resources such as IP addresses and AS numbers are important public resources and an essential part of the Internet infrastructure. Therefore, it is important that they are managed responsibly and distributed in a fair manner. To ensure this, there are policies in place that guide the Internet community in the usage of these resources. These policies make sure the resources are not being wasted, that they are properly registered and that they are used according to agreed best current practices. These policies can cover broad principles of stewardship. For example, IP addresses are not sold or bought. Other policies have a more specific technical focus, such as how to obtain an IP address allocation from APNIC. But what's common for all these policies, however, is that they aim to be fair and consistent while ensuring proper usage of Internet resources. This is vital for the continued stable growth of the Internet. So, who makes these policies? The Internet community develops and agrees on all APNIC policies. But, just as the Internet continues to develop, policies also need to evolve to suit changes in the industry. A key role of APNIC and the other Regional Internet Registries is to provide a forum through which members of the Internet community can discuss changes in the Internet and create policies to suit these changes. But how does the process of policy development work? A basic principle of Internet policy development is that the process is open to everyone. Because IP addresses and AS numbers are considered a public resource, it's important that anyone with an interest can get involved and propose changes to current policy. You don't even need to be an APNIC member. The second important principle is that this is a transparent process. All the decisions, meeting notes, presentations and discussions are documented on the APNIC website, which anyone can access. The third and final principle is that policy development is a bottom-up process. This means that the decisions and the proposals come from the community. The APNIC Secretariat doesn't decide on Internet resource policy. Instead, it's those who need and use the resources who decide what the policies should be. OK, so what are the steps involved in developing the new policy? Before a new policy can be created, or an existing policy changed, a member of the community must submit a policy proposal to one of the APNIC mailing lists. From here, the policy proposal goes through a series of steps, including special interest group discussions, the APNIC member meeting, continued discussion on the mailing lists and final approval by the APNIC Executive Council. This process ensures that the community is given the chance to examine the proposal in depth, with the proposer needing approval by consensus at each stage along the way. At the end of this process, with the whole community informed of the changes, the new policy is implemented. As you can see, there are many opportunities to express your opinion and it is easy to take part in the decision-making process. You don't have to be a member to propose new policy and anyone can participate in the process. So, why should I get involved? Taking an active role in Internet policy development can be a valuable opportunity to ensure that your organisation's interests are represented. But it's also an opportunity to learn and share experiences with others in the industry and to stay abreast with the latest development in the Internet. By taking part in the decision-making process, you make sure that your voice is also heard. Finally, the APNIC policy development process allows everyone to be sure that the Internet is being managed responsibly and that the decisions made are in the best interests of all Internet users. The APNIC policy development process is designed to ensure that anyone, no matter what their situation, can take an active role. At the centre of the process are the APNIC open policy meetings, which are healed twice a year. These meetings provide a physical forum for the Internet community to come together and, among other things, discuss Internet policy. For those Internet community members based in developing economies, there are opportunities for fellowship grants, which help ensure that all regions have the chance to be heard. For those unable to attend in person, it is still possible to participate in APNIC meetings. Live and online tools like Jabber chat, webcasts and transcripts allow people on the other side of the world to take part in policy development. You can not only listen to the discussions remotely, but you can also provide your input without having to be physically present at the meeting. Outside APNIC meetings, policy development continues on a number of APNIC mailing lists. Information on all mailing lists is available on the APNIC website, where you can find descriptions of each mailing list and instructions on how to subscribe. As we have seen, there are many opportunities and avenues to participate in the policy development process. Whether you choose to come to a meeting or participate remotely through the mailing list or Jabber chat, everyone in the Internet community can play a part in creating the policies that shape the Internet. We hope that you will play an active role in the Internet community and we hope to hearing from you. APPLAUSE TOSHIYUKI HOSAKA Thank you, Nurani. NURANI NIMPUNO I should add that we're showing this at the help desk. We have a policy development quiz you can fill out and there will be a fantastic prize at the end. So watch the clip and see if you understand the policy development process. It's fairly simple and you have a chance of winning a fantastic prize. We hope to see you at the help desk. Thank you. PAUL WILSON Yeah, I would like to mention that that production was made in-house. It was produced entirely by APNIC staff with the graphic design, the voices as well - some of them you might recognise - even the music by Chris here. So, in terms of the budget, it cost APNIC very little. But the quality of the production, I think - and I hope everyone agrees - is pretty fantastic and it certainly would not be easy to get something done like that commercially. So the APNIC production team is available for your multimedia needs, if anyone would like to get in touch, and the rates are low. Thanks. TOSHIYUKI HOSAKA Thank you very much. The final agenda is the election of chair, since Arano-san ANNOUNCED his intention to step down from the chair of this Policy SIG. So this process is done by - is going to be done by APNIC Secretariat. ANNE LORD Hello, yes. As Toshiyuki mentioned, Arano-san has sadly resigned. Before we start, I'd like to say thank you very much to Arano-san for his many dedicated years of service presiding as chair over the Policy SIG. We actually announced the request for anyone who would like to be chair of this Policy SIG and there was one nomination and that nomination was from Kenny Huang, who is actually currently a co-chair. So, unless there are any strong objections right now here today, Kenny will be the new chair of the Policy SIG and we will call for a new co-chair straight after this meeting. So if everyone is in agreement with that, I would like to congratulate Kenny on being the new chair of the Policy SIG. APPLAUSE TOSHIYUKI HOSAKA OK, so, we would like to thank you for all the presentations, who contributed to this successful policy SIG and thank you to all the participants to the Policy SIG. Hopefully we can meet next Policy SIG at the next APNIC meeting. Thank you very much. APPLAUSE