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

IPv4 PA assignments policy change draft proposal
by Jeroen Lauwers 17 May '22

17 May '22

Dear community, My name is Jeroen and I am new to the community. Ripe 84 is gonna be for me the first in-person Ripe meeting. I thought it would be nice as a newcomer to contribute something to the Ripe Community. In consultation with some of the chairs, we decided I could try to pick up the recommendation from the RIPE Database Requirements Task Force. Last November the DBTF recommended changing the address policy for IPv4 PA assignments (for own usage) from mandatory to recommended. Before I would send it as an official proposal to the RIPE NCC I would like to share it with the community to see what they think about it. I also would give a short presentation about it on RIPE 84 Where there would be space for discussion and feedback. You can find the draft version down in this mail. Feel free to reach me. Kind regards, Jeroen Lauwers #### Policy Draft Proposal #### Remove mandatory IPv4 PA Self assignment registration in the RIPE Database. Number: Author: Jeroen Lauwers jlauwers(a)a2b-internet.com<mailto:jlauwers@a2b-internet.com> A2B Internet Proposal Version: Submission Date: Suggested RIPE WG: Address Policy Proposal Type: Modification Policy Term: Indefinite Summary of Proposal In its final report, the RIPE Database Requirements Task Force (DBTF) recommended dropping IPv4 PA assignment(s) as a policy requirement [ 1 ]. This recommendation was motivated by the fact that existing LIRs are no longer eligible to request additional IPv4 prefixes from the RIPE NCC. This partially obsoletes the requirement for LIRs to document the assignment of used/reserved prefixes in the RIPE Database. This proposal aims to change the policy on assigned IPv4 PA space from “must" to "may", which will address the issue of unnecessary registration and verification of certain prefixes for LIRs and the RIPE NCC. However, it would still be possible (and recommended) for LIRs to register PA assignments. [1] https://www.ripe.net/publications/docs/ripe-767#612 Policy 1.0 Introduction In the past, LIRs could request a new IPv4 prefix when their current pool was sufficiently used. However, since the RIPE NCC started to run out of IPv4, LIRs with existing IPv4 prefixes have not been eligible to receive additional IPv4 prefixes from the RIPE NCC. This resulted in unnecessary efforts by LIRs to register IPv4 prefixes and by the RIPE NCC to ensure that LIRs complied with the policy. This has also led to inconsistencies in the RIPE Database, as some resource holders registered more information than necessary, while many others did not make any PA assignments. The DBTF reported that in May 2021, there were 16,232 PA allocations without any child PA assignments and 9,986 LIRs held PA allocations containing no PA assignments. The current policy states that you must register a PA assignment for each prefix that an LIR uses. If this specific policy were changed from “must” to “may” for IPv4 PA assignments, the RIPE NCC would not need to spend resources on enforcing compliance with LIRs that have not followed this policy. This policy change would also serve the goal to keep the database limited to what is needed. However, it would still be recommended and possible to register IPv4 PA assignments in the RIPE Database. Also, LIRs would still be obligated to make assignments in the database when they want to sub-allocate or partition part of their IPv4 resources to another entity (sub-allocated PA/assignments). 2.0 Policy Text Current policy text [ 2 ] 4.0 Registration Requirements All assignments and allocations must be registered in the RIPE Database. This is necessary to ensure uniqueness and to support network operations. Only allocations and assignments registered in the RIPE Database are considered valid. Registration of objects in the database is the final step in making an allocation or assignment. Registration data (range, contact information, status, etc.) must be correct at all times (i.e. they have to be maintained). New Policy Text 4.0 Registration Requirements Allocations and assignments to third parties must be registered in the RIPE Database to be considered valid. For IPv4 PA assignments used for the LIR's own network infrastructure, registration is recommended but not mandatory. This is necessary to ensure uniqueness and to support network operations. Registration of objects in the database is the final step in making an allocation or assignment. Registration data (range, contact information, status, etc.) which filled in the database, must be correct at all times. [ 2 ] https://www.ripe.net/publications/docs/ripe-733#4 3.0 What about legacy space? As the RIPE NCC does not audit RIPE NCC members on their legacy space or how they use it, this policy change does not have an impact on legacy space or legacy space holders. 4.0 Attribution This document was developed by the RIPE community, and more specifically by Jeroen Lauwers, based on the findings of the RIPE Database Requirements Task Force. Rationale a. Arguments supporting the proposal • One of the main reasons for registering IPv4 PA assignments was that LIRs could show their use of IPv4 and thus justify an additional IPv4 allocation from the RIPE NCC. However, this requirement has become obsolete since the IPv4 run-out. • The application of IPv4 assignment registration policies in the RIPE Database is inconsistent. Some resource holders flood the database with tiny assignments (e.g. assignments for individual IP addresses), while many others do not register any assignments. • Resource holders of a /24 allocation are required to create at least two assignments (/25 or smaller). • This is in line with the data consistency and data minimization principles (as defined in the DBTF report): – Data stored in the RIPE Database should be adequate, relevant, and limited to only what is necessary. – It is recommended that resource registration requirements are applied consistently. • More flexibility b. Arguments opposing the proposal • An exception to the main rule does not make the overall policy more understandable. • It is questionable whether other arguments for public tracking of the use of designated prefixes are weak enough to move from “must” to “may”.

