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

Minimum size for IPv4 temporary assignments
by Edwin Verheul 17 Nov '22

17 Nov '22

Dear colleagues of the Address Policy Working Group, During (my first!) RIPE85 there was short discussion about the minimal size for IPv4 temporary assignments in this workgroup. The policy for temporary IPv4 assignments requires you to use 50% of the assigned addresses [1]. This requirement pushes events or experiments into smaller assignments less than /24’s, which are mostly unroutable on the internet. This is mentioned before by Marco Schmidt [2] in October 2022 and Randy Bush [3] in Januari 2022. It looks to me this is a legitimate reason to propose this in a policy change: * Temporary IPv4 assignments ≤ /24 should NOT subject to the 50% usage requirement; * Only smaller assignments will be handed out if the assignee is explicitly willing to have (sub optimal) unroutable IP space on the internet; * If it is required by the assignee to advertise multiple subnets, the policy should allow to assign multiple /24’s( or a bigger assignment, so the assignee can split and advertise by themselves). Elvis Velea and myself are willing to (co) author this proposal. We will do our best to hand in the proposal by the end of this year. Any thoughts on this? Kind regards, Edwin Verheul SURF AS1103 [1] https://www.ripe.net/publications/docs/ripe-587#utilisation-rates [2] https://www.ripe.net/ripe/mail/archives/address-policy-wg/2022-October/0135… [3] https://www.ripe.net/ripe/mail/archives/address-policy-wg/2022-January/0134…

1 0

IPv6 Allocation to the RIPE NCC
by Marco Schmidt 11 Nov '22

11 Nov '22

Dear colleagues, The RIPE NCC Arbiters Panel has approved a request for an IPv6 allocation to the RIPE NCC for its internal network based on the RIPE Document ripe-635, "Allocating/Assigning Resources to the RIPE NCC", and the RIPE NCC Document ripe-738, “IPv6 Address Allocation and Assignment Policy”. You can find the full announcement at: https://www.ripe.net/publications/news/about-ripe-ncc-and-ripe/ipv6-allocat… If you have any questions, please send us a message at <feedback at ripe.net>. Kind regards, Marco Schmidt Manager Registration Services RIPE NCC

1 0

IXP pool lower boundary of assignments
by Matthias Wichtlhuber 08 Nov '22

08 Nov '22

