RIPE 89 Address Policy Working Group Minutes

Session 1

Wednesday, 30 October 09:00 - 10:30 (UTC+1)
Chaired By: Leo Vegoda, Alex le Heux
Scribe: Alun Davies
Status: Draft

A. Open Session

Presentation slides and recording available at:
https://ripe89.ripe.net/archives/video/1461

The session started with a welcome from the Working Group Chairs, Leo Vegoda and Alex le Heux. They introduced the agenda and provided guidelines for participation, emphasising the importance of the RIPE Code of Conduct.

B. In Memoriam - Erik Bais

Presentation slides and recording available at:
https://ripe89.ripe.net/archives/video/1463

The community paid tribute to Erik Bais who sadly passed away shortly after RIPE 88. Alex le Heux shared heartfelt memories, highlighting Erik's significant contributions and the warmth he brought to the community. Mirjam Kühne (RIPE Chair), Sander Stefan (RIPE NCC Executive Board), Nathalie Trenaman (AMS-IX) and Brian Nisbet (HEAnet) also stepped up to say some words of condolence. A moment of silence was observed in Erik's honour.

C. ASO AC Update

Hervé Clément / Constanze Bürger

Presentation slides and recording available at:
https://ripe89.ripe.net/archives/video/1465

Hervé provided an update on the NRO NC and the ICP-2 review project. The presentation covered topics including the election process for the ICANN Board seat 10 and provided a timeline for the ICP-2 project, the main goal of which is to strengthen INR management or registration by modernising ICP-2 in collaboration with regional and ICANN communities. Hervé called for input from the community, inviting the audience to share feedback via the ICP-2 questionnaire.

Leo expressed thanks to the NRO for their work and encouraged people to take part in the consultation. Constanze Buerger (ASO AC) seconded this, encouraging people to take the questionnaire.

Jordi Palet Martinez (Moremar - The IPv6 Company; attending online) commented that he hadn't received feedback after filling in the questionnaire. Hervé pointed out that feedback will be given later on, once all responses are in.

Rüdiger Volk (retired) asked what changes are expected around plans for the ICP‑2, specifically with reference to a talk from Randy Bush at RIPE 88. Hervé suggested that they might need to go and look back at Randy's presentation to answer that properly and thanked Rudiger for the question.

No further questions.

D. Policy Update

Angela Dall'Ara, RIPE NCC

Presentation slides and recording available at:
https://ripe89.ripe.net/archives/video/1467

Angela talked about recent policy updates, including changes to IPv4 and IPv6 assignment policies, and emphasised the importance of community feedback in the Policy Development Process. Two IPv6 proposals were listed as under discussion: one on revising PI assignment policies and one aimed at extending allocations from /29 to /28. Updates from other RIRs included AFRINIC’s governance challenges, APNIC’s reduction of IPv4 assignments for IXPs, ARIN’s implementation of allocation clarifications, and LACNIC’s new rules for abandoning dormant proposals. Angela encouraged global engagement and shared resources for tracking policy developments.

Karla Skarda (APNIC) clarified that, with regards prop 156, the temporary assignment is for conferences and events only and is for six months. She noted that the information was in the deck, but wanted to clarify to be clear. Angela thanks Karla.

No further questions.

E. Registration Services Update

Marco Schmidt, RIPE NCC

Presentation slides and recording available at:
https://ripe89.ripe.net/archives/video/1469

Marco provided updates on IPv6 allocation transfers, IXP assignment policies, and temporary transfers. He reported that measures to curb IPv6 stockpiling, including stricter need justification, have led to a significant reduction in transfers. Smaller default IXP assignments have extended the IPv4 pool lifespan for IXPs. Procedural changes have also clarified temporary transfer rules for cases like member terminations or EU sanctions. Marco also proposed adding details, such as party location and transfer type, to transfer statistics and sought feedback on whether to address this through policy changes or administrative decisions.

Wolfgang Tremmel (DE-CIX Academy) asked how many of the new IXPs were happy with the /26, and how many asked for a larger network. Marco did not have exact figures but noted that when the request was received, things went smoothly.

