.
RIPE 83
.
Address Policy session
.
23 November 2021
.
10:30 a.m. (CET)
JAMES KENNEDY: Good morning, everyone.
LEO VEGODA: Should I put the agenda slide up on the ‑‑ so that everyone can see it?
ERIK BAIS: So, welcome, everybody. Thanks for joining us in Address Policy RIPE 83. It's November 23rd. My name is Erik Bais and I am here with my co‑chairs, Leo and James.
As a warning, the sessions are recorded, and we have pre‑recordings for most of the topics on the agenda. We sent out a couple of e‑mails about this, this will allow us to do some more discussion during the session so you can all watch the content prior. The presentations are also online in the agenda, so, if you haven't seen the full videos, at least there is the presentations during the topics.
We have asked the speakers to provide some insight on just one or two slides, not to recap the whole presentation, so we'll have to topics so that everybody is aware, you know, the takeaways from the actual videos.
So, agenda bashing. We'll have the full agenda here, administrative matter, welcome everybody, thanking the scribe and approving the minutes. We'll do that later on. We'll have the ASO AC report from James, Nurani and Herve, the NRO NC/ASO AC candidate introductions from Ulka, we have the Q&A on the current policy topics with Angela.
Then we'll have an update, which is a new topic in the agenda, an update about the AFRINIC situation by Hans Petter, there is no pre‑recording for that, Hans Petter will do this online. We'll have a Q&A on feedback from the RIPE NCC Registry Services from Marco, and then we'll have the Ripe Database Requirement Task Force, where James will do a short recap, and then we'll have a short break.
And then last but not least, Leo will host the review of the RIPE IPv6 policy goals and anything other that needs to be discussed.
So, any questions about the agenda?
.
Next slide. Did we miss anything? Raise your hands if you have any questions. Okay...
.
Next slide...
.
So, the minutes from RIPE 82, they have been posted online by Leo on June 14th. We have seen no comments or feedback. Did we miss anything or are they good to go as they are? We have heard nothing on the mailing list or in private. I don't see any raised hands. I'm sure you have all read them thoroughly. Then we can declare the minutes from last meeting as approved and we'll proceed.
So, during the session we'll have the stenographers that are typing out the whole session, thanks for that, for doing that work. We have the minutes approved. So we can start with the next part, which is the ASO AC report. We have seen the whole presentation about this online. James, are you taking this one?
JAMES KENNEDY: No, I am going to hand over the honour to Nurani, our outgoing colleague, so, Nurani, are you there?
ERIK BAIS: I haven't seen her online yet. We have Herve online.
HERVE CLEMENT: Even if I don't see any changes during the numbering of the slides, etc. So, that was a record of the presentation of the ICANN ASO AC activities. So recording that the ASO AC is a number resource policy body composed of 15 members, three from each region, and the members of the ASO AC and ISO AC numbers is to advise the ICANN board on Internet matters, to review when ‑‑ so there is a global policy under discussion so to review the global policy development process. One important role is to select ICANN board members, so two specifically for the time and ten, and to select a representative so to ICANN bodies specifically, the nomination committee, and so we record that, so we meet monthly and those meetings are open to everybody except from closed session, when we discuss appointment to the ICANN board.
And so I recall that we are in the process of the seat 10 selection for the ICANN board, and it's possible for everyone who is interested, it's possible to nominate somebody and to be nominated until December 1st, so everybody who is interested to be an ICANN board director, so it's still possible to be nominated, and if you are interested, Nurani, James and I can answer your questions.
So, of course, you can see the pre‑recording presentation of that, a more complete, and if you have any questions, so James, Nurani and I, if she is able to connect, can answer. And the last word I would add is, we warmly thank Nurani for her very useful and excellent job, so she decided not to reappoint. Thank you.
Can you pull up the slide number 8.
HERVE CLEMENT: It's something I tried to do, but ‑‑ so I shared that. Okay. This one.
ERIK BAIS: Yes. So this is the timeline that we're talking about for the board selections, and we grant audio and video for Nurani who is online. Hello...
.
So this is the timeline. So, we still have some time for nominations currently.
HERVE CLEMENT: So we have ‑‑ so I will say one week for the nomination phase.
ERIK BAIS: Okay. All right. Do we already have people that are nominated?
HERVE CLEMENT: Yes, there are people, but if more people are interested, they are warmly welcome, of course.
ERIK BAIS: Excellent. All right. Then I think we can all ‑‑ well, at least from my perspective here, I would like to thank Nurani for her work and effort. I can't hear Nurani. (No sound from Nurani)
Is something wrong from the audio from Nurani? So let's see if we can fix this in a couple of seconds, and otherwise we'll have to go ‑‑ let's see if we have any questions and give Nurani a bit more time.
LEO VEGODA: There is nothing in the Q&A queue at the moment.
ERIK BAIS: Perhaps Nurani has selected the wrong mic, is the suggestion.
NURANI NIMPUNO: Can you hear me?
ERIK BAIS: It's very soft, Nurani. It sounds like your audio is coming from far away. I think we'll leave it at this. All right. Thanks, Herve. Thanks, James. Thanks, Nurani, for all the work. The audio isn't working at this point. We'll have to go to the next topic so. Leo...
LEO VEGODA: Okay. Coming back to the agenda, and the next item on the agenda is the NRO NC, ASO AC candidate introductions so we'd like to invite Ulka to speak and share slides.
ULKA ATHALE: Hi. Good morning, everyone. I hope you can see the slides. My name is Ulka Athale, our Senior Communications Officer at the RIPE NCC, and I am running the NRO NC election taking place at this RIPE meeting. I will just first present a very short recap of how voting works, and then we have time for any questions you might have for the candidates and if there is still a little time left, the candidates could get a minute to speak and address the Working Group.
So, first, this is an election to fill one seat on the NRO NC. The seat is currently held by Nurani and her time ends on the 31st December this year. And thank you again, Nurani, for all the work you have put in. The time we're holding elections for will begin on the 1 January 2022 and will end in December '24. All RIPE meeting attendees, except RIR staff, who have checked in for RIPE 83, are eligible to vote, and we have four candidates in the running. Simply put, the candidate with the most votes will be elected and voting takes place electronically.
So, how do you register to vote and check in? So, it's really simple. You might have already registered to vote in the NRO NC election while registering for RIPE 83. In that case, all you need to do is check in. Just find your RIPE meeting registration e‑mail, or the e‑mail you received this morning about day 2 of RIPE 83, contains a unique link to your personal registration options so just select the option to check in and select the option to vote in the NRO NC election and please make sure you have done this before 2 p.m. UTC + 1 today. Registration will close at two o'clock, UTC + 1. Voting will open later today at the end of the last session at 5 UTC + 1, and voting will close on Friday morning at 10:30 UTC + 1. The RIPE Chair will announce the results in the Closing Plenary, so please make sure you have checked in because only checked in attendees who registered to vote will receive the voting link at 5 p.m.
And with that, I open the floor for questions for our candidates. We have four candidates:
.
Toma Gavrichenkov, Anastasia Sandera, Sander Steffann and Salam Yamout.
If you have watched the video, the candidate introduction videos have already been shared, they were shared last week, and do I see any questions for the candidates?
LEO VEGODA: I am looking at the questions queue and there aren't any questions there, but Sander wants to speak.
(Sander Steffann on mute)
LEO VEGODA: We also have Toma.
ERIK BAIS: Toma, can you say something?
.
TOMA GAVRICHENKOV: So, we see some technical issues with all of this, so Sander just said that he doesn't want to speak. So, I guess we all are just to answer your questions, if there are any.
ULKA ATHALE: I believe we also have Anastasia who is present.
LEO VEGODA: We do actually have a question that has just come into the Q&A and I am going to read this out because the stenographers have asked us to read out questions slowly to make sure they get a good record.
This is from Peter Koch of DENIC, and he says: "Could candidates elaborate on what, absent global policies, they would envision ASO NRO becoming involved in as per by‑laws, for example?"
ERIK BAIS: Is that for anybody in particular, Peter, or...?
LEO VEGODA: He addressed it to candidates plural, so I think it's any candidate that would like to answer that question.
TOMA GAVRICHENKOV: That's almost like speaking from international space station. Yes, you always need to understand that you are being heard still.
Anyway, first part is that ‑‑ well, absent global policies. There is ‑‑ the whole global policy part isn't as active, maybe, as the policy process in each region is, so maybe there is ‑‑ there might be potential for bringing some ‑‑ building some bridges there. Also, if we speak of anything except global policies, there is, I'd say, experience of different RIRs, right, in dealing with different issues, including abuse, including routing issues, for example, and this experience is greatly different in LACNIC, APNIC and the NCC, so this experience exchange ‑‑ like, this year, we have got a perfect case of sharing the experience of how the local policy development works. This is what's done during the ASO NRO meetings this year. The mutual experience exchange in helping other RIRs to implement what's already been implemented, and where, for a reason, in one or two RIRs, is something that the ASO could be busy with.
ERIK BAIS: All right. Thanks for that answer. Any of the other candidates that want to do a 30‑second reply on this or what their role will be in the ASO NRO? Otherwise, we'll cut the mic. I don't see any additional questions. Then I would like to say ‑‑ thank the candidates, wish them all the best. Thanks to Ulka for the presentation.
ULKA ATHALE: Thank you. If you have any questions or issues, please just e‑mail nominations [at] ripe [dot] net and please register before 2 p.m. today. Thank you.
ERIK BAIS: Thank you. All right, then. Now, the thing that we have all been waiting for. Angela.
ANGELA DALL'ARA: Good morning, everybody. I have been waiting for this presentation. There is already a presentation pre‑recorded online, I hope somebody had a look at it, so, here, I'm going to give you only a short summary.
I can eventually share my slides and I give you a very short update about it.
So, this year has been, I think, one of the most quiet years in our region, so we had no policy proposals, we had no new implementation, but that doesn't mean that everything was quiet, because the community worked a lot on other matters, and so what is very important is that there is a new draft for the PDP document that will be presented on Thursday by the RIPE Chair, so the idea is that you share your feedback on the RIPE list, you give your suggestions, you give your comments, because this is actually the way in which the community is going to implement and take decisions in the future. So, please participate, it is very important.
Going to other regions, the implemented policies are mostly regarding recommendation. So, for example, in APNIC, it's not needed any more to provide the purpose for assignments and sub‑assignments, so whenever you changed the usage of your address, you don't need to provide the documentation again. Then we have time until the 5th December to provide some tutorial changes to these four proposals that have already been accepted and are going to be implemented soon. And there is new guideline that is going to be implemented soon still in APNIC to restrict private ASes, and located ASes in the creation of ROAs.
In ARIN, they implemented two clarifications in the language of the policy manual, and, in LACNIC, they have now new talk with ‑‑ where you can create ROAs where they create ROAs with origin AS zero for unallocated space, so there is, how can I say, a big attention for what is regarding RPKI.
In our region, there is still the possibility to use our hosted certificate authority and that is excluding only the private ASes.
So, under discussions, we have some policies in AFRINIC and some in ARIN. In my recorded presentation, there was also policy in LACNIC that did not reach consensus and has been abandoned, it was regarding some modifications in the PDP.
So, I ask you if you have any questions. If you don't want to make them here, you can always write to me at pdo [at] ripe [dot] net. And that's from my side.
LEO VEGODA: We don't yet have any questions in the queue, but if anyone wants to send one, we'd be happy to read it out for Angela.
ANGELA DALL'ARA: So all clear, I think I can clear the floor to...
ERIK BAIS: Wait, let's see. Let's give them a bit more time. We have some.
JAMES KENNEDY: Any questions in the Q&A or the chat, please?
ERIK BAIS: Yeah, you said it was a bit quiet in the RIPE region. As the new Chair collective for Address Policy, we'll make sure you'll get enough to do even this year.
ANGELA DALL'ARA: Thank you.
ERIK BAIS: Don't worry about that. Thanks for the updates. Any ‑‑ I have seen that the AFRINIC region was quite active with all the appeals going on. For the Transfer Policy, the Inter‑RIR Transfer Policy that wasn't ratified yet. What is the ‑‑
ANGELA DALL'ARA: There were multiple proposals there. At the moment, the one that went into last call is a policy that is actually allowing outgoing transfers, so from AFRINIC to other regions only when they are legacy or they are regarding addresses that were coming from, how can I say, out of region. So it is not, how can I say, fully reciprocal with our policy, but let's say it is compatible. I mean, we can accept from them these kind of transfers. It went into last call. It is still under discussion. Let's see how it's going to be.
ERIK BAIS: Okay. So we have a request for the mic. We have Jordi, who is aware of what's going on in AFRINIC.
JORDI PALET MARTINEZ: Not just AFRINIC, other regions.
ERIK BAIS: You have been quite active in the mailing list in AFRINIC, I have seen.
JORDI PALET MARTINEZ: I think there is some confusion in the transfer policy in AFRINIC. There was a policy proposal that reached consensus, according to the Chairs that were recalled, but the Chairs were recalled because that policy proposal was changed, which no real comments in the last call three times, and is under appeal. Obviously, if the Chairs were recalled because that change was against the PDP, I don't expect that the Appeal Committee will accept that policy proposal and that's the reason why they were ‑‑ didn't ratify it.
Then there are two policy proposals that actually were previous to that one but didn't reach a consensus. One of them is from me, it's fully reciprocal, which all the registries didn't reach a consensus in this meeting, I don't agree with that, but that may be subjected to a new appeal. And the other policy proposal is not reciprocal, which we know is the major donor of addresses to all the other regions, you know, in general. I'm not looking at the last few months, just last couple of years, because the situation changed a little bit with a big block of addresses in APNIC.
I got requests from other people to appeal also that policy that, according to the Chairs, reached consensus, because there were plenty of objections that the Chairs have not considered it, but this cannot proceed until the Chairs confirm their decision because that was in the last meeting. So I expect nothing will change and we will not have transfers in the next year because, even if a policy is ratified, AFRINIC already confirmed it will take at least nine months to implement it. So that's ‑‑ Angela, I'm not going to contradict you, but just to provide some more insights.
ANGELA DALL'ARA: No, I said there were multiple transfer policy proposals, but at the moment the only one that went into last call is this one.
JORDI PALET MARTINEZ: All right. Thank you.
ERIK BAIS: Then there is one thing that is actually going to need your input, and already did in the last year, working together with Mirjam, the RIPE Chair, is the review of the current PDP. The status there, because although it's a community policy, it's not running in Address Policy here, so that runs on discussion on the RIPE list, and is written down by the RIPE Chair by both Mirjam and Niall. What is the status there? Can you provide us with a small update?
ANGELA DALL'ARA: Well, it is published, the new draft. Mirjam sent, I think, end of October, on the 26th, I think, of October, the link to look at the new draft. So, they are waiting for feedback, and it's going to also be presented on Thursday morning. So, there are not really huge changes, I don't want to anticipate too much in the sense that everybody has to ‑‑ not in the sense that everybody has to read it and to compare it with previous version, but Mirjam also listed which are the main points for the changes, like, for example, to facilitate, let's say, the starting of a discussion because sometimes, you know, the people are a bit intimidated by the whole process of PDP, I have to have a ready policy proposal, what do I do? And so on. It is, how can I say, promoting the proposal of an idea to see if there is the interest for a policy proposal. So, it can also be an opportunity to find people that want to cooperate in writing the proposal, having a more ‑‑ of course now it is more virtual, more on a distance, it is good to promote cooperation between people. So, everybody ‑‑
ERIK BAIS: Yeah, so a bit more discussion first before we actually go into the formal ‑‑
ANGELA DALL'ARA: To see if ‑‑ the problem statement is clear, if everybody is feeling that there is the need to change something and so on. And then seeing the experience of the appeal that we had a couple of years ago, it was the first one in our history, there is a bit better defined, how can I say, description of what does what ‑‑ who does what ‑‑ who can participate into the appeal and so on. So, it is a way to improve our PDP. There is not a big, how can I say, change in what are the phases, in what are the time lines and so on, but the time to make it a more, how can I say, also more approachable and clear for everybody.
JAMES KENNEDY: Sorry to cut in, folks, we do have one question from the chat.
Chuene Semono from the University of Limpopo asks: "Why take nine months to implement a policy though if it is approved?"
ANGELA DALL'ARA: It depends which kind of policy we are sort of talking about. It depends what the policy is. I mean, there is not a fixed time of nine months to implement the policy, there is no ‑‑ it's not written in stone.
ERIK BAIS: I think this is in regards to the answer of Jordi about if the transfer policy in AFRINIC is going to be implemented, it will not be done within the next nine months because it will take AFRINIC to actually implement that particular policy because it needs to interact with all the other RIRs and needs to align processes.
Okay. I don't have any additional questions for you at this time, Angela. I don't see any questions in queue. Then.
JAMES KENNEDY: Thank you very much, Angela.
ANGELA DALL'ARA: Good‑bye everybody. Thanks.
ERIK BAIS: Then we'll move on to the Director of the NCC, Hans Petter, with an update about AFRINIC.
HANS PETTER HOLEN: Thank you. So, can you hear me while I am looking for my slides?
LEO VEGODA: Yes.
HANS PETTER HOLEN: Very good. Thank you. So, an update on the AFRINIC case. So, I am Hans Petter Holen, I am the Managing Director of the RIPE NCC, and I am also the Chair of the NRO Executive Council this year.
Normally, I would not comment too much on business going on in other RIRs, but I was asked by the Chairs of this Working Group to give a short update on the the AFRINIC case and since that is important to the whole RIR system, I accepted this invitation.
So the background for the ongoing case is that AFRINIC, in 2020, initiated audits of its members, and found, among others, that one member's resources were not going used for their original purpose. After seeking clarifications on their status, AFRINIC informed the member that they would begin the process to reclaim the resources. This resulted in the member taking AFRINIC to court in order to stop the deregistration.
They went further also to freeze ‑‑ to have a court order to freeze AFRINIC's bank accounts and that happened in July.
Now, this went back and forth in several hearings in the court and in October the court lifted the freeze on AFRINIC's accounts. So, after this, AFRINIC is fully capable of conducting business as usual.
The litigation continues. There is a list of court cases on the AFRINIC website, and you can also find this discussed on various AFRINIC lists if you are interested.
Just last week, AFRINIC had its 34th meeting, I did not attend that meeting, but if you are interested in seeing what happened there, I have included the URL here as well.
So, the reason that the RIPE NCC gets involved is because the NRO has established a joint RIR stability fund, and we are committed to support the joint Internet numbers registry because for uniqueness of numbers in the Internet, our five registries together is the global joint Internet numbers registry, and AFRINIC is an integral part of this. The Joint RIR Stability Fund is a mechanism through which assistance can be provided for the Registration Services.
The RIPE NCC Executive Board has authorised me to act on behalf of the RIPE NCC if AFRINIC submits a request to access this fund. And, so far, AFRINIC board has not made any such request. So, this is clearly a last resource in keeping the registry going on in the African region.
If you want to see some further details about the RIPE NCC thinking in this, there is a RIPE Labs article I published a while back.
This was a short and sweet update on the AFRINIC legal situations. So back to you, Erik.
ERIK BAIS: All right. Thanks for this short and concise update. I think it was important for the Working Group to be at least aware what's going on and thank you for this update, Hans Petter. I don't see any questions in the queue, so that leaves me to thank you, Hans Petter, especially on the short notice that we gave you on this. Thanks again.
HANS PETTER HOLEN: You're welcome.
ERIK BAIS: Next on the agenda, Marco, for the update from RS. Good morning, Marco.
MARCO SCHMIDT: Good morning. I am going to share the slides. Good morning once more. I just want to provide you with a very quick recap of my pre‑recorded presentation that hopefully some of you had time to watch, also the complete slide deck with the feedback from RS, and basically I had three topics in my presentation and I compressed each topic into one slide.
The first one was a quick update on the IPv4 allocations because since quite exactly two years, the RIPE NCC provides IPv4 allocations on a first‑come first‑served waiting list system, and I show here a graph to you that shows how we handed it out. Maybe a quick explanation. You see here there was columns though the monthly amount of allocations we gave out, starting from December 2019 to now. You see three colours there. So if it's blue, it means that we gave it out to an LIR that represented one member. If it's red, it was given to an LIR that has already ‑‑ that belongs to a member that has up to four LIR accounts. And if it's yellow, it belongs to an LIR, or it was given to an LIR that belongs to a member with more than five and more LIR accounts.
And, yeah, you can see quite clearly something happened earlier this year, around May, that ‑‑ until then, we handed out an average 100 allocations per month. It peaked, and it peaked mostly because of requests from multiple LIR accounts, and, as a result, actually just a few days ago last week, we had to activate a waiting list again so the demand exceeded what we had in stock, and it's clearly related to those multiple LIR account requests.
And the reason is quite simple: It was currently cheaper to open another LIR account than get the /24 in the market, and also, even if, now, the waiting list is activated, it is still counting that you have to run an LIR account for three years or more and it's still currently cheaper than get it on the market. And the consequence, of course, is for the real newcomers, they have to get in line and they have to wait longer. So, right now, I can tell you that the people that now joined the waiting list will not get any IPv4 this year, hopefully early next year.
Yes, Erik?
ERIK BAIS: I have a question on this. So, most of the people will have read or read the presentation and seen the whole video that you have done. Great, actually. I fairly enjoyed watching it. I would recommend, for the people that haven't seen the video, to review that after the session, particularly on this, because I haven't seen any questions on this particular topic. In your view, how can we ‑‑ besides the fact that we now have an actual active waiting list, we e‑mailed about that last week, or two weeks ago, that this was coming up, is there ‑‑ that's particular also for the Working Group ‑‑ do we see this as a problem? And if so, how do we want to fix this in the current waiting list policy, for instance, by limiting, for instance, the waiting list for only new LIRs per organisation as an example? We have some time to discuss, and what is the idea about, you know, from the Working Group on this, and I also would like to hear your opinion on this, Marco.
MARCO SCHMIDT: Yes. So then maybe I can go first, indeed. What the Working Group can do is look at the policy. Currently, it is clear rule that each LIR can request an IPv4 allocation if it has never received an IPv4 allocation from the RIPE NCC before. Of course, another option would be looking at the charging scheme which would be from the member base, not here in this Working Group, and also that would have earliest effect for 2023 because the charging scheme for 2022 is already decided, so the Working Group really could have a look at the policy and if there is any need to adjust something there.
ERIK BAIS: Okay. We have Peter Hessler at the mic.
PETER HESSLER: Hello. So I only saw your video this morning so this is only a half‑baked idea. But, there is ‑‑ I believe there is a potential policy proposal we can make to help with the situation, and essentially it's a new type of status for an application which is no transfer and the short version is: This address block could be allocated to the LIR as appropriate, they can use it as normal. However, this can never be transferred to another LIR, ever. And in case they merge their LIR accounts, this will then be returned to the RIPE NCC as part of the normal return process. They could transfer the LIR ownership, but that LIR has to stay a LIR for the entirety of that prefix. You would not be able to transfer it ‑‑ and included in not being allowed to transfer, you cannot transfer it out of region as well. This, of course, would only only apply to new IPv4 applications. As much as we want to go back into the past, we can't, and I don't see a reason why this would need to apply to IPv6 or ASNs as well. So, do you have a first thought on this? Does the community have some thoughts on this?
ERIK BAIS: Well, as the author of the majority of the transfer policy that we currently have, the problem is with the merger and acquisition of companies where this might actually become an issue. And getting specific status new to hand out IP space because, as you said, you can't go back, this might actually become ‑‑ you know, it doesn't solve this in the short‑term, I think moving into a way where we just limit the waiting list for new LIRs, you know, organisations having their first LIR might in fact have more factors. Gert, you were on the ‑‑ you were online as well.
GERT DÖRING: Good morning, dear Working Group. It's a pleasure to just lean back and listen to you. But I want to comment on this. We have been at this point with the /22s and the AGM restrictions on there can only be one /22 per member. And I am worried that this is not going the right way because, in many European jurisdictions, it's very easy and very cheap to just open a new company. So, if we tell people you can only have one LIR account per member, they would just come up with new companies and the real holder then gets hidden so that would harm the registry. That said, I really, really like what Peter Hessler proposed: change the transfer policy and have like a ten year or forever restriction on these. Yes, there will be cases where this hurts, and if your company gets acquired, then either keep the LIR account or return, or go to v6, but that would actually, I think, be effective. Thank you.
ERIK BAIS: All right. Thanks for your comments. Hans Petter?
HANS PETTER HOLEN: Thank you Erik. So, I may want to point you to the GM tomorrow where the board will present some thought on potential changes to the charging scheme where addressing the gap between setting up a new LIR and the fees versus the market price. That's another way to deal with this where one thing that I would like to see would remove the artificial creation of LIR just to get more address space because we really do not have good support in the system for the distinction between LIRs and members, so either we would need to put in considerable development time to get this really good in the back office system or we would move into a world where there is a membership fee rather than an LIR fee in the future. So this is where Address Policy crosses charging scheme, and I think please come to the GM and listen to the proposal from the board. This is not up for voting at this time, but I think having the principles discussed now so that there can be refined proposal in the May meeting to vote on is what we're aiming for. So I just wanted to throw that in here, so maybe if we're able to decouple the two of them, it could be good.
ERIK BAIS: Okay. Thank you. Sander.
SANDER STEFFANN: I basically wanted to second what Gert said, because if we don't limit the mergers and acquisition path, then it will be too easy to just get rid of the LIR that way. So, actually having a ten year or forever limit on transferring, and also make it deregister when there is an ‑‑ so basically they can't just merge the LIR accounts, would be the best way. But then you get into what Hans Petter just said. So this ‑‑ this is a very hard topic. We have discussed this in Address Policy many times, looked at many avenues, and if you close one way, you open another way, and if you solve one problem, you create another, so it's a very hard problem. And at some point, I must admit that I'm just okay with it as well, because, you know, we keep solving the IPv4 problem instead of going to v6, so, you know, at some point ‑‑ like, it's a bit unpopular but, you know, just let IPv4 rot in hell. It's fine. It's fine.
ERIK BAIS: We'll get to the v6 problem later, you know. We'll ‑‑
SANDER STEFFANN: I know. Like I said, I'm intentionally putting some more force behind it, words behind it, but I do notice my feeling is moving that way.
ERIK BAIS: Okay. All right. Thanks for your comments, Sander. Marco, back to you.
MARCO SCHMIDT: Okay. I'm going to continue with the second topic, which is ‑‑ I can keep it brief because it also ties in a bit with what James Kennedy actually will present later in the Database Task Force findings. That was also ‑‑ and I presented it at the last RIPE meeting. We do see quite some challenges for, especially new members to understand why they have to create assignments to document their networks in the allocations, especially now with the /24 allocations, which is the smallest route of the prefix and as a network and we had a look at it so it's still about two‑thirds of those IPv4 allocations that are announced or in use without assignments. So there is ‑‑ really, the definition of allocation and assignments is quite old and maybe needs an update, but I would say ‑‑ I will move on at this moment to the next topic and eventually it can be picked up when James Kennedy will present on the Database Task Force findings.
ERIK BAIS: Let me have a question about this to the Working Group on this particular topic. Is there ‑‑ on this particular topic, what are the thoughts? I do agree that this particular part is a bit outdated, specifically for looking at v4. V6 will also need to have a look at this. But, anyone in the audience that wants to voice an opinion on this? Otherwise, we'll leave it to when the ‑‑ when James is picking this up in the update on the Database Task Force, because this is also on that topic, something that we need to look into. Okay, moving on.
MARCO SCHMIDT: Okay. Then, moving on, this is also a topic that is maybe like an old friend because the RIPE NCC has proposed it a couples of times. Again, a similar graph, but this time about v6 allocations that we handed out over the last 36 months and it also was discussed on the mailing list that we see this trend of stockpiling and, so far, the feedback was there are real use case, that's true, that maybe an organisation needs two or three allocations for different networks. There also was the feedback, okay, what is the harm, because there is still enough IPv6 for everybody. But maybe if you just have a look at this graph, you can see a quite significant trend. Again, yellow means that these IPv6 allocations go to a member that has already five or more LIRs and collected five or more IPv6 allocations. And if you see over the last three years about how the v6 allocations went to such multiple LIR accounts. And it feels a little bit, you know, I use an example, it's like an all‑you‑can‑eat buffet, so everybody can get what you want, and you see somebody who is grabbing, grabbing a lot of stuff from the buffet. So far, nobody is really impacted except of the waiter that has to fill up the table ‑‑ so the RIPE NCC ‑‑ but we keep on bringing it up to the community because there are potential problems in the future, especially also the conflict with the goals which Leo will present, and the most obvious conflict is with the goal of conservation, which actually is probably outdated, that's why we actually are more concerned about conflicts with the goal of aggregation, and also the goal of registration, because these ‑‑ basically, some members now collected IPv6 allocations in amounts that put them in the top ten of IPv6 space in the whole region, so that even just big players like Deutsche Telekom or France Telecom have more IPv6 space than them, but these companies are not, let's say, in the same league from the businesses. So, that's why we keep on bringing it up and we understand it's not a real painful issue right now for the Working Group, but it's really a trend that is ‑‑ we find it concerning and we want to bring it to your attention again.
ERIK BAIS: Okay.
LEO VEGODA: We have a couple of questions that have come in on the Q&A and I'd like to read them out. Some of these are trailing a little bit the topic that we have just been talking about, so, the first one is from Wolfgang Zenker from punkt.de GmbH:
"Another suggestion: Stop giving out IPv4 space to members for free but put available /24s up for auction. Only members allowed to bid. Every participant making exactly one non‑public bid. Highest bidder wins."
.
So that appears like a suggestion more than a question. So I won't ask you to respond to that.
Next, we have from Jordi Palet Martinez, and he says ‑‑
ERIK BAIS: He is referring to a question earlier about the AFRINIC topic.
LEO VEGODA: Yes. And he says: "And Inter‑RIR Transfer Policy requires many months of job to coordinate with the other RIR systems. It may be faster now for AFRINIC as the other four RIRs already did, but, even so, you need to have availability of staff resources mainly at AFRINIC, but also at all the RIRs for implementing testing etc. "
.
Then we have Michael Richardson of Sandelman Software Works:
.
"Hypothesis: The people grabbing 5 plus LIRs for IPv4 are just doing the same for IPv6, being ignorant."
.
And then Maximilian Wilhelm, representing himself: "Do we know if these allocations are in use in any way?" And perhaps you could answer that.
MARCO SCHMIDT: Yes, I certainly can. So, the biggest amount of allocations are currently not announced, so likely not in use and they are probably just stock‑piled for future plans. However, we also know of some of those organisations that actively offer big parts of their IPv6 allocations to other parties, to non‑members, for a better price, basically, than a membership, and basically to do whatever activities they can do with those v6 blocks.
LEO VEGODA: May I ask a question? So, back in the late eighties, early nineties, it was relatively common for large industrial organisations to say, well, we're going to start putting robots in our factories automating manufacturing and we are going to control them with IP, and they would get a block of IP addresses for the factory in city one and another block of addresses for their factory in city two. Could we be seeing exactly the same sort of thing but just for IPv6? And because it's a factory, they have no need to announce this address space on the Internet; they just want unique address space to control their factory automation.
MARCO SCHMIDT: Not that I'm aware of. There was organisations that are, let's say, leading these activities to collect many IPv6 allocations, they are not ‑‑ they are not running factories or producing anything. In fact, even often you don't find much information about them in the Internet. So ‑‑ and just by their name, they seem to be IT‑related, so nothing producing.
JAMES KENNEDY: Also, if I can follow up on that point. With IPv4, we previously have seen stockpiling and mass distribution of IPv4 resources, even with a former employer of mine was involved where, say back ten, fifteen years ago, it was much cheaper these guys who were stockpiling to get address space, address blocks from the RIPE NCC and set up a membership and then, over time, when the v4 became more valuable, even monetary value on the market, the prices used to ‑‑ they used to up the prices to an extortionate amount, unaffordable amount. So, yeah, the stockpiling conservation is one challenge and one danger, but there are other risks that I think we should definitely take into account and learn the lessons of IPv4 in that sense.
ERIK BAIS: Yeah, so one of the topics that we see here is that we have the same graph, basically, as that that we have seen with the multiple LIRs for IPv4, and again, the same ‑‑ if it's the same group of people grabbing the same, you know, doing the same land‑grab. Maybe we should have a good discussion about being able to register multiple LIRs because that could potentially fix two birds with one stone.
Let's go to the queue at this point. I have Jordi as one.
JORDI PALET MARTINEZ: Yes, even if I don't agree with what possibly it looks like tricks to get more IPv4 resources, I am not really too much worried about IPv4 any more. It's over, basically. But, yes, the problem is that we may have the same problem, which is ridiculous, with IPv6, because there are enough resources in principle, but maybe the solution is not really just the policy, or maybe a combination of policy and internal process in the sense of why not be more strict to allow additional LIR accounts? I mean, I think the actual policy is good if the justification for an extra, or additional LIR account is good enough. Do you see my point, Marco?
MARCO SCHMIDT: Yes.
JORDI PALET MARTINEZ: Now, again, the point here is it is a policy, or it may be just an internal process and you really need both. Because if it's a policy, we can start working on that very quickly in the list.
MARCO SCHMIDT: Well, I wouldn't ‑‑ sorry, would I see that it is a policy because their current policy requirements are very clear, that every LIR can request an IPv6 allocation up to a /29 without much questions, or any questions asked, basically, and the result you see here in this graph.
ERIK BAIS: Okay. We'll have to cut down the line for the questions and answers. Please take them to the list. We're overrunning, otherwise, pretty quickly. Marco, were there other topics slides that you wanted to...?
MARCO SCHMIDT: No. That's all, basically.
ERIK BAIS: I do want to read out the questions that we see on the Q&A, very quickly. Rinse Kloek says:
"Can it help to make the default v6 allocation size of an ISP dependent on a the current IPv4 allocation it has?"
MARCO SCHMIDT: Well, maybe I'll ‑‑ it might be a bit challenging because especially ISPs that don't have much IPv4 might need to invest in IPv6, indeed, so it might get difficult.
ERIK BAIS: Okay. Then we have a random Internet citizen named Remco van Mook:
"What percentage of v6 space has currently been allocated and are we at risk of running out?"
MARCO SCHMIDT: Yes, it is a small fraction that insofar as running out, we are in the second /12 that we have received from IANA, I think two years ago, so, indeed, the risk of running out is not there. It's ‑‑ again, if I make this comparison of all you eat is free, they still supply a lot, but it might not feel right for somebody to see the neighbour grabbing and grabbing as much as he can just because it's possible.
JAMES KENNEDY: There are other risks other than conservation, right? Other dangers.
MARCO SCHMIDT: Exactly. Like aggregation and registration is under potential risk, I think.
ERIK BAIS: All right. We're ten minutes out. So, James, your session will be cut short, definitely. We'll do a quick five minutes and see if we can grab some time back, because I don't see we're even getting close to the time that we need for the v6 policy. Thanks, Marco.
MARCO SCHMIDT: Thank you.
JAMES KENNEDY: Thank you, Marco. So, hi, everyone, James Kennedy here again. A quick update from the RIPE Database Task Force on a recommendation that we have for Address Policy.
So, I want to talk as much about process as about the actual recommendation because it's important to get that clear. Our report is, I am happy to say, published finally, on the RIPE website and we encourage you all to read t it contains, amongst other details, recommendations primarily based on input that we received from the community over the past two years since we started our tasks and our careful deliberations. The recommendations are not set in stone. They are to be discussed within the relevant Working Groups, and, yeah, if a recommendation is by and large accepted, it will be implemented by the community and the RIPE NCC. How, will depend on what needs to be done because in each case it's not uniform across. So, it depends on what needs to be done and the RIPE NCC will work with the RIPE community to implement. Of course if there is any change to policy, it needs to go through the established PDP policy development process.
So, the recommendation itself that we have is to clean up, as such, or remove RIPE policies that state it is compulsory to register all IPv4 PA assignments in the RIPE database. But keep this function of being able to create inetnum PA assignments, keep the function available for holders who still want to use it. As such, giving address holders the freedom to decide on whether they want to register their infrastructure assignments in the Ripe Database or not, which, in practice, is actually what's happening today, but I'll get into that later.
We do have the strong caveats; please note that we do, however, recommend sub‑allocating and partitioning part of your PA address space to a third party, another entity. This should be documented in the Ripe Database.
And please be ‑‑ do note that we're not recommending the forced deletion of existing assignments in the Ripe Database. Again, going back to my former point, the freedom should be in the hands of address holder, whether they want to make their infrastructure assignment in the Ripe Database or not.
So, why do we come to this recommendation? Well, there are several reasons, but I listed out just a few here. The core reason for registering PA assignments in the Ripe Database in the first place was for an LIR to show to the RIPE NCC their utilisation of their current address pools and then, in doing so, justifying a request for additional IPv4 address space. However, this requirement has been (inaudible ‑ lost connection) since the RIPE NCC ran out of the IPv4 free pools in 2019.
And I'll quickly go through. There are tremendous inconsistencies across how the current IPv4 registration policies are applied. Some LIRs, some members register individual IP addresses into inetnum objects, while many others, many other hold allocations even ones that are being announced on the Internet, they do not register any assignments in the Ripe Database, so in the little table I have here, which was correct as of May this year, on the left is some details on the over‑signing of individual IP addresses. So, just a few LIRs who are doing it with over 10,000 /32 assignments each in the Ripe Database. While on the right‑hand side, are some details on under‑signing, as such. So, almost 10,000 ‑‑ well, back in May, probably 10,000 LIRs ITR stage, hold allocations containing no assignments in the Ripe Database. And also, keep in mind, of course, since the RIPE NCC are handing out /24 PA allocations, this means that the holder needs to register at least two assignments in the Ripe Database, /25 or smaller, because you can't have the same size allocation and assignment object in the Ripe Database. It's a feature. So, today, they have over 3,700 /24 allocations today. Multiply that by two is the amount that needs to go in the database at least. And 65% of the announced address allocations have zero assignments in the Ripe Database. So the policy is basically not being applied in reality.
ERIK BAIS: This actually provides some additional issues with audits as well. If you do an ARC, this is one the topics that's been addressed where policy and reality are currently not in line. This was also addressed by Marco. The question, do we need to change this? I think it's well‑documented, and for me, as a ‑‑ as one of the Chairs, I think it's definitely in need for an update.
JAMES KENNEDY: In regards ‑‑ the last point also within that document, everyone please go and read ‑‑ we do have some data management principles which we have as a guide for users, how to manage their database. There is also consistency and minimisation which we have as principles and, yes, the challenge of having, you know, all these inaccurates in the database. So the process in in this recommendation in regards to potential implementation, so the steps are we'll discuss it within the Working Group. You know, if there is any other aspects that we need to take into account, that if there is any value, for example, that these policies provide that need to be taken into account, let's have that discussion. We don't have time now, but let's take it to the mailing list. And obviously this will be ‑‑ if to be implemented, will need some policy change. So, in other words, we'll need volunteers to make a policy proposal to clean up these outdated policies.
ERIK BAIS: Okay. So, we'll take this to the mailing list. Thanks for the update. We are running a bit short on time, so we'll not be taking any questions. We'll have a five‑minute break and then go in speed mode through the presentation of Leo. Thanks again.
LEO VEGODA: My presentation will not take long.
ERIK BAIS: Excellent. So, see you all in five minutes.
(Coffee break)
LEO VEGODA: Hello, everyone. I hope you can hear me clearly. I hope you had an opportunity to refresh yourselves. I'm going to quickly walk through an introduction to the IPv6 policy goals. And the reason we're looking at this is, it's essentially 20 years since we set these up. The goals that we have in RIPE‑738 are basically the same as the ones we had in RIPE‑246. The last statement in the policy goals is that aggregation should be considered the most important of those goals. The goals are here on the right‑hand side of the screen, and I'm going to quickly run through what the titles mean.
So, uniqueness means that when you get your Internet number resources, your IP addresses in this case, they are yours uniquely worldwide.
Registration is that they are in the database so that everyone knows who is responsible for those resources.
Aggregation is that space should be distributed in an hierarchical manner according to the topology of your network infrastructure.
Conservation, we shouldn't be unnecessarily wasteful.
Fairness, should take account of everyone who is already a member of the Internet community and the people who might come in the future.
And then minimised overhead essentially make it a little bit easier to get your IPv6 address space than it was to get IPv4 address space. Certainly that was, I think, what was in people's minds at the time that we looked at these goals back about 20 years ago.
So, over the last 20 years, IPv4 has run out. We have introduced and refined transfer policies. We have introduced policies on publishing abuse contact information. The RIPE NCC publishes an annual report on requests for law enforcement agencies and, of course, this month, the RIPE NCC started publishing a report on the impact of sanctions on its operations. So, we are in a significantly different world. The environment around us has changed. It is appropriate to go and consider whether the goals that we set out with 20 years ago are still applicable and, if they are still applicable, do we have goals that were more important then than they are now, and vice versa? Is there something that was held out as the most important goal, like aggregation? Is that now equal to the other goals or are there two top goals, or whatever? So, my questions here are not intended to go and set out: We must change things. But I think, after 20 years, it is appropriate to go and say: Hey, the world around us is changing. We should go and just take a look at what we set up 20 years ago, is it still right? Do we need to be here or should we be going in some other direction? And so, this is our discussion. I appreciate we only have a few minutes left for our discussion, but I'd like to offer the floor to anyone who would like to make a point, or alternatively, we could just go and take this to the mailing list which it will end up back with anyway. Gert, I see that you want to say something
GERT DÖRING: Yes. Thank you. Thanks for bringing up the topic. My personal take on this is that our policies have been a tremendous success, because it's very easy for people that want to run an IPv6 network to get space, to get big blocks of space. That said, looking again after 20 years is definitely a good thing and I want to volunteer to help with that. I have been sort of involved in what's there. So, yeah...
ERIK BAIS: Yeah, I was hoping you were going to step up and not leave the scene here, Gert. Let's see... perhaps we'll have another IPv6 enthusiast who is willing to assist Gert on this.
LEO VEGODA: On the chat, I see that Sander has put his hand up.
ERIK BAIS: Great. On the topic with the allocation assignments we'll need two volunteers or at least one volunteer as well.
JAMES KENNEDY: We do have a couple of questions in the Q&A. So, while we look for volunteers, let me just read them out in parallel for time sake.
So Tom Hill of BT asks: "Would just define your use still not be required when transferring in address space from another RIR? Would that process be made more complex?"
ERIK BAIS: That is in regards to the question on the Database Task Force topic with the assignments being removed as registered in the database. Yes, you need to provide plan if you want to have inter‑RIR transfers to the RIPE region. So, from the RIPE region, that is not an issue. To the RIPE region, you need to provide that you have a plan for usage for v4. But it doesn't come into the requirement of doing it in the Ripe Database.
Then there is a question from Jordi. Do you want to read it out, James?
JAMES KENNEDY: From Jordi: "I think aggregation is still the same important goal. I would not change that but maybe we need to consider other issues, count on me!"
ERIK BAIS: Okay. Then do we have ‑‑ let me go back to the chat. Jordi wants to participate in providing input in the v6 policy.
JAMES KENNEDY: Just to give everybody else an opportunity as well, does anybody else want to join the motley crew to review and refresh v6 policy if necessary?
ERIK BAIS: We'll definitely have a good discussion on this topic in the ‑‑ on the mailing list. This will not be an easy one to fix within, you know, a couple of one‑liners and I propose that we'll take this to the mailing list. This will conclude the time that we have on the current Address Policy Working Group session. I want to thank the scribe, thanks to the chat monitor, and all the people participating, especially the people that presented with the videos, and thanks to the co‑chairs. Then we'll see you all in Berlin, let's hope, for the next session, and if not, online, and we'll definitely see each other on the mailing list. And for people that want to chat after this, let's move to SpatialChat and head out for lunch. Thanks, everyone.
JAMES KENNEDY: Thanks, everyone. Have a good week ahead. And we'll see you on the mailing list.
ERIK BAIS: Bye‑bye.
(Lunch break)
