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

Feedback on reviewing the RIPE policy documentation
by Angela Dall'Ara 17 Jun '25

17 Jun '25

Dear colleagues, Following up on the final point of my presentation [1] at RIPE 90, I would like to invite your feedback on the review of RIPE policy documentation. Currently, we have multiple policy documents, and we often hear that it can be challenging to identify which document outlines the applicable policy for a specific request. Additionally, the documents follow different formats, and not all of the content is directly relevant to understanding the core policies. To address this, it may be beneficial to consolidate policies related to the same topic into a single, clear, and well-structured document. More specifically we have: Three policy documents regarding IPv6: - ripe-738: IPv6 Address Allocation and Assignment Policy (https://www.ripe.net/publications/docs/ripe-738/ <https://www.ripe.net/publications/docs/ripe-738/>) - ripe-451: IPv6 Address Space Policy For Internet Exchange Points (https://www.ripe.net/publications/docs/ripe-451/ <https://www.ripe.net/publications/docs/ripe-451/>) - ripe-636: IPv6 Addresses for Internet Root Servers in the RIPE Region (https://www.ripe.net/publications/docs/ripe-636/ <https://www.ripe.net/publications/docs/ripe-636/>) Two policy documents regarding transfers: - ripe-807: RIPE Resource Transfer Policies (https://www.ripe.net/publications/docs/ripe-807/ <https://www.ripe.net/publications/docs/ripe-807/>) - ripe-806: Voluntary Transfer Lock (https://www.ripe.net/publications/docs/ripe-806/ <https://www.ripe.net/publications/docs/ripe-806/>) Two policy documents regarding provider independent resource holders requirements: - ripe-637: Contractual Requirements for Provider Independent Resource Holders in the RIPE NCC Service Region (https://www.ripe.net/publications/docs/ripe-637/ <https://www.ripe.net/publications/docs/ripe-637/>) - ripe-603: Publication of Sponsoring LIR for Independent Resources (https://www.ripe.net/publications/docs/ripe-603/ <https://www.ripe.net/publications/docs/ripe-603/>) In order to avoid generating too much traffic on the APWG ML, I kindly ask that you send your responses directly to me at pdo(a)ripe.net answering the following questions. *Content structure * In the new policy document: A) Would including only the Abstract, Introduction and Policy Text from each existing document be enough? B) Could each document’s Rationale, Attribution and Acknowledgements be referenced via footnotes? C) Could the Definitions and Goals be published in a separate document? *Preferred way forward* Which approach would you prefer? 1) The RIPE community to set up a Task Force to redact new documents 2) The RIPE community to propose new documents for discussion through the PDP 3) The RIPE NCC to propose new documents for discussion through the PDP 4) Another approach (it could be that you are fine with leaving thing as they are, but if you have another idea, please explain) Please share your thoughts by 31 May. I will compile and summarise the feedback received and share it with the WG. Thank you in advance for your time and input. Kind regards, Angela Dall’Ara Policy Officer RIPE NCC [1] https://ripe90.ripe.net/archives/video/1611/(from 10:15 )

1 1

2025-01 End of Discussion Phase (ASN assignment criteria revisited)
by Leo Vegoda 11 Jun '25

11 Jun '25

Dear Address Policy WG, As you’ve seen, Urban and Tobias are working on an update to 2025-01: ASN assignment criteria revisited. They will take account of the feedback received. This is a summary of the feedback. Eight people expressed support for the proposal on the mailing list and at the microphone at RIPE 90. In addition to supporting the proposal they almost unanimously requested that the text should be simplified. 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/ Kind regards, Leo Vegoda, for the Address Policy WG co-chairs

1 0

2025-01 New Policy Proposal (ASN assignment criteria revisited)
by Angela Dall'Ara 05 Jun '25

05 Jun '25

Dear colleagues, A new RIPE Policy Proposal, 2025-01, "ASN assignment criteria revisited" is now available for discussion. This proposal aims to to simplify requirements for new ASNs, while ensuring that the requirements are enforceable in practice and preventing the exponential exhaustion of 32-bit ASN space. You can find the full proposal at: https://www.ripe.net/community/policies/proposals/2025-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 proposers. 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 4 June 2025. Kind regards, Angela Dall'Ara Policy Officer RIPE NCC

9 13

2024-02 Review Phase (IPv6 Initial Allocations /28)
by Angela Dall'Ara 23 May '25

23 May '25

Dear colleagues, Policy proposal 2024-02, "IPv6 Initial Allocations /28 ", is now in the Review Phase. This proposal aims to change the initial IPv6 allocation size from /29 to /28 and allow one IPv6 allocation extension per member to /28 without justification. This proposal has been updated and it is now at version 3.0. The main difference from version 2.0 is that one IPv6 allocation extension up to /28 without justification is allowed per member instead of per LIR. 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-02/ https://www.ripe.net/participate/policies/proposals/2024-02#impact-analysis And the draft document at: https://www.ripe.net/participate/policies/proposals/2023-04/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 11 June 2025. Kind regards, Angela Dall'Ara Policy Officer RIPE NCC

8 11

FYI: Address Policy List now on moderation
by Franziska Lichtblau 20 May '25

20 May '25

Dear Address Policy Working Group, due to recent events we as chair team decided to put this list on moderation. Some of your posts may be delayed. Thanks for your understanding, Franziska on behalf of the Address Policy co-Chairs

1 0

Posts in NANOG
by info＠netstyle.io 16 May '25

16 May '25

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hello, I kindly bring my following two linked posts in NANOG to the attention of the RIPE community: https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/25GSIL2… https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/LBIRATB… Kind Regards, Elad -----BEGIN PGP SIGNATURE----- Version: ProtonMail wsG5BAEBCgBtBYJoJzmXCZCAS+uEnipSW0UUAAAAAAAcACBzYWx0QG5vdGF0 aW9ucy5vcGVucGdwanMub3JnAp3tbij5bDCxR4d9UVJ3Ntg5owLa3wDEL9Tt nqr1c5sWIQTD50Y2bI5NSOj/nnWAS+uEnipSWwAAy8AP/2ztVrMghrN7Pn40 c75LaNy5ia4fMUOu/LRZwOa0LyLAmIQUFtfxy/Pn9PxnP/wkqfGYyg3ReRFQ u2V3Q5Zs29tL+SgTKE0WZvzCFa/z9rGJfE5/Hx7nTD2s6s+ldoRUUJkb0ian JL+NqIEc9jlZJJ55MkGgcvjlCbnRXiyKk5tWnE01YeLrnMmcsAe3sJMiNt2Y xhnMwsKxpTE39z7DTHT0rGpS22CdNBsLxe+peNx8SlBW7JXfQziyT/05nu7g 9cKFWioQ+JExQ14URM1O/tiQ0jxIEKUtG5Gxm6sUlrrmy2dw8I776FPYU5Ab 02dF4c7l9OSax+/JW9QsHeKaNegq3kzMAbxCTtMqNix75MgDujeAEEp3tAHN cd4qLLgrHcS+XEc6Lekg23CKVcqVlD38rXILI4yOm4kjhOBY6lf0KU4/QzmF dYwSuW3+SubpHS1fUlCYJSds7RnMsoy++a54hf0J/csDbQked1zVSZ+eMmYP SBqnJ3X3NbBq6jQ8Ciou4llgs73yn529umqN7N/OEd/TA8K33ScyRKxgcAwC 7A9VHQlWG8Zrwt8s3LXIjuURTFICoiiD0wsk+K/xN1QGlG4lyPpGl1dB99yR VSY9qm8hZg0fdwoZKkKRrhGfHNIitKWO4Ew+GSPwGTosa6Ns0BlgEI9PT2uj bEt2pLEa =Z78a -----END PGP SIGNATURE-----

3 4

Address Policy WG Agenda for RIPE90
by Alex Le Heux 05 May '25

05 May '25

Dear Address Policy WG, Here is the current agenda for the RIPE90 working group session: A. Open session (5 mins) - Welcome - Remind everyone about code of conduct - Thank those taking minutes and providing stenography services - Ask if draft minutes can be accepted B. Co-chair selection (10 mins) C. ASO AC update - (10 mins) D. ASO AC ICP2 update - (15 mins) D. Policy Update - Angela (20 mins) E. Registration Services Update - Marco (30 mins) Total session length: 90 minutes Coffee break G. IPv6 PI Policy - Tobias (25 mins) H. IPv6 Initial Allocations - Jordi (25 mins) I. Removing multihoming requirement from ASNs - discussion (25 mins) J. Open Mic (15 mins) Total session length: 90 minutes Kind regards, Alex Le Heux, Leo Vegoda co-chairs

1 0

2024-02 End of Discussion Phase (IPv6 Initial Allocations /28)
by Leo Vegoda 14 Apr '25

14 Apr '25

Dear Address Policy WG, Rinse and Jordi have agreed to take 2024-02: IPv6 Initial Allocations /28 to the Review Phase. They clarified the wording in the proposal text based on the discussion. The RIPE NCC will publish the new version. Four people commented on the proposal: - Jori Vanneste supported the proposal as written. - Nick Hilliard suggested rewording text explaining that each organisation can extend only one allocation up to /28. - Andy Davidson suggested using the word "member" instead of "organisation". - Gert Doering supported the proposal, however did not see it as “needed”. The RIPE NCC will publish the impact analysis and the new policy draft and announce the start of the Review Phase. 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/ Kind regards, Leo Vegoda, for the Address Policy WG co-chairs

1 0

Monthly Summary of Policy Related Discussions - March 2025
by Angela Dall'Ara 07 Apr '25

07 Apr '25

Dear RIPE Working-Group Chairs, Please find in attachment a summary of the discussions held in March 2025 on the following mailing lists: // <https://mail.lacnic.net/pipermail/politicas/>// • AC-DISCUSS (Address Council Coordination) Mailing List • RIPE Policy Announce Mailing List • RIPE Address Policy Working Group Mailing List • AFRINIC Policy Mailing List • APNIC Policy Mailing List • ARIN Policy Mailing List • LACNIC Policy Mailing List This summary is a joint effort by colleagues from the Registry Services department, we hope you will find this useful. Kind regards, Angela -- Angela Dall'Ara Policy Officer RIPE NCC

2 2

DRAFT ASN assignment critera revisited
by Urban Suhadolnik 02 Apr '25

02 Apr '25

Dear Colleagues, Following RIPE 89 Address policy WG, I was asked to prepare a new policy for ASN assignment criteria together with Tobias. We've compared the ASN assignment criteria at other RIRs, current proposals at other RIR and followed various conversations at RIPE community events. After some internal feedback from Alex, Leo and PDO we feel that this draft is ready for the mailing list. I would like to ask all of you for feedback on the proposal and on the text of the proposal. Best, Urban and Tobias _____________________________ Summary of Proposal This policy proposal changes the requirements for ASN assignments. Under the new policy, any organization or LIR (in case of multiple LIR per ASN) may request a single ASN without justification. Additional ASNs can be assigned if the requester provides a unique external routing policy and demonstrates peering with a third party. The proposed changes reflect the reality that the current requirements are unenforceable in practice [1] and that ASNs are no longer a scarce resource since the complete introduction and global acceptance of 32-bit ASNs. The aim of this policy is to simplify requirements for new ASN, while making the requirements enforceable in practice and avoiding exponential burn of 32bit ASN space. [1] - Personal ASN Open House Recap - RIPE NCC - Page 5 https://ripe89.ripe.net/wp-content/uploads/presentations/88-Personal-ASN.pdf <https://ripe89.ripe.net/wp-content/uploads/presentations/88-Personal-ASN.pdf> Policy text: Current policy text *2.0 Assignment Criteria* In order to help decrease global routing complexity, a new AS Number should be used only if a new external routing policy is required, see RFC1930. A network must be multihomed in order to qualify for an AS Number. When requesting an AS Number, the routing policy of the Autonomous System must be provided. The new unique routing policy should be defined in RPSL language, as used in the RIPE Database. The RIPE NCC will assign the AS Number directly to the End User upon a request properly submitted to the RIPE NCC either directly or through a sponsoring LIR. AS Number assignments are subject to the policies described in the RIPE NCC document entitled “Contractual Requirements for Provider Independent Resource Holders in the RIPE NCC Service Region”. New policy text *2.0 Assignment Criteria* Any organization OR LIR, in case an organization has more than one LIR, may be issued a single Autonomous System Number (ASN) upon request. Organizations and LIRs may be issued additional ASNs. Requirements for additional ASNs are: * Unique external routing policy of the Autonomous System must be provided. The uniqueness of the routing policy includes the announced prefixes. * Autonomous System must peer with a third party. When requesting an AS Number to be visible in the GRT, the routing policy of the Autonomous System must be provided. The new unique routing policy should be defined in RPSL language, as used in the RIPE Database. Otherwise, documentation on the non-visible purpose, e.g., a reference to the assigned IXP LAN prefixes, must be provided. Reasonable periodic use cases MAY be allowed. A benefit statement for such MUST be provided. The requester has 6 months after the ASN has been issued to fulfil the criteria for which the application was approved. Approval of an additional ASN MAY depend on fulfilment of criteria and up-to-date documentation on existing ASNs. In case of an ASN visible in the GRT, RIPE NCC confirms that the ASN fulfils the criteria by checking publicly visible state in the GRT. In case of off-GRT ASN, RIPE NCC may ask for operational proof of fulfilling the criteria. Failing to provide sufficient proof is considered as not fulfilling the criteria. The RIPE NCC will assign the AS Number directly to the End User upon a request properly submitted to the RIPE NCC either directly or through a sponsoring LIR. AS Number assignments are subject to the policies described in the RIPE NCC document entitled “Contractual Requirements for Provider Independent Resource Holders in the RIPE NCC Service Region." Rationale There are valid technical reasons for having a single homed ASN. BGP and RPSL has appeared to be a very robust way of exchanging routing information. Schemes where customer's have their own IP space would benefit by using a dedicated ASN to communicate routing information over BGP. Conservation measures currently implemented are not really helpful anymore. They reduce visibility and make operating and troubleshooting of networks more complex. Arguments supporting the proposal Four octet (32 bit) ASNs were defined in May 2007 in RFC 4893. It has taken several years for routing equipment in general use to catch up, but with 32 bit AS numbers, ASN are not a scarce resource anymore. IANA has assigned 402332 ASN to RIRs which is ~0.01 % of available 32 bit ASN space. While RIRs have assigned only around, 88400 to network operators, which represents ~0,002 % of available 32 bit ASN. Our policies should reflect that, and we should utilize number resources in such a way to help network operators reduce operational complexity and increase visibility for operating and troubleshooting networks. Lastly, the current ASN requirements have appeared to be unenforceable in practice. Many AS start by fulfilling the multihomed requirement, but then turn single-homed over time, while others have never become multihomed in the first place. Half of allocated ASN by RIPE don't fulfil the requirements [1] This proposal removes the requirement for the first Autonomous System Number for an organisation or LIR (in case an organisation has more than one LIR) and introduces a set of requirements that are reasonable, will not deplete the pool of available ASN and be enforceable for RIPE NCC. [1] - Personal ASN Open House Recap - RIPE NCC - Page 5 https://ripe89.ripe.net/wp-content/uploads/presentations/88-Personal-ASN.pdf <https://ripe89.ripe.net/wp-content/uploads/presentations/88-Personal-ASN.pdf> Arguments against the proposal Simplified availability of ASN will result in an increase of Autonomous Systems on the GRT. While depletion of available ASN will not be a problem in the foreseeable future, there could be an increase of complexity of the GRT which will increase the requirements on processing power and memory of network equipment. Counterarguments: * An increase of Autonomous systems might not have as big of effect on hardware requirements as one might think at first. Conservation measures for cases presented in RFC1930 and RFC2280 and others conserve only the AS number, and do not conserve the processing power and memory needed to process the announced prefixes. When a foreign prefix (e.g. PI) as announced (via e.g. private ASN) from an AS (e.g. ISP) it still creates a separate entry in the routing table. * This policy shouldn't cause any significant increase of complexity of GRT, because best practices from RFC1930 were not used. New technologies built on easy availability of AS numbers could exponentially increase the request rate for new AS numbers Counterarguments: * New RIPE NCC fees, particularly "per ASN" fee, mitigates this to some extent. However, current per ASN fee of 50€, would in practice not stop such technology from being developed based on cost alone. On the other hand, an increase of fees would jeopardize small and private ASN end-users. Risk of mass (hundreds or thousands) ASN requests exist. The effect of this policy should be reviewed within a reasonable timeframe after implementing.

8 31