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

@EXT: FW: 2023-04 Review Phase (Add AGGREGATED-BY-LIR status for IPv4 PA assignments)
by Kessler, Emmanuel 21 Dec '23

21 Dec '23

Dear all, Thanks for the various points provided after my last message of the 13th December. we are assessing them with our colleagues of the police forces and we have shared with cybersecurity actors the EU. >From Law enforcement perspective, we would consider highly reasonable that RIPE organises a full consultation with relevant stakeholder groups that use RIPE data basis, to fully assess the impact and their needs. Such consultation would be necessary and legitimate as considering the official agreement signed on 2016 between RIPE NCC and EUROPOL that states that both parties, in accordance with their respective mandates, inform each other about the implementation of their respective mandates in the area of cybercrime, inform each other of programmes of potential interest in order to identify possibilities for joint activities and mutual contributions. As already mentioned, we were informed only recently about the proposal that would need full assessment that takes time. Any new loss of information linked with aggregation of IPV4, would mean less criminals identified and more victims targeted or in life danger. Such losses of information would also conflict with current EU regulatory activities against the "going dark matter" (loss of access to information for LE authorities for judicial purposes). This problem is highly identify at EU level, and I would also prefer to prevent any future misunderstanding between actors in RIPE and EU actors, would the measure be adopted in an hasty way... >From reading your points, I observe that beyond text, is the matter of the real implementation by LIRs and others...we need to clarify and ensure that. Thanks for your understanding and constructive spirit. Regards Emmanuel KESSLER Emmanuel KESSLER Head of Team - Prevention/Outreach Europol - O3 European Cyber Crime Centre (EC3) Eisenhowerlaan 73, 2517 KK The Hague, The Netherlands Phone: [Moderated] / mobile [Moderated] www.europol.europa.eu<http://www.europol.europa.eu/> [cid:image001.png@01D8169D.5B765D70] -----Original Message----- From: denis walker <ripedenis(a)gmail.com> Sent: 15 December 2023 15:05 To: Jeroen Lauwers <jlauwers(a)a2b-internet.com> Cc: RIPE Address Policy Working Group <address-policy-wg(a)ripe.net>; Gert Doering <gert(a)space.net>; Kessler, Emmanuel <Emmanuel.Kessler(a)europol.europa.eu> Subject: Re: [address-policy-wg] 2023-04 Review Phase (Add AGGREGATED-BY-LIR status for IPv4 PA assignments) This email originated from outside Europol. Do not click links or open attachments unless you recognize the sender and know the content is safe. The external address that sent the message is: denis1(a)gmail.com Hi Jeroen Looking back over this email, there are two things that really stand out to me. "Do you already use AGGREGATED-BY-LIR when registering IPv6 assignments? Would you find it convenient and useful to be able to register IPv4 assignments in the same way?" "the statement <When an End User has a network using public address space this must be registered separately with the contact details of the End User> found in the current policy (and removed by 2023-04 in order to bring the wording in line with that of the IPv6 policy)" These two statements that you made basically sum up this policy proposal. You are suggesting we fundamentally change IPv4 address policy for the 'convenience' of operators and to 'align' some words between two different policies regardless of the consequences. When you add to this a comment Gert made at RIPE 87 when he said that after 30 years we have no clue as to what the "admic-c:" attribute means or why anyone would want to contact them or what they would expect to get from such contact. We have maybe 5 or 6 million inetnum objects in the RIPE Database, a few million inet6num objects and probably tens of thousands of aut-num objects. They all have a mandatory admin-c and we don't know why it is there. All we have is a 30 year old definition that says it must be an on-site contact for the End User in the case of assignment and ASNs. This is a dreadful situation to be in. I suggest that 2023-04 is withdrawn. Then we have a wide reaching consultation with many stakeholder groups who use the RIPE Database. Determine what their needs are for a public registry. What information they need and would like to have in the RIPE Database. Basically do what I expected the last database task force to do, produce a business requirements document for the RIPE Database as a public registry. Then see where we go from there. cheers denis On Wed, 13 Dec 2023 at 19:14, Jeroen Lauwers <jlauwers(a)a2b-internet.com> wrote: > > Dear colleagues, > > Though we recognise that most of you are probably busy preparing for the upcoming holidays, we would like to ask you to share your opinion on proposal 2023-04. Remember that Policy Development Process requires any comments made during the Discussion phase must be repeated during the Review phase in order to count towards or against rough consensus, as your views can now take the RIPE NCC's Impact Analysis into account. > > Here are some questions for the WG to get the discussion started: Do you already use AGGREGATED-BY-LIR when registering IPv6 assignments? Would you find it convenient and useful to be able to register IPv4 assignments in the same way? Does 2023-04 address this use case well in its current form, or could you think of any potential improvements? > > We hope you will find the time to let your voice be heard! > > The Policy Development Process requires the proposers to adequately address any suggestions for changes or objections to the proposal in each phase, which we will do below. > > 1. Does 2023-04 change the contact registration requirements for assignments? > > > The argument made is that the statement <When an End User has a network using public address space this must be registered separately with the contact details of the End User> found in the current policy (and removed by 2023-04 in order to bring the wording in line with that of the IPv6 policy), implicitly requires LIRs to register non-delegated/outsourced contact information for the End User in the RIPE database, not necessarily in the mandatory <admin-c> or <tech-c> attributes, but possibly in an optional attribute like <descr>, <org> or <remarks>. > > Proposers' response: > > We do not believe so, for the following reasons, and keeping the current practice and policies in consideration: > > The RIPE NCC does not consider that 2023-04 changes the contact registration requirements in any way[1][2][3]. Absent any (rough) consensus in the Working Group to the contrary, we defer to the RIPE NCC's judgement on this point. > The practice of creating assignments with all contact information delegated is already widespread. If this was a policy violation made possible due to the RIPE NCC implementing RIPE policy incorrectly, we would have expected the community to take action to correct this situation. However, no such policy proposal has been put forward by the community. > Outsourcing and delegation of contact information is a common practice across many industries, including in networking and information technology. There is no policy language that explicitly prohibits this for IPv4 assignments. Absent that, we believe any implicit prohibition found "between the lines" is essentially <void for vagueness>[4]. > An obligation to publish the End User's contact information in the RIPE database will constitute a violation of Article 6(3) of the RIPE Database Terms and Conditions[5] and Article 6(1)(a) of the GDPR[6], if the End User's contact person has not given explicit consent to such publication. We believe that the RIPE policy cannot reasonably be interpreted to require LIRs to break EU law (and even if it explicitly did require that, EU law would still take precedence). > The policy's stated goal of registering assignments is <to ensure uniqueness and to provide information for Internet troubleshooting at all levels>[7]. Requiring LIRs to publish the contact information of End Users who often will not have any knowledge or capability to aid with troubleshooting does work towards this attaining goal. On the contrary, delegating the contact information to the LIR/ISP may well be the only way to attain this goal. > > > [1] > https://www.ripe.net/ripe/mail/archives/address-policy-wg/2023-Septemb > er/013856.html [2] > https://www.ripe.net/participate/policies/proposals/2023-04#impact-ana > lysis [3] > https://www.ripe.net/ripe/mail/archives/address-policy-wg/2023-Novembe > r/013892.html [4] https://www.law.cornell.edu/wex/void_for_vagueness > [5] > https://www.ripe.net/manage-ips-and-asns/db/support/documentation/term > s [6] > https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32016R0 > 679#d1e1888-1-1 [7] https://www.ripe.net/publications/docs/ripe-804#3 > > 2. The <assignment-size> attribute should be a CIDR prefix length > > Leaving it undefined could result in some LIRs using it to represent an IPv4 address count, while others would use it to represent a CIDR prefix length. > > Proposers' response: > > We agree <assignment-size> should be a CIDR prefix length. We understand that, if proposal 2023-04 would be accepted, the RIPE NCC could implement the <assignment-size> attribute for IPv4 inetnum objects to be a CIDR prefix length, and document it as such. Therefore we do not believe it is necessary to spell this out explicitly in the policy document (it is not spelled out in the IPv6 policy document either). > > > Thank you for your attention and enjoy your holidays! > > Best regards, > Jeroen and Tore > > > Op 21 nov. 2023, om 11:13 heeft Angela Dall'Ara <adallara(a)ripe.net> het volgende geschreven: > > > Dear colleagues, > > Policy proposal 2023-04, "Add AGGREGATED-BY-LIR status for IPv4 PA assignments", is now in the Review Phase. > > The goal of this proposal is to introduce the AGGREGATED-BY-LIR status for IPv4 PA assignments to reduce LIR efforts in registration and maintenance. > > This proposal has been updated and it is now at version 2.0. The proposed policy text did not change, the only difference is that the section "Arguments opposing the proposal" includes a reference to the last round of discussion. > > 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-04 > https://www.ripe.net/participate/policies/proposals/2023-04#impact-ana > lysis > And the draft document at: > https://www.ripe.net/participate/policies/proposals/2023-04/draft > > As per the RIPE Policy Development Process (PDP), the purpose of this four-week Review Phase is to continue the 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 20 December 2023. > > Kind regards, > Angela Dall'Ara > Policy Officer > RIPE NCC > > -- > > 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 > > > -- > > 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

