Skip to main content

RIPE 91 Address Policy Working Group Minutes

Session 1

Thursday, 23 October 2025 11:00 ‐ 12:30 (UTC+3)
Chaired By: Leo Vegoda, Franziska Lichtblau, Alex le Heux
Scribe: Ed Shrayne
Status: Draft

View the recordings
View the stenography transcript
View the chat logs

Open Session

Presentation slides and recording available at:
https://ripe91.ripe.net/programme/meeting-plan/sessions/40/BRSEHF/

Leo Vegoda, Address Policy WG Co-chair, welcomed attendees to the session and went through the Agenda.

The minutes from RIPE 90 were approved.

Current ASO AC Activities

Hervé Clément, Orange SA / ASO AC
Andrei Robachevsky, Global Cyber Alliance/NRO NC
Constanze Buerger

Presentation slides and recording available at:
https://ripe91.ripe.net/programme/meeting-plan/sessions/40/M9V3QX/

Hervé presented on the current activities of the NRO NC and in particular recent developments of the second draft RIR governance document (ICP-2) and what it meant for the IP address community. He asked the community to read and comment on the draft before the consultation period ended on 7 November 2025.

Randy Bush, RGnet, IIJ and Arrcus, said significant progress had been made since the Lisbon meeting and the NRO NC deserved the community’s deep thanks.

Danko Jevtovic, with ICANN until October, said the work of the ASO AC was extremely important and that ICANN and its board were grateful. He thought ICP-2 could be used by the RIR community to gain more attention within the ICANN environment. He said that he was surprised not to see more discussion on the governance of the root server system, which was no less important than the ICP-2 discussion, and he asked the community to get involved.

Policy Update

Angela Dall'Ara, RIPE NCC

Presentation slides and recording available at:
https://ripe91.ripe.net/programme/meeting-plan/sessions/40/EQNMVJ/

Angela gave an update on policy developments across the various RIR regions since RIPE 90:

  • Within the RIPE region, there was a new policy to give the RIPE NCC a mandate to revoke persistently non-functional delegated RPKI CAs. This same proposal had already been accepted in the APNIC region.
  • The AFRINIC board had been reconstituted and some proposals were already accepted and one was under implementation. RPKI ROAs for unallocated and unassigned AFRINIC address space were being tested and would be implemented soon.
  • In APNIC a proposal on whois privacy had been accepted, as well as a proposal on published statistics on directory service usage, to improve the transparency of usage of the whois service.
  • In ARIN there were two recommended draft policies. One clarified when a member receiving a transfer needed a new registration service agreement. The other clarified requirements for IXPs.
  • In LACNIC there were two proposals awaiting a decision on consensus. One was about temporary transfers while the other concerned distribution of resources to natural persons.

Jordi Palet Martinez, The IPv6 Company, (online) pointed out that one proposal had been missing from Angela’s update – LACNIC 2025-2 “Definition of Organisation” which clarified that natural persons could obtain Internet number resources, and aligned the policy manual with LACNIC’s existing practices. [Angela later clarified in the chat that she had not included this because the day before the LACNIC Policy Development Chairs had declared that v1 of the proposal had failed to reach consensus, though the author could submit a new version.]

Dave Phelan, APNIC, pointed out that prop-162 “Whois Privacy” had now reached consensus. As part of its implementation, APNIC would eventually revoke all bulk Whois access for existing users, and a new system would require the periodic renewal of agreements.

RIPE Docs & the Evolution of This Thing of Ours

Ilke Ilhan, RIPE NCC

Presentation slides and recording available at:
https://ripe91.ripe.net/programme/meeting-plan/sessions/40/UJZ9N3/

Ilke gave an engaging presentation about the history of the RIPE Documents and how they told the story of the community, showing its evolution over time.

Franziska Lichtblau, Address Policy WG Co-chair thanked Ilke for her excellent work. She said comments in the chat indicated that her analysis reflected what people had actually felt at the time.

Brian Nisbet, HEAnet, said this was a wonderful introduction to the state of where they were now, especially for newcomers. The fact that they didn’t throw these documents away was a fantastic example of archiving that was hugely useful.

Tom Strickx, Cloudflare said this was amazing work, and it was good that they could look back and acknowledge what went before. He said he would love to see a follow-up to this once a year. He suggested Ilke look at the members-discuss list, and how discussions went to other mailing lists.

Peter Hessler, Database WG Co-chair, said that while the Database WG didn’t publish policy per se, a lot of work was based on Numbered Work Items. He asked Ilke to include NWIs in future analyses.

