RIPE 92 Address Policy Working Group Minutes

Session 1

Thursday, 21 May 2026 11:00 ‐ 12:30 (UTC+1)
Chaired By: Franziska Lichtblau, Alex le Heux, Leo Vegoda
Scribe: Antony Gollan
Status: Draft

View the recordings
View the stenography transcript
View the chat logs

Open Session

Presentation slides and recording available at:
https://ripe92.ripe.net/programme/meeting-plan/sessions/97/Y77RKA/

Leo Vegoda, Address Policy WG Co-chair, welcomed attendees and ran through the agenda. The minutes from the previous meeting were approved.

Co-chair selection

Recording available at:
https://ripe92.ripe.net/programme/meeting-plan/sessions/97/BJN9WV/

Leo said that he would be stepping down as co-chair of the WG. Leslie Nobile had been nominated and statements of support had been shared on the mailing list. He invited Leslie to give a brief statement. Leslie said she had been attending RIPE Meetings since 2001, and that she had been working in the RIR system her entire career. She had a lot of experience with IP addressing policy and hoped this would be useful for the WG. She was grateful for the opportunity. Leo said from the applause in the room he thought there was consensus.

ASO AC Update

Andrei Robachevsky, Global Cyber Alliance
Hervé Clement, ASO AC
Constanze Buerger

Presentation slides and recording available at:
https://ripe92.ripe.net/programme/meeting-plan/sessions/97/VBJADC/

Hervé Clement gave an update from the ASO AC, explaining what it did and how it was constituted. With 15 members (three from each RIR region), it advised the ICANN Board, oversaw the Global Policy Development Process, appointed two members to the ICANN Board (seats nine and ten), and one member to the ICANN NomCom. The ASO AC met monthly via teleconferences that were open to observers. They also had an annual face-to-face meeting at ICANN that was open to observers, and their mailing list was open with public archives. He also gave an update on their work on an updated ‘RIR Governance Document’ (formerly ICP-2). They would continue drafting the final version of the document at ICANN 86, after which it would be delivered to the NRO EC and then presented at the next round of RIR Meetings and at ICANN 87.

Franziska Lichtblau, Address Policy WG Co-chair, said Leo had exited the stage too quickly and she wanted to thank him for his contribution to the WG. She and Alex were also looking forward to working with Leslie.

Sander Steffann, speaking as a former ASO AC Member, said he wanted to thank Hervé and his colleagues for their efforts to update the RIR Governance Document. He knew how much work it was.

Hervé noted that there was a drafting team within the ASO AC which was handling this work, and he wanted to recognise Andrei Robachevsky and Nicole Chan who were both at the meeting.

Policy Update

Angela Dall'Ara, RIPE NCC

Presentation slides and recording available at:
https://ripe92.ripe.net/programme/meeting-plan/sessions/97/CHDGUX/

Angela Dall'Ara, RIPE NCC Policy Officer, ran through all the open policy proposals, both in the RIPE and other regions. Within the RIPE Region: the RIPE NCC was currently in the process of implementing the proposal for ‘Revocation of Persistently Non-functional Delegated RPKI CAs’ (ripe-847), and there were two proposals currently active within the RIPE PDP. ‘2025-01: ASN assignment criteria revisited’, and ‘2024-01: Revised IPv6 PI Assignment Policy’ had both completed the Discussion Phase. Angela also noted there was an upcoming review of the RIPE Policy Development Process (PDP) document, since the last update had been made in 2022.

There were no questions.

Registration Services Update

Marco Schmidt, RIPE NCC

Presentation slides and recording available at:
https://ripe92.ripe.net/programme/meeting-plan/sessions/97/JZ3KEL/

Marco Schmidt gave an update from the RIPE NCC’s Registration Services department. His update touched on the implementation of NWI-21, outreach to legacy holders, leasing, and clarification of the IPv6 Policy.

Gert Döring, SpaceNet, thanked Marco for reporting back on their efforts to contact legacy holders. He was happy to see that the carrot approach seemed to be working well. This seemed to differ from the picture that had been painted yesterday that made it seem like legacy holders were being unfair and they needed to fight them.

