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, an issue of, once address space is going to be sold as property, then it is going to be considered as part of taxation and it is going to change how companies do their budget. And a number of ISPs felt that if it is officially not recognised as a policy, they would find it difficult to actually go out and transfer to the black market, because you know, their accounting system actually doesn't allow it. Questions like this.
I think some of the questions raised could be maybe solved by an idea which was introduced by a proposal in RIPE, an idea about non-permanent; and personally, I haven't really discussed it within Japan or within my organisation. I think that could solve some of the questions, but my point is this: I think we would like to consider each of these points and be a bit more careful before implementing it too immediately.
GEOFF HUSTON:
You have precisely three years less a few days. Not every question is going to get answered in three years, less a few days, before IANA runs out of this. So, in some ways, the role of v4 addresses out of the unallocated pool has an inevitability like a brick falling from the 40th floor of a building.
Not every question can be answered. Equally, we are not governments. We cannot, if you will, define whether things are regarded as a taxable asset in a taxation regime in an economy. As APNIC, we are not any particular Government at all. That is not our business. This proposal, like many other forms of activities, has implications for players. They will need to answer some of those questions themselves in their context; we can't do it all. So, while I recognise that this is a leap away from a familiar, well-trodden and comfortable path into an area of our own making that is unpleasant and different, we can't avoid it. If you think that any form of transfer is impossible, because, as you pointed out in your comment, then all I can say is that your v6 plan for the rest of the planet better be good, because you only have about three years. There's not a lot of time here. And if the need for v4 stretches beyond that as appears to be incredibly likely, then industry is going to solve this problem one way or another; and the real question is, to what extent can we make that transition less painful than it otherwise would be?
So, there's an awful lot of balancing of factors here. This is not 'let's create a new framework forever'. This is trying to say, 'let's preserve the essentials of the Internet across a relatively nasty thing that's going on that is really quite threatening to the integrity of the network'. So, while I respect this sort of - and we would really like to know more - you're asking beyond the void. Some questions are not going to be answerable until we are there.
IZUMI OKUTANI:
OK, I got your point, and I assume maybe you can't answer everything, but maybe we should have more time to discuss about these issues and see what we think about it?
GEOFF HUSTON:
We are doing that now.
IZUMI OKUTANI:
OK.
GEOFF HUSTON:
We have done this since September. Certainly, the mailing lists have been there. I do note that in your very busy lives, the amount of activity on the mailing list about this particular proposal has been relatively scant. Let me ask those, give you the warning that in your day job in three years time, this is all you're going to be thinking about and you wished you would have thought about it now. So, encouraging a little bit more group-think about this at this point in time is perhaps appropriate.
IZUMI OKUTANI:
OK, thank you. I got your point.
ROQUE GAGLIANO:
Roque Gagliano from LACNIC. Firstly, I would like to mention the community and the former policy proposal. However, there's been some internal discussion in the mailing list and a lot of awareness with everything with exhaustion and what's going to happen later. But, I wanted to ask you, Geoff: You mentioned a certain amount. It could be possible to have co-operation between at least transfer with RIRs through some certification of the...I want to use your terms, not the ARIN one.
GEOFF HUSTON:
Qualification.
ROQUE GAGLIANO:
But the one who gives out and the one who receives it.
GEOFF HUSTON:
The disposer.
ROQUE GAGLIANO:
I wonder if you have any idea where the policy there stops and actually we're talking about, not necessarily policy, but just implementation?
GEOFF HUSTON:
There are a number of ways of implementing it at the moment. I think that most of them are relatively easy once you figure it out. How do we understand that the disposer is a genuine disposer? I didn't mention the word 'seller'. How do we know that the acquirer is known to us and registered? Realistically, what the policies are trying to say in all three so far is: Here's what a disposal looks like. We know them, they have a relationship. They're one of these kinds of things inside our RIR.
Similarly for the acquirer: We know them, they have these kinds of characteristics, they meet this criteria. If you are discussing what would happen in a cross-RIR situation, what if, in an APNIC context, APNIC was going to modify this policy at some future point saying, we recognise RIPE policy 2007/08? And that we will consider a qualified disposer as being a RIPE-qualified disposer under their policy and an acquirer being so on. So, if you refine this policy by recognising another RIR's policy and saying that if they qualify under that RIR as one party, we would recognise the transfer. That's one way of doing it.
So, I'm not sure that it is a particularly insoluble problem. I think it is a relatively easy problem as a next step. In other words, inside this framework of each RIR, it can be solved and I'm not sure that we would advocate that we need a globally coordinated policy. I'm actually saying it is not necessary.
BILL MANNING:
Strike Bill. Don't tell him that!
GEOFF HUSTON:
David Conrad strikes Bill.
BILL MANNING:
A couple points. First, your assertion that no-one will want IPv4 again. It's going to go away and we will mourn its passing. When RIP dies, I will be comfortable with the assertion. I think there will be a continuous use for IPv4 for the foreseeable future.
GEOFF HUSTON:
Absolutely, Bill, but is the continuous demand in the order of four billion addresses or less?
BILL MANNING:
Long-shot says less.
GEOFF HUSTON:
If it is less, it is no longer scarcity.
BILL MANNING:
We can go to the long-shot site later and place the bet!
The second has to do with the attestation of the disposer and the receiver, whatever you call it, the acquirer. In the absence of the mechanisms which we have also been talking about for the last three or four years, it's going to be problematic I think for the RIRs to ensure that their processes are up to speed.
Would you suggest that that be in place before the transfer policy is in effect, or are they unlinked?
GEOFF HUSTON:
At this point, in this particular policy proposal, we have qualified the parties as being known and current, so that we recognise that there are some historical records in there, but there is another process to bring that in. So, we don't need additional mechanisms to implement this policy today.
That being said, we have presented a number of times from the Secretariat on work on resource certification, and using X509 certificates as a visible attestation of an allocation would help this transfer process, and help the parties to recognise legitimacy of each other considerably. But, it is not a precondition or a necessity to be in place before. It would be good to be there, but it wouldn't have to be there.
BILL MANNING:
The third piece and I will pass the baton to someone else. Is there a reason why, once we have gone through all of the effort to understand the ramifications of a transfer policy, that the transfer policy would be temporary and not be there with the system for any address system?
GEOFF HUSTON:
Should the policy go further than where it is? And the answer is: I feel personally comfortable about a v4 policy. I sense that those who feel confident have commented in the context of v4. I have not heard anyone say, they should apply for manual favour resource, and in the absence of such enthusiasm, I'm certainly as a proposer not able to extend it either. It's a v4 thing.
DAVID WOODGATE:
The conversation between Geoff and Izumi before reinforced what I was trying to say earlier, which is that I feel that if we spend too much time arguing about the proposal, then we'll get to the run-out date and find we have no policy actually implemented.
I think it will be fairly safe to say that whatever proposal is implemented, it will be wrong to some extent in the first instance. Pretty much everything you do in the first attempt is wrong in some way. But, it would be better to have something on the path to get underway.
Now, if there's concern that by introducing it too early, we'll introduce some undesirable aspects and the one comment that maybe there needs to be some consideration of triggers, trigger circumstances introduced, you know to prevent, to identify when the policy should actually become active, so that the policy can be approved, that would of course be active in certain circumstances. I don't know if that is necessarily there, just a thought.
GEOFF HUSTON:
We have very few constraints, very few abilities to manoeuvre. Oh my God, transfers isn't working, reopen the unallocated pool! It's empty! Once you lose the regulatory or the control mechanism that you had by being able to allocate on the basis that you had from the pool, your ability to affect the actions and players out there is very, very limited. What we're trying to do is to say: Look, each of you are responsible for your own businesses, your own destiny and your own future out there, and you will be exposed to pricing signals if a market emerges of scarcity in one resource. You will be, that is unavoidable, because scarcity is indeed one of those kinds of things.
If the answer truly is that we can't make v4 last forever, and that appears to be the answer, then the scarcity signal is going to appear and that is of necessity a good thing because no other signal in the last 10 years has made one jot of difference to this industry. Not one. The current 1,000 ASes don't appear to be awfully significant out there. So, in some cases, you are going to get a number of scarcity shocks inside this industry. Trading will alleviate some of the worst aspects of 'oh my God, I can do nothing about it', when you can indeed do something, but it is not a long-term answer, no.
So in some ways, failure in the market says, we really did take v6 seriously. Mr Conrad.
DAVID CONRAD:
I'm not swallowing the microphone. With relation to RIRs, my understanding is that this policy does not apply to that. The question is: What does it actually mean? Does it mean that they cannot be acquirers, does that mean they can not be disposers?
GEOFF HUSTON:
We don't understand if someone isn't a member of APNIC who they are. They're not in our database, they're not known to us, so it is really hard for us to create an entry, because our entries say 'this is a JPNIC resource'. So, NIRs can be there.
OLEF NORDLING:
Olef Nordling from ICANN. So NIRs which are registered there...
GEOFF HUSTON:
They meet the current criteria there. They are a current APNIC account holder, yes.
OLOF NORDLING:
So, what would discourage the NIRs from trying to corner the market?
GEOFF HUSTON:
I would have thought that rather as searching for weird ways of perversion.
OLOF NORDLING:
I work at ICANN, please!
GEOFF HUSTON:
You do! I would have actually thought that NIRs and APNIC share a very, very common interest here in trying to get us to the other side of this particular thing. One can dream up all kinds of scenarios, realistically, pragmatically. I would expect the NIRs to understand this and understand what is in the best interest of their members and the greater good as they've done all along. So yes, we can go into perversion picking, but I would rather you did it outside the room over a beer, thank you!
OLOF NORDLING:
You brought up in one of the slides, the question whether this would be a regional policy or a global policy and I think it is advisable, just to avoid confusion to reserve the expression 'global policy' to those policies which directly have addresses from IANA to the RIRs. Perhaps if you could clarify that and say, we are talking about a common framework policy across RIRs or something of the sort, which may be more appropriate than calling it the global policy. An integrated thing.
GEOFF HUSTON:
Thank you for the connection. I had tried to use the term, globally coordinated policy, and that's distinct from global policy.
OLOF NORDLING:
But, you didn't on the slide.
GEOFF HUSTON:
Oh, thank you, bad slide. Naughty slide.
TOSHIYUKI HOSAKA:
Please state your name.
IZUMI OKUTANI:
Just referring to the comments that David Conrad made earlier, 'what is the position of the policy'. Theoretically, according to the proposal, NIRs don't have to implement it. But, realistically, if the APNIC region as a whole supports this policy and implements it, then I think it would have a more negative effect for Japan or Korea or an NIR in not implementing it. So, I think in reality, we would end up implementing the policy for the rest of the region if the policy passes.
GEOFF HUSTON:
I would stress that the intent of the policy proposed is that it is the choice of the NIR to make in their own way. It is not enforcing function from the APNIC to the NIR.
IZUMI OKUTANI:
Certainly, I understand.
TAKASHI ARANO:
Takashi Arano from Japan. Is it OK for APNIC to easily give up, to be using the correct address to free pool? I'm not sure. APNIC allocates address to RIR under the condition, RIR uses the address according. This can be seen something like a contrast to a promise between APNIC and the RIR. If this makes sense, if the RIR doesn't need the address any more, then maybe change of plan, I don't know the reason for that. But for APNIC not to transfer that. In the sense, JPNIC should maybe be responsible. Maybe this idea is maybe too strict, and I do understand that avoiding the black market is also important. Right now, I'm not confident I'm saying yes or no and in this sense, I would like to discuss more before deciding.
GEOFF HUSTON:
Thank you. Yes, there is a distinction between what should happen if everyone obeyed all of the constraints that we attempted to replace when they received the allocation, and try to assess what is most likely to happen from a broad and diverse industry faced with rather big problem. It is true that the amount of returns we've had have been relatively small, and that in practice, the idea that if you no longer need them, they get returned is more honoured in the spirit than the practice. And pragmatically, transfers are very likely. If that's the case and we refuse to acknowledge them, we are holding the network itself hostage, and that's an outcome none of us want. It might be good to adhere to your principles, but if that means no Internet, I'm really not sure that was the right outcome. So, there is a delicate balance between what is pragmatically necessary to do, versus what is the right thing to do all the time.
WEI ZHAO:
Speaking about ideas on the proposal. Coming to the reality and operation of this proposal if it has been passed, I do have something to consider, like we know the transfer is going to be much longer. I'm really not sure if this proposal is a guideline or we're going to have a separate proposal coming up about the details of the transfer; because if the address has been allocated from RIRs, then the address when we transfer from one party to another, are they going to arise some legal issues if that address has been incorrectly? So, to recommend about, problem, Geoff, we'll put more details. Will the details come up separately?
Another point of the recommendation is, when we are talking about transfer fee, probably someone is thinking it isn't appropriate to have a transfer fee. Some say it is necessary to have the transfer fee to let them realise the IPv4 free pool costs more than IPv6, then they're deployed. That's a good point, but another point is, most of us are concerned that the market which is the black market will be triggered no matter the transfer policy is there or not. But, we just think, we don't want to really put the transfer fee or transfer cross which is leading to a very high level that will be in favour of the black market, because I think the lower fee, or the proper fee is set up and the black market actions will be in the background. Thank you very much. That was my concern.
GEOFF HUSTON:
Let me clarify an assumption you made in your comment that is perhaps not quite in line with the proposal. Let's say that you and I are both APNIC members and exhaustion has happened and I happen to have a /16 and you happen to have a desperate need and we agree for a transfer. No matter how we do this, money might change hands between you and I. I might sell to you from some other consideration that is our business. When we approach APNIC and say, please register the transfer, we're not paying APNIC the money that you and I might have transacted, that's completely independent. The fee is effectively a book-keeping fee to maintain that registry. I do not, you do not pay APNIC for, if you like, the value of the transfer. That's completely between you and I.
So, the transfer fee is in effect a book-keeping fee around keeping the registry. It is nothing to do with whatever value that you and I might have placed on that transfer as two parties.
WEI ZHAO:
The reason I brought that up is that we know that the person who is going to transfer out the address will be personally you and I, such as for example, I'm the holder of a IPv4 and I'm willing to give up, and I'm just concerned that receiving resource, receiving holder is that if the concern would cost a lot more to get the resource from APNIC than the black market, who are they going to go for? And that will be...
GEOFF HUSTON:
You're not getting it from APNIC. APNIC is simply registering a transaction between you and I. That's all it is.
WEI ZHAO:
Definitely, but the issue of paying the transfer fee based on the block or based on the size is transferred. That's just a concern to be aware of paying too much on that, and people probably were thinking it is better to go to the black market. That's just a concern about that.
GEOFF HUSTON:
OK, thank you for your comment.
PHILIP SMITH:
I want to try to drag this back a little bit into Internet functions where the ISPs need to run functions and check what prefixes their customers are trying to send them and so forth. So, the ISPs would very much like to see, well, know who is the entitled user of this particular address, and I think the policy proposal as the text is on the screen right at the moment will probably achieve that, because then APNIC can keep a record of what is actually using the particular address space, because we're getting away from; well, there already is a black market of v4 addresses. I think we all know that.
I really would like to see continuing recording of who is the legitimate holder of the address space. I think the whole conversation got completely lost with all of the particular details. I don't have a way out of this, I don't have a good suggestion.
GEOFF HUSTON:
There's a suggestion in front of you called prop-050.
PHILIP SMITH:
Yes, but what is exactly on the screen there is fine. If there are discussions about fees for this, and who it applies to, and who it doesn't apply to, and all of the other pieces which get in the way I don't know what the answer is. We need to have incentives for people to realise that this is the thing to do.
GEOFF HUSTON:
The basis of the policy is very simple. In order to make the registry work, we have to know who the parties are that we're describing, even today. That's the fundamental. We don't put a random owner, a random contact; we know them and we have a relationship. This simply says we will do transfers between parties we know. We, APNIC, will do transfers between parties we know for resources we understand, and the resources we truly understand are current. The historical ones are ones we used to understand a while ago, but actually don't understand today. There's a process to get there. In essence, Philip, it is a simple proposal and it really does say precisely that. I did strive to make it simpler and a couple of people helped me remove the /24 and allowing non-permanent makes it even simpler in some sense. We will do what people want as long as we understand who they are.
PHILIP SMITH:
So, if this goes around to another one, could I encourage simple and clear language.
GEOFF HUSTON:
I don't do simple and clear!
PHILIP SMITH:
It was just trying to sort through a lot of the discussions from the list here. I was sitting there trying to figure it all out and I got confused.
GEOFF HUSTON:
I probably need a co-author to remove some words, if you're volunteers.
PHILIP SMITH:
I can volunteer.
RAY PLZAK:
Ray Plzak from ARIN. I would like to go back to David Conrad.
GEOFF HUSTON:
The perverted mind of David Conrad!
RAY PLZAK:
The NIR questions were interesting when you look at the other things that you said regarding inter-RIR processes and so forth. And your comment about APNIC would have to know who the parties were to transfer, which really says that any large, or any ISP which is receiving address space from an NIR is not known to APNIC.
In fact, the NIR is not the one that would be wanting to acquire the address space or to give it up. It is the ISP inside that particular NIR that actually wants to be the party. So, I guess from a mechanical stand point, would there be some method where the NIR functions as a proxy? Is there some method by which you need to have a separate registration, the APNIC service provider? Is there the NIR which doesn't acquire address space under the same policies as an ISP does in the APNIC region? And so there's a number of things that I think would have to be considered, other than just the blanket statement about the NIRs and doing what they can. And whatever is as a result of that would then have to be factored into any kind of discussion to forward on regarding criteria for an inter-RIR process.
GEOFF HUSTON:
Thank you, Ray. If I wander into topics that I know nothing about to talk about, the APNIC registry itself contains registries to affect the NIRs. If you look at this from a registry-centric perspective, then APNIC runs a registry. APNIC enters into its registries transactions that directly reflect transactions between its members, but also can place entries in there from an NIR where the NIR is the trusted point. In a transfer from an NIR to someone else, there is a registry transaction in the NIR's registry that may then get reflected in the APNIC registry. So, I'm not sure that I truly think that there's a significant issue here, but, it is a case of looking at this from the perspective of registry transactions and the registries themselves.
And then taking that perspective without saying 'let's just solve the inter-RIR problem by me waving my hands'. I am saying though that I think there is a direction that could solve this by looking at this as a set of registry transactions, but there's a lot more work to do, Ray, around that area, and it is not just, oh, let's do it. Absolutely not.
IZUMI OKUTANI:
Izumi Okutani from JPNIC and with how to do it. I was actually trying to put a few more words into the comments. We definitely understand that this is probably the most practical way and trying to keep the original policy might not necessarily be the most practical or realistic way, you know when we face a different situation. But based on that understanding, we still have questions, such as, OK, for example, if we allow market and other people to buy and sell address space, there are people who will be able to purchase address spaces will be big and wealthy ISPs, and those who don't have that much money to be able to buy address space, they will not be able to sustain it.
Under this current policy, that issue will not happen because the fee is pretty much fixed by RIRs. So, it doesn't necessarily mean that we're against it, but then, that's one of the things, the questions that we have and one of the issues we have about this proposal.
GEOFF HUSTON:
Fairness is such a hard thing in a scarce market, and it is incredibly difficult to understand what fairness is in any open, competitive market; because, once you price something, you immediately qualify people who pay and people who think that the price is too much. When demand exceeds supply, not everyone can get it. You are faced with one of two responses: rationing or a market.
Rationing is the law of equal displeasure. Nobody got what they wanted and it places one party, the rationer, in a very privileged position of having to make judgments. We have never been, if you will, placed in such a terrible position of having to do that. The policies that we have applied have been the policies around abundance: Demonstrate your need and we will give you your need. Not two thirds, not one half, not one tenth - your need. No matter how we phrase this next period, demand exceeds supply in v4, and the ultimate answer is: I can't fix it and you can't either. The answer is v6.
To what extent the folk who can not afford the market at that price are forced into early adoption in v6, is that necessarily good or bad? Is that necessarily a better outcome? So, when we talk about fairness and who is able and who is excluded from the market, there are many dimensions to this. It is not a single, everyone should have. We are no longer in the room of plenty. We're in the room of not enough. And the room of plenty is v6. How do we get there is the other thing I think we all have to consider. And we can't make a market affordable for everyone when demand exceeds supply. It just won't happen. Thank you.
IZUMI OKUTANI:
I understand your position. Thank you.
JAMES SPENCELEY:
I understand adding non-permanent transfers. I suspect that transferring addresses to someone and then expecting them to return them, especially someone as static as an IP address is complex policy. I would be interested to know how APNIC would resolve a dispute between two ISPs where they leased space to a second party.
GEOFF HUSTON:
I'll quickly respond to that in noting the other part of the RIPE proposal had 'resources must be certified'. And one of the things about certificates is that they have expiry dates. So, if you have, if you will, a timed certificate, at the end of that certificate's day, it is gone, it is over. There is no way that you can assert a right when the certificate says it is over. So, in the RIPE proposal, they created both the framework, non-permanent, and the implementation certified in one hit. Maybe when I look at this and understand what I've said and conclude to be non-permanent, maybe certificates will come in there and say: 'this is the mechanism to make it clear what's going on'. The certificate will do that for you.
JAMES SPENCELEY:
Assuming that they're there.
GEOFF HUSTON:
No, certificates in the registry. We don't need them in BGP.
JAMES SPENCELEY:
Assuming that the registry level, transferring it for a period of two years, the transferee is refusing to, I suppose unwrap address space, would you say that APNIC would get involved?
GEOFF HUSTON:
APNIC said, here is a certificate, it goes until this period. After that, it's over. The registry dies.
JAMES SPENCELEY:
OK, that still doesn't mean that the ISP is stopping to route the address space.
GEOFF HUSTON:
It is up to ISPs to figure out whether they're prepared to have them. Did you route that /24 coming in from Pakistan telecom. No or yes?
JAMES SPENCELEY:
No.
GEOFF HUSTON:
It is up to ISPs to figure out what to believe in routing. You and I can't figure that out unless we are ISPs, and what do you do for route security? APNIC can't force anything down anyone's throat here.
JAMES SPENCELEY:
I guess if APNIC is allowing the temporary transfer of address space, there is something of an onus on APNIC to back it up with some level of support; given that APNIC holds constraints over each party with regard to the other address space. But that gets back to the whole APNIC and the routing police.
GEOFF HUSTON:
I would point to the certificate part of RIPE and say that's the most likely way of putting this in.
DAN ALEXANDER:
I just wanted to offer kind of a word of caution as we discuss a lot of this. I completely agree that one of the main intents is to protect the registrations. We often bring this up, the black market and the desire to avoid a widespread black market, and it sometimes reminds me of a political discussion in that if you say something enough times, it becomes true.
While I don't dispute that current buying and selling may exist, there's no data as to the current scale, so the only point I want to make is that we're talking in a lot of hypothetical.
GEOFF HUSTON:
My example that I gave was in response to direct personal experience at AUNIC. And we really did not have a registry that mirrored reality. So, we've been in this place, and what happened was that other ISPs had their legal departments involved in really messy discussions. All of a sudden, if the registry isn't the arbiter, the ISPs randomly are placed in the position that their routing system makes deliberate choices as to who gets the route. In the absence of a registry, they're placed in a very insidious position about viabilities. I stuffed it, so this isn't apocryphal. We have experience with some of us and we didn't like it. That's the situation that we are saying that if this goes into a completely submarine environment, where someone says: "I got the addresses from this guy I met on the street last night, it really is good, I gave him my MasterCard, they'll say they will route it", chaos ensues. Then what? You don't want to be there, we have been there and it is messy, it is expensive and it diverts everyone. So, I emphasise that this is not about a square tactic. This could happen. Some of us have been there. Some of us inadvertently created it.
DAN ALEXANDER:
Are we talking about the integrity of 10% of the Internet?
GEOFF HUSTON:
Even a /24 can cost you a few million in law suits. Talk to YouTube.
I can say anything now. We are there. OK.
PAUL ANDERSON:
I was wondering, under your policy, if I'm reading it correctly, the recipient would not need to justify the block and as you were aware, the ARIN policy does have it. I was wondering if you could comment on the reasons why?
GEOFF HUSTON:
It gets back to the generic comment that the APNIC policy proposal is relatively constraint free. We no longer have the ability to apply constraints. Folk move addresses around, we will register it. It is possible you might think there should be more constraints. But I think it becomes a conversation about why additional constraints should be applied and what effect you are trying to generate as a result. What goodness, net goodness, appears as a result? The ARIN proposal is somewhat different. It comes from a very, very constrained environment and says "this is what will happen." It is extremely tight. And my perception is that the discussion is going to be, once you accept the fact that transfers are highly likely, which constraints might be relaxed to improve the overall goodness of if.
We are coming from different sides, I admit. To some extent they are complimentary but useful discussions. It is appropriate if you look at starting at close to where we are today and say transfers occur, but within a framework that is pretty consistent and see what the community thinks; we don't need this or this, and you are going to dragged towards something that is less constrained is my guess.
Equally, you can say: "we know them", that is it. What more is necessary or appropriate? If you analyse both discussions, at the end you'll come up with a lot more knowledge about what the right thing to do is. It was deliberately a very, very accepting policy that says: "Look, we know you, we know you, the resource is current, go for it" versus, "You need to qualify here and here, and demonstrate need."
So we will see in these discussions where both of us end up, and we might converge and be a bit different, but they are both useful discussions; but it was useful, yes.
TOSHIYUKI HOSAKA:
Thank you very much for the discussion. I see no person in front of the mic, so Geoff?
GEOFF HUSTON:
Sorry?
TOSHIYUKI HOSAKA:
I myself have a question. I, are we really ready to implement this policy? In this region? Not only to you but to you all.
GEOFF HUSTON:
There are two ways. I work for the Secretariat. If the policy was put forward now, would the Secretariat be in a position to implement it? Yes. Would they be ready? Yes, although certificates would be really good, they are not necessary, as I said earlier. Do I sense the community is ready to do this? Maybe you should ask who is ready to do it now, who needs more time, noting you only have two years and some 300 odd days. Time is not an infinite resource here. Do you need to do it today? Maybe, maybe not, but maybe you should ask the room that rather than 'do you want to do the policy proposal now?'
TOSHIYUKI HOSAKA:
Yes, that is what I would like to do now. I have heard concerns from the floor; I heard some support to the basic idea; but in some suggestions the details including routing or something, certification and so on. So, before seeking consensus on this particular proposal text, I would like to see how many of you support the idea; basic idea of the transfer? Is it fair?
GEOFF HUSTON:
I think that is fair, yes.
TOSHIYUKI HOSAKA:
OK. So how many of you support the basic idea of transfer? Do we need such a policy? Please raise your hand. It is not seeking consensus.
Right. Thank you. Once again? OK, sorry, Secretariat is counting. How many of you support the basic idea of transfer? Please raise your hand nice and high.
Thank you. So, next, how many of you do not support or oppose to the idea of the transfer? Please raise your hand?
HYUN JOON KWON:
Is there any option?
TOSHIYUKI HOSAKA:
So you want option, what option. Possible options.
SPEAKER FROM THE FLOOR:
I just heard of so many concerns about this policy so maybe if they need more time, about modifications of the policy maybe?
TOSHIYUKI HOSAKA:
Yes, what I'm doing now is to, you know, capture the general feeling from the floor, on the basic concept of this proposal.
GEOFF HUSTON:
I think if all of you say it is a really bad idea, I can stop working on it. If most of you are saying: "Look, it is a good idea but keep working on the words", which is what I believe I saw, then it is certainly a message I can work on. It is not a case of these words right now, but keep working on it; come back to the next meeting and discuss, because I believe what I heard, is that right?
TOSHIYUKI HOSAKA:
Yes, I saw, I don't have the exact number but around 20 people? 17, OK, 17 people support the basic idea of the transfer and disagreement on the basic concept. But the measure, the majority of this floor supports the basic idea or concept of this proposal. So, I understand that we are supportive of the continuing discussion of this policy rather than abandoning the policy.
GEOFF HUSTON:
Excellent.
TOSHIYUKI HOSAKA:
So I suggest that we are going to send back to the mailing list profile a discussion rather than seeking for the consensus right now.
GEOFF HUSTON:
I will submit version three with the suggestions as proposed from the floor and put it on the mailing list, yes.
TOSHIYUKI HOSAKA:
Right, yes, if no objections from the floor, I will do so. Any comments on Jabber? No. OK, thank you very much. So we have 10 minutes to lunch. I'm afraid we have no time to present next proposal, so may I declare that this is the time for lunch? That is fine? How long? How long?
GEOFF HUSTON:
We are scrabbling here trying to get Tony's presentation up with the PDF, go and have lunch, that is brilliant!
TOSHIYUKI HOSAKA:
OK, let's go for lunch, thank you.
APPLAUSE
So the third session of the policy SIG will commence at 2pm, so please come back then.
[END OF SESSION]
APNIC 25
Policy SIG
Thursday, 28 February 2008
1400-1530
TOSHIYUKI HOSAKA:
Hello, everyone, could you please take your seats now. This is the third session of Policy SIG to begin.
So, before Tony Hain's proposal, let me read out the house keeping notes again. I have six notes. One: We would like to acknowledge Google for sponsoring our Policy SIG sessions.
Two: You can participate in sessions using Jabber Chat. Directions are available via the APNIC website.
Three: APNIC closing event will be held tonight from 7pm to 9pm sponsored by Cisco, held at Shan Chang Hall. Transport will be provided. First bus leaves at 5:45 pm from the car park.
On Friday transportation will be provided. If you're interested in joining us, the cost is $600 Taiwanese.
The Helpdesk is now available in the Osmanthus room on level two during breaks.
Six: When filling in the survey online at the APNIC meeting website, the closing date is after afternoon tea today. The winner will be announced during the last session of today. Thank you to those who have already entered.
So, that's all from me. So now, are you ready to present your proposal, Tony?
prop-052: Cooperative distribution of the end of the IPv4 free pool
TONY HAIN:
Here it goes. So, I had a hardware failure right before Geoff's talk ended. The network interface on this has died and it looks like more than that died because I couldn't get it to connect to the screen. We'll use the other laptop. Make it easier.
My name is Tony Hain and I have a proposal for co-operative distribution at the end of the IPv4 free pool. To put this in context, this fits in between the two proposals from the morning.
The first proposal was about what to do with the last of the remaining IANA pool and how to distribute that. Geoff's discussion was: When we get to a market space, how do we handle transfers? This proposal actually sits in between at the point where IANA has run out of space and one or more RIRs have run out of space, but they haven't all run out of space, so in the general context, it is a middle ground and what is the process at that point.
So, the problem is, IANA has run out of space. One or more RIRs have run out of space. At that point, existing practice has come to an end. You know, there's a lot of discussion about how to continue on with historical policies, but my contention here in the second bullet is that the RIR members are not captive to their own RIR. They stay there today because that's a good thing for the community as a whole; reasonable practice. But, at the point where they need address space, their RIR, the one they're normally a member of, has run out of address space. They're not going to sit back and say: "oh well, I can't get address space". They will become members of whichever RIR has address space and move on.
So, the proposed solution, and I don't have any particular reason for picking these numbers. They were numbers just to stimulate discussion. So, the proposed solution is that at the point where a member comes up and says: "I need space"; their RIR is out of space, rather than having them go wander off to some other part of the world and become a member there to get space, that the RIR that they're already a member of collects those and aggregates them out and proxies them out to the RIR that has the most remaining space. And suggesting, once the RIR has hit the window of run rate, they go off and get the three-month pool for which ever RIR pool has the most space left. But, that is until you get down to the dregs and I suggested one eighth is the limit.
As I said, you don't have any particular reason for picking these numbers; they were just numbers thrown down to have a discussion. There hasn't been a lot of discussion on any of the lists anywhere. So, if people have other numbers they would rather see, if they would rather see it go strictly into weekly mode, rather than not see it at all, if you want to have that discussion...
So, the advantage here, the primary advantage is to keep the workload in the area where the members are rather than areas where the address space is.
Today, the members of each RIR are familiar with the staff. There's been reviews done, there's a lot of history built up. If suddenly a bunch of organisations go off to some other part of the world to get address space, they have to go through a whole review process to establish their history and what it is they've done with past allocations to be able to acquire new space, and that's a lot of extra work, so we're trying to avoid shifting the burden to a part of the world that will be a short-term burden and then go away once the remaining IPv4 pool is gone and you're into the market space. The disadvantage of this is that the RIR would have acquired a new collection of members at the tail-end won't get the fees for membership. So, with that, I'll go to questions and answers.
TOSHIYUKI HOSAKA:
Thank you, Tony. Any questions, comments?
RANDY BUSH:
Randy Bush from IIJ. Am I correct in saying that your proposal includes if I'm in ARIN and I want space and AfriNIC has it, that the request will be made from me to AfriNIC, and by the way, it says by the way under whose policy that AfriNIC has to deal with?
TONY HAIN:
You are an LIR, an RIR or an ISP? Just give me a context for you asking?
RANDY BUSH:
I started with Randy Bush, IIJ.
TONY HAIN:
I wasn't sure if you were in that discussion or something else. All right, so if Randy Bush IIJ were to go to Africa...
RANDY BUSH:
No, your proposal says, actually when you read it says that I go to JPNIC who goes to APNIC, who then goes to AfriNIC and makes the request.
TONY HAIN:
Yes.
RANDY BUSH:
So, indeed, the advantage you maintain first is not correct. Secondly, is this proposal, considering the reality of the situation is that it is most likely that the poorer countries will have the address space at the end, that indeed, this is merely the rich ripping off the poor, so is it rationality or racism?
TONY HAIN:
Excuse me, but it is neither of those. Come on. It is taking a look at where the people are and the resources they're going to consume, and it is not saying that you're going to rip off the poorer countries. It is saying that people will go off and find a resource under whatever policies exist and, rather than have them go off and stir the pot and create a lot of trouble, keep them where they are, keep the relationships in place and don't create a situation where people go RIR shopping because some other RIR had space and the other one doesn't.
If we establish the process for RIR shopping, that will be hard to go away.
ALAIN DURAND:
If you go from the RIR shopping for the RIR to protect themselves. If you go to the address space to be used, you have to provide for the region. That's very simple.
I wanted to add that this morning I had some sympathy for the proposal to say, let's take the last five and share them with a different RIR, there's a small cost that provides predictability and has an analogy and let's decide locally how to use it. Your proposal goes in exactly the opposite direction, which is a free for all, and let's grab the resources from a poor country and bring them into the developed country. I think this is not the thing to do.
TONY HAIN:
All right. What I'm suggesting here in the second bullet on the slide is, despite whatever you think, the members will go find a way to get the resource. They are going to set up whatever process they have to set up to acquire the resource from wherever it exists. They're not going to sit back and say, oh well, we have to wait until the market forms. They're not going to be nice. This is not going to be pretty when we get to this point. And having some process in place that establishes a relationship and keeps things at least sane and where everybody understands what's going on makes a whole lot more sense.
Put it in context, you give the RIR space to the pools, random organisation in some other region comes along and says, they're going to have a lot of blurb to put it in the bath tubs and I'm going to go and collect a bunch of it and nobody will see what I'm doing with it until after we get into the market space. Because I don't have to expose it. The 6 months we're talking about here is actually a fairly short window of time. Maybe this stretches out to a year. But, I can mask a whole lot of things behind that time frame and nothing can be done about it.
DAVID CONRAD:
Ah, flipping it back and forth probably didn't help!
I just wanted to clarify that the goal of this proposal is to recognise that when you're drowning anything that happens to look like it floats will serve as something that you will clutch to. Right?
TONY HAIN:
Yes.
DAVID CONRAD:
There's no implication that it is a goal to strip the unfortunates of the world of their resources. Rather, that that's going to happen anyway.
TONY HAIN:
That's the presumption that if we do something like this, we can know what's happening and have some chance of managing it.
DAN ALEXANDER:
Dan Alexander, ARIN Advisory Council. If the goal of this is to avoid people creating shell companies and so forth from taking it from the registries who have that spare space, what you're proposing here, isn't the end result the same? Although, you're only making it easier for those larger companies to acquire that space from their originating registry, rather than having them make the effort?
TONY HAIN:
It depends on how good the relationship is with the existing registry. If I set up a shell company going in and reviewing the process and having some chance of figuring it out, it's going to be very difficult. Whereas, if I talk to my existing local registry, they already have some history. They know what my past firm rate has been and what my likely consumption is. They're able to put more of a break on it than some organisations looking with some random plan that they've never seen before.
DAN ALEXANDER:
If they know my history and this is in place, I can immediately justify a large allocation based on past history, whereas if a sham company were to be created in a region for the purpose of acquiring space and the allocation system kicks in and it throttles it more than if this was in place.
TONY HAIN:
You're assuming only one company. Why wouldn't you set up 40 companies. How can you tell the difference.
RANDY BUSH:
Industries are not that stupid.
GEOFF HUSTON:
I've done some work in looking at the distribution of allocations across the RIRs, actually trying to understand the patterns of demand, and I think I mentioned this morning and I'll say it again that 5% of the address space in the last two years was actually allocated in 201 separate transactions out of a total of 13,500. Of those, six were from AfriNIC. Now, if you think about it, there's an awful lot of space going into a relatively small set of folk because that's the one where the distribution of addresses actually works.
If you expose all of the registries to the same demand set, the relatively small number of large demanders who, in effect, are looking at this distribution are distributed, ARIN and RIPE NCC would immediately move across into the remaining pools of LACNIC and AfriNIC and it would be all over immediately. Now, that might be desirable, and I make no value judgment, but, what I do observe is that in AfriNIC, the overall majority of allocations and the allocation sizes are smaller with the /16,/17,/18 and I could imagine the case being made. We would like to serve as that in our region as a priority, please.
Your proposal seems to expose that desire against global demands from a very small number of players who actually aren't in regions according to this distribution.
TONY HAIN:
Going back to the earlier comments, you don't know when the large organisations are going to come back and whether they're going to actually acquire space before the exhaustion point. The first order you know, they're history, but you don't know whether they're going to be going forward. The point is, we're going to get to the state of a market. The market will gravitate to where the resource is. The resource is still free in some areas. Processes don't matter at that point.
RANDY BUSH:
In the ARIN region, according to statistics published this morning, 75% of the address space in the last two years went to 10 entities.
TONY HAIN:
Yes.
RANDY BUSH:
The same is likely true to some extent at different variants here. I think less so probably in RIPE. This is not unique to this address space thingy. You know, it's a constant problem throughout the world and throughout the economies, etc. We have the rich countries and the poor countries and this will specifically and definitely advantage the rich over the poor.
TONY HAIN:
It is not intended to do that. It is intended to recognise...
RANDY BUSH:
I accept that it is not your intent. I'm telling you what the results will be.
ROQUE GAGLIANO:
Just a clarification. So, this is a regional policy that you are proposing so it could be not approved in all five RIRs?
TONY HAIN:
That's one of the points of discussion that needs to happen in each of the regions. I put it in specifically because it is not a global policy, it is a co-operative policy. So, if it doesn't get passed everywhere, then the organisations that passed could share amongst themselves but wouldn't necessarily share with the organisations that didn't.
PHILIP SMITH:
Philip Smith from Cisco. I will hold the mic!
I basically see this proposal saying that we do not need the registry system at all. That's basically what it says to me and for that level, I mean, if we want to basically propose that, we shouldn't exist, we should go ahead and do this. I think it is a really bad proposal.
TONY HAIN:
I don't see how it says we don't need the registry system at all.
PHILIP SMITH:
It says it very clearly, Tony.
TONY HAIN:
It says that the historical component for the IPv4 system ends, when the first registry runs out of space.
PHILIP SMITH:
Take it to the logical extension. If this whole, big common pool somehow is set up for v4, why would somebody not come along and say, well now, you've got this working for v4, let's do it for v6 and v10 and whatever other Vs come along afterwards and it walks straight into the trap that other agencies who do not like the way our system works want to operate. That's how it works. They as a central organisation want to run it and we're taking one step as a central organisation for the last pool of v4.
TONY HAIN:
I will not argue at all that the language could use work here. It was intended to be exactly the opposite of that because the logical extension of doing nothing is that the rich will go and raid the poor. By which process, by whatever process they have to do that, and if they are kept in their existing system, kept in the existing RIR system and not off registry shopping, then you retain the perception going forward that we're regional. That's where I'm trying to go with this. If I've not got the wording correct, so that you understand what I was trying to get to, clearly I need to reword it.
PHILIP SMITH:
I think rewording would be helpful, because at the moment it looks quite simply like, well, it was pointed out already. It makes it easy to do registry shopping.
TONY HAIN:
It actually doesn't, it says that the registries go collectively on your behalf to the other registry on your behalf so you aren't registry shopping.
PHILIP SMITH:
It means that you go and get it more easily. Registry shopping is hard. This makes it easy.
TONY HAIN:
No it doesn't. You're still going to the existing registry.
PHILIP SMITH:
Randy said that the existing registry is a shopping card. MasterCard is accepted! That's what this does. It is encouraging the shopping around of all of the registries. It says there, the second point. The registry members are not captive to their home registry. Registry members, if you can't get it from us, go to another one.
TONY HAIN:
OK, the way it came out here, this is a problem. This is the problem I'm trying to solve, not the solution. The registry members will go off once their registry is out of space. They will do whatever they need to get the space. The market will find a way to fill the void. I'm not saying that the second bullet that that's the solution, that's the problem.
PHILIP SMITH:
But the explanation of the proposal as I've read it and it was presented here. Basically, proposing a solution that's listed in the problem there?
TONY HAIN:
No, the solution is that you stay with the existing registry.
PHILIP SMITH:
And they do it for you?
TONY HAIN:
They do it for you, but at the same time, they already have the history to know what makes sense for you to have. Yes, your existing registry does the shopping for you.
PHILIP SMITH:
Exactly, that's what I'm saying, so why is this stopping registry shopping? That's what I'm saying, I'm completely lost. I would recommend that better wording and better thought is applied to it first. I think that's probably why there's been little comment, because people have been confused.
TONY HAIN:
OK, I can appreciate that, but it is not... the fact that your existing registry is off collecting space for you is not for the purpose of registry shopping. Yes, they're providing a shopping cart, I understand that point. But at the same time, you're staying in your existing registry space, you're staying in the distributed model.
PHILIP SMITH:
But, where the physical membership is versus where you get the address space from, it's going the same way.
TONY HAIN:
I guess I don't see the perceived attachment that people will not go off and do this. There's a perception that people will not go and raid the space that exists and I don't understand why people believe that.
PHILIP SMITH:
People are definitely going to go and raid the space that exists, is existing. This is what partly also concerned me with the /8 preserve for each proposal, AfriNIC and LACNIC have the /8 left over and nobody else has it. They're going to be raided for that whatever way and I don't like that, and this is just helping the raid happen. But it is an official approve between all of the registries raid, rather than just each individual entity trying to do it.
DAVID CONRAD:
It means that you have Registration data and allows for the same constraints that exist now. If you don't, then these folks will be going all over the world and setting up companies and using whatever fraud is necessary to get the address space that they need.
PHILIP SMITH:
And this doesn't happen now? Anyway, I'll leave the other people on the floor who have questions.
JONNY MARTIN:
Once he gets to the stage where one or more address spaces run out of space and they're going through all of the RIRs, do you expect them to actually abide by this policy at that point in time. You have the stage with a registry and a heap of space left and nobody else does. It's going to be a different time, so it doesn't just pop this proposal, assuming that you get to the point of an RIR that you have to pull out of this because we've got space and you haven't. This just makes it easier for them to exclude all of those, all of the registry shopping that's coming in proxy via RIR. I can't see how this is going to work.
TONY HAIN:
So the point is that they may agree to it upfront and when they get to the reality, they put it back out.
JONNY MARTIN:
Exactly, it is helpful to be friendly and co-operative, but in two years time, are we going to be in the same environment. Human nature would suggest probably not.
TONY HAIN:
Interesting. So, then the question becomes, is it in the registry that still has space, is it in their self interest to have a single entity that's doing reviews on their behalf, or have to go and do reviews of the collection of organisations that will randomly show up at their door claiming to be members at this point. Which is the better process for them. I understand your point, they would want it back out, but at the same time, if they think it through and realise if they back out, they don't have this organisation that's doing the views on their behalf. They have to do the reviews themselves.
JONNY MARTIN:
The history that they're talking about that home RIRs would have and the existing LIRs, the RIR that heads the space, they have it for the actual RIR. So it is pretty easy for them to filter out all of the bogus and shell companies that are coming along because they don't already exist as members of the RIR.
TONY HAIN:
So, if they apply the filter, they can't form any new company once one RIR has run out of space.
JONNY MARTIN:
In the same way that you can't form any more IPv4 space.
TONY HAIN:
Essentially, you caused everything to stop until the RIRs run out. Which may persist for several years if some organisation which has a very slow burn rate and a very large pool. If you have allocation and the one that tripped the process received just one and then tripped the process has 2, but the burn rate is so low that it's going to take them four or five years to burn out, you put something in the market space that Geoff is going to have and there's going to be a lot of weird things that they won't be able to fend off for three or four years.
JONNY MARTIN:
I think the proposal makes a great discussion. We'll finish on that.
TONY HAIN:
If anybody has specific language that they would prefer to see, please send it. I have no particular problem with the language, I believe that this is the space we need to go to, an approach makes sense. A lot of people think it doesn't make sense.
TOM VEST:
It is a comment and apropos to this discussion, and to many other policy proposals and discussions and it has to do with the statements which circulate about the distribution of transactions or the sum of resources and how they are currently distributed across registration, RSA signatories or LIRs or whatever it is called. There is a great deal of commentary about the distribution at the top in isolation from other thinking about the broader, the other dimensions of distribution, like the distribution from the bottom and things like that, and also specific assertions about shares going to the top-most people. Well, I mean, possession of the facts for one region, and if you aggregate to the most, the broadest conceivable level which is permitted by just the files themselves, in other words, you put the suppositions to the toughest possible test, you can deal with wild speculation.
You don't really reach the 75% mark in terms of space allocated over the last year and a half or so until you get to the top 500 recipients, at least for the RIPE region. I think, actually, I did not do a lightening talk, I thought about doing interpreting concentration diffusion patterns, there are standard ways to do that and to the extent we are basing very strong feelings about what you would do in the future or summary interpretations of what the past has produced. I think we ought to go through this in a defensible, systematic way. If you believe, if you are persuaded, that at the top, there is no limit of institutions that get everything, then it doesn't seem like the system is much different than even the most ugliest march you can imagine.
If that distribution is not quite correct, people might have a different opinion. I think again, these kinds of stats are driving a lot of opinions and to the extent you are vesting them with that, you should have a side discussion about what the facts are. So apologies for that, but it had to be said.
DAVID CONRAD:
My impression is that the implication of this policy wouldn't change the final outcome, the same sets of folks will probably end up getting essentially the same amount of address space. What it would change, however, is where the membership fees would go. The, the existing model, the membership fees would probably continue to go to the less developed RIR regions, in the model that you are proposing, the fees, there wouldn't be any additional membership fees.
TONY HAIN:
The list here, if you don't do this, there will be membership fees to whoever gets up holding it, if you do this, that doesn't happen. I don't know if there is an approach that makes sense, I didn't want to get into a fee discussion during policy proposal.
LOUIS LEE:
How much use is there of the other proposal to split up the last remaining /8s amongst the regions? Being that you could just go to your region to have address space from the other regions, that still have space?
TONY HAIN:
Well, in fact, this specific language I put that is not on the slide is that each existing RIR will become an LIR of the other region and have to conform to the LIR policies in the donating region. If the distribution policy said LIRs can only have 11 /16s at a time, I don't know. In some sense, I don't think the handout, or just run them out, makes a whole lot of difference. Either way, the space will be burned through, it just causes extra process and possibly, some key transfers to happen that wouldn't have happened otherwise, but in terms of timeframe, I don't think it makes any difference at all.
RAY PLZAK:
Following what you just said, I think one of the intents of the previous proposal was to allow each RIR the opportunity of how to plan to dispose of the last /8.
TONY HAIN:
It would, but I believe they don't have control of it to begin with. I believe the members are different from their past membership, right? So whatever the policy was, essentially, whatever policy exists today won't exist at this point. That is the problem, the initial problems.
TOSHIYUKI HOSAKA:
Any other questions. Comments? I heard some strong concerns and opposition and some clarification on the wording of the proposal but anyway, but the policy proposal submitted to the APNIC region, there was some talk it wasn't a policy proposal but I'm seeking consensus for the proposal.
TONY HAIN:
I believe there is enough confusion still that it is not working, I would like to reword it.
TOSHIYUKI HOSAKA:
But if you don't have any support at all, probably we should abandon the proposal one, and maybe come up again for the next meeting. What do you think?
TONY HAIN:
Whatever process you want to follow, I don't think it makes a lot of difference.
TOSHIYUKI HOSAKA:
OK, so I would like to see your show of hands. How many of you support this proposal? Please raise your hands? Nice and high. I see none.
OK, thank you. How many of you who opposed to this proposal? Please raise your hand? Nice and high, please.
OK, thank you very much. So I see no support to this proposal for now. So no consensus for it was reached to this proposal. So we will abandon this proposal for now, if there is no objection from the floor.
Thank you very much, Tony. So next proposal is proposal number prop-58.
prop-058: Proposal to create IPv4 shared use address space among LIRs
HIROYUKI ASHIDA:
Good afternoon, my name is Hiroyuki Ashida from its communications in Japan. I explain about my proposal from now on.
This is proposal overview. We propose to create IPv4 shared use address space among LIR. It is one /8. It is allocated the address out of global and LIRs in the AP region can use the address block. When LIRs in the other region use, we demand that is necessary to discuss & confirm in each region.
This block is not advertised to the Internet. The DB registration to RIR as the block of specific LIR is not necessary. LIR assign this space to its customers include enterprises.
Our motivation: LIRs can continue to provide current service for new customer after IPv4 address exhaustion.
Even if it is assigned only IPv6 address an end site, communications it not concluded.
The many communication equipments who does not support IPv6 stay in future.
Practical six-to-four translator for communication carrier has not been released.
The web site where link directly IPv4 address is left for the time being.
LIRs provide the connectivity using IPv4 private address RFC 1918 unwillingly. Routing is not concluded technically.
Many customers are using RFC1918 address space for their internal network, as a result, address of customer and LIR are duplicate.
The situation is expressed in this slide. Upper side is LIR network, LIR connects end-user at provider edge. This left-side customer is current, his traffic transit routers of LIR. Center is the customer assigned RFC1918 with NAT, addresses are duplicate like this. Right is the customer assigned proposed address with NAT, addresses that is different from both RFC 1918 and global are not duplicate.
And this block is closed in LIR network. Each LIR can use the block like this figure.
Next, I explain the ground of the detail of our proposal.
First, the ground of "one /8" that the size of space is necessary. There is an ISP that has customers more than 10 million in AP region, Japan. /9 is not enough.
Second, why AP region? There are opinions to be necessary at least in AP region, Japan. There is demand that LIR want to use in Japan. It have reached consensus at Japan Open Policy Meeting. If demands occur in other region, we entrust it to judgment of each community.
Third, why LIR limited? If end user uses this space, the duplicate of the addresses happens when LIR use it. LIR cannot claim to their customer, I will touch upon this reason later.
Fourth, why not RFC 1918 or 240/4. There are two issues using well-known private address. One is technical reason. Well-known private address does not influence only new customers. Existing customer receive the packet with RFC 1918 or 240/4 as source address. Legacy equipment cannot receive it. It is very difficult to update or replace the equipments of existing customers. If LIRs exchange the traffic between customers, LIRs cannot use destination-based routing. LIRs have to use source-based routing. It is very critical for large scale ISPs.
The situation is expressed in these slides. The LIR not only has residential customers, LIR connects enterprise customers who has their server. The traffic of customer transit provider edge, reach to the server of enterprise customer. If well-known private address such as RFC 1918 block, general firewall blocks.
To avoid this issue, if the traffic of NAT customers passes the NATbox of LIR, LIR have to use source address based routing. It is very hard operation for large-scale LIRs. It is very critical that ISP cannot use destination based dynamic routing.
Another reason of why not RFC 1918 or 240/4 is political issue. Anyone can use well-known private address because written in the documents. So, LIRs cannot claim to their customers: update software of your equipment; update your policy of firewall; renumber your internal IP address; buy your new router.
The customer says and conflict between ISP and customer. I'm operating NAT-box for the service of my company. I have experience this situation.
Why not global IPv4 address, if LIRs use global addresses to NAT purpose, they request large subsequent IPv4 address each such as this figure. IPv4 address exhaustion will be close and after IPv4 address exhaustion, LIRs have to assign RFC 1918 or 240/4.
Why not IPv6? Everyone says, "That's short-time issue, use IPv6". I understand that IPv6 is the best solution. New customer may not have IPv6 ready equipment. Actually, current and new customer is existing customer of other ISP. They have many equipments supported only IPv4.
This proposal does not obstruct a shift to IPv6. The service used this space cannot provide peer-to-peer communication. LIRs can make the time to shift to IPv6 enough.
This policy has many advantage. For APNIC: it promotes effective use of global IPv4 address space. For LIRs: by using this shared use address space, LIRs can continue to provide IPv4 connectivity even after the IPv4 address exhaustion.
LIRs can provide IPv4 connectivity by dual-stacking shared use addresses with IPv6 addresses. This is important as we currently do not have high-throughput IPv6-IPv4 translators for commercial use.
For end-users: end user can connect CPE that has only IPv4 after the IPv4 address exhaustion.
Disadvantage is one /8 is not small block, this block diminishes the address pool in the world by one /8. These are requirements of management: No need for allocation request from LIR to APNIC; no need for Second Opinion Request from LIR to RIR; no need for Database (WHOIS) registration; uniqueness in LIRs network should be ensured in LIRs network. It is the LIR's job: only LIRs can use this address End-user should be assigned from its upstream LIR
These are requirements of operation: should not be advertise to Inter-Domain network. It is recommended that an LIR filters those packets with this address as source and/or destination. Should not be allowed in IX. Reverse DNS delegation. LIR should manage and resolve reverse DNS for this address in their network, and should not leak it in the root-DNS tree.
That is all. If you have any questions, please ask me.
DAVID WOODGATE:
I believe there are two. One is the proposal itself, is additional address space necessary? The question is RFC 1918, is it enough? The experience I'm seeing within my company at least is that there are various issues coming up with considering future NATing scenarios where home gateways with a diverse range of customers and equipment, which are already using RFC 1918, how are they going to interact in a predictable way, if you try to do a NAT into another RFC 1918 domain? It would appear to be numerous technical problems which may just simply not scale across to that level. There are also other private areas in terms of network management where it would be beneficial but the - to have an additional range from the multitude of RFC 1918s that are currently being used but the current primary one is looking towards an IPv4 efficiency irrespective of trying to use a improved NATing capability on a scale in a reliable way into a double NATing situation.
The other issue that has come up on the mailing list I have noticed is one about does APNIC have a capability or a right to reserve an address space for this purpose? That is going to get into a discussion about what is the expectation of APNIC's allocations and the expectations of IANA, and I might leave it for a second set of comments in a while. But in terms of the first issue of is this required, I certainly believe that we need an address space. Now, would I foresee it handled as a local issue, would it be preferable to have had been handled as a local issue rather than a regional issue? In principle, I say absolutely. The question is, if you said that, how long would it take it to get it through and would there be any address space once it got through in a global level to have such an address space reserved? I'll leave you for the moment with that.
BARBARA ROSEMAN:
As far as the specific question
IZUMI OKUTANI:
Could you just slow down for a moment while I explain it?
HIROYUKI ASHIDA:
Thank you for your comment. I like to confirm just your comment in this meeting.
BARBARA ROSEMAN:
I want to ask how IANA would treat such a request. If we got a request from APNIC and they took a /8 and dedicated to a certain use that could not be documented for utilisation, IANA would have to treat it as an undocumented /8 and therefore it would count, whenever we go back and look at utilisation for APNIC's further requests, this /8 would be counted as undocumented, and therefore available.
PHILIP SMITH:
Philip Smith, Cisco, the slides on the screen basically explain a lot of the problems. The first problem is I understand the issue is really a request to increase private address space. Well, let's just follow the proper processes to do that. RFC 1918 had a proper process if you want to increase it - please do it that way. Barbara has indicated one of the problems with doing it this way, it has to be done across all registered regions. The second issue to have is, OK, you say LIRs should use it, how are you going to enforce that? How will you stop the end user from using it? There has been no answer provided there. It is a fundamental problem. Round table advertisement must not be allowed. How? What stopped the YouTube from Pakistan? Nothing. How are you going to enforce it? Must not be used for IX access, how?
It is all this kind of thing, it is a nice naive proposal but it is technically unimplementable. I would rather see you increase private address space to solve the particular problem you want to solve. This way, I don't think it will work, at all.
JIAN ZHANG:
I think Izumi is just explaining the question to him. Should we go to the next question or you are going to answer that?
IZUMI OKUTANI:
He presented it, he feels it is important to be noted clearly in the policy that the end-user is not available to use it and he feels it would, maybe some people will still use it, but RFC 1918 space, there will always be some people who misuse it but it will probably prevent the majority of people from misusing it, that was his comment.
ALAIN DURAND:
If you felt it was a good idea, and I stress if, then the proper way would be to go back to IETF and see if there is some space. But then the question will be how much more space will we need? You assert that one /8 is the answer. And I disagree. We, in 2005, exhausted our private address space, and we looked at that time how many addresses we will need in the future and we came with an astronomical number of 100 addresses or more. That's ten /8s, or more. So if you want to make this useful you have to make it useful for the large player, it is not just one more, it's not going to fix the problem, we need to put much, much more addresses, like, maybe a /4. And at that point, that becomes way, way too expensive. It is much, much better... it was much better, in our opinion, to start migrating to IPv6. In fact, what we have done in my organisation, where we have been planning for many years to use all our infrastructure and to migrate it to IPv6 because you don't have the address problems. It is what I would encourage you to do, try and see how you can use IPv6 internally to relieve some of your pressure and go that route instead of creating this huge amount of space that will be private space that will be lost for everybody.
HIROYUKI ASHIDA:
I think this is closing the LIR but actually, this work will be close under the NAT, the NAT.
IZUMI OKUTANI:
So regarding your point that no, it would need to consume a large volume of IPv4 address space in order to have it, make this policy effective, he feels it is likely to be used within the NATbox of LIR, so a single LIR can double use the same address space. But it is multiple NATboxes, so the proposal feels that this, having a single /8 would be, in fact, effective way to address the issues he wants to solve.
JONNY MARTIN:
The points that were just raised is what I was going to say. I'll stop from saying I agree with it. There are two problems from a network provider, the first is having enough space to number all the devices you wish to number, the second problem that is there is trying to remain some semblance of uniqueness within a domain. The big issue is when you get mergers and acquisitions happening, be it over 20 providers or different arms of a single provider, as I have seen happen a couple of times, it doesn't solve the problem - you still have collision between the entities. There is only one solution to that is that is unique address space, you are after unique address space and you need more of it, you have to go with something with more addresses with more addresses in it than IPv4. It seems it be a weak attempt to delay the deployment of IPv6, which we all realise is necessary.
IZUMI OKUTANI:
So the presented proposal has considered the case of merger and acquisitions, and in this case, still wouldn't solve the problem but they feel that out of the total number, the total number of people who will benefit from this proposal, the mergers and acquisitions cases is quite small in volume. So they have potentially left out of the scope of this proposal, so he agrees it doesn't solve the problem for those cases but it is quite rare compared to the total number of people who benefit.
One more point, and again, according to the point made earlier, as long as the address space is actually assigned to the physical NAT machine, just not duplicate, they can share the same address space within each user's shared subscribers pool. So he thinks even with merger and acquisition, it probably won't be as big a problem as you feel it is.
DAVID WOODGATE:
There are a few problems. I disagree with the comment about the technical manageability of the implementation for a couple of reasons. To start off with, in principle, you can argue that RFC 1918 itself is not a manageable situation and yet the world has put up, pretty much, most of the route filters required to make it a manageable and acceptable space. I don't see it is any different, in fact, it may be slightly easier because the principle here is that by consensus between the ISPs would be you would implement it within an ISP infrastructure and probably the ISPs would throw up routing filters to end-user sites against any errant route advertisements.
In terms of Jonny's comment about the mergers, I also agree with the presenters that although this will change it from being a manageable, sorry, although you would still have to cope with the merger of a couple of networks, that is a smaller scale and manageable, albeit painful situation to have to go through, whereas dealing with thousands of customers sites you are trying to manage with addressing for some reason, it becomes an unmanageable situation.
And in terms of Alain's comment, I would certainly agree that you, I mean, (A) I agree you produce multiple domains within the space of the ISP and I would also suggest that nobody would be trying to use it as an internal delaying tactic to avoid from going to IPv6, but indeed, just trying to grab, an attempt to grab some breathing space while IPv6 plans are developing more thoroughly. There are enough issues that are immediate and around now with private space that some additional space would certainly be of benefit, I think, to the general industry.
IZUMI OKUTANI:
So, the presenter appreciates your comments for the support and one thing he like to add, this proposal, the proposals also think the long-term issues for shifting to IPv6, this is only providing a temporary solution, it is intended to be intentionally, intended to be a temporary solution. So it is trying to address the immediate needs at the time of exhaustion.
JONNY MARTIN:
If we think it is a temporary solution, we are going to be dealing with it forever. The other thing I will say is we will, all the particular considerations, sure, there are lots of things that can be done one way or another, but it is not what we are debating, we should be doing it properly and following existing procedures to get more address space, even if the private address space is commissioned for its use.
IZUMI OKUTANI:
Also, regarding earlier comment about, it might stop the deployment of IPv6 and you know, this being a temporary solution, then it might still be continued to be used in an undesirable way, so regarding that point, the proposal thinks that even after we move into IPv6, the IPv4 Internet still remains. So this space is still necessary to address the issue that we face immediately. But even after the IPv6 network takes place, this address continues to be necessary in order to maintain and operate IPv4-based network.
JAMES SPENCELEY:
I also agree that the forum is not the most appropriate - the disadvantage is that the appropriate forum is going to take a lot longer. And we don't have the address space left. We tried to get an address space allocated for IPv4 address space and it went nowhere. I suspect placing it into the IETF will go nowhere too. I strongly support this, I think it will become useful and in the future chaos it ensues, we will think why didn't we do it. My greatest issue is as a regional level we can all agree we will never route the space and back each other every six months and pat each other on the back that we didn't do it, but it doesn't stop a global announcement or and unless there's a global commitment not to route the address space, and in the desperation our customers will feel, someone will announce it and the first person to announce it won't be the last.
IZUMI OKUTANI:
Thank you for your comment about the need for maybe, perhaps a better way to proceed with this and also he feels that the discussions so far, it is probably shouldn't be closed within the APNIC region and we should discuss it on a more global basis.
PHILIP SMITH:
This is getting more bizarre as time goes on. You said we only need one /8 because if we need more we will use NAT in between our domains or something equivalent. If you are going to use NAT between your domains, what is wrong with /10s and all the different - you can double NAT or triple NAT because you seem to love NAT. I'm sorry, it is just so ridiculous now. You can look at the network diagram here, you are a transit provider, trying to do traces through the network, you can't see anything at all, troubleshoot your network, you can't troubleshoot your transit provider's networks, ISPs already use it for infrastructure for a supposed security region that it is just so hard to run a network.
Why are we trying to find bizarre ways to run our networks and our infrastructure when there are perfectly valid, legitimate ways of doing it? And Jonny has mentioned one. Just use v6. We have had explained what Comcast did. Why find bizarre solutions. As the forum goes on, even more and more strange suggestions are coming up. If more private address space is needed, do it. Let's try it, not every ISP space is run as well as Telstra and filtering it and filtering private address numbers. You look at the full speed, you see all sorts of garbage appear, so we can't just assume that you know, it is just another one we have got to filter because very few people pay attention to it.
IZUMI OKUTANI:
OK, just translating what the proposer has said, regarding the point that simply used private address space and use multiple NATS and in that case, if the end-user is also using the private space, it might duplicate with the private space that ISPs infrastructure is using. So that is the biggest concern that is the proposer has.
PHILIP SMITH:
You are already NATing your private address space. The end-user, if they are using private address space, you are already NATing them to connect to the Internet or are you providing some private routing domain that is nothing to do with the Internet? If that is the case, why are we even talking about this?
RANDY BUSH:
Double NAT.
IZUMI OKUTANI:
It is not just an issue of an end-user using private address space but for enterprise customer, using global address space they will not be able to receive the packets from those end sites that are using private address space if we don't implement this solution.
BILL MANNING:
No, no, I'm sorry, you're going to take this one somewhere else. There is a line and we are going to finish this. So you can have the engineering discussion at the bar. This is Bill Manning and Philip alluded to more and better ideas coming. And I will support this proposal as the next step, or actually, as the first step, in what should have properly been done with RFC 1918 in the first place. And as a step towards, go towards IPv6 which is to take each /8 individually and the IPv4 space and turn it into private space. And then the public routing of IPv4 would occur over RFC 1918 space between transit providers. This gives you the equivalent of IPv6 /32 and IPv4 space for the ISPs. When you are comfortable with that, you can turn on IPv6 because you'll have all the infrastructure in place. If that is your intent, then I support this proposal.
IZUMI OKUTANI:
I'm sorry, I didn't quite catch your... but I just got the sarcastic part of it.
BILL MANNING:
There was, in fact, no sarcasm here.
JONNY MARTIN:
I think everyone is in agreeance that having more private address space or private-with-conditions-on-it address pace is a good thing. Nobody is arguing with you there. The biggest problem it seems to be not an APNIC problem to solve. As Barbara said in the second comment here, if we do this, that is a /8 against APNIC's name. I have got no problems with APNIC leading the way in terms of global policies and that sort of thing but we should not be doing this ourselves. So I think it is, this is, you could look at this, good work to start the process of increasing the RFC 1918 space increase, it is a win for all, if we can stop the insanity here right now and move on and do this the proper way. A lot of happy people.
IZUMI OKUTANI:
The presenter understands your point very well so he would like to seek comments on two steps, whether people feel this kind of address space is necessary and the second is a comment to the people here, what do you think would be an appropriate process that is moving, if people think this kind of space is necessary.
ALAIN DURAND:
First of all, I do not think this is necessary, I would strongly encourage him to read an Internet draft that I have published at IETF, to be discussed in two weeks in Philadelphia, in the working group, the name of the draft is Distributed NAT for Broadband Deployment Post IPv4 Exhaustion and I can give you the point if you want to read it. It is talking about scenarios before NATs, but you would have v6 but you would have internals and there are many, many ways to solve the problem that do not require more private IPv4 space.
JIAN ZHANG:
May I make a suggestion, it is time consuming, we still have three proposals to go.
IZUMI OKUTANI:
OK, the presenter is aware of the case of Comcast and the technology that is implemented but he feels that it doesn't actually solve the problem of managing the traffic for end-user.
ALAIN DURAND:
Read my draft.
HIROYUKI ASHIDA:
I read your condition, thank you.
DAVID WOODGATE:
With permission of the chairs, can I just take a quick straw poll, I was wondering whether the chair would care to ask the question whether there is support for the idea of going to the IETF in this group and seeking more private address space, or does the group here believe that that is not worthwhile? Would the chairs be interested in putting that forward?
IZUMI OKUTANI:
One more question from the presenter, should it be IETF or presented to each RIR globally? I think it makes quite a bit of difference?
RANDY BUSH:
The IETF already turned it down once.
GEOFF HUSTON:
Some years ago, the APNIC community decided by policy proposal to have documentation to use v6 addresses. We accepted that, did all the things, Yes, this is a wonderful proposal. It became APNIC policy. We went to IANA and said, Make it so. IANA said, "Excuse me, it doesn't happen like that. They said, "The only way it will happen is if it is an IETF standard, and RFC published." So they published it and requested the address be placed as an IANA special address entry. When published as an RFC through the IETF process, it happened. I suspect the proposer is trying to create a special use prefix. If that is the case, the normal accepted precedent, and I believe the only way we have been able to do this has been through an IETF standards action, which is a published RFC.
It does entail a series of steps of review in the IETF process. To help you, the previous type, we APNIC, were in this particular situation, and we went and approved the policy, it still didn't make it happen. You still had to go through an IETF standards action to make the entry into the Internet registry files, thank you.
TOSHIYUKI HOSAKA:
So are you suggesting we should seek consensus here first and then go into IETF?
GEOFF HUSTON:
I have no opinion what gets an RFC through the IETF.
JIAN ZHANG:
So let's make, that will be the last question.
JAMES SPENCELEY:
You asked if there was support in the audience, yes, I support it, I guess, the IETF based on Geoff's comments is the correct place and I encourage you to do that and also the VPN address, nothing to it and I wish you luck.
TOKASHI ARANO:
Some of you will know, all measures in Japan is now considering to implement IPv6 and during the study, we found the ISP, more full of address spaces, in parallel to the growing IPv6. So just doing IPv6 is not the solution because IPv6 is not now, technically operationally mature, not mature. So from the past, they need to go both global IPv4 and IPv6. It is our conclusion. It is why they are proposing this. Please understand it. It is also described in the JPNIC exhaustion report analysis, OK? So of course, delaying IPv6 is not the intention, definitely. And hearing this discussion, we better discuss two things separately, the requirements for it and how to implement the requirements. First of all, let's discuss on the first issue and the second issue is very difficult to implement, I know, but for us we should consent first on the requirements, whether we need more private address or not.
DAVID WOODGATE:
Sorry, just been asked to repeat the question I asked earlier - would the chairs please ask the room whether they felt, for their support, whether they thought there was general support for that request for further private space should be made to the IETF?
JIAN ZHANG:
We can do that, but according to the procedure, going to seek consensus first, then we can ask the question to the audience.
DAVID WOODGATE:
It is more just an indicative thing, not a procedure.
JIAN ZHANG:
I know, but we are going to ask for consensus first. So far, as we can see, there is so many concerns about this proposal, still I'm going to ask for those who support this proposal, please raise your hands?
OK, thank you. For those who oppose this proposal, please raise your hands?
So that is not consensus, I guess.
JIAN ZHANG:
As David suggested when we ask, how many people support to put this proposal IETF procedure? For the support for the proposal, please raise their hand. Thank you.
TOSHIYUKI HOSAKA:
Thank you very much, that is maybe a good feedback from the floor. So this proposal does not reach consensus but should consider other ways to make this happen. Probably the floor general feeling is that we should go to the IETF process.
HIROYUKI ASHIDA:
OK. I would like to reach consensus, thank you for your comments and opportunities.
ALAIN DURAND:
You asked the question, you did not ask the opposite question: does the room feel it does not go to IETF?
TOSHIYUKI HOSAKA:
Fair enough. Please raise your hand if you think this proposal should not go to the IETF process? Please raise your hand? Two, I see two?
Thank you very much.
HIROYUKI ASHIDA:
Thank you very much.
TOSHIYUKI HOSAKA:
Thank you, anyway.
APPLAUSE
TOSHIYUKI HOSAKA:
It is now 3:45 and it is now coffee break. So we are resuming our meeting from 4pm. We have 15 minutes.
[END OF SESSION]
APNIC 25
Policy SIG
Thursday, 28 February 2008
1600-1730
TOSHIYUKI HOSAKA:
We are discussing prop-053, changing minimum IPv4 size to /22. Originally, this proposal was submitted to propose change the minimum allocation to /24, but after the mailing list discussion, the original changed from /24 to /22.
Unfortunately, the original author of this proposal cannot attend this meeting, so on behalf of the original author, he's going to make a presentation. But, I heard that you're taking - you're not going to take any questions, right?
prop-053: Changing minimum IPv4 allocation size to /22
KUSUMBA SRIDHAR:
Good afternoon everyone. Since I'm in favour of part of the proposal, maybe I'll take some questions. If there are any, we'll put it back to the author. I need to listen to the questions.
TOSHIYUKI HOSAKA:
OK, so the original proposal content is two aspects. One is to change the minimum IPv4 allocation size from /21 to /22. The other is relating to fee. As you may know, the Policy SIG is not the place where we discuss the fees, so we request for someone to separate those two things and focussing on changing the minimum IPv4 allocation sites. So, please focus on the minimum IPv4 allocation size change. So, Kusumba, please.
KUSUMBA SRIDHAR:
This proposal has been discussed at length in the mailing list. It is more of a summary and the solution to change the result is reflected now. As mentioned, this proposal actually has two parts. One is the change of the minimum allocation criteria, that's part one of the proposal. And the second one was to create a new type of membership at a much lower fee with a minimum allocation criteria.
Now, as mentioned, as an EC of APNIC, I would not be happy to be going to the second part of the proposal, since it is not something that we feel we have to discuss policy and that's been on the mailing list too.
So, this is where it started. I'll quickly go through the notes because I think this is something we will discuss again. Some background from agendas - Does APNIC have a minimum allocation? Yes! APNIC's minimum IPv4 allocation is /21 addresses. The APNIC community has set this as a minimum practical size in an effort to abide by the conflicting global goals of aggregation and conservation. New members are allocated a /21 as part of the "slow start" policy. Now, if there was to be a question, if you were to request less than /21, what do you do? And the FAQ realised, I think, that really at the bottom, going to LIR. This is the correct policy that we have.
The problem there are two things, not only with the minimum allocation criteria, but the significant difference in between the allocation and the assignment, so as we've seen, policy for IPv4 in the Asia-Pacific region. There is a significant distinction between allocated and assigned.
Allocated address spaces is address space which is distributed to RIRs and subsequent distribution which has to be used only in the same network where it has actually been assigned. And it also explicitly says that this may not be sub-assigned.
Now, with this background, here is a table of the current membership tariff. You'll see the rates in the Australian dollars since now we're talking about Australian dollars. So, we have - I'm skipping associate because there's no address space there. A very small member at this moment gets up to /22, up to and including /22 for which he pays AU$1,584. The small is /22 and up to /19, which means that if somebody wants a /22 alone who is an ISP, ask for the minimum allocation criteria of APNIC, you have to justify your set of /21, but then that /21 falls in small criteria. Now, here's the issue.
Is membership a suitable option for my organisation? Again, an extract from the membership FAQ. APNIC membership is open to all organisations. However, membership of APNIC does not mean their organisation will automatically be eligible for address space. To promote better aggregation of routing information, APNIC has a minimum IPv4 allocation of /21. But, the problem is the really small membership is an assignment and the small membership is an allocation.
Now, that's the trick here, which of course was done through policy consulting, but at this moment, this is currently creating a couple of issues in terms of the membership, not small ISPs to either do multihoming or not being able to connect to multiple peers. This is an impact which we also have seen recently in India, when we had 65% of Internet of India thrown out. And the first quarter we had this issue when we had an earthquake in Taiwan, so those small ISPs who go to the regional use as a broadband service provider, who of course finally depend on them and to defend /21 here, but having said that, still the regional ISPs could not connect to the ISPs. That ended up creating these issues. As I just mentioned, ISPs that need resources less than or up to /22 will not get allocations due to a minimum allocation criteria being /21 though the small category starts as above /22 and up to /19.
ISP inevitably is forced to become a small member, though his requirement is met by very small member criteria. The last one, current policy, is not accessible to smaller ISPs and could not become a member of APNIC and obtain resources directly. So, these are the issues and the author also suggests policy change requests as given here, but, this goes as two parts, because the policy request also had two different parts, one dealing with the policy and the other one dealing with the fees. For the part one, the minimum allocation criteria as a /22 instead of /22 so that the member can remain in very small category and still get the resources. They can be allotted and which are not assigned, for which we may have to resources to very small category be allocated and not assigned by doing so.
Just as a snapshot, here is the minimum allocation criteria of the other RIRs. AfriNIC has /22. ARIN of course /22, only when you're able to demonstrate multihoming, otherwise the /20. LACNIC /20 and RIPE /21. The second part suggestions for this policy is that either in order to create the minimum allocation criteria to the request, instead of listing the existing very small membership, it is also created to differentiate again between ISPs and non-ISPs, we create a tiny membership and where the membership is in the resource fee, should be lower given the smaller ISPs.
So, these are the two policy change requests coming out of this policy request, and I think that's all we have.
As I mentioned, part two is something to deal with the fees, which I personally feel is not essentially... can not be discussed in the Policy SIG and it is something that EC has to do about it. So, if you would like to discuss part one of changing the minimum allocation criteria to /22 instead of /21 so that the member can still get allocatable resources in the smaller category. Thank you.
TOSHIYUKI HOSAKA:
Thank you. Any questions? Comments?
DAVID WOODGATE:
My understanding of the proposal as it stands, the two parts are still intertwined within the proposal, so at the moment, we can't reach consensus on the proposal as submitted. Is that a fair statement without agreeing to both parts. Is that a correct statement?
KUSUMBA SRIDHAR:
I guess the author is willing to drop the part two part of the proposal because the request has a primary consensus to take this proposal ahead and put in one part while dropping part two. Because if it is having the part two, it wouldn't go into the Policy SIG. That's my personal opinion.
LOUIE LEE:
Hi.
KUSUMBA SRIDHAR:
We just had tea, so it may not switch on again.
LOUIE LEE:
Louie Lee, I am here channelling Bill Manning. He's unable to be in the room right now. Bill is in support of this proposal. However, he believes that there is a typographical error in that the /22 mentioned should be a /32!
RANDY BUSH:
33, do I hear 34!
PHILIP SMITH:
Philip Smith, Cisco. I support this proposal as well. I'm delighted to see it has been approved from the previous version of /24 as I couldn't understand. As those of you in the mailing list have seen, as the authors have seen. So, /22 is fine if it reduces the barring into APNIC membership. If it gets more ISPs and using real address space and can be independent of the upstreams, great. So, I think this is generally good stuff. I would like to comment on the membership category stuff, but given it is not the place to do it, I won't.
KUSUMBA SRIDHAR:
As I mentioned, I think the author is happy to drop the part 2 part of it because the proposal requires minimum eligibility criteria for it as a policy. I guess we're dropping the part 2 part of it from this moment. So, if the chair is OK actually, we can still take consensus for part 1.
TOSHIYUKI HOSAKA:
Part 1 only.
KUSUMBA SRIDHAR:
Yes, since it is being recorded and made to go.
IZUMI OKUTANI:
This is not really a comment from JPNIC, but just sharing. We discussed this proposal in our community so just sharing the questions raised. There was questions asked by minimising the size, how much would it help to remove barrier? How many members would benefit from this proposal? And, is this issue more of a fee rather than the changing of the criteria. These were the questions raised on the mailing list.
KUSUMBA SRIDHAR:
I'm not sure. Rather, I would like not to directly answer this, but yes, the same question I had and I have pulled out some interesting statistics there about the current membership position in the APNIC. So, if you look at the very small membership, it currently has 304 members and there is a significant possibility of growth there since you must have seen that, there is a change of 48% in the small membership trial, which actually is most of the guys who have easily been accommodated into the very small since their department is very small. But inevitably, they are much smaller, they had to go to small. Just because they wouldn't qualify the minimum qualification criteria. So, the increase in the very small, and you can definitely see many members coming back or many members coming to the APNIC and resources can be utilised, and with my practical experience, I know if you look at our part of the world in south-east Asia, that the small category members who have got the current allocation, I'm not sure if they are using those resources more than 50% of the time. So I think this is one way of basically, we are trying to give them only what they actually want, but not give them something more when actually they don't want it.
JONNY MARTIN:
Jonny Martin from NZNOG, New Zealand. I support this proposal as well. I think it is great to bring down the barrier entry for a lot of smaller ISPs and providers and even medium businesses themselves. I think it is a positive spin-off of this policy change and the New Zealand content would help to introduce a lot more content within the actual ISP and into the business, purely because when you put it in the hands of the end-users, the end organisations and also beholden to a telco or a transit provider for the space. That's a positive spin-off indeed.
KUSUMBA SRIDHAR:
Thank you.
PAUL WILSON:
Paul Wilson from APNIC. I just wanted to clarify in case it is not clear to everyone that the minimum allocation in the APNIC case does actually represent a strict barrier to entry into APNIC membership. I'm sure this is what you were trying to say. So, just to be quite clear in the case of APNIC, you cannot receive addresses unless you get a portion of them from the minimum allocation in terms of medium usage, so it is a barrier. Izumi's suggestion that numbers would help I think is a good one, but the problem is that because what we're seeing here is a barrier that prevents people from entering at all, we don't know how much people are being discouraged or turned away and it would be difficult to do that.
I can say though that I think for what it is worth, it is fairly common wisdom that in developing parts of the world, this minimum allocation is important and I think it was a very concerted effort in the case of AfriNIC to ensure that the minimum allocation was appropriate for the region, and it was quite a heated discussion at the time, but one in which that issue I think was demonstrated and then accepted, that in AfriNIC's case, it was a reasonable situation. Now, in APNIC's case, we have a very wide range of situations and circumstances for the different economies of the region, from highly developed, through to lesser developed, and underdeveloped. So, definitely, we could say, what goes for AfriNIC and what was well accepted in the AfriNIC case should go at least for the underdeveloped regions of APNIC. I'm not saying on the other hand that we should have different criteria for different countries or economies. I think that would be very difficult. But we should recognise if our overall regional policies are disadvantaging one part of the region, I would say based on previous discussions and accepted policies in this area, we should take that into account and take action to ensure that no-one is discouraged.
KUSUMBA SRIDHAR:
Is it not that some of the African destinations, regions, also have allocations from APNIC? I think we do have some criteria for that, correct?
PAUL WILSON:
No, we had a number of countries, a small number of countries or economies in our region that were transferred to AfriNIC, eight or so in and around the Indian ocean, actually.
ROQUE GAGLIANO:
Roque Gagliano from LACNIC. I wanted to comment for the Latin American region, that is the minimum allocation size that LACNIC does, but in reality, there are two things. The thing is, what does it say about the qualification for the allocation, and the other one is the size. In order to get an allocation for LACNIC, you need to prove usage of a medium necessity of a /23, so to detail one year usage for a /22. And actually, the first allocation, you receive a /21. Just to clarify. So there's two things, the size you get and the addresses that you need to prove that you're using.
KUSUMBA SRIDHAR:
I take your point. So, actually, the minimum allocation criteria, you said it is /23, right? OK! I think that's definitely something that fits into the proposal which we're trying to say, we're still saying that it should be /22 as the minimum allocation criteria. I think that's every good thing from the proposal at this moment.
TOSHIYUKI HOSAKA:
OK. Any more questions or comments?
ALASTAIR JOHNSON:
I'm now somewhat more in favour of the proposal than I was initially now that it has been revised. Going around the membership tier that was mentioned. I'm wondering if any analysis was done on the impact to the IPv4 zone.
I was wondering, given the increase of a likely increase in prefixes that will enter the default free zone from the additional members that will now be announcing these unique /23s or /22s, do we have any idea what that's likely to do? Will we see a couple of thousand or a couple hundred or a couple of dozen?
KUSUMBA SRIDHAR:
I don't see if it would go into the thousands, I could put up here another slide, which I don't have it right now, but that would probably give you some idea about the current ISPs who are in different classes in India if you really look at it that way. Totalling about 357 of them right now. We have about 150 of them as members to APNIC, and there's still about 200 of them who are still depending on the LIRs. Out of that, I can tell you that the Vice-President of the ISP Association of India, I can tell you that about 75% of them are the guys whose requirement is only something that is less than /22.
ALASTAIR JOHNSON:
Thank you, I echo the comments that it would be good for New Zealand.
KUSUMBA SRIDHAR:
When the proposal came with /24 as a minimum allocation criteria, we know that the boxes would need to be geared up to do that, but then Version 2 carried /22 which is quite demonstratable at the moment. Since this policy was actually made, now there's a significant improvement in the routers and the capability of handling this type of route. Though, a couple have tried filtering it.
TOSHIYUKI HOSAKA:
Any more questions?
KUSUMBA SRIDHAR:
I have a concern here. If we're going to take on the part one of this, that two solutions on this.
TOSHIYUKI HOSAKA:
Definitely.
KUSUMBA SRIDHAR:
One is talking about changing the minimum allocation criteria, which also must result in changing the very small to an allocation assignment, whether we're going to do it that way, or - I'm actually not clear on that point.
TOSHIYUKI HOSAKA:
We don't care what the tier membership is? Just what we're discussing on the minimum allocation size.
KUSUMBA SRIDHAR:
Yes.
TOSHIYUKI HOSAKA:
So, before we were seeking consensus on this particular proposal, I would like to make sure that part 2 of this proposal has been cut off.
KUSUMBA SRIDHAR:
Yes, it is dropped at this moment. If it has to come back, it will come back as a different proposal or a different group at a later date.
TOSHIYUKI HOSAKA:
OK, I would like to see your show of hands. How many of you support to change the minimum allocation size to /22? Those who support, please raise your hand?
Nice and high please.
KUSUMBA SRIDHAR:
Here, it's me, am I counted! OK!
TOSHIYUKI HOSAKA:
OK. Those who do not - sorry, those who oppose the change from allocation size to /22, please raise your hand.
I should say this is a rough consensus. So, the consensus, the rough consensus was reached to change the minimum allocation size to /22.
KUSUMBA SRIDHAR:
Thank you, Chair and thank you everybody.
Just before leaving this, I have small news to share with you all and request your help.
One of our EC members Vinh Ngo is currently in hospital in Australia, he's suffering excess iron in his body and the doctors have mentioned that his liver is not functioning properly at this moment and he is on a drip. I request you all to pray for his speedy recovery and please do pass on the greetings, and he passed them on through the APNIC Secretariat. Thank you so much.
TOSHIYUKI HOSAKA:
Thank you for your presentation.
Next, we have a presentation from David Conrad. And originally, he was going to make some presentation for his proposal IPv4 soft landing, but you changed?
DAVID CONRAD:
Yes, a bit.
TOSHIYUKI HOSAKA:
OK, so is this a proposal which you are going to seek consensus for?
DAVID CONRAD:
No.
TOSHIYUKI HOSAKA:
OK, thank you for your clarification.
prop-056: IPv4 soft landing
DAVID CONRAD:
There we go. Hi, I'm David Conrad. Originally, someone twisted my arm repeatedly to submit a proposal called Soft Landing, and we won't say who she is, will we Sam!
After many e-mails, I finally did get around to submitting it. That caused our hero, Geoff Huston, to respond, saying it was crap, more or less!
So, I'm here to propose something slightly different. It is Softer Landing. And I chose that particular transition just to drive everyone insane, because that's what this has been doing to me!
So, the Soft Landing proposal, basically, it had, it proposed to have a serious of thresholds tied to the amount of space left within the IANA free pool, and the thresholds would result in a incrementally tightening of requirements for additional allocation of address space, and some of those requirements would include documenting the use of non-RFC 1918 space and your IPv6 plans, and there would be additional requirements to meet in terms of percentage of utilisation that you assign as an ISP, you assign to our downstreams.
The analysis that Geoff did - first, the basic idea was to encourage increased space utilisation efficiency. That is that the amount of address space that ISPs would then sub-allocate to their customers, the idea was to try to increase that efficiency, and if that increased efficiency didn't work, then the impact of Soft Landing would actually be minimal. Geoff ran the numbers using his various, very complicated mathematical functions and pulled a number out of his, well... out of his ear! And then estimated a couple of months.
The problem is that Soft Landing is actually a very complicated proposal. There are four or five thresholds even I've forgotten. There are lots of additional requirements and that would impose significant additional work for the APNIC staff, and the question really becomes, is the benefit worth the cost? If there's not a significant increase in efficiency, then it definitely - at least in my opinion - wouldn't be worth it.
So, going back to first principles, it would be nice in my opinion if we had more information about how the transition to IPv6 was actually going, about the state of IPv6 planning, who is actually planning on deploying v6 and who is saying, we don't need the stinking v6 stuff.
And what people are doing with the RFC 1918 space, not what they're assigning to customers but what they're using for numbering for routers and that sort of stuff.
If we had a policy that required this information, it could actually encourage people to think about doing IPv6 transitions sooner than they may have otherwise. It may result in their CEO saying, "Well, why aren't we doing this?" That sort of thing. So, that resulted in this idea that I'm calling Softer Landing.
I should say that I threw this presentation together just before lunch because, actually a little before lunch because I was told that I had to present before lunch, so this isn't well thought out. I'm actually soliciting input and ideas. If this is a bad idea or whatever. But the idea is like, have a single threshold where this would apply, i.e. 35 /8 s in the IANA free pool. And when the threshold is crossed, in order to obtain additional v4 address, you need to document your deployment plans for v6 or document why you don't believe you need plans to deploy v6. To document the use of non-RFC 1918 space, or explain why you don't need, why your employee can continue to use non-RFC 1918 space, and there are some other things like, in the original Soft Landing proposal, there was an idea of having a standardised survey that the RIRs could submit, could require their customers to obtain to submit in order to obtain additional resources. Something along those lines could be continued, and the idea is to try to gauge information about how the transition to v6 is occurring to help the RIRs prepare for the inevitable joy of run out and for helping to promote v6 deployment. So, that's it.
Any questions?
RANDY BUSH:
Randy Bush. Could you roll that last slide again. Do you really mean that in the last bullet, to promote the use of 1918 space?
DAVID CONRAD:
Promoting the use of 1918 space? Yes.
RANDY BUSH:
This soon after lunch!
DAVID CONRAD:
Sorry, in the context of internal infrastructure, stuff which doesn't appear for the router interfaces and that sort of stuff. Instead of using globally addressable space, for things which are only within your internal infrastructure.
RANDY BUSH:
OK. For $100 each, I will help to give people plans on why they do or don't need v6 to get past this.
DAVID CONRAD:
I understand.
RANDY BUSH:
I would do it for any other example. I think those will be passed around. I happen to like the idea. I think you're sending the right message, aside from the 1918 thing. But I think it is the right - it send a pretty good message.
JAMES SPENCELEY:
Observation and question in one. Do you feel that by creating this artificial limit of 35 /8s, you might speed up the allocation to that limit before you slow down the allocations? Because people know that they're getting closer to this and they request.
DAVID CONRAD:
Right now, we're at 41. I don't actually expect - to be honest, I don't think anyone would actually notice.
JAMES SPENCELEY:
Fair enough.
ALAIN DURAND:
I like the new proposal much better.
DAVID CONRAD:
I'm shocked!
ALAIN DURAND:
But what I really liked in the second part about the documenting of plans and having standardised way to compare IPv6 deployment in the different regions or the different players, and this is something that you really had to establish a merger of the uptake of IPv6. And I think it is a really, really good thing.
DAVID CONRAD:
Thank you.
DAN ALEXANDER:
I guess my question is, with these statements, deployment plans, is there a right or a wrong answer to these questions?
DAVID CONRAD:
My immediate feeling is that there isn't a right or wrong answer. It is basically information collecting, because I wouldn't want, or speaking personally, I wouldn't want to get into a situation where organisations feel it necessary to lie in order to obtain the resources necessary, because that would just result in the behaviour that Randy was implying.
DAN ALEXANDER:
My thought to that is that there's no point in having a threshold. We may as well just start asking the questions right now and just make it a procedural step of every application.
DAVID CONRAD:
The reason I put the threshold was primarily to give people, to give me time to come up with the necessary questions and also the idea I have was actually to have this as a globally coordinated policy, so running through the other RIRs as well which will take a bit of time.
DAVID MILES:
David Miles from Alcatel Lucent. I think it is a great idea, but I think it is too late. One of my concerns is that now with Geoff's help, is a very good estimate of when the service providers are going to feel the crunch. If we implement a policy like Softer Landing, all of a sudden it is all out of kilter. I think many providers were struggling to justify the objects to make changes to their core networks to implement non-RFC 1918 space.
DAVID CONRAD:
To be clear, I'm not suggesting that the ISPs would actually have to change anything. I'm suggesting that they merely document it so that that could be used within the RIRs to understand what the sort of environment is in which they're trying to actually change policies to deal with the run out. This may provide information that could then result in changes in policies.
DAVID MILES:
Doesn't that suggest that it will change the status quo. All you have to say is that you will deploy IPv6.
DAVID CONRAD:
You need more elaborate plans to explain to the RIRs.
DAVID MILES:
Provided it is focussed on IPv6 deployment, it doesn't seem to support your original goal of efficiency of IPv4. It seems to really be more than a proposal to encourage IPv6.
DAVID CONRAD:
Actually, the original proposal, the goal was to encourage IPv6 deployment and getting additional v4 space more and more painful over time. However, this proposal is primarily targeted at information gathering, and as a side effect of that information gathering, hoping to encourage people to say, oh, you know maybe we should think about migrating to v6. For those who have not already.
GEOFF HUSTON:
I'm just reacting to your suggestion that you said 35 /8s.
DAVID CONRAD:
I'd rather listen to her!
GEOFF HUSTON:
You said the threshold of 35 /8s to give time for a coordinated global policy. The six /8s between here and there is way too short for a global policy, that's just over six months. That won't work. Why does it need to be a global coordinated policy, this can be done per RIR and it might end up the same, but it doesn't necessarily have to be the same from the start. I would certainly gently suggest that you consider simply doing This on an RIR by RIR basis.
Secondly, I'm not sure that this policy actually needs all of these questions documented in the policy proposal, even as it stands now, I've probably giving enough guidance to anybody to implement. I'm not sure that you need to be overly specific in order to get this going. In other words, even as it stands, you're close to cooked if that's where you want to be, if that's where you want to be.
DAVID CONRAD:
With respect to the first point, the reason I want it to be globally coordinated is that I want the questions, particularly on the survey to measure apples to apples. If you had each RIR coming up with different questions in a survey, then it would be difficult to try to determine cross-regional...
GEOFF HUSTON:
Are you assuming that this documentation is public?
DAVID CONRAD:
Not so much. I was anticipating...!
GEOFF HUSTON:
In the current policy framework and in the implementation, the information provided to the RIRs for applicants to resources is confidential; therefore, this documentation is confidential unless the policy starts to say that it should be treated in a different way.
DAVID CONRAD:
The indent of the survey which is different than the deployment plans, so I didn't list the survey on the slides. But the survey would be intended for public dissemination.
GEOFF HUSTON:
Why would you need to tie it to the policy.
DAVID CONRAD:
Good point.
GEOFF HUSTON:
I'm saying with a little bit of careful thought, you're close to done if that's what you want. The precise questions can be done as implementation rather than as policy.
DAVID CONRAD:
I understand your point.
IZUMI OKUTANI:
We like this proposal much better in the revised matter and you might not be too surprised, but we like the spirit of trying to promote IPv6. But the concern is, do we necessarily have to enforce it in terms of policy? In terms of JPNIC, we think it is probably not appropriate to provide information or training or do outreach in other areas to raise awareness among members and say to do this.
DAVID CONRAD:
Right, the intent of putting it into a policy framework is to tie it into allocation requests, therefore ensuring that it actually gets done. There are existing efforts in all of the RIRs I believe to promote v6 deployment and this is simply another tool in that toolbox.
IZUMI OKUTANI:
We understand the intention, but we feel that it should be left up to the choice of LIRs rather than as part of the criteria. But I understand your point.
DAVID CONRAD:
Thank you.
TOSHIYUKI HOSAKA:
Any more questions? So, this is not a policy proposal at this time, so what would you like to do?
DAVID CONRAD:
Actually...
TOSHIYUKI HOSAKA:
Would you like to see some show of hands on this approach.
DAVID CONRAD:
Whether I should continue chasing after this one or go back to doing real work!
TOSHIYUKI HOSAKA:
OK then, I will ask you for a show of hands whether you can support David to continue to work this proposal. Supporting?
How many of you support? To continue to refine this proposal? Please raise your hands.
Thank you.
How many of you think this is a bad idea and request David to stop it!
DAVID CONRAD:
And go back to work!
I live for this kind of thing.
TOSHIYUKI HOSAKA:
Right, it is up to you whether you are going to come back! Or whether you want to go back to work! Anyway, thank you very much David.
APPLAUSE
TOSHIYUKI HOSAKA:
OK, so I have one more informational presentation. For the IPv6 deployment, this is the information of presentation.
Large IPv4 address space Usage trial for Future IPv6 Deployment
KOSUKE ITO:
This is a quick update. Many of you already know the reporting stream. We are approaching towards the closing portion of the program, which is the promise to end the trial at the end of this year. So I will inform you how we are preparing for the closing of this trial.
At this moment, we, as we promised to you, we conducting the regular hearing session about once a half year. Currently, a couple of the participants have been dropped from the trial, some of them have taken on problems or some of them are business issues. Actually, one public wireless NAN service provider needs to be dropped from the trial because of the business issue. We have done an interview this month, the beginning of this month
Then most of them, still remaining in this trial, are going to make basic service soon. And they are really positive about deploying a commercial service. One of them is starting a native service and also conducting a dual connectivity service and also one is IPv6 L3 service which is with two partners. One is IPv6 CDN platform service, which is starting a v6 6 connectivity service, anticipating maybe Windows Vista users.
And currently, allocation list is like this. And the red line is returning from the wireless service provider.
And toward their goal of providing an IPv6 service, it has provided an IP-phone service and also the VoIP serve provider continues a trial, which we would like to convert it to a commercial one. CDNASP released a commercial service for IPv6.
And also, nationwide fibre service providers started planning of their commercial IPv6 connectivity service. That is pretty much it for it. And, however, they still make consumer's environment, which is not IPv6 favourable yet. Most of the applications still rely on IPv4, so it is a struggle with this situation. Also, most of the users still demand IPv4. Very, very small amount of people doesn't say anything about the v4 or v6 but some are aware and the people still requesting the v4 connectivity. Also many of the planning department like to start v6 service in their carrier or company. And trying to plan the v6, but the decision level doesn't understand yet, because of no clear demand from the market. So that is another struggle point.
And that is all about what we have observed from the participants. And procedure of the closing of this trial, we have started discussing with JPNIC and during the couple meetings in APNIC meetings and also online conferences we have conducted with APNIC and also JPNIC people joining this meeting, regarding this closing process, then we agreed to transfer the registration of the IANA zone files from ARIN to APNIC. The management of the 43 /8. We also reporting to APNIC theoretically towards a closing end, more frequently.
So, summary. Most of the participants go for IPv6. So that is the way, many people are starting to be aware of it.
V6PC keeps promoting participants to start the real commercial IPv6 services and also continuously check their status. If it meets their schedule or not. We are preparing to close the trial with APNIC by the end of this year, as committed and we already done a meeting this lunch time also. And we have cleared most of the issues then and just going to be more traditional level. So I guess, no issues to be left for the closing. And any questions? If you have any feedback, I appreciate it.
TOSHIYUKI HOSAKA:
Any questions or comments? If not. Thank you very much. Thank you.
KOSUKE ITO:
Thank you.
APPLAUSE
TOSHIYUKI HOSAKA:
So we have gone through the agenda today but before we conclusion the session we have a lucky draw result. Not yet! Not yet. So when can we expect to do that? Five minutes? Oh! Then just relax for five minutes.
Taking this time, I will repeat the house keeping notes, we have APRICOT closing event, sponsored by Cisco, featured today from 7pm to 9pm, transportation will be provided. The first bus leaves at 5.45 from the car park. So we have the result? No.
Miwa-san from APNIC just reported the other session is still going so we can't announce the result. So we will announce the result tomorrow morning. So this concludes the policy SIG session today. Thank you very much if your participation.
RANDY BUSH:
No, no.
TOSHIYUKI HOSAKA:
No? The departing time has been changed. Shuttle buses depart from the hotel car park from 5.30pm to 6.15pm for APRICOT closing dinner today.
OK. Is there anything else? No? OK.
Thank you, so, this concludes the policy SIG session today. Thank you for your participation and see you next time. Thank you.
APPLAUSE
[END OF SESSION]
