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

2023-02 (Minimum Size for IPv4 Temporary Assignments)
by Leo Vegoda 13 Jun '23

13 Jun '23

Dear WG, The Review Phase of policy proposal 2023-02 "Minimum Size for IPv4 Temporary Assignments" has now ended. Many thanks to all for your comments. The proposal will now move forward to the Last Call for Comments Phase. More details about the phases of the Policy development Process are published here: https://www.ripe.net/publications/docs/ripe-781 You'll also see an announcement from the RIPE NCC soon. Kind regards, Leo Vegoda for the co-chairs

1 0

2023-01 (Reducing IXP IPv4 assignment default size to a /26)
by Leo Vegoda 13 Jun '23

13 Jun '23

Dear WG, The Discussion Phase of policy proposal 2023-01 "Reducing IXP IPv4 assignment default size to a /26" has now ended. Many thanks to all for your comments. The proposal will now move forward to the Review Phase. The RIPE NCC will prepare an impact analysis and a draft RIPE Document. More details about the phases of the Policy development Process are published here: https://www.ripe.net/publications/docs/ripe-781 You'll also see an announcement from the RIPE NCC soon. Kind regards, Leo Vegoda for the co-chairs

1 0

2023-02 Extended Review Phase (Minimum Size for IPv4 Temporary Assignments)
by Angela Dall'Ara 29 May '23

29 May '23

Dear colleagues, The policy proposal 2023-02, "Minimum Size for IPv4 Temporary Assignments" is now in the extended Review Phase in an updated version. Following up on the feedback received, the wording was simplified without changing the proposal content. This policy proposal recommends setting the minimum assignment size for IPv4 temporary assignments to a /24,while still allowing for a smaller assignment if requested by the End User. This policy proposal also allows routing requirements to justify the request for more than a /24 for research purposes. As per the RIPE Policy Development Process (PDP), the purpose of this Review Phase extension is to continue discussing the proposal taking the impact analysis into consideration, and to review the updated versionof the full draft RIPE Policy Document. At the end of the Review Phase, the Working Group (WG) Chairs will determine whether the WG has reached rough consensus. It is therefore important to provide your opinion, even if it is simply a restatement of your input from the previous phase. If you support this version of the proposal (v 2.0), please indicate that support with a simple message to the mailing list. If you have objections or would like a change, please provide that feedback to the mailing list. You can find the proposal and impact analysis at: _https://www.ripe.net/participate/policies/proposals/2023-02_ _https://www.ripe.net/participate/policies/proposals/2023-02#impact-analysi… And the draft document at: _https://www.ripe.net/participate/policies/proposals/2023-02/draft_ We encourage you to read the proposal, impact analysis and draft document and to send any comments to address-policy-wg(a)ripe.net before 29May 2023. Kind regards, Angela Dall'Ara Policy Officer RIPE NCC

3 2

2023-01 Extended Discussion Phase (Reducing IXP IPv4 assignment default size to a /26)
by Angela Dall'Ara 29 May '23

29 May '23

Dear colleagues, The policy proposal 2023-01, "Reducing IXP IPv4 assignment default size to a /26" is now in the extended Discussion Phase. This proposal modifies the default size of IPv4 assignments for IXPs from a /24 to /26 and clarifies the return of the assignments previously issued for their IXP peering LAN. The Discussion Phase has been extended as there was some support for the concept, but no feedback was sent on v 2.0. As per the RIPE Policy Development Process (PDP), the purpose of this five-week Discussion Phase is to discuss the proposal and provide feedback to the proposers. If you support this version of the proposal (v 2.0), please indicate that support with a simple message to the mailing list. If you have objections or would like a change, please provide that feedback to the mailing list. At the end of the Discussion Phase, the proposers, with the agreement of the WG Chairs, will decide how to proceed with the proposal. You can find the full proposal at: https://www.ripe.net/participate/policies/proposals/2023-01 <https://www.ripe.net/participate/policies/proposals/2023-01> 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 29 May 2023. Kind regards, Angela Dall'Ara Policy Officer RIPE NCC

7 6

IPv6 policy
by jordi.palet＠consulintel.es 24 May '23

24 May '23

As usual, I’m happy to take over the job of drafting a new policy proposal (I’ve already drafted something some months ago). I can do it alone or together with some other folks. (sorry was not able to join this morning, but just looked at the video) 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.

1 0

2023-02 Minimum Size for IPv4 Temporary Assignments
by Peter Hessler 19 May '23

19 May '23

I support this proposal. I initially was confused on the second clause of the new text for section 3.3, but it became clear when I read the entire context within the new proposal. -peter -- Weinberg's First Law: Progress is made on alternate Fridays.

1 0

Chair re-appointment - RIPE86
by Erik Bais 17 May '23

17 May '23

Dear Working group, As you might remember, the WG Chairs are appointed for a set term as that reminds us now and then, for both the WG Chair as the WG, to think about if we are still happy with the current chair setup. More insight on the terms can be found at the AP-WG page on the RIPE website: https://www.ripe.net/participate/ripe/wg/active-wg/ap This RIPE86, the first term of both James Kennedy and Leo Vegoda is done and both stated that they would be more than happy to do another term. As the co-Chair of AP-WG, I'm glad that both want to run again for the stability of the WG, however in the end it is up to the WG if you are as well. So during the AP-WG session, we will have time in the agenda to ask the WG if you like to proceed with the current WG Chair setup. If you to replace one or both WG Chairs, please let me know up front and I will contact you to ask a couple questions in regards of introduction .. and we will ask the WG if they would like a WG chair change. We like to hear in the WG if you like to support the current WG chairs (or not) ... this can be done by a reply on this email, or during the meeting. See you all next week in Rotterdam. Regards, Erik Bais Co-Chair AP-WG

2 1

Checking interest in the community for changing IPv4 assignments policy
by Jeroen Lauwers 17 May '23

17 May '23

Hi Everyone, Now RIPE 86 is around the corner Tore and I would like to check if there is any interest in changing the way of making assignments in the IPv4 policy. At this moment we got 3 major points coming repetitively back from the community. 1. The current policy asks for a lot of repetitive work in making these assignments and it would be nice if, with a policy change, a lot of this repetitive work could be taken away. 2. There is a lot of under and over-assigning in the RIPE DB where a policy change would be beneficial to take some of the reasons away for this. 3. Policy 6.3 “Network Infrastructure and End User Networks” can be interpreted differently for what the right use case is. Including the feedback from the previous policy proposal, we are thinking about introducing AGGREGATED-BY-LIR status just as in the IPv6 policy. In this way, we can aggregate multiple assignments into one AGGREGATED-BY-LIR assignment which we think would result in improving the above-mentioned points. We would like to check what the community thinks about this plan and if there is enough positive feedback we would like to make a concept proposal from it and present this at RIPE86. Kind regards, Jeroen

3 2