Antoin Verschuren, Liberty Global, (online) said, on the topic of leasing, prefix brokers did not make assignments for prefixes they leased to customers, which made it harder for network operators to identify customers when BGP sessions failed. They had previously used the description field in route objects to identify the customer, but this was now dummified for privacy reasons in bulk whois, which seemed to create operational security risks. He asked how users of leased address space could be identified. He also asked whether dummification of route object descriptions could be reversed if assignments for prefix brokers could not be mandated.

Marco said these observations applied to all kinds of assignments, but it was a good point in general.

Nicola von Thadden, PFALZKOM, said ISPs varied widely in how they documented assignments in the RIPE Database. Some recorded every /26 or /28 assigned to individual companies, while others simply marked that a particular /20 was being assigned to business customers. He questioned what value this smaller assignment data had, given that geolocation was unreliable and abuse-c and tech-c contacts often pointed back to the managing ISP. He said they should consider what information they actually wanted in the database.

Marco said this was in line with what he was trying to highlight.

Emanuele Iovini, Europol, thanked Marco for his efforts to improve the situation regarding legacy resources. He also wanted to support the earlier comments because he wanted to stress the importance of contactability and accountability for Europol. If the contract for leasing cases could be registered in the database that would be very helpful for them. He said they were also available to offer help if needed.

IP Address space for Outer Space

Tony Li

Presentation slides and recording available at:
https://ripe92.ripe.net/programme/meeting-plan/sessions/97/RHW7DB/

Tony Li said the economics of space travel had shifted and the IETF’s TIPTOP WG was therefore working to extend the Internet in space. Currently space agencies were going to their local RIRs, which meant they couldn’t do any aggregation, and the TIPTOP WG would like to change that. They were proposing one block for outer space, and within that block they wanted one prefix (each) for the Moon, all of the planets, Lagrange points, the asteroid belt (potentially), and others. He noted that links to rovers were in the realm of 500 bits per second, which meant that IPv6 overhead was very much a serious concern, and as a result some mission planners would choose IPv4 for their purposes, and they also wanted aggregation for this.

Warren Kumari, Google, thanked Tony for his presentation and said that he and Jen Linkova were planning on writing a slightly different document that asked IANA to set aside a large block for space, which the RIRs could then draw from specifically for space uses. The RIRs could then figure out whatever policies they wanted. This meant that they might end up with five prefixes, but that would be perfectly aggregatable. He thought it was important to have a single block specifically identified as for space. They should avoid having one single RIR responsible for this because each country or region had someone they wouldn’t deal with, whether due to sanctions, conflicts or other issues.

Tony said this approach would end up with five prefixes per planet and there were concerns about how well that would aggregate.

Job Snijders said he was not optimistic about the potential for aggregation. Time and time again, aggregation based on geography had not worked in practice. He thought it was perhaps even naive to operate on the assumption that there could be one prefix per planet. It might be lucky to even get five prefixes. Regarding the need for IPv4 in space, if the overhead was a concern, there were many compression algorithms that could deal with this on the link layer, this was a well understood problem space.

Tony thanked Job but said he disagreed.

Maximilian Emig, no affiliation, (online) asked why RIPE and not IANA. He opposed reserving additional IPv4 but supported this for IPv6.

Silvan Gebhardt, speaking for himself, said Tony’s slides made him think of international waters and asked where did they start with space, because technically they already had satellite to satellite communication. He asked where that would fit within his proposal.

Tony said international waters were not in his proposal and not something he was trying to tackle.

Nicola von Thadden, PFALZKOM, speaking for himself, said that if he was concerned about aggregation they could still do one prefix per planet from IANA but then sub-allocate that per RIR. But then you would have multiple announcements per planet going into BGP, so he wasn’t sure that would fulfil the point of aggregating things there. He also opposed the idea of having only one RIR, because this could create contractual issues for members having to deal with multiple RIRs.

