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

2026-01 New Policy Proposal (Simplify assignment of first ASN)
by Angela Dall'Ara 10 Jul '26

10 Jul '26

Dear colleagues, A new RIPE Policy Proposal, 2026-01 "Simplify assignment of first ASN" is now available for discussion. This proposal aims to remove the needs assessment for the first AS Number requested by holders of an IP address prefix assigned or allocated directly by the RIPE NCC. You can find the full proposal at: https://www.ripe.net/community/policies/proposals/2026-01 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 5 August 2026. Kind regards, Angela Dall'Ara Policy Officer RIPE NCC

15 16

2025-01 Policy Proposal Withdrawn (ASN assignment criteria revisited)
by Angela Dall'Ara 06 Jul '26

06 Jul '26

Dear colleagues, The policy proposal 2025-01, "ASN assignment criteria revisited” has been withdrawn.  This proposal aimed to simplify the requirements for new ASNs, while preventing the exponential exhaustion of 32-bit ASN space.  The proposal is archived and can be found at:  https://www.ripe.net/community/policies/archived-policy-proposals/ Reason for withdrawal:  The proposer decided to work on a new 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

Discussion: Do we still share a common understanding of an IPv6 End Site?
by Yuli Azarch 06 Jul '26

06 Jul '26

Hello AP-WG, While following IPv6-related discussions over the past few years [Such as: https://mailman.ripe.net/archives/list/address-policy-wg@ripe.net/message/F…] I have found myself wondering whether the community still shares a common understanding of what constitutes an “End Site” in practice for IPv6 deployments. What makes something a separate end-site? *Core problem statement* Many aspects of the IPv6 assignment policy and documentation of assignments in the RIPE Database are based on assignments made to "End Sites”. The definition exists but is anchored to subscriber-location, and it's not obvious if it covers operationally or topologically distinct deployments, which is what I'd value the community's view on. That ambiguity may have been tolerable when most deployments followed relatively common patterns, but the wider range of deployment models in use today makes the lack of precision more noticeable. Operational and deployment models have evolved considerably since the original definition was introduced. I am interested in understanding whether the community believes the current interpretation remains clear and consistently understood. *Some areas where differing interpretations may exist include:* • What qualifies a deployment as a distinct end-site? Physical location only, or also operational/topological separation? • Whether an End Site is primarily a legal entity, an organization, a network, a physical location, a single end-user, or an operational deployment? • How the concept applies to distributed enterprise networks spanning multiple locations? I would be interested to hear views, examples, and operational experiences from others. -- Best regards, *Yuli Azarch*

4 6

Withdrawal of proposal 2025-01 "ASN Assignment Criteria Revisited"
by Leslie Nobile 05 Jul '26

05 Jul '26

Dear Address-Policy WG, Policy proposal 2025-01 has been updated by the authors to incorporate feedback suggested by the community. Due to the significant changes that have been made, 2025-01 will be withdrawn and the updated text will be assigned a new policy ID. Once this has been done, the proposal will be posted to the APWG list for review and discussion. A new discussion phase will start when the new version of the proposal is published. The RIPE NCC will update the proposal page and announce the publication when the new draft is ready. You can find all current policy proposals at: https://www.ripe.net/community/policies/current-proposals/ You can read our Policy Development Process at: https://www.ripe.net/publications/docs/ripe-781/ Best regards, Alex, Franziska, Leslie APWG co-Chairs

1 0

Feedback for potential policy proposal on IPv6
by Marco Schmidt 02 Jul '26

02 Jul '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…

1 0

IPv6 end-site definition
by Yuli Azarch 16 Jun '26

16 Jun '26

Hi Franziska (and fellow Address Policy chairs), We spoke briefly during RIPE 92. I'm exploring whether there's a case to clarify the end-site definition in IPv6 policy, and before taking anything to the list I'd value your view on the framing and angle. The thought: the assignment and utilisation provisions are anchored to "per End Site," but the definition describes a subscriber location - a unit that doesn't map cleanly onto how address space is used in many deployments today. That creates room for inconsistent interpretation worth addressing. If you've had conversations on this with community members off-list, or have a sense of whether it's been raised before, any steer would be appreciated. Yuli -- Best regards, *Yuli Azarch* CEO & Co-Founder [image: RapidSeedBox] W: *www. <https://followup.cc/l/10355620/82d48c1301f2ee846cbf37acc97cebe7/http%3A%2F%…>RapidSeedbox.com <https://www.rapidseedbox.com>* P: (+1)3039520447 <(303)%20952-0447>

2 2

2024-01: "Revised IPv6 PI Assignment Policy" - current state
by Franziska Lichtblau 15 Jun '26

15 Jun '26

Dear Address-Policy WG, the discussion phase for proposal 2024-01: "Revised IPv6 PI Assignment Policy" ended on 24 April. The proposers have agreed to advance it to the Review Phase. Eight people supported the proposal and the proposers agreed to include minor editorial changes suggested during the Discussion Phase and at RIPE 92 into their new version. The RIPE NCC will publish the impact analysis and the policy draft, and announce the start of the Review Phase. Best regards, Alex, Franziska, Leslie APWG co-Chairs

1 0

New AS Number Blocks Allocated to the RIPE NCC
by Marco Schmidt 02 Jun '26

02 Jun '26

Dear colleagues, On 1 June 2026, the RIPE NCC received the following AS Number blocks from IANA: 216476-217499 217500-218523 218524-219547 You may want to update your records accordingly. All allocations of AS Numbers made by IANA to RIRs are listed here: http://www.iana.org/assignments/as-numbers Kind regards, Marco Schmidt Manager Registration Services RIPE NCC

1 0

New on RIPE Labs: Legacy Out of Contract
by Alun Davies 15 May '26

15 May '26

Dear colleagues, Following on from our 2024 look back at 10 years of legacy policy, we’ve been taking a deeper dive into out-of-contract legacy address space managed by the RIPE NCC. Qasim Lone and colleagues provide a detailed breakdown of the numbers and explore the behaviours that emerge from this region of IPv4. Read more on RIPE Labs: https://labs.ripe.net/author/qasim-lone/legacy-out-of-contract/ Kind regards, Alun Davies RIPE Labs Editor RIPE NCC

1 0

Making Resource Holders Easier to Identify: Introducing reg-nr: in the RIPE Database
by Marco Schmidt 30 Apr '26

30 Apr '26

Dear colleagues, We’re happy to share that, as of 30 April, the reg-nr: attribute is now available in the RIPE Database following the completion of NWI-21. https://www.ripe.net/community/wg/active-wg/db/numbered-work-items/ First proposed at RIPE 91 in the Address Policy Working Group and then discussed further in the Database Working Group, it’s now in place ahead of RIPE 92. This is a great example of how community input can quickly turn into something tangible and useful. Thank you to all who provided feedback and contributed to this outcome. The reg-nr: attribute adds the official company registration number of resource holders to organisation objects co-maintained by the RIPE NCC. This makes it easier to clearly identify organisations, especially where names are similar or the same. Please note that this does not apply to all organisation objects. For privacy reasons, a reg-nr: with value "Not applicable" will be published for natural persons and governmental organisations. If you come across information that appears incorrect or incomplete, please let us know by sending an email to ripe-dbm(a)ripe.net. Our Member Services team will follow up. More details are available in the RIPE Labs article: https://labs.ripe.net/author/marco_schmidt/making-resource-holders-easier-t… Kind regards, Marco Schmidt Manager Registration Services RIPE NCC

1 0