2 1

@EXT: Inputs/observations from EUROPOLon proposal 2023-04
by Kessler, Emmanuel 20 Dec '23

20 Dec '23

Dear partners, companies and RIPE, on the last RIPE meeting, my inputs have unfortunately been hampered by some technical problems of online connection. With this message, I would like to express from Europol perspective, our questions and some clear concerns about the measure 2023-04 as proposed. We have been very recently informed about the project of measure that would indeed remove User assignment data from the RIPE Database public registry. We have started a consultation of EU law enforcement services (that however takes time), and informed the EU Commission. >From the first feedback we have gathered, the measure will have some clear negative impacts on the capacity of law enforcement authorities to lead investigation, considering the current situation and practices. Various law enforcement actors (LEA) do appreciate to have the information in the RIPE databases. This direct access helps many investigators to work swiftly in their daily activity against cybercriminals, fraudsters, pedophiles, terrorists...as we all know. The first negative impact will concern the swift availability of data : with the new measure, LEA will systematically have to request information to the LIRs, with a court order. Beyond the sole matter of lawfulness requirement, it will not ease as such the daily work, but instead it will be another barrier to the facilitated access to the data : easing the access means easing an efficient and swift investigation. The proposed measure does not prioritize it. Maintaining access to the data of end users at RIPE level is also a way to ensure access to all data, in spite of the uncertainty of answers from some LIRs. Registration practices are far to be uniform across the various LIRs. Please kindly consider that capacity of Law Enforcement is asymmetric towards large volumes of ransomware attacks, online scam types and massive sharing of Child Sexual Abuses Material,...all support from our partners is the most precious to counter these realities. The other main impact will be on the quality of collected data. In practice, the proposed policy could indeed allow assignments to be somewhat anonymised. The measure would have here an impact on data granularity : The shift to aggregated assignments would result in less granular data available to law enforcement. While individual assignments offer specific and detailed information about each IP address's usage, aggregated data may obscure such details, potentially complicating investigations that rely on precise IP address information.. We do understand that the aggregated registration of IPv4 addresses would streamline administrative processes for LIRs but, it is important to acknowledge that it would also have a negative impact on the efficiency and effectiveness of law enforcement investigations. The less detailed information will require additional steps or inquiries to ascertain the specifics of an IP address's usage, potentially delaying investigative processes. Identifying IPV4, remains highly challenging in many cases, as all know, and IPV6 will not replace it at short term. All delays hamper the general (complex) process of investigation and may have an strong impact on the final result (bad guys arrested and new victims prevented or saved) EU has recently adopted the NIS2 directive with its article 28 for a better access to DNS information for the legitimate actors. we observe that the planned measure 2023-04 would open an opposite (negative) trend on the access to IP information. We express our serious concern with the impact that such a measure would have on various investigations carried out by EU competent authorities, and the protection of victims, should it be adopted. Thank you for your attention and consideration. Regards Emmanuel KESSLER Head of Team - Prevention/Outreach Europol - O3 European Cyber Crime Centre (EC3) Eisenhowerlaan 73, 2517 KK The Hague, The Netherlands Phone: [Moderated] / mobile [Moderated] www.europol.europa.eu<http://www.europol.europa.eu/>

