[arin-ppml] Revised - Draft Policy ARIN-2025-1: Clarify ISP and LIR Definitions and References to Address Ambiguity in NRPM Text
Tyler O'Meara
arin at tyleromeara.com
Sun Sep 14 10:36:47 EDT 2025
I agree with what's been said thus far, but I want to propose a (potentially)
radical idea: Do we need to define ISP/LIR/End User at all? Why not have 2
available pathways to justifying a request, and the requesting organization can
just choose whichever is most appropriate for themselves?
Tyler
On Sun, 2025-09-14 at 09:11 -0500, David Farmer via ARIN-PPML wrote:
> The layman's definition of the term ISP (Internet Service Provider) is a
> company that provides individuals and businesses with access to the internet
> and related services, such as email and web hosting. ISPs facilitate your
> connection to the global network, using various technologies like fiber optic,
> cable, DSL, and satellite to deliver their services. Major examples of ISPs
> include Comcast (Xfinity), Verizon, and AT&T.
>
> John, the technical definition you provided makes sense from an ARIN Policy
> perspective. However, that is not the definition provided for ISP by this
> policy. The definition provided in this policy is more like the layman's
> definition.
>
> I think the question the ARIN community needs to ask itself is, "Do all ARIN
> customers that request resources on the basis of the needs of their customers,
> and not the needs of their own organization, want to be known as an ISP?" Many
> organizations that qualify for this technical definition we are talking about
> don't think of themselves as ISPs.
>
> As Owen said, "All ISPs are LIRs, but not all LIRs are ISPs." Or, maybe at
> least all LIRs don't want to be considered as ISPs. This policy effectively
> says they are ISPs regardless of what they think themselves to be.
>
> Attempting to make LIR and ISP have precisely the same meaning, and
> eliminating the term LIR, is an oversimplification and will eliminate
> important nuance of the current policy.
>
> I don't support the policy as written.
>
> Thanks.
>
> On Sat, Sep 13, 2025 at 11:54 PM John Sweeting <jsweeting at arin.net> wrote:
> > 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
> > > <arin-ppml at arin.net> 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 <jlewis at lewis.org> 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
> > > > > > <arin-ppml at arin.net> 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 <info at arin.net> 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 (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.
> > > > >
> > > > > _______________________________________________
> > > > > 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.
> > > > >
> > > >
> > > > ----------------------------------------------------------------------
> > > > 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 (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.
> > >
> > > _______________________________________________
> > > 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.
> > _______________________________________________
> > 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.
>
>
> --
> ===============================================
> David Farmer Email:farmer at umn.edu
> 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 (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.
More information about the ARIN-PPML
mailing list