Gert Döering (SpaceNet AG) thanked Marco for the clarification on transfers and what happens in the case of sanctions or shutdowns. On the question of the transfer statistics, he noted that the WG shouldn't micro-manage the RIPE NCC, so the extra columns, in the transfer logs, should be added if the RIPE NCC deems it useful.

Clara Wade (AWS) commented that it's great to see the implementation of the changes to IPv6 transfer procedure having the needed effect. On temporary transfers, she suggested that given the lack of transfer fees, the small periods of the requests, and the increased costs for RIPE NCC staff for diligence checks, there should be a minimum period. The community will probably look to the RIPE NCC to determine what is reasonable there.

Jordi Palet Martinez (Moremar - The IPv6 Company; attending online) commented that temporary transfer policies raise questions about minimum/maximum periods in RIR regions that don't have them. He suggested a minimum transfer period of 30 days.

Tobias Fiebig (MPI-INF/AS59645) asked if any ISP assignment requests came in without asking for v4. Marco said he would be happy to look into that with the team.

There were no further questions.

F. Personal ASN Open House Recap

Marco Schmidt, RIPE NCC

Presentation slides and recording available at:
https://ripe89.ripe.net/archives/video/1471

Marco recapped the RIPE NCC Open House on Personal ASNs, highlighting some of the questions that arose around policy implications and usage. Marco provided a broad overview of ASNs registered in the RIPE Registry and discussed issues around policy-related matters, such as the multihoming requirement. He noted efforts to address unused ASNs through the new charging scheme and community outreach, encouraging members to review and update their resources.

Gert Döering commented that it was interesting to see the distribution of ASNs in terms of visibility. He read that the policy text states that they must be multihomed and have a unique routing policy. He noted that having something in place before people just grab a whole bunch of ASNs is probably a good thing. And keeping that fee incentive there perhaps makes it possible to keep things slightly looser on the policy side.

Urban Suhadolnik (TU Graz) asked what is done with the returned ASNs, both for 16-bit and 32‑bit. Marco responded that they are recycled - after six months they go into the available pool. He added that currently no distinction is made here between 16‑bit and 32‑bit ASNs.

Tobias Fiebig noted that you can have a unique routing policy for an ASN even though you are technically single‑homed. As an example, he pointed out that AS215250 is single-homed but active across many IXPs. So there are lots of cases to consider here in terms of how things are defined and the related policy restrictions, because these things can be hard to check. Marco responded that in the charts he showed, he did not want to say that half of ASNs are in conflict with the policy. Establishing this means contacting the holders, which takes work.

Radu-Adrian Feurdean (France-IX) said that one reason for unannounced ASNs is route servers ASNs. He asked if Marco was taking these ASNs into account and asked, if so, whether these could be taken as a separate case because of the visibility issues around route servers. Marco responded that he was aware of this and that he was presenting a relatively simple view and that there are many reasons why something might not be visible.

Dominik Dobrowolski (dcloud.cx) pointed out that many ASNs for businesses are registered as natural persons. He also noted that it's important to keep in mind the scale of ASNs we're actually looking at here - we're not really facing any problems of ASN exhaustion. Marco agreed and noted that there is much to keep in mind while looking at ASN registrations and making sure policies are being followed.

There were no further questions.

At the end of the first session, Leo Vegoda brought up the need for a third co-chair. He gave six months' notice that the WG should select an additional co-chair at RIPE 90 in Lisbon. Potential candidates should think about what they want from the WG and whether they might be a good fit for the co-chair. He added that there's a job description for RIPE co-chairs in ripe-692. Leo then ended the first session, reminding the room that the second session would continue after the break.

End of first session.

Session 2

Wednesday, 30 October 11:00 - 12:30 (UTC+1)

Chaired By: Leo Vegoda, Alex le Heux

Scribe: Antony Gollan

G. 2024-01: Revised IPv6 PI Assignment Policy

Tobias Fiebig

Presentation slides and recording available at:
https://ripe89.ripe.net/archives/video/1475/

