7 May '09 ‑ Main Hall ‑ Address Policy 9am
CHAIR: Good morning everybody. I'm glad to see at least a few of you back. The room was definitely more crowded yesterday. There was an AMS‑IX party yesterday but I'm still happy that actually you made 9 o'clock on a morning after the AMS‑IX party.
The the Working Group chairs are still Sandra and myself. The session is still web cast so the usual caveats applys, state your name, speak in the microphone, et cetera.
We will have a short wrap up by Nigel Titley of what was discussed in the NCC Services Working Group yesterday, so the text on here is what I had on the agenda before but we're doing it a bit different. Since the discussion has been had we'll get the results, then we'll get presented these four protocols and discuss what we think about it and how to move forward. If there's time, which I can't promise at this point, there will be a couple of minutes in the end, definitely not a full hour, to mention things that you might want to see as a formal policy proposal eventually but just mention informally to get some feedback on your ideas and anything else that might come up.
First thing is Nigel Titley, Nigel, if I might ask you.
Nigel Titley: Okay, just a couple of minutes to wrap up on the discussion yesterday. You'll know about this, about this policy proposal, it's about the RIPE NCC setting out guidelines for how LIRs can receive certificates for their PA space. And basically this proposal sets out how this should be done. I'm not going to go through the proposal. The status is the RIPE NCC is ready it partially [] de/PHREU this, in other words, just a /PERTal implementation (/P‑RTal
The main concern is that certification plus /SKAUR /RUTing effectively can give a big red button for the internet, you can actually turn off a route /TPHUPBSment. You can only do this if they're cooperating. It could have implications for the internet as we know it. So there was quite a bit of discussion on this, which was rather nice. There was cautious approval that this gives more advantages than disadvantages but we really really need to get down and work out exactly what the ramifications are.
One of the arguments was this is only a tool, like filtering, you use it if you want. If everybody uses it, it becomes mandatory, if you don't use it, you won't get any customers.
The RIPE NCC must take the project further. This is only really a start, toddler's first steps and missing a lot of function alternate and it's missing the up down protocol, which is needed and we need to investigate all the ramifications. So that was an action on the RIPE NCC to get together a list of documents and policies that need looking at and changing.
Set of documents, policies and procedures to cover all the issues brought up. Action on the RIPE NCC and we do need to plan how to go forward on the certification project which is only in its first stages. Usable, but only just. And that's it. Nothing else.
Any questions? Anybody awake? Letter. Good.
(Applause.)
CHAIR: Okay. Thank you Nigel for wrapping up where we are with this today. For our policy process regarding 2008‑owe eight this means installed. We will wait for the certification process to proceed for the community to come up with where to take this and revisit the proposal, either rewrite it and abandon it or have a new one. 2008‑08 is not going further just now.
So now we now come to the first of the new proposals of this year, 2009‑01. Without further ado I give the microphone to Axel who's going to present who, why, what.
Axel: Good morning. Thank you. Okay. This, then is about the global policy proposal for the allocation of IPv4 blocks to the regional internet registries 2009‑01. This has been assembleed by a couple of concerned people who know a bit about the registrys and how to deal with the RIRs and what we are faced with and what we're missing and what we hear out in the world.
We currently do not have a global policy on IPv4 that would cover any reclaimed address space. Basically the RIRs might or might not reclaim the address space and sits there which in principle is not bad. However, then, if we are assemblers of here and nothing there, there's no mechanism currently to distribute not used space among the RIRs. So we cannot just decide that we have so much space left over we would like to go some to ARIN, for instance. We can't do that.
So the ‑‑ what we thought up is a mechanism to basically effectively be able to do this. The idea is to give space back to IANA and reallocate to aAnna to the RIRs and this is just about the mechanism and the numbers and how quickly and how fast that needs to be done by IANA that is procedure and will be defined later.
We have a couple of definitions here, recovered address space. It's reclaimed space, it's space returned voluntarily to the RIRs and does not include [] /PRERBly reclaimed space after termination of contracts with RIRs.
Then we speak about IPv4 address holding, the space unallocated at the RIRs and does not include reserved space that is reserved for later allocation.
On the two phases to this: Phase 1 is before the depletion of IPv4, the IANA, basically IANA [] /PRAEURZ for this, sets up recovered IPv4 pool and the RIRs start returning IPv4 address space as they have it available, return it in chunks every three months and only if they have aggregated blocks of /24 or larger. At some point in time we all run out of that space as we all expected, what happens is IANA obviously announces we don't have anything anymore. We recall the current global policy that governs current allocation space to the RIRs and this policy will come into effect.
What we do then, there's an allocation period defined that's basically six months and starts more or less arbitrary day in the year, 1st of March and goes until September and the second allocation period starts. Then we have an IPv4 allocation unit to define and that is a little bit geeky maybe. We thought this is something that needs to be flexible, depends a little bit on how much space overall is in this pool and we thought the allocation should be roughly about a tenth of the IPv4 address pool, then we have five RIRs then every RIR could get one of those and every half year half of the available addresses in that pool at IANA will be given out again.
Allocations to the RIRs that will be done one allocation per RIR per allocation period. So one allocation every half year. If an RIR needs it, if it is eligible, and it would be then in one allocation unit. That's why we call it allocation unit.
When is an RIR legible to receive this space from IANA? Basically this only happens once per allocation period. So we mustn't have received one yet in this period. And the RIR holdings are less than 50 percent of the current allocation unit.
Should we have new RIRs? You never know. They would get one allocation unit on recognition of this RIR or as soon as possible, as soon as there's space available to be given out to them. Of course IANA does all the reporting on this, they make public announcement. That's straight forward.
Time line, the implementation would be immediately after the ratification of the policy, that's a set up of the returned IPv4 pool.
Advantages of the policy, basically defines a mechanism for distribution of reclaimed address space.
Disadvantages we don't see any.
Where are we with this? This is a global policy, needs to be around the world, needs too be accepted by all the RIRs to come into effect. We have had a meeting in Manila where we discussed this and it was approved. Now it's subject to the last period over there. Last week we discussed this and there was a bit of complication as in the ARIN region the advisory counsel there took this text of the global policy and changed it a little and there was some backing and [] forthing about that and if [] /PHAL /A is in /SHAOEZ on the advisory council, maybe she would give some explanation there. As I understand it, we are currently looking at a rewrite of this policy text to make returns of none legacy reclaimed space optional. So basically what that would mean is that legacy space is part ‑‑ is subject of this policy and must be returned if ARIN gets back any legacy space it should go back to IANA and if ARIN gets back any space that was allocated to ARIN before, they might or they might not.
That's basically the policy. Questions or clarifications. If I did say something wrong, maybe you want to correct me.
CHAIR: Thanks for explaining what this is all the about. I have one thing that I would like some words of clarification, whether I understood it correctly. The way I understood phase one is that if today ‑‑ well, if this goes into effect and the day afterwards, and you new RIR that has been opened is closed again has received space from a nice and shiney /8, that space will then go back to IANA? Because it's reclaimed address space.
SPEAKER: Any space would be back to the RIRs, the RIPE NCC in this case and if we would not have reallocated it, we would give it back to IANA
CHAIR: Before the pool is depleted, space that comes from your working set of /8s will already go back?
SPEAKER: Yes.
CHAIR: I think that should be very clear because that has implications. Question: First of all, the ARIN region's modification doesn't really make quite a bit of sense. That's my first comment. And the second comment, Axel, could you please pull up this one supplied with the time lines and the 1/10th.
SPEAKER: Which one? Tell me when you see it.
QUESTIONER: I'll keep talking. This one here. Do I understand it correctly that this actually slows down the redistribution of reclaimed address space, even if ‑‑ even if there is quite a bit of resources being returned? My understanding is there is just two times a year where you can apply. And at a certain point in time there is almost nothing in the pool, like in the first period, and so you get 1/10ths minus something and then a big bunch of addresses comes back to IANA and there is need for those addresses but you sort of ‑‑ you had bad luck in being a little bit too early and you just got a penny but there is millions in the bank and you have to wait for another half a year.
SPEAKER: At the maximum.
QUESTIONER: At the maximum to reapply, is that right?
SPEAKER: Yes. You cannot only apply on the 1st of March and September, that is just the period, within that period you get one allocation.
SPEAKER: I got that one, but is it intentional that this slows down the redistribution of reclaimed addresses even if there is a documented need?
SPEAKER: Depends on what's in the pool and when. Yes.
QUESTIONER: I'm here as an Advisory Council ARIN rep. Axel pretty much cleared it up but I'm a fan of full disclosure so to cover it, we did optional because the main reason this policy came about was to address legacy space and if you're not aware ARIN holds the majority of space and a big chunk that people are hoping will come back from the DOD. That's really why this is here. We talked with the authors last week in ‑‑ where we were in San Antonio. And they agreed any other space should be taken. They were trying to get to the other RIRs to change the text from what we discussed to make it legacy only every where, but they ‑‑ there just wasn't enough time so it passed in APNIC as is. So that would leave us now really still looking at the same text we currently have which is optional for other space and leave it as legacy only. We do have other concerns as well that not all RIRs have justfy indication required in all of their policies and we're not a a big fan of handing back address space if it's not going to be properly justified for useage and that's another contention we're working with. We're doing our best to try to work with everybody and give back address space, but there just are outline policies that affect this one and we're trying to get there as fast as we can.
SPEAKER: I would like to support the statement that you make that it is mostly about legacy space, this whole idea of the policy. If you go to places like Geneva and talk to people there, they will tell you the RIRs are doing a but of course the Americans hold all that address space and that is just so unfair. So having something like this might also be seen as the RIRs doing their jobs as stewards and looking out for that stuff.
QUESTIONER: ICANN and just an observation on a trivial matter. You about the title of the policy proposal is exactly the same as the now global policy that's currently in force, which is perfectly logical because it's going to be the successor, but in the mean time, if it's adopted, pre‑depletion and it's supposed to replace the current policy, policy depletion, it will nevertheless have an effect because you have the return rules and all of that. So wouldn't it be advisable to perhaps add a qualifyer like a simple roam an 2 or something of the sort?
SPEAKER: That might be a sensible thing to do.
QUESTIONER: Leo, ICANN too. I just wanted to state that we ‑‑ we as in IANA, we can implement the policy. Thought it was probably worth putting that on the record.
CHAIR: Thanks. I would actually like to hear somebody else from our region to comment on, well, does ‑‑ do our region like this proposal or not? Or do we want to change anything?
SPEAKER: Good morning.
CHAIR: Actually, I think ‑‑ well, I'm now in the awkward situation that I want to say something about the policy and have to take my Working Group chair off.
SPEAKER: You might have a co‑chair.
CHAIR: Okay. So he's the chair now.
I think the change that this discussion of making non‑legacy space optional would avoid having quite some operational overhead, working with the fresh space that you have, and that you have procedures on how to reclaim and reassign to ‑‑ reallocate, reassign to people. If that all of a sudden starts going away right in the middle of /8 ‑‑ I'm sure that registration services is not really being happy about it. So for the legacy space, I think there should be a must or this is a way forward. But for the non‑legacy space, I like the ARIN change.
Maybe somebody from registration service can actually say a few words about that? Do I see someone? Yes, Alex, maybe you can.
Alex, RIPE NCC: Looking at our current backing systems, you have a good point because returning blocks in the middle of our /8s to the IANA would be difficult, but we are working on reimplementing the backing systems which should be finished by the end of the year and then this would not be an operational issue.
CHAIR: Okay. Thank you. So from the mechanics, we could do either way, we just go for what you think most logical. Since this needs to be a global policy, it needs to be aligned so if ARIN goes for optional we can as well go to optional.
QUESTIONER: Just to be on the record, I also think that at this point in time we should avoid punching holes into the PA blocks for quite a few different reasons. And as I'm hearing other policy proposals like address where there is the argument, we need to do something because we got routing problems, unless we do stupid things. I think this is once again one of those situations where we should be consistent. I do not expect anyone to, within a short time frame react to updating filters to accommodate one of those small blocks that have gone back and forward and reversed DNS delegation and all different sorts of things. But I don't know if this is appropriate at that point in time.
I have a logistics question as well regarding to phasing out the existing policy. But we might do that afterwards.
QUESTIONER: Hans Peter. I was just trying to understand what the advantage would be for RIPE NCC freeing up a /16 in the middle of a /8, returning it to IANA and then ARIN requesting space and getting that one and ARIN frees up some other time and RIPE requests a /16 and gets that ‑‑ this doesn't make sense, does it? If some region returns a lot of address space and some regions are in need, then this makes sense but you have to figure out how to make this a sensible policy.
SPEAKER: I agree and I think the option to ‑‑ the thought of making this mandatory for legacy space and optional for other spaces is entirely reasonable. We should also keep in mind that this is basically maybe addressing ‑‑ ultimate fairness in the very end of IPv4 address space. This will only come into place after IANA has run out and allocated the last five /8s to the various RIRs and right now we should be deemploying IPv6 anyway so this shouldn't be really really that relevant. It's one of those policies that demonstrate good steward ship on behalf of the RIRs, that give us a way to continue allocating bits of IPv4 space should that be necessary and we're all hope it won't be used because we're all happy on IPv6 anyway.
QUESTIONER: This time it's not a clarification, I have a question because I'm a little confused myself. About the phasing out of the existing policy, there was another question about that as well. My understanding, this policy, global policy, if accepted would be, in effect, only after IANA pool depletes, so the current existing policy will not be applicable anymore.
SPEAKER: Maybe I wasn't clear about this. If we all agree and it's ratified then phase 1 comes into action, and prior to depletion, IANA will set up this pool to receive address space and actually, yes, the RIRs will start to return address space to IANA. And after they run out of the current regular IPv4 space then they will start from this phase 2. Sorry, I wasn't clear about that.
CHAIR: Any other comments?
QUESTIONER: Just this logistics question, but maybe it's for the address support organisation to find out how to put in existing global policy to rest by either updating it, extending it with those provisions that it remains in effect and each and every policy can be modified and also global policy can be modified like our RIPE policies can, or if we really want to put it at rest and replace it, we have to think about how to do that properly. I'm not sure whether this would require the sort of same process like getting ‑‑ getting rid of a policy completely, whether that would actually require the same logistics steps like putting a proposal ‑‑ I don't know.
SPEAKER: My simplistic way of doing this is to do as it says here, let IANA run out of the current pool. Once they run out, the old policy can be put on the shelf and forgotten, whether we fully formally terminate it or modify it. I would just forget about it and put this one into use and then that's that. Again, we can do additional motor I have stuff as well to make it clear, version number changes and stuff.
QUESTIONER: France Telecom. I it is very good but is there sufficiently your basis for the original registry to reclaim legacy space from current holders? The legal path.
SPEAKER: I'm not sure. That depends on the situation and the various regions. Basically this, as I see it, would be ‑‑ as we've reclaimed space before, basically calling people, asking them whether they use it and they voluntarily more or less return it.
CHAIR: Due to time constraints I would like to close the microphones now. I think we should go forward with the ARIN version of the proposal and try to get consensus on that one. So that's what we'll do.
(Applause.)
CHAIR: I had to give the microphone to sender for wrapping up things as I had an opinion. So don't let this confuse you.
The next thing on our list is an old proposal which we still haven't reached consensus on, that's Philip Smith on the use of the last /8. And immediately afterwards we go to the presentation of a new proposal for the use of the last /8. And then we will discuss both proposals together since they both target the use of the last /8, and I see them as incompatible, so we can only have one of them or need to sort of find a compromise between both and then go forward, but we definitely cannot have both at the same time.
Philip, thank you.
SPEAKER: Good morning, everybody. As I say in the title here, this is the second version of the final /8 proposal. Rather than going through this in detail, I'll point out some of the changes and go through the key points of the proposal.
So the changes from version 1 are removing the distinction between new and existing LIRs, basically duplication because we describe what the policy will be with new LIRs, describe what it will be with existing LIRs and of course it was exactly the same so rather than trying to define them we just removed it and said LIRs.
There was some confusion on the list and in Dubai about whether LIRs could get one or two or more allocations from it. That was probably more my bad choice of words than the actual document. So I made it very clear that it's one allocation from this /8. And also in the text I've updated what the status of similar policy proposals are in other registry regions. So just quickly running through it.
How the NCC is going to handle the final /8 worth of address space that they have. This was all inspireed ‑‑ I started all this off in the APNIC region. It was inspired by the global policy where IANA would allocate a /8 to each LIR. That's all been ratified and happened. This does not address that /8, only the final /8 worth of address space that the NCCC holds. Details, LIRs would get NCC's minimum allocation from the /8, regardless of what their needs are. And that minimum allocation is whatever is in force at the time the LIRs comes for addresses. And they can only get one allocation from this.
There's also the /16 reserve for future use, don't know what that future use is. If there's no future use then this 16 goes back into the pool to be used as per the previous point.
Argues for: Then we have special policy for the final /8 which really all this trys to do is avoid the risk of one or two organisations consuming the entire /8 with our well‑justified and well‑crafted application.
Arguments against. I suspect quite a few. This is a couple of the main ones. Some organisations say we needs loads and loads of v4 addresses because we're roleing out some new network infrastructure but as I say here the final /8 is not really intended as a solution to growth of these organisations but really intended for transition to v6. And yes there's a chance that some organisations could get busy and set up multiple registrations for LIRs with NCC, there really isn't any mechanism to stop anybody doing now so I'm not proposing that this policy proposal should address that one.
That's pretty much it. I guess questions come later on.
CHAIR: So we go now directly to Aland, and then we do a joint discussion about what the RIPE community wants.
SPEAKER: Good morning, everybody. This is the proposal regarding the use of final /8 in a way to facilitate IPv6 deployment. So some reference to what we were at some time ago, with Geoff Huston's presentation, we all know the story of IPv4 implementation. The IANA allocates the last five /8 to the five RIRs according to the now approved global policy and the RIRs have to define a policy on the use of this last /8. All on board this train surviveed so we have some hope.
This year, we have to address at the time of exhaustion of IPv4 resources will still be required for new entrants and existing LIRs in order to support legacy IPv4 services. So we need a solution to insure that access to the limited amount of addresses is in place for the transition period. This as we know the transition period will be rather long, so we need a solution available for sufficient period of time.
Specific concerns we have to address is as Philip indicates, some specific concerns related to fairness in the context of allocation of the last IPv4 resources at regional level and we can refer to Daniel Karrenberg's presentation in Dubai. One response is the Run Out Fairly proposal and it could be this proposal to encourage IPv6 deployment. We refer to two overarching principles. We know IPv6 is the only perennial solution and we think this policy needs to be a catalyst for IPv6 deployment. The intention here is not to stretch the lifetime of IPv4 but a way for IPv6 adopters to have a window to the legacy IPv4 environment.
So to create some incentives to IPv6 deployment and not to extend the life of IPv4.
The second overarching principles on which this proposal is based is allocations and assignments should be based on justified and well‑documented needs.
So the proposal itself: The last /8 is reserved to encourage IPv6 deployment so allocation and assignment will be done in accordance with existing IPv4 address allocation and assignment policies for the RIPE region. Nothing new. Need will have to be expressed to the RIPE NCC. And we introduce in that policy additional requirements for existing LIRs. We must demonstrate that requirements for migration to IPv6 as an example, that RFC 5211 are met. For new LIRs, we need to have a request for an initial IPv6 allocation or assignment to be sure that the assignment put in place is IPv6 ‑‑ it's to provide some IPv4 addresses to allow for communicate with the IPv4 world.
Second point is that as this policy must provide addresses for long term, one solution could be to downscale allocation and assignments by factor of 64. It means that the minimum location should be down scaled to /27.
Similar proposals in other regions, I think the ARIN one is this policy is proved, the objective is similar, the same incentive for v6 deployment and the minimum allocation size is slash 28 and only a /10 block is dedicated.
APNIC, the policy is approved and implemented. It's similar but I don't think it is clearly based on needs and I don't see any incentive for v6 deployment. The size of this minimum allocation size in force is /22.
LACNIC, only for new entrants and this is from /24 to /22 and AfriNIC is down to /23.
Possible objections, what I heard is first routing impact. This will potentially create a lot of entries in the routing table, new entries. Yes, the down scale factor, we offer a lot of possibilities for small allocation, but clearly down scaleing factor will only limit the volume of addresses assigned, to what is really need in these specific queues. I think the growth of routing table will be proportional to the growth of new ISPs/PA holders. It is based on need and the number of entries is not limited to space, but to your needs.
In addition to that, I think the use of sparse allocation techniques, clearly it's not a one‑time process, we could have an allocation ‑‑ further allocations if the needs are here and this is long term. So requesters should come back to the RIPE NCC that could use the first prefix allocated and assign or allocate another prefix if needed and the requirement are met.
Filtering issues, again the downscaleing factor, allocation will be made from a specific /8. It may be easier to adapt filtering policies and of course filters will be adapted to this minimum allocation.
Okay, that's it.
CHAIR: Thanks for presenting. These don't run away. I think it would be useful to have Philip and Alain available and then get feedback from the audience and try to figure out how to join these. Don't run away.
QUESTIONER: George Michaelson. I'm going to ask a question which is possibly off to one side of this policy and doesn't materially go to the heart of what you're trying to do but it is a concern that's in my mind. The host masters in the registries essentially apply objective processes currently to assess what people get based on an application process, but that's predicated on there being adequate resource to meet the justification and the regime you're moving into is people will be able to justify far more address than you can give them and that brings to my mind this question of subjectivity. What objective aspects in these policies will be available to guide the process of determining what is an appropriate response to give someone in that regime where the justification is so much higher than the available resource? Do you feel you have ideas which can address this? Because I worry that the host masters are going to be placed in a very difficult position about having to make subjective measures between competing applications. Does that make sense as an observation?
CHAIR: Randy.
QUESTIONER: No, it doesn't. The proposal says that they get ‑‑ this specifies what they get. No judgment. In APNIC today they get a /22. Question there is none. One per customer, this size. It's painted blue and has no windows.
SPEAKER: Regarding my proposal, that's why we made a reference to the RFC because it's a clear example of criterias regarding IPv6 deployment that are objective and could be used by the host master to appreciate if the request is available or not.
QUESTIONER: Sandy Davidson. If the policy ‑‑ if the community consent ‑‑ meets a consensus on a policy and decides it's a good idea, why are we waiting until we only have one more /8 left before putting it into action? Can we start this earlier if it's a good policy that we're building together? Additionally will this policy also count for any allocations that are received after the last /8 is used? For example, these addresses that are going to go back to IANA and come back to RIPE again and be given further, are these rules going to govern those assignments and allocations as well?
SPEAKER: Answering the second bit, that's a good question. I started all this before we even had that idea of taking address space back, so I don't know, what should it be. The first bit was as I said in the presentation, it was inspired by the registries getting a final /8 from the IANA, which they all ‑‑ that's all been ratified, so I based it on once the registries have a /8 left, then let's do this.
As for the size, I have no opinion but the inspiration is from the final /8.
QUESTIONER: Wilfried. I think it's very reasonable to think about sort of cutting up the remaining stuff into smaller pieces and trying to give those pieces to as many different entities as possible, instead of being overwhelmed by one bigger request. That's sort of in support of the general idea to manage that last /8. The basic problem I'm having with the proposal to tie access to the remaining address space to a particular application, being IPv6, I'm having a problem with that. I don't think that a resource distribution policies should favour one particular application or one particular environment to be used in over other ones, because ‑‑ unique IP resources are just a piece of technology and the product you build on top of those should still be your own decision and not the decision of the big global capital I internet service providers, because what it does is limit access to the resources to those capital I internet ISPs who intend to deploy IPv6. I can imagine there's a very good reason to get a small block of IPV addresses if you want to install a management system in a mid‑size city, you might want to have IP addresses, global unique IP addresses but it doesn't make sense to do IPv6 and having 200 or 21,000 customers or no customers these days. It's a matter of limiting or not with the method of the policy, useability of those global resources for a particular type of application or not. We should be consciously making that decision.
CHAIR: Let's have Randy and Alex.
QUESTIONER: Randy Bush. I have something to say. I didn't realize I should state conflict of interest. I'm a co‑author with APNIC and full and I'm co‑chair of the APNIC Address Policy.
Philip originally when the ‑‑ 1/8 T registry proposal came out, why are we doing this if we don't know what we're going to do with that /8 and that's what this proposal adressed in APNIC.
The idea is, at least from my part is whether the world goes v4, horrible, bad, evil, or goes to IPv6, new entrants, new people coming in at the edge, are going to need a little bit of v4 to talk to the v4 internet. So the idea is to take a nice chunk of address space ‑‑ if you slice it up nice and small, will last for many years letting new people in. This has some implications to some of the questions that were just asked. The first question is: Should we do this starting now? I think many people would be unhappy doing this now. And in fact if you do this to the last /8 and you job it up into 24s or 22s or 27s, you'll have enough to last for ten, 15, 20 years, so you don't need to do other space now before and the space that is returned and recycled through the IANA or the ITU or whoever, also doesn't need to be put into this because you have enough of a pool to meet the goal. Right. Chopping up that last /8 will do it. And I agree with Wilfried very much that making sure the people who use it go to the right churchs, not a very interesting thing.
CHAIR: Thanks Randy. Alex, is that a comment from Debra?
QUESTIONER: This is me. Alex, RIPE NCC. From the point of view of evaluating requests by the IP resource analysts, it would be helpful that policies which include any requirements for address space to ‑‑ any requirements that an LIR demonstrates some sort of transition to IPv6, it would be helpful if that policy would specify what this means.
CHAIR: It has some words. We are referring to RFC ‑‑
QUESTIONER: If there would be clear RFCs mentioned, that would be obvious
CHAIR: Point taken.
QUESTIONER: A few remarks. I think what I see is an important factor in the second proposal that real simulates deployment of IPv6. I think it's not a religious issue but I think internet can develop in many different ways when we run out of IPV addresses and some ways and some architectures may change fundamentally the internet as we see it now.
Another remark is that in the second proposal I think, if I understand it correctly, it is based on the very same principles as we do address space allocation now. The downscaleing factor of 64, it just says that if you have a need for /21 and you can demonstrate this need, it is assumed that multiple technologies will be used in the future when we run out of IPv4 address space and sharing of IPV addresses will be very common and therefore if you have a need for/21,/27 should satisfy this need. So evolution from this point of view should be pretty straight forward.
And maybe final remark, in Philip's proposal, I think it's not the final proposal, it actually implies that there will be an an emerging proposal that will minimize the allocation size. If we go with this proposal right now, with a minimum allocation that RIPE NCC allocates, you will hardly cover the existing LIRs and there will be hardly anything left for the newcomers. All in all, no proposal is perfect but there's nothing perfect when we run out of IPv4 address space and looking at that we have to compare the alternatives, what happens if there's no proposal whatsoever.
CHAIR: I would really like to hear a few more voices from non‑Working Group chairs, non‑NCC members, non‑address support council members, from just the generic community. There has to be someone in here who has an opinion on this.
Okay, this is being difficult. Max.
QUESTIONER: Max, I say something about it. I think we should switch our focus to other side. Now we should develop the rules of IP version 4 market that will be ‑‑ that actually there is IPv6 market but after this, after IPv4 will be valuable source, there will be big and great market. So better is let's discuss what we can do to make it market white not black, that's my opinion.
CHAIR: Thanks for that but I think that sort of missed the point. We can define the rules for the market independent of the rules on the last /8. So on the topic at hand what do you think, should we abandon both, go for one of them?
QUESTIONER: We should do nothing, just give this final /8 as usually after that market starts.
CHAIR: That was a very clear statement. Okay.
QUESTIONER: Martin Peterson, Air Wire. Basically, I think, it should be kept as simple as possible. In general, yeah, the one thing that ‑‑ the first proposal that was presented, that Philip and ‑‑ yeah, I'd say that kind of does it like. Everybody can get one allocation of the last /8, that said. But beyond that I don't think there has to be done much more than that.
CHAIR: Okay, thank you.
Okay voices? We have plenty of time today. So really, don't be shy.
QUESTIONER: Mime's from BSI. I think the usage of the /8 should be used to facilitate, to encourage the usage of IPv6. I think it's hard enough for the networks and the providers to migrate to IPv6 and I think it should be encouraged to use it and to connect the IPv46 to the IPv4 world. That's my opinion.
CHAIR: Okay. So from those that are awake, I don't have a very clear direction. We really have had voices going for do nothing, go for the simple one size fits all and no v6 strings attached and promote v6. I will now try something and I'm not sure if I will regret it. I will try to get a show of hands which direction to take with this.
First of all, if you're awake please show your hand. This was quite an interesting exercise, I think we got about 90 percent of the people in the room, but that's good. I was expecting a bit more hangover from yesterday. So I'm going to ask three questions now, the first question is do nothing special. The second question is go with something that's similar to Philip's proposal and work out the details, but the main difference is no v6 promotion attached and the third question is go with something similar to Alain's proposal, work out the fine print and it has v6 promotion.
So show of hands, roughly, who thinks that the best way forward is not do anything special with the last /8? Sander, could you make a note, something like five to six people.
Who thinks that we should have a special policy but that special policy should not have v6 promotion attached to it? That would be Philip's proposal.
Something like about 15, 20.
Okay, the last question, who thinks that we should have a special policy and that special policy should take v6 promotion into act account?
That's more. I think that's about ‑‑ of all people that actually raised their hand in response to the specific questions, that was about ‑‑ a little bit more than half of them. So it very much looks like we go forward with Alain's proposal and work out the specific mechanics on the mailing list then. Is that the way forward? One last comment.
QUESTIONER: From the RIPE NCC Jabbering today. There's a comment from the. He says he's in favour of the first proposal, it sufficiently spreads the chance of getting allocation for every market entering LIR, also doesn't put so much burden on the routing table so.
CHAIR: Okay. Thank you. We will need to take it to the mailing list anyway and form the decision on the mailing list. Thanks for your comments. Thanks to you guise for ‑‑ Philip don't run away. It's you go.
Thanks for presenting your ideas and driving this forward. Now, it's the last proposal today which is Philip again with historic address space, efficient use of historic allocations.
SPEAKER: Okay, me again. So this is, again, second version. I did the first version of this in Dubai, took the feedback from the meeting and from the mailing list and revised appropriately. So as before I'll quickly go through the changes rather than going through the whole details of the presentation.
So the changes from the first version. I've removed the word historical. Actually the word historical caused a fair amount of discussion and debate and what historical meant. To me as an English speaker it seemed but it got difficult writing it down in text.
I also updated the status from the other registry regions.
So what's this about is all addresses be allocated, 2011, 2012, something like that. Again, emphasizing the importance of responsiblely or distributeing the remaining v4 addresses. Current problem is that LIRs who are applying for new v4 allocations only have to declare past allocations they've received from the NCC. They don't have to say anything about any other allocations.
Situation in other RIR regions, APNIC, ARIN and LACNIC consider all previous address assignments that have been made when doing new allocations, AfriNIC doesn't do anything. It doesn't consider address space that has not been allocated by AfriNIC.
So the details quite simple: NCC will now consider all v4 addresses that LIRs hold, so that will bring it into line with what APNIC, ARIN and LACNIC do.
Arguments for: Ensure efficient use of scarce IPv4 addresses space resources to the fullest extent possible, use of all IPv4 addresses will follow current best practices for address management and the free pool will be allocated to LIRs that have a genuine need.
Argument against: I don't know if this is an argument against but organisations will be unable to hoard address space while at the same time getting more space from the NCC's pool. And that's it.
CHAIR: Thank you, Philip, for reminding us what this is about since it has been there for a while. One counter‑argument I've heard is that people might prefer not to actually register their legacy address space in the database if it means that this address space is then used against them in the future. So that registration data might become worse if we do something like that. Is that something that has been mentioned in the APNIC region? And if yes, what was the opinion on that?
SPEAKER: Trying to remember back ‑‑ I can see the argument. I don't know if Randy can help my memory or not. I think it was mentioned but I don't think it was really considered a major issue. People can just choose to disappear in any case. Even today.
CHAIR: Okay. I see Randy nodding. Do you want to actually say something?
QUESTIONER: Just in case you want to beat me up further, I believe Philip's quite correct.
CHAIR: Okay, please, comments from the audience.
QUESTIONER: Just a question for clarification. Sort of considering the historical legacy, whatever you call it, address space of an LIR, looking at our situation, is the LIR meant to be exactly that, that one organisation, which would fit easily, for example, for a big telco doing that stuff, or would it also include the customers? Like in our situation as a national research network, we operate an LIR with PA space and we distribute addresses to our customers from that pool. But we have an additional set of customers having legacy address space, and that is not formally part of the LIR operations. So I think we have to ‑‑ or I need to do some home work to understand what the terminology really means because my feeling is that we should actually take into account each and every organisation applying for additional address space to sort of disclose their historical resource holdership before applying for additional ones. Or am I completely off track?
SPEAKER: The intention really was that ‑‑ I mean, if an organisation has got ‑‑ say in your case, you have affiliated organisations that have address space, is that address space that disappears and comes back to you
QUESTIONER: No, it's legacy stuff.
SPEAKER: So it's not your address space then so I wouldn't see why you'd have to declare it
QUESTIONER: Then I'd like to turn it around and think about extending it to not just applying to LIRs and PA space but to all organisations holding resources.
SPEAKER: I was going to try to do one bat at a time I think.
QUESTIONER: Filiz Yilmaz, RIPE NCC, about your first point, I think we are having a from APNIC to RIPE policies, I think the issue there is that in RIPE region, according to our policies, RIPE NCC is looking at 80 percent rule for LIR allocations because the LIRs are the ones who come back to ask for further space and there's a continuity in our registration services that we follow up on their useage while in PI world, for the PI address space there's no such continuity, and if you want to have that, that is, I think, a new policy for PI space to be evaluated for each organisation who holds PI space, that there should be a useage over a similar policy applyed over them as well.
CHAIR: Randy and then Jabber.
QUESTIONER: Jabber's disadvantage, they should get it. Are you Jabbering? Keep life simple. All this is trying to say is: When considering your utilization, consider all you hold, not just the blue stuff but the pink stuff too.
CHAIR: Yes but then we need to agree on what the pink stuff is, what is what Wilfried was
QUESTIONER: It's the stuff you hold, right, that's it, the stuff you hold. So if it's some sister organisation, you don't hold it. If it's a child who holds it, you don't hold it. If it's somebody on the moon, you don't hold it. It's what you hold. All of what you hold.
CHAIR: Very definite clarification.
QUESTIONER: Okay, Jabber from RIPE NCC. We have a comment: It is a mistake to aadopt the legacy term from ARIN a policy, network are either members of the community or they are not. He also said that we can add that this is a general comment valid for all policies.
CHAIR: So I take this to mean that we should go into the wording of the policy and see whether it really fits our terms that we use in RIPE land.
QUESTIONER: A member is not legacy or not. An address block is legacy or not. There's a confusion in that statement from Jabber.
CHAIR: I still think ‑‑ also based on the experience from other proposals that it might be a useful exercise to check every single word in there, whether something has slipped in that other regions use and we might not use the term in exactly the same way. I have nothing specific that I think needs changing but it would be prudent to take a close look.
I have heard questions for clarification. I have not heard clear directions, whether we should go for it or whether we should not go for it. So what are we going to do? I think we will have to do a new round on the mailing list, take into account the few comments that we have received so far, maybe clarify the text and do another review on the list and see if we get enough comments to have a clear idea of does the community want to go for it or not
SPEAKER: There is updated text that goes with this. So I think if the list can see the updated text, I think it will clarify some of the issues that we have in version one.
CHAIR: Then we have a way forward. Put V 2 on the list, put it up for comments and we'll see what comes out of it. Thank you for the work you put into it and it you for coming up and waiting for the to may toes. Some applause please for Philip.
(Applause.)
CHAIR: Being up there on Thursday morning 9 o'clock after the AMS‑IX party is not so easy.
That's for the formal part of the Address Policys discussion so far. So all the proposals that are in the system have a number, have explicit text and so on are covered. We have ten minutes left before the coffee break and I'm not going to let you go. We have at least one sort of not yet fully formed policy proposal, that's Andy Davidson. Would you come here and take the microphone and state the idea of what you're trying to change and how to tackle it and then we need some feedback from you.
SPEAKER: Andy Davidson. The community has recently passed the IPv6 PI policy, so thankfully and we're all very happy that we're able to do end user assignments using IPv6 with PI again that's great news. However there's a clause in the new policy being formed that states an LIR can never ever have IPv6 PI. And I think that that's possibly a mistake to leave in there because it's not a very future‑proof policy and also it means your need for addresses is determined and measured based on whether you have a contract with the NCC or not. And I think that's quite a dangerous precedent to leave in the policy. Now, I don't believe that people should be able to get PI where they should have PA, it would be for your infrastructure, not for end‑user assignments. But in my opinion whether you have a contract with the NCC or not should not determine your eligibility for addresses.
Any comments?
CHAIR: On the mailing list when discussing the PI policy, we received comments to that extent and it was agreed that we should go forward with a policy for the time being and not Wordsmith it any further, either if we are not completely happy with the details, to have a policy and then go and change it and Andy has volunteered to pick up there. So we have already some backing from the community to go with that. I would like to hear more voices.
QUESTIONER: Martin Peterson, first of all, the limitation with a LIR not being able to get PI space, I can't really see that being a problem because what do you want with PI when you have PA?
SPEAKER: You might need to make an announcement using a completely different routing policy for special case, parts of your infrastructure. So if somebody invents a protocol in the future that allows for better localization of content or if I want to do regional announcements for some of my services I can't announce that or might have to de/AG gate my PA excessively. And this is not for end user assignments, just for parts of your own infrastructure that need an individual routing policy. And the very earliest drafts of my proposed change do /SAEUT state that, the LIR must announce that differently and must give the PI back if the requirement ceases.
QUESTIONER: In theory you should be able to get /P‑FPL A for that, then it would make more sense to allow for a smaller PA /SARBGS signment that you specifically register as such. As a LIR you shouldn't have a need for PI
SPEAKER: If I have a PA that's a /32 and a PA that's a slash 48, the 48 isn't /AG gateable, it feels like PI at that point.
CHAIR: Sorry to interrupt there. I want to directly answer that. The PA policy definitely does not allow this. As it stands today the /P‑FPL A policy does one LIR one block, no provisioning for another block. In the end it doesn't matter what the /HRAEUBle says, if it's something that LIR wants to have for themselves, it's just a block of addresses. So what sort of tag is attached to it doesn't make a difference in the big scheme of things. (/HRAEUBles) so tack /‑LG these in the PI policies get us there much easier than reopening the question of who and when are you eligible to get a second PA block while the first block is not full. We had that discussion yesterday and it was difficult.
QUESTIONER: Yeah, no, it's just that ‑‑ then the other thing with the contractual clause, that needed to be there with the PI. Obviously, if you want a LIR to get PI space, the LIR already has a contract with the NCC
SPEAKER: I'm not saying the LIR shouldn't have a contract with the NCC but I'm saying whether or not you have a contract with the NCC that isn't is a fair reason to judge whether you're eligible for address or resource space. It should be addressed on need not whether you're in the club or outside the club.
QUESTIONER: Yeah but the way PI is now you don't need to be in the club
CHAIR: But if you join the club later on you lose the right to keep your PI which is dangerous.
QUESTIONER: Okay, I can see that point. Yes.
QUESTIONER: Relaying the Jabber again: A comment: The result is okay when LIR has already IPv6, what happens then when that is taken into consideration
SPEAKER: There are some words in the draft and we've had some discussions with policy makers and I'm trying to get some feedback now. We have some ideas we just don't know if they're the best ones.
QUESTIONER: As the author of the IPv6 IP policy, I'm trying to remember all the different conversations in the mailing list and the existing conversations, not only in this region, also looking globally. I think it would be much easier and much more current to actually allow an ISP to have different blocks with different announcements even if the first block is not already used. I don't know, maybe it's my personal view, but I will feel more comfortable that way because looking at different policies, development of new technologies and so on, and people already asking for allowing the aggregation, it makes more sense. But again it's my personal view and at the same time it will allow us to keep the existing IPv6 provider policy which seems more or less right for everyone, at least it passed after three years, no need to touch it again. While already there is a need to touch the existing provider Address Policy ‑‑ need modifications because some people is already asking for the aggregation.
SPEAKER: We basically have to change something to allow for D /AG or change something to allow the LIR
QUESTIONER: Exactly.
SPEAKER: I think the clause that's in there now that says if you're an LIR you can't have something, I think that's a bad precedent to leave and I think that's a worse problem to leave in the clause because in the future people might look at that as a precedent to say we can treat LIRs differently. I think if as a community we believe that your need for addresses is determined by what you're going to use them for, then we should clean up that line in the policy, in my opinion. I think we have the same outcome, but I think that we have a different conversation about how to do it.
CHAIR: What I'm hearing from that is that we are not completely in agreement on what the existing policy is supposed to have as criteria, like not being an LIR, actually being supposed to mean don't use this space to number your customers, and not actually having anything to do with the type of organisation but with the way the addresses are used. So this is not as straight forward as I assumed it would be. But we have received valuable input and I think we should go now to the list and get more feedback and then make a formal proposal. There's a need to change something, whether the output will be ‑‑ or what the output will be remains to be seen. Thanks for coming up. Thanks for getting the feedback and presenting the idea.
An applause, please.
(Applause.) Okay, we're coming to the end. We had the discussion about /KPRA 32 providers yesterday (extra) and we also had the discussion on maybe we shouldn't solve in ‑‑ we should solve this in routing or IPv6 and the Working Group chairs of routing and IPv6 got together with me and stole address space from today's ‑‑ time from today's plenary. Not address space. Well same thing, different calling name system.
So on your meeting plan you have RIPE 20 years today at 4 p.m., and the first half of that is likely going to be a discussion on this specific topic, do we want to permit deaggregation, do we want to permit additional 32s to providers. What's the way out of the cry /SEUS? Who's maintaining the internet routing police and what sort of prefixes are needed and so on. This is today, four p.m. in here. That's for the pure Address Policy Working Group for this meeting. Thanks for being here early in the morning after the AMS‑IX party. Thanks for your input and enjoy the day and the evening at the party tonight. And we're right on time for the coffee break.
Applause.)
QUESTIONER: Just so you know it's not a fantasy I want to return some address space and you know about how long this will keep IPv4 going.
CHAIR: Good morning everybody. I'm glad to see at least a few of you back. The room was definitely more crowded yesterday. There was an AMS‑IX party yesterday but I'm still happy that actually you made 9 o'clock on a morning after the AMS‑IX party.
The the Working Group chairs are still Sandra and myself. The session is still web cast so the usual caveats applys, state your name, speak in the microphone, et cetera.
We will have a short wrap up by Nigel Titley of what was discussed in the NCC Services Working Group yesterday, so the text on here is what I had on the agenda before but we're doing it a bit different. Since the discussion has been had we'll get the results, then we'll get presented these four protocols and discuss what we think about it and how to move forward. If there's time, which I can't promise at this point, there will be a couple of minutes in the end, definitely not a full hour, to mention things that you might want to see as a formal policy proposal eventually but just mention informally to get some feedback on your ideas and anything else that might come up.
First thing is Nigel Titley, Nigel, if I might ask you.
Nigel Titley: Okay, just a couple of minutes to wrap up on the discussion yesterday. You'll know about this, about this policy proposal, it's about the RIPE NCC setting out guidelines for how LIRs can receive certificates for their PA space. And basically this proposal sets out how this should be done. I'm not going to go through the proposal. The status is the RIPE NCC is ready it partially [] de/PHREU this, in other words, just a /PERTal implementation (/P‑RTal
The main concern is that certification plus /SKAUR /RUTing effectively can give a big red button for the internet, you can actually turn off a route /TPHUPBSment. You can only do this if they're cooperating. It could have implications for the internet as we know it. So there was quite a bit of discussion on this, which was rather nice. There was cautious approval that this gives more advantages than disadvantages but we really really need to get down and work out exactly what the ramifications are.
One of the arguments was this is only a tool, like filtering, you use it if you want. If everybody uses it, it becomes mandatory, if you don't use it, you won't get any customers.
The RIPE NCC must take the project further. This is only really a start, toddler's first steps and missing a lot of function alternate and it's missing the up down protocol, which is needed and we need to investigate all the ramifications. So that was an action on the RIPE NCC to get together a list of documents and policies that need looking at and changing.
Set of documents, policies and procedures to cover all the issues brought up. Action on the RIPE NCC and we do need to plan how to go forward on the certification project which is only in its first stages. Usable, but only just. And that's it. Nothing else.
Any questions? Anybody awake? Letter. Good.
(Applause.)
CHAIR: Okay. Thank you Nigel for wrapping up where we are with this today. For our policy process regarding 2008‑owe eight this means installed. We will wait for the certification process to proceed for the community to come up with where to take this and revisit the proposal, either rewrite it and abandon it or have a new one. 2008‑08 is not going further just now.
So now we now come to the first of the new proposals of this year, 2009‑01. Without further ado I give the microphone to Axel who's going to present who, why, what.
Axel: Good morning. Thank you. Okay. This, then is about the global policy proposal for the allocation of IPv4 blocks to the regional internet registries 2009‑01. This has been assembleed by a couple of concerned people who know a bit about the registrys and how to deal with the RIRs and what we are faced with and what we're missing and what we hear out in the world.
We currently do not have a global policy on IPv4 that would cover any reclaimed address space. Basically the RIRs might or might not reclaim the address space and sits there which in principle is not bad. However, then, if we are assemblers of here and nothing there, there's no mechanism currently to distribute not used space among the RIRs. So we cannot just decide that we have so much space left over we would like to go some to ARIN, for instance. We can't do that.
So the ‑‑ what we thought up is a mechanism to basically effectively be able to do this. The idea is to give space back to IANA and reallocate to aAnna to the RIRs and this is just about the mechanism and the numbers and how quickly and how fast that needs to be done by IANA that is procedure and will be defined later.
We have a couple of definitions here, recovered address space. It's reclaimed space, it's space returned voluntarily to the RIRs and does not include [] /PRERBly reclaimed space after termination of contracts with RIRs.
Then we speak about IPv4 address holding, the space unallocated at the RIRs and does not include reserved space that is reserved for later allocation.
On the two phases to this: Phase 1 is before the depletion of IPv4, the IANA, basically IANA [] /PRAEURZ for this, sets up recovered IPv4 pool and the RIRs start returning IPv4 address space as they have it available, return it in chunks every three months and only if they have aggregated blocks of /24 or larger. At some point in time we all run out of that space as we all expected, what happens is IANA obviously announces we don't have anything anymore. We recall the current global policy that governs current allocation space to the RIRs and this policy will come into effect.
What we do then, there's an allocation period defined that's basically six months and starts more or less arbitrary day in the year, 1st of March and goes until September and the second allocation period starts. Then we have an IPv4 allocation unit to define and that is a little bit geeky maybe. We thought this is something that needs to be flexible, depends a little bit on how much space overall is in this pool and we thought the allocation should be roughly about a tenth of the IPv4 address pool, then we have five RIRs then every RIR could get one of those and every half year half of the available addresses in that pool at IANA will be given out again.
Allocations to the RIRs that will be done one allocation per RIR per allocation period. So one allocation every half year. If an RIR needs it, if it is eligible, and it would be then in one allocation unit. That's why we call it allocation unit.
When is an RIR legible to receive this space from IANA? Basically this only happens once per allocation period. So we mustn't have received one yet in this period. And the RIR holdings are less than 50 percent of the current allocation unit.
Should we have new RIRs? You never know. They would get one allocation unit on recognition of this RIR or as soon as possible, as soon as there's space available to be given out to them. Of course IANA does all the reporting on this, they make public announcement. That's straight forward.
Time line, the implementation would be immediately after the ratification of the policy, that's a set up of the returned IPv4 pool.
Advantages of the policy, basically defines a mechanism for distribution of reclaimed address space.
Disadvantages we don't see any.
Where are we with this? This is a global policy, needs to be around the world, needs too be accepted by all the RIRs to come into effect. We have had a meeting in Manila where we discussed this and it was approved. Now it's subject to the last period over there. Last week we discussed this and there was a bit of complication as in the ARIN region the advisory counsel there took this text of the global policy and changed it a little and there was some backing and [] forthing about that and if [] /PHAL /A is in /SHAOEZ on the advisory council, maybe she would give some explanation there. As I understand it, we are currently looking at a rewrite of this policy text to make returns of none legacy reclaimed space optional. So basically what that would mean is that legacy space is part ‑‑ is subject of this policy and must be returned if ARIN gets back any legacy space it should go back to IANA and if ARIN gets back any space that was allocated to ARIN before, they might or they might not.
That's basically the policy. Questions or clarifications. If I did say something wrong, maybe you want to correct me.
CHAIR: Thanks for explaining what this is all the about. I have one thing that I would like some words of clarification, whether I understood it correctly. The way I understood phase one is that if today ‑‑ well, if this goes into effect and the day afterwards, and you new RIR that has been opened is closed again has received space from a nice and shiney /8, that space will then go back to IANA? Because it's reclaimed address space.
SPEAKER: Any space would be back to the RIRs, the RIPE NCC in this case and if we would not have reallocated it, we would give it back to IANA
CHAIR: Before the pool is depleted, space that comes from your working set of /8s will already go back?
SPEAKER: Yes.
CHAIR: I think that should be very clear because that has implications. Question: First of all, the ARIN region's modification doesn't really make quite a bit of sense. That's my first comment. And the second comment, Axel, could you please pull up this one supplied with the time lines and the 1/10th.
SPEAKER: Which one? Tell me when you see it.
QUESTIONER: I'll keep talking. This one here. Do I understand it correctly that this actually slows down the redistribution of reclaimed address space, even if ‑‑ even if there is quite a bit of resources being returned? My understanding is there is just two times a year where you can apply. And at a certain point in time there is almost nothing in the pool, like in the first period, and so you get 1/10ths minus something and then a big bunch of addresses comes back to IANA and there is need for those addresses but you sort of ‑‑ you had bad luck in being a little bit too early and you just got a penny but there is millions in the bank and you have to wait for another half a year.
SPEAKER: At the maximum.
QUESTIONER: At the maximum to reapply, is that right?
SPEAKER: Yes. You cannot only apply on the 1st of March and September, that is just the period, within that period you get one allocation.
SPEAKER: I got that one, but is it intentional that this slows down the redistribution of reclaimed addresses even if there is a documented need?
SPEAKER: Depends on what's in the pool and when. Yes.
QUESTIONER: I'm here as an Advisory Council ARIN rep. Axel pretty much cleared it up but I'm a fan of full disclosure so to cover it, we did optional because the main reason this policy came about was to address legacy space and if you're not aware ARIN holds the majority of space and a big chunk that people are hoping will come back from the DOD. That's really why this is here. We talked with the authors last week in ‑‑ where we were in San Antonio. And they agreed any other space should be taken. They were trying to get to the other RIRs to change the text from what we discussed to make it legacy only every where, but they ‑‑ there just wasn't enough time so it passed in APNIC as is. So that would leave us now really still looking at the same text we currently have which is optional for other space and leave it as legacy only. We do have other concerns as well that not all RIRs have justfy indication required in all of their policies and we're not a a big fan of handing back address space if it's not going to be properly justified for useage and that's another contention we're working with. We're doing our best to try to work with everybody and give back address space, but there just are outline policies that affect this one and we're trying to get there as fast as we can.
SPEAKER: I would like to support the statement that you make that it is mostly about legacy space, this whole idea of the policy. If you go to places like Geneva and talk to people there, they will tell you the RIRs are doing a but of course the Americans hold all that address space and that is just so unfair. So having something like this might also be seen as the RIRs doing their jobs as stewards and looking out for that stuff.
QUESTIONER: ICANN and just an observation on a trivial matter. You about the title of the policy proposal is exactly the same as the now global policy that's currently in force, which is perfectly logical because it's going to be the successor, but in the mean time, if it's adopted, pre‑depletion and it's supposed to replace the current policy, policy depletion, it will nevertheless have an effect because you have the return rules and all of that. So wouldn't it be advisable to perhaps add a qualifyer like a simple roam an 2 or something of the sort?
SPEAKER: That might be a sensible thing to do.
QUESTIONER: Leo, ICANN too. I just wanted to state that we ‑‑ we as in IANA, we can implement the policy. Thought it was probably worth putting that on the record.
CHAIR: Thanks. I would actually like to hear somebody else from our region to comment on, well, does ‑‑ do our region like this proposal or not? Or do we want to change anything?
SPEAKER: Good morning.
CHAIR: Actually, I think ‑‑ well, I'm now in the awkward situation that I want to say something about the policy and have to take my Working Group chair off.
SPEAKER: You might have a co‑chair.
CHAIR: Okay. So he's the chair now.
I think the change that this discussion of making non‑legacy space optional would avoid having quite some operational overhead, working with the fresh space that you have, and that you have procedures on how to reclaim and reassign to ‑‑ reallocate, reassign to people. If that all of a sudden starts going away right in the middle of /8 ‑‑ I'm sure that registration services is not really being happy about it. So for the legacy space, I think there should be a must or this is a way forward. But for the non‑legacy space, I like the ARIN change.
Maybe somebody from registration service can actually say a few words about that? Do I see someone? Yes, Alex, maybe you can.
Alex, RIPE NCC: Looking at our current backing systems, you have a good point because returning blocks in the middle of our /8s to the IANA would be difficult, but we are working on reimplementing the backing systems which should be finished by the end of the year and then this would not be an operational issue.
CHAIR: Okay. Thank you. So from the mechanics, we could do either way, we just go for what you think most logical. Since this needs to be a global policy, it needs to be aligned so if ARIN goes for optional we can as well go to optional.
QUESTIONER: Just to be on the record, I also think that at this point in time we should avoid punching holes into the PA blocks for quite a few different reasons. And as I'm hearing other policy proposals like address where there is the argument, we need to do something because we got routing problems, unless we do stupid things. I think this is once again one of those situations where we should be consistent. I do not expect anyone to, within a short time frame react to updating filters to accommodate one of those small blocks that have gone back and forward and reversed DNS delegation and all different sorts of things. But I don't know if this is appropriate at that point in time.
I have a logistics question as well regarding to phasing out the existing policy. But we might do that afterwards.
QUESTIONER: Hans Peter. I was just trying to understand what the advantage would be for RIPE NCC freeing up a /16 in the middle of a /8, returning it to IANA and then ARIN requesting space and getting that one and ARIN frees up some other time and RIPE requests a /16 and gets that ‑‑ this doesn't make sense, does it? If some region returns a lot of address space and some regions are in need, then this makes sense but you have to figure out how to make this a sensible policy.
SPEAKER: I agree and I think the option to ‑‑ the thought of making this mandatory for legacy space and optional for other spaces is entirely reasonable. We should also keep in mind that this is basically maybe addressing ‑‑ ultimate fairness in the very end of IPv4 address space. This will only come into place after IANA has run out and allocated the last five /8s to the various RIRs and right now we should be deemploying IPv6 anyway so this shouldn't be really really that relevant. It's one of those policies that demonstrate good steward ship on behalf of the RIRs, that give us a way to continue allocating bits of IPv4 space should that be necessary and we're all hope it won't be used because we're all happy on IPv6 anyway.
QUESTIONER: This time it's not a clarification, I have a question because I'm a little confused myself. About the phasing out of the existing policy, there was another question about that as well. My understanding, this policy, global policy, if accepted would be, in effect, only after IANA pool depletes, so the current existing policy will not be applicable anymore.
SPEAKER: Maybe I wasn't clear about this. If we all agree and it's ratified then phase 1 comes into action, and prior to depletion, IANA will set up this pool to receive address space and actually, yes, the RIRs will start to return address space to IANA. And after they run out of the current regular IPv4 space then they will start from this phase 2. Sorry, I wasn't clear about that.
CHAIR: Any other comments?
QUESTIONER: Just this logistics question, but maybe it's for the address support organisation to find out how to put in existing global policy to rest by either updating it, extending it with those provisions that it remains in effect and each and every policy can be modified and also global policy can be modified like our RIPE policies can, or if we really want to put it at rest and replace it, we have to think about how to do that properly. I'm not sure whether this would require the sort of same process like getting ‑‑ getting rid of a policy completely, whether that would actually require the same logistics steps like putting a proposal ‑‑ I don't know.
SPEAKER: My simplistic way of doing this is to do as it says here, let IANA run out of the current pool. Once they run out, the old policy can be put on the shelf and forgotten, whether we fully formally terminate it or modify it. I would just forget about it and put this one into use and then that's that. Again, we can do additional motor I have stuff as well to make it clear, version number changes and stuff.
QUESTIONER: France Telecom. I it is very good but is there sufficiently your basis for the original registry to reclaim legacy space from current holders? The legal path.
SPEAKER: I'm not sure. That depends on the situation and the various regions. Basically this, as I see it, would be ‑‑ as we've reclaimed space before, basically calling people, asking them whether they use it and they voluntarily more or less return it.
CHAIR: Due to time constraints I would like to close the microphones now. I think we should go forward with the ARIN version of the proposal and try to get consensus on that one. So that's what we'll do.
(Applause.)
CHAIR: I had to give the microphone to sender for wrapping up things as I had an opinion. So don't let this confuse you.
The next thing on our list is an old proposal which we still haven't reached consensus on, that's Philip Smith on the use of the last /8. And immediately afterwards we go to the presentation of a new proposal for the use of the last /8. And then we will discuss both proposals together since they both target the use of the last /8, and I see them as incompatible, so we can only have one of them or need to sort of find a compromise between both and then go forward, but we definitely cannot have both at the same time.
Philip, thank you.
SPEAKER: Good morning, everybody. As I say in the title here, this is the second version of the final /8 proposal. Rather than going through this in detail, I'll point out some of the changes and go through the key points of the proposal.
So the changes from version 1 are removing the distinction between new and existing LIRs, basically duplication because we describe what the policy will be with new LIRs, describe what it will be with existing LIRs and of course it was exactly the same so rather than trying to define them we just removed it and said LIRs.
There was some confusion on the list and in Dubai about whether LIRs could get one or two or more allocations from it. That was probably more my bad choice of words than the actual document. So I made it very clear that it's one allocation from this /8. And also in the text I've updated what the status of similar policy proposals are in other registry regions. So just quickly running through it.
How the NCC is going to handle the final /8 worth of address space that they have. This was all inspireed ‑‑ I started all this off in the APNIC region. It was inspired by the global policy where IANA would allocate a /8 to each LIR. That's all been ratified and happened. This does not address that /8, only the final /8 worth of address space that the NCCC holds. Details, LIRs would get NCC's minimum allocation from the /8, regardless of what their needs are. And that minimum allocation is whatever is in force at the time the LIRs comes for addresses. And they can only get one allocation from this.
There's also the /16 reserve for future use, don't know what that future use is. If there's no future use then this 16 goes back into the pool to be used as per the previous point.
Argues for: Then we have special policy for the final /8 which really all this trys to do is avoid the risk of one or two organisations consuming the entire /8 with our well‑justified and well‑crafted application.
Arguments against. I suspect quite a few. This is a couple of the main ones. Some organisations say we needs loads and loads of v4 addresses because we're roleing out some new network infrastructure but as I say here the final /8 is not really intended as a solution to growth of these organisations but really intended for transition to v6. And yes there's a chance that some organisations could get busy and set up multiple registrations for LIRs with NCC, there really isn't any mechanism to stop anybody doing now so I'm not proposing that this policy proposal should address that one.
That's pretty much it. I guess questions come later on.
CHAIR: So we go now directly to Aland, and then we do a joint discussion about what the RIPE community wants.
SPEAKER: Good morning, everybody. This is the proposal regarding the use of final /8 in a way to facilitate IPv6 deployment. So some reference to what we were at some time ago, with Geoff Huston's presentation, we all know the story of IPv4 implementation. The IANA allocates the last five /8 to the five RIRs according to the now approved global policy and the RIRs have to define a policy on the use of this last /8. All on board this train surviveed so we have some hope.
This year, we have to address at the time of exhaustion of IPv4 resources will still be required for new entrants and existing LIRs in order to support legacy IPv4 services. So we need a solution to insure that access to the limited amount of addresses is in place for the transition period. This as we know the transition period will be rather long, so we need a solution available for sufficient period of time.
Specific concerns we have to address is as Philip indicates, some specific concerns related to fairness in the context of allocation of the last IPv4 resources at regional level and we can refer to Daniel Karrenberg's presentation in Dubai. One response is the Run Out Fairly proposal and it could be this proposal to encourage IPv6 deployment. We refer to two overarching principles. We know IPv6 is the only perennial solution and we think this policy needs to be a catalyst for IPv6 deployment. The intention here is not to stretch the lifetime of IPv4 but a way for IPv6 adopters to have a window to the legacy IPv4 environment.
So to create some incentives to IPv6 deployment and not to extend the life of IPv4.
The second overarching principles on which this proposal is based is allocations and assignments should be based on justified and well‑documented needs.
So the proposal itself: The last /8 is reserved to encourage IPv6 deployment so allocation and assignment will be done in accordance with existing IPv4 address allocation and assignment policies for the RIPE region. Nothing new. Need will have to be expressed to the RIPE NCC. And we introduce in that policy additional requirements for existing LIRs. We must demonstrate that requirements for migration to IPv6 as an example, that RFC 5211 are met. For new LIRs, we need to have a request for an initial IPv6 allocation or assignment to be sure that the assignment put in place is IPv6 ‑‑ it's to provide some IPv4 addresses to allow for communicate with the IPv4 world.
Second point is that as this policy must provide addresses for long term, one solution could be to downscale allocation and assignments by factor of 64. It means that the minimum location should be down scaled to /27.
Similar proposals in other regions, I think the ARIN one is this policy is proved, the objective is similar, the same incentive for v6 deployment and the minimum allocation size is slash 28 and only a /10 block is dedicated.
APNIC, the policy is approved and implemented. It's similar but I don't think it is clearly based on needs and I don't see any incentive for v6 deployment. The size of this minimum allocation size in force is /22.
LACNIC, only for new entrants and this is from /24 to /22 and AfriNIC is down to /23.
Possible objections, what I heard is first routing impact. This will potentially create a lot of entries in the routing table, new entries. Yes, the down scale factor, we offer a lot of possibilities for small allocation, but clearly down scaleing factor will only limit the volume of addresses assigned, to what is really need in these specific queues. I think the growth of routing table will be proportional to the growth of new ISPs/PA holders. It is based on need and the number of entries is not limited to space, but to your needs.
In addition to that, I think the use of sparse allocation techniques, clearly it's not a one‑time process, we could have an allocation ‑‑ further allocations if the needs are here and this is long term. So requesters should come back to the RIPE NCC that could use the first prefix allocated and assign or allocate another prefix if needed and the requirement are met.
Filtering issues, again the downscaleing factor, allocation will be made from a specific /8. It may be easier to adapt filtering policies and of course filters will be adapted to this minimum allocation.
Okay, that's it.
CHAIR: Thanks for presenting. These don't run away. I think it would be useful to have Philip and Alain available and then get feedback from the audience and try to figure out how to join these. Don't run away.
QUESTIONER: George Michaelson. I'm going to ask a question which is possibly off to one side of this policy and doesn't materially go to the heart of what you're trying to do but it is a concern that's in my mind. The host masters in the registries essentially apply objective processes currently to assess what people get based on an application process, but that's predicated on there being adequate resource to meet the justification and the regime you're moving into is people will be able to justify far more address than you can give them and that brings to my mind this question of subjectivity. What objective aspects in these policies will be available to guide the process of determining what is an appropriate response to give someone in that regime where the justification is so much higher than the available resource? Do you feel you have ideas which can address this? Because I worry that the host masters are going to be placed in a very difficult position about having to make subjective measures between competing applications. Does that make sense as an observation?
CHAIR: Randy.
QUESTIONER: No, it doesn't. The proposal says that they get ‑‑ this specifies what they get. No judgment. In APNIC today they get a /22. Question there is none. One per customer, this size. It's painted blue and has no windows.
SPEAKER: Regarding my proposal, that's why we made a reference to the RFC because it's a clear example of criterias regarding IPv6 deployment that are objective and could be used by the host master to appreciate if the request is available or not.
QUESTIONER: Sandy Davidson. If the policy ‑‑ if the community consent ‑‑ meets a consensus on a policy and decides it's a good idea, why are we waiting until we only have one more /8 left before putting it into action? Can we start this earlier if it's a good policy that we're building together? Additionally will this policy also count for any allocations that are received after the last /8 is used? For example, these addresses that are going to go back to IANA and come back to RIPE again and be given further, are these rules going to govern those assignments and allocations as well?
SPEAKER: Answering the second bit, that's a good question. I started all this before we even had that idea of taking address space back, so I don't know, what should it be. The first bit was as I said in the presentation, it was inspired by the registries getting a final /8 from the IANA, which they all ‑‑ that's all been ratified, so I based it on once the registries have a /8 left, then let's do this.
As for the size, I have no opinion but the inspiration is from the final /8.
QUESTIONER: Wilfried. I think it's very reasonable to think about sort of cutting up the remaining stuff into smaller pieces and trying to give those pieces to as many different entities as possible, instead of being overwhelmed by one bigger request. That's sort of in support of the general idea to manage that last /8. The basic problem I'm having with the proposal to tie access to the remaining address space to a particular application, being IPv6, I'm having a problem with that. I don't think that a resource distribution policies should favour one particular application or one particular environment to be used in over other ones, because ‑‑ unique IP resources are just a piece of technology and the product you build on top of those should still be your own decision and not the decision of the big global capital I internet service providers, because what it does is limit access to the resources to those capital I internet ISPs who intend to deploy IPv6. I can imagine there's a very good reason to get a small block of IPV addresses if you want to install a management system in a mid‑size city, you might want to have IP addresses, global unique IP addresses but it doesn't make sense to do IPv6 and having 200 or 21,000 customers or no customers these days. It's a matter of limiting or not with the method of the policy, useability of those global resources for a particular type of application or not. We should be consciously making that decision.
CHAIR: Let's have Randy and Alex.
QUESTIONER: Randy Bush. I have something to say. I didn't realize I should state conflict of interest. I'm a co‑author with APNIC and full and I'm co‑chair of the APNIC Address Policy.
Philip originally when the ‑‑ 1/8 T registry proposal came out, why are we doing this if we don't know what we're going to do with that /8 and that's what this proposal adressed in APNIC.
The idea is, at least from my part is whether the world goes v4, horrible, bad, evil, or goes to IPv6, new entrants, new people coming in at the edge, are going to need a little bit of v4 to talk to the v4 internet. So the idea is to take a nice chunk of address space ‑‑ if you slice it up nice and small, will last for many years letting new people in. This has some implications to some of the questions that were just asked. The first question is: Should we do this starting now? I think many people would be unhappy doing this now. And in fact if you do this to the last /8 and you job it up into 24s or 22s or 27s, you'll have enough to last for ten, 15, 20 years, so you don't need to do other space now before and the space that is returned and recycled through the IANA or the ITU or whoever, also doesn't need to be put into this because you have enough of a pool to meet the goal. Right. Chopping up that last /8 will do it. And I agree with Wilfried very much that making sure the people who use it go to the right churchs, not a very interesting thing.
CHAIR: Thanks Randy. Alex, is that a comment from Debra?
QUESTIONER: This is me. Alex, RIPE NCC. From the point of view of evaluating requests by the IP resource analysts, it would be helpful that policies which include any requirements for address space to ‑‑ any requirements that an LIR demonstrates some sort of transition to IPv6, it would be helpful if that policy would specify what this means.
CHAIR: It has some words. We are referring to RFC ‑‑
QUESTIONER: If there would be clear RFCs mentioned, that would be obvious
CHAIR: Point taken.
QUESTIONER: A few remarks. I think what I see is an important factor in the second proposal that real simulates deployment of IPv6. I think it's not a religious issue but I think internet can develop in many different ways when we run out of IPV addresses and some ways and some architectures may change fundamentally the internet as we see it now.
Another remark is that in the second proposal I think, if I understand it correctly, it is based on the very same principles as we do address space allocation now. The downscaleing factor of 64, it just says that if you have a need for /21 and you can demonstrate this need, it is assumed that multiple technologies will be used in the future when we run out of IPv4 address space and sharing of IPV addresses will be very common and therefore if you have a need for/21,/27 should satisfy this need. So evolution from this point of view should be pretty straight forward.
And maybe final remark, in Philip's proposal, I think it's not the final proposal, it actually implies that there will be an an emerging proposal that will minimize the allocation size. If we go with this proposal right now, with a minimum allocation that RIPE NCC allocates, you will hardly cover the existing LIRs and there will be hardly anything left for the newcomers. All in all, no proposal is perfect but there's nothing perfect when we run out of IPv4 address space and looking at that we have to compare the alternatives, what happens if there's no proposal whatsoever.
CHAIR: I would really like to hear a few more voices from non‑Working Group chairs, non‑NCC members, non‑address support council members, from just the generic community. There has to be someone in here who has an opinion on this.
Okay, this is being difficult. Max.
QUESTIONER: Max, I say something about it. I think we should switch our focus to other side. Now we should develop the rules of IP version 4 market that will be ‑‑ that actually there is IPv6 market but after this, after IPv4 will be valuable source, there will be big and great market. So better is let's discuss what we can do to make it market white not black, that's my opinion.
CHAIR: Thanks for that but I think that sort of missed the point. We can define the rules for the market independent of the rules on the last /8. So on the topic at hand what do you think, should we abandon both, go for one of them?
QUESTIONER: We should do nothing, just give this final /8 as usually after that market starts.
CHAIR: That was a very clear statement. Okay.
QUESTIONER: Martin Peterson, Air Wire. Basically, I think, it should be kept as simple as possible. In general, yeah, the one thing that ‑‑ the first proposal that was presented, that Philip and ‑‑ yeah, I'd say that kind of does it like. Everybody can get one allocation of the last /8, that said. But beyond that I don't think there has to be done much more than that.
CHAIR: Okay, thank you.
Okay voices? We have plenty of time today. So really, don't be shy.
QUESTIONER: Mime's from BSI. I think the usage of the /8 should be used to facilitate, to encourage the usage of IPv6. I think it's hard enough for the networks and the providers to migrate to IPv6 and I think it should be encouraged to use it and to connect the IPv46 to the IPv4 world. That's my opinion.
CHAIR: Okay. So from those that are awake, I don't have a very clear direction. We really have had voices going for do nothing, go for the simple one size fits all and no v6 strings attached and promote v6. I will now try something and I'm not sure if I will regret it. I will try to get a show of hands which direction to take with this.
First of all, if you're awake please show your hand. This was quite an interesting exercise, I think we got about 90 percent of the people in the room, but that's good. I was expecting a bit more hangover from yesterday. So I'm going to ask three questions now, the first question is do nothing special. The second question is go with something that's similar to Philip's proposal and work out the details, but the main difference is no v6 promotion attached and the third question is go with something similar to Alain's proposal, work out the fine print and it has v6 promotion.
So show of hands, roughly, who thinks that the best way forward is not do anything special with the last /8? Sander, could you make a note, something like five to six people.
Who thinks that we should have a special policy but that special policy should not have v6 promotion attached to it? That would be Philip's proposal.
Something like about 15, 20.
Okay, the last question, who thinks that we should have a special policy and that special policy should take v6 promotion into act account?
That's more. I think that's about ‑‑ of all people that actually raised their hand in response to the specific questions, that was about ‑‑ a little bit more than half of them. So it very much looks like we go forward with Alain's proposal and work out the specific mechanics on the mailing list then. Is that the way forward? One last comment.
QUESTIONER: From the RIPE NCC Jabbering today. There's a comment from the. He says he's in favour of the first proposal, it sufficiently spreads the chance of getting allocation for every market entering LIR, also doesn't put so much burden on the routing table so.
CHAIR: Okay. Thank you. We will need to take it to the mailing list anyway and form the decision on the mailing list. Thanks for your comments. Thanks to you guise for ‑‑ Philip don't run away. It's you go.
Thanks for presenting your ideas and driving this forward. Now, it's the last proposal today which is Philip again with historic address space, efficient use of historic allocations.
SPEAKER: Okay, me again. So this is, again, second version. I did the first version of this in Dubai, took the feedback from the meeting and from the mailing list and revised appropriately. So as before I'll quickly go through the changes rather than going through the whole details of the presentation.
So the changes from the first version. I've removed the word historical. Actually the word historical caused a fair amount of discussion and debate and what historical meant. To me as an English speaker it seemed but it got difficult writing it down in text.
I also updated the status from the other registry regions.
So what's this about is all addresses be allocated, 2011, 2012, something like that. Again, emphasizing the importance of responsiblely or distributeing the remaining v4 addresses. Current problem is that LIRs who are applying for new v4 allocations only have to declare past allocations they've received from the NCC. They don't have to say anything about any other allocations.
Situation in other RIR regions, APNIC, ARIN and LACNIC consider all previous address assignments that have been made when doing new allocations, AfriNIC doesn't do anything. It doesn't consider address space that has not been allocated by AfriNIC.
So the details quite simple: NCC will now consider all v4 addresses that LIRs hold, so that will bring it into line with what APNIC, ARIN and LACNIC do.
Arguments for: Ensure efficient use of scarce IPv4 addresses space resources to the fullest extent possible, use of all IPv4 addresses will follow current best practices for address management and the free pool will be allocated to LIRs that have a genuine need.
Argument against: I don't know if this is an argument against but organisations will be unable to hoard address space while at the same time getting more space from the NCC's pool. And that's it.
CHAIR: Thank you, Philip, for reminding us what this is about since it has been there for a while. One counter‑argument I've heard is that people might prefer not to actually register their legacy address space in the database if it means that this address space is then used against them in the future. So that registration data might become worse if we do something like that. Is that something that has been mentioned in the APNIC region? And if yes, what was the opinion on that?
SPEAKER: Trying to remember back ‑‑ I can see the argument. I don't know if Randy can help my memory or not. I think it was mentioned but I don't think it was really considered a major issue. People can just choose to disappear in any case. Even today.
CHAIR: Okay. I see Randy nodding. Do you want to actually say something?
QUESTIONER: Just in case you want to beat me up further, I believe Philip's quite correct.
CHAIR: Okay, please, comments from the audience.
QUESTIONER: Just a question for clarification. Sort of considering the historical legacy, whatever you call it, address space of an LIR, looking at our situation, is the LIR meant to be exactly that, that one organisation, which would fit easily, for example, for a big telco doing that stuff, or would it also include the customers? Like in our situation as a national research network, we operate an LIR with PA space and we distribute addresses to our customers from that pool. But we have an additional set of customers having legacy address space, and that is not formally part of the LIR operations. So I think we have to ‑‑ or I need to do some home work to understand what the terminology really means because my feeling is that we should actually take into account each and every organisation applying for additional address space to sort of disclose their historical resource holdership before applying for additional ones. Or am I completely off track?
SPEAKER: The intention really was that ‑‑ I mean, if an organisation has got ‑‑ say in your case, you have affiliated organisations that have address space, is that address space that disappears and comes back to you
QUESTIONER: No, it's legacy stuff.
SPEAKER: So it's not your address space then so I wouldn't see why you'd have to declare it
QUESTIONER: Then I'd like to turn it around and think about extending it to not just applying to LIRs and PA space but to all organisations holding resources.
SPEAKER: I was going to try to do one bat at a time I think.
QUESTIONER: Filiz Yilmaz, RIPE NCC, about your first point, I think we are having a from APNIC to RIPE policies, I think the issue there is that in RIPE region, according to our policies, RIPE NCC is looking at 80 percent rule for LIR allocations because the LIRs are the ones who come back to ask for further space and there's a continuity in our registration services that we follow up on their useage while in PI world, for the PI address space there's no such continuity, and if you want to have that, that is, I think, a new policy for PI space to be evaluated for each organisation who holds PI space, that there should be a useage over a similar policy applyed over them as well.
CHAIR: Randy and then Jabber.
QUESTIONER: Jabber's disadvantage, they should get it. Are you Jabbering? Keep life simple. All this is trying to say is: When considering your utilization, consider all you hold, not just the blue stuff but the pink stuff too.
CHAIR: Yes but then we need to agree on what the pink stuff is, what is what Wilfried was
QUESTIONER: It's the stuff you hold, right, that's it, the stuff you hold. So if it's some sister organisation, you don't hold it. If it's a child who holds it, you don't hold it. If it's somebody on the moon, you don't hold it. It's what you hold. All of what you hold.
CHAIR: Very definite clarification.
QUESTIONER: Okay, Jabber from RIPE NCC. We have a comment: It is a mistake to aadopt the legacy term from ARIN a policy, network are either members of the community or they are not. He also said that we can add that this is a general comment valid for all policies.
CHAIR: So I take this to mean that we should go into the wording of the policy and see whether it really fits our terms that we use in RIPE land.
QUESTIONER: A member is not legacy or not. An address block is legacy or not. There's a confusion in that statement from Jabber.
CHAIR: I still think ‑‑ also based on the experience from other proposals that it might be a useful exercise to check every single word in there, whether something has slipped in that other regions use and we might not use the term in exactly the same way. I have nothing specific that I think needs changing but it would be prudent to take a close look.
I have heard questions for clarification. I have not heard clear directions, whether we should go for it or whether we should not go for it. So what are we going to do? I think we will have to do a new round on the mailing list, take into account the few comments that we have received so far, maybe clarify the text and do another review on the list and see if we get enough comments to have a clear idea of does the community want to go for it or not
SPEAKER: There is updated text that goes with this. So I think if the list can see the updated text, I think it will clarify some of the issues that we have in version one.
CHAIR: Then we have a way forward. Put V 2 on the list, put it up for comments and we'll see what comes out of it. Thank you for the work you put into it and it you for coming up and waiting for the to may toes. Some applause please for Philip.
(Applause.)
CHAIR: Being up there on Thursday morning 9 o'clock after the AMS‑IX party is not so easy.
That's for the formal part of the Address Policys discussion so far. So all the proposals that are in the system have a number, have explicit text and so on are covered. We have ten minutes left before the coffee break and I'm not going to let you go. We have at least one sort of not yet fully formed policy proposal, that's Andy Davidson. Would you come here and take the microphone and state the idea of what you're trying to change and how to tackle it and then we need some feedback from you.
SPEAKER: Andy Davidson. The community has recently passed the IPv6 PI policy, so thankfully and we're all very happy that we're able to do end user assignments using IPv6 with PI again that's great news. However there's a clause in the new policy being formed that states an LIR can never ever have IPv6 PI. And I think that that's possibly a mistake to leave in there because it's not a very future‑proof policy and also it means your need for addresses is determined and measured based on whether you have a contract with the NCC or not. And I think that's quite a dangerous precedent to leave in the policy. Now, I don't believe that people should be able to get PI where they should have PA, it would be for your infrastructure, not for end‑user assignments. But in my opinion whether you have a contract with the NCC or not should not determine your eligibility for addresses.
Any comments?
CHAIR: On the mailing list when discussing the PI policy, we received comments to that extent and it was agreed that we should go forward with a policy for the time being and not Wordsmith it any further, either if we are not completely happy with the details, to have a policy and then go and change it and Andy has volunteered to pick up there. So we have already some backing from the community to go with that. I would like to hear more voices.
QUESTIONER: Martin Peterson, first of all, the limitation with a LIR not being able to get PI space, I can't really see that being a problem because what do you want with PI when you have PA?
SPEAKER: You might need to make an announcement using a completely different routing policy for special case, parts of your infrastructure. So if somebody invents a protocol in the future that allows for better localization of content or if I want to do regional announcements for some of my services I can't announce that or might have to de/AG gate my PA excessively. And this is not for end user assignments, just for parts of your own infrastructure that need an individual routing policy. And the very earliest drafts of my proposed change do /SAEUT state that, the LIR must announce that differently and must give the PI back if the requirement ceases.
QUESTIONER: In theory you should be able to get /P‑FPL A for that, then it would make more sense to allow for a smaller PA /SARBGS signment that you specifically register as such. As a LIR you shouldn't have a need for PI
SPEAKER: If I have a PA that's a /32 and a PA that's a slash 48, the 48 isn't /AG gateable, it feels like PI at that point.
CHAIR: Sorry to interrupt there. I want to directly answer that. The PA policy definitely does not allow this. As it stands today the /P‑FPL A policy does one LIR one block, no provisioning for another block. In the end it doesn't matter what the /HRAEUBle says, if it's something that LIR wants to have for themselves, it's just a block of addresses. So what sort of tag is attached to it doesn't make a difference in the big scheme of things. (/HRAEUBles) so tack /‑LG these in the PI policies get us there much easier than reopening the question of who and when are you eligible to get a second PA block while the first block is not full. We had that discussion yesterday and it was difficult.
QUESTIONER: Yeah, no, it's just that ‑‑ then the other thing with the contractual clause, that needed to be there with the PI. Obviously, if you want a LIR to get PI space, the LIR already has a contract with the NCC
SPEAKER: I'm not saying the LIR shouldn't have a contract with the NCC but I'm saying whether or not you have a contract with the NCC that isn't is a fair reason to judge whether you're eligible for address or resource space. It should be addressed on need not whether you're in the club or outside the club.
QUESTIONER: Yeah but the way PI is now you don't need to be in the club
CHAIR: But if you join the club later on you lose the right to keep your PI which is dangerous.
QUESTIONER: Okay, I can see that point. Yes.
QUESTIONER: Relaying the Jabber again: A comment: The result is okay when LIR has already IPv6, what happens then when that is taken into consideration
SPEAKER: There are some words in the draft and we've had some discussions with policy makers and I'm trying to get some feedback now. We have some ideas we just don't know if they're the best ones.
QUESTIONER: As the author of the IPv6 IP policy, I'm trying to remember all the different conversations in the mailing list and the existing conversations, not only in this region, also looking globally. I think it would be much easier and much more current to actually allow an ISP to have different blocks with different announcements even if the first block is not already used. I don't know, maybe it's my personal view, but I will feel more comfortable that way because looking at different policies, development of new technologies and so on, and people already asking for allowing the aggregation, it makes more sense. But again it's my personal view and at the same time it will allow us to keep the existing IPv6 provider policy which seems more or less right for everyone, at least it passed after three years, no need to touch it again. While already there is a need to touch the existing provider Address Policy ‑‑ need modifications because some people is already asking for the aggregation.
SPEAKER: We basically have to change something to allow for D /AG or change something to allow the LIR
QUESTIONER: Exactly.
SPEAKER: I think the clause that's in there now that says if you're an LIR you can't have something, I think that's a bad precedent to leave and I think that's a worse problem to leave in the clause because in the future people might look at that as a precedent to say we can treat LIRs differently. I think if as a community we believe that your need for addresses is determined by what you're going to use them for, then we should clean up that line in the policy, in my opinion. I think we have the same outcome, but I think that we have a different conversation about how to do it.
CHAIR: What I'm hearing from that is that we are not completely in agreement on what the existing policy is supposed to have as criteria, like not being an LIR, actually being supposed to mean don't use this space to number your customers, and not actually having anything to do with the type of organisation but with the way the addresses are used. So this is not as straight forward as I assumed it would be. But we have received valuable input and I think we should go now to the list and get more feedback and then make a formal proposal. There's a need to change something, whether the output will be ‑‑ or what the output will be remains to be seen. Thanks for coming up. Thanks for getting the feedback and presenting the idea.
An applause, please.
(Applause.) Okay, we're coming to the end. We had the discussion about /KPRA 32 providers yesterday (extra) and we also had the discussion on maybe we shouldn't solve in ‑‑ we should solve this in routing or IPv6 and the Working Group chairs of routing and IPv6 got together with me and stole address space from today's ‑‑ time from today's plenary. Not address space. Well same thing, different calling name system.
So on your meeting plan you have RIPE 20 years today at 4 p.m., and the first half of that is likely going to be a discussion on this specific topic, do we want to permit deaggregation, do we want to permit additional 32s to providers. What's the way out of the cry /SEUS? Who's maintaining the internet routing police and what sort of prefixes are needed and so on. This is today, four p.m. in here. That's for the pure Address Policy Working Group for this meeting. Thanks for being here early in the morning after the AMS‑IX party. Thanks for your input and enjoy the day and the evening at the party tonight. And we're right on time for the coffee break.
Applause.)
QUESTIONER: Just so you know it's not a fantasy I want to return some address space and you know about how long this will keep IPv4 going.