5 9

Draft agenda - Address Policy WG at RIPE 84
by Leo Vegoda 25 Apr '22

25 Apr '22

Hi, We have a draft agenda for the Address Policy WG session on Wednesday, 18 May at RIPE 84. A. Introduction, including appointment of co-chair (10 mins) B. NRO NC Update (10 mins) C. Policy Update followed by Q&A (15 mins) D. Registry Services Update followed by Q&A 15 mins E. IPv6 Policy Goals report from community team followed by discussion (20 mins) F. IPv4 Waiting List (20 mins) - Recap - Find a volunteer to propose the policy G. Database Requirements TF recommendation for removing the requirement for IPv4 assignments (20 mins) - Recap - Discussion H. AOB/Open Mic (10 mins) We look forward to seeing you there in Berlin and online! Kind regards, Leo

1 0

Address Policy WG Co-Chair Selection Process - 2022
by Leo Vegoda 25 Apr '22

25 Apr '22

Dear Address Policy WG, According to our WG Chair Selection process, one of the WG chairs has to step down every two years, and a new WG chair is selected by the WG. Erik Bais is the co-chair whose term ends and he has volunteered to serve again. Other nominations are also welcome. If you would like to put your name forward then you may do so. Please send your name to James Kennedy (jameskennedy001(a)gmail.com) and me. Please include a short bio and your reason for applying. We will collect applications and publish them all on Monday, 25 April. The Address Policy WG will choose at RIPE 84 in Berlin. Kind regards, Leo Vegoda for the Address Policy WG Co-Chairs

1 2

Policy building - call for volunteers
by James Kennedy 10 Apr '22

10 Apr '22

Apologies for the previous formatting :) --- Community friends, Who would like to get involved in some policy building? Putting the “work” back into Working Group, we are seeking volunteers to follow-up on the following two RIPE Database Requirements Task Force recommendations relating to address policy. 2.1. The task force recommends that as resource holders have full responsibility over the registration of their IPv4 PA assignment(s), they are free to make assignments or not. If the community accepts this recommendation, the relevant RIPE Policies should be updated accordingly, and documenting IPv4 PA assignment(s) will stop being a policy requirement. 2.2. Following the data consistency principle, the task force also recommends resource registration requirements be applied consistently to all Internet number resources, regardless of their type or status. https://www.ripe.net/participate/ripe/tf/rdb-requirements-tf/database-requi… https://www.ripe.net/publications/docs/ripe-767 Much of the heavy lifting has already been performed by the task force, and the recommendations have received positive feedback during previous RIPE meetings and BoFs. Please respond with your interest to this thread or directly to the Address Policy WG Co-Chairs. Regards, James APWG co-chair

3 3

Policy building - call for volunteers
by James Kennedy 29 Mar '22

29 Mar '22

Community friends, Who would like to get involved in some policy building? Putting the “work” back into Working Group, we are seeking volunteers to follow-up on the following two RIPE Database Requirements Task Force recommendations relating to address policy. 2.1. The task force recommends that as resource holders have full responsibility over the registration of their IPv4 PA assignment(s), they are free to make assignments or not. If the community accepts this recommendation, the relevant RIPE Policies should be updated accordingly, and documenting IPv4 PA assignment(s) will stop being a policy requirement. 2.2. Following the data consistency principle, the task force also recommends resource registration requirements be applied consistently to all Internet number resources, regardless of their type or status. https://www.ripe.net/participate/ripe/tf/rdb-requirements-tf/database-requi… https://www.ripe.net/publications/docs/ripe-767 Much of the heavy lifting has already been performed by the task force, and the recommendations have received positive feedback during previous RIPE meetings and BoFs. Please respond with your interest to this thread or directly to the Address Policy WG Co-Chairs. Regards, James APWG co-chair