6 12

Address Policy WG Co-Chair - James Kennedy Steps Down
by Leo Vegoda 28 Nov '23

28 Nov '23

Dear WG, You will have seen the recent announcement that James Kennedy has joined the RIPE NCC as Chief Registry Officer. He's stepping down from his community leadership roles, including as co-chair of the Address Policy WG. Because we still have two co-chairs there is no immediate need to recruit a replacement. Instead, we'd like to encourage anyone considering joining the team to contact us to discuss what is involved. You can write to us and we can schedule a call. You can also approach us at RIPE 87 in Rome. Kind regards, Leo & Erik Address Policy WG Co-Chairs

9 9

Draft Address Policy WG Agenda for RIPE 87, Rome
by Leo Vegoda 28 Nov '23

28 Nov '23

Hi, Here is our draft agenda for Rome. We can make refinements if needed, so please contact the chairs if you would like us to add or change something. Kind regards, Leo Session 1 starts: 09:00 A. Introduction [5 min] B. Chair Selection [10 min] C. NRO NC / ICANN ASO AC Update [10 min] Hervé Clement and/or Sander Steffann D. Registry Services Update Followed by Q&A [15 min] Marco Schmidt, RIPE NCC E. Policy Update Followed by Q&A [15 min] Angela Dall'Ara, RIPE NCC F. Discussion: What is the purpose of IPv4 assignment registration in 2024? [30 mins] [co-chairs to show 1 discussion slide] Session 1 ends: 11:00 ☕ Session 2 starts: 11:30 G. 2023-04: Add AGGREGATED-BY-LIR status for IPv4 PA assignments [25 mins] Jeroen Lauwers, A2B Internet Tore Anderson, Redpill Linpro H. Improving IPv6 PI Policy [25 mins] Tobias Fiebig I. AOB [10 mins] Session 2 ends: 12:30

