- 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