Sander Steffan, former Address Policy WG Co-chair, said that the period with the high number of documentation changes exactly overlapped with his time as a WG chair, and he wanted to leave it with the room whether that was correlation or causation.

Will van Gulik, Saitis / RomandIX, said he was seeing that they had a really good way to archive these documents within the RIPE community. He wondered if they needed a way to track documents in the wider sense for other communities so they didn’t lose track of their history.

Ilke noted that even the archived documents were in the RIPE Document store.

Hisham Ibrahim, RIPE NCC, thanked Ilke and suggested for future work they could create a Best Current Operational Practices (BCOP) on how decision making and consensus worked within the RIPE community.

Franziska thanked Ilke for her presentation and for describing the current situation as “calm”. She added that the community might want to think about how they could get people to engage and join in on policy discussions again.

Registration Services Update

Marco Schmidt, RIPE NCC

Presentation slides and recording available at:
https://ripe91.ripe.net/programme/meeting-plan/sessions/40/FJ7YSH/

Marco presented the Registration Services update, including the informational RFC 9663 which proposed to allocate unique IPv6 prefixes per client, which could impact their IPv6 policy. Other topics included improving accuracy for legacy resources without a contract, enhancing resource holder information, and a new request form for LIRs to stop their sponsorship of independent resources.

Jordi (online) said, regarding RFC 9663, he didn’t see a problem in terms of “large enough justification”, as people could tell the RIPE NCC in their request that they were allowing RFC 9663 in their networks. He had created a proposal in 2018 to address the PI-related issues but he had later withdrawn it. He could see that this had been a mistake as they were now back with the same problem. It was likely that people were either violating the current policy or avoiding IPv6 deployments because they couldn’t do it correctly. He already had a new draft proposal that he would share on the mailing list soon. He finished by saying that as a community they needed to be proactive in addressing any policy-related issues so they didn’t stand in the way of IPv6 deployment.

Emanuele Iovini, Europol, said not knowing who was behind 5% of legacy space seemed like a risk to him, because people could commit crimes with those addresses. He asked the community to start a technical assessment to address this. He really liked improving resource holder information and thanked Marco for his proposal. He said he wanted to participate in these discussions as he had ideas from the perspective of law enforcement.

Marco said he wanted to clarify about this 5%. While they could agree that this was a lot, as the RIPE NCC they did have a pretty good idea who these resource holders were, it was just not visible to the public.

Gert Döring, SpaceNet AG, said that regarding the legacy resource holder proposal, he thought it was a good idea as it was an improvement and relatively low effort. On the organisational data proposal, he thought that was reasonable, though he would like to see an impact analysis to see if there were legal implications. Regarding the stop sponsoring request form, he asked that the system check for any already open tickets for the resources, and to notify them when unsponsoring resources.

Marco noted that only the stopping of sponsorships would be automated, not the deregistration of any resources. He said they would publish more details on both proposals before moving ahead.

Peter suggested they publish an LIR’s registration number in the LIR Portal or on the list of members page instead of the RIPE Database, as this made it very clear who was responsible for updating the information and who had validated it, while in whois there could be some confusion, especially when using third-party clients.

Jen Linkova, Google, thanked Marco for being proactive in considering the policy implications of RFC 9663. She was happy to help and would love to hear from people who wanted to deploy it but couldn’t because of the policy. She thought the policy should reflect operational reality.

Clara Wade, AWS, speaking for herself, thanked Marco and said she was in favour of the proposals. She supported verifying legacy holders. As part of the Charging Scheme Task Force, they had seen a lot of data about this, and were also aware of the situation where legacy status can be inherited in the RIPE region, which was a loophole that can be used to avoid policy and paying fees. She and Peter had been working on a draft proposal to put an end to that.

Gert commented on the prefix delegation proposal. He said the PI policy had been deliberately written in a way that discouraged giving addresses to third parties. However, it later became clear that if someone used your wifi, that was not really a third party. The policy said not to give a prefix but this situation was not envisaged. That was the scope of the discussions they would have – how to make a good PI policy without encouraging things they didn’t want. Part of what they wanted to avoid was an ISP running on PI space giving all their customers only a /64.

Franziska thanked Gert for the clarification.

End of first session.

Session 2

Thursday, 23 October 2025 14:00 ‐ 15:30 (UTC+3)
Chaired By: Leo Vegoda, Franziska Lichtblau, Alex le Heux
Scribe: Antony Gollan

