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

mobing report 24/7
by Драгана Топаловић 12 Sep '26

12 Sep '26

do not unsubscribe this email mobing report 24/7

1 4

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

08 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 7

Announcement: TIPTOP Interim on IP address policy / RIRs for Space Use
by Warren Kumari 07 Sep '26

07 Sep '26

Dear RIPE Address Policy WG, As you may remember from RIPE 92 in Edinburgh, there was a presentation on “IP Address space for Outer Space”. Sides: https://pretalx.ripe.net/media/ripe-92/submissions/RHW7DB/resources/RIPE_ad… Recording: https://ripe92.ripe.net/programme/meeting-plan/sessions/97/RHW7DB/#video. The questions start at 9:45 or so. This topic was also discussed at the IETF 126 Taking IP To Other Planets (TIPTOP) meeting – recording: https://www.youtube.com/watch?v=qgX1UnuUeAY&t=1363s TIPTOP will be having an interim meeting on this topic - announcement here: https://mailarchive.ietf.org/arch/msg/ietf-announce/vbEtKf3cCWFI9d0prl17j-V… — The Taking IP To Other Planets (tiptop) WG will hold a virtual interim meeting on 2026-09-09 from 07:00 to 08:30 America/Los_Angeles (14:00 to 15:30 UTC). Agenda: (No agenda submitted) Information about remote participation: https://meetings.conf.meetecho.com/interim/?session=35851 — As with most IETF interim meetings, it is held on MeetEcho. It is free to participate in, but do do require a (free) IETF Datatracker account, which can be created here: https://datatracker.ietf.org/accounts/create/ The TIPTOP chairs (CCed) asked us to announce it, and if you are interested to please join. Thanks, Warren, Jen.

2 1

Fwd: Discussion Phase for 2026-01 "Simplify Assignment of first ASN" ended
by Leslie Nobile 02 Sep '26

02 Sep '26

Dear Address Policy WG- The discussion phase for 2026-01: Simplify Assignment of first ASN ended on 05 Aug 2026. The proposers have agreed to move it to the Review Phase. The RIPE NCC will now create the Impact Analysis and announce the start of the Review Phase with a new version, including small modifications that take into consideration the feedback received from the community. Here is a short summary of the feedback received on this proposal: - *Support:* 6 participants supported the proposal as written. One supported it with an amendment to remove the needs assessment but retain an RPSL routing-policy requirement in the RIPE Database. - *Opposition:* Concerns were mainly about the lack of evidence that the current policy prevents operators from obtaining ASNs, the proposal being a larger policy change than necessary, the RIPE NCC already allocating more ASNs than other RIRs, the increased workload for security researchers and operational analysis, and speculative claims about enabling future BGP products. - *Additional suggestions:* One was to require ASPA information, and another supported the proposal but opposed the RPSL requirement, considering it cumbersome and unclear. - *Questions:* clarification on which resources the policy applies to and whether the proposal would allow one ASN per LIR, organisation, or company within a corporate group. Best Regards, Alex, Franziska, Leslie APWG Co-Chairs

1 0

2024-01 Review Phase (Revised IPv6 PI Assignment Policy)
by Angela Dall'Ara 31 Aug '26

31 Aug '26

Dear colleagues,   Policy proposal 2024-01, "Revised IPv6 PI Assignment Policy", is now in the Review Phase.   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/2024-01/ https://www.ripe.net/community/policies/proposals/2024-01/#impact-analysis And the draft document at:  https://www.ripe.net/community/policies/proposals/2024-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 23 September 2026. Kind regards,   Angela Dall'Ara Policy Officer RIPE NCC

6 6

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

14 Aug '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 9

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

20 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 17

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

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

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