1 0

Re: [address-policy-wg] address-policy-wg Digest, Vol 122, Issue 3
by Den 20 Mar '22

20 Mar '22

Okay, no problem, I have only the one question: - Why RIPE NCC ignores EU sanctions against Russia? -- Regards, Den 02.03.2022 13:00, address-policy-wg-request(a)ripe.net wrote: > Send address-policy-wg mailing list submissions to > address-policy-wg(a)ripe.net > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.ripe.net/mailman/listinfo/address-policy-wg > or, via email, send a message with subject or body 'help' to > address-policy-wg-request(a)ripe.net > > You can reach the person managing the list at > address-policy-wg-owner(a)ripe.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of address-policy-wg digest..." > > > Today's Topics: > > 1. Re: RU goverment IP revoke (James Kennedy) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 1 Mar 2022 12:04:45 +0100 > From: James Kennedy<jameskennedy001(a)gmail.com> > To:address-policy-wg@ripe.net > Subject: Re: [address-policy-wg] RU goverment IP revoke > Message-ID: > <CAN4ZMgXrDem2TJe=5O8ioz_OULQiJPynt_JhSYtboQemhvAx9w(a)mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Community friends, > > The urge for action is understandably strong but please, refrain from using > this working group as a platform for targeted cyber attacks. Despite where > the moral compass may point. > > Also this is not the most effective forum for discussing potential > sanctions or exceptions for specific RIPE NCC members. I would suggest the > ripe-list (www.ripe.net/ripe/mail/archives/ripe-list/) or perhaps the RIPE > NCC Services WG (https://www.ripe.net/participate/ripe/wg/active-wg/services) > are more appropriate for airing such concerns. Address Policy - which is > the focus of this working group - is applied consistently to all RIPE NCC > members. > > Regards, > James > APWG co-chair > > > On Mon, Feb 28, 2022 at 4:03 PM Den<den.rlir(a)gmail.com> wrote: > >> Hi Jan, >> >> Thanks for your time, looks like other's are too busy or already at the >> basement / under attack.. >> >> Here's what I've found: >> >> AS8291 The Federal Guard Service of the Russian Federation / Main >> Division of Informations Resources / kremlin.ru, etc. >> AS43797 The Federal Guard Service of the Russian Federation >> AS42121 The Federal Guard Service of the Russian Federation >> AS48552 OJSC The Russian Armed Forces Broadcasting Company ZVEZDA >> AS57767 Federal State-owned Enterprise Russian Television and Radio >> Broadcasting Network >> AS57352 Federal State Unitary Enterprise Rossiya Segodnya >> International Information Agency >> AS57107 Federal State Unitary Enterprise "Russian Satellite >> Communication Company" >> AS57767 Federal State-owned Enterprise Russian Television and Radio >> Broadcasting Network >> AS59541 Federal State-owned Enterprise "Russian Television and Radio >> Broadcasting Network" >> AS44479 Federal State Unitary Enterprise Rossiya Segodnya >> International Information Agency >> AS25292 Federal State Unitary Enterprise "The Russian Television and >> Radio Broadcasting Company" >> AS211382 Federal State Unitary Enterprise of the Order of the Red >> Banner of Labour "Russian Broad-casting and >> AS208075 Federal State Unitary Enterprise of the Order of the Red >> Banner of Labour "Russian Broad-casting and >> AS201030 Federal state unitary enterprise "Public corporation for >> organisation of air traffic in Russian Fede >> AS198372 Federal State Unitary Enterprise "Television Technical Center >> "Ostankino" >> AS197969 Federal State Unitary Enterprise "Morsviazsputnik" >> AS197553 Federal state unitary enterprise 'State Research Institute of >> Aviation Systems' >> AS197150 Federal State Unitary Enterprise of the Order of the Red >> Banner of Labour "Russian Broad-casting and >> AS196641 Federal Unitary State Enterprise General Radio Freqency Centre >> AS57724 DDOS-GUARD THAT HIDES RT.COM and others russian's broadcasting >> companies >> >> .... >> >> (This list can be much longer, it's from my quick research) >> >> Guys, who read, please help us, please make some unexpected failures, >> anyway you know what to do. >> >> *Let's make our work Now!* >> >> Thanks for all of you guys, we all want Internet with freedom and without >> dictatorship! >> >> Love and peace for all of you guys! >> >> -- >> >> Cheers, Den >> -- >> >> 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 >> >

10 12