Hi address policy WG, Marco pointed out in the WG session, that we should probably start a discussion on the lower boundary of assignments from the IXP pool. I would like to kick off this discussion with this post. When we had the discussion on the current policy in 2019, I posted an analysis of PeeringDB data, which I have updated with data from 2022 now (https://github.com/mwichtlh/address-policy-wg). The comparison of both analyses provides some interesting data points: 1.) The overall number of IXPs is growing fast (951 IXPs up from 672 in 2019 with 1014 peering LANs up from 726 in 2019). To me, this looks more like exponential growth and honestly speaking I doubt the linear projection of depletion in 2029 presented in the WG. I think this will happen earlier. 2.) The updated data clearly shows that the lower boundary of /24 assignments continues to create a lot of waste in terms of IP space, as ~80% of all IXPs would fit into a /25 (including 100% overprovisioning) and roughly 70% of all IXPs would even fit into a /26 (including 100% overprovisioning). Thus, decreasing the assignmemt size is unlikely to cause harm but might be very helpful to extend the lifetime of the pool into the 2030s. Another pro I see here is that lowering the boundary would allow to extend the overall size of the pool, as we could ask RIPE to add IP space dust </24 to the pool, that cannot be assigned anyways because it cannot be routed; please note that IXPs commonly have no interest in routing their peering LAN space, e.g., leaking the peering LAN space at DE-CIX is explicitly disallowed for members and will quickly lead to a port shutdown for the respective AS because we don't want a route into the peering LAN for security reasons. With regard to that, the "bug" of non-routeable IP space could even be a feature for many IXPs, because it does not require monitoring external BGP collectors for route leaks. At the same time, we should be well aware that we are only buying time. That's why we should kick off some initiative to test and deploy multi protocol BGP at IXPs (but that is probably a question for the IXP community). Regards, Matthias -- Dr.-Ing. Matthias Wichtlhuber Senior Researcher ------------------------------ DE-CIX Management GmbH Lindleystr. 12, 60314 Frankfurt (Germany) phone: +49 69 1730902 141 mobile: +49 171 3836036 fax: +49 69 4056 2716 e-mail: matthias.wichtlhuber(a)de-cix.net web: www.de-cix.net ------------------------------ DE-CIX Management GmbH Executive Directors: Ivaylo Ivanov and Sebastian Seifert Trade registry: District court (Amtsgericht) Cologne, HRB 51135 Registered office: Lichtstr. 43i, 50825 Cologne ------------------------------ DE-CIX 25th anniversary: Without you the Internet would not be the same! Join us on the journey at https://withoutyou.de-cix.net

13 35

Re: [address-policy-wg] IXP pool lower boundary of assignments
by Aleksi Suhonen 07 Nov '22

07 Nov '22

Hello, I feel that /26 is the smallest reasonable subnet size for an IXP, no matter how small the IXP is initially. If it starts growing, it will quickly grow past /27, but might just stay inside the /26. This is based on empirical experience over the decades. I do agree that it would be nice if the vendors took RFC 5549 seriously. A lot of IXPs would be ready to adopt it, if it was an option. It will create some headaches for route server scalability, but perhaps bird3 will fix those... anyway I digress... My two cents, PS. I don't think Tore appreciates how much more difficult it is to renumber an IXP compared to a data centre or an access provider. -- Aleksi Suhonen / TREX () ascii ribbon campaign /\ support plain text e-mail

4 4

2022-02 New Policy Proposal (Remove mandatory IPv4 PA assignment registration in the RIPE Database)
by Angela Dall'Ara 01 Nov '22

01 Nov '22

Dear colleagues, A new RIPE Policy Proposal, 2022-02, "Remove mandatory IPv4 PA assignment registration in the RIPE Database" is now available for discussion. This goal of this proposal is to change the registration of IPv4 assignments from mandatory to optional. You can find the full proposal at: https://www.ripe.net/participate/policies/proposals/2022-02 <https://www.ripe.net/participate/policies/proposals/2022-02> As per the RIPE Policy Development Process (PDP), the purpose of this four-week 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 <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 2 November 2022. Kind regards, Angela Dall'Ara Policy Officer RIPE NCC

15 40

Re: [address-policy-wg] [ncc-announce] [news] RIPE NCC Response to Committee of the Verkhovna Rada of Ukraine
by Sander Steffann 21 Oct '22

21 Oct '22

Hi Hans Petter! > I would encourage you to have a look at the article outlining some of the alternatives: > https://labs.ripe.net/author/athina/protecting-resource-holders-in-distress… Yeah, I did read that. I just don’t agree with the arguments. > While this might seem like an easy solution on the surface, we cannot help but anticipate situations where this could be abused. For example, we can imagine cases where malicious employees want to prevent an upcoming transfer. Such a solution would also have some administrative challenges, because who is authorised to activate this freeze would need to be specified. Make it the same person who is authorised to open/close an LIR. The NCC already has those contracts. To prevent abuse make it a paper form with signatures over registered mail, or whatever the NCC has in place already. I’d put the authorisation level at the same one as closing the LIR. > Also, we wouldn't be able to adhere to such a requested freeze when companies are bankrupt, liquidated or in case of a legitimate merger and acquisition. Yeah, I agree there is little you can do about those in any circumstance. > In any case, if the period of time for the lock is longer than a couple of days, we would again be very reluctant in implementing this solution without a policy proposal. Why? An LIR explicitly and voluntarily giving up some rights they have under the service agreement is surely a matter between the member and the NCC? The policy stays exactly the same. > I can assure you that we have taken the measures we believe we can within the existing policy. I think adding a disclaimer that allows for making transfers null and void retroactively is a much bigger risk to all involved than a transfer lock would have been. I don’t see how on one hand the NCC can’t verify whether a transfer lock is valid, but can verify with absolute certainty that existing paperwork is null and void. To me it feels more like a “let someone else figure this out in court” attitude than an actively helpful one. > Looking forward to hearing what the community thinks here at the list or the meeting next week. Me too! I’m only a single voice here, and this is a community! Cheers, Sander

2 1

Re: [address-policy-wg] [ncc-announce] [news] RIPE NCC Response to Committee of the Verkhovna Rada of Ukraine
by Sander Steffann 20 Oct '22

20 Oct '22

Hi Hans Petter, > Today we responded to a request from the Committee of the Verkhovna Rada of Ukraine on Matters of National Security, Defense and Intelligence to discuss measures to protect Internet number resources in Ukraine. We have published this on our website: > https://www.ripe.net/publications/news/announcements/ripe-ncc-response-to-c… > > As we note in our response, we will be presenting on this topic in the RIPE NCC Services Working Group at RIPE 85 next week. We encourage anyone with an interest in this topic to join that session. In your response you refer them to the Address Policy Working Group ("On the same day, from 09:00-11:30 UTC+2, the Address Policy Working Group will meet to discuss matters of policy, and we suggest that this would be a good forum to raise these matters.”). I am not sure I agree with that. I think the current situation requires something like a transfer lock that LIRs can voluntarily activate. I remember already talking about that with NCC staff at the Berlin meeting, so the issue was known and a possible solution discussed a long time ago. To be honest I expected that the NCC had long since implemented something like this as an operational procedure. I do not consider something like that a matter for policy. The address policies stay exactly the same, only the operational procedures should change. My personal feeling is that the NCC is taking much too long here, sending the poor ISPs in Ukraine into a lengthy process of having to write a policy that will take even longer to implement, for something that is an operational matter, not a policy one. I urge you to solve this inside the NCC as soon as possible. You do not need this community to write policy on how to protect the RIPE database’s contents from clear and present operational dangers. I’m sure there will be many in this community scrutinising whatever you come up with, and there will be much debate on whether the solution the NCC implemented contains bike sheds in all the right colours, and I guess that is unavoidable in a bottom-up community. But a fast response (which IMHO should have been done months ago) is more important than perfection right now. Please go for “good enough for now” first. Thank you Sander

1 0

Draft Address Policy WG Agenda - RIPE 85
by Leo Vegoda 17 Oct '22

17 Oct '22

Dear Address Policy WG, This is the draft agenda for our sessions in Belgrade at RIPE 85 later this month. Kind regards, Leo (for the co-chairs) Address Policy Working Group Wednesday, 26 October 09:00 - 10:00 (UTC+2) Chaired By: Erik Bais, James Kennedy, Leo Vegoda A. Introduction [5 mins] B. ASO AC Update [10 mins] C. NRO NC Election [10 mins] D. Policy Update followed by Q&A [15 mins] RIPE NCC E. (2022-02) Remove mandatory IPv4 PA assignment registration in the RIPE Database [15 mins] Wednesday, 26 October 10:30 - 11:30 (UTC+2) Chaired By: Erik Bais, James Kennedy, Leo Vegoda F. Registry Services Update Followed by Q&A [15 mins] RIPE NCC G. IPv6 Policy Goals - Review Process (community input sought) [15 mins] H. Temporary IPv4 Assignments - Minimum Assignment Size [10 mins] I. AOB/Open Mic [20 min]

1 1

Potential Improvements to the Temporary Internet Number Assignment Policies
by Marco Schmidt 12 Oct '22

12 Oct '22

Dear colleagues of the Address Policy Working Group, During the last RIPE Meeting in May, I presented on several observations that the Registration Services department had [1]. After receiving some feedback during the meeting, it was agreed to continue the discussion on the mailing list before RIPE 85. One of the topics discussed was the challenges encountered when dealing with temporary assignment requests. A specific policy allows the RIPE NCC to assign Internet Number resources on a temporary basis for a specific time-limited purpose, such as academic research and experimental purposes, conferences and other types of events. [2] Over the past years, the RIPE NCC has received some requests for academic research that required only a few IPv4 addresses for actual experiments, but within a routable prefix. This created a conflict with the current policy which requires the use of at least 50% of the requested IPv4 address space. With some creativity, the RIPE NCC has been able to approve these requests so far, but this has resulted in unnecessary delays in processing these requests. It is also possible that people have been refraining from submitting a request because of this policy limitation. One possible solution would be to review the current policy and propose a policy change, for example the introduction of a minimum IPv4 assignment size. Does the working group agree that this is an issue that should be discussed and that might require a policy change? Kind regards, Marco Schmidt Manager Registration Services RIPE NCC [1] https://ripe84.ripe.net/archives/video/786/ [2] https://www.ripe.net/publications/docs/ripe-587

5 4

RIPE NCC impact analysis for RIPE DB Requirements TF recommendations
by James Kennedy 14 Sep '22

14 Sep '22

Dear APWG, The RIPE NCC has released an initial impact analysis on the recommendations made by the RIPE Database Requirements Task Force. This should prove a useful reference point when reviewing the recommendations. You can find a link to the impact analysis here, at the end of the first paragraph: https://www.ripe.net/participate/ripe/tf/rdb-requirements-tf/database-requi…. Regarding recommendation 2: IPv4 PA Assignments, the RIPE NCC reports the following "Requirements" and "Impact". "Requirements: A new policy providing details about if and how to amend PA assignment registration must be proposed and accepted in the RIPE Address Policy WG. Impact: The RIPE NCC will need to update the Database rules and related external documentation. RIPE NCC Registry Services can expect some additional tickets with questions and requests for support. RIPE NCC training course content will need to be updated." RDBTF recommendation 2: IPv4 PA assignments 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. Please note that the task force does NOT recommend that these assignments be deleted but that resource holders can choose to document this information in the RIPE Database. However, if a resource holder wants to sub-allocate or partition part of their IPv4 resources to another entity, the task force strongly recommends documenting this sub-allocation or assignment in the RIPE Database. 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. To ensure that the information published in the RIPE Database is correctly updated by resource holders, the task force recommends that the RIPE NCC continue to use ARCs (Assisted Registry Checks) to verify this data. *** Regards, James apwg co-chair

1 1

Maximum size for current IPv4 allocations
by Ronald F. Guilmette 22 Aug '22

22 Aug '22

What is the maximum size for current new IPv4 allocations in the RIPE region? Someone told me it is /22, but I need to double check that.

8 14

Address Policy WG Minutes from RIPE 84
by Leo Vegoda 05 Aug '22

05 Aug '22

Dear WG, The RIPE NCC has now published draft minutes of our session at RIPE 84. Please write to this list or inform the co-chairs of any issues or corrections. https://www.ripe.net/participate/ripe/wg/active-wg/ap/minutes/ripe-84-addre… Video recordings and transcripts are available on https://ripe84.ripe.net Many thanks to Matt Parker for taking the minutes. Kind regards, Leo Vegoda for the Address Policy WG co-chairs

1 0

Reclamation of Number Resources
by Ronald F. Guilmette 12 Jul '22

12 Jul '22

Greetings all, As many of you no doubt know, there has been quite an extraordinarily large brouhaha of late within the AFRINIC region relating to AFRINIC's efforts to reclaim certain large blocks of IPv4 addresses from one particular member organization. This effort has resulted in considerable litigation within Mauritius, the home country of AFRINIC. Partially as a result of this ongoing controversy, but also just for my own edification, I would like to ask a number of questions about any and all prior instances in which RIPE has reclaimed number resources from member organizations, based on policy. It seems safe to assume that there have historically been some instances in which RIPE memberships have been terminated, and any associated assigned number resources reclaimed, if and when a given member has simply failed to pay fess due to RIPE. My questions however have to do with situations where policy violations other than the non-payment of fees are involved. Specifically, I would like to know if any of you can recall past instances where number resources have been reclaimed, by RIPE, for any of the following reasons: *) Usage of the assigned number resources was no longer consistant with the original justification submitted to RIPE. *) Violation(s) of out-of-region usage policy. *) Any other policy violations. Thanks in advance for any and all responses. Regards, rfg

2 3

2022-01 end user personal data
by denis walker 29 Jun '22

29 Jun '22

Colleagues I have just started a discussion on the DB-WG mailing list about the use of the "descr:'' attribute in resource objects for the personal data of end users. As this may overlap with registration data issues, it may be of interest to this community. The discussion starts here https://www.ripe.net/ripe/mail/archives/db-wg/2022-June/007515.html cheers denis Proposal author

1 0

Re: [address-policy-wg] IPv6 Policy Musings...
by Max Emig 06 Jun '22

06 Jun '22

Good morning, thanks Max :) and of course Gert for the effort and the excellent presentation; I fully agree with the goals you described. To reiterate, end users can request an assignment of one separate /48 PI allocation per site with little justification. The implementation of the current policy permanently inhibits aggregation; receiving the same number of bits as an aggregate assignment instead of multiple /48 PI in practice requires a much more convoluted justification of additional routing requirements. To get a better understanding of the impact of the current policy, I've done some analysis on the state of IPv6 PI assignments: Number of IPv6 PI assignments per prefix length: /48: 3381 assignments /47: 40 assignments /46: 15 assignments /45: 7 assignments /44: 2 assignments /42: 1 assignment /40: 1 assignment /32: 3 assignments Number of /48 PI assignements per organisations: 1 /48: 2896 organisations 2 /48: 123 organisations 3 /48: 28 organisations 4 /48: 15 organisations 5 /48: 5 organisations 6 /48: 5 organisations 7 /48: 4 organisations 12 /48: 1 organisation This can't account for the number of end users who didn't choose to go with one /48 IPv6 PI per site, i.e. by leasing IPv6 (disaggregating PA space) instead or were deterred from IPv6 deployment at all. Enterprises, which stand to benefit from a policy change, are still lagging the furthest behind with IPv6 deployment, according to Paolo Volpato's presentation in the IPv6 WG. As Gert described, renumbering is hard. I believe we shouldn't needlessly prevent any aggregation from occurring in the future, i.e. when an end-user with multiple sites adds transport links between their sites or other future changes of plans, they should be able to aggregate. I support the proposal to promote aggregation as a BCOP. Please keep in mind that a single disaggregated /29 PA from any LIR could octuple the size of the global routing table; we shouldn't judge end-users abilities to keep the size of the global routing down any worse than those of LIR, which could cause significantly more harm. >From a conservation perspective, rounding up the additional bits to the next aggregate block is hardly relevant, especially compared to the generous IPv6 PA allocations to LIR. Currently, each standard /48 PI assignment has a reserved size of /46 in the pool; allowing for non-bureaucratic extensions instead of additional /48 PI assignments for additional sites is therefore more conservative than the status quo in the current model. The fact that the already reserved /46 can satisfy the needs of over 90% of the end-users with more than one /48 PI assignment per organisation, as per my analysis, fits in nicely with this proposal. Neither I nor any entity I am currently representing is interested in obtaining larger IPv6 PI assignments at the moment. Thus, I believe I am in no conflict of interest. Best regards Maximilian Emig On Sunday, May 22, 2022 20:59 CEST, Maximilian Wilhelm <max(a)rfc2324.org> wrote: Anno domini 2022 Gert Doering scripsit: Hey folks, > I announced too many weeks ago that a small group was looking into the > IPv6 policy, as it is today, why it is what it is, and whether the > underlying assumptions that the policy is based on are still valid. [...] > We'll present about this next week, picking some points as starting > points for "shall we do something here? if yes, what? and who?" - > but this is not about *me*, but about the commounity - *you*. Anyone > is free and welcome to start a discussion and work on aspects we brought > up - or on other aspects. Thanks for this and the work you put into it! I also believe some parts of the policies need some review and overhaul, and I think you identified a lot of details to think about. I'll try go provide a brain dump of some topics which resonated with me and which I ran into in the past with one of my different hats. First and foremoest, I agree with the observation that IPv6 PI space is a complicated beast and I still remember my last attempt at making it more usuable so people don't have to lie about there use cases. I fully agree with Jan's statement at the mic that we should look into this again and like Gert's suggestion to just drop the "3rd party clause" of the PI policy. In *this* case the marked might really have solved the issue and I'd be confident the issue of ISPs only giving out one IP per subscriber won't arise as those offers will be laughted at. Another commonly observed obstacle with IPv6 PI has been getting more than one /48, which also has been brought up by Max (not me :)), which I also fully agree with. If a network has a number of sites today and qualifies for n * /48 prefixes and in the foreseeable future might be able to conntect those sites (by means of DF, waves, or whatever), it does make a lot of sense to provide this organization with the aggregate for ceil(n * /48). Even if the sites don't end up being interconnected there's not much difference in prefix size and routing table usage, but less hassle for all parties involved. As a customer I recently ran into the issue that an IP access business connection came with an IPv4 /29 out of the box but no IPv6 whatsoever, not even a /64 on-link which would have totally sufficed for the use case. To get a /56 available on that link, it needed to be booked for 30€ MRC on top of the existing monthly fee, which isn't very 2020. Private customers obviously get IPv6 by default as DS-lite is used to serve their IPv4 traffic. Tackling business practices isn't really within our scope, but maybe we can have this in mind when updating BCOP documents, to "motivate" ISPs to diverge from such practices, which certainly do not help furthering IPv6 deployment. Cheers, Max -- Friends are relatives you make for yourself. -- 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

1 0

IPv6 Policy Musings...
by Gert Doering 22 May '22

22 May '22

Dear Working Group, I announced too many weeks ago that a small group was looking into the IPv6 policy, as it is today, why it is what it is, and whether the underlying assumptions that the policy is based on are still valid. After taking way too long (apologies - lots of good excuses, but this really shouldn't have dragged so long), I present you document with a very personal view on the IPv6 address policy, coming from me, Kurt Kayser and Sander Steffan (.txt and .pdf). This is not a task force document, this is not a formal WG document, and this is not an official RIPE document (though it might make a labs article). It is intended as a personal look at 24-odd years of IPv6 policy... and to spur discussion and further work on some areas that feel "in the rough". We'll present about this next week, picking some points as starting points for "shall we do something here? if yes, what? and who?" - but this is not about *me*, but about the commounity - *you*. Anyone is free and welcome to start a discussion and work on aspects we brought up - or on other aspects. Gert Doering -- long-time IPv6 policy geek -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279

2 1

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