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 <[email protected]> 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 ([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.