Tobias gave an update on his policy proposal, which aimed to reduce fragmentation within the registry space, provide more flexibility for End Users, and clarify ambiguities in the current policy. The proposal sought to simplify the definitions of sub-assignments and end sites while introducing a structured framework for nibble-boundary allocations to address growth and renumbering concerns. Tobias detailed the changes to Sections 2.6 and 7 of the policy, emphasising the goal of creating policies that align with operational realities and reduce unnecessary complexity.

Gert Döring (SpaceNet AG) said his main objection was that the proposal was adding too much text to an already complex document. RIPE policies should be workable and readable. He said they needed to consider what they wanted to achieve and whether it could be done with fewer words.

Tobias responded that the first draft of the policy had been much simpler, but as the process evolved, new requirements and clarifications were added to address issues raised by the community and the RIPE NCC. He acknowledged that the growing complexity was a valid concern.

Gert said that there was no need for separate definitions of end sites for PI and PA. He asked why they wanted to duplicate definitions unnecessarily. He was also concerned about the use of "Layer 2" as a specific term, and suggested it could exclude valid cases or create ambiguities in application.

Tobias clarified that the intention was to remove unnecessary distinctions and align the language with RIPE NCC’s operational practices. He emphasised that the proposed policy sought to simplify rather than introduce new layers of complexity. However, he welcomed feedback on alternative language to ensure clarity and practicality.

There were no further questions.

H. 2024-02: IPv6 Initial Allocations /28

Jordi Palet Martínez and Rinse Kloek

Presentations slides and recording available at:
https://ripe89.ripe.net/archives/video/1477/

Jordi Palet Martínez and Rinse Kloek presented their proposal to simplify IPv6 allocation policies by introducing a clear choice between /32 and /28 as initial allocations. This change aims to improve aggregation, reduce administrative overhead, and address the operational challenges associated with justifying allocation extensions. They shared statistics demonstrating that 90% of requests in the previous year had been for a /29 instead of a /32, and that 91% of existing allocations could be extended to /28 without additional justification. He highlighted the importance of providing LIRs with simplified options.

Rüdiger Volk (retired) questioned the lack of specific deployment data supporting the proposal and the lack of counter-arguments. He said the proposal could undermine the goal of address-space conservation without clear evidence of real operational need. Rudiger argued that the community needed reports detailing deployment experiences and how allocations of /29 and /28 had been used in practice. These reports might very well justify going ahead, but without specific reasoning this was not acceptable.

Jordi said that the proposal was based on discussions held over two years and statistical data provided by the RIPE NCC. In terms of deployment experience, for a provider with less than 50,000 sides, a /32 was more than enough. But for a medium ISP with 4-500,000 sites, a /29 was not enough. He added that the focus of the proposal was on improving aggregation rather than conservation, as IPv6 did not face the same constraints as IPv4 in terms of available addresses.

Remco van Mook (speaking for himself) said he had two observations. First, if he followed the rationale they had provided, which was essentially that a /28 was simply better than a /29, then they could eliminate the /32 option entirely to help people, especially if aggregation was so important. Second, the reason they could easily expand the allocation size was because the RIPE NCC had helpfully reserved adjacent address space each time they had increased the allocation size in the past. If the RIPE NCC continued to reserve larger blocks (up to a /24) for future growth, it could lead to a cycle of ever-larger allocations. If they were going to do this, he thought they should be very explicit in instructing the RIPE NCC that aggregation beyond this block was not necessarily required. He finished by saying that he currently had no opinion on whether he supported the proposal.

Jordi said it might be worth having some text that provided guidance to the RIPE NCC as Remco suggested. Rather than the issue of /32s vs /29s vs /28s (Remco’s first point), one of the open questions was whether people wanted this to be a choice between two sizes or anything in the middle as he said in his presentation.

Rinse added that since 2016 the RIPE NCC had been reserving a /25. Also, 90% of people went with a /29 when given a choice. He expected the same to happen if they went to a /28. The only difference was that they wanted to stick to the nibble boundary, which was why they wanted to go for the two variants (/32 and /28).

Denys Titov (DCXV), asked what would happen when LIRs with allocations underwent a merger or acquisition.

