RIPE 90 Address Policy Working Group Minutes
Session 1
Wednesday, 14 May 2025 09:00 - 10:30 (UTC+1)
Chaired by: Leo Vegoda, Alex le Heux
Scribe: Antony Gollan
Status: Draft
View the recordings
View the stenography transcript
View the chat logs
A. Open Session
Presentation slides and recording available at:
https://ripe90.ripe.net/archives/video/1605/
Leo Vegoda, Address Policy WG Co-chair, welcomed attendees to the session and ran through the Agenda.
The minutes from RIPE 89 were approved.
B. Co-chair Selection
Presentation slides and recording available at:
https://ripe90.ripe.net/archives/video/1607/
Ahead of RIPE 90, Franziska Lichtblau had volunteered to serve as co-chair of the WG. Leo invited her to say a few words to introduce herself.
Franziska said she had been part of the community for ten years while doing Internet measurement research. She had also worked on cloud infrastructure operations, and was a member of the RIPE Programme Committee and Code of Conduct Team. She was recently approached by people asking her to serve as co-chair and so had decided to step forward.
Franziska was selected as Address Policy WG Co-chair by acclamation.
C. NRO NC (ASO AC) Update and D. ICP-2 Update
Hervé Clément, Constanze Bürger and Andrei Robachevsky, NRO NC / ASO AC
Presentation slides and recording available at:
https://ripe90.ripe.net/archives/video/1609/
Hervé Clément, Constanze Bürger and Andrei Robachevsky explained what the NRO NC / ASO AC did and how it was organised. They explained some of the context around the ongoing consultation to update “Internet Coordination Policy-2 (ICP-2) – Criteria for the Establishment of New Regional Internet Registries”. This document was 25 years old and had been developed after three of the five RIRs were already created. The updated draft document made RIRs’ obligations more explicit and outlined the conditions under which they could be de-recognised. The community had until 27 May 2025 to give feedback on the draft.
Sander Steffann, RIPE NCC Executive Board, speaking as an ex-NRO NC member, said he encouraged people in the community to give feedback. Once the document was finished, the leadership of the RIRs would have to implement it, so people needed to speak up if they wanted to see something specific.
Maximilian Emig, (online), no affiliation, asked if NIRs were in scope for this.
Andrei said that they were not.
Constanze added that this was also covered in the FAQ.
Randy Bush, IIJ Research / Arrcus, said this was a boring, tedious, administrative document and process and they would all like to ignore it. However, it was also the foundation they would have to live with for the next two decades. He said it was critical that the community paid attention and got it right.
Constanze said the NRO NC was grateful for the community’s engagement with the process and for sharing its experience with them.
Andrei said that while he didn’t want to undermine Randy’s point, the updated document had a section on review periods and so it wouldn’t be two decades before they could make further modifications.
E. Policy Update
Angela Dall'Ara, RIPE NCC
Presentation slides and recording available at:
https://ripe90.ripe.net/archives/video/1611/
Angela ran through policy developments in the other RIR regions. She then noted that there were 16 policies currently applicable within the RIPE region, in addition to six global policies. She asked if the community would like to consolidate these into a single policy document and outlined a few different approaches – ranging from a community task force to the RIPE NCC proposing consolidated policy documents for discussion in the PDP.
Jordi Palet Martinez, The IPv6 Company, said he was very much in favour of this work. He hoped that the RIPE NCC could do this work and have the community provide input. If that wasn’t an option, then he was happy to do the work himself, though he would also support a task force.
Tobias Fiebig, MPI-INF, said he thought it would be a mess whatever they did. The policies had grown over time and so, even if they just wanted to consolidate them, they would encounter policy implications. He also wasn’t convinced there would be sufficient engagement within the WG to help them spot all of these issues. He didn’t have any solutions, but he admired the problem and he supported the RIPE NCC in taking this on.
Marco Paesani, speaking for himself, said had seen that the new allocation size for IPv6 would be /28. He asked if older allocations (from /32 to /29) could also be extended to /28.
Angela said in this version of the policy proposal there was the option for each member to extend one existing allocation up to a /28.
Clara Wade, AWS, speaking for herself, said some of the options proposed could be applied to different purposes. For example, when it came to consolidating the policy into a single manual, perhaps a task force could handle this. She thought it would be great if the RIPE NCC’s Registry Services Team could also be involved in policy development, since they were much closer to this than many in the community.
Angela said her approach would be very gradual, because there were different outputs you could get from this procedure. Her first step would be to consolidate the existing content into one document without any changes. Once they had this, they could then work towards a manual, though this was a later stage.
Clara said a task force could be a step in the right direction, provided it included RIPE NCC staff.
Hans Petter, RIPE NCC CEO, said he had been a member of a RIPE community task force to consolidate and revise the IPv4 policies some 25 years earlier. The people in the room were the ones who would have to live with these policies and so he encouraged them to step forward and engage with this effort. Of course, the RIPE NCC would provide secretariat support and could do the heavy lifting, but they really needed the community to provide input and start building consensus early in the process.
F. Registration Services Update
Marco Schmidt, RIPE NCC
Presentation slides and recording available at:
https://ripe90.ripe.net/archives/video/1614/
Marco gave an update on what had happened since the per-ASN charge had been implemented. This had resulted in a drop of around 500 End Users and a further 1,100 End Users changing their sponsoring LIR. Their new approach to IPv6 transfers also seemed to be having the intended effect, though it created some frustration from those who were unable to justify multiple allocations. Finally, he shared that they now had 74% of legacy space under a direct or indirect contractual relationship, but the remaining address space presented some challenges – a lot of work was needed to review old company data and keep track of changes.
Clara Wade, AWS, speaking as a member of the Charging Scheme Task Force, said that one of the issues that had come up in their discussions was how labour intensive it was to deal with legacy space that wasn’t under a contractual relationship. This required half a full-time employee’s time which was why they recommended charging for this. Another issue, which was out of scope for the TF, was that the “right to hold legacy resources” was meant for those who had received the allocation originally, but this could then be transferred along with the addresses to a new recipient.
Marco said it was only in the RIPE region that they had the concept of “legacy resources”, which could be transferred on to a new holder. In the other RIR regions they had the concept of “legacy resource holder” which was the one who had originally received the resources.
Clara added that legacy resources were being portrayed as a business opportunity because they had less operational cost. There were also cases where they were making updates to the RIPE Database directly without going through the registry, which was not where they wanted to be as a community.
Carlos Friaças, FCT|FCCN (Portuguese NREN) / member of the Charging Scheme Task Force, asked whether Marco thought they needed changes to the policy or if there were other approaches that could be taken.
Marco said at this stage he mostly wanted to bring this to the attention of the WG and he didn’t have a clear personal opinion yet.
Jordi said he didn’t think the rights of the legacy holders should be transferrable. In other regions they had to sign a contract or they lost their legacy status. He thought they should consider this in the RIPE region as well. He also thought legacy holders should not be able to receive services without paying for them. He understood from Marco’s presentation that around 20% of holders didn’t know they had the addresses or didn’t exist anymore, which was an opportunity for abuse. He said that in the APNIC region they were attempting to contact these holders and if there was no contact in place or they did not sign an agreement, they were recovering the addresses and returning them to their membership.
Marco said he wanted to make it clear that while there were various initiatives in the ARIN, LACNIC and APNIC regions, there was currently nothing like that planned here. He personally thought it was good that the existing policy allowed the RIPE NCC to provide some services to people without a contractual relationship because this helped registry accuracy, but he also wanted to highlight the downsides that came with this.
Randy said he was a legacy holder and asked what their goal was. He thought it was to ensure an accurate registry while being fiscally responsible. He said they shouldn’t replicate the approach APNIC and ARIN had chosen. He didn’t think they gained anything by removing the “legacy” status after addresses were transferred, especially if this had no attributes other than a tag. Their aim should be to lower the barrier to become a member or buy services – so that data was accurately registered with contacts. He added that not all address space had to be visible in the global routing table to be in use.
Tobias said he was using a sub-allocation of legacy space and he loved it. This was because it allowed him to put everything in the registry to document his network and what he was using IP addresses for in a very specific and detailed way. He also had PI addresses, but these came with a significant reduction in utility and accuracy of registration that you could provide as a holder. He encouraged them to think about this in the context of the RIPE Database WG if they were thinking about taking away the status of legacy, because in the case of his specific prefix it would become just another /22 rather than a very detailed prefix that explained what was being used for what.
Marco clarified that he wasn’t suggesting they take away the legacy status as there was a very good reason why it was there. He simply wanted to point out the challenges in terms of accuracy.
Hans Petter said this problem had many dimensions and the example from Tobias was something he hadn’t thought about. However, that could easily be fixed by adding more features to the RIPE Database and so it wasn’t about legacy per se. Legacy meant the addresses had come from IANA or InterNIC before the RIPE NCC was set up – and the value proposition of the RIRs was that they offered the right to registration in their databases under a contract. Without this, he didn’t know how they could ensure the addresses weren’t registered to someone else. The question was then whether legacy holders ought to contribute to keep this system running.
Hans Petter continued by saying it didn’t sound right to have address space in the RIPE Database that wasn’t linked to an organisation. One approach could be to publish ORGANISATION objects that shared what they knew about the resources and to transparently make it clear when information hadn’t been updated since the space was first allocated. It was very difficult to untangle the history of this space when there had been various mergers and acquisitions and name changes since it had first been allocated in the 1970s. He finished by saying this wasn’t about taking addresses away from anyone, but how they ensured an accurate registry and how they cleaned up the last quarter of this address space that was remaining since the policy had been implemented over ten years ago.
End of first session.
Session 2
Wednesday, 14 May 2025 11:00 - 12:30 (UTC+1)
Chaired by: Leo Vegoda, Alex le Heux, Franziska Lichtblau
Scribe: Virgile Uytterhaegen
View the recordings
View the stenography transcript
View the chat logs
G. IPv6 PI Policy
Tobias Fiebig, MPI-INF
Presentation slides and recording available at:
https://ripe90.ripe.net/archives/video/1616
Tobias presented on the status of the policy proposal 2024-01, “IPv6 Assignment Policy Revision”. Even though the initial plan was to use the nibble boundary and give out blocks bigger than /48, the reality is different. He mentioned different corner cases and the situation introduced by splitting on the nibble boundary. He concluded his talk by asking for feedback on the proposal.
Stefan Wahl, Route128, made a comment that he always advised his customers to go for the nibble boundary and that he thought Tobias’s proposal was good and should be adopted.
Blake Willis, L33 Networks, pointed out that IPv4 thinking should be discarded when designing IPv6 networks and questioned how to keep the changes to a minimum after provisioning addresses.
H. IPv6 Initial Allocations
Jordi Palet-Martínez, The IPv6 Company
Presentation slides and recording available at:
https://ripe90.ripe.net/archives/video/1619
Jordi presented version 3 of the proposal 2024-02, “IPv6 Initial Allocations /28” which aimed to make IPv6 easy to get and to encourage aggregation. He shared some stats from the RIPE NCC which showed the need for extending /29 allocations to /28 and explained that some ISPs had difficulty justifying this need. His main proposal to solve this was to allow LIRs to get initial allocations between /32 and /28. Regarding members with multiple LIRs, to avoid the stockpiling of IP addresses Jordi suggested they allow these members to extend only 1 of their allocations to /28. The main benefits of the proposal were to reduce the overhead for the RIPE NCC and to give flexibility to LIRs. Jordi concluded his presentation with the advice from the co-chairs to split the proposal into smaller parts. Fellow proposer Rinse Kloek joined him on stage to answer questions.
Ondřej Caletka, (online), RIPE NCC, asked Jordi’s opinion about charging members more for a /28 than for longer prefixes. Jordi replied that the charging scheme was not related to the size of the allocation and therefore this was a different discussion.
Dmytro Kohmanyuk, Hostmaster LLC, made a comment that it should be clarified which one they should be able to extend if a member with multiple accounts wanted to extend 1 LIR.
Jordi said that was what the proposal was about.
Eric Băleanu, InterLAN-IX, pointed out that /29 could be a real need and not just used for stockpiling.
Jordi said that the policy was designed for LIRs that need more than a /29.
Tobias said the problem was similar to what he proposed in the IPv6 PI policy and having too much text would overcomplicate things. He proposed that an LIR could hold up to a /28 without justification.
Rinse said that this was related to the discussion between “LIR” and “member” and clarified that member was a legal entity while LIR was operational.
Piotr Strzyżewski, no affiliation, said there was confusion between LIR and member in the policy and the restriction should be applied to the member and not LIRs. Jordi replied that in the previous version of the policy, the term organisation had been used. He said they were going for a restriction using the terminology from before. The term organisation was introduced in 2018.
Piotr said that this was a mistake from the past and should not be repeated.
Michael Booth, Independent, said that smaller companies could benefit from getting sponsored resources instead of going directly to the RIPE NCC to ask for a /29.
Blake Willis, L33 Networks, voiced concerns about certain RIRs allocating /16s to entities and said they would get very large blocks. He thought that asking LIRs for a justification to get a /28 would prevent LIRs from immediately transferring resources when they got the /28.
Tobias advised against introducing friction for a /28 because that would cost members money.
I. Removing Multihoming Requirement from ASNs
Urban Suhadolnik, TU Graz
Presentation slides and recording available at:
https://ripe90.ripe.net/archives/video/1621
Urban started the presentation by explaining that 32-bit ASNs were not a scarce resource and that half of the ASNs were not multi-homed and so didn’t meet the current policy requirements. He proposed they change the policy so that no justification was needed for the first ASN and additional ASNs needed to peer with an upstream to avoid chaining. The conclusion of his talk was that members should update the documentation they provided to the RIPE NCC and Urban asked if more responsibilities should be given to the LIRs.
Jordi Palet-Martínez, The IPv6 Company, supported the proposal and recommended using simpler text. He noted that he had proposed similar changes in October 2020 and was still waiting for feedback from the chairs.
Will van Gulik, Saitis / RomandIX, said he supported the proposal and he would have a use case for it soon.
Dmytro asked if a work item would be created for every request after six months. He thought the waiting period wasn't necessary and that single-user ASNs were fine.
Urban said he would get back to him on that after the session.
Tobias said that responsibility of LIRs should be considered to avoid members using the RIPE NCC for free KYC when requesting numbers for their End Users.
Urban thanked Tobias for highlighting that point and mentioned edge cases of LIRs doing a good job but their sponsored ASNs not following the policy.
Urban answered Dmytro that he would not like to have members with unused ASNs and that the six-month check would help make sure members needed them.
J. Open Mic
Recording available at:
https://ripe90.ripe.net/archives/video/1623/
Jordi Palet, The IPv6 Company, shared his concerns about the lack of formalism in the PDP. Sometimes it seemed like there was support for a policy while they were discussing in the room, but later once a policy proposal was submitted, there was no answer. He raised the issue of a policy proposal with multiple authors and what happened if one of the authors stepped out and the policy was still being considered by the chairs. He asked why the chairs had the power to decide who could submit a policy proposal, he thought this belonged with the community.
Leo said the chairs were responsible for managing the work of the WG. He said the chairs would be very happy to sit down with Jordi and discuss his concerns, he didn’t think it was helpful to discuss this in the session now.
Clara Wade, AWS, said she was concerned that the lack of utilisation requirements was being exploited. She believed this had been introduced around 2013 to remove bureaucracy. However, there were now some organisations that didn’t even run a real network getting address space transferred and flipping or monetising it. In the transfer logs they could see this involved /16s and /15s, and in some cases it was legacy space as well. She suggested it might be time to discuss having needs-based policy again.
Piotr Strzyżewski, no affiliation, made a comment to Jordi that he had been in a similar position with a proposal he wanted to make that was later taken up by someone else. He said that sometimes proposals were not accepted because of a lack of time and he thought it was better to move forward and not get stuck with that.
Jordi replied that they should change the PDP to reflect that, if that was the case.
Leo closed the session and invited participants to sign up to the mailing list and provide input in WG discussions.
End of second session.