October 2022 - address-policy-wg

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

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