2023-01 - New Version Policy Proposal (Reducing IXP IPv4 assignment default size to a /26)
by Angela Dall'Ara 16 May '23

16 May '23

Dear colleagues, RIPE policy proposal 2023-01, "Reducing IXP IPv4 assignment default size to a /26" is now available for discussion again. The goal of this proposal is to reduce the default size of IPv4 assignments for IXPs from a /24 to /26 and clarifies the return of the assignments previously issued for their IXP peering LAN. Following the last round of discussion, this proposal has been updated and it is now at version 2.0. The main difference from version 1.0 is that IXPs are not required to implement the exchange of IPv4 routing information over IPv6 before requesting an assignment larger than a /24. You can find the full proposal at: https://www.ripe.net/participate/policies/proposals/2023-01 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 proposers, 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 We encourage you to review this proposal and send your comments to address-policy-wg(a)ripe.net before 4 April 2023. Kind regards, Angela Dall'Ara Policy Officer RIPE NCC

8 8

Draft Address Policy WG Agenda - RIPE 86
by James Kennedy 12 May '23

12 May '23

Dear Address Policy WG, This is the draft agenda for our sessions in Rotterdam at RIPE 86 later this month. If you would like to add a topic for discussion, please send us an email at apwg-chairs(a)ripe.net. Regards, James (on behalf of the co-chairs) Address Policy Working Group Wednesday, 24 May 10:30 - 11:30 (UTC+2) Chaired By: Erik Bais, James Kennedy, Leo Vegoda A. Introduction [5 mins] B. Chair Selection [5 mins] C. ASO AC Update [10 mins] D. Registry Services Update Followed by Q&A [15 minutes] E. Policy Update Followed by Q&A [15 mins] F. Concept: AGGREGATED-BY-LIR status for IPv4 PA assignments [10 mins] Wednesday, 24 May 11:00 - 12:00 (UTC+2) Chaired By: Erik Bais, James Kennedy, Leo Vegoda G. 2023-01: Reducing IXP IPv4 assignment default size to a /26 [15 mins] H. 2023-02: Minimum Size for IPv4 Temporary Assignments [15 mins] I. IPv6 Policy Review [25 mins] J. AOB [5 mins]

2 2

2023-02 - Review Phase Ended (Minimum Size for IPv4 Temporary Assignments)
by James Kennedy 07 May '23

07 May '23

Dear All, The Review Phase of policy proposal 2023-02 - Minimum Size for IPv4 Temporary Assignments - ended on 2nd May, 2023. https://www.ripe.net/participate/policies/proposals/2023-02 Taking into consideration the feedback received, the proposers will work on making the wording of their proposal clearer. The change will be purely editorial, the content will not be modified. The RIPE NCC will soon publish the new version of the proposal and the policy draft, and announce an extension of the Review Phase. Regards, James co-chair apwg

1 0

Fwd: Coop WG interim session on Wednesday, May 3rd 15:00-16:00 CEST
by Leo Vegoda 03 May '23

03 May '23

Dear Address Policy WG, Please review the pages linked in Desiree, Julf, and Achilleas's message below. Kind regards, Leo Vegoda, for the Address Policy WG co-chairs ---------- Forwarded message --------- From: Desiree Miloshevic <miloshevic(a)gmail.com> Date: Wed, 3 May 2023 at 02:37 Subject: Coop WG interim session on Wednesday, May 3rd 15:00-16:00 CEST To: <wg-chairs(a)ripe.net> Cc: Cooperation WG Chairs <cooperation-wg-chairs(a)ripe.net> Dear WG chairs Please find the announcement about Cooperation Working Group Small Task Team session today at 15:00 - 16:00 CEST. We would be grateful if you could share it with your working group members as well. https://www.ripe.net/participate/ripe/wg/active-wg/coop/interim-sessions/co… The announcement was sent to the mailing list as well. https://www.ripe.net/ripe/mail/archives/ripe-list/2023-March/002814.html Best Desiree, Julf, Achilleas -- Coop WG Co-Chairs

1 0

Call for presentations, Address Policy WG at RIPE86 (Rotterdam, The Netherlands)
by James Kennedy 01 May '23

01 May '23

Dear Address Policy WG, With RIPE86 fast approaching - 22 to 26 May, 2023 - we are busy arranging the agenda for the Address Policy Working Group sessions. https://ripe86.ripe.net/programme/meeting-plan/ Is there a topic or issue that you would like to bring to the attention of the working group? If so, please send us an email at apwg-chairs(a)ripe.net, stating: - the topic you would like to discuss and a short description - the expected duration of your presentation - if you intend on being onsite in Rotterdam or online Regards, James on behalf of the Address Policy WG co-chairs

1 0

2023-02 Review Phase (Minimum Size for IPv4 Temporary Assignments)
by Angela Dall'Ara 26 Apr '23

26 Apr '23

Dear colleagues, Policy proposal 2023-02, "Minimum Size for IPv4 Temporary Assignments", is now in the Review Phase. This policy proposal recommends setting the minimum assignment size for IPv4 temporary assignments to a /24,while still allowing for a smaller assignment if requested by the End User. This policy proposal also allows routing requirements to justify the request for more than a /24 for research purposes. The RIPE NCC has prepared an impact analysis on this proposal to support the community’s discussion. You can find the proposal and impact analysis at: _https://www.ripe.net/participate/policies/proposals/2023-02_ _https://www.ripe.net/participate/policies/proposals/2023-02#impact-analysi… And the draft documents at: _https://www.ripe.net/participate/policies/proposals/2023-02/draft_ As per the RIPE Policy Development Process (PDP), the purpose of this four-week Review Phase is to continue discussion of the proposal taking the impact analysis into consideration, and to review the full draft RIPE Policy Document. At the end of the Review Phase, the Working Group (WG) Chairs will determine whether the WG has reached rough consensus. It is therefore important to provide your opinion, even if it is simply a restatement of your input from the previous phase. We encourage you to read the proposal, impact analysis and draft document and to send any comments to address-policy-wg(a)ripe.net before 2 May 2023. Kind regards, Angela Dall'Ara Policy Officer RIPE NCC

5 4

IPv6 policy - 2nd prioritisation and outcomes discussion webinar
by Leo Vegoda 11 Apr '23

11 Apr '23

At RIPE 85 we continued a review of the IPv6 policy that began at RIPE 83. Several areas for improvement were agreed. We promised to host an inter-sessional webinar to discuss priorities and the outcomes to work towards. We held the first webinar on Monday, 20 February 2023. You can read a summary of what was discussed on RIPE Labs. A full recording and minutes are published on the interim sessions page. - https://labs.ripe.net/author/leo_vegoda/next-steps-in-ipv6-policy-work/ - https://www.ripe.net/participate/ripe/wg/active-wg/ap/interim-sessions The second webinar will take place on Tuesday, 11 April at 13:30 UTC (15:30 CEST). If you want to help us set priorities and define the outcomes the community needs you are welcome to join. Join Zoom Meeting https://ripe.zoom.us/j/93730573273?pwd=eWJ1WEEzSzVSSEJNKy9JeXk0L3RqZz09 Leo Vegoda for the Address Policy WG co-chairs

