April 2024 - address-policy-wg

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

Co-chair selection (was: Fwd: [ripe-list] The RIPE Chair Team Reports - April 2024)
by Leo Vegoda 17 Apr '24

17 Apr '24

Hi, Mirjam's update notes that this and other working groups are running selections for co-chairs. If you are interested in becoming a co-chair of this or another working group, please take a look at Mirjam's blog post and the linked resources. They include a job description and training resources. My earlier announcement is archived here: https://www.ripe.net/ripe/mail/archives/address-policy-wg/2024-March/014008… If you are considering standing for selection as co-chair, now or in the future, you're welcome to contact me directly. I'll be posting the list of candidates on 19 April. Kind regards, Leo ---------- Forwarded message --------- From: Mirjam Kuehne <mir(a)zu-hause.nl> Date: Wed, 17 Apr 2024 at 03:47 Subject: [ripe-list] The RIPE Chair Team Reports - April 2024 To: RIPE List <ripe-list(a)ripe.net> Dear colleagues, With the RIPE 88 Meeting approaching fast, and plenty of developments in our community, we report on some of the developments in this new article on RIPE Labs: https://labs.ripe.net/author/mirjam_kuhne/the-ripe-chair-team-reports-april… Kind regards, Mirjam Kühne RIPE Chair -- 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

2023-04 Proposal Accepted (Add AGGREGATED-BY-LIR status for IPv4 PA assignments)
by Angela Dall'ara 16 Apr '24

16 Apr '24

Dear colleagues, Consensus has been reached on 2023-04 "Add AGGREGATED-BY-LIR status for IPv4 PA assignments". This proposal aimed at introducing the AGGREGATED-BY-LIR status for IPv4 PA assignments to reduce LIR efforts in registration and maintenance. You can find the full proposal at: https://www.ripe.net/membership/policies/proposals/2023-04/ The new RIPE Document is called ripe-822 and is available at: https://www.ripe.net/publications/docs/ripe-822/ We estimate that this proposal will take around two months to fully implement. We will send another announcement once the implementation is complete and the new procedures are in place. Thanks to everyone who provided input. Kind regards, Angela Dall'Ara Policy Officer RIPE NCC

3 3

Consensus – 2023-04: Add AGGREGATED-BY-LIR status for IPv4 PA assignments
by Leo Vegoda 15 Apr '24

15 Apr '24

Dear Working Group, No new objections were raised during the Concluding (Last Call) phase. The community has achieved a consensus. The RIPE NCC can proceed with implementation. Our thanks to everyone who contributed to this discussion. In particular, we'd like to thank Tore and Jeroen for the calm professionalism they demonstrated. Kind regards, Leo Vegoda, for the Address Policy WG co-chairs

1 0

Proposal: Limiting Membership and Allocating IPv4 Subnets in Less Developed Countries
by AlbaHost SH.P.K 10 Apr '24

10 Apr '24

Limiting Membership and Allocating IPv4 Subnets in Less Developed Countries. Background: The Regional Internet Registry (RIR) for Europe, the Middle East, and parts of Central Asia, RIPE NCC, faces challenges in managing the allocation of IPv4 addresses due to exhaustion of available IPv4 address space globally. This proposal aims to address these challenges by implementing limits on membership per entity and providing special considerations for less developed countries where IPv6 adoption is still low. Proposal Details: 1. Limit Membership per Entity: - RIPE NCC will implement a policy limiting the number of memberships per entity to a maximum of two. - This measure aims to prevent hoarding of IPv4 address space by a few entities, ensuring fair distribution and availability of addresses to a wider range of organizations. 2. Allocation of IPv4 Subnets in Less Developed Countries: - Recognizing the challenges faced by less developed countries where IPv6 adoption is still minimal, RIPE NCC will allocate more than one /24 subnet to eligible entities in such regions. - This special consideration aims to support the growth and development of internet infrastructure in these countries, allowing them to meet their addressing needs while transitioning to IPv6 gradually. Rationale: 1. Fair Distribution: Limiting membership per entity ensures that a small number of organizations do not monopolize the available IPv4 address space, promoting fair distribution among a broader range of stakeholders. 2. Encouraging IPv6 Adoption: While IPv4 addresses are increasingly scarce, encouraging IPv6 adoption remains a priority. However, in less developed countries where IPv6 infrastructure is till underdeveloped, providing additional IPv4 address space can help sustain internet connectivity and services while facilitating a smoother transition to IPv6 in the long term. 3. Balanced Approach: By combining limits on membership with special considerations for less developed countries, RIPE NCC aims to strike a balance between managing IPv4 scarcity effectively and supporting the needs of regions where internet infrastructure development may lag behind. Conclusion: This proposal seeks to address the challenges of IPv4 address exhaustion by implementing limits on membership per entity and providing additional IPv4 address space to less developed countries. By promoting fair distribution and supporting regions with limited IPv6 adoption, RIPE NCC can better manage its resources while fostering global internet connectivity and development. This proposal invites feedback and discussion from the RIPE community to refine and implement effective policies for the equitable distribution of IPv4 addresses in the region. Kind Regards. -- *Sinqerisht / Sincerely,* AlbaHost [image: Logo] <https://www.albahost.net/> Albanian Hosting SH.P.K. Besim Beka p.n. 50000 Gjakovë, Kosovë. NIPT/VAT ID: 811442657 T: +386900501502 E: info(a)albahost.net W*: *wWw.AlbaHost.Net <http://www.albahost.net/> [image: Facebook icon] <https://www.facebook.com/albanianhosting> [image: Twitter icon] <https://twitter.com/albahost> [image: Instagram icon] <https://www.instagram.com/albahost_vpn/> [image: Banner] Përmbajtja e këtij emaili është konfidenciale dhe ka për qëllim marrësin e specifikuar vetëm në mesazh. Ndalohet rreptësisht shpërndarja e ndonjë pjese të këtij mesazhi me ndonjë palë të tretë, pa pëlqimin me shkrim të dërguesit. Nëse e keni marrë këtë mesazh gabimisht, ju lutemi përgjigjuni këtij mesazhi dhe ndiqni me fshirjen e tij, në mënyrë që të sigurohemi që një gabim i tillë të mos ndodhë në të ardhmen. The content of this email is confidential and intended for the recipient specified in message only. It is strictly forbidden to share any part of this message with any third party, without a written consent of the sender. If you received this message by mistake, please reply to this message and follow with its deletion, so that we can ensure such a mistake does not occur in the future.