1 2

New on RIPE Labs: Who’s Waiting on the IPv4 Waiting List?
by Antony Gollan 24 Nov '23

24 Nov '23

Dear colleagues, Four years after our IPv4 waiting list became active, and with more than a thousand LIRs in the queue for an allocation, how successful has the list been at providing at least a minimal amount of IPv4 space to newcomers? We take a closer look at some of the numbers in this article on RIPE Labs: https://labs.ripe.net/author/antony_gollan/whos-waiting-on-the-ipv4-waiting… Regards Antony Gollan Communications Team Manager RIPE NCC

1 0

pinkpanther360
by Salena 24 Nov '23

24 Nov '23

pinkpanther360 pinkpanther360 <https://mail.google.com/> https://mail.google.com/

1 0

Re: [address-policy-wg] TESTING360
by Salena 24 Nov '23

24 Nov '23

TESTING360 On Fri, Nov 24, 2023 at 5:48 PM Salena <salenamartine360(a)gmail.com> wrote: > TESTING360 > TESTING360TESTING360TESTING360TESTING360TESTING360TESTING360TESTING360TESTING360TESTING360TESTING360 > TESTING360 <https://mail.google.com/> > https://mail.google.com/ > >

1 0

[Moderated]
by unknown＠example.com 23 Nov '23

23 Nov '23

[This message was removed from the archive because it was considered to be spam]

1 0

2023-04 (Add AGGREGATED-BY-LIR status for IPv4 PA assignments)
by Leo Vegoda 07 Nov '23

07 Nov '23

Dear WG, The Discussion Phase of policy proposal 2023-04 "Add AGGREGATED-BY-LIR status for IPv4 PA assignments" 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

3 5

Potential fraud in applying for temporary assignments
by Siyuan Miao 25 Oct '23

25 Oct '23

Hi folks We wanted to bring to your attention a matter of concern regarding recent emails from the RIPE member, cn.jiunetwork. They are offering assistance in obtaining temporary IP address assignments from RIPE for one to five years, which seems to conflict with RIPE-801's guidelines. I suggest reviewing past temporary address requests made by them to ensure compliance with RIPE policies and legitimate usage. Original Message from cn.jiunetwork: Now we have new IP address for delivery, it is clean . Subnet size from /24 to /20 ,did you need more ipv4 ? note: we no provide lease service , but if you need , we can help you from RIPE get Temporary Address(/24-/18,TEMPORARY /24 is $1300 years/time, you can purchase 1-5 years ) If you are interested in ordering more, please contact us. my mail is REDACTED -- Siyuan Miao *AS917 | Misaka Network, Inc.* 8 The Green, Ste 6288 Dover, DE 19901