2 1

RIR Policy Proposal overview
by Sander Steffann 08 Apr '23

08 Apr '23

Hi everybody, I created a quick overview page of all the policy proposals in the different RIRs: https://proposals.nogalliance.org/ Hope you find this useful! Cheers! Sander

1 0

2023-02 New Policy Proposal (Minimum Size for IPv4 Temporary Assignments)
by Angela Dall'Ara 07 Apr '23

07 Apr '23

Dear colleagues, A new RIPE Policy Proposal, 2023-02, "Minimum Size for IPv4 Temporary Assignments" is now available for discussion. This policy proposal recommends setting the minimum assignment size for temporary assignments to a /24 while still allowing for a smaller assignment if requested by the End User. This policy proposal also allows routing requirements to justify the request for more than a /24 for research purposes. You can find the full proposal at: https://www.ripe.net/participate/policies/proposals/2023-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 proposers. At the end of the Discussion Phase, the proposers, 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 We encourage you to review this proposal and send your comments to address-policy-wg(a)ripe.net before 10 March 2023. Kind regards, Angela Dall'Ara Policy Officer RIPE NCC

7 7

IPv6 PI /46 Assignment Request Experience Summary
by Tobias Fiebig 06 Apr '23

06 Apr '23

Heho, I just had an interesting thread with the RIPE NCC when applying for an ASN and IPv6 /46 PI. Given the upcoming discussion on the 11th, some people suggested it might be interesting to describe the process on the list. Please excuse the length. I tried to be short, but there is a bit of context i believe should be included. With best regards, Tobias # Background ## About me For those who do not know me, I am Tobias, in my day-job I am a somewhat network measurement, somewhat security, somewhat humans researcher at the MPI-INF. In my spare time, i push a few packets around the Internet. I am currently speaking for myself/as de.wybt, and not my affiliation/MPI. ## Measurement.Network I am currently trying to build a 'measurement AS', i.e., an AS that is solely dedicated to network measurements, providing that service to academics, but also adding on some additional support. Specifically, the idea (briefly) is to: - Esp. support things going beyond SYN/Banner scanns; Did a lot of mail stuff in the past, for example, where it is easier to make mistakes. - Have a well-known AS/v4+v6 prefix dedicated to the network to make blocking easier, esp. as some researchers use public cloud infra for measurements, which are hard to block (as real services may be on those addr a week later) - Keep blocking collateral away from university/researchers' own institutions' networks - Do probe attribution, abuse handling, and opt-out correctly - Provide support/review of tools, going beyond 'academic ethics review' (there were some cases were people released harmfull tools due to their limited experience with the protocols they measured; and new PhDs students usually don't have 20 years of industry experience ;-)) - Make such infra more accessible; Some university IT departments can be a little anxious when you want to do active measurements My current plan is to get this built and running, and then see if some parts of the community would be willing to adopt it (and its governance); Usually easier to ask for support when you have something working to show for. ;-) The idea is to have at least two PoPs with dedicated routing policies to also move DNS and mail 100% into the AS (block one thing, see no packets of any kind). Additionally, a further /23 allows for anycast experiments or tests using more/less specifics, without interfering with the infrastructure/static measurement networks. For the purpose of setting this up, MPI borrowed me a /22 v4. This left me with needing an ASN and an IPv6 prefix, the latter ideally being at least a /46 to be able to exactly mirror whatever policy might be on the /22. # Requests to the NCC Based on the above, I requested a 32bit ASN and a /46 PI from the NCC. Assignment of the ASN commenced after some in-depth discussion on policy provisions and how they apply to legacy space; After fulfilling the requirement that LEGACY spaceh should have INETNUM for the same org as the ORG holding an ASN (independent of MNT-ROUTE), the ASN was issued, even though I could not find this requirement in the applicable policy documents. The discussion around a PI assignment was, however, less successful. ## Reasoning for PI (7.2): - This is an independent project from the main activities of the main ASN of the LIR and should ultimately be upstreamed independent of AS59645. For now, while setting up, upstream would be provided by AS59645 and AS41051. - The assignment should not overlap with the existing PA of the LIR to ensure that the PA is not affected by potential blocking activity - The project, when established, would qualify for interconnection the main networks of the LIR do not necessarily qualify for, i.e., again necessitate a different routing policy. ## Reasoning for a /46 - The nature of the project needs it to be able to mirror any routing policy set for the v4 /22 to be able to leverage this network for measurements to its full extend based on requested experiments, ranging from experiments using more/less specifics or anycast experiments. (routing needs) - There are at least two PoPs which are to be hosting services necessitating distinct routing policies (DNS prim/sec, mail prim/sec), even though there is L2 transport for iBGP between the PoPs. Even though upstreams overlap between the PoPs, upstreams also have diverging routing policies for both PoPs. (routing need) ## Additional reasoning in line with general goals (3.) - To prevent renumbering and overhead if the project would reach a state that allows it to enter community governance, resources should be independent of the LIR, i.e., transferable (3.7). - As the routing policy of the /22 v4 should be mirrored, more than a /46 is not necessary (3.5), a /46 allows for aggregation (3.4) under changing policy, i.e., when no experiments are running that require all four sub-networks in different policies, and an aggregatable prefix is needed to be able to run experiments with overlapping prefixes, e.g., investigate how well more specifics are honored given some anecdotes that they might not _always_ win). # Discussion with the NCC ## First exchange In the first reply, the NCC requested a full documentation of the intended modus operandi of measurement.network, likely aiming at identifying whether use of addresses would technically constitute sub-allocations to researchers, barring the use of PI. Additionally, the NCC noted that additional reasoning for PI has to be provided given existing PA. The NCC noted, after just having had initially denied the request for an ASN to announce the v4 /22, that the /22 or any more specifics are not in the DFZ, and hence requested documentation of AS59645's current routing policy and how it would differ for the requested PI. ### Reply In reply, I provided a full documentation of the proposed goals and modus operandi as well as the intended governance structure of measurement.network. Furthermore, I detailed the reasoning following 7.2 as outlined above. ## Second exchange After informing me of needing some time to deliberate, the NCC came back and requested information on what 'network measurements' are, which subnet sizes would be used for measurements, and the legal status of any potential 'review board' of the project prior to it moving to not-only-me-is-responsible-governance, likely to ascertain whether there should be another entity listed as an ORG. Additionally, the NCC mentioned that more specific INET(6)NUM objects cannot be created for PI (see also my recent post on the db-wg ML). Instead, the NCC suggested i could do this with an allocation. ### Reply In reply, i defined network measurements and provided examples via my recent publications, clarified that, for now, i would be solely responsible in a legal sense, explained subnet sizes planned to be used, detailed various experiments needing unique routing policies stretching over a /46, and documented why technically, more specific INET6NUM are covered by policy as long as they use the same ORG object, but simply are not supported by the DB. Additionally, i asked whether their reference to PA suggested that they propose to apply RIPE-738 5.2.1. b), i.e., the justification of a new allocation due to new needs arising from this project, specifically, as per RIPE-738 5.1.2, the segmentation of infrastructure for security reasons, more specifically, the blocking and security implications of measurement infrastructure. Even though i noted that I'd be happy to receive an additional non-adjacent allocation to my existing PA, I also noted that a /46 PI would satisfy the unique routing requirementes we seemed to have converged on at this point, as it aligns closer to 3.5 of the policy (address space conservation). ## Third exchange A day later, the NCC came back, first addressing my question regarding their suggestion around PA by referencing the general page on assessment criteria for IPv6 allocations, and noting that a /29 holds 524 thousand /48. The NCC also agreed on my point concerning more specific INET(6)NUM objects, but noted that this is not supported by the DB. Next, the NCC came back to highlighting unique routing requirements, noting that announcements would take place in the same physical locations as AS59645 is present in, and hence again questioned unique routing requirements. Furthermore, the NCC noted that i mentioned that both sites are connected via L2, making Duesseldorf and Berlin essentially one end-site. This means that they could only issue one /48 unless i can demonstrate unique routing requirements for each site; The NCC also states that "The minimum size of the assignment is a /48.", which is interpreted as to mean that '[f]ollowing the policy, [the NCC] can only issue larger assignments to sites where there is a need to use more than 65536 of /64 subnets. However, multiple /48 assignments can be issued to multiple distinct sites.' Hence, as even when qualifying for more than one /48, i would receive multiple non-contiguous prefixes, the NCC concludes, that this means that 'it [is] impossible to achieve traffic advertisement using more and less specific prefixes (as [the NCC] understand[s] you need to use for the measurements) while using IPv6 PI space' ### Reply In reply, i first referred back to the second message in the ticket, where i detailed the different upstream and pering interconnections the project would qualify for, despite the announcements happening from the same physical locations, i.e., measurement.networking being topologically different. Next, i first state that 'minimum size of the assignment' prevents a /49, but not--as implied--a /47. Next, i challenge the point that addressing needs (number of devices to address) is the only justification for less specific assignments, referring to 5.4.2 of the policy, which clearly stats that exceeding the size of a single /48, either via multiple /48 or a shorter prefix, requires that it: a) must be based on address usage OR b) because different routing requirements exist Subsequently, i also note that the policy does not distinguish between assigning more than a single /48 to an end-site and assigning a less specific prefix, as it reads "Assignments larger than a /48 [shorter prefix] or additional assignments exceeding a total of a /48..." Before concluding, i again reference the NCCs statement that PI could not meet my routing requirements, asking whether their statements means that they acknowledge that my unique routing requirements could be satisfied by assigning a /46, but not by assigning a /48. I conclude the reply by summarizing my core points: - I read the NCCs statements regarding impossibility of fulfillign my routing requirements as acknowledging the existence of unique routing requirements. - The NCC proposes multiple /48 instead of a /46, claiming the former to be in-policy and the latter not, while the policy does not distinguish the two cases (or connected). - Noting that given 3.8 and thereon 3.4 of the policy, a single /46 will be more compliant than multiple /48, thereby making multiple /48 essentially incompliant. Finally, i note that i find it challenging to see how the NCC applies policy, especially given they cite policy incomplete and make proposals essentially less compliant than the (in my opinion in-policy) initial request. Hence, I ask whether they could point to where the policy supports their interpretation, or if they believe the case to be so unclear that it should be discussed with the wg. ## Fourth exchange Three days later, the NCC came back, claiming that 5.4.2 of the policy only "covers cases when [a] single End-site need[s] a larger prefix due to "address usage" which in this case is measured in terms of subnets. Subnet size in IPv6 is fixed at /64." Furthermore, they reiterate that this only means multiple assignements can be requested and approved under the policy. The NCC also reiterates that, due to the L2 connection, only one /48 can be issued, and i only informed the NCC about one routing policy. The NCC also repeats that, even if there were multiple locations, only multiple /48 could be assigned, not referring to policy at all. ### Reply In reply, i highlgihted again that the NCC makes claims not covered by policy, specifically, there being a difference between multiple non-adjacent more specifics vs. a less specific of the same aggregate size (barring the aggregation principle outlined in 3.8, which should be the highest priority goal in all interpretations of the policy, according to the policy, essentially prioritizing a single less specific over multiple more specifics). I also reiterate that 5.4.2 does not require multiple locations for routing requirements to be in place. I conclude by reiterating that the NCC acknowledged my unique routing requirements use case, given it sees it as a routing setup not possible with a single /48; Note that--as the NCC considers DUS and BER to be one site--5.4.2 certainly applies, which also means that the same requirements hold for assigning multiple /48 instead of a shorter prefix (aggain, barring 3.8). I close with the question why the NCC--given it considers multiple /48 feasible--refuses to apply policy (unique routing requirements and a single prefix shorter than /48 to satisfy these). ## Resolution At this point, the process had been going for nearly two weeks. While typing up the last reply to the NCC around 4pm, I acquired a /32 IPv6 PA and had the offering party initiate a transfer. The next morning, I received a reply from the NCC telling me that they would come back to me regarding my prior reply to the PI request. When the transfer of the /32 was completed a few hours later, I informed the NCC that the issue had been resolved and I would no longer need a dedicated assignment. So far, the ticket has not been closed, but i expect this to happen shortly. # Relevant discussion points Given how the process went, I see some points relevant to the ongoing discussion. ## Interpretation of policy by the NCC I believe that my reading of the policy has been outlined sufficiently above. I see that one may disagree on matters of how policy may be read. What, however, concerns me a bit is that the NCC provided incomplete citations of the policy in multiple instances throughout the ticket, where the omitted parts no longer supported the position of the NCC. Furthermore, i find the very fundamental adherence to, even multiple, /48 assignements in place of a smaller prefix/larger assignment size odd given 3.4 and 3.7 of the policy, especially considering the statement in 3.8 of the policy that makes it very clear that "In IPv6 address policy, the goal of aggregation is considered to be the most important." ## 3.5-3.7 of RIPE-738 Given the standard reservation sizes for v6 PI, as well as the ultimate solution for the issue I encountered, I am not sure whether either multiple /48 or the path I now ultimately took to reduce overhead for me is ideal; However, obtaining a larger prefix than needed (due to the minimum size of PA, i.e., /32 instead of /46), and doing so in less than 24h, in contrast to a nearly two week (unsuccesful) request with the NCC feels odd. I am also not to sure whether 3.6 is sufficiently covered here. As it is indeed significantly easier for LIRs to obtain PA of at least /32, than it is for end-users to even obtain a /47. Looking at this cynicaly, one might argue that undertaking/building/contributing a project like the one I am building is hardly possible for end-users that are not LIRs, even though I'd also argue that projects like this are very much what PI is for. Being an LIR making this easier, at least to me, pretty much feels like an "other factor", as described in 3.6. -- Dr.-Ing. Tobias Fiebig T +31 616 80 98 99 M tobias(a)fiebig.nl