Jordi said they kept both allocations, and under their proposal they would be able to expand each of them to a /28.

Richard Patterson (Sky) shared his experience requesting additional IPv6 allocations and voiced support for the /28 option. However, he cautioned against scenarios where LIRs might face higher barriers to justify allocations exceeding /32, which in his experience seemed like a very real possibility. Richard emphasised that LIRs should have the option to choose /28 without undue justification requirements.

Jordi said the point of the current text was that it was the LIR’s decision whether they wanted a /32 or a /28.

Angela Dall'Ara (RIPE NCC Policy Officer) clarified that for initial allocations there was currently no requirement to justify their need for the addresses. The justification was in terms of documenting that they had a plan to deploy IPv6 within the next two years. She reassured Richard that the proposal would not introduce additional burdens in this regard.

Dominik Dobrowolski (speaking for himself) said they had previously expanded the allocation size and he wanted to know if they expected to see an aggregation benefit from this proposal.

Sergey Myasoedov (NetArt Group) (online), said stockpiling should be considered an argument against the proposal.

Sebastian Jürges (Bundesdruckerei) (online), said there was a middle ground for every request that was a /32 aligned with a /28. Nibble boundaries while they had available space allowed for expansion in the future.

There were no further questions.

I. Simplifying Assignment Status

Remco van Mook

Presentation slides and recording available at:
https://ripe89.ripe.net/archives/video/1479/

Remco presented his proposal to simplify/reduce the number of different statuses applied to address space in the RIPE Database. He explained there were longstanding reasons for these differences, but for the wider world many of these were largely irrelevant. These distinctions also made it harder for people to understand policies and to use the RIPE Database. He suggested they start with the INETNUM status field, which conflated information about contractual relationships with operational state.

Tobias said Remco’s proposal suffered from the same problem as his own PI proposal, where all of these problems had come up. He thought the proposal was too big and essentially they needed to start from a clean slate.

Nick Hilliard (INEX) agreed with Tobias that this was too big. He also didn’t think he understood Remco’s proposal enough, and so thought more work was needed to express what he was trying to achieve and to break the proposal up into smaller pieces that were more manageable.

Tina Morris (AWS) said she supported the idea of having a limited selection of states, though not necessarily changing existing statuses without careful consideration. She also thought they should review their policies to clean them up more generally.

Gert said he hadn’t supported the proposal when it had been proposed on the list, since it would take away information that was useful. He appreciated seeing more of the thought process behind it. He agreed they should make the explanations for the things they did easier and more accessible, and they should have complete documentation available. Simplifying the values was a worthy undertaking, but he did value being able to see the contractual relationship somewhere, and it would be good to keep that in some form, though he didn’t have a clear idea of how to get there. He thought this was a worthy undertaking.

Jordi Palet Martinez, (IPv6 Company) (online), said he had always thought having a single consolidated policy manual was better than separate documents, and RIPE was the only community that did it this way. He thought this would probably require a Task Force but it made sense and he would be happy to participate.

There were no further questions.

J. Open Mic

Recording available at:
https://ripe89.ripe.net/archives/video/1481/

Nick said there was no particular resource constraint on ASNs these days, and now that they had a per-ASN charge to take care of the “garbage collection”, he didn’t see a need to maintain the multihoming requirement. The role of the RIPE NCC was to record people rather than constrain what they were doing.

Lee Howard (IPv4.Global-Hilco Streambank) said it wasn’t clear in the policy that temporary transfers did not trigger the 24-month holding period, nor was it clear that a temporary transfer could only occur for a maximum of one year. He thought this was something they would need to clarify.

SilvanGebhardt (Openfactory) asked people to join them on their proposal as he thought the IPv6 PI assignment policy would also clean up the current fragmentation of PA space being used as an alternative to PI, so this should be worked on.

Leo said they had a lot going on in the WG at the moment. They had three active policy proposals and ideas for a fourth or a fifth, so they would be busy. He said he would appreciate it if people shared any reflections they had from the session on the mailing list. He thanked everyone who had joined the session, both in person and online.

End of second session.