Peter Koch, DENIC, said he believed there was an international convention about not poisoning planets with unwanted lifeforms and he thought that should be extended to include IPv4. They currently had ‘globally-routed IPv6’ and he wondered how ‘globally’ would extend to space. It would probably require getting another slice of addresses, but not from IANA as it didn’t have it yet. On the question of the RIRs, given the presentations on ICP-2 and such, he didn’t think policy-wise this was covered by picking one, adding a new one, or distributing it between the five RIRs they had. Dedicating a new slice of protocol parameters might help with that but this wasn’t an engineering problem.

Brian Nisbet, Asiera, said that while he supported the bottom-up process, this seemed like an NRO discussion rather than each RIR community giving its opinion. He also didn’t see how any one RIR could fill this role given the current geopolitics, so he quite liked the IANA idea.

Tony noted that he had sent this to the NRO but hadn’t heard anything back.

Gert Döring, SpaceNet AG, said that if the community wanted to do this, policy text would need to change, because existing policies described what RIRs currently did and this was outside that scope. He agreed that asking IANA to set aside a block for use in space was a necessary starting point, because without addresses there was nothing to distribute. He said global policy would also need adjustment, but the Address Policy WG would still need to update its own formal policy text if it wanted to support this. He thought this was all doable, but tricky.

Warren said he wanted to answer two different things. A couple of people had suggested they make this IANA’s problem. He did not think this was the right approach, as there could be many requests and the RIR communities already had policy processes and a membership community. Being able to use this seemed like an advantage. The other part was that earlier in the week there had been a presentation from the IAB on network operator outreach. This was a good example of this in action and he encouraged people from the operator community to participate in the IETF discussions, as they had expertise the IETF did not.

Stephen Strowes, Fastly, said he agreed with carving out space at the IANA level. He didn’t think that with geopolitics they wouldn’t get one uniform registry for space. He said they had different levels of cooperation in space and seemed to be moving from having one International Space Station to a series of individual national stations, for example, and he thought they’d need a multiple-RIR approach. He asked if space agencies were coordinating with TIPTOP.

Tony said there was some participation from space agencies. There were some challenges with that but they were trying to get the agencies to engage with them.

Éric Vyncke, Cisco, speaking as the responsible Area Director for TIPTOP in the IETF, clarified that space agencies were not directly interacting with TIPTOP, but their contractors and systems integrators were. He noted that Tony’s document was currently under call for adoption in the IETF, which was the first step, and he encouraged the RIPE community to join the discussion.

John Curran, ARIN, said he wanted to clarify one thing about ARIN as the ‘outer space RIR’; this had only come up because of a policy proposal in their region (ARIN 2026-1). Because the community was discussing this, ARIN was asked to provide a staff and legal assessment. They responded and said there were some issues with the policy. Regarding implementation, this would require a block to be allocated by the IETF, some indication from IANA that the RIRs should provide service for that block, a decision by the ARIN Board that it wished to serve entities outside its traditional region, and consent from the other RIRs. He said there were multiple ways service for such a block could be provided.

Remco van Mook, said looking at the list of spacegoing countries, most of them effectively have their own national Internet registries already. For them to pick up new address space this would require them to go outside of their own NIRs which they had set up themselves because they felt they needed them. He would like to see how that dynamic would work. Aggregating in outer space would only make sense if you had interconnection in space – which would only make sense if you were not planning to trombone traffic back to Earth. However, it seemed like space exploration would be a competitive enterprise and so not just addressing but also routing in space would be a critical part.

Tony said they absolutely expected to have that interplanetary communication, for example between the Moon and Mars, and this was where having one prefix in each direction would be useful.

Remco agreed, but noted that it would not be Mars - it would be China on Mars, the US on Mars, etc. Currently he didn’t see much interconnection and interoperability between one another on Earth, and it was hard to imagine that it would be any different when talking about something much more strategically important.

Tony said the aim was to encourage interconnection and interoperability, and aggregatable addressing would help with this.

Warren said he thought eventually countries would interconnect. He said it was therefore important to set aside address space and make this easy. He also pointed people to the Space Research Group, which was looking at higher-level space networking issues, and said he and Jen were working on a document and would welcome input from people with addressing policy expertise.

End of first session.

Session 2