1 0

Re: [address-policy-wg] New Policy Proposal for Voluntary Transfer Lock
by Михайло Кононихін 08 Mar '23

08 Mar '23

Hello I hope the new 'Voluntary Transfer Lock' does not require a notarized statement as 'Voluntary Registry Lock' It should be a fast working tool. And it should freeze all current transfer requests

3 2

2023-01 New Policy Proposal (Reducing IXP IPv4 assignment default size to a /26)
by Angela Dall'Ara 17 Feb '23

17 Feb '23

Dear colleagues, A new RIPE Policy Proposal, 2023-01, "Reducing IXP IPv4 assignment default size to a /26" is now available for discussion. The goal of this proposal is to extend the lifetime of the IXP IPv4 address pool and to motivate IXPs to implement the exchange of IPv4 routing information over IPv6. You can find the full proposal at: https://www.ripe.net/participate/policies/proposals/2023-01 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 We encourage you to review this proposal and send your comments to address-policy-wg(a)ripe.net before 7 February 2023. Kind regards, Angela Dall'Ara Policy Officer RIPE NCC

15 28

IPv6 policy - prioritisation and outcomes discussion webinar
by Leo Vegoda 15 Feb '23

15 Feb '23

At RIPE 85 we continued a review of the IPv6 policy that began at RIPE 83. Several areas for improvement were agreed. We promised to host an inter-sessional webinar to discuss priorities and the outcomes to work towards. The identified areas for improvement include: - Better guidance on documentation requirements for large allocations - Simpler language for the HD-ratio - Make it easier for small networks to assign a few addresses to other organisations - Ensure allocations always fall on a nibble boundary If you wants to help us set priorities and define the outcomes the community needs you are welcome to join. Monday, 20 February 2023 at 13:00 UTC (14:00 CET). Join Zoom Meeting https://ripe.zoom.us/j/94307989734?pwd=YytnQm53SjJEWUtKemxQM3dGcjZmQT09 Meeting ID: 943 0798 9734 Passcode: 339420 Leo Vegoda for the Address Policy WG co-chairs