View the recordings
View the stenography transcripts
View the chat logs

2024-02: IPv6 Initial Allocations /28 and extension to /28

Jordi Palet Martinez, The IPv6 Company
Rinse Kloek

Presentation slides and recording available at:
https://ripe91.ripe.net/programme/meeting-plan/sessions/43/E8MVFH/

Rinse presented his and Jordi’s proposal to expand the size of initial IPv6 allocations up to a maximum of /28 without requiring additional supporting information. They were proposing to reserve a /26 for each initial allocation and 90% of existing /32s and /29s could also be expanded to that size.

There were no comments.

2025-01 2.0: ASN assignment criteria revisited

Urban Suhadolnik
Tobias Fiebig

Presentation slides and recording available at:
https://ripe91.ripe.net/programme/meeting-plan/sessions/43/PJKSWV/

This proposal aimed to remove the multi-homing requirement for ASN assignments and eliminate the need to provide an explanation for the first assignment. However, the recipient would still need to peer with a third party and publish a unique routing policy in the RIPE Database.

Gert said he liked that Urban and Tobias were making an attempt to simplify the policy. He thought the short and concise text they had was good. He added that the new policy should not apply retroactively, as it would be unreasonable to re-evaluate historical assignments made under different rules, and contract law would likely prevent this anyway.

Gert said he was neutral on the policy’s goal of making ASNs easier to get. He had some reservations on the number of ASNs showing up in BGP, as this increase was not without cost. It was important to keep a reclaiming mechanism – a small fee of EUR 50 per year would sufficiently annoy people into returning ASNs they didn’t need and prevent them from requesting too many. If the policy was going to become more relaxed, they would need to keep this sort of financial mechanism in place to drive the return of these resources. Of course, the WG didn’t set the charging scheme, but they could at least issue a statement to the RIPE NCC Executive Board or the GM about this.

Urban said he was concerned that a fee of EUR 50 per ASN was nothing for a business and might not deter bulk use if there were new commercial products that relied on public ASNs. He also asked the community to consider whether the proposed criteria for reusing existing unused ASNs were appropriate, and whether it should apply to all historical assignments or only future ones.

Gert said if someone with 20 unused ASNs claimed they had a need for more assignments, they should be able to explain why. He also recommended they avoid trying to define End User in the policy, as that could become very difficult.

Jordi Palet Martinez, The IPv6 Company, (online) suggested that instead of “Third party”, they could use “Third party/ISP or business unit when it's the same organisation. Some special cases documented in RFCs are also supported.” He thought this covered all possible cases.

David Tatlisu, IONOS SE, said he was in favour of lifting restrictions as 32-bit ASNs removed all scarcity. He cautioned against encouraging organisations to create multiple LIRs solely to meet policy criteria, since this came with privileges such as additional voting rights. His company had eight different LIRs for historical reasons and they had a goal to move everything into one LIR without having to renumber. While it was outside the scope of the WG, he thought they should consider a pricing model where the cost increased exponentially per ASN – as this could eventually start to impact the balance sheet of organisations that were hoarding hundreds of them.

Urban said it was a good point about LIRs and maybe he would need to talk to the RIPE NCC about the specifics later. He wasn’t sure how to distinguish between separate business units and this seemed like something worth looking at further.

Marco Schmidt, RIPE NCC, recommended they not try to solve potential edge cases through the policy, since the more specific it became, the less flexibility the RIPE NCC had to find workable interpretations for difficult requests.

Jahongir Jabborov, Babilon-T ISP, (online) asked how the RIPE NCC would define and assess cases of intermittent ASN usage. For example, how temporary usage should be before a benefit statement became insufficient.

Urban said research and measurement projects often used ASNs intermittently, such as 16-bit ASNs that appeared only during periodic research runs, or temporary ASNs used for recurring events. The general idea was that the ASN should be in use, but that was meant in terms of “not abandoned.” If the ASN was only visible a couple times each year, that seemed fine to him.

Marco added that the RIPE NCC already had a policy for temporary assignments which included ASNs. He noted that community members might find it confusing to distinguish between “intermittent” and “temporary” use, and so an impact analysis might be needed. While the existing temporary assignment policy worked for cases like annual conferences, the proposed policy changes created some overlap that should be considered.

Urban said that in most cases a simple justification, such as the need for a specific ASN for measurement purposes, would be a good enough benefit statement.

