Address Policy
16 October 2019
11 a.m.:
GERT DORING: Welcome back. This is still Address Policy in here. We are five minutes late but I think people had some difficulties finding the room, so ‑‑
ERIK BAIS: Finding coffee. There was a huge line as well.
GERT DORING: So welcome back. This is what we are going to do in the second lot. First, we have the current policy topics overview from Marco, then we have some feedback from the NCC registration service, from Nikolas, basically all standards, let us know what is going on topics. Then we actually have these two new policy proposals, 2019‑06 about wording clean‑up in the IPv6 policy to make things easier to understand. And we already discussed 2019‑7 so it's ‑‑ it belongs here in the agenda but we already did that. And then we have the open policy hour and AOB in case we have time and you have something on your mind that you want to bring up.
With that, I hand over this stage to Marco. Thanks for being here and doing this, bring us up on current developments. The stage is yours.
ERIK BAIS: I have heard that there is an actual policy hidden in the presentation from Marco.
MARCO SCHMIDT: Yes, and I will come to that.
ERIK BAIS: Interesting.
MARCO SCHMIDT: Good morning everybody from myself, welcome to the second session of the Address Policy. Normally, my slot is in the first session, in the early morning where usually the room is a bit more empty, but this morning we had a very interesting panel discussion for the first time aye hope most of you were able to see it. And I am actually looking forward to have more of this in this Working Group. But for now, it is my turn, I would like to present this presentation that I do at every RIPE meeting, about the current policy topics.
So I usually ‑‑ well, always I start with a little overview what's going on or what has happened in our regions since the last RIPE meeting, then I make a big ‑‑ a little bit bigger view on the world, what is discussed in the other four regions, in the other four communities and I am closing with PDO updates, which are Policy Development Office update, and it will be a bit different today, I can tell you already.
But first off, what has happened since Reykjavik, what is going on, which proposals we have under discussion and which have been finished in the last few months.
We have currently three proposals in the initial discussion phase. The first one is 2019‑04, the validation of the abuse mailbox. This proposal is not discussed in this Working Group, it's discussed in the Anti‑Abuse Working Group, so if you want to participate tomorrow at 9 o'clock, same room, if I remember correctly, this is the place to be. Just a bit of background. The RIPE NCC is right now already validating the abuse conduct information on the RIPE database and this proposal suggests to intensify this validation.
About the other two proposals I will not say much because 2019‑06 will be just presented later in this session and 2019‑07 was actually presented in the first session, about adjusting the assignment size for IXPs.
One proposal is in last call, right now. Also, this one is not discussed here in the Address Policy Working Group, because it's routing‑related, it's in the Routing Working Group. And it's ‑‑ it has quite a mouthful of policy title, it's the RIPE NCC IRR database non‑authoritative route object clean‑up. I managed. And it's basically, you know, in the ‑‑ in the RIPE IRR database we have route objects for resources that are not handed out by the RIPE NCC and until recently it was possible to create such route objects by anybody basically, so there was no verification who did it, and this has now been stopped, but still, there is quite some information in there that nobody can really verify if it's correct or not and this proposal actually suggested if there exists a ROA by the authorised resource holder, wherever he is in the world, that is in conflict with these objects in these non‑authoritative database, then these objects will be deleted.
Three proposals actually finished, the PDP cycle in the last few months, two of them successfully, they have been accepted. First one 1907 the IPv4 waiting list implementation, if you have been at the panel it was touched upon, we have now a policy, a clear policy that defines that there is a first‑come first‑served waiting list, and if you are on this waiting list you will get a /24 allocation. If one is available. And you have never received an IPv4 allocation before from the RIPE NCC.
Second one also was discussed here in Address Policy group, the revised IPv4 assignment policy for IXPs. Basically, this extended to safeguard IXPs for the foreseeable feature, for the next 10 or 15 years and made some adjustments, some fine‑tuning on the assignment criterias there.
One proposal has been withdrawn recently, it was discussed in the Anti‑Abuse Working Group, it was quite heavily discussed, there was a lot of intense talk going on about it. It's the resource hijacking of is a RIPE policy violation. Originally called BGP hijacking and after the review phase was closing to its end the proposers decided to withdraw this proposal as it was unlikely that consensus could be achieved.
That was the brief overview of our region, so now let's have a look what is going on elsewhere in the world, and that's right now a little graph of open policy proposals in the other four regions. So you see except of APNIC there is quite some discussion going on. I will not go in detail of each and all of them, because many of them are very specific, very detailed and maybe not that relevant for the RIPE community, but I picked a couple of interesting policies proposals that you might find interesting.
First off, IPv4 and I feel now a little bit ashamed I mention run‑out there because as Remco pointed out earlier we have a run‑out run‑out run‑out, but at least I had some before that say run‑out and beyond. There actually two proposals in ARIN that are quite interesting, because while it was earlier said that ARIN had a cold run‑out so there was no soft landing policy, they actually have a section, 4.10, in their policy manual that has set aside a /10 IPv4 of which ARIN members can get a small block of IPv4 if they can document that it's for IPv6 deployment. So they can get up from a /28, so very tiny, up to a /24, if it helps their IPv6 plans.
The first proposal actually suggests now to get rid of these very tiny blocks because it's considered as not really usable so to change it to minimum allocation size from that pool to a /24, and even members of ARIN can come back every six months if they need more IPv4 for their v6 deployment in order to, up to a maximum of /21 in total.
This one is recommended draft policy in ARIN, so it is likely or it's possible that it will reach consensus soon, maybe at the next ARIN meeting.
The other one, 2019‑17, the returned addresses to that specific pool, the 4.10, you probably know that ARIN run out except that have pool of IPv4 in the 2015 if I remember correctly and since then they have a waiting list, and different to our waiting list where there will be just an allocation address of of /24, in ARIN there was not really a size limitation. If you could justify a need of a /16 and a /16 was returned to ARIN, you actually could get such a block. However, it has ‑‑ it has been found out that there was quite some malicious activity so people managed unfortunately to set up information that are not true just to get large address blocks to put in later them on the transfer market as soon as it was possible, that is why the waiting list is, if I am not miss taken is frozen right now and this proposal suggests to not allow new entries to that waiting list to finish the existing people that are on the waiting list, finish them off until they got their space but then any further address space of IPv4 that goes back to ARIN will be added to this specific pool and it will be only handed out to ARIN members that can document that it's for IPv6 deployment needed.
Another one related to soft landing is in AFRINIC, there was an update, it has been already ratified and AFRINIC is implementing it, so basically also make the requirements and to make the address space that can be handed out a bit more tight, to delay the full exhaustion of the AFRINIC pool.
Transfers, of course, very big topic still all around, as we also just saw the panel.
LACNIC has a proposal that has reached consensus and is already ratified, it's called IPv4 resource transfer policy comprehensive, and it's made not obvious from the name but the most interesting part for our region is that it includes an Inter‑RIR transfer policy of IPv4. Because at this stage, Inter‑RIR transfers are possible between three regions which is the RIPE region, ARIN and APNIC, and LACNIC is still busy implementing that policy change, it probably will be done next year, and once the implementation is finished, also LACNIC will join the club of Inter‑RIR transfers.
Then, there are a couple of proposals, I will bring them up all together in three regions, ARIN, APNIC and LACNIC. Opposite to the RIPE region where IPv6 transfers are possible, they are not allowed yet in the other regions. However, there might be the situation that an organisation takes over a different organisation but they are based in two different service regions, and they might want to even move then the networks to another service region as part of this merge and acquisition, and currently, especially for IPv6, this is not really covered and these proposals try address that situation that if there is such merge and acquisition, that crossing borders of service regions that all the resources can be moved around.
And last but not least, AFRINIC is of the five regions, the last area that has not an Inter‑RIR transfer policy yet. However, there are two proposals under discussion by the AFRINIC community, and they both will come up next month in Angola at the next AFRINIC meeting and maybe they will reach consensus and then also AFRINIC will join the club of Inter‑RIR transfers of IPv4.
Anti‑abuse, also a topic you saw we have a proposal on that one, and a similar proposals are or were out there in the other four regions as well, so basically to validate abuse contact information in the databases and they have taken quite different developments. In AFRINIC and in LACNIC they are still under discussion. They represent add couple of times and couldn't reach consensus at this stage and get adjusted. In APNIC, it has been already accepted and implemented a while ago and in ARIN the proposal has been abandoned.
LACNIC had a similar hijacking proposal like our community had and also it has been abandoned a few weeks ago, by the end of September.
But the proposal is still out there, or similar proposal, to consider resource hijacking, to consider BGP hijacking as a policy violation, at the AFRINIC region, and also it will be discussed next month.
And then there is the last proposal that I want to mention is actually quite interesting one, it has reached consensus at the last APNIC meeting in Thailand, one month ago, and it's called RPKI ROAs for unallocated and unassigned APNIC address space. And the idea is basically that all the address space is managed or is in the pools of APNIC, that they are creating their own ROA, their own certificate for it, to basically make it more difficult that these ununallocated or unassigned address space is announced by not authorised people because if there is a ROA it makes it a bit more difficult and I mention it specifically here because the proposal of this policy proposal mentions he plans to do it as global policy proposal, maybe not exactly as a formal one, but to at least introduce the same idea in the other four regions so eventually sooner or later it will be up for the RIPE community to discuss such policy change.
That ‑‑ I see Erik.
ERIK BAIS: Can you go back to twolides.
MARCO SCHMIDT: Transfers.
ERIK BAIS: Yes. Specifically on the LACNIC proposal. Currently between ARIN, RIPE, RIPE, APNIC, there is a needs assessment for Inter‑RIR transfers. How is that implemented in the policy which is currently under consensus for LACNIC, between RIPE and LACNIC, for instance?
MARCO SCHMIDT: I have to admit I am not 100 percent sure but I see somebody raising his hand and I think he can address this better.
JORDI PALET MARTINEZ: I am the author of that policy proposal. The policy proposal has reached consensus. LACNIC presented the difficulty the implementation in the last meeting last week in Panama. They said they believe it will be finally implemented by July next year and it's totally symmetric to what we have in April, and APNIC I did propose to make sure we can do without any problems those transfers, I think that answers your question?
ERIK BAIS: Yes, it does.
JORDI PALET MARTINEZ: Just a clarification. We have not abandoned the BGP hijacking policy. The problem is that the LACNIC system don't allow the website to say standby. That's just a clarification. And the anti‑abuse tomorrow is not here, it's in the other room, I double‑checked it just in case.
MARCO SCHMIDT: That's lot, Jordi.
CHRIS WOODFIELD: ARIN Advisory Council. Can we go back to the slide about the ARIN wait list policy that you mentioned. Return addresses ‑‑ okay. Just to give some more information about what happened in the ARIN wait list. The allocations from the wait list are no longer suspended, ARIN is now allocating resources, reclaimed resources to wait list members. There were some policy changes made to the ARIN N rpm through the emergency PDP process, dramatically changing the rules and the size of allocations, I think it's ‑ only get a /22, you can't apply if you are already have a /20 or greater, and ‑‑ and I think you have to wait five years now before you can transfer anything received under the wait list. That said, that language change was done under ARIN's emergency PDP process. We are continuing to propose, tweak and try to make for more sensible policy through the regular PDP. So that's the current situation today in the ARIN region.
MARCO SCHMIDT: Thanks a lot for the summary, because yes, there were a lot of activity in the ARIN community. So I decided to focus on the latest developments, but thanks a lot.
Mr. Wood field: The entity that was discovered to be man inlaying the policy actually has been indicted by the US Department of Justice for that activity.
MARCO SCHMIDT: If there are no more questions on those external policies ‑‑ then I quickly go from animated ones and I come to the PDO update and usually I am giving you some statistics, some numbers what is going on but sometimes it's a bit different because there is a policy proposal you have probably not heard about it because it was not circulated on public mailing lists. It's called policy development office changes. And the summary is that the policy officer has been doing his this job for six years. It's time for a change ‑ both for him and for the policy development office.
I looked a bit back in history, I found this picture five years ago of me and you will see time hasn't been kind to me. As it was a proposal, there were some supporting arguments, the new policy officer has a solid understanding of the RIPE community and the PDP, two years as a trainer, I will ton serve the community as assistant manager of registration services and policy development office, so I extend my job title name a bit. And there are also some opposing arguments so the community might miss the previous officer but there is a counter‑argument, there is no evidence that this is true. So let's see.
So, I can till the proposal has already been accepted without community involvement, I apologise for that. And it's Petri who will follow Marco as policy officer. He definitely has some PDP credibility and he is also here in the room, if you just could give a little warm welcome.
(Applause)
So ‑‑
JORDI PALET MARTINEZ: You may receive an appeal.
MARCO SCHMIDT: I am sorry, in that internal process it's not possible, sorry. And at this stage actually, I just want to thank you all, it was a pleasure to serve you for six years and I still will be around but it was great time and thank you very much for this.
(Applause)
RANDY BUSH: Thank you, Marco.
GERT DORING: I am not sure the process was followed correctly. There was lack of transparency and there was too many smoke‑filled rooms here. I might want to appeal, we definitely will miss you. That said, thanks a lot for all the time and effort you have spent on this and for the really, really great work helping us do the necessary whatever it was needed to be be done, so thanks a lot.
And Randy ran away.
RANDY BUSH: I just wanted to thank Marco.
MARCO SCHMIDT: And I just have some usual slides, I don't have to look at them, if you need any links of the information I gave you just download my presentation and if there are any other questions, this will be my last presentation as a policy officer so if there is something unanswered, now is your chance. Else, ask Petrit.
ERIK BAIS: Thank you very much for all the work. Thanks.
(Applause)
GERT DORING: So that said, we now come to Nikolas, who will give us an update on the view from NCC RS and what is happening in policy land and the effect on you, basically.
NIKOLAS PEDIADITIS: I only have three minutes? Hi. I am part of the registration services team at the RIPE NCC. This session, in this session normally we give you an update about what is happening in the registration services. Things that we observe and we think will be of interest to you, issues that we want to raise and ask your opinion this time around the expectation is we will focus on IPv4 run‑out and the waiting list, what is happening, what we have been doing, how we have been preparing for it and what the current status is. So that's what we will be doing and we will focus a lot on that.
In contrast to other updates we gave in the past, I will mention some operational parts, because we feel it's quite important to give you a clear picture of where we stand and how we have been preparing to handle this situation.
So, let's pick it up from where we left it in Iceland, during RIPE 78. If you were there and if you have a strong memory, maybe you remember that we were asking ourselves the question: Will we make it to Rotterdam with IPv4? And the numbers at the time were pointing to February 2020 as the run‑out date, because we are looking at the trends, at the consumption rate at the time but we didn't really believe these numbers because we could see the trend was really rising and our estimation back then was that we might make it to Rotterdam, maybe not, but most probably we will still have a bit of IPv4 until the RIPE meeting in Rotterdam. And yeah, that's what's happened. We have bits and pieces left, and for the very last time, we can take a look at this photograph and then we can really put it to rest because it's not going to be useful any more. As you can see scratching the bottom of the barrel, there is not much left. And with that, we can go into what the current status is. On 2nd October, about a week ago, we allocated the last contiguous /22 we had in our pools, no more /22s. As that have moment, we are issuing equivalents of /22, so we combine /23s, /24s, to make up a /22. And once we can in longer allocate the equivalent of a /22, we will announce that we have reached run‑out. I will keep repeating the term run‑out for Remco because he does like the term.
GERT DORING: He is in the other room.
NIKOLAS PEDIADITIS: That is too bad; he will see the recording later.
The question you are most probably asking: When will we actually run out. I have decided to give you all the myths at the beginning of the presentation so then we can relax and pay a bit more attention. When will we run out? Right now, we have 751 /22 equivalents left in our pool, and actually, the number is wrong, that was the count last night. I checked this morning and it was already 740, because my colleagues went in the office and started allocating again. And if you look at the consumption rate, the last few months, you can see that in June the number was 484, then it picked up in July into crazy numbers and remained steady through August and September, so for the last let's say, three months, we allocate more than 700 per month.
Based on that, when will rerun out? We did a final estimation, it's not written in stone, but according to what we see, our best guess is the third week of November. Now, plus or minus one week. It can be plus or minus two weeks, we don't know for sure, things change, don't forgive we still have existing members that can always request their final allocation, our best guess right now is that approximately around the third week of November, a bit before, a bit after, we will completely exhaust our pools.
So what happens then? Then, we have the waiting list. This community reacted and this Working Group reacted the last months, the last couple of years, and two policies will be put in place. One was the 2019‑O2 IPv4 waiting list implementation which basically established waiting list and it reduced the allocation size from /22 to /24. The policy was accepted on the 30th July, last July and we announced, the RIPE NCC announced it as implemented on 19th of September and there was a second policy proposal that was initiated basically during RIPE 78 for revised POU assignment policy for IXPs. That one was accepted on 10th of October we immediately start implementation, we have been preparing for it, and already the pool management part of that has been implemented. The 1850.0.0./16 and any fragments smaller than /24 has been put and to fully say we fully implement because we need to update our systems and proceed use, we need until total, two months.
Now, this is the time‑line we created, some time ago, and I thought it was useful to show you in order for you to get a better understanding of what exactly is happening, what we have been doing and how did we implement this waiting list. Because we could foresee we were going to run out, we could see it well in advance, and we noticed that we really need to prepare, there is a lot of work to be done, and we had a lot of variables, there were policies being discussed, we didn't know how those policies would go and we created a plan long ago and we were adjusting as we were going along, along based on how the policy discussions were going. But we have ‑‑ we had really big variable unknown factor that was the date that we will actually run out, so it could not prolong things. That was deadline that was coming closer to us. So already since last January we started preparing. We had created an expected time frame and this is basically the updated version, now that we know more facts with milestones, RIPE 78, RIPE 79 and the actual run‑out date.
There were policies being discussed, it's the two ones I just mentioned, and you can see where they were being actually accepted and implemented, and something that we really paid attention and it was really, really important to us was the communication part. And we realised early enough it is important that we communicate well with our community well in advance so people don't get confused and panicked and know what is happening and when. And for that reason, we take several actions, we updated ripe.net and placed banners on the LIR Portal so members when they tried to apply to become members they already see warnings about the fact that, depending on when they will finish their application, they might end up in a waiting list when send in an IPv4 request. We were sending announcements as we were going along, following the milestones, already in August we inform the community that we are approaching the end. A few weeks ago we informed the community again that we don't have any /22s left and we also informed the community about the fact we have a big queue of LIRs waiting to be activated and basically our IPv4 blocks or /22s equivalents are less than that queue. We had to go through multiple software changes and updates, a lot of documents, legal external/internal, had to be updated. You will get a better overview of that later on in a presentation when he is going to go more into operations and the impact all of this will have for the RIPE NCC.
So we have a waiting list. How is it going to work? The waiting list will become active once we can no longer allocate the equivalent of a /22. It's on a first‑come/first‑served basis as it was already, the allocation system that we are following. And we kept the current process that we have for IPv4 requests the same, and the ‑‑ the main reason for that, was to ensure fairness. We have existing members, we have new members applying to become members, we want to make sure that the system remains fair and first‑come/first‑served is preserved for all of them. The allocation size will be reduced from a /22 to /24, and only LIRs that have never received will go on waiting list for /24. That does not include LIRs that have space, merge and acquisition or if it's legacy space for example. This is only for LIRs at some point received an allocation from the RIPE NCC.
We are going to make this as transparent as possible, so we will publish on ripe.net the size of the list and we will also publish for how long is the next person in line waiting to get a /24. And we will make the placement number visible for every LIR in the LIR Portal so everyone would know what is their placement in the list at all times.
So what can we expect? As, you know, the RIPE NCC will keep recovering IP space. In the beginning, we expect things will be better and as we go along we expect we will recover less and less. But right now we have quite a bit coming back for the next few months, and what we do when we recover IP space we put it in quarantine and after a few months the common practice, unless there are other reasons, the common practice is six months, we put it in quarantine and then we reissue it to members.
So, you can see for the next six months what is the expectation of IP space that we have in our pools in quarantine and expected to go out of quarantine. Between October and November, it's not much, but depending on when we will actually reach the last slash equivalent, but we don't know if that's going to go in the waiting list or not. As of December it's a bit more secure. So based on the numbers, we expect we will be able to distribute more than 1,300 /24s in the coming five to six months. That is the expectation. So, hopefully we will be able to accommodate at least for the first batch of LIRs that will be on the waiting list, most of them if not all of them.
So where do we stand today, we are ready. The waiting list has been implemented. Our systems have been updated. So if we run out tomorrow we are good to go. We are trying to keep the community informed as much as possible. We go, apart from the RIPE meetings, we present about this in the regional meetings in member lunches, we are sending mails, we send certifications and so far we are happy to say that we have good feedback, people are informed so we don't see any complaints or big panic about that.
Something important to note is that IPv4 requests that will come from now into the future from LIRs, it is highly possible that will end up in the waiting list. So if somebody sends a request today or if somebody is trying to become a member by the time that the membership application will be finished and the LIR will be activated and send an IPv4 request most probably we can tell you that will end up in the waiting list.
GERT DORING: I have a question on that. Is that made very clear to the people when they submit an application, that they might not get their 22?
NIKOLAS PEDIADITIS: Yes.
GERT DORING: If they come with the expectation that the run‑out hasn't run out yet and you tell them in two months' time oh, no, you don't get anything, there will be panic and bad mouthing and bad press and everything. You should be very clear.
NIKOLAS PEDIADITIS: Thanks for asking, it gives me the opportunity to clarify. We have been doing that for several months, actually our customer services department is working a lot on that. And we are doing that through multiple ways. So when a member and where it ‑‑ implemented that back in August, that we saw reaching the point where people are submitting applications massively, in massive numbers, so already back then we placed banners on the ‑‑ during the membership application process, so if you tried to become a member the first thing you see is a banner that tells you your time to become a member, bear in mind because of the queue of the workload, you will have to wait, you might end up in a waiting list, we cannot guarantee you are going to get /24s. In addition, a disclaimer has been added so people have to tick that they understand that this is the case and they still want to proceed. And just to make sure we covered everybody, our customer service department e‑mailed all the LIRs that had already applied up to that moment to become members, to ask them ‑‑ to inform them about the status of our pools and to ask them if they still want to continue with their application process. So it's something we really pay attention to, yes.
RANDY BUSH: Arrcus and IIJ. Concerning IPv4 run‑out has occupied 50% of our bandwidth for the last 20 years, how could they miss it? When address space is in quarantine, have you considered doing quality tests, i.e. on blacklist etc., etc.? And I can understand especially with the increase in the number of lawyers in the NCC that you don't want to put a stamp on the address space but you might delay lower quality address space and kind of sort by quality.
NIKOLAS PEDIADITIS: It's not something we do by default as a standard, because as you already mentioned, we cannot put a stamp on it. It's something that we do on ad hoc basis and it's something that we are currently considering to see if we can propose to provide this as a service for our members. Indeed, when we see that IP space can be dirty and you might have heard in the past few months that a lot of IP blocks were deregistered from cases that were not that, let's say, clean, we do have our eyes on it and we know when this IP space will be redistributed to knew LIRs or existing ones, they will have a problem with it. So we are in contact with them and doing everything we can to help. If we have to communicate with third parties and ask what the process is, yes.
So, that was it about the present time. But maybe this is a good opportunity to do a bit of a time travel and see how did we really are end up here, what happened since the beginning of time for the RIPE NCC, since we started allocating and how did we end up with basically a waiting list.
In this graph you can see the historical distribution of IP addresses from the RIPE NCC, from the beginning of time until today, and you can see that it was picking up slowly, but then Internet starting evolving, then we had the big boom and the main ‑‑ the most ‑‑ the biggest allocations we gave were between the years 2005 and 2011 and most specifically 2005 and 2007, those were the years where major ISPs got big blocks, it was years we issued multiple /10s and you can see a very definite point in time, that was 2012, there, where everything went down because we still had started allocating /22s and from there onwards it was pretty steady.
And if we compare allocations and PI assignments we see a big difference. The graph showing the IPv4 allocations we issued over time is pretty similar to what you saw before because they consist of vast majority of IPv4 addresses we handed out. It's interesting to see the difference with the PI assignments because some of them in the early years is what we ended up calling PI assignments but back then they were not called PI assignments, the people that are much longer than me around, you remember how it used to be back then, last resort registries and all that, so PI assignments more steady growth but smaller numbers, that lasted to 2012 but after 2012 not possible any more.
Some interesting fact we noticed looking back in time. In total the RIPE NCC has distributed approximately 650 million IP addresses, that's 38 .7/9s. The biggest IPv4 allocation we ever hand out was a/9 in 2006, and I am not revealing any secrets, it's public information, that was France Telecom. And we also issued 10 /10 allocations to major ISPs from 2011 to ‑‑ 2004 to 2011. If you think with your minds the biggest ISPs you know in Europe, those are the ones that got the /10s. And it's interesting there was a specific moment in time, that was 2012, and now we relate a bit with the panel that was earlier, and that was being discussed, that specific ‑‑ that significant times of the 15th September 2012 where the last /8 policy was activated and it's interesting to see within 2012, up to that point, we issued around 40 IP addresses and from that point onwards 997,000 IP addresses.
Speaking of 2012, there are some interesting facts that maybe we can pay attention to and I think now maybe we will answer some questions that were asked in the previous session, maybe you were asking for some numbers. So what happened since 2012:
In terms of IPv4 allocations, this is what happened. We started with 807 in 2012, steady growth between 2015 and 2017 the numbers were pretty much the same, around 3 .5 thousand allocations, and then panic started in 2018, 2019, multiple LIRs phenomenon and so on. So the numbers went really up.
What happened with IPv4 transfers since 2012? The first transfer took place in October 2012. That's the first transfer we ever did. There was a policy in place before that time but because we had plenty of IPv4 to distribute and we could still give big blocks, there was no need for it. In September 2012, we had the new policy with a final /8 so in October 2012 we had the first transfer.
In total, in terms of IPv4 allocations, we have processed the transfers of 10,000, almost a 1700 original IP blocks because it's possible for someone to cut an IP block in pieces and transfer two pieces of one IP block. For us that's one IP block that some piece of it is being transferred so that's one IP block.
In terms of IPv4 assignments 2,500 and the total IP blocks that have been transferred since 2012 are a bit above 13,000.
Interesting point, we have already completed Inter‑RIR transfers for 5 IP blocks from the final /8. And specifically from 185 /8 so 55 of those have been already with APNIC and ARIN.
And maybe that is a small introduction to the next topic, because this is something that we would like to raise with you, would like to see how you feel about it. And ask if we should continue doing what we are doing or if you would like us to do more. So we would like to discuss a bit the topic of out of region use and out of region LIRs.
Why are we raising this now? We took a look at the numbers. You can see in the matrix from 1995 until today, how many LIRs we have based out of region, and as you can see in the beginning there were not that many, they increased a bit until 2004, and primarily the reason for that was that, back then, AFRINIC was not established so we had a lot of members from the AFRINIC region. Then 2005, AFRINIC was established and the numbers went down. We didn't really have many out of region LIRs. And then the numbers started picking up again 2011, 2012, when the policy changed, maybe it was a coincidence, but it was a time when we could not gave big IP blocks any more. And as of 2015, we see a big increase in numbers, especially as of 2016. Again, it could be coincidence, it could be not, but something significant happened in 2015 is that ARIN ran out of IPv4. And what we observed is that really the last two years we have a big numbers, we have big numbers rising for ‑‑ out of region LIRs, you can see that in 2018 it's 433, in 2019 it's 466.
RANDY BUSH: When Africa was part of the NCC region, they shouldn't be counted as out of region.
NIKOLAS PEDIADITIS: Indeed.
RANDY BUSH: Just picking a small nit.
NIKOLAS PEDIADITIS: We don't count them today out of region. Historically how many LIRs we had with reg /*EUDZ pointing to areas outside of service region.
RANDY BUSH: But they were in the service region.
NIKOLAS PEDIADITIS: Indeed.
ERIK BAIS: Do we still have a lot of new registries or LIRs registering from, you know, the Seychelles or other tax haven countries which actually make it harder to distinguish which person is actually behind those corporations? Because that is probably a bigger misuse than having a US entity that also has network in the Europe service region.
NIKOLAS PEDIADITIS: Yes.
ERIK BAIS: So did you have ‑‑
NIKOLAS PEDIADITIS: We still receive applications. We have threat ‑‑ do due diligence checks as much as possible. We are stricter, and we proceed if we can verify. It's difficult, it's tricky, we are trying to balance between ‑‑ because there are legitimate cases as well so we are trying to balance things and keep it reasonable but we are much stricter and we apply due diligence checks as much as possible. But yeah, they still apply. It's not only for those ‑‑ from those regions, though. We have a lot of applications from US, we have a lot of resource requests, not necessarily to become members but also as end users, with sponsoring LIRs from China, from Hong Kong, we have a big increase from those territories and from those countries we can go to the original registries and see if somebody is indeed CEO, if a company is registered, not all of them but for some of them we can. Yes.
So that's in regard to out of region LIRs. I am getting into the out of region use, the thing is that there is not ‑‑ we don't have a specific document that explicitly says what out of region use is and how it should be handled in our region. I think it's commonly accepted that the RIRs, all the RIRs operate within specific geographic region and in multiple places in our policies, this is being referenced. I just grabbed two examples from IPv4 policy and IPv6. It's referenced in many places in those documents, where it is understood that the primary roles of the LIRs is to distribute Internet number resources within their respective regions. And they operate within their respective regions. This is the sentence that is being repeated.
So what do we now as current practice, how have we interpreted this over the years. We understand that networks can be global, we understand that one can have the need to announce part of an IP block in another region, one can have an AS number and one to announce multiple IP blocks because it's app global network. That's common sense.
However, we do require when we issue resources that the requester has at least one active network element within our service region, and we also require that the resources that we will hand out will be at least partially used within our region so if we get an IP block from the RIPE NCC at least part of it should be used within our service region. If you get a /22 IPv6 block for example and you solely want to use it in ARIN then most probably you should go to ARIN IPv6 block and get that and not from the RIPE NCC. However, we don't have a rule that says that legal presence in our region is mandatory. I will talk about the other RIRs in a bit, because that's not the case, but in our region we don't have this as a strong requirement.
So let's look a bit at the numbers and let's see what the numbers are and then based on that you can decide if it is an issue at all or not.
Currently, we have 1246 LIRs out of region and these are holding almost 2000 IPv4 allocations and 768 IPv6 allocations. Then we looked a bit at the announcements to see, okay, how these IP blocks that we handed out, how are they being used; are they being used Air at least partially outside of the region or ‑‑ what we did was to take a look at IP blocks that are being announced by ASNs only, by ASNs, not managed by the RIPE NCC, I mean they are not our registry, they are in the registry of another RIR. So in terms of IPv4 allocations, that's 1,819, IP assignments 238, the interesting thing is that, and that's why we are bringing this up, this trend continues with IPv6 N terms of IPv6 allocations it's similar to IPv4 allocations, it's almost 1,000, 13 IPv6 PI assignments and we notice that 971 AS numbers are appearing only with AS numbers and not managed by the RIPE NCC. So these are the numbers.
What are the other RIRs cog? Most of them you can see the overview, most of them are requesting a network or an organisation to have either legal presence or a network in the region. In most cases, both.
What we have observed is that we ‑‑ that is really growing trend. The numbers are increasing fast. When we issue IP blocks and then sometimes later we see that this IP block is has solely been announced outside of our region, that member, to get that IP block, has confirmed to us that they have an active network element in our region and during our due diligence checks we are trying catch as much as possible the ones that lie, so we ask, we see fake invoices and things like that. But it is a tricky system and we don't have any means of really, really checking what is happening in the networks and we don't have the mandate to do so.
So the question is, is this okay? Is there some RIR shopping happening? Is it because of, maybe people from the audience have an opinion about it. Is people going to different RIRs based on prices, based on whether they want to hide or not. It's concerns that we have, it's ideas we get by looking at the numbers but it's not like we can make a definite decision about it. And do you want us to take action? Are we doing enough, do you want us to be more strict and take action on this issue?
So if you have any questions, I will be happy to answer. If not, we can go into the discussion topics, which basically is IPv4 run‑out, which was actually discussed in the panel session, but maybe you would like to brainstorm here about the way moving forward and lessons learned from the IPv4 era and things we should not repeat with IPv6, and mainly tell us what do you think about the out of region use.
GERT DORING: Let's do this quickly because we are running into Jordi's policy proposal time.
ERIK BAIS: I have a quick question about the due diligence that you are to go, a couple of slides back you stated there have been incidents where specifically the active network elements tick box was checked and that has already led to termination of membership and sponsorships. Was that during the ARCs or was it on informal investigations or information provided to the NCC you might want to have a look here, and then the NCC started investigating that?
NIKOLAS PEDIADITIS: It was in both. In most cases that happened during their IPv4 application request or their IPv6 application, their IPv6 request. Because they have confirmed during their membership application possess that they have an active network element so when it comes to it, if we see they are out of region we ask can you explain to us where you have this active network element and a surprising number of people toned lie about it because they don't, they fabricate invoices with data centres, other documents they submit them to us, we check and realise they are fake so terminate membership.
JORDI PALET MARTINEZ: I am not a member of RIPE or any other RIR, but I am working with policies in all the five regions ‑‑
NIKOLAS PEDIADITIS: We have noticed.
JORDI PALET MARTINEZ: I have the feeling that RIPE is the most flexible and cheap one and that sometimes means easier to cheat as well. I don't really have a strong opinion on that but I think we are too easy.
NIKOLAS PEDIADITIS: It's kind of the feedback we want to get from the community and from our members, in this case how strict they want us to be, and how they would like us to approach this matter, if maybe we change nothing, maybe we do change something, but Jordi, to answer your question, with those situations you lose something and win something, so this community has given us a specific direction and we are following it and, yeah, it's a balance.
ERIK BAIS: Is that something that we need to discuss in the GM or here?
NIKOLAS PEDIADITIS: I think it will be a nice topic for the GM actually. I think it's something that concerns their members. At the end of the day, the members are paying the bill for this also, so it might be a good topic for it.
RANDY BUSH: Arrcus and IIJ, again a minor, very small thing is, due to insane repressive ARIN policies and their massive legacy space there are transfers occurring from ARIN to RIPE because, for instance, you can get a certificate for legacy space here, so those generate out of region announcements but I think it's not something we want to discourage.
NIKOLAS PEDIADITIS: Yes, absolutely.
RANDY BUSH: Refugees do not a home.
NIKOLAS PEDIADITIS: Yes, and that is why the basis of this we recognise this is a valid case and indeed networks are global, so we are not saying by any means that there is a problem with all out of of region LIRs. We see spike and rise in trend, we wanted to mention it, we see more and more people trying to game the system, that is the truth and we want to see if you want us to do something more.
GERT DORING: I think it will be interesting to watch this space, as soon as we have had 100 I couldn't tell run‑out run‑out and we have no v4 to give the people any more, we might be more loose on the v6 policy, maybe not. The big intensive is there are v4 for grabs will be gone. Let's see what happens. But we could certainly bring the questions, if you feel you need more answers, maybe bring it to the list and see if we have more voices, but I agree with Randy that having the option is good. We should combat abuse which is what you are doing but you cannot catch everything. Somebody who is good at lying will go unnoticed for a while. Eventually you will get them.
NIKOLAS PEDIADITIS: And the main question for us and maybe this is something you can discuss at the GM, is, okay we hand out an IP blocks let's say it's IPv6, forget IPv4, and after a month we see that it's not being used in our region at all, should we do something about it or should we just let it be? That is a common question that we have, because it's really difficult to go into the step further of reclaiming an IP block because somebody can just announce it, start announcing it. So it's not something that we can can or want to do so far but we want to know if that's okay with the community as well if we are doing the right thing or should do something different. So that's something, not necessarily to discuss here but maybe in the mailing list or GM or both and it would be a direction for us would be welcome.
GERT DORING: Yes.
NIKOLAS PEDIADITIS: Thank you.
(Applause)
GERT DORING: We have one more policy proposal to discuss now, this is from Jordi, on basically cleaning up language and removing historic baggage from the IPv6 policy ‑‑
JORDI PALET MARTINEZ: I can start without the slides. I already commented briefly about this idea on the last meeting in Reykjavik, I observed there is some text in the actual policy that mention talking about things like lack of experience, potential new changes, come on, we have experience now in IPv6, policies are are to be amended when news so we don't need to have a potential new changes wording. There was also a text which we had in most of the regions and I already changed that in I think all the regions but RIPE regarding that shorter prefixes and /48 should be approved by the ‑‑ by RIPE in this case, then other changes I am proposing is small mention to the RIPE BCOP for the people to be able to link our policy which are best current operational practices and reviewing some generic wording. So, I think it's just ‑‑ just in case some of you have not read that, the small letters in the left is the existing text and the big ones, the new text, is not for you to read it but just to point ‑‑ if this works ‑‑ just to point to removing some text here so no need to say we may review this in the future. Then, the mention here to typically you assign to users and a /64s and then mention of the RIPE 69, and then this is probably the major change, it's not really changing too much, it's just say, look, we are adults, we don't need to get NCC, the NCC to review our allocation; if we need or we have a customer that needs a /47 instead of a /48, right? That's the big change. And the rest of the wording is just clarifications and making it simple to read and deleting some text that is not necessary, like, for example, let me remember, basically, this wording is to say if you have provided independent you follow the same rules for the /48 and if you need more you justify. I think that's ‑‑ that's basically it. There was a question in the list ‑‑ well, I think this is some support in the list for this change, I don't think there was any discussion that was against the proposal. I recall a very interesting comment from David Farmer, if I recall correctly, which was saying you are talking about end site, I have not changed that in the actual policy proposal text, but what happens if instead of single customer with a single site is ‑‑ single customer with multiple sites, right? I have some thought about that, and this is the ‑‑ the definition that we have for end site and it's why are they finishing, it comes from previous policy proposals the same in all the regions. APNIC I look at this morning has the same text except something that actually one of my policy proposals changed when we work it on the IPv6 PI policy proposal, we same or associated entities, but we have basically the same text, and my thinking to clarify that question is that it may be the same policy proposal actually, I think it's an easy change and very easy to understand, keep it simple. If we just add to the existing text "location" in every singence I think it makes it very, very clear. I know it's difficult for you now to read again and check. I have to verify this transfer policy this is breaking anything else. I don't think so. So this is probably something we can add to this proposal instead of having another one. Binge that with these small change we are clear that that question, and with that, I think that was my last slide. Somebody can tell me we need to define the end location. I think it's an open concept. I think everybody understands location may be, for example, a single university campus or depending on the decision of the administrator, everybody building need to be considered. We can keep that open. Questions?
Lee Howard: IPv4 global. A question on specifically this text. Those bullet‑points, are those and/or, or?
JORDI PALET MARTINEZ: Good question. I think it's "or," it's not clear. This is the same in all the regions unless some of them have modified that already.
AUDIENCE SPEAKER: Do you want me to ask the question three more times at three other meetings or trust you have this one now?
GERT DORING: Indeed, we had a discussion about does the ISP have to provide transit and there it is again, so we might take the opportunity clarify this better.
JORDI PALET MARTINEZ: Exactly.
GERT DORING: End site has been in the policy forever and there there has never been a definition so it's good thing to tackle this. So, other comments? We have time left, let's make good use of it. Discuss. You are all hungry.
JORDI PALET MARTINEZ: Tomatoes, stones, whatever, fire.
GERT DORING: From what I hear on the mailing list you are on the right track with that.
JORDI PALET MARTINEZ: I skipped one of the slides, this has been changed already in several regions. I think I was also the author of those policy proposals and the last APNIC meeting I did exactly the same changes and yesterday there was an announcement in the list that it reached consensus and is now in the last call or something like that and it's going to be ratified.
GERT DORING: You know my comment on that, we do what is reasonable for us, not what other regions ‑‑
JORDI PALET MARTINEZ: Just a reference.
GERT DORING: Yeah, but thanks anyway. Yes. So, thank you. You have done well with your time.
(Applause)
I have the formal bullet‑point of formal policy hour and AOB which means anything you are coming up with that you didn't know in advance. So is there anything else policy‑related that one of you want to grab a microphone and say a few words about, we have seen these developments in this country and this really shouldn't be.
AUDIENCE SPEAKER: ‑‑ I want to bring up maybe for a while a discussion about PI objects on support, because it's not so clear what policy should we use or what rules should we use to maintain those objects in LIRs. And in past years it was a lot of cases about PI objects and thousand maintain same correctly, what to check, how to do due diligence of the companies. And we have a lot of questions about it, and there are ‑‑ it was a lot of cases when LIRs was not agree with the RIPE NCC or RIPE NCC was not agree with the LIRs. So, we still see here some maybe ‑‑ this is situation is not so clear right now, and ‑‑
GERT DORING: Let me interrupt to clarify, this is about maintenance of the INET num object for PI network in the RIPE database or about contract obligations?
AUDIENCE SPEAKER: The last one. So when an LIR has PI objects on support sponsoring objects.
ERIK BAIS: What is the exact question?
AUDIENCE SPEAKER: How to discuss this with RIPE NCC and to get answers for all common questions and issues that LIR can have with PI objects and maybe it's idea to discuss with LIRs who has a lot of PI objects on support on sponsoring.
GERT DORING: So you want to build a frequency asked questions list that you can put ‑‑ point your end user to so here is all the answers to all the questions you might have. And something like this ‑‑
AUDIENCE SPEAKER: And to have answers from RIPE NCC as well.
GERT DORING: It sounds like a useful exercise. It I am not sure which forum.
NIKOLAS PEDIADITIS: RIPE NCC. For now, what I can say is we are here all week so we are more than happy to meet with anyone and answer all those questions and indeed we can look into a solution into coming up with a Q&A or a sort of document somewhere with common answers to common questions.
GERT DORING: I have had discussions with my own PI sponsorees, so having an easy accessible, what is my obligations what is the role of the LIR here and so on, might help, maybe, maybe not.
RANDY BUSH: Arrcus and IIJ again. With Marco retiring or changing hats, today is the 21st anniversary of one of the early allocator, John Pastel, I wanted to remind us of a little bit of history.
ERIK BAIS: There was actually in the panel discussion, a discussion about the temporary assignments or the temporary transfers. It appears that the reason why the NCC's actually or ‑‑ is doing it the way they are doing it currently is an operational thing, we need to have a check to see if it's an operational procedure that we can change to make it more flexible and if that's desirable, but it's definitely something that we can pursue and provide the information on the mailing list and perhaps in Berlin.
GERT DORING: Sounds like plan. We don't do action items any more but let's do an action item on you to sort this out with the NCC and report back. With that, thanks for being here. Enjoy your lunch and see you in Berlin, then.
(Applause)
LIVE CAPTIONING BY AOIFE DOWNES, RPR
DUBLIN, IRELAND