1 0

2023-04 New Policy Proposal (Add AGGREGATED-BY-LIR status for IPv4 PA assignments)
by Angela Dall'Ara 17 Oct '23

17 Oct '23

Dear colleagues, A new RIPE Policy Proposal, 2023-04, "Add AGGREGATED-BY-LIR status for IPv4 PA assignments" is now available for discussion. This proposal aims to introduce the AGGREGATED-BY-LIR status for IPv4 PA assignments to reduce LIR efforts in registration and maintenance. You can find the full proposal at: https://www.ripe.net/participate/policies/proposals/2023-04 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 3 October 2023. Kind regards, Angela Dall'Ara Policy Officer RIPE NCC

26 57

Status IPv6 Policy Draft
by Tobias Fiebig 14 Sep '23

14 Sep '23

Heho, i am currently scrolling over my inbox, and was wondering what the status of the v6 policy draft is (with 87 coming up). Is anyone already working on a draft to discuss? Otherwise, I could take a shot to have something ready closer to 87 which picks up the major points from prior discussions. With best regards, Tobias -- Dr.-Ing. Tobias Fiebig T +31 616 80 98 99 M tobias(a)fiebig.nl

2 1

2023-01 Policy Proposal Accepted and Implemented (Reducing IXP IPv4 assignment default size to a /26)
by Angela Dall'Ara 14 Sep '23

14 Sep '23

Dear colleagues, Consensus has been reached on 2023-01 “Reducing IXP IPv4 assignment default size to a /26”. This proposal modifies in the IPv4 Policy the default size of IPv4 assignments for IXPs from a /24 to /26 and clarifies the return of the assignments previously issued for the IXP peering LAN. The archived policy proposal can be found at: https://www.ripe.net/participate/policies/proposals/2023-01 The new RIPE Document, "IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region" is available at: https://www.ripe.net/publications/docs/ripe-804 This proposal is implemented with immediate effect. Thank you to everyone who provided input. Kind regards, Angela Dall'Ara Policy Officer RIPE NCC

1 0

Consensus - 2023-01 - Reducing IXP IPv4 assignment default size to a /26
by Leo Vegoda 12 Sep '23

12 Sep '23

Dear Working Group, Two comments were made during the Last Call phase. These comments did not address the subject of the policy proposal. This means the community has achieved a consensus. The RIPE NCC can proceed with implementation. Our thanks to everyone who contributed to this discussion. Kind regards, Leo Vegoda, for the Address Policy WG co-chairs

2 1

New AS Number Blocks Allocated to the RIPE NCC
by Marco Schmidt 14 Aug '23

14 Aug '23

Dear colleagues, On 10 August 2023, the RIPE NCC received the following AS Number blocks from IANA: 213404-214427 214428-215451 215452-216475 You may want to update your records accordingly. All allocations of AS Numbers made by IANA to RIRs are listed here: https://www.iana.org/assignments/as-numbers/as-numbers.xhtml Kind regards, Marco Schmidt Manager Registration Services RIPE NCC

1 0

Policy Proposal Implemented: 2023-02 “Minimum size for IPv4 Temporary Assignments”
by Angela Dall'Ara 31 Jul '23

31 Jul '23

Dear colleagues, We are pleased to announce that we have fully implemented the RIPE Policy Proposal 2023-02 “Minimum size for IPv4 Temporary Assignments”. This policy sets the default assignment size for IPv4 temporary assignments to a /24 and allows routing requirements to justify the request for more than a /24 for research purposes. The archived policy proposal can be found at:  https://www.ripe.net/participate/policies/proposals/2023-02 The RIPE Document, "Temporary Internet Number Assignment Policies" is available at: https://www.ripe.net/publications/docs/ripe-801 Kind regards, Angela Dall'Ara Policy Officer RIPE NCC

1 0

2023-01 Last Call for Comments (Reducing IXP IPv4 assignment default size to a /26)
by Angela Dall'Ara 31 Jul '23

