Policy SIG, Wednesday February 25, 2:00pm-5:30 pm ARANO: This is the Address policy SIG. Welcome to this Policy SIG. OK, this is a history. This is the ninth Policy SIG. This is the agenda of the three sessions. We changed the order of the presentation like this because, tomorrow, we will have another session IPv6 summit, so IPv6 issues will be presented today. First - the introduction which I am doing now, which is the action item check. The first speaker should be multiple discreet networks by Norman Hoy but I can't find him. I don't know him. Please identify yourself if you are here, OK? And second is the IPv6 allocation to v4 network. Then we may have break. And, if we miss the multiple discreet networks proposal, probably 'IPv6 allocation to closed network' should be in the first session. The IPv6 guideline, LIR IPv6 requirement, updates of IPv6 address experiment in JP - this is the first day. The second day - the introduction of Doug Barton, he is the ICANN president - the IANA president, I am sorry - the IPv4 minimum allocation size and then the recovery of address space, the subsequent allocation in DSL/cable guideline and the "NAT is evil" talk. OK, this is the agenda for today. On how to proceed this SIG. We don't have a lot of time and probably, as usual, we may - I'm sorry, we will not have enough time and we will run out of time. That's usual. And so short and succinct presentations would be very much appreciated. I would like to ask you to leave more time for discussion, not for presentation. Any comments are welcome. I would like to hear from as many kinds of opinion as possible. This is the Policy SIG for the Asia Pacific. That means there are many non-native speakers so I am and please speak slow and easy English, please. Also, the onsite notice board will help you to understand the contents and the discussion - like this. Do you have any questions about the agenda or any comments on the agenda? Any requests for this agenda or anything? It is OK? OK. They are the open action items since previous times. Action item add-15-002 - "Secretariat to refer discussion of signing the DNS root to the DNS operations SIG." ANNE LORD: It's been done. TAKASHI ARANO: It's been done. Next - "The Chair will circulate the draft charter to the mailing list for further discussion." I did, but no discussion, unfortunately. Next action item, 16-002 - "Secretariat to prepare implementation of policy development process proposals as agreed, subject to final endorsement according to the policy development process." ANNE LORD: It's been done. TAKASHI ARANO: It's done. OK. If you have a question about these action items, please raise your hand or go to the mic and say something. You can stop me. Next action item is 16-003 - "Secretariat to prepare implementation of document editorial proposal as agreed, subject to final endorsement according to the policy development process." ANNE LORD: It's been done. TAKASHI ARANO: It's done. OK. Next, 16-004. "Secretariat to call for the formation of a working group to draft IPv6 guidelines." It's done. OK. Next - 16-005 - "Chair to circulate IANA to RIR IPv4 allocation principles document to mailing list according to policy development process." I did, I believe. Next - 16-006-"Chairs to initiate discussion on mailing list relating to preferred IANA to RIR IPv6 allocation size." I did, but no discussion so far. Next action item, 007, "Secretariat to prepare implementation of the agreed parts of the IXP proposal, namely definitions and routing restriction amendments, subject to final endorsement according to the policy development process". ANNE LORD: Done. TAKASHI ARANO: Done. OK. Action item 008 - "proposer to resubmit revised version of IXP proposal dealing with remaining proposal elements, such as fee waiver..." but it's not done. Is Bill Woodcock here? No? Do we want to keep this action item as it is or we throw away? ANNE LORD: I think we'll follow up with him. TAKASHI ARANO: OK. We will follow up. Next action item-009. "Secretariat to prepare implementation of the historical resource transfer proposal as agreed, subject to final endorsement according to the policy development process. There is a recommendation that the policy document should clarify that existing resource holders will be able to still update their resources as previously." ANNE LORD: Done. TAKASHI ARANO: It's done. That's the end of action item check. Is there any question or something missing? OK? OK. Let's move on the first item. It should be LIRs to manage multiple discreet networks under a single APNIC membership, presented by Norman Hoy. NORMAN HOY: Thank you very much. My name's Norman Hoy. I'm from MCI. I'm based in Adelaide and, as the slide shows, I'm actually giving a talk on behalf of Dawn Martin, who can't be here today. I believe she's probably on webcam watching it at the moment so hi, Dawn. The proposal is to allow people who have memberships in a number of countries to actually bring all of that under the one management because I'm sure, as most of us know, at the moment, those who are in multiple countries, it can get quite cumbersome having to manage a bunch of memberships with APNIC. The local Internet registries with multiple memberships with APNIC - you've got to log out half a dozen times, you're getting blocks of IP numbers that are sometimes difficult to manage and it affects the routing tables and the sizes of those routing tables and hopefully this proposal will assist in bringing that under control to some extent. The other problem is that accounting sections within companies that are in multiple countries - they're getting bills coming sometimes once, twice a month spread throughout the year and all of that adds to sometimes forgetting to pay the membership, getting friendly reminders that you owe some money to some people. Putting the proposal into a policy would allow members to manage their accounts as a single resource. Essentially, to sum it up before we get down into the major points of the proposal, is APNIC would give a Local Internet registry a block and that Local Internet Registry would then be responsible for managing that block across the country whereas currently that's what APNIC does for you. And the individual memberships of the country is having to constantly apply back to APNIC for IP numbers within those blocks. ARIN currently has something very similar. RIPE - they don't have anything in place at the moment. Nor does LACNIC. So the proposal is, when applying for additional address space from somebody like APNIC, new networks who apply for the additional space must show greater than 50% utilisation of the last block that's been granted. So, if we've got, say, a /16 or something like that or an organisation's got a /16, 50% of that has to be utilised before it can go back to APNIC to ask for another one. That's currently, I guess, something that APNIC does. The organisation must not issue any additional address space to a discreet network unless all of the blocks sub-allocated to that network show greater than 80% utilisation, individually or as a whole. The organisation must not sub-allocate a CIDR block any larger than the current minimum allocation and, although it's currently down there as a /20 for APNIC, I think there's a proposal before the group to actually, I think, reduce that down to a /22 but - sorry, a /21. But essentially what we're saying is the Local Internet Registry or the organisation that might have the membership in a number of countries would mimic or follow whatever APNIC's or the Regional Internet Registry's policy is. The organisation must not sub-allocate any additional CIDR blocks any larger than the current minimum. Again, that's to be a /22, to an existing network, unless the previous growth rate for that network indicates that it is likely a CIDR block would be requesting it. I mean, it's pretty pointless being allocated a /20 if, two weeks later, you're asking for another one, so you might start looking for /19s. When sub-allocating a block larger than the minimum size to an existing network, the Local Internet Registry should use the smallest allocation possible out of the larger reserved block. So, again there, you see the Local Internet Registry's doing pretty much the same as what APNIC is doing now, or the Regional Internet Registry. This requirement is to reduce the number of routes that the Local Internet Registry will announce from that autonomous system. The LIR must also follow the guidelines of RFC 2050 or its replacement, which is currently what - which is essentially the guidelines that APNIC have now. LIRs with multiple membership accounts should request that this policy apply to them. So in other words, it's not compulsory. The changes we're asking for is on a voluntary basis so that, if organisations that operate in multiple countries continue to operating the way they do now, then so be it. But certainly if this policy is implemented, what it's going to do is that, from my organisation's perspective, for example, it's going to reduce the requirements - we won't be laying anybody off, because we don't have enough to lay off - but it will reduce the workload of the people that are currently looking after those blocks and also help to save some money from the accounting perspective. The LIR must keep detailed records of how it has allocated not just the discreet networks but also any sub-blocks it has in reserve. So, in this LIR's case, we moved in to India and we had a large block we were using to manage the whole Asia Pacific region and we reserved part of a /20 for India, we would need to allocate all of that and put it into the registry so that people knew what was going on. An assignment window will be assigned to the LIR and will need to be followed for the entire network. Second opinion requests need to be sent to APNIC for review. So, if it was to change - I think currently it's a /24, is that right? For our organisation anyway. If we needed to increase that, then we would need to come back to APNIC and make sure that it's OK. And, of course, the fees. The IP addresses from all the combined resources would be taken into account when assessing the membership tier for that organisation. I guess I recognise that APNIC may need to reassess their policies therefore because what this could do is create some fairly large organisations within APNIC's books and so APNIC may want to re-examine some of their fees for the larger networks, but I certainly feel that there's the potential for some savings there, for us anyway. If the proposal is implemented, we're proposing three months for APNIC to get their systems in place and also, I guess, from anybody that wishes to opt in to this to look at it and do something about it. As I said, I'm speaking as a proxy for Dawn. I hope I did alright for her. Ask me some questions if you like. I'll hopefully answer them. GEOFF HUSTON: I'm trying to rephrase this so that I can understand it better. In my head, the way I've rephrased what you're asking for is you're asking for a single membership, a single entity, to, at their discretion and only at their discretion - no one else's - at their whim, to be able to open up multiple allocation windows. NORMAN HOY: No. GEOFF HUSTON: Well, I don't understand the point of difference because when I listen to what you've said, you want to treat it as a single entity with all the holdings taken into account, you want to subdivide your allocations into various themes, countries or cities, subdivide them at will using a mechanism of your devising, no one else's, and have allocation windows applied separately to each of those subdivisions that you've declared. So I'm not sure that we're saying things differently here. NORMAN HOY: OK. Certainly, if we were to go into a new country. GEOFF HUSTON: But countries of your choosing. NORMAN HOY: That's certainly part of the policy change, yes. If we were to open up an allocation window in a new city or country or whatever it might be, then we would allocate that out of a block that APNIC had given us. GEOFF HUSTON: For that particular thing so would you see this as beneficial to the overall routing system and aggregation of the address space if this was used across the entire region at levels that might be as low as apartment blocks? NORMAN HOY: If you had everybody in the apartment block wanting to do that, you could have some difficulty. However, certainly from our perspective in multiple countries, I see it as an advantage to the routing system. GEOFF HUSTON: My comment is that, in the proposal, I don't see the word 'countries'. I see a more generic way of describing what you’re after. Maybe I'm applying a reduction ad absurdium to your proposal, but nevertheless, if we accept that policy phrased the way it’s said, then it could be applied at a level of granularity so that, every time I opened up a new POP, I'd open up a new allocation window and effectively at no financial penalty because of the way the fee structure works. And if that were going to be true, and I could simply just open up window after window after window, and I’m not seeing, if you will, a natural tendency not to do this in your proposal. NORMAN HOY: I suggested that may need to be re-examined. However, I don't see an organisation within a country having multiple memberships with APNIC. I certainly do see an organisation having multiple memberships with APNIC for the different countries that they are in. GEOFF HUSTON: But you're asking in the LIR proposal that it's really just the LIR and the fee is based on aggregate so it really becomes just one member again. NORMAN HOY: OK, so if we want to argue the definition of an LIR, I'm happy to do that. GEOFF HUSTON: No, I was taking it at a more generic level and if this is applied and if we all do it and open up arbitrary windows at any level of granularity... NORMAN HOY: That would cause a problem. I don't disagree with that statement. If what we want to do, however, is take this one step further and define an LIR for the policy, I'm happy to do that but, certainly, from my perspective, what I see is multiple memberships and I think that becomes rather unwieldy. Yes, we have seven memberships with APNIC currently because of the different countries that we're in and that might grow. From a routing perspective, I cannot aggregate within my single AS those blocks because not all of them are continuous. There's a whole queue lining up to get at me! GEOFF HUSTON: I must admit, for the record, I don't see this as being in the interests of all of us. I think it needs more refinement. Q. I'm Izumi from JPNIC, and we have the same situation as well. I thought this proposal was really interesting and we addressed this issue in a different way. I thought it might be of interest to share with others as well, and what we do is we allow members to have a single contract with JPNIC, even though they have independent networks. By independent networks, we defined them as having a different AS number so if, like, an organisation runs networks with, for example, three different AS numbers, then we consider them as three independent networks and we give them separate account names and - in terms of address management, it's going to be managed as though they are just a single independent organisation. So we look at the utilisation for each network. For example, if an organisation have three independent networks, A, B and C, then we just look at the utilisation of network C, if network C needs subsequent allocation. So we don't really look at the utilisation rate of networks B and A when network C needs additional address space. And the point that Geoff has pointed out regarding the, you know, it might cause some risks of ISPs creating new POPs. We don't have that because we only restrict it to create new accounts when they have an independent ASN so we don't allow that to happen just because they create a new POP. I thought it would be good to implement a similar policy. One thing, just out of curiosity, is that if you apply that you have to meet the utilisation of 80% for each of those networks, I think it will impose a really big restriction on the size of the LIRs. Because I think, if each network is independent, there would probably be cases where network A has lots and lots of customers and network C doesn't have so many customers, and network A needs subsequent allocation but, because the utilisation rate of network C is really low, it can't meet the utilisation of 80% as a whole, so we don't do if that way. We just look at the utilisation of individual networks. That's all from me, thanks. NORMAN HOY: OK, just on that. I guess what we're looking at is out of the initial block, we're saying that it's 50% total, I think. It must show greater than 50% out of the last block routed. And then 80% greater utilisation in individual networks. IZUMI: We don’t consider it a sub-allocation. JPNIC makes direct allocations to each distinct network. It's only in terms of contracts that the organisation has a single contract. I think, according to my understanding, your proposal would be like APNIC makes direct allocations to the organisation as a whole and this organisation will sub-allocate to each of those district networks, right? Ours is different. JPNIC makes direct allocations to each of the discreet networks. I hope my point is clarified. RICHARD JIMMERSON: We have a similar policy. It was introduced in our community a few years ago and it was ratified and has been implemented for a few years. When it was originally introduced, the intent of it by the author was to prevent organisations from having to have multiple accounts with ARIN and pay multiple fees for the multiple networks when they did have a need for discreet networks. That didn't help many organisations when we implemented this but it seemed, over the years, that organisations are looking to this policy and the way that it's written. There are some implementations where we have concerns. Organisations are trying to use this more as a way to move away from the 80% figure. For some organisations, it's very difficult for them. They come to ARIN and try to demonstrate 80% utilisation of the address space they've used to date, including the previous block. Some organisations seem to be using this policy as it's written and as it's stated on our website to create some, you know, distinctions amongst their networks, inside their company, not because it's necessary to avoid fees or to have a single account with ARIN, but to have a avoid the 80% utilisation problem that they seem to be having. And there have been some proposals introduced in ARIN region recently that talk about moving away from the 80% figure. And one of the reasons that it was difficult, I believe, in ARIN region perhaps more than other regions - we have organisations coming in, they have to come in every three months in the ARIN region. They only receive allocations for a 3-month time frame and every time they receive allocations, they're building a next request it seemed. One policy was ratified here in the last couple of months that says ARIN can make allocations up to six months and that might help out with this as well. But I do see organisations, or we do see organisations, using this policy to avoid the 80% figure more than we see them using it to avoid having to open up multiple accounts with ARIN. NORMAN HOY: Do you see anybody wanting to use this policy to get down to building levels by any chance? Sorry. RICHARD JIMMERSON: It doesn't seem that it would help reduce the number of routes in the routing table because the way that we’re implanting this is that, say an organisation has one account with ARIN and they have four discreet networks with ARIN, the way that we're managing those discreet networks is as if they were completely separate accounts. They get their own address range and they get their own reservation, each of the discreet networks. We're still talking about four different prefixes that are growing into a reservation and it's not being aggregated into one. RANDY BUSH: First of all, we have two general areas of discussion. One is the administrative problem and the other is the engineering problem. I want it speak to the second one. This is a really good illustration of the tension we have in many of our policy decisions between aggregation and utilisation. As a backbone engineer, I want to take one routable prefix and attach it to a POP because, if that POP gets partitioned from my network, that prefix is still being announced as a whole prefix. But that causes me to have the problem when I go back to get more allocations of having to show, for each of those POPs an aggregate utilisation that justifies my getting more address space. I don't think there's a magic solution. I just want to point out that is the basic tension we have here at the engineering level, not at the administrative level. Izumi-san is talking about, first of all, separating the administrative problem by letting you have one account and then dealing with you separately for things. But what if is that separately - allocations that must be judged individually or in the aggregate. That's the problem that Geoff brought up. And I have no magic solution and I'm not arguing either way but I just want to point out, when we get down to the real basics, it's aggregation and utilisation. PAUL WILSON: Paul Wilson from APNIC. I'm not going to comment on the particular proposal, except that the intention of the proposal seems to be to make quite reasonable allowances for the needs of large networks and I'll just point out that at the last meeting, there was a proposal with the same intention which was quite different and it had to do with the application of the HD-Ratio to IPv4 address utilisation. The point of the HD-Ratio, of course, is that, as the overall address space gets larger, the requirement for utilisation of that block becomes less. The reason for that is that, with a larger block, you have a more complex network, you have a much harder time in utilising that larger network block at the same 80% level. So the fact it is an HD-Ratio-based utilisation requirement represents a more consistent level of technical difficulty in utilisation. I would just point out, in case it's not known to the people who proposed this particular proposal that there is an alternative which is still on the books. It was not approved at the last meeting and there's no further action being taken on it at this meeting but it is still out there. LEO VEGODA: You said that we don't have a specific policy for this at RIPE NCC and you're right. We don't have a specific policy. The way it works is that you get one allocation per account but, occasionally, people want to merge their LIR memberships into a single account and we let them do that and sometimes they want to split up various allocations from one LIR between other LIRs and we let them do that. But you only get one new allocation per account. That's how it works. We've not had anyone propose something similar to Paul's HD-Ratio proposal or similar to this in our region as yet. TAKASHI ARANO: Any other questions/comments? Do we want to take a vote or do we want to...? NORMAN HOY: I don't know where you want to go from here. I guess I was interested to hear the comments today, particularly as, up until now, although it was posted, we didn't receive one e-mail. So I'm happy if you want to take it and put it to the vote or take it back to the executive. I mean all I can do is put the policy up, put the proposal up. It would certainly seem that certainly all the speakers anyway were not in favour of this. TAKASHI ARANO: I've got a question. The proposal about the multiple networks, discreet networks, when purchased by the same operator or same management, right? So that's very different from the - how do you say? - confederation idea - it's very different. Just one comment. The second thing is that, - did you hear my comments? Should I repeat? My question is that - whether his proposal is about separate or discreet networks operated by one single management or several management bodies. But his answer is just one. That's one point. The second point - I can see that, I can understand this problem. Can you solve this problem by the operational issue as an operational issue? I mean, APNIC can treat these kind of things without such kind of policy, I believe. What do you think? ANNE LORD: Anne Lord, APNIC. I think it's a good comment Arano-san. But I can comment on what was wrong with the confederation one which, as I see it, is actually something similar to this in that you want to have discreet pools of address space that run at different utilisation rates under a single membership and one of the problems with the confederation model was that it became very complex to administer, it was an administrative problem from APNIC's perspective. Part of that problem was that there was no actual definition - this is the problem that Geoff alluded to I think - there was no real clear definition of what a multiple discreet network was. You get a situation where many networks are being opened up for individual discreet pools and they're just gathering pace. And that was one of the problems I think in trying to manage the confederation model. And I see this as being - while understanding the problem, I see this as having a similar difficulty in this definition of what is a multiple discreet network. And JPNIC has tried to define it with an AS and I think that's reasonable but it needs to be clearer, I think, within this document. TAKASHI ARANO: You want to take a vote? OK. I'd rather take a vote of all of you. RANDY BUSH: Thinking about it as an AS. An AS is something I use for a technical routing policy and I'd rather not bind those decisions to have large administrative consequences. NORMAN HOY: I think what we're getting down to now - it's sounding to me as if the proposal itself is not necessarily that bad. It is the definition of what we would regard as an LIR and the possible abuse of that. Would that be a fair description? And so therefore I should take this policy away and come up with a definition of an LIR that's acceptable. ANNE LORD: I don't think it's a definition of an LIR. We've got definitions of an LIR in the policy document. It's the multiple discreet networks that we're not clear about. GEOFF HUSTON: She said it so... NORMAN HOY: Certainly that part of the proposal and the central part of the proposal is that an LIR would get a block and then they'd be responsible for sorting it out as Geoff's alluded to - going into another country and not coming back to APNIC or whatever. GEOFF HUSTON: You are using the option of, if you will, reconsidering and redrafting. It would certainly be helpful, I think, for some of us. At least it would be helpful for me, to understand why alternative approaches in large deployments that use the HD-Ratio would be inapplicable to this kind of envisaged situation. Because, in my understanding of the theory and practice behind the use of an HD-Ratio, it actually encompasses some of the structural tendencies that tend to occur in large roll-outs. From your description, it would appear to be a relatively large roll-out. Default thinking would be surely the HD-Ratio would allow you to use a block and actually slice it into various areas and consider the total in terms of its HD efficiency, which would allow you to achieve individual objectives in each of your areas of business. And, if that's not the case, perhaps it would be good to understand why it's not the case and why you believe this particular policy proposal is a better way of solving a problem. NORMAN HOY: Yeah. At the moment, what we do is we apply on a per-country basis for a block. We have situations where different countries are growing at different rates. GEOFF HUSTON: That's your current operational practice internally but, as a point of policy in the APNIC sort of area, that's not totally germaine to the issue and. As I said, I think it would help the proposal to at least understand why the HD-Ratio would be inappropriate for this kind of purpose. NORMAN HOY: OK, well, I'm unfamiliar with the HD-Ratio proposal. GEOFF HUSTON: Perhaps it would be worth checking through with that and seeing why it wouldn't suit your needs. TAKASHI ARANO: It is OK? For you, I can take a vote for the proposal as it is but probably not many people. Can I ask you to rewrite the proposal, considering the alternative of the HD-Ratio or as something else. Thank you very much. NORMAN HOY: Thank you everybody for your time. APPLAUSE TAKASHI ARANO: Next speaker will be Paul. The title is "IPv6 allocations to IPv4 infrastructure". PAUL WILSON: This is a proposal about the issue of IPv6 allocations to organisations with existing IPv4 infrastructure. This is - it's not a new policy proposal as such, it's a proposal for the clarification of the existing IPv6 policy in the area of how addresses are allocated to networks with existing v4 infrastructure. Because it's a proposal to clarify the policy and replace some of the words of policy, so hence it's here as a proposal. The background of this policy or to this proposal is that the IPv6 policy that we have actually does allow existing IPv4 infrastructure to be considered during the process of evaluating IPv6 requests or the process of requesting v6 space, and this is because there is an assumption in the policy that existing IPv4 networks are going to transition to v6 at some time in the future. At some time in the future without saying when, there is an overall assumption that v6 is coming and that the transition to v6 is more or less inevitable for v4 networks. It seems reasonable that an existing v4 networks should receive or should qualify for address space sufficient to actually support its transition to IPv6 at some time in the future. In the existing APNIC-089 document, which is the IPv6 policy document, section 4.4 is the section that addresses consideration of IPv4 infrastructure and it says that where an existing service provider requests v6 space for eventual transition to v6, the number of customers may be used to justify a larger request, rather than the minimum request, which may be justified solely on an IPv6 deployment plan. In addition, this slide shows the associated clause in the policy document about the initial allocation slides and it basically just says that the minimum allocation, the initial allocation of a /32 and organisations may qualify larger than a /32 when they request IPv6 address space if they submit documentation that justifies that request. It does say that that allocation size can be based on the number of existing users and the extent of the infrastructure. The problem we have with those word in the policy document is that they have not been well understood and the actual procedure is not very clear. What does it actually mean that v4 infrastructure will be taken into account or that customers of existing networks and infrastructure will be taken into account . It's just not very clear, with the result that the policy hasn't been used so far in the APNIC region. So the motivation for this proposal here is to clarify that policy and procedure, specifically to facilitate the deployment of v6 networks and the transition to v6 in this region. So the proposal is simply to change some words to clarify the policy, and in section 4.4, the important change is highlighted here in yellow. What it says where an existing IPv4 service provider requests v6 space for provision of existing services via IPv6, the existing IPv4 infrastructure and customer base will be evaluated and an IPv6 allocation will be made which is sufficient to allow the network to be addressed using v6. So that says very clearly that if you've got a v4 network and if you’re expressing the intent to transition eventually to v6, you should have enough v6 address space provided to you to address that network using IPv6. At the same time, there’s the associated section 5.1.2, which is about exactly how much address space is allocated under these circumstances, and I've proposed to reword that as well, specifically on the next slide. It says qualifying organisations may request an initial allocation greater than /32 by submitting additional documentation to justify the request, and in particular this may include comprehensive documentation for planned infrastructure, or, in accordance with this section 4.4, a description of the existing IPv4 network which is to receive v6 space. In either case, the allocation which is made is one which should fulfil the calculated address requirements in accordance with the HD-Ratio policy, and that's an aspect of the policy which has not been clear either in terms of the size of the allocation which should be made to satisfy a v6 address requirement. So I've got a couple of examples. In particular, in the case of v4 infrastructure, specifically, a customer network of any size in the IPv4 network should qualify for a /48 which is simply in accordance with the IPv6 policy. A dial-up customer requiring subnets should also qualify to receive a /48 and an ISP POP to qualify for a /48. Now, remembering this is all talking about existing IPv4 networks. There's also a cause here that says existing devices requiring a /32 should receive addresses in accordance with RFC 3177, which is the IABIESG recommendation on assignment sizes. So specific examples - if your network has 5000 customer sites, it has 20,000 dial-up users who will be requiring subnets and has five POPs, then you would, using the previous table, find a total requirement of 25,005 /48s and that's a simple calculation. Now that request justifies a /29 according to the HD-Ratio. I’ll just skip to the next slide, which shows in the highlighted line here, that if you have 25,000 /48s, then you're actually qualifying for a /29, which has a utilisation threshold of 37,641. The second example is a larger network, 25,000 customer, 50 POPs and that gives a total of 525,050 /48s, and that justifies, according to the HD-Ration table a /24. The issue of RFC 3177 assignments should probably be addressed here. That RFC specifies that /48s are to be used in the general case except for very large subscribers, and of course that would apply here as well. A /64 is supposed to be assigned when it’s known that only one subnet needed and a /128 when exactly one device will be connected. So we may have to have a look at how many /48s might be justified in the case of infrastructure involving such assignments but I would point out we are still talking about IPv4 networks and there are not many networks which appears where there would be devices that would qualify for /128s or /64s. However, we would still apply the same utilisation policy and same RFC 3177-based policies. So for instance, if you were assigning /64s to a large number of devices, then 7132 of those /64s would constitute utilisation of a /48 and that again is in accordance with the HD-Ratio. So again, an example, if your application in your v4 network involves devices qualifying for /64s then for every 7132 of those you qualifying for a /48. If there are devices requiring /128s, these are individual devices with no subnetting or other capabilities, then we can look at those, but they are not really the target of this particular policy proposal. The existing IPv4 networks, which are the likely subject of these, do not involve such infrastructure at this stage, normally. So this policy was proposed on January 23 in SIG Policy. There was some feedback which requested to modify the language to make it clear that this is an optional when applying for IPv6 and of course, that would be the case - it is one set of qualification criteria, if the requester wishes to use them. The second request was to clarify that the number of IPv4 customers is also counted and I think that should be clear enough, I think, considering the examples I've given. The customers and customer's address requirements which are counted. And also requests to modify the language so that no commitment to a complete transition to v6 is actually required at any particular time, and that was the intent, and it was felt sufficient to simply ask the requester to verify that they do intend to transition in the future, and that will qualify them for address space under this policy. And NIR considerations - if this policy's approved, it would be a regional policy for the purposes of the APNIC policies and procedures and therefore applicable to all NIRs. And its implementation would follow the normal policy process, which is EC approval after the 2 month comment period. Because this is an IPv6 policy, we've got to consider the coordination issues and the intent of the RIR staff in particular to coordinate policy changes. So we would continue to coordinate with respect to this particular issue with the other RIRs and perhaps present this policy proposal at the other RIRs’ policy meetings if requested. So thank you very much. I'm happy to answer any questions. TAKASHI ARANO: Any questions? IZUMI OKUTANI: In the example you said that you showed how it works with IPv4 network and how we can interpret it in terms of IPv6 networks. That's it, yeah. Is this just examples of how APNIC hostmasters will interpret it when they receive the evaluation request to request for IPv6 address? Or, regardless of the actual operation, or is this a suggestion that for a single customer network a /48 should be assigned? Let me explain. I think there are some cases where ISP actually want to assign to a /64 to each customer. I'm wondering if that would be considered as a /48 assignment in evaluating the request regardless of the actual operation or this is just to give them the reference - you can assign a /48 per each customer. PAUL WILSON: That's a good question the examples, I believe these examples follow on from the policy document that we already have that says simply that if you have a customer network, then it's expected that you assign a /48 to that network. So, that is a policy that exists already. It doesn't need to be stated here. The purpose of the slide is simply to say that in terms of an IPv4 network, a customer network, a customer assignment is represented by a block of address space of variable size, depending on the size of the assignment. But regardless of the size for each of those it's expected that in accordance with the policy that exists already, a /48 would be assigned. If this policy being approved resulted in an ISP making a request and receiving /48s for every customer network, and the ISP subsequently assigned /64s, I think they are… it depends on whether they've changed their plan from what they might have represented during the request process. I would say that that is the sort of change that happens in the normal case anyway. All that these policies do is ask an ISP to declare their intention and plan if that plan changes afterwards, then that is a natural course of action. I don't think there's any policy in which ISPs are required to exactly follow exactly the plan that they've put forward. IZUMI OKUTANI: What is the plan in the first place to assign /64s. PAUL WILSON: If they are only requiring /64, then I don't see why they should be assigned more address space than the address space they require, so it depends on how they ask the question. They are entitled to receive, under this policy, a /48. They can ask for a /48 because they're entitled to do that. IZUMI OKUTANI: I think that will be my second question after this. Q. When I recalled a very basic background when we implemented 4.4, was, this is early stage to deploy IPv6. Existing IPv4 ISP operators may not be receiving current policy conditions... Under the current policy condition, they may not be receiving enough address space to prepare themselves for future IPv6 planning as of the services. So, we think that if they are existing operators, they can at least receive a /32 to start it off. That's the very beginning - the initial reason to implement the policy. But however, if you are rephrasing - rephrases to understand phrases for 4.4 combination, this might be a little bit different from the original contingency for 4.4. And also it sounds like a little bit against the principle of the ideal for allocation, basic principles such as assignment or allocations is down for necessity basis. No potential basis. But if you're counting the existing IPv4 and just mapping that to IPv6, then that's just a potential basis that you can allocate IPv6 space. Then there's no concrete reason to use up the huge addresses. So we need to consider those two things for future management. I'm not against to changing to what you're proposing, but I'm a little bit anxious about perception of the policy documentation. Within the documentation there might be some contradiction there between the principles and existing operations. RANDY BUSH: I believe I have trouble with the word transition. I think IPv6 and IPv4 are now and will continue to be for a long time in a state of co-existence. I do not believe in a high correlation between an ISP's utilisation of IPv4 address space and IPv6 address space. I believe that you may, as an RIR or LIR, have some level of relationship, trust or engineering understanding based on their history of IPv4. But I don't think - I think binding IPv6 allocations size to IPv4 utilisation will cause in some cases under-allocation and in some cases over-allocation. And I think in both spaces, they should justify what they need and get what they need. Does that make any sense at all? My friends from China are going to need and be able to justify large chunks of v6 space, and yet their v4 space has been very conservative in comparison. Whereas, there are small ISPs, who will give you a grandiose argument... I think I’ve made my point. PAUL WILSON: Yeah, I’ll just point out that the proposal does not suggest one to one correspondence between v4 and v6, for instance, replacing every /32 with a /48, for instance, because I think such a proposal would be exactly a case of what you said, where some of those assignments would be excessive and some would be inadequate. But I think where you are analysing, looking at the use of the v4 address space within an existing network, all this proposal is saying is that there is an existing network, here is an address space that wants to use IPv6 address space for that network, so let’s work out how much v6 space they need and give it to them. What isn’t addressed here is the question of NATs, and that’s a good point in a network in which every customer that has NAT may well not qualify under this policy. And that's something that we should add to the policy as well. RANDY BUSH: Your [inaudible] is pretty clearly saying that IPv6 space will be allocated based on the number of IPv4 utilisation, and yes, one case where a network is heavily networked, the opposite case is where [inaudible] routing used to be based on RIP and is a /16, or a /24 was being used from point to point. And there is an enormous amount of space and it isn’t being used! PAUL WILSON: That’s actually not what the policy says Randy, and there would be no provision for that allocation. RANDY BUSH: "An IPv6 allocation would be made which is sufficient to allow the network to be addressed using IPv6" - that’s saying, there's a picture of the network using IPv4, we're going to give it in v6. And I’m saying that the needs might be entirely different. PAUL WILSON: The address space will be allocated to the network using v6 according to the current IPv6 policy. And so a /16 that's used on a point to point link, what are you saying that would qualify for under the... RANDY BUSH: Sufficient to allow the network to be addressed using IPv6. PAUL WILSON: You seem to have an interpretation of the wording that you’re insisting on regarding, regardless of the explanation, and I still don’t see how this proposal would allow anything unreasonable to be assigned to a network where a /16 is used from point to point. I’m sorry, I don't understand. RANDY BUSH: Because that’s an enourmous v6 /16 space, and in fact I only ever have three users using v6. Which is sufficient to allow the network. PAUL WILSON: We're talking about another issue now. Point taken. DAVID KESSENS: Dave Kessens, Nokia. I also wanted to say it's about the needs of the customer... [inaudible] and this is not based on that. It's all about needs. If there's needs, people should get address spaces. It should be all based on needs. If somebody needs the addresses, they should get it, if they don't need it, they shouldn't get it. It's too vague. I doesn’t say anything, and I think that’s the problem. IZUMI OKUTANI: I think it's good because for those who prefer to be evaluated based on the v6 infrastructure, they can do that. This just gives them additional choice. For those people who plan to transfer the v4 networks into v6, it makes sense to evaluate the v4 networks if that's the case. Of course it's not going to make any sense if an organisation tries to construct v4 and v6 totally independent networks and base it on v4. It only applies to those cases where they try to have a dual stack network and it's based on v4 but they need v6 addressing. It makes sense to me. But one concern I have is the same as what was pointed out earlier. I think that we should make a clear distinction about those between those LIRs or networks that have received v4 assignments but have no plan - they might desire but they have no plan - and those who have the plan and they might not be realised at the end of the day, but at least they have the plan. We should make a clear distinction about this. Maybe this can't be addressed in a policy description. Maybe it's something that should be addressed in the guidelines document. And in my personal opinion, to make a clear distinction between the two, we should at least ask for when they plan to transfer to v6 network or some kind of time frame. This doesn't have to be accurate. They don't have to follow the plan. I think we should at least ask that to make that distinction. PAUL WILSON: Do you have a particular time frame in mind? IZUMI OKUTANI: Not really. I think as long as they provide some time frame then it should be OK. If they say 10 years later, I don't think it's too realistic but I'm not sure if we should define it or if it should be case by case. PAUL WILSON: So in the sense of this slide here it would be requesting v6 space for provision of existing services via v6 within a specific time frame according to a specific plan. Q. I'm from Singapore. My - I have experienced, I access on your website in China, I cannot access. I cannot access the website. I can't access anywhere. I really cannot access. I'm thinking a lot of the problem is from the blocks, too many blocks. So during this phase, can we consider the kind of user in different countries. And consider future potential use in a different country? So we will make IPv6 allocation more reasonable and more efficient? PAUL WILSON: With respect, I think that's a different matter. I think my understanding of your suggestion is allocations could be made on the basis of some projected need for the country, for the particular area. So I think that's probably something to be discussed in question time after or in any available time at the end of the SIG. I think it's a good question. Thanks. LEO VEGODA: We have actually had a request that was based on providing IPv6 connectivity to large numbers of existing IPv4 customers. And after we evaluated the request, we allocated them a /27, and the way we looked at this request was that I think it was probably a little bit similar to the way that Randy was thinking. We weren't saying how many IP addresses they have in IPv4. We looked at it and we said, we asked how many /48s - because they intended to assign each of their customers a /48 - how many /48s do you intend to sign over the next 18 months, two years? And they came up with the number. It was only a small proportion of their network. They were rolling it out on a test customer base. And we were like, "OK, that equals using the HD-Ratio, /27, so that's what we'll allocate for you". That's how we've looked at it when we've had a case like this. PAUL WILSON: You’ve described exactly what this proposal states. I don't see there's a difference. Thanks. The difference in this case, if I could just comment as I think in that case the RIPE NCC hostmasters have gone through a process that isn't documented in the policy. And perhaps because it’s not documented in the policy you might find that other ISPs who wish to do the same thing, may not understand that it's an available option. LEO VEGODA: I think it's not documented clearly. To be honest, I don't think the text of the policy document is particularly helpful to LIRs considering making requests. We had to spend a lot of time reading through the document and comparing sections of text, and we were spending a lot of time and we went through the document a lot of times. I think it was documented but it was just a bit inscrutable. PAUL WILSON: That’s exactly why I think in the case of this particular proposal changing the words is is quite important, where we had clear need for that. Thanks. Q. Why are the RIRs likely to assign very big chunk at the initial point? PAUL WILSON: I suppose because of long-standing dissatisfaction among ISPs with the slow start policy, and the slow start policy says, particularly under IPv6, it says we don't care what network you've got, we don't care what you've done in the past, we're going to give you the smallest available allocation and pretend that you know nothing about managing that allocation and wait until you’ve used it up before we give you anymore. So there is a history of dissatisfaction with the slow start policy where ISPs, quite justifiably in a lot of cases, believe that they have the expertise... both the requirement for a large block and the expertise to manage it responsibly. Q. That is why we have an automatic allocation mechanism in place. As long as they satisfy the HD-Ratio, and they have no additional questions to be asked, they can receive that block. If you combine with the sparse allocation mechanism, you can have next block to the previous allocated block, right? So, if they can start it from the /32, there is no - from my point of view there is no issues to increasing the others. At the moment they are necessary for the spaces going to plan. If we allow to give them a very large chunk at the initial point, RIRs or NIRs should check their utilisation for the future, how much they are following up from the initial point of planning. If they don't make it, we have to do something about this. So from this viewpoint, starting from the /32, increasing their allocated block or application block, will be much easier than giving them a very large space at the initial point. PAUL WILSON: I would anticipate a counter argument which is if you have a network that's large enough to require a /34 and you’reasked to first start addressing that network with a /32, then a /31, then a /30 and smaller and smaller blocks, even with the HD-Ratio, you've got a lot of fragmentation with that address block and your internal management of that address block is going to be unnecessarily complicated when all you wanted to do was address that network with a reasonable amount of address space in the first place. And you expressed a credible plan for doing that. So I still think we can do better in the case that a credible plan for addressing of that large a network is presented in the first place. ANNE LORD: I’d just add to that too, that in the case of the minimum allocation of IPv4, there's always been a case and provision for exceptions to that in the case of very large networks where what Paul's just said, that the initial allocation deployment wouldn’t be covered by that allocation size. That perception has always been there. IZUMI OKUTANI: Let me just point out what just been discussed. I can understand the concern, only when the plan is not credible and if their only desire, if it's just a desire, I can understand your concern. But I agree with Paul’s and Anne’s point that if the plan is credible enough, I don't see any reason to accommodate allocations larger than initial allocation size. And to move on to my point - I stated earlier that I have no particular comment about the time frame. I had some comments from guys from JPNIC here that to be consistent with the v6 policy, not based on v4, it says that 200 customers within two years, so maybe it would be good to say that they plan to transfer 200 of their customers within two years to be consistent. PAUL WILSON: Thanks. TAKASHI ARANO: Do you want to modify your proposal? PAUL WILSON: I think so. I think the particular suggestion could be easily accommodated within a new proposal which could be put out to the mailing list for comment within the comment period. TAKASHI ARANO: Another point, just one point. My observation is that this proposal is very good but your proposal is based on the assumption that all IPv4 customer improving their customer would subscribe with IPv6 with /48 block. This is very unsure, because the current situation in Japan is that most of Japanese ISPs, give whole customer to just a /64. That's very typical. This proposal does not. But assume that the /48 is a standard. An example of this is very... PAUL WILSON: Dial-up customers requiring subnets - the IESBIAB recommendation is that it receives a /48. TAKASHI ARANO: It would be just one segment in the future. That they should be assigned a /64. Whether it is in the policy, or in the guideline. This example should be in the guideline. Should be modified in such case? PAUL WILSON: I think so. Those examples are suggestions and interpretations of the policy and the guideline document is exactly meant to formalise those interpretations. I agree with you though there should be more detail there. TAKASHI ARANO: There is one suggestion to request that for the using of these addresses. With this modification - is this clear for everyone? IZUMI OKUTANI: In a timeframe or without the timeframe? PAUL WILSON: I think with the two years timeframe. TAKASHI ARANO: Do you understand the modified proposal? Is this OK? Can I take a vote? How many of you agreed with the modified proposal? Raise your hand. Thank you very much. How many of you disagree? And how many of you has no opinion on it or no idea about it? OK. Yeah. You have consensus. This is end of first session. The second session will start 4 o'clock sharp. Thank you very much.