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

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

In memoriam: Erik Bais
by Alex Le Heux 31 May '24

31 May '24

Dear Address Policy WG, We are deeply saddened by the passing of one of the pillars of the RIPE community, Erik Bais, on Tuesday, 28 May 2024. Erik was a RIPE NCC member, the Address Policy Working Group Chair, and above all, a dear friend to RIPE NCC staff and the RIPE community. Erik’s willingness to help others in any and all situations will be profoundly missed. Erik was 51 years old and is survived by the love of his life Wilhelmina and his amazing sons Lars and Niels A condolence and farewell service will be held in Purmerend on Tuesday, 4 June 2024. Anyone whose life was touched by Erik in any way is welcome to pay their respects. Uitvaartcentrum Purmerend Purmerweg 94 1441 RC Purmerend The Netherlands 4 June 2024 19:30 - 21:30 CEST For those who cannot make the journey there is an online condolence register at: https://www.memori.nl/gedenkplaats/erik-bais Erik will be cremated in a private ceremony which can be followed online on 5 June 2024 at 13:00 CEST: https://start.memoriam.tv/SEPC-19WV Because Erik cared deeply about the mental health of the people and community around him, his family has requested that instead of sending flowers, those who wish to should make a donation in Erik's name to the Dutch Suicide Prevention Fund: Account name: 113 Fonds Zelfmoordpreventie IBAN: NL 54 RABO 0160 6244 87 / BIC: RABONL2U Reference: Erik Bais https://doneren.113.nl/doneer-aan-113-zelfmoordpreventie Alex Le Heux, Leo Vegoda Co-chairs

1 0

New RIPE Labs Article: "IPv6 Stockpiling: A Trojan Horse in Our Midst?"
by Marco Schmidt 18 May '24

18 May '24

Dear colleagues, Together with my colleague Rene Wilhelm, I have just published an article on the interesting phenomenon of IPv6 stockpiling and its implications for the Internet ecosystem in our region. You can find the article here: https://labs.ripe.net/author/marco_schmidt/ipv6-stockpiling-a-trojan-horse-… During the Address Policy WG session at RIPE 88 next week, I'll be talking more about this trend and would love to hear your thoughts. Kind regards, Marco Schmidt Manager Registration Services RIPE NCC

3 2

RIPE Labs: Reflections on Six Months as Chief Registry Officer
by James Kennedy 17 May '24

17 May '24

Dear colleagues, I have published a new RIPE Labs article reflecting on my first six months as Chief Registry Officer: https://labs.ripe.net/author/james-kennedy/reflections-on-six-months-as-chi… In the article, I explore the changing environment and how some of the associated pressures are affecting our Registry Department. I also look at the impact of the increased volume of End User ASN requests and provide some numbers on our overall workload. Any feedback or questions are welcome. Kind regards, James Kennedy Chief Registry Officer RIPE NCC

1 0

Address Policy WG Agenda for RIPE 88
by Leo Vegoda 16 May '24

16 May '24

Dear Address Policy WG, We are still adjusting the agenda but here is the current draft. Welcome A. Chair selection B. ASO AC update C. Registry Services Update D. Policy Update E. IPv6 PI Policy F. COFFEE BREAK G. PI Policy Simplification H. ASN assignment issues I. Getting useful input from government adjacent organisations J. Open Microphone We’ll confirm the final agenda early next week. Kind regards, Alex Le Heux, Erik Bais, Leo Vegoda co-chairs

1 0

