[arin-ppml] Recommended Draft Policy ARIN-2024-5: Rewrite of NRPM Section 4.4 Micro-Allocation

Mon Sep 29 16:46:35 EDT 2025

With the exception of the root server IP addresses which are hardcoded into every recursive resolver on the public Internet, I don’t see any particular need to reserve the addresses used by any authoritative DNS server, gTLD, ccTLD, or otherwise (or ARIN or IANA for that matter). One of the points of the DNS is that it is dynamic and allows for the addresses in the infrastructure, critical or not, to change gracefully.  The whole concept of reserving a block for “Critical Internet Infrastructure” seems specious — does ARIN actually want to encourage hard coding IP addresses? What problem does this actually solve?

FWIW.

Regards,
-drc

> On Sep 29, 2025, at 12:41 AM, Owen DeLong via ARIN-PPML <arin-ppml at arin.net> wrote:
> 
> The intent at the time was to make sure to exclude TLD operators for the ICANN Make Money Fast scheme that was (at the time) getting ready to launch and create potentially thousands of new gTLDs. We were explicit about earlier gTLDs and ccTLDs because at the time (and to the best of my knowledge, still) those were the only two other classes of TLDs.
> 
> ICANN Sanctioned applies to the “root server operators” as opposed to the various competing DNS Roots out there that are _NOT_ ICANN sanctioned, as we also didn’t want to open this reservation up to them for (obvious?) reasons.
> 
> The language is an attempt to clarify those exclusions by including the legitimate intended users of the policy.
> 
> gTLD operators are singled out because they are not permitted access to this reserved special address pool, but they are allowed a /23 from other customary sources (free pool, transfers, etc.).
> 
> They are special cased for a reason and I think that the only confusion I see here is an attempt to include them in eligibility to this pool.
> 
> I oppose the policy as written because I think it would create confusion and potentially open the pool up to gTLD operators which is not the policy intent and was hotly contested during the policy development with very strong support from the community for that exclusion.
> 
> Owen
> 
> 
>> On Sep 27, 2025, at 12:28, Martin Hannigan <hannigan at gmail.com> wrote:
>> 
>> 
>> 
>> In contrasting the original and this, we skewed closer back to intent. Original proposal author(s) may have inadvertently created confusion with a narrowing to ccTLD which we didn't intend. This was hopefully obvious in the followup discussion regarding service providers and data that was provided, but clearly not in the policy proposal.
>> 
>> - TLD Coverage
>> 
>> Policy statement 4.4.2 just says “TLD operators.”, but earlier in 4.4 main text “ICANN-sanctioned gTLD operators” is singled out with /23 limits. This creates a confusing mismatch. Are gTLDs special-cased while ccTLDs fall under “TLD operators”? Or are all TLDs covered? Ambiguous.
>> 
>> - 4.4. Clarity
>> 
>> "CII includes Internet exchange points (IXPs), core DNS service providers (e.g. ICANN-sanctioned root and ccTLD operators) ARIN, and IANA".
>> 
>> I don't know what a core DNS service provider is, but as long as it's clear we're using e.g. properly the "ccTLD" part isn't necessarily completely wrong, but is confusing. I don't recall that ccTLD's are ICANN "sanctioned". Perhaps it would've been best to remove that fluff? We did in the original proposal since it was confusing.
>> 
>> This isn't terrible, but somewhere down the line the lack of clarity (or too much clarity) is going to be problematic for names infrastructure. If anything, naming infrastructure scales far more efficiently than other CII which I don't see any problems to solve for past practices. 
>> 
>> HTH, YMMV
>> 
>> -M<
>> 
>> 
>> 
>> On Tue, Sep 23, 2025 at 12:32 PM ARIN <info at arin.net <mailto:info at arin.net>> wrote:
>>> On 18 September 2025, the ARIN Advisory Council (AC) advanced the following Draft Policy to Recommended Draft Policy status: 
>>> 
>>> * ARIN-2024-5: Rewrite of NRPM Section 4.4 Micro-Allocation
>>> 
>>> The text of the Recommended Draft Policy is below, and may also be found at: 
>>> 
>>> https://www.arin.net/participate/policy/drafts/2024_5/
>>> 
>>> You are encouraged to discuss all Recommended Draft Policies on PPML prior to their presentation at the next ARIN Public Policy Consultation (PPC). PPML and PPC discussions are invaluable to the AC when determining community consensus. 
>>> 
>>> 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)
>>> 
>>> 
>>> Recommended Draft Policy ARIN-2024-5: Rewrite of NRPM Section 4.4 Micro-Allocation
>>> 
>>> AC Assessment of Conformance with the Principles of Internet Number Resource Policy:
>>> 
>>> "Following a review of community feedback, staff and legal recommendations, and AC discussions, Draft Policy  ARIN-2024-5: Rewrite of NRPM Section 4.4 Micro-Allocation, was found to conform to the principles of the ARIN Policy Development Process. Based on being fair, impartial, and technically sound, this Draft Policy was moved to Recommended Draft state by the Advisory Council. If adopted by the ARIN Board Of Trustees, it would update the NRPM’s terminology from “Micro-Allocation” to “Critical Internet Infrastructure” in order to better describe the usage for the resources described in Section 4.4, as well as clarify qualification and usage requirements for resources allocated under the section."
>>> 
>>> Problem Statement:
>>> 
>>> The current NRPM Section 4.4 language hasn’t aged well. As the ARIN 53 policy experience report demonstrated, 4.4 has also become difficult to implement by ARIN staff. The growth and use of Internet Exchanges have also changed. The overhaul seeks to improve technical soundness, respect the privilege of a dedicated pool and to more closely observe conservation principles using clear, minimum and enforceable requirements and underscoring the value of routability of allocated prefixes as required.
>>> 
>>> Policy Statement:
>>> 
>>> 4.4 Critical Internet Infrastructure (CII) Allocations
>>> 
>>> ARIN will reserve a /15 equivalent of IPv4 address space for critical Internet infrastructure (CII) within the ARIN RIR service area. Allocations from this pool will be no smaller than a /24. Sparse allocation will be used whenever practical. CII includes Internet exchange points (IXPs), core DNS service providers (e.g. ICANN-sanctioned root and ccTLD operators) ARIN, and IANA.
>>> 
>>> ICANN-sanctioned gTLD operators may justify up to the equivalent of an IPv4 /23 block for each authorized gTLD, allocated from the free pool or received via transfer, but not from the above reservation. This limit of a /23 equivalent per gTLD does not apply to gTLD allocations made under previous policy.
>>> 
>>> Previous allocations under this policy must continue to meet the justification requirements of this policy.
>>> 
>>> Use of this policy for CII is voluntary; address holders that qualify for CII allocations may use allocations obtained via other means for CII resources. ARIN will publish a record of all addresses allocated under this section for research purposes.
>>> 
>>> 4.4.1 Internet Exchange Allocations
>>> 
>>> Internet exchange operators must justify their need by providing a minimum of three initial participants not under common control connected to a shared, physical switching fabric to be used for the purpose of the exchange of data destined for and between the respective networks. This justification must include participant names, ASNs and contact information for each named participant. The applicant’s Internet exchange-affiliated ASNs are not eligible to be included in meeting the participant requirement.
>>> 
>>> Allocated addresses may be publicly reachable at the operator’s discretion but must be assigned only to resources directly related to the operation of the IXP.
>>> 
>>> 4.4.2 TLD Allocations
>>> 
>>> TLD operators will provide justification of their need and certification of their status as currently active zone operators.
>>> 
>>> 4.4.3 Additional Requests
>>> 
>>> A recipient may request up to a 24-month supply of IPv4 resources under this section. Requests for additional resources under this section will be evaluated using Section 4.2.4.1’s usage requirements.
>>> 
>>> In cases where fulfilling the request by expanding the existing allocation is not possible, a single prefix sized to accommodate both the prior and additional requested allocation will be issued to facilitate renumbering. The original allocation must be returned to ARIN within 12 months of the new allocation.
>>> 
>>> Timetable for Implementation: Immediate.
>>> 
>>> 
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> ARIN-PPML
>>> You are receiving this message because you are subscribed to
>>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net <mailto:ARIN-PPML at arin.net>).
>>> Unsubscribe or manage your mailing list subscription at:
>>> https://lists.arin.net/mailman/listinfo/arin-ppml
>>> Please contact info at arin.net <mailto:info at 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 at arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> https://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact info at arin.net if you experience any issues.
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20250929/1f5ee3bd/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 322 bytes
Desc: OpenPGP digital signature
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20250929/1f5ee3bd/attachment-0001.sig>