1 1

End of Discussion Phase for 2023-01 (Reducing IXP IPv4 assignment default size to a /26)
by James Kennedy 09 Feb '23

09 Feb '23

Dear WG, The Discussion Phase of policy proposal 2023-01 "Reducing IXP IPv4 assignment default size to a /26" has now ended. Many thanks to all for your comments. Taking into consideration the community feedback, the proposers have drafted a new version of the proposal. The RIPE NCC will soon publish the new version on the mailing list and kick-off a new Discussion Phase as per the PDP: https://www.ripe.net/publications/docs/ripe-781. Regards, James

1 0

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

30 Nov '22

Dear colleagues, The policy proposal 2022-02, "Remove mandatory IPv4 PA assignment registration in the RIPE Database” has been withdrawn. The goal of this proposal was to change the registration of IPv4 assignments from mandatory to optional. The proposal is archived and can be found at: https://www.ripe.net/participate/policies/archived-policy-proposals/archive… Reason for withdrawal: The proposer decided to withdraw this proposal, feeling that a new proposal would be more suitable for including the suggestions and feedback provided by the community during the discussion phase. Kind regards, Angela Dall'Ara Policy Officer RIPE NCC

1 0

Draft Address Policy WG Minutes from RIPE 85
by Leo Vegoda 28 Nov '22

28 Nov '22

