[arin-ppml] Revised - Draft Policy ARIN-2025-1: Clarify ISP and LIR definitions and references to address ambiguity in NRPM text

[Martin Hannigan]

A redline would be useful and easier to understand the ask accompanying
such a large post.

Warm regards,

-M<



On Wed, Mar 19, 2025 at 16:22 ARIN <info at arin.net> wrote:

> The following Draft Policy has been revised:
>
> *Draft Policy 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/
>
> 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 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,
> removing an ambiguous word and clarification on usage for the term LIR,
> removing an ambiguous terminology statement in Section 6.5.1a, and changing
> terms in Section 6.5 to explicitly state it applies to “LIR/ISP,” thus
> fulfilling the original intent of 6.5.1a, in all appropriate locations.
>
> 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.
>
> Add definition for ISP:
>
> 2.18 Internet Service Provider
>
> An Internet Service Provider (ISP) is a type of LIR 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]”
>
> Change all references in section 6.5 to use LIR/ISP, where appropriate:
>
> [Editing note: For the purposes of clarity in plaintext communication
> mediums, any addition of LIR or ISP 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 add ISP and LIR in 15 locations
>
> 6.5.2. Initial Allocation to LIRs_/ISPs_
>
> 6.5.2.1. Size
>
> 1. All allocations shall be made on nibble boundaries.
>
> 2. In no case shall an LIR_/ISP_ receive smaller than a /32 unless they
> specifically request a /36 or /40. In order to be eligible for a /40, an
> _LIR/_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 _LIR/_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/3serving sites and Y is a multiple of 4 greater than 4/3end 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 LIR_/ISP_ which has
> subordinate LIRs_/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 LIR_/ISP_. LIRs_/ISPs_ which do not receive
> resources directly from ARIN will not be able to make such reallocations to
> subordinate LIRs_/ISPs_ and subordinate LIRs_/ISPs_ which need more than a
> /32 shall apply directly to ARIN.
>
> 6. An LIR_/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 LIR_/ISP_ is entitled.
>
> 7. An LIR_/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 LIR_/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 _LIR/_ISP’s current or former
> IPv4 address holdings.
>
> Amend Section 6.5.2.2 to add LIR in 2 locations:
>
> 6.5.2.2. Qualifications
>
> An organization qualifies for an allocation under this policy if they meet
> any of the following criteria:
>
> 1. Have a previously justified IPv4 _LIR/_ISP allocation from ARIN or one
> of its predecessor registries or can qualify for an IPv4 _LIR/_ISP
> allocation under current criteria.
>
> 2. Are currently multihomed for IPv6 or will immediately become multihomed
> for IPv6 using a valid assigned global AS number. In either case, they will
> be making reassignments or reallocations from allocation(s) under this
> policy to other organizations.
>
> 3. Provide ARIN a reasonable technical justification indicating why an
> allocation is necessary. Justification must include the intended purposes
> for the allocation and describe the network infrastructure the allocation
> will be used to support. Justification must also include a plan detailing
> anticipated reassignments and reallocations to other organizations or
> customers for one, two and five year periods, with a minimum of 50
> assignments within 5 years.
>
> Amend Section 6.5.3 to add ISP in 4 locations:
>
> 6.5.3. Subsequent Allocations to LIRs_/ISPs_
>
> 1. Where possible ARIN will make subsequent allocations by expanding the
> existing allocation.
>
> 2. An LIR_/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
> LIR_/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 LIR_/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 add ISP in 1 location:
>
> 6.5.4.1. Reassignment to Operator’s Infrastructure
>
> An LIR_/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.5 to add LIR in 1 location:
>
> 6.5.5. Registration
>
> _LIRs/_ISPs 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.
>
> Amend Section 6.5.5.4 to add LIR in 1 location:
>
> 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 _LIR/_ISP shall register that assignment as described in
> section 6.5.5.1.
>
> Amend Section 6.5.7 to add ISP in 1 location:
>
> 6.5.7. Existing IPv6 Address Space Holders
>
> LIRs_/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.9 to add LIR and ISP in 2 locations:
>
> 6.5.9. Community Network Allocations
>
> While community networks would normally be considered to be LIR/ISP type
> organizations under existing ARIN criteria, they tend to operate on much
> tighter budgets and often depend on volunteer labor. As a result, they tend
> to be much smaller and more communal in their organization rather than
> provider/customer relationships of commercial ISPs. This section seeks to
> provide a policy that is more friendly to those environments by allowing
> community network to receive a smaller allocation than other LIRs or
> commercial ISPs. Community networks may also qualify under section 6.5.2 as
> a regular LIR/ISP.
>
> Amend Section 6.5.9.2 to add ISP in 1 location:
>
> 6.5.9.2. Allocation Size
>
> Community networks are eligible only to receive an allocation of /40 of
> IPv6 resources under this section. Community networks that wish to receive
> a larger initial allocation or any subsequent allocations must qualify as a
> regular LIR_/ISP_, see sections 6.5.2 or 6.5.3 respectively.
>
> Amend Section 6.5.9.3 to add ISP in 1 location:
>
> 6.5.9.3. Reassignments by Community Networks
>
> Similar to other LIRs_/ISPs_, Community networks shall make reassignments
> to end-users in accordance with applicable policies, in particular, but not
> limited to sections 6.5.4 and 6.5.5. However, they shall not reallocate
> resources under this section.
>
> 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20250319/9eda0de5/attachment.htm>