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

[Martin Hannigan]

On Thu, Mar 6, 2025 at 4:56 PM ARIN <info at arin.net> wrote:

[ clip ]


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 Exchanges, IANA-authorized
> root servers, TLD operators that offer domain-level DNS services to outside
> parties, ARIN, and IANA.
>

I would suggest revising the grammar of this: "ARIN will reserve a /15
equivalent of IPv4 address space" to this:  "ARIN will reserve the
equivalent of a /15 of IPV4 address space".

I believe the majority of Internet Exchange Point operators call it an
Internet Exchange Point as it was initially proposed. At least as I best
recall Aaron Wendell's proposal for a definition which was widely supported
did which you can refresh your memories here:
https://www.arin.net/participate/policy/proposals/2024/ARIN_prop_332/

I have no idea what this means: "TLD operators that offer domain-level DNS
services to outside parties"


> Addresses allocated from this pool may be revoked if they are no longer in
> use or not used for approved purposes. Only Section 8.2 transfers are
> allowed. Use of this policy for CII is voluntary. ARIN will publish all 4.4
> allocated addresses for research purposes.
>

This is true, accurate and reasonable. However, it creates a new issue to
deal with which should be simple. This policy says Internet Exchange Points
are CII because of what they are, not what address space they use. I'll tie
this to something below shortly.


>
> 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


I could swear we landed on layer 2 switch fabric. The intent is not a
router or a virtual machine acting as a router. As long as that's the
interpretation, ok.


> 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 required to operate the
> IXP.
>

Opps! ^^^


>
> 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. To qualify for additional resources, a recipient must have
> utilized all other resources allocated via 4.4, in aggregate, to at least
> 80%, and at least 50% of each individual prior allocation.


That "/24-month" supply is my typo which has made it through.

Since the policy clearly states an Internet Exchange Point (root, TLD too I
guess) is CII and not the number resource this math should also be applied
to IXP's that choose to use other resources as long as they comply with the
4.4 policy regardless of using numbers from the pool. There's no obvious
reason for an IXP to be required to use the pool and it would be "fair" to
apply the utilization math as a result.

Probably easy to add a simple sentence saying something like "if an
Internet Exchange Poiint using IPv4 addresses other than those allocated
via 4.4 is otherwise in compliance with this policy they they utilization
formula in 4.4.3 will apply.

That also allows an IXP to request a /24 via 4.10 for their legitimate
operational needs if so inclined by fulfilling those requirements.

Seems like a happy place is close, subject to how the TLD/root people
interpret the other parts.

-M<
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20250308/d9ebe523/attachment.htm>