Transcript: IPv4 Plenary
Disclaimer
Due to the difficulties capturing a live speaker's words, it is possible this transcript may contain errors and mistranslations. APNIC accepts no liability for any event or action resulting from the transcripts.
Thursday, 26 August 2010, 09:00-10:30 (UTC +10)
SUNNY: I think we will wait for another five minutes or six minutes and we will start.
OK? Thank you.
SUNNY: Thank you for your patience. Once again, good morning and welcome to day 3 of APNIC 30. I hope you had a wonderful time last night.
How many enjoyed the dolphin show?
Wonderful! Good to see that.
I'm sure the dolphins enjoyed it as well, and they felt happy that you didn't eat them!
This morning, we start with a plenary session, IPv4 Tomorrow. I would like to thank Gaurab for accepting the chair this session in the last minute. We have three presenters, all APNIC staff.
I would like to encourage you to approach the microphones and make your comments, clearly state your name and your affiliation if you prefer.
And also, I would like to request the speakers to speak slowly, so that the stenos can capture your words.
And whoever is participating remotely express their views and comments on the jabber chat.
We have a web cast, we have an audio cast, and one of the staff members here is watching the jabber, and if there is any comments, they will relate to the floor.
I would like to invite Gaurab, the chair of this session, to brief what is IPv4 Tomorrow? is all about.
Gaurab Raj Upadhaya.
GAURAB RAJ UPADHAYA: Glad to help out, because everything about IPv4 seems to be last minute.
It as Sunny said, one of the purposes of this plenary is to see and look at different policies that have been in place at APNIC for the last year and a half.
And then look at some of the impacts that Hostmaster operations as well as some of the other related aspects of what do we do at APNIC in terms of policy or operators when we hit the last /8 of policy, or when we get to a point where there are no more IPv4 addresses to give out under the standard policy.
The plenary is titled IPv4 Tomorrow?.
There is a working document on this topic on the website.
If you don't know where the website is, go to the URL there that I put on the screen. There is a discussion document that should help you guide through the discussion that we are going through on what are the topics that we will discuss and what are the things that we will try to see in this plenary session.
So grab the document. It will help you immensely when we start discussing the topic.
As Sunny said, I have three presenters here.
And first will be policy manager Samantha Dickinson from APNIC, and Guangliang Pan who is the Resource Services Manager and Elly - I don't know what her title is! Sorry!
They will give three different aspects of the last /8 policy and so on.
If you grab this document from the website, we will follow some ground rules. We will let the three presenters speak and then we will go into discussion. It is better that we discuss this thoroughly, and not restrict ourselves. It looks like we will have more time at the end of the day today. So if we run out of time for discussion on this session, we can probably resume this after the Policy SIG. There has been a withdrawal in the policy SIG proposal. We will have time. Chairs of the Policy SIG have agreed to let this discussion continue at the end of the day. First up, Sam.
SAM DICKINSON: It's been a whole two years since the final /8 policy was passed. I'm here to remind you what it actually is about.
The policy was passed in the Christchurch meeting and is now documented in the general IPv4 allocation and assignment policy document in section 9.2.
The first bit is the actual wording from the policy, "when the total remaining space in the unallocated APNIC address pool reaches a threshold of 1 /8, the following policies come into force." Notice there it says "a total of one /8" not the 1 /8 that we got from IANA.
The first version of the proposal that went to Christchurch said that it was going to be about reserving the final /8 received from IANA, but discussion at the meeting decided that it was better to leave the decision to the Secretariat as an operational decision.
From this final /8 worth of address space, every organization is only eligible for one allocation. That means any existing organization that is a Member of APNIC or any future APNIC Member.
And it doesn't state the size of the allocation. But it uses the minimum size of allocation that exists in APNIC policy at the time that the final /8 policy takes effect.
In reality if the policy took effect now it means that every organization would be eligible for 1 /22 if they also met the criteria for an allocation from APNIC.
The policy reserves a /16 in case there is any future use that needs IPv6 but if we have used up the rest of the /8 and still haven't touched that /16, it gets returned to the general /8 free pool and can be allocated according to the rest of the final /8 policy.
Transfers.
At the moment, if you want to transfer space between APNIC Members, the recipient has to justify technical need for those resources. But once we hit the final /8 technical need, justification goes out the window.
A point that policy is dynamic - this is the policy in place at the moment. But can it change at any time. Just like APNIC policies have changed in the past. So the final /8 policy can change today, next meeting or it could even change once the final /8 policy takes effect.
What is not covered by policy and Guangliang will go into more detail about this is the more operational matters. So there is no description in the policy as written about what happens if we get more reclaimed addresses and it gets larger than a /8 that APNIC has in its pool. Does that mean that we roll back the final /8 policy or do we just keep going?
With those returned addresses, what do we do with them? Is the final /8 policy confined to those or is it considered a different type of address and a different policy applies to those?
That is it from me.
GAURAB RAJ UPADHAYA: Thank you, Sam. The next to present is Guangliang Pan.
GUANGLIANG PAN: Good morning, everyone. My name is Guangliang Pan. I am the Resource Service Manager at APNIC.
Today, I would like to explain to you the final stages of IPv4 distribution.
As you may know, IPv4 addresses will run out in the next few years. The manner of distribution will have to change as the resource runs out. APNIC wants to know how the Members want these stages to be managed. Therefore, in this presentation, I will give you some basic knowledge of how APNIC manages the IPv4 address at present, and an overview the possible models for the transition period.
This information is very important. Firstly, it affects you directly as Members. Secondly, it is related to the policy proposals which will be discussed later today. During this session, I would like to hear your opinions about how APNIC should manage this process.
You will have noted that English is not my first language. I know that many of you also come from non-English speaking backgrounds. Therefore, I will try to speak slowly in the hope that you might understand better.
Let's look at the status of the IPv4 address space. I believe you all know that there are 256 /8 blocks in total. This pie chart shows the resource, and the status of all the IPv4 /8s.
35 blocks reserved by IETF and IANA, not for allocation. 92 blocks have been allocated before the RIRs were set up.
This range is addressed by a policy proposal, prop-086 global policy for IPv4 allocations by the IANA post-exhaustion.
It sets out the criteria for allocating address space, returned to IANA. This will be discussed later today. After the RIRs has to be set up, IANA allocates /8 blocks to RIRs directly. These are the numbers of /8s each RIR has.
You can see RIPE NCC has 32. LACNIC has 8 and ARIN has 33 and APNIC has 40 and AfriNIC has 2.
So how many unallocated IPv4 address blocks does IANA have? Of the 256, as of now, only 14 remain unallocated in the IANA pool. The important question is when will they run out? So far this year, IANA has allocated 12 /8s. I expect APNIC, ARIN, and RIPE NCC will require two blocks each later this year or early next year. This means six more blocks will be gone. And only eight will remain. There are also some discussions at the IETF; they will reserve one /8 for IPv6 transition. If this happens, then one block will be gone, and the seven remain. And as you all know, IANA has reserved five blocks for the five RIRs. This means only two are left. And possibly any RIR will require more IPv4 earlier next year. This means the IPv4 pool in the IANA will be run out, possibly before the middle of 2011.
Let's look at Geoff Huston's projection. His model predicted that the IANA pool will run out about May 2011.
It is dropping in May 2011. This is a clear message to us that IPv4 distribution is coming to the end. In response to this, we come up with a document called Final Stages of IPv4 Distribution. This document has been published at the meeting website, as Gaurab just mentioned, at the beginning of this session.
Don't worry if you haven't got the time to read it. I will explain it to you now.
Just look at this graphic. In this graphic, we have defined three stages of this process. We are in stage 1 now. When IANA allocated the last /8, we will know we will have reached stage 2. When APNIC reaches its final /8, we will have reached stage 3. So there are two incidents to separate the three stages.
I used a different colour - see? The green, yellow and red is similar to a traffic light, separating these three stages.
I'm going to talk about each of these stages in detail. So you will be able to understand what will happen at every stage.
Stage 1 at the moment, IANA unallocated pool still available. This means we can still request more IP addresses from IANA.
This graphic shows the IPv4 address pool and distribution model at stage 1.
I would like to give you some explanations about this graphic. First, let's look at the IANA unallocated pool. It is on the left-hand side. This means unallocated /8s held in IANA. We just talked about that and we know that the number is down to 14 /8s now. At this stage, when APNIC needs more IPv4 addresses, we can request from IANA.
When we receive new allocations from IANA, we put them into the RQA pool. What's the RQA?
RQA stands for Resource Quality Assurance. This is a project we created to assess the quality of the resources before allocating them to our members. The objective is to reduce routability problems.
Once the RQA process is completed, we will move them to the APNIC free pool for distribution. The APNIC free pool means the available space which is ready for distribution.
You can also see there is some special range and temporary reservation in the APNIC free pool. What does that mean? For the temporary reservation, this means some reservation for certain Members, for the aggregation purpose. Sometimes we do reservation. For example, a Member request for a /16, due to some reasons we only agree to allocate a /17 to them. But we know that they will come back for another /17 soon. In such case, we will reserve that /17 for them so that they can aggregate to announce a whole /16. This is the temporary reservations means. Special ranges means ranges reserved for Internet exchange program, critical infrastructure assignment, and temporary allocations. All these ranges are part of the APNIC free pool.
All allocations and assignments are made from the APNIC free pool. The allocated pool means the allocated or assigned space held by members. When a Member closes their membership account, their resources will be reclaimed and put back to the RQA pool. If a Member wants to downgrade their membership, they will return part of the resource to APNIC. This returned space will also put back to the RQA pool. You can see in the RQA pool there is some reclaimed and returned space. There is also some historical and routed resource being reclaimed by APNIC. They are all put in an RQA pool at this stage.
After the RQA process, they will move to the free pool for allocation.
This is the current cycle and diagram showing how APNIC allocates resources.
Here is the key message about what the RQA project does. When we receive a new block from IANA, RQA will do an assessment which identifies some of the back ranges which are not suitable for allocation at this stage. There are other organizations who help the APNIC to do these assessments. I would like to use this opportunity to acknowledge them.
They include RIPE NCC, NTT Communications, Merit, YouTube, Google, AARNET.
I would like to give thanks for their great support to APNIC for this project.
So moving on.
What happens during stage 1? Actually, nothing special.
APNIC still can request more IP addresses from IANA and the business looks running normal. Maybe we will continue to follow current policy to distribute IPv4 addresses. All allocations will be based on a common capacity and customer numbers. And current escalation procedures will continue to apply.
I would like to give you some background information on how APNIC Hostmaster handles large IPv4 requests. We have an escalation procedure to ensure all the allocations follow APNIC policy. If the request size larger or equal to /19, they the request must be approved by two hostmasters. If the request size is larger or equal to /17, the request must be approved by the Resource Service Manager. And if the request size is larger or equal to /15, the request must be approved by Senior Management Review Team.
Let's move to stage 2.
At this stage, the IANA pool has finished.
This graphic shows the IPv4 address pool and distribution model at stage 2.
You can see the IANA pool is gone. We are not able to get any more IPv4 addresses from IANA. But we still keep making allocations and assignments from APNIC pool following the current policy and procedures. Same as stage 1. If the policy is no change, we still follow the same policy.
So you can see the RQA pool - when the last allocation comes to APNIC, we will have some new block from IANA. And after the RQA, we will move them to the free pool. And at this stage, the free pool has reservations and special range, and we try to release them.
There is a policy discussion about the critical infrastructure. One of the critical infrastructures assignment range is also listed in that special range. So it is on the discussion - APNIC released them for normal allocation or assignment, or we keep that continuing as critical infrastructure assignment.
So at stage 2, we will try to release all the available space. And also from the RQA pool, we will try to get as possible as we can - get all the resource, past RQA to the free pool to make the allocation.
And you can see from this graph there is a final /8 size there, in the yellow colour. Because the policy requires APNIC to reserve 1 /8 as a final /8.
How do we reserve the final /8?
We reserve the last /8 from IANA. So far, there are some discussions on the mailing list.
And I can see there are many advantages to reserve the last IANA block as the final /8.
Firstly, the last IANA block is a clean block. You probably know IANA reserved five clean blocks for the five RIRs. The reason for that is coming to the final stage, and the 14 /8 in IANA pool, some of them have more problems. For example, like the one before allocated to APNIC, that that 1 /8, and we call them a problem block or dirty block. For some of the blocks, they have less problems, and we call them a clean block. To be fair to each RIR, IANA has reserved the five clean blocks. These make sure that the last one you get from IANA will be a clean block.
Same here at APNIC.
If we reserve the last IANA block as the clean block to be the final /8, and in RIR we only get 1 /22 as the minimum size then everyone will get a clean piece of cake at the end. Otherwise if we don't reserve the last /8, it will be a mess of ranges.
OK, so we continue. So for the first reason, is the last IANA block will be a clean block. So everyone, if you received the last piece from the final /8, it will be a clean range. Otherwise, you may get a dirty range. So, is this a bit unfair to some of you in case you get the dirty range. So that's the first reason I would suggest to reserve the last IANA block as the final /8. And secondly, it is easy for APNIC to manage the final /8 and separate with other recycle and transfer ranges. For the operation point of view, I'd strongly recommend we use the last IANA block as the final /8.
However, there's one disadvantage of reserving the last IANA /8 block. It will create some fragmentations when there is a large request and we only have small prefixes to pick up the allocation size without using the reserved final /8 block. But from my point of view, for the last few allocations, even you received multiple prefixes to make up your allocation. You should feel lucky instead of complain. Why? Because the next one behind you will get nothing.
So, we will continue allocating all available space. All reserved range except the final /8 will be released in this stage. One allocation may combine multiple prefixes to make up the required size. There's the question here - should we move all address space in the RQA pool to the APNIC free pool for allocation? Even those that range which are not able to pass the RQA?
Members may start using the IPv4 transfer policy to transfer IPv4 addresses between Members. According to the policy, all such transfers will be subject to APNIC Hostmasters' evaluation at this stage. Stage three, the APNIC reaches the final /8. This graphic shows the IPv4 address pool and the distribution model at stage 3. You can see the APNIC free pool has gone. We only have the final /8 for allocations.
So, how do you use the final /8? We have a final /8 policy. One /8 block will be reserved for future use. Each LIR can only receive one allocation of the minimum allocation size.
IPv4 transfers. There's no need for Hostmaster evaluation at this stage. Members can use MyAPNIC to transfer their IPv4 address easily.
So, we have some questions here. After APNIC reaches the final /8, it is possible that some of the Members will close their membership account and return IPv4 addresses to APNIC and we put that to the RQA pool. After the RQA process, there will be some available space in the APNIC free pool. What we should do with the free pool? So, we will put them to the final /8, or should we have a policy to allocate them?
So, what should we do next? Propose a new policy to manage recycling IPv4 address space? Move to IPv6 as early as possible? Or any more?
So, let me do a quick summary. We have defined the three final stages of the IPv4 distribution.
Stage 1 - IANA allocated pool is still available.
Stage 2 - post IANA pool.
Stage 3 - APNIC reaches the final /8.
And the future - actually, I don't know what will happen after that. I think that's why we need your input. We need your opinions. I would like to clarify the role as APNIC Secretariat. We don't make policies. The policy is made by the community, and made by you. So, your voice and your opinion is very important. So, please bring your opinions forward after this presentation.
Let's quickly review those. These are the three final stages of the IPv4 distribution. And this graph shows stage 1 - how the IPv4 address has been allocated and how APNIC manage the resource.
And this is stage 2, and the IANA pool has gone.
And at stage 3, we only have the final /8 left.
And the future, some questions. So, how should APNIC deal with those new free pools, like the new available space?
Thank you very much.
APPLAUSE
GAURAB RAJ UPADHAYA: Thank you. Next, I would like to ask Elly to present.
ELLY TAWHAI: Good morning, everyone. My name is Elly Tawhai. For those of you I haven't had a chance to meet yet, I'm an Internet resource analyst and Pacific liaison officer within APNIC. I do requests and I also do Pacific outreach within the Pacific.
So, what I'm going to talk about with you today is how we're going to and have plans to lower the minimum prefix size for APNIC blocks. Now, it is important to note - this is not a policy change. This is an informational presentation only. So I'll go into more details of what this actually means.
So, on the screen, you can see the blocks that APNIC is responsible for management of. So we delegate address space to Members from these blocks. So you can see the prefix sizes that are currently set. So what this means is, we take /22, the minimum allocation size, which is a /22 portable allocations from the following blocks listed in the first point.
In the second point, you can see the minimum size made for portable allocations is a /24, so from the blocks listed, you can see in the second point where the /24 portable assignment has come from. So, because we take allocations and assignments from set blocks, it's causing some issues. So, the problems that are actually arising from setting the prefix size from set APNIC blocks is, when it comes to transferring address space between different organizations, because the minimum transfer size is a /24. Also, we sometimes get membership downgrade requests, so what this means is, when a Member may have applied for the minimum allocation of a /22, because they justify that they may have had the equipment capacity to justify a /22, and so, for example, the business may not have done so well and they may decide to downgrade their membership.
So, therefore, they may wish to only keep a /24 out of the /22 and return the rest of the previous allocated IPv4 address space to APNIC.
The other issue is, with the blocks that we manage, we actually have them on our APNIC website along with the prefix sizes set for each of the blocks. Now, we find sometimes that Members actually, or the community actually sets their filter sizes based on the prefix size listed on the website. So if you want to have a look, we have the URL mentioned on screen.
So, what we've discussed and the solution we've come up with to rectify this issue is to change the prefix size to /24 on all APNIC IPv4 address blocks. And then along with that, update the APNIC website and also advise the community. So we plan to sent an announcement to the community after APNIC 30 so people are aware.
Thank you.
APPLAUSE
GAURAB RAJ UPADHAYA: Thank you, Elly. I think what basically summarizes the questions being put to the audience here. Primarily, we are looking at the three stages, stage one which is now, where the IANA still has the address space to give out. Stage 2, when IANA has given the address space and it is in the address pool.
And stage three when we go into the last and final stage. Give me a second to put the questions up to the audience and then we can go and...
(Pause)
So, I think we'll welcome questions now or feed back or comments. We also have participants on the jabber room and also a lot of people watching the stream, so make sure that you state your name, and if you want, your affiliation. It's not required. But please keep the discussion to the point, and as I said, if there are things that we need to discuss, we can extend this in the afternoon in the last session of the day.
DAVID WOODGATE: Hello, David Woodgate, Telstra. I just wanted to ask one question about Guangliang Pan's presentation. You were talking about how the final IANA /8 would be clean in comparison with some of the previous allocations. I suppose there's a strong probability that this final IANA /8 may end up being the final APNIC /8. I just wanted to make the comment that it seems a little strange that given that APNIC's last /8 is unlikely to be fully utilized because of the final /8 policy, whereas any /8s before hand are, of course, expected to be fully utilized. It seems a little strange that we're handing out, shall we say, dirty /8s to be fully utilized. We could be - depending on how the dice falls. It seems a little strange that we might end up handing out a dirty /8 that will be fully utilized and the final /8 which may be clean and untouched may not actually be used much?
GUANGLIANG PAN: Yes. Actually, the first reason why I suggested that we would better reserve the last IANA block as the final /8. For example, if we don't do that, and we probably use a different range, as combined with the whole of the /8. And some of them may be not a good range, it's possible. And if someone, like, we only give one LIR the minimum allocation size, this is the last bit for each Members. If unfortunately, they get a dirty one, it is probably a problem for them. So to be fair for everyone, I just think that it would be better if we used the last /8 as the final /8. That's the reason. Yeah. Does that answer your question?
DAVID WOODGATE: It's possible that I was more commenting than asking a question. But thank you,
GAURAB RAJ UPADHAYA: Thank you, I see Philip there on my left.
PHILIP SMITH: Philip Smith Cisco. I just want to comment as one of the authors of the final /8 policy. We deliberately left it as... well, to the Secretariat to decide how and what the final /8 should be. In other words, should it be the final /8 of APNIC's entire holding or should it be a specific address block? So I think in what you've presented here, you've actually, you're actually saying to us or sharing with us what you want to do. And as one of the authors, I think that you should do what you've shared. Because we never wanted to tell you how to distribute address space and what address space you should be distributing. So I think you've answered the question that we left you with about two years ago. So if you feel that having one specific clean - for whatever description of clean is - as your final /8, then do it.
GUANGLIANG PAN: OK thank you.
SANJAYA: I think one of the reasons why we want to keep the final /8 the clean one is because we don't have time left to do RQA. With RQA, the longer that we hold in the RQA space, we actually can clean up more, you know. But with the last /8, we just don't have the time to do RQA, so basically, that's one of the reasons why we choose the clean block. Thank you.
CHAMPIKA: There is a coming from Jabber. It is Louie Lee. Will IANA ask the IETF to formally seek feedback from the APNIC community from the ASO or NRO if they receive a request from the IETF to set aside space as discussed?
GAURAB RAJ UPADHAYA: Thank you. I think that that question is more for someone from IANA to answer rather than for someone from APNIC.
GUANGLIANG PAN: You mean the question is about the IETF request for the reserve one /8? Is that it?
GAURAB RAJ UPADHAYA: I think the question is - will IANA ask the IETF to formally seek feedback from the APNIC community via the ASO or NRO with a request. If they receive a request to set aside space as discussed. Anyone from IANA want to take that up.
ELISE GEIRICH: I'm from the IANA and I can. And there is, as you mentioned, activity at the IETF to look at allocations of the /8. And as this proceeds, I guess I would also request that the RIRs participate in that discussion so that their voices are heard at the IETF because it is an organization that has "no membership". And therefore, your voices can weigh in if and when this proposal should move forward, we would clearly ask for feed back from the RIRs.
GAURAB RAJ UPADHAYA: Thank you, Elise. I think that we will keep that voice in there because that is more of a global policy than an APNIC policy. Actually, I would like more feedback from the audience on whether the last final /8 that APNIC designates should be a collection of addresses with the two /8s, or as Guangliang Pan said, and preferred by the Hostmasters, it should be the last /8 as assigned by IANA? With more feedback, I think it will make it more difficult for them to decide on this. And as Philip pointed out, two years ago when we were discussing the last /8 policy, we left it up to the Secretariat on that. And now they've come back with that and we're looking for feed back from the community on whether that is the right approach to do.
That's nice. No comments. OK, now I see activity on the right side of the room.
OWEN DELONG: I don't know that we've had a chance to really think this through in the ARIN region, so I won't comment as a representative of the region. David Farmer can do that if he sees fit. But I will say that what I saw when I looked at that IETF proposal was - wow, this is a really bad idea.
IZUMI OKUTANI: Izumi from JPNIC. It is not a new comment, actually. I don't have a very strong opinion about it and I think that it is better to manage it in the way that the Secretariat feels it is better to manage the final /8. So I'm pretty much echoing what Philip is saying.
GAURAB RAJ UPADHAYA: Thank you, Izumi. I think that the silent consensus here is to give the Secretariat a chance to do what we told them to do two years ago and let them see this. I think that that is what is the silent consensus.
FELIZ YILMAZ: From RIPE NCC, policy manager. We had the same proposal, basically. Philip is one of the authors in our region and now the third version of that proposal is being worked on, and in the second version, yes, the idea from the proposals was to leave it to the Secretariat and work with an equivalent of the /8 that the Secretariat would see fit towards the end. But then on the third version now, it will be specifically the one that RIPE NCC will receive from IANA. So it is being changed.
GAURAB RAJ UPADHAYA: Thank you, Feliz. So I think that we can probably go to the next question and what David Woodgate raised earlier is if we go and see the final /8 assigned from IANA. The current policy says that APNIC needs to exhaust all other IPv4 addresses in the unallocated pool. How do we handle stuff like 1.1.1.0/24 that was presented yesterday. I don't think that I want that address space on my network. And other things like, you know, the special addresses that we already had with APNIC and the critical infrastructure /16. The multihoming assignments, /24 s, so what would the community think? Should the addresses be excluded when we count the final /8? And left there as unallocated? Or whether they should be considered part of the last /16 that is there for as yet unforeseen cases?
What is the feed back from the community on that? I would probably like to hear more from Ops people because that is probably of more impact to Ops rather than to policy.
DAVID WOODGATE: Given what we did see yesterday and that there are these clear vectors with some of the use of the /8s, I think that it is actually worth isolating some of the obvious targets like the 1.1.1.1 space going forward and any other similar ones that may come up in the final spaces.
PHILIP SMITH: Philip Smith from Cisco. I'm not really a policy person and not really very much of an Ops person either, so sorry about that. But, George Michaelson showed yesterday that some of those addresses are pretty much unusable, well, unless you've got maybe a spare bit of fiber to sink gigabits per second of traffic. So I would definitely be trying to exclude unusable address space as any of the criteria before getting the final /8. But these special ranges, there's actually no policy that APNIC has defining these special ranges. So the special ranges, as far as APNIC are concerned operationally, but they're not special as far as policy goes. So as I said on the mailing list, if APNIC is handing out whatever from whichever address block, that whole block should be exhausted for regular allocations and assignments before we move to the final /8 - in my opinion - unless somebody gets on really, really quickly before we reach the final /8 and has a policy proposal saying right, this /16 will be used for X and that /16 will be used for Y.
Because there's nothing in the policy system at the moment that says they're special.
GAURAB RAJ UPADHAYA: Any more comments there?
WENDY ZHAO: From CNNIC. Actually, it's not a question, but probably some comments, I would say. First of all, I think I can speak for my members saying that they definitely don't want the dirty addresses, which are not going to be useful. But for some particular person, they might get money from the bad addresses and they are exclusive.
Also, there is a question for the including the existing special range. I'm the co-author of the prop-085, and I do really want those special arrangements to be included in the final /8, as it is for the current assignment, even though there is no special policy talking about that, about going to get one. Thank you.
GAURAB RAJ UPADHAYA: Any more questions there?
JONNY MARTIN: Oh, that was fast. Yeah, I think when we get to the last /8, as I think it is Randy who keeps pointing it out. It is the last /8, there's no more. There's no need for special arrangements at that point. So yeah, just throw everything, all the special ranges into the pool and let's get on with it.
SANJAYA: From APNIC. I guess the question that we would really like to hear from the operator community is - does it help you if the infrastructure assignment coming from a specific /16 block? Or operationally? Or are you OK if we give the critical infrastructure coming from different blocks? Does it help your filtering? Does it help... I don't know. That's the question that's pertinent here. So do let us know whether you want to have the future critical infrastructure still coming from an identifiable blocks, or if it is OK for you to give the infrastructure and IXs coming from the blocks?
MIKE JAGER: It seems to me that one of the main reasons that you would assign critical infrastructure out of pre-defined /16 s, for example, would be to help the operational community in filtering on an RIR boundaries. As v4 run-out happens, it would seem that there's going to be more and more deaggregation, and the number of networks around the world that are going to be able to keep up with carrying the full global IPv4 routing table will increase. Unless they give them away for free, they're just not going to be able to afford the boxes. So I think you'll find that you'll end up with networks running default-free. Sorry, not default-free. They will have a default, so being able to filter on things like that may become less important.
They'll just throw packets up to their transit providers and let them deal with it. Thanks.
WENDY ZHAO: To answer Sanjaya's question. I, as the .CN, I don't mind the critical infrastructure from any blocks. We don't need to be in any specific blocks, but we would like to see in the final blocks. Thank you.
GAURAB RAJ UPADHAYA: I think that personally, that is my personal opinion, not as a chair. That it is useful to have an unknown set of addresses with critical infrastructure coming out. But as Jonny pointed out and Randy pointed out and various people have pointed out on the SIG policy mailing list, when you get to the last /8, it is the last /8. So everything else is irrelevant at that point.
I think that we're in the interest of time. May I suggest that the APNIC Hostmasters, just like we've proposed that you would like to assign the last /8 assigned by IANA as the last /8. You come up with a policy or a working document that would recommend to the membership saying that these are the address spaces that we think would not pass through the RQA process and should be excluded until a time that it becomes more acceptable? Because as the common feedback is, I don't think that people want to get unusable address space or address space which is not "productive enough" to be used. And if that can be presented to the membership over the next meeting and discussed like it has been done here, that would probably be acceptable to the members. Am I summarizing that correctly? Unless if somebody has anything against that? Please speak up. ?
MA YAN: It's a very unique moment so I'm quite sure that APNIC will have a lot of interaction with the other RIRs and with the NRO or from IANA to make an announcement that more people are aware of the depletion and to be ready to migrate to the v6. So any announcement or any specific news, to be released, to be prepared for that period of time that's my personal comment.
GAURAB RAJ UPADHAYA: John, you were standing up there.
JOHN CURRAN: Axel is here actually. But I will save him the effort. The five CEOs of the executive directors of the RIRs are working together along as part of the NRO to prepare a press release to be ready and standing by at the time we get the 5% that is prepped and on a hair trigger! And the folks who are working on it are actually in the room and should go off the moment that that event has occurred.
GAURAB RAJ UPADHAYA: Thank you for bringing that up. Because I will put the next slide on the screen now and that sort of relates to that. If we go by the rules or go by the words in the final /8 policy, APNIC should not have any other problem. If we go through the last policy, it restricts APNIC in the sense that it doesn't come into action until they've run out of all other address space, including anything that's in the RQA, things like dirty addresses that we've been talking about and so on. So would it make sense for the APNIC to return those to IANA so that its own coffers are free of...
I can understand that the Hostmasters and the Secretariat are bound by the policy of the membership. And if it says, "thou shall not assign from the /8 until you have nothing left, then give it back to IANA. It's their problem, right!" So that's the thing. Either we create a policy as we discussed and as Ma Yan pointed out, there could be something done there with the RIRs. Or somebody has to take the risk. Go ahead.
DAVID FARMER: ARIN and University of Minnesota. Small problem with that. All we end up doing there is passing the hot potato around, because nobody is going to want the unusable address space. We should just find a way to lock it up and throw away the key.
GAURAB RAJ UPADHAYA: Yes.
JONNY MARTIN: Yeah, let's not give back any of that dirty space. 1.1.1.1 is the ultimate vanity address. Auction it off or make it available for security researchers or something like that.
LAUGHTER
All right a big honey pot!
PHILIP SMITH: I don't think that I've got anything to add, really.
LAUGHTER
I won't!
GAURAB RAJ UPADHAYA: Any more. Because it is one of those topics where like Philip, I have nothing to add. And I probably don't want the 1.1.1.1 address space. If Jonny is keen, he can auction it off.
GREG SOFFE: Greg Soffe, Telecom NZ. We just started up an Asia-Pacific security organization based in the Philippines. I'm sure that they would love to get their hands on one. Just an opportunity there!
GAURAB RAJ UPADHAYA: Any other things for the Secretariat? What do the Hostmasters think in terms of assigning the address space. Are you happy to give it to the folks who ask for it? I think going back to the Hostmaster practices, I don't think that you can ask for it from APNIC?
GUANGLIANG PAN: We don't allow to choose AS numbers or IP numbers. So it is randomly assigned, the next available space. And at this stage, the 1.1.1.1 and 1.0.0.0 - I think it is still under RQA. It is not released for assignment at this stage. But yeah, I think it is also open to the community. If anyone says that this would be available and someone wanted it, maybe we can release for assignment. This is also dependant on the community wants.
TERRY MANDERSON: I think one of the problems here is that you were having a discussion about what the definition of exhaustion is. If you take the view that exhaustion is all of those things that have been set aside for a particular use, including critical infrastructure IXs, you also consider exhaustion to be the address blocks in 1 /8 which are clearly unusable. That pretty much drives you to an answer.
GAURAB RAJ UPADHAYA: Actually, I have a question for Guangliang Pan. Forget the not so usable RQA address space, but APNIC has a /16 set aside for conferences. So have you considered that? Is that part of the allocated address space? Or part of the free pool?
GUANGLIANG PAN: That is in the temporary allocation pool. It is in a free pool. And at the end of stage 2, I believe that it will be released for allocation. Like for a conference, or a temporary allocation. Then we will all take back. There's no policy...
GAURAB RAJ UPADHAYA: Does that mean that at the end of stage 2, there is no longer the temporary allocation. Because even temporary allocations are not governed by policies, as far as I understand. So nothing is stopping Hostmasters from continuing to have a bunch of address space for allocations for research and as Terry said, I would consider that address space already allocated for some purpose. Which of course, might come back to be part of the last /8 or the unallocated pool. But when you go and activate the last /8 policy, you know, if, by definition, temporary allocations are also allocations, that would probably solve the problems. I don't know.
I think I'll give the audience a bit of a time to think about this policy discussion and going into very specifics of address allocation practices and policy at APNIC.
We've got five minutes. And as I said, I think I'll get Guangliang Pan and the Secretariat to come back at the next meeting with the idea or come back on the APNIC talk or one of the other mailing lists. Maybe the SIG policy. OK, I need to come back on the mailing list and summarize the discussion and come back with options and what the Hostmasters think would be the right thing to do and discuss the pros and cons.
GUANGLIANG PAN: Yes.
GAURAB RAJ UPADHAYA: That would be the best way because not everybody is well-versed on address policy assignment. So before we begin, I think we'll go to Elly's question, the changing of the stacks.
So, to repeat this question, APNIC and all the RIRs, they actually publish this which means the allocation for the particular /8. I can try to bring it up on my browser here, but what Elly is proposing is whether we should, APNIC should, as a blanket act, just remove all of barks it was explained all in the earlier slides. Feedback or comments on that. I think this has more of an operational impact than a policy impact, per se.
Does anyone want me to go through the previous slide which defines the problem? OK, Jonny.
JONNY MARTIN: I think this is a bad idea, obviously, from a routing table growth perspective. Perhaps a far better way of doing This is to leave the minimum allocation size when it is documented in each of the /8s the same as it is now. But when a transfer occurs or something like that, that gets recorded. So the information is there for those networks out there that want to filter based on both the original RIR boundaries, plus the new transfers and enables the people who don't have this to run with the original RIR boundaries and ignore the transfers, seems to be a far better way to leave all of the information out there in the public domain and let the individual networks make their choice.
DAVID FARMER: Just a thought - what about, rather than changing it, you know put in the asterix saying "Transfers down to /24 or allowed, or whatever." Because I agree that you want the original information and then note that the real conditions as well. Loss of information would be a bad thing.
GAURAB RAJ UPADHAYA: So this is the information that Elly was proposing that should be changed
DAVID FARMER: Loss of the original information would be a bad thing.
GAURAB RAJ UPADHAYA: Yeah. Comments on this? What is the thinking at the other RIRs? If I'm being very explicit? Has that not been discussed yet?
VALENTINUS UANUAR RIYADI: From Indonesia. I just want to ask how many IP addresses that we can reuse if we use the new policy that we are lowering The minimum allocation for all subnets? So how many addresses that we can reuse with this policy? Thank you.
ELLY TAWHAI: So, by changing the minimum prefix size on all of the blocks to /24, it's not stopping from the address space from being re-used. So re-delegated, say for example, if they're returned due to a membership downgrade or a member closes, it's not stopping that address space from being then further re-assigned to another organisation at a later date.
PHILIP SMITH: Philip Smith, Cisco. I've always understood that page to be the smallest pieces of addresses that APNIC has distributed to membership? I've been watching it over the last, I don't know how many years, 10, 11 years? Probably not quite as long as that, but I'm sure that those minimum sizes have changed over the years. So all you're saying to us is hey, you're going to change the minimum sizes, so just do it. If you've got a /24 coming out of - let's say 60 /8 that you've done as a result of a membership downgrading. Then the smallest thing you've handed out of 60 /8 is a /24, and you document it there. That's what I would doing. And I think that's what APNIC has been doing Over the years. I certainly know that the RIPE NCC has been doing That over the years.
Remember 193 /8 had a minimum allocation of a /19. But if you look at it now according to the RIPE NCC website, it's a lot smaller. So as I say, just do it.
SANJAYA: Just to correct Philip. No, we are quite strict with that, actually. So if there has been a transfer currently in the past that might break that, we would actually ask the Member to renumber to a different block. And so far, it has been successful. But lately, it is becoming harder and harder to do that.
PHILIP SMITH: Philip Smith here again. Just a quick comment because the routing table analysis that I do, I code in the information that APNIC has been making and every few months I have to check this file and I'm making changes. So it is changing, but you don't come and ask the community if you can make the change, like you are now, which is why I'm confused.
SANJAYA: That part is correct, yes.
PHILIP SMITH: That's what I was observing, yes.
GAURAB RAJ UPADHAYA: A question for Guangliang Pan actually. When the transfer policy comes into play, whenever it is. Do you plan to publish all the resources that have been transferred or not?
GUANGLIANG PAN: Yes. I think that if any resource transfer followed the prop-050 proposal, then we will publish on the APNIC website. But so far, we haven't received any. That's why there's nothing there at the moment.
And I also, just Sanjaya said it. 80% is not proposed to change to the minimum IPv4 allocation size T is not a policy change T is just operational issues like which block we can make what size of the allocation and assignment. It is just an operational issue, it is not a policy issue.
GAURAB RAJ UPADHAYA: Thank you, I think I'm a bit disappointed by the level of discussion here! But anyway, I think that I don't see anyone complaining about the proposal that you put forward. But I think what Philip said, the membership would probably appreciate a notification on the announcement list when you do things like that. You know, you take your time and decide when to do it and send a notification. I think that that would be the right thing to do
Thank you very much. We are almost on time given that we started ten minutes late. Sunny s there anything to be said? No, OK.
We have the Policy SIG starting at 11:00. We have tea and pink cookies or pink cakes outside! We had that yesterday. I don't know what's there today! We'll see you back here at 11:00.
Thank you very much for being here this morning.