I think this is the wrong approach. In reality, ARIN cares about LIRs and deals with LIRs and end users. It is generally irrelevant from a policy perspective whether a given LIR is an ISP or not.
Therefore, IMHO, a better approach would be to simply consolidate to the LIR term and eliminate ISP from the NRPM. IPv6 policy already explicitly declares that the terms are interchangeable from a policy perspective. Owen > On Sep 12, 2025, at 10:18, ARIN <[email protected]> wrote: > > The following Draft Policy has been revised: > > *ARIN-2025-1: Clarify ISP and LIR Definitions and References to Address > Ambiguity in NRPM Text > > Revised text is below and can be found at: > > https://www.arin.net/participate/policy/drafts/2025_1/ > > A PDF document showing the proposed NRPM edits is available to download at: > > https://arin.net/participate/policy/drafts/pdf/ARIN_2025_1_diff_091225.pdf > > 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-2025-1: Clarify ISP and LIR Definitions and References to > Address Ambiguity in NRPM Text > > Problem Statement: > > Section 2.4 of the NRPM defines an LIR but does not explicitly define an ISP. > An ISP is defined in the context of an LIR, but the explicit definition is > otherwise assumed. > > Through implication and in common business practice, all ISPs are LIRs, but > not all LIRs are ISPs. > > This proposal adds clarity by creating an explicit definition for ISP, > clarifying the historical and out-of-region usage for the term LIR, and > replaces LIR with ISP throughout the NRPM as appropriate. > > Policy Statement: > > Add Internet Service Provider definition: > > Remove the word “primarily” from the definition of LIR and add usage > clarification: > > FROM: > > 2.4. Local Internet Registry (LIR) > > A Local Internet Registry (LIR) is primarily an IR that assigns IP addresses > to the users of the network services that it provides. LIRs are generally > Internet Service Providers (ISPs) whose customers are primarily end users and > possibly other ISPs. > > TO: > > 2.4. Local Internet Registry (LIR) > > A Local Internet Registry (LIR) is an IR that assigns IP addresses to the > users of the network services that it provides. LIRs are generally Internet > Service Providers (ISPs) whose customers are primarily end users and possibly > other ISPs. _While LIR has been historically referenced in policies for ease > of comparing other region's policies, LIR is not used in the ARIN service > region; ISP is the equivalent term._ > > > Add definition for ISP: > > 2.18 Internet Service Provider (ISP) > > An Internet Service Provider (ISP) is a type of organization that provides > Internet services to other organizations, its customers, and\or individuals > other than its employees. Internet services include, but are not limited to, > connectivity services, web services, colocation, dedicated servers, virtual > private servers, and virtual private networks. > > > Replace Section 6.5.1a > > Original Text: “The terms ISP and LIR are used interchangeably in this > document and any use of either term shall be construed to include both > meanings.” > > New Text: “[Retired]” > > > Remove all references in section 6.5 of LIR where appropriate: > > [Editing note: For the purposes of clarity in plaintext communication > mediums, any changes to the text is denoted with the underscore character > before and after the insertion. The underscore character is not considered a > part of the final text.] > > > Amend Section 6.5.2 to replace LIR with ISP, 12 in total > > 6.5.2. Initial Allocation to _ISPs_ > > 6.5.2.1. Size > > 1. All allocations shall be made on nibble boundaries. > > 2. In no case shall an _ISP_ receive smaller than a /32 unless they > specifically request a /36 or /40. In order to be eligible for a /40, an ISP > must meet the following requirements: > > - Hold IPv4 direct allocations totaling a /24 or less (to include zero) > > - Hold IPv4 reassignments/reallocations totaling a /22 or less (to include > zero) > > In no case shall an ISP receive more than a /16 initial allocation. > > 3. The maximum allowable allocation shall be the smallest nibble-boundary > aligned block that can provide an equally sized nibble-boundary aligned block > to each of the requesters serving sites large enough to satisfy the needs of > the requesters largest single serving site using no more than 75% of the > available addresses. > This calculation can be summarized as /N where N = P-(X+Y) and P is the > organization’s Provider Allocation Unit X is a multiple of 4 greater than > 4/3*serving sites and Y is a multiple of 4 greater than 4/3*end sites served > by largest serving site. > > 4. For purposes of the calculation in (c), an end site which can justify more > than a /48 under the end-user assignment criteria in 6.5.8 shall count as > the appropriate number of /48s that would be assigned under that policy. > > 5. For purposes of the calculation in (c), an _ISP_ which has subordinate > _ISPs_ shall make such reallocations according to the same policies and > criteria as ARIN. In such a case, the prefixes necessary for such a > reallocation should be treated as fully utilized in determining the block > sizing for the parent _ISP_. _ISPs_ which do not receive resources directly > from ARIN will not be able to make such reallocations to subordinate _ISPs_ > and subordinate _ISPs_ which need more than a /32 shall apply directly to > ARIN. > > 6. An _ISP_ is not required to design or deploy their network according to > this structure. It is strictly a mechanism to determine the largest IP > address block to which the _ISP_ is entitled. > > 7 An _ISP_ that requests a smaller /36 or /40 allocation is entitled to > expand the allocation to any nibble aligned size up to /32 at any time > without renumbering or additional justification. /40 allocations shall be > automatically upgraded to /36 if at any time said _ISP_’s IPv4 direct > allocations exceed a /24. Expansions up to and including a /32 are not > considered subsequent allocations, however any expansions beyond /32 are > considered subsequent allocations and must conform to section 6.5.3. Partial > returns of any IPv6 allocation that results in less than a /36 of holding are > not permitted regardless of the ISP’s current or former IPv4 address holdings. > > > Amend Section 6.5.3 to replace LIR with ISP in 4 locations: > > 6.5.3. Subsequent Allocations to _ISPs_ > > 1. Where possible ARIN will make subsequent allocations by expanding the > existing allocation. > > 2. An _ISP_ qualifies for a subsequent allocation if they meet any of the > following criteria: > > - Shows utilization of 75% or more of their total address space > > - Shows utilization of more than 90% of any serving site > > - Has allocated more than 90% of their total address space to serving sites, > with the block size allocated to each serving site being justified based on > the criteria specified in section 6.5.2 > > 3. If ARIN can not expand one or more existing allocations, ARIN shall make a > new allocation based on the initial allocation criteria above. The _ISP_ is > encouraged, but not required to renumber into the new allocation over time > and return any allocations no longer in use. > > 4. If an _ISP_ has already reached a /12 or more, ARIN will allocate a single > additional /12 rather than continue expanding nibble boundaries. > > > Amend Section 6.5.4.1 to replace LIR with ISP in 1 location: > > 6.5.4.1. Reassignment to Operator’s Infrastructure > > An _ISP_ may reassign up to a /48 per PoP as well as up to an additional /48 > globally for its own infrastructure. > > > Amend Section 6.5.7 to replace LIR with ISP in 1 location: > > 6.5.7. Existing IPv6 Address Space Holders > > _ISPs_ which received an allocation under previous policies which is smaller > than what they are entitled to under this policy may receive a new initial > allocation under this policy. If possible, ARIN will expand their existing > allocation. > > > Amend Section 6.5.8 to remove “or other LIR” in 2 locations > > 6.5.8.1. Initial Assignment Criteria > > FROM: > > f. By providing a reasonable technical justification indicating why IPv6 > addresses from an ISP or other LIR are unsuitable. > > TO: > > f. By providing a reasonable technical justification indicating why IPv6 > addresses from an ISP are unsuitable. > > > FROM: > > Examples of justifications for why addresses from an ISP or other LIR may be > unsuitable include, but are not limited to: > > TO: > > Examples of justifications for why addresses from an ISP may be unsuitable > include, but are not limited to: > > Timetable for Implementation: Immediate > > > > > _______________________________________________ > 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. _______________________________________________ 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.