Thursday, 21 May 2026 14:00–15:30 (UTC+1)
Chaired By: Franziska Lichtblau, Alex le Heux, Leo Vegoda
Scribe: Boris Duval
Status: Draft

View the recordings
View the stenography transcript
View the chat logs

Open Session

Franziska Lichtblau opened the second Address Policy Working Group session and welcomed participants on behalf of the co-chairs.

Discussion on AS Reallocation

Antonis Chariton, AS4601 / Cisco

Presentation slides and recording available at:
https://ripe92.ripe.net/programme/meeting-plan/sessions/100/S3BFX8/

Antonis Chariton presented the issue of ASNs being returned to the RIPE NCC, cleaned up in the RIPE Database and BGP, quarantined for six months, and then reassigned while old ROAs, and potentially future ASPA objects, may still reference them. He said his analysis suggested that almost one in five reassigned ASNs currently had pre-existing ROAs, creating a risk that a new holder could announce address space from a previous holder and have it appear RPKI-valid.

Leo Vegoda, former Address Policy Working Group Chair, said Antonis had done a good job and supported the concerns raised. He said the relevant IANA policy referred to the number of free ASNs held by an RIR, and that if an ASN was legitimately held in quarantine, it should not count as free. In his view, the RIPE NCC could therefore adjust its operational process without a policy change.

Rüdiger Volk, speaking remotely, thanked Antonis for taking note of his Plenary comments about ROA monitoring. He said address holders needed better tools to maintain their ROA sets, and that reallocating ASNs created a conflict because ASNs were often treated as stable identifiers of an entity.

Antonis said the RPKI Dashboard could be improved, although this would need to be prioritised against other RIPE NCC work. He said he personally saw value in not recycling ASNs, while recognising that this depended on interpretation and community agreement.

Tobias Fiebig, TU Wien, said not reassigning ASNs could create incentives for people to request and return large numbers of ASNs. He said the real problem was people not cleaning up after themselves, and that an active cleanup process, such as following up with holders who left ROAs behind, would be needed.

Maximilian Emig, commented remotely, that he supported extending the quarantine period and checking for references to ASNs in places such as PeeringDB, ROAs, route objects and RIR databases. Antonis agreed and said similar stale-reference problems also occurred in PeeringDB and at IXPs.

Job Snijders said the current six-month cool-down period appeared too short, given the near-20% collision rate. He suggested a four-year quarantine period, saying this would preserve long-term reuse while reducing the likelihood of reassignment with stale references.

Peter Hessler, Database Working Group Co-chair, said the topic had recently been discussed in the Database Working Group. He said there had been clear support, though not a formal consensus call, for deleting associated ROAs, ASPA objects and similar RPKI-related objects when an ASN was returned to the RIPE NCC.

Antonis said some cleanup was possible, but noted technical limits, especially where a delegated CA or another RIR was involved. He said unassigned ASNs were probably fair game, but that the details could be complex.

Marco Schmidt, RIPE NCC, said the spike in recycled ASN assignments at the beginning of 2025 occurred because the RIPE NCC had finished its latest IANA ASN block and was assigning returned ASNs. He said the six-month quarantine period was an RIPE NCC operational decision rather than a policy requirement, and that the RIPE NCC would extend it significantly very shortly.

Marco also said it might be worth warning users when ROAs reference unassigned ASNs or ASNs assigned elsewhere. Antonis said additional validation checks could be considered if there was no legitimate use case.

Ivan Beveridge suggested notifying affected users by email, rather than only through the user interface, and said cleanly returned ASNs with no references could perhaps return to the pool sooner. Antonis agreed that email notification would be an easy first step and that clean ASNs could potentially be recycled more quickly.

Tobias Fiebig said a four-year quarantine period might not make reassigned ASNs cleaner, but could simply make problems appear later and more unexpectedly. He said active measures, such as automatically emailing contacts for networks with existing ROAs when an ASN was returned, were needed.

Gert Döring suggested the Working Group might consider sending a message to the NCC Services Working Group about an assignment fee for ASNs.

RIPE Policy Proposal 2024-01: Revised IPv6 PI Assignment Policy