31 Jul '23

Dear colleagues,   Proposal 2023-01, "Reducing IXP IPv4 assignment default size to a /26", is now in Concluding 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 WG co-chairs have declared that rough consensus has been reached and the proposal will now move to Last Call.   As per the RIPE Policy Development Process (PDP), the purpose of this Concluding Phase is to give an opportunity to present well-justified objections for those who missed the previous two phases and wish to oppose the proposal.  Any objection must be made by 8 September 2023 and must be supported by an explanation. If no substantive objections are raised by the end of Last Call, the proposal will complete the PDP and will be evaluated by the WG co-chairs for final consensus.   You can find the full proposal at: https://www.ripe.net/participate/policies/proposals/2023-01   Please e-mail any final comments about this proposal to <address-policy-wg(a)ripe.net> before 8 September 2023. Kind regards, Angela Dall’Ara Policy Officer RIPE NCC

1 0

Last Call - 2023-01 - Reducing IXP IPv4 assignment default size to a /26
by Leo Vegoda 31 Jul '23

31 Jul '23

Dear Working Group, The issue raised during the Review Phase was resolved. We will move the proposal to Last Call. If you missed the previous discussion and have identified an issue that has not already been resolved, please raise it. Traditionally, Last Call is four weeks. But opening a Last Call on the last day of July and closing it before the end of August might mean that some people miss this announcement. For this reason, we will hold Last Call open until the end of Friday, 8 September. Kind regards, Leo Vegoda, for the Address Policy WG co-chairs

1 0

2023-02 Proposal Accepted (Minimum Size for IPv4 Temporary Assignments)
by Angela Dall'Ara 18 Jul '23

18 Jul '23

Dear colleagues, Consensus has been reached on 2023-02"Minimum Size for IPv4 Temporary Assignments". This policy proposal aimed to setthe defaultassignment size for IPv4 temporary assignments to a /24and allow 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 <https://www.ripe.net/publications/docs/ripe-801> The new RIPE Document is called ripe-801and is available at: https://www.ripe.net/publications/docs/ripe-801 <https://www.ripe.net/publications/docs/ripe-801> We estimate that this proposal will take less than two weeksto fully implement. We will send another announcement once the implementation is complete and the new procedures are in place. Thanks to everyone who provided input. Kind regards, Angela Dall'Ara Policy Officer RIPE NCC

1 0

Consensus - 2023-02 - Minimum Size for IPv4 Temporary Assignments
by Leo Vegoda 18 Jul '23

18 Jul '23

Dear Working Group, No objections were raised during the Last Call phase. The community has achieved a consensus. The RIPE NCC can proceed with implementation. Our thanks to everyone who contributed to this discussion. Kind regards, Leo Vegoda, for the Address Policy WG co-chairs

2 1

2023-02 Last Call for Comments (Minimum Size for IPv4 Temporary Assignments)
by Karen Hung 12 Jul '23

12 Jul '23

Dear colleagues, Proposal 2023-02, "Minimum Size for IPv4 Temporary Assignments" is now in Concluding Phase. This policy proposal recommends setting the minimum assignment size 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 WG co-chairs have declared that rough consensus has been reached and the proposal will now move to Last Call. As per the RIPE Policy Development Process (PDP), the purpose of this four week Concluding Phase is to give an opportunity to present well-justified objections for those who missed the previous two phases and wish to oppose the proposal. Any objection must be made by 13 July 2023 and must be supported by an explanation. If no substantive objections are raised by the end of Last Call, the proposal will complete the PDP and will be evaluated by the WG co-chairs for final consensus. You can find the full proposal at: https://www.ripe.net/participate/policies/proposals/2023-02 Please e-mail any final comments about this proposal to <address-policy-wg(a)ripe.net <mailto:address-policy-wg@ripe.net>> before 13 July 2023. Kind regards, Karen Hung On behalf of Policy Officer RIPE NCC

9 8

2023-01 Review Phase (Reducing IXP IPv4 assignment default size to a /26)
by Angela Dall'Ara 12 Jul '23

12 Jul '23

