This looks good to me. Thanks Leif.
Eric C. Landgraf
Virginia Tech
On May 18 18:38, Leif Sawyer via ARIN-PPML wrote:
> I guess this isn’t as much fun as TIPTOP, but hopefully the minor changes
> help with readability (i.e., expanding the first use of acronyms in
> paragraphs, removing broken parentheticals, etc)
>
> Any last concerns from the community before we ship this off to staff and
> legal review?
>
> -L
>
> Leif Sawyer
> GCI | he/him | Engineer IV, CNI – Standards and Planning
> t: 907-351-1535 | w: www.gci.com<https://www.gci.com> | KL5BN
>
> From: ARIN-PPML <[email protected]> On Behalf Of ARIN
> Sent: Thursday, May 7, 2026 1:01 PM
> To: [email protected]
> Subject: [arin-ppml] Revised - Draft Policy ARIN-2025-1: Clarify ISP and LIR
> Definitions and References to Address Ambiguity in NRPM Text
>
> [EXTERNAL EMAIL - CAUTION: Do not open unexpected attachments or links.]
>
> 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/<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_050726.pdf<https://arin.net/participate/policy/drafts/pdf/ARIN_2025_1_diff_050726.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/<https://www.arin.net/participate/policy/pdp>
>
> Draft Policies and Proposals under discussion can be found at:
>
> https://www.arin.net/participate/policy/drafts/<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
> reframing and aligning with the term LIR, and replaces ISP with LIR
> throughout the NRPM as appropriate.
>
> Policy Statement:
>
> Update the Table of Contents, replacing ISP with Local Internet Registries as
> follows:
>
> 4.2. Allocations to Local Internet Registries
>
> 4.2.2. Initial Allocation to Local Internet Registries
>
> 4.2.3.4.2. Downstream Local Internet Registries
>
> 4.2.4. Local Internet Registry Additional Requests
>
> 6.5.4. Reassignments from Local Internet Registries
>
>
>
> Section 2:
>
> Rewrite the LIR definition to provide clarity and relationship to ISP
>
> 2.4. Local Internet Registry (LIR)
>
> A Local Internet Registry (LIR) is an Internet Registry that is a member of
> an RIR, receives allocations of internet numbers from that RIR, for
> allocation to its customers, end-users, and infrastructure, at a local level.
> LIRs include Internet Service Providers (ISPs) whose customers are primarily
> end users and possibly other ISPs. Historically in the ARIN service region
> "ISP" was used as an equivalent, albeit incomplete, term.
>
>
>
> Replace ISP with Local Internet Registry:
>
> 2.15. Provider Assignment Unit (IPv6)
>
> When applied to IPv6 policies, the term “provider assignment unit” shall mean
> the prefix of the smallest block a given Local Internet Registry assigns to
> end sites (recommended /48).
>
>
>
> Add new 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.
>
>
>
> Section 3:
>
> Replace first ISP with Local Internet Registry, remaining with LIR
>
> This policy applies to every Organization that has Internet number resources
> issued by ARIN (or one of its predecessor registries) or a reallocation from
> an upstream Local Internet Registry. This includes but is not limited to
> upstream LIRs and their downstream LIR customers, but not reassignments made
> to their downstream end user customers.
>
>
>
> Section 4:
>
> Replace ISP with Local Internet Registry: in the following sections:
>
> 4.2. Allocations to Local Internet Registries (Requirements for Requesting
> Initial Address Space)
>
>
>
> 4.2.1.1<http://4.2.1.1>. Purpose
>
> ARIN allocates blocks of IP addresses to Local Internet Registries for the
> purpose of reassigning and reallocating that space to their customers.
>
>
>
> 4.2.1.5<http://4.2.1.5>. Minimum Allocation
>
> In general, ARIN allocates /24 and larger IP address prefixes to Local
> Internet Registries. If allocations smaller than /24 are needed, LIRs should
> request address space from their upstream provider.
>
>
>
> 4.2.2. Initial Allocation to LIRs
>
> All Local Internet Registry organizations without any IPv4 addresses from
> ARIN automatically qualify for an initial allocation of a /24. LIRs providing
> a 24-month utilization plan for the request size specified may receive up to
> a /22. LIRs holding reallocations and/or reassignments must show the
> efficient utilization of their resources consistent with the requirements in
> sections 4.2.3 and 4.2.4.
>
>
>
> 4.2.3.1<http://4.2.3.1>. Efficient Utilization
>
> Local Internet Registries are required to apply a utilization efficiency
> criterion in providing address space to their customers. To this end, LIRs
> should have documented justification available for each reassignment and
> reallocation. ARIN may request this justification at any time. If
> justification is not provided, future receipt of allocations may be impacted.
>
>
>
> 4.2.3.2<http://4.2.3.2>. VLSM
>
> To increase utilization efficiency of IPv4 address space, Local Internet
> Registries reassigning IP address space to their customers should require
> their customers to use variable length subnet mask (VLSM) and classless
> technologies (CIDR) within their networks. LIRs should issue blocks smaller
> than /24 wherever feasible.
>
>
>
> 4.2.3.3<http://4.2.3.3>. Contiguous Blocks
>
> IP addresses are allocated to Local Internet Registries in contiguous blocks,
> which should remain intact. Fragmentation of blocks is discouraged. To avoid
> fragmentation, LIRs are encouraged to require their customers to return
> address space if they change LIRs. Therefore, if a customer moves to another
> service provider or otherwise terminates a contract with an LIR, it is
> recommended that the customer return the network addresses to the LIR and
> renumber into the new provider's address space. The original LIR should allow
> sufficient time for the renumbering process to be completed before requiring
> the address space to be returned.
>
>
>
> 4.2.3.4<http://4.2.3.4>. Downstream Customer Adherence
>
> Local Internet Registries must require their downstream customers to adhere
> to the following criteria:
>
>
>
> 4.2.3.4.1. Utilization
>
> A downstream customer requesting address space from an upstream Local
> Internet Registry must document a plan to the allocating LIR for their
> utilization to conform to Section 4.3.3. Reassignment and reallocation
> information for prior allocations must show that each customer meets the 80%
> utilization criteria and must be available via SWIP / a distributed service
> which meets the standards set forth in section 3.2 prior to issuing them
> additional space.
>
>
>
> 4.2.3.4.2. Downstream Local Internet Registries
>
> Customers must follow ARIN policy for Local Internet Registries.
>
>
>
> 4.2.3.6<http://4.2.3.6>. Reassignments to Multihomed Downstream Customers
>
> If a downstream customer has a requirement to multihome, that requirement
> alone will serve as justification for a /24 allocation. Downstream customers
> must provide contact information for all of their upstream providers to the
> Local Internet Registry from whom they are requesting a /24, and utilize a
> border routing protocol between the customer and the LIR. Customers may
> receive a /24 from only one of their upstream providers under this policy
> without providing additional justification. LIRs may demonstrate they have
> made an assignment to a downstream customer under this policy by supplying
> ARIN with the information they collected from the customer, as described
> above, or by identifying the AS number of the customer.
>
>
>
> 4.2.3.7<http://4.2.3.7>. Registration
>
> Local Internet Registries are required to demonstrate efficient use of IP
> address space allocations by providing appropriate documentation, including
> but not limited to assignment histories, showing their efficient use.
>
>
>
> 4.2.3.8<http://4.2.3.8>. Reassignments for Third Party Internet Access (TPIA)
> over Cable
>
> IP addresses reassigned by a Local Internet Registry to an incumbent cable
> operator for use with Third Party Internet Access (TPIA) will be counted as
> fully used once they are assigned to equipment by the underlying cable
> carrier provided they meet the following requirements:
>
>
>
> 4.2.4. Local Internet Registry Additional Requests
>
>
> 4.2.4.1<http://4.2.4.1>. Utilization Percentage (80%)
>
> Local Internet Registries must have efficiently utilized all allocations, in
> aggregate, to at least 80% and at least 50% of every allocation in order to
> receive additional space. This includes all space reassigned or reallocated
> to their customers.
>
>
>
> 4.2.4.3<http://4.2.4.3>. Request Size
>
> Local Internet Registries may request up to a 24-month supply of IPv4
> addresses.
>
>
>
> Section 6:
>
> Update terminology section to reference how Internet Service Provider and
> Local Internet Registry are used
>
> 6.5.1. Terminology
>
> a. The terms Internet Service Provider and Local Internet Registry were
> previously used interchangeably in this section. Unless otherwise noted, the
> term ISP is treated as a subset of LIR.
>
>
>
> Replace ISP with Local Internet Registry in the following sections:
>
> 6.5.2.1<http://6.5.2.1> Size
>
> a. All allocations shall be made on nibble boundaries.
>
> b. In no case shall a Local Internet Registry receive smaller than a /32
> unless they specifically request a /36 or /40. In order to be eligible for a
> /40, an LIR 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 LIR receive more than a /16 initial allocation.
>
> g. A Local Internet Registry 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 LIR’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 LIR’s current or former IPv4 address holdings.
>
>
>
> 6.5.2.2<http://6.5.2.2>. Qualifications
>
> An organization qualifies for an allocation under this policy if they meet
> any of the following criteria:
>
> a. Have a previously justified IPv4 allocation from ARIN or one of its
> predecessor registries or can qualify for an IPv4 allocation under current
> criteria.
>
>
>
> 6.5.4. Reassignments from Local Internet Registries
>
> 6.5.5. Registration
>
> Local Internet Registries are required to demonstrate efficient use of IP
> address space allocations by providing appropriate documentation, including
> but not limited to reassignment and reallocation histories, showing their
> efficient use.
>
>
>
> 6.5.5.4<http://6.5.5.4>. Registration Requested by Recipient
>
> If the downstream recipient of a static assignment of /64 or more addresses
> requests publishing of that assignment in ARIN’s registration database, the
> Local Internet Registry shall register that assignment as described in
> section 6.5.5.1<http://6.5.5.1>.
>
>
>
> 6.5.8.1<http://6.5.8.1>. Initial Assignment Criteria
>
> f. By providing a reasonable technical justification indicating why IPv6
> addresses from a Local Internet Registry are unsuitable.
>
>
> _______________________________________________
> ARIN-PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List
> ([email protected]<mailto:[email protected]>).
> Unsubscribe or manage your mailing list subscription at:
> https://lists.arin.net/mailman/listinfo/arin-ppml<https://lists.arin.net/mailman/listinfo/arin-ppml>
> Please contact [email protected]<mailto:[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.
