RIPE 93
Main hall
29 October 2026
11 a.m.
Address Policy Working Group it
FRANZISKA LICHTBLAU: Hello everyone. Welcome to the first session of Address Policy at RIPE 93. I am Franziska, Alex my co‑Chair is here. And Leslie, sadly, this time, can't join us but she is going to go back at RIPE 94 with us.
Without further ado, we'll get started.
Let's get the housekeeping out of the way. We still the post coffee slot, let's see how long that will hold, because there are vital discussions about this. So, as usual, this is a hybrid session, you can participate over Meetecho, you can either use the Q&A function or you can add yourself to the queue and actually voice your questions and comments via the microphone, or you can join here in person, we have as usual the microphones distributed over the room. Please remember to state your name and affiliation relevant for this Working Group.
As with all other RIPE related events, meetings, the Code of Conduct is supplied, please make sure you conduct yourself in a way that makes everyone feel welcome and let's keep our conversations polite and treat each other with respect.
As usual, thanks a lot to the stenographers and the scribes who will keep records of your session, and actually thank you Leo to making sure I can actually now see these notes as well, because you have been talking about that for a while and I now get to profit from that.
So, as any avid follower of the RIPE address policy mailing list we made a slight lapse of sending out the minutes of RIPE 92 a bit late but I am sure you all took the time to review them because we didn't get any comments.
Thanks Antony for compiling them. And I assume, as we didn't get any comments to the contrary, we can accept the minutes as final, Unless anyone in this room objects?
.
That is fine.
Then, let's jump into what we are actually doing here today. As usual, we still have two slots. We start in this session, 11 until 12:30, then we have a lunch break and we jump to the next session.
So, today, we have first we welcome you to the session and explain how all of this works, that's what I'm doing now. Then we have Angela from the Policy Officer from the RIPE NCC giving the policy update of what's going on in the policy world of the other RIRs as well as RIPE.
Then we have Herve who is giving us the update on the ASO AC and what they have been doing, I am curious if there is anything going on with ICP‑2. And then we will have a slight change in agenda, we will keep Marco from the RIPE NCC to give us his registration service update at this slot. But then we will switch the next two presentations around so Marco actually gets to sit down in the middle and Leo will update us on the policy proposal 2601, simplify assignment of first ASNs. And then Marco will come with 2603, IPv6 policy clarification which has been posted to the list quite recently. And with that then we go to lunch and the agenda in the second session stays as we announced it. We have Remco talking on a potential way to move towards a RIPE policy manual. And then about his most favourite topic, IPv6 and space. And we close with James, who wants to talk about IPv4 PA space in the RIPE Database.
That will close the presentations, but as usual, we keep time aside for anything you want to voice to the Working Group, so if you have any of questions, concerns, comments, make sure you add yourself to the virtual or physical microphone and let us know what's going on.
Otherwise, as usual, RIPE Working Groups work mailing list based, so make sure you are subscribed to the list, you actually see what's going on there because this is where we make the actual discussions and decisions, and otherwise, after that, we will see you in Vilnius, but for that, that will be at the end of the next session.
So, with that, I think I will hand over to Angela.
ANGELA DALL'ARA: Thank you. Good morning everyone. For anyone who doesn't know me, I am Angela, Policy Officer at RIPE NCC, and my main task is to take care of assisting the community through the policy development process.
So let me know if I'm fading away or if you can't hear me well.
What are we going to hear today, as usual what happened since the last time we saw each other in Edinburgh at RIPE 92.
Then what has been changed since then in other regions? And what is under discussion in these days in all RIRs?
.
In our region, as, you know, we implemented a new policy that is revocating persistently non‑functional delegated RPKI CAs. It was effected in June, and there is now also a new version of the terms and conditions for the RIPE NCC certification repository. More details have been given on Tuesday by Tim, and the good thing is that now RIPE NCC is going to inform timely the operators of CAs that are appearing not to be functional after seven days, after 30 days and after 60 days of inactivity. So that if you are running one of those check that things are in order and if not you should have the time to fix things or remove them.
Then we had a couple of policies last time that have been withdrawn. The first one is, was ASN assignment criteria revisited, but it has been sort of revisited in the new policy that Leo will present later, and of course, you have to check what are the proposed changes and please, as I always invite you to do, be ready to comment and say if you agree or not with the proposal.
Then we had another policy proposal, 2024‑01, that was withdrawn by the proposer in September 2026.
What do we have on the table at the moment? We have the proposal of Leo that you will hear about later, to simplify the assignment of the first ASN. If this policy is accepted, it is going to modify the current policy for the assignment of autonomous systems, and this one is in the review phase, I will tell you a bit later what is the difference between the other two that are just being submitted in the discussion phase.
The first one is under discussion in the Security Working Group. There was a presentation in that Working Group a couple of days ago, and it is a contractual accountability framework for infrastructure level network abuse. It's going to be a new policy. So if it is accepted, whichever version it's going to be, because it appears that a new version is possibly to come up, it's going to be a new document. So, a new policy.
And the other one is from Marco, that is clarifying audit and policy compliance frameworks for IPv6 policies.
If that policy, that proposal is going to be accepted, that is going to modify the current policy regarding IPv6 address allocation and assignments. Marco will tell you everything later.
So there is a difference between phases in our PDP. I would like to remind you that the discussion phase is the moment in which a draft ‑‑ not a draft, but actually a proposal is submitted for discussion, it's the moment to provide comments, to help the proposer modifying and optimising and refining the proposal. And it's very important to see if there is actually material for going to the review phase. The review phase is going to be the phase where you are asked to provide comments and repeat eventually your comments that you made during the discussion phase, because the comments during that phase are going to be used by the Working Group Chairs to decide if there is rough consensus or not.
The difference is also that at the end, if there is a decision to go to the review phase, the RIPE NCC is going to produce an impact analysis, and I would like to clarify a bit what is this impact analysis. It's not the opinion of the RIPE NCC on the policy, because the RIPE NCC of course implements what the community wants, but it is just explaining what the impact on the organisation is going to be. So sometimes it's possible that the RIPE NCC also makes questions because it can find some issues in how to implement the policy in case the policy is accepted. So it's possible that we ask also for clarification regarding some parts of the policy.
.
So, at that point, it's time to reanalyse the policy proposal and the impact analysis to see if it can be refined to allow the RIPE NCC to proceed with its implementation and set up the procedures to implement the policies.
So as you see now, we have two policy proposals in discussion phase and the one of Leo already went to review phase. You find an impact analysis under the policy proposal text, so, please read it, provide, in all policies, but especially in this one in review phase, provide your comments, and help, you know, the development of this proposal.
Also help the Working Group Chairs to understand if you like it or not.
Just to finish the description for who is not familiar. At the end of the review phase, if there is the decision to declare rough consensus on the policy ‑‑ on the proposal, the proposal will go to last call. Last call is reserved for new objections. All the observations must be addressed by the proposer during the discussion, if there are no comments during the last call it means that rough consensus has been confirmed.
So, what happened in other regions since we met in Edinburgh?
.
We have new policies implemented and a couple that are awaiting implementation. I just give you a couple of numbers. So you see how much activity there was.
Nice to note that APNIC is the only one that implemented a policy. If you want to have a look a bit more in detail, we have six policy proposals awaiting implementation that are actually have been already ratified in AFRINIC. And let's say, the topics are two about IPv4, because AFRINIC recovered some space and they had already a policy regarding how to assign and allocate the last /8, but now that they have new space available they had to decide if the rules for that space, the last /8 are still valid can you applied or not. And these two policies are regarding that pool.
The second one is, let's say, making ‑‑ is softening a bit the utilisation requirement for requiring additional space.
.
Interestingly enough in the database, a policy proposal that was already accepted in our ‑‑ they have a policy proposal that was in our region was accepted as numbered work item, they have the requirement of creating a new AS‑Set with a hierarchical name. There was a nice presentation this morning in the database by James, if you want to have more technical details, I refer you to that, and to see which are the advantages of that.
Then they have policy the abuse management transfer. Interesting to know that transfers outgoing from the AFRINIC region are only regarding legacy space and space received from other RIRs. They can accept all the space from other RIRs.
Still in implementation already for a while is the policy that is regarding the IS 0, so the creation of ROAs for unallocated space in RPKI with a specific zero that is making them actually invalid for routing.
In APNIC, the implemented already a new service. Now, all the members can see how their resources were queried in Whois, and it's a good service for having an idea how much interest or how much not so nice interest there is for the resources of each member. And under implementation, there is the removal of some personal data from the bulk query in Whois, and the similar proposal that we implemented recently, the revocation of persistently non‑functional RPKI certification authorities.
In LACNIC, a big change. Now, it is under implementation, they announced that they should be read around the end of the year. Now, part of the allocation can be sub‑allocated to third parties, as long as they are members. Consult so at the moment it's still under implementation, so there are some requirements for the receiving party of this sub‑allocations.
Under discussion in different regions, to make Franziska happy, I have a sort of summary that can show you a bit which are the topics that are under discussion. You can see what is, what are the common ones and what are the peculiar ones for each RIR. And I am being a bis fast, for example IPv4 is in discussion in ARIN, AFRINIC and APNIC. Then we have IPv6 in our region and APNIC. Then we have abuse management that is having three proposals in APNIC and one in our region. And the PDP is under review in many of the LIRs, especially in AFRINIC because they are actually reviewing the whole process.
Then I have a nice set of slides where you can find all the proposals and what can be more interesting for you to join in the discussion because all the communities are open to everybody no matter where you live. This is the list of what is under discussion in AFRINIC. Then we have what is under discussion in APNIC. As you see, there is still attention for IPv4, IPv4 is still a hot topic in some RIRs but in APNIC, there is also some effort to make IPv6 utilisation an assignment, an allocation a bit more flexible.
Then in ARIN, ARIN is always busy trying to review the policy manual that they have, and there was this, in this period particular attention for out of region an in region usage. You see there is a policy proposal in last call, that is let's say reserving the IPv4 that is testing for the transition to IPv6, there is the requirement to use it in region. And to change how much in the second policy, how much of your space you must use in a region to qualify for additional resources. At the moment it's /22. They want to go to ‑‑ it's going to go, if it's accepted, it to /24 to favour the operators that have not a lot of space.
.
And in LACNIC, they are ‑‑ it's interesting to see what they are proposing, the community is proposing to recover unjustified legacy resources, so they are trying to give the possibility to legacy resources to justify their usage and to become members of LACNIC, and otherwise LACNIC might have the authority to recover the resources. Interesting for us is that if the policy about transfers goes ahead, we might, as RIPE NCC, be required to ask for a justification need whenever you have, whenever you receive space from LACNIC. This is similar to what happened with the transfer, so incoming to RIPE NCC, incoming transfer from ARIN, this is going to be a similar procedure.
Usual slide where you can find all the details about all these policies, and the policy manual. So how do they fit in the policy manual. If you have any questions, you can grab me in the corridor, you can send an e‑mail to pdo@ripe.net or you can ask me a question now.
Applause)
FRANZISKA LICHTBLAU: Anyone? Do we have anyone online? Okay..
And next up is Herve with the ASO AC activity report.
HERVE CLEMENT: Thank you. Good day everyone. So, I am here to present you the ASO AC regular and usual activities because as you say, you could have imagined that in three years ICP‑2 could be our only passion, but that's not the only thing we do and we do other things.
.
I am Herve, Constanze and Andrei are there also from the RIPE NCC region, members of this Council.
Finally, to go to the basis, the ASO AC, what it is. It's an organisation of the ICANN dealing with numbering, addressing on something like that. Two parts of the ASO. The NRO NC comprises of the COs of the regions, so you are lucky enough to have all the COs here on site in Sofia and us, the NRO NC, 15 people, are coming from the different regions.
What do we do? We don't only do ICP‑2, but we invite the ICANN Board, normally we meet once during one the ICANN meeting during the year, so the first ICANN meeting next year will be Lisbon in March, it's an opportunity for the ASO AC to meet in person, because each year we have new people in the Council. We oversee the global policy development process and I will speak a little about that later. In the ICANN there is a board of the ICANN comprises approximately 20 members and we appoint 2, the seat 9 and the seat 10, I will have a slide about that. We appoint somebody to the ICANN Nominating Committee also.
.
We meet monthly, but we talk about that also. And this year of course ICP‑2, you will be lucky enough in the Community Plenary this afternoon to have the three of us on stage explaining perhaps for the last time what we did on ICP‑2.
Seat 9 on development policy process one more time.
I think it was since December 2021, we were not complete in the Council because of the event from the AFRINIC, but last year, the Executive Board of the AFRINIC that was elected, newly elected appointed Saul to the Council and it was in June during the AFRINIC 47, Mussa has been elected also from the community. So we have 15 now
Transparency is very important for us because ‑‑ and it was important for the ICP‑2 ‑‑ but important globally. We meet remotely face to face every month, not face to face, but remotely. For that you can go to the ASO AC website. You have the date of the monthly meeting. Everybody here can attend this meeting as an observer. We are sometimes closed for a specific issue regarding election and so, but the main part of the meetings are open. The
.
We normally meet once, generally during the first ICANN meeting and the dedicated meetings are open also. There has been, during the last year more meetings about ICP‑2 and there were closed session because there was difficult discussion but normally it's not the case and we have definitely open session. You can find the mailing list on the website, the open mailing list also.
There is a monthly teleconference.
In 2026 we work ‑‑ in fact we didn't work specifically on global policy development process, but there is, from the region, one person of the Council looking for the discussion about the discussions, so regarding what Angela presented, for instance, just before, which is very useful, by the way, and if we see something that could be potential global policy, we are here to look after the process of the adoption of such a policy. ICP‑2 of course, this afternoon, don't forget.
And we have launched recently the process for the 2027 election for the seat 9 of the Board of the ICANN.
Here it's Address Policy Working Group, there is something which is called the global policy development process, and the global policy first, so it's a policy which is identical and proposed in every region and it governs, the PTI, or the public technical notifier. And what is a PTI? It's the organisation which is in charge with performing the IANA function for this region of the resource to the different regional Internet registries. Anyone of course, because it's a case of everybody's proposal can propose a global policy. Once it's proposed, it has to go through the different regional policy development in every region, and where identical, by word version, has to be ratified. When there is a consensus in every region, we, the proposer is merged in a single policy statement, and then we are here to process and to see if the global policy can be ratified on all the steps are followed accordingly.
What is the story of a global policy development process, knowing that the last one, it was in 2012, ASIC remember, it was about the redistribution of the free pool of IPv4 address at IANA and every six months a different region received he part of this pool. Will that was not a big part but it was a redistribution.
2027 seat 9 election.
We work about that because sadly, so we lost Alan Barrett, you know, who filled this position, with a fast process we choose Oscar Robles, who was the CEO of the LACNIC till October, November 2027. And now we started the process to elect the one for the term 2027 to 2030. Christian Kaufmann, you know very well, he is the one who is filling the seat 10, and as he is from its Europe region, so nobody from the Europe region can candidate for the seat 9. Perhaps in this room, you have people not from Europe, so if you are interested, so you have the link to candidate and you can candidate till the 15th of December.
And I have two minutes left as ICP‑2 is our passion, I have only three slides on that. We have received ICP‑2 which is an ICANN document Internet connecting policies. Two of them, we are not absolutely dealing with IP addresses, but DNS or something, so it's old document, 25 years old, and the ICP‑2 it listed a different criteria for original Internet registry to be created. And in ICP‑2 it was LACNIC and AFRINIC, has been created for that.
And we needed to update it because it was old and of course the ecosystem of the Internet has changed a little bit.
For that reason, so the NRO EC has to work on it, and we will explain about that. We started in 2024, and last July finally we passed or work back to the NRO EC so that was our homework to them. And we will see this afternoon, it's a document we have passed to the NRO EC, it was shared via different consultation with the communities and one more time thank you for that to comment on the document and we take into account all the comment we received.
And with that, I think I have finished, so if you have any questions or remarks, I am very happy to answer.
FRANZISKA LICHTBLAU: Thank you.
(Applause)
Anyone got any questions? Not that I see. Do we have anything online? Okay. Then we'll see you back in the Community Plenary with your detailed updates. Thank you Herve. Then the next talk from Marco with the update from Registration Services from the RIPE NCC.
MARCO SCHMIDT: Thank you. Good morning everybody. I am Marco Schmidt, manager of the Registration Services of the RIPE NCC. At this regular slot I would like to give you the latest observations that are done by my team and want to bring to your attention to see if there is maybe anything needed to develop policies further or give us some guidance.
I plan to talk about those three topics. First I want to talk about IXP assignments. Some observations there. Then I like to give you an update on the legacy verification project, and I will close with some observations and considerations regarding the IPv4 waiting list policy.
So let's dive in. Some observation about IXP assignments. So, Internet Exchange points are considered critical in the Internet infrastructure, and that's why there is also, there are special policies that define how we issue ranges to Internet Exchange points so. There is one for IPv4 and one for IPv6, there is even for IPv4 a dedicated pool where we still have address space available for IXPs. Around three years ago this Working Group discussed a policy change, how we hand out IPv4 IXP space and since then, we hand out by default a /26 assignment to new IXPs, and once they can show they've enough participants like at least 50% usage, which is around 30 participants, they can contact us again, they can request a /24, they re‑number and return the /26 if they keep on growing they can get even larger ranges even up to a /22.
Looking at some numbers. We have handed ought around such 100 IXP assignments and most of them were /26s. If you look at the pool size, we still have a bit more than a /16 left and looking at the consumption rate over the last year or so, it's fair to say that we estimate this pool will last for the next eight to nine years, which is actually good news and also a sign that this policy is working.
Still I want to bring to your attention two issues, challenges is too strong a word because it's not that serious but still something that especially if you run an IXP or know somebody who runs an IXP might want to consider. The first one is about initial assignment size. As I said the policy says it's by default a /26. But sometimes we have a new IXP coming to us and is telling us oh we have already more than 30 potential participants waiting so we would immediately meet the criteria to get a larger block and to take away some of the numbering efforts, we then did some verification and then hand out a /24 straight away.
However, it also has happened already that the later we are approached by other people and say oh why did you give them a /24? We know that they have much less participants.
So, my question to you would be, okay, should we be very strict, always give a /26 and even if they have to re‑number a few weeks or months, that's it. Or, should we maybe also do some kind of deeper audit activity especially to larger IXP assignments after a time if the numbers that they provided us are still up to date? Or is it really not that serious of an issue and just continue with the way we are dealing with things?
.
Another topic related to IXPs is a transferably mismatch between IPv4 and IPv6. As I said for both specific policies for Internet Exchange points and for IPv4, you can't use the ‑‑ you can't make a policy transfer for them because the policy describes if you don't need them anymore, you must give them back. For IPv6, this condition doesn't exist. So you can actually make a policy transfer. And we observed over the last couple of years there is quite some changes going on in the IXP landscape, there is some mergers, some takeovers, new management and then there is sometimes just want to quickly fix the holdership update with the policy transfer and then they sign the contract, they want to submit it and they realise oh we only can do this for IPv6. They contact us, we tell them no, for IPv4 we need to see that there was a real acquisition, a real holdership change and it must be documented by papers from national authorities. That caused some delay and they actually want to bring to your attention that maybe it's worth considering to align those two transfer restrictions between IPv4 and IPv6.
Moving on to the next point. It's a quick update on the legacy verification project. I presented about this during the last meeting. So just a very quick recap for the people that are new to this topic.
Legacy space is space that was handed out before the RIPE NCC and the current RIR system existed. It's outside policy framework, but there is one policy that defines what services we can provide to them and also what contractual relationship they can enter with the RIPE NCC with sponsoring LIRs. One option is that they don't have any contractual relationship, which has the downside in the terms of accuracy and data quality, because we don't really know who is still using them, who is still holding them and so on. And after this was presented last year to this Working Group we got your thumbs up that we should reach out to those roughly one‑and‑a‑half thousand resource holders. That we have all data in our records and we see something in the web database and to verify the roughly 2300 legacy ranges, if the resource holders are still the ones that we believe they are or if they can document that the new holder got it right fully.
Actually, just last month, we completed the first outreach activity. We contacted now all one‑and‑a‑half thousand legacy resource holders, and I want to give a quick update on that.
Here you see a pie‑chart. Right now we are still waiting for half of those ranges for a response. It looks maybe a bit more dramatic than it is. Because also we just made the first outreach attempt around one month ago, to around half of those resources. Actually, much nicer we have already verified more than one quarter. We are also in contact for 20% of the other legacy ranges, and even around 1%, they even decided to convert the legacy space into another start for example, an allocation or an assignment.
Also, actually, a trend that I found quite positive. When we reach out to those legacy resource holders, quite often they are not just want to be verified they say it's a good idea that we sign a contract because then we can make better use of the services such as RPKI. And here, you see a little bit the overview of all the legacy ranges in our registry. The green ones that are in contract. The red ones have no contract. You see the green one is slowly but gradually increasing since the project started. That's also the observation for the whole project. The progress remains steady but it's gradual. One reason is quite a lot of those legacy resource holders want to bring them under contract, and often these academias and governmental organisations, and if you work with or for such organisations you might know that their decision‑making process is not always the fastest, so it takes time to sign the contract and send them to us. That's why we want to continue our support in outreach activity until the end of this year the a least and by early next year, we want to put this co‑maintained organisation objects that show the verified holder, or if it could not be verified to all those 2300 resources. And then I expect at the next RIPE meeting, in Vilnius, to give you a summary of the outcome. At this moment, I would expect that we will manage to verify at least a half of those resources around then we can think together what to do with the remaining part.
That brings me now to my last point, the IPv4 waiting list policy. And again, I want to start with a bit of background for the ones that are not aware.
.
In the IPv4 policy in section 5.1, there is defined how the RIPE NCC, who doesn't have a free IPv4 address pool left anymore, but we constantly get some IPv4 ranges back, how we recycle them and hand them out. It was actually pretty straightforward. It's only given to new LIRs that have never received an allocation from the RIPE NCC. It is exactly one /24. And as the demand exceeds what we can supply, it will be given via a waiting list, first come first served. This it is based on a policy 2019‑02, that also was discussed in this Working Group and reached consensus. And when looking at the original intent of this policy, then it's really clear that it was, the aim was to give a fair distribution, mostly to newcomers, to give them a little bit of IPv4, to dedicate the dual‑stack, that it helps them also with the IPv6 deployment and they have a little foothold in the IPv4 network world. Also, the idea was to prevent hoarding, that's why elder LIRs couldn't join the waiting list.
The reality was looking different, because of a difference between the wording in the policy that talks about every LIR can get a /24 via the waiting list. And understanding an organisational approach of the RIPE NCC that a member can have, could have multiple LIR accounts. So, some people indeed opened multiple LIR accounts to get more IPv4. That resulted into a very long waiting queue where everybody had to wait longer, especially newcomers. And that's a good example of how sometimes the intent of a policy is a bit overwritten or countered with some work‑arounds when there is an economic incentive. I also tried to put this statement with some data and I created this graph and I admit there is a lot going on to please bear with me.
What I tried to do that I tried to show the calculation that people that wanted to get IPv4 mostly to then sell it again, would do it at a certain moment in time. So they obviously would make a calculation how much will it cost me to open an LIR account and to keep the LIR account open as long as I can get the IPv4 and I must hold it for at least two years?
And then they obviously would also look at the space that I get from the RIPE NCC, what is the market value?
So, the red line that you can see here are the estimated costs and this of course is not the actual cost but it was based on the information that a person would have at a certain moment in time. They didn't know if the membership fee would change and so on. They would look at the market price at the moment of opening an LIR account. The market price also might go down.
So, you see when the green line is above the red line, they could estimate a profit in eventually reselling it with all the risks involved of the holding period.
Under 2019, there was a different policy in place, the last /8 policy that gave a /22, and you'll see there there was a significant profit to be expected. Then there is this immediate drop in November 2019, because then the RIPE NCC ran totally out of available address space, the waiting list policy kicked in, and as I mentioned they would get a /24. So that the profit at this moment quartered and even for a while cost and potential profit was equal. Even in 2020, 2021, as the rise of IPv4, the price rose for IPv4, there was again a profit expected, and if you now look at the little blue line below, that is the number of LIR activations per half year. And you see a very clear correlation whenever there was a profit to be expected, the numbers rose significantly. And you see since around three years, giving that the membership fee raised, not just the membership fee but also the cost that you would data networking but not only the fee raised slightly but you had to keep your LIR account open longer because there was more waiting time included, so the cost exceeded the potential resale value.
And actually since then, the number of LIR activations is pretty stable, it's roughly around 500 per half year. So actually now that there is no economic incentive the policy does work as intended, so there is an organic demand, newcomers are mostly joining, and there are not many multiple LIRs account opened anymore. You also might have seen the announcement of the RIPE NCC Board last month that it is now no longer possible anymore to open or acquire additional LIR accounts.
.
So, that work‑around is now closed, but what I ‑‑ so somebody might say, so now all is fine. But I recently have seen in the past from the behaviour in the past, whenever there is an economic incentive, people might look for work‑arounds to get more IPv4. Something was already mentioned they would open maybe multiple legal entities, and why this is definitely a bit more complicated than just open more accounts because you need to pay for open those organisations you need to give tax declarations and so on and so forth, it's definitely a possibility.
So, that's why I actually want to raise the point here is it maybe time to look if the IPv4 waiting list policy as it stands right now is ready for such potential changes in the future? Even if right now it works, but it can change quickly.
Then thinking about what are the options from the current situation. There are basically three options. One is to put more guard rails to make it more strict, learning what work arounds are there and try to prevent it. Another option is do nothing, say okay, it's fine now we don't have to do anything. But as we know if something changes there is some vulnerability. Or the third one also might be to look at the original intent again, is it still needed that we have to reserve something for newcomers? We are now seven years later, IPv6 is half there, half not. Do we need still to do this or open a little bit the door to get existing members and so on more the opportunity to get more IPv4 from the RIPE NCC?
.
Now, thinking a bit further how could we chief either of those options, so it would be all in the policy in the IPv4 waiting list policy. Also maybe it's a good moment to clarify, this is now not talking about multiple LIR accounts because that's not in the policy. Will it's also not about charging more or less for certain things. It's really looking at what could be done in the IPv4 waiting list policy. And to be more protective, what could be done, for example, limit the transferability, because right now it's two years and we have seen people take into account for how long they need to keep the LIR account open.
We also could add more requirements in the policy to actually qualify for support,s or reduce the eligibility. If the idea is more to review the intent and come up with a new intent. One possibility would be allow repeated requests for a member, because then they don't need to look for work arounds. Also maybe allow more members to request IPv4, and even give more address space. And to have some inspiration, I looked a bit at what are the other RIRs doing it, and I list it had here, interestingly all of them have something that is a bit more protective but also something that eases a little bit. So looking for example at APNIC, they also have clarification they don't really have a waiting list yet, they are still in the last /8 policy but they have a five‑year holding period. So it's definitely longer than our two years, and that's probably always one the reasons why there is still some IPv4. On the other hand, the LIRs can get a /23. And as Angela just mentioned there is even a policy discussion going on to give even a /22 to requesters with the documentation just let get over IPv4 and let's empty that pool.
ARIN took a different approach. They tied eligibility very strongly to activities on the transfer market. So, if in ARIN you receive IPv4 via a policy transfer, and you are also on the waiting list, you will lose your spot on the waiting list and you have to wait at least 90 days before you can join the waiting list again. And even if you transfer IPv4 away, you also will be dropped off the waiting list and you have to wait for 36 months before asking for it.
On the other hand, to make it easier, ARIN is the one where you can join the waiting list multiple times, you can get up to a /22 per request, and as long as you have up to a /20 of existing address space you can join the waiting list again and again with this 90 day period in between and basically can effectively ask for five times /22s.
LACNIC is maybe the most strict one, it's only for new LIRs, this IPv4 space is not transferrable at all, and you also must have IPv6 as a requirement. But on the other hand, in a LACNIC you also can go get up to a /22, so four times more than our policy allows. In AFRINIC they also do not have a waiting list yet because they have some space available. They can get also up to a /22 but you must show a very utilisation of the existing address space.
So that's my last slide, and I am actually very curious for feedback from the room. Thank you.
AUDIENCE SPEAKER: Tomas. We are a small residential ISP precisely in the cases that you said we don't really have a lot of IPv4, I think that it, we should also mention that in ARIN, there is the policy for that specific block for IPv6 deployment that I think reserves a /10 in 2015 if I'm not wrong. And they still have it. So I think it's ‑‑ because it's very restrictive to get it, it's non‑transferrable also, so it's not really monetisable in any way besides being used directly by the operator. So, maybe, just maybe we could keep the current waiting list policy for a /24, but additional requests must show that that address space will be used for IPv6 deployment purposes, and it will never be transferrable. And maybe you could have a policy like ARIN just give away up to a /22 or something like that. I think it should also be mentioned that for that spacing number wise seems to be working quite well.
AUDIENCE SPEAKER: Janus: I wanted to mention something about easing the restrictions as well, that's the reason I am here today. I mean, you really have to consider other aspects as well, like for example, not all LIRs have the same, you know, needs and requirements. I come from the telco sector, I work for ISPs and now I work for an NDN O, and I think it's not fair that we only get ‑‑ we're a new LIR, two, three years, it's not fair that we only get a /24. We don't have the same needs as, you know, other LIRs, and us getting just a single /24 just, you know, contributes on maintaining that vicious circle of IPv4 resale and so on. So, I guess the question is, are you going to do something to ease those restrictions? Are your ideas going to be a part of a new proposal? Of a new policy I mean, and how soon?
MARCO SCHMIDT: Well, actually I can give the question back because it's not us, we don't write the policies, you could write a policy proposal for example and in this Working Group will discuss it. So...
FRANZISKA LICHTBLAU: Please keep your comment and statements short and maybe ideally ask questions.
AUDIENCE SPEAKER: Gert Döring, somewhat involved in policy in the past.
IPv4 policy ‑‑ my success criteria for IPv4 policy ‑‑ my success criteria for IPv4 policy has always been if everybody is equally unhappy about them, that seems to be fair. So while I am tempted to just have them run out and get over the v4, what we have now seems to fulfil the criteria of everybody's unhappy, because everybody can have a bit, which is not enough for everybody, but the next guy can also receive some. So, I personally think it is working. It's not perfect, it will not be, it's IPv4. There is no way to make it ‑‑ make everybody happy here. I wouldn't change it.
FRANZISKA LICHTBLAU: I am closing the queue after this. So Tobias.
TOBIAS FIEBIG: I generally agree with Gert, that it is kind of perfectly making everyone unhappy. I think the only reason why we want to reconsider is if we indeed want to push certain dynamics and one of them might indeed be trying to reduce transferability to strengthen the role of the NCC in ensuring there is need basis of IP addresses and less market and utilisation for the market.
MARCO SCHMIDT: Thanks.
AUDIENCE SPEAKER: Stefan: Marco thank you very much for the IXP assignment policies, bringing up the topic. I will take it to the next URX meeting, and I think we should stay in contact here. I like the idea to have IPv6 and IPv4 in the same policy. So answer your second question. That was I think short enough.
MARCO SCHMIDT: Thank you so much.
FRANZISKA LICHTBLAU: One remark I think just to make sure that everyone is on the same side here, what Marco presents here is the perspective of Registration Services and where they actually want this Working Group to give them input. So, if you want anything to change, to inform them, to actually answer the questions that are listed here, you can find us on the mailing list, you can find all of them here on the meeting and please use this possibility and reach out to them. And with that, we now switch over to Leo, and I hope we made sure we also have his slides as we spontaneously change the agenda.
LEO VEGODA: Thank you very much. And it is very reassuring to see the stenography in front of me, I am very are grateful to the RIPE NCC for making that possible.
So, talking about a proposal to simplify the assignment of the first AS number that an organisation wants: Firstly, before getting on to this particular proposal, I think it's really important to appreciate the work that has already been done in this area, Tobias and Urban worked very hard on 2025‑01 and the very summarised feedback was that this Working Group wanted a very tight scope, and wanted to keep the language simple. So, Urban and I, as the proposers of this proposal, have tried to keep that in mind.
So, this is the problem. Back in 1996 things were different, we had a 16‑bit AS space, and if I am the scale, we pushed down hard on the side of conservation. And now, we have over 4 billion AS numbers, 32 bit AS space, and in summary we are just saying let's not make it like that, but let's make it sort of like that, a little bit more administrative ease. So, we only had 64 thousand AS numbers, now we have got over 4 billion, let's move forward.
I stole this picture from the NRO. They do a quarterly report showing the status of all the different Internet number resources. You can see the pale blue is the AS numbers that are allocated to the RIRs. And I think, and maybe Marco or Angela will tell me if I am right, That unallocated does not include the reserved. Like for instance there is about 100 million AS numbers reserved for private use. So, that doesn't feature in there. So you can sort of get an idea of the scale.
And I also stole this from the IANA website on Sunday. This is something they run every single day, which looks at how all of the RIRs using all of their resources, because the global policy is deterministic and it's a calculation. And on Sunday, they said the RIPE NCC is averaging 254 ASN assignments a month. This is just to give you an idea of where we are, you know, between the run rate and the total resource pool.
So, are our proposal is to move from this to this with the administrative ease, and it's quite tightly scoped. You have to have IP addresses that were issued to you directly by the RIPE NCC. So, an allocation or assigned PI, but not assigned PA, so if you got your addresses from an LIR, no, you can't qualify under this.
Now, you could perhaps qualify if you did qualify under the regular policy. This is an amendment, it's just an additional thing, it doesn't take away the rest of the policy. Everything else needs a needs assessment.
.
There was the initial discussion phase and now we are in the review phase. In the discussion phase we heard three main pieces of feedback. Firstly on routing policy publication. It was never our intention to make any change to that, and the initial wording we had was slightly ambiguous, so we have updated the language for the review phase, and there is certainly no intended change in policy there. Of course, you are the people who will go and review our wording and you'll give feedback if you think that we haven't achieved what we intended. Or what you like.
Secondly, per LIR or per organisation? That was a piece of feedback and you would be able to qualify under this policy, if it becomes policy, if you have a PI assignment. So, per organisation. And there was also a comment about ASNs going to shady entities. And this proposal makes no change to the RIPE NCC's due diligence business process. And I think the processes that the RIPE NCC uses to make sure that it's doing business with the right people are a business process not a policy, so, hopefully this proposal, were it to become policy, would have no impact there, it would not degrade the quality.
So, the RIPE NCC published an impact assessment. My summary is, you know, a slight increase in the number of ASNs assigned. There was a medium impact on software development, and slightly simpler request handling. So again we're going from this to this. And we're now in the review phase. Because in the review phase we have slightly different text than in the discussion phase, I am asking you if you supported this proposal and you still support it, please send a plus one to the mailing list. And if you have concerns about this proposal, please send a couple of sentences to the mailing list explaining what your concerns are. Because there is no point having a proposal become policy if it's not any good. And I did find a nice picture of a microphone but I know we're running tight on time. So I have made my call, please send your mail. Thank you.
FRANZISKA LICHTBLAU: I actually think we have Urban online who wants to comment as well. So we start with that.
URBAN SUHADOLNIK: Okay, so, unfortunately I couldn't join for this RIPE meeting. A few more additions from my side. So, this is only for the first ASN, Leo ‑‑ like, I think to be clear, this is for the first ASN per organisation, for all the others the policy is exactly the same as now, which is basically the multihomed requirement. The idea was by tying this to IP resources assigned directly by the RIPE NCC is essentially to some extent to outsource the thing to the IP policy. So essentially, if you do have PI space, you should also have an ASN. And PA, and as an LIR, if you have PA space, so your own space. One the ideas was with PA space or not assigned PA was to keep the aggregation of resources that LIRs have.
So ‑‑ and maybe my last comment compared to the, to the 2025‑01 policy, is with the previous policy there was an attempt to change the whole policy to fit ‑‑ to give the first ASNs also to single home networks. Now, we do have a discrepancy between organisations, for example, have like one location, they get an ASN, they can use PI, no problem, while organisations that are larger that have multiple sites but maybe would want to run more ASes go with the old policy.
So, the scope was tight now only for the first ASN, but if there is any demand to try to revamp the whole policy, like last time, this could be a thing for further policy proposals. That's all from my side.
FRANZISKA LICHTBLAU: Thank you. Then we start with the Q and A.
GERT DÖRING: I want to state something which is obvious but still for the record, because the discussion always turns around, we have 4 billion AS numbers, and they should be free. They are not free because there is consequences on the NCC and everything. I wanted this in the minutes, and they are now. That said, I very much like the proposal. Because it is very simple, easy to implement, limited impact and gets the job done for a specific group of IP holders that are currently not served well. So thank you for that.
LEO VEGODA: Thank you.
GERT DÖRING: I will send it to the list.
LEO VEGODA: Thank you. And on the not free, one point I would like to make is that Urban and I considered the fact that the RIPE NCC does charge a small annual fee for each AS number and this proposal is made with that fact in mind. That fact would ‑‑ it's useful, because it provides some sort of collection mechanism if an AS number is not used. So, we were aware of that, and I think you bringing up the free word is very important. They are not free to anyone. And hopefully, the unused ones will come back.
TOBIAS FIEBIG: I would like to add‑on the free part because I think this proposal actually makes the first ASNs a bit more free for the RIPE NCC because it reduces overhead because the needs based assessment for the first ASN is removed, which is part of the costs the RIPE NCC has when assigning an ASN, and if you get address space from the NCC you kind of need an ASN any way, so I think it actually makes ASNs a bit more free which is very helpful.
FRANZISKA LICHTBLAU: Do we have anything online? No, okay, thank you Leo.
(Applause)
.
And I can only echo, please voice your comments and statements to the mailing list because that makes our life easier, especially now that this is in the review phase.
And now Marco's second presentation, which is about an actual policy proposal. So here we are not on the NCC giving us an update on how the world looks like, but we are in the regular policy proposal process for the Working Group to consider.
MARCO SCHMIDT: Thank you. And exactly, you took the words out of my mouth. So this is an unusual spot for me to be on the stage to talk about a policy proposal.
It has the beautiful name clarifying audit and policy compliance frameworks for IPv6 policies. So quite a mouthful. In short the proposal 2026‑03.
And let me quickly tell you what it is about, because it was published around ten days ago and you mightn't have had time to look it up yet.
Basically, when looking at the IPv6 policy, it's out there since 2002, and during this 20 plus years it went through 20 changes, 20 times the policy development took place and improved that policy.
But mostly regarding the provision of IPv6 and the registration requirements of IPv6. While on the same side if you look at the remaining texts, definitions and especially the post provisioning lifecycle we often have the original words for 20 or more years, it lacks some information for example about a clear reference to the audit procedure, while the audit is mentioned in some parts of the new additions there is not a direct reference. It also uses some interesting wording like bad faith and good faith and licences. What I tried to achieve with this proposal was to enhance the clarity, or to do some alignment with the IPv4 policy to make it just a bit easier to read for people that are not familiar with all this policy text.
I will quickly show what actually changes are proposed. I want to start with that all the wording that I am currently proposing to add is a one to one copy from the IPv4 policy.
For example, to add to the abstract that these policies apply to the RIPE NCC and to LIRs within the service region. Then, in section 4.1, I propose to remove this very lengthy text that I'm not reading out now, indeed talks about licences to be renewed basis, it might not be renewed if there is bad faith at play and so on.
Then I also suggest to add an automatic reference to the audit procedure as a new section, section 9. And add a new section 10, which defined, for example, so, when an LIR can be closed and there is also the policy compliance included.
.
So, if you now think well that's not an exciting proposal, you are right. It's definitely not the most sexy one but also not the intention because the RIPE NCC, there was discussion should make the RIPE NCC policy proposals and it was said yes because in the policies, there are some needs that sometimes can be improved or the a least can be discussed but it also would take some of your working time, your efforts to do that. So we are happy to take this on and all the sexy proposals we are going to leave up to you. So that's definitely don't worry about that.
And despite that, I am actually happy that we already received some feedback on the mailing list and there was four responses. They were all in support of the intent of the change. Also the atomic reference to the audit procedure, there was some feedback from Leo that some of the proposed wording also needs some clarifications, and I agree with that because it's a copy of the IPv4. Also Denis raised some concerns if you take away the term bad faith that we don't have the authority anymore to penalise non‑compliance. And to address, I also will do this actually at the mailing list, to address this concern, it's really unfounded because we have very good procedure documents that define exactly what are the consequences if a resource holder does something that is non‑compliant?
Regarding those points, like what Leo mentioned, the new text would say within the RIPE NCC Services region, why we also have members outside the service region. Also the way how the whole LIR requirements are phrased. I agree, and I am actually considering in the next version to enter an atomic reference to the closure and deregistration procedure because they are all those requirements there. And also on this point I would for example like to get your feedback, should we do this in the next version or do we wait for some alignment in a RIPE policy manual which will be presented at the next session, although that will take much more time.
And I see already people lining up, which is perfect timing because I am at my last slide.
This proposal aims to clarify some IPv6 requirements, especially for the provisions. The discussion phase is ongoing till the 17 November, and please any comments also are welcome on the mailing list, are even required, but yeah. Thank you.
(Applause)
AUDIENCE SPEAKER: Peter Koch, good morning. Thanks Marco, I am a bit confused about this chapter or section 10. The ability to close the LIR is ‑‑ well first of all the LIRs are address family agnostic, so one part of my ‑‑ I am multiply confused. One part is about why have it in two different places, as in the v4 and the v6 policies? And also I am wondering what the nature of this is. To me this looks non‑normative, because that ability to close the LIR comes from elsewhere, and that should actually be made clear in the text, so that the authority is not generated there, but maybe that was the part that you already had on the slides. Again I apologise for being confused.
MARCO SCHMIDT: I completely understand the confusion, and we actually notice that had other members are also confused because I mentioned on the mailing list we are performing some IPv6 audits and sometimes the people then are surprised why you audit me on IPv6 there is nothing in the policy? Of course there is yes there is, there is an audit procedure around by the way the policy compliance is also there. So that's why I used that wording that is like this in the IPv4 policy to have some consistency, although that probably also has room to improve.
TOBIAS FIEBIG: I personally like the idea of first aligning the two policies and maybe not, actually not doing the word fixing that you now came up with but first making sure that those are aligned. After we did that, do the clarifications to both at the same time. That might just ensure that we stay consistent because otherwise we have the clarified v6 policy and nobody takes care of v4.
FRANZISKA LICHTBLAU: No other comments? Nothing online?
Okay, that apparently means we are actually closing early. Thank you Marco.
.
Before everyone runs off to lunch, as usual we get this nice paper slip where we are supposed to tell you all the important things that are happening next.
So, first of all, also in the Working Groups as well for the Plenary you can always rate the talks, we are very interested in your feedback what you want to see more of, what did go well, what didn't go so well. And you can still vote for the PC candidates, we have two open slots, three candidates running and the voting will close at 5 will p.m. today. And I have been asked to inform you that open deliberations of the Secret Working Group happen from two o'clock until four o'clock in the Marie Curia room, but obviously you are only available until 3:30 because until then we have the second session of this Working Group. So have a nice lunch, see you back at two o'clock.
(Lunch break)
