- address-policy-wg - mailman.ripe.net

2026-01 Review Phase (Simplify assignment of first ASN)
by Angela Dall'Ara 03 Nov '26

03 Nov '26

Dear colleagues,   Policy proposal 2026-01, "Simplify assignment of first ASN", is now in the Review Phase.    This proposal aims to remove the needs assessment for the first AS Number requested by holders of an IP address prefix allocated or assigned directly by the RIPE NCC.   This proposal has been updated and it is now at version 2.0. The main difference from version 1.0 is that the routing policy should be documented in the RIPE Database also when the AS number received without providing a justification is in use.   The RIPE NCC has prepared an impact analysis on this proposal to support the community’s discussion.    You can find the proposal and impact analysis at:   https://www.ripe.net/community/policies/proposals/2026-01/ https://www.ripe.net/community/policies/proposals/2026-01#impact-analysis and the draft document at:  https://www.ripe.net/community/policies/proposals/2026-01/draft/  As per the RIPE Policy Development Process (PDP), the purpose of this four-week Review Phase is to continue the discussion of the proposal taking the impact analysis into consideration, and to review the full draft RIPE Policy Document.   At the end of the Review Phase, the Working Group (WG) Chairs will determine whether the WG has reached rough consensus.  It is therefore important to provide your opinion, even if it is simply a restatement of your input from the previous phase.   We encourage you to read the proposal, impact analysis and draft document and to send any comments to address-policy-wg(a)ripe.net before 10 November 2026. Kind regards,   Angela Dall'Ara Policy Officer RIPE NCC

10 9

Re: RIPE-826: time to revisit maybe
by Yannis Nikolopoulos 03 Nov '26

03 Nov '26

Hello, On 10/30/26 8:49 PM, Gert Doering wrote: > Hi, > > On Fri, Oct 30, 2026 at 04:13:51PM +0200, Yannis Nikolopoulos wrote: >> All I'm trying to say that, ISPs (like IXPs, which are BTW treated >> differently) are different from other RIPE members and providing they can >> show said growth and plans, they should be able to get additional IPv4 >> allocations. In essence, not all LIRs are equally displeased with this >> policy. Some are more displeased than others. > So you are saying that if you get more IPs, implying that even *less* > will be left for others, this would be a positive change? I'm not implying anything. I'm clearly stating that not all LIRs have the same needs and unlike IPv6 where we can use the flat "one size for all" model, in the remaining IPv4, we need to implement a fair allocation policy and RIPE-826 is not (currently) that. > > Assuming "yes", how would the RIPE NCC know what LIRs would be "ISPs", > whatever that is? DSL providers, cloud providers, hosting service > providers, friendly neighbourhood wifi services, ...? It's relatively easy for an LIR to justify extra needs because of being a mobile service operator or fixed service operator (or both), if you do not like the "ISP" term, but that's just semantics, details that need to be ironed out, nothing more. Yannis > > Gert Doering

2 2

RIPE-826: time to revisit maybe
by Yannis Nikolopoulos 30 Oct '26

30 Oct '26

Hello, Following Marco Schmidt's very informative presentation during RIPE93, it's maybe time to revisit the IPv4 address allocation policy. Possible options were presented by Marco, in order to ease restrictions, such as: allow repeated requests or increase allocation size. There are many arguments to be made here, both for and against, so I'll just state the "new ISP/MSP" case: with 256 IPv4 addresses, the provider is pretty much limited in their options and while growing they'll have to either buy IPv4 addresses (thus feeding and extending this vicious circle) or strangle their users (with less ports or more aggressive NATs etc). All I'm trying to say that, ISPs (like IXPs, which are BTW treated differently) are different from other RIPE members and providing they can show said growth and plans, they should be able to get additional IPv4 allocations. In essence, not all LIRs are equally displeased with this policy. Some are more displeased than others. Regards, Yannis

2 1

