2 points of clarification: If you need to use customers to justify your needs requirements then you are considered an ISP.
Everyone receives allocations now so even end users can use Reassignments/reallocations if they require that service. No input on the policy, just clarifications. Sent from my iPhone > On Sep 13, 2025, at 9:39 PM, Owen DeLong via ARIN-PPML <[email protected]> > wrote: > > There are many ways to structure Colo and cloud services that need to be > LIRs but might not meet the definition of ISP. > > Certain large enterprises need to act as LIRs but don’t have external > customers and thus might not meet the definition of ISP. > > I’m sure there are others, but these are the obvious ones that come to mind. > > Owen > > >> On Sep 13, 2025, at 11:17, Jon Lewis <[email protected]> wrote: >> >> Maybe I'm not thinking creatively enough, but can someone give an example >> of how an ARIN member would qualify for direct allocations from ARIN and >> operate as an LIR, but not be an ISP? >> >>>> On Sat, 13 Sep 2025, Martin Hannigan wrote: >>> >>> Hi Owen, >>> What is the difference between using one term or the other? Would it make >>> sense to consolidate to plain language and ubiquitous ISP? >>> Thanks, >>> Martin >>>> On Sat, Sep 13, 2025 at 11:40 AM Owen DeLong via ARIN-PPML >>>> <[email protected]> wrote: >>> 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. >>> >> >> ---------------------------------------------------------------------- >> Jon Lewis, MCP :) | I route >> Blue Stream Fiber, Sr. Neteng | therefore you are >> _________ http://www.lewis.org/~jlewis/pgp for PGP public >> key________________________________________________________ >> 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. _______________________________________________ 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.
