RIPE 92
Main room
21 May 2026
11 a.m.
Address Policy session
LEO VEGODA: Good morning everybody. Alex, Franziska and I would like to welcome you all to the Address Policy Working Group at RIPE 92.
We have two sessions today. This session before lunch and the session immediately after lunch. We used to be always on Wednesday morning at nine o'clock, but some people prefer a more generally start to the morning, and so we now have this Thursday late morning start, and, you know, so many people enjoy that so we're probably keeping it.
We'd like to let everyone know that this is a hybrid session, so, there are people here in the room, and there are people who are participating over Meetecho. If you are participating over Meetecho, you can definitely ask a question using the Q&A tab, and you can also put your hand up to speak if you want to make a point. And of course if you are here in the room, you are welcome to approach the microphones if you have a comment to make or a question to ask.
We have a Code of Conduct. We'd like to keep all discussion professional and polite. Please treat everyone with respect.
We'd also like to thank or scribes, Antony is going to be taking minutes for us today. Thank you very much, Antony. And our stenographers, thank you very much, we really appreciate your work, both while we're speaking in the room and also later on when we go and look at what we actually said.
So, we have minutes from RIPE 91. They were published, and we haven't had any comments. Does everyone think that we can accept the minutes that we published as draft from RIPE 91? I see some nods. I am going to that I can that as a yes. So, we will finalise the minutes, thank you very much.
This is our agenda for today. We will be selecting a new co‑Chair, as I am standing down at this meeting. We have an ASO AC update from holder survey, a policy update from Angela, and Marco will then give us an update from Registration Services, and finally before lunch, we have an informational presentation from Tony about IP address allocations to celestial bodies. And then after lunch, we have more, we have presentations on recycling AS numbers, revised IPv6 PI assignment policy, and an upcoming policy proposal on legacy status and anyone who is in the RIPE NCC Services Working Group, yesterday might go and recognise that topic. If you didn't see that presentation, you might want to go and check it out before the second session.
So, the next part of what we're doing is the co‑Chair selection.
The process we have is published on the website, and people who are participating in this session get to choose the co‑Chair. We announced the call for a new co‑Chair. Leslie was nominated. There was some support posted on the list, and I'd like to invite Leslie to come up here and introduce herself to everyone who doesn't already know Leslie before we do a call for consensus.
Leslie: Good morning everyone. My name is Leslie, I am happy to be back at a RIPE meeting, it's been quite some time. I started coming in 2001, I have been in the Internet industry for pretty much my entire career starting with the registry system and, well not starting but basically, it's been my whole career, the registry system. I have a lot of experience with IP Address Policy and I hope that that experience is useful to the AP WG, I am looking forward to working with all of you and I thank you for the opportunity.
(Applause)
Well, I think that round of applause clearly means that there is consensus. So, thank you very much, I am going to step down as co‑Chair, Leslie steps up as co‑Chair. And I think my closing act will be to invite Herve to the stage and give an update on the ASO AC NRO NC.
(Applause)
HERVE CLEMENT: Good morning everyone. First, thank you Leo for the work you have been performed here and thank you for your last task, and welcome Leslie on board of this Address Policy Working Group, I am pretty sure regarding the experience you had before this, that you will do an excellent job in that area.
The NRO NC update, which is the ASO AC also, it's a presentation so we do regularly during the policy Working Group. It's about the current work we are performing within the ASO AC. I will talk a little bit about ICP 2 but I invite everybody but I am sure everybody had planned to go to the Community Plenary this afternoon and we will have an excellent presentation of the ICP‑2, co‑present with Andrea as well.
NRO Number Resource Organisation Number Council, NRO is the collection of the five Regional Internet Registries and this Council, the NRO NC is comprised of normally three people coming from the different regions and the NRO NC fulfils the function of the ASO AC, there are at least three supporting organisations within the ICANN ASO, dealing with IP addresses. There is also the GNSO, regarding the domain name generally I would say they are DNS related and the ASO NSO for the country code domain.
This Council I already explained what it is. This Council, I all right explained that normally there are 15 members, three from each of the regions, but you know that due to the circumstances within the AFRINIC at the moment, we had absolutely nobody within the Council and we are happy enough to have him on board from the beginning of the year.
What we do: We advice with the NRO AC, the ICANN Board about the problematic regarding the IP global management system. We oversee the global policy development process. That is a policy between each of the regions and dealing with the function of the IANA on the Regional Internet Registry. And our role is if there is a development policy proposal, to see if the process is correctly fulfilled about that, noting that the last development policy was designed in 2012, as I can remember.
We appoint one member to the IANA Board and we appoint one member to the ICANN Nominating Committee as well and we meet monthly. And we have normally one on site meeting per year.
The people here in the slide, we have, still in 2026, so we are happy enough to have somebody from the AFRINIC and somebody who can participate and give his opinion about ICP‑2, that's very important. And you have the other people sorted by the different regions. First the ARIN, then the APNIC, then the LACNIC, and you recognise the people from the RIPE NCC Services region as well.
.
In 2026, we didn't get bothered, absolutely. We still monitor and support the global policy development process. We have a sub‑group of the ASO AC who is in charge to see within each regions what are the different policy proposals and will come back there. And they are responsible to see if one of these policies can potentially be a global policy also.
In 2026, we have not identified any potential global policy. It's something we will explain this afternoon, we conduct the ICP‑2 be review. And at the end of this year, we will launch at the 2027 election for the seat 9 of the ICANN Board.
About this seat 9. Currently, it is Alan Barrett who is serving the ASO seat and his term will end in November 2026. So in one year and a month. During the ICANN 90 and it's a long process because there is a call for the candidate, but we will go back to that in October. As Christian Kaufmann it still the Chair for the seat 10, there won't be any possibility for the RIPE NCC to present any candidate for the seat 9 during this session.
And you can see here the link regarding the different information regarding the current Board appointments.
Transparency. Threats a word that is very important for us and we will repeat this word. ‑‑ I am not very fluid this morning, perhaps it's my French will come back very easily because we are in Scotland. Transparency, so it's an important word and we will repeat this word a lot. Transparency, this afternoon during the ICP‑2. We have a mailing list open. Our ASO monthly meetings are open. There is a calendar in the ASO AC website and you can read the calendar and participate without any problem except sometime there is a closed session at the end of the meeting. And we have different meetings during the ICANN all different locations in the world regarding ICP‑2 also.
The next meeting regarding the Working Group and the work we'll perform regarding the compilation of the document will take place in invest I will, ICANN, it will take place in two weeks, something like that, there will be a set of closed session but we will do our best to have at least one open session on the ASO presentation also as well.
ICP‑2 review. I will say a few words about that.
It's just about the definition, about the source and about where we are currently regarding the agenda. We have collectively defined.
What is ICP‑2? So, you know, perhaps I can give a quiz for that, is the Internet Coordination Policy 2, and this document adopted by the ICANN in 2001, has the principle objective for recognising new Regional Internet Registry. And it's a different criteria to define the Regional Internet Registry. Am an example of Krill, so a new Regional Internet Registry must be sufficiently large in terms of region, in terms of multinationality. It has, it's an important function, to support the local numbering community, the Regional Internet Registry is here to support the community, so it's to support you. And has the capability of technical of course, so you can see that within the RIPE NCC, you have a lot of big expert, technical experiments and we had a presentation yesterday afternoon regarding the difference with that. And there is the link to the document.
General history. You know. You see that there were first Regional Internet Registry created, and Hans Petter, last Monday, recalled that there was before the RIPE community and then the RIPE NCC created in 1992, there was the APNIC, ARIN, and then the ICANN was created, and then the ICP adopted in 2001, the LACNIC first in 2002 had been established, and the AFRINIC in 2005.
Why revisit this document? For two reasons. The first one I said it was adopted by the ICANN in 2001. It's a quarter of a century, and in the Internet world a lot has changed regarding the Internet.
And the relationship between the Regional Internet Registry and the ICANN has changed also.
But also, another reason to update the ICP‑2, as I say, that it was primarily focused on the creation of a new Regional Internet Registry, but it is missing the part that the criteria defined in the ICP‑2 can be used to follow the ongoing entire life of Regional Internet Registry, and there will be one more time very extreme cases the possibility of de‑recognition of a Regional Internet Registry.
So, and it's because the NRO AC, so the group of the Regional Internet Registry asked the ASO AC regarding a short‑term task, the first one, it's the ICP‑2 implementation to consider, it was to review and revise the NRO AC on the draft procedures for validating and addressing ongoing Regional Internet Registry compliance with ICP‑2. And the second task is the task we have worked since three years, something like that. Is really to review the ICP‑2 to review the criteria to add the two other moments of the lifecycle of the Regional Internet Registry also. And the idea definitely is to consolidate the system.
Since then, we have worked a lot, as you can see, but I won't describe this table.
You have supporting documentation available. The last document available is the last update available is the Regional Internet Registry Governance doc v2, so you have the link. You have a status report of what happened in quarter 12026 also, and you have a document regarding the community engagement.
An the new one is a status report May 2026, because every month there is something new.
And regarding the global timeline, we are here in Q2, 2026, where we share the status report May 2026 I have talked about and there be the ICANN 86 with a different Working Group session there.
Then, in Q3, Q4, 2026 the final version of the document will be delivered to the NRO EC. And a final version presented in the Regional Internet Registry meeting and ICANN 87 then. And from quarter 4 2026, the NRO and the ICANN will talk together for the process of the approval of the document.
And that's all. I have one minute 43 left.
(Applause)
FRANZISKA LICHTBLAU: Thank you. We are on time, so that's fine. I am shocked you said you were only working on this for three years, it feels so much longer. But first of all, you stole a little bit of Alex and my thunder, we would like to first thank lastly to Leslie to step up into this role. It's going to be amazing that we have you with so much experience on our team and obviously Leo excused himself very, very quickly. Thanks a lot for the great collaboration, you helped me personally stepping into this role. It's sad to see you go but I am very happy to have you on the other side of the microphone again.
(Applause)
Now, do you have questions for Herve?
AUDIENCE SPEAKER: Sander Steffann: I know how much work this has been, I have been part of a little bit before I had to resign, so, thank you very much for putting all this hard work in because I know how much work it is.
HERVE CLEMENT: Thank you so much. I wanted to focus that there is within the ASO AC a specific Working Group which is called the Drafting Team Working Group who has a big work. And Andrej here is part of the drafting team Working Group and Nicole as well from the APNIC who is here.
FRANZISKA LICHTBLAU: Do we have questions online? Okay, then thanks a lot.
And as most of you probably already know, our next speaker is Angela, Policy Officer of the RIPE NCC, who gives us an update on what's happening in the policy world in our region and the other regions since we met the last time.
ANGELA DALL'ARA: Good morning all. We are here for the usual update regarding policy development in our region and in all other regions, but please allow me also to give a big thank you to Leo for all his commitment through the years but also personally it's been lovely to work together and thank you also for knowing each other a bit better. It was really great.
.
So going back to business, policy update. What happened since we saw each other in Bucharest, and then I will give you an anticipation of some work that probably you are going to be requested to do, giving feedback on a review of the PDP, and I will tell you later.
So we have a new policy. This was already accepted in Bucharest, but the development, the implementation proceeded and on the 5th May, the new terms and conditions for the RIPE NCC certification repository have been published. They will be effective on 8th June and from that moment, the RIPE NCC will start monitoring for the revocation of persistently non‑functional delegated RPKI CAs and the new policy is RIPE 847. My colleague Bart gave a beautiful presentation yesterday in the Routing Working Group, so you can ‑‑ give you what the RIPE NCC is going to do to inform the operators of delegated CAs that are non‑functional for more than 90 days, and for details, I refer you to that presentation.
So, for now, if you have ‑‑ if you are running a delegated CA, check that it's functioning, and if you have some issues, I understand that the RIPE NCC is more than available to assist you in eventually solving the issues.
Then, we have two policy proposals at the moment in the PDP.
The first one is awaiting a new version, it's regarding the revisitation of the criteria for assigning AS numbers, and I expect to see a new version after this meeting being posted. And later on, you will hear from Tobias and Clara about the revised IPv6 assignment policy proposal 2024‑01. The discussion phase is ended for this proposal, and I think they are going to seek your feedback to take a decision, and please read the proposal, be prepared about all the topics that this proposal is touching on, and give your feedback if this proposal is responding to your need or not. And provide suggestions and comments.
For who is not familiar with our PDP, It is organised in different phases, so the fact that the discussion phase is ended for both the proposal means that the community has ‑‑ you, as Working Group, has discussed if there was material to go ahead with eventually creating policy draft, impact analysis by the RIPE NCC, and if, and this is in case the proposal goes to review phase.
Again, I must reiterate that during review phase the comments are important. You have to repeat the comments that you made during the discussion phase because those comments are considered by the Working Group Chairs to determine if consensus has been achieved or not. So, if you don't comment, they don't know what to decide very shortly. So you have to repeat even if you participated in the discussion phase, please take part in the review phase.
And then last call is for people that missed the first two phases, and in that phase, you can submit new objections and eventually for the review of draft consensus if this was made.
In other regions. News from AFRINIC. Those three proposals that were awaiting for ratification for a long time have been ratified. The first one was already ratified long ago and is in the last phase of testing and this is regarding the RPKI ROAs for unallocated and unassigned AFRINIC address space. For some people this is also known as AS0.
And the last two ratified policies are the transfer policy. This is a new addition to the possibility to also to do inter‑RIR transfers from end to AFRINIC. You will see that there are some particular conditions there. AFRINIC will be able to transfer out of the region legacy space and a space that it received from our RIRs. And will be able to accept space from other RIRs, but details about implementation will be given by AFRINIC.
And then the abuse content policy is going to require for Inetnums, Inet6num, the availability of contact for reporting abuse in, that has to be registered in the database.
Last week, some proposals proposals were submitted, two last week, soft landing to recover the space and priority and amendment of utilisation in soft landing.
The first one is actually saying that the recovered space can be distributed following the same rules of software landing, and priority regards when this recovered resources are going to be, let's say, put in the list of assignments. So in which kind of timeline. And amendments of utilisation in soft landing is lifting the needs of utilising 90% of the resources already assigned in case of particular needs.
Then yesterday, a new policy proposal was submitted and these exactly, I think exactly the same of what we implemented a couple of years ago with NWI 19, so the new AS sets must be registered with hierarchical names. And we already implemented in our region.
In ARIN. I am always admiring that Advisory Council because they are very active. They implemented clarification of the registration service agreement is giving more flexibility to ARIN in deciding in case of transfers, which is the service agreement that can be accepted, because before there was a limitation that it was supposed to be in the last two versions.
Then we have recommended draft policy that is, that is, you can make is similar to our last call. That is requiring the space that is reserved for IPv6 transition, is requiring to use it in a region.
.
Then a couple of draft policies under discussion. There is the clarification of whether to use the word ISP or LIR in the number resource policy manual. I think there is also an agreement to use LIR instead of ISP.
Then another draft policy is suggesting to reduce the required amount of, let's say, the minimum required amount of addresses to be used in a region in order to be able to use addresses also out of region. At the time you must use at least a /22. They want to reduce it to a /24.
Fixed formula in this paragraph, and make policy to match examples in other paragraphs. The first one is the formula for defining which is the maximum allocation that can be distributed, and it looks like there was some unclarity there. The second one is, how can I say, clarifying that when you have a single site network you can receive only a /48, because at the moment the examples are only mentioning multisized networks.
Then ultimately hear more about the topic of the last policy proposal that is regarding the distribution of addresses for networks outside the world.
In APNIC all these proposals are under implementation. The first one is, let's say, taking away ‑‑ how can I say ‑‑ removing some details, contact details from the, let's say, the output of queries, bulk queries, to the Whois.
The second one is the same proposal that we have on implementation in our region.
And the third one is going to give more transparency on how the data are queried in the Whois and RDAP in APNIC.
In LACNIC, it's a big change because we have now a policy that has been ratified. This changes a lot the possibility to ‑‑ the usage that can be done of IPv4 allocation now is going to be possible to assign, sub‑assign part of the allocation to third parties. Before the ratification of this policy, it was not possible, it was supposed to be used ‑‑ an allocation was supposed to be used only for the infrastructure of the holder, and now there is an opening to sub‑assign part of it, but to a member of LACNIC with some requirements. So these members have to have an AS number, IPv6 and so on.
Then there is a policy under discussion to define much better the organisation term in the policy manual.
The usual useful links. There is the comparative policy overview that is updated periodically. And all the links to the policy proposals and the policy manuals of the other RIRs.
Then PDP document review.
As, you know, we have our PDP that is described in a document, at the moment it's RIPE 781. I made this beautiful artistic, I am proud of myself really, it's fantastic, so you can see that the PDP started to be documented in 2005 and then periodically it was reviewed.
So, it is already a while that this was not done, and now the RIPE Chair is, let's say, again reviewing the RIPE Chair team actually, is reviewing the document to see if after so much time, after four years, there is the need to make some clarification regarding the roles, the time lines and if there is something that can be made much more clear.
If you are interested in knowing how the PDP evolved through time, Niall O'Reilly, the ex Vice‑Chair RIPE Chair did a beautiful document going through the whole history, which modifications have been made through time, it's a very nice read if you are interested, and also to realise if the proposed changes, the suggested changes have been already proposed, if they can be more relevant now or not.
You are going to be asked to give feedback. Please do it because this is the way in which we are going to discuss policies in which consensus is going to be achieved or not, and you are part of it, so it's important that you participate.
With this, I think I am done, and I wonder if you have any questions.
(Applause)
FRANZISKA LICHTBLAU: Do we have questions? We have somebody lined up online: We can't hear that.
.
Do we have anything from the room? Okay, anything in the chat? No. Okay, thank you.
(Applause)
.
Next up is Marco Schmidt from RIPE NCC's Registration Services, who gives us his usual update, and for everyone who is not so deeply involved here, those are the people who actually need to implement and execute what we decide here, so their feedback is very important to us.
MARCO SCHMIDT: Good morning and thank you, Franziska. My name is Marco Schmidt, manager manager of registration services, I want to start to welcome Leslie, and thank you very much Leo for the great cooperation and looking forward to see you around here and waiting for input.
I would like to give you this regular update of observations and activities that are done by Registration Services. I want to start indeed to inform you about some activities that we have done since RIPE 91. And then talking about a topic from leasing to registration quality. And some potential need of clarification in the IPv6 policy.
But first, as I mentioned project updates, activity updates.
The first one I will keep very short because it was already presented also by my colleague at the Database Working Group, but during the last RIPE meeting in Bucharest I presented here to this Working Group the observation that some registration data, if we only published a company name and the country of legal registration, are not unique, and I suggested that we could also publish the registration number of legal organisations because we have them in our internal records. That was taken up as a numbered work item in the RIPE Database Working Group, it was received support and was eventually accepted. And in the end of April we have implemented it and as you see here, more than 33 thousand such registration numbers are now published.
I will not go much more into detail now because as I said it was already presented and also I linked here a reference to a RIPE Labs article that gives more details. I want to use the opportunity to point something out. If you yesterday attended the RIPE Services Working Group with yesterday Hans Petter said that we are want to provide services in a more agile, in a more efficient way, and I think that already, this implementation contributed to that one, so if you see just between two RIPE meetings it's implemented. We were not aiming for the gold plated perfect solution, rather publish something that as a value and that now can be tested, used by you and also giving feedback to us and we have already received quite some useful feedback and it helped us even to fix one little bug that we had noticed ourselves, so that's great. So please keep on providing us feedback and helping us to improving our service in a much more collaborative and efficient way.
The next project that also was initiated following RIPE 91 is being legacy. Just a quick recap, Legacy are resources that have been issued, provided before the RIPE NCC and the RIRs was established so, before the current policy framework. There is a policy in place for legacy resources and it also allows actually those legacy resource holders to don't enter in any contractual relationship with the RIPE NCC. Which of course causes the problem that we don't really know who is still really using them, is it the rightful holder around so on. That refers to around 40 million IP addresses, hold, according to our records by around 1600 resource holders. Then we proposed and we received your support that we actually would reach out to them to see if we can verify them and if this is done at an organisational object to those legacy resources with verified holder name. This project has started a couple of weeks ago and I want to share with you some preliminary results.
So at this moment, here is the total amount of legacy holders, a bit more than one third has been contacted. We have decided to do this in phases because of the amount and also there is different complexity involved and so far we have received response from 6 percent. That looks maybe a bit, a little bit sad, but I also have to say that a big amount of contacting emails have just been sent last week, so the responses are coming in. Also we noticed already that it can get a bit challenging to get those legacy resource holders to answer to us. Diving a bit deeper into that 6% at this moment, we have already managed to verify 18 of those legacy resource holders who are still decided to remain without contractual relationships. Another 35 actually used our outreach activity to decide to bring the resources under contract. And five even decided to convert the legacy space. And another 40 still are making up their mind.
But overall, and that's actually ‑‑ I am really happy to see that there is an increasing trend to bring legacy more in the registry system to bring it under contract or to convert, mostly to get better access to services that we provide with RPKI in particular.
So, I included some numbers there, so just in these first five months of 2026, around 200 ranges have been converted, and another 200 ranges have been brought under contract. So that is way above average of the last years. So it's a good trend.
And as it was already mentioned in the second session, there will be a proposal idea by Clara and Peter that also actually will propose something towards this goal to improve the registration quality of legacy resources.
So, the project is ongoing, we keep on to reach out and stay in contact with those legacy resources holders. At the next RIPE meeting and also in between on the mailing list I will provide more updates on how this project is ongoing.
If you want to get more details about legacy, without contract in particular, just last week a very extensive article has been published by my colleagues, it also looks at about how they are visible, what activities we see there, so it's also linked in these slides, if you download them you can get this information.
Moving on, the next topic I called it from leasing to registration quality, and what do I mean by this?
.
So far, in parts of the RIPE community and some RIPE members, RIPE NCC members, use the term "Leasing" quite heavily when they promote their businesses. And if you look up general definitions what leasing actually is, you find something like what I posted here, so they are basically two parties, an offering party provides for a defined period, again some payment, assets of resources to a receiving party, but the holdership, the ownership stays with the offering party. And in February, there was an e‑mail sent to the Address Policy Working Group mailing list by James Kennedy raising some concerns that there might be some quality issues, there might be some also transparency gap with this type of service provision. And that's why the Working Group Chairs reached out to the RIPE NCC if we can confirm this from our side.
And I have to be honest, I am always struggling a little bit when the term "Leasing" is used in the Internet numbers world, because it's not really formally defined yet by any policy. And so we did look in some data, or in some registration data of members that use the term "Leasing" for their outreach and marketing activities and we have to say we didn't find anything extraordinary there, some do a very good job, some others have room to to improve. But let's say it was nothing exclusively related to something that was framed as leasing.
And actually, the RIPE policies, they do have several concepts, non‑commercial concepts, leasing is more really a business relation, that also referred to temporary provision of IP ranges. You probably know them, assignments, sub‑allocations and transfers. Temporarily transfers.
And intentionally, there is no mentioning of a contractual relationship because until now, that's not really in the scope of the RIPE database to identify what relationship two parties have.
But what is in the scope very clearly, it's also what James actually pointed out, there should be a good way to reach out the responsible party that is managing, that is using a network. So that's also mentioned in the IPv4 policy, and which I quoted here and also in the IPv6.
So, we decided to look a little bit to take a step back, leaving aside for the moment and look a bit what numbers we see there on this existing concept. So assignments, sub‑allocations and temporary transfers, we looked at total numbers, we looked at how much the RIPE NCC is actually involved, and the Abuse‑c contact, which is let's say the most obvious if you want to reach somebody for some issues that are observed. And overall, estimation of the quality of those entries.
So, you see here that assignments of course, they take the biggest chunk, so we have almost 4 million peer assignment in IPv4 allocations, and almost 1 million in IPv6 allocations. Sub‑allocations it's less, around 20 K in IPv4 allocations and a bit more in IPv6 allocations. Temporary transfers are significantly lower, a bit more than 500 at this stage. Medium regarding the RIPE NCC involvement, maybe starting with the temporary transfers, they are obviously very strongly involved because such temporary transfers only can be done with the RIPE NCC's approval, like any other resource transfer. So we make sure we perform all our due diligence.
For assignments and sub‑allocation, it's different because it's intentionally that this is actually to be created by our members within the allocations, to indicate networks. And we only look at them when we perform an audit or an ARC, so assisted register check.
Looking at the Abuse‑c validation, because there is a policy that requires us to validate Abuse‑c contacts. It's first important to mention that for assignments and sub‑allocations it is not mandatory to add a specific Abuse‑c contact, but if it's there, we also validate it annually, and if we feel it's not working, we start an automated process to inform the responsible party that it should be fixed. But once the automated process is ended, we don't enforce it for assignments and sub‑allocations, rather we make a remark in the RIPE database that it seems to be not working and refer to the abuse contact of the member that we have validated. Of course for temporary transfers, that refers to allocations or independent assignments, we make sure that those abuse contacts are working.
Which brings me to the most important point, what can we actually say about quality of those database entries? And for temporary transfers we have pretty confident because we are strongly involved. For assignments and sub‑allocations we have to use some indications, because we have a lower involvement there, but looking at the ARCs that we perform, in around one third of those ARCs we do find issues that either the assignment information is outdated or there are even assignments not needed anymore, on the other hand it's even missing. So it points to some bigger issues there and it's also supported by additional observations. To the younger people in the room, I want to just point out that until 2012, until September 2012, the RIPE NCC used to have lots of IPv4 and we gave larger ranges to members that needed them, and if they could justify their need. And how they justified that need, they created assignments in the existing allocations and when there was enough usage, they could come back for more.
.
So we had to look at them and actually looking at those assignments that have been created before October 2012, 75% have been changed since then. And I am not sure about you, but I have to suspect that quite some of them are not exactly accurate anymore. Some for sure might be but there is a lot of old and not current ‑‑ well outdated information.
On the other hand, for newer IPv4 and IPv6 allocations, often members, newer members are not really aware about the purpose to create more specific assignments, objects in the allocations, or they also think anyhow that's all my business or I shouldn't do anything there. But these two, these two effects actually impact negatively the quality of the registration data.
Subsequently, to reach the responsible parties.
So, the questions, or the considerations that I want to put here in the room that do the existing concepts actually need a review, especially in terms of getting good data, current data?
.
Should it be, or could it be an idea to make this more specific entries only if the operational accountability is no longer with the member or rather they handed it over, with you but then also make sure that it is maintained and it's accurate? And just talking about IPv4, just this morning, he had actually mentioned in the Database Working Group there is this option of creating aggregated by LIR, also for IPv4, but so far I think it's only 700 objects so that might be and idea for members to create such objects for all the networks that that are not their responsibility.
Of course, also, coming back to the beginning of this topic, should maybe contractual relationships somehow document it or present it in the RIPE Database?
.
Coming to my last point, it's a bit a shorter point about IPv6, especially the IPv6 policy that is out there already since 2002. It was created over a joint community discussion of the three RIRs back then that existed. So, APNIC, ARIN and the RIPE communities.
And since then, around, or exactly 20 changes have been made to this document. Which shows it is a live document, as it should be, the policy evolves and improves if there is a need.
But what happened, I listed here some changes, that happened over the years. The allocation size has been adapted, how you can justify for larger blocks, the PI concept was introduced, but what has ‑‑ parts that don't have changed over the last 20 years and still have the old wording is what happened after we provided those resources. And there is still the wording there from 2002, and this sometimes lack clarity, also are consistent with newer wording added. To give you two examples just, the term "Audit" is mentioned twice in the IPv6 policy, in reference to making assignments and to aggregations. But there is not a clear reference to the audit procedure as we actually have in the IPv4 policy. That's also the reason why I include it this here because I informed the Working Group a little while ago that we started to perform some audits of members that hold a loss of IPv6 allocations, then of course they come with a question where is this covered? It is there but it's not as specific as I would like, for example.
And the same about policy requirements, policy compliance requirements, and what to do, when there is policy compliance missing or incomplete.
And this wording, I am not reading it out, is from 2002, it uses terms that licence and good faith and bad faith and renewing it, that is not really out there anymore in other policy documents.
So, something that I wanted to ask the audience here, so, should, while actually everything is in the current IPv6 policy regarding the resource lifecycle, is there maybe a need to make it more clear and more consistent, and if you would agree with that, the RIPE NCC could author or co‑author such a policy proposal because it's no so much a content change rather a clarification change.
And that brings me to the end of my presentation, and I would welcome any questions, comments, and just pointed out here the three topics that I raised, the projects, the registration concepts and IPv6 policy.
FRANZISKA LICHTBLAU: Thank you, Marco.
AUDIENCE SPEAKER: Gert Döring: Thanks for bringing back the results on talking to the legacy holders; around I am actually quite happy to see that the carrot seems to be working reasonably well. It seems to have an effect they are not ignoring you, they bringing the addresses in the system and documentation improves. Which is slightly different picture than the one painted yesterday with all these stupid legacy holders, it is so unfair and we need to go fight them. So thanks.
AUDIENCE SPEAKER: On the topic of leasing. Prefix brokers don't make assignments for the prefixes they lease out to customers, this makes it increasingly difficult for network operators to identify customers when BGP sessions fail. It is impossible to contact prefix brokers in the middle of the night to ask who their customer is. We had a work route in place to mandate our customers to use the description field in route objects to identify for which customer we should route the prefix. But since some months the description field in route objects is dummified for privacy regions. We don't understand why or how a voluntary field should be dummified it brings operational security risks. What would be a solution to identify users of leased address space, can we please refer to dummification for descriptions in route objects if assignments for prefix brokers cannot be mandated.
MARCO SCHMIDT: Thank you, and having those observations applied to all kind of assignments, because again leasing, some people use it, but I think it's a general good observation for all kinds of entries, yeah.
AUDIENCE SPEAKER: I see there is a big variety of documentation of IPv4 assignments between various ISPs. Some ISPs, especially the ones which are for business, in business for quite a while, tend to put every /26, /27, /28 or whatever they assign to their business customer with a static IP in the RIPE Database as we do at the moment, but I see also an increasing number of ISPs not documenting those small assignments and just put a big like 22 in the database and that's like yeah, statically assigned to business customers and that's it. But I also bring up the question, what's the benefit of having that customer in there, like it is assigned to a random company somewhere in the middle of nowhere? What are we going to do with that data? Geolocation isn't working that well anymore based on these objects, and also trying to get a hold of the company is not really working anymore, because usually Admin C and Tech C and offer Abuse‑c is still with the ISP because they are managing the backbone the customer is connected to. So, it only gives you a rough indication who you are talking to on the other end of the IP address. But I would like to see some clarification there to get it back to a level where everyone agrees on what we want to have in the database there.
MARCO SCHMIDT: I think that is in line also what I highlighted, reaching the one that is responsible for running that network, like in your case, would be the ISP.
AUDIENCE SPEAKER: Just a remark, I want to thank you on the work you are doing on the legacy resources, also I am from Europol ‑‑ for the record ‑‑ I also work on these proposal from James, these remarks on the leasing, because we, as Europol, we want to stress the importance of contactability and accountability, which is not only technical but we have to be able to contact some in any case, even if they have a problem themselves, even if you won't help them, if it compromises resources or whatever we want to be able to contact them. So I welcome this work you are doing, especially on the legacy resources, but I think something can be done also on the leasing so if the contract is stated in the database it will be helpful for us. Let's see how it can be done and we are able to help you if you want. Thank you.
FRANZISKA LICHTBLAU: With that, thank you Marco.
(Applause)
.
Our last presentation for this session is joining us remotely. It is Tony Li with IP addressing for outer space. And I would I like to highlight that we started this discussion already on the mailing list, or Tony started it, and we had the feeling the Working Group was not very clear on what this is, the scope and what this is actually about, so we are very happy that Tony can now clarify that for us and I would encourage everyone to use the opportunity to come to the microphone in the end and actually have a discussion about that.
TONY LI: Thank you very much. It's 4 a.m. here, so if I fall asleep while I am talking, somebody please yell and me and wake me up.
Today's talk is about work that we are doing in the TIPTOP Working Group in IETF.
.
As you may have noticed, the economics have space travelled, or shifted, and we are very much, once again, exploring space, and what we're trying to do in TIPTOP is to extend the Internet out it into space. We very much need to think about addressing, and we very much wanted to aggregate. We have a draft with all of the details, please feel free to take a look at it.
The gist of it is pretty simple. Right now, there is no official RIR for outer space, only for earth continents. And we have an assignment from Antarctica to ARIN but that's the basic layout of things. There is nothing to be done for ‑‑ nothing is currently signed for outer space and we'd like to change that.
.
Right now, space agencies are going to their local RIR because those are international organisations, we end up with address space from all over the place, and that means we can't do any kind of aggregation. That's a problem. We'd really like routing to be efficient in space. Resources are very limited, and we really, really need things to be compressed.
So what we'd like to do is to have one RIR and one address block for outer space. For legacy reasons, we have been talking to ARIN about this, but it could be any RIR and certainly ARIN is not locked in at this point. If RIPE would like to do this, we can certainly talk about that.
.
I am very much looking for your feedback ongoing in this direction.
What we're proposing is one block for all of outer space, and within that block, we'd like to assign a prefix for the moon. Each planet other than earth, points, the Asteroid belt maybe, but there is some discussion about that. And then as we grow out into the solar system, other areas.
.
The space agencies have generally been cooperative. They certainly expect to interconnect in space, and for them this is actually very important. Communications is mission critical, quite literally, and so interconnecting for them minimises costs, maximizes resilience, and communications obviously are life critical for them. So, resilience is extremely important. So they very much want to interconnect and do so as much as possible and so they are very considered in aggregating. And so one prefix per planet would actually minimise their costs.
The draft that we are proposing enables aggregation, it does not mandate it.
We are proposing doing this for both IPv4 and IPv6. We are very bandwidth constrained. Analytics to Roacheers, if you don't go through relay are in the order of 5 hundred bits per second that's down in modem land. And when with this mission critical since how they communicate and control Roacheers so this is absolutely monitor to them, so IPv6 overhead is very much a serious concern, and so some mission planners would very much like to avoid that cost. So, that they have selected IPv4 previously and it's likely that they will do so in the future for short‑term uses.
.
Longer term, when we start talking about colonisation, obviously we'd kind of like to do picks because we don't want to be in a position we we have to re‑number things in space. We'd like to enable aggregation for obviously both IPv4 and IPv6. Support IPv4 does not require a full IPv4 block. The address space needs are really quite modest for the foreseeable future something like a reclaimed /16 might suffice.
That's the guts of the proposal. Any questions?
FRANZISKA LICHTBLAU: Thank you.
AUDIENCE SPEAKER: Warren, Google. Thank you for writing this I have been meaning to reach out to you and chat for for a while. Jen and I are actually planning on writing a sort of slight, slightly different document, which would request the IANA to set aside a large block for space, and then the various RIRs can draw from that space specifically for space use. The RIRs can then decide to, you know, figure out whatever policy they want so they could for example say use this block on this planet body or not. That means you don't actually get a single prefix per body, maybe you end up with five but that's still nicely aggregatable. I still think it is useful for there there to be a specific block for space use because your stack should know this packet potentially is going to have a really long round trip time, your stack can behave differently etc. Some of my concerns with there just being one RIR is no matter where you put it, no matter where it's homed, there is going to be some set of countries that aren't going to fall into a reasonable thing. You put it in US, they won't deal with Syria. You put it China, they won't deal with some other country. We have already got an RIR system that has members and has figured out how to deal with these sorts of policies. I think we should just sort of propagate that. So again, one big block at the IANA, RIRs, when they get a request for space use can go, you know, Dear IANA, we need a block for this and then sub‑allocate from that.
I had one other point which I was all riled up about, but I forget it so I'll go to the back of the queue.
TONY LI: Thank you, the concern with that it we would end up with five prefixes per planet and there is some concerns about how well that would aggregate. So we'd really like to have one prefix per planet.
JOB SNIJDERS: Job Snijders, speaking for Job Snijders. I am not optimistic about the potential for aggregation here. Time after time, aggregation based on geography has proven not really to work well in practice and people start poking holes in it and then the holes leak out somehow. It goes not really a thing. In fact I would say it is very naive to operate on that assumption that there could be one prefix per planet aggregation.
So, from this perspective, I think the initiate is lucky if it gets five prefixes per planet, over time humans are going to human.
As for using v4 in space, I am like guys, really, really, is that the state of the hardware blasting into space?
.
If the overheads is a concern, there are many compression algorithms you can apply on the link layer, and this is a well understood problem space, so this reasoning I reject it fully.
So I like Warren's approach of getting a block from IANA for space, but I think the v4, I would drop it from the slides. Thank you.
TONY LI: Thank you, I disagree.
FRANZISKA LICHTBLAU: We'll take a question from the chat first.
AUDIENCE MEMBER: Maximilian says "why RIPE and not IANA, I oppose reserving additional IPv4, IPv6, sure".
AUDIENCE SPEAKER: When I saw your slide about the allocation to specific areas, I was still wondering we do have areas which are also international waters and where do you start with space because technically you also have satellite to satellite communication, would that also apply under your proposal?
TONY LI: So, international waters is absolutely not part of this proposal. I don't know how you want to deal with that. But not something I am trying to tackle.
AUDIENCE SPEAKER: If you are concerned about aggregation, you could still do one prefix per planet from IANA, and then sub‑allocate that per RIR. But still then you would have multiple announcements per planet going into the BGP. So I'm not too sure that would even fulfil the point of aggregating stuff there. And I also oppose the idea to have one RIR, because currently everyone has an agreement with their local RIR and having sub‑assignments from RIR per planet to an RIR shouldn't be a big problem, but would help members not having issues with dealing with multiple RIRs then, or at least two, where they have, might have contractual problems as we see with current RIPE members.
TONY LI: Thank you. Noted.
AUDIENCE SPEAKER: Peter Koch: On v4 in space, I believe there is an international convention about it kind of hygiene, so not to poison remote planets with unwanted life forms. No, seriously. But I think that can be extended to v4 in the spirit.
.
More seriously on the other points. I am wondering what we currently have is globally routed IPv6, and I am wondering how globally would extend to space, so that would probably suggest getting another slice but not from the IANA because it doesn't have it yet, it would have been the address space that isn't yet assigned logically. And then the question of the RIRs, given the other presentations about ICP‑2 and such, I don't think that policy wise that is usefully captured by either picking one, adding another one or distributing it across the five we have for reasons of policy coordination and the dedicating of a new slice of protocol parameter actually might help you with that. But that's not an engineering problem in the first place. Thank you.
BRIAN NISBET: So, a huge fan and all as I am of the bottom up process and things like that, this seems like an NRO conversation rather than individual Working Group, or individual policy group in each RIR conversation. I mean I think, I can't see how one RIR undercurrent geopolitics could serve this particular role, so I kind of like the IANA idea, even though that comes with its own complexities but I just think that this should be a conversation that the RIRs should be having at a senior management level with each other rather than necessarily each group kind of giving its own opinion. Thank you.
TONY LI: Thank you, I have submitted this to NRO and have not heard back.
GERT DÖRING: I just need to disagree with Brian, because I can, But that wasn't the point why I am here. So I discussed this with Warren on the last coffee break because I thought let's see what we can do here to proceed in a good way.
From the geopolitics, from the way the policies have been written down over the last years, this is a bit of a complex issue to tackle because we have written down what we do and this is not what we do so we need to change the text of that.
I think the idea that Warren brought with having an idea, starting with an idea of document that tells IANA here is a block, use that for space, is one of the definitely necessary things to actually get started. If we have no addresses, there is no way to distribute them.
And this is where I disagree with Brian. We have policies that write down how we do IPv6 distribution, so this text needs adjustment. If we, as the Address Policy Working Group agree that this is a useful thing to do. If we write it down formally and we do something new we have to adjust the formal thing that we have written down. An on the NRO level, of course there is the global policy paper that also needs twisting. But first we need addresses. Otherwise this is all a bit weird. So that's doable but tricky.
AUDIENCE SPEAKER: Warren here again. Answering two different things. A couple of people have said why not just make this completely the IANA's problem? I had a chat with Kim Davis at IANA and others and I don't think that's the right approach because potentially they are going to be a lot of requests, and, you know, there is already a membership community here, there are already people who discuss policy. Being able to reuse that seems like a great advantage. It's also clear who, you know, who your particular RIR is in a region.
The reason I originally got up here, though, is earlier in the week the IAB did a whole thing object operator outreach and this is exactly the sort of input that we think is really helpful. There are people in this community who thought about addressing policy, who understand Address Policy and so we like these sort of people to participate and make your views known to we can learn from you. That's all.
FRANZISKA LICHTBLAU: Thank you, I am not sure who was first. Stephen.
AUDIENCE SPEAKER: Stephen: We are not in space, but I think this is super interesting stuff. I agree with carving out space at the IANA level. I don't believe that with the geopolitics behind space that we would get to one uniform registry for space. But it does bring me to the question of you put up a slide on corporation in space and use the ISS as an example. I am not optimistic about that future. The ISS is going to be deorbited in five years or so. We have China operating in space, we have Russia about to put up its own space station, we have India. We have different levels of cooperation in space, and so I feel perhaps we are going to wind up with a multiRIR setup for any extra planetary Internet that we end up with.
I guess the question that comes out of that is: I haven't been following the TIPTOP work. Are the various space agencies or their relate the governments engaged in this? If they are I definitely feel like they should be
.
TONY LI: Earth very much is in space, so it does count. Yes, space agencies are trying to interoperate with TIPTOP, we are trying to get them involved and there is some challenges with that but we are trying to get them kicking and screaming to participate with us.
AUDIENCE SPEAKER: Erik, Cisco, but mainly the responsible RIR director for the TIPTOP working at the IETF. Thank you Tony for being at 4 a.m. Like Warren said it's nice that we get this discussion here, because this community has got input that the IETF doesn't have and vice versa.
To the point of space agency that the question just before. They do not directly interact with TIPTOP, but they use contractors and the system integrator, basically by interacting in TIPTOP, just to be clear on this one.
And finally, the document from Tony is currently under call for adoption which is a first step in the IETF process. And it will be changing after.
So feel free to join the discussion on the IETF document, and basically the discussion here needs to continue. Thank you. And thank you Tony again.
FRANZISKA LICHTBLAU: Thanks for clarifying because that's something that we have been discussing if the stakeholders are actually in the room that would have interest in that and I think your hint is really helpful.
AUDIENCE SPEAKER: Thank you, John Curran, CEO of ARIN. Tony, thank you for presenting this to RIPE, it's very important. I just want to clarify one thing about ARIN serving as the outer space RIR.
This only came up because as a policy proposal in the ARIN region, ARIN 2026‑1, because our community was discussing that they asked for staff and legal assessment, equivalent to your policy impact statements. So we had to respond, as the organisation, so the community would understand what happens if they adopted a policy, and so we responded and we said there are some issues with this policy, obviously, someone has to understand what the benefits are and how aggregation would be achieved. But let's talk about preliminaries. Lets talk about implementation, if it was implemented it requires a block to be allocated by the IETF. It requires some way for the IANA to indicate that it would like the RIRs to provide service to say this block. It requires the ARIN Board to decide it wishes to serve entities outside of our classic region. That's not automatic. And we have done it before, when ARIN was formed our region was everything not RIPE and APNIC. So it's everything not RIPE and APNIC if the Board says the community wants it, we could do it.
That's not excitement about doing it's just saying it's a potential and it's a role we have served before.
The last part is it requires consent of the other RIRs that it wants ARIN to serve in this capacity. There is a number of ways services to such a block could be provided. A global policy could allocate is in slices to each RIR and have it issued respectively, it could done by one RIR. It's attached to draft policy 2601 on the ARIN website. I just wanted to clarify what the position was because there might be some confusion, we haven't jumped up and down and said we want to be the space RIR, we're responding to a community policy draft. Thank you.
FRANZISKA LICHTBLAU: Thanks for the context.
AUDIENCE SPEAKER: Tony, first of all, thank you so much for my quote of the week, earth is in space. I find that amazing. Thank you. I never considered that.
.
Now, on to more serious bits.
So, one of the things that, as we go through the listing of space going countries, I can't escape the notion that in the real world mostly all of them and John, I hope you ‑‑ I apologise for the analogy, effectively have their own national Internet registries as is. And for them to pick up new address space would require them to go outside of the legacy holders LIRs that they have set up themselves because they felt they needed them. I would very much like to see how that dynamic would work.
Secondly, I think that doing this, and being able to aggregate address space in outer space would only serve a purpose if you actually also had inter‑connection in outer space locked down, because there would be no point in aggregating address space if everyone was going to trombone their traffic back to planet earth. I think that that, especially in, probably going to be slightly competitive arena exploring outer space, if I have ever seen any scifi series about it it's not going to be all shiny happy, I think that that needs to be a critical part of how we're going to do not just addressing but also routing in outer space. Thank you.
TONY LI: Yes, absolutely, we expect to have communications between planets. For example, we would expect eventually to have a link between the moon and mars, and that's where we'd like to have one prefix in each direction.
AUDIENCE SPEAKER: I couldn't agree more Tony, but I mean it's not just mars, it is China on mars, it is Russia on mars, it is the US on mars, and I don't currently see them actually even in our current tiny piece of space, using interoperability and routing between each other and frankly, I would be terribly surprised if that would be any different for something that would be strategically more important.
TONY LI: We are trying to encourage them to interconnect and operate, and giving them aggregatable addressing helps.
AUDIENCE SPEAKER: Warren, Google again. Thank you again very much Tony for writing this and presenting it and being willing to be awake early in the morning.
I agree that at the moment, you know, countries aren't initially interconnecting and maybe we won't soon for inter planetary stuff. Eventually they will, maybe not five or ten years but eventually. So I think it is important for us to have set aside address space and make this easy.
Why I originally got up though was to mention if people are following this work in TIPTOP, there is also another Working Group called space research group that has sort of much higher level stuff and much wider participation from sort of newer things. So if people want to follow it, please do that as well. And also, as I mentioned, Jen and I remember in the process of writing a document, you know, who knows what will happen, but if there are people who know a bunch about Address Policy and want to help, please come along and chat about possibly being an author. Will also thanks again, Tony.
FRANZISKA LICHTBLAU: Thank you. Maybe you want to post that to the list as well so everyone has the reference.
TONY LI: Thank you very much.
FRANZISKA LICHTBLAU: Okay. I don't think we have anything online anymore. Everyone here is out discussed. Then thank you, Tony, Thanks for staying up late for us and presenting this.
(Applause)
.
FRANZISKA LICHTBLAU: Okay. And with that, I give you five minutes back, I would like you to ‑‑ I would like to remind you that you can still vote for the Programme Committee until five o'clock today, there are two seats open. We have an amazing set of candidates. Have a look at the website, cast your votes so that the PC may resume excellent work next time, and I'll see you all back at two o'clock after lunch. And of course, rate the talks.
(Lunch break)