Ongoing proposal 2026-02 in Security WG
by Franziska Lichtblau 27 Oct '26

27 Oct '26

Dear Address Policy Working Group, we would like to make you aware of an ongoing proposal "Contractual Accountability Framework for Infrastructure-Level Network Abuse" in the Security Working Group that might be of interest to APWG as well. https://www.ripe.net/community/policies/proposals/2026-02/ Best regards, Franziska for the APWG co-chairs

3 2

RIPE 92 Minutes
by Alex Le Heux 25 Oct '26

25 Oct '26

Dear colleagues, The RIPE NCC has published the minutes of the RIPE92 working group session for your review: https://www.ripe.net/community/wg/active-wg/ap/minutes/ripe-92-address-poli… We extend our gratitude to Antony Gollan from the RIPE NCC for preparing these minutes. The minutes have been on the ripe.net website for some time, the responsibility for any delay in informing the APWG Mailing List rests entirely by the co-chairs. Our apologies for this. Please review the minutes and provide feedback if you think there is something missing or incorrect. Best regards, Alex Le Heux, for the Address Policy WG co-chairs

1 0

2026-03 New Policy Proposal (Clarifying Audit and Policy Compliance Frameworks for IPv6 policies)
by Angela Dall'Ara 21 Oct '26

21 Oct '26

Dear colleagues, A new RIPE Policy Proposal, 2026-03 "Clarifying Audit and Policy Compliance Frameworks for IPv6 policies" is now available for discussion. The goal of this proposal is to clarify the existing requirements for the IPv6 post-provisioning lifecycle, while also aligning the text with IPv4 policies. You can find the full proposal at: https://www.ripe.net/community/policies/proposals/2026-03/ As per the RIPE Policy Development Process (PDP), the purpose of the Discussion Phase is to discuss the proposal and provide feedback to the proposer. At the end of the Discussion Phase, the proposer, with the agreement of the WG Chairs, will decide how to proceed with the proposal. The PDP document can be found at: https://www.ripe.net/publications/docs/ripe-781 We encourage you to review this proposal and send your comments to address-policy-wg(a)ripe.net before 17 November 2026. Kind regards, Angela Dall'Ara Policy Officer RIPE NCC

6 6

RIPE93: Draft Agenda
by Franziska Lichtblau (rhalina) 06 Oct '26

06 Oct '26

Dear Address Policy WG, we have a draft agenda for Address Policy WG's two working sessions during RIPE 93. We still have time available so do not hesitate to suggest new topics. If you want to submit a topic you can reach the chairs via <apwg-chairs(a)ripe.net>. You can also still submit via Pretalx (https://pretalx.ripe.net/ripe-93/cfp) just select APWG. Session 1: Oct, 29th 2026 10:30 - 12:30 UTC+2 ---------------------------------------------- * Open Session [ 5 min] * Policy Update, Angela Dall'Ara [15 min] * Registration Services Update, Marco Schmidt [20 min] * IPv6 Policy clarification, Marco Schmidt [15 min] * 2026-01: Simplify assignment of first ASN, Leo Vegoda [10 min] Session 2: Oct, 29th 2026 14:00 - 15:30 UTC+2 --------------------------------------------- * The Kitchen Sink Proposal/RIPE Policy Manual, Remco van Mook [20 min] * Draft Global Policy Proposal: IPv6 for extra-terrestrial networks, Remco van Mook [20 min] * Registering 3rd party operators of PA space in the RIPE database, James Kennedy [20 min] * Open Mic You can find the whole meeting plan here: https://ripe93.ripe.net/programme/meeting-plan/ Looking forward to seeing you there! Your co-chairs, Leslie, Alex, Franziska

1 0

2024-01 Policy Proposal Withdrawn (Revised IPv6 PI Assignment Policy)
by Angela Dall'Ara 28 Sep '26

28 Sep '26

