[arin-ppml] Draft Policy ARIN-2025-1: Clarify ISP and LIR Definitions and References to Address Ambiguity in NRPM Text

[Scott Leibrand]

You have a typo in the replacement for 6.5.2. Initial Allocation to LIRs,
which should read 6.5.2. Initial Allocation to LIRs_/ISPs_, not LIR_/ISPs_
(which removes the plural from LIRs). The same mistake also occurs in
6.5.7. Existing IPv6 Address Space Holders and 6.5.9.3. Reassignments by
Community Networks, where you now have "LIR_/ISPs_"

What is the reason to remove the word “primarily” from the definition of
LIR? Depending on interpretation, that seems like it could be a substantive
change in how strict ARIN is about LIRs'/ISPs' internal uses of addresses.

-Scott


On Wed, Jan 29, 2025 at 2:33 PM ARIN <info at arin.net> wrote:

> On 24 January 2025, the ARIN Advisory Council (AC) accepted
> “ARIN-prop-339: Clarify ISP and LIR Definitions and References to Address
> Ambiguity in NRPM Text” as Draft Policy.
>
> Draft Policy ARIN-2025-1 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 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,
> 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. The term LIR originates from and is in more common use
> in other RIR regions.
>
>
>
> 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 LIR_/ISPs_
>
> 6.5.2.1. Size
>
> All allocations shall be made on nibble boundaries.
>
> 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.
>
> 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.
>
> 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.
>
> For purposes of the calculation in (c), an LIR_/ISP_ which has subordinate
> LIR_/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_. LIR_/ISPs_ which do not receive resources
> directly from ARIN will not be able to make such reallocations to
> subordinate LIR_/ISPs_ and subordinate LIR_/ISPs_ which need more than a
> /32 shall apply directly to ARIN.
>
> 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.
>
> 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:
>
> 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.
>
> 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.
>
> 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 LIR_/ISPs_
>
> Where possible ARIN will make subsequent allocations by expanding the
> existing allocation.
>
> 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
>
> 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.
>
> 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
>
> _LIR/_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
>
> LIR_/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 LIR_/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.
>
>
> Comments:
>
> This proposal was submitted after the abandonment of Proposal 2024-6,
> which proposed clarifying 6.5.1a’s language. The community feedback
> indicated a more explicit approach was desired to remove ambiguity,
> resulting in this follow up proposal.
>
> The changes in Section 6.5 adding LIR or ISP were reviewed with the
> context of each reference in mind, and only those that clearly fit the
> contextual change of needing the “LIR/ISP” definition were included. This
> did not necessarily include every reference to LIR or ISP in Section 6.5
>
> 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/20250129/b79621ff/attachment-0001.htm>