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

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! > 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