[arin-ppml] Revised - Draft Policy ARIN-2025-1: Clarify ISP and LIR Definitions and References to Address Ambiguity in NRPM Text
David Farmer
farmer at umn.edu
Sun Sep 14 10:11:19 EDT 2025
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
===============================================
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20250914/ee486dc6/attachment-0001.htm>
More information about the ARIN-PPML
mailing list