Transcript: APNIC Policy SIG
Disclaimer
Due to the difficulties capturing a live speaker's words, it is possible this transcript may contain errors and mistranslations. APNIC accepts no liability for any event or action resulting from the transcripts.
1100 - 1230 (UTC+8) Thursday 4 March 2010
RANDY BUSH: At the door to the room, we're giving away documents on the procedure of the Policy SIG. The PDP, the policy development process. If you were staying in the room between sessions or something, if you would like a copy, just raise your hand and somebody will see that you get one.
SRINIVAS CHENDI: OK, welcome to the Policy SIG. I've got a note here to announce this one. One of our EC members, Akinori, he lost his digital camera, a Panasonic camera, and he'll be happy to get it back if anyone found it. Please hand it back to the APNIC Secretariat staff or directly to him, if you know him. That would be much appreciated.
And we have a couple of presentations that we missed out on last night at the social event because we know you're all enjoying the party, so we didn't want to disturb you. So we're going to do it now here. I would like to request Mr Paul Wilson to come up on the stage and present a memento to our Platinum Sponsor, Telekom Malaysia for supporting us and being with us here in KL for APNIC 29. Is there a representative from Telekom Malaysia here please that can come up on the stage? Thank you. Ladies and gentlemen, please give TM a round of applause for their support for APNIC.
APPLAUSE
And as you know, last night's social event was sponsored by Hurricane Electric and Google. So we would like to ask Martin J Levy if he's in the room to please come up on the stage as well as Jake Chin from Google.
Thank you, guys. Ladies and gentlemen, please give them a round of applause again.
APPLAUSE
And we have a couple of prizes so I would like to request Jake and Martin to stay up here on the stage. We also didn't do the lucky door prizes last night, so we're going to do it here. I hope you have your tickets with you.
(ALL) no!
Do we want to do it after the lunch break? Maybe you can go and get your tickets, if you still have them with you! Jonny is showing his ticket! Maybe we'll do it after the lunch break.
OK, you keep hearing this noise, right. So we have two remote locations connecting to the Policy SIG today. One is from Bangkok where our future meeting is, APNIC 30. And one connection coming from Laos, so we're going to bring them live. If they have any comments, they'll be asking through the polycoms that they have on the other side, and I'll flick them on the screen. But before that, please remember, if you're coming to the microphone to speak or to make a comment, make it slowly and state your name so that our remote users can hear you clearly or they can read the transcript and see who is making the comment. Now I would like to pass on to the chair to open the session.
RANDY BUSH: Hi, I'm Randy, IIJ. You already heard me too much today and yesterday, and here are my co-chairs, Terence and Ching-Heng. Due to time issues, we're going to be briefer than usual; maybe this is a feature and not a bug. Terence is going to cover the open action items and Ching-Heng with the overview of the policy development process. I'll do a very quick summary of the proposals presented today and then we will move to the proposals.
TERENCE ZHANG: Good morning everyone, I'm Terence Zhang from CNNIC. I'm going to run through quickly the list of open action items from the previous meeting and the current update of these open action items. The first one is pol-28-01: pending approval at each remaining stage of the policy proposal process. APNIC Secretariat to implement proposal prop-073, simplifying allocation assignment of IPv6 to APNIC members with existing IPv4 addresses. The current update is that the policy is implemented on February 10, this year.
Next, prop-078. Reserving /10 IPv4 address space to facilitate IPv6 deployment, returned to authors and the mailing list for further development. The current update is Version 2 of the proposal to be presented in this Policy SIG.
The next proposal, prop-076, requiring aggregation for IPv6 subsequent allocations, returned to the mailing list for further discussion about the plan for aggregation component of the IPv6 allocation criteria. The current update is that it is withdrawn by the author. It is a proposal which is removing aggregation criteria for IPv6 initial allocation is submitted. And will be discussed in this Policy SIG.
It's moving too fast! OK, the next one, pol-28-06, pending approval at each remaining stage of the APNIC policy development process and the global policy development process. Because this is a global policy, it is required approval by all RIRs. The IANA to implement prop-074. IANA policy for allocation of ASN blocks to the Regional Internet Registries. The current update is that it is endorsed by APNIC EC and pending remaining steps of the global policy development process.
And the last action item, pol-28-07, pending approval at each remaining stage of the policy proposal process. The APNIC Secretariat to implement prop-075, ensuring efficient use of historical AS numbers. The current update is that the policy is implemented on February 10, this year. That's all for the open action items.
CHING-HENG KU: Good morning, everybody. I'm Ching-Heng Ku, and I will quickly brief the policy proposal process. Here is the Policy SIG charter. The charter is to develop policies and procedures which relate to the management and use of Internet address resources by APNIC, NIRs and ISPs within the Asia-Pacific region. If you have any comments, you can send the comments to the mailing list.
And the policy development process is open, transparent and bottom-up. We have, there is one month policy proposal discussion. Here we are with the APNIC meeting and tomorrow, there is the AMM meeting, and after the AMM meeting and the proposal makes consensus, there will be eight weeks' discussion in the mailing list. After the EC endorses the policy proposal, there is a minimum of a three month period of time for the Secretariat to implement the policy, so this slide shows the policy development cycle. So, please remember and please be kind and respectful to all opinions. Thank you.
RANDY BUSH: OK, I'm going to try to summarize the proposals that we're going to discuss today. The summary is going to be a bit briefer than usual, but the purpose is to try to get everybody aware so that at lunch, so we're orientated and at lunch, you can discuss them, etc. The first one is prop-077 which is, the problem it means to address is that the old IPv4 transfer policy. This was the policy where, you know, I was acquiring a company, these kinds of things, was designed to encourage holders with no relationship with APNIC to bring their resources in to the APNIC community framework. OK, the new policy for transfer, prop-050, and allocations directly from APNIC require justification. Whereas the old one, did not. So this proposal suggested that recipients of legacy address, when they went to transfer in to APNIC, they should justify their need.
so OK, by either the prop-050 justification criteria or the existing v4 allocation criteria. At the last meeting, we returned it to the authors for further consideration because prop-050 was passed and we had no history of it, and so, the authors as far as I understand it are deferring further action until we have some more experience. So we will not, unless the authors quickly change their mind, be further discussing this, this week.
Prop-078 which is, if you remember prop-062, said how we were going to deal with the final /8. And this proposal wants to say that the problem is that prop-062 could be used without restriction other than justification. And prop-062 did not say that the people receiving allocations from the final /8 should justify them by preparing for IPv6. So this proposal says, to get space from the final /8, the account holder must show that they have a transition plan, or they have IPv6 deployment needs, which needs the v4 address space. And they need to have either existing IPv6 spaces or an application in process.
Prop-079 says there's no formal or consistent way for the Whois Database to say where to send abuse reports. There's no abuse contact in the database, so this proposes to make it mandatory to conclude a reference to an IRT object in the inetnum and inet6num and autnum objects. And you can see the IRT object and the RPSL stuff. So, to have a mandatory abuse field in the IRT object, and delete the abuse mailbox fields in all objects without IRT and delete the trouble field everywhere starting 2011.
Prop-080 is the removal of the current exchange policy on IPv4 prefixes. Under the old or the current historical prefix exchange policy, networks can take three or more discontiguous, you know, separate chunks of IPv4 space and trade it for a single, larger prefix--you know, aggregate to get routing aggregation without having to re-justify the use of the address space. So you have it, however you got it, you can take a chunk of separate ones, and put them together and get an aggregated address. The problem is that in the lead-up to IPv4 exhaustion, it will be harder and harder to find the large enough unallocated blocks to give in exchange. So therefore, this proposal says, let's remove the exchange policy since it's going to be hard to do.
Prop-081, how was one eligible for assignments in the last /8. In the current final /8 policy, only allocations can be made. Allocations are what we give LIRs to further allocate to their customers. This is differentiated from assignments which are not subdivided and given out by the receiving LIR. They're used for endsite, Internet Exchange Point, and critical infrastructure. And prop-081 only has allocations, not assignments. The proposed solution is to allow each account holder to receive an assignment under the final /8 and if an account holder already has an allocation from the final /8, the account holder is not eligible for that assignment. In other words, they can get one or the other. They can get an assignment or an allocation, but not both.
Prop-082, sorry, we had there a solution without a problem! And this is not the ITU meeting. Here we have the prop-082 says that IPv6 initial allocations require that the LIR aggregates the block, i.e., announce only one prefix. But the new kickstart policy does not require allocation and the subsequent allocations do not require aggregation. So the proposed solution is to remove the requirement for the initial allocation. And I believe, lastly, but I could be wrong!
Prop-083 says, subsequent IP allocations, in other words, allocations after the first one. The last proposal proposed to change the criteria for the first one. This is the subsequent ones. It says that an APNIC account holder with an existing /32 allocation or larger can not deaggregate that allocation in routes smaller than a /32 due to the community practice of filter blocking, bogon lists, etc, which are known to have a minimum allocation size of /32. This prevents an LIR from building a network in separate locations, i.e., there's no backbone connecting them and provide IPv6 connectivity to deaggregate the /32 for that purpose. In other words, they can't take a /32 and split it between two separated network connection points.
The proposal is to permit current APNIC holders with networks in multiple locations, but without a connecting infrastructure to obtain separate resources, i.e., multiple /32s, one for each location. And I was right, that was the last one. So, shall we move ahead to the first proposal. I believe some magic competent person will come along and enable us to do that.
RANDY BUSH: Unless someone has objections, we're going to go in numeric order; makes it simpler for us. I don't think that there are significant interdependencies.
OK, this is a proposal by Terence, I believe, one much the co-chairs. And so, and some friends of his at CNNIC. And so, shall we just let him present it?
TERENCE ZHANG: Hello everyone, Terence Zhang again. This is the version two of prop-078. IPv6 deployment criteria for IPv4 final /8 allocations.
The introduction. The proposal supplements the final /8 policy by requiring applicants to demonstrate IPv6 deployment needs or a transition plan.
The current status - the final /8 policy has the objective of assisting account holders to participate in the IPv4 Internet while they deploy services using the IPv6 Internet. The current /8 policy provides one single /22 allocation to each LIR, does not specifically require account holders to demonstrate IPv6 deployment needs or a transition plan. The position in other RIR regions - ARIN has adopted a similar policy, which is dedicated IPv4 blocks to facilitate IPv6 deployment.
RIPE has similar policy proposal under discussion, which is IPv4 allocation and assignments to facilitate IPv6 deployment.
AfriNIC has a similar policy proposal under discussion, which is IPv4 soft landing policy. It requires IPv6 deployment lease or transitional plan in order to allocate address during the exhaustion phase.
LACNIC currently have no similar policies or proposals.
Before going to the details, I'm going to highlight some of the changes to version one. The major change to version one was based on the comments from the last meeting. We've extended the reserved /10 block to the whole /8, excluding the last /16 reserved for future use. And the size, the allocation size confirmed with the final /8 allocation size, which is the minimum allocation size. And subsequent allocation is limited. So the details of the proposal. It is proposed that in order to receive IPv4 addresses under the final /8 policy, account holders must meet the following additional criteria. The first is must demonstrate either IPv6 transition plan or IPv6 deployment needs, especially the needs for IPv6 to IPv4 Internetworking. The second criterion, must have either existing IPv6 addresses or a valid application for IPv6 addresses.
The /16 reserved for future use is exempt from the IPv6 requirements. So basically, we just add this additional criteria to the final /8 policy. We didn't change the /16, we didn't change the principle of one organization get one allocation for the final /8.
The advantage - it ensures account holders use the final /8 space for IPv6 transition, which supports the need for native IPv6 networks to communicate with the IPv4 Internet.
Disadvantages, some account holders will not be eligible to receive addresses from the final /8 if their sole intent is to grow IPv4 services.
Any questions? Comments, from the floor?
FILIZ YILMAZ (RIPE-NCC): I just want to make a clarification, actually it's a comment. It is stated that in RIPE region, there's a similar proposal--it's true, it's in our PDP, there's a proposal that you mentioned. However, there have been some developments since the last RIPE meeting which I want to say now. When it was discussed during the last RIPE meeting, it came out that we were also discussing it together with the last /8 proposal, because we have in the RIPE community, we haven't reached consensus in the /8 proposal at all. So we combined those two as they were relating to the same resource. And the community's decision or recommendation was more in the lines that maybe we should go for an alternative third proposal, which is not mainly taking elements from the other two.
So at the moment, although those two proposals are still looking like it is in the RIPE PDP, in reality, there is a third potential proposal that is in production, which we are in contact with the proposal, but it hasn't been published yet. And it may not be very similar to what you are discussing here in the APNIC committee. I just wanted to mention that. Thank you.
TERENCE ZHANG: OK, thank you.
SEIICI KAWAMURA (NEC BIGLOBE): Thank you, Randy. Hello. Can you go back to the slide with the details. I just want to ask a clarifying question. I didn't understand if the first one and the second one is in order, and do I have to meet both one and two? Or is it either one or two?
TERENCE ZHANG: One and two.
SEIICHI KAWAMURA: One and two. So, if my network was already dual stacked and I already transitioned to IPv6 and I wanted IPv4 address space from the last /8, would I be able to get one?
TERENCE ZHANG: Of course you can. If you already have the IPv6 address space, which is the second criteria. And you already have deployment list. So I guess you have to meet the final /8 allocation criteria, which is the IPv4 allocation criteria. Which is in this proposal. This is just like the criteria.
SEIICHI KAWAMURA: And it says to demonstrate a transition plan. And if you've already done it, is that what you're trying to say?
TERENCE ZHANG: Yes, the plan or the needs and the address application or existing address.
SEIICHI KAWAMURA: So I don't have to tell you I'm about to do it, just give me the address.
TERENCE ZHANG: This is the last chance to get the four address and you have to consider using it for IPv6 deployment. That's what you want to make more formal. Thank you.
RANDY BUSH: Randy Bush speaking without his chair hat on, which is why I'm speaking from the floor. APNIC's job is to allocate addresses according to need. Not to tell people how to run their networks. We don't know why we're going to get that little bit from the last /8. It's just a little bit and they shouldn't have to run, and by the way, we're the first special deployment of IPv6 in the world. It's not that we don't like IPv6. Love IPv6, worship IPv6, etc. We don't think that you should be coercive with it. You should not tell them to run IPv6. You should not tell them that you should use routing security. You should not tell them that they should not use telenet to their routers. They should justify the IPv4 address space. They get the last chunk and that's our job. Not to tell them how to run their business, etc. If we're going to do that, I would ask them to promise that they will never use NAT.
TERENCE ZHANG: Thank you.
KENNY HUANG: According to the assessing IPv4, perhaps lasts for a few more months or more. The original purpose of the final /8 proposal is the global policy right now, is to try to make sure that the implementation of the final allocation policy will be conducted with extreme care, or even to go into a higher goal. And that's why I see that where you're standing, and to reach another higher goal.
TERENCE ZHANG: Thank you.
CHING-HENG KU: OK.
PHILIP SMITH: Philip Smith Cisco. As one of the original authors of the final /8 proposal. The idea was to share out the final /8 as fairly as possible. What this proposal seems to do is to make it harder for people to get IPv6, and it ventures into what Randy was talking about earlier, of trying to have a policy that's coercing people to do things, or not do things, or whatever. So this is not the idea that we were really trying to go after in the final /8, and ISPs and everybody else is going to deploy v6 anyway no matter what it does. So I can't support this at all. No way.
CHING-HENG KU: OK, thank you.
MIKE JAGER: From New Zealand. I agree with both Philip and Randy, the purpose of the RIR is to allocate the space to whatever they feel is in their interest. If a given member doesn't want to deploy v6, then I don't believe that's the RIR's problem or responsibility to ensure that they do that. Obviously there's good reasons to deploy v6, but if a given member chooses not to, I don't believe that APNIC should prevent them from receiving space for the final /8 policy.
WENDY ZHAO: From CNNIC. I'm one of the co-authors. I do believe our intention is not telling people how to do the last /22. Apparently we did not really do that. You have to use the final /22 that you can get to use for the final translation. And only sending messages saying, you're considering of the IPv6 deployment and then you get the addresses. That means that you can use wisely. And although, yeah, I do agree that not everyone goes, chooses to go to IPv6, but I do believe that everyone in this room, we really want to see that eventually, everyone has to go to v6. And although there is another consideration about it's hard for some member to get the final /22, but we don't see it as being the problem. In the last meeting, we go through a policy proposal that's easy for applying the IPv6. And it could be in the positive way, it could be a way to promote IPv6, but it is not the key point for the proposal. So that's just some clarification for the intention of this proposal.
IZUMI OKUTANI: From JPNIC. I do see what CNNIC is trying to do in this proposal.
RANDY BUSH: Could you move closer to the mic.
IZUMI OKUTANI: But trying to encourage or give recommendations and adding it in policy criteria is, I think, a different thing. So if that is the purpose, trying to encourage people and give recommendations, can we separate that from adding that into the criteria and just, I don't know, I don't know if that would be a policy document to state the recommendation or not. But do it in some other way to give recommendations, rather than adding it as a criteria?
TERENCE ZHANG: OK, some more comments. Currently, you know in all of the RIR regions, we have like two diversions for the final /8. One is like the APNIC policy, one size fits all. We don't have any additional requirements. The other direction was implemented in ARIN or was discussed in RIPE or in AfriNIC. It's attached some IPv6 requirement. So that's the situation I think that if there's a requirement, we will have more guidance or incentive for people to for people to move to IPv6. And it also faces people when they apply for address space, they may refer to the policy proposal. They may just see the policy itself, the policy for the IPv6. My transition, so we just want to make the message clear that is our intent. It is not one to look this operation.
RANDY BUSH: IIJ Japan. Again my apologies. First, Philip has to remind me that I have to confess that I believe I'm a co-author of the final /8 proposal. A little more detail was that the intent was, as Philip said, to be fair, in other words just, the problem is over time, there had to be justification because of wanting to aggregate routing, you have to justify a need for an address block. As things get really nasty in the final /8, we felt that we wanted to be absolutely fair and reduce all barriers to entry. So that a new ISP, etc, could not complain that they couldn't get space. So, that was the intent of, I believe, the final /8 policy. I believe also that we're mischaracterizing a little and I would like to hear from ARIN what is going on in the ARIN region.
I done believe that policy is their policy for what to do with the final address space. I believe that policy is set aside a /10 for use in transition to v6. And the third thing is, I might have a procedural announcement to make that only people running IPv6 can have lunch today.
CHING-HENG KU: Thank you, Randy.
EINAR BOHLIN: There was a question about the policy. The ARIN policy has the /8 as a trigger. So ARIN is to designate a /10, perhaps from the /8 or from the reserves, perhaps, and that is for facilitating IPv6 deployment. The minimum prefix size is a /28. The minimum is a /24 and one prefix every six months.
TERENCE ZHANG: Thank you.
CHING-HENG KU: So, we have the discussion. If there are no suggestions or comments, to summarize the proposal. The proposal states the criteria in the original policy. So, we hope to make consensus. Do you think it should be set out in new policy to add in additional criteria? So, if you support this policy proposal, please raise your hand.
How about Bangkok participants. If you support this policy proposal, please raise your hand.
And how about Laos. If you support this policy proposal, please raise your hand?
OK, thanks. And the next question, if you oppose... if you oppose this policy proposal prop-078, please raise your hand.
OK, thanks. And how about Bangkok? If you oppose this policy proposal, please raise your hand. How about Laos, if you oppose this policy proposal, please raise your hand.
RANDY BUSH: Just a sec. That's from?
RANDY BUSH: From Laos. They say that they just want to discuss for a moment. Tell us when you're ready. For your information, I don't know, can you folks see our room here? Do you get the video feed? So if they get the video feed, they get to see the room here. Any opinion from Laos. From Phnom Penh.
CHING-HENG KU: So I think that this policy proposal cannot have consensus. This proposal maybe can be modified and can be discussed. Thank you, Terence.
TERENCE ZHANG: Thank you everyone for giving your comments.
DAVID CROCKER: I'm here on behalf of Tobias, I'm presenting this, but it is not my proposal, which means that I get to talk about it in a type of support which is personal rather than that of an author. The proposal is very simple. I'm sure there will be no controversy. Everyone will want it immediately.
The premise of the proposal, and I do invite you to actually read the slides, because I will try not to repeat exactly the words that are on the slide. Is that there is a reality in operations today which is that we have ongoing concerns with abuse, and that one operations environment needs to be able to report it to another operations environment. And currently, does not have a unique address for that, but must use other contact addresses. And so the proposal is to create a distinct place for listing an abuse address. So the rest of this presentation just gives a little background, and then the details, but that is the core of the proposal. I've been led to believe that most of the people in this room are not running an abuse desk, but that someone else in your organization probably is. But that with the concern arrangement for registering addresses in Whois, you often get abuse reports and then must pass them on. The proposal is trying to fix that confusion. So that today, when one organization needs to send an abuse report, they have trouble deciding where to send it to and they make different choices and that abuse reports therefore often go to the wrong place. They can get lost. And certainly, they can get delayed. The slides list some of the kinds of choices that get made today. Each of which has the problem of frequently not being the right place. I think this slide repeats the point I've been making.
There is some existing practice already for this topic, and the key point is, it is not mandatory and it is not the same across the different environments. And APNIC, sorry, this environment is the first effort to create a standard for this with the intent of going to the other groups and asking for the same convention. And so, ARIN has a place for this information, but it is optional. LACNIC does too. AfriNIC does not. RIPE does have one. But again, it is optional. So, if this proposal is approved here, Tobias will be taking the same proposal to the other venues.
So the proposal is to make this object mandatory, or these objects mandatory. And it would be created when the, when an organization updates an existing entry or when they get, when they create a new one. Is that something I should... no, alright. (Bell Rings)
So the intent is that when someone needs to send an abuse report, they would send it to this e-mail address. The proposal does not specify what happens on the receiving side, merely that there is a mailbox that is associated with that address. So the next few slides, I think, further state the sorts of points that I've been making. And shockingly, Tobias sees no disadvantages. More surprisingly, Neither do I. So, this summarizes what effect this proposal would have on you folks. The main effect is that you need to support another object in the database and you need to enter the data for that. And I have to admit, I don't fully appreciate the difference that might accrue to NIRs. So, I think that this slide is perhaps from a different presentation! I know that everything relates to IPv6! But think that this particular proposal is not.
So the version of the slides that I have basically points out that there is the overhead of needing to create the object and populate it with an e-mail address, and the one potential downside is that you have to keep it current. Like any other database maintenance problem, these addresses sometimes become stale and you would have to worry about that. So that's the proposal. Do we do questions? Sorry, I'm not sure of the procedure.
CHING-HENG KU: Are there any questions? Comments?
MATTHEW MOYLE-CROFT (INTERNODE): If we're going to be adding new things, is it worth being able to describe more specific abuse contacts, say not just a general abuse contact. But in a lot of organiZations, e-mail is handled Very differently from issues to do with network abuse. You know, people having their machines riddled with various botnet things and so on?
DAVID CROCKER: So I will give you a response which represents my understanding of the real world, but I'm not an operator and I don't run an abuse desk and I don't pretend to. But I do participate in discussions among those groups. And I think that the reality is that an extremely reasonable idea, the actual practice would not work very well, because it depends upon people making fine-grained, very precise distinctions, that in practice, they can't or won't. And that it is better that the main benefit here is to separate abuse from other kinds of traffic. Whereas the fine grain distinctions of different kinds of abuse just would require, it would add complexity and it is not clear that it would add benefit. So it is a reasonable idea, but everything I've been seeing, even, by the way, all the way to the end-users with the spam button versus multiple buttons, the distinction keeps coming up and it appears that it is better to keep it simple.
MATTHEW MOYLE-CROFT: Sure.
CHING-HENG KU: Any more comments or suggestions?
MIKE JAGER: New Zealand. As someone who has been on the receiving end of abuse complaints before, while I can appreciate the desire to have a dedicated abuse contact associated with an inetnum or similar, I remain unconvinced that it will prevent abuse reports from going to the other contacts associated with an inetnum as well. We often receive abuse complaints that have gone to contacts for us, our upstreams, contacts on a domain name that happens to be associated with a router that was in the path between the abusing party and the rest of the Internet. So, while I think it would be nice in an ideal world, I can't see that it is actually going to achieve the desired effect in practice. Thank you.
DAVID CROCKER: People are used to using other addresses, and second of all, there's just the fact of trying to decide what address to use, and that's a human decision and people will make the wrong one. And I think that it is less that this is designed to guarantee a separation. But more a case of trying to make it more likely, and perhaps over time as practice develops make it highly likely. Without this, people are certain to be the wrong ones getting the report. With this, that perhaps less often or at least that's the idea behind it.
PHILIP SMITH (Cisco): I think the lack of having the abuse contact information, it levels the other contacts open to other possible or receiving the abuse contact, but having it there will help. I agree with Mike as well, even though it says there, I don't see that people will necessarily use it. But you know, let's at least try to put something in there so that the opportunity is there as things get better going forward.
WENDY ZHAO (CNNIC): Actually, I'm not putting comments on the proposal but sharing information. In NIRs, sorry, most of the time we get allocation from APNIC and we attend the key blocks. So on the change line, normally we put our role e-mail contact whatever at CNNIC. But the main arbitration person and technical information actually in the object. But we find out within two days, we can receive thousands of abuse e-mails, only sending to CNNIC e-mail, without any forward or CC to any of those specific contact persons. So that's just information more to share.
OWEN DELONG (Hurricane Electric): We have a question from the jabber room to get all of the materials from the web server. It's stated that he can't see some presentation materials when he accesses with IPv6.
DAVID CROCKER: So I was wrong, this presentation does relate to v6!
CHING-HENG KU: OK, there are no more comments and questions. We make the consensus or not for the attendees. So maybe Bangkok and Laos can prepare to have the process. Is there anyone who supports this proposal? Please raise your hand. Support. Support.
OK, thanks. OK, thank you Bangkok and Laos.
And if you oppose this policy proposal, please raise your hand. Oppose.
RANDY BUSH: Just a second. Bangkok, sorry for accusing you of being in Cambodia. Anybody in support or opposition. Bangkok, do you oppose this proposal? Do you support this proposal?
OK, there's support in Bangkok. Thank you. Bangladesh speaks.
NORBUT KLEIN (Cambodia): I just wanted to say, it was Cambodia which doesn't appear here. You're talking about Laos.
RANDY BUSH: Yes, I corrected myself and even apologized to them.
CHING-HENG KU: So this proposal makes consensus. So the next one is there.
Have the prefixes replaced with a single, larger and contiguous block. Here is the policy. Exactly what I would like to remove and it is at the URL at the bottom of this. There is a historical exchange policy in section 6. The key message of the exchange policy is, if someone has more than three blocks of historical resource, that are contiguous. Discontiguous. So they can come to APNIC to train for a single block of IP address that could be larger than what it was. For example, they can bring in three /24s, and then receive the /22. They can also bring in one /16 and two /24 and get a /15. And the hostmaster is not able to ask any questions because the policy says that there are no questions to ask. There's no justification of the resource holder.
At the time, this policy was introduced, it has a good intention to reduce the global routing table. At that time, the global routing table is going up very fast and our equipment is a bit hard to handle. But now, the global routing table site is not the major concern to the Internet community. Instead of that, the IPv4 exhaustion becomes the major concern to most of the people.
So let's look at the problems. This policy allows people to exchange three single prefixes. To become a larger, one single prefix. And also, that exchange looks at justification. So it's become a bit dangerous that people can use this policy to get more IPv4 address without any justifications.
Let's check other RIRs and see if there's any policy in the region. Actually, ARIN has two policies related to exchange. I look at the policy. Basically, the policy is, intention to encourage people to return and use historical resource. But at the same time, if they still need resources, they can change to a single prefix. And anything larger than /20, they still need the hostmaster to do the deliberation. But the APNIC policy, there's no deliberation. No questions asked. That's a bit dangerous. And in other three RIRs, there's no such exchange policy.
So getting to the details of the proposal. It is proposed that APNIC remove the policy that enables networks to exchange non-contiguous address blocks in exchange for a single aggregated range. Basically, it's to remove the historical exchange policy listed in the section 6 of historical resource policy. The advantage of this policy proposal. It is to remove a policy responsibility that APNIC will not be able to fulfil during the IPv4 exhaustion period. It prevents organizations taking advantage of the exchange policy to obtain more IPv4 addresses from APNIC by rounding up to the next bit without justification of the need.
Of course, there's some disadvantages. It prevents organizations willing to return non-contiguous blocks to reduce the size. But now it is not a major concern to the Internet community.
So what is the effect? This policy actually, it will prevent APNIC members from exchanging non-contiguous prefixes for a single prefix. It's also an effect to the NIR members. They are not able to do the exchange. Finally, I would like to give you the usage data of using this exchange policy. It is only ten cases so far. It is not very used by the community. This is all of the cases listed here from 2003 to last year.
Thank you. Any questions?
RANDY BUSH: I actually have one. So there's a current policy that says I can take a bunch of them and say, give me an aggregated and you're worried that you're not going to have an aggregated to give me? And so, you want to remove the policy, but can't you just say, "Sorry, I don't have one to give you this week?" And six months later, you have one? So maybe that would be a little unfair, because it depends upon when I ask? But do you really need a policy change?
GUANGLIANG PAN (APNIC): Yes, I think it is better to remove the policy. If someone comes in and they don't have the contiguous and sometimes it is unfair to people. Yes.
PHILIP SMITH (Cisco): Is there a problem right now that you can't actually fulfil this? I mean, I would be happier seeing something which says, you know a modification which says, when have no longer any contiguous space to give, then the policy stops being current, because I would imagine, even though it has hardly been used over the next two or three years, it doesn't need to be removed right now. I would be happier waiting until you can't hand anything up. Set up the proviso in the policy that says, we'll carry on doing this until we can't do it any more, and then it is null and void.
GUANGLIANG PAN: Yes, actually, it is not like an immediate concern of this policy. Like, we are not able to fulfil at the moment. But in the long-run, when it goes to the final /8, it is a possible problem. Of course, when we hit into the final /8, actually, this policy will be automatically disabled because it is not allowed to do this, because only the final /8 policy proposal will be adopted at that time. But as I mentioned here, there's another two advantages here. Also, it is organizations taking advantage of the policy to require more v4 addresses at this stage. Like for example, a final /16 and get two /24. That's a little bit more. Like, if you go and say, I give you three prefixes and you give me one? What is the last one? /15. Then you actually double your IP address. According to the policy, there's no questions asked. APNIC is not able to ask any questions. That is a bit dangerous. When it comes to the final stage of the v4 space.
PHILIP SMITH: OK, that's great, thank you for clarifying that.
GUANGLIANG PAN: Thank you.
RANDY BUSH: OK, we'll try to see what consensus there is. Would those who support this proposal in Kuala Lumpur and Laos and Bangkok please raise your hands? So, who supports this proposal?
Somebody in Vientiane is saying something but we're not hearing them. Vientiane, we did not hear you. Can you jabber it because we did not hear you. And those who oppose the proposal, could you please raise your hand.
OK, that's about it. It looks like we have... oops! Bangkok, were you supporting or opposing? Was that support? Or opposition? Bangkok? Bang
SPEAKER FROM BANGKOK: I have a question.
RANDY BUSH: Please go ahead. Speaker from Bangkok: The question... actually to oppose the policy, but it is not like, even we use the IPv6 tomorrow. And we will stop use of reform. (Inaudible)
I see in the policy, that we can use the aggregate, but if we can just not remove the policy. We just have more straight policy. Like, instead, we say, OK, if you actually can get, if we say, if you've got to, you can get a bigger one. But not the 3 to 4.
RANDY BUSH: Excuse me. I think you are maybe looking at the wrong policy. We're discussing prop-080. Which is about trading in three IPv4 cards for one bigger IPv4 card.
LORENZO COLITTI: I think, if I understand correctly, the voice from the VC is saying, I want to trade two cards for one card, as long as the one card is the same as the two cards combined in size.
GUANGLIANG PAN: Yes, I got the point. Probably the same, they're saying, the size is not larger. Means that if they try to change the size. It's not larger. We still allow them to do it. That's probably what they're trying to say. But that would have to change the policy as well. If not remove it, it would have to change the policy. That's the case. But I think it is not my policy proposal. My policy proposal is just to remove it completely, because it would be automatically disabled when we hit to the final /8 anyway.
RANDY BUSH: OK, Bangkok, again, a lot of you raised your hands. Were you raising your hands in support?
Bangkok, a lot of you raised your hands. Were you raising your hands in support? Or opposition? Were they in support of the proposal? Bangkok, can you hear me?
CHAMPIKA (APNIC): Actually Vientiane, they're from Vientiane.
RANDY BUSH: OK, sorry, they switched monitors on me. So that's the intent. Vientiane. A lot of people raised their hands. Was that in support?
SPEAKER FROM LAOS: We are supporting.
APPLAUSE
OWEN DELONG: I have a Jabber from Thailand that simply said, Question from Thailand. And now I have one that says, two/to support from Thailand.
There was consensus.
So now we have a question, should Wendy present her proposal and then we go to lunch and then we come back and discuss it? Or shall we just go to lunch? Those in favour of letting Wendy present her proposal, please raise your hands.
And those who demand immediate lunch, and the only people who demand immediate lunch must be running IPv6!
LAUGHTER
PAUL WILSON: Before going to lunch, I just wanted to mention something that relates to IPv6 like everyone does. There was a comment earlier that presentations from our sessions aren't available on IPv6 via the APNIC website.
RANDY BUSH: Some of the presentations are broken on IPv4, people are fixing them.
PAUL WILSON: I'm just letting you know that it is being fixed. It's to do with different caches on the system.
RANDY BUSH: The last presentation wasn't working on IPv4!
PAUL WILSON: If they're not synchronized, it's to do with an asynchronize there.
RANDY BUSH: So Wendy, let's go.
SPEAKER FROM VIDEO LINK: It's OK for us have lunch first. Then come back.
RANDY BUSH: Too late.
WENDY ZHAO: Someone raise hands. You support the lunchtime or you oppose the lunchtime? OK.
I will make it as quick as possible before some people start eating the pens and papers. I'm Wendy Zhao. And I'm making the presentation on behalf of the other two authors, co-authors, Jane and Terence.
I'm presenting a proposal to be able to make portable assignment for the account, current account holders and future account holders to get the blocks from the final /8.
This proposal actually seek to supplement the final /8 policy. The account holder be able to receive the possible assignment from the final /8 space. We believe that's the spirit of the current final /8 policy.
Current status - for the current final /8 policy, the only allocation is permitted for the account holder. And actually, the assignment, possible assignment mentioned in that policy.
Situation in other RIRs - I believe there are some proposal for the other RIRs. And one RIR which is LACNIC have policy reserve in the block for the assignment for the future new member.
The details - the detail, actually - there's so many words but it's really simple. In the final /8, each assignments will actually, the account holder who can identify their criteria based on the current assignment policies, they can get a block of assignments regarding, related to the current minimum assignment size. For the multihoming, we don't have assignment size minimum, but the minimum assignment size applied to the multihoming request.
Actually, sorry, the current account holder and future account holder only can get single allocation or assignments, so they can't really get both of them. They can only get either of it.
Pros and cons - the advantage is to make sure that someone can't really clarify the requirement of /22, if only /24 for the critical infrastructure, they still can get their blocks from the final /8.
Currently, we don't really see a disadvantages of this proposal.
The effect on APNIC members is the account holder may receive the assignments from the final /8. The same with the NIR members - sorry - that's, that's not the updated slides. There's two more slides I actually put on to make clarification of the assignment and allocations. For the allocations, the criteria is RIRs want the blocks and they subsequent to allocate to their members. For the assignments, if someone need a block for multihoming Internet exchange point, or critical infrastructure, they can get possible assignments. That's something to make clear. That's all my presentations. Only three minutes. Yay!
Thank you. So, we are taking questions and comments after lunch, right?
RANDY BUSH: I think that would be a good idea. Because I think this one will have a little discussion. And also, maybe people during lunch will have time to think about it and discuss it with each other.
WENDY ZHAO: It's a good idea. I'll be in the lunch room if anyone want to talk to me, I won't mind. I can manage my mouth doing both. Thank you.
RANDY BUSH: Any administration before lunch? Sam, are we allowed to have lunch now? Thank you, all. It's lunchtime.
We'll be back in one hour. So you guys in Southeast Asia can have a quick break too.
1400 - 1530 (UTC+8) Thursday 4 March 2010
RANDY BUSH: We should probably start now. We only have half the room. All the people who don't room IPv6 had to find a restaurant for lunch. Some of you may notice that getting to the presentations on the APRICOT website, have been somewhat problematic, both for IPv4 and IPv6. And that's because APNIC is out of cash. But the other kind of cache. So, would you please show the foils that she missed and told people to go get from the website because they don't know if they really can? Is that OK, Wendy?
Because it's difficult to get them from the website, so could you show them? He's got your slides for you.
WENDY ZHAO: Shall we get started? I do apologize, there's two slides missing. And I fixed these slides on screen that people can read through. Just a couple of additional definitions about what actually is allocation and assignment are in the current policy. People can read that through.
Before taking comments and questions, I have clarifications to make. The current final /8 policy actually is for all the Members, either the direct Member of APNIC or the direct Member of NIR. So I do believe that's the key point. And this proposal followed the current final /8 policy which is the current account holder, both APNIC direct Member and NIR direct Member can get a portable assignment if they qualify for the criteria. So that's the clarifications.
I guess I can take the comments and questions.
JONNY MARTIN: Hello. Jonny Martin from all over the place. New Zealand, actually.
This seems to be kind of a bad idea, I guess. When we get to the last /8 it's because we have no more address space. So, well, I hate to say it, but we're rearranging the deck chairs on the Titanic. The idea behind the original policy was that everyone gets one last fair chance once we get to the /8. We don't really want to be starting to deal with end-sites and that kind of thing. It's going to be bad enough as it is. I think we want to put this one to bed and be done with it otherwise we'll have another policy at the next meeting, add some other criteria to the last /8, the meeting after that. It's not going to end. So I think we just need to accept it and move on.
WENDY ZHAO: Right, yep. About that, actually, you're right. I do believe the spirit for the original, the current final 8/ policy is for everyone, fair enough to have the last slice of the cake from the pool. But apparently someone didn't really go through the current policy. In the current policy, only talking about allocations, I can't say there's a big number of Members, they only have portable assignments but there are some of them. They only qualify for the portable assignment and the definition for the allocation and assignment are different. So if we don't include assignment in to the final /8 delegation policy, that mean some of them couldn't get last slice, whatever. So the assignment actually has been missed out, because we do the portable assignment in the current policy but not in the final /8 policy. In that age or time, they can't say all policy, but current policy won't take a place.
Only the last /8 policy take place and the last /8 policy says only allocation can be made, not assignment.
JONNY MARTIN: In the ideal world, we would be giving everybody all the IPv4 space they wanted out of that /8. But it doesn't work. It's not, you know, it's the end.
WENDY ZHAO: You see, the spirit of the current final /8 is give everybody, every account holder one piece of the cake, one piece of the /22. There was someone who was left out in the room, which is the portable assignment. And I believe we calculating the APNIC back to a year ago, when we went through the final /8 policy, we're talking about 1,600 Members and the final /8, we calculated if /22 is enough and the final /8 space is going to run out, we do include all these Members, which only have portable assignments. But, actually, they are not in writing in the policy. Thank you.
IZUMI OKUTANI (JPNIC): I also don't want to add too much criteria to the current /8 policy, which is quite simple, and fair. But at the same time I feel that if there are needs that should be met, we shouldn't just neglect it. We should be a bit careful in considering what kind of needs we would be facing. And one thing that I feel that there might be needs for portable assignment is for critical infrastructure, such as if there's new GTLD or ccTLD set-up, I think they would need a portable address space, that does not, is not dependent on ISPs. And if they can't meet the criteria for /22--because they have a separate criteria in the current policy now--so we should be able to meet the needs of these people and I'm also happy to hear feedback from the people who feel we don't need this policy, and if there's a way to address the problems of these people who need the space.
WENDY ZHAO: Thank you.
CHING-HENG KU: Any comment? OK, Randy, please.
RANDY BUSH (IIJ): Yet again, sorry. First, again, central purpose - why 62 was allocations and not assignments was that one of the co-authors strongly felt that the goal - two things, one was the goal that new entries into the market should be fairly given space for a long time. In other words, so that nobody could say that APNIC policy prevented new LIRs from going in to business. He specifically did not want to solve the problem of end-sites because there are too many of them and IPv4 is going to run out.
And this is - let me speak to my feelings - IPv4 is going to be gone. We can't give everybody what they need. "Critical infrastructure, like GTLD servers," I know they'd love to have golden private space, but, no. We're out. Sorry. Go get space from somewhere else.
The issue for exchange points is they need a /26, a /25, maybe a /24, and if you really think they're critical and that they can't go get it from anywhere, and, again, where an exchange point is numbered from is not important, it doesn't need to be separate portable space. There's no need for it. OK. It's just the layer two mesh. OK.
And, third, is end-sites. OK. Why, in the final days of v4, do end-sites need v4 space? It's because they need v4 connectivity. Because it's going to be 20 years before the last v4 goes away, if we're lucky. OK. And what they need is just a teeny little space to do NAT PT or what's more fashionably called today, NAT 64. They don't need a default allocation. And there's also still the sad story that when you get to them, the number of them is more than we're going to handle in the final /8. So, again, we'd love to give them what they need. We ain't got it. OK. So, two things is we really can't…
(computer crash but no text lost as Randy waited)
RANDY BUSH: So, gTLDs do not need portable address space, and we can't have all of the multihomers and see these needs, even if we wanted to try to meet them, are all for different sizes of address space. So shouldn't be under this one size fits all final /8 structure. Sorry to go on so long.
WENDY ZHAO: OK, I, based on my poor memory. I can answer the one that I got the most impression. First of all, for the critical infrastructure, for the final /8 policy, I do agree. We don't try to solve all of the problems. That's why we only give a /22 to all size of Members, for the big one, small one or medium ones. Because we don't solve their problems. We only give them a chance and they solve the problem themselves. But for this policy, it is actually trying to bring the equality. For the criteria, actually, Randy brought it out saying that the multihoming and the Internet Exchange Point, and the critical infrastructure, that's the current criteria. Just like what we've done for the last /8 for the current allocation Members which they will obey the current criteria. So this proposal, actually looks at the portable assignment requirements to base on the current criteria.
If we don't think, the current criteria is not suitable for the future after we ran out, or after we got the final /8, it could be the other proposal to change that. But right now, we try to solve the problem about who wants the assignment. Who wants the portable assignment for this, and also to talking about the Members. I do believe if I'm a company who is running the ccTLD or new gLTDs wanting to become an APNIC Member will get rejected, so I will become a Member, but I cannot qualify with the current allocation criteria which is /22. Because normally for the portable assignment, only /24, I would be happy for that. So, for this person, they could not qualify to get their portion, which is the future account holder. So that's the part we try to solve. I do believe that is the last /8 and we can't really separate everybody, but separate everybody in the room already.
That's what we're trying to do. Is we don't divide the room into one allocation part and the other is assignment part and say, allocations guys hey, you're so lucky because of your allocation size and you get your slice. And for the critical infrastructure mainly, the portable assignment account. And talking about critical infrastructure, I do believe, as an NIR and a NIC, we do actually operate the dot-c. I do believe we want individual portable assignment, not from upstream, which should be based on the business.
RANDY BUSH: Why do you want it?
WENDY ZHAO: I want the portable assignment to be included into the final /8.
RANDY BUSH: Why? Explain to me technically why? I run 21 ccTLD servers. I don't need one portable assignment. That's there's root, and it says where you move the server to a different address: you just change the pointer. You don't technically need special portable space for anything other than the root servers. That's a side discussion. The point is - two things. Number one is, 62 does not say /22. It says current policy. Current policy happens to be /22 now. Three years from now, it might be /26. The third thing is, the policies we have for after v4 run out, talks about the food we are going to serve when there is no more food. I think we should leave that to the ITU.
WENDY ZHAO: Technically, I can't really say if the critical infrastructure do need portable assignments. But business-wise, in China, we do need that portable assignment. I don't know about the other regions.
RANDY BUSH: Why do you need it business-wise?
WENDY ZHAO: It's supposed to be individually, not connected with the upstream. The IP addresses which, I can't say really strongly, but we prefer to have our own address space rather than get it from upstream.
RANDY BUSH: I assure you, it makes no difference if you move providers. All that happens is the root server changes the address for the CN server. It takes five minutes.
WENDY ZHAO: Randy, you know what, why don't you come to China and talk with some of the folk in there and you might understand me better.
RANDY BUSH: But you're making the proposal in saying there is a need. They're not.
CHING-HENG KU: OK, I've seen many discussions currently is about the criteria of the assignment, but maybe there is opinion for this proposal. If you have any other comments--
RANDY BUSH: You should give it to Owen because he's representing Jabber.
OWEN DELONG: I have two comments from Jabber. One is from Terry Manderson, "No particular affiliation," he says. The justification is right for the final /8. "It is fair and will serve as a better function for IPv6 deployment than /24 assignments to endsites. I cannot support this policy proposal. The last /8 is special." Terry from Australia, speaking for himself. And another comment here from Skeeve Stevens says, "People are not impressed with Randy, a co-chair, kicking the ass of the policy presenters."
RANDY BUSH: I'm not impressed with Skeeve who is sitting over there and won't speak for himself.
TERENCE ZHANG: I just want to stress some data. I think currently, if you look at the status, the APNIC region has about 1,000 and something portable assignments. And half of them are /24 size. So I think the lead is just different. Maybe for some kind of business, they say, I can't have other solutions. But I think still there is definitely some need. Probably not a very large need, or more requirement. But definitely there is a need to have portable assignment. Because currently we have a thousand and a couple of hundred of them and many of them are /24 size which is to justify a /22 allocation in the final /8. That's one part, and another part is in the final /8, the LIR only gets a /22 allocation. Therefore, the end-user, it is difficult to get assignment from the upstream because they are also running out of IPv4 addresses. And the last one is, currently the 62 allows about 16,000 allocations, which, currently we have only 2,000 and something Members. So, I expect we will have enough space to accommodate the assignments.
RANDY BUSH: And one procedural thing first. Skeeve, by the way, who won't speak for himself. You should note that prop-062, which we're discussing modifying, was made with one of the authors being one of the co-chairs. This proposal is being made by one of the co-chairs. So, speaking to it by one of the co-chairs is not really procedurally seems that horrible. If people here have problems with that, would they please raise their hand. Thank you.
Terence, to your point. Is counting the number of Members, I'm not sure is what you want to do when you're talking about giving it to any multihomer. There's a massive number of multihomers out there. And hopefully many more. And I just think you're talking about a different scale, a different set of math. But again, I note here, it is what we're talking about on the mailing list, which is, it is not that I do not see the need, although I do not see the need for DNS servers, or exchange points needing special portable space. But I do see the need for multihomers. But I think for all three of those, they have different amount of space needs. So I think if I want to take the proposal seriously, I would want something that says specifically, it is like I said on the mailing list.
For multihomers, they get a /29 or a /28 and for exchange points they get a maximum of a /24, etc. And not just the, enough for an allocation to an LIR whose space is as big as we have left in our pockets, which isn't much. But enough for them to sub-allocate. I mean, the /22 is enough for them to give a lot of /30 out to multihoming matters.
TERENCE ZHANG: By looking at the number, that was the need. And about the size, because currently we are making assignment developments, assignment size is like a /24. And for the multihomer, there was a low minimum assignment size. This is the current policy. I believe if in the future, we see the need to reduce those assignment sizes, we can have another proposal to discuss it. Including the minimal allocation size, because in the future, they might have a little discussion of size. But this proposal leading to the minimum assignment size is just like prop-062 is linked to the minimum allocation size. The size can change in the future and in this proposal, the size will just reduce, if the future size reduces. So I think it is just lying consistent with the current prop-062.
CHING-HENG KU: OK, Terence. Thank you. So, now in our discussion. Any other suggestion or comments? So this proposal is considering assignment should have the address in the final /8 or not. Any other comment? And another discussion about the criteria of the assignment. Is one of the opinions in this discussion. Another opinion in this discussion.
JONNY MARTIN: One last comment I was going to make was, things are going to be bad when we get to the last /8 and this is effectively lowering the bar to a very low level. You don't need to do much to get a multihoming assignment. So the APNIC Secretariat are going to have enough work to do at the time to sort out the valid from the non-valid requests and I think this will make it a lot worse.
CHING-HENG KU: Thank you.
PHILIP SMITH: I'm sorry I came late into the discussion, I had another meeting. But the original intention of the final /8 that I was co-author of was to try to keep things as simple as possible. This seems to make things more complicated. I'm not really quite honestly sure if it is really needed or even worth doing given that we're really only, what, 18 months of v4 left. So I would say that we should just forget this and move on to do v6, which seems more sensible to me.
OWEN DELONG: Hurricane Electric for Jabber. Terry comments, "I'd like to suggest to the Policy SIG that in the end days of IPv4, we should not be making additional work for the RIR or NIRs to adjudicate additional requests. We should be responsible with Member funds, we should ease the effort of the RIRs." Also, in fairness to Skeeve, I was not supposed to take that snide comment from the chatroom to the microphone. That was my error.
CHING-HENG KU: So, if there are no other comments.
SEIICHI KAWAMURA (Government of Japan): I would just like to make one comment. I think it is important that we could think about the needs that may come up, that we might be missing something. But thinking about the needs that we don't see right now or we don't have the exact figures for, and doing something with the /8 is, I think two totally different things. So I think we should leave the /8 as it is and we should keep on discussing what is going to happen when the final /8 goes in and what kind of thing, if we need to save for some critical infrastructure like the root servers. We should keep on discussing that. So that's kind of what I think.
CHING-HENG KU: OK. Maybe I need to make consensus or not. And maybe Bangkok and Laos could be ready for the consensus process. Bangkok and Laos, who supports? Who supports these policy proposal? Please raise your hand. OK, thanks. If you oppose this policy proposal, please raise your hand.
OK, thanks. And so, I think this policy proposal needs to be more discussions, so it does not make the consensus. Maybe this policy proposal can be discussed in the mailing list. Thank you, Wendy.
WENDY ZHAO: Thank you.
CHING-HENG KU: And the next proposal is prop-082.
OWEN DELONG: Point of order--Bangkok and Laos were not asked for their votes.
SPEAKER FROM LAOS: I think we need both allocation and assignment. Because, I don't know, in the future, we change the condition, and we have to change - I think, the allocation and assignments to be stable for us.
CHING-HENG KU: Maybe we ask again Bangkok is support this policy proposal, please raise your hand? Let me check. No. And Laos, do you support this policy proposal 81, please raise your hand?
OK, so Bangkok, if you oppose this policy proposal 81, please raise your hand? OK. Thanks. And Laos, if you oppose this policy proposal 81, please raise your hand. Ok thanks.
So we keep the original result; this policy proposal 81 does not make consensus. So you keep discussing on the mailing list. Thanks.
TERENCE ZHANG: Now we move to proposal 82. Removing aggregation criteria for IPv6 initial allocations. Presented by Tomohiro. Ok, please go on.
TOMOHIRO FUJISAKI: My name is Tomohiro Fujisaki, and today I propose to remove aggregation criteria for IPv6 initial allocation. This is introduction. Current APNIC IPv6 address allocation policy have three kind of criteria. First one is initial allocation for APNIC Members, and second one is initial allocation for Members, and the third one is the subsequent allocation.
This shows the text of each criteria. And I don't explain in detail here, but I think there is a big inconsistency amongst these criteria. And that is only initial allocation criteria have aggregation requirement in it.
I think this is a problem, because if current policy have the aggregation requirement only the initial part, but it can end up with the other two cases, with the aggregation announcement. I think this is the biggest problem. And one more problem is registries such as APNIC, RIRs should not concern itself strongly with routing issues.
So, this is the proposal. I propose to remove the requirement under the initial IPv6 allocation criteria.
But I think the aggregation itself is an important issue. I want to add some strong text to, a combination to this policy document. And this is an example of text. And the aggregation recommendation to the proposal. And this is other RIRs. LACNIC is now discussing the same policy to remove the aggregation requirement from the initial allocation criteria. And RIPE has recently removed the routing requirement from IPv6 policy. And AfriNIC and ARIN have no such discussion now.
And this is advantages and disadvantages. The advantage is, of course reduce the number of requirements to obtain IPv6 address. And this makes allocation criteria consistent and possible to avoid misunderstanding that the aggregation announcement is permitted.
And of course the disadvantage is by removing the aggregation - it, yeah, the deaggregated routes may begin to be announced. I think this is a disadvantage. And this is a summary. I propose to remove the aggregation requirement from the initial criteria of IPv6 address policy.
Thank you. Any questions or comments?
TERENCE ZHANG: Questions or comments from the floor?
SHENG WEI KUO (KTNIC): We know that most NIR only request that one IPv6 address block now and if we can solve the IPv6 allocation for initial request, you will risk a lot, IPv6 rollout, maybe -
JOAO DAMAS (RIPE Routing Working Group Chairman): Yes, I just wanted to confirm that what you said about RIPE, that after much discussion beside the aggregation of routing concerns didn't belong exactly in the address policy. And it's hard to separate that. And within the Routing Working Group, we decided to produce a document that would have a set of recommendations. Everyone here is more than welcome to participate in elaborating that document and also to refer to it once it's done. Or, of course, prepare your own.
MIKE JAGER (New Zealand): I support this, this proposal, just as in the previous proposal, removing the requirement to deploy v6 to qualify for an assignment out of the last /8, the RIR shouldn't be telling the Members what they can and can't do with the address space that they've received. So it should be up to the Member to decide whether they should be able to deaggregate or aggregate or whatever. It's up to them, really.
RAPHAEL HO (Equinix): I agree with this proposal because as an enterprise user of IPv6, I want to multihome to different providers. And having a single /32 assignment makes it, if I must aggregate, it makes it very difficult for me to have efficient routing on the Internet because I'd be taking traffic in from another point and routing it across my internal network versus the external network. So in order to encourage more enterprise adoption of IPv6, we must allow people to deaggregate as necessary. We are not promoting deaggregation but where it makes sense in the deployment, we should allow them to do so.
OWEN DELONG (Mobile : We support this policy. It makes sense for all the reasons others have stated.
SKEEVE STEVENS (Intelligo): It's more of a question to the floor. Although, I support the policy and indeed RIPE have done the same thing in 2009-6, are saying here that we are going to support any level of deaggregation, if someone wants to announce 65,000 routs and then sit there and demand, because of this policy, these sort of things, we will end up with a lot of mess.
And I realize the feelings which are quite clear is that these policies shouldn't be dictating how people design their networks. This seems to be open slather, especially into v6, to cause a lot of damage, especially if people have the right to deaggregate as far down as they like?
OWEN DELONG: So, Terry again comments, "I agree with Joao, routing policy should be removed from allocation policy and so I support this policy on that basis."
IZUMI OKUTANI: I also feel that in the registry's policy, we shouldn't make criteria for routing and at the same time I can see concerns that if we don't define anything anywhere, it might lead to, like, too much growth of routing table. So maybe this is more of a question to the people on the floor here. Would it help to create some kind of operational documentation that RIPE is drafting or we simply encourage people to refer to the RIPE document? I don't know. Maybe it would help to have a separate documentation or recommendation outside of the policy to minimize the impact on routing table growth?
PHILIP SMITH: Yeah, I agree with the policy proposal, again, divorcing aggregation, advice with policy itself. We have RIPE 399 document which was written by the RIPE Routing Working Group with which I'm one of the authors which talks about aggregation recommendations. I think, I mean, I've said this at the RIPE meeting as well, I think it would be pretty nice if the registries--APNIC actually includes this, appointed to this document whenever an allocation is made. It's just an advice document. It's not saying, "You must do this." But it point out some of the risks and dangers of doing some of the rampant deaggregation that seems to be very, very popular in IPv4 space.
TERENCE ZHANG: Anymore questions or comments? Can we look at Bangkok?
RANDY BUSH: Any comments from Laos or Thailand?
TERENCE ZHANG: Any comments?
SPEAKER FROM LAOS: We support this policy proposal. Due to the policy, the number of the requirement, with IPv6, more IPv6.
TERENCE ZHANG: OK. Any more comment? OK. Then now we call the consensus. Anyone support proposal 82, please raise your hand? Support the proposal? OK. And anyone who oppose the proposal 82, please raise your hand?
OK, is that Bangkok? Bangkok - OK. But is that, does it support? OK. Let's go to Bangkok first. Bangkok, you have to raise your hand again. Now it's time for Bangkok to raise your hand if you support a proposal. Bangkok. Bangkok, OK. I see it. OK.
OWEN DELONG: In Jabber, they supported for support for Bangkok.
RANDY BUSH: It takes a long time for sound to reach Bangkok.
TERENCE ZHANG: Is that Bangkok over there? OK. Last time for Bangkok to raise your hand if you oppose the proposal?
RANDY BUSH: Count to 10.
TERENCE ZHANG: OK. It's done for Bangkok.
SPEAKER FROM THAILAND: All support.
TERENCE ZHANG: Let's go to Laos. All support in Laos. That's what I hear, alright. OK. OK. OK, Laos, we declare this proposal reach consensus. Thank you. Thank you very much.
OK, we're going to the next proposal, prop-083. Let's welcome Skeeve. OK, you can start.
SKEEVE STEVENS: I suppose I'd like to start with a comment to the chair, as I feel like I need to justify myself. I'm not a fan of chairing from the floor. And I believe if Randy wants to be a judge or a lawyer, he should choose one or the other. As such, with any of the other co-chairs and some things I'd like to talk to someone at APNIC about policy changes regarding this.
OK, so let's move on with prop-083. This is version two. It was sent to the list about two days ago - it's not much different from the first one. This is a proposal to enable current APNIC account holders that have existing IPv6, so indifferent to the initial allocation, this is that already have an allocation, to receive subsequent IPv6 allocations from APNIC for use in networks that are not connected to the initial IPv6 allocation network where they are announcing that.
The summary of the current problem is that an LIR with an existing /32 allocation, with regard to prop-082, there you have been previously unable to deaggregate due to policy but in additionally, unable to aggregate due to the community practice of filter blocking or bogon lists. That's mainly referred to as the strict filter lists which cause a major problem. An LIR may want to build networks in separate locations and provide IPv6 connectivity. Due to routing problems the LIR can not use the subset of their initial allocation in the new location.
An example is that you've got your initial allocation, let's say in New Zealand, you want to build a new POP in Singapore and you don't have the finances or as such to build an international capacity, which is quite expensive, and you have Customs to allocate to, then, and you've got a different AS number you're announcing from and you're announcing v4 and v6 space, that you may need to get an additional /32 to be able to do so.
This is an example in the current APNIC region, which is the part of the bogon filtering project. APNIC's entire 24 100/12, they filter everything that's not smaller than an /19 and larger than a /32 at the moment.
Situation with the other RIRs. AfriNIC and LACNIC, have not been able to find any other policies. ARIN had a similar policy, 2009-5 which has been adopted. Thank you for David Farmer for pointing it out. RIPE had a similar policy with this same number but it was rejected in favor of 2009-6. And I've read a lot of the comments relating to that and there are some valid points and some, just the way they do business over there in Europe, it's a bit different, but some of the valid points are there.
They rejected 2009-5 in favor of 2009-6 which is the same as our prop-082. The details that we're proposing, point one, is that alternative criteria be added to the subsequent IPv6 allocation policy to allow current APNIC holders with networks in multiple locations, but without a connecting infrastructure, to obtain IPv6 resources for each location.
Number two, to qualify for the subsequent IPv6 allocations, under the proposed alternative criteria, account holders must, firstly, be a current APNIC holder with an existing IPv6 allocation, which is now everybody if they want one; be announcing the existing IPv6 allocation from an AS; have a compelling reason for establishing a separate network which is not connected to the network for the initial allocation.
Some examples are geographic distance diversity, autonomous multihome separate networks, regulatory restrictions, and each additional allocation must be announced--actually, this is an older slide presentation, that should be up in the main section. One of the requirements should be each allocation should be announced from a separate AS number.
The advantages and disadvantages of the proposal. The advantages are enable current APNIC account holders to avoid the problematic network designs and limitations with their current IPv6 network. There are a lot of smaller providers that have POPS across multiple countries. At the moment, there's no way for them to separate out with the different routing policies around the world and upstreams. They'll be able to require resources that announce them separately to transient providers and allow them to sub-allocate, to customers.
The only disadvantage I could find, and in discussion with people, would be faster consumption. However, given the size of the total IPv6 space, I do not believe this seems to be a significant issue. I have a reference slide about the number. At the moment, there are over a million /32s in the current /12 that APNIC have. There is under 3,000 Members, with allocations. Just from a sheer numbers perspective, I'm not a fan of resource wastage but in this case it's sort of a business driver and that's what we're trying to encourage, is people to build their v6 networks, rather than be held back by policy.
The effects are pretty simple; to be able to build networks, same as advantage. The NIRs would be able to have the same choice.
And these are the references that follow through the document.
TERENCE ZHANG: Any questions and comments?
OWEN DELONG: I support the proposal. We've had this for v4 in the ARIN region for a very long time. It was called multiple discreet networks, I believe, and it worked very, very well for us in v4. The recently adopted proposal that brought it forward to v6 was the result of somebody noticing this had been an oversight in v6 policy in the ARIN region. It's not something that we had intentionally avoided until recently, just something we hadn't noticed we missed in the v6 policy development. And it went through the process pretty rapidly with a lot of consensus. I think it's good policy.
LORENZO COLITTI (Google): I question the rationale, if we - so, we're saying that we're not allowing ISPs to deaggregate or we would rather that they didn't in order to, in order to reduce presumably a number of entries in the routing table. If we just assign another block to them, then we have the same number of entries in the routing table, we're using double the space. I don't see - and, also, the RIRs do not guarantee routability of the space. This is an operational issue that needs to be taken up by the operational community.
SKEEVE STEVENS: Perhaps. I don't believe the numbering is the same. If you take your /32 and deaggregate it to eight /35s, just to give one /35 to another country, that ends up with more than two routs. That ends up with about six or so, five or six to be able to do it. Rather than forcing to be to deaggregate down and much further down, maybe more further than they need to be able to split it up, an extra subsequent allocation would be better. Especially this is mainly for discreet networks where it is a separate AS, not necessarily the Google network which is probably one AS around the entire planet.
LORENZO COLITTI: Can't you deaggregate the /32 into multiple places that you spread the blocks around, as it were, but only announce the ones you need?
SKEEVE STEVENS: One of the points of this was the community filtering. Which the RIRs partially influence.
LORENZO COLITTI: That's the operational issue we were discussing. The proposal that was previously accepted just now was in favor of removing the requirement that address space be announced in one block. It seems like we're going in two different directions here. As the policies in various regions converge on not requiring address space to be routed in one single block, and for initial assignments, perhaps this is not the right direction to be going in.
SKEEVE STEVENS: They could be seen as two different directions or compatible directions. The consensus I seem to have here is ISPs being able to do what need to do operationally makes both of these compatible.
JUDITH DUAVIT VAZQUEZ (PHCOLO): I understand Skeeve's concern, that we haven't deployed because of vacuums of policy involving issues like yours. But with the support for the deaggregation, I think it's timely for us to look at the various ways the operators intend to deploy a block as big as this. Moving forward, so in essence, I do support the policy but the how to, the details of which I think need further study. By the operators. Thank you.
OWEN DELONG: Another comment from Terry in chat, "I support this. It seems as an oversight and complementary to the previous proposal. Removing the routing requirement from policy doesn't change the community response to route filtering. Thailand says since aggregation allocation, i.e. 32, is removed from previous policy, this policy do not need additional allocation assignment. Let's deaggregate the allocation and announce from another site but make a standard i.e. /48."
TERENCE ZHANG: OK.
IZUMI OKUTANI: How I understand your policy proposal is that this is for the network that happens to be organizational, it's one. If we look in terms of network, it's separate AS. It's the same as separate network. I think it does make sense to allow another block of allocations. But I think rather than just simply allowing it, it would make more sense to me to add a little bit of criteria similar to maybe like new allocations, for example, make sure that if you have existing v4 infrastructure, you should ensure you make downstream allocation, downstream assignment, rather than just simply allowing a /32 with those with ASN.
SKEEVE STEVENS: No, no. I agree with that. As one of the ideas that have come up that we could make one of the requirements be that you must make sub-allocations. It must be for a sub-allocations or you could be requesting a PI space, that is /48, if you are not going to be making sub-allocations. Some countries do have operations and want their own v6 for multihoming but might not necessarily be serving customers in that country either, so might have it for themselves. So if you aren't going to sub-allocate to customers, you get a /48. If your are going to sub-allocate to customers, perhaps you can get a /32.
RANDY BUSH: Could I ask the room a question? How many operators here filter on a /32 boundary? Thank you.
SKEEVE STEVENS: There were some.
RANDY BUSH: Oh, there we go. Thank you.
SKEEVE STEVENS: I employ the strict filtering on many of the ISP networks we do too.
RAPHAEL HO: Going back to my previous example, where I may have 10 offices around the world, that needs to be multihomed to v6 by this proposal I'll get 10 /32 assignments, one for each of the office, that seems like a horrible waste. Whereas, I can subnet my current /32 just like eight /35s, which is supported by the previous proposal and have just conserved the space. I think the issue is not a policy issue, it's a best practices issue. If the community issues a BCP that says you should filter up to a /35, then that becomes the minimum usable space and conserves the rest of the routing table. I propose we write a BCP as opposed to passing this proposal.
PHILIP SMITH: I've great sympathy with your proposal, Skeeve. The thing that worries me is we're using the policy process to work around what a few ISPs are doing for pretty much no justification whatsoever. That's my disappointment about it. Why are people filtering /32 boundaries, apparently randomly? Make sure some ISPs are getting /32s, others are getting /20s or /26s. What's magic about a /32? It's the same as taking it in the v4 side when APNIC was handing out /19s as a minimum for v4. They filtered rigidly on a /19 without paying attention to what the minimum allocation size was. So, I don't know, I think it's a shame we have to go this particular path. I'm not objecting to it.
SKEEVE STEVENS: I agree it's a shame that we have to go on this path. But the, and I do not want to solve by a policy issue by throwing resources at it and it's not my goal. But we've got business to do. We're trying to get v6 out there. While we're talking about, and I agree, it seems like a waste, but how many v6 allocations have we got and what are the numbers we're talking about? Even if every member got another five, ten /32s and just this RIR, and such as the numbers we were quoting yesterday, so insignificant to be under 0.something per cent and it would still be irrelevant and that would be timesing five, ten, times as the /32 that they have at the moment.
PHILIP SMITH: Yeah, I don't want to discuss the numbers. I quite agree--they're irrelevant. But I'm happy to help writing a BCP. I do a lot of this stuff already.
SKEEVE STEVENS: Unfortunately, these documents don't help. If anyone, and I presume some of the people have been handed allocations from APNIC that have previously been on bogon lists and up to a year or two later, you're still trying to deal with joint organizations like Ebay and PayPal that still have those ranges listed in bogon lists that they just set and forget. Years later, we are still having operational issues. Now, this is not a--and those documents will help for those that read them and care to log in to their routers every now and again--but as we run further and further out, those allocations and with the one dot assignment, we're going to have some major problems. I'd rather in v6, where there is not this scarcity of resources at the moment, let us go forward without restrictions and without these operators which perhaps set and forget.
GAURAB RAJ UPADHAYAI: Um, actually qualify when I raise my hands for Randy's question. We do filter, I do filter /32s, but increasingly, there are so many exceptions that we're going on RIR allocation whatever boundary because there are plenty of /48s and the old /35s in the APNIC region still being announced. Having said that, I agree with Raphael and Philip that this is probably not a policy issue. When I started doing IPv4, we were filtering on /19 and with the filter the /24. As more people do that and get more /48s, I think we'll use the filter as /48 and I'm almost on the verge of doing so instead of maintaining all the sub- /32 in my filters. It's getting more tedious to maintain them. So I would actually, more than changing the policy, if there is a separate AS, separate administrative boundary, they can become separate APNIC members.
They can get their address space. There's a process for that. You don't want the same company having multiple allocations just because they have operations in multiple countries. It's a routing issue and I think the community will change as the number of allocations grows. I'm pretty sure a lot of us recall that /32s are a huge amount of address space. And we can possibly, still announce /35s out and even under the /35, versus breaking one /32 in to multiple /35s doesn't help in the case of the routing table growth. You will still see more prefixes. Why waste space? This is a routing issue trying to be addressed by a policy, and I'm not so comfortable with that. Thank you.
SKEEVE STEVENS: It sounds like you've suggested the same thing this policy is doing. If you suggest that a company can become another APNIC Member, all you're suggesting is that they spend more money to get the same resources. But, with the APNIC fee structure, as it is, they'll pay more money to get the same resources.
GAURAB RAJ UPADHAYAI: Yeah, they do.
SKEEVE STEVENS: It's the exact same solution. You will just suggest a separate membership structure if they want to get those resources which you're OK with.
GAURAB RAJ UPADHAYAI: They'll probably have some administrative overhead and maybe they'll work around that problem. Either way, if there is work to be done, if they need a prefix, if they think it's not working, they will get a new /32, following the existing process. I don't see why this, you know, actually might conflict with some of the allocation schemes used by other RIRs. When you get a address allocation, they use binary-top, so the next time you ask for more address space, you get another one. So what if I'm filtering on RIR boundary, RIR allocation data, I will filter out on a /31. It still won't help their case. This is a routing issue, it's a BCP issue. So you're trying to tell APNIC if I go back for a new address allocation, I should not get addressing block for IPv6. As a network operator, what do I filter, do I still allow two /32s or do I look at APNIC allocation data and say that we got another /32, I'm going to build a /31?
It still won't solve your problem.
SKEEVE STEVENS: What the community does, we can't stop. That's one of the key issues about this policy, is to get around that.
GAURAB RAJ UPADHAYAI: The point is you're trying to make BCP in to the community and say there are cases and issues that come up and work around it. The policy still won't address what I just said.
SKEEVE STEVENS: I understand. The BCP seems to be, seems to be a paper tiger in that that has not helped in any way whatsoever with the v4 bogon lists. The amount of effort and overtime in network operations that we've had to do.
GAURAB RAJ UPADHAYAI: It was a BCP earlier on who said filter not on the Internet. It was true when there was a lot of addresses in the bogons and we all filtered. Now it's come to a point where v4 is running out and we're allocating from that address space and we're seeing the pains. I mean, it was a BCP when I started working on the Internet who said filter this, this, and this out. We took all of them out like three years ago. Saying that we no longer do this and stop bothering about the rest of it and start any time soon. It will take time. It's routing operations. I'm already changing my v6 filters from what I had a year ago and it's probably going to constantly change. Thanks.
LORENZO COLITTI: I have to say I agree. We have, AS 15169 provides transit to various prefixes and they're all smaller than /32 and they're accepted. I think the writing's on the wall for filtering on /32 boundaries. I think allowing entities to obtain more address space in the form of additional blocks, by just saying that they need more will cause lots of requests and you know, corresponding 10 x or 100 x use of address space which is something I'm not comfortable with. We have offices in 50 countries, 100? Do we get 50 /32s?
SKEEVE STEVENS: Depends who you're asking them from and the policies involved in that. The discretion of the hostmasters of APNIC to follow the policy and what the allocation guidelines are, which I'm more than happy for the community input to tighten those policies for specific reasons. One of the justifications on the list was regulatory. There are countries where companies aren't allowed to operate. They have to operate separately and so forth. And at this suggestion, at the moment, it's set up another APNIC Member, which sounds like an administrative overhead that seems to be pointless.
LORENZO COLITTI: When there are regulatory constraints, you can assume there's a fair amount of paper work involved. You need a separate amount of legal entities in that stuff. Applying for a separate APNIC membership seems to be a drop in the ocean of that, frankly. And, yeah.
TERENCE ZHANG: OK. Any more comments or questions from this room? OK. We go to Bangkok. Any comment, questions from Bangkok or Laos? Bangkok and Laos, do you hear me? OK. Seems no questions, no comments from remote. So now we call on consensus. OK, no comments. OK. We call for consensus. Anyone who support prop-083, please raise your hand?
OK. Anyone opposed to prop-083, please raise your hand? OK. OK. Do we need to go to Bangkok? No. Because this room have, OK. Also people on the remote. Because we have a few people opposed to the proposal, so this proposal does not reach consensus. Then probably we can return it to the author and the mailing list for further discussion. OK. What's next, Randy?
RANDY BUSH: Nothing is next. We have, despite the ITU wars taking over yesterday afternoon's meeting and starting late today, we've actually finished the agenda. Does anybody else have any other items, care to speak, etc? If not, those people who run IPv6 can have afternoon tea.
LAUGHTER
SRINIVAS CHENDI: I believe I had a consensus to draw the prizes after lunch time. With your permission, can I do that now? Please. Thanks. Hope you have your tickets with you. May I ask, is Martin here? No. Is Jake Chin here? Can you come up?
Hope we get this one done quickly. There's a red ticket, F53. Any lucky winner? OK. This is looking like we're going to spend our entire afternoon tea here. We got - Adiel!
CHEERING AND APPLAUSE
Red ticket, F53. Red F32. 32. Red F32. Red F53. Oh, that's the same one.
LAUGHTER
you got the cool gift, really, goggles with camera on it. You can start spying on people. We don't have it here, 32. It's a black F94. 94. No takers? Keep going, Jake. Oh, you got? Black ticket, F94.
APPLAUSE
And it's a media-streaming server. High definition. Thank you.
APPLAUSE
I think now we can go for a tea break. And when we come back, we still have one more session, APRICOT's closing plenary. Tonight there is an APRICOT closing reception as well. I believe someone will announce it later. Thank you for your participation and thanks to Laos and Bangkok for participating remotely in APNIC 29 in this Policy SIG. Tomorrow morning we have Members Meeting as well as EC Elections. So we start same time 9 o'clock, in this room. See you then.
RANDY BUSH: Thank you, all.
APPLAUSE