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

@EXT: RE: RIPE POLICY PROPOSAL 2024-1
by Kessler, Emmanuel 20 Oct '24

20 Oct '24

Dear Partners, From EUROPOL perspective, we observe with interest, the proposed measure, considering the digital investigation matters, While consulting colleagues also at national level and partners, we have identified various points on which we would thank you to bring information, for our better understanding. 1) With the addition of the nibble boundary, how do we ensure that the policy complies with the "Registration goal", which is essential for Internet troubleshooting and avoiding abuse? Are PIs required to register End Site information ? What type of information is recorded by PI and how is this information made accessible to a requesting Authority? What type of information is recorded by the End User, for example about his End-Sites? How they provide information when requested by an Authority, ensuring that they comply with "Registration goal"? How to ensure that an IP range is used by a single party and not more? 2) When a PI receives a larger prefix for more than one End-Site instead of two smaller prefix, how they have to distribute IPs in those range? Are they obliged to distribute them evenly, or can they simply use most of them at one of the End-Sites and leave some others at the remaining site? How to prevent the "Fragmentation" of a larger prefix between different End Sites (instead of having them use contiguous IP ranges)? Couldn't they just demonstrate the need of small End-Sites to get a larger pool of IPs for a single End-Site (or stockpiling them), violating the "Conservation goal"? 3) How to avoid unlawful internal renumbering in case of end-site growth after assignment of a larger prefix? 4) How should the relationship between an End Site and a newly acquired interval be recorded by PI? How the PI should manage the reverse lookup and how the PI delegates to end-user organizations the responsibility of managing the reverse lookup zone corresponding to the given address? 5) How to prevent PI being abused for providing ISP services and how to get information about the End Users if it happens? 6) Where are the Authorities supposed to get information about who is the entity using the /56 prefix range if there is no sub-assignment? Thanks for your cooperation Regards Emmanuel Kessler O3 European Cyber Crime Centre (EC3)

3 2

Draft Address Policy WG Agenda - RIPE 89
by Leo Vegoda 17 Oct '24

17 Oct '24

Dear Working Group, We have a draft agenda for our two sessions at RIPE 89. Some details might change between now and then. We are scheduled for the first two sessions on Wednesday, 30 October. We start at 09:00. A. Open session (5 mins) B. In memoriam - Erik Bais (10 mins) - Words to remember him - A period of silence C. ASO AC update - (10 mins) D. Policy Update - (20 mins) E. Registration Services Update - (30 mins) F. Personal ASN Open House Recap - (10 mins) Total session length: 85 Break for ☕ G. IPv6 PI Policy - Tobias Fiebig - (30 mins) H. Simplifying Assignment Status - Remco van Mook (30 mins) I. Out of region INR registration (see item F) - discussion (15 mins) J. Open Mic (15 mins) Total session length: 90 See you there! Leo Vegoda, for the co-chairs

1 1

Further discussion on 2024-01
by Tobias Fiebig 14 Oct '24

14 Oct '24

Moin, thank you all for your feedback on 2024-01. With the discussion slot coming up at RIPE-89, I wanted to share some considerations on how the various suggestions from the ML could be addressed ahead of time, so we can go for a more active on-site discussion. I put the changes into git again: https://git.as59645.net/tfiebig/ripe-738-pi-update/src/branch/draft-09/draf… Specifically, I saw the following core-points: - Concerns about the interaction with the charging scheme I clarified again, that charging scheme discussions are out of scope, also illustrating the voiced concerns and that--ultimately--the same effect is already present with the current version of the policy. - Concerns regarding various terms and handling of PA vs. PI The purpose for changes to 2.9 and 5.4 have been explained in more detail in the associated considerations. Furthermore, some clarifications have been integrated into the text. I also made clear that the purpose is the defragmentation of the registry. - Concerns voiced regarding evaluation of renumbering requests The policy now clearly discusses how and under which conditions renumbering is necessary, and when which prefixes need to be handed back, including methods to reduce the impact on End Users that may face, e.g., renumbering, i.e., allowing the withdrawel of a request if it would otherwise cause renumbering. I am looking forward to further discussions on the list, as well as to a lively discussion at the upcoming meeting. With best regards, Tobias