Review of IPv6 policy goals
by JORDI PALET MARTINEZ 16 Mar '22

16 Mar '22

Hi all, In the last WG meeting (at the RIPE 83), there was a brief presentation from the chairs about the possible review of IPv6 policy goals. I recall there was at least 3-4 people that volunteered (included myself), but after that we didn't get any discussion in the list or among the people that volunteered. I've not seen any discussion in the list, neither the volunteers being in touch to start working on this, so I think we must move on somehow to get the work done. Could the volunteers confirm they are still willing to participate and we can find a way to organize the work together? Regards, Jordi @jordipalet ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.

6 11

Last call and final reminder for nominations to the 2022 Rob Blokzijl Award
by Carsten Schiefner 14 Mar '22

14 Mar '22

[Apologies for cross-posting to various RIPE lists] Dear Address Policy WG members - this is the last call and final reminder for nominations to the 2022 Rob Blokzijl Award that will be accepted until this Friday, 18th March, at 23:59 UTC. In seeking nominations for this prestigious award, which was created to celebrate Rob's contributions to the development of the Internet, the Award Committee (https://rob-blokzijl-foundation.org/2021/11/22/2022-award-committee/) is interested to receive nominations of those who have reflected Rob's approach in either a technical or operational capacity. Please give some consideration to nominating individuals - but also teams and groups of people! - in your own community and/or the wider industry in the RIPE region who, in your opinion, deserve to be recognised for their work to make the internet and/or internet community better. To specifically have this emphasised again after some according queries: nominations of teams and groups of people are very well possible and wished for as well in case their collective work would match the criteria of the call as laid out! The Award Committee is particularly interested to receive nominations of contributors who, in addition to their own contributions, have also supported and enabled others anywhere in the world. Also, the Award Committee would like to encourage those making nominations to consider not only the community members in the later stages of their careers or who are widely known but also those who may have contributed greatly in the springtime of their career or discreetly for the greater good or who may be considered to be part of an unrepresented group. And last but not least: those of you who previously have made a nomination other than Wilfried Woeber, the 2018 awardee, may want to consider resubmitting a nomination. The complete details of the call and the nomination process can be found at: https://rob-blokzijl-foundation.org/2021/11/25/call-for-nominations-2022/ Best wishes and kind regards Carsten (on behalf of the Award Committee)

1 0

ripe-587, Temporary Internet Number Assignment Policies
by Randy Bush 07 Mar '22

07 Mar '22

ok, i did it again, tried to fit a square peg in a round hole. while the immediate problem is past, thanks to the ncc reg folk, i fear that we could benefit from thinking a bit more about $subject. for a research experiment, we wanted eight or a dozen routable, i.e. /24, prefixes which we would announce from various places in the topology. each /24 would have one pingable address, let's assume .42. because this is ops based research, we have to o go through the ncc bureaucrazy o actually deploy and test o run the measurements for a few months o do the analysis o possibly tune or vary the experiment o write the paper and submit it o wait three months for the accept/reject o if rejected, retune and submit to a different venue o the reviewers may ask for us to re-run to get fresh data for publication o whine whine this takes six to twelve months. if you are familiar with $subject, you will sense there are two problems here. 587 is designed for a much shorter time window, and it kind of assumes more that 1:256 utilisation. you can imagine that my request to registration services generated a bit of discussion :). as our social environment has become less tolerant, reg services understandably wants simple rules they can follow and which clearly justify their actions. and geeks such as i just want our mtv :). i suspect we may be able to wordsmith conditions to deal with the time length issue. but i suspect that codification of guidelines covering the needs & justifications for research experiments, folk qualifying strange devices, and those doing other weird things will not be so easy. i am considering a policy proposal in this space; but want to learn what others see and think, and to see if it is worth the time and effort. and can we please keep discussion focused on temporary address space assignments? thanks. randy

13 27

New on RIPE Labs: IPv4 Allocations - Is Fairness Still the Goal?
by Angela Dall'Ara 03 Mar '22

03 Mar '22

Dear colleagues, An interesting discussion took place last December on whether current policies and procedures for the allocation and transfer of IPv4 resources in the RIPE NCC service region are in line with the original policy intent. To help lend clarity on the issue, I give an overview of the relevant changes that have come into effect since the RIPE NCC started distributing the last /8 we received from IANA. I hope you will find this helpful. https://labs.ripe.net/author/angela_dallara/ipv4-allocations-is-fairness-st… Kind regards, Angela -- Angela Dall'Ara RIPE NCC Policy Officer

1 0