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.

Reply via email to