Tobias Fiebig, TU Wien

Presentation slides and recording available at:
https://ripe92.ripe.net/programme/meeting-plan/sessions/100/JBGK7J/

Tobias Fiebig presented Version 2 of RIPE Policy Proposal 2024-01, which aims to allow larger IPv6 PI assignments to end users, clarify sub-assignment rules, clarify maximum assignment size and support nibble-boundary assignments. He said Version 2 had been simplified after feedback that Version 1 was too complex, with some topics moved to future work, and that the authors believed the proposal was ready to proceed to RIPE NCC impact analysis if the chairs found sufficient support.

A remote comment from Maximilian Emig said that some reserve created by nibble-boundary assignments should be seen as a feature rather than a bug, given IPv6 abundance and the benefit of reducing RIPE NCC workload. Tobias agreed.

Allan Battistello, RIPE 92 Fellow, asked whether the six-month period to return previous assignments after renumbering could be extended, as it might be tight for operators with BGP customers or interconnects already using the prefixes. Tobias said a longer period was technically feasible, but he was unsure whether it was necessary for the likely affected PI users and was open to Working Group input.

Jordi Palet, The IPv6 Company, commented remotely that he supported the intent but had major concerns with the current text. He said RIPE policy should not restrict or contradict what was standardised in the IETF. Tobias referred to his mailing list response on that point.

Gert Döring said the shorter proposal was useful and that the separation of PA and PI text and sub-assignment clarification were improvements. He said some wording around point-to-point links, peering and connecting other entities to the Internet appeared contradictory and should be clarified. He added that he did not believe nibble assignments were useful, but would not oppose the proposal.

Marco Schmidt, RIPE NCC, clarified that the proposal was at the end of the discussion phase, not at a consensus call. He said the next step, if there was sufficient support, would be a RIPE NCC impact analysis, and urged participants to read both the proposal and impact analysis carefully because operational details, such as what happens if a holder cannot renumber within six months, could have important consequences.

James Kennedy, KIPA.global, thanked Tobias and Clara for their work and asked why previous assignments had to be returned if no contiguous extension was possible. Tobias said the main reason was to prevent stockpiling by making such resources non-transferable. James said the impact on holders with active use should be considered in the impact analysis.

Upcoming AP Policy Proposal: Loss of Legacy Status Upon Transfer

Clara Wade, AWS
Peter Hessler

Presentation slides and recording available at:
https://ripe92.ripe.net/programme/meeting-plan/sessions/100/DJQKBJ/

Clara Wade and Peter Hessler introduced an upcoming proposal to remove the option of retaining legacy status after a transfer, while not eliminating legacy status entirely or applying the change retroactively. They said the goals were to reduce RIPE NCC overhead, address speculation and policy avoidance around scarce resources, improve registry accuracy, and reduce friction around RPKI adoption.

Niall O’Reilly, former employee of a legacy holder and co-author of policy proposal 2012-07, said he was concerned about due process. He said the proposal could be seen as third-party interference in existing arrangements, and that legacy holders who had not been reached through RIPE NCC outreach might not view the RIPE community as an open consensus forum. He offered to help identify pitfalls and said existing policy might already offer ways to address the issue.

Peter thanked Niall and agreed that the topic had pitfalls. He said this was why the proposers wanted legal review and a full PDP process, and said initial temperature checks with some legacy holders showed they would need to see the details.

Brian Nisbet, Asiera and also the sponsoring LIR for a number of legacy resources, said he conceptually supported the idea. He said legacy status was valid, but that after a transfer the special status should be lost, and that retaining it after purchase appeared to be a way to get around existing policies.

Tom Fantacone, IP.Trading.com, said they were not a fan of the proposal as currently framed but appreciated the discussion. They said legacy holders could already use RPKI if they signed a legacy services agreement and became a member or used a sponsoring LIR, and suggested an alternative where recipients could retain legacy status but would be required to become a member or be sponsored.

Peter said this was an interesting avenue for mailing list discussion. He added that RPKI was not the main driver of the proposal; the main concern was flipping and avoiding policy.