Dear colleagues, Policy proposal 2023-01, " Reducing IXP IPv4 assignment default size to a /26", is now in the Review 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 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-01_ _https://www.ripe.net/participate/policies/proposals/2023-01#impact-analysi… And the draft documents at: _https://www.ripe.net/participate/policies/proposals/2023-01/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 28 July2023. Kind regards, Angela Dall'Ara Policy Officer RIPE NCC

9 13

Input Requested: How to Ensure Responsible ASN Resource Management
by Marco Schmidt 22 Jun '23

22 Jun '23

Dear colleagues, At RIPE 86, we shared some observations regarding Autonomous System Number (ASN) requests and usage [1]. We see an increasing number of ASN requests coming from both inside and outside of our service region. This seems to be driven primarily by the low cost and ease of receiving an ASN from the RIPE NCC. The downside is that we also see a significant decrease in responsible resource management by these resource holders. A large number of ASNs are never used or become abandoned after a short period. Some data: in the last two years, we have provided 4,186 ASNs (between March 2021 and February 2023). Of this amount, we can see that 1,478 ASNs (more than 35%) do not appear to be in use, as they are not visible in the routing system. Looking at total numbers, we have issued almost 38,000 ASNs, of which more than 8,000 (~20%) are not visible. This growing trend not only creates avoidable work for Registration Services and added costs for the membership, we believe it also undermines the goal of responsible management of Internet number resources within our service region. As the membership voted against an annual service fee for ASNs at the recent RIPE NCC General Meeting, I would like to ask the working group for guidance on how resource holders can be motivated to manage their ASNs responsibly and how the RIPE NCC can provide support for this. We also plan to intensify our ongoing project to clean up unused Autonomous System (AS) Numbers [2]. Almost 2,000 unused ASNs have been recovered as part of this work so far. Do you support our approach here? And are there other ways we could improve the situation? Perhaps you could add clarification on requesting and returning ASNs in the relevant RIPE policy, or maybe we could give a stronger mandate and responsibility to the sponsoring LIRs. If you have an ASN registered to you that you don’t need anymore, you can always contact us through the LIR Portal or via your sponsoring LIR and we will arrange for the return of this resource. Kind regards, Marco Schmidt Manager Registration Services RIPE NCC [1] https://ripe86.ripe.net/wp-content/uploads/presentations/82-RIPE86-Feeback-… [2] https://www.ripe.net/manage-ips-and-asns/as-numbers/as-number-clean-up

12 21

Re: [address-policy-wg] Input Requested: How to Ensure Responsible ASN Resource Management
by Arturo Servin 22 Jun '23

22 Jun '23

