Speaking as the proposal author: It appears that a URL included in the draft language has been inadvertently eaten by formatting. The Statistics & Reporting link is here: https://www.arin.net/reference/research/statistics/#ipv4-reserved-pool-status-nrpm-4-10-ipv6-deployments
I’ll also note that this page appears to have been updated since the policy was originally submitted - it now appears that the NPRM 4.4 Micro-Allocation pool is 65% allocated, with 35% remaining. (There’s a good chance I was rounding down when I said 50% in the problem statement) Thanks, -Chris > On Jun 20, 2023, at 08:54, ARIN <i...@arin.net> wrote: > > On 15 June 2023, the ARIN Advisory Council (AC) accepted “ARIN-prop-320: /26 > initial IPv4 allocation for IXPs” as a Draft Policy. > > Draft Policy ARIN-2023-2 is below and can be found at: > > https://www.arin.net/participate/policy/drafts/2023_2 > > You are encouraged to discuss all Draft Policies on PPML. The AC will > evaluate the discussion to assess the conformance of this draft policy with > ARIN's Principles of Internet number resource policy as stated in the Policy > Development Process (PDP). Specifically, these principles are: > > * Enabling Fair and Impartial Number Resource Administration > * Technically Sound > * Supported by the Community > > The PDP can be found at: > > https://www.arin.net/participate/policy/pdp/ > > Draft Policies and Proposals under discussion can be found at: > https://www.arin.net/participate/policy/drafts/ > > Regards, > > Eddie Diego > Policy Analyst > American Registry for Internet Numbers (ARIN) > > > Draft Policy ARIN-2023-2: /26 initial IPv4 allocation for IXPs > > Problem Statement: > > Per NRPM Section 4.4, ARIN has reserved a /15 for micro-allocations for > critical internet infrastructure, such as internet exchange points (IXPs) and > core DNS service providers. The majority of these allocation requests are > made by IXPs. As of the last ARIN report, roughly half of this reservation is > allocated (see Statistics & Reporting Projections from ARIN staff suggest > that at current allocation rates, the remaining reserved space may be > exhausted in the next few years. > > In parallel, an analysis of PeeringDB data conducted by the RIPE Address > Policy Working Group shows that approximately 70% of global IXPs have fewer > than 32 members registered with that site. An IXP this size could readily > operate with a /26 allocation, which would provide 100% overprovisioning > beyond their existing peer count. (Source: > https://github.com/mwichtlh/address-policy-wg ) > > Unlike other types of allocations, IXP peering networks are not required by > member networks to be globally reachable; only members of the IXP must be > able to reach the prefix. As such, there is no technical requirement that an > IXP allocation must be no smaller than a /24. > > Policy statement: > > Existing text: > > 4.4. Micro-allocation > > ARIN will make IPv4 micro-allocations to critical infrastructure providers of > the Internet, including public exchange points, core DNS service providers > (e.g. ICANN-sanctioned root and ccTLD operators) as well as the RIRs and > IANA. These allocations will be no smaller than a /24. Multiple allocations > may be granted in certain situations. > > Replace with: > > 4.4 Micro-allocation > > ARIN will make IPv4 micro-allocations to critical infrastructure providers of > the Internet, including public internet exchange points (IXPs), core DNS > service providers (e.g. ICANN-sanctioned root and ccTLD operators) as well as > the RIRs and IANA. These allocations will be no smaller than a /26 for IXPs, > or a /24 for other allocations that require global reachability of the > assigned allocation. Multiple allocations may be granted in certain > situations. > > 4.4.1 Micro-allocations for Internet Exchange Points (IXPs) > > An IXP requesting an initial IPv4 allocation from this reserved space will be > assigned a /26 by default. An IXP requesting an allocation larger than a /26 > must show an immediate need to utilize more than 25% of the requested > allocation size upon initial commissioning. > > An IXP requesting an allocation under this section must have also requested, > or already received, an IPv6 allocation for the same purpose under Section > 6.10.1. > > An allocation made to an IXP under this section may only be used for the > operation of its public peering LAN. No other uses are allowed. > > An IXP that has received an IPv4 allocation under this section may request a > larger allocation once they have utilized more than 50% of their existing > one. Upon receiving the larger allocation, the IXP must migrate to the new > allocation and return their previous one to ARIN within 6 months. > > Comments: > > This proposal mirrors RIPE policy proposal 2023-01 (see > https://www.ripe.net/participate/policies/proposals/2023-01) which is > currently under consideration in that region and appears to have sufficient > community support for adoption at the time of this writing. > > Timetable for implementation: Immediate > > > _______________________________________________ > ARIN-PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML@arin.net). > Unsubscribe or manage your mailing list subscription at: > https://lists.arin.net/mailman/listinfo/arin-ppml > Please contact i...@arin.net if you experience any issues. _______________________________________________ ARIN-PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML@arin.net). Unsubscribe or manage your mailing list subscription at: https://lists.arin.net/mailman/listinfo/arin-ppml Please contact i...@arin.net if you experience any issues.