4 5

@EXT: FW: Last Call - 2023-04 (Add AGGREGATED-BY-LIR status
by Kessler, Emmanuel 08 Apr '24

08 Apr '24

Dear All, I would have some comments about the previous points that mentions Europol Thanks for your cooperation spirit Regards Emmanuel Kessler -----Original Message----- From: address-policy-wg <address-policy-wg-bounces(a)ripe.net> On Behalf Of Kai 'wusel' Siering via address-policy-wg Sent: vendredi 5 avril 2024 21:41 To: address-policy-wg(a)ripe.net Subject: Re: [address-policy-wg] Last Call - 2023-04 (Add AGGREGATED-BY-LIR status Moin, am 05.04.24 um 16:51 schrieb denis walker: > I used to wonder why no one > would even talk about bringing the RIPE Database into the modern > world. Because this is address-policy (»The Address Policy Working Group develops policies relating to the management and registration of Internet number resources.«), not database (»The Database Working Group deals […]«). > Europol has expressed serious concerns about these changes. Europol has the means to challenge the maintainer of the address space for more information on individual usage; there is no real thread to Europol's operation by the change, it might just become less convenient to get the wanted information. --> Sorry, but reading this, I observe that you may indeed have only a fuzzy/limited idea of what Europol does, and the impact on LE operations.. As knowing the scope of Europol and digital investigation (we work here), we repeat that the matter is not only being less convenient. The matter is the loss of opportunities of identification that will vanish for investigators... > If someone had informed them earlier > of the changes being considered that may affect them, Well, this is happening all in the open. IF Europol is depending so greatly on the RIPE DB, they SHOULD be following the PDP already for years and years and voiced their concerns more timely. --> the matter is not just Europol, but the impact on investigations of LE services....Europol has been regularly well active in various working groups of RIPE... Please consider that capacities of investigators are impacted by a large number of negotiation processes : at E-governance level (ICANN, RIPE,..), UN treaties, Council of Europe conventions, numerous EU legislations (Nis2, E-evidence package, DSA,...), national levels ones... (and I may forget some..?!).... linked with judicial cooperation frameworks, companies regulations, cybersecurity actors, technological standards in permanent evolution, .... The number of working groups, regulations, proposals, legal acts, is the most consequent...it is a "jungle" of processes that have to be covered,...you can believe me... in spite of the efforts of our committed people, we are unfortunately not omniscient an always present everywhere....(nobody is...!). As in all organisations, capacities are not infinite and we have sometimes to prioritize those we have, under emergencies and the various agendas.. ...but whatever the raised questions, THE relevant question is overall that a joint work in open spirit is THE best way...beyond considering the only question of a seat gap at a moment... --> The matter should remain in the end, which impact (positive/negative...) ? when all know new popping processes from the beginning, it allows to formalize swiftly a full knowledge about impact, and prevent 2 undesirable ends that are : wasting time on a proposal that should be given up/ or persisting on the difficult adoption of a measure that will bring damage on victims protection... we can do great job to secure digital space, (just see Lockbit and the latest operations against ransomwares : https://www.europol.europa.eu/media-press/newsroom?q=cyber ) including protecting private sector and companies that are essential for business and the economic health of our countries, but if we lose the access to data, it means less operational achievements/ and criminals being more in capacity to target companies and peoples, who still "pay the bill" of crimes... > proceed with all haste to No haste visible at all; this is about 2023-04 — we already are in 2024-04. Regards, -kai -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/address-policy-wg

4 3