I cannot answer for Mike, but for those that I know, yes, those are multihomed. So there is a legitimate use of an ASN that there isn't in the Internet (you need a public one to guarantee uniqueness) Regarding the topic, I do not think that RIPE NCC needs to spend time trying to recover unseen (but not for sure unused) ASNs. Regards as On Thu, Jun 22, 2023 at 1:27 PM Arturo Servin <arturolev(a)google.com> wrote: > > I cannot answer for Mike, but for those that I know, yes, those are > multihomed. > > So there is a legitimate use of an ASN that there isn't in the Internet > (you need a public one to guarantee uniqueness) > > Regarding the topic, I do not think that RIPE NCC needs to spend time > trying to recover unseen (but not for sure unused) ASNs. > > Regards > as > > > On Thu, Jun 22, 2023 at 1:21 PM Arash Naderpour <arash_mpc(a)parsun.com> > wrote: > >> Hi Mike, >> >> Are these setups still multihome? >> >> Regardsm >> >> Arash Naderpour >> >> On Thu, Jun 22, 2023 at 12:12 PM Mike Bromwich < >> mike.bromwich(a)stacuity.com> wrote: >> >>> Hi, >>> >>> One other aspect to consider - there are situations where public ASNs >>> (and addresses) are required - but not directly connected to the Internet. >>> Therefore, they do not appear in the Internet routing tables but are >>> legitimately used elsewhere. >>> >>> For example, in our field (mobile cellular networks) mobile operators >>> are connected using the IPX network as managed by the GSMA. This is >>> distinct from the Internet but public ASNs and addresses are required. >>> >>> The relevant guidelines from the GSMA: >>> https://www.gsma.com/newsroom/wp-content/uploads/IR.40-v8.0.pdf >>> >>> 'The GSMA worked closely with the all the RIR communities (RIPE NCC, >>> ARIN and APNIC) >>> to develop and produce the early versions of this document. This was >>> essential to ensure >>> that the proposed guidelines to the Service Providers associated with >>> requesting and >>> implementing Public addresses are aligned with the existing policies and >>> procedures of the >>> RIR community.' >>> >>> 'New Public address space assignment must be requested by Service >>> Providers and IPX >>> Providers from the appropriate LIR/NIR/DR using existing procedures >>> supported by its >>> respective serving RIR. >>> >>> This document can be used as part of the request submitted by the >>> Service Provider as a >>> source of reference to help explain the requirement for Public address >>> space.' >>> >>> Perhaps there are other such networks which work in the same way? >>> Perhaps there should be a mechanism to record or report that resources are >>> in use elsewhere and so should not be recovered? >>> >>> Mike >>> >>> >>> -----Original Message----- >>> From: address-policy-wg <address-policy-wg-bounces(a)ripe.net> On Behalf >>> Of Marco Schmidt >>> Sent: Thursday, June 8, 2023 2:31 PM >>> To: address-policy-wg(a)ripe.net >>> Subject: [address-policy-wg] Input Requested: How to Ensure Responsible >>> ASN Resource Management >>> >>> Dear colleagues, >>> >>> At RIPE 86, we shared some observations regarding Autonomous System >>> Number (ASN) requests and usage [1]. >>> >>> We see an increasing number of ASN requests coming from both inside and >>> outside of our service region. This seems to be driven primarily by the low >>> cost and ease of receiving an ASN from the RIPE NCC. The downside is that >>> we also see a significant decrease in responsible resource management by >>> these resource holders. A large number of ASNs are never used or become >>> abandoned after a short period. >>> >>> Some data: in the last two years, we have provided 4,186 ASNs (between >>> March 2021 and February 2023). Of this amount, we can see that 1,478 ASNs >>> (more than 35%) do not appear to be in use, as they are not visible in the >>> routing system. >>> >>> Looking at total numbers, we have issued almost 38,000 ASNs, of which >>> more than 8,000 (~20%) are not visible. >>> >>> This growing trend not only creates avoidable work for Registration >>> Services and added costs for the membership, we believe it also undermines >>> the goal of responsible management of Internet number resources within our >>> service region. >>> >>> As the membership voted against an annual service fee for ASNs at the >>> recent RIPE NCC General Meeting, I would like to ask the working group for >>> guidance on how resource holders can be motivated to manage their ASNs >>> responsibly and how the RIPE NCC can provide support for this. >>> >>> We also plan to intensify our ongoing project to clean up unused >>> Autonomous System (AS) Numbers [2]. Almost 2,000 unused ASNs have been >>> recovered as part of this work so far. Do you support our approach here? >>> And are there other ways we could improve the situation? Perhaps you >>> could add clarification on requesting and returning ASNs in the relevant >>> RIPE policy, or maybe we could give a stronger mandate and responsibility >>> to the sponsoring LIRs. >>> >>> >>> >>> If you have an ASN registered to you that you don’t need anymore, you >>> can always contact us through the LIR Portal or via your sponsoring LIR and >>> we will arrange for the return of this resource. >>> >>> Kind regards, >>> >>> Marco Schmidt >>> Manager Registration Services >>> RIPE NCC >>> >>> >>> >>> [1] >>> >>> https://ripe86.ripe.net/wp-content/uploads/presentations/82-RIPE86-Feeback-… >>> >>> [2] >>> https://www.ripe.net/manage-ips-and-asns/as-numbers/as-number-clean-up >>> >>> >>> -- >>> >>> 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 >>> -- >>> >>> 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 >>> >> -- >> >> 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 >> >

2 1

Draft Address Policy WG Minutes from RIPE 86
by Leo Vegoda 20 Jun '23

20 Jun '23

Dear WG, The RIPE NCC has now prepared draft minutes of our session at RIPE 86. You can find them on the website here: https://www.ripe.net/participate/ripe/wg/active-wg/ap/minutes/ripe-86-addre… 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

1 0