[{ "number": "ARIN-2025-8", "title": "Reserve 4.10 Space for In-Region Use", "status": "Under Discussion", "recommended": true, "shepherds": ["Kaitlyn Pellak", "E. Marie Brierley"], "problemStatement": "\nARIN 4.10 allocations, reserved to facilitate IPv6 deployment, currently have no restrictions for out-of-region use beyond the general restrictions laid out in Section 9. As the use of these allocations outside of the ARIN region seems to be contrary to the intentions for use of this space - and ARIN staff has interpreted the policy as such - the prohibition of this practice should be codified in policy.\n","policyStatement": "\nChange the second sentence in NRPM Section 4.10 from:\n"This IPv4 allocation will be set aside and dedicated to facilitate IPv6 deployment."\nto:\n"This IPv4 allocation will be set aside and dedicated to facilitate IPv6 deployment within the ARIN service area"\n","implementationTime": "Immediate","fullText": ["## Current Text (14 July 2025)", "### AC Assessment of Conformance with the Principles of Internet Number Resource Policy", "Recommended Draft Policy ARIN-2025-8 conforms to the principles of the ARIN Policy Development Process. This policy, if adopted, clarifies within the NRPM ARIN’s current practices for managing IPv4 addresses allocated to facilitate IPv6 Deployment (IPv4 allocations governed by Section 4.10 in the NRPM). There were concerns from a small subset of the community that the added language was too ambiguous. Follow-ups to both the PPML and at the ARIN 57 in-person meeting did not reveal any additional concerns about the ambiguity of the language in this policy, nor did they yield any suggestions for how the wording could be made less ambiguous. This policy did receive community support both at the most recent ARIN meeting and in prior meetings. We have found this policy to be fair and impartial, and technically sound."", "### Problem Statement", "ARIN 4.10 allocations, reserved to facilitate IPv6 deployment, currently have no restrictions for out-of-region use beyond the general restrictions laid out in Section 9. As the use of these allocations outside of the ARIN region seems to be contrary to the intentions for use of this space - and ARIN staff has interpreted the policy as such - the prohibition of this practice should be codified in policy.", "### Policy Statement", "Change the second sentence in NRPM Section 4.10 from:", ""This IPv4 allocation will be set aside and dedicated to facilitate IPv6 deployment."", "to:", ""This IPv4 allocation will be set aside and dedicated to facilitate IPv6 deployment within the ARIN service area"", "### Timetable for Implementation", "Immediate", "**Comments:** This proposal was prompted by community feedback to Registration Services, as reported in the ARIN 55 Policy Experience Report. ARIN staff has indicated that there is no intention to extend this restriction to 4.10 allocations assigned before the implementation of this policy.", "### Staff and Legal Review (12 November 2025)", "**Staff Understanding:** The current implementation of Section 4.10 (Dedicated IPv4 Allocations to Facilitate IPv6 Deployment) requires that IPv4 addresses be used within the ARIN region. Draft Policy ARIN-2025-8: Reserve 4.10 Space for In-Region Use codifies the current practices applied by ARIN staff when processing requests under Section 4.10. This policy does not alter existing review practices; it formally documents the longstanding approach ARIN staff has used and will continue to apply.", "**Implementable as Written?:** Yes", "**Impact on ARIN Registry Operations and Services:** None", "**Legal Review:** No material legal issue", "**Implementation Timeframe Estimate:** 3 months", "**Implementation Requirements:**", "- Staff Training", "- Updates to public documentation", "- Updates to internal procedures and guidelines", "**Proposal/Draft Policy Text Assessed:** [14 July 2025](https://lists.arin.net/pipermail/arin-ppml/2025-August/038062.html)", "## History and Earlier Versions", "|Action|Date|", "|--- |--- |", "| [Proposal](/participate/policy/proposals/2025/ARIN_prop_347/) | 14 July 2025 |", "| [Draft Policy](https://lists.arin.net/pipermail/arin-ppml/2025-August/038062.html) | 26 August 2025 |", "| [Recommended Draft Policy](https://lists.arin.net/pipermail/arin-ppml/2026-April/038346.html) | 27 April 2026", "## Related Meetings", "### Advisory Council", "- [21 August 2025](/about/welcome/ac/meetings/2025_0821/)", "- [18 September 2025](/about/welcome/ac/meetings/2025_0918/)", "- [31 October 2025](/about/welcome/ac/meetings/2025_1031/)", "- [20 November 2025](/about/welcome/ac/meetings/2025_1120/)", "- [18 December 2025](/about/welcome/ac/meetings/2025_1218/)", "- [30 January 2026](/about/welcome/ac/meetings/2026_0130)", "- [19 February 2026](/about/welcome/ac/meetings/2026_0219)", "- [19 March 2026](/about/welcome/ac/meetings/2026_0319/)", "- [22 April 2026](/about/welcome/ac/meetings/2026_0422/)", "- [21 May 2026](/about/welcome/ac/meetings/2026_0521/)", "- [18 June 2026](/about/welcome/ac/meetings/2026_0618/)", "- 16 July 2026", "- ", "### Board of Trustees", "### ARIN Public Policy Meetings", "- [ARIN 56](/participate/meetings/ARIN56/)", "- [ARIN 57](/participate/meetings/ARIN57/)"], "lastUpdated": "2025-08-26", "url": "https://www.arin.net/participate/policy/drafts/2025_8/" },{ "number": "ARIN-2026-3", "title": "NRPM Section 6.4.1 Retirement", "status": "Under Discussion", "recommended": false, "shepherds": ["E. Marie Brierley", "Gerry George"], "problemStatement": "\nCurrent NRPM Section 6.4.1 contains language referring to property rights of IPv6 direct allocations made by ARIN. Past references to any rights on IP resources was defined in legacy versions of the Resource Services Agreement between an entity and ARIN. Any mention of property or other rights do not belong in the Number Resource Policy Manual, this should be referenced in the Registration Services Agreement. Section 6 of the Number Resource Policy Manual was modeled on a framework the other RIRs added to their policy manuals going back as far as 2004.\n","policyStatement": "\nRetire 6.4.1 Address Space Not to be Considered Property\n## History and Earlier Versions\n|Action|Date|\n|--- |--- |\n| [Proposal](/participate/policy/proposals/2026/ARIN_prop_351/) | 11 June 2026 |\n| Draft Policy | 21 July 2026 |\n## Related Meetings\n","fullText": ["## Current Text (11 June 2026)", "### Problem Statement", "Current NRPM Section 6.4.1 contains language referring to property rights of IPv6 direct allocations made by ARIN. Past references to any rights on IP resources was defined in legacy versions of the Resource Services Agreement between an entity and ARIN. Any mention of property or other rights do not belong in the Number Resource Policy Manual, this should be referenced in the Registration Services Agreement. Section 6 of the Number Resource Policy Manual was modeled on a framework the other RIRs added to their policy manuals going back as far as 2004.", "### Policy Statement", "Retire 6.4.1 Address Space Not to be Considered Property", "## History and Earlier Versions", "|Action|Date|", "|--- |--- |", "| [Proposal](/participate/policy/proposals/2026/ARIN_prop_351/) | 11 June 2026 |", "| Draft Policy | 21 July 2026 |", "## Related Meetings", "### Advisory Council", "- 16 July 2026", " ", "### Board of Trustees", "### ARIN Public Policy Meetings"], "lastUpdated": "2025-08-26", "url": "https://www.arin.net/participate/policy/drafts/2026_3/" },{ "number": "ARIN-2026-2", "title": "NRPM Section 6.5 Revision", "status": "Under Discussion", "recommended": false, "shepherds": ["Matthew Wilder", "Alicia Trotman"], "problemStatement": "\nCurrent NRPM Section 6.5 contains allocation mechanisms that are complex and formula driven. These mechanisms include rigid sizing calculations, utilization-based thresholds, and IPv4-dependent qualification criteria.\nIPv6 deployment is based on hierarchical planning, aggregation, and projected growth.\nARIN’s IPv6 network planning guide emphasizes structured planning instead of mathematical formulas, including the use of hierarchical addressing, aggregation, and multi-year growth projections.\nThe current policy is complex, is difficult for applicants to interpret consistently and does not align with ARIN’s published guidance.\n","policyStatement": "\n: Modify NRPM Section 6.5 (IPv6 Allocations) to simplify allocation criteria and align policy with IPv6 network planning practices.\nThe revised policy replaces formula-based and utilization-based allocation mechanisms with a planning-based evaluation model.\nUnder this model:\n- Eligibility is based on demonstrated operational requirements for IPv6 address space, including service provider operations, multihoming, and internal infrastructure needs\n- All requests must include a network plan describing intended addressing use, hierarchical structure, and projected growth over defined time horizons\n- Allocation sizes are determined based on the documented network plan and need for aggregation and contiguous growth\n- Subsequent allocations are based on demonstrated implementation consistent with prior plans and updated growth projections\n- End-user allocations and LIR allocations are evaluated using consistent planning-based criteria appropriate to their operational context\nSection 6.5: IPv6 Allocations\n6.5 Policies for IPv6 Address Space\nIPv6 address space is issued to support scalable, hierarchical network design, efficient aggregation, and long-term operational requirements.\nIPv6 policy emphasizes minimizing fragmentation of the global routing table and supporting structured network growth.\n6.5.1 Eligibility\nAn organization is eligible to receive IPv6 address space if it meets one or more of the following criteria:\na. It operates as a Local Internet Registry (LIR) or intends to make reallocations to downstream networks or customers; or \nb. It operates infrastructure or internal networks that require provider-independent IPv6 address space to meet operational or architectural requirements.\n6.5.2 Network Plan Requirements\nRequests for IPv6 address space must include a documented network plan. Consistent with IPv6 network planning best practices, the plan must:\na. Identify typical assignment sizes for your remote sites or customers (e.g., /48, /56, or /64); \nb. Describe the addressing hierarchy and logical structure of the network; \nc. Provide projected utilization of addressing units at approximately 1-year, 2-year, and 5-year intervals.\n6.5.3 Initial Allocation to LIRs\nAn organization acting as a Local Internet Registry (LIR) may receive an initial IPv6 allocation when it demonstrates a requirement to make assignments or reallocations to downstream networks or customers.\nInitial allocation requests must include a network plan that:\na. Identifies the intended customer or downstream assignment model, including typical prefix sizes; \nb. Describes how address space will be distributed across the network to support aggregation; \nc. Provides projected growth in the number of assignments or sites over approximately 1-year, 2-year, and 5-year intervals.\nIn evaluating initial allocation requests, ARIN will consider:\ni. The anticipated number and type of downstream assignments; \nii. The need to support hierarchical addressing and route aggregation; \niii. The ability to accommodate growth through contiguous address space.\nInitial allocations will be issued at sizes sufficient to support the documented plan and allow for efficient expansion. Assignments will be no smaller than a /48, unless the documented network plan justifies a different size.\n6.5.4 Subsequent Requests\nTo ensure scalable growth while maintaining registry integrity, additional IPv6 address space may be granted when an organization demonstrates:\na. The organization has assigned or reallocated at least 75% of the prefix units defined in its current 2-year network plan; \nb. Documented evidence that the address space has been deployed according to the hierarchical structure previously submitted, or a technical justification for architectural changes; \nc. A revised network plan showing projected requirements for additional prefix units over a new 5-year horizon; \nd. The request supports the continued aggregation of prefixes. To minimize global routing table growth, ARIN will—whenever possible—issue additional space contiguously by extending the organization’s existing allocation.\n6.5.5 Deployment Timeline\nOrganizations are expected to begin using issued IPv6 address space within 12 months of issuance.\n6.5.6 End-User Allocations (Provider-Independent)\nEnd-user organizations may receive provider-independent (PI) IPv6 address space when they demonstrate a need for stable, non-provider-dependent addressing for internal infrastructure or operational continuity.\nRequests must include a documented network plan that:\na. Identifies the number of sites and associated addressing requirements; \nb. Describes the internal addressing structure, including segmentation of infrastructure, services, and end systems; \nc. Supports hierarchical addressing and aggregation within the organization; \nd. Includes projected growth in addressing requirements over approximately 1-year, 2-year, and 5-year intervals.\nInitial allocations will be issued on nibble boundaries and will be based on the organization’s network plan and projected growth.\nIn evaluating requests, ARIN will consider:\ni. The number and type of sites or operational units; \nii. The need to support internal hierarchy and segmentation; \niii. The ability to accommodate growth without renumbering.\nAllocations will be issued at sizes sufficient to support the documented plan and allow for efficient expansion.\n6.5.7 Registration (Whois/RDAP)\nOrganizations must maintain records sufficient to document their use of IPv6 address space.\nReassignments or reallocations to external entities of a /64 or larger must be registered in ARIN’s directory services, in accordance with applicable requirements.\n## History and Earlier Versions\n|Action|Date|\n|--- |--- |\n| [Proposal](/participate/policy/proposals/2026/ARIN_prop_350/) | 4 May 2026 |\n| [Draft Policy](https://lists.arin.net/pipermail/arin-ppml/2026-June/038394.html) | 24 June 2026 |\n## Related Meetings\n","fullText": ["## Current Text (4 May 2026)", "### Problem Statement", "Current NRPM Section 6.5 contains allocation mechanisms that are complex and formula driven. These mechanisms include rigid sizing calculations, utilization-based thresholds, and IPv4-dependent qualification criteria.", "IPv6 deployment is based on hierarchical planning, aggregation, and projected growth.", "ARIN’s IPv6 network planning guide emphasizes structured planning instead of mathematical formulas, including the use of hierarchical addressing, aggregation, and multi-year growth projections.", "The current policy is complex, is difficult for applicants to interpret consistently and does not align with ARIN’s published guidance.", "### Policy Statement", "Policy Statement: Modify NRPM Section 6.5 (IPv6 Allocations) to simplify allocation criteria and align policy with IPv6 network planning practices.", "The revised policy replaces formula-based and utilization-based allocation mechanisms with a planning-based evaluation model.", "Under this model:", "- Eligibility is based on demonstrated operational requirements for IPv6 address space, including service provider operations, multihoming, and internal infrastructure needs", "- All requests must include a network plan describing intended addressing use, hierarchical structure, and projected growth over defined time horizons", "- Allocation sizes are determined based on the documented network plan and need for aggregation and contiguous growth", "- Subsequent allocations are based on demonstrated implementation consistent with prior plans and updated growth projections", "- End-user allocations and LIR allocations are evaluated using consistent planning-based criteria appropriate to their operational context", "Section 6.5: IPv6 Allocations", "6.5 Policies for IPv6 Address Space", "IPv6 address space is issued to support scalable, hierarchical network design, efficient aggregation, and long-term operational requirements.", "IPv6 policy emphasizes minimizing fragmentation of the global routing table and supporting structured network growth.", "6.5.1 Eligibility", "An organization is eligible to receive IPv6 address space if it meets one or more of the following criteria:", "a. It operates as a Local Internet Registry (LIR) or intends to make reallocations to downstream networks or customers; or ", "b. It operates infrastructure or internal networks that require provider-independent IPv6 address space to meet operational or architectural requirements.", "6.5.2 Network Plan Requirements", "Requests for IPv6 address space must include a documented network plan. Consistent with IPv6 network planning best practices, the plan must:", "a. Identify typical assignment sizes for your remote sites or customers (e.g., /48, /56, or /64); ", "b. Describe the addressing hierarchy and logical structure of the network; ", "c. Provide projected utilization of addressing units at approximately 1-year, 2-year, and 5-year intervals.", "6.5.3 Initial Allocation to LIRs", "An organization acting as a Local Internet Registry (LIR) may receive an initial IPv6 allocation when it demonstrates a requirement to make assignments or reallocations to downstream networks or customers.", "Initial allocation requests must include a network plan that:", "a. Identifies the intended customer or downstream assignment model, including typical prefix sizes; ", "b. Describes how address space will be distributed across the network to support aggregation; ", "c. Provides projected growth in the number of assignments or sites over approximately 1-year, 2-year, and 5-year intervals.", "In evaluating initial allocation requests, ARIN will consider:", "i. The anticipated number and type of downstream assignments; ", "ii. The need to support hierarchical addressing and route aggregation; ", "iii. The ability to accommodate growth through contiguous address space.", "Initial allocations will be issued at sizes sufficient to support the documented plan and allow for efficient expansion. Assignments will be no smaller than a /48, unless the documented network plan justifies a different size.", "6.5.4 Subsequent Requests", "To ensure scalable growth while maintaining registry integrity, additional IPv6 address space may be granted when an organization demonstrates:", "a. The organization has assigned or reallocated at least 75% of the prefix units defined in its current 2-year network plan; ", "b. Documented evidence that the address space has been deployed according to the hierarchical structure previously submitted, or a technical justification for architectural changes; ", "c. A revised network plan showing projected requirements for additional prefix units over a new 5-year horizon; ", "d. The request supports the continued aggregation of prefixes. To minimize global routing table growth, ARIN will—whenever possible—issue additional space contiguously by extending the organization’s existing allocation.", "6.5.5 Deployment Timeline", "Organizations are expected to begin using issued IPv6 address space within 12 months of issuance.", "6.5.6 End-User Allocations (Provider-Independent)", "End-user organizations may receive provider-independent (PI) IPv6 address space when they demonstrate a need for stable, non-provider-dependent addressing for internal infrastructure or operational continuity.", "Requests must include a documented network plan that:", "a. Identifies the number of sites and associated addressing requirements; ", "b. Describes the internal addressing structure, including segmentation of infrastructure, services, and end systems; ", "c. Supports hierarchical addressing and aggregation within the organization; ", "d. Includes projected growth in addressing requirements over approximately 1-year, 2-year, and 5-year intervals.", "Initial allocations will be issued on nibble boundaries and will be based on the organization’s network plan and projected growth.", "In evaluating requests, ARIN will consider:", "i. The number and type of sites or operational units; ", "ii. The need to support internal hierarchy and segmentation; ", "iii. The ability to accommodate growth without renumbering.", "Allocations will be issued at sizes sufficient to support the documented plan and allow for efficient expansion.", "6.5.7 Registration (Whois/RDAP)", "Organizations must maintain records sufficient to document their use of IPv6 address space.", "Reassignments or reallocations to external entities of a /64 or larger must be registered in ARIN’s directory services, in accordance with applicable requirements.", "## History and Earlier Versions", "|Action|Date|", "|--- |--- |", "| [Proposal](/participate/policy/proposals/2026/ARIN_prop_350/) | 4 May 2026 |", "| [Draft Policy](https://lists.arin.net/pipermail/arin-ppml/2026-June/038394.html) | 24 June 2026 |", "## Related Meetings", "### Advisory Council", "- [18 June 2026](/about/welcome/ac/meetings/2026_0618/)", "- 16 July 2026", " ", "### Board of Trustees", "### ARIN Public Policy Meetings"], "lastUpdated": "2025-08-26", "url": "https://www.arin.net/participate/policy/drafts/2026_2/" },{ "number": "ARIN-2026-1", "title": "Taking IP To Other Planets (TIPTOP)", "status": "Under Discussion", "recommended": false, "shepherds": ["Alison Wood", "Brian Jones"], "problemStatement": "\nOrganizations conducting space exploration missions are deploying IP-based networking infrastructure beyond Earth orbit, including on the Moon and in other deep-space environments. These networks currently utilize address space allocated independently from multiple RIRs, including ARIN.\nAs international missions expand and networks operated by multiple agencies interconnect to share communications infrastructure and provide operational redundancy, the use of unrelated terrestrial address allocations introduces routing scalability concerns. Existing allocations are not aligned with the topology of outer space communications networks, which may require the advertisement of numerous disaggregated prefixes when networks interconnect.\nOuter space communications infrastructure is expected to develop around natural clusters near celestial bodies, with limited communication links between those regions. Addressing structures that reflect these topological boundaries could improve route aggregation and long-term routing scalability.\nImplementation of any such addressing framework would depend upon broader coordination within the Internet technical and registry communities, including determination by the IETF and IANA that dedicated address resources and registry coordination are necessary, concurrence among the RIRs regarding operational responsibilities, and a determination by the ARIN Board of Trustees that participation is consistent with ARIN’s mission.\nFor the purposes of this policy, outer space includes the Moon and regions beyond Earth orbit, but excludes low Earth orbit (LEO) and geostationary Earth orbit (GEO).\n","policyStatement": "\nARIN may allocate IPv4 and IPv6 address space to organizations operating IP networking infrastructure in outer space, including beyond Earth orbit and on the Moon. Allocations are intended to support interagency connectivity, operational redundancy, and scalable routing in emerging space networks.\nAddressing structures should be organized hierarchically to reflect major celestial regions—such as the Moon, Earth–Moon Lagrange points, asteroid belt, and other planetary systems—enabling route aggregation where feasible. Participation in aggregation is voluntary, and organizations may advertise more specific prefixes when necessary.\nThis policy applies to government, research, and commercial space operators, and encourages coordination among agencies to facilitate efficient address usage and scalable routing for outer space networks.\nDefinitions (Add to NRPM Section 2)\n2.xx Extra-Terrestrial Network (ETN) An ETN is defined as any IP-based networking infrastructure operating physically beyond the Geostationary Earth Orbit (GEO) arc, including but not limited to Lunar, Martian, or deep-space deployments.\nIPv4 Policy (Add to NRPM Section 4)\n4.11 IPv4 Allocations for Extra-Terrestrial Networks ARIN shall maintain a dedicated pool or specific registration guidelines for organizations operating ETNs to ensure routing scalability.\n4.11.1 Eligibility: Applicants must demonstrate a direct operational requirement for networking infrastructure located beyond Earth’s orbit. Eligible entities include government agencies, research institutions, and commercial operators.\n4.11.2 Topological Hierarchy: To prevent global routing table exhaustion, allocations for ETNs should be issued from contiguous blocks where possible, designated by "Celestial Regions" (e.g., Luna, Mars, Lagrange Points).\n4.11.3 Utilization Requirements: Standard utilization requirements (Section 4.2.4) apply, but ARIN may grant exceptions for high-latency "cold storage" nodes or orbital relay constellations where traditional "active host" pings are impractical for verification.\nIPv6 Policy (Add to NRPM Section 6)\n6.12 IPv6 Allocations for Extra-Terrestrial Networks Due to the vast distances and high-latency nature of deep-space communications, IPv6 is the preferred protocol for ETN deployments.\n6.12.1 Minimum Allocation: The minimum allocation size for an ETN operator shall be a /48, or a size sufficient to allow for hierarchical subnetting per celestial body.\n6.12.2 Planetary Aggregation: Organizations are encouraged to aggregate all prefixes within a specific gravity well or orbital system to a single aggregate route for advertisement back to Terrestrial Ground Stations (TGS).\n6.12.3 Sparse Allocation: ARIN will employ sparse allocation techniques within the ETN block to allow for the future growth of lunar and planetary colonies without fragmenting the space.\n**Comments:** This is being proposed jointly with the IETF TIPTOP working group. Please see https://datatracker.ietf.org/doc/draft-li-tiptop-address-space/ and https://datatracker.ietf.org/doc/draft-many-tiptop-ip-architecture/ for more details.\n","fullText": ["## Current Text (27 May 2026)", "### Problem Statement", "Organizations conducting space exploration missions are deploying IP-based networking infrastructure beyond Earth orbit, including on the Moon and in other deep-space environments. These networks currently utilize address space allocated independently from multiple RIRs, including ARIN.", "As international missions expand and networks operated by multiple agencies interconnect to share communications infrastructure and provide operational redundancy, the use of unrelated terrestrial address allocations introduces routing scalability concerns. Existing allocations are not aligned with the topology of outer space communications networks, which may require the advertisement of numerous disaggregated prefixes when networks interconnect.", "Outer space communications infrastructure is expected to develop around natural clusters near celestial bodies, with limited communication links between those regions. Addressing structures that reflect these topological boundaries could improve route aggregation and long-term routing scalability.", "Implementation of any such addressing framework would depend upon broader coordination within the Internet technical and registry communities, including determination by the IETF and IANA that dedicated address resources and registry coordination are necessary, concurrence among the RIRs regarding operational responsibilities, and a determination by the ARIN Board of Trustees that participation is consistent with ARIN’s mission.", "For the purposes of this policy, outer space includes the Moon and regions beyond Earth orbit, but excludes low Earth orbit (LEO) and geostationary Earth orbit (GEO).", "### Policy Statement", "ARIN may allocate IPv4 and IPv6 address space to organizations operating IP networking infrastructure in outer space, including beyond Earth orbit and on the Moon. Allocations are intended to support interagency connectivity, operational redundancy, and scalable routing in emerging space networks.", "Addressing structures should be organized hierarchically to reflect major celestial regions—such as the Moon, Earth–Moon Lagrange points, asteroid belt, and other planetary systems—enabling route aggregation where feasible. Participation in aggregation is voluntary, and organizations may advertise more specific prefixes when necessary.", "This policy applies to government, research, and commercial space operators, and encourages coordination among agencies to facilitate efficient address usage and scalable routing for outer space networks.", "Definitions (Add to NRPM Section 2)", "2.xx Extra-Terrestrial Network (ETN) An ETN is defined as any IP-based networking infrastructure operating physically beyond the Geostationary Earth Orbit (GEO) arc, including but not limited to Lunar, Martian, or deep-space deployments.", "IPv4 Policy (Add to NRPM Section 4)", "4.11 IPv4 Allocations for Extra-Terrestrial Networks ARIN shall maintain a dedicated pool or specific registration guidelines for organizations operating ETNs to ensure routing scalability.", "4.11.1 Eligibility: Applicants must demonstrate a direct operational requirement for networking infrastructure located beyond Earth’s orbit. Eligible entities include government agencies, research institutions, and commercial operators.", "4.11.2 Topological Hierarchy: To prevent global routing table exhaustion, allocations for ETNs should be issued from contiguous blocks where possible, designated by "Celestial Regions" (e.g., Luna, Mars, Lagrange Points).", "4.11.3 Utilization Requirements: Standard utilization requirements (Section 4.2.4) apply, but ARIN may grant exceptions for high-latency "cold storage" nodes or orbital relay constellations where traditional "active host" pings are impractical for verification.", "IPv6 Policy (Add to NRPM Section 6)", "6.12 IPv6 Allocations for Extra-Terrestrial Networks Due to the vast distances and high-latency nature of deep-space communications, IPv6 is the preferred protocol for ETN deployments.", "6.12.1 Minimum Allocation: The minimum allocation size for an ETN operator shall be a /48, or a size sufficient to allow for hierarchical subnetting per celestial body.", "6.12.2 Planetary Aggregation: Organizations are encouraged to aggregate all prefixes within a specific gravity well or orbital system to a single aggregate route for advertisement back to Terrestrial Ground Stations (TGS).", "6.12.3 Sparse Allocation: ARIN will employ sparse allocation techniques within the ETN block to allow for the future growth of lunar and planetary colonies without fragmenting the space.", "**Comments:** This is being proposed jointly with the IETF TIPTOP working group. Please see https://datatracker.ietf.org/doc/draft-li-tiptop-address-space/ and https://datatracker.ietf.org/doc/draft-many-tiptop-ip-architecture/ for more details.", "### Staff and Legal Review (1 April 2026)", "**Staff Understanding:** The Draft Policy seeks to establish provisions within the NRPM for the allocation of address space to organizations operating IP networking infrastructure beyond Earth orbit (Extraterrestrial Networks, or ETNs). The Draft Policy introduces definitions, eligibility criteria, and allocation practices intended to support routing scalability through hierarchical addressing aligned with celestial regions.", "Specifically, the Draft Policy calls for:", "- A. Establishment of a dedicated allocation pool or registration guidelines within ARIN for address space used by networks operating in outer space.", "- B. Introduction of new definitions and eligibility criteria for Extraterrestrial Networks (ETNs) within the NRPM.", "- C. Development of allocation practices intended to facilitate routing aggregation for deep-space networking environments, including hierarchical addressing aligned with celestial regions.", "Per discussion on ARIN-PPML, the Draft Policy appears primarily motivated by concerns regarding current operational practices among space agencies deploying deep-space networking infrastructure. In particular, the Draft Policy seeks to address current use of address space from existing allocations without coordination for long-term routing aggregation across shared deep-space communications infrastructure and to establish a coordinated addressing framework intended to improve routing scalability in such environments.", "The Draft Policy amends the NRPM directly and therefore falls within the procedural scope of ARIN’s Policy Development Process (PDP). However, it raises several considerations related to clarity, implementability, and alignment with ARIN’s role in the Internet number resource system.", "The Draft Policy seeks to improve routing aggregation through coordinated allocation practices for ETNs from dedicated, contiguous address blocks reserved for deep-space use. Without such address space, networks built using ad hoc IPv4 and IPv6 allocations would not support meaningful aggregation. Accordingly, the availability and source of dedicated address space are prerequisites for achieving the Draft Policy’s stated objectives and should be clearly specified as an underlying assumption of the policy.", "The IETF could direct IANA to allocate dedicated address space for this purpose, including coordination with the RIR system for appropriate allocation and registry services for the relevant operational community (including, for example, interim administration by an existing RIR of registry and policy development functions until such time as the establishment of a distinct Internet number registry organization by that community).", "While ARIN served a "rest of world" role at the time of its formation (i.e., requests not handled specifically by RIPE NCC or APNIC were handled by ARIN), it is not clear that the ARIN Board would consider ARIN serving as the "default" registry for this purpose, even on an interim basis, to fall within the scope of ARIN’s current mission. If the Board were to determine that providing such services is compatible with ARIN’s mission (e.g., until such time as there is a deep-space Internet Number Registry organization), then ARIN could provide such services pursuant to policy recommended by the community and adopted by the Board. Such a determination would likely depend on both community sentiment and explicit acknowledgment by the other RIRs that such a role is acceptable.", "The Draft Policy, as written, presumes that these prerequisite conditions have already been satisfied, and these conditions should be clearly stated in the policy to provide a shared understanding of the circumstances under which the policy could be adopted: (a) that the IETF has determined that a dedicated address block is required; (b) that IANA has allocated appropriate IPv6 and/or IPv4 address space for this purpose and coordinated with the RIRs to provide operational registry services for that space; (c) that the ARIN Board of Trustees has determined that providing such services is consistent with ARIN’s mission; and (d) that the other RIRs have concurred with ARIN serving in this capacity.", "Due to the complexity of this Draft Policy, active discussions, and necessary confirmations described above, a comprehensive staff review will be necessary once this Draft Policy is further developed.", "**Implementable as Written?:** No", "**Impact on ARIN Registry Operations and Services:** N/A", "**Legal Review:** At this preliminary stage, Legal has identified several areas for further consideration, including potential jurisdictional questions, coordination with other RIRs, and the source of IP resources. Additional clarity in definitions and alignment with the service region model will also be important. These observations are based on the Draft Policy in its current form, and a more comprehensive legal analysis may be provided if and when the Draft Policy is further developed.", "**Implementation Timeframe Estimate:** N/A", "**Implementation Requirements:** N/A", "**Proposal/Draft Policy Text Assessed:** [24 March 2026](https://lists.arin.net/pipermail/arin-ppml/2026-March/038312.html)", "## History and Earlier Versions", "|Action|Date|", "|--- |--- |", "| [Proposal](/participate/policy/proposals/2026/ARIN_prop_349/) | 3 March 2026 |", "| [Draft Policy](https://lists.arin.net/pipermail/arin-ppml/2026-March/038312.html) | 24 March 2026 |", "| [Revised](https://lists.arin.net/pipermail/arin-ppml/2026-May/038385.html) | 27 May 2026 |", "## Related Meetings", "### Advisory Council", "- [19 March 2026](/about/welcome/ac/meetings/2026_0319/)", "- [22 April 2026](/about/welcome/ac/meetings/2026_0422/)", "- [21 May 2026](/about/welcome/ac/meetings/2026_0521/)", "- [18 June 2026](/about/welcome/ac/meetings/2026_0618/)", "- 16 July 2026", "- ", "### Board of Trustees", "### ARIN Public Policy Meetings", "- [ARIN 57](/participate/meetings/ARIN57/)"], "lastUpdated": "2025-08-26", "url": "https://www.arin.net/participate/policy/drafts/2026_1/" },{ "number": "ARIN-2025-7", "title": "Make Policy in 6.5.8.2 Match the Examples", "status": "Under Discussion", "recommended": true, "shepherds": ["Lily Botsyoe", "Leif Sawyer"], "problemStatement": "\n6.5.8.2 states "An organization qualifies for an assignment on the next larger nibble boundary when their sites exceed 75% of the /48s available in a prefix."and then follows with "For example: More than 1 but less than or equal to 12 sites justified, receives a /44 assignment;"implying that a single site should only receive a /48. However, 1 /48 exceeds 75% of the /48s available in a /48 (1), so per the rule an organization with a single site should receive a /44, which differs from the example.\n","policyStatement": "\nCurrent Text:\n6.5.8.2. Initial Assignment Size\nOrganizations that meet at least one of the initial assignment criteria above are eligible to receive an initial assignment of /48. Requests for larger initial assignments, reasonably justified with supporting documentation, will be evaluated based on the number of sites in an organization’s network and the number of subnets needed to support any extra-large sites defined below.\nThe initial assignment size will be determined by the number of sites justified below. An organization qualifies for an assignment on the next larger nibble boundary when their sites exceed 75% of the /48s available in a prefix. For example:\n- More than 1 but less than or equal to 12 sites justified, receives a /44 assignment;\n- More than 12 but less than or equal to 192 sites justified, receives a /40 assignment;\n- More than 192 but less than or equal to 3,072 sites justified, receives a /36 assignment;\n- More than 3,072 but less than or equal to 49,152 sites justified, receives a /32 assignment; etc…\nProposed Text:\n6.5.8.2. Initial Allocation Size\nOrganizations that meet at least one of the initial allocation criteria above are eligible to receive an initial allocation of /48. Larger initial allocation sizes will be determined by the number of sites justified below; an organization will qualify for an allocation on the next larger nibble boundary when their sites exceed 75% of the /48s available in a prefix. For example:\n- 2 to 12 sites justified will receive a /44 allocation;\n- 13 to 192 sites justified will receive a /40 allocation;\n- 193 to 3,072 sites justified will receive a /36 allocation;\n- 3,073 to 49,152 sites justified will receive a /32 allocation, etc.\n","implementationTime": "Immediate","fullText": ["## Current Text (20 May 2026)", "### AC Assessment of Conformance with the Principles of Internet Number Resource Policy", "Recommended Draft Policy ARIN-2025-7 conforms to the principles of the ARIN Policy Development Process. If adopted, this policy fixes a math loophole in NRPM Section 6.5.8.2 to clarify that a single-site organization receives a /48 IPv6 allocation. To align with current registry procedures, it also updates the terminology throughout the section from "assignment" to "allocation." These clarifications match ARIN's actual current practices, introduce no operational changes, and have received strong community support both on the PPML and at recent ARIN meetings. We have found this policy to be fair, impartial, and technically sound. Additionally, we have had no concerns expressed by the community for this policy.", "### Problem Statement", "6.5.8.2 states "An organization qualifies for an assignment on the next larger nibble boundary when their sites exceed 75% of the /48s available in a prefix."and then follows with "For example: More than 1 but less than or equal to 12 sites justified, receives a /44 assignment;"implying that a single site should only receive a /48. However, 1 /48 exceeds 75% of the /48s available in a /48 (1), so per the rule an organization with a single site should receive a /44, which differs from the example.", "### Policy Statement", "Current Text:", "6.5.8.2. Initial Assignment Size", "Organizations that meet at least one of the initial assignment criteria above are eligible to receive an initial assignment of /48. Requests for larger initial assignments, reasonably justified with supporting documentation, will be evaluated based on the number of sites in an organization’s network and the number of subnets needed to support any extra-large sites defined below.", "The initial assignment size will be determined by the number of sites justified below. An organization qualifies for an assignment on the next larger nibble boundary when their sites exceed 75% of the /48s available in a prefix. For example:", "- More than 1 but less than or equal to 12 sites justified, receives a /44 assignment;", "- More than 12 but less than or equal to 192 sites justified, receives a /40 assignment;", "- More than 192 but less than or equal to 3,072 sites justified, receives a /36 assignment;", "- More than 3,072 but less than or equal to 49,152 sites justified, receives a /32 assignment; etc…", "Proposed Text:", "6.5.8.2. Initial Allocation Size", "Organizations that meet at least one of the initial allocation criteria above are eligible to receive an initial allocation of /48. Larger initial allocation sizes will be determined by the number of sites justified below; an organization will qualify for an allocation on the next larger nibble boundary when their sites exceed 75% of the /48s available in a prefix. For example:", "- 2 to 12 sites justified will receive a /44 allocation;", "- 13 to 192 sites justified will receive a /40 allocation;", "- 193 to 3,072 sites justified will receive a /36 allocation;", "- 3,073 to 49,152 sites justified will receive a /32 allocation, etc.", "### Timetable for Implementation", "Immediate", "### Comments", "Based on community feedback, the policy structure was reworked to state that a single-site organization receives a /48, and then the 75% formula applies to multi-site organizations, rather than framing the /48 as an exception. In addition, we received comments stating the "assignment" term is no longer used and it should be updated to "allocation" to align with current procedures as they no longer reference assignments. This has been updated in the entire section.", "## Staff and Legal Review (15 June 2026)", "### Staff Understanding", "Section 6.5.8.2 of the NRPM describes the requirements for an initial allocation of IPv6 addresses to end user organizations based on the number of sites in the organization’s network. Staff understands this Draft Policy intends to clarify how these requirements apply to organizations with only one site. ", "Staff also understands this draft policy updates instances of "assignment" to "allocation" since Assignments are no longer issued by ARIN.", "This policy would not result to any change in existing allocation practices and only adds clarity.", "### Implementable as Written?", "Yes", "### Impact on ARIN Registry Operations and Services", "None", "### Legal Review", "No material legal issue", "### Implementation Timeframe Estimate", "3 months", "### Implementation Requirements", "- Staff Training", "- Updates to public documentation ", " ", "### Proposal/Draft Policy Text Assessed", "[20 May 2026](https://lists.arin.net/pipermail/arin-ppml/2026-May/038378.html)", "## History and Earlier Versions", "|Action|Date|", "|--- |--- |", "| [Proposal](/participate/policy/proposals/2025/ARIN_prop_346/) | 19 May 2025 |", "| [Draft Policy](https://lists.arin.net/pipermail/arin-ppml/2025-July/037946.html) | 1 July 2025 |", "| [Revised](https://lists.arin.net/pipermail/arin-ppml/2026-February/038208.html) | 4 February 2026 | ", "| [Revised](http://lists.arin.net/pipermail/arin-ppml/2026-May/038378.html) | 20 May 2026 |", "| [Recommended Draft Policy](https://lists.arin.net/pipermail/arin-ppml/2026-June/038393.html) | 24 June 2026 |", "## Related Meetings", "### Advisory Council", "- [26 June 2025](/about/welcome/ac/meetings/2025_0626/)", "- [17 July 2025](/about/welcome/ac/meetings/2025_0717/)", "- [21 August 2025](/about/welcome/ac/meetings/2025_0821/)", "- [18 September 2025](/about/welcome/ac/meetings/2025_0918/)", "- [31 October 2025](/about/welcome/ac/meetings/2025_1031/)", "- [20 November 2025](/about/welcome/ac/meetings/2025_1120/)", "- [18 December 2025](/about/welcome/ac/meetings/2025_1218/)", "- [30 January 2026](/about/welcome/ac/meetings/2026_0130)", "- [19 February 2026](/about/welcome/ac/meetings/2026_0219)", "- [19 March 2026](/about/welcome/ac/meetings/2026_0319/) ", "- [22 April 2026](/about/welcome/ac/meetings/2026_0422/)", "- [21 May 2026](/about/welcome/ac/meetings/2026_0521/)", "- [18 June 2026](/about/welcome/ac/meetings/2026_0618/)", "- 16 July 2026", "- ", "### Board of Trustees", "### ARIN Public Policy Meetings", "- [ARIN 56](/participate/meetings/ARIN56/)", "- [ARIN 57](/participate/meetings/ARIN57/)"], "lastUpdated": "2025-07-01", "url": "https://www.arin.net/participate/policy/drafts/2025_7/" },{ "number": "ARIN-2025-6", "title": "Fix Formula in 6.5.2.1c", "status": "Under Discussion", "recommended": false, "shepherds": ["William Herrin", "Gus Reese"], "fullText": ["## Staff and Legal Review (9 September 2025)", "### Staff Understanding", "NRPM section "6.5.2.1. Size" describes requirements for the size of IPv6 allocations to ISPs/LIRs. Sub-section "c" defines how to calculate the largest allocation justified by the requestor. Accompanying the text description is a mathematical formula that intends to summarize the calculation 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." ", " ", "This draft policy indicates the formula does not match the text, and intends to correct it with, "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 log_2(serving sites) and Y is a multiple of 4 greater than 4/3 log_2(end sites served by largest serving site)."", " ", "ARIN staff currently implements 6.5.2.1c based on the text alone. The summarized formula is overly complex for your typical IPv6 requestor. The text alone is more easily understood by customers and implemented by ARIN staff. Modifying the formula would have no impact on ARIN operations. Staff would continue to implement 6.5.2.1c based on the text alone. Removing the formula from the NRPM would have no impact on ARIN operations, and would simplify the policy language for IPv6 requestors.", " ", "NRPM section "6.5.2.1. Size" includes the text "Provider Allocation Unit", while sections 2.15 and 2.16 reference the term, "Provider Assignment Unit ". This draft policy intends to update the text in sections 2.15 and 2.16 to "Provider Allocation Unit". Modifying "Assignment" to "Allocation" aligns with the deprecation of Direct Assignment’s that occurred during ARIN’s fee harmonization. Staff agrees the terms should match between section 2 and section 6. Staff currently considers subnetted Direct Allocations, Reallocations, and Reassignments to be "Provider Assignment Units". This modification aligns with staff’s current implementation.", "### Implementable as Written?", "Yes", "### Impact on ARIN Registry Operations and Services", "None", "### Legal Review", "No material legal issue", "### Implementation Timeframe Estimate", "3 Months", "### Implementation Requirements", "- Staff Training", "- Updates to public documentation", "### Proposal/Draft Policy Text Assessed", "[3 September 2025](https://lists.arin.net/pipermail/arin-ppml/2025-September/038097.html)"], "lastUpdated": "2025-07-01", "url": "https://www.arin.net/participate/policy/drafts/2025_6_firstslr/" },{ "number": "ARIN-2025-6", "title": "Fix Formula in 6.5.2.1c", "status": "Abandoned", "recommended": false, "shepherds": ["Gus Reese", "Chris Woodfield"], "problemStatement": "\nSections 6.5.2.1 explains the initial IPv6 ISP/LIR allocation in a way that is difficult to follow and the formula in section (c) does not match the remainder of the text.\n","policyStatement": "\nIn 6.5.2.1c, replace:\n"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."\nwith:\n"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*log_2(serving sites) and Y is a multiple of 4 greater than 4/3*log_2(end sites served by largest serving site).\nIn 2.15 and 2.16, replace "provider assignment unit"with "provider allocation unit."\n","implementationTime": "Immediate","fullText": ["## Current Text (3 September 2025)", "### Problem Statement", "Sections 6.5.2.1 explains the initial IPv6 ISP/LIR allocation in a way that is difficult to follow and the formula in section (c) does not match the remainder of the text.", "### Policy Statement", "In 6.5.2.1c, replace:", ""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."", "with:", ""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*log_2(serving sites) and Y is a multiple of 4 greater than 4/3*log_2(end sites served by largest serving site).", "In 2.15 and 2.16, replace "provider assignment unit"with "provider allocation unit."", "### Comments", ""Provider assignment unit" in section 2.15 was intended to match "Provider Allocation Unit" in this policy section, but the words fell out of sync.", "### Timetable for Implementation", "Immediate", "## Staff and Legal Review (16 March 2026)", "### Staff Understanding", "NRPM section "6.5.2.1. Size" describes requirements for the size of IPv6 allocations to ISPs/LIRs. Sub-section "c" defines how to calculate the largest allocation justified by the requestor. Accompanying the text description is a mathematical formula that intends to summarize the calculation 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." ", "This draft policy indicates the formula does not match the text, and intends to correct it with, "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 log_2(serving sites) and Y is a multiple of 4 greater than 4/3 log_2(end sites served by largest serving site)." ", " ", "ARIN staff currently implements NRPM 6.5.2.1.c based on the policy text rather than the summarized formula. The summarized formula is overly complex for many typical IPv6 requestors, while the policy text is more readily understood by customers and more consistently applied by ARIN staff. ", "In practice, staff evaluates initial allocation size by reviewing the number of serving sites in the ARIN region and the number of end sites served by the largest serving site and then applying the 75% utilization standard consistent with current implementation. This approach is also reflected in the training materials ARIN provides to assist organizations in calculating IPv6 address requirements. In addition, the applicable policy parameters are built into the workflow for IPv6 ISP address requests.", "Removal of the summarized formula from the NRPM would have no impact on ARIN operations and would simplify the policy language for IPv6 requestors. Staff would continue to implement NRPM 6.5.2.1.c consistent with current practice. ", "NRPM section "6.5.2.1. Size" includes the text "Provider Allocation Unit", while sections 2.15 and 2.16 reference the term, "Provider Assignment Unit ". This draft policy intends to update the text in sections 2.15 and 2.16 to "Provider Allocation Unit". Modifying "Assignment" to "Allocation" aligns with the deprecation of Direct Assignment’s that occurred during ARIN’s fee harmonization. Staff agrees the terms should match between section 2 and section 6. Staff considers subnetted Direct Allocations, Reallocations, and Reassignments to be "Provider Assignment Units". This modification aligns with staff’s current implementation.", "### Implementable as Written?", "Yes", "### Impact on ARIN Registry Operations and Services", "None", "### Legal Review", "No material legal issue", "### Implementation Timeframe Estimate", "3 Months", "### Implementation Requirements", "- Staff Training", "- Updates to public documentation", "### Proposal/Draft Policy Text Assessed", "[3 September 2025](https://lists.arin.net/pipermail/arin-ppml/2025-September/038097.html)", "## History and Earlier Versions", "|Action|Date|", "|--- |--- |", "| [Proposal](/participate/policy/proposals/2025/ARIN_prop_345/) | 19 May 2025 |", "| [Draft Policy](https://lists.arin.net/pipermail/arin-ppml/2025-July/037945.html) | 1 July 2025 |", "| [Revised](https://lists.arin.net/pipermail/arin-ppml/2025-September/038097.html) | 3 September 2025 |", "| [Abandoned](https://lists.arin.net/pipermail/arin-ppml/2026-May/038384.html) | 27 May 2026 |", "## Related Meetings", "### Advisory Council", "- [26 June 2025](/about/welcome/ac/meetings/2025_0626/)", "- [17 July 2025](/about/welcome/ac/meetings/2025_0717/)", "- [21 August 2025](/about/welcome/ac/meetings/2025_0821/) ", "- [18 September 2025](/about/welcome/ac/meetings/2025_0918/)", "- [31 October 2025](/about/welcome/ac/meetings/2025_1031/)", "- [20 November 2025](/about/welcome/ac/meetings/2025_1120/)", "- [18 December 2025](/about/welcome/ac/meetings/2025_1218/)", "- [30 January 2026](/about/welcome/ac/meetings/2026_0130)", "- [19 February 2026](/about/welcome/ac/meetings/2026_0219)", "- [19 March 2026](/about/welcome/ac/meetings/2026_0319/)", "- [22 April 2026](/about/welcome/ac/meetings/2026_0422/)", "- [21 May 2026](/about/welcome/ac/meetings/2026_0521/)", "### Board of Trustees", "### ARIN Public Policy Meetings", "- [ARIN 56](/participate/meetings/ARIN56/)", "- [ARIN 57](/participate/meetings/ARIN57/)"], "lastUpdated": "2025-07-01", "url": "https://www.arin.net/participate/policy/drafts/2025_6/" },{ "number": "ARIN-2025-5", "title": "Clarify Justification Requirements for 4.4, 4.10, 6.10, and 11.10 IP Addresses", "status": "Abandoned", "recommended": false, "shepherds": ["Kaitlyn Pellak", "Alison Wood"], "problemStatement": "\nThe NRPM text is ambiguous about whether out of region use cases can justify requests for IP addresses allocated under 4.4, 4.10, 6.10, and 11.10, as well as whether these IP Addresses impact justification requirements for normal IP addresses. This change codifies ARIN Staff's current practices to remove this ambiguity, removing a source of confusion for resource requesters.\n","policyStatement": "\nAdd the following to 4.4:\nJustifications for resources under this section must be for use within the ARIN service region. Resources issued under this section may also be used out of\nregion if that use is consistent with the in-region justification (for example, global Anycast). Resources issued under this section have no impact on the justification or utilization requirements for requests under any other section.\nAdd the following to 4.10:\nJustifications for resources under this section must be for use within the ARIN service region. Resources issued under this section may also be used out of region if that use is consistent with the in-region justification (for example, global Anycast). Resources issued under this section have no impact on the justification or utilization requirements for requests under any other section.\nAdd the following to 6.10:\nJustifications for resources under this section must be for use within the ARIN service region. Resources issued under this section may also be used out of region if that use is consistent with the in-region justification (for example, global Anycast). Resources issued under this section have no impact on the justification or utilization requirements for requests under any other section.\nAdd Section 11.10:\nJustifications for resources under this section must be for use within the ARIN service region. Resources issued under this section may also be used out of region if that use is consistent with the in-region justification (for example, global Anycast). Resources issued under this section have no impact on the justification or utilization requirements for requests under any other section.\n","implementationTime": "Immediate","fullText": ["## Current Text (1 July 2025)", "### Problem Statement", "The NRPM text is ambiguous about whether out of region use cases can justify requests for IP addresses allocated under 4.4, 4.10, 6.10, and 11.10, as well as whether these IP Addresses impact justification requirements for normal IP addresses. This change codifies ARIN Staff's current practices to remove this ambiguity, removing a source of confusion for resource requesters.", "### Policy Statement", "Add the following to 4.4:", "Justifications for resources under this section must be for use within the ARIN service region. Resources issued under this section may also be used out of", "region if that use is consistent with the in-region justification (for example, global Anycast). Resources issued under this section have no impact on the justification or utilization requirements for requests under any other section.", "Add the following to 4.10:", "Justifications for resources under this section must be for use within the ARIN service region. Resources issued under this section may also be used out of region if that use is consistent with the in-region justification (for example, global Anycast). Resources issued under this section have no impact on the justification or utilization requirements for requests under any other section.", "Add the following to 6.10:", "Justifications for resources under this section must be for use within the ARIN service region. Resources issued under this section may also be used out of region if that use is consistent with the in-region justification (for example, global Anycast). Resources issued under this section have no impact on the justification or utilization requirements for requests under any other section.", "Add Section 11.10:", "Justifications for resources under this section must be for use within the ARIN service region. Resources issued under this section may also be used out of region if that use is consistent with the in-region justification (for example, global Anycast). Resources issued under this section have no impact on the justification or utilization requirements for requests under any other section.", "### Timetable for Implementation", "Immediate", "## History and Earlier Versions", "|Action|Date|", "|--- |--- |", "| [Proposal](/participate/policy/proposals/2025/ARIN_prop_344/) | 29 April 2025 |", "| [Draft Policy](https://lists.arin.net/pipermail/arin-ppml/2025-July/037944.html) | 1 July 2025 |", "| [Abandoned](https://lists.arin.net/pipermail/arin-ppml/2025-September/038149.html) | 18 September 2025 |", "## Related Meetings", "### Advisory Council", "- [26 June 2025](/about/welcome/ac/meetings/2025_0626/)", "- [17 July 2025](/about/welcome/ac/meetings/2025_0717/)", "- [21 August 2025](/about/welcome/ac/meetings/2025_0821/)", "- [18 September 2025](/about/welcome/ac/meetings/2025_0918)", " ", "### Board of Trustees", "### ARIN Public Policy Meetings"], "lastUpdated": "2025-07-01", "url": "https://www.arin.net/participate/policy/drafts/2025_5/" },{ "number": "ARIN-2025-4", "title": "Resource Issuance to Natural Persons", "status": "Abandoned", "recommended": false, "shepherds": ["Elizabeth Goodson", "Doug Camin"], "problemStatement": "\nARIN policies currently restrict the issuance of number resources to organizations. This limits access for individuals who are running networks under their own legal name, especially in regions where forming or registering a business is not required or feasible. Other RIRs such as RIPE NCC allow individuals to receive resources directly. ARIN should consider similar flexibility to ensure equal and consistent access to Internet number resources for all operators, regardless of legal structure.\n","policyStatement": "\nThis proposal introduces explicit policy text into the NRPM to allow number resource issuance to natural persons (individuals) who provide valid justification and identity verification.\nAmend NRPM Section 2 to add the following definition:\n2.18 Organization\nAn organization is a company, corporation, partnership, sole proprietorship, government agency, non-profit entity, educational institution, or a natural person acting in a capacity consistent with operating a network and who meets ARIN’s resource eligibility criteria.\n","implementationTime": "Recommend implementation within 3–6 months of ratification to allow ARIN staff and legal counsel to develop supporting processes.","fullText": ["## Current Text (20 May 2025)", "### Problem Statement", "ARIN policies currently restrict the issuance of number resources to organizations. This limits access for individuals who are running networks under their own legal name, especially in regions where forming or registering a business is not required or feasible. Other RIRs such as RIPE NCC allow individuals to receive resources directly. ARIN should consider similar flexibility to ensure equal and consistent access to Internet number resources for all operators, regardless of legal structure.", "### Policy Statement", "This proposal introduces explicit policy text into the NRPM to allow number resource issuance to natural persons (individuals) who provide valid justification and identity verification.", "Amend NRPM Section 2 to add the following definition:", "2.18 Organization", "An organization is a company, corporation, partnership, sole proprietorship, government agency, non-profit entity, educational institution, or a natural person acting in a capacity consistent with operating a network and who meets ARIN’s resource eligibility criteria.", "### Comments", "Sections 4.2, 5.1, and 6.5 shall be interpreted to allow "organizations" as newly defined in Section 2.12, thereby including individuals where appropriate.", "Staff may develop identity verification and residency requirements appropriate to individuals (e.g., government-issued photo ID and proof of address).", "All resource justification, utilization, and RSA signing requirements remain unchanged.", "There has been extensive discussion of this topic on the ARIN Public Policy Mailing List (PPML) in April 2025. Participants have cited inconsistencies and barriers created by reliance on state-level business registries, and called for more inclusive eligibility mechanisms similar to other RIR regions. The proposal addresses these concerns while maintaining accountability and justification requirements.", "### Timetable for Implementation", "Recommend implementation within 3–6 months of ratification to allow ARIN staff and legal counsel to develop supporting processes.", "### Anything Else", "This proposal does not reduce the level of justification required to obtain resources, but merely expands eligibility to natural persons who operate networks and meet all existing technical and usage criteria.", "## Staff and Legal Review (3 June 2025)", "### Staff Understanding", "Staff understands that the intent of this policy is to minimize the administrative hurdles that individuals face when obtaining number resources and related services from ARIN. ", "As written, the policy would add a new definition to section 2 for "Organization". The new definition would define the term Organization to encompass both its commonly understood meaning and additionally would include a "natural person" (in their capacity of operating a network and who meets ARIN’s resource eligibility criteria.) While ARIN currently serves individuals operating as a business, the change is intended to allow natural persons to obtain number resources and associated services from ARIN without any business construct (i.e., sole proprietorship, LLC, etc.).", "ARIN presently provides Internet number resources and associated services to natural persons but requires such individuals to operate as a legally recognized business, such as a sole proprietor, DBA, LLC, freelancer, or professional corporation. ARIN was formed in 1997 as a membership organization to provide registry services to organizations within its region and has operated on a business-facing (B2B) model (serving ISPs, enterprises, and a variety of other organizations) since that time. ", "ARIN presently does provide number resources and related services to individuals who intend to operate Internet network infrastructure and who meet ARIN’s resource eligibility criteria; but ARIN accommodates these requests by directing the requester to first establish a legally recognized business, such as a sole proprietor, DBA, LLC, or corporation. (See ARIN Blog post ["Can I request Internet number resources as an individual?"](https://www.arin.net/blog/2025/05/28/individual-requests/)) Doing so allows clear compliance with existing NRPM policy that references "Organizations" and maintains ARIN as an entity that operates in a business-to-business service model. ", " of the ARIN Policy Development Process (PDP) states, in part:", ""… A Policy Proposal may not define the specific processes by which the Policy Proposal will be implemented by ARIN staff, nor may it define or establish services offered by ARIN, or the fees charged by ARIN for its services. To suggest changes to ARIN processes, fees, or services, members of the Internet community may participate in ARIN’s Consultation and Suggestion Process (ACSP)." ", "The reformulation of Organization to include the addition of "natural persons" represents a substantive change to ARIN’s current service model, as it would redefine that scope of ARIN’s customer base. ARIN’s General Counsel noted to the ARIN AC that such a change was likely outside of the scope of the ARIN PDP and that expanding ARIN’s customer community to directly include natural persons could have potential implications for how ARIN is treated under law and regulation. While the potential organizational implications for directly serving individuals can be assessed by ARIN staff during the course of policy development, General Counsel further suggested that the change might be better suited for the ARIN Consultation and Suggestion Process (ACSP). The ARIN AC did adopt the proposal as a draft policy, and ARIN staff suggested that a staff and legal review be requested by the ARIN AC immediately given the potential for significant organizational implications resulting from the change. This initial staff and legal review is being provided to inform the current policy development effort with full knowledge that a complete assessment may require both additional policy language clarifications and further legal work as noted below. ", "### Implementable as Written? ", "No. The redefinition of Organization in a manner contrary to both the common usage of the term and existing usage in NRPM does not provide adequate clarity regarding how natural persons requesting number resources are to be treated in policy going forward. The draft policy includes a comment to the effect that Sections 4.2, 5.1, and 6.5 shall be interpreted to allow use by natural persons, but there are many other usages of term Organization in the NRPM thus leaving numerous policy sections (, etc.) whose applicability to natural persons would be left indeterminate by the draft policy text. In addition, the legal/regulatory analysis necessary to more fully determine implications of the draft policy – if adopted – will also be considered by external parties (e.g. legal/financial/insurance/tax advisors, governmental authorities/regulators) for whom the term "Organization" will lack sufficient clarity and risk misinterpretation if the term recast as proposed to incorporate natural persons. Staff recommends that the draft policy be expanded to more clearly define the portions of existing number resource policy that would or would not be applicable to natural persons, if adopted.", "### Impact on ARIN Registry Operations and Services", "The draft policy would represent a significant change to current ARIN services and operations. ", "### Legal Review", "Draft Policy 2025-4 proposes that ARIN issue Internet number resources directly to natural persons/individual customers. Historically, ARIN has issued such resources only to legal, business entities with an established operation and appropriate justification, including sole proprietorships. The proposed change would shift ARIN’s operational model from business-to-business (B2B) to one that would include business-to-consumer (B2C) relationships.", "This type of change to ARIN’s operations would necessarily involve a substantial number of legal and operational issues as well as a long implementation timeline given the number of issues that would need to be resolved. There would also need to be a review and likely updates to most, if not all, of ARIN’s service terms, agreements, and applicable operational policies and communication materials.", "Several other significant legal considerations that will arise if this proposal is adopted include, but are not limited to, the following:", "<ol>", "<li><b>Consumer Protection Laws Compliance</b> ", "Transacting directly with individuals would likely subject ARIN to consumer protection laws at multiple levels (federal, state/provincial) that are generally not applicable to commercial, B2B relationships. These laws may impose additional compliance obligations, limit enforceability of standard contract provisions, and increase the potential for regulatory scrutiny.</li>", "<li><b>Insurance Implications</b>", "ARIN’s existing insurance coverage and strategy does not fully address liabilities arising from individual consumer transactions. A shift toward a model that includes B2C interactions could necessitate changes to current policies or procurement of additional coverage which would likely result in higher overall insurance costs.</li>", "<li><b>Tax and Financial Compliance</b>", "A B2C model is likely to give rise to new tax obligations and reporting requirements depending on the jurisdiction, as ARIN has relied upon treatment as a business providing B2B services. As a business directly serving natural persons, it is likely that ARIN would have to undertake corresponding operational adjustments in billing, accounting, and customer classification, including the collecting and remitting of sales taxes that may become applicable as a result. This shift would introduce significant administrative overhead and potential audit exposure. It could also subject ARIN to other international tax regimes (e.g., EU VAT, U.S. state-level nexus laws), expanding its compliance burden across multiple jurisdictions.</li>", "<li><b>Data Privacy Obligations</b>", "Interacting with individuals will likely require enhanced data privacy compliance, including revisions to ARIN’s privacy policies and procedures to address personal data rights and protections under applicable laws. Currently, ARIN deals with businesses which are publicly known, and these organizations provide business information including business point of contact information necessary for registry operation; and thus, a change to directly serving individuals carries significant risk as a result of the significant expansion of the regulatory regimes that could become applicable to ARIN at the federal, state, and provincial level, and with which ARIN must remain compliant.</li> ", "<li><b>Data Accuracy</b> ", "Directly serving natural persons as customers will increase administrative burden on ARIN due to the increased need for verification of natural persons, some of which is presently accomplished by public authorities in the course of business entity registration; and it may reduce the overall reliability and verifiability of public contact data, which is foundational to ARIN’s registry function. </li>", "<li><b>Liability and Enforcement</b>", "Individual customers may present greater risk to ARIN in terms of non-performance, limited recourse in the event of breach, and overall enforceability of ARIN’s terms of service. Individuals are also less likely than businesses to have assets available to satisfy liabilities to ARIN; and further, individuals present a greater challenge and risk in terms of pursuing any legal claim.</li> ", "</ol>", "If adopted, ARIN 2025-4 would materially alter ARIN’s risk profile by introducing consumer-facing obligations and exposures. While the policy’s intent looks to simply enhance inclusivity, it is a very complex proposal that proposes changing the nature of services that ARIN offers, with corresponding changes to how ARIN is treated in multiple legal, tax, regulatory regimes. Proper implementation will require significant investment to determine the full extent of the legal, operational, and compliance adaptations necessary, as well as determining resulting implementation cost. A further, in-depth review of the final policy text would be necessary prior to implementation, including analysis of contract, insurance, tax, data privacy, compliance, and any other applicable impacts.", "### Implementation Timeframe Estimate", "Minimum 1 year pending further evaluation", "### Implementation Requirements", "(Initial assessment)", "- Staff Training", "- Updates to internal procedures and guidelines", "- Website, training and printed materials", "- Further discussion needed to determine scope of additional outreach and education", "- Review and implementation of tax obligations and reporting requirements", "- Updates to ARIN Online; in-depth review of requirements needed", "### Proposal/Draft Policy Text Assessed", "[20 May 2025](https://lists.arin.net/pipermail/arin-ppml/2025-May/037877.html)", "## History and Earlier Versions", "|Action|Date|", "|--- |--- |", "| [Proposal](/participate/policy/proposals/2025/ARIN_prop_343/) | 21 April 2025 |", "| [Draft Policy](https://lists.arin.net/pipermail/arin-ppml/2025-May/037877.html) | 20 May 2025 |", "| [Abandoned](https://lists.arin.net/pipermail/arin-ppml/2025-August/038061.html) | 26 August 2025 |", "## Related Meetings", "### Advisory Council", "- [15 May 2025](/about/welcome/ac/meetings/2025_0515/)", "- [26 June 2025](/about/welcome/ac/meetings/2025_0626/)", "- [17 July 2025](/about/welcome/ac/meetings/2025_0717/)", "- [21 August 2025](/about/welcome/ac/meetings/2025_0821/)", " ", "### Board of Trustees", "### ARIN Public Policy Meetings"], "lastUpdated": "2025-05-20", "url": "https://www.arin.net/participate/policy/drafts/2025_4/" },{ "number": "ARIN-2025-3", "title": "Change Section 9 Out Of Region Use Minimum Criteria", "status": "Under Discussion", "recommended": false, "shepherds": ["Gerry George", "Matthew Wilder"], "problemStatement": "\nSection 9 of the NRPM, Out of Region Use, requires organizations to use at least a /22 in the ARIN region before they can justify out of region use. This harms smaller organizations that have less than a /22 in region but do require some out of region use.\n","policyStatement": "\nModify the following text in Section 9:\nFROM:\nIPv4: At least a /22 used in region.\nTO:\nIPv4: At least a /24 used in region.\nRESULT:\nOut of region use of ARIN registered resources are valid justification for additional number resources, provided that the applicant has a real and substantial connection with the ARIN region which applicant must prove (as described below) and is using the same type of resources (with a delegation lineage back to an ARIN allocation or assignment) within the ARIN service region as follows:\nIPv4: At least a /24 used in region\nIPv6: At least a /44 used in region\nASN: At least one ASN present on one or more peering sessions and/or routers within the region\n","implementationTime": "3 months ","fullText": ["## Current Text (25 March 2025)", "### Problem Statement", "Section 9 of the NRPM, Out of Region Use, requires organizations to use at least a /22 in the ARIN region before they can justify out of region use. This harms smaller organizations that have less than a /22 in region but do require some out of region use.", "### Policy Statement", "Modify the following text in Section 9:", "FROM:", "IPv4: At least a /22 used in region.", "TO:", "IPv4: At least a /24 used in region.", "RESULT:", "Out of region use of ARIN registered resources are valid justification for additional number resources, provided that the applicant has a real and substantial connection with the ARIN region which applicant must prove (as described below) and is using the same type of resources (with a delegation lineage back to an ARIN allocation or assignment) within the ARIN service region as follows:", "IPv4: At least a /24 used in region", "IPv6: At least a /44 used in region", "ASN: At least one ASN present on one or more peering sessions and/or routers within the region", "### Comments", "In my experience when a company needs address space outside of the ARIN region without at least a /22 in region, they go to RIPE and acquire either PI or Legacy space (the least expensive option), often acquiring the space from ARIN sources.", "In the case of an inter-regional ARIN to RIPE transfer, RIPE does require the recipient to demonstrate need, as required by ARIN. ARIN is losing registration of the block and annual fees, as well as the recipient transfer fee. Most of these recipients would much rather keep everything together in one ARIN account instead of having to go to another registry.", "Looking back over the history of Section 9, it was first proposed by Terri Stumme in PROP 189 in May 2013, and was abandoned.", "The Second proposal was by David Farmer in PROP 192 in January 2014 and was abandoned.", "The third proposal was by Christian Tacit in PROP 219 in May 2015. It became draft policy ARIN-2015-5, implemented July 2016. The AC Shepherds were Tina Morris and David Huberman.", "In looking over the discussions of the proposals, there was a concern before ARIN ran out of addresses in 2015 that foreign entities would set up shell companies in the ARIN region, looking for free addresses. Since ARIN is out of address space, that fear is no longer valid. If there is a fear of swindling the already crowded waiting list, it might be prudent to ban out of region needs demonstration from the waiting list.", "### Timetable for Implementation", "3 months ", "## Staff and Legal Review (23 February 2026)", "### Staff Understanding: ", "NRPM Section 9, Out of Region Use, for IPv4 addresses requires that to justify out-of-region use, an organization must utilize at least a /22 within the ARIN region before additional resources may be approved for use outside the region. Section 9 applies to IPv4 address requests in conjunction with section 4 "IPv4", section 8.3 "Transfers Between Specified Recipients Within the ARIN Region", and section 8.4 "Inter-RIR Transfers to Specified Recipients". This section does not apply to section 4.4 or 4.10 space, these sections have their own restrictions.", "Draft Policy 2025-3 proposes reducing the in-region IPv4 utilization threshold from a /22 (or equivalent) to a single /24. Under this change, an organization would need to demonstrate use of only one /24 within the ARIN region to justify receiving additional ARIN-issued IPv4 resources for use outside the ARIN region. Neither the current policy text nor this draft policy establishes any maximum on the amount of IPv4 space that may be justified to be used outside the ARIN region, so long as at least a single /24 is utilized within the ARIN region, meaning a single in-region /24 could, in practice, unlock requests for substantially larger blocks for deployment entirely outside the ARIN region. This draft policy does not modify the current section 9 threshold for Autonomous System Number and IPv6 usage. ", "In conjunction with section 4.1.8 "ARIN Waitlist", an organization could request an initial /22 from the IPv4 waitlist with the intent to use a portion outside the ARIN region, provided they demonstrate efficient projected usage of one /24 within the ARIN region, and three /24s outside the ARIN region. ", "Staff anticipates this draft policy would significantly increase the volume of IPv4 waitlist requests. Because the policy requirements for an organization to justify an initial /24 are generally straightforward to meet, it is expected that more organizations may request a /24 primarily to qualify for additional ARIN-issued IPv4 addresses for out-of-region use. It is expected that this would result in more ARIN IPv4 space being used out of region.", "### Implementable as Written?: ", "Yes", "### Impact on ARIN Registry Operations and Services: ", "Anticipate increase to staff ticket workload ", "### Legal Review: ", "No material legal issue", "### Implementation Timeframe Estimate: ", "3 months", "### Implementation Requirements:", "- Staff Training", "- Updates to public documentation", "- Updates to internal procedures and guidelines", "### Proposal/Draft Policy Text Assessed: ", "[25 March 2025](https://lists.arin.net/pipermail/arin-ppml/2025-March/037780.html)", "## History and Earlier Versions", "|Action|Date|", "|--- |--- |", "| [Proposal](/participate/policy/proposals/2025/ARIN_prop_341/) | 13 February 2025 |", "| [Draft Policy](https://lists.arin.net/pipermail/arin-ppml/2025-March/037780.html) | 25 March 2025 |", "## Related Meetings", "### Advisory Council", "- [20 March 2025](/about/welcome/ac/meetings/2025_0320/)", "- [30 April 2025](/about/welcome/ac/meetings/2025_0430/)", "- [15 May 2025](/about/welcome/ac/meetings/2025_0515/)", "- [26 June 2025](/about/welcome/ac/meetings/2025_0626/)", "- [17 July 2025](/about/welcome/ac/meetings/2025_0717/)", "- [21 August 2025](/about/welcome/ac/meetings/2025_0821/)", "- [18 September 2025](/about/welcome/ac/meetings/2025_0918/)", "- [31 October 2025](/about/welcome/ac/meetings/2025_1031/)", "- [20 November 2025](/about/welcome/ac/meetings/2025_1120/)", "- [18 December 2025](/about/welcome/ac/meetings/2025_1218/)", "- [30 January 2026](/about/welcome/ac/meetings/2026_0130)", "- [19 February 2026](/about/welcome/ac/meetings/2026_0219)", "- [19 March 2026](/about/welcome/ac/meetings/2026_0319/)", "- [22 April 2026](/about/welcome/ac/meetings/2026_0422/)", "- [21 May 2026](/about/welcome/ac/meetings/2026_0521/)", "- [18 June 2026](/about/welcome/ac/meetings/2026_0618/)", "- 16 July 2026", " ", "### Board of Trustees", "### ARIN Public Policy Meetings", "- [ARIN 55](/participate/meetings/ARIN55/)", "- [ARIN 56](/participate/meetings/ARIN56/)", "- [ARIN 57](/participate/meetings/ARIN57/)"], "lastUpdated": "2026-02-23", "url": "https://www.arin.net/participate/policy/drafts/2025_3/" },{ "number": "ARIN-2025-2", "title": "Clarify 8.5.1 Registration Services Agreement", "status": "Implemented", "recommended": true, "shepherds": ["Gus Reese", "Kendrick Knowles"], "problemStatement": "\nThe current policy mandates that entities receiving transferred resources sign a new RSA unless they have an RSA on file no older than the last two versions. However, defining RSA versioning requirements within the NRPM does not align with the Policy Development Process (PDP) guidelines, as determining which RSA version is considered current is a business decision rather than a policy matter.\n","policyStatement": "\nRemove (within the last two versions) from 8.5.1 to state: The receiving entity must sign an RSA covering all resources to be transferred unless that entity has a current RSA on file per ARIN business practices.\n","implementationTime": "Immediate. ","fullText": ["## Current Text (25 February 2025)", "### AC Assessment of Conformance with the [Principles of Internet Number Resource Policy](/participate/policy/pdp/#4-principles-of-internet-number-resource-policy)", "Recommended Draft Policy ARIN-2025-2 conforms to the principles of the ARIN Policy Development Process. This policy, if adopted, will allow ARIN the flexibility needed for effective operations by returning the decision to ARIN on what the current version of the RSA regarding transfers under 8.5 in the Number Resource Policy Manual. It is fair, impartial, technically sound and has received support from the community.", "### Problem Statement", "The current policy mandates that entities receiving transferred resources sign a new RSA unless they have an RSA on file no older than the last two versions. However, defining RSA versioning requirements within the NRPM does not align with the Policy Development Process (PDP) guidelines, as determining which RSA version is considered current is a business decision rather than a policy matter.", "### Policy Statement", "Remove (within the last two versions) from 8.5.1 to state: The receiving entity must sign an RSA covering all resources to be transferred unless that entity has a current RSA on file per ARIN business practices.", "### Timetable for Implementation", "Immediate. ", "## Staff and Legal Review (15 May 2025)", "### Staff Understanding", "Current transfer policy 8.5.1 defines the current RSA to be "within the last two versions". ARIN business practices for determination of what constitutes "current" under any given business conditions are constrained by the number resource policy text. The current wording of the policy is overly specific and requires that ARIN either utilize the same definition elsewhere or have inconsistent practices across different business functions.", " ", "This Draft Policy will remove "within the last two versions" from section 8.5.1, allowing ARIN the flexibility needed for effective operations.", "### Implementable as Written?", "Yes", "### Impact on ARIN Registry Operations and Services", "None", "### Legal Review", "No material legal issue", "### Implementation Timeframe Estimate", "3 Months", "### Implementation Requirements", "- Staff Training", "- Updates to public documentation", "- Updates to internal procedures and guidelines", "### Proposal/Draft Policy Text Assessed", "[25 February 2025](https://lists.arin.net/pipermail/arin-ppml/2025-February/037721.html)", "## History and Earlier Versions", "|Action|Date|", "|--- |--- |", "| [Proposal](/participate/policy/proposals/2025/ARIN_prop_340/) | 10 February 2025 |", "| [Draft Policy](https://lists.arin.net/pipermail/arin-ppml/2025-February/037721.html) | 25 February 2025 |", "| [Recommended Draft Policy](https://lists.arin.net/pipermail/arin-ppml/2025-July/037943.html) | 1 July 2025 |", "| [Last Call](https://lists.arin.net/pipermail/arin-ppml/2025-November/038185.html) | 5 November 2025 |", "| [Pending Board of Trustees Review](https://lists.arin.net/pipermail/arin-ppml/2025-November/038194.html) | 25 November 2025 |", "| [Adopted](/about/welcome/board/meetings/2025_1215/) | 15 December 2025 | ", "| [Implemented](/announcements/20260303/) | 3 March 2026 |", "## Related Meetings", "### Advisory Council", "- [20 February 2025](/about/welcome/ac/meetings/2025_0220/)", "- [20 March 2025](/about/welcome/ac/meetings/2025_0320/)", "- [30 April 2025](/about/welcome/ac/meetings/2025_0430/)", "- [15 May 2025](/about/welcome/ac/meetings/2025_0515/)", "- [26 June 2025](/about/welcome/ac/meetings/2025_0626/)", "- [17 July 2025](/about/welcome/ac/meetings/2025_0717/)", "- [21 August 2025](/about/welcome/ac/meetings/2025_0821/)", "- [18 September 2025](/about/welcome/ac/meetings/2025_0918/)", "- [31 October 2025](/about/welcome/ac/meetings/2025_1031/)", "- [20 November 2025](/about/welcome/ac/meetings/2025_1120/)", "- ", "### Board of Trustees", "- [15 December 2025](/about/welcome/board/meetings/2025_1215/)", "### ARIN Public Policy Meetings", "- [ARIN 55](/participate/meetings/ARIN55/)", "- [ARIN 56](/participate/meetings/ARIN56/)"], "lastUpdated": "2025-02-25", "url": "https://www.arin.net/participate/policy/drafts/2025_2/" },{ "number": "ARIN-2025-1", "title": "Clarify ISP and LIR Definitions and References to Address Ambiguity in NRPM Text", "status": "Under Discussion", "recommended": false, "shepherds": ["Leif Sawyer", "Elizabeth Goodson"], "problemStatement": "\nSection 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.\nThrough implication and in common business practice, all ISPs are LIRs, but not all LIRs are ISPs.\nThis 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.\n","policyStatement": "\nUpdate the Table of Contents, replacing ISP with Local Internet Registries as follows:\n4.2. Allocations to Local Internet Registries\n4.2.2. Initial Allocation to Local Internet Registries\n4.2.3.4.2. Downstream Local Internet Registries\n4.2.4. Local Internet Registry Additional Requests\n6.5.4. Reassignments from Local Internet Registries\nSection 2:\nRewrite the LIR definition to provide clarity and relationship to ISP\n2.4. Local Internet Registry (LIR) \nA 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.\nReplace ISP with Local Internet Registry:\n2.15. Provider Assignment Unit (IPv6)\nWhen 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).\nAdd new definition for ISP:\n2.18 Internet Service Provider (ISP)\nAn Internet Service Provider (ISP) is a type of organization that provides Internet services to other organizations, its customers, andor 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.\nSection 3:\nReplace first ISP with Local Internet Registry, remaining with LIR\nThis 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.\nSection 4:\nReplace ISP with Local Internet Registry: in the following sections:\n4.2. Allocations to Local Internet Registries (Requirements for Requesting Initial Address Space)\n4.2.1.1. Purpose\nARIN allocates blocks of IP addresses to Local Internet Registries for the purpose of reassigning and reallocating that space to their customers.\n4.2.1.5. Minimum Allocation\nIn 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.\n4.2.2. Initial Allocation to LIRs\nAll 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.\n4.2.3.1. Efficient Utilization\nLocal 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.\n4.2.3.2. VLSM\nTo 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.\n4.2.3.3. Contiguous Blocks\nIP 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.\n4.2.3.4. Downstream Customer Adherence\nLocal Internet Registries must require their downstream customers to adhere to the following criteria:\n4.2.3.4.1. Utilization\nA 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.\n4.2.3.4.2. Downstream Local Internet Registries\nCustomers must follow ARIN policy for Local Internet Registries.\n4.2.3.6. Reassignments to Multihomed Downstream Customers\nIf 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.\n4.2.3.7. Registration\nLocal 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.\n4.2.3.8. Reassignments for Third Party Internet Access (TPIA) over Cable\nIP 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:\n4.2.4. Local Internet Registry Additional Requests\n4.2.4.1. Utilization Percentage (80%)\nLocal 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.\n4.2.4.3. Request Size\nLocal Internet Registries may request up to a 24-month supply of IPv4 addresses.\nSection 6:\nUpdate terminology section to reference how Internet Service Provider and Local Internet Registry are used\n6.5.1. Terminology\n 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.\nReplace ISP with Local Internet Registry in the following sections:\n6.5.2.1 Size\n a. All allocations shall be made on nibble boundaries.\n 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:\n - Hold IPv4 direct allocations totaling a /24 or less (to include zero)\n - Hold IPv4 reassignments/reallocations totaling a /22 or less (to include zero)\n \nIn no case shall an LIR receive more than a /16 initial allocation.\n 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.\n6.5.2.2. Qualifications\nAn organization qualifies for an allocation under this policy if they meet any of the following criteria:\n 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.\n6.5.4. Reassignments from Local Internet Registries\n6.5.5. Registration\nLocal 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.\n6.5.5.4. Registration Requested by Recipient\nIf 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.\n6.5.8.1. Initial Assignment Criteria\n f. By providing a reasonable technical justification indicating why IPv6 addresses from a Local Internet Registry are unsuitable.\n","implementationTime": "Immediate. ","fullText": ["## Current Text (7 May 2026)", "### 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, andor 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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 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. 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. 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.", "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.", "### Timetable for Implementation", "Immediate. ", "## Staff & Legal Review (15 June 2026)", "### Staff Understanding", "ARIN staff understands this Draft Policy adds a definition for "Internet Service Provider (ISP)" to Section 2, and updates the existing definition for "Local Internet Registry (LIR)". This Draft Policy also replaces applicable instances and variations of "Internet Service Provider (ISP)" with "Local Internet Registry (LIR)" throughout the NRPM.", "Staff understands the intent of this Draft Policy is to clarify the relationship between ISP and LIR, with ISP treated as a type of LIR rather than as an equivalent term. Staff notes that while the term "Local Internet Registry (LIR)" exists in the NRPM, it has not historically been the primary term used in the ARIN service region. As a result, implementation may require updates to customer-facing materials and staff guidance to support consistent understanding and use of the revised terminology.", "This Draft Policy would not materially change current registry operations, or how ARIN evaluates requests. However, the terms "Internet Service Provider" and "ISP" are used throughout ARIN’s web content, documentation, internal procedures, and applications. Implementation would require review and updates across those materials and systems to ensure consistent terminology. Staff estimates six months for implementation.", "Staff has the following comments and suggestions intended to improve clarity, consistency, and implementation of the proposed text.", "2.4 ", "- Staff suggests adding additional examples to clarify the scope of LIRs. For example: "LIRs include, but are not limited to, large enterprises, universities, and Internet Service Providers (ISPs) whose customers are primarily end users of the network services they provide and, in some cases, other ISPs."", "- Staff notes that the phrase "at a local level" may be ambiguous and recommends clarifying or removing it.", "- Staff recommends removing the sentence: "Historically in the ARIN service region ‘ISP’ was used as an equivalent, albeit incomplete, term." Staff believes the operational distinction can be addressed without including historical explanation in the policy text.", "2.15", "- Staff recommends updating "Provider Assignment Unit (IPv6)" to "Provider Allocation Unit (IPv6)" for consistency with the use of allocation terminology in this section.", "- Staff recommends removing "(recommended /48)" from the definition. This parenthetical may be interpreted as policy guidance within the definition itself and may be better addressed elsewhere if needed.", "4.2.1.5", "- Staff recommends removing "In general" from the sentence, "In general, ARIN allocates /24 and larger IP address prefixes to Local Internet Registries." Removing this phrase would make the statement clearer and more consistent with the minimum allocation language.", "4.2.3.1", "- Staff recommends modifying "should" to "must" in the following sentence: "LIRs should have documented justification available for each reassignment and reallocation."", "- Suggested revision: "LIRs must have documented justification available for each reassignment and reallocation."", "- Staff believes this change better aligns the sentence with the existing requirement that ARIN may request this justification at any time and that future receipt of allocations may be impacted if justification is not provided.", "6.5.1", "- Staff recommends retiring 6.5.1.a. If this update to LIR terminology is adopted, the distinction between ISP and LIR will no longer need to be explained separately in this section.", "- If 6.5.1.a is retained, staff recommends removing the final sentence. If instances of ISP are removed from the section, the sentence would no longer be necessary.", "### Implementable as Written?", "Yes", "### Impact on ARIN Registry Operations and Services", "None", "### Legal Review", "No material legal issue", "### Implementation Timeframe Estimate", "6 months", "### Implementation Requirements:", "- Staff Training", "- Updates to public documentation (web and print)", "- Updates to internal procedures and guidelines", "- Updates to applications", "### Proposal/Draft Policy Text Assessed", "[7 May 2026](https://lists.arin.net/pipermail/arin-ppml/2026-May/038350.html)", "## History and Earlier Versions", "|Action|Date|", "|--- |--- |", "| [Proposal](/participate/policy/proposals/2025/ARIN_prop_339/) | 8 January 2025 |", "| [Draft Policy](https://lists.arin.net/pipermail/arin-ppml/2025-January/037674.html) | 29 January 2025 |", "| [Revised](https://lists.arin.net/pipermail/arin-ppml/2025-March/037766.html) | 19 March 2025 |", "| [Revised](https://lists.arin.net/pipermail/arin-ppml/2025-March/037783.html) | 27 March 2025 |", "| [Revised](https://lists.arin.net/pipermail/arin-ppml/2025-September/038098.html) | 12 September 2025 | ", "| [Revised](https://lists.arin.net/pipermail/arin-ppml/2026-March/038286.html) | 5 March 2026 | ", "| [Revised](https://lists.arin.net/pipermail/arin-ppml/2026-May/038350.html) | 7 May 2026 |", "| [View Markups](/participate/policy/drafts/pdf/ARIN_2025_1_diff_050726.pdf ) | 7 May 2026 | ", "## Related Meetings", "### Advisory Council", "- [24 January 2025](/about/welcome/ac/meetings/2025_0124/)", "- [20 February 2025](/about/welcome/ac/meetings/2025_0220/)", "- [20 March 2025](/about/welcome/ac/meetings/2025_0320/)", "- [30 April 2025](/about/welcome/ac/meetings/2025_0430/)", "- [15 May 2025](/about/welcome/ac/meetings/2025_0515/)", "- [26 June 2025](/about/welcome/ac/meetings/2025_0626/)", "- [17 July 2025](/about/welcome/ac/meetings/2025_0717/)", "- [21 August 2025](/about/welcome/ac/meetings/2025_0821/)", "- [18 September 2025](/about/welcome/ac/meetings/2025_0918/)", "- [31 October 2025](/about/welcome/ac/meetings/2025_1031/)", "- [20 November 2025](/about/welcome/ac/meetings/2025_1120/)", "- [18 December 2025](/about/welcome/ac/meetings/2025_1218/)", "- [30 January 2026](/about/welcome/ac/meetings/2026_0130)", "- [19 February 2026](/about/welcome/ac/meetings/2026_0219)", "- [19 March 2026](/about/welcome/ac/meetings/2026_0319/)", "- [22 April 2026](/about/welcome/ac/meetings/2026_0422/)", "- [21 May 2026](/about/welcome/ac/meetings/2026_0521/)", "- [18 June 2026](/about/welcome/ac/meetings/2026_0618/)", "- 16 July 2026", " ", "### Board of Trustees", "### ARIN Public Policy Meetings", "- [ARIN 55](/participate/meetings/ARIN55/)", "- [ARIN 56](/participate/meetings/ARIN56/)", "- [ARIN 57](/participate/meetings/ARIN57/)"], "lastUpdated": "2026-05-07", "url": "https://www.arin.net/participate/policy/drafts/2025_1/" },{ "number": "ARIN-edit-2024-3", "title": "Edit 6.5.8.3 Section 2", "status": "Implemented", "recommended": false, "shepherds": ["Kendrick Knowles", "Doug Camin"], "problemStatement": "\nA typo was discovered in the policy language that requires correction. An editorial change will accomplish this.\n","policyStatement": "\nCurrent policy: \nWhen possible subsequent assignments will result it the expansion of an existing assignment by one or more nibble boundaries as justified.\nWe propose that the text should be: \nWhen possible subsequent assignments will result in the expansion of an existing assignment by one or more nibble boundaries as justified.\n","implementationTime": "Immediate","fullText": ["## Current Text (1 March 2024)", "### Problem Statement", "A typo was discovered in the policy language that requires correction. An editorial change will accomplish this.", "### Policy Statement", "Current policy: ", "When possible subsequent assignments will result it the expansion of an existing assignment by one or more nibble boundaries as justified.", "We propose that the text should be: ", "When possible subsequent assignments will result in the expansion of an existing assignment by one or more nibble boundaries as justified.", "### Timetable for Implementation", "Immediate", "### Comments", "This is an editorial change that was pointed out by a member of the community.", "## Staff and Legal Review (2 April 2024)", "### Staff Understanding", "This Editorial Update corrects a minor typo in section 6.5.8.3, Section 2 changing the word "it" to "in". The text is clear and understandable.", "### Implementable as Written?", "Yes", "### Impact on ARIN Registry Operations and Services", "None", "### Legal Review", "No material legal issue", "### Implementation Timeframe Estimate", "3 months", "### Implementation Requirements", "- Updates to public documentation", "### Proposal/Draft Policy Text Assessed", "[1 March 2024](https://lists.arin.net/pipermail/arin-ppml/2024-March/037270.html)", "## History and Earlier Versions", "|Action|Date|", "|--- |--- |", "| [Proposal](/participate/policy/proposals/2024/ARIN_prop_330/) | 1 March 2024 |", "| [Editorial Update](https://lists.arin.net/pipermail/arin-ppml/2024-March/037270.html) | 26 March 2024 | ", "| [Advanced to Board of Trustees](https://lists.arin.net/pipermail/arin-ppml/2024-May/037316.html) | 21 May 2024 |", "| [Adopted](https://lists.arin.net/pipermail/arin-ppml/2024-July/037461.html) | 3 June 2024 | ", "| [Implemented](https://lists.arin.net/pipermail/arin-ppml/2024-August/037573.html) | 21 August 2024 |", "## Related Meetings", "### Advisory Council", "- [21 March 2024](/about/welcome/ac/meetings/2024_0321/)", "- [17 April 2024](/about/welcome/ac/meetings/2024_0417/)", "- [16 May 2024](/about/welcome/ac/meetings/2024_0516/)", "### Board of Trustees", "- [3 June 2024](/about/welcome/board/meetings/2024_0603/)", "### ARIN Public Policy Meetings", "- [ARIN 53](/participate/meetings/ARIN53/)"], "lastUpdated": "2024-05-21", "url": "https://www.arin.net/participate/policy/drafts/ARIN_edit_2024_3/" },{ "number": "ARIN-edit-2019-1", "title": "Tracking Information", "status": "Implemented", "recommended": false, "problemStatement": "\nThere is confusing IPv4 policy in section NRPM Section 6.10.1.\n","policyStatement": "\nReplace sentence\n"These allocations will be no smaller than a /24 using IPv4 or a /48 using IPv6."\nwith\n"These allocations will be no longer than a /48."\n","implementationTime": "Immediate","problemStatement": "\nThere is confusing IPv4 policy in section NRPM Section 6.10.1.\n","policyStatement": "\nReplace sentence\n"These allocations will be no smaller than a /24 using IPv4 or a /48 using IPv6."\nwith\n"These allocations will be no smaller than a /48."\n","implementationTime": "Immediate","fullText": ["## Discussion Tracking", "## Mailing List:", "Formal introduction on PPML on [26 March 2019](https://lists.arin.net/pipermail/arin-ppml/2019-March/032791.html)", "[Origin - ARIN-prop-259](/participate/policy/proposals/2019/ARIN_prop_259_orig/)", "[Editorial Change - 26 March 2019](https://lists.arin.net/pipermail/arin-ppml/2019-March/032791.html)", "[Advanced to Board - 21 May 2019](https://lists.arin.net/pipermail/arin-ppml/2019-May/033421.html)", " ", "[Public Policy Mailing List](http://lists.arin.net/pipermail/arin-ppml/)", "## ARIN Public Policy Meeting:", "## ARIN Advisory Council:", "AC Shepherds: Chris Woodfield, Rob Seastrom", "- [25 January 2019](/vault/about/welcome/ac/meetings/2019_0125/)", "- [21 February 2019](/vault/about/welcome/ac/meetings/2019_0221/)", "- [21 March 2019](/vault/about/welcome/ac/meetings/2019_0321/)", "- [10 April 2019](/vault/about/welcome/ac/meetings/2019_0410/)", "- [16 May 2019](/vault/about/welcome/ac/meetings/2019_0516/)", "- [20 June 2019](/vault/about/welcome/ac/meetings/2019_0620/)", "## ARIN Board of Trustees:", "[20 June 2019](/vault/about/welcome/board/meetings/2019_0620/)", "## Revisions:", " ", "## Implementation:", "[10 July 2019](/announcements/20190710/)", "### Latest Version", "21 May 2019", "### Problem Statement", "There is confusing IPv4 policy in section NRPM Section 6.10.1.", "### Policy Statement", "Replace sentence", ""These allocations will be no smaller than a /24 using IPv4 or a /48 using IPv6."", "with", ""These allocations will be no longer than a /48."", "### Comments", "### Timetable for implementation", "Immediate", "##########", "Earlier version", "##########", "### Version Date", "26 March 2019", "### Problem Statement", "There is confusing IPv4 policy in section NRPM Section 6.10.1.", "### Policy Statement", "Replace sentence", ""These allocations will be no smaller than a /24 using IPv4 or a /48 using IPv6."", "with", ""These allocations will be no smaller than a /48."", "### Comments", "### Timetable for implementation", "Immediate"], "lastUpdated": "2022-10-06", "url": "https://www.arin.net/participate/policy/drafts/ARIN_edit_2019_1/" },{ "number": "ARIN-edit-2022-7", "title": "Editorial Clean-up of NRPM Section 2.16", "status": "Implemented", "recommended": false, "shepherds": ["Anita Nikolich", "Kat Hunter"], "problemStatement": "\nThis proposal continues the work that the ARIN AC NRPM Clean-up Working Group undertook to conduct an editorial review of the NRPM. It relates specifically to Sections 2.16. The focus of this proposal is to ensure that the intended meaning of the text is clear.\n","policyStatement": "Policy statement\nReplace the text "The term utilized shall have the following definitions when" in the first line with the text "When applied to IPv6 policies the term "utilized" shall be interpreted as follows"; and\nIn the paragraph numbered 2, replace the text :\n"Larger blocks shall have their utilization defined by dividing the number of provider assignment units assigned from the containing block by the total number of provider assignment units. This ratio will often be expressed as a percentage (e.g. a/t*100, for a /36 3072/4096 * 100 = 75% utilization)"\nWith the text:\n"Larger blocks shall have their utilization defined by dividing the number of provider assignment units assigned from the containing block (a) by the total number of provider assignment units (t). This ratio will often be expressed as a percentage (e.g., a/t*100, for a /36 3072/4096 * 100 = 75% utilization)."\n","implementationTime": "Immediate","fullText": ["## Current Text (26 July 2022)", "### Problem Statement", "This proposal continues the work that the ARIN AC NRPM Clean-up Working Group undertook to conduct an editorial review of the NRPM. It relates specifically to Sections 2.16. The focus of this proposal is to ensure that the intended meaning of the text is clear.", "### Policy statement", "Replace the text "The term utilized shall have the following definitions when" in the first line with the text "When applied to IPv6 policies the term "utilized" shall be interpreted as follows"; and", "In the paragraph numbered 2, replace the text :", ""Larger blocks shall have their utilization defined by dividing the number of provider assignment units assigned from the containing block by the total number of provider assignment units. This ratio will often be expressed as a percentage (e.g. a/t*100, for a /36 3072/4096 * 100 = 75% utilization)"", "With the text:", ""Larger blocks shall have their utilization defined by dividing the number of provider assignment units assigned from the containing block (a) by the total number of provider assignment units (t). This ratio will often be expressed as a percentage (e.g., a/t*100, for a /36 3072/4096 * 100 = 75% utilization)."", "### Comments", "This proposal is intended to be editorial in nature and to replace Prop-305 in part. Note to staff: The double quotes around "utilized" are not single quotes since the outer quotes for the text being affected by the proposal will disappear when implemented.", "### Timetable for implementation", "Immediate", "## Staff and Legal Review (13 September 2022)", "<a name="slr"></a>", "### Staff Understanding", "ARIN-edit-2022-7 makes minor editorial changes to NRPM Section 2.16, including references to variables in the utilization ratio.", "The policy text is clear and understandable.", "### Implementable as Written?", "Yes", "### Impact on ARIN Registry Operations and Services", "None.", "### Legal Review", "No material legal issue.", "### Implementation Timeframe Estimate", "3 months", "### Implementation Requirements", " - Staff training", " - Updates to public documentation", " - Updates to internal procedures and guidelines", "### Proposal/Draft Policy Text Assessed", "[26 July 2022](https://lists.arin.net/pipermail/arin-ppml/2022-July/036349.html)", "## History and Earlier Versions", "|Action|Date|", "|--- |--- |", "| [Proposal](https://www.arin.net/participate/policy/proposals/2022/ARIN_prop_315_orig/) | 14 June 2022 |", "| [Classified as Editorial Change](https://lists.arin.net/pipermail/arin-ppml/2022-July/036349.html) | 26 July 2022 |", "| [Advanced to Board of Trustees](https://lists.arin.net/pipermail/arin-ppml/2022-September/036532.html) | 20 September 2022 |", "| [Adopted](https://www.arin.net/about/welcome/board/meetings/2022_1019/) | 19 October 2022 |", "| Implemented | 22 March 2022 |", "## Related Meetings", "### Advisory Council", "- [21 July 2022](/about/welcome/ac/meetings/2022_0721/)", "- [18 August 2022](/about/welcome/ac/meetings/2022_0818/)", "- 15 September 2022", "### Board of Trustees", "### ARIN Public Policy Meetings"], "lastUpdated": "2018-07-02", "url": "https://www.arin.net/participate/policy/drafts/ARIN_edit_2022_7/" },{ "number": "ARIN-edit-2022-6", "title": "Editorial Clean-up of NRPM Sections 2.12 and 2.14", "status": "Implemented", "recommended": false, "shepherds": ["Anita Nikolich", "Kat Hunter"], "problemStatement": "\nThis proposal continues the work that the ARIN AC NRPM Clean-up Working Group undertook to conduct an editorial review of the NRPM. It relates specifically to Sections 2.12 and 2.14. The focus of this proposal is to eliminate the capitalization of certain words that are not defined in the NRPM and ensure that the intended meaning of the text is clear.\n","policyStatement": "Policy statement\nIn Section 2.12, change the text "Information" to "information", and in Section 2.14, change the text "shall mean" to "means", and change the text "Points of Presence (POPs), Datacenters, Central or Local" to "points of presence (POPs), datacenters, central or local".\n","implementationTime": "Immediate","fullText": ["## Current Text (26 July 2022)", "### Problem Statement", "This proposal continues the work that the ARIN AC NRPM Clean-up Working Group undertook to conduct an editorial review of the NRPM. It relates specifically to Sections 2.12 and 2.14. The focus of this proposal is to eliminate the capitalization of certain words that are not defined in the NRPM and ensure that the intended meaning of the text is clear.", "### Policy statement", "In Section 2.12, change the text "Information" to "information", and in Section 2.14, change the text "shall mean" to "means", and change the text "Points of Presence (POPs), Datacenters, Central or Local" to "points of presence (POPs), datacenters, central or local".", "### Timetable for implementation", "Immediate", "### Anything else", "This proposal is intended to be editorial in nature and to replace Prop-305 in part.", "## Staff and Legal Review (13 September 2022)", "<a name="slr"></a>", "### Staff Understanding", "ARIN-edit-2022-6 makes minor editorial changes to NRPM Sections 2.12 and 2.14.", "The policy text is clear and understandable.", "### Implementable as Written?", "Yes", "### Impact on ARIN Registry Operations and Services", "None.", "### Legal Review", "No material legal issue.", "### Implementation Timeframe Estimate", "3 months", "### Implementation Requirements", " - Staff training", " - Updates to public documentation", " - Updates to internal procedures and guidelines", "### Proposal/Draft Policy Text Assessed", "[26 July 2022](https://lists.arin.net/pipermail/arin-ppml/2022-July/036348.html)", "## History and Earlier Versions", "|Action|Date|", "|--- |--- |", "| [Proposal](https://www.arin.net/participate/policy/proposals/2022/ARIN_prop_313_orig/) | 14 June 2022 |", "| [Classified as Editorial Change](https://lists.arin.net/pipermail/arin-ppml/2022-July/036348.html) | 26 July 2022 |", "| [Advanced to Board of Trustees](https://lists.arin.net/pipermail/arin-ppml/2022-September/036532.html) | 20 September 2022 |", "| [Adopted](https://www.arin.net/about/welcome/board/meetings/2022_1019/) | 19 October 2022 |", "| Implemented | 22 March 2022 |", "## Related Meetings", "### Advisory Council", "- [21 July 2022](/about/welcome/ac/meetings/2022_0721/)", "- [18 August 2022](/about/welcome/ac/meetings/2022_0818/)", "- 15 September 2022", "### Board of Trustees", "### ARIN Public Policy Meetings"], "lastUpdated": "2018-07-02", "url": "https://www.arin.net/participate/policy/drafts/ARIN_edit_2022_6/" },{ "number": "ARIN-2022-10", "title": "Editorial Clean-up of NRPM Sections 2.4 and 2.5", "status": "Implemented", "recommended": false, "shepherds": ["Anita Nikolich", "Kat Hunter"], "problemStatement": "\nThis proposal continues the work that the ARIN AC NRPM Clean-up Working Group undertook to conduct an editorial review of the NRPM. It relates specifically to Sections 2.4 and 2.5. The focus of this proposal is to increase the consistency of terminology employed in the NRPM and ensure that the intended meaning of the text is clear.\n","policyStatement": "\nIn Section 2.4, change the text "address space" to "IP addresses", and remove the comma after the text "(ISPs)", and in Section 2.5, change the text "Address space" to "IP addresses" in each of the first four paragraphs and change the text "address space" to "IP addresses" in the last paragraph.\n","implementationTime": "Immediate","fullText": ["## Current Text (23 August 2022)", "### Problem Statement", "This proposal continues the work that the ARIN AC NRPM Clean-up Working Group undertook to conduct an editorial review of the NRPM. It relates specifically to Sections 2.4 and 2.5. The focus of this proposal is to increase the consistency of terminology employed in the NRPM and ensure that the intended meaning of the text is clear.", "### Policy Statement", "In Section 2.4, change the text "address space" to "IP addresses", and remove the comma after the text "(ISPs)", and in Section 2.5, change the text "Address space" to "IP addresses" in each of the first four paragraphs and change the text "address space" to "IP addresses" in the last paragraph.", "### Timetable for Implementation", "Immediate", "### Comments", "This proposal is intended to be editorial in nature and to replace Prop-305 in part.", "## Staff and Legal Review (14 October 2022)", "<a name="slr"></a>", "### Staff Understanding", "ARIN-edit-2022-10 makes minor editorial changes to NRPM Sections 2.4 and 2.5.", "The policy text is clear and understandable.", "### Implementable as Written?", "Yes", "### Impact on ARIN Registry Operations and Services", "None.", "### Legal Review", "No material legal issue.", "### Implementation Timeframe Estimate", "3 months", "### Implementation Requirements", " - Staff training", " - Updates to public documentation", " - Updates to internal procedures and guidelines", "### Proposal/Draft Policy Text Assessed", "[23 August 2022](https://lists.arin.net/pipermail/arin-ppml/2022-August/036463.html)", "## History and Earlier Versions", "|Action|Date|", "|--- |--- |", "| [Proposal](/participate/policy/proposals/2022/ARIN_prop_311_orig/) | 14 June 2022 |", "| [Classified as Editorial Change](https://lists.arin.net/pipermail/arin-ppml/2022-August/036463.html) | 23 August 2022 |", "| [New community review period](https://lists.arin.net/pipermail/arin-ppml/2022-October/036552.html) | |26 October 2022 |", "| [Advanced to Board of Trustees](https://lists.arin.net/pipermail/arin-ppml/2022-December/036642.html) | 20 December 2022 |", "| [Adopted](/about/welcome/board/meetings/2023_0130/) | 30 January 2023 |", "| Implemented | 22 March 2022 |", "## Related Meetings", "### Advisory Council", "- [21 July 2022](/about/welcome/ac/meetings/2022_0721/)", "- [18 August 2022](/about/welcome/ac/meetings/2022_0818/)", "- [15 September 2022](/about/welcome/ac/meetings/2022_0915/)", "- [21 October 2022](/about/welcome/ac/meetings/2022_1021/)", "- [17 November 2022](/about/welcome/ac/meetings/2022_1117/)", "- [15 December 2022](/about/welcome/ac/meetings/2022_1215/)", "### Board of Trustees", "### ARIN Public Policy Meetings"], "lastUpdated": "2018-07-02", "url": "https://www.arin.net/participate/policy/drafts/ARIN_edit_2022_10/" }]