Dear colleagues,   The policy proposal 2024-01 “Revised IPv6 PI Assignment Policy” has been withdrawn.   This proposal aimed to reduce the operational burden that operators experience when working with PI and to clarify some long-standing issues in the IPv6 addressing policy. The proposal is archived and can be found at:  https://www.ripe.net/community/policies/archived-policy-proposals/ Reason for withdrawal: The proposers decided to withdraw the proposal based on the feedback received. Please note that as per RIPE Policy Development Process “After a withdrawal, anyone is free to re-introduce the topic on the mailing list.“ The PDP document can be found at: https://www.ripe.net/publications/docs/ripe-781 Kind regards, Angela Dall'Ara Policy Officer RIPE NCC

1 0

Withdrawal of proposal 2024-01 Revised IPv6 PI Assignment Policy
by Alex Le Heux 24 Sep '26

24 Sep '26

Dear colleagues, Proposal 2024-01 "Revised IPv6 PI Assignment Policy" has been withdrawn. The proposal aimed to decrease the operational burden when working with IPv6 PI space and clarify some long-standing issues in the policy text. It will be archived at https://www.ripe.net/participate/policies/archived-policy-proposals/archive… Please note that anyone is free to re-introduce this topic on the mailing list as per RIPE PDP. The PDP can be found at https://www.ripe.net/publications/docs/ripe-781/ Kind regards, Alex Le Heux For the APWG Co-chairs

1 0

Feedback for potential policy proposal on IPv6
by Marco Schmidt 21 Sep '26

21 Sep '26

Dear colleagues, I would like to follow up on a topic I raised during RIPE 92 regarding the IPv6 Address Allocation and Assignment Policy [1]. Over the years, this working group discussed a number of policy proposals to update the IPv6 policy framework. However, during recent reviews and audit activities, Registration Services found that some parts of the policy relating to the post-provisioning lifecycle could be clarified and made more consistent through a policy discussion. For example, while the term "audit" appears in some sections of the policy text, there is no general reference to the audit procedure itself (unlike in the IPv4 policy). While such reference is not a requirement to perform an audit on IPv6 resources, it would make the RIPE NCC mandate clearer to everyone. In addition, the section dealing with policy compliance and non-compliance has remained unchanged since 2002 and uses relatively complex wording: "[...] The policies in this document are based upon the understanding that globally unique IPv6 unicast address space is licensed for use rather than owned. Specifically, IP addresses will be allocated and assigned on a license basis, with licenses subject to renewal on a periodic basis. The granting of a license is subject to specific conditions applied at the start or renewal of the license. RIRs will generally renew licenses automatically, provided requesting organisations are making a “good faith” effort at meeting the criteria under which they qualified for or were granted an allocation or assignment. However, in those cases where a requesting organisation is not using the address space as intended, or is showing bad faith in following through on the associated obligation, RIRs reserve the right to not renew the license. Note that when a license is renewed, the new license will be evaluated under and governed by the applicable IPv6 address policies in place at the time of renewal, which may differ from the policy in place at the time of the original allocation or assignment." [2] While the intent of this text remains valid, some parts may be difficult to grasp, particularly for those less familiar with RIPE policies and their historical context. As these sections primarily affect the RIPE NCC's role in assessing and maintaining policy compliance after resources have been issued, I am considering creating a policy proposal aimed at improving clarity and consistency. The intention would be to clearly define the existing framework rather than make substantive changes to the policy’s intent. Before creating this proposal, I welcome feedback from the working group. Do you think these parts of the IPv6 policy could benefit from review? Are there other areas that you believe should be clarified, updated, or taken into account if a proposal were developed? Kind regards, Marco Schmidt Manager Registration Services RIPE NCC [1] https://pretalx.ripe.net/media/ripe-92/submissions/JZ3KEL/resources/RIPE_92… [2] https://www.ripe.net/publications/docs/ripe-738/#41-address-space-not-to-be…

5 8