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

2024-02 New Policy Proposal (IPv6 Initial Allocations /28)
by Angela Dall'Ara 29 Oct '24

29 Oct '24

Dear colleagues, A new RIPE Policy Proposal, 2024-02, "IPv6 Initial Allocations /28" is now available for discussion. This proposal aims to change the initial IPv6 allocation size from /29 to /28. You can find the full proposal at: https://www.ripe.net/community/policies/proposals/2024-02 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 proposers, 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 12 November 2024. Kind regards, Angela Dall'Ara Policy Officer RIPE NCC

16 41

DRAFT: Simplifying Number Resource Status
by Remco van Mook 26 Oct '24

26 Oct '24

Dear colleagues, following up on my presentation at RIPE 88, please find below a draft version of the policy proposal for simplifying the status of number resource records. I wanted to get this out much earlier, my apologies for the delay. Looking forward to your constructive feedback ahead of next week’s session. Kind regards, Remco van Mook —— Number: (assigned by the RIPE NCC) Policy Proposal Name: Simplifying Number Resource Status Author: Remco van Mook \<remco.vanmook(a)gmail.com\> Proposal Version: (assigned by the RIPE NCC) Submission Date: TBD Suggested RIPE WG for discussion and publication: Address Policy Proposal Type: modification or deletion Policy Term: Indefinite Summary of proposal: There is about 30 years of history reflected, sometimes poorly, in the status field describing IPv4 and IPv6 resources in the database. This proposal seeks to simplify and harmonise the contents of the status field between IPv4 and IPv6 and limits the field to what has operational relevance, and removes any implied contractual relationship from the status field itself. (Remnants of) address policy define a very rigid model for the RIPE NCC to follow for the structure of its membership, mostly based on rules about the distribution of IPv4. If we want to give the RIPE NCC membership room to evolve its membership structure based on today’s reality we need a clean break with policy and a database that no longer prescribes the RIPE NCC membership model, but rather allows it to accurately reflect reality. Policy text: a. Current policy text (if modification) RIPE-826 \- IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region: 5.3 Sub-allocations Sub-allocations are intended to aid the goal of routing aggregation and can only be made from allocations with a status of "ALLOCATED PA". LIRs holding "ALLOCATED PI" or "ALLOCATED UNSPECIFIED" allocations may be able to convert them to PA allocations if there are no ASSIGNED PI networks within it. The meanings of the various "status:" attribute values are described in Section 7.0. LIRs may make sub-allocations to multiple downstream network operators. The LIR is contractually responsible for ensuring the address space allocated to it is used in accordance with the RIPE community's policies. It is recommended that LIRs have contracts requiring downstream network operators to follow the RIPE community's policies when those operators have sub-allocations. Sub-allocations form part of an LIR's aggregatable address space. As such, an LIR may want to ensure that the address space is not retained by a downstream network if the downstream network operator ceases to receive connectivity from the LIR's network. LIRs not wishing to lose address space in this way are responsible for ensuring that the status of the sub-allocation is clear in any contracts between the LIR and the downstream network operator. 7.0 Types of Address Space LIRs are allocated Provider Aggregatable (PA) address space. They sub-allocate and assign this to downstream networks. If a downstream network or End User changes its service provider, the address space assigned or sub-allocated by the previous service provider must be returned and the network renumbered. Clear contractual arrangements are mandatory for PA space. End Users requesting PA space must be given this or a similar warning: Assignment of this IP space is valid as long as the criteria for the original assignment are met and only for the duration of the service agreement between yourself and us. We have the right to reassign the address space to another user upon termination of this agreement or an agreed period thereafter. This means that you will have to re-configure the addresses of all equipment using this IP space if you continue to require global uniqueness of those addresses. LIRs will register the type of any assigned address space using the "status:" attribute of the inetnum object in the RIPE Database. The possible values of this attribute are: ALLOCATED PA: This address space has been allocated to an LIR and no assignments or sub-allocations made from it are portable. Assignments and sub-allocations cannot be kept when moving to another provider. ALLOCATED UNSPECIFIED: This address space has been allocated to the RIPE NCC or other RIRs for further distribution. If the address space is administered by the RIPE NCC, more specific objects with other values may exist. ALLOCATED-ASSIGNED PA: This address space has been allocated to an LIR and entirely assigned to the LIR infrastructure or for use by an End User with services provided by the issuing LIR. It cannot be kept when terminating services provided by the LIR. SUB-ALLOCATED PA: This address space has been sub-allocated by an LIR to a downstream network operator that will make assignments from it. All assignments made from it are PA. They cannot be kept when moving to a service provided by another provider. LIR-PARTITIONED PA: This allows an LIR to document distribution and delegate management of allocated space within their organisation. Address space with a status of LIR-PARTITIONED is not considered used. When the addresses are used, a more specific inetnum must be registered. LEGACY: This indicates the Internet number resource was obtained prior to or otherwise outside the current system of hierarchical distribution (by allocation or assignment) through the Regional Internet Registries. ASSIGNED PA: This address space has been assigned to the issuing LIR infrastructure or an End User for use with services provided by the issuing LIR. It cannot be kept when terminating services provided by the LIR. AGGREGATED-BY-LIR: This address space has been assigned to different parts of the issuing LIR infrastructure or to End Users for use with services provided by the issuing LIR. The purpose and the contact details must be consistent throughout the whole assignment. It cannot be kept when terminating services provided by the LIR. ASSIGNED PI: This address space has been assigned to an End User for a specific purpose. It cannot be used to make further assignments to other parties. ASSIGNED ANYCAST: This address space has been assigned for use in TLD anycast networks. It cannot be kept when no longer used for TLD anycast services. Registering an inetnum object with a status of “ALLOCATED-ASSIGNED PA” or "ASSIGNED PA" or "ASSIGNED PI" is only possible if there is no less specific or more specific inetnum object with an "ASSIGNED" status. Address space without an explicit type in the "status:" attribute is assumed to be PI. LIRs must clearly mark all new assignments in the RIPE Database with either "PA" or "PI" as appropriate. In the past, some LIRs assigned address space that was de facto aggregated but not formally PA because there were no clear contractual arrangements for termination of the assignment. LIRs must ask leaving customers to voluntarily release this address space upon termination of service. Where possible, LIRs should work to make contractual arrangements to convert PI addresses into PA addresses. The RIPE NCC no longer allocates or assigns PI address space, except for assignments to Internet Exchange Points as described in section 6.1. b. New policy text RIPE-826 \- IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region: 5.3 Sub-allocations LIRs may make sub-allocations to multiple downstream network operators. The LIR is contractually responsible for ensuring the address space allocated to it is used in accordance with the RIPE community's policies. It is recommended that LIRs have contracts requiring downstream network operators to follow the RIPE community's policies when those operators have sub-allocations. Sub-allocations form part of an LIR's aggregatable address space. As such, an LIR may want to ensure that the address space is not retained by a downstream network if the downstream network operator ceases to receive connectivity from the LIR's network. LIRs not wishing to lose address space in this way are responsible for ensuring that the status of the sub-allocation is clear in any contracts between the LIR and the downstream network operator. 7.0 Types of Address Space LIRs are allocated Provider Aggregatable (PA) address space. They sub-allocate and assign this to downstream networks. If a downstream network or End User changes its service provider, the address space assigned or sub-allocated by the previous service provider must be returned and the network renumbered. Clear contractual arrangements are mandatory for PA space. End Users requesting PA space must be given this or a similar warning: Assignment of this IP space is valid as long as the criteria for the original assignment are met and only for the duration of the service agreement between yourself and us. We have the right to reassign the address space to another user upon termination of this agreement or an agreed period thereafter. This means that you will have to re-configure the addresses of all equipment using this IP space if you continue to require global uniqueness of those addresses. In the past, some LIRs assigned address space that was de facto aggregated but not formally PA because there were no clear contractual arrangements for termination of the assignment. LIRs must ask leaving customers to voluntarily release this address space upon termination of service. Where possible, LIRs should work to make contractual arrangements to convert PI addresses into PA addresses. The RIPE NCC no longer allocates or assigns PI address space, except for assignments to Internet Exchange Points as described in section 6.1. Any allocated or assigned address space status must be registered in accordance with the policy document ‘Address Allocation and Assignment Status’. RIPE-NEW \- Address Allocation and Assignment Status: Abstract This document defines the content of the status field for the assignment and allocation of globally unique IP addresses to Internet Service Providers (ISPs) and other organisations. It exists together with the IPv6 Address Allocation and Assignment Policy which is harmonised between the RIPE, ARIN and APNIC regions as well as the IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region. While the status field of inet6num records in the RIPE Database has been mostly inferred from the IPv4 inetnum record as it existed when the first provisional IPv6 Allocation and Assignment policy was defined in RIPE-196, there was no equivalent for Chapter 7 of the IPv4 Address Allocation and Assignment Policy “Types of Address Space” in defined policy. To prevent duplication, this document applies equally to IPv4 inetnum and IPv6 inet6num records. 1.0 Status of Address Space resource records LIRs will register the type of any assigned address space using the "status:" attribute of the inetnum or inet6num object in the RIPE Database for IPv4 and IPv6 registrations, respectively.. The possible values of this attribute are: ALLOCATED: This address space has been allocated to an LIR or downstream network operator and no assignments or sub-allocations made from it are portable. More specific objects may exist in the RIPE database. ASSIGNED: This address space has been assigned to the issuing LIR infrastructure or an End User. More specific objects do not exist in the RIPE database. AGGREGATED-BY-LIR: This address space has been assigned to different parts of the issuing LIR infrastructure or to End Users for use with services provided by the issuing LIR. Each End User has been assigned a block the size of the assignment size in the object. More specific objects do not exist in the RIPE database. 2.0 Mapping of Legacy Status Attributes The following mapping is used to update legacy status attributes: ALLOCATED: - ALLOCATED PA - SUB-ALLOCATED PA - LIR-PARTITIONED PA - ALLOCATED UNSPECIFIED - ALLOCATED-BY-RIR - ALLOCATED-BY-RIR \# This block was actually allocated by the IANA - ALLOCATED-BY-LIR ASSIGNED - ASSIGNED PA - ASSIGNED PI - LEGACY - ASSIGNED ANYCAST Unchanged but added for completeness: AGGREGATED-BY-LIR - AGGREGATED-BY-LIR Rationale: a. Arguments supporting the proposal - Reduces complexity of the status of number resources - Removes the need to attribute origin in the status attribute as that’s inferred from the structure of the database - Focus the database on more accurately reflecting operational reality - Special case/historical documentation is better suited elsewhere - Harmonises IPv4 and IPv6 registrations - Less confusion about usage caused by status \- e.g. most operational anycast space is not in the database as ‘ASSIGNED ANYCAST’ - Facilitates a future decoupling of address policy and NCC membership structure b. Arguments opposing the proposal - Loss of public visibility of contractual relationship - Loss of public visibility of historic/legacy assignments/special cases

6 8

@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