Dear WG, The RIPE NCC has now prepared draft minutes of our session at RIPE 85. Please write to this list or inform the co-chairs of any issues or corrections. Kind regards, Leo Vegoda for the Address Policy WG co-chairs RIPE 85 Address Policy WG Minutes Wednesday, 26 October 2022, 09:00-10:00 UTC+1 Chairs: Erik Bais, James Kennedy, Leo Vegoda Scribe: Antony Gollan Status: Draft A. Introduction The presentation is available at: https://ripe85.ripe.net/wp-content/uploads/presentations/64-RIPE-85-Address… The video is available at: https://ripe85.ripe.net/archives/video/898/ There were no changes to the agenda. The minutes from RIPE 84 were approved without changes. B. ASO AC Update James Kennedy, ASO AC The presentation is available at: https://ripe85.ripe.net/wp-content/uploads/presentations/72-ASO-AC-Report-R… The video is available at: https://ripe85.ripe.net/archives/video/901/ James Kennedy gave an update from the ASO AC. Kevin Blumberg from the ARIN region was their new Chair. Kevin had appointed Mike Silber (AFRINIC) and Herve Clement (RIPE) as Vice Chairs. There were no questions. C. Policy Update Followed by Q&A Angela Dall'Ara, RIPE NCC The presentation is available at: https://ripe85.ripe.net/wp-content/uploads/presentations/59-RIPE-85-Current… The video is available at: https://ripe85.ripe.net/archives/video/902/ Angela ran through open policies in the five RIR service regions. In the RIPE region, there were two: 2022-01: Personal Data in the RIPE Database (Database WG) and 2022-02: Remove mandatory IPv4 PA assignment registration in the RIPE Database (Address Policy WG). Jordi Palet Martinez (online), Moremar, noted all of the APNIC proposals would get a new version soon. D. (2022-02) Remove Mandatory IPv4 PA Assignment Registration in the RIPE Database James Kennedy, Address Policy WG co-chair The presentation is available at: https://ripe85.ripe.net/wp-content/uploads/presentations/73-2022-02.pdf The video is available at: https://ripe85.ripe.net/archives/video/905/ James said that the proposer (Jeroen Lauwers) could not be at the meeting and so he would run through the proposal quickly for him. He added that he would be recusing himself as WG co-chair from determining consensus on this proposal. James’s interpretation of the intent of the policy was that it sought to allow LIRs to document only information in the RIPE Database that was needed for operational and administrative purposes, and to reduce workload by not forcing them to maintain duplicate data. Sander Steffann, 6connect, said he agreed that everything visible externally should be documented in the RIPE Database. That was an absolute minimum. However, he thought they already had this – if it was externally visible there would be a ROUTE object, in which case there would have to be an INETNUM object it pointed to. Erik Bais, Address Policy WG co-chair, said for the allocation there was not. Sander said then he would definitely put that in as a minimum requirement. For the rest, it was a contact database – so that if something went wrong, people could see who to contact and who was responsible. If the LIR was willingly taking responsibility to be the contact for all its customers, that was a business decision, and they should allow for that. Kurt Kayser (online), speaking on his own behalf, asked if the logic was correct that routed = used, and that it if was not assigned, it was not shown as used. Erik said this played into the comment from Sander. When were they going to say the address space was in use? Was it when there was a valid ROUTE object or when there was a valid assignment? James said, on that point, maybe the ROUTE object was created before being used. But a quarter of all allocations was an interesting number. Elvis Daniel Velea (online), v6escrow, said he supported the intent of the proposal. Assignments should only be registered if required by the End User or if the LIR wanted to delegate some administrative/abuse/routing decisions. Peter Koch, DENIC, said he had been a member of the RIPE Database Requirements Task Force. The TF report made a distinction between the RIPE Database and the RIPE Registry. He thought the differences and commonalities here weren’t reflected in the proposal in a way that would help with making a decision. Further, while the author pointed towards the TF report and its recommendations, he didn’t think the proposal reflected the corresponding recommendation. That was fine, because it didn’t have to, but he wanted to avoid the impression that this was a proposal to implement what the TF recommended. It did make a recommendation on the assignments, following the observation of an asymmetry in terms of depth and volume of usage by various LIRs and, as someone had said on the mailing list, maybe a policy wasn’t the way to change that. Peter made a further observation. The RIPE Chair Team had, after consultation and with the community’s support, offered clarification to the PDP. That clarification had strongly suggested that policy proposals should be the result of in-depth discussion. This proposal seemed to come out of the blue, and so he would urge the chairs to think about their gatekeeping and steering function. Finally, Peter didn’t think this proposal was getting anywhere. Unfortunately, the PDP’s was biased towards stumbling forward, and so he would suggest putting an end to the proposal and considering the problems identified in the subsequent discussion. Erik noted that the intent for creating the proposal was discussed at RIPE 84 in Berlin and the proposal was only created later. Peter said that since Berlin there had been little discussion on the list that would support the general direction of the proposal and the problem statement that needed to be fixed. A couple of people had mentioned their own surprise at seeing the proposal and two or three had said it did not seem to be addressing the problem it sought to fix. James said he thought the proposer had tried to get as much feedback as possible at RIPE 84, but he took Erik’s point that it could have been progressed further on the mailing list. James added that he had been on the Database Requirements TF with Peter and their recommendation had inspired this proposal, but it was definitely not one-to-one. Brian Storey (online), Gamma, asked if the intent of the proposal was to no longer require the registration of any downstream End User PA assignments. James said he could only give his own interpretation. The current policy text said that for any assignments it should be optional. But from the feedback Jeroen had received over the past few weeks, and from his discussions with him, he was taking that into account. So, the intent seemed to have changed since then. Erik said as chairs they had looked at all the comments on the mailing list. If this was moving forward, they would need to have a discussion with Jeroen about whether it was for all assignments or just for the resource holder of the allocation, which would probably make more sense. Kurt said he would split the main purpose of the documentation between customer data (mainly assignments) and network operator related data (such as abuse-c and admin-c). RIPE NCC needed both datasets before but now the (very sensitive GDPR-Data) purposes may allow a different handling. Erik said this was not a GDPR topic. Yes, they were trying to minimise the duplication of data. If the assignments were the same information as the resource holder, then they shouldn’t need to duplicate it. But if you were adding different information with different parties and contacts, then that should still be in the database. At least that was how he read it. Erik and James encouraged people to share their opinions on the mailing list. E. Registry Services Update Followed by Q&A Marco Schmidt, RIPE NCC The presentation is available at: https://ripe85.ripe.net/wp-content/uploads/presentations/66-RIPE85-Feeback-… The recording is available at: https://ripe85.ripe.net/archives/video/907/ Marco gave an update from the RIPE NCC’s Registry Services Department. He had three topics he wanted feedback on: 1. IPv4 Waiting List: they now had about 1,050 LIRs on the waiting list and the estimated wait time was now about two years. There were still multiple-LIRs being created, which disadvantaged newcomers. He asked if the WG wanted to accept this or if they should try to fix it. 2. IPv4 IXP Pool: the addition of a further /16 to the pool for IPv4 IXP assignments had drastically extended its lifetime. They expected this pool to become empty around 2029. He asked if that was enough. 3. Assignment Definition: the policy referred to assignments made to ‘downstream networks’ but later referred to ‘End Users’. He asked if these terms needed further definition by the WG. Shane Kerr, NS1, responded to the question about the IXP pool. This policy had been created so that IXPs wouldn’t have to go to an LIR. Now that they were out of space, he asked why they wouldn’t buy address space like anyone else. Marco said he thought this was about seeing IXPs as critical infrastructure. Shane said everyone thought their own infrastructure was critical. Sander said he’d been around since the beginning of the run-out policies. The fact that they still had some IPv4, even with a waiting list of two years, was an achievement which meant their policies had worked well. By now, they had extended this for so many years and given people many opportunities, but at a certain point they needed to say that they had properly arranged the deck chairs on the Titanic. Regarding IXPs, Sander thought they did have an important role and they should keep a separate pool for that. Maybe they could have a policy that used some of the recovered IPv4 space to top up the pool when it reached a certain level. He suggested they try a proposal that would allow the RIPE NCC to manage this without an intervention from the WG every time. Erik said they would need input from the Connect WG on this policy, and how it saw the prospect of this pool running out in seven years. Sander said he would attend the Connect WG session later that day and raise the topic there. Regarding the definition of assignments, Sander said he could vaguely remember this being discussed a long time ago; they had tried to keep it vague since there were many ways of providing a service to a customer. They had intentionally avoided going into what that service could be, as they would be stuck chasing reality. They did put in that there had to be some relation, and so he thought the RIPE NCC could be a bit stricter, but that would require a very long policy process to define what that meant. Elvis (online), suggested they not get into the leasing discussion. Since forever, LIRs in the RIPE region had assigned either PA or PI to connecting customers or customers that offered all kind of services and the colors of the IPs hadn’t really mattered. Denis Walker, Database WG co-chair, said he had a comment on leasing. What they had now was a situation where someone with spare address space was asking third-party companies to lease it out on their behalf, which might go to an LIR that saw it more as an allocation and assigned it to an End User. None of this could be reflected in the RIPE Database, because this whole structure that was hidden from view. If they were going to allow leasing, they should document it properly. Riccardo Gori, IP4WISP, wanted to go into the definition of LIR. He interpreted this as ‘Local Internet Registry’ in the same way as an RIR was a regional registry. He didn’t find a strict relation between the LIR and the services that were operated. Often the resources were associated to access offered by an operator to an Internet Service Provider or in a data centre. So, he didn’t see much need to go deeper into the definition of an LIR because it should reflect the fact that, as the comment before said, it should give the right description in the RIPE Database where the resources were being used and who was using them. If this was consistent and correct, then in his opinion it was done. End of first session. F. IPv6 Policy Goals - Review Process (Community Input Sought) [15 minutes] Leo Vegoda, Address Policy WG co-chair The presentation is available at: https://ripe85.ripe.net/wp-content/uploads/presentations/81-IPv6_at_RIPE-85… The recording is available at: https://ripe85.ripe.net/archives/video/910/ Leo noted that they’d started a discussion at RIPE 84 to look at the goals of the IPv6 policy, which hadn’t been reviewed for many years. He asked if they wanted to adjust the policy goals, change their order of priority, or introduce new ones. Erik said there had been a lot of updates on this topic since RIPE 84. That didn’t mean that the issues raised were gone. He’d also had a discussion with a Dutch ISP that had quite some issues, because they actually planned to do IPv6 with /48s to their customers, but instead they had to refer back to /56s because they couldn’t get the documentation within a reasonable time period. This meant they had to move ahead with a /29 instead of a /25 or /27. Sander said he was part of the group that discussed all these IPv6 changes and the main thing was a steep jump in requirements and in terms of documentation they needed a full-sized novel. He asked if the RIPE NCC was still reserving three bits of adjacent address space for future growth. Marco confirmed that they were. Sander said he had heard concerns from organisations that they would have to come back and get de-aggregated blocks when they needed to grow later. So this might help to address some of their concerns. This wasn’t in the policy and was an implementation detail – so maybe to alleviate some of this stress the RIPE NCC could make this a bit more official and tell people that they had a reservation for when they came back in the future. Marco confirmed that they could extend all the way to a /26. Erik said this meant they could take a gradual approach and they could grow into their space. Sander said there was a three-bit reservation. There was an issue with older allocations, as they would be able to extend from a /32 to a /29 as opposed to others who could grow from a /29 to a /27. There might also be the issue of LIRs who opted for a /32 rather than a /29 and unknowingly limited themselves in the future. Leo asked what kind of planning horizon was reasonable from the perspective of a network operator in terms of growing to a larger allocation. He also asked to hear from the RIPE NCC, as they were the ones who would have to go back to IANA if they needed more address space. Sander said currently there was no official planning horizon and the implementation detail was that there was a planning horizon of three bits – so someone could grow up to eight times as large. He didn’t want to micromanage the RIPE NCC – maybe they needed to put this in policy or maybe they just needed to inform people what the current operational procedure of the RIPE NCC was. Erik said maybe the LIR could have some kind of first right of refusal – so they could give the RIPE NCC notice that they were intending to grow in the next three to five years so that the additional bits were not consumed. This could be a lightweight way to do it. Sander asked if this was more of an informational hint rather than a guarantee. Erik said they would still need to do the documentation part. Sander said his first preference would be to round allocation sizes to nibble boundaries. Erik said they couldn’t always, especially if they were running out and would have to go back to IANA and ask for additional allocations – IANA would ask why. Leo said, from memory, one of the things in the global policy was that reservations were considered use. But that didn’t mean they shouldn’t manage things responsibly. Marco Schmidt, RIPE NCC, said he wanted to confirm for the record that they reserved an additional three bits for every IPv6 allocation. This meant someone with a /29 had a reservation up to a /26, for a /26 up to a /23 and so on. There were a few exceptions, for example historical allocations of a /32 that were extended to a /29 and couldn’t go further, and sometimes those who transferred their allocations were unable to extend, but that was just a sidenote. This approach had been used for a long time and it worked well. They could do more to make sure that people were aware. They did things on a case-by-case basis and sometimes would tell people that they might start with a /29 so they could expand later if they needed to. They could do this in a more consistent and formal way. They weren’t too concerned about going back to IANA – the /12s they currently received lasted for a long time. Tina Morris, AWS, said nibble boundaries shouldn’t be such a concern. They were using 3% globally of what had been assigned and it was ridiculous to get these micro allocations when the whole point of IPv6 was to make things easier. When you assigned just part of a block, the entire network planning was messed up – internally you could no longer use nibble boundaries, could no longer make a good organisational plan for your network. The whole point of IPv6 was to make things easier, better, implementable, and if they didn’t make things workable for organisations, then they were blocking the growth of IPv6 networks. Elvis said the RIPE NCC already reserved three bits for larger blocks and so he wondered why they were even having this discussion. The way the RIPE NCC used the sparse allocation mechanism allowed allocations to grow further. Kurt said he would turn it around and define a nibble-boundary routing-obligation to support small IPv6 routing tables. He hated fragmentation and deaggregation. Erik said this came back to the goals of the policy. Obviously, they still thought that deaggregation wasn’t something they could fix in the policy. They encouraged everyone to use BCPs and not announce all their /48s. But if you looked at the IPv6 routing tables, it was 48% /48s at this point. Sander asked if there was interest in him drafting a policy proposal to realign the policies with nibble boundaries. That would mean changing a /29 to a /28 and asking the RIPE NCC to reserve four bits to align it with the /24. Maybe it was time to be more ambitious than to tweak this one bit at a time. He asked for a show of hands [but only saw a couple of hands]. He said he would discuss further with the chairs to see if there was support. Erik said on the next video call that they would have on IPv6 they would invite Sander and Gert to provide additional feedback. They would also invite people from the RIPE NCC to explain what their current operation was and where they stumbled on the current policy, before they made any changes. Daniel Karrenberg, Internet geek, asked why maintaining a low number of prefixes was suddenly such a big problem. They had managed a much bigger number in IPv4. Erik said it was the fact that IPv6 prefixes were longer, and if you started announcing every /29 in /48s, you got an explosion in the routing table, so that’s why aggregation was a topic. Mirjam Kühne, RIPE Chair, said she was happy to see the enthusiasm. She was going to suggest they discuss this on the list before creating a proposal, but she noted that Erik seemed to be suggesting this with the interim call. Erik agreed. Leo said he thought this had been a useful discussion. Before leaping towards a specific thing with nibble boundaries, he thought it would be good to base this in the policy goals. If they could get clear on that, it would help any discussions on the specifics to be more productive, as they would know what they were trying to achieve. Erik said that sounded reasonable. G. Temporary IPv4 Assignments - Minimum Assignment Size Leo Vegoda, Address Policy WG co-chair The video is available at: https://ripe85.ripe.net/archives/video/913/ Leo gave a brief summary of the topic. The RIPE NCC got requests for temporary allocations for academic and research experiments that often only needed a very small number of IPv4 addresses. The policy said that justification was required for experiments in the same way as anything else – meaning that if you were unable to justify 128 addresses or more, you did not get a /24. The question was whether they needed a minimum allocation size for experiments, and whether this should apply only to academic or research assignments, or if it needed to be a more general thing – because if you needed to use an assignment it had to be a /24. Elvis (online) said /24 should be the minimum size for temporary assignments, as it was unusable otherwise. Erik asked if they needed to limit this to research or if it should be for more general use. His personal feeling was that it shouldn’t be limited to specific research as the IPv4 policy had a minimum size for allocations and the policies should align. He said they would take this back to the mailing list. Edwin Verheul, SURF, said they liked that the RIPE NCC provided temporary assignments – they used them for events and were happy with that. One issue was geolocation. He wondered if certain /24s could be limited to certain countries or regions so they didn’t run into limitations in that department. Erik said geolocation was going to be an issue when they ran into leasing or temporary assignments. There might be an option where the RIPE NCC could provide a geofeed. This could feed into the IP databases that were doing geolocation. Otherwise, you could extend the time that the addresses were in use – it typically took 6-8 weeks before geolocation databases were updated unless you were willing to do the legwork. Marco said he was happy to hear the suggestion that they have a minimum assignment size and he would like to see this discussed further on the mailing list. For the RIPE NCC it was a pain point and everyone thought it should change. Erik said he would try to find someone to create a proposal. Kurt asked if there was any usability guarantee after getting the space back (getting it removed from spam blocklists and so on). Marco said they did pick address space randomly and allowed a certain quarantine time, but they didn’t check how ‘tainted’ the address space was. They tried to give space that was as clean as possible and he might contact Kurt to hear feedback on how his experience was. Radu-Adrian Feurdean, FranceIX, asked if they should plan to gradually phase out temporary allocations. Surely the message should be that IPv4 was over and IPv6 was the way. Elvis volunteered to author the temporary assignment policy proposal. H. AOB/Open Mic The video is available at: https://ripe85.ripe.net/archives/video/914/ Sander said there was a message on one of the RIPE mailing lists from Hans Petter Holen about Ukraine. This was about protecting the resources of Ukrainian members from being transferred at gunpoint. They had talked about this in Berlin, but it still seemed to be going on. In his response to the Ukrainian Government, Hans Petter had suggested they raise this in the Address Policy WG. He didn’t think protecting members’ resources was a policy issue, but he was interested to hear from the WG. Erik said the WG chairs had discussed this issue. It wasn’t unique to Ukraine, whatever they came up with should apply to other areas, such as Palestine, Syria and so on. He added that there had been a suggestion that people have some kind of ability to lock their resources in the LIR Portal. Some kind of country-specific transfer lock was not something he would envision. When looking at art [as a parallel example], this was often stolen in war. What happened was that the owners went to the court after the war and got their property back that way. His personal thinking was that they should focus more on the appeals side rather than finding a policy solution. Max Tulyev, NetAssist, agreed that it should not be handled through policy. He agreed it would be good to have a big red button that would lock transfers for some period of time. A country-specific lock was not an option. He added that there was government corruption within Ukraine and he thought some kind of government approval for transfers should not be used. Erik said that one of the risks he saw – and he was sorry to state it this way – was if a gun was pointed at a director of a company or their family. Surely in this case the best response was to process the transfer and get an appeal afterwards. That was the safest option for everybody involved. However, that was his own opinion. Max said they had some statistics that this had already happened in the occupied territories regarding other types of assets (he didn’t know of any cases involving IP resources) and they were killing people after the transfer. Reversing transfers would also open a can of worms as it could be open to abuse. Erik said the process here was similar to cases of art, for example. He added that there would be an update on this topic in the RIPE NCC Services WG. Olena Kushnir, WebPro, said they were a telecommunications provider of critical infrastructure in Ukraine. Of course, they had LIRs that only bought and sold IP addresses, and others who used these resources to provide services. When the war started in Ukraine, businesses that continued to work in the country were afraid that they would be put in danger. Of course they would do everything to save their family and their lives – but they were also afraid for their business and resources. It was first of all a matter of cyber-security. It was also a considerable amount of money that they could save [in terms of the value of the resources]. They didn’t want influence from government in their business, though she added that they had good dialogue with government through many working groups. She noted that Max said he didn’t know of any cases involving stolen IP addresses – she referenced the case of FTcom which had transferred addresses to Russian territory. She thought it was good to discuss changes to policy and she was grateful for the opportunity to be present for the discussion. She said they wanted to freeze all transfers until they found some way to protect Ukrainian network operators, because they were also part of the RIPE family. Hans Petter Holen, RIPE NCC, thanked his Ukrainian colleagues for attending the meeting and raising their concerns. What was happening in their country was terrible and he wanted to be clear on that. He noted that Athina would be presenting on this in the RIPE NCC Services WG. They would need input from the community on this and would be listening carefully to all of the input they received. And he reassured them that no matter how they would go forward, the RIPE NCC’s Board was intent on them taking timely action on the matter, so he didn’t think they should let the policy path be prohibitive just because of the timing, as perhaps the board could approve a temporary measure until the policy was ready. Artem Zurkov, no affiliation, said he was a provider from an occupied territory. He thought there should be some kind of public log so that if resources were locked, people would know that there was no ability to unlock them. This could support people’s physical safety if people with guns could see that this was the case. He supported Max’s suggestion that they should have some way for people to lock resources for a period of time. Elvis asked Hans Petter for guidance from the RIPE NCC on what kind of policy interventions would be needed. Hans Petter said the transfer policies said that the RIPE NCC should process transfers, but now they were suggesting that it shouldn’t process some transfers… but the community wanted the RIPE NCC to follow its policies. Clearly this could become complicated. He encouraged people to attend the RIPE NCC Services WG services session later that day to hear more on this. Rüdiger Volk, no affiliation, said he wanted to raise a different topic. He wondered whether the status field in the delegated extend file as it was defined and operated by the RIPE NCC should get some attention in the Address Policy WG. He noted that ISOC had reported some confusion using the data and, as far as he could tell, there was not really any clear documentation or attention to what was being done in that file. A couple of years ago, people had said this was just some statistics the RIRs were putting out and didn’t have much meaning. At the time of RIPE 75, policy changes in RPKI provided arguments that the delegated extended file actually had to be taken seriously. At RIPE 78, he had reported operational problems with the file, and he thought that if ISOC people, who were quite knowledgeable, were getting confused, then this was something that should be reviewed from a policy point of view. Erik thanked Rüdiger for his feedback and said this was definitely a discussion they needed to have on the mailing list, so they would need some more feedback from him there. End of second session.

1 0

Re: [address-policy-wg] Minimum size for IPv4 temporary assignments
by Erik Bais 24 Nov '22

24 Nov '22

Hi Edwin, Thank you on stepping forward on this. And I think that it would make sense to have a discussion on this with a policy proposal on the table. As you mentioned, this has been brought up multiple times already, so it would be good to see if we can get this sorted. It would be nice if the AP-WG members could provide some insight if the would support (or not) a policy proposal as suggested. Regards, Speaking as one of the Co-Chairs, Erik Bais From: address-policy-wg <address-policy-wg-bounces(a)ripe.net> on behalf of Edwin Verheul <edwin.verheul(a)surf.nl> Date: Thursday, 17 November 2022 at 16:24 To: "address-policy-wg(a)ripe.net" <address-policy-wg(a)ripe.net> Subject: [address-policy-wg] Minimum size for IPv4 temporary assignments 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