2 3

RIPE NCC Open House: The Future of Personal ASNs – 25 Sept 2024 09:00-10:30 UTC
by Alastair Strachan 24 Sep '24

24 Sep '24

Dear all, We invite you to join us for a focussed discussion on the growing trend of personal ASNs at the RIPE NCC Open House on 25 September 2024, 09:00-10:30 UTC. To secure your spot, register at: https://www.ripe.net/meetings/open-house/personal-as-numbers-25-sept-2024/ As more individuals and smaller organisations begin to operate their own ASNs, questions around the implications, best practices and future developments are becoming increasingly important to address. In this session, we'll explore what motivates individuals and small entities to acquire and manage their own ASNs, the regulatory considerations involved, and the potential impact of personal ASNs on the broader Internet ecosystem. Kind Regards Alastair RIPE NCC

1 0

2024-01 Extended Discussion Phase (Revised IPv6 PI Assignment Policy)
by Angela Dall'Ara 17 Sep '24

17 Sep '24

Dear colleagues, The Discussion Phase for RIPE Policy Proposal 2024-01 "Revised IPv6 PI Assignment Policy" has been extended to allow for more feedback on the mailing list and at the upcoming RIPE 89 in Prague. This proposal aims to define End Sites and requirements for “IPv6 PI Assignments” and “Assignments from IPv6 Allocations”, clarifies permitted use cases and introduces IPv6 PI issuance at the Nibble boundary and new principles for aggregation and registration. You can find the full proposal at: https://www.ripe.net/community/policies/proposals/2024-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 22 November 2024. Kind regards, Angela Dall'Ara Policy Officer RIPE NCC

1 0

Fwd: [ripe-list] Mailing Lists Migration from Mailman 2 to Mailman 3 Begins
by Leo Vegoda 03 Jul '24

03 Jul '24

Dear Address Policy WG, In case you haven't seen it, the RIPE NCC will be making changes to our mailing list configuration. Kind regards, Leo Vegoda, for the Address Policy co-chairs ---------- Forwarded message --------- From: Timour Bakeev <tbakeev(a)ripe.net> Date: Tue, 2 Jul 2024 at 03:44 Subject: [ripe-list] Mailing Lists Migration from Mailman 2 to Mailman 3 Begins To: <ripe-list(a)ripe.net> Dear colleagues, In response to the community concerns regarding using the outdated Mailman 2 software for the RIPE mailing lists, RIPE NCC is starting the migration process to the Mailman 3 software suite. This upgrade will enhance the user interface and message archives for these lists. We expect to complete this work by 14 July 2024. Previously, we successfully updated our internal mailing lists to Mailman 3 and the ASO and NRO mailing lists, containerising them in the process. This latest migration extends those improvements to these external mailing lists as well. What will change? Mailman 2 and Mailman 3 are entirely different products, which brings some changes in the observed behaviour. The location of the email archives. The new address of the archive will be: https://mailman.ripe.net/archives/list/{list-name}@ripe.net/ The subscription address will be changed to {list-name}-join(a)ripe.net To maintain historical links to the archives, we’re planning to turn this into a static website at: https://lists.ripe.net/ The mail delivery process for the existing subscribers will not change, so they will continue to receive emails from the lists as usual, with a potential one-time delay of up to four hours during the actual transition. The interaction with the server is also going to remain the same. Thank you for your understanding and cooperation. Kind regards, Timour Bakeev Senior System Engineer RIPE NCC -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/ripe-list

1 0

RIPE 88 Address Policy WG - Draft Minutes Published
by Leo Vegoda 01 Jul '24

