Policy SIG, Wednesday February 25, 4:00pm-5:30 pm TAKASHI ARANO: In the second session, we will discuss the four topics like this. The first speaker, Maemura Akinori, is the chair for APNIC. MAEMURA AKINORI: This is Akinori Maemura. Today, I'm presenting the proposal prop-015-001. This is the website of APNIC and I'm very glad to have this kind of a formalised process for the policy process. This proposal is - the author of this proposal is the APNIC Secretariat but, in this case, APNIC Executive Council had something to do with this proposal, so I am proposing now this proposal on behalf of Executive Council. OK. This proposal is regarding to some problems with the APNIC policy document APNIC-089. In the initial allocation criteria which includes, it reads, "Organisation must plan to provide IPv6 connectivity to organisations to which it will assign /48s, by advertising that connectivity through its single aggregated address allocation". And this article has ambiguous points. One is, does this include private networks which are not connected to the global Internet? If not, where do such networks obtain their addresses. And the second thing is that, OK, it reads, "by advertising that connectivity through its single aggregated address allocation" but advertising to whom? This is ambiguous points. And I present you conclusion first. This ambiguous point in the policy document has been interpreted by Secretariat as closed networks have been considered to be within scope of existing policy of the APNIC-089. So APNIC Secretariat has made one IPv6 allocation to such a network that met all other initial allocation criteria. So, during 20 the year 2003, the Secretariat sought clarification from the APNIC Executive Council. That is the conclusion and that is the practice for this proposal. Let's review the background. The background is that the lack of private address space available in IPv6. As you know, there has been - as you know, IPv4 has the private address defined in RFC1918. It features 10/8, 172.16/12 and 192.168/16. But, in case of the IPv6, we don't have any private address space. And, in the concept of the IPv6, in that case, we should use site-local address. But the assignment size is limited to /48 and, moreover, this site-local address is now under discussion but likely to be opposed. But, on the other hand, large not-connected networks need IPv6 address space. Not only large networks, but small networks have some problems if we don't have the site-local addresses. So before the Secretariat began the application of this interpretation, the EC, Executive Council, had a discussion about this and, as a conclusion, we issued interim clarification notice in November, 2003, to direct Secretariat to continue making such allocations until APNIC OPM, that is this Open Policy Meeting. This clarification notice can be read further in this URL. And no reference for the 'to whom' such advertisements should be made. This advertisement may not be part of the global Internet, but it may be part of the private network for a very big private network that is not connected to the Internet. Let's look at other RIRs. In ARIN, ARIN does not currently make allocations to closed networks. In LACNIC, LACNIC does not currently make allocations to closed networks. And in RIPE NCC, evaluation is to be done on a case-by-case basis. So the proposal here is that the APNIC IPv6 policy should allow allocations to the closed network. That is supporting the current interpretation of the APNIC Secretariat. So providing IPv6 address space if other initial allocation criteria are met. So the proposal that the current APNIC-089 should be applied, it reads. For this proposal for the NIR considerations - the outcome of this policy discussion should be applicable to all NIRs equally in APNIC region so this issue has no difference in the cases in APNIC and cases in NIRs. And implementation is - if this proposal is approved through APNIC policy processes, the current interim EC notice for clarification will expire. And this proposal is to be implemented immediately. That means the continuing client status. And regarding the coordination with the other RIRs, it should be done to clarify the language and intent of the policy. This is all for this proposal. Comments or questions? TAKASHI ARANO: Comments? Questions? TOSHIYUKI HOSAKA: Toshi from JPNIC. Actually, I agree with this proposal but I have just one comment. I was not aware of your EC interim notification until I coincidentally found it in the website, APNIC website. And I didn't see any posting on the mailing list, nor could I find it on the APNIC homepage. So I think it would be better for us all that we can see such notification. It should be posted on the appropriate mailing list or APNIC homepage so that we NIRs can explain our members accordingly in a timely manner and we can evaluate the requests from our members as well. This is my comment. Thank you. MAEMURA AKINORI: OK. Thank you very much. Q. You did this in the past? MAEMURA AKINORI: I don't think so. GERARD ROSS: I think there was just simply an administrative error and the announcement didn't get made. There was an intention to do it and the document was published but the announcement didn't go out. EINAR BOHLIN: My name’s Einar Bohlin, I'm with the American Registry for Internet Numbers. We have two policy proposals that are going to be discussed leading up to our next meeting that concern themselves with the use of unique IPs for private networks. MAEMURA AKINORI: OK, thank you very much. LEO VEGODA: Leo Vegoda from RIPE NCC. On the presentation, you mentioned that we look at these cases on a case-by-case basis and the reason I said that is we've had one case. So I thought let's not make it a binding precedent. We've actually had someone contact us on basically this kind of matter which would be case number two. And I think that some clarity in this is needed because, at the moment, it looks like the address policy is trying to force people to make a routing policy decision which is odd because most address policies don't tell people how to route address space. So I think, in this case, some clarity is definitely needed. TAKASHI ARANO: Do you need basic change in the current policy document? Do you want to do some supplement in the guideline document? GEOFF HUSTON: Geoff Huston, as far as I'm aware, the document, the root document we're talking about is actually a common document across the RIRs and, unless someone else can stand up and contradict me here, I actually believe that the most appropriate thing right now is to produce a second document, a supplemental, that interprets the first. I suspect that, if you actually want to change that root document, we've got a coordination exercise across the other three RIRs in that base document. Am I right? LEO VEGODA: Geoff, I'd actually question why you would want to re-interpret the base document. If there's a problem with the base document because it's wrong, then I’d just suggest changing it and, if there's a coordination effort, then the RIR staff will support the policy-making community or at least this RIR staff will, in doing that and will try and make it as easy as possible for the policy-making people to do that. But I personally find it a little bit odd that, if there's a problem with the base document, that we just re-interpret it in a different way. It sounds like English law. Why not just fix the problem instead of pretending the problem doesn't exist? GEOFF HUSTON: If the APNIC version of the comment document is changed, then we don't have a common document that describes a global policy, that's all. Now this is really down to the operational esoterica in some way and it's just trying to understand the difference in process between a policy within a particular RIR and the usual route when an RIR has observed a problem with a coordinated global policy and within the RIR has proposed and accepted a change, assuming you do that. Then what's the mechanics, if you will, of saying, first in the APNIC community, "Fine, we're going to go with this interpretation," and then, secondly, across the other RIRs in the system, what happens then? LEO VEGODA: Just presenting the proposal at each Open Policy Meeting, putting it on the mailing list. There's the RIPE meeting in January, a meeting now, the LACNIC meeting in March, ARIN meeting in April. Just stick it on all those agendas and, there, you're done. I mean, it's not rocket science. GEOFF HUSTON: Assuming they all accept it. LEO VEGODA: If there's a genuine problem and people genuinely see it, they might. If it's the sensible solution, people might see that there's a problem. GEOFF HUSTON: But I think the question is still a valid question. What Leo is suggesting - he's suggesting that we can simply change APNIC-089 and move on and, unless I hear anyone objecting to that, then I suppose I will run to that. I actually thought there might be some sensitivities but, if there is none, then that's fine. IZUMI OKUTANI: I think the point that Geoff has raised is an interesting point. If we don't have a coordination issue, I agree with Leo that it should be clarified in the policy rather than the guidelines. That's a much more simple, easier thing and better to understand. But I'm not sure to what extent each region can have its own policy. Because, for example, the proposal that Paul has made earlier - I'm not sure how that would affect the, you know, unique policy. We shouldn't have, like, you know, case by case decisions. I think we need to - I don't know if this is the proper forum, but I'm interested to know to what extent each RIR can have their own policy document. I don't mean any supplementary. And to what extent you need to coordinate. GERMAN VALDEZ: German Valdez, from LACNIC. I was going to present [inaudible] that LACNIC regions develop a new criteria for additional allocation of IPv6. So, from the perspective of Latin America, we wish to develop a different policy that the rest of the criteria - for the rest of the region. Part of the solution is that the staff be fully involved in any coordination for future common policy about IPv6. It's important to say that the criteria was developed for what is happening right now in the LACNIC region. This is also part of this resolution that we are going to review this policy in two years and see how this is working. But the details, I mean, I can give you next Friday. Q. My name is [inaudible] and I am in favour of this proposal in that, first, we have a policy and also, in APNIC, we are developing a IPv6 guidelines document so things like this in different RIRs, there are different operations, this may be covered in the guidelines document and if there is something that we need to make change in the policy document, we can go for that. But, meanwhile, putting that in the guidelines document and see what the actual operation fits would be something we might want to try. MAEMURA AKINORI: So you mean this kind of interpretation? Maybe this is the proposal and this is the current policy. You are now proposing to include this kind of content in the guidelines. Is that correct? Q. Yes, putting it in the guideline would be easier for coordination between RIRs and before the coordination is made, before the consensus is made, meanwhile, we can work on it with the guidelines. PAUL WILSON: Could I just make a comment or clarification on the history of the policy development - it's not actually on this policy. When the RIRs were initially asked to prepare for IPv6 allocations by the IAB, there was a global effort at that time around 1998-99 to develop a policy that was common to all RIRs. It was called for a time a global policy until it was pointed out that global policy has a special meaning in the ICANN and to continue to develop a global policy starts to require a ratification through the ICANN structure which I think nobody felt was appropriate for this type of activity. So, in fact, what the RIR community then worked on is what is referred to as a common policy, and I'm sure most people here remember a lot of work being done on this common policy, particularly Arano-san and Kosuke, who went around the world in order to coordinate a common policy. The downside of that - and it was said many times - is that it's a long process and it’s really unsustainable in terms of the ongoing development of this IPv6 policy, and I believe that now the tendency amongst all of the RIRs is in fact to make regional changes to the current policy, referring to the policy as a coordinated policy - that is, while the policy may not be identical in every region, efforts will be made in these policy groups to make sure that there is not a radical divergence, that there is cross communication about policy changes and so forth. So, as Cameron just said in fact, LACNIC has adopted some different policy provisions and it may well be that, through this process here, that we adopt different policy provisions. I think we can face that fact and still maintain a coordinated policy. I think it's a little bit risky to put real policy provisions into the guidelines document as has just been suggested because they are still policy and, in fact, this proposal is a policy. If it only appears in the guidelines document, then we're asking our other RIR counterparts to track a policy document and a guidelines document and to bring those together because, in fact, the policy will be spread across both. So I think we should be facing, my feeling is that we should be facing the reality of making changes to the core policy document that we will at the staff level and within these groups continue to coordinate those changes and to make sure that information is shared and that we have some parallel development and not radical divergence of policies. A. This kind of implementation of this interpretation should be reflected in the policy document. IZUMI OKUTANI: I think Paul has explained pretty much what I wanted to confirm. I just felt that Paul’s proposal and this proposal should follow a consistent process. This shouldn't go into the guidelines and then Paul's proposal be included in the policy. That's the part I was concerned with. TAKASHI ARANO: OK. Any other comments or questions? I will take a vote for you. The voting should consist of two parts. One is the proposal itself. Do you agree for this proposal particularly? And second question I will pose is the global coordination question. First of all, I will ask you whether you are in favour of this proposal to allow closed networks to be allocated global address space. How many of you agree with Maemura-san's proposal. Raise your hands. How many of you disagree? You've got consensus. And the second question is how to proceed with this proposal and the previous one. I understand that global- coordinated policy means we change the APNIC policy first and then try to coordinate with other regions. But there is a difference of opinion. He said that we should suspend the implementation until the coordination is finished and meanwhile we should describe something in the guidelines. Right? A. Yeah. Q. So which do you like? Is there any comments or opinion about these things? If not, I will call for a vote here. Is this OK? Is everything clear? IZUMI OKUTANI: I thought that Paul's point was to describe it in the policy document because the policy can be coordinated and we can have distinct policy documents. TAKASHI ARANO: Yes, my question will be that - can we change the APNIC document 089 immediately or wait for the coordination, global coordination, as he said. If there is no opinion about this coordination... ANNE LORD: I think as it's consensus here, we follow the policy process, which means putting this on to the mailing list for two months. In that time, we can coordinate with the other RIRs and I think the other meetings are coming up. We can also, after that two months is up, if there's easy approval, then I think we can go ahead and change the APNIC policy document, but still coordinate with the other RIRs in parallel. TAKASHI ARANO: I totally agree with you personally but there is another opinion that he said that we should wait for global coordination. If we throw away his idea, it's OK but, as a Chair, I'd like to get all of your opinions. IZUMI OKUTANI: I'd like to ask if this was proposed before Paul's explanation or you still feel the same way after Paul's explanation. A. Before Paul's proposal, I was saying that I was just anxious whether, if we get the consensus on your basic proposal, I was just wondering how we proceed on that. One way of proceeding is I was suggesting going with the guideline but, if we can just go and change APNIC-089, then that would be fine for me. So I have no problem with Anne's proposal. TAKASHI ARANO: You did not propose a concrete text in your proposal. Should we spend some three months as a standard process or just two months is enough? MAEMURA AKINORI: Yes, I should have proposed. GERARD ROSS: With the process that we have now following the decisions that went through at the end of last year, a policy statement can be made by the SIG, general policy issues can be discussed, then the Secretariat will draft a statement which we believe captures what was the consensus and that draft is put up, people can object to that if they think it doesn't appropriately capture the consensus. But basically it's not necessary in the SIG to come up with the exact wording. TAKASHI ARANO: Thank you Gerard. Thank you very much. Next presentation is the IPv6 guidelines presented by the three people. BILLY CHEON: My name is Billy from KRNIC. I will introduce guidelines for IPv6 allocations and assignment. OK, first, I want you to know the intention of this guideline. As you are aware, we already have IPv6 policy, but it has ambiguous and confusing points so, to avoid that, we developed guidelines. And I believe the main difference from policy is that this guideline provides specific examples for the initial allocation and subsequent allocation as well as special cases. And hopefully these guidelines will be a supporting document for the existing policy documents. For the drafting, first, we had the three of us - I mean, we have three volunteered Co-chairs, Akira-san from Poweredcom and Toshiyuki-san from JPNIC and myself from KRNIC. We drafted the document and submitted it on the mailing list and then as of December 2003 to this meeting, we collected opinions from the APNIC community. This guideline consists of 11 items. The 11 items are split by three Co-chairs. Table of contents one to five will be covered by myself and six to seven will be covered by Toshi-san and the rest of it will be covered by Akira-san. OK, let's see the introduction. These guidelines are developed to meet APNIC community's needs and nothing in these guidelines is going to change any of the specific policies in other APNIC documents. As I said, this is supporting document. And the second-scope - this document applies only to the management of global IPv6 address space in the Asia Pacific region. It should be read in conjunction with other APNIC documents particularly APNIC-089. I mentioned that it should be referenced with this guideline. Third - additional guidance - these guidelines are not exhaustive. If you need more information, maybe you can refer to APNIC website. Four - I followed the six management goals of IPv6 address management. Five - application of guidelines. These issues in this document reflect many of the considerations used by APNIC in evaluating requests. It is intend that NIRs will either adopt these or similar guidelines for their own members. This is it for my part and if you have any questions or comments, hopefully I can get at the end of presentation. TOSHIYUKI HOSAKA: I'm from JPNIC. Six - definition of a site. The motivation is to try to clarify the definition of a site to those who are not familiar with this concept. The summary is that a site is counted in accordance with the number of contracts. And we had some comments from JPNIC that what if there was a case that one contract offers multiple access lines. This may be a blank concept but no other good expression coming up so we left original draft as it is. 6.1 - assignment address space size. This section is just saying that LIRs can assign /48 to their residential customers. And then seven - Initial allocation criteria. Maybe this is one of the most important parts of this guideline because the initial motivation of this guideline is to reduce the psychological barrier by providing an example of 200 /48s to other organisations. So the summary here is that what we'd like to say is that the most important point here is that the existence of a plan to assign 200 /48s to other organisations, not the feasibility of the plan. Next is the use of existing IPv4 infrastructure. [inaudible] This section reflects the consensus or modified presentation from APNIC. This is the documentation required and supplementary document. So the motivation here is that we'd like to provide an example documentation each RIR and NIR request to LIRs. So summary here is LIRs are requested to provide a network diagram, network equipment information or other relevant information. And we have actually - we have a comment from the community that network diagram information should be enough. But I have no idea whether this is enough to evaluate the request so I personally think this is a case-by-case basis. And next is closed networks. I think the allocation, IPv6 allocation to the closed networks, the proposal regarding closed networks reached a consensus. So this section will therefore have to reach consensus in this APNIC meeting. Thank you. AKIRA NAKAGAWA My name is Akira from Poweredcom, it's an ISP in Tokyo. TOSHIYUKI HOSAKA: I'm sorry. I forgot one part. Initially, we were going to put NAT on this guideline document and actually we had an excellent draft from Geoff Huston, but we decided to delete this section because I thought this description does not help anyone who requests an initial allocation. AKIRA NAKAGAWA: What is the SOR? It is the process for RIR and NIR to see the detail. The LIRs must follow the SOR process in the case of requesting for initial prefix shorter than a /48, like a /48, or there is a request for subsequent prefix. LIRs don't have to do in case sub-allocating to downstream ISPs. It means allocations, including downstream ISPs. In case of assignment, an SOR is needed but in case of allocation, no need for SOR. For SOR, documentation is required. Network diagram of an end-site and the network equipment information and full details to justify the /48 assignments at end-site. It might be hard for LIRs but this is the required documentation. Or, in a special case, other information to justify multiple /48s - other information is needed. Subsequent allocations - this is the criteria and example for subsequent allocations. The HD ratio table is very complicated and so this simplifies the explanation table. How to calculate /48s? It is based on /48s registered in the Whois database, which includes assigned /48s and assigned /48s through its downstream ISP. It doesn't include sub-allocation. This is the point which is different from IPv4. In IPv4, sub-allocated blocks are considered as utilisation. Requesting a reservation - who registers? Well, RIRs allocate to LIR, LIR should allocate register. When LIR assign to its end-site, end-site or LIR according to their contract, one of them has to register. When LIR allocate to downstream ISP, it's the responsibility of the downstream ISP. When the downstream ISP assigns to the end-site, it's the downstream ISP or the end site. Minimum size is a /48. Now, ip6.arpa is recommended to use. There are a few cases but, if you use temporary address, which is described in RFC3041, in this case, there is no description in any documents. So, on this guideline, there is no definition, I don't think. Next, is the database registration. In this case, database means Whois database of RIRs and NIRs. If NIR has a database, NIR's database is to be used. But, if NIR doesn't have a database, RIR's database is to be used instead of NIR's. Who has the responsibility of the registration? Initial and subsequent allocation, it's the RIR's responsibility and each assignment, in case of each assignment, this is the responsibility of the organisation which assigns. In the case of the downstream ISP, this is the organisation or the downstream ISP. If the - in case of /48, for example, it is organisation that assign. The items to be registered is as follows: The detail is in URL. And there are some remaining issues like, for example, firstly, what if an ISP plans to assign a /64 to its users? The second point is transit providers. It's very difficult to meet the criteria for transit providers. And last of all, multinational companies - can we allow them to receive an allocation? The three of these are remaining issues. So then, about the publication of guidelines - after this APNIC meeting, we will request the APNIC Secretariat to edit the wording and then I would like APNIC to publish this. APNIC will post the edited guidelines document to appropriate mailing list and the guideline mail list or SIG mailing list. If you have any comments, we can answer or, if we cannot answer here, we will discuss - there is a mailing list up there, so you can post to the mailing list. That's all. TAKASHI ARANO: OK, thank you very much. Is there any question, comment? From me, sorry - can I consider whether these guidelines reflect the current practice of APNIC? I would like to confirm? Any questions. Comments? ANNE LORD: Anne Lord, APNIC. I was an observer on the mailing list and I just wanted to say that I was very impressed with the work that was done by the working group and wanted to thank them all for their efforts because they achieved what they did in a very short time frame and produced, I think, some very useful work that will be used by people in this region and read by people in this region who perhaps need extra explanations as to how to understand the policy, so that's just a thank you. And I have a couple of other specific comments which I perhaps might make on the mailing list about certain issues. But some things I think you may be touching into some policy areas and you might want to take that to the policy forum. The issues you raised at the end - some of those might be policy items and also I think in general, the section on the database requirements also applied to IPv4 and perhaps that's a more general database FAQ that we need to look at our existing documentation on the database to see if it's clear enough to incorporate the sort of guidelines you've got for the IPv6 assignment allocation registration details. So I just think perhaps the database part could be pulled from the document because I think it's already covered in existing documentation and, if it isn't, it should be. That's all. AKIRA NAKAGAWA: Thank you very much. TAKASHI ARANO: Comments? IZUMI OKUTANI: It's just a minor point but I thought it would be good to provide examples of the v4 networks converting to v6 as shown in Paul's slide. I thought it would be useful to include them in the guidelines. Just my personal comment. AKIRA NAKAGAWA: Thank you very much. BILLY CHEON: Billy from KRNIC. Table of contents 6.1 - there is statement that registered subscribers should have received /48. With this statement, there is comments from Korean community. This means - my personal opinion, if residential subscribers Are public users, I think they can receive /48. I think it might be wasteful of address for home users. I'd like to suggest maybe we can change this wording. Residential subscribers 'can' receive a /48 instead of residential subscribers 'should' receive. TOSHIYUKI HOSAKA: Yes. I am actually aware that most of Japanese ISPs are assigned to residential users. But, on the other hand, RFC says the residential customers should receive a /48. So my original idea is that we - yes, we should not say that LIR must assign /48 or /64. It depends, it's up to ISP. So it's yeah, I agree. We can slightly modify that wording to 'can' or something. KOSUKE ITO: Actually, the original document of the policy doesn't step into assignment size. So, in the guidelines, they shouldn't say anything about 'should' or 'can'. It should point out which reference they are pulling out - that's the guideline. Then, if we have some mixed feeling about the assignment of the /48 to the regular residential users, then we should go for the recommendation to change the text. Otherwise, while we are considering the text on the guidelines... TOSHIYUKI HOSAKA: Alright, thank you. Any other comments? TAKASHI ARANO: Actually, since this is information, informational. I would like to ask the Secretariat to implement ,to write actual guidelines and post it to the mailing list. That is the action item. Thank you very much. APPLAUSE Next presentation is LIR IPv6 requirements, presented by Leo. LEO VEGODA: Can you hear me now? Lovely. OK. I'm Leo Vegoda, Registration Services Manager, RIPE NCC in Amsterdam, and I'm going to talk about some things that we've noticed over the last few months. The amount of IPv6 address space that people are using and ask some questions about how we should be managing the IPv6 address pool. An overview: the reason we’re looking at this is because we noticed more address spaces going out. So I'm going to explain the current situation as we're seeing it in our region, look at the methodology that we use to work through this, to report the numbers that we found, and ask some questions. OK. IPv6 is in its initial deployment stage at the moment but we do see an increasing number of allocations going out and we're seeing larger allocations going out. We've made two that are larger than the minimum and I've had people talking to me and talking about seriously quite large requests. So that might mean that the way we currently have address space, we get /23 blocks from the IANA and we go through those fairly fast. We went through about three last year. Now, it's not such a big problem for us. We can go through the address blocks as fast as we need them. I don't suppose it's such a big problem for Doug at the IANA. It might be a problem for ISPs because they might want to be updated filters and things like that. Now I mentioned earlier that we made a /27 allocation to one LIRs. The minimum allocation is a /32, and that’s quite a difference in size between those two, and of course, this wasn't for porting their whole network so that it's all IPv6 capable. This is only for small subset. So at this point we start thinking, "OK, we really need to take a look at this because the way we're managing things at the moment might be inconvenient for people and it might have an impact on the routing system that is not a positive one." So how much address space will LIRs need and of course that reflects in how should the RIRs manage the IPv6 address space? So we've got the /32 minimum allocation. Our practice at the moment at the RIPE NCC, and I think this may be a case for all the RIRs, we reserve three bits. Our chap who got a /27, we've reserved up to a /24. That's what they can grow into. If they need more address space than that, then they're going to have to add another route. That's our current practice. Maybe it's good. Maybe it's not. We've made 302 allocations so far, as of last night. So these vary from /35, where again they're reserved up to a /29, or the /32 reserved up to a /29. We're just reserving three bits for anyone with a /32 or more address space. Now this is the IPv6 unicast space, our current /3. Now, this down here at the bottom is our /3 cut into /8s and at the left-hand side, 2000/8. That's the current production IPv6 address space that the RIRs are giving out. This here is where 6bone is, in 3F00/8. Now, when I was at this meeting last year, and at RIPE meetings and so on, people have said we’d like distinct blocks for RIRs because that helps then when they're managing our systems. That was a call from operators that we heard. So, listening to that, we’ve thought, if they want distinct blocks, what size blocks do they want? Here we've just gone and said this is the largest size block you can give out, the one at the top, cut into /6s. Those are the largest blocks you can give out in the current /3. There are six blocks there. There are currently four RIR and AfriNIC is clearly on the way. If you wanted to, you could say each of the RIRs should get a /6 but that's jumping the gun. Let's go and have a look at what we're looking at. When we're cutting up the address space, we need to try and look into the future, and make predictions about how things might be or how things will be and see what we want to do. That's difficult because we don't really know what's going to happen. We can only base our predictions on looking at the past and see what's happened there. We'll be getting these large requests and not just for IPv6 but also for IPv4. That's the current trend. Where is IPv4 address space being used? That's the only thing we really know about. That's where the real deployment is. What's the biggest user of IPv4 address space and does that map to IPv6? The biggest user of IPv4 address spaces that we see is the always-on broadband customer. OF course, there are other users of IPv6 address space or there will be other users of IPv6 address space that aren't this sector in the market, but we don't really know about them, so how can we make a prediction? We've got to go on what we can see. We can see that there's growth in this sector of the network. We know that the existing always-on broadband providers are now offering IPv6. I could get a native IPv6 ADSL connection in Amsterdam, at least if I installed a telephone line I could. My dad could get a native ADSL connection in London, and I’m sure that there are other providers in other countries where they're offering native IPv6 connections at the moment. And we need to look at the assumptions that we've made here and I'll show you how we've tried to work out how this section of the network might impact the address space, because at least it can give us an inkling into how to we might want to cut things up. We've assumed that IPv6 is going to be ubiquitous, because maybe people want ubiquitous networks. We’ve assumed that there’s going to be this co-existence between IPv4 and IPv6. And we've assumed that the connections for households, residential connections are going to be very common. One reason we've assumed that is because governments seems to be in a competition over who has the most broadband users. They like to push those sectors of the market. They can push towards pushing implementing broadband and always-on connections. This is quite important because we came up, as the RIRs, with a proposal to take that whole /3 and provide a single sparse allocation mechanism when handing out the address space. We've got to look at this because the message we got was they want RIRs to have separate blocks for each RIR. So it's very important that we go and take these sort of things into account when we're going to work out how big each RIR's block is likely to be. So here’s our methodology - we went and took the top users of IPv4 and IPv6 address space in our region. They didn't map exactly into each other but we ended up with 11 countries and stayed in the top 10, and that's out of 90 countries in our region. At the time we did this study, there were 3,488 LIRs and 2,327 were represented in the study. We think it's fairly representative of those big users - it's about two third of our membership. We took some statistics on the number of households we got from the United Nations. We looked at some ITU statistics on how these always-on technologies are dispersed around the world. How many households in different countries have access to always-on broadband connections. And then we had a look and we see the HD ratio and it favours the network - the more address space you need, the more the HD ratio gives you, so you’ve got to take that into account as well. So, when we go and have a look at a 10% penetration, which is sort of around the area that some of the countries in our region is at. We go and see that the usage per country is actually - there's a fair bit of difference some country that could easily fit inside a /26 and then we’ve got say, for instance, Russia, where it looks like they need a /21, assuming that 10% of the households had IPv6, always-on broadband connections. So we're seeing quite a difference there. That's about five bits. But that's not the only way to look at it. We've looked at it from the point of view of the average allocation size. And when we look at the average allocation size, we were assuming - we weren't assuming but the way we did it, it was an even spread of customers between LIRs. We know that's not entirely realistic. Obviously some LIRs will have more customers than others, but it was the only way we could realistically do the study in the time we had. So when we look at that we can see that quite a few of these country have LIRs that conceivably would fit quite nicely inside a /32. In fact they also fit quite nicely inside our reservations. If they got the minimum allocation in a /22, they'd fit nicely in a /29, for 10%. We had a look at 70% penetration in this particular market because we thought, "What's the largest penetration that we can find?", and the largest we could find was Korea, which was around 70%. We thought, "Maybe that's sort of like the top amount that we're likely to see over the next few years." So we looked at 70% and some of the smaller countries or countries with smaller LIRs, they came out with smaller needs. But we see that for instance France and Russia come out looking like they need maybe /18s between all their different LIRs. And that's a bit odd because although France is a relatively large country, it's nowhere near as large as Russia. Russia is huge. So this made us think again, and what we did was have a look and we actually found that France seems to have way more customers per LIR or way more assignments and address space per LIR than some of the other countries. Basically, the market is not the same all across our region. What we see is for instance in a country like Finland or the Netherlands, lots and lots and lots of small ISPs, whereas you go into a country like France and you see a few larger ISPs, and this has a big effect because of the HD ratio and the way it works - it favours the bigger networks. So, when we go and look here at the 70% penetration average allocation size, assuming an even spread of customers to LIR, it comes out that France average LIR needs a /26. That doesn't fit any of those French LIRs that currently have an IPv6 allocation of a /32, or they’re not going to be able to expand that to a /26 because we’ve been reserving it up to a /29. So they're gonna need more than one route announcement. But of course, this is 70% and it's a way off. So we went and had a look again to go and see the sort of amount of address space we would need overall, and one thing we did was we thought we'd have a look at the amount of IPv4 address space that we've been notified as being used for these always-on broadband services. When we're looking at this, we're not seeing the whole picture, because LIRs send us request and they say, "Please may we make this assignment?", and send us a second opinion request much the same way APNIC gets sent requests. But LIRs have assignment windows, so we don't see all of the assignments they make but we categorise the ones that do come in. And according to the IPv4 assignments that we've had come through us for these technologies, it looks like that will turn into a /18 which is actually more than a 10% penetration when we look at just IPv6. And obviously what we're seeing here, or I think what we could be seeing here, is that lots of ISPs will review a subnet for your always-on connection. Always will give you maybe a /32, either static or dynamic, and some will only give you an attic connection. So it's very important that we don't just sort of give a /48 for every single IPv4 address that's used for these kind of technologies because that's probably not what is needed. When we go and look at the other end of that scale, we see at 70% it looks like a /15 but this is without any reservation, without any room for growth, and not taking into account any other users of this address space because we were just looking at what we saw as a big usage sector. We couldn't go and look at all usage sectors, OK? So we're seeing /15 as sort of what would be needed with a 70% penetration in this particular kind of market. And, so, looking back again, the thing that sticks out, is LIR allocation size. Most customers are going to qualify for a /48 under this common policy that we're working to at the moment and the HD ratio favours the larger LIR - it pays to be big, at least that's what I tell my doctor. So, this is a table which is very similar to the table which Paul showed us earlier on. We can see that if you have about 25,000 customers, on this table, you would justify a /29 allocation. And that's actually not so many customers, at least in some of the countries in our region. When you go and look at the other end of the scale, you see 5 million customers, or 5 million /48 assignments and I'm assuming each /48 assignment is a customer of the network, equaling a /21. OK. 5 million customers or 5 million assignments, it sounds like a lot, but when we go and look at our LIRs, they're big multinational networks. They operate in more than one country, and what they've said to us is, 'hey, what we'd like to do is get one allocation because we like to make a single announcement from our area,' and so we’ll have one LIR send in a request, get that big allocation, we’ll make sub-allocations to the national operations. Those national operations are then going to sign the address space to the customers attached to their networks. And when you go and think of a network or a company that's operating in 8 or 9 or 12 countries, 5 million assignments doesn't sound all that incredible. So you could be looking at a big LIR with a big customer base, justifying quite a lot of address space, because remember, if you go back to this slide, we were saying it looks like maybe a /15, but we don't need many of those /21 networks to fill up a /15. So, our findings are not constant. Total usage made between a /19 and a/15, assuming absolutely no room for growth looking at 11 countries and only broadband always-on type services - average allocation size seems to be a /26, but that’s only the average, and there's lots that's not average. And this is important because big guys get very big. So I think we need to ask some questions. How many years should RIRs allocate for? Because we can't really know the future and we've only looked at a small segment of the total ISP-type market here. So how many years should LIRs have an allocation that would last them for because we don't know what’s going to be the killer service, the big seller of four or five years time. How many years should RIRs have space for? Because if an LIR has to come back again and again for address space, we can have issues with lots of routes. The RIR can't reserve to let the LIR grow and you're gonna have the same sort of routing table size in IPv6 that you see in IPv4 and maybe that's a good thing and maybe it's not - I don’t buy routers. How much growth in an LIR’s allocation should be allowed for? Because we can only look at some of the things that we know now. And what we can't look at is what we don't know. And we don't know what's going to be the thing that really takes off. This could be the thing that really takes off if IPv6 penetrates to residential users, and if it does, it could be using a fair bit of address space. So we need to look at these questions when we're looking at how the IPv6 address space should be cut up and managed. I don't have the answers, this presentation is intended to stimulate thought and perhaps a bit of discussion on mailing lists. So those are the questions I'll leave you with and thank you for inviting me today, and I'll see you on-line. TAKASHI ARANO: Any comments or questions? KOSUKE ITO: There's a couple of quite not-typical ISP businesses, new businesses coming up in Japan, so, residential users number to a total number of address space usage in the future. So that kind of new thing needs to be looking at, I guess. And we are also aware that those sort of things is coming up, but not quite big enough to impact to the whole address management but we are still looking at the new things coming up for ISP users, new services. LEO VEGODA: I think I know what you’re saying, you're saying we can't know and predict the future. The thing is, we don't know if it's going to be incredibly successful or if it’s going to be Betamax, so there are questions to think about. RANDY BUSH: Three years ago we were making projections which also had very optimistic curves based on 3GPP, which was going to take over the world. I'm still waiting. I do know that if I came to the RIR with plans that were essentially marketing dreams, you would laugh hard. So I don't think I want to base policy on these modelling projections yet but certainly discussing the implications here, I think we really don't want to know what's driving now is merely ISPs and then devices. There's now use or application that's really going to make this thing explode. That's what's going to make a difference. TAKASHI ARANO: I also wanted to make a similar comment. I’ve got two points; future usage, not only for the [inaudible], but for the closed networks [inaudible]. Another thing, have a look at page 7. These are assumptions. In the Japanese ISPs case, assignment size to the household is not /48 but /64 is more common. LEO VEGODA: I agree with both you and Randy that this is just a small slice of the picture but a small slice we can try and peek at moment. I don't think we should go and make policy based on this. This is here to stimulate some discussion. But with this slide here, what we've said /48 per connection. The reason we've put that in is because those ISPs that we know provide IPv6 services at the moment aren't providing /48s to residential users who possibly only have one or two machines connected to the Internet. And I'm just basing this on the experience of the RIPE NCC service engine and what we're seeing there. If you're seeing /64s, maybe that's actually a better way to go, but that's not what we're seeing, so I can only base it on that. The requests we see, most people say they want to assign their customers /48s. Maybe they're just sort of reading and saying it has to be a /48 and maybe we need to look at the text in that policy and emphasise that it is a choice, it's a recommendation from the IAB but it's up to the LIRs or ISPs to develop a product that they want to develop. They’re not required to develop products based on a /48. TAKASHI ARANO: I think this is very important. My suggestion here is that I want to ask the Japanese community to report the /64s /48 assignment situation in Japan and analyse the reasons for choosing for this. Probably at this next policy SIG or next meeting. IZUMI OKUTANI: I think that's a very good point. I think if the outcome becomes that the majority of the LIRs in Japan thinks it's easier in their operations to assign /64 to their users, that might imply it's really difficult for them to meet the current v6 allocation policy. So I think it would be a very interesting survey to do. TAKASHI ARANO: Thank you very much. APPLAUSE KOSUKE ITO: My name is Kosuke and this is a kind of regular report and our IPv6 Promotion Council update, and this is the SIG report. This is not a v6 trial. This is IPv4 trial usage for IPv6. As we are running out of time, I'm kind of rushing the contents. I'll update from the last report and go through. We have done users' interview, the fourth interview, actually, at the beginning of this year. The current participating members are not changing at all since the last time. Broadband always-on connection service providers, and large VoIP/ADSL service providers and contents delivery service and also public space wireless access space. And, according to the interviews we have conducted, some members revealed that actual their IPv6 transition plan and this is really good to us, since this is one of the goals we are trying to make an experiment that the address space to be utilised for the users and something like that. Building to the wireless service providers said that they're connecting a mobile service for P2P voice chat and also area-dependent information and applying transition technology by 6to4 and also LIN6 they are going to make access points. And access points need to be replaced to be IPv6-enabled one by one, so this could be a kind of a tough job for them to make an adaption of IPv6 connectivity for their services. And for the VoIP service providers over the time, they are studying IPv6 connectivity over IPv4 services. The main reason is they think that it's much easier to start off an IPv6 connective service through the IPv4 environment. Then, they don't have to care about transition of v4 to v6 for the connectivity levels. They can continue the v6 application level service regardless of the connectivity level protocol changes. And also they are going to start the SIP/v6 IP phone terminals using those terminals they are offering a Voice Over IP services. They have started a technical examination for the service deployment in the near future. But they found that they need to replace the IP phone terminal firmware one by one for IPv6-capable and also needs to place a v4/v6 translator at the PBX gateway. So they need to have additional work to make their current Voice Over IP service to the v6 ready for that additional work and additional time to make it work. And the last one, broadband access service provider identifies what to replace for IPv6- enable. They pointed out these four major items - DSLAM, switches, routers and backbone routers. And some of them needs to be replaced and some of them are just OK. And then they found that, if they are going to make a change for the network-wide to IPv6 ready, they need to apply the changes more than 30,000 nodes, so it needs to have a time to change those kinds of nodes. But they are planning to start a pilot service from this coming June. They are starting with the tunneling and then make it to the dual step by step. [inaudible] They like to start with the IPv6 service but this network facility is not quite easy to change and also the device site is not quite fully ready yet. So they couldn't start it off with the IPv6 services but they are trying to accommodate those switching time to make the whole IPv6 service shifting to - I mean, shifting from the IPv4 services. And this one is quite a little negative sound, but it's their express that it seems to be a bit early to return IPv4 addresses utilised under this program because there might not be enough lead-in time to switching from the IPv4 to the IPv6 infrastructure with the whole thing and especially the user-side and also the infrastructure-side So maybe, as promised, the IPv6 Promotion Council may end the IPv4 side of this program by the end of 2005 but maybe we may ask this community to extend the term of this program at the next meeting based on the members' request. So please understand this point. This might be the sort of business effect comes into this decision. And the consideration - there's two points. There are two points. The members, participating members, have been able to convince the users of the value of the global addresses and also the ease of introducing potential new applications such as P2P, information exchange and IP-phone through this program. And so the IPv6 service becomes very reasonable to be introduced to the users and then the users see the value of the new, coming IPv6 area and also the see from the security point of view, on the built-in functionality of the IPv6 protocols, but need more time to make their network, whole network to IPv6-enabled. And IPv6-ready solutions are not so available yet, fully available yet in the wide variation, so much as we have currently IPv4 solutions lined up. So they are still a little bit costly. So we should be a little bit - needs the time, I don't know, the lead-in time to make them to the v6, whole thing moving to the v6. I guess that's all I'd like to say. Thank you very much. TAKASHI ARANO: Any questions? Any comments? Nothing. Thank you very much. APPLAUSE This is the end of the address policy SIG for the first day. Tomorrow, we will start the session at 11:00 am. Five topics will be discussed. Just be careful that this brochure had the wrong information. On page 19, it says that this starts at 2:00 but it's not, here at same place. And the Secretariat wants to say something about the reception. SAVENACA VOCEA: Thank you, Arano-san. First of all, I'd like to once again refer you to the onsite notice board which is available for people to use during the meeting, wherever the meeting is held, the agenda items, also the papers that are available in the website. There's also a Jabber chat service, a chatline that you can use to also request your colleagues back at home to also enter the meeting, also if they want to ask questions to be asked at the meeting so you can do that. Lastly, for this evening, APNIC is hosting a social event. You are all required to have a ticket for this. If you haven't requested that, you can come and see me today. The buses pick up from the front of the hotel at 7.00 pm tonight so I look forward to seeing you all at the Beach Hut at the Mines Beach Resort and Spa. TAKASHI ARANO: Anything else? OK. Thank you for good presentation, good discussion and cooperation. Thank you very much. APPLAUSE