As one who was actively involved in developing the policy, I confirm that as my understanding at the time as well.
Owen > On Sep 29, 2025, at 14:10, David Farmer <[email protected]> wrote: > > I believe the original intention behind reserving a pool for microallocations > was an attempt by some networks to enforce aggregation, while still allowing > critical infrastructure to receive /24 prefixes. I don't think this was ever > really an effective strategy. > > However, with the IPv4 runout, this policy was revised to set aside a pool of > IPv4 addresses, ensuring the continued availability of IPv4 for critical > infrastructure (for IXes and at least some TLDs) without resorting to the > IPv4 market. > > At least that is my understanding of things. > > YMMV! Thanks. > > On Mon, Sep 29, 2025 at 3:46 PM David Conrad via ARIN-PPML > <[email protected] <mailto:[email protected]>> wrote: >> 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 <[email protected] >>> <mailto:[email protected]>> 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 <[email protected] >>>> <mailto:[email protected]>> 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 <[email protected] >>>> <mailto:[email protected]>> 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 ([email protected] >>>>> <mailto:[email protected]>). >>>>> Unsubscribe or manage your mailing list subscription at: >>>>> https://lists.arin.net/mailman/listinfo/arin-ppml >>>>> Please contact [email protected] <mailto:[email protected]> if you experience any >>>>> issues. >>>> _______________________________________________ >>>> ARIN-PPML >>>> You are receiving this message because you are subscribed to >>>> the ARIN Public Policy Mailing List ([email protected] >>>> <mailto:[email protected]>). >>>> Unsubscribe or manage your mailing list subscription at: >>>> https://lists.arin.net/mailman/listinfo/arin-ppml >>>> Please contact [email protected] <mailto:[email protected]> if you experience any >>>> issues. >>> >> >> _______________________________________________ >> ARIN-PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List ([email protected] >> <mailto:[email protected]>). >> Unsubscribe or manage your mailing list subscription at: >> https://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact [email protected] <mailto:[email protected]> if you experience any >> issues. > > > > -- > =============================================== > David Farmer Email:[email protected] > <mailto:email%[email protected]> > Networking & Telecommunication Services > Office of Information Technology > University of Minnesota > 2218 University Ave SE Phone: 612-626-0815 > Minneapolis, MN 55414-3029 Cell: 612-812-9952 > ===============================================
_______________________________________________ ARIN-PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List ([email protected]). Unsubscribe or manage your mailing list subscription at: https://lists.arin.net/mailman/listinfo/arin-ppml Please contact [email protected] if you experience any issues.