01 Jul '24

Dear Address Policy WG, We’ve received the minutes of the RIPE 88 meeting and the RIPE NCC has published them for your review. https://www.ripe.net/community/wg/active-wg/ap/minutes/ripe-88-address-poli… We'd like to thank Adonis and Alun from the RIPE NCC for preparing the draft for us. Please review the minutes and provide feedback if you think there is something missing or incorrect. Kind regards, Leo Vegoda, for the Address Policy WG co-chairs

3 4

2023-04 Policy Proposal Implemented (Add AGGREGATED-BY-LIR status for IPv4 PA assignments)
by Angela Dall'Ara 01 Jul '24

01 Jul '24

Dear colleagues, We are pleased to announce that we have implemented the RIPE Policy Proposal 2023-04 “Add AGGREGATED-BY-LIR status for IPv4 PA assignments” The archived policy proposal can be found at: https://www.ripe.net/community/policies/proposals/2023-04 The RIPE Policy Document "IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region" is available at: https://www.ripe.net/publications/docs/ripe-826 Kind regards, Angela Dall'Ara Policy Officer RIPE NCC

1 0

RIPE Policy document updated “IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region” (ripe-826)
by Angela Dall'Ara 20 Jun '24

20 Jun '24

Dear Colleagues, The RIPE policy “IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region” has been updated to align with the implementation of NWI4, done in Whois release 1.112, which added the option to change the status of an IPv4 allocation object in the RIPE Database from “ALLOCATED PA” to “ALLOCATED-ASSIGNED PA” when the whole address space is assigned to the LIR infrastructure or for use by an End User with services provided by the issuing LIR. The new document is called ripe-826 and is available at: https://www.ripe.net/publications/docs/ripe-826/ Please note that also the following has been updated: 1) In the Abstract: The link to the webpage where to find information on the Address Policy WG from https://www.ripe.net/participate/ripe/wg/ap to https://www.ripe.net/community/wg/active-wg/ap/ 2) In 1.1 Scope: The link to the webpage listing the RIPE community’s policies: from https://www.ripe.net/ripe-policies to https://www.ripe.net/publications/docs/ripe-policies/ 3) In 5.3 Sub-Allocations The option to ask for a conversion of PI to PA via LIR Portal has been added. Kind regards, Angela Dall'Ara Policy Officer RIPE NCC

1 0

Updated Approach to IPv6 Transfer Requests
by Marco Schmidt 19 Jun '24

19 Jun '24

Dear colleagues, During the Address Policy WG session at RIPE 88, I presented on the topic of IPv6 stockpiling by several members [1]. There was widespread support from the working group that our application of IPv6 needs to evolve, emphasising the importance of enforcing policy requirements for transfers of IPv6 allocations. In light of this, the RIPE NCC will now prioritise enforcing policy requirements when evaluating IPv6 allocation transfer requests. Since transferred resources are no different than allocations made by the RIPE NCC, if the receiving party of a transfer request already holds an IPv6 allocation, they must document the need for another allocation according to the policy requirements for subsequent allocations [2][3]. This means the receiving party must demonstrate how they have utilised their existing allocation or justify the need for a new one. In the case of an IPv6 allocation transfer, a successfully deployed network on that range would be considered a valid new need. This updated approach will be applied to any new transfer request submitted from today. Please note, this updated approach only applies to transfer requests under RIPE policies. If the change of holdership of an IPv6 allocation is due to a company merger or acquisition, the RIPE NCC will process this change in accordance with relevant RIPE NCC procedures. Kind regards, Marco Schmidt Manager Registration Services RIPE NCC [1] https://ripe88.ripe.net/wp-content/uploads/presentations/73-RIPE88-Feeback-… [2] https://www.ripe.net/publications/docs/ripe-807/#2-1-transfer-requirements [3] https://www.ripe.net/publications/docs/ripe-738/#52-subsequent-allocation

2 3