Jordi (online) said he partially disagreed with Gert’s earlier point about the retroactive application of policy, since RIPE NCC members were bound to follow policy changes. However, while he thought that previous cases should not be re-evaluated, same or similar cases must be supported in the future.

Sander Steffann, speaking as a former APWG co-chair, said the last time the ASN policy came up, one of the worries had been that people might request a million ASNs because there was no rate limit, however now they had the current per-ASN fees which acted as a limiting factor. He asked what problem they were trying to solve by keeping the complex assignment criteria.

Urban said he thought EUR 50 wouldn’t deter all forms of stockpiling, especially if someone created products or systems that used public ASNs for internal purposes. He thought it was important to preserve some basic criteria to ensure that ASNs were tied to outward-facing use.

Franziska asked Urban what his next steps would be.

Urban said the next step would be to go through the feedback again (and so he would appreciate as much community feedback as possible on the mailing list). For edge cases, they would likely have one sentence to cover all of them as special cases, and to open the door for experimental usage. Some parts might be removed if they specified too much, based on the feedback.

Gert said he might want to consider having a sentence which said that ASNs were freely available so long as there was a fee in place, and if there was no fee then there was no longer a policy and nobody could get ASNs. The actual cost was less important than the annoyance of having to pay the fee. As Sander had said, they could do away with most of the criteria so long as there was a reclaiming function.

Tobias Fiebig, Max-Planck Institut fuer Informatik, (online) speaking for himself and as a co-author of the policy, said he wanted to respond to the idea of tying fees to the policy. He thought this could result in too much text and so he wanted to caution against that.

2024-01: Revised IPv6 PI Assignment Policy

Tobias Fiebig
Clara Wade

Presentation slides and recording available at:
https://ripe91.ripe.net/programme/meeting-plan/sessions/43/N7MVYE/

Clara presented on the updated proposal. In this latest version, the definition of End Site was spun off into a separate proposal. Section 7.1 had been simplified, and some redundant statements were removed.

There were no questions.

Open Mic.

Recording available at:
https://ripe91.ripe.net/programme/meeting-plan/sessions/43/998PQF/

Radu-Adrian Feurdean, France-IX, said they had hit an issue with the current policy, which did not allow the transfer of IX blocks from one entity to another. He asked if it was worth updating the policy so that an allocation could be transferred, provided the underlying reality remained the same.

Marco asked Radu to speak with him so they could look at the details. They had processed one such transfer in the past and it sounded like this should be possible under the current policy.

Gert said at one point they had tried to have a transfer policy which covered everything and perhaps it was simply an oversight that they had forgotten about IXPs. It was great that the RIPE NCC was available to find solutions but it would be good to save that extra round.

Marco said the policy was clear that all resources could be transferred unless another policy overruled them, and the IXP policy said that unused allocations should be returned.

Gert said technically they were still being used by the same network, which was why they could be transferred.

Marco said this was correct.

Angela said she wanted to signal there was another inconsistency with this. They had this specification for IPv4 addresses for IXPs while IPv6 addresses could still be transferred – because in the IPv6 policies there was not a specific exclusion from transfers. The exclusion came from the fact that the return was mandated if the holder was not applicable anymore. So if somebody from the community wanted to work on that they were welcome.

Franziska thanked Radu for raising this topic.

Gert said he wasn’t happy with how the session had been scheduled at this meeting. He had wanted to speak with the chairs after the first session but they had needed to run off to join the WG Chairs Collective meeting. This was not optimal if people wanted to speak with the chairs before the second session.

Franziska said she had also noticed that. Probably there was nothing stopping them from being a little later to that meeting. Some people were happy with the way the break was structured, but they could see what they wanted to do here.

Sander said in policies over the last couple of years, there seemed to be a tendency to want to specify everything. He encouraged the WG to consider the balance between keeping the policy straightforward and accepting that there would be some edge cases that arose from this.

Franziska said the chairs had also been thinking about this. However, while Sander made a very compelling case, there were some underlying concerns that they should address, as there seemed to be a lack of clarity about how much room the RIPE NCC had to interpret the policies. She said they probably needed to have a broader discussion about this as a WG.

Urban said he supported the new format with lunch in-between the two sessions.

Franziska said there might be other options available, like having the session on Wednesday or moving the WG Chairs meeting.

Tobias noted he was involved in two thirds of the proposals that were currently open. He said the policy would not get simpler if nobody helped with the simplification. So if this was something they wanted, then they needed a few more people to actually step up and start doing things.

End of second session.