Last Call - 2023-04 (Add AGGREGATED-BY-LIR status
by Leo Vegoda 01 May '24

01 May '24

Dear Address Policy WG, There was a consensus on this proposal and we are moving it forward to Last Call. The RIPE NCC will publish an announcement with dates. There was a request, in Rome, for clarity over whether aggregated assignments needed to have a fixed size or could vary. The proposers suggested that a fixed size should be optional. We extended the list discussion by a month and the two issues raised have been addressed. One was End User sites not having the End User's own admin-c instead of the LIR's. There has been extensive discussion of this. One key reason given is that it is common and acceptable to outsource a part of an organisation's operations to another, more skilled, operator. The RIPE NCC's impact analysis noted that the proposal "simply leaves the status quo unchanged." It would not need to update its operational processes. Concerns were also raised that aggregating assignments would impact criminal investigations. But this proposal is intended to improve the quality of data registered by offering LIRs a less arduous way to share registration data. At the end of 2023 there were over 19,000 PA allocations without any assignments. Those LIRs that want to share data are already doing so. Those who would like to share some data if it were easier to do so will be accommodated if this proposal becomes policy. Kind regards, Leo Vegoda, for the Address Policy WG co-chairs

10 13

Discussion on Options for Revising the IPv6 PI Assignment Policy
by Tobias Fiebig 20 Apr '24

20 Apr '24

Dear Colleagues, at RIPE87 in Rome we discussed several pathways forward for the IPv6 address policy in the NCC region. I suggested to take a look at the IPv6 PI policy. Over the past months I have been collecting perspectives and ideas which I aggregated to a suggested set of changes which I would like to start discussing on the ML prior to RIPE88, to see whether these directions work for the community, and how to improve them. Please note that this is not a formal proposal, but a work-in-progress as a basis for further discussion. I am tracking the development of the text in git; Additionally, I also attached the corresponding files. Individual suggestions can be found here; Each .patch contains more detailed reasoning along with the proposed change. https://git.as59645.net/tfiebig/ripe-738-pi-update/src/branch/draft-04/indi… And the overall diff here: https://git.as59645.net/tfiebig/ripe-738-pi-update/src/branch/draft-04/draf… # The core changes proposed are: ## Section 2.6 - Clarify that a PI assignment holder may host another entities' server in their assignment, also providing them with a /64-/56 - Allow (for servers) static address configuration - Explicitly prohibit use of PI space for subscriber services, while still allowing uses like, e.g., Freifunk ## Section 2.9 - Define meaning of 'End Site' for PA and PI individually to better distinguish between the nuances of the two - Make sure that an L2 link (e.g., direct fibre/wave, packet- switched vlan etc.) does not merge end sites. - Allow announcing more specifics from end sites when the set of end sites received a covering prefix ## Section 5.4. - Make it explicit that this section is about assignments made from an LIR's allocation - Made wording more precise ## Section 7.1 - Clarify for what PI assignments are made (end users using the assignment in their infrastructure, without making sub- assignments) - Clarified that PI assignments have a prefix length of /48 or shorter. - Introduced that PI assignments to one end user should be aggregatable to prevent address space fragmentation ## (NEW) Section 7.1.1 - Introduce PI assignments being made at the nibble boundary; This is to make extendability/reservations/planning easier, i.e., limiting renumbering needs for PI holders if they require more address space. Furthermore, it also allows testing the implications such a move would have on the larger scope of PA. - Ensures that assignments are atomic, i.e., cannot be further split to prevent fragmentation ## (NEW) Section 7.1.2 - Describe that PI assignment holders need to request an extension of their assignment if they need more address space, instead of requesting a new assignment. ## (NEW) Section 7.1.3 - Describe how PI assignments assigned prior to the policy change should be handled. Essentially: - When more space is needed, the assignment holder receives one (new) prefix for their whole addressing need - All other assignments must be returned after a renumbering period - The renumbering period can be extended by providing documentation that renumbering is not feasible. The idea here is that this places resources in a state which does not force assignment holders to immediately perform a (potentially unreasonably costly) renumbering. However, if the space is (eventually) freed it will have to be returned. # Together, these changes should accomplish: - Easier accessibility of PI for small organizations that do not provide address space to third parties, while allowing better aggregation when such an organization would, under the current policy, require multiple assignments - More streamlined / easier to assess assignment procedures - Reducing fragmentation of PI, while also reducing previously accumulated address space fragmentation - Clarification concerning common issues of PI, e.g., a dual-homed end user who wants to co-locate a server for a friend, while providing a static address that is >=/64, i.e., follows IPv6 addressing best practices. - Allowing the use of a /64 per device in, e.g., an organization's WiFi - Making it more explicit that uses that are commonly associated with an IP making assignments from their allocation are not permitted with PI I am looking forward to receiving feedback on the direction, and always appreciate suggestions to change formulations and improve upon the current version to move towards a document that can reach consensus. With best regards, Tobias -- Dr.-Ing. Tobias Fiebig T +31 616 80 98 99 M tobias(a)fiebig.nl

3 3

Address Policy WG co-chair selection
by Leo Vegoda 19 Apr '24

19 Apr '24

Dear Address Policy WG, We need to select two co-chairs for the Address Policy WG at RIPE 88 in May. You can find a job description here: https://www.ripe.net/publications/docs/wgchair-job-description The RIPE NCC has produced a RIPE Working Group Chair e-learning course. You can find it at: https://academy.ripe.net/enrol/index.php?id=16 Erik Bais's term ends at RIPE 88. He has volunteered to serve again. Alex le Heux volunteered and was introduced at RIPE 87 in Rome. He would like to be confirmed as co-chair. Other volunteers are welcome to put their names forward. You can either write directly to this list or to me. I will publish the full list of candidates on Friday, 19 April. The process for deciding on co-chairs is published on our website: https://www.ripe.net/community/wg/active-wg/ap/address-policy-wg-chair-sele… As two co-chairs need to be selected at the same time, one will take a three year term and the other a two year term. Kind regards, Leo Vegoda, for the Address Policy WG co-chairs

1 1

New RIPE Labs Article - Building a stable future for the RIPE NCC
by Remco van Mook 18 Apr '24

18 Apr '24

Dear colleagues, I’d like to draw your attention to an article that was just published on RIPE Labs, about building a stable future for the RIPE NCC. As it touches on some very foundational aspects all across the various working groups and NCC membership, I thought it important to share, and I would very much like to ask everyone for their input and ideas. In order to not spread the discussion too much across the various mailing lists, I suggest that we use the general RIPE list (which I’ve put into the reply-to field of this email. I’m currently in the process of organising a BOF during RIPE 88 on this topic as well and am looking forward to a constructive discussion! Kind regards, Remco van Mook RIPE NCC Executive Board

2 2