Address Policy
Wednesday, 22nd May 2019
9 a.m.:
ERIK BAIS: Good morning, everybody. Welcome to Address Policy Working Group for this RIPE meeting. Everybody in? Good.
So, on behalf of Gert Doring and myself, welcome. We have some adjustments in the agenda. We will go over that later. It's a bit different than what we had drafted on the mailing list. There have been some changes in Address Policy, one of them is the new changes recently done that were not using any lay TREX any more so thanks to Gert for doing that in the last couple of years. It's particularly helpful for the RIPE NCC that we are now going to do this in PowerPoint.
Administrative matters:
Thanks for the scribe. We have the minutes that we are going to approve, we have a chair rotation. The longest serving chair is going to step down and we have a new candidate, which is the same chair. One of the things that's different on the agenda is, we are going to have a brief new policy proposal and in the ‑‑ we have published it a bit to the front of the agenda, one of the reasons for that is that the policy proposal will conflict with the Connect Working Group on the second session, so that's why we want to have it in the front. Before that, we will also give Hans Petter some speaking time, so after the chair rotation, we will give the floor to Hans Petter. Hans Petter, that's okay? So after the chair rotation, you will have your time.
Then after that presentation of Remco, Who is also in the room, welcome, we will do the current policy topics and after that we will have the update from Nikolas about the RIPE NCC registration services.
This topic might actually overflow, it depends a bit how we are doing on time, into the second session the second session will also be here in the side room, and after the coffee break we will have, we will then continue with the open policy proposal, which is 2019‑O2 waiting list and the reduction of IPv4 allocations and then we have open policy hour. And in open policy hour, we will have Rudiger and ‑ will have a short talk about the extended stats file. And then any other business.
So, are we missing anything, anything that somebody wants to bring up for the agenda? Open policy hour? So if you have something that you want to discuss, come to us in the coffee break or if you want to either to me or to Gert, and then we can see if we can fit that in.
So, the minutes from RIPE 77, any questions on that, any comments? You all read them, of course? Anything that needs to be adjusted? Then we did not receive any feedback and comments, so in that case, we will conclude the minutes are final.
Then we will go to the chair selection. We did this a bit different this time, we asked on the mailing list for participants if somebody wanted to volunteer as a new Address Policy Working Group chair. It's a bit more ‑‑ it's a bit of a different way of doing it. The intent was to get, you know, candidates and then basically introduce new candidates to the mailing list with overwhelming feedback that we received, we have one candidate, and here is Gert. So Gert agreed to do another term. So we don't have much of an election but more a reintroduction of Gert, and if the room agrees, then we will proceed with Gert as the new chair.
(Applause)
Then without further ado, Hans Petter.
HANS PETTER HOLEN: Thank you. So as many of, you know, we have ongoing discussion of the RIPE chair selection procedure, and for those of you who attended the BoF last night you will know that there are no two draft documents one for selection of chair by a phenomenon come which is the sort of the results of the results on the last meeting that has been published on the RIPE chair discuss mailing list for a while and there is a second proposal based on BCP 10 from IETF on thousand put together the NomCom. Since the last document was published I want to call for consensus at this meeting but I want to point you all to this document, I will send you out an e‑mail to the RIPE list later today. And encourage you to read them and comment on them so that we can sort of conclude the discussion based on documents some weeks after the RIPE meeting and call for consensus so we can get the documents in place and hopefully start the formal process to select a chair based on this process.
And that could then start at the next meeting. Whether I will run or not is something I will decide closer to that meeting. I have said in the past that I am willing to put my name forward. But, well in a world like this, you never know what happened so far. So, really I encourage you all to have a look at these documents and voice your opinions so that we get good community consensus on that. Thank you.
ERIK BAIS: Thanks, Hans Petter. Then, are you ready?
REMCO VAN MOOK: As ready as I will be this morning.
So, good morning, ladies and gentlemen. What I did was upload my slides 30 seconds before walking up here, you should not do this. I repeat: You should not do this. And if you are presenting at the Connect Working Group at 11:00 please upload your slides now. Thank you.
But that's not what I am here for. What I am here for is a long time ago, about seven years ago, this Working Group passed a policy which created a separate pool for Internet Exchanges to be assigned addresses out of. And that pool has actually been quite successful, roughly about half of it's been used, but given the accelerated growth of Internet Exchange points in the service region, the end of that pool could very well be coming a little sooner than we were hoping for. So, therefore, this is a draft policy proposal so it doesn't have a number yet. So Marco is going to have to do some homework after this session, which ‑‑ which does a couple of things. So this is the current policy, there is a reserve /16, IXPs can get a single block ranging from a 24 as a starting IX to 22 if they are really big. Any unused assignments. So basically if you grow from a 24 to 23 you have to return the whole 24 and so on.
Changes:
There has been a bit of textual clean‑up. The policy itself, the text wasn't necessarily in the right order and very clean which is partly my fault, so I tried to do a better job this time together with Will and Will to reduce the confusion.
What is changing: We increased the reserve pool from a 16 to 15. We reduced the maximum assignment size to a 23, so basically if you are having an exchange with more than 500 members you should be able to find your own address space somewhere else. And we reduced the minimum assignment to a /27. Now, what does this, there is a bunch of scraps lying in the basement of the RIPE NCC office that are too unusable for global routing but are still globally unique and actually, as Internet Exchanges have evolved we have pretty much figured out Internet Exchange does not or should not be globally routed, but should very much be globally unique. So this offers an option to have a place to put the scraps, basically. The default assignment for new exchange remains at 24.
Rationale: The original policy dates back from 2012. We have used about half the pool, globally routable less of a concern now. We do need globally unique. And we are not going to touch any of the existing assignments, so if you have a 22 based on current policy you are not going to get caught out.
Arguments against:
Well it no longer provides for large IXs and the main argument against for this room is it moves the depletion of the free pool forward by by about a week. I am sure you will all shocked. And that's it. Any questions? Cake? Tomatoes? Rocks? In that case, I will go back to my coffee, thank you.
(Applause)
GERT DORING: Don't run away yet. We had the discussion about the routability of the exchange points networks, I think two meetings ago, and I got yelled at by the IXP folks that we shouldn't do assumptions by routability and non‑routability. So, if a smaller IXP comes up and say we have ten members but we want our network to be visible, what will they get?
REMCO VAN MOOK: The default assignment is always going to be 24.
GERT DORING: So you would only ‑‑ the new policy would only assign something smaller if an exchange point comes up and says I want a 27 because that is good enough for what we do?
REMCO VAN MOOK: I want a 27 is an argument ‑‑ or the only thing that is left is a 27.
GERT DORING: Okay. But you don't have arguments and discussions about routing or not?
REMCO VAN MOOK: No
GERT DORING: If you want 24, there is no questions asked?
REMCO VAN MOOK: Basically if there is a place to put all these tiny little blocks that have problems, this is where they should go.
GERT DORING: Good. Thank you
WOLFGANG TREMMEL: I work for DE‑CIX run exchange points. Is there any text in there for growth so that an exchange if it it's growing gets returned
REMCO VAN MOOK: Like the policy is right now, if you have a 24 you outgrow the 24 you can go ask for 23 and you have to return the 24 within 80 days
WOLFGANG TREMMEL: And then you get 22?
REMCO VAN MOOK: You get 23 and 22 option in the new policy gets dropped.
WOLFGANG TREMMEL: I like everything except you did cannot grow beyond /23
REMCO VAN MOOK: Given you are only one of the exchanges on planet with more than 22 I can see why that is.
WOLFGANG TREMMEL: We are not the only one. AMS‑IX as well.
REMCO VAN MOOK: I say one of the few, not the only.
ERIK BAIS: Any other questions? It's time for coffee for you.
(Applause)
All right. Then Marco, are you ready for it? It's a bit early, I know, I know.
MARCO SCHMIDT: Good morning everyone, also for me, I work as the policy officer from the RIPE NCC, and I am actually very happy to see such a full room early on Wednesday morning.
And yes, I want to give my usual presentation about what's going on in the policy land since the last RIPE meeting, last year in October in Amsterdam, so you will find out everything else except the proposal, the very new traffic proposal that Remco just presented, it came so quickly and so recent that I couldn't include it in my slides.
So what I am going to do, I am first going to talk about what happened in our region since October last year. Then, I will look a little bit beyond what is going on in the other four regions and I will close with a little update from the policy development office.
So first off, what has happened in the last month here? And also what proposals are currently out there under discussion. At this moment, we have three proposals in the initial discussion phase, and none of these proposals actually is discussed here in the Address Policy Working Group. The first one, 2018‑06 this will be discussed tomorrow at 11:00 in the Routing Working Group. And this one is about entries in the RIPE routing registry that are not authorised by the RIPE NCC.
Maybe a bit of background: A long time ago, not every region had its routing registries so there was an option in the RIPE routing registry to enter some route objects but not always they were entered by the rightful resource holder. And this proposal actually tried to tackle that one in a way that, if there is a conflict with a certificate from the resource holder with that entry then this entry will be deleted. And this proposal was presented around the last RIPE meeting and the proposals were a bit busy with other things and it took sometime and a few days ago they submitted their second version and probably later today it will be published and a new discussion phase will start on this second version.
The second proposal here on the list, it's one that will be discussed tomorrow in the Anti‑Abuse Working Group at 9:00 in the main room downstairs. That one, I am not sure if you have followed that discussion, it was quite intensive one so far with a lot of participation, a lot of feedback, so very interesting. It's about BGP hijacking and that this would be considered a RIPE policy violation. And that is quite new, unchartered territory because so far, it's common understanding by many people of the RIPE community that routing is not the ‑‑ yeah, this is not part of the mandate of the registry system, of the Internet registries. So if you are interested in that topic, I invite you again tomorrow at 9:00 to be downstairs in the main room.
There also you will hear about a second proposal that will be discussed in the anti‑abuse Working Group, the about validation of the abuse mailbox. Actually about last year, a policy proposal has reached consensus in our region that mandates the RIPE NCC to validate the abuse contact information that is mandatory in the RIPE database. And this validation is focusing on the technical features of an e‑mail address so if it's working, if the domain exists, if the main servir is configured. However, this proposal the new one suggests this is not enough, there should be human interaction for every abuse contact e‑mail address and this should be done every six months. It's just out in the discussion since last week and it will be presented tomorrow.
A proposal that is currently in review phase and that will be discussed in this Address Policy Working Group is the IPv4 waiting list implementation, so I will not spend much time on this, also because my colleague Nikolas in the next presentation will have some interesting numbers on that topic.
And there are three proposals that actually have finished the policy development in the last six months. One was accepted, actually just last week, 2019‑01. This one clarified something in the IPv4 policy. There are the different statuses mentioned that an IP range can have in RIPE database and it was not completely clear that the status assigned PA actually also can be used for the LIR infrastructure, and now we have with this change, this is clarified and there is no ambiguity any more.
And two proposals have been withdrawn. The first one 2018‑O2, it was an assignment clarification in the IPv6 policy, and that one followed actually another policy change that was done, that reached consensus just before to define what is a sub‑assignment and what is not in the IPv6 world. That's why this proposal didn't get much support and didnt get much feedback and also there was a feeling that it doesn't change really so much and that whatever this tried to achieve can be actually done with additional clarification on the RIPE NCC website for how IPv6 can be used.
Another proposal that was withdrawn that was discussed in the NCC ‑‑ RIPE NCC Services Working Group, it was about the publication of legal address of Internet number resource holders, sparked by some discussion, sparked some opposition and subsequently it was withdrawn.
That was the quick overview what's going on in our region. So let's look a little bit what's going on somewhere else. And I can tell you it's quite a lot. So this is a a list of policy proposals that are under discussion in the different regions, AFRINIC currently leading with 14 different policy proposals. And no worries, I am not telling you about each and every one of them and I will not tell you how many of these proposals are of the same person. So I will ‑‑ so I will actually ‑‑ I just picked a few that I think are interested ‑‑ of interest for policy discussions in our region and in general for the RIPE community.
In the first topic is about IPv4, or more specific about IPv4 run‑out, and in APNIC region actually a proposal reached consensus and already implemented that changed the minimum allocation size. In APNIC it's called minimum ‑‑ maximum delegation size to /23. So far that allocation was a /22, and with an attempt to stretch the remaining IPv4, the proposal was put forward to reduce this by half to a /23.
Another proposal that goes a bit in the same direction is about abolishing of a waiting list for unmet IPv4 requests, and that's maybe a little bit confusing, why get rid of a waiting list? So I give a feedback there. In the APNIC region there are two IPv4 pools, one is the classical last /8 pool, the 103 /8 and every new member gets a /23 now out of it. And there has been a second pool of all the returned address space and members could get a second IPv4 out of that pool and as this pool had been depleted there was a wasting list and once address space was returned, members got a second block from that range. This proposal basically said, you know what, let's get rid of this waiting list and add all this returned address space to the first pool so once this has been depleted that new members still can get address space from that returned address space as a first block.
In ARIN there are also some discussions about the waiting list. ARIN has run out of IPv4 a couple of years ago, but they have a waiting list and if you justify a need for a certain size, even larger sizes, you were put on a waiting list and if such address space was returned, you could get that block. However, it has been found out that a significant amount of this address space, it was received via the waiting list was transferred shortly after soon after the policy restriction on transfers have been expired. So it reams a reasonable amount of those distributions from the waiting list were used by speculators. And to counter that there is a proposal now out to actually reduce the maximum block size that you can get from the waiting list to a /22. And there is even another maybe more radical proposal out there, that even says let's get rid completely of the waiting list and that ARIN, all the address space that ARIN gets back puts out for auction and give it to the highest bidder. So let's see how this goes.
And in AFRINIC, there is a soft landing update, so soft landing, AFRINIC still has IPv4 but it's also reaching the end and called soft landing policy, some people believe it's too relaxed so they want to tighten that one. And that proposal, amongst all the others, will be discussed in a few weeks in the next AFRINIC meeting in Uganda.
Moving on to IPv6, there are also a couple of proposals out there in the world. The first one here actually, the clarification of IPv6 sub‑assignments, they are out in three regions, that is the one that has been withdrawn in our region, and it's in different statuses. In AFRINIC it has been accepted and it's currently in implementation. In APNIC it's still under discussion. In LACNIC it has just reached last call following the LACNIC meeting two weeks ago.
And also in AFRINIC there is quite new proposal out there that wants to define better what is IPv6 PI, for what can it be used and for what not.
ASN also some proposals out there, it's actually the same but in two different regions, to remove the multi‑homing requirement. It has reached consensus in the APNIC region and it will be under discussion in AFRINIC also in a few weeks' time.
Transfers. Another big topic of course. There are a lot of proposals out there, all around the world, and I just picked the ones that are probably most interesting for our region.
First off, ARIN again, they have accepted some time ago and now also implemented, an Inter‑RIR transfer policy for AS numbers. So far such transfers have been only possible between our region, the RIPE NCC region and APNIC, and now ARIN joined the club. So in case you knew about a very nice AS number that is in the ARIN region or you have a nice one to give, that's not possible to transfer.
LACNIC has reached rough consensus on a proposal that is called IPv4 Resource Transfer Policy Comprehensive, it's now in last call and the interesting part is that one also includes an Inter‑IR clause, so if this one is going to finish the last call and will be implemented also LACNIC will join the club of IRs that allow IPv4 transfers between their regions.
Which would leave AFRINIC currently as the last of the five regions that have not an Inter‑RIR transfer policy yet in consensus at least but there are several proposals out there that try to tackle that topic in from different angles and all them again will be discussed soon and let's see if one of them at least will reach consensus and then AFRINIC might join the club of Inter‑RIR IPv4 transfers as well.
And last one that I want to mention, ARIN is also discussion ongoing to allow IPv6 transfers with other regions. So far, the RIPE region is the only one that allows IPv6 transfers, and as there is no other region that is doing that it's only possible within our service region. If that proposal would reach consensus, then our policies would match and transfers of IPv6 resources also would be possible with ARIN, but it's still under discussion there.
And yeah, as I said, there are a couple of more but I am not going into the detail of them. I think these ones are the most interesting and relevant ones.
Anti‑abuse, from my first section you might remember we have two interesting proposals on that in our region, so have a couple of the other regions, in AFRINIC, APNIC, and LACNIC, so there is a discussion going on of the validation of abuse contacts. It has reached consensus in APNIC some time ago and APNIC is still busy with the implementation and in the other three regions it's still under discussion.
In LACNIC, they have a similar proposal like our BGP hijacking proposal, it's called resource hijacking. It has been presented and heavily discussed during the last LACNIC meeting and it's still under discussion. It's ongoing.
And in ARIN, a similar proposal also has been put forward but there it's a bit different, the policy development works different there, everybody can bring forward their proposal and then the ARIN Advisory Council looks at if this proposal is sound and within the scope of the ARIN policy manual. And the Advisory Council first considered that this proposal would not be in scope because BGP hijacking is something new and not mentioned there. However, then there was the ARIN PDP allows some ‑‑ allows a petition against this proposal, against this decision, and this was successful so there were enough people on the mailing list speaking up and say okay, regardless if I support or oppose that proposal, I would like to discuss it. So, currently status is that ARIN board of trustees is looking at this BGP hijacking proposal again, whether or not if it's within scope.
That brings me to my last short section
AUDIENCE SPEAKER: AFRINIC is there as well but still not published, I guess today or tomorrow?
MARCO SCHMIDT: We get some inside information, AFRINIC will join the club of BGP hijacking proposals.
Last short section, a little bit on update. I always keep a track of the participation in policy discussions. So I look a little bit at the different Working Groups, how many people give feedback to policy proposals. And I try to find out where these people are located because it's good to see that we have ‑‑ if we have a nice distribution there.
So you see here darker the country, more people participate. I put intentionally Iceland on the top left there, so unfortunately so far we have nobody from Iceland participating. So maybe after today and with this very interesting proposals that are out there also some Icelandic people are going to join because all in all, it is good that the whole region participates and gives their opinion. And personally I would like to see sometimes more participation from the Balkan area, from the Middle East and we are still working there to get it, but you see so far we have quite nice distribution, more than 100 people from more than 30 countries, so it's pretty good. But it always can be better.
Last update is a little new feature that we just have implemented. So far if in our region a proposal gets accepted, the announcement is sent out and the new policy document gets published. And sometimes it's a bit confusing because sometimes the RIPE NCC needs extra time to implement a proposal. And this was so far not clearly visible on our website. So we have now something that if you look at the archive proposal that you can see if it's already implemented or if it's still ongoing and you also can see the date when it has been implemented because sometimes it might be useful if you look back, oh, at this moment was already a transfer allowed, yes or not. And thank you. So far, this has not been applied to all the archived proposals because I have to go to the mailing list to find out when which proposal has been implemented but you can expect in the next couple of days and weeks that this data will be added.
This brings me to the end of my presentation. If you found interesting or a bit too fast and if you want to now know about all the 14 policy proposals of AFRINIC just download my presentation and there you have those links and you always can follow me on Twitter, also there I keep you updated about the latest policy developments all around the world.
And that's it. I am happy to take any questions or comments.
AUDIENCE SPEAKER: Just a comment, I just wanted to congratulate you about your job because ‑‑ so I try to follow the discussion in the different regions and about all the policy discussion proposals etc. Particularly ‑‑ last anti‑abuse which is now implemented within the RIPE region, discussion are ongoing in very different ways so to have this work of ‑‑ so different discussion is very, very useful from my point of view. So thank you very much.
MARCO SCHMIDT: Thanks. I see nobody else. Then, thank you very much.
(Applause)
ERIK BAIS: Then we will go to Nikolas for your update from the RS.
NIKOLAS PEDIADITIS: Good morning everyone. I am part of the Registration Services team at the RIPE NCC. Andrea couldn't be with us, unfortunately, this time but he sends his greetings to all of you. And for quite a few RIPE meetings now, the main theme of this session is IPv4 run‑out. And it makes sense, the end is near, and so this time I would like to give you an update on what is happening, what the current status is, how we are handling things, if there are any topics still to be discussed, but would also like to focus on the next day and IPv6.
I am pretty sure most of you are familiar with this graph. It represents our available IPv4 pools. And I don't think I bring any shocking news to anybody by saying that it's declining fast and we are really, really close to the actual final run‑out. The question is, how close are we? And what we keep asking ourselves is this: Is will IPv4 make it to Rotterdam? And the answer is, we are not quite sure. The numbers give an indication so we can make an estimation on when we will actually run out. We can say with some certainty that it will not make it to Berlin but for RIPE 79, we are not that certain. And let's see why is that. Let's look at some numbers.
This is the current status of our pools. So right now, we have in total in our pools a bit more than 4 million IPv4 addresses, and that will accommodate for another 4,000, approximately, /22s. In terms of contiguous at this stage use above 3,000 and we have reserved /16 and another 64 and if we calculate the fragments that will be /23s and 24s, we can combine those and make up for another 965 /22s more.
Now, if you look at the consumption rate, you can see a steady increase. So if we look at 2019, in January we issued a bit less than 400 IPv4 allocations. And in April 500. So you can see a steady increase. And if we make another average of the past six months we can say we are allocating approximately 475 allocations per month. However, it's not a steady number.
So, considering those numbers, when will we actually run out? If everything stays the same, if there is no major policy change in the coming months, then we expect that we will run out of contiguous /22s late November 2019. Then we have a reserve /16, that will last us for another five days or so. And once we start combining the fragments to make /22s, it will go up to early February 2020. So, that will be our best‑case scenario right now.
Now, according to this, you could say okay then IPv4 will make it to Rotterdam. However, our previous estimation in the previous RIPE meeting was for May to June 2020. And since then, the number of allocations reached every month is increasing. So, we kind of expect it to be quite a bit sooner than February 2020. So Rotterdam or not, it will be a close call.
What's next? Then there will be a waiting list. We discussed this for the previous couple of RIPE meetings. There was not really any other visible solution suggested, so one way or another, in order to make sure that things will be ‑‑ will remain fair, since the RIPE NCC will continue receiving some IPv4 addresses back, there has to be a waiting list.
And because of that, and because we don't have a lot of time but we do have a lot of work to do, we have already started to preparing at the RIPE NCC to gather the requirements to see how that is going to work and plan things in advance.
So currently just to give you an overview of what we are doing, we are reviewing our procedures in order to make sure that when the time comes we are ready for it. We need to plan complex changes in our internal and external software. There is a lot of updates that need to be done to our documentation and we need to establish clear communication with all of our stakeholders, and we are doing that while keeping some goals in mind.
We want to be ready as early as possible. We don't like the idea of when the day comes to turn a switch and then things can go wrong and people can freak out. We are going to be ready in advance so we can make this as smooth and seamless for our members as possible. We want to keep things simple, and ensure fairness so the idea of first‑come/first‑served will remain. And we want to ensure transparency. And we are working our ways on how to achieve that.
To give you some examples, we want to make it visible for members what the position in that waiting list will be, we want to make it publicly visible externally, what the size of the waiting list currently is, things like that. We are working to see how we can make that happen. We want to keep things efficient, we want to automate this as much as possible, try to avoid any unnecessary tickets for people and any hassle. And something that is really, really important, we want to keep our members informed, especially the up coming ones. We want to make sure that it's clear to everybody that if you plan to become a member, you might be placed on a waiting list, there are no guarantees that you will get IPv4 and we want this to be clear before a member becomes a member.
The good thing is we are not totally new to this process, we have been there before in 2012 in the previous run‑out. So we have gained some experience and we will use that experience and the lessons learned to make sure that everything will go smooth this time as well.
Speaking of a waiting list, we have a new policy proposal, or to be more exact, we have a Version 2 of a policy proposal. Now, in the upcoming slot after the coffee break, you will have plenty of time to discuss about it; for now I would like to give you the main points. Hopefully everybody followed Erik's e‑mail and you actually read Version 2 of the proposal so we can avoid misunderstandings of speaking about Version 1. So I would like to give you the main points and illustrate them with some numbers that will facilitate your discussion in the upcoming slot.
So this proposal is introducing first‑come/first‑served waiting list as per policy, and that's a good thing because it's a nice thing to have this in a policy with a clear mandate from the community.
What does it say: That when an equivalent of a /22 can no longer be allocated then the ‑‑ then it comes into effect, then the waiting list comes into effect. And then the slides ‑‑ size of allocations will reduce from /22s to /24s. This will be only accessible, the /24s will be only available for LIRs that don't yet have an allocation from the RIPE NCC. That, of course, excludes LIRs that have IPv4 allocations received through a transfer, a merger or acquisition and so on. But if an LIR had already received an allocation from the past is not entitled for a new /24. And then IPv4 blocks smaller than a /24, what we used to call IPv4 dust, will be kept aside until the missing fragments are there to make complete /24s and put it back in the pool to be issued.
Now, you heard Remco before, I think this is a conflict there between this and the expand ‑‑ expanding the IXP pool proposal maybe, but I am sure you guys can discuss this and a solution can be found. I don't see this as a big issue.
So what happens to this policy proposal will be accepted. From our side we can tell you that our time‑lines will not be affected. We will run out when we will run out, regardless of whether this proposal is accepted or not, simply because it does not change what happens with /22s.
More LIRs will be able to receive a small chunk of IPv4. So if you look at the table, you will see the amount of IPv4 addresses that the RIPE NCC is recovering in the past three years. It's not a lot. It's another ‑‑ 80,000 let's say IP addresses per year. According to current policy this will accommodate approximately 80 requests per year so 80 more networks, 80 more LIRs, getting a small chunk of IPv4, with a new policy that quadruples to 320 so more people will be able to have access to a little bit of IPv4.
It will reduce waiting time on the waiting list. In the previous RIPE meeting, we presented this model to you in order to explain exactly that. So basically it's a simulation based on a more neutral year than last year, 2017, and what would happen if we continue with /22s, what would happen if that becomes a /24. And as you can see, the waiting time in the waiting list, it reduces significantly.
And we believe it will also make it much less attractive for speculators. A /24 if someone wants to open an LIR to get IPv4 and sell it, a /24 will not be as attractive as a /22. So there will be some benefits gained there as well.
Now, I was planning to also discuss the last remaining issue that needs to be resolved following up from the previous RIPE meeting but this community, the reflexes are so great we have already a proposal and a proposal coming up, because it's really, really the last call if we want to do anything with the IXP pool. A graph just to make a point, as Remco already said, we have /16 set aside for IXPs, we have already consumed half of it and our estimation is with the current utilisation rate that by mid‑2022, max early 2023, the IXP pool will be empty. So, I think it's established in this community that IXPs are considered a key part of the Internet ecosystem. Take into account that the PDP takes four months at least, so it's really good that the discussion already started and we have already a proposal coming up. But keep in mind that even that we start now, by the time the PDP is finished we are already in September. So it's really good that people reacted really fast in this. There is no question any more if pool is large enough, that you will discuss during the policy proposal discussion phase. And the only thing we needed to tell you is time ‑ if you believe we need to increase the pool.
Now, enough with IPv4. We can maybe talk for more fun stuff. Also known as IPv6, which apparently is also running out. Maybe we should declare 2019 as the year of run‑out of all things, I don't know. But what do we mean by that? This is a graph that shows how the RIPE NCC historically was distributing IPv6. Now, in the early days, some of you might remember, it was around '99 we started issuing /35 allocations. Things changed over time, the policies were updated, the allocation sizes changed, the reservation sizes came along with allocation sizes. Things became different. We were issuing /35s and back then, as per policy, we were reserving /26. ‑‑ /29s, I am sorry. Then later on the default size of an allocation became a /32 and 29, by default I mean you could get /29 without any justification required. That's the case today. At the same time, over time, things were happening in the IPv4 world that were impacting the IPv6 world. It used to be the case that you ‑‑ it was mandatory to have an IPv6 allocation in order to get your /22. This was abolished later on. Then we had this big phenomenon of multiple LIRs that really really impacted the number of IPv6 allocations that the RIPE NCC was issuing, and we reached the present day where we are actually running out. And if we keep things as they are, you might be surprised but if we do nothing we might actually run out of IPv6 before we run out of IPv4, which is extraordinary, if you think about it.
But this is IPv6. So, there is no reason to panic because we can get more, and we have plenty of more to get and we are getting more. So according to the IANA policy for allocations of IPv6, every RIR is eligible to receive additional IPv6 allocation from IANA once it reaches the point when 50% of the /12 is consumed. So that will be a /13. We reached that point long ago. In fact, right now if we count the available space in our pools, is around 20% of /12. And with that, the RIPE NCC is about to become the first RIR to request a second /12 from IANA. We already underway and hopefully pretty soon, maybe as early as next week, we will be able to make an announcement to you and show you the new shiny /12 that will be available in our pools. And in a few months from now, we will start allocating from it.
(Applause)
And actually that is really good news for you guys. It means that something is happening. Now, with that, we will also like to discuss something with you, it's an issue that we raised in the past, some time ago. Back then, we showed you some numbers and you told us, okay guys, we see the problem but it's not a big problem yet so keep monitoring, keep monitoring it, come back to us, if it becomes bigger show us numbers and we will see if it's an issue or not and I am talking about stockpiling of IPv6. So that's what we did, we went back because we did see a really big increase in numbers when it comes to it, and the idea is to present it to you and then you get to decide if it's an issue or not, if you want to us do something about it or not.
The big picture is this: What we tried to do initially was to group IPv6 allocations per member. As you know, a member can have multiple LIR accounts these days, so we thought okay, let's see, for every member how many IPv6 allocations are being held? And the numbers have increased considerably since the last time we discussed this. We have a member that holds 52 allocations. And we have a member that holds 31, another one 28, so on, we have 12 members holding 10 allocations, 33 holding 5, 165 holding 3 and so on. Now, this is not entirely the complete picture, because, as, you know, anybody can open multiple companies, you can have multiple memberships, every member can have multiple RIRs and we do know that the accumulation of IPv6 is actually higher than what this table shows.
What are the factors that are making this possible? Of course, it's our current status and the way our policies work. Every LIR can get a /29, it's not per organisation, the policy was clarified quite recently. As you know IPv6 is transferrable in our region, we are actually the only RIR that this is allowed. And of course multiple LIRs are allowed in our region.
The thing is, and that's why we are bringing this up again, that we really see a growing trend. If you look at the two graphs, the one on the left shows the size of IPv6 allocations. We count /32s in order to make our graphs consistent and not individual separate allocations so you can see 44,000 of them are with members that have multiple LIRs and twice as much with members having only one LIR. What shows a clear picture and the growing trend that I am talking about is the graph on the right. Look at the blue line. That shows the size of allocations issued to multiple LIR accounts. And you can see, for example, that in here, 2018, more than 5,000 of them went to multiple LIRs. In 2019, we expect the number to be even higher, and at the same time you see an increase in the transfers between them. So there are a lot of IPv6 blocks that go back and forth. Do you see this as an issue? It raises a question, maybe. We have members that rare /28 or a/26, they have doing according to the policy requirements, they need to justify why they need so much, we will evaluate, issue to them, at the same time we have a lot of members with a lot of allocations that don't have doing through that route. So it's one of the questions. Is that something that is ‑‑ it's a question of fairness, maybe.
Then we did something that we were curious, we thought it would be interesting to show you, so we thought okay let's look at announcements because the truth is, whether multiple LIRs or single LIRs, the amount of space is pretty much the same, pretty much 50% of what we allocate is being announced. So we thought let's have look at the IP blocks issued only to multiple LIRs and let's take only the big ones so we looked at members that have at least five LIR accounts and looked at how they are announcing their IPv6 space. So, is it being announced by their own AS number, by AS number of end user by somebody else's AS number? And if, for example, you look at the first column, let's focus just on the /29s, we can see that approximately one‑third of them is being announced by the AS number of the LIRs themselves, there is a little fraction of it that is being announced by the AS number of an end user. The interesting part is that almost one‑third of it is being announced by AS numbers of other LIRs, and almost another third is being announced by AS numbers that are not relevant. So it's AS numbers that maybe are out of region in other RIRs, AS numbers that are under the registration or in our free pools for example and they shouldn't be announcing something. So, that raises another question, because if an LIR gets IP space it can do whatever they want, of course it's their job to assign and to suballocate it, but when an LIR is assigning IP space to somebody else to use, that is supposed to be reached in the RIPE database and if that is a bigger than a /48 according to the policy the RIPE NCC should ever a request to evaluate that need for something bigger than a /48 for a single end site. And I can tell you as RIPE NCC we maybe have received a handful of requests to evaluate assignments bigger than /48. So that raises another question. Could be a sub allocation, and some people do that, we have quite a lot of examples of that.
So we are not saying necessarily that this is an issue; we are asking if this is an issue. Our arguments, in order to facilitate the discussion, we don't focus this in usage, we don't don't say that people are wasting IPv6. I think it has become clear by this community that guys we have a lot, let's get it out there and used. It's not about the usage or wasting IPv6. In the context of our function as an RIR, I mean, we focus in the registry, do you see this as an issue? We have been pointed out by members to people offering /32s in better prices than the RIPE NCC. We have been shown the websites doing that. Is that okay? Do we run the risk maybe in the future ‑‑ because if people are handing /32 in better prices, do we run the risk in the future we don't know who has what, we cannot validate that. Then it's another question of fairness: Do you guys see a discrepancy between the policy for large allocations and the people that can bypass that by opening two LIRs?
And finally, we have some experience from IPv4. We have some sad experiences from the past especially from certain countries, where people received big chunks of IPv4 from LIRs, if you remember things were not clear, was it PI or PA, and then at some point they were told, okay, now you are using it, you have two options, you pay a lot more, order your number, go to the RIPE NCC if you have any complaints. And they were coming to the RIPE NCC and were shouting although the space was PA. Do we run the risk of having that repeated with IPv6? So, this is why we are bringing this up. We want to ask you if this is an issue, and if you believe that this is an issue, is there something that we can do? And with that, if you have any questions, I will be happy to answer. Otherwise we can move on with discussion.
GERT DORING: I have one comment, and this is, well, it's partly to you, and partly to the room, that I think we have been doing well with the /12s and the way we do inside the /12, because we got a /12 that lasted like close to 20 years, which means we reduce your overheads in going back to IANA like every two months and getting more space, but we have been making good use of that space so we actually used it and gave it out and you have been building v6 networks. So looking at these 20 years I think we have done something pretty reasonable there. So that's good.
On the numbers here, on the 32s, it's interesting. If you put it in perspective, it's just a fairly small number compared to the overall 32 /29s you have been giving out. So yes we might think about it, but it's not dramatic. That's my take on it. But it's very good to have the numbers and the questions so we can do an educated discussion. Thank you.
ERIK BAIS: Yes. For that as well, do you expect this increase to go after Rotterdam? Because at a certain time, the v4 will stop, and then a new LIR will just get the v6 allocation. The question is, will this stockpiling of v6 continue with, you know, after October/November/December this year?
NIKOLAS PEDIADITIS: Indeed it is highly possible it will not. We do anticipate a big drop in the multiple LIRs phenomenon after that. So, hopefully this will decrease. Whether people will have built up a business case to continue, I'm not sure. But the incentive of getting IPv4 will be out. So hopefully, indeed, this will decrease this phenomenon.
ERIK BAIS: Yes. So if we would actually find some way, if we see there is a need to fix this, the amount of time to actually fix it, four, five, six months, to do new policy, by that time probably the problem fixed itself as well.
NIKOLAS PEDIADITIS: Could be.
ERIK BAIS: Without having to increase more difficulties for current members to actually get v6. On the larger allocations, the question is, it feels a bit like a disbalance for the amount of documentation that I need to provide. But on the other hand, we may also not want to make that too easy in order to make this problem bigger.
NIKOLAS PEDIADITIS: Yes.
ERIK BAIS: So. How does the room feel?
RANDY BUSH: IIJ and Arrcus. I am very confused about all that because I don't understand the physics underneath it, I don't understand what the motivations and expected results are of the actors, but I'd like to separate that from what is, to me, the core issue for us as a community, which is the accuracy of the database. Okay. And I think that has to be our first principle. And, beyond that, you know, if I put on an IPv6 bigot hat, stockpiling IPv6 is like stockpiling air, that is, you know, we haven't come to where we are going to worry about that yet.
NIKOLAS PEDIADITIS: Thank you for mentioning this. And yes, I totally agree, and that was the main point, that the reason we went to present this to you, to decide if it's an issue, was not really about usage or wasting IPv6; indeed it was with a focus on the registry, so does it affect the registry, does it affect its accuracy, will we have a problem in the future? So yes, indeed.
GERT DORING: I wonder whether we should play the ball to you folks and, if you see something really funky, have a chat, a very friendly and inquiring chat, not like you shouldn't be doing this but just ask them what is it that you do and is there something in policy land that is broken that you feel the need to do things like get a 29 from here and have the 32s be announced by ASNs that are totally unrelated to you. This strikes me as a bit weird. It cannot be a formal mandate of you go to inquirer because we don't know whether it's good or bad or whatever but we are just curious.
JORDI PALET: I ask at the microphone. I agree with what Erik has said, probably when we run out of IPv4, the thing of multiple LIRs can be reduced. But I am wondering, and my question is not just for IPv6 but also for IPv4, if we should actually consider that for having multiple LIRs ‑‑ and I know many people will not agree ‑‑ we should ask for some kind of justification. I mean, to just allow it without any kind of demonstration that there is a real need for an organisation to have multiple accounts, just asking openly, not having an opinion.
The other thing is also regarding IPv6 transfers, should we have a reason or a justification for allowing IPv6 transfers? Again, just open question, not having an opinion right now.
SANDER STEFFANN: Just one small example. I have actually have given a suballocation to a small nonprofit which is running a community network and they are running on a zero budget and didn't have enough money to become an LIR themselves so they have a /32 suballocation from me. So that's one example of how this could occur.
GERT DORING: If that's all documented that sounds like a good plan to me.
SANDER STEFFANN: Of course, in database.
RANDY BUSH: What AS? Sander, from what AS are they announcing it?
SANDER STEFFANN: From their own AS, I don't know what the number is, but not my AS.
RANDY BUSH: Which leads me to what I was going to ask and I am going to put on my researcher hat, is, when you look at the ASs, these, let's call them sub allocations or transfers or whatever you want, all those different flavours come from, how do we say they are unrelated, have we looked at the AS path, maybe they are a customer, so on and so forth?
NIKOLAS PEDIADITIS: No, it's completely ‑‑ we don't say necessarily they are unrelated. They appear on a registration point of view unrelated; that's what we mean. They could be related because an organisation can have presence in two regions, so they can have an AS number there announcing they are here. So it's purely from registration ‑‑
RANDY BUSH: ‑‑ BGP space.
GERT DORING: I have two more comments. One is in response to Jordi. The multiple LIR thing is something that has been heatedly discussed in the members' forum, and the reason why we permit what we do today is, courtesy of the registry, because if somebody really wants to have five LIR accounts, we cannot stop them from opening a UK limited for 5.5 pounds and come with basically worthless registration details. So, the members felt that it was more useful to actually have proper records, proper names on things than try prevent something that is very easily circumvented. So this was a vote and that was a decision, so it was done consciously. Yes, don't do rules that you cannot properly enforce.
JORDI PALET: Maybe just better documentation.
GERT DORING: That was the point. The other thing is that I think there's numerous examples why you have two or three 32s, like we have two 32s because we bought another ISP and they came with a 32. So the 2 ones or 3 don't surprise me. The 52 one is a bit extreme, but it's one.
HANS PETTER HOLEN: RIPE chair. You mentioned something that is close to my heart and that is the border between policy and RIPE NCC rules. So my observation is that the community has made a policy to restrict something, while the RIPE NCC has then made mechanisms to make it easy business‑wise and circumvent that policy set by the community. So I think that's food for thought for the community, how to draw that line and make sure that this is in sync and maybe unify those two processes.
The charging for providing independent, for instance, is another feature of these things. I think as a long‑term goal we should look at complete separation between the policy process and the commercial process of the RIPE NCC and shouldn't mix them. But that is just my sort of flag here. And it's not something that we can fix right here now but it's perhaps more of a long‑term thinking that if we try to use policies to restrict something that's easy to circumvent by using real life legitimate things like dotter companies, how can we shape that policy then?
ERIK BAIS: Anybody else have any comments on Nikolas' presentation? Questions? How are we doing on time.
GERT DORING: Ten minutes past so we still have plenty of time. But we could have an early coffee. You are the operating chair.
ERIK BAIS: In that case, we are going to for coffee.
(Applause)
LIVE CAPTIONING BY AOIFE DOWNES, RPR
DUBLIN, IRELAND
