Policy SIG transcript
APNIC 25
Policy SIG 1600-1730
Wednesday, 27 February 2008
Table of contents
Welcome and introductions
Introduction to the policy development process
Overview of policy proposals at APNIC 25
IPv6 per address fee discussion
End policy for IPv4 address space in APNIC region
prop-057: Proposal to change IPv6 initial allocation criteria
prop-055: Global policy for the allocation of the remaining IPv4 address space
prop-050: IPv4 resource transfers
Action items from APNIC 24
prop-052: Cooperative distribution of the end of the IPv4 free pool
prop-058: Proposal to create IPv4 shared use address space among LIRs
prop-053: Changing minimum IPv4 allocation size to /22
prop-056: IPv4 soft landing
Large IPv4 address space Usage trial for Future IPv6 Deployment
Welcome and introductions
TOSHIYUKI HOSAKA:
All right, it is 16:05 on my clock. I'm Toshiyuki Hosaka from JPNIC and this is the Policy SIG session setting the scene.
I have some Housekeeping notes before entering the session. Number one, we have APNIC social event tonight supported by Nominum from 7 pm to 9 pm, which is held at Shintori 5. Registration at the information desk and more information can be found on the website.
Number two, APRICOT closing event sponsored by Cisco will be held on Thursday tomorrow from 7 pm to 9 pm.
Number three, APNIC informal dinner will be held on Friday from 7pm to 9pm. Transportation will be provided and if you're interested in joining us, the cost TWD$600. The payment will be required on Friday morning. More information will be available at the Helpdesk.
Number four, Helpdesk is now available Osmanthus Room, level two. There are various prizes.
Number five, and this is the last house keeping note: Win a digital frame when filling in a survey online, it is available at APNIC meetings website. The closing is Thursday 28th of February. The winner will be announced during the last session of the day on Thursday 28th of February. So, that's it from me.
So let's begin the session. So, Srinivas.
SRINIVAS CHENDI:
Thank you Toshiyuki.
Good afternoon all and welcome to Policy SIG: Setting the Scene. This is a Policy SIG, however we will not be discussing any policies or will the presenters present their proposals here. This is a direct result of the member survey that we did in 2007 where the members requested stability of the policy proposals, so this is the first time we're connecting this session here. So, those who are in this room and those who are participating remotely can participate in this policy process.
So, without taking much on, I would like to introduce some of the key persons of this Policy SIG. As you all know, Toshiyuki Hosaka is the chair of the Policy SIG, he's been serving since March 2007 up until February 2009.
Next we have Jian Zhang from CNNIC, she got elected as a co-chair in Delhi September 2007 and she'll be serving until August 2009.
And, Randy Bush who is sitting on the stage here from IIJ, he's also a co-chair of the Policy SIG. Even he got elected at APNIC 24 in Delhi in September 2007 and he'll be serving until 2009.
We also have some staff working at the Secretariat, that's myself, and also we have Samantha Dickinson who is, Sam, if I can ask you to stand up and wave to the people, please. That's Sam. Thank you, Sam.
I'll pass it on to Jian Zhang for the policy development overview and the Policy SIG chat.
Introduction to the policy development process
JIAN ZHANG:
Good afternoon, everyone. I'm Jian. I'm going to do some introduction about our policy process. Our policy SIG charter is develop policies and produce procedures which relate to the management and use of Internet address resource for APNIC RIRs and ISPs within the Asian Pacific region. We do have two mailing lists - one is a policy SIG, one is for policy SIG, SIG policy at apnic.net and the other is for policy SIG chairs only.
Our policy development process is an open process. Anyone can propose policies and anyone can discuss policy proposals. Also this process is a transparent process. APNIC publicly documents all the policy discussions and decisions and most important is this: The community drives policy development. It's a bottom-up proposal.
This is actually a diagram to show our whole process. Four weeks before APNIC meeting, you can start to submit proposed policy to the APNIC Secretariat. The SIG Chair will propose it to the mailing list. The next one will be the community which discusses the proposal on the SIG mailing list. During one week-long APNIC meeting, we're going to have a face-to-face discussion in SIG session, that's in this meeting, that's going to be tomorrow. We're going to have a full-day policy session.
Any proposal if we had consensus that policy session is to go to where the SIG chair will report the session to AMM. If we got consensus on AMM, we're going to do eight weeks long, final call for public comment. Just go to the public comments, it will be eight weeks long.
At that point, the community will discuss the proposal on the SIG mailing list. The SIG Chair posts the outcome of the SIG mailing list discussion.
After that eight week period, if we do get consensus, we go to proposal, actually, the proposal goes to EC. The proposal will be endorsed by EC. If at the EC meeting, they get consensus, it is going to be APNIC is going to be implemented and doing implementation. Minimum, it will take three months long. So, you can see, if we didn't look at consensus, the proposal could be either discussed, or go back to the mailing list to start the discussion again. Basically, that's the full process of our policy development. Any questions?
Thank you.
TOSHIYUKI HOSAKA:
Thank you, Jian. Next, we are going to briefly explain what proposal is coming up tomorrow. The explanation is from Randy.
Overview of policy proposals at APNIC 25
RANDY BUSH:
There will be a three minute break while the slides are being finished! In the meantime, I'll figure out how to do things like plug in my laptop. Technology is wonderful!
OK. The purpose right now is to review for you, what the policy proposals are that we will discuss tomorrow so that you have a chance to get an overview of the detail of them and we hope, read them before we get to seriously discuss them tomorrow. The reason for this fluffy overhead is because we have people from many languages and cultures, and it is easy to just, for people whose English is a first language to go, blah, blah, blah and leave everybody behind. So the purpose here is to review them for people who have questions, to understand what the proposal is, please ask, please interrupt. OK, the purpose here is to be able to review and see what the proposals are. We have a lot of them which is one of the reasons that we've done it this way.
Prop-050 is resource transfers. This one is, the problem is current policy says that if I have some address space, the only way that address space can be transferred to Okutani-San is by business merger acquisition, etc., and then it is the full APNIC policy process. We believe that as a community, there's likely to be a large demand for v4 after the IANA pool is exhausted. And we also believe, and it is not here, that there already is an existing trading market. People are actually buying and selling address space, we just don't talk about it!
And lastly, we think that there needs to be a way for the APNIC resource registry to accurately reflect it. If people are trading in the black market now, the resource registry doesn't actually represent reality. OK, because the reality is, excuse the English idiom, 'under the table'. I believe these were essentially Geoff's goals in this proposal and the proposal solution is to remove the policy restrictions on transferring IPv4 space between APNIC account holders. This says that only address blocks which are larger than a, the block is larger than a /24, that the prefix is equal or lower than a /24 may be transferred. In other words, you can't transfer /27. APNIC is not going to say how LACNIC does transfers.
The transferred block will be subject to all current policies. In other words, if I want to transfer a /23 to Okutani-San, she must justify the use of that space, in the same way that we do today. And the source - in other words, whoever is selling or giving away - can not receive any future address blocks for APNIC for 24 months. Hey, if I'm giving them away or selling them, why should APNIC give me more resources?
When this proposal was made just before the Delhi meeting, it was presented at the Delhi meeting. Because it was within the window, it was not presented; it was not published long enough before to have adequate discussion. It was not considered by our policy process, which Jian described, it was not fair to discuss it and try to get consensus at the Delhi meeting, so now, it's been discussed on the list and now we can actually process the proposal.
So, Geoff modified it from the discussion at the Delhi meeting and took into account many comments, not mine of course! And there have been 35 posts on the subject, and here's the 11 people, and here's the distribution of the people. OK, not the distribution of the posts, because of course, three plus three plus five does not equal 35!
The discussion, OK, there have been similar proposals in RIPE and ARIN. They're at about the same stage of progress. I think ARIN will be discussed in Denver? The proposals are active, right?
FILIZ YILMAZ:
There's a new version on the way.
RANDY BUSH:
Yes, but it is an active proposal. So, some of the serious questions about how to enter between RIR transfers take place, in other words why does this proposal restrict it to the APNIC people? Would people come forward to do it, would it work? The people who are buying and selling under the table, will they actually do it publicly now?
It allows one prefix to be swapped for another. So, the prefix doesn't need to leave the RIR pool it originally came from. In other words, this is to try to help aggregation. Right, I could return a piece and a different piece could be issued. You know, you could trade it through the registry and aggregate that one. There have been people asking, "why is it /24?" OK, any organisation anywhere is free to become a member of APNIC, and therefore could become a recipient of it. So, is that a hole or is that a feature, and what does that mean about this?
An organisation to transfer part of its address block while keeping the rest of it. In other words, is this something they can do? Should it be something they can do? I have a /16, can I sell a /24? Does anybody have any questions on that proposal? Not discussing, pro or against, but is it clear to everybody what that proposal is and how it is being discussed? Am I going too slowly and everybody already knows all of this? Or am I going too fast for some people? Everybody is going to take a nap! Then, how come I can't take a nap! That's not fair!
OK, prop-052, co-operative distribution at the end of the free pool. The problem statement is, what happens when the IPv4 pool space is unallocated in the pool after it has been exhausted? In other words, APNIC has two /8s left when ARIN runs out. This proposal says when one RIR starts running low, the RIRs work together to transfer space from that RIR with the most remaining space to those needing it the most.
Then it goes into detail, and RIRs within 30 days of the end of whatever it has, request a block sufficient for three months with the longest allocation window. As it becomes smaller, RIRs forward request addresses for their region to the other regions. In other words, APNIC still has a /12 left, and RIPE has run out, somebody from Germany will send a request, and RIPE will forward the request from somebody in Germany to APNIC for allocation from APNIC. Am I fairly representing this?
TONY HAIN:
Yes.
RANDY BUSH:
So, proposals on the 28th of November. After New Delhi and plenty of time to be formally discussed here. To be clear, the process that Jian described is specifically long and has all of these steps so it can be fairly heard by everybody and everybody has a chance to speak to the proposal and about the proposal, ask questions, etc. That's why we have this long post. There was one post on the mailing list from one person from Japan. That person said, is this rather operational procedure rather than policy? I have to confess, that person was myself! In other words, I asked, procedurally within this SIG, how deeply we want to get into discussing how the RIRs operate as opposed to what allocation policy is.
Another proposal. Questions on the previous proposal prop-052, going once, going twice.
Prop-053, changing the minimum IPv4 to a /22, it is currently /21. Small ISPs cannot afford the annual small membership fee. There are two things buried in here. One is the fee. The other is the allocation size. The proposed solution is that this proposal makes is to change the allocation size from a /21 to a /22 and create a new tier, 'Tiny' for /22 allocations. The discussion was fairly large. It was posted on the Policy SIG mailing list on January 8. It was posted in the window. OK. There were 21 posts on the list. 9 people... OK, you can read! The discussion on the mailing list and there's now a modified proposal to change the minimum allocation size from/24 to a /22. Originally it was /24, when it moved to /22, when the proposer moved that to /22, a number of people removed their objection. A number of people were concerned that /24 was overly fragmenting address space, etc. Some people asked, is the introduction of new 'Tiny' membership tier appropriate? Why don't we have the existing membership tier?
The initial IP resource application fee is the real issue. It's not the address space fee, it's the initial one. Why is it so expensive? Somebody else said, "should fees be discussed at all in the Policy SIG?" Or the APNIC Member Meeting, and if you read the By-laws of this organisation, it is the Executive Council who decides fees. One thing that may happen tomorrow is trying to separate the fee from the allocation proposal.
That's about it. Any questions? Global policy of the allocation of the remaining IPv4 space. This is something we've been discussing for a while. The problem is that the global coordinated policy we have now could mean that the last RIR gets four /8s, and none of the RIRs who need it the next week get any. So, we want to continue, the proposers want to continue applying a global coordinated policy, but we need to match the reality of the situation.
Issues each RIR will face during the exhaustion period varied by regions as the level of development of IPv4 and IPv6 are widely different. As a result, applying one coordinated policy may not be the best way of doing things. The solution proposed is, at the end, IANA will hold one /8 for each RIR. I.e., five /8 s and we currently have about 41 or something in the IANA pool.
OK, later, when IANA receives requests for IPv4 space that can not be fulfilled from the remaining free pool, in other words, when they get down and those five are left and another request comes in from LACNIC, that triggers the event that causes all five to be allocated, one to each RIR. Then if LACNIC requested four when there were six left, that remaining /8 will be allocated to the last RIR that made the last request. So, just a little fudging of the math to make it work.
The two separate proposals in New Delhi have been merged. It has been coordinated now. One proposal was from the LACNIC region, one from JPNIC etc. They have all actually gotten together and made one proposal they agree on. There have been eight posts listed, two from Australia, one from Japan, two from outside the Asia-Pacific. Is there another one for this one? Yes, discussion on the mailing list.
One of them is, hey, if we don't know what are we going to do with the last /8, what are we going to do about it? What should APNIC do with that? Another said RIRs can not have restrictions about allocating them which are not in the RIR region so there could be RIR shopping.
OK, could be not so much a problem because only one /8 is involved. Without a restriction on requests from outside the region, this proposal has no impact other than raising awareness. In other words, if somebody from ARIN can come here and eats from the same rice bowl, then, what's the use? OK.
I want to add an additional explanation, and one that I said in New Delhi. I originally thought that the proposals were crazy. In New Delhi Okutani-San made me meet the proposers and that this allows RIRs to plan what happens in the last kilometre before the car runs off the cliff. We're not going to stop running off the cliff, it just allows us to make sure that we eat the picnic lunch or whoever had the last glass of wine before it happens. It just allows planning. OK, and that's the intent here. I finally understood that. Questions?
Soft landing. This proposal said there's a problem with the availability of IPv4 and a lack of deployment for v6, so therefore, we want to promote the efficient use of the scarce IPv4 resource, and this specifically is going to draw a curve as things run out. So, for instance, it says when there are 10 /8s left in the free pool, then, you must explain things a bit more and you must demonstrate a greater degree of efficiency than today. So, all this is saying is details about, as the free pool gets smaller, we get tighter with allocation.
The solution which this institute has set, guidelines and phases, OK, using the amount of address space in the IANA free pool as the driving number and then we have the requirements for allocation which have become more stringent. There will be four phases depending on how much is in the free pool. Those are /8s, and if for instance, and the proposer has a nice table. To show what's there for each level, there's plenty of time to be voted on in this meeting. There have been six posts for these people, one from Australia, two from Japan and another from outside. The discussion was kind of like: What's the use? It's going to run out anyway. We're playing with the last little bit and the other side of that, and so when the proposer said, oh, I guess that's true, I'll withdraw the proposal, a number of people said, yes, but it's in the right spirit. It communicates what we need. Maybe we should keep the proposal.
So, we're going to discuss that tomorrow. Oh, more! Right, so Geoff Huston says, his usual projected figures from the management, and should, therefore, this proposal be withdrawn? The proposal is not the end, it sends a message. The projected figures may or may not be good. The new version will be discussed tomorrow.
Proposal to change the IPv6 initial allocation criteria. Currently, you are required to have a plan for making 200 assignments within two years. This is being misunderstood for many reasons, one of them language, another just "what about my plan?" In Japan, having a plan is pretty close to "this is the way it's going to happen." Other places is, a plan is like those marketing diagrams which look like a hockey stick. Like yeah, I've got plans for it, sure. I'd love to. So, this attempt here is to try to make it clear and make it fair. So, the idea is to add an alternative criteria that allows an LIR to choose between making a plan for at least 200 assignments, or be in an existing registry with IPv4 allocations which starts to make IPv6 assignments or sub allocations and announces the allocations in the global routing system within two years.
So, it was posted on January 25th? Is that the window? It is. There have been 63 posts. This is the winner. 17 people from a number of places.
The discussion was, "was the revised additional criteria in the Version 2 more acceptable to many people?" The discussion of what is meant by 'plan'. This 'plan' implies, does it imply commitment? Must it be done or is it like, yeah, I think I'm going to do that? We assume that any organisation with an IPv4 allocation also requires an IPv6 allocation. Maybe they don't. Any policy-related blocking to IPv6 adoption should be removed. Is that one kind of clear?
Prop-057, two more to go. Oh, this is the same thing. I think I see it. Prop-058, the last one.
Proposal to create a shared use address space for IPv4. So, some LIRs providing firewall and IP connectivity services behind NATs using RFC, that's 192.168 are having address space collisions between end-user networks to choose the address space and themselves. This is preventing LIR end-users benefiting from the security and efficiency of IPv4 addresses that use firewalls and NATS. Some people don't believe that NATs provide security. Instead, some LIRs are applying and receiving global space to solve this problem. Furthermore, if LIRs assign only IPv6 addresses to end-users, they can not communicate with the non-IPv6-ready sites.
What's proposed is, APNIC takes another /8 as an IPv6 shared use address space for LIRs in the APNIC region. By shared use space, what they really mean, I believe, excuse me, is it make it private like network 10? In other words, create Network 10 prime, is that fair?
So, this shared use address space will prevent collisions between two interconnected LIRs using the same RFC 1918 space. Because, one of them can use Network 10 and the other use network...whatever the new one is. And actually, all it does is reduce the problem by half. You don't know what the other shows. Global uniqueness is not guaranteed under the proposal, of course.
It's been discussed, there were 20 posts. There's where they came from. So, six people produced 20 posts to discuss it.
The discussion was, mostly, could be useful in the double NAT world. Is APNIC the forum, is it IANA or IETF? Does it need to be a global policy? One thing that's interesting to note is that if APNIC picks a /8 and says this is now a private address space, anybody in any region could use it that way. Because it has been hidden. Questions? You just want to go and have more tea!
MR SHIRAHATA:
I have a question on the proposal.
RANDY BUSH:
You need to say who you are.
MR SHIRAHATA:
I have a question about a proposal prop-050. Is this proposal, for NIR from JPNIC to... as an organisation like an APNIC member. As I know, this proposal, the proposal seems to be, does not care about focus through NIR.
RANDY BUSH:
I'm not sure what you're saying.
IZUMI OKUTANI:
For communication of what he just explained, he wants to find out if the address blocks managed by NIR are also taken as a part of consideration of this policy, or is this out of scope?
RANDY BUSH:
It says in the APNIC region.
IZUMI OKUTANI:
So it also includes the blocks included by NIR.
RANDY BUSH:
I could be incorrect and I could be correct and yet misrepresenting the intent of the author, who I think will wander towards the microphone. But as far as I know, it says APNIC region.
GEOFF HUSTON:
Prop-051, section 7, effect on NIRs, and I quote "this policy does not encompass those from NIRs nor the transfer of resources where they are in the NIR service entities."
TOSHIYUKI HOSAKA:
Thank you very much for your excellent briefing and we are going to have a policy discussion tomorrow, so let's see you tomorrow at the Policy SIG session.
We have 35, almost 40 minutes and taking that time, I would like to go through some informational presentation here, so the APNIC chief scientist would like to say something about IPv6 discussion. Geoff.
IPv6 per address fee discussion
GEOFF HUSTON:
Thank you, I'm actually wearing the hat of the Executive Secretary of the APNIC Executive Council. Late in 2007, around August I believe, the Executive Council referred the matter of a reconsideration on aspects of policy prop-031 back to the Policy SIG. Policy number 31 actually concerned the HD ratio to be used in IPv6 address allocations. And also actually concerned with the calculation of the utilisation factor with the endsite address size. The implications of that decision on the per-address fee was calculated. The APNIC people would like to say that they have reconsidered this and they respect the policy outcomes regarding the HD IPv6 HD ratio of the utilisation factor. And recognise that there is a fee issue that has been raised by an APNIC member that will require further study, but the EC will conduct that study in terms of the fee implications of this for the per-address fee. So, the bottom line is that the APNIC EC does respect the policy outcome and would like to withdraw that particular discussion item from the Policy SIG, and would like to inform the Policy SIG that they will take the fee issue and study it themselves and make an appropriate outcome from that.
Thank you.
TOSHIYUKI HOSAKA:
Thank you, Geoff. Like, Randy said, EC has the right to make a decision on the policy of fees. So, I think, I personally think that that is the right thing to withdraw the discussion from Policy SIG. So, next, we have Okutani-San to present. She's from the Asia-Pacific region for the policy proposal.
End policy for IPv4 address space in APNIC region
IZUMI OKUTANI:
Is this on, OK. It took a bit of time to get started. Good evening, my name is Izumi Okutani from JPNIC and I would like to have a brain storming kind of discussion on how we are going to use the last piece of address block that APNIC will have at the time of IPv4 address exhaustion. And, some of the ideas that I will introduce, it's not fixed, so if there are any suggestions for improvements, other ideas, comments, for or against it, they're very welcome.
Just to explain the relationship with the proposal I will be making tomorrow at the Policy SIG, the proposal I will make tomorrow will be discussing about how IANA will distribute the last bits of its address block to each RIR and this presentation. This informational presentation intends to discuss how APNIC will distribute the last piece of IPv4 address block within its community.
So, why discuss it? Maybe some people feel we can simply distribute it based on the current policy, we don't have to change it, we don't have to decide anything. But when you think about the largest issue at the time of IPv4 address exhaustion, although IPv6 is available as an alternative address space to IPv4, when we look at the actual situation, not many people are using IPv6 yet, and the majority of the Internet is still using IPv4. So, we must think about this transition phase where people are, although they're aware that in the long-term, they have to move into IPv6, they still feel the need to access and operate on IPv4 base.
So, what I tried to consider in this presentation is, consider ways of, not just in terms of operational area, but if there is anything we can think in terms of address management, how APNIC will effectively use this address space in order to consider this issue. I haven't come up with a concrete specific policy proposal this time, because I wanted to see what are the areas that we should focus on.
So, what I've done is list and classify the target or functions that uses IPv4 address space, and then consider for each function what happens if IPv4 address space is no longer available, and if there's any particular target of function that we should give priority to distribute IPv4 address space. And after we have some discussions here, I'm hoping as a next step that we can come up with a concrete policy proposal based on the needs of the community.
So, maybe this category is not perfect, but it is a brief category how I classified the types of networks based on IPv4. First, the big category is new IPv4 networks and the second is existing IPv4 networks that already receive IPv4 address space and operates on IPv4 Internet. Then I subdivided it into ISP network, within that, they have different functions. They need a pool for subscribers, also to operate servers, or in the future to operate NAT translator machines. And even within endsites, they might operate servers or the translator machines. So, you've sub-divided these depending on the type of network and the functions they have.
The second chart I've shown is that for each function, if there are any alternative ways to resolve or connect to IPv4, if they are not able to receive additional new IPv4 address space and the possible choices I came up with is first to use RFC 1918. The alternative is to use IPv6 space for the parts that don't connect to the Internet.
The third option, the third option is only available for existing networks, not for new networks, but more effective use of available IPv4 address space they already have. For example, if they already receive a /21 and use, I don't know, say a /22 for new subscribers, maybe they can use private space for the part of the subscriber's pool and then have the extra additional /22 now available that they can use it as a global address space, so maybe these are also options. So, for each function, I have categorised if these options are available.
The observations I've made as a result is that for pool subscribers, they don't necessarily need to have global IPv4 address space. They can assign either private address space or IPv6 for users of connections and then they can switch into... if they are using IPv6, they can use Translator. If they are using private address space, they can NAT it in order to connect global IPv4 connection to the subscribers. However, for other functions, such as servers for NAT Translators, they definitely need a global IPv4 address space.
The second observation I made is that for endsites, both new and existing, if they're upstream, ISPs are able to provide some kind of NAT for translator function to endsites, maybe it is also possible, even if there are servers, they can first assign private address space or IPv6 to individual machines and then maybe the upstream provider will be able to switch to global v4 address space. This might have technical issues and possibly, maybe not all ISPs are happy to provide this kind of service, so, this is just one idea, but it could be possible that endsites don't necessarily need global address space even for the servers or even for the servers.
And the third point is that those with... sorry, I was just trying to read what I was writing! Those already with IPv4 address space available in their networks, they have needs to efficiently use IPv4 address space they already received in order to make it available for their servers or NAT or Translators as I explained earlier. Then again, it has limits. It can't exceed the size they already received. For example, if they already received a /21 but they need, I don't know, a /20 for their servers in total, of course, this can't be a permanent solution, but it can, if it is a small number that they need for their servers, it can still be a solution.
And the third point is that as a result of reviewing each of these functions and alternative solutions, the function that has no other alternative whatsoever seems to be the address space that new ISPs will need for their servers or NAT or translator machines. So, after these observations, how far should we consider these needs for IPv4 address space for each of these functions? We can have a policy either very moderate and let's allow all servers to have IPv4 address space, or if we try to make it really strict, we should only allow NAT or translator machines of new ISPs and also there are other possibilities in between. So, when we try to brain storm all of these possible options, as a personal opinion, I feel that allowing all servers or all translators, including those for endsites, I think the target will be too large. Almost all endsites have servers and it is quite possible that most endsites will have translators or NAT machines, so I think it will not be very effective as policy if we try to make the policy too large.
So, a realistic possibility could be, either to allow for translators or NAT for ISPs, so, should we include new or existing or only restrict it for new ISPs?
Another point is that assuming that we only allow new ISP networks to receive address space, would it be sufficient to only allow what they need for their servers or do they need a buffer for their NAT pool, and I think we should also consider these issues as well.
The questions I have to the people who are here today is, do you feel that such consideration is useful and are there any suggestions on other alternatives other than what I've listed over here? Or, is there a particular function that you feel that they should give a priority to receive address space? I would love to hear your opinions in these points and after the discussions, the next step would be to consider the criteria that best fits what the community would need in order to address the issue at the time of exhaustion. Thank you.
TOSHIYUKI HOSAKA:
Thank you. Any comments. Any questions? Clarification? No? Thank you very much.
So, we can finish all of the agenda today. Yes, so see you all tomorrow and before we complete this session. We still have some housekeeping announcements from the APNIC Secretariat for tonight's social.
MIWA FUJII:
After this session, we have MyAPNIC BoF from 5:30 to 7:00pm. The room is Magnolia Narcissus room, at the same level B2, here right across from this room. This is from 5:30 to 7:00. Please feel free to join this BoF. Tonight, we have APNIC social event this evening. We are meeting at this hotel side entrance, but if you go to the lobby of this hotel, the APNIC staff and TWNIC staff will guide you to the bus. Buses leave at 6:30, but there is MyAPNIC BoF which is finishing at 7pm so the last bus leaves at 7pm. The venue is Shintori 5, and please don't forget your name badge and the social event is available from here. That's it.
RANDY BUSH:
I've read the reviews of the place, it's not bad!
TOSHIYUKI HOSAKA:
Thank you, so see you all in the social event and please don't drink too much! Don't miss the Policy SIG tomorrow! Thank you very much for your participation.
APPLAUSE
(End of session)
APNIC 25
Policy SIG
Thursday, 28 February 2008
9:00-10:30
TOSHIYUKI HOSAKA:
Good morning, everyone. The Policy SIG session will begin very shortly. I have some housekeeping notes today. Number one, we would like to acknowledge Google for sponsoring our Policy SIG sessions. Thank you, Google. Number two, you can participate in sessions using Jabber Chat. Directions are available via the APNIC website. Number three, APRICOT closing event sponsored by Cisco will be held today from 7pm until 9pm in the Shin Chang Hall. Transportation will be provided. The first bus leaves at 5:45pm. APNIC dinner will be held on Friday from 7pm until 9pm. Transportation will be provided. If you're interested in joining us, the cost is $600 Taiwanese. Number five, Helpdesk is available in Osmanthus room during the breaks. Number six, when filling in a survey online, survey forms will be available online at APNIC meeting website, closing date is afternoon tea today. The winner will be announced during the last session of today.
So, today, we have seven proposals to discuss. Yesterday we had a session to explain these proposals briefly. So, some of you who attended that meeting are now well-known with those proposals, I think.
The first proposal to be discussed today is proposal prop-057. Proposal to change IPv6 initial allocation criteria discussed by Izumi Okutani.
prop-057: Proposal to change IPv6 initial allocation criteria
IZUMI OKUTANI:
Good morning everyone. My name is Izumi Okutani and I would like to make a presentation on my proposal which proposes a change in the initial allocation criteria for IPv6.
The general background is that we have voices raised through ISPs in Japan, especially small and medium ISPs and IDCs who feel that the current criteria is a barrier for IPv6 allocations. Also, when we look at the situation in other RIRs, all other RIRs, except APNIC, actually the communities feel the same way and they have removed this change as part of the criteria which is an issue. So, let me just briefly introduce the current criteria, and out of all of these criteria from A to D, part D is an issue here. It is the part which says that a requester must have a plan for making at least 200 assignments to other organisations within two years.
I think if you just look at the number and then think in terms of IPv4, it doesn't seem to be a very strict criteria: 200. But, when we actually look at the current situation in IPv6 where it is not really commercially taking off in general, really trying to see if they can really achieve this number. Some people feel that this is a bit too strict, and they don't feel confident that they will be able to make this plan.
So, the current problem is that although when this policy was drafted, the proposal authors felt that LIRs, ISPs of a certain size, that if it plans to make assignments to other organisations should be eligible to receive IPv6 allocations. Even though some of the ISPs who were intended to be the target of this allocation feel that this is a barrier. This I've represented in this diagram over here.
So, we need to explain, oh no, actually, even though it says 200, we don't really mean it and it is not strict, so the plan is just a plan, but every time we have to do this explanation about the original intention of the policy, and it is not easy to read the words as it is.
So, I feel that the measure we should take is to redefine the criteria so that the intended target of the original intended target of the v6 allocations should be able to read the criteria and feel that they're eligible to request for v6 allocations.
From my understanding, I think the intended target for IPv6 is generally ISPs or organisations of a substantial size that makes assignments or some allocations to other organisations. We shouldn't just give it out to anybody, so no endsites and probably the scale of organisation should be pretty much the equivalent of the organisations which make IPv4 allocations.
So, that's the kind of idea that I have, and based on this, the basic principles should be that when we revise the criteria, the criteria should not be easier, looser than the original intention. We shouldn't give it out to organisations that are too small or no end sites.
And the second point is this - we should also look long term, not at this stage where IPv6 is not commercially taking off. We should also think that the criteria is reasonable enough and we shouldn't end up giving it out at the time when IPv6 becomes actually the major part of the Internet.
The third point is that the organisation should actually use IPv6, they shouldn't just feel, oh, I want to keep it just in case or you want it use it for the experiment, or we're not sure if we're going to use it, but it is just good to have a v6 address. So, based on these three points, I came up with a criteria which I believe would meet the basic principles.
Where we still maintain the current criteria as an addition which is to plan to make 200 assignments within two years, so that once IPv6 takes off, people will still receive assignments based on the current criteria. Then, as an additional point, what I've added was that if you are already eligible to receive IPv4 allocations, I would assume that you're already large enough as an organisation; and so, if you plan to deploy IPv6, we can probably assume that they would have a reasonable number of customers once the customers transfer into IPv6. In addition, in order to ensure that they actually will use IPv6 address space that they receive, they must announce their route, they must make route announcement of the allocation that they receive.
So, the letters marked in red is the part that I added to the current criteria.
In comparison, this is the situation in other RIRs, and as you can see, none of the RIRs currently make the 200 assignments as a 'must' criteria and I think our criteria is a combination of AfriNIC, ARIN and RIPE's policy.
So far, from my understanding, major issues based on the mailing list, because at the beginning I didn't have the route announcement as part of the criteria, so some people felt that maybe people will just request for IPv6 address space, but end up not using it. So to prevent this, I have agreed to add route announcement within two years as part of the criteria, and so that's being revised. And maybe, perhaps some people still have issues with the wording of the proposed criteria that maybe it is not strong enough to request for a commitment, so, I don't really have a very strong preference about it. We don't require people to feel that it makes it feel like an obligation and the wording is pretty much consistent with other APNIC documents.
Thank you.
Any comments or questions from the floor?
FILIZ YILMAZ:
I have a question and a comment: You said that the intention of this policy proposal is to cover the LIRs who don't have a big customer base, but themselves are, the LIR itself is big enough and they want to make assignments for themselves. Is that right or did I misunderstand that?
I'm short! Alright, maybe this is better now. Just a question first. At the beginning of your presentation, I thought you said that the intention of this proposal is to have those LIRs who don't have maybe 200 customers at the organisations to make assignments. You don't cover organisations or big enterprises or other organisations who want to make assignments to themselves.
IZUMI OKUTANI:
They're not the target. So, just to clarify, I think Filiz's concerns is that LIRs which receive IPv4 assignments, just to assign to their own network and not to provide services to other people, and your question was, 'is my proposal intending to cover those people?' And my answer is 'no'. Does that clarify the point?
FILIZ YILMAZ:
In our region, this was changed. 200 criteria was removed, but at the same time, the end-user or endsite definition was also changed, so that now an LIR (with a university for example who doesn't have third parties as a commercial sense as customers but they still have students), they still now qualify under our policy with that change. They are qualified now.
IZUMI OKUTANI:
Right, in that case, I wasn't really sure. I think there are two ways. With the condition that you mentioned, I believe that they should qualify under this as well. What I had in mind was like a big corporations for example, multinational organisation like maybe McDonalds or whatever, where they have lots of networks. But only assignments within their organisations and they don't provide any connections services or hosting service. Those organisations shouldn't qualify for this criteria. They should apply for a portable IPv6 assignment.
DAVID WOODGATE:
David Woodgate from Telstra. I wanted to say that I support this proposal for the reasons outlined. In particular, I find it very difficult at this stage of IPv6 deployment to understand that it is easy for a lot of areas to say there are definitely 200 places which need to be deployed. But, if somebody wants to put IPv6, if an endsite of an LIR wants to put IPv6 on now, and if the LIR isn't capable of getting the IPv6 address because there are only 10 or 20, then it is stopping the type of IPv6 deployment that I think we're all trying to encourage here.
IZUMI OKUTANI:
Thank you very much.
ROQUE GAGLIANO:
Roque Gagliano from LACNIC. There was a 200 requirement from some years ago.
IZUMI OKUTANI:
Thank you for the input. Any other comments.
PHILIP SMITH:
Philip Smith. I'm happy to see the development that this policy proposal has made on the mailing list. I think this is a great thing, but we could have the discussion beforehand and I must commend the authors for being open to the discussion and participating; it is fantastic. I would like to see other policy proposals do the same thing. As you see, Izumi, I started off not being keen because I travel a lot, most ISPs I work with understand what a plan is. Randy explained yesterday what some of the issues were with certain economies and to understand those, so the lettering in, well on the screen there, I think that is a good addition to the policy proposal, which I think will clarify the issues for those parts of the region that were having problems with the planned concept. So I support this. Thank you.
IZUMI OKUTANI:
Thank you very much.
JIAN ZHANG:
This is policy proposal for the SIG consensus today, so, for those who are in favour of this proposal, please raise your hand.
OK, who is not in favour and oppose this proposal, please raise their hand.
I didn't see anybody. Any hands? OK, so should I say we have reached consensus of this proposal? Thank you.
Next one, we're going to discuss prop-055, global policy for allocation of remaining IPv4 address space. It is also going to be presented by Izumi-San.
prop-055: Global policy for the allocation of the remaining IPv4 address space
IZUMI OKUTANI:
Izumi from JPNIC again. Now I'll be presenting about another topic and this time the topic I'm trying to address is what we're going to do about the address pool that IANA holds at the time of IPv4 address exhaustion. So, it tries to define how IANA will distribute the last pieces of IPv4 address blocks at the time of v4 address exhaustion, and I assume a lot of you in this room are already familiar with the proposal, because it is a revised version of the proposals which were made at APNIC 24.
At that time, there were two separate proposals with a different number of /8 blocks to be allocated to each RIR, and the first proposal was the proposal on the top, proposal from JPNIC and proposal prop-051 from LACNIC and AfriNIC. So we combined the two and made it into a single proposal.
Just to share the background, I'm sure all of you, I don't really need to repeat it too much into detail, but the IPv4 address exhaustion is projected to take place within the next few years. For the details, please see Geoff Huston's website.
So, in order to prepare for the situation, I'm sure there are many issues we have to address in terms of operations, also like impact on ISP's business, things like that. But, also we try to think what we can do in terms of address management area. We try to divide it up into two phases.
First, before the exhaustion takes place, and the second is after the exhaustion takes place, and I think the focus of the issues we should address depending on which phase we're at, for the first phase before the exhaustion actually takes place, I think it would be important to focus that there will be minimum confusion at the time of when we address the last pieces of IANA blocks to RIR, and as well as to distribute the last pieces of RIR blocks to its communities.
But, once the address exhaustion takes place, of course, there's no more new unallocated blocks to be distributed, so, the focus will shift on how we're going to manage and actually ensure that the authentic owners of IPv4 assignments will be able to keep using it, and keep track and a correct record. And I think both of these issues are important, but in this proposal, we would like to focus on the first part: What we're going to do. Minimise the confusion at the time of IPv4 address exhaustion.
The current problem is that since we haven't really properly defined how we're going to distribute the last piece of IANA block to RIRs, and I think some people may say, we can just carry it out under the current policy based on consumption. However, if we do that, it would be difficult for RIRs to plan the distribution of the last pieces of blocks in their representative regions because they would not know until the last minute how much address pool they would have under their management. This would especially be of an issue if a particular RIR feels that they would like to use a part of our /8 block for a special purpose which would help to address issues at the time of address exhaustion. And in case that they don't feel that way, they feel that we're just going to distribute the address space under the current policy based on consumption bases, even if all of the RIRs decide to continue under the current policy, I think it would still help to know in advance how much address space you would be able to get from IANA at the last block in planning their distribution of address space to its LIRs, and also inform the communities and the timing of the last request that they should make.
And I would like to share this in a chart in a little bit more detail later. So, the measures we should take is that we should probably define how we're going to distribute the last piece of IANA blocks to RIRs to reduce the confusion at the last minute.
The proposal, to put it in short, it is very simple. The idea is that since we have five RIRs at this stage. So, once IANA's address block hits five times /8, we should distribute a single /8 each to RIRs. That's the basic idea and these are the details of what we're going to do.
First, we would like to propose IANA to separately reserve five times /8 blocks from the standard blocks that they manage in order to allocate to RIRs.
Then, the second step is that IANA will continue allocations under the current policy until the standard, regular IANA pool runs out. And once this pool runs out, then IANA should proceed to allocate one /8 each to RIR from reserve block from out of the five /8 s. That's the proposal. And to show a diagram of how this is going to help, I've made a comparison of how this is going to happen if we didn't apply this policy and if we do apply this policy.
We can think of three different cases if we didn't apply this policy, and though we think in terms of APNIC region, the first case is that APNIC questions the address space and then they're able to get what they wanted. For example, let's say there are five /8 blocks in IANA available, and then APNIC would like to request for two /8 blocks. Then, in this first case, first area comes and requests, and then three /8 blocks available. APNIC is the next one to request, so they're able to receive the blocks that they requested.
The second case is that APNIC is able to partially receive the blocks they wanted, but because other RIRs made a request in advance and there was not enough space available in IANA, so even though they wanted to receive two /8 blocks, there's only one /8 block available, so they were only able to receive part of what they actually wanted.
The third case is that APNIC is not able to receive the blocks they actually wanted because other RIRs made a request before APNIC. So, if we didn't apply this policy, we can see the three different patterns, and it is not easy to predict what's going to happen, how much address space that APNIC is able to get at the last minute. So, it can vary from no subsequent allocations, or more than two /8 blocks, and it is difficult for the communities to know what to expect. I mean, how much address block is there available in the respective RIR regions? And then, consider if they can make the request or not.
So, if we apply this proposal, the idea is once IANA's address block hits five times /8, equally distribute one each to each RIR so we would know what's going to happen. So, that's what makes the difference.
The impact on the address, on applying this policy is that if we didn't apply this policy, the additional free pool that an RIR is able to receive can vary from zero to more than two /8 s. If we apply this policy, it is certain that each RIR can certainly receive at least a single /8. So, for an RIR with large consumption rate, it might lose the chance of receiving more than two /8s, but equally, they can save themselves from not receiving any /8 blocks. So, it is more like a guarantee and knowing how much they can receive at the last minute.
The situation in other RIRs is that in the AfriNIC and LACNIC region, consensus was reached on the framework. And in our region, although there has not been any official consensus on this, but when we looked for the raise of hands and show the opinions of the participants, more number of participants expressed support by the show of hands than those against this proposal.
In the RIPE region, well, I wasn't there myself, but from what I heard, there was no consensus, but there was an agreement on continued discussions on this proposal.
So, any questions or comments?
JIAN ZHANG:
Thank you Izumi-San. Any comments.
DAVID WOODGATE:
I find it difficult to support this proposal on the basis that there is no company plan for the final use of the /8. While I appreciate what you're saying about the need for APNIC to have a plan for the final set of addresses, I believe that a plan should be made without having a specific /8 address made against it, and B, that there's enough time to do that before the end, or rather if it is not done now, it's never going to happen anyway.
So, I find that without that sort of solid planning and without that activity taking place, I can't see the benefit of this proposal, rather than against just running out according to the current procedures as they are.
IZUMI OKUTANI:
OK, thank you for your comments. I agree with your points that if there is no proposal at this stage on how APNIC is going to distribute the last piece of address block, then it could be possible that this proposal is passed and then APNIC just carries out to distribute under the current policy. And in my opinion, I think there's two benefits, even and to carry out to distribute in the current policy which implements this, but I understand your point. Thank you.
GEOFF HUSTON:
I would like to respond to what you said there, and in actual fact, that's not precisely correct. If you're looking at the situation of run-out and you're looking at five independent RIRs each making allocations from, sorry, requests from IANA and then handing them out, if you, according to this policy redistribute the last five /8s according to this, you're going to get a different distribution. And what you're actually going to find is that the RIRs which are consumed the fastest actually lose by one /8 and the RIRs which are consumed the slowest win by one /8 if you use the words like 'lose' and 'win', but it has a different outcome. So your statement, even if we did nothing in policy and did the same for the current policies and the /8s, they would be identical, that is not the case; the outcome would be different and substantially so in terms of where the resources actually end up. So, unless there's a plan here as to what to do, which there isn't in this proposal, you are indeed arguing for a substantively different outcome in the last set of resources. I'm sorry, but that's just the way it works out.
JIAN ZHANG:
Anybody else?
TONY HAIN:
Partly responding to Geoff's point, I don't have any serious concerns about the proposal. I don't believe it makes a whole lot of difference. For Geoff's point, it is possible that there could be a difference; you can't predict it now, you can't say that the slowest would necessarily win if they happened to be the one that got there last anyway because of their timing. They could actually be better off the other way around.
GEOFF HUSTON:
It would be different. It would not be the same outcome. Sorry, my comment in question was, irrespective of what the difference is, I'm simply saying that the outcome would be different.
TONY HAIN:
So the final distribution point is different, but to my policy proposal which I'm sure we'll discuss at some point, it is what happens at the next piece which matters. So, I don't think that this proposal is necessarily bad or good. I think it is fine to do. It allows people to have the perspective of knowing what's going to happen. From that perspective, I think it is good. Some level of predictability in the system, but it is the next piece that really makes the difference here.
PHILIP SMITH:
Philip Smith from Cisco. I think I've been long on the record of not really seeing what the point of the proposal is. I suppose I've said I've been against it for a while because I don't see the point, and I think I would still be against it because I don't see the point. We already have all policy procedures and so forth with APNIC.
What I'm curious about though, you have another thing listed on the agenda which is discussing what to do with the final /8, and it is only just a discussion, and I was kind of hoping that maybe it could be, well, not combined, but partnered with this policy proposal and another joint policy proposal; give it a separate number and bring the two together because then they will explain to the community how the final /8 will be handled in a different way.
At the moment, even if this goes through, it is still the current APNIC policies that determine what happens to the final /8, and all you need is an ISP with a huge deployment that will probably gobble up half of it and well, what's the point? We've spent all of the cycles in these meetings from, well the APNIC meeting, and how many other meetings in the other registry regions are discussing this. But, my standard complaint is, what are you going to do with the final /8?
So, I think you're tantalisingly close to making this something which could be useful. But as I say, with the presentation on the agenda, if it is presented as a policy proposal. My position at the moment is, as people said, rearranging the deckchairs there.
IZUMI OKUTANI:
Point taken, and to Geoff's comment earlier, we noted that for the RIR, a large consumption rate, if they were eligible to receive two /8s, they would lose one /8, but with the RIR with the large consumption rate, they could have gotten zero, even with two /8. So I think it is difficult to say that I would lose out.
I take both Geoff's point and Philip's point that even though I personally believe there is still benefit to this proposal, the merit is not as strong if we define how we're going to use the last piece of IPv4 for the APNIC region at least. So, in general, as a personal opinion, I still feel the benefit, but I understand the points that Philip and Geoff have made.
JORDI PALET:
I am against this proposal. I have expressed this several times in different regions. My view is that it has been said already by some other people. We really need to have a plan if we go for this proposal for this /8. If we don't have a plan, I think it is actually an unfair proposal, in the sense that the proposal is trying to be fair with regions which may have less /8s right now. But actually, it may be the other way around because it may happen that in other regions that they couldn't complete... because they couldn't complete the proposal without a specific plan for this /8. In addition to that, I think that whatever we try to guess from the future from one region or another, it can change. It can be, I don't know, a catastrophe, so geographical situation, so movements of people from one region to another.
What are we going to do if that happens? We're going to make another proposal to go back with this one? I really think it is better to stay in the situation where we have policies implemented in other regions and keep going that way, and in addition to that, I think trying to make this is not really going to help the problem that we have before exhaustion, so I don't see that that is a good thing. Thank you.
DAN ALEXANDER:
I think you can correct me if I'm wrong, but the impression I get from this is that everybody needs to come to terms with what they're going to do with the last /8. I don't get the impression that that plan should be incorporated into this proposal, because everybody's needs will be different. It should be up to each RIR to make those plans. The intent of this is simply for each registry to agree to the fact that we will ensure that each registry has one /8 in order to make those points accordingly.
IZUMI OKUTANI:
Thank you very much. That's actually the point of the proposal. Thank you for clarifying that point.
PAUL WILSON:
Paul Wilson from APNIC. I listened to the discussion in the ARIN meeting last year and drew an analogy which I thought was helpful. I would like to repeat that here in case it is also helpful.
I come from a city which has been in a severe drought for many years and there's been serious discussion about the fact that the water could run out within the next 18 months. Luckily, there's actually been some rain there, but we're not going to have the same. I think we know we're not going to have the same relief in the case of IPv4 addresses.
But, if you imagine the prospect of the water in your taps being switched off or run out at a completely unpredictable time in the future, then I think that's a fairly scary prospect. You don't know what the other people around you are doing with their water. You're just trusting that you're all working in the mutual interest. But I think when it comes closer to the time or when you're looking at or anticipating the time where the water is finally switched off, your city might give you the opportunity at the end of the supply to fill your bath tub up and have a supply of water for your own use as you see fit.
I think if I was in that situation, I would take that opportunity. Because even without knowing what I was going to do with the water, I would have a supply that I knew was under my control, that I could make decisions later. I mean, I know that that water will come in handy, and I know that by having it under my own control, I've got some control over my destiny, and I'm not subject to what everybody else is doing around me, which might be having a shower or watering your garden or doing other things which I might not choose to do myself.
So, I think just looking forward and imagining the situation, I can see, similarly, this proposal gives each regional community control over its destiny at the final state, the final period, and even without knowing exactly what we're going to do, we know that we will have the opportunity to run some policies and make some decisions between now and then. Thank you.
IZUMI OKUTANI:
Thank you for explaining the essence of this proposal by analogy.
DAVID WOODGATE:
Just responding to the last speaker, two thoughts go through my mind. One is that I'm not sure that this is a particularly unpredictable run-out in that there's close monitoring going on at the RIR levels, so I think that they will be quite well known when we're getting up to the last batch.
And my second point, and possibly more relevant, is that if there isn't clarity for the last /8, irrespective of whether it is allocated for this policy or coming to the last one, coming to the last one and through to the current allocation procedure for IANA, then it doesn't actually matter. You know that you've got the last /8 because you're probably still going to allocate it in the standard way anyway. If you think that there is a requirement to have a plan for the last /8, if there is particular infrastructure requirements or something else, then they need to be identified now and to meet those plans. And then, we'll probably be in a better state to say, well, we need to do a particular reservation along the way.
ALAIN DURAND:
Alain Durand from the ARIN region. When the first proposal came out a while ago, it was about five /8s. I was opposed to that because I thought it was very expensive. Now that it is down to one /8, I think it is more economical. To go back to Geoff's point, the outcome is different, but marginally different, but at a burn rate, one /8 is less than a month. That's very, very small. So, it seems to me that it's a small price to pay collectively to introduce a little bit of predictability, and as Paul said, that everybody essentially has the destiny. So I do support this.
RAY PLZAK:
Since the effect of this proposal is for the depletion of the IANA free pool for the left, I'm wondering if Geoff or anyone takes those types of forecasts as made in such a forecast and what the new date would be?
IZUMI OKUTANI:
So, is that a question to Geoff?
RAY PLZAK:
I guess it is Geoff. How far to the left does it shift?
ROQUE GAGLIANO:
Actually, I'm one of the authors of the proposal since my last job, so I just want to give a little bit of background. We started this proposal almost a year ago. Actually, the idea when we started the proposal was to have a very different number at the last location was to separate a discussion, if the global community thinks if this was a good idea. And then, also trying to discuss what should be the size of this allocation.
Several years after it came out, in a global sense, there was an agreement but we were proposing it. I have the feeling and we have the opportunity to get a global consensus and to go forward to the idea of the equal. After the discussion we decided the allocation. In the regional proposal, the proposal was to allow each region to decide what to do with the last allocation. The basic thing is discussing inside the region is far easier, and far more simple to get it approved than doing it in a global way. Each situation could be totally different, and the outcome could be totally different.
What's being discussed here, there's other proposals about having a maximum number of allocations, /8s, etc., and the good thing is that it can be solved faster, say less than a year, in six months. However, doing the global policy is way more difficult and we're going to be running. If we approve this process, it will be around 18 months.
And the other issue is that this will come back. In giving a message saying, 'OK, that's what we're going to do' and allowing this to kind of close the discussion so far, what we're going to do with the last allocation and we can have other discussions, because we know with the proposal we have today, there are many discussions about different issues, but it allows us to move on and not to come back to that topic and back and back and back.
IZUMI OKUTANI:
OK, thank you. I think Paul's analogy on water really describes the point that you have made in a very comprehensive and compact way. Thank you for your comments.
TONY HAIN:
Going back from July to about end of February 2010 kind of way. So, it doesn't really affect that much.
BILL MANNING:
And I'm going to speak to Paul's water analogy. If we are in an IPv4 drought condition, which arguably we are, APNIC currently knows that there are, there is a certain amount of IP space available, and if they really want to have a slush fund, a kiddy pool or a bath tub to do with what they want, one of the /8s that they're going to get in the next three years, they can reserve. And hold it in abeyance until afterwards, until after everything has run out and they have the store that they can then use. APNIC can do that now without trying to implement the global policy.
IZUMI OKUTANI:
True, but you may want to use it as efficiently as possible in distributing to the people who need it until the last minute.
PAUL WILSON:
We actually can't do that now because it is not recognised by the IANA allocation policy. So if we were to put a /8 into reserve, we would have no way of demonstrating it for the purpose of ongoing allocations from IANA.
GEOFF HUSTON:
Geoff Huston, APNIC. In answer to Ray, the answer is around 132 days. What actually goes on is that by that time in March 2011, the allocation rate out of IANA is approval of 1.2, 1.3/8s per month. If you back off by five /8s, you back off into November 2010. However, let me point out one thing here about the work for Tony and myself, phenomenal uncertainty.
Over the last two years, the RIR system made 15,300 allocations, which is a lot over two years: 7,500 a year. Of those, 203 allocations consumed half of all that space. So, in other words there's a very small number of allocations which are relatively big and a large number of allocations which are relatively small in terms of number of addresses.
Whenever we do these predictions of run-out days, we're assuming that the relatively small collection of folk who do large demands appear uniforming throughout the year; they don't cluster and bunch. That's not true, but I don't know when they're coming next. No one does. So, when we say it will move by five months and so on, we really are talking averages. Reality is going to be different I can assure you, but I'm not sure that any of us can understand precisely the degree of difference at this point. So, the rule of run-rate, we're talking around 4.5 months. In reality, I really don't know.
RAY PLZAK:
You can take the same rationale that you're applying to the IANA pool and apply it to the remaining free pool of the RIR. So the one /8 could last forever, or the one /8 could be consumed quickly by one provider.
GEOFF HUSTON:
The biggest allocation we've seen in the past two years has been a /11.
The argument is correct that when a legitimate request comes through and it is the size of a /10 or a /9, the most of it would govern one transaction.
RAY PLZAK:
So what really is important to save some time is that this actually makes no difference. The real difference is what does the RIR do for the internal provision?
GEOFF HUSTON:
I think I have to agree with that logic.
IZUMI OKUTANI:
Can I just clarify before we move on to the next speaker. The intention of this is not to provide a projected date of exhaustion, but to ensure that RIRs know how much address space they have, and they are able to receive it at the last minute. So, if they receive a large /8 request, they can think, OK, so I can expect to receive another /8, so I can allow this request, or I'm not really sure how much space I will be able to get. So, even if this organisation is requesting for a /8, it is going to impact the rest of my pool.
So, I might request then to hold the allocation size a little bit more. It allows RIRs to make these kinds of plans, so the main intention is not to make a correct projection the of exhaustion date. I hope that clarifies the intention.
ALAIN DURAND:
When you think of the argument in favour of this, it could be seen as transparency in the case of running to the bank of an RIR and going to an RIR in trying to get the remaining five or six /8s. Essentially what we do if this happens, automatically the distribution of /8s goes to the other registry, and I look at this as a very, very positive thing.
IZUMI OKUTANI:
Thank you.
ROQUE GAGLIANO:
Roque Gagliano speaking as the author of the policy. When we went around in different RIRs, one of the arguments you find in favour was that actually, as Ray said, when people try to promote policies inside RIRs to change the allocation policies, they realised that the community was not willing to go because they were just saying 'we don't want to be at a disadvantage in front of the rest of the RIR to start getting more allocation from IANA'. So, the advantage that was seen on this policy is it could be a trigger for those allocation changes inside the RIRs.
JIAN ZHANG:
If there's no comments any more, we're going to seek consensus on this one. For those who are in favour of this proposal, please raise your hand.
So raising the hands for supporting this one.
For those who oppose this proposal, please raise their hands.
Thank you.
So, I think at this point, we didn't reach consensus in this proposal. Thank you.
IZUMI OKUTANI:
Thank you.
JIAN ZHANG:
Next we're going to move to prop-050, so I'm going to switch back to Toshiyuki Hosaka.
TOSHIYUKI HOSAKA:
Thank you, next proposal from Geoff Huston. IPv4. Since we have 30 minutes until the coffee break, so probably after Geoff makes his presentation, we're going to go to a coffee break and using that time, please approach to the proposer or to your concerns or questions, clarification and so on. And discuss the proposal and queries at that time.
TOSHIYUKI HOSAKA:
The switch is not working. I will read it. After this proposal we discuss prop-052, cooperative distribution of end of free pool. The proposal to create a shared user space among the LIRs and 53, change allocation of /24 size to /22. If we have time to ask, if you have time, I will call on the information presentation the IPv4 space for future IPv6 requirements at the end of the session. Geoff, are you ready?
GEOFF HUSTON:
I'm ready, is there video on this? This microphone is right up there. I'm Geoff Huston with APNIC, it is the second time...We are not talking about anything because the microphone is dead.
TOSHIYUKI HOSAKA:
Switch on the bottom.
prop-050: IPv4 resource transfers
GEOFF HUSTON:
Hello? Hello. The non-functioning switch is on the bottom. Right, now it is working. My name is Geoff Huston, I am with APNIC, it is the second time I'm presenting the policy proposal, slightly revised since New Delhi. To give you some background on this, it is obvious what we had planned about moving to IPv6 was going to rely on a fair deal of time where both IPv4 and IPv6 is actually inside the network and being used. When an IPv6 packet starts on its merry way through the network, you can't transform it into an equivalent IPv4 packet unless you know a lot about addressing.
The entire issue if you want to do this transition, you have got to dual stack. That means having v4 addresses available to you through that period. However you look at it, you have got about three years left of the current run on the unallocated pool of IPv4 addresses, at most.
Considering the current consumption rate of addresses from the unallocated pool is in excess of 180 million /32s a year, you appear to have very little capability to complete the transition inside the time available. So at some point, you are going to need to keep on running dual stack over an increasingly larger network, but you haven't got addresses to do it from the unallocated pool. There is a bit of a problem flying around there. It is likely, highly likely, that the broad industry demand for IPv4 addresses is going to extend well beyond any calculated time at which the unallocated address pool runs out.
So once the RIRs have nothing left and industry wants more, what are they going to do? How can you ensure that addresses maintain their uniqueness? How do the registries maintain their integrity? How do you know, as ISPs, the address you are being asked to route is really YouTube's and not someone else's? The problem is the industry will continue to grow. Addresses will continue to be fielded to meet demand and that, one way or another, industry are going to move addresses around between themselves.
So what are we, the registries, going to do to support that? We can either wait to right near the end and panic or perhaps we can look at it now and figure out what are the options available and how can we react to this and actually underpin the most likely scenarios, even now. The transfer proposal is relatively simple.
What it says is that after APNIC runs out, we have got nothing left to give, folk will move addresses between themselves. If we do not recognise that transfer, then our registry, our version of a routing resource and an Internet route registry, is going to be become historical rather than accurate, which is useless. What this proposal is is to simply recognise that when two parties move addresses between themselves and their current APNIC account holders, APNIC will recognise the transfer and record is in the registry.
The finer details, right now, across most of the world, if you have an address block smaller than a /24, it is not going to get routed. The de facto minimum size out there in the routing world is indeed, a /24. This tries to not make the world any worse in that respect, so the constraints are the address block that gets moved is a /24 or larger, no smaller. It also says we are actually, in APNIC, have that address in our registry. So the address block is administered by APNIC.
For those of you who have been around an awfully long time you'll remember there was a large legacy. APNIC hasn't been here forever and there are address blocks whose status is historical or legacy. Those addresses are not part of this proposal. The addresses that can move are current and have a right of use from current APNIC members. The address block, of course, is subject to current or prevailing APNIC policies.
Also, in terms of registration, what the registry actually contains is a binding between an IP address and a known entity. That is what is in the APNIC registry. So in terms of doing a transfer, we actually like to understand the two parties to this transfer are, in fact, known to APNIC, so the registry transfer can indeed continue to recognise reality as it stands.
So this entails the constraints on the source of the transfer are that they are a current APNIC account holder, their membership is current, they are, indeed, the member who has the right of use of the addresses, the registered holder of the block and they can't simply go to APNIC, get some addresses, transfer them out and go back to APNIC and say, "Whoops, I didn't mean it, I need some more." So once a disposer transfers addresses they can no longer go to APNIC and request an allocation or an assignment for a period of 24 months.
Now, today, that makes a lot of sense. Once APNIC has run out of unallocated addresses, well, you can wait for as long as you like, but in essence what it says is while APNIC has addresses in their unallocated pool, once someone disposes of addresses they are ineligible for further address allocations. After the 24 months, if we have still got addresses, fine. They would need to provide additional documentation to APNIC justifying the change of circumstances that now means they have a legitimate request under the terms of the APNIC policies. So if they do come back in 24 months, we are requesting they provide further documentation as to why their circumstances have changed.
For the recipient, it is a little bit simpler: We know them. They are a current holder, they are in the registry. Of course, the recipient is subject to all the prevailing APNIC policies and any fees associated with that resource holding then becomes a liability for the recipient.
The details on the transfer: In terms of making sure that we are not party to unscrupulous actions we are requiring for a transfer to happen at the registry. Both parties need to notify APNIC the transfer should be made, and the details of the transfer published in a separate transfer log so that all such transfer transactions are recorded separately in the log of these. And the APNIC EC may levy a fee on that; the policy permits a levy of a transfer registration fee.
Policy proposals normally require some assessment of the advantages and disadvantages. We are two things, and perhaps the second role has never been as prominent as the first. Currently, the Regional Internet Registries - APNIC is no exception - are an allocator of previously unallocated resources. We distribute addresses according to policy. Equally, and in our second role, we are an authoritative independent registry of where addresses are, who actually receive those allocations and assignments. The advantage of this particular proposal is that in the case where parties are transferring address resources between themselves, we are ensuring the APNIC registry can be current rather than historical, and maintain a consistent and accurate registry of precisely where those addresses are today.
If we want any form of integrity in a network, if you don't know who has which address, you cannot preserve uniqueness and you cannot have a network.
This, indeed, is one of those survival things of the Internet. If the way addresses move changes, the registry must reflect the changes in order to be relevant and accurate. Also, bringing up a transfer market tries to avoid some of the worst excesses in attempting to ignore it. If transfers are indeed inevitable, if the demand for IPv4 addresses outlives the current unallocated pool, addresses are going to move. If we, as the Regional Internet Registries, and APNIC in particular, do not recognise those, it will still happen. We will not register it. When someone comes to you on a dark street corner at night and says, "You want a used /16?" who are they? Is it really theirs and are you the only buyer, and what is the price? Indeed, how do you make sure transfers operate with any degree of integrity and stability unless you bring it into the form of an open venue and publish the transactions as they occur?
It is attempting to mitigate some of the risks on suppressing it; we need the addresses to support your stack. If you don't have them, then really, really, incredibly strange things are liable to happen. The disadvantages: For many years, the RIRs have been in adherence to a general principle that addresses are not property, addresses are neither tradable, viable or sellable; and certainly, transfers do permit the formation of a market, and indeed do permit various forms of market distortions emerging.
This does not say that APNIC is the regulator of any such market. It exclusively does not even say that APNIC hosts any such market. That's beyond the direct control of the view of APNIC. And if various forms of market distortions occur, they will occur at the incentive of the players, and other folk might find regulatory functions of it. I do not believe that this function says that APNIC should do that. There is the potential for process abuse because of unmonetising goods, to see if there are opportunities and exploit them.
There is the potential for some further routing table growth, although, frankly, I do not believe it is terribly great. The current behaviour, if you analyse the last few years of allocations, is that consistently, consistently, most allocations are sliced and diced between a /20 and a /24 in the routing system.
Over the last few years the routing system consistently has at least 62% to 65% of addresses are more specific of aggregates. It wouldn't change that, make it much worse or much better. In other words, the routing system fragments for reasons beyond allocation. Anyone who believes allocation policies have an effect on the fragmentation of the routing system, I believe, has not been looking at the true data sitting inside the routing system. There is some potential but I don't believe it is high.
Since the proposal was presented in Delhi, there have been two other proposals presented in RIRs. The first one was RIPE, 2007/2008 and I believe one of the authors is here. Is that right, Nigel? The brief summary of slight differences. There is a terminology difference: I have current account holders and these proposals, party holders. A subtle difference: in APNIC, a /24 is the minimum, in the RIPE, the minimum size is a /8 I believe, I believe that interpretation is correct. There is a fascinating sentence here, allowing permanent and non-permanent transfers. Non-permanent seems a remarkably innovative approach. I am very tempted to listen to a suggestion to allow also non-permanent transfers. What it means is that if someone wants to use an address for a period of time, by doing a non-permanent transfer of the registry, the two parties involved are locked in. The lender cannot renege on the deal for the period of the transfer. The RIR becomes, if you will, the broker or holder of the contract. I like the idea of non-permanent and I think it is quite innovative.
Of course, the last one here: Address blocks must be certified, referring to the resource certification process. Again, this is not inside APNIC, but there are certainly merits to doing so.
The ARIN advisory council has put forward a proposal on their public policy mailing list. I believe, if I understand the ARIN policy development process correctly, it is not at this point a formal proposal that is under discussion. Someone may correct me on that subtle distinction, but the advisory committee itself hasn't formally adopted it.
SPEAKER FROM THE FLOOR:
A formal proposal.
GEOFF HUSTON:
It is a formal proposal. Thank you. The difference is by and large in the constraints of the source and the recipient. They use terminology of transferer and transferee. I have found it confusing, so I have rewritten it: The disposer has not received resources for 24 months after the transfer. The acquirer, the transferee, may only make one transaction every six months and can't dispose for a further 24 months, and must be qualified under ARIN as requiring the addresses. It is quite a significant change on the proposals before RIPE and APNIC, and the IP block is the minimum size constraint. There's a lot of detail, but I think it highlights the major differences.
There are considerations here at looking at each of the proposals in a broader context and trying to understand why these proposals are subtly different. What were they trying to achieve and is the outcome what you want? The constraints: To what degree do you apply constraints to the disposer, and the block itself and the acquirer. Imposing tight constraints on who is allowed to say "I have got addresses, do you want them? And who is allowed to say "I need addresses". You minimise the possibility of middlemen who acquire addresses but don't need them, but sit on them releasing them at a later price. It can prevent hoarding, fragmentation and speculation.
On the other hand, whose job is it and what are you trying to do? Scarcity in any market leads to pricing that has scarcity premiums. IPv4 is a scarce resource, and following the exhaustion of the unallocated pool, it is a very scarce resource. Pricing signals will occur. Are those pricing signals unnatural? I would argue they are natural and realistically part of the reason why IPv6 has not been adopted. So far, the pricing signals are not strong enough. Folks see the path of least resistance, that offers the greatest benefit for the minimal expenditure, is IPv4. That is why we run it. If pricing makes IPv4 much more expensive, the intention to transfer becomes stronger. Do you, indeed, encourage IPv6 by allowing scarcity pricing to appear in a market? The answer may well be you do.
The other thing is addresses will move, whether the RIRs recognise it or not. Needs, where there is supply, demand, and demand always happens. A very excessive constraints setting encourages the formation of transfers outside the framework of black and grey markets. If you are too constrained, it happens in place.
People argue the trading will completely explode the routing system, dominated by 16 million /24s in the routing system. Part of the question is just how fragile is today's routing environment? Precisely how close to the edge is it? Certainly one could argue 250,000 entries in the routing table, and modern routers are capable of holding millions of entries, we have a large margin in today's technology and routing.
One could argue the existence of fragmentation through traffic engineering hasn't changed in the last few years and pressures remain, irrespective. I'm not sure the complaints, if you will, or disadvantages that this will make routing infeasible are well analysed from my view. And I'm not sure at this point they have made the case that is a consistent and logical argument, given the current data.
What distinguishes the data from an existing fragmentation practice? I really can't tell.
Why are we doing this? Are we doing it to make v4 last forever to actually make a transition work without blowing up the Internet on the way? Is this meant to happen for decades or meant to happen for as long as it takes this industry to understand the signals around v4 and v6. If we are looking at a measure that is intended to last for a small number of years, a decade at most, versus a measure that is intended to last for centuries, precisely what constraints and structure of transfers is necessary? I would contend if we are trying to introduce a new system of allocation in v4 and v6 and intended to be a different way of doing things forever, that is an entirely different proposal than one that says you have an immediate tactical problem. The signals around transition are not happening.
You need to have v4 addresses for a longer than we can sustain from the unallocated pool for a transition, and you need pricing signals about scarcity to get you into the phase. Are we looking at a long-term viable market in v4 addresses to sustain an IPv4 network forever or mitigating the risks of the intended transition to IPv6?
What are RIRs when we are no longer allocators of IPv4? Are we registrants of outcomes or, indeed, trying to facilitate a redistribution of addresses by hosting, and indeed, by operating a transfer market? I would contend that we are indeed more like a title office than actually running the exchange.
I would argue that transfer policy proposal recognises the transfers take place but leaves the facilitation of transfer mechanisms to other parties who may be interested.
There are three proposals out there from this region and the RIPE region and the ARIN region. Should these be regional proposals? Is there scope for global? Should we try and do a coordinated policy proposal, noting the last time we tried it took years - and I'm not sure we have that much time - or should we instead look at ways policies like this can recognise and encompass across RIR transfers; so that if a disposer is ineligible in one region and an acquirer is eligible under APNIC's policies, could the transfer happen without policies themselves being the same?
I think I'm on time at 10:30 and I think you are proposing to hold questions after the break?
TOSHIYUKI HOSAKA:
Yes, thank you very much for your punctuality. We will have a coffee break at 11:00 and we will resume then. Thank you very much.
APPLAUSE
[END OF SESSION]
APNIC 25
Policy SIG
Thursday, February 28 2008
1100-1230
Action items from APNIC 24
TOSHIYUKI HOSAKA:
Hello, everyone. Welcome to the second session. We'll resume very soon. Before accepting the questions from Geoff's proposal, let me show you the Policy SIG action items which I missed to show at the start of the session.
So, open action policies pol-23-005. For the formal policy proposal at APNIC 24. This is the update. The proposal is not presented at APNIC 24. The proposal is now abandoned on Policy SIG mailing list after no objections received.
And the action item 24-001, chair to return prop-046 IPv4 countdown policy proposal to the mailing list for further development by the community.
The APNIC 24 update, a new version which was presented a few moments ago, prop-055 of the proposal will be presented at APNIC 25.
So, 24-002, pending approval at each remaining stage of the policy proposal process APNIC Secretariat to implement the proposal prop-049. IANA policy for allocation of ASN blocks to RIRs.
This was endorsed by the APNIC EC on 13 December 2007.
Action item 24-003, proposal author to post a revised version of prop-050. IPv4 address transfers to the Policy SIG mailing list for further discussion.
And the version two of the proposal is now presented at APNIC 25. So, thank you very much.
Now, I will hand over the mic to Geoff.
GEOFF HUSTON:
I will ask for questions, comments and anything else at this point.
ALAIN DURAND:
I wanted to talk about transfers. They have to think about the processes for the community at large talking about RIR, to go together and talk about the prices and how to regulate the industry of markets. But I'm really afraid is that if you open up a market like this, you can't take it back. And when you say, "oh, this is only for v4", and then move to v6 and you say there will be no problem, well, if the market is being created and it is unregulated, the first thing that's going to happen is that a regulator will come. It is going to be really, really hard to explain to that regulator that it is only for v4 and not for v6. So, we would end up in a situation that's going to be extremely different from where we are now, and it is very hard to predict how this is going to go. I'm a bit afraid that essentially, you are doing what is described as opening up a Pandora's box and we don't know where we're going.
GEOFF HUSTON:
In response, let me first say RFC 1744. Look at that; it dates back to 2001 or 2002, maybe earlier. It actually discusses this whole issue of the ability to determine addressing policy, who has it and why. The reason why we've been able to create bottom-up process, the reason why we've been able to create a policy framework around addresses has actually been because of the unallocated pool. Our ability to actually say "we give you these addresses on the basis of demonstrated need" and so on and so forth, all hinges on our ability to do so. Once that pool of addresses have been distributed and goes away, our own ability naturally to regulate that allocation function disappears with it.
Now, in v6, as far as I'm aware, the pool of unallocated addresses is pretty big. Really, really big and it is not going to go away in the lifetime of any of the people in this room as far as I can tell.
So, that ability to regulate the market by, if you will, allocating, a certain function always exists in v6 while the pool exists; but, given there is no such pool in v4, our natural, and I use the word 'natural', our natural ability to regulate the market disappears with it. And then we have to create assertions of authority, assertions that are not necessarily going to be accepted. There is no legal framework that people must obey the RIRs.
There is a co-operative framework that we are an industry body and we are, if you will, you. And that the policies and procedures we make are yours. But, that's no authority. So, at some point, I think we have to give up the fact that we are authoritative to people, we have to react to what folk want, rather than tell them what they can't do. So, I would argue I suppose that the fears and concerns that you're expressing are not in necessity applicable to this situation. With respect, I think I disagree. I understand the validity of what you're saying but I personally don't see it that way.
TONY HAIN:
Actually, I have two points. I firstly encourage you to go back and rewrite your proposal to include the temporary proposals.
GEOFF HUSTON:
To include non-permanent. Thank you and noted.
TONY HAIN:
It occurred to me that the transactions assumed that the market would be purchase sale as opposed to lease. Please revise the text as appropriate.
Second point, you said you tried to get to the point of the RIRs becoming the registry of what has transacted and not tried to regulate the market per se. At the same time, you mixed in the /24 requirements which is in fact a regulatory thing, so I would encourage you to remove that specific thing and let the market drive that. If you can't drive anything on the /24, the market for those will be, anything longer will be very low and as soon as you can't route things longer, that market will be gone. And then, actually, if you put in policy, it will make it very difficult and artificially inflate the price when routers can't handle it. So, I would encourage you to remove that particular text as well.
GEOFF HUSTON:
So noted, and thank you for that. I'm not sure who was first.
DAVID WOODGATE:
I think there will be many requirements of this general principle, but as has also been stated here, the requirement for transfer capability is inevitable. I think that the registries are the logical place to act as the registrars of those places and are important to do so to maintain a structured framework of IP address allocations.
I think that the proposal as it stands has nothing particularly objectionable in it, so I think that the proposal should go through as it is at this point and then the subsequent developments and refinements.
DAN ALEXANDER:
The original form of that draft was changing to a /24. There was quite a large thought that it was a bad idea. So much, it caused a rewrite of that proposal. This proposal, in its current form, in a sense allows that to happen either by registration down to a /24. So I'm just kind of offering up the thought of whether this proposal is a little too unrestricted that one is a /24, the correct wording, or should it simply adhere to whatever the current minimum allocation is. According to the policy. And the other thought was "do you really need to do this prior to the IANA pool run-out?"
GEOFF HUSTON:
Thank you, two questions and there are two kinds of answers flying around. In terms of fragmentation of the routing space and the issue of /24s, there was a study in I did in 2004 I presented to the APNIC meeting in that year around the extent to which allocations are fragmented into /24s as soon as people get them. The idea the minimum allocation size has any impact on fragmentation from that study is fiction and folk do slice and dice addresses no matter how big, according to traffic needs and without constraints. Our thought and assumption in the RIRs that somehow the allocation size has some impact on the routing table is a fallacious assumption. In fact, it just simply has no bearing. I don't really see much need to perpetuate the fiction.
The second issue about 'why should this policy take effect now rather than until the time at which IANA runs out?' In some ways, this is a policy which has very few constraints. In reality, I suppose part of it is an argument there should be more constraint. As it stands, the policy has very few. Tony Hain argued to remove the last remaining one almost. To some extent we are no longer the controllers of the way in which folk are going to behave over address movement. Once the unallocated pool exhausts we are not able to control the actions. We are not responsible for the outcomes. We record them, but we can't direct folk for how they buy and sell; it is not our money. In this respect, I would argue we can put it up now, and folk can always come to APNIC and get allocations.
DAN ALEXANDER:
The original form of that draft was changing to a /24. There was quite a large thought that it was a bad idea. So much, it caused a rewrite of that proposal. This proposal, in its current form, in a sense allows that to happen either by registration down to a /24. So I'm just kind of offering up the thought of whether this proposal is a little too unrestricted that one is a /24, the correct wording, or should it simply adhere to whatever the current minimum allocation is? According to the policy? And the other thought was do you really need to do this prior to the IANA pool run-out?
GEOFF HUSTON:
Thank you, two questions and there are two kinds of answers flying around. In terms of fragmentation of the routing space and the issue of /24s, there was a study in I did in 2004 I presented to the APNIC meeting in that year around the extent to which allocations are fragmented into /24s as soon as people get them. The idea the minimum allocation size has any impact on fragmentation from that study is fiction and folk do slice and dice addresses no matter how big, according to traffic needs and without constraints. Our thought and assumption in the RIRs that somehow the allocation size has some impact on the routing table is a fallacious assumption; in fact, it just simply has no bearing. I don't really see much need to perpetuate the fiction.
The second issue about, why should this policy take effect now rather than until the time at which IANA runs out? In some ways, this is a policy which has very few constraints. In realistically, I suppose part of is an argument there should be more constraint. As it stands, the policy has very few. Tony Hain argued to remove the last remaining one almost. To some extent we are no longer the controllers of the way in which folk are going to behave over address movement. Once the unallocated pool exhausts we are not able to control the actions. We are not responsible for the outcomes. We can record them, but we can't direct folk as to how they buy and sell, it is not our money. In this respect, I would argue we can put it up now, and folk can always come to APNIC and get allocations.
Quite frankly, while someone is doing allocations, effectively on the basis of need at relatively minimum cost, I'm not sure why anybody would buy on the market, but it is their choice. I'm not sure that we should necessarily restrain that at this point, simply because we have to wait until June 5th, or June 10th, or March 19th 2011. So my argument is that I'm not sure why it would add particular value on putting constraint on the policy.
DAN ALEXANDER:
I would offer a follow-up thought. If the /24 is an irrelevant point, then given the fact that IPs are still readily available, would it make sense to change the minimum allocation to a /24 and allow smaller organisations to obtain those registrations and offer the little guys a little money saving.
GEOFF HUSTON:
One policy proposal at a time. If you feel like making another, enter the process.
TOM VEST:
Tom Vest, consultant to RIPE. Actually, they have two related questions. The preservation of the highest group, the fact that the registry function, that's in a sense the highest good you're trying to preserve in moving to this market. The registry function currently only operates over some sense of the universal resources. We had this large quantity of resources which are not covered currently and are covered under some definitions, and which are not covered by policy. Or your proposal.
Once you recognise the legitimacy of the transactions, you basically have given, you have basically acknowledged that institutions have a choice. They can either buy and sell through the framework you've defined, or do what we all acknowledge happens and do it through the great market; in which case, in your preferred version, the registry function is preserved and the other version, it is not and it degrades the very map of it.
So, my question is, what incentives are there going to be for the good side of that transaction to be retained and not to bleed out as fast as that?
GEOFF HUSTON:
Could I go in?
TOM VEST:
The second question is related.
GEOFF HUSTON:
I can cite this from an ISP in the country where I live, where we were in a relatively central position, and routing as the upstream for a number of ISPs. The registry function at the time was performed by a rank amateur who had no idea what he was doing, and allowed the title of addresses to lapse into an incredible state of disrepair and he was justifiably fired as soon as possible. And I speak of myself! But, the result of this was that we had different customers indirectly asserting the same routing object. We, as an ISP, were being, if you will, threatened with legal action because both parties assumed it was our routing system which was making the decision. And because I couldn't point to a registry which was definite and authoritative, because I stuffed it, I was unable to get out of the fix and it was incredibly difficult and it happened not once, but time and time again. That chaos is expensive for everyone except lawyers. It is expensive to the industry. This whole system that we have relies on integrity of the address plan to the point of which disputation is with the registry if you will, rather than as you and me as routing. If you destroy the integrity of the registry, I believe you've gone a long way to destroying the network. That's why I'm saying that the accuracy and integrity of the registry is indeed the greater good. And the fact that you might observe that there is some legacy components created by amateurs who were fired appropriately from their job, doesn't mean that they should all emulate and reproduce the outcome.
TOM VEST:
I would reply that you're providing an awareness and commitment to the greater good by the community, and I think if you positive that, we can do many other things to mitigate the coming turmoil. But I think that we need to achieve some level of consistency on the assumptions.
My answer to my own question has to do with the legitimacy and non-contested status of the system to that. There's no-one else claiming to be the legitimate broker for address resources and no external authority saying that we're not legitimate any more. And I think a lot of that legitimacy has to do with the needs-space-allocation rule and the basis of the needs in technical criteria; and I think once you take away the technical criteria and you take away all needs basis for that, you have not only a lot of discord amongst former supporters of the system, but you also have less cause for external parties, which will remain nameless, to forebear from arranging alternative arrangements. So I think that is the glue that has held together what you say is most dear to preserve. And recognising monetary-based institutional transactions which bypass that, I'm afraid that... actually I commend you on bringing the 1744 there, just as a reminder that any ability to encourage compliance, to maintain the registry, even the presence of people in rooms like this at the same time. It's nothing to date, nothing has been more than an artefact of the allocation function, which over time has led to a front of goodwill and legitimacy which I think are quite fragile. So, I don't know if that's a question for a statement.
GEOFF HUSTON:
There was one assertion in there that I will comment on, and simply comment on. It doesn't require a response.
I'm not sure that the market needs to be eternal. I'm pretty sure that it does not. I'm pretty sure that scarcity will reflect itself in pricing. I'm pretty sure that ability to be registered in the market doesn't drift away with the function of allocated registry. That's gone. But, on the other hand, the real issue is that if the price of a v4 address escalates to 50 gazillion, billion dollars, and it is on a needs-based allocation, the signal... I'm being told to swallow the microphone!
The signal in terms of 'I wonder which is cheaper to deploy and gives me better value and better return on the investment' starts to be pretty obvious, and it is the opposite of the signals that are there today. So, if your real goal is here to force the industry through what is a painful and chaotic process and emerge at the other end with a network intact, I'm not sure that we can hang on to every vestige of history. I'm not sure between the two of you who was next.
ALAIN DURAND:
Many points, but I need to choose one! I would like to talk about the need for some common frameworking between the different parts of the world to go to this path of reclaiming unusable space. From reading the proposal and listening to you yesterday, the NIR control space is not part of the framework, nor is the legacy space. So whether it is right or wrong and I would like you to comment.
GEOFF HUSTON:
There are processes for folk who are not current APNIC members who have address space which is administered by APNIC to become current. So that when you say this doesn't apply to historical resources in the APNIC context, that is true; but there are processes already there for such holders of resources to become current members with current resources. I think Mr Wilson is going to clarify. Is that right?
PAUL WILSON:
You're completely correct, keep going.
GEOFF HUSTON:
Sorry, I'm completely correct! So, in that respect, the reason why it doesn't apply to historical is because historical can become current there or at the party's own choice. The issue of whether it should be uniform globally or not: We don't have a huge amount of time left to do this, and our experience with global coordinated policies has been both colourful and lengthy. They are not fast things to do.
In some ways, actually having separate discussions and separate grounds is very helpful to all of us. Let me quickly respond by characterising the ARIN proposal for this point as tightly constrained, and I suspect that the discussion in ARIN is going to be about which of those constraints is perhaps not necessarily needed.
This proposal is relatively unconstrained, and perhaps part of the discussion is: What further constraints might be needed? I think the totality of discussion is useful to understand precisely what is going to work for the registry, for the Internet and for players. So, at this point, I would not say we should be arguing the same thing. I actually think some divergence and difference of perspective is very helpful.
ALAIN DURAND:
Could you speak about the NIR restrictions?
GEOFF HUSTON:
A lot of the discussions with the NIRs has been: "You're forcing this, we don't have a say, we have our other constituencies and communities". By saying it doesn't apply, it says to the NIRs: "Talk, and with your own community, understand your own needs. If you wish to be recognised in this process, fine, let's talk about how a party who is the disposer in one NIR and is required as a member of APNIC or another can do this". And I believe that a more positive discussion, the one that says here: "Like it or lump it" when the relatively large constituencies which aren't in this room, which are in NIRs are not able to directly participate. So, by phrasing it this way, the APNIC members can consider it and the RIR members can discuss it in their own context without feeling obligated. We must do it that way because I think NIR conditions do vary, and I believe they have the ability and necessity to figure out what works to their particular circumstances.
ALAIN DURAND:
I think the issue will be transfer between NIRs.
GEOFF HUSTON:
It is not part of this proposal.
NIGEL TITLEY:
Nigel Titley from Easynet. I have two comments and one request to make. The first comment is: Obviously I support this proposal. The first comment would be that I would like to offer the following illustration. We've all been in a position where we know there is something we should do to our network. We find it very, very difficult to build a business case to do that. At least the existence of an IPv4 market allows us to place a value on the IPv4 addresses that we are getting rid of in order to replace with IPv6. This will satisfy the bean counters in your organisation.
The second comment is that believing that the tax authorities were not able to distinguish between an IPv4 address and an IPv6 address. The tax authorities in my country can distinguish between a cup of coffee I buy on the premises and a cup of coffee that I drink on the side.
Thirdly, I would urge Geoff to introduce the temporary transfer provision in the RIPE proposal. Thank you.
GEOFF HUSTON:
Thank you, and so noted. I've heard that twice, and from the non-temporary and non-permanent I can see some merit there; insofar as in a market which is continuously changing, and which has a sunset, we're not going to trade v4 forever; it's going to be useless at some point. Some folk think that it is a very long time away and some who think this transition won't last very long.
If I have addresses and you think it is going to be a very long time, you might want them for a short period of time to see your needs through. Having non-permanent transfers or temporary satisfies that diversity there, which is valuable, so I'm happy to put that in.
IZUMI OKUTANI:
I have a number of questions about implementing this proposal and I don't expect them to be answered immediately; but then, I suppose the point is that there are still a number of issues that we still need to consider carefully; so I totally support continued discussions on this proposal and consider it as the options. But I feel that there's still a number of issues. For example, a point was raised on the mailing list that if this was implemented before the exhaustion action takes place, then maybe there will be some speculators thinking: "this will gain us money". So, even if they don't need that much address space, they will try to apply for as much address space in APNIC or other RIRs as much as possible, and then try to sell it once it is exhausted, so it encourage those movements.
Or, how by international trading can we accommodate it? Or