Tom said speculators were not always harmful and could provide liquidity in the IPv4 market.

Sergey Myasoedov, NetArt Group, said that the legacy IPv4 market was a mess and that he would support losing legacy status after transfer. He said he would be happy to contribute if the discussion became a policy proposal.

Tobias Fiebig, speaking personally, said that IP addresses were not property and that policy should aim to make a better Internet rather than attract speculators or traders. He said he supported the proposal and would personally apply it retroactively, arguing that if a legacy holder wanted a change from the RIPE NCC, the community could require current rules to apply.

Maximilian Emig asked remotely whether AWS and its subsidiaries had converted all previous legacy resources to PA or PI, and asked about the process and legal review. Clara said AWS had converted all previous resources to PA, especially because AWS supported Charging Scheme Option B and wanted to contribute its fair share.

Jordi Palet, The IPv6 Company, commented remotely that the community should move away from legacy status and that legacy status should be lost when resources were transferred, as in other RIRs.

Clara asked participants to look out for the policy proposal on the mailing list and read it.

Open Mic

Presentation slides and recording available at:
https://ripe92.ripe.net/programme/meeting-plan/sessions/100/FPLPBS/

Franziska opened the Open Mic session by asking for feedback on the convention that speakers state their name and affiliation at the microphone. She said the question had been discussed during the RIPE Meeting and among Working Group Chairs, and that affiliation could provide useful transparency in policy discussions but might also discourage or prevent some participants from speaking.

Gert Döring, member of the RIPE community, said affiliations could be useful context but could also get in the way. He said he might speak as SpaceNet, as a former Address Policy Working Group Chair, as part of an open source project, or simply as himself, and therefore saw affiliation as an optional extra.

Tobias Fiebig, TU Wien, said name and affiliation were important for transparency and for making clear which role a speaker was using. He said even when someone spoke personally, their employer or role could provide relevant context.

Tina Morris, AWS, said affiliation was important because people’s professional backgrounds shape their perspective. However, she recognised that some people might not be able to name their employer, and suggested they could instead describe the type of organisation they work for, such as a large cloud provider.

Niall O’Reilly, a randomer who just walked in the room, said regular participants might know his background, but newcomers would not. He said disclosure of relevant context should be a strong “SHOULD”.

Janos Zsako, ISZT Nonprofit Kft, speaking as an Internet citizen, said affiliation should be stated when someone feels they are speaking on behalf of it, but that it should not be enforced when someone does not want to state it.

Will, AS2613, said it would be helpful to state the affiliation relevant to the comment, especially for people with multiple hats.

Tobias Fiebig, speaking for himself, added that the issue was also about preventing people from speaking on behalf of an affiliation without declaring it. He compared this to IETF blue sheets, which record who was in the room and included affiliation.

Jen Linkova, speaking from her experience across the Internet industry, including at an ISP, a content provider, a system integrator, a routing and switching vendor, and running an enterprise network, asked whether this discussion belonged in the RIPE Community Plenary rather than in one Working Group. She said affiliation could be useful but also misleading, and that forcing disclosure could make some people reluctant to speak.

Rory Bush, Netcraft, said that as a first-time RIPE Meeting attendee, affiliations were useful because they gave context about who was speaking and what biases they might have.

Stefan Wahl, speaking for himself, said he agreed with Niall that this should be a strong “SHOULD”. He said people should state the hat relevant to their comment, and that consultants or people with multiple roles could explain the context without necessarily naming every affiliation.

Peter Hessler, Database Working Group Co-chair, said the issue affected all Working Groups and that Franziska had raised it for input rather than to make a decision. He said there should eventually be a single guideline for Working Groups, the Plenary and the event as a whole.

Ivan Beveridge, ex fintech employee, said it could be difficult for people to name their employer if the employer did not want to be associated with the comment. He suggested a middle ground where speakers state their name and company, but make clear they are speaking only for themselves.

Niall O’Reilly, old timer at RIPE, said it was appropriate for Franziska to raise the question in the Working Group she was chairing, because any convention would have to be implemented by Working Group Chairs.

Franziska thanked participants for the comments and closed the session.

End of second session.