[{ "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/)", " ", "### 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-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.\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 (24 March 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.", "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 |", "## Related Meetings", "### Advisory Council", "- [19 March 2026](/about/welcome/ac/meetings/2026_0319/)", "- [22 April 2026](/about/welcome/ac/meetings/2026_0422/)", " ", "### 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": false, "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": "\nChange the sentence "The initial assignment size will be determined by the number of sites justified below."\nTo: "Larger initial assignment sizes will be determined by the number of sites justified below."\nResulting with:\nOrganizations that meet at least one of the initial assignment criteria above are eligible to receive an initial assignment of /48. Larger initial assignment sizes 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…\n","implementationTime": "Immediate","fullText": ["## Current Text (4 February 2026)", "### 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", "Change the sentence "The initial assignment size will be determined by the number of sites justified below."", "To: "Larger initial assignment sizes will be determined by the number of sites justified below."", "Resulting with:", "Organizations that meet at least one of the initial assignment criteria above are eligible to receive an initial assignment of /48. Larger initial assignment sizes 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…", "### 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.", "## 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 | ", "## 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/)", "### 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": "Under Discussion", "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 |", "## 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/)", "### 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/)", " ", "### 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. ", "## 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 | 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/)", " ", "### 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-2024-11", "title": "IPv4 Transition Efficiency Reallocation Policy (ITERP)", "status": "Abandoned", "recommended": false, "shepherds": ["Brian Jones", "Kaitlyn Pellak"], "problemStatement": "\nAs the exhaustion of IPv4 addresses continues, ISPs and end-users face increasing challenges in managing their transition to IPv6. Many end-users require small amounts of IPv4 space to implement technologies like Carrier-Grade NAT (CG-NAT) or dual-stack environments, which are critical for their own IPv6 deployment efforts. Under the current NRPM 4.10 policy, ISPs are prohibited from reallocating portions of their IPv4 blocks to end-users, forcing these organizations to request larger, inefficiently used blocks (e.g., /24s) from ARIN.\nThis practice contributes to the unnecessary consumption of scarce IPv4 resources, as many end-users only need small blocks (e.g., /29s or /28s) for their CG-NAT and IPv6 transition processes. The inability to reallocate these smaller blocks results in wasteful allocations and hampers the overall efficiency of IPv4 address management.\nWithout a mechanism to allow ISPs to reallocate small portions of their NRPM 4.10 space to qualified end-users, the current policy inadvertently encourages inefficient IPv4 address utilization, which conflicts with ARIN’s goal of maximizing the use of remaining IPv4 resources while facilitating the widespread adoption of IPv6.\nThe problem is twofold:\n1. End-users are forced to request larger, underutilized IPv4 blocks for their IPv6 transition needs.\n2. ISPs are unable to efficiently manage and reallocate their IPv4 resources under NRPM 4.10 to meet end-user demands for small-scale CG-NAT and IPv6 transition deployments.\n","policyStatement": "\nAdd these bullets to section 4.10 of the NRPM to facilitate ARIN approved reallocation of 4.10 resources.\n- ISPs may reassign a /29 or /28 for their direct downstream customers for IPv6 transition only. ARIN reserves the right to validate any downstream allocations from ISPs to direct customers.\n- Anyone wishing to perform a reassignment of a 4.10 allocation must be approved through ARIN and meet all the justification requirements of this policy.\n","implementationTime": "Immediate. ","fullText": ["## Current Text (30 October 2024)", "### Problem Statement", "As the exhaustion of IPv4 addresses continues, ISPs and end-users face increasing challenges in managing their transition to IPv6. Many end-users require small amounts of IPv4 space to implement technologies like Carrier-Grade NAT (CG-NAT) or dual-stack environments, which are critical for their own IPv6 deployment efforts. Under the current NRPM 4.10 policy, ISPs are prohibited from reallocating portions of their IPv4 blocks to end-users, forcing these organizations to request larger, inefficiently used blocks (e.g., /24s) from ARIN.", "This practice contributes to the unnecessary consumption of scarce IPv4 resources, as many end-users only need small blocks (e.g., /29s or /28s) for their CG-NAT and IPv6 transition processes. The inability to reallocate these smaller blocks results in wasteful allocations and hampers the overall efficiency of IPv4 address management.", "Without a mechanism to allow ISPs to reallocate small portions of their NRPM 4.10 space to qualified end-users, the current policy inadvertently encourages inefficient IPv4 address utilization, which conflicts with ARIN’s goal of maximizing the use of remaining IPv4 resources while facilitating the widespread adoption of IPv6.", "The problem is twofold:", "1. End-users are forced to request larger, underutilized IPv4 blocks for their IPv6 transition needs.", "2. ISPs are unable to efficiently manage and reallocate their IPv4 resources under NRPM 4.10 to meet end-user demands for small-scale CG-NAT and IPv6 transition deployments.", "### Policy Statement", "Add these bullets to section 4.10 of the NRPM to facilitate ARIN approved reallocation of 4.10 resources.", "- ISPs may reassign a /29 or /28 for their direct downstream customers for IPv6 transition only. ARIN reserves the right to validate any downstream allocations from ISPs to direct customers.", "- Anyone wishing to perform a reassignment of a 4.10 allocation must be approved through ARIN and meet all the justification requirements of this policy.", "### Timetable for Implementation", "Immediate. ", "### Comments", "IPv4 Transition Efficiency Reallocation Policy (ITERP) and Its Impact on CG-NAT, IPv6, and Efficient Resource Use", "Utilization of Reallocated IP Space by End-Users and Small ISPs for CG-NAT", "Under the IPv4 Transition Efficiency Reallocation Policy (ITERP), end-users and even small ISPs can efficiently use reallocated IPv4 space for CG-NAT (Carrier-Grade NAT) while leveraging their IPv6 deployments. Many smaller ISPs, particularly those that only have NRPM 4.10 space and limited IPv4 allocations, could benefit from this policy by reallocating IPv4 subnets (e.g., /29 or /28) to their customers or other ISPs who require minimal IPv4 addresses for CG-NAT in dual-stack environments.", "Through the use of BGP for IPv6, along with alternative IPv4 multi-homing technologies like source and policy based routing combined with CG-NAT, end-users or small ISPs could even connect to multiple providers utilizing IPv6 natively while performing CG-NAT towards multiple providers over IPv4. This approach helps balance traffic, increase redundancy, and achieve better failover capabilities. By employing IPv6 for outward-facing traffic and CG-NAT for IPv4 communication, smaller networks can provide their customers a seamless experience without consuming large amounts of IPv4 space.", "Eligibility and Address Space Efficiency", "This policy amendment is strictly intended for organizations that would otherwise be eligible for a /24 under NRPM 4.10. Instead of receiving an entire /24 (256 addresses) that may go largely underutilized, these end-users could now request smaller blocks (e.g., /29s or /28s) from multiple providers that only hold NRPM 4.10 space. This allows for much more efficient use of IPv4 resources, as the smaller allocations can directly serve CG-NAT needs without wasting a significant portion of the address space.", "Such end-users are typically transitioning to IPv6 and need small amounts of IPv4 space only for backward compatibility and legacy systems. This policy ensures that they don’t have to unnecessarily consume large blocks of IPv4 addresses that are rapidly depleting, especially since most of their traffic will run over IPv6.", "Incentivizing IPv6 Deployment by ISPs", "This policy can also incentivize ISPs to evangelize IPv6 deployment to their customers. As the ISPs are held accountable for monitoring and reporting the usage of reallocated space, they are motivated to actively assist their customers in migrating to IPv6 to ensure compliance with ARIN’s policies. By reallocating IPv4 space under the NRPM 4.10 policy, ISPs will naturally push for greater IPv6 adoption and encourage their end-users to take advantage of the superior capabilities and scalability of IPv6.", "In many cases, ISPs can act as trusted technology advocates, guiding their customers through the transition process, offering resources, and providing technical support for deploying dual-stack environments. This not only supports IPv6 growth but also fosters stronger partnerships between ISPs and their customers as they collectively work toward the next generation of networking technologies.", "Supporting ISPs with Only NRPM 4.10 Space and IPv6", "Many ISPs, particularly newer or smaller ones, may only have access to NRPM 4.10 IPv4 space and IPv6 allocations. These ISPs often lack sufficient general-purpose IPv4 space but are fully invested in deploying IPv6 to their customers. The IPv4 Transition Efficiency Reallocation Policy provides an efficient and pragmatic way for these ISPs to serve end-users with small-scale CG-NAT needs, helping them facilitate IPv6 adoption without having to apply for entire /24s of IPv4 space that they don’t require.", "By allowing the reallocation of small IPv4 blocks to end-users for CG-NAT and IPv6 dual-stack environments, IPv4 exhaustion can be minimized, and numbering resources can be more efficiently utilized. These ISPs can push their customers toward IPv6 while offering minimal IPv4 resources needed for NAT and legacy services. This policy, therefore, promotes responsible IPv4 stewardship and accelerates the migration to IPv6.", "Conclusion: Efficient Use of Resources and Push for IPv6 Adoption", "The IPv4 Transition Efficiency Reallocation Policy (ITERP) ensures that IPv4 address space is used efficiently by allowing small allocations to end-users for specific transitional technologies like CG-NAT. By utilizing BGP for IPv6 and multi-homing technologies, end-users can effectively route traffic while minimizing their reliance on IPv4. This policy enables ISPs, particularly those that only have NRPM 4.10 space, to act as leaders in the push for IPv6, ensuring that numbering resources are preserved while advancing the deployment of the next generation of Internet technology.", "Other technologies are also available, such as routing IPv4 space over IPv6, which is supported in many modern routing systems, meaning a /32 of IPv4 space could be routed to an end-user over a native IPv6 network with no other space involved. This policy would encourage ISPs to evangelize and accelerate the deployment of an IPv6 Internet by making deploying IPv6 even more beneficial to end users, while also preserving the precious remaining IPv4 address space.", "By embracing this approach, ARIN can foster greater IPv6 adoption, prevent IPv4 depletion, and empower ISPs and end-users alike to move forward with innovative, future-proof network architectures.", "This policy provides a more efficient and responsible approach to achieving the goals initially intended by ARIN-2008-5, which aimed to allow the use of longer prefixes than /24s without causing the complications associated with ARIN allocating such longer prefixes directly.", "When ARIN-2008-5 was introduced, the idea was to allow networks to receive smaller allocations than /24, recognizing that many organizations, particularly those transitioning to IPv6, do not require a full /24 for their IPv4 needs. However, allocating smaller prefixes directly from ARIN would have created routing and administrative challenges, including concerns about route fragmentation and maintaining the integrity of the global routing table.", "The IPv4 Transition Efficiency Reallocation Policy (ITERP) resolves these issues by enabling ISPs to handle the reallocation of small IPv4 blocks (such as /29 or /28) from their NRPM 4.10 space, instead of ARIN directly assigning longer prefixes. This allows for more granular and flexible use of address space without fragmenting ARIN’s allocations, ensuring that the allocations remain efficient and manageable.", "Furthermore, by placing responsibility on the ISPs to ensure proper utilization, ITERP:", "- Minimizes the risk of route table bloat, as ISPs manage these smaller blocks within their own infrastructure.", "- Ensures IPv4 allocations are tied to specific, justified use cases (such as CG-NAT and IPv6 transition), aligning with the original intent of ARIN-2008-5 to avoid wasteful consumption of IPv4 addresses.", "In doing so, this policy not only promotes efficient use of IPv4 space but also strengthens the transition to IPv6 by encouraging ISPs to work closely with their customers on deploying dual-stack environments, thus driving greater IPv6 adoption. This policy balances the need for flexibility in smaller allocations while preventing the complications that could arise from direct ARIN allocations of smaller prefixes.", "## Staff and Legal Review (19 May 2025)", "### Staff Understanding", "Current staff implementation for NRPM section 4.10. Dedicated IPv4 Allocation to Facilitate IPv6 Deployment does not consider Reallocations/Reassignments made from parent reserved 4.10 IPv4 subnets to downstream customers/organizations to be within policy. Staff’s current practice is to issue allocations from the reserved 4.10 pool strictly for in-region use by the requesting organization and only for IPv6 translation services. The requesting organization must provide proof of having and using IPv6 translation services. ", " ", "Staff understands this Draft Policy would: ", "- allow ISPs to reassign, from their allocated parent NRPM section 4.10 subnet, a /29 or /28 to their direct downstream customers for IPv6 transition only.", "- explicitly reserve the right for ARIN staff to validate any downstream allocations from ISPs to direct customers.", "- require that anyone wishing to perform a reassignment of a NRPM section 4.10 allocation must be approved through ARIN and meet all the justification requirements of this policy.", " ", "This policy text is implementable as written, however ARIN staff notes the following:", " ", "Staff has concerns that this proposed policy change could enable inappropriate use of the section 4.10 reserved address block. Staff currently expends a significant amount of time and resources auditing, tracking, and reclaiming NRPM section 4.10 space where it has been misused by direct allocation holders. Allowing direct allocation holders to reallocate or reassign this reserved space to downstream customers adds additional difficulties to policy enforcement. Policy enforcement is further complicated if the customer holds multiple 4.10 reallocations/reassignments from multiple different ISPs. Once reallocated or reassigned, the space could be used for any purpose, effectively undermining the intent of the reservation. This would require additional resources in order to verify, track and manage these allocations. ", " ", "It is unclear how reallocating small blocks (such as /28 or /29) to downstream customers would support IPv6 transition needs like dual-stack DNS. These smaller blocks are not independently routable, and the upstream ISP would still be responsible for reverse DNS management—further complicating implementation and oversight.", " ", "This Draft Policy states, "ISPs may reassign…," and later states, "Anyone wishing to perform a reassignment…". Both ISPs and End-users receive direct allocations from ARIN, granting both types of organizations the ability to create reallocations and reassignments. If the intent is to permit anyone to reallocate/reassign (ISPs and End-users) or if the intent is to permit only ISPs to reallocate/reassign, then the Draft Policy text should be refined to reflect the intention clearly and consistently.", " ", "Usage of "reassign" and "allocation" are used interchangeably in the proposed text, however Reallocations and Reassignments have different permissions. Reallocations can be further reallocated or reassigned by the downstream customer to their own downstream customers. ", "Reassignments cannot be further reallocated or reassigned. Staff recommends refining the text to avoid confusion and a possible means for abuse.", "### Implementable as Written?", "Yes", "### Impact on ARIN Registry Operations and Services", "Increased staff resources required to adequately review NRPM section 4.10 requests and holdings. ", "### 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", "[30 October 2024](https://lists.arin.net/pipermail/arin-ppml/2024-October/037623.html)", "## History and Earlier Versions", "|Action|Date|", "|--- |--- |", "| [Proposal](/participate/policy/proposals/2024/ARIN_prop_338/) | 4 September 2024 |", "| [Draft Policy](https://lists.arin.net/pipermail/arin-ppml/2024-October/037623.html) | 30 October 2024 |", "| [Abandoned](https://lists.arin.net/pipermail/arin-ppml/2025-July/037942.html) | 1 July 2025 | ", "## Related Meetings", "### Advisory Council", "- [25 October 2024](/about/welcome/ac/meetings/2024_1025/)", "- [21 November 2024](/about/welcome/ac/meetings/2024_1121/)", "- [19 December 2024](/about/welcome/ac/meetings/2024_1219/)", "- [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/)", " ", "### Board of Trustees", "### ARIN Public Policy Meetings", "- [ARIN 55](/participate/meetings/ARIN55/)"], "lastUpdated": "2024-10-30", "url": "https://www.arin.net/participate/policy/drafts/2024_11/" },{ "number": "ARIN-2024-10", "title": "Registration Requirements and Timing of Requirements With Retirement of Section 4.2.3.7.2", "status": "Abandoned", "recommended": false, "shepherds": ["Alicia Trotman", "Lily Botsyoe"], "problemStatement": "\nRegistration is central to the value provided by ARIN to the community. Registry quality depends greatly upon the timely registration of reassignments from ISPs to end users. The motivation for registration has waned since the depletion of the free pool. Registration remains vital to a number of stakeholders, including law enforcement and network operators.\nThis proposal aims to modernize the registration-related policies in Section 4 by introducing language that is meant to remind ISPs of the importance of registration when feasible for the benefit of the community.\n","policyStatement": "\nREPLACE: Section 4.2.3.7.1\nOriginal Text:\n"Each IPv4 reassignment or reallocation containing a /29 or more addresses shall be registered via SWIP or a directory services system which meets the standards set forth in section 3.2."\nNew Text:\n"Each IPv4 reassignment or reallocation containing a /29 or more addresses shall be registered via an approved directory services system which meets the standards set forth in section 3.2, within fourteen calendar days."\nRETIRE: Section 4.2.3.7.2 - Reassignments and Reallocations Visible Within Seven Days\nRENAME: 6.5.5.1 from "Reassignment Information" to "Reassignment and Reallocation Information".\nREPLACE: 6.5.5.1\nOriginal Text:\n"Each static IPv6 reassignment or reallocation containing a /47 or more addresses, or subdelegation of any size that will be individually announced, shall be registered in the WHOIS directory via SWIP or a distributed service which meets the standards set forth in section 3.2. Reassignment and reallocation registrations shall include each client’s organizational information, except where specifically exempted by this policy."\nNew Text:\n"Each static IPv6 reassignment or reallocation containing a /47 or more addresses, or subdelegation of any size that will be individually announced, shall be registered via an approved directory services system which meets the standards set forth in section 3.2. Reassignment and reallocation registrations shall include each client’s organizational information, except where specifically exempted by this policy."\nRENAME: 6.5.5.2 from "Reassignments and Reallocations Visible Within Seven Days" to "Reassignments and Reallocations Visible Within Fourteen Days"\nREPLACE: Section 6.5.5.2\nOriginal Text:\n"All reassignments and reallocations shall be made visible as required in section 6.5.5.1 within seven calendar days of reassignment or reallocation."\nNew Text: \n"All reassignments and reallocations shall be made visible as required in section 6.5.5.1 within fourteen calendar days of reassignment or reallocation.\n","implementationTime": "Immediate. ","fullText": ["## Current Text (18 July 2025)", "### Problem Statement", "Registration is central to the value provided by ARIN to the community. Registry quality depends greatly upon the timely registration of reassignments from ISPs to end users. The motivation for registration has waned since the depletion of the free pool. Registration remains vital to a number of stakeholders, including law enforcement and network operators.", "This proposal aims to modernize the registration-related policies in Section 4 by introducing language that is meant to remind ISPs of the importance of registration when feasible for the benefit of the community.", "### Policy Statement", "REPLACE: Section 4.2.3.7.1", "Original Text:", ""Each IPv4 reassignment or reallocation containing a /29 or more addresses shall be registered via SWIP or a directory services system which meets the standards set forth in section 3.2."", "New Text:", ""Each IPv4 reassignment or reallocation containing a /29 or more addresses shall be registered via an approved directory services system which meets the standards set forth in section 3.2, within fourteen calendar days."", "RETIRE: Section 4.2.3.7.2 - Reassignments and Reallocations Visible Within Seven Days", "RENAME: 6.5.5.1 from "Reassignment Information" to "Reassignment and Reallocation Information".", "REPLACE: 6.5.5.1", "Original Text:", ""Each static IPv6 reassignment or reallocation containing a /47 or more addresses, or subdelegation of any size that will be individually announced, shall be registered in the WHOIS directory via SWIP or a distributed service which meets the standards set forth in section 3.2. Reassignment and reallocation registrations shall include each client’s organizational information, except where specifically exempted by this policy."", "New Text:", ""Each static IPv6 reassignment or reallocation containing a /47 or more addresses, or subdelegation of any size that will be individually announced, shall be registered via an approved directory services system which meets the standards set forth in section 3.2. Reassignment and reallocation registrations shall include each client’s organizational information, except where specifically exempted by this policy."", "RENAME: 6.5.5.2 from "Reassignments and Reallocations Visible Within Seven Days" to "Reassignments and Reallocations Visible Within Fourteen Days"", "REPLACE: Section 6.5.5.2", "Original Text:", ""All reassignments and reallocations shall be made visible as required in section 6.5.5.1 within seven calendar days of reassignment or reallocation."", "New Text: ", ""All reassignments and reallocations shall be made visible as required in section 6.5.5.1 within fourteen calendar days of reassignment or reallocation.", "### Timetable for Implementation", "Immediate. ", "## Staff and Legal Review (30 September 2024)", "### Staff Understanding", "Staff understands that this policy will eliminate the outdated term of SWIP in section 4, and simplify the language to use directory services, which includes SWIP and RWhois. This draft policy will combine sections of 4.2.3.7.1 and 4.2.3.7.2 into a single section, further simplifying the policy text. It also extends the time to publicly report IPv4 reassignments and reallocations from seven days to 14 days. This draft policy is not clear on the timing being calendar days. If this policy is adopted, staff would implement it as 14 calendar days to maintain consistency with the previous policy and current practice.", "This draft policy also changes the title of section 6.5.5.1 to include IPv6 Reallocations, aligning it with current staff practices. Staff suggests updating additional text in section 6 to remain consistent with the proposed changes to section 4.", "Section 6.5.5.2 outlines that reassignments and reallocations are to be reported within seven calendar days. This introduces differences in reassignment and reallocation requirements for holders of IPv4 (14 days) and IPv6 (7 days), which could lead to confusion for customers holding both IPv4 and IPv6. Staff recommends updating section 6.5.5.2 to 14 calendar days, being consistent with the proposed change in section 4.2.3.7.1.", "Also of note, section 6.5.5.1 uses the terms SWIP and distributed service while the proposed revision to 4.2.3.7.1 uses directory services system. Staff recommends using directory services system to be consistent with revised section 4.2.3.7.1.", "### 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", "[13 September 2024](https://lists.arin.net/pipermail/arin-ppml/2024-September/037579.html)", "## History and Earlier Versions", "|Action|Date|", "|--- |--- |", "| [Proposal](/participate/policy/proposals/2024/ARIN_prop_337/) | 17 July 2024 |", "| [Draft Policy](https://lists.arin.net/pipermail/arin-ppml/2024-August/037566.html) | 20 August 2024 |", "| [Revised](https://lists.arin.net/pipermail/arin-ppml/2024-September/037579.html) | 13 September 2024 |", "| [Revised](https://lists.arin.net/pipermail/arin-ppml/2024-November/037636.html) | 21 November 2024 |", "| [Revised](https://lists.arin.net/pipermail/arin-ppml/2025-July/038032.html) | 18 July 2025 |", "| [Abandoned](https://lists.arin.net/pipermail/arin-ppml/2025-August/038061.html) | 26 August 2025 |", "## Related Meetings", "### Advisory Council", "- [15 August 2024](/about/welcome/ac/meetings/2024_0815/)", "- [19 September 2024](/about/welcome/ac/meetings/2024_0919/)", "- [25 October 2024](/about/welcome/ac/meetings/2024_1025/)", "- [21 November 2024](/about/welcome/ac/meetings/2024_1121/)", "- [19 December 2024](/about/welcome/ac/meetings/2024_1219/)", "- [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/)", " ", "### Board of Trustees", "### ARIN Public Policy Meetings", "- [ARIN 54](/participate/meetings/ARIN54/)", "- [ARIN 55](/participate/meetings/ARIN55/)"], "lastUpdated": "2024-09-13", "url": "https://www.arin.net/participate/policy/drafts/2024_10/" },{ "number": "ARIN-2024-9", "title": "Remove Outdated Carveout for Community Networks", "status": "Implemented", "recommended": true, "shepherds": ["Alison Wood", "Alicia Trotman"], "problemStatement": "\nSections 2.11 and 6.5.9 define Community Networks, and provide special dispensation for Community Networks to receive only a /40 of IPv6 space. When these sections were last materially updated in 2017 (ARIN-2017-8), the smallest allowed allocation to a normal ARIN LIR was a /36, so the Community Networks sections still provided value. In 2020 (ARIN-2020-3) however, the NRPM was amended such that any LIR may request to receive only a /40 for any reason. As such, the carveout for Community Networks to receive a /40 is no longer necessary, and potentially confusing.\n","policyStatement": "\nRetire Sections 2.11 and 6.5.9\n","implementationTime": "Immediate. ","fullText": ["## Current Text (23 June 2024)", "### AC Assessment of Conformance with the [Principles of Internet Number Resource Policy](/participate/policy/pdp/#4-principles-of-internet-number-resource-policy)", "ARIN policy 2024-9 "Remove Outdated Carveout for Community Networks" is fair and impartial, technically sound and has the support of the community to move to recommended status. The policy, if adopted, will retire sections 2.11 and 6.5.9 regarding Community Networks from the NRPM as there is no longer any advantage to obtaining space as a community network, and qualifying for community space is in fact more difficult than without the community requirements.", "### Problem Statement", "Sections 2.11 and 6.5.9 define Community Networks, and provide special dispensation for Community Networks to receive only a /40 of IPv6 space. When these sections were last materially updated in 2017 (ARIN-2017-8), the smallest allowed allocation to a normal ARIN LIR was a /36, so the Community Networks sections still provided value. In 2020 (ARIN-2020-3) however, the NRPM was amended such that any LIR may request to receive only a /40 for any reason. As such, the carveout for Community Networks to receive a /40 is no longer necessary, and potentially confusing.", "### Policy Statement", "Retire Sections 2.11 and 6.5.9", "### Timetable for Implementation", "Immediate. ", "## Staff and Legal Review (15 September 2024) ", "### Staff Understanding", "This policy intends to remove an outdated and unused policy specific to one very narrow segment of potential users. While the qualification requirements for Community Networks (6.5.9) differ from those outlined in the Initial Allocations and Subsequent Allocations sections (6.5.2.2 and 6.5.3), staff does not expect that this change would affect any potential Community Network.", "Section 6.5.9 accommodates the anticipated tighter budgets of Community Networks by allowing a smaller allocation of a /40. However, section 6.5.2.2 also allows for a /40 allocation, so the same budgetary aide is being realized for smaller network operators, including Community Networks.", "Additionally, section 6.5.9.1 requires community networks to demonstrate they meet the definition outlined in section 2.11. This may involve providing documentation, notarized affidavits, or other evidence.", "In contrast, and paraphrasing, section 6.5.2.2 allows applicants to qualify by: ", "- Having, or are able to qualify for IPv4 under current policy", "- Being, or committing to becoming, multihomed for IPv6", "- Providing technical justification indicating why the allocation necessary", "In staff’s experience, organizations can generally meet the full text of the IPv6 requirements with relative ease under the first or second criteria. Since there is currently no requirement for community network operators to apply under the Community Networks policy, staff believes that removing this unused and potentially confusing policy may benefit prospective community network operators.", "### 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 July 2024](https://lists.arin.net/pipermail/arin-ppml/2024-July/037466.html)", "## History and Earlier Versions", "|Action|Date|", "|--- |--- |", "| [Proposal](/participate/policy/proposals/2024/ARIN_prop_336/) | 21 June 2024 |", "| [Draft Policy](https://lists.arin.net/pipermail/arin-ppml/2024-July/037466.html) | 23 July 2024 |", "| [Recommended Draft Policy](https://lists.arin.net/pipermail/arin-ppml/2024-September/037583.html) | 24 September 2024 |", "| [Last Call](https://lists.arin.net/pipermail/arin-ppml/2024-October/037621.html) | 30 October 2024 |", "| [Advanced to Board of Trustees](https://lists.arin.net/pipermail/arin-ppml/2024-November/037637.html) | 26 November 2024 | ", "| [Adopted](/about/welcome/board/meetings/2024_1209/) | 9 December 2024 | ", "| Implemented | 4 March 2025 |", "## Related Meetings", "### Advisory Council", "- [18 July 2024](/about/welcome/ac/meetings/2024_0718/)", "- [15 August 2024](/about/welcome/ac/meetings/2024_0815/)", "- [19 September 2024](/about/welcome/ac/meetings/2024_0919/)", "- [25 October 2024](/about/welcome/ac/meetings/2024_1025/)", "- [21 November 2024](/about/welcome/ac/meetings/2024_1121/)", "### Board of Trustees", "- [9 December 2024](/about/welcome/board/meetings/2024_1209/)", "### ARIN Public Policy Meetings", "- [ARIN 54](/participate/meetings/ARIN54/)"], "lastUpdated": "2024-07-23", "url": "https://www.arin.net/participate/policy/drafts/2024_9/" },{ "number": "ARIN-2024-8", "title": "Restrict the Largest Initial IPv6 Allocation to /20", "status": "Abandoned", "recommended": false, "shepherds": ["Liz Goodson", "Gus Reese"], "problemStatement": "\nIn order to promote aggregation, the NRPM currently allows initial allocations up to a /16. However, the entire IPv6 address space only contains 65536 /16s, and the space allocated to IANA for globally routable purposes only contains 8192 /16s. Therefore, a /16 is a sufficiently large portion of the IPv6 address space that the goal of conservation starts to outweigh the goal of aggregation.\n","policyStatement": "\n6.5.2.1b: Replace "In no case shall an ISP receive more than a /16 initial allocation."with "In no case shall a LIR receive more than a /20 initial allocation."\n","implementationTime": "Immediate. ","fullText": ["## Current Text (25 June 2024)", "### Problem Statement", "In order to promote aggregation, the NRPM currently allows initial allocations up to a /16. However, the entire IPv6 address space only contains 65536 /16s, and the space allocated to IANA for globally routable purposes only contains 8192 /16s. Therefore, a /16 is a sufficiently large portion of the IPv6 address space that the goal of conservation starts to outweigh the goal of aggregation.", "### Policy Statement", "6.5.2.1b: Replace "In no case shall an ISP receive more than a /16 initial allocation."with "In no case shall a LIR receive more than a /20 initial allocation."", "### Timetable for Implementation", "Immediate. ", "### Comments", "A quick look at ARIN's stats shows that only a single IPv6 allocation exceeds a /20 in size:", "grep "ipv6"delegated-arin-extended-latest | grep allocated | cut -d '|' -f 5 | sort | uniq -c ", "1 16 ", "8 20 ", "22 22 ", "39 24 ", "2 27 ", "127 28 ", "15 29 ", "6 30 ", "21 31 ", "4236 32 ", "1 33 ", "2 35 ", "1401 36 ", "1 37 ", "1 38 ", "1050 40 ", "11 41 ", "13 42 ", "9 43 ", "851 44 ", "16 45 ", "15 46 ", "26 47 ", "1754 48 ", "## History and Earlier Versions", "|Action|Date|", "|--- |--- |", "| [Proposal](/participate/policy/proposals/2024/ARIN_prop_335/) | 31 May 2024 |", "| [Draft Policy](https://lists.arin.net/pipermail/arin-ppml/2024-June/037406.html) | 25 June 2024 |", "| [Abandoned](https://lists.arin.net/pipermail/arin-ppml/2024-October/037617.html) | 30 October 2024 |", "## Related Meetings", "### Advisory Council", "- [20 June 2024](/about/welcome/ac/meetings/2024_0620/)", "- [18 July 2024](/about/welcome/ac/meetings/2024_0718/)", "- [15 August 2024](/about/welcome/ac/meetings/2024_0815/)", "- [19 September 2024](/about/welcome/ac/meetings/2024_0919/)", "- [25 October 2024](/about/welcome/ac/meetings/2024_1025/)", " ", "### Board of Trustees", "### ARIN Public Policy Meetings", "- [ARIN 54](/participate/meetings/ARIN54/)"], "lastUpdated": "2024-06-25", "url": "https://www.arin.net/participate/policy/drafts/2024_8/" },{ "number": "ARIN-2024-7", "title": "Addition of Definitions for General and Special Purpose IP Addresses", "status": "Abandoned", "recommended": false, "shepherds": ["Kaitlyn Pellak", "Alison Wood"], "problemStatement": "\nThe Number Resource Policy Manual (NRPM) often treats general purpose and special purpose IP addresses differently. Unfortunately, we don’t have a convenient to use term to describe these categories, so policy often becomes either excessively wordy or does not correctly capture the intent. Examples of this can be found in section 4.1.8 of the NRPM, and in (currently pending) Draft Policies ARIN-2023-8 (where the fact that 4.4 and 4.10 space isn’t counted against an organization is repeated numerous times) and ARIN-2022-12 (where the text does not exclude 4.4 and 4.10 allocations from being counted against an organization, but it is the intent that those allocations should be ignored). Additionally, temporary allocations under section 11 are rarely carved out, even when 4.4 and 4.10 are, even though it is likely the policy’s intent that these too should be ignored.\n","policyStatement": "\nAdd the following definition to Section 2\n2.18 Reserved IPv4 and IPv6 Addresses \nAddresses that are reserved by ARIN for specific purposes including, but not limited to; maintaining critical infrastructure, facilitating IPv6 deployment, or temporary experimental purposes as approved by ARIN.\n","implementationTime": "Immediate. ","fullText": ["## Current Text (13 December 2024)", "### Problem Statement", "The Number Resource Policy Manual (NRPM) often treats general purpose and special purpose IP addresses differently. Unfortunately, we don’t have a convenient to use term to describe these categories, so policy often becomes either excessively wordy or does not correctly capture the intent. Examples of this can be found in section 4.1.8 of the NRPM, and in (currently pending) Draft Policies ARIN-2023-8 (where the fact that 4.4 and 4.10 space isn’t counted against an organization is repeated numerous times) and ARIN-2022-12 (where the text does not exclude 4.4 and 4.10 allocations from being counted against an organization, but it is the intent that those allocations should be ignored). Additionally, temporary allocations under section 11 are rarely carved out, even when 4.4 and 4.10 are, even though it is likely the policy’s intent that these too should be ignored.", "### Policy Statement", "Add the following definition to Section 2", "2.18 Reserved IPv4 and IPv6 Addresses ", "Addresses that are reserved by ARIN for specific purposes including, but not limited to; maintaining critical infrastructure, facilitating IPv6 deployment, or temporary experimental purposes as approved by ARIN.", "### Timetable for Implementation", "Immediate. ", "### Comments", "I originally intended to give a better definition for the general purpose addresses (something along the lines of "An IPvX address indefinitely issued by ARIN without special limitations on its use"), but opted for the current proposal to make it clear that all addresses in scope for the NRPM are either Special Purpose or General Purpose, and that the 2 definitions are mutually exclusive.", "Note that this proposal only adds definitions and does not change any of the existing text; I figured it’d be better to leave any use of the definitions to a future policy proposal.", "## History and Earlier Versions", "|Action|Date|", "|--- |--- |", "| [Proposal](/participate/policy/proposals/2024/ARIN_prop_331/) | 19 April 2024 |", "| [Draft Policy](https://lists.arin.net/pipermail/arin-ppml/2024-June/037405.html) | 25 June 2024 |", "| [Revised](https://lists.arin.net/pipermail/arin-ppml/2024-December/037645.html) | 13 December 2024 |", "| [Abandoned](https://lists.arin.net/pipermail/arin-ppml/2025-May/037869.html) | 5 May 2025 |", "## Related Meetings", "### Advisory Council", "- [20 June 2024](/about/welcome/ac/meetings/2024_0620/)", "- [18 July 2024](/about/welcome/ac/meetings/2024_0718/)", "- [15 August 2024](/about/welcome/ac/meetings/2024_0815/)", "- [19 September 2024](/about/welcome/ac/meetings/2024_0919/)", "- [25 October 2024](/about/welcome/ac/meetings/2024_1025/)", "- [21 November 2024](/about/welcome/ac/meetings/2024_1121/)", "- [19 December 2024](/about/welcome/ac/meetings/2024_1219/)", "- [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/)", " ", "### Board of Trustees", "### ARIN Public Policy Meetings", "- [ARIN 54](/participate/meetings/ARIN54/)", "- [ARIN 55](/participate/meetings/ARIN55/)"], "lastUpdated": "2024-12-13", "url": "https://www.arin.net/participate/policy/drafts/2024_7/" },{ "number": "ARIN-2024-6", "title": "6.5.1a Definition Update", "status": "Abandoned", "recommended": false, "shepherds": ["Kendrick Knowles", "Doug Camin"], "problemStatement": "\nSection 2.4 of the NRMP defines "A Local Internet Registry (LIR) is an IR that primarily assigns IP addresses to the users of the network services that it provides. LIRs are generally Internet Service Providers (ISPs) whose customers are primarily end users and possibly other ISPs." This statement differs from the intention of section 6.5.1a that allows section 6 to use LIR and ISP interchangeably. This proposal seeks to clarify the text in section 6.\n","policyStatement": "\nChange the text from:\nThe terms ISP and LIR are used interchangeably in this document and any use of either term shall be construed to include both meanings.\nto\nThe terms ISP and LIR are used interchangeably in this SECTION and any use of either term shall be construed to include both meanings.\n","implementationTime": "Immediate. ","fullText": ["## Current Text (3 May 2024)", "### Problem Statement", "Section 2.4 of the NRMP defines "A Local Internet Registry (LIR) is an IR that primarily assigns IP addresses to the users of the network services that it provides. LIRs are generally Internet Service Providers (ISPs) whose customers are primarily end users and possibly other ISPs." This statement differs from the intention of section 6.5.1a that allows section 6 to use LIR and ISP interchangeably. This proposal seeks to clarify the text in section 6.", "### Policy Statement", "Change the text from:", "The terms ISP and LIR are used interchangeably in this document and any use of either term shall be construed to include both meanings.", "to", "The terms ISP and LIR are used interchangeably in this SECTION and any use of either term shall be construed to include both meanings.", "### Timetable for Implementation", "Immediate. ", "## History and Earlier Versions", "|Action|Date|", "|--- |--- |", "| [Proposal](/participate/policy/proposals/2024/ARIN_prop_334/) | 3 May 2024 |", "| [Draft Policy](https://lists.arin.net/pipermail/arin-ppml/2024-May/037319.html) | 21 May 2024 |", "| [Abandoned](https://lists.arin.net/pipermail/arin-ppml/2024-October/037617.html) | 30 October 2024 |", "## Related Meetings", "### Advisory Council", "- [16 May 2024](/about/welcome/ac/meetings/2024_0516/)", "- [20 June 2024](/about/welcome/ac/meetings/2024_0620/)", "- [18 July 2024](/about/welcome/ac/meetings/2024_0718/)", "- [15 August 2024](/about/welcome/ac/meetings/2024_0815/)", "- [19 September 2024](/about/welcome/ac/meetings/2024_0919/)", "- [25 October 2024](/about/welcome/ac/meetings/2024_1025/)", " ", "### Board of Trustees", "### ARIN Public Policy Meetings", "- [ARIN 54](/participate/meetings/ARIN54/)"], "lastUpdated": "2024-05-21", "url": "https://www.arin.net/participate/policy/drafts/2024_6/" },{ "number": "ARIN-2024-5", "title": "Rewrite of NRPM Section 4.4 Micro-Allocation", "status": "Abandoned", "recommended": false, "shepherds": ["Chris Woodfield", "William Herrin"], "problemStatement": "\nThe current NRPM Section 4.4 language hasn’t aged well. As the ARIN 53 policy experience report demonstrated, 4.4 has also become difficult to implement by ARIN staff. The growth and use of Internet Exchanges have also changed. The overhaul seeks to improve technical soundness, respect the privilege of a dedicated pool and to more closely observe conservation principles using clear, minimum and enforceable requirements and underscoring the value of routability of allocated prefixes as required.\n","policyStatement": "\n4.4 Critical Internet Infrastructure (CII) Allocations\nARIN will reserve a /15 equivalent of IPv4 address space for critical Internet infrastructure (CII) within the ARIN RIR service area. Allocations from this pool will be no smaller than a /24. Sparse allocation will be used whenever practical. CII includes Internet exchange points (IXPs), core DNS service providers (e.g. ICANN-sanctioned root and ccTLD operators) ARIN, and IANA.\nICANN-sanctioned gTLD operators may justify up to the equivalent of an IPv4 /23 block for each authorized gTLD, allocated from the free pool or received via transfer, but not from the above reservation. This limit of a /23 equivalent per gTLD does not apply to gTLD allocations made under previous policy.\nPrevious allocations under this policy must continue to meet the justification requirements of this policy.\nUse of this policy for CII is voluntary; address holders that qualify for CII allocations may use allocations obtained via other means for CII resources. ARIN will publish a record of all addresses allocated under this section for research purposes.\n Internet Exchange Allocations\nInternet exchange operators must justify their need by providing a minimum of three initial participants not under common control connected to a shared, physical switching fabric to be used for the purpose of the exchange of data destined for and between the respective networks. This justification must include participant names, ASNs and contact information for each named participant. The applicant’s Internet exchange-affiliated ASNs are not eligible to be included in meeting the participant requirement.\nAllocated addresses may be publicly reachable at the operator’s discretion but must be assigned only to resources directly related to the operation of the IXP.\n TLD Allocations\nTLD operators will provide justification of their need and certification of their status as currently active zone operators.\n Additional Requests\nA recipient may request up to a 24-month supply of IPv4 resources under this section. Requests for additional resources under this section will be evaluated using Section 4.2.4.1’s usage requirements.\nIn cases where fulfilling the request by expanding the existing allocation is not possible, a single prefix sized to accommodate both the prior and additional requested allocation will be issued to facilitate renumbering. The original allocation must be returned to ARIN within 12 months of the new allocation.\n","implementationTime": "Immediate. ","fullText": ["## Current Text (7 July 2025)", "### Problem Statement", "The current NRPM Section 4.4 language hasn’t aged well. As the ARIN 53 policy experience report demonstrated, 4.4 has also become difficult to implement by ARIN staff. The growth and use of Internet Exchanges have also changed. The overhaul seeks to improve technical soundness, respect the privilege of a dedicated pool and to more closely observe conservation principles using clear, minimum and enforceable requirements and underscoring the value of routability of allocated prefixes as required.", "### Policy Statement", "4.4 Critical Internet Infrastructure (CII) Allocations", "ARIN will reserve a /15 equivalent of IPv4 address space for critical Internet infrastructure (CII) within the ARIN RIR service area. Allocations from this pool will be no smaller than a /24. Sparse allocation will be used whenever practical. CII includes Internet exchange points (IXPs), core DNS service providers (e.g. ICANN-sanctioned root and ccTLD operators) ARIN, and IANA.", "ICANN-sanctioned gTLD operators may justify up to the equivalent of an IPv4 /23 block for each authorized gTLD, allocated from the free pool or received via transfer, but not from the above reservation. This limit of a /23 equivalent per gTLD does not apply to gTLD allocations made under previous policy.", "Previous allocations under this policy must continue to meet the justification requirements of this policy.", "Use of this policy for CII is voluntary; address holders that qualify for CII allocations may use allocations obtained via other means for CII resources. ARIN will publish a record of all addresses allocated under this section for research purposes.", " Internet Exchange Allocations", "Internet exchange operators must justify their need by providing a minimum of three initial participants not under common control connected to a shared, physical switching fabric to be used for the purpose of the exchange of data destined for and between the respective networks. This justification must include participant names, ASNs and contact information for each named participant. The applicant’s Internet exchange-affiliated ASNs are not eligible to be included in meeting the participant requirement.", "Allocated addresses may be publicly reachable at the operator’s discretion but must be assigned only to resources directly related to the operation of the IXP.", " TLD Allocations", "TLD operators will provide justification of their need and certification of their status as currently active zone operators.", " Additional Requests", "A recipient may request up to a 24-month supply of IPv4 resources under this section. Requests for additional resources under this section will be evaluated using Section 4.2.4.1’s usage requirements.", "In cases where fulfilling the request by expanding the existing allocation is not possible, a single prefix sized to accommodate both the prior and additional requested allocation will be issued to facilitate renumbering. The original allocation must be returned to ARIN within 12 months of the new allocation.", "### Timetable for Implementation", "Immediate. ", "## Staff and Legal Review (21 August 2025)", "### Staff Understanding", "Staff understands that this draft policy seeks to address ambiguities in the current policy language and formalize existing ARIN practices.", "Under current practice, Internet exchange points (IXPs) are allocated a /24. Requests for allocations larger than a /24 are evaluated based on other policies outlined in Section 4, including utilization requirements. This draft policy clarifies that IP addresses issued under Section 4.4 are intended exclusively for operational use directly related to the IXP and not for other purposes. This draft policy resolves any ambiguity regarding the routing of IXP space and specifies that IP addresses allocated under this policy may be made publicly reachable at the operator’s discretion. The draft also establishes that a qualified recipient may request up to a 24-month supply of IPv4 addresses for the IXP. Any justifications for allocations beyond a /24 will be reviewed in accordance with the relevant policies in Section 4.", "Additionally, this draft policy clarifies ICANN-sanctioned gTLDs may not receive IPv4 allocations under section 4.4, however they may receive up to a /23 equivalent via the free pool or transfer for each gTLD.", "Staff notes the change of "the RIRs" to "ARIN" in the list of examples of critical infrastructure providers of the Internet. This aligns with ARIN’s current business practice.", "### Implementable as Written?", "Yes", "### Impact on ARIN Registry Operations and Services", "Allowing public announcement of section 4.4 IPv4 addresses will increase time and effort needed by ARIN staff to review and process section 4.4 requests. This impact is expected to be minimal.", "### 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", "[7 July 2025](https://lists.arin.net/pipermail/arin-ppml/2025-July/037948.html)", "## History and Earlier Versions", "|Action|Date|", "|--- |--- |", "| [Proposal](/participate/policy/proposals/2024/ARIN_prop_333/) | 23 April 2024 |", "| [Draft Policy](https://lists.arin.net/pipermail/arin-ppml/2024-May/037318.html) | 21 May 2024 |", "| [Revised](https://lists.arin.net/pipermail/arin-ppml/2024-December/037640.html) | 10 December 2024 |", "| [Revised](https://lists.arin.net/pipermail/arin-ppml/2025-March/037751.html) | 6 March 2025 |", "| [Revised](https://lists.arin.net/pipermail/arin-ppml/2025-March/037760.html) | 18 March 2025 | ", "| [Revised](https://lists.arin.net/pipermail/arin-ppml/2025-July/037948.html) | 7 July 2025 |", "| [Recommended Draft Policy](https://lists.arin.net/pipermail/arin-ppml/2025-September/038150.html) | 18 September 2025 |", "| [Draft Policy](https://lists.arin.net/pipermail/arin-ppml/2025-November/038186.html) | 5 November |", "| Abandoned | 24 February 2026 |", "## Related Meetings", "### Advisory Council", "- [16 May 2024](/about/welcome/ac/meetings/2024_0516/)", "- [20 June 2024](/about/welcome/ac/meetings/2024_0620/)", "- [18 July 2024](/about/welcome/ac/meetings/2024_0718/)", "- [15 August 2024](/about/welcome/ac/meetings/2024_0815/)", "- [19 September 2024](/about/welcome/ac/meetings/2024_0919/)", "- [25 October 2024](/about/welcome/ac/meetings/2024_1025/)", "- [21 November 2024](/about/welcome/ac/meetings/2024_1121/)", "- [19 December 2024](/about/welcome/ac/meetings/2024_1219/)", "- [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", "### Board of Trustees", "### ARIN Public Policy Meetings", "- [ARIN 54](/participate/meetings/ARIN54/)", "- [ARIN 55](/participate/meetings/ARIN55/)", "- [ARIN 56](/participate/meetings/ARIN56/)"], "lastUpdated": "2024-05-21", "url": "https://www.arin.net/participate/policy/drafts/2024_5/" },{ "number": "ARIN-2024-4", "title": "Internet Exchange Point Definition", "status": "Abandoned", "recommended": false, "shepherds": ["Brian Jones", "Matthew Gamble"], "problemStatement": "\nThe term "Internet Exchange Point" appears in the Number Resource Policy Manual (NRPM) as an entity eligible for special allocations and treatment but is not clearly defined. This proposal seeks to define the term as it relates to ARIN policies.\n","policyStatement": "\n2.18 Internet Exchange Point:\nAn Internet Exchange Point, also known as an Exchange Point, Internet Exchange, IX, IXP or NAP, is a shared, physical switching fabric used by three or more autonomous systems for the exchange of data destined for and between their respective networks.\n","implementationTime": "Immediate. ","fullText": ["## Current Text (21 June 2024)", "### Problem Statement", "The term "Internet Exchange Point" appears in the Number Resource Policy Manual (NRPM) as an entity eligible for special allocations and treatment but is not clearly defined. This proposal seeks to define the term as it relates to ARIN policies.", "### Policy Statement", "2.18 Internet Exchange Point:", "An Internet Exchange Point, also known as an Exchange Point, Internet Exchange, IX, IXP or NAP, is a shared, physical switching fabric used by three or more autonomous systems for the exchange of data destined for and between their respective networks.", "### Timetable for Implementation", "Immediate. ", "## Staff and Legal Review (3 October 2024)", "### Staff Understanding", "This draft policy introduces a new subsection to the Number Resource Policy Manual defining an Internet exchange point. The proposed definition specifies in part that an Internet exchange point must consist of three or more autonomous systems. Section 4.4 Micro-allocation supports this specification by stating that an Internet exchange point requires a minimum of three other participants, which is consistent with the proposed definition.", "However, section 6.10.1 Micro-allocations for Critical Infrastructure currently states that Internet exchange point operators require a minimum of only two other participants, which creates a discrepancy. Staff recommends addressing and resolving this discrepancy.", "### 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", "[21 June 2024](https://lists.arin.net/pipermail/arin-ppml/2024-June/037395.html)", "## History and Earlier Versions", "|Action|Date|", "|--- |--- |", "| [Proposal](/participate/policy/proposals/2024/ARIN_prop_332/) | 22 April 2024 |", "| [Draft Policy](https://lists.arin.net/pipermail/arin-ppml/2024-May/037317.html) | 21 May 2024 |", "| [Revision](https://lists.arin.net/pipermail/arin-ppml/2024-June/037395.html) | 21 June 2024 |", "| [Abandoned](https://lists.arin.net/pipermail/arin-ppml/2024-October/037617.html) | 30 October 2024 |", "## Related Meetings", "### Advisory Council", "- [16 May 2024](/about/welcome/ac/meetings/2024_0516/)", "- [20 June 2024](/about/welcome/ac/meetings/2024_0620/)", "- [18 July 2024](/about/welcome/ac/meetings/2024_0718/)", "- [15 August 2024](/about/welcome/ac/meetings/2024_0815/)", "- [19 September 2024](/about/welcome/ac/meetings/2024_0919/)", "- [25 October 2024](/about/welcome/ac/meetings/2024_1025/)", " ", "### Board of Trustees", "### ARIN Public Policy Meetings", "- [ARIN 54](/participate/meetings/ARIN54/)"], "lastUpdated": "2024-06-21", "url": "https://www.arin.net/participate/policy/drafts/2024_4/" },{ "number": "ARIN-2024-2", "title": "Whois Data Requirements Policy for Non-Personal Information", "status": "Implemented", "recommended": true, "shepherds": ["Leif Sawyer", "Daniel Schatte"], "problemStatement": "\nARIN’s mission includes maintaining and distributing registration information about who holds Internet number resources (Internet Protocol (IP) addresses and Autonomous System Numbers (ASNs)) in a public database referred to as Whois. Whois provides network operators, technical troubleshooters, law enforcement, researchers, and other interested parties with information about which organization administers specific Internet number resources. Distributing this non-personal information is very much in the public interest of proper functioning of the Internet.\nWhile ARIN continues to recognize the ongoing relevancy and importance for publicly available Whois information in its control, ARIN must also take stock of evolving regional developments pertaining to data privacy and the cross-border sharing of personally identifying information (PII) which have led to or could lead to redactions among similar Whois resources outside of ARIN’s purview.\nIn light of such developments, it is important for ARIN to codify its Whois data requirements and disclosure practices in a manner that is both a) respectful of privacy rights pertaining to PII and b) cognizant of the value non-PII data plays in the security of the Internet and the protection of the general public.\nCurrently there are no ARIN policies that clearly define what organization and associated point of contact information must be provided and registered in the public Whois. This proposal attempts only to clarify and codify ARIN’s existing practice regarding organization and contact data collection and display in Whois.\n","policyStatement": "\n2.12 Organizational Information\nModify 2.12 to read:\nInformation needed to uniquely identify an Organization.\n3.8 Directory Service Records\nModify 3.8.1 to include the following sentence:\nAll organization registration records will be visible in the public Whois. Organizations that are registered as D/B/A may choose to show the Business name rather than the registered party’s name.\nAdd 3.8.2\n3.8.2 Required Organization Record Information\nThe following information must be provided to ARIN to register an organization record:\n- Org Name\n- Org Postal Address including country\nAdd 3.8.3 Point of Contact Record Creation\nAn organization must register designated Points of Contact to manage its organization and resource registration records to include Administrative, Technical, NOC and Abuse contacts. These Points of Contact shall be representatives of the organization and any information provided to ARIN shall be that contact’s associated organizational information and not personal data.\nPoint of Contact registration records will generally be visible in the public Whois. Refer to NRPM 3.3 and NRPM 4.2.3.7.3.2 for exceptions to this general rule.\nAdd 3.8.4 Required Point of Contact Record Information.\nThe following information must be provided to ARIN to register a Point of Contact:\n- Contact Name (this can be an individual representative of the company or a Role POC)\n- Contact’s Company Name (Required for Role POC)\n- Contact’s Postal Address including country\n- Contact’s Organization Phone Number (optional)\n- Contact’s Organization E-Mail Address\n","implementationTime": "Immediate. ","fullText": ["## Current Text (26 August 2024)", "### AC Assessment of Conformance with the [Principles of Internet Number Resource Policy](/participate/policy/pdp/#4-principles-of-internet-number-resource-policy)", "Following a review of community feedback, staff and legal recommendations, and AC discussions, Draft Policy ARIN-2024-2: Whois Data Requirements Policy for Non-Personal Information, was found to conform to the principles of the ARIN Policy Development Process. Based on being fair, impartial, and technically sound, this Draft Policy was moved to Recommended Draft state. If adopted by the board, it would further clarify what information is collected and published via ARIN's public Whois service.", "### Problem Statement", "ARIN’s mission includes maintaining and distributing registration information about who holds Internet number resources (Internet Protocol (IP) addresses and Autonomous System Numbers (ASNs)) in a public database referred to as Whois. Whois provides network operators, technical troubleshooters, law enforcement, researchers, and other interested parties with information about which organization administers specific Internet number resources. Distributing this non-personal information is very much in the public interest of proper functioning of the Internet.", "While ARIN continues to recognize the ongoing relevancy and importance for publicly available Whois information in its control, ARIN must also take stock of evolving regional developments pertaining to data privacy and the cross-border sharing of personally identifying information (PII) which have led to or could lead to redactions among similar Whois resources outside of ARIN’s purview.", "In light of such developments, it is important for ARIN to codify its Whois data requirements and disclosure practices in a manner that is both a) respectful of privacy rights pertaining to PII and b) cognizant of the value non-PII data plays in the security of the Internet and the protection of the general public.", "Currently there are no ARIN policies that clearly define what organization and associated point of contact information must be provided and registered in the public Whois. This proposal attempts only to clarify and codify ARIN’s existing practice regarding organization and contact data collection and display in Whois.", "### Policy Statement", "2.12 Organizational Information", "Modify 2.12 to read:", "Information needed to uniquely identify an Organization.", "3.8 Directory Service Records", "Modify 3.8.1 to include the following sentence:", "All organization registration records will be visible in the public Whois. Organizations that are registered as D/B/A may choose to show the Business name rather than the registered party’s name.", "Add 3.8.2", "3.8.2 Required Organization Record Information", "The following information must be provided to ARIN to register an organization record:", "- Org Name", "- Org Postal Address including country", "Add 3.8.3 Point of Contact Record Creation", "An organization must register designated Points of Contact to manage its organization and resource registration records to include Administrative, Technical, NOC and Abuse contacts. These Points of Contact shall be representatives of the organization and any information provided to ARIN shall be that contact’s associated organizational information and not personal data.", "Point of Contact registration records will generally be visible in the public Whois. Refer to NRPM 3.3 and NRPM 4.2.3.7.3.2 for exceptions to this general rule.", "Add 3.8.4 Required Point of Contact Record Information.", "The following information must be provided to ARIN to register a Point of Contact:", "- Contact Name (this can be an individual representative of the company or a Role POC)", "- Contact’s Company Name (Required for Role POC)", "- Contact’s Postal Address including country", "- Contact’s Organization Phone Number (optional)", "- Contact’s Organization E-Mail Address", "### Timetable for Implementation", "Immediate. ", "## Staff and Legal Review (29 July 2024)", "### Staff Understanding", "The last sentence of the problem statement states that this proposal intends to clarify and codify ARIN’s existing practices. However, the policy text as written would result in modification to some of ARIN’s existing business practices. Staff recommends the following changes to be made to ensure that this policy is consistent with the problem statement and current ARIN business practices.", "Section 2.12 Organizational Information ", "We recommend removing the last sentence, "Differing uses within ARIN online, L/RSA, and the NRPM could have different requirements", as this does not add to policy clarity.", "Section 3.8.1 Organization Record Creation ", "Current ARIN business practice is to allow a D/B/A name to be published rather than the organization’s legal name. Recommend that this Draft Policy be modified to allow for this business practice to continue.", "Section 3.8.2 Required Organization Record Information ", "Under the Org Address bullet point, we recommend changing "Org Address" to "Org Postal Address" and removing the lines with the address information detail. A third bullet point could be added to specify identification of the Org Country.", "Section 3.8.3 Point of Contact Record Creation ", "This section states, "An organization may register designated Points of Contact…" The term "may" would imply that the registration of a Point of Contact is optional, which would be a change to current practice. ARIN recommends changing "may" in the policy text to "must".", "Current text in this Draft Policy seems to allow an Organization Record to be created without Points of Contact listed. ARIN currently requires that at least one contact of each of the following types - Admin, Tech, and Abuse Point of Contact - be designated on an Organization Record. There are three optional POC types (NOC, Routing, and DNS) that may be created if desired.", "Section 3.8.4 Required Point of Contact Record Information ", "We recommend removing "organization or resource" from the first line and changing "an" to "a".", "Contact Name: Current business practice refers to these as Role POCs. We recommend changing "role account" to "Role Point of Contact".", "Company Name is not listed as required information to register a Point of Contact record. ARIN currently requires Company Name for Role POCs. Staff recommends adding the following to the list:", "- Contact’s Company Name (required for Role POC)", "Under the Contact’s Address bullet point, recommend changing "Contact’s Address" to "Contact Postal Address" and removing the lines with the address information detail. A fifth bullet point could be added to specify identification of the Contact Country.", "In addition, in alignment with ARIN’s current business processes, Contact’s Organization Phone Number should be identified as optional as not all organizations have a business phone number.", "### Implementable as Written?", "Yes", "### Impact on ARIN Registry Operations and Services", "None", "### Legal Review", "While there are no material legal issues with the substance of the proposed policy, we note that the problem statement indicates an effort to help clarify ARIN’s handling of personally identifiable information (PII). ARIN maintains its Privacy Policy that states how ARIN handles and manages PII, and that Privacy Policy can be viewed on ARIN’s website at https://www.arin.net/about/privacy/.", "### 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 June 2024](https://lists.arin.net/pipermail/arin-ppml/2024-June/037407.html)", "## History and Earlier Versions", "|Action|Date|", "|--- |--- |", "| [Proposal](/participate/policy/proposals/2024/ARIN_prop_329/) | 9 February 2024 |", "| [Draft Policy](https://lists.arin.net/pipermail/arin-ppml/2024-March/037269.html) | 26 March 2024 |", "| [Revised](https://lists.arin.net/pipermail/arin-ppml/2024-June/037407.html) | 25 June 2024 |", "| [Revised](https://lists.arin.net/pipermail/arin-ppml/2024-August/037577.html) | 26 August 2024 |", "| [Recommended Draft Policy](https://lists.arin.net/pipermail/arin-ppml/2024-September/037582.html) | 24 September 2024 |", "| [Last Call](https://lists.arin.net/pipermail/arin-ppml/2024-October/037620.html) | 30 October 2024 |", "| [Advanced to Board of Trustees](https://lists.arin.net/pipermail/arin-ppml/2024-November/037637.html) | 26 November 2024 |", "| [Adopted](/about/welcome/board/meetings/2024_1209/) | 9 December 2024 | ", "| Implemented | 4 March 2025 |", "## 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/)", "- [20 June 2024](/about/welcome/ac/meetings/2024_0620/)", "- [18 July 2024](/about/welcome/ac/meetings/2024_0718/)", "- [15 August 2024](/about/welcome/ac/meetings/2024_0815/)", "- [19 September 2024](/about/welcome/ac/meetings/2024_0919/)", "- [25 October 2024](/about/welcome/ac/meetings/2024_1025/)", "- [21 November 2024](/about/welcome/ac/meetings/2024_1121/)", "### Board of Trustees", "- [9 December 2024](/about/welcome/board/meetings/2024_1209/)", "### ARIN Public Policy Meetings", "- [ARIN 53](/participate/meetings/ARIN53/)", "- [ARIN 54](/participate/meetings/ARIN54/)"], "lastUpdated": "2024-03-26", "url": "https://www.arin.net/participate/policy/drafts/2024_2/" },{ "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-2024-1", "title": "Definition of Organization ID/Org ID", "status": "Abandoned", "recommended": false, "shepherds": ["Gus Reese", "Gerry George"], "problemStatement": "\nDuring work on a related policy proposal, the NRPM Working Group determined that a definition of Organization Identifier (Org ID) should be included in the NRPM to add clarity to the term and unify NRPM references to match the use of the term in other ARIN publications such as ARIN online.\n","policyStatement": "\nCurrent: None\nProposed:\nSection 2.18. Organization Identifier (Org ID)\nAn Organization Identifier (Org ID) is a unique text label that represents a business, nonprofit corporation, or government entity in the ARIN database.\n","implementationTime": "Immediate. ","fullText": ["## Current Text (7 January 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-2024-1 conforms to the principles of the ARIN Policy Development Process. This policy, if adopted, will add clarity to the NPRM by providing a clear definition of an Organization Identifier as section 2.18. It is fair, impartial, technically sound and has received support from the community.", "### Problem Statement", "During work on a related policy proposal, the NRPM Working Group determined that a definition of Organization Identifier (Org ID) should be included in the NRPM to add clarity to the term and unify NRPM references to match the use of the term in other ARIN publications such as ARIN online.", "### Policy Statement", "Current: None", "Proposed:", "Section 2.18. Organization Identifier (Org ID)", "An Organization Identifier (Org ID) is a unique text label that represents a business, nonprofit corporation, or government entity in the ARIN database.", "### Comments", "This definition had previously been included in an earlier policy proposal (ARIN-2023-7), but community feedback recommendations on that proposal showed a preference for adding the definition separately from that proposal. As such the definition is now being proposed as a standalone proposal, and the language will be removed from the current ARIN-2023-7 proposal, allowing the two sections of that proposal to be evaluated separately.", "### Timetable for Implementation", "Immediate. ", "## Staff and Legal Review (1 May 2024)", "### Staff Understanding", "This Draft Policy intends to add a clear definition of Organization Identifier (Org ID) to the Number Resource Policy Manual (NRPM). 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", "- Updates to public documentation", "### Proposal/Draft Policy Text Assessed", "[7 February 2024](https://lists.arin.net/pipermail/arin-ppml/2024-February/037209.html)", "## History and Earlier Versions", "|Action|Date|", "|--- |--- |", "| [Proposal](/participate/policy/proposals/2023/ARIN_prop_328/) | 18 December 2023 |", "| [Draft Policy](https://lists.arin.net/pipermail/arin-ppml/2024-January/037186.html) | 31 January 2024 |", "| [Revised](https://lists.arin.net/pipermail/arin-ppml/2024-February/037209.html) | 7 February 2024 |", "| [Recommended Draft Policy](https://lists.arin.net/pipermail/arin-ppml/2024-May/037321.html) | 21 May 2024 |", "| [Draft Policy](https://lists.arin.net/pipermail/arin-ppml/2024-October/037622.html) | 30 October 2024 |", "| [Revised](https://lists.arin.net/pipermail/arin-ppml/2025-January/037666.html) | 7 January 2025 | ", "| [Abandoned](https://lists.arin.net/pipermail/arin-ppml/2025-January/037673.html) | 29 January 2025 |", "## Related Meetings", "### Advisory Council", "- [26 January 2024](/about/welcome/ac/meetings/2024_0126)", "- [15 February 2024](/about/welcome/ac/meetings/2024_0215/)", "- [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/)", "- [20 June 2024](/about/welcome/ac/meetings/2024_0620/)", "- [18 July 2024](/about/welcome/ac/meetings/2024_0718/)", "- [15 August 2024](/about/welcome/ac/meetings/2024_0815/)", "- [19 September 2024](/about/welcome/ac/meetings/2024_0919/)", "- [25 October 2024](/about/welcome/ac/meetings/2024_1025/)", "- [21 November 2024](/about/welcome/ac/meetings/2024_1121/)", "- [19 December 2024](/about/welcome/ac/meetings/2024_1219/)", "- [24 January 2025](/about/welcome/ac/meetings/2025_0124/)", "### Board of Trustees", "### ARIN Public Policy Meetings", "- [ARIN 53](/participate/meetings/ARIN53/)", "- [ARIN 54](/participate/meetings/ARIN54/)"], "lastUpdated": "2024-05-21", "url": "https://www.arin.net/participate/policy/drafts/2024_1/" },{ "number": "ARIN-2023-8", "title": "Reduce 4.1.8 Maximum Allocation", "status": "Abandoned", "recommended": false, "shepherds": ["Gerry George", "Brian Jones"], "problemStatement": "\n4.1.8 waiting times are too long, making justifications untimely by the time a request is met. New entrants to the waiting list are expected to wait three years for their need to be met under current policy, with a waiting list of around 700 at this point. Data indicates that reducing the current /22 maximum further to a /24 would significantly reduce this waiting period, and further tightening the requirements by replacing the /20 recipient maximum holdings with a /24, and preventing multiple visits to the waiting list queue.\n","policyStatement": "\n4.1.8. ARIN Waitlist\nARIN will only issue future IPv4 assignments/allocations (excluding 4.4 and 4.10 space) from the ARIN Waitlist. The maximum size aggregate that an organization may qualify for is a /24.\nOrganizations that have ever held any IPv4 space other than special use space received under section 4.4 or 4.10 are not eligible to apply.\nAddress space distributed from the waitlist will not be eligible for transfer, with the exception of Section 8.2 transfers, for a period of 60 months. This restriction will be applied to all distributions from the waitlist to also include those organizations or requesters currently listed. Qualified requesters will also be advised of the availability of the transfer mechanism in section 8.3 as an alternative mechanism to obtain IPv4 addresses.\nWaiting list recipients must demonstrate the need for a /24 on an operating network.\nThe limitation to a single /24 will be enforced for waitlist requests submitted after this policy takes effect, and will only apply to new entrants to the waitlist. Requests received before the policy change will be evaluated based on the policy in place at the time of the request.\nNote: Sections 4.1.8.1 Sequencing, 4.1.8.2 Fulfillment and 4.1.8.3 Qualification remain unchanged.\nIn section 4.2.2 replace the sentence:\nFROM:\n"All ISP organizations without any IPv4 addresses from ARIN automatically qualify for an initial allocation of a /24. ISPs providing a 24-month utilization plan for the request size specified may receive up to a /22. ISPs 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."\nTO:\n"All ISP organizations without any IPv4 addresses from ARIN automatically qualify for an initial allocation of a /24. "\nIn section 8.3 Conditions on the source of the transfer, remove this sentence:\n"The source entity will not be allowed to apply for IPv4 address space under Section 4.1.8 ARIN Waitlist for a period of 36 months following the transfer of IPv4 address resources to another party."\n","implementationTime": "Immediate. ","fullText": ["## Current Text (27 June 2025)", "### Problem Statement", "4.1.8 waiting times are too long, making justifications untimely by the time a request is met. New entrants to the waiting list are expected to wait three years for their need to be met under current policy, with a waiting list of around 700 at this point. Data indicates that reducing the current /22 maximum further to a /24 would significantly reduce this waiting period, and further tightening the requirements by replacing the /20 recipient maximum holdings with a /24, and preventing multiple visits to the waiting list queue.", "### Policy Statement", "4.1.8. ARIN Waitlist", "ARIN will only issue future IPv4 assignments/allocations (excluding 4.4 and 4.10 space) from the ARIN Waitlist. The maximum size aggregate that an organization may qualify for is a /24.", "Organizations that have ever held any IPv4 space other than special use space received under section 4.4 or 4.10 are not eligible to apply.", "Address space distributed from the waitlist will not be eligible for transfer, with the exception of Section 8.2 transfers, for a period of 60 months. This restriction will be applied to all distributions from the waitlist to also include those organizations or requesters currently listed. Qualified requesters will also be advised of the availability of the transfer mechanism in section 8.3 as an alternative mechanism to obtain IPv4 addresses.", "Waiting list recipients must demonstrate the need for a /24 on an operating network.", "The limitation to a single /24 will be enforced for waitlist requests submitted after this policy takes effect, and will only apply to new entrants to the waitlist. Requests received before the policy change will be evaluated based on the policy in place at the time of the request.", "Note: Sections 4.1.8.1 Sequencing, 4.1.8.2 Fulfillment and 4.1.8.3 Qualification remain unchanged.", "In section 4.2.2 replace the sentence:", "FROM:", ""All ISP organizations without any IPv4 addresses from ARIN automatically qualify for an initial allocation of a /24. ISPs providing a 24-month utilization plan for the request size specified may receive up to a /22. ISPs 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."", "TO:", ""All ISP organizations without any IPv4 addresses from ARIN automatically qualify for an initial allocation of a /24. "", "In section 8.3 Conditions on the source of the transfer, remove this sentence:", ""The source entity will not be allowed to apply for IPv4 address space under Section 4.1.8 ARIN Waitlist for a period of 36 months following the transfer of IPv4 address resources to another party."", "### Timetable for Implementation", "Immediate. ", "## History and Earlier Versions", "|Action|Date|", "|--- |--- |", "| [Proposal](/participate/policy/proposals/2023/ARIN_prop_327/) | 26 October 2023 |", "| [Draft Policy](https://lists.arin.net/pipermail/arin-ppml/2023-November/037101.html) | 21 November 2023 |", "| [Revised](https://lists.arin.net/pipermail/arin-ppml/2024-February/037216.html) | 14 February 2024 |", "| [Revised](https://lists.arin.net/pipermail/arin-ppml/2024-September/037585.html) | 30 September 2024 | ", "| [Revised](https://lists.arin.net/pipermail/arin-ppml/2025-June/037939.html) | 27 June 2025 |", "| [Abandoned](https://lists.arin.net/pipermail/arin-ppml/2025-August/038061.html) | 26 August 2025 |", "## Related Meetings", "### Advisory Council", "- [16 November 2023](/about/welcome/ac/meetings/2023_1116/)", "- [21 December 2023](/about/welcome/ac/meetings/2023_1221)", "- [26 January 2024](/about/welcome/ac/meetings/2024_0126)", "- [15 February 2024](/about/welcome/ac/meetings/2024_0215/)", "- [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/)", "- [20 June 2024](/about/welcome/ac/meetings/2024_0620/)", "- [18 July 2024](/about/welcome/ac/meetings/2024_0718/)", "- [15 August 2024](/about/welcome/ac/meetings/2024_0815/)", "- [19 September 2024](/about/welcome/ac/meetings/2024_0919/)", "- [25 October 2024](/about/welcome/ac/meetings/2024_1025/)", "- [21 November 2024](/about/welcome/ac/meetings/2024_1121/)", "- [19 December 2024](/about/welcome/ac/meetings/2024_1219/)", "- [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/)", " ", "### Board of Trustees", "### ARIN Public Policy Meetings", "- [ARIN 53](/participate/meetings/ARIN53/)", "- [ARIN 54](/participate/meetings/ARIN54/)", "- [ARIN 55](/participate/meetings/ARIN55/)"], "lastUpdated": "2023-11-21", "url": "https://www.arin.net/participate/policy/drafts/2023_8/" },{ "number": "ARIN-2023-7", "title": "Clarification of NRPM Sections 4.5 and 6.11 Multiple Discrete Networks", "status": "Implemented", "recommended": true, "shepherds": ["Chris Woodfield", "Elizabeth Goodson"], "problemStatement": "\nSection 4.5 and 6.11 of the NRPM does not adhere to the style guide used by the remainder of the document. The numbered lists in these two sections also detracts from the readability and usability of the NRPM.\n","policyStatement": "\nCurrent:\n4.5 Multiple Discrete Networks\nOrganizations with multiple discrete networks desiring to request new or additional address space under a single Organization ID must meet the following criteria:\n1. The organization shall be a single entity and not a consortium of smaller independent entities.\n2. The organization must have compelling criteria for creating discrete networks. Examples of a discrete network might include:\n3. Regulatory restrictions for data transmission,\n4. Geographic distance and diversity between networks,\n5. Autonomous multihomed discrete networks.\n6. The organization must keep detailed records on how it has allocated space to each location, including the date of each allocation.\n7. When applying for additional internet address registrations from ARIN, the organization must demonstrate utilization greater than 50% of both the last block allocated and the aggregate sum of all blocks allocated from ARIN to that organization. If an organization is unable to satisfy this 50% minimum utilization criteria, the organization may alternatively qualify for additional internet address registrations by having all unallocated blocks of addresses smaller than ARIN's current minimum allocation size.\n8. The organization may not allocate additional address space to a location until each of that location's address blocks are 80% utilized.\n9. The organization should notify ARIN at the time of the request their desire to apply this policy to their account.\n10. Upon verification that the organization has shown evidence of deployment of the new discrete network site, the new network(s) shall be allocated the minimum allocation size under section 4.2.1.5.\nProposed:\nReplace Section 4.5 in its entirety with the following text: \n4.5 Multiple Discrete Networks\nOrganizations with multiple discrete networks desiring to request a new or additional IP address space allocation under a single Organization ID must meet the following criteria:\n1. The organization must be a single entity and not a consortium of smaller independent entities.\n2. The organization must have compelling criteria for creating discrete networks. Examples of situations which may represent compelling criteria for multiple discrete networks might include:\n - Regulatory restrictions for data transmission;\n - Geographic distance and diversity between networks; or\n - Autonomous multihomed discrete networks.\n3. The organization must keep detailed records on how it has allocated IP addresses to each location, including the date of each allocation. \n4. When applying for additional IP address allocations from ARIN, the organization must demonstrate utilization greater than 50% of both the last IP addresses allocated and the aggregate sum of all IP addresses allocated from ARIN to that organization. If an organization is unable to satisfy this 50% minimum utilization criteria, the organization may alternatively qualify for additional IP address allocations by having all unallocated IP address blocks smaller than ARIN’s current minimum allocation size.\n5. The organization must not allocate additional IP address space to a location until each of that location’s IP address allocations are 80% utilized.\nThe organization must notify ARIN at the time of the request of their desire to apply this policy to their account.\nCurrent:\n6.11. IPv6 Multiple Discrete Networks\nOrganizations with multiple discrete IPv6 networks desiring to request new or additional address space under a single Organization ID must meet the following criteria:\n1. The organization shall be a single entity and not a consortium of smaller independent entities.\n2. The organization must have compelling criteria for creating discrete networks. Examples of a discrete network might include:\n- Regulatory restrictions for data transmission,\n- Geographic distance and diversity between networks,\n- Autonomous multihomed discrete networks.\n3. The organization must keep detailed records on how it has allocated space to each location, including the date of each allocation.\n4. The organization should notify ARIN at the time of the request their desire to apply this policy to their account.\n5. Requests for additional space:\n6. Organization must specify on the application which discrete network(s) the request applies to\n7. Each network will be judged against the existing utilization criteria specified in 6.5.2 and 6.5.3 as if it were a separate organization, rather than collectively as would be done for requests outside of this policy.\nProposed:\nReplace Section 6.11 in its entirety with the following text:\n6.11. IPv6 Multiple Discrete Networks\nOrganizations with multiple discrete IPv6 networks desiring to request new or additional IPv6 address allocations under a single Organization ID must meet the following criteria:\n1. The organization must be a single entity and not a consortium of smaller independent entities.\n2. The organization must have compelling criteria for creating discrete networks. Examples of situations which may represent compelling criteria for multiple discrete networks might include:\n - Regulatory restrictions for data transmission;\n - Geographic distance and diversity between networks; or\n - Autonomous multihomed discrete networks.\n3. The organization must keep detailed records on how it has allocated IPv6 addresses to each location, including the date of each IPv6 address allocation. \n4. When an organization is requesting additional IPv6 address allocations under this policy, the organization must specify on the application which discrete network(s) the IPv6 address request applies to. A request for additional space will be judged against the existing utilization criteria specified in 6.5.2 and 6.5.3 as if it were a separate organization, rather than collectively as would be done for requests outside of this policy.\nThe organization must notify ARIN at the time of the request their desire to apply this policy to their account.\n","implementationTime": "Immediate","fullText": ["## Current Text (20 August 2024)", "### AC Assessment of Conformance with the [Principles of Internet Number Resource Policy](/participate/policy/pdp/#4-principles-of-internet-number-resource-policy)", "Based on community feedback and AC discussion, we have promoted ARIN-2023-7: Clarification of NRPM Sections 4.5 and 6.11 Multiple Discrete Networks to Recommended Draft Policy. This Draft Policy is fair, impartial, and technically sound; it will add clarity and readability to the NRPM sections being updated by this proposal.", "### Problem Statement", "Section 4.5 and 6.11 of the NRPM does not adhere to the style guide used by the remainder of the document. The numbered lists in these two sections also detracts from the readability and usability of the NRPM.", "### Policy Statement", "Current:", "4.5 Multiple Discrete Networks", "Organizations with multiple discrete networks desiring to request new or additional address space under a single Organization ID must meet the following criteria:", "1. The organization shall be a single entity and not a consortium of smaller independent entities.", "2. The organization must have compelling criteria for creating discrete networks. Examples of a discrete network might include:", "3. Regulatory restrictions for data transmission,", "4. Geographic distance and diversity between networks,", "5. Autonomous multihomed discrete networks.", "6. The organization must keep detailed records on how it has allocated space to each location, including the date of each allocation.", "7. When applying for additional internet address registrations from ARIN, the organization must demonstrate utilization greater than 50% of both the last block allocated and the aggregate sum of all blocks allocated from ARIN to that organization. If an organization is unable to satisfy this 50% minimum utilization criteria, the organization may alternatively qualify for additional internet address registrations by having all unallocated blocks of addresses smaller than ARIN's current minimum allocation size.", "8. The organization may not allocate additional address space to a location until each of that location's address blocks are 80% utilized.", "9. The organization should notify ARIN at the time of the request their desire to apply this policy to their account.", "10. Upon verification that the organization has shown evidence of deployment of the new discrete network site, the new network(s) shall be allocated the minimum allocation size under section 4.2.1.5.", "Proposed:", "Replace Section 4.5 in its entirety with the following text: ", "4.5 Multiple Discrete Networks", "Organizations with multiple discrete networks desiring to request a new or additional IP address space allocation under a single Organization ID must meet the following criteria:", "1. The organization must be a single entity and not a consortium of smaller independent entities.", "2. The organization must have compelling criteria for creating discrete networks. Examples of situations which may represent compelling criteria for multiple discrete networks might include:", " - Regulatory restrictions for data transmission;", " - Geographic distance and diversity between networks; or", " - Autonomous multihomed discrete networks.", "3. The organization must keep detailed records on how it has allocated IP addresses to each location, including the date of each allocation. ", "4. When applying for additional IP address allocations from ARIN, the organization must demonstrate utilization greater than 50% of both the last IP addresses allocated and the aggregate sum of all IP addresses allocated from ARIN to that organization. If an organization is unable to satisfy this 50% minimum utilization criteria, the organization may alternatively qualify for additional IP address allocations by having all unallocated IP address blocks smaller than ARIN’s current minimum allocation size.", "5. The organization must not allocate additional IP address space to a location until each of that location’s IP address allocations are 80% utilized.", "The organization must notify ARIN at the time of the request of their desire to apply this policy to their account.", "Current:", "6.11. IPv6 Multiple Discrete Networks", "Organizations with multiple discrete IPv6 networks desiring to request new or additional address space under a single Organization ID must meet the following criteria:", "1. The organization shall be a single entity and not a consortium of smaller independent entities.", "2. The organization must have compelling criteria for creating discrete networks. Examples of a discrete network might include:", "- Regulatory restrictions for data transmission,", "- Geographic distance and diversity between networks,", "- Autonomous multihomed discrete networks.", "3. The organization must keep detailed records on how it has allocated space to each location, including the date of each allocation.", "4. The organization should notify ARIN at the time of the request their desire to apply this policy to their account.", "5. Requests for additional space:", "6. Organization must specify on the application which discrete network(s) the request applies to", "7. Each network will be judged against the existing utilization criteria specified in 6.5.2 and 6.5.3 as if it were a separate organization, rather than collectively as would be done for requests outside of this policy.", "Proposed:", "Replace Section 6.11 in its entirety with the following text:", "6.11. IPv6 Multiple Discrete Networks", "Organizations with multiple discrete IPv6 networks desiring to request new or additional IPv6 address allocations under a single Organization ID must meet the following criteria:", "1. The organization must be a single entity and not a consortium of smaller independent entities.", "2. The organization must have compelling criteria for creating discrete networks. Examples of situations which may represent compelling criteria for multiple discrete networks might include:", " - Regulatory restrictions for data transmission;", " - Geographic distance and diversity between networks; or", " - Autonomous multihomed discrete networks.", "3. The organization must keep detailed records on how it has allocated IPv6 addresses to each location, including the date of each IPv6 address allocation. ", "4. When an organization is requesting additional IPv6 address allocations under this policy, the organization must specify on the application which discrete network(s) the IPv6 address request applies to. A request for additional space will be judged against the existing utilization criteria specified in 6.5.2 and 6.5.3 as if it were a separate organization, rather than collectively as would be done for requests outside of this policy.", "The organization must notify ARIN at the time of the request their desire to apply this policy to their account.", "### Comments", "The working group considered entering 3 separate proposals but decided that the parts are all related enough to combine into one proposal. Section 2.18 is the proposed section number for Organizational Identifier (org ID) definition due to recently adopted ARIN-2022-11 taking section 2.17.", "### Timetable for Implementation", "Immediate", "## Staff and Legal Review (30 July 2024)", "### Staff Understanding ", "This policy corrects and reorganizes the numbered bullets in section 4.5 and 6.11 for clarity. Additional edits were made to include "Allocation", reflecting ARIN’s deprecation of "Assignment".", "ARIN staff suggests the following editorial changes for consistency:", "Section 4.5 item 4 change:", "- "Internet Resource allocations" to "IP address allocations"; and", "- "internet IP allocations" to "IP address allocations"", "Section 6.11 item 4 change:", "- "additional space" to "additional IPv6 address allocations"", "Section 4.5 and 6.11, item 2 example bullets: ", "We recommend ending the second bullet in each section with "; or".", "### 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", "[20 June 2024](https://lists.arin.net/pipermail/arin-ppml/2024-June/037383.html)", "## History and Earlier Versions", "|Action|Date|", "|--- |--- |", "| [Proposal](/participate/policy/proposals/2023/ARIN_prop_325/) | 17 August 2023 |", "| [Draft Policy](https://lists.arin.net/pipermail/arin-ppml/2023-September/036958.html) | 26 September 2023 |", "| [Revised](https://lists.arin.net/pipermail/arin-ppml/2023-December/037170.html) | 19 December 2023 |", "| [Recommended Draft Policy](https://lists.arin.net/pipermail/arin-ppml/2024-February/037247.html) | 21 February 2024 | ", "| [Draft Policy](https://lists.arin.net/pipermail/arin-ppml/2024-April/037302.html) | 22 April 2024 |", "| [Revised](https://lists.arin.net/pipermail/arin-ppml/2024-June/037383.html) | 20 June 2024 |", "| [Revised](https://lists.arin.net/pipermail/arin-ppml/2024-August/037567.html) | 20 August 2024 |", "| [Recommended Draft Policy](https://lists.arin.net/pipermail/arin-ppml/2024-September/037581.html) | 24 September 2024 |", "| [Last Call](https://lists.arin.net/pipermail/arin-ppml/2024-October/037619.html) | 30 October 2024 |", "| [Advanced to Board of Trustees](https://lists.arin.net/pipermail/arin-ppml/2024-December/037663.html) | 26 December 2024 |", "| [Adopted](https://lists.arin.net/pipermail/arin-ppml/2025-January/037679.html) | 14 January 2025 |", "| Implemented | 4 March 2025 |", "## Related Meetings", "### Advisory Council", "- [21 September 2023](/about/welcome/ac/meetings/2023_0921/)", "- [20 October 2023](/about/welcome/ac/meetings/2023_1020/)", "- [16 November 2023](/about/welcome/ac/meetings/2023_1116/)", "- [21 December 2023](/about/welcome/ac/meetings/2023_1221)", "- [26 January 2024](/about/welcome/ac/meetings/2024_0126)", "- [15 February 2024](/about/welcome/ac/meetings/2024_0215/)", "- [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/)", "- [20 June 2024](/about/welcome/ac/meetings/2024_0620/)", "- [18 July 2024](/about/welcome/ac/meetings/2024_0718/)", "- [15 August 2024](/about/welcome/ac/meetings/2024_0815/)", "- [19 September 2024](/about/welcome/ac/meetings/2024_0919/)", "- [25 October 2024](/about/welcome/ac/meetings/2024_1025/)", "- [21 November 2024](/about/welcome/ac/meetings/2024_1121/)", "- [19 December 2024](/about/welcome/ac/meetings/2024_1219/)", "### Board of Trustees", "- [14 January 2025](/about/welcome/board/meetings/2025_0114/)", "### ARIN Public Policy Meetings", "- [ARIN 52](/participate/meetings/ARIN52/)", "- [ARIN 53](/participate/meetings/ARIN53/)", "- [ARIN 54](/participate/meetings/ARIN54/)"], "lastUpdated": "2024-07-31", "url": "https://www.arin.net/participate/policy/drafts/2023_7/" },{ "number": "ARIN-2023-6", "title": "ARIN Waitlist Qualification", "status": "Implemented", "recommended": true, "shepherds": ["Alicia Trotman", "Matthew Gamble"], "problemStatement": "\nSince the depletion of ARIN’s IPv4 address free pool, ARIN now issues general purpose IPv4 addresses exclusively from the Waitlist, which is described in section 4.1.8. ARIN Waitlist. Currently the text found in section 4.2 Allocations to ISPs (Requirements for Requesting Initial Address Space), 4.3 End-users - Assignments to End Users, and 4.5 Multiple Discrete Networks, might give some readers the impression that meeting these conditions is sufficient to justify the issuance of IPv4 addresses. Indeed these requirements do serve to complement section 4.1.8. ARIN Waitlist policy, as necessary - but not sufficient - conditions. \nThis proposal aims to make explicit the relationship between waitlist policy and the qualification for waitlist space based on section 4.2 for ISPs, section 4.3 for End-users, and section 4.5 for organizations making use of multiple discrete networks.\n","policyStatement": "\nAdd:\n4.1.8.3. Qualification \nARIN staff will evaluate all Waitlist requests against the requirements of otherwise applicable Section 4 policies.\n","implementationTime": "Immediate","fullText": ["## Current Text (27 February 2024)", "### AC Assessment of Conformance with the [Principles of Internet Number Resource Policy](/participate/policy/pdp/#4-principles-of-internet-number-resource-policy)", "Draft Policy ARIN-2023-6: Draft ARIN Waitlist Qualification Update, conforms to the principles of the ARIN Policy Development Process. This draft policy is found to be fair, impartial and technically sound. Based on community feedback and AC discussion we motion to move ARIN-2023-6 Draft ARIN Waitlist Qualification Update to Recommended Draft. If adopted this policy aims to clarify qualification requirements for the IPv4 waitlist based on Section 4 Policy. This is achieved by adding a sub section in Section 4.1.8. ARIN Waitlist.", "### Problem Statement", "Since the depletion of ARIN’s IPv4 address free pool, ARIN now issues general purpose IPv4 addresses exclusively from the Waitlist, which is described in section 4.1.8. ARIN Waitlist. Currently the text found in section 4.2 Allocations to ISPs (Requirements for Requesting Initial Address Space), 4.3 End-users - Assignments to End Users, and 4.5 Multiple Discrete Networks, might give some readers the impression that meeting these conditions is sufficient to justify the issuance of IPv4 addresses. Indeed these requirements do serve to complement section 4.1.8. ARIN Waitlist policy, as necessary - but not sufficient - conditions. ", "This proposal aims to make explicit the relationship between waitlist policy and the qualification for waitlist space based on section 4.2 for ISPs, section 4.3 for End-users, and section 4.5 for organizations making use of multiple discrete networks.", "### Policy Statement", "Add:", "4.1.8.3. Qualification ", "ARIN staff will evaluate all Waitlist requests against the requirements of otherwise applicable Section 4 policies.", "### Comments", "The working group evaluated the possibility of removing or collapsing 4.2 and 4.3 and their respective subsections. However, there are differences between ISPs and End Users which remain relevant, and ARIN staff references these respective sections when processing Waitlist requests.", "### Timetable for Implementation", "Immediate", "## Staff and Legal Review (14 February 2024)", "### Staff Understanding", "This policy adds a new sub section to 4.1.8 ARIN Waitlist which clarifies qualification requirements for the IPv4 Waitlist based on policy text found within section 4. Staff agrees that there is value to the policy statement but suggests that including examples is not necessary especially since future policy development could modify those examples. A more effective way to clarify the applicability of qualification requirements is to make the simple reference that all Waitlist requests will be reviewed against the requirements of otherwise applicable Section 4 policies.", "### 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", "[16 August 2023](https://www.arin.net/participate/policy/proposals/2023/ARIN_prop_324/)", "## History and Earlier Versions", "|Action|Date|", "|--- |--- |", "| [Proposal](/participate/policy/proposals/2023/ARIN_prop_324/) | 16 August 2023 |", "| [Draft Policy](https://lists.arin.net/pipermail/arin-ppml/2023-September/036957.html) | 26 September 2023 |", "| [Revised](https://lists.arin.net/pipermail/arin-ppml/2024-February/037257.html) | 27 February 2024 |", "| [Recommended Draft Policy](https://lists.arin.net/pipermail/arin-ppml/2024-March/037268.html) | 26 March 2024 | ", "| [Last Call](https://lists.arin.net/pipermail/arin-ppml/2024-April/037301.html) | 22 April 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 September 2023](/about/welcome/ac/meetings/2023_0921/)", "- [20 October 2023](/about/welcome/ac/meetings/2023_1020/)", "- [16 November 2023](/about/welcome/ac/meetings/2023_1116/)", "- [21 December 2023](/about/welcome/ac/meetings/2023_1221)", "- [26 January 2024](/about/welcome/ac/meetings/2024_0126)", "- [15 February 2024](/about/welcome/ac/meetings/2024_0215/)", "- [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 52](/participate/meetings/ARIN52/)", "- [ARIN 53](/participate/meetings/ARIN53/)"], "lastUpdated": "2024-04-22", "url": "https://www.arin.net/participate/policy/drafts/2023_6/" },{ "number": "ARIN-2023-5", "title": "Clean-up of NRPM Sections 4.3.4, 4.4, 4.10 and 6.10.1", "status": "Implemented", "recommended": true, "shepherds": ["Alison Wood", "Kendrick Knowles"], "problemStatement": "\nThis proposal continues the work that the ARIN AC NRPM Clean-up Working Group undertook to simplify the NRPM. It relates specifically to sections 4.3.4, 4.4, 4.10 and 6.10.1. The focus of this proposal is to remove unnecessary wording from these sections. In the case of section 4.3.4, the text of the entire section is redundant, because it is clear throughout the NRPM that resources can be obtained under various policies and so it is not necessary for that to be stated specifically. In the case of sections 4.4 and 6.10.1, the references to fee payment should be removed since the PDP does not address fees. In the case of section 4.10, unnecessarily complex language can be simplified.\n","policyStatement": "\nDelete section 4.3.4 in its entirety and replace it with the heading "4.3.4 [Retired]".\nFor section 4.4, delete the sentence: "Organizations receiving these micro-allocations will be charged under the fee schedule."\nFor section 4.10, replace the text "4.10. Dedicated IPv4 Block to Facilitate IPv6 Deployment" with the text "4.10. Dedicated IPv4 Allocation to Facilitate IPv6 Deployment"\nFor section 4.10, replace the text "This IPv4 block will be set aside and dedicated to facilitate IPv6 deployment" with the text "This IPv4 allocation will be set aside and dedicated to facilitate IPv6 deployment"\nFor section 4.10, replace the text "This block will be subject to a minimum and maximum size allocation of /24." with the text "A /24 will be allocated."\nFor section 6.10.1, delete the sentence: "Organizations receiving these micro-allocations will be charged under the fee schedule."\n","implementationTime": "Immediate","fullText": ["## Current Text (22 April 2024)", "### AC Assessment of Conformance with the [Principles of Internet Number Resource Policy](/participate/policy/pdp/#4-principles-of-internet-number-resource-policy)", "With AC and community discussion and support we motion to move ARIN-2023-5: Clean-up of NRPM Sections 4.3.4, 4.4, 4.10 and 6.10.1 to Recommended Draft. This policy, if adopted, will provide the following:", "Delete section 4.3.4 in its entirety and replace it with the heading "4.3.4 [Retired]". ", "For section 4.4, delete the sentence: "Organizations receiving these micro-allocations will be charged under the fee schedule."", "For section 4.10, replace the text "This block will be subject to a minimum and maximum size allocation of /24."with the text "A /24 will be allocated."", "For section 6.10.1, delete the sentence: "Organizations receiving these micro-allocations will be charged under the fee schedule."", "### Problem Statement", "This proposal continues the work that the ARIN AC NRPM Clean-up Working Group undertook to simplify the NRPM. It relates specifically to sections 4.3.4, 4.4, 4.10 and 6.10.1. The focus of this proposal is to remove unnecessary wording from these sections. In the case of section 4.3.4, the text of the entire section is redundant, because it is clear throughout the NRPM that resources can be obtained under various policies and so it is not necessary for that to be stated specifically. In the case of sections 4.4 and 6.10.1, the references to fee payment should be removed since the PDP does not address fees. In the case of section 4.10, unnecessarily complex language can be simplified.", "### Policy Statement", "Delete section 4.3.4 in its entirety and replace it with the heading "4.3.4 [Retired]".", "For section 4.4, delete the sentence: "Organizations receiving these micro-allocations will be charged under the fee schedule."", "For section 4.10, replace the text "4.10. Dedicated IPv4 Block to Facilitate IPv6 Deployment" with the text "4.10. Dedicated IPv4 Allocation to Facilitate IPv6 Deployment"", "For section 4.10, replace the text "This IPv4 block will be set aside and dedicated to facilitate IPv6 deployment" with the text "This IPv4 allocation will be set aside and dedicated to facilitate IPv6 deployment"", "For section 4.10, replace the text "This block will be subject to a minimum and maximum size allocation of /24." with the text "A /24 will be allocated."", "For section 6.10.1, delete the sentence: "Organizations receiving these micro-allocations will be charged under the fee schedule."", "### Comments", "The proposed changes relating to sections 4.3.4, 4.4, 4.10 and 6.10.1 were combined even though they address different topics because they are all viewed as very simple changes, and ARIN Community members have expressed a desire not to have too many policy proposals moving through the PDP at the same time to the extent that they can be reasonably aggregated without introducing undue complexity.", "### Timetable for Implementation", "Immediate", "## Staff and Legal Review (9 October 2023)", "### Staff Understanding", "Draft Policy ARIN-2023-5 makes minor editorial changes to NRPM Sections 4.3.4, 4.4, 4.10 and 6.10.1", "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", "- Updates to public documentation", "### Proposal/Draft Policy Text Assessed", "[14 August 2023](https://lists.arin.net/pipermail/arin-ppml/2023-September/036956.html)", "## History and Earlier Versions", "|Action|Date|", "|--- |--- |", "| [Proposal](/participate/policy/proposals/2023/ARIN_prop_323/) | 14 August 2023 |", "| [Draft Policy](https://lists.arin.net/pipermail/arin-ppml/2023-September/036956.html) | 26 September 2023 |", "| [Recommended Draft Policy](https://lists.arin.net/pipermail/arin-ppml/2023-October/036984.html) | 25 October 2023 |", "| [Last Call](https://lists.arin.net/pipermail/arin-ppml/2024-April/037300.html) | 22 April 2024 |", "| [Advanced to Board of Trustees](https://lists.arin.net/pipermail/arin-ppml/2024-June/037404.html) | 25 June 2024 |", "| [Adopted](https://lists.arin.net/pipermail/arin-ppml/2024-August/037572.html) | 19 August 2024 |", "| [Implemented](https://lists.arin.net/pipermail/arin-ppml/2024-August/037573.html) | 21 August 2024 |", "## Related Meetings", "### Advisory Council", "- [21 September 2023](/about/welcome/ac/meetings/2023_0921/)", "- [20 October 2023](/about/welcome/ac/meetings/2023_1020/)", "- [16 November 2023](/about/welcome/ac/meetings/2023_1116/)", "- [21 December 2023](/about/welcome/ac/meetings/2023_1221)", "- [26 January 2024](/about/welcome/ac/meetings/2024_0126)", "- [15 February 2024](/about/welcome/ac/meetings/2024_0215/)", "- [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/)", "- [20 June 2024](/about/welcome/ac/meetings/2024_0620/)", "### Board of Trustees", "### ARIN Public Policy Meetings", "- [ARIN 52](/participate/meetings/ARIN52/)", "- [ARIN 53](/participate/meetings/ARIN53/)"], "lastUpdated": "2024-04-22", "url": "https://www.arin.net/participate/policy/drafts/2023_5/" },{ "number": "ARIN-2023-4", "title": "Modernization of Registration Requirements", "status": "Abandoned", "recommended": true, "shepherds": ["Alicia Trotman", "Daniel Schatte"], "problemStatement": "\nRegistration is central to the value provided by ARIN to the community. Registry quality depends greatly upon the timely registration of reassignments from ISPs to end users. The motivation for registration has waned since the depletion of the free pool. At the same time, privacy laws have been introduced in many jurisdictions across ARIN’s service region which constrain registration in certain cases. This combination of forces has generally discouraged many ISPs from registering reassignments. Registration remains vital to a number of stakeholders, including law enforcement and network operators. \nThis proposal aims to modernize the registration-related policies in Section 4 by introducing language that is meant to make registration requirements more adaptable to changing privacy laws, while reminding ISPs of the importance of registration when feasible for the benefit of the community.\n","policyStatement": "\nIn section 4.2.3.7.1,\nReplace\n"Each IPv4 reassignment or reallocation containing a /29 or more addresses shall be registered via SWIP or a directory services system which meets the standards set forth in section 3.2."\nWith\n"Each IPv4 reassignment or reallocation containing a /29 or more addresses shall be registered in the WHOIS directory via SWIP, or a directory services system which meets the standards set forth in section 3.2, within 14 days." \nRetire section 4.2.3.7.2 Reassignments and Reallocations Visible Within Seven Days\nRename 6.5.5.1\nFrom\n"Reassignment Information"\nTo\n"Reassignment and Reallocation Information"\nIn section 6.5.5.1,\nReplace\n"Each static IPv6 reassignment or reallocation containing a /47 or more addresses, or subdelegation of any size that will be individually announced, shall be registered in the WHOIS directory via SWIP or a distributed service which meets the standards set forth in section 3.2. Reassignment and reallocation registrations shall include each client’s organizational information, except where specifically exempted by this policy."\nWith\n"Each static IPv6 reassignment or reallocation containing a /47 or more addresses, or subdelegation of any size that will be individually announced, shall be registered in the WHOIS directory via SWIP, or a distributed service which meets the standards set forth in section 3.2, within 14 days. Reassignment and reallocation registrations shall include each client’s organizational information, except where specifically exempted by this policy."\nRetire section 6.5.5.2 Reassignments and Reallocations Visible Within Seven Days\n","implementationTime": "Immediate","fullText": ["## Current Text (17 January 2024)", "### AC Assessment of Conformance with the [Principles of Internet Number Resource Policy](/participate/policy/pdp/#4-principles-of-internet-number-resource-policy)", "Draft Policy ARIN-2023-4: Modernization of Registration Requirements, conforms to the principles of the ARIN Policy Development Process. This draft policy is found to be fair, impartial and technically sound. Based on community feedback and AC discussion we motion to move ARIN-2023-4: Modernization of Registration Requirements to Recommended Draft. If adopted this policy aims to modernize the registration related policies in Section 4.", "### Problem Statement", "Registration is central to the value provided by ARIN to the community. Registry quality depends greatly upon the timely registration of reassignments from ISPs to end users. The motivation for registration has waned since the depletion of the free pool. At the same time, privacy laws have been introduced in many jurisdictions across ARIN’s service region which constrain registration in certain cases. This combination of forces has generally discouraged many ISPs from registering reassignments. Registration remains vital to a number of stakeholders, including law enforcement and network operators. ", "This proposal aims to modernize the registration-related policies in Section 4 by introducing language that is meant to make registration requirements more adaptable to changing privacy laws, while reminding ISPs of the importance of registration when feasible for the benefit of the community.", "### Policy Statement", "In section 4.2.3.7.1,", "Replace", ""Each IPv4 reassignment or reallocation containing a /29 or more addresses shall be registered via SWIP or a directory services system which meets the standards set forth in section 3.2."", "With", ""Each IPv4 reassignment or reallocation containing a /29 or more addresses shall be registered in the WHOIS directory via SWIP, or a directory services system which meets the standards set forth in section 3.2, within 14 days." ", "Retire section 4.2.3.7.2 Reassignments and Reallocations Visible Within Seven Days", "Rename 6.5.5.1", "From", ""Reassignment Information"", "To", ""Reassignment and Reallocation Information"", "In section 6.5.5.1,", "Replace", ""Each static IPv6 reassignment or reallocation containing a /47 or more addresses, or subdelegation of any size that will be individually announced, shall be registered in the WHOIS directory via SWIP or a distributed service which meets the standards set forth in section 3.2. Reassignment and reallocation registrations shall include each client’s organizational information, except where specifically exempted by this policy."", "With", ""Each static IPv6 reassignment or reallocation containing a /47 or more addresses, or subdelegation of any size that will be individually announced, shall be registered in the WHOIS directory via SWIP, or a distributed service which meets the standards set forth in section 3.2, within 14 days. Reassignment and reallocation registrations shall include each client’s organizational information, except where specifically exempted by this policy."", "Retire section 6.5.5.2 Reassignments and Reallocations Visible Within Seven Days", "### Timetable for Implementation", "Immediate", "### Comments", "None", "## Staff and Legal Review (6 November 2023)", "### Staff Understanding", "This policy extends the requirement to create Reassignment and Reallocation records from 7 days to 14 days. The policy text is clear and understandable. Staff agrees with Legal's comment.", "### Implementable as Written? ", "Implementable with Legal's concerns addressed.", "### Impact on ARIN Registry Operations and Services", "None", "### Legal Review", "Legal has a material legal issue with the inclusion of "to the extent permitted and manner provided by applicable law" in proposed sections 4.2.3.7.1 and 6.5.5.1. Section 1.1 of the Policy Development Process (PDP) addresses generally that all policies must be consistent with applicable laws and regulations. Since the goal of the PDP is to create and update the policies that ARIN uses to administer Internet Number Resources, any such reference to applicable law is unnecessary and could create ambiguity and inconsistencies.", "### Implementation Timeframe Estimate ", "Three months", "### Implementation Requirements", "- Staff Training", "- Updates to public documentation", "- Updates to internal procedures and guidelines", "### Proposal/Draft Policy Text Assessed", "[21 September 2023](https://lists.arin.net/pipermail/arin-ppml/2023-September/036954.html)", "## History and Earlier Versions", "|Action|Date|", "|--- |--- |", "| [Proposal](/participate/policy/proposals/2023/ARIN_prop_322/) | 5 June 2023 |", "| [Draft Policy](https://lists.arin.net/pipermail/arin-ppml/2023-July/036918.html) | 25 July 2023 |", "| [Revised](https://lists.arin.net/pipermail/arin-ppml/2023-September/036954.html) | 21 September 2023 |", "| [Recommended Draft Policy](https://lists.arin.net/pipermail/arin-ppml/2023-December/037178.html) | 28 December 2023 |", "| [Revised](https://lists.arin.net/pipermail/arin-ppml/2024-January/037181.html) | 17 January 2024 |", "| Abandoned | 22 April 2024 | ", "## Related Meetings", "### Advisory Council", "- [20 July 2023](/about/welcome/ac/meetings/2023_0720/)", "- [17 August 2023](/about/welcome/ac/meetings/2023_0817/)", "- [21 September 2023](/about/welcome/ac/meetings/2023_0921/)", "- [20 October 2023](/about/welcome/ac/meetings/2023_1020/)", "- [16 November 2023](/about/welcome/ac/meetings/2023_1116/)", "- [21 December 2023](/about/welcome/ac/meetings/2023_1221)", "- [26 January 2024](/about/welcome/ac/meetings/2024_0126)", "- [15 February 2024](/about/welcome/ac/meetings/2024_0215/)", "- [21 March 2024](/about/welcome/ac/meetings/2024_0321/)", "- [17 April 2024](/about/welcome/ac/meetings/2024_0417/)", "### Board of Trustees", "### ARIN Public Policy Meetings", "- [ARIN 52](/participate/meetings/ARIN52/)", "- [ARIN 53](/participate/meetings/ARIN53/)"], "lastUpdated": "2024-04-22", "url": "https://www.arin.net/participate/policy/drafts/2023_4/" },{ "number": "ARIN-2023-3", "title": "Amendment of the waitlist agreement to include a restriction on leasing", "status": "Abandoned", "recommended": false, "shepherds": ["Chris Tacit", "Gerry George"], "problemStatement": "\nCurrently section 4.18 prohibits the transfer of waitlist space for a period of 60 months. However, there are no restrictions on leasing out the space immediately after obtaining it from the waitlist.\n","policyStatement": "\nModify the current text in 4.18 from:\nARIN will only issue future IPv4 assignments/allocations (excluding 4.4 and 4.10 space) from the ARIN Waitlist. The maximum size aggregate that an organization may qualify for at any one time is a /22. Organizations will be able to elect a smaller block size than they qualify for down to a /24. Organizations which hold more than a /20 equivalent of IPv4 space in aggregate (exclusive of special use space received under section 4.4 or 4.10) are not eligible to apply. Address space distributed from the waitlist will not be eligible for transfer, with the exception of Section 8.2 transfers, for a period of 60 months. This policy will be applied to all future distributions from the waitlist to include those currently listed.\nto\nARIN will only issue future IPv4 assignments/allocations (excluding 4.4 and 4.10 space) from the ARIN Waitlist. The maximum size aggregate that an organization may qualify for at any one time is a /22. Organizations will be able to elect a smaller block size than they qualify for down to a /24. Organizations which hold more than a /20 equivalent of IPv4 space in aggregate (exclusive of special use space received under section 4.4 or 4.10) are not eligible to apply. Address space distributed from the waitlist will not be eligible for lease or transfer, with the exception of Section 8.2 transfers, for a period of 60 months. This policy will be applied to all future distributions from the waitlist to include those currently listed.\n","implementationTime": "Immediate","fullText": ["## Current Text (20 June 2023)", "### Problem Statement", "Currently section 4.18 prohibits the transfer of waitlist space for a period of 60 months. However, there are no restrictions on leasing out the space immediately after obtaining it from the waitlist.", "### Policy Statement", "Modify the current text in 4.18 from:", "ARIN will only issue future IPv4 assignments/allocations (excluding 4.4 and 4.10 space) from the ARIN Waitlist. The maximum size aggregate that an organization may qualify for at any one time is a /22. Organizations will be able to elect a smaller block size than they qualify for down to a /24. Organizations which hold more than a /20 equivalent of IPv4 space in aggregate (exclusive of special use space received under section 4.4 or 4.10) are not eligible to apply. Address space distributed from the waitlist will not be eligible for transfer, with the exception of Section 8.2 transfers, for a period of 60 months. This policy will be applied to all future distributions from the waitlist to include those currently listed.", "to", "ARIN will only issue future IPv4 assignments/allocations (excluding 4.4 and 4.10 space) from the ARIN Waitlist. The maximum size aggregate that an organization may qualify for at any one time is a /22. Organizations will be able to elect a smaller block size than they qualify for down to a /24. Organizations which hold more than a /20 equivalent of IPv4 space in aggregate (exclusive of special use space received under section 4.4 or 4.10) are not eligible to apply. Address space distributed from the waitlist will not be eligible for lease or transfer, with the exception of Section 8.2 transfers, for a period of 60 months. This policy will be applied to all future distributions from the waitlist to include those currently listed.", "### Timetable for Implementation", "Immediate", "### Comments", "None", "## History and Earlier Versions", "|Action|Date|", "|--- |--- |", "| [Proposal](/participate/policy/proposals/2023/ARIN_prop_321/) | 2 June 2023 |", "| [Draft Policy](https://lists.arin.net/pipermail/arin-ppml/2023-June/036849.html) | 20 June 2023 |", "| [Abandoned](https://lists.arin.net/pipermail/arin-ppml/2023-October/036983.html) | 20 October 2023 |", "## Related Meetings", "### Advisory Council", "- [15 June 2023](/about/welcome/ac/meetings/2023_0615/)", "- [20 July 2023](/about/welcome/ac/meetings/2023_0720/)", "- [17 August 2023](/about/welcome/ac/meetings/2023_0817/)", "- [21 September 2023](/about/welcome/ac/meetings/2023_0921/)", "- [20 October 2023](/about/welcome/ac/meetings/2023_1020/)", "### Board of Trustees", "### ARIN Public Policy Meetings", "- [ARIN 52](/participate/meetings/ARIN52/)"], "lastUpdated": "2023-06-20", "url": "https://www.arin.net/participate/policy/drafts/2023_3/" },{ "number": "ARIN-2023-2", "title": "/26 initial IPv4 allocation for IXPs", "status": "Abandoned", "recommended": false, "shepherds": ["Matthew Wilder", "Gus Reese"], "problemStatement": "\nPer NRPM Section 4.4, ARIN has reserved a /15 for micro-allocations for critical internet infrastructure, such as internet exchange points (IXPs) and core DNS service providers. The majority of these allocation requests are made by IXPs. As of the last ARIN report, roughly half of this reservation is allocated (see Statistics & Reporting Projections from ARIN staff suggest that at current allocation rates, the remaining reserved space may be exhausted in the next few years.\nIn parallel, an analysis of PeeringDB data conducted by the RIPE Address Policy Working Group shows that approximately 70% of global IXPs have fewer than 32 members registered with that site. An IXP this size could readily operate with a /26 allocation, which would provide 100% overprovisioning beyond their existing peer count. (Source: https://github.com/mwichtlh/address-policy-wg )\nUnlike other types of allocations, IXP peering networks are not required by member networks to be globally reachable; only members of the IXP must be able to reach the prefix. As such, there is no technical requirement that an IXP allocation must be no smaller than a /24.\n","policyStatement": "\nExisting text:\n4.4. Micro-allocation\nARIN will make IPv4 micro-allocations to critical infrastructure providers of the Internet, including public exchange points, core DNS service providers (e.g. ICANN-sanctioned root and ccTLD operators) as well as the RIRs and IANA. These allocations will be no smaller than a /24. Multiple allocations may be granted in certain situations.\nReplace with:\n4.4 Micro-allocation\nARIN will make IPv4 micro-allocations to critical infrastructure providers of the Internet, including public internet exchange points (IXPs), core DNS service providers (e.g. ICANN-sanctioned root and ccTLD operators) as well as the RIRs and IANA. These allocations will be no smaller than a /26 for IXPs, or a /24 for other allocations that require global reachability of the assigned allocation. Multiple allocations may be granted in certain situations.\n4.4.1 Micro-allocations for Internet Exchange Points (IXPs)\nAn IXP requesting an initial IPv4 allocation from this reserved space will be assigned a /26 by default. An IXP requesting an allocation larger than a /26 must show an immediate need to utilize more than 25% of the requested allocation size upon initial commissioning.\nAn IXP requesting an allocation under this section must have also requested, or already received, an IPv6 allocation for the same purpose under Section 6.10.1.\nAn allocation made to an IXP under this section may only be used for the operation of its public peering LAN. No other uses are allowed.\nAn IXP that has received an IPv4 allocation under this section may request a larger allocation once they have utilized more than 50% of their existing one. Upon receiving the larger allocation, the IXP must migrate to the new allocation and return their previous one to ARIN within 6 months.\n","implementationTime": "Immediate","fullText": ["## Current Text (20 June 2023)", "### Problem Statement", "Per NRPM Section 4.4, ARIN has reserved a /15 for micro-allocations for critical internet infrastructure, such as internet exchange points (IXPs) and core DNS service providers. The majority of these allocation requests are made by IXPs. As of the last ARIN report, roughly half of this reservation is allocated (see Statistics & Reporting Projections from ARIN staff suggest that at current allocation rates, the remaining reserved space may be exhausted in the next few years.", "In parallel, an analysis of PeeringDB data conducted by the RIPE Address Policy Working Group shows that approximately 70% of global IXPs have fewer than 32 members registered with that site. An IXP this size could readily operate with a /26 allocation, which would provide 100% overprovisioning beyond their existing peer count. (Source: https://github.com/mwichtlh/address-policy-wg )", "Unlike other types of allocations, IXP peering networks are not required by member networks to be globally reachable; only members of the IXP must be able to reach the prefix. As such, there is no technical requirement that an IXP allocation must be no smaller than a /24.", "### Policy Statement", "Existing text:", "4.4. Micro-allocation", "ARIN will make IPv4 micro-allocations to critical infrastructure providers of the Internet, including public exchange points, core DNS service providers (e.g. ICANN-sanctioned root and ccTLD operators) as well as the RIRs and IANA. These allocations will be no smaller than a /24. Multiple allocations may be granted in certain situations.", "Replace with:", "4.4 Micro-allocation", "ARIN will make IPv4 micro-allocations to critical infrastructure providers of the Internet, including public internet exchange points (IXPs), core DNS service providers (e.g. ICANN-sanctioned root and ccTLD operators) as well as the RIRs and IANA. These allocations will be no smaller than a /26 for IXPs, or a /24 for other allocations that require global reachability of the assigned allocation. Multiple allocations may be granted in certain situations.", "4.4.1 Micro-allocations for Internet Exchange Points (IXPs)", "An IXP requesting an initial IPv4 allocation from this reserved space will be assigned a /26 by default. An IXP requesting an allocation larger than a /26 must show an immediate need to utilize more than 25% of the requested allocation size upon initial commissioning.", "An IXP requesting an allocation under this section must have also requested, or already received, an IPv6 allocation for the same purpose under Section 6.10.1.", "An allocation made to an IXP under this section may only be used for the operation of its public peering LAN. No other uses are allowed.", "An IXP that has received an IPv4 allocation under this section may request a larger allocation once they have utilized more than 50% of their existing one. Upon receiving the larger allocation, the IXP must migrate to the new allocation and return their previous one to ARIN within 6 months.", "### Timetable for Implementation", "Immediate", "### Comments", "This proposal mirrors RIPE policy proposal 2023-01 (see https://www.ripe.net/participate/policies/proposals/2023-01) which is currently under consideration in that region and appears to have sufficient community support for adoption at the time of this writing.", "## History and Earlier Versions", "|Action|Date|", "|--- |--- |", "| [Proposal](/participate/policy/proposals/2023/ARIN_prop_320/) | 25 May 2023 |", "| [Draft Policy](https://lists.arin.net/pipermail/arin-ppml/2023-June/036848.html) | 20 June 2023 |", "| [Abandoned](https://lists.arin.net/pipermail/arin-ppml/2023-December/037177.html) | 28 December 2023 |", "## Related Meetings", "### Advisory Council", "- [15 June 2023](/about/welcome/ac/meetings/2023_0615/)", "- [20 July 2023](/about/welcome/ac/meetings/2023_0720/)", "- [17 August 2023](/about/welcome/ac/meetings/2023_0817/)", "- [21 September 2023](/about/welcome/ac/meetings/2023_0921/)", "- [20 October 2023](/about/welcome/ac/meetings/2023_1020/)", "- [16 November 2023](/about/welcome/ac/meetings/2023_1116/)", "- [21 December 2023](/about/welcome/ac/meetings/2023_1221)", "### Board of Trustees", "### ARIN Public Policy Meetings", "- [ARIN 52](/participate/meetings/ARIN52/)"], "lastUpdated": "2023-06-20", "url": "https://www.arin.net/participate/policy/drafts/2023_2/" },{ "number": "ARIN-2023-1", "title": "Retire 4.2.1.4. Slow Start", "status": "Implemented", "recommended": true, "shepherds": ["Brian Jones", "Kaitlyn Pellak"], "problemStatement": "\nSection 4.2.1.4 Slow Start has been a part of the NRPM for two decades, and successfully served to constrain the rate at which ARIN issued IPv4 address allocations to its members for many years. Following the exhaustion of the free pool, as well as the introduction and refinement of transfer policies, Slow Start has ceased to be applicable to the operations of ARIN's registration services. Staff has confirmed that this policy has not been used since 2018.\n","policyStatement": "\nRetire 4.2.1.4 Slow Start\n","implementationTime": "Immediate","fullText": ["## Current Text (23 May 2023)", "### AC Assessment of Conformance with the [Principles of Internet Number Resource Policy](/participate/policy/pdp/#4-principles-of-internet-number-resource-policy)", "Based on community feedback and AC discussion Draft ARIN-2023-1: Retire 4.2.1.4. Slow Start has been moved to Recommended Draft. This policy, if adopted, will retire section 4.2.1.4 Slow Start which served its purpose to constrain the rate of IPv4 allocations made by ARIN and has not been in use since 2018 due to the exhaustion of the IPv4 free pool and introduction of transfer policies. This Draft Policy is fair, impartial, and technically sound.", "### Problem Statement", "Section 4.2.1.4 Slow Start has been a part of the NRPM for two decades, and successfully served to constrain the rate at which ARIN issued IPv4 address allocations to its members for many years. Following the exhaustion of the free pool, as well as the introduction and refinement of transfer policies, Slow Start has ceased to be applicable to the operations of ARIN's registration services. Staff has confirmed that this policy has not been used since 2018.", "### Policy Statement", "Retire 4.2.1.4 Slow Start", "### Timetable for Implementation", "Immediate", "### Comments", "None", "## Staff and Legal Review (6 November 2023)", "### Staff Understanding", "Draft Policy ARIN-2023-1 Retire 4.2.1.4. Slow Start intends to retire policy text that is no longer applicable. 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 ", "Three months", "### Implementation Requirements", "- Updates to public documentation", "### Proposal/Draft Policy Text Assessed", "[23 May 2023](https://lists.arin.net/pipermail/arin-ppml/2023-May/036786.html)", "## History and Earlier Versions", "|Action|Date|", "|--- |--- |", "| [Proposal](/participate/policy/proposals/2023/ARIN_prop_319/) | 17 April 2023 |", "| [Draft Policy](https://lists.arin.net/pipermail/arin-ppml/2023-May/036786.html) | 23 May 2023 |", "| [Recommended Draft Policy](https://lists.arin.net/pipermail/arin-ppml/2023-November/037100.html) | 21 November 2023 |", "| [Last Call](https://lists.arin.net/pipermail/arin-ppml/2024-April/037299.html) | 22 April 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", "- [18 May 2023](/about/welcome/ac/meetings/2023_0518/)", "- [15 June 2023](/about/welcome/ac/meetings/2023_0615/)", "- [20 July 2023](/about/welcome/ac/meetings/2023_0720/)", "- [17 August 2023](/about/welcome/ac/meetings/2023_0817/)", "- [21 September 2023](/about/welcome/ac/meetings/2023_0921/)", "- [20 October 2023](/about/welcome/ac/meetings/2023_1020/)", "- [16 November 2023](/about/welcome/ac/meetings/2023_1116/)", "- [21 December 2023](/about/welcome/ac/meetings/2023_1221)", "- [26 January 2024](/about/welcome/ac/meetings/2024_0126)", "- [15 February 2024](/about/welcome/ac/meetings/2024_0215/)", "- [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 52](/participate/meetings/ARIN52/)", "- [ARIN 53](/participate/meetings/ARIN53/)"], "lastUpdated": "2023-05-23", "url": "https://www.arin.net/participate/policy/drafts/2023_1/" },{ "number": "ARIN-2022-12", "title": "Direct Assignment Language Update", "status": "Implemented", "recommended": true, "shepherds": ["Doug Camin", "Leif Sawyer"], "problemStatement": "\nAs a result of ARIN's fee harmonization direct assignments are no longer being utilized within ARIN databases therefore language around that has been deprecated and should be modernized and aligned with current ARIN practices.\n","policyStatement": "\nSection 2.5:\nUpdate definition of Allocation and Assignment to reflect current practice.\nFROM:\n"Allocation - IP addresses delegated to an organization directly by ARIN for the purpose of subsequent distribution by the recipient organization to other parties.\nAssignment - IP addresses delegated to an organization directly by ARIN for the exclusive use of the recipient organization."\nTO:\n"Allocation - A block of IP addresses issued from ARIN directly to customers. These IP addresses may be further reassigned or reallocated accordingly.​\nAssignment - This term is no longer used to describe IP addresses issued by ARIN.\nSection 2.6:\nChange "receiving assignments of" to "issued."\nFROM:\n"2.6 End User\nAn end-user is an organization receiving assignments of IP addresses exclusively for use in its operational networks."\nTO:\n"2.6 End User\nAn end-user is an organization issued IP addresses exclusively for use in its operational networks."\nSection 2.8\nChange "allocated or assigned" to "issued."\nFROM:\n"2.8. Registration Services Agreement (RSA)\nNumber resources allocated or assigned by ARIN under these policies are subject to a contractual agreement between ARIN and the resource holder. Throughout this document, any and all forms of this agreement, past or future, are simply referred to as the Registration Services Agreement (RSA)."\nTO:\n"2.8. Registration Services Agreement (RSA)\nInternet number resources issued by ARIN under these policies are subject to a contractual agreement between ARIN and the resource holder. Throughout this document, any and all forms of this agreement, past or future, are simply referred to as the Registration Services Agreement (RSA)."\nSection 3.6.3:​\nChange paragraph 1 text​\nFROM: "This policy applies to every Organization that has a direct assignment, direct allocation, or AS number from ARIN"​\nTO: "This policy applies to every Organization that has Internet number resources issued by ARIN"​\nRESULT: "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 ISP. This includes but is not limited to upstream ISPs and their downstream ISP customers (as defined by NRPM 2.5 and 2.6), but not reassignments made to their downstream end user customers."\nSection 4.2.2:​\nReplace text as follows\nFROM:​ "All ISP organizations without direct assignments or allocations from ARIN qualify for an initial allocation of up to a /22, subject to ARIN’s minimum allocation size.​\nAll ISP organizations without direct allocations, direct assignments, re-allocations or reassignments automatically qualify for a /24. These organizations are exempt from requirements of showing the efficient utilization of previously held IPv4 space. These organizations may qualify for a larger than a /24 by documenting how the requested allocation will be utilized within the request size specified in 4.2.4.3.​\nISPs holding re-allocations and/or reassignments must show the efficient utilization of their resources consistent with the requirements in sections 4.2.3 and 4.2.4.​"\nTO:​ "All ISP organizations without any IPv4 addresses from ARIN automatically qualify for an initial allocation of a /24. ISPs providing a 24-month utilization plan for the request size specified may receive up to a /22. ISPs holding re-allocations and/or reassignments must show the efficient utilization of their resources consistent with the requirements in sections 4.2.3 and 4.2.4.​"\nSection 4.3.2:​\nChange paragraph 1 text​\nFROM: "End-user organizations without direct assignments or allocations from ARIN qualify for an initial assignment of ARIN’s minimum assignment size."\nTO: "End-user organizations without an IPv4 allocation from ARIN qualify for an initial allocation of ARIN’s minimum allocation size."​\nSection 6.5.8:​\nChange section title​\nFROM: "Direct Assignments from ​ARIN to End-user Organizations"​\nTO: "End-user Allocations"​\nSection 8.5.4: ​\nChange section text ​\nFROM: "Organizations without direct assignments or allocations from ARIN qualify for transfer of an initial IPv4 block of ARIN’s minimum transfer size."\nTO: "Organizations without an IPv4 allocation from ARIN qualify for transfer of an initial IPv4 allocation of ARIN’s minimum transfer size."​\nSection 8.5.6: ​\nChange section text ​\nFROM: "Organizations with direct assignments or allocations from ARIN must have efficiently utilized at least 50% of their cumulative IPv4 address blocks in order to receive additional IPv4 addresses. This includes all IPv4 space reassigned to their customers."\nTO: "Organizations with an IPv4 allocation from ARIN must have efficiently utilized at least 50% of their cumulative IPv4 address blocks in order to receive additional IPv4 addresses. This includes all IPv4 space reallocated and/or reassigned to their customers."​\n","implementationTime": "Three months","fullText": ["## Current Text (20 March 2024)", "### AC Assessment of Conformance with the [Principles of Internet Number Resource Policy](/participate/policy/pdp/#4-principles-of-internet-number-resource-policy)", "Draft Policy ARIN-2022-12: Direct Assignment Language Update, conforms to the principles of the ARIN Policy Development Process. This draft policy is found to be fair, impartial, and technically sound. Based on community feedback and AC discussion we motion to move ARIN 2022-12: Direct Assignment Language Update, to Recommended Draft. If adopted this policy aims to update the language of Number Policy Resource Manual to remove references to the deprecated term "assignment" and use the term "allocation," which conforms with current ARIN business practices.", "### Problem Statement", "As a result of ARIN's fee harmonization direct assignments are no longer being utilized within ARIN databases therefore language around that has been deprecated and should be modernized and aligned with current ARIN practices.", "### Policy Statement", "Section 2.5:", "Update definition of Allocation and Assignment to reflect current practice.", "FROM:", ""Allocation - IP addresses delegated to an organization directly by ARIN for the purpose of subsequent distribution by the recipient organization to other parties.", "Assignment - IP addresses delegated to an organization directly by ARIN for the exclusive use of the recipient organization."", "TO:", ""Allocation - A block of IP addresses issued from ARIN directly to customers. These IP addresses may be further reassigned or reallocated accordingly.​", "Assignment - This term is no longer used to describe IP addresses issued by ARIN.", "Section 2.6:", "Change "receiving assignments of" to "issued."", "FROM:", ""2.6 End User", "An end-user is an organization receiving assignments of IP addresses exclusively for use in its operational networks."", "TO:", ""2.6 End User", "An end-user is an organization issued IP addresses exclusively for use in its operational networks."", "Section 2.8", "Change "allocated or assigned" to "issued."", "FROM:", ""2.8. Registration Services Agreement (RSA)", "Number resources allocated or assigned by ARIN under these policies are subject to a contractual agreement between ARIN and the resource holder. Throughout this document, any and all forms of this agreement, past or future, are simply referred to as the Registration Services Agreement (RSA)."", "TO:", ""2.8. Registration Services Agreement (RSA)", "Internet number resources issued by ARIN under these policies are subject to a contractual agreement between ARIN and the resource holder. Throughout this document, any and all forms of this agreement, past or future, are simply referred to as the Registration Services Agreement (RSA)."", "Section 3.6.3:​", "Change paragraph 1 text​", "FROM: "This policy applies to every Organization that has a direct assignment, direct allocation, or AS number from ARIN"​", "TO: "This policy applies to every Organization that has Internet number resources issued by ARIN"​", "RESULT: "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 ISP. This includes but is not limited to upstream ISPs and their downstream ISP customers (as defined by NRPM 2.5 and 2.6), but not reassignments made to their downstream end user customers."", "Section 4.2.2:​", "Replace text as follows", "FROM:​ "All ISP organizations without direct assignments or allocations from ARIN qualify for an initial allocation of up to a /22, subject to ARIN’s minimum allocation size.​", "All ISP organizations without direct allocations, direct assignments, re-allocations or reassignments automatically qualify for a /24. These organizations are exempt from requirements of showing the efficient utilization of previously held IPv4 space. These organizations may qualify for a larger than a /24 by documenting how the requested allocation will be utilized within the request size specified in 4.2.4.3.​", "ISPs holding re-allocations and/or reassignments must show the efficient utilization of their resources consistent with the requirements in sections 4.2.3 and 4.2.4.​"", "TO:​ "All ISP organizations without any IPv4 addresses from ARIN automatically qualify for an initial allocation of a /24. ISPs providing a 24-month utilization plan for the request size specified may receive up to a /22. ISPs holding re-allocations and/or reassignments must show the efficient utilization of their resources consistent with the requirements in sections 4.2.3 and 4.2.4.​"", "Section 4.3.2:​", "Change paragraph 1 text​", "FROM: "End-user organizations without direct assignments or allocations from ARIN qualify for an initial assignment of ARIN’s minimum assignment size."", "TO: "End-user organizations without an IPv4 allocation from ARIN qualify for an initial allocation of ARIN’s minimum allocation size."​", "Section 6.5.8:​", "Change section title​", "FROM: "Direct Assignments from ​ARIN to End-user Organizations"​", "TO: "End-user Allocations"​", "Section 8.5.4: ​", "Change section text ​", "FROM: "Organizations without direct assignments or allocations from ARIN qualify for transfer of an initial IPv4 block of ARIN’s minimum transfer size."", "TO: "Organizations without an IPv4 allocation from ARIN qualify for transfer of an initial IPv4 allocation of ARIN’s minimum transfer size."​", "Section 8.5.6: ​", "Change section text ​", "FROM: "Organizations with direct assignments or allocations from ARIN must have efficiently utilized at least 50% of their cumulative IPv4 address blocks in order to receive additional IPv4 addresses. This includes all IPv4 space reassigned to their customers."", "TO: "Organizations with an IPv4 allocation from ARIN must have efficiently utilized at least 50% of their cumulative IPv4 address blocks in order to receive additional IPv4 addresses. This includes all IPv4 space reallocated and/or reassigned to their customers."​", "### Timetable for Implementation", "Three months", "## Staff and Legal Review (15 March 2024)", "### Staff Understanding", "We understand that the intent of this Recommended Draft Policy is to update the definition of the terms "Allocation" and "Assignment" in section 2.5 of the Number Resource Policy Manual. Staff recommends that proposed definitions be changed to the following to be more precise and clearer as to the meaning of these terms in reference to ARIN practice and the policies in the NRPM .", "- In Section 2.5, update definition of Allocation and Assignment to reflect current practice.", " - **Allocation** – the term allocation refers to a block of IP addresses issued from ARIN directly to customers. These IP addresses may be further reassigned or reallocated accordingly.", " - **Assignment** – this term is no longer used to describe IP addresses issued by ARIN.", "- Staff suggests that consistent use of the term Allocation when the definition of Allocation is intended, instead of synonyms or other forms of the word, such as "allocated," will add clarity and precision to the text. For similar reasons, staff recommends eventually making these updates to the entire NRPM.", "### Implementable as Written? ", "Yes", "### Impact on ARIN Registry Operations and Services", "None", "### Legal Review", "There is no legal objection to proposed language, but as this is the first time that the terminology has been reviewed in many years, Legal notes that use of the term "issued" rather than "allocated or assigned" in Section 2.8 would make the language consistent with the terminology used in the Registration Services Agreement (RSA).", "### Implementation Timeframe Estimate ", "Three months", "### Implementation Requirements", "- Staff training", "- Updates to public documentation", "### Proposal/Draft Policy Text Assessed", "[1 March 2024](https://lists.arin.net/pipermail/arin-ppml/2024-March/037258.html)", "## History and Earlier Versions", "|Action|Date|", "|--- |--- |", "| [Proposal](/participate/policy/proposals/2022/ARIN_prop_317_orig/) | 25 July 2022 |", "| [Draft Policy](https://lists.arin.net/pipermail/arin-ppml/2022-August/036465.html) | 23 August 2022 |", "| [Revised](https://lists.arin.net/pipermail/arin-ppml/2022-November/036589.html) | 3 November 2022 |", "| [Revised](https://lists.arin.net/pipermail/arin-ppml/2023-March/036686.html) | 20 March 2023 |", "| [Revised](https://lists.arin.net/pipermail/arin-ppml/2023-July/036905.html) | 18 July 2023 |", "| [Revised](https://lists.arin.net/pipermail/arin-ppml/2023-August/036929.html) | 2 August 2023 |", "| [Revised](https://lists.arin.net/pipermail/arin-ppml/2023-August/036940.html) | 14 August 2023 |", "| [Revised](https://lists.arin.net/pipermail/arin-ppml/2023-September/036950.html) | 5 September 2023 |", "| [Revised](https://lists.arin.net/pipermail/arin-ppml/2023-September/036962.html) | 29 September 2023 |", "| [Revised](https://lists.arin.net/pipermail/arin-ppml/2024-February/037193.html) | 1 February 2024 |", "| [Revised](https://lists.arin.net/pipermail/arin-ppml/2024-March/037258.html) | 1 March 2024 |", "| [Revised](https://lists.arin.net/pipermail/arin-ppml/2024-March/037266.html) | 20 March 2024 |", "| [Recommended Draft Policy](https://lists.arin.net/pipermail/arin-ppml/2024-May/037320.html) | 21 May 2024 | ", "| [Last Call](https://lists.arin.net/pipermail/arin-ppml/2024-October/037618.html) | 30 October 2024 |", "| [Advanced to Board of Trustees](https://lists.arin.net/pipermail/arin-ppml/2024-November/037637.html) | 26 November 2024 | ", "| [Adopted](/about/welcome/board/meetings/2024_1209/) | 9 December 2024 | ", "| Implemented | 4 March 2025 |", "## 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/)", "- [27 January 2023](/about/welcome/ac/meetings/2023_0127/)", "- [16 February 2023](/about/welcome/ac/meetings/2023_0216/)", "- [16 March 2023](/about/welcome/ac/meetings/2023_0316/)", "- [19 April 2023](/about/welcome/ac/meetings/2023_0419/)", "- [18 May 2023](/about/welcome/ac/meetings/2023_0518/)", "- [15 June 2023](/about/welcome/ac/meetings/2023_0615/)", "- [20 July 2023](/about/welcome/ac/meetings/2023_0720/)", "- [17 August 2023](/about/welcome/ac/meetings/2023_0817/)", "- [21 September 2023](/about/welcome/ac/meetings/2023_0921/)", "- [20 October 2023](/about/welcome/ac/meetings/2023_1020/)", "- [16 November 2023](/about/welcome/ac/meetings/2023_1116/)", "- [21 December 2023](/about/welcome/ac/meetings/2023_1221)", "- [26 January 2024](/about/welcome/ac/meetings/2024_0126)", "- [15 February 2024](/about/welcome/ac/meetings/2024_0215/)", "- [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/)", "- [20 June 2024](/about/welcome/ac/meetings/2024_0620/)", "- [18 July 2024](/about/welcome/ac/meetings/2024_0718/)", "- [15 August 2024](/about/welcome/ac/meetings/2024_0815/)", "- [19 September 2024](/about/welcome/ac/meetings/2024_0919/)", "- [25 October 2024](/about/welcome/ac/meetings/2024_1025/)", "- [21 November 2024](/about/welcome/ac/meetings/2024_1121/)", "### Board of Trustees", "- [9 December 2024](/about/welcome/board/meetings/2024_1209/)", "### ARIN Public Policy Meetings", "- [ARIN 50](/participate/meetings/ARIN50/)", "- [ARIN 51](/participate/meetings/ARIN51/)", "- [ARIN 52](/participate/meetings/ARIN52/)", "- [ARIN 53](/participate/meetings/ARIN53/)", "- [ARIN 54](/participate/meetings/ARIN54/)"], "lastUpdated": "2024-05-21", "url": "https://www.arin.net/participate/policy/drafts/2022_12/" },{ "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-2022-8", "title": "Streamlining Section 11 Policy Language", "status": "Implemented", "recommended": true, "shepherds": ["Chris Tacit", "Andrew Dul"], "problemStatement": "\nSection 11 of the NRPM contains a great deal of language that is either explicitly not policy, or is not impactful on ARIN's administration of Internet number resources for experimental allocations, or to the customers requesting said resources. A revision to transform Section 11 into a collection of policies for experimental allocations serves to make the Section more easily digested by the reader, and a more functional reference for customers and ARIN staff during experimental allocation requests.\n","policyStatement": "\nSection 11 Overview\nCurrent text:\n11. Experimental Internet Resource Allocations\nARIN will allocate Numbering Resources to entities requiring temporary Numbering Resources for a fixed period of time under the terms of recognized experimental activity.\n"Numbering Resources"refers to unicast IPv4 or IPv6 address space and Autonomous System numbers.\nThe following are the criteria for this policy:\nProposed text:\n11. Experimental Internet Resource Allocations\nARIN will allocate Internet Number Resources to organizations requiring temporary Internet Number Resources for a fixed period of time under the terms of a recognized experimental activity.\nSection 11.1\nCurrent text:\n11.1. Documentation of Recognized Experimental Activity\nA Recognized Experimental Activity is one where the experiment's objectives and practices are described in a publicly accessible document. It is a normal requirement that a Recognized Experimental Activity also includes the undertaking that the experiment's outcomes be published in a publicly accessible document at the end of the experiment. The conditions for determining the end of the experiment are to be included in the document. Applicants for an experimental allocation are expected to demonstrate an understanding that when the experiment ends, the allocation will be returned; a successful experiment may need a new allocation under normal policies in order to continue in production or commercial use, but will not retain the experimental allocation.\nA "publicly accessible document"is a document that is publicly and openly available free of charges and free of any constraints of disclosure.\nARIN will not recognize an experimental activity under this policy if the entire research experiment cannot be publicly disclosed.\nARIN has a strong preference for the recognition of experimental activity documentation in the form of a document which has been approved for publication by the IESG or by a similar mechanism as implemented by the IETF.\nProposed text:\n11.1. Eligibility Criteria for Recognized Experimental Activity\nThe eligibility criteria for a recognized experimental activity under this policy are:\n- The experiment’s description and objectives are published in a publicly accessible document, which for the purposes of this policy means that the document is readily available free of charge to the public, and free of any constraints of disclosure within one year after the end of the experiment;\n- The experiment’s outcomes must also be published in a publicly accessible document;\n- Demonstration to ARIN that the experimental activity is technically sound; and\n- Demonstration to ARIN that the experimental activity is technically coordinated in that consideration of any potential negative impact of the proposed experiment on the operation of the Internet and its deployed services has been considered, and a description of experimenter mitigation plans to contain any negative impacts has been provided.\nRetire Sections 11.2 and 11.3\nSection 11.4\nCurrent text:\n11.4. Resource Allocation Term and Renewal\nThe Numbering Resources are allocated for a period of one year. The allocation can be renewed on application to ARIN providing information as per Detail One. The identity and details of the applicant and the allocated Numbering Resources will be published under the conditions of ARIN's normal publication policy. At the end of the experiment, resources allocated under this policy will be returned to the available pool.\nProposed text:\n11.4. Resource Allocation Term and Renewal\nThe Internet Number Resources are allocated for a period of one year under this policy. The allocation can be renewed on application to ARIN, prior to the expiry of the one-year period, providing information as to why an extension is necessary for a successful experiment. The resources allocated under this policy must be returned to ARIN at the earliest of: (1) the recognized experimental activity has ended; or (2) the end of the one-year period and any extension thereof.\nSection 11.5\nCurrent text:\n11.5. Single Resource Allocation per Experiment\nARIN will make one-off allocations only, on an annual basis to any applicant. Additional allocations to an organization already holding experimental activity resources relating to the specified activity outside the annual cycle will not be made unless justified by a subsequent complete application.\nIt's important for the requesting organization to ensure they have sufficient resources requested as part of their initial application for the proposed experimental use.\nProposed text:\n11.5. Single Resource Allocation per Experiment\nARIN will make only one allocation per recognized experiment. An allocation may consist of multiple Internet Number Resources if required to conduct the recognized activity. Additional allocations to an organization already holding experimental activity resources will not be made under this policy unless justified by a subsequent complete application relating to a different experimental activity.\nRetire Section 11.6\nSection 11.7\nCurrent text:\n11.7. Resource Allocation Guidelines\nThe Numbering Resources requested come from the global Internet Resource space, do not overlap currently assigned space, and are not from private or other non-routable Internet Resource space. The allocation size shall be consistent with the existing ARIN minimum allocation sizes, unless smaller allocations are intended to be explicitly part of the experiment. If an organization requires more resources than stipulated by the minimum allocation size in force at the time of its request, the request must clearly describe and justify why a larger allocation is required. All research allocations must be registered publicly in whois. Each research allocation will be designated as a research allocation with a comment indicating when the allocation will end.\nProposed text:\n11.7. Resource Allocation Guidelines\nThe Internet Number Resources requested come from the global Internet Number Resource space, shall not overlap any currently assigned space, and shall not be from private or other non-routable Internet Number Resource space. The allocation size shall be consistent with existing ARIN minimum allocation sizes, unless smaller allocations are explicitly required due to the nature of the experiment. If an organization requires more resources than stipulated by the minimum allocation size in force at the time of its request, the request must clearly describe and justify why a larger allocation is required. All research allocations must be registered publicly in ARIN’s directory services. Each research allocation will be designated as a research allocation with a comment indicating when the allocation will end.\nSection 11.8\nCurrent text:\n11.8. Commercial Use Prohibited\nIf there is any evidence that the temporary resource is being used for commercial purposes, or is being used for any activities not documented in the original experiment description provided to ARIN, ARIN reserves the right to immediately withdraw the resource and reassign it to the free pool.\nProposed text:\n11.8. Commercial Use Prohibited\nIf there is any evidence that the temporary resource is being used for commercial purposes or is being used for any activities not documented in the original experiment description provided to ARIN, ARIN reserves the right to immediately withdraw the resource.\nRetire Section 11.9\n","implementationTime": "Immediate","fullText": ["## Current Text (15 March 2023)", "### 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 2022-8 conforms to the ARIN Policy Development Process since: (1) the simplifications and additional clarity of the proposed text enhance the fair and impartial administration of number resources by ARIN; (2) clarifications contained in the text regarding the temporary nature of the use of number resources for experimental purposes are technically sound, since they support the conservation and efficient utilization of number resources; and (3) the proposed text appears to be supported by the community generally based on feedback received so far.", "### Problem Statement", "Section 11 of the NRPM contains a great deal of language that is either explicitly not policy, or is not impactful on ARIN's administration of Internet number resources for experimental allocations, or to the customers requesting said resources. A revision to transform Section 11 into a collection of policies for experimental allocations serves to make the Section more easily digested by the reader, and a more functional reference for customers and ARIN staff during experimental allocation requests.", "### Policy Statement", "Section 11 Overview", "Current text:", "11. Experimental Internet Resource Allocations", "ARIN will allocate Numbering Resources to entities requiring temporary Numbering Resources for a fixed period of time under the terms of recognized experimental activity.", ""Numbering Resources"refers to unicast IPv4 or IPv6 address space and Autonomous System numbers.", "The following are the criteria for this policy:", "Proposed text:", "11. Experimental Internet Resource Allocations", "ARIN will allocate Internet Number Resources to organizations requiring temporary Internet Number Resources for a fixed period of time under the terms of a recognized experimental activity.", "Section 11.1", "Current text:", "11.1. Documentation of Recognized Experimental Activity", "A Recognized Experimental Activity is one where the experiment's objectives and practices are described in a publicly accessible document. It is a normal requirement that a Recognized Experimental Activity also includes the undertaking that the experiment's outcomes be published in a publicly accessible document at the end of the experiment. The conditions for determining the end of the experiment are to be included in the document. Applicants for an experimental allocation are expected to demonstrate an understanding that when the experiment ends, the allocation will be returned; a successful experiment may need a new allocation under normal policies in order to continue in production or commercial use, but will not retain the experimental allocation.", "A "publicly accessible document"is a document that is publicly and openly available free of charges and free of any constraints of disclosure.", "ARIN will not recognize an experimental activity under this policy if the entire research experiment cannot be publicly disclosed.", "ARIN has a strong preference for the recognition of experimental activity documentation in the form of a document which has been approved for publication by the IESG or by a similar mechanism as implemented by the IETF.", "Proposed text:", "11.1. Eligibility Criteria for Recognized Experimental Activity", "The eligibility criteria for a recognized experimental activity under this policy are:", "- The experiment’s description and objectives are published in a publicly accessible document, which for the purposes of this policy means that the document is readily available free of charge to the public, and free of any constraints of disclosure within one year after the end of the experiment;", "- The experiment’s outcomes must also be published in a publicly accessible document;", "- Demonstration to ARIN that the experimental activity is technically sound; and", "- Demonstration to ARIN that the experimental activity is technically coordinated in that consideration of any potential negative impact of the proposed experiment on the operation of the Internet and its deployed services has been considered, and a description of experimenter mitigation plans to contain any negative impacts has been provided.", "Retire Sections 11.2 and 11.3", "Section 11.4", "Current text:", "11.4. Resource Allocation Term and Renewal", "The Numbering Resources are allocated for a period of one year. The allocation can be renewed on application to ARIN providing information as per Detail One. The identity and details of the applicant and the allocated Numbering Resources will be published under the conditions of ARIN's normal publication policy. At the end of the experiment, resources allocated under this policy will be returned to the available pool.", "Proposed text:", "11.4. Resource Allocation Term and Renewal", "The Internet Number Resources are allocated for a period of one year under this policy. The allocation can be renewed on application to ARIN, prior to the expiry of the one-year period, providing information as to why an extension is necessary for a successful experiment. The resources allocated under this policy must be returned to ARIN at the earliest of: (1) the recognized experimental activity has ended; or (2) the end of the one-year period and any extension thereof.", "Section 11.5", "Current text:", "11.5. Single Resource Allocation per Experiment", "ARIN will make one-off allocations only, on an annual basis to any applicant. Additional allocations to an organization already holding experimental activity resources relating to the specified activity outside the annual cycle will not be made unless justified by a subsequent complete application.", "It's important for the requesting organization to ensure they have sufficient resources requested as part of their initial application for the proposed experimental use.", "Proposed text:", "11.5. Single Resource Allocation per Experiment", "ARIN will make only one allocation per recognized experiment. An allocation may consist of multiple Internet Number Resources if required to conduct the recognized activity. Additional allocations to an organization already holding experimental activity resources will not be made under this policy unless justified by a subsequent complete application relating to a different experimental activity.", "Retire Section 11.6", "Section 11.7", "Current text:", "11.7. Resource Allocation Guidelines", "The Numbering Resources requested come from the global Internet Resource space, do not overlap currently assigned space, and are not from private or other non-routable Internet Resource space. The allocation size shall be consistent with the existing ARIN minimum allocation sizes, unless smaller allocations are intended to be explicitly part of the experiment. If an organization requires more resources than stipulated by the minimum allocation size in force at the time of its request, the request must clearly describe and justify why a larger allocation is required. All research allocations must be registered publicly in whois. Each research allocation will be designated as a research allocation with a comment indicating when the allocation will end.", "Proposed text:", "11.7. Resource Allocation Guidelines", "The Internet Number Resources requested come from the global Internet Number Resource space, shall not overlap any currently assigned space, and shall not be from private or other non-routable Internet Number Resource space. The allocation size shall be consistent with existing ARIN minimum allocation sizes, unless smaller allocations are explicitly required due to the nature of the experiment. If an organization requires more resources than stipulated by the minimum allocation size in force at the time of its request, the request must clearly describe and justify why a larger allocation is required. All research allocations must be registered publicly in ARIN’s directory services. Each research allocation will be designated as a research allocation with a comment indicating when the allocation will end.", "Section 11.8", "Current text:", "11.8. Commercial Use Prohibited", "If there is any evidence that the temporary resource is being used for commercial purposes, or is being used for any activities not documented in the original experiment description provided to ARIN, ARIN reserves the right to immediately withdraw the resource and reassign it to the free pool.", "Proposed text:", "11.8. Commercial Use Prohibited", "If there is any evidence that the temporary resource is being used for commercial purposes or is being used for any activities not documented in the original experiment description provided to ARIN, ARIN reserves the right to immediately withdraw the resource.", "Retire Section 11.9", "### Timetable for Implementation", "Immediate", "### Comments", "Due to the scope of this Draft Policy’s recommended edits, a tracked document is available at https://www.arin.net/participate/policy/drafts/pdf/NRPM-Section11-update-20230314.pdf ", "## Staff and Legal Review (13 March 2023)", "<a name="slr"></a>", "### Staff Understanding", "This Draft Policy makes substantial revisions to NRPM Section 11. Experimental Internet Resource Allocations. The suggested changes appear to accomplish the problem statement task of "A revision to transform Section 11 into a collection of policies for experimental allocations serves to make the Section more easily digested by the reader, and a more functional reference for customers and ARIN staff during experimental allocation requests."", "Previously, staff recommended adding "and"before the final criterion of any lists, removing "the"from "existing the ARIN minimum allocation sizes"in Section 11.7,"and clarifying the return language in 11.4. Staff also recommended sharing the revisions as a tracked document via the comments section. This has all been addressed in the current version. ", "Staff recommends the following additional revisions to the text:", "Section 11.4 Resource Allocation Term and Renewal", "Current Proposed Text - The resources allocated under this policy must be returned to ARIN at the earliest of: (1) the recognized experimental activity has ended; and (2) the end of the one-year period and any extension thereof.", "Recommendation - This text presents two scenarios and the occurrence of the earliest of those events requires the return of the resources; not the occurrence of both events. Therefore, it is recommended that "or" be used instead of "and." "The resources allocated under this policy must be returned to ARIN at the earliest of: (1) the recognized experimental activity has ended; and or (2) the end of the one-year period and any extension there of the available pool."", "Section 11.4 Resource Allocation Term and Renewal", "Current Proposed Text - The allocation can be renewed on application to ARIN prior to the expiry of the one-year period providing information as to why an extension is necessary for a successful experiment.", "Recommendation – For clarity, treat the phrase "prior to the expiry of the one-year period" as a parenthetical by adding commas: "The allocation can be renewed on application to ARIN, prior to the expiry of the one-year period, providing information as to why an extension is necessary for a successful experiment." Alternatively, the phrase could be moved to the beginning of the sentence.", "Section 11.7 Resource Allocation Guidelines.", "Current Proposed Text - The Internet Number Resources requested come from the global Internet Resource space, shall not overlap any currently assigned space, and shall not be from private or other non-routable Internet Number Resource space.", "Recommendation – For consistency, modify "space" in the same manner, such as Internet Number Resource space. "The Internet Number Resources requested come from the global Internet Number Resource space, shall not overlap any currently assigned space, and shall not be from private or other non-routable Internet Number Resource space."", "### Implementable as Written?", "Yes", "### Impact on ARIN Registry Operations and Services ", "None.", "### Legal Review ", "No material legal issue.", "### Implementation Timeframe Estimate", "Three months", "### Implementation Requirements", "- Staff training", "- Updates to public documentation", "- Updates to internal procedures and guidelines", "### Proposal/Draft Policy Text Assessed", "[23 February 2023](https://lists.arin.net/pipermail/arin-ppml/2023-February/036681.html)", "## History and Earlier Versions", "|Action|Date|", "|--- |--- |", "| [Proposal](/participate/policy/proposals/2022/ARIN_prop_316_orig/) | 15 June 2022 |", "| [Draft Policy](https://lists.arin.net/pipermail/arin-ppml/2022-July/036350.html) | 26 July 2022 |", "| [Revised](https://lists.arin.net/pipermail/arin-ppml/2022-September/036531.html) | 19 September 2022 |", "| [Revised](https://lists.arin.net/pipermail/arin-ppml/2022-October/036553.html) | 26 October 2022 |", "| [Revised](https://lists.arin.net/pipermail/arin-ppml/2023-February/036678.html) | 13 February 2023 |", "| [Recommended](https://lists.arin.net/pipermail/arin-ppml/2023-February/036681.html) | 23 February 2023 |", "| [Revised](https://lists.arin.net/pipermail/arin-ppml/2023-March/036682.html) | 15 March 2023 |", "| [Last Call](https://lists.arin.net/pipermail/arin-ppml/2023-April/036718.html) | 19 April 2023 | ", "| [Advanced to Board of Trustees](https://lists.arin.net/pipermail/arin-ppml/2023-May/036785.html) | 23 May 2023 |", "| [Adopted](https://lists.arin.net/pipermail/arin-ppml/2023-August/036925.html) | 18 July 2023 |", "## 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/)", "- [27 January 2023](/about/welcome/ac/meetings/2023_0127/)", "- [16 February 2023](/about/welcome/ac/meetings/2023_0216/)", "- [16 March 2023](/about/welcome/ac/meetings/2023_0316/)", "- [19 April 2023](/about/welcome/ac/meetings/2023_0419/)", "- [18 May 2023](/about/welcome/ac/meetings/2023_0518/)", "### Board of Trustees", "- [18 July 2023](/about/welcome/board/meetings/2023_0718/)", "### ARIN Public Policy Meetings", "- [ARIN 50](/participate/meetings/ARIN50/)", "- [ARIN 51](/participate/meetings/ARIN51/)"], "lastUpdated": "2018-07-02", "url": "https://www.arin.net/participate/policy/drafts/2022_8/" },{ "number": "ARIN-2022-5", "title": "Clean-up of NRPM Section 2.11", "status": "Implemented", "recommended": true, "shepherds": ["Alison Wood", "Gus Reese"], "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 Section 2.11. The focus of this proposal is to ensure that the intended meaning of the text is clear.\n","policyStatement": "\nChange the text "A community network is deployed, operated and governed by its users" to "A community network is one that is deployed, operated and governed by its users" in the first line and change the text "to the user community it services" from "to the community it services" in the second line.\n","implementationTime": "Immediate","fullText": ["## Current Text (21 March 2023)", "### 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-2022-5 conforms to the principles of the ARIN Policy Development Process. This policy, if adopted, will add clarity to the text in Section 2.11 of the NRPM regarding community networks. It is fair, impartial, technically sound and has received support from the community.", "### 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 Section 2.11. The focus of this proposal is to ensure that the intended meaning of the text is clear.", "### Policy Statement", "Change the text "A community network is deployed, operated and governed by its users" to "A community network is one that is deployed, operated and governed by its users" in the first line and change the text "to the user community it services" from "to the community it services" in the second line.", "### Timetable for implementation", "Immediate", "### Comments", "This proposal is intended to replace Prop-305 in part. Although the proposal was drafted in the course of an editorial review of Section 2.11, some of the changes proposed may not be considered purely editorial in nature and so this proposal is not being presented as strictly editorial.", "## Staff and Legal Review (10 February 2023)", "<a name="slr"></a>", "### Staff Understanding", "This Draft Policy makes minor clarifications to NRPM Section 2.11 Community Network. This update offers some grammatical clarity with no substantive impact on policy. ", "The intent with the second proposed edit appears to be to insert "user" in front of "community." Staff recommends this be confirmed with the Shepherds by changing:", ""to the user community it services" to "to the community it services"", "to", ""to the user community it services" from "to the community it services"", "The remaining 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", "Three 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/036347.html)", "## History and Earlier Versions", "|Action|Date|", "|--- |--- |", "| [Proposal](/participate/policy/proposals/2022/ARIN_prop_312_orig/) | 14 June 2022 |", "| [Draft Policy](https://lists.arin.net/pipermail/arin-ppml/2022-July/036347.html) | 26 July 2022 |", "| [Revised](https://lists.arin.net/pipermail/arin-ppml/2023-March/036683.html) | 15 March 2023 |", "| [Recommended Draft Policy](https://lists.arin.net/pipermail/arin-ppml/2023-March/036689.html) | 21 March 2023 |", "| [Last Call](https://lists.arin.net/pipermail/arin-ppml/2023-April/036717.html) | 19 April 2023 |", "| [Advanced to Board of Trustees](https://lists.arin.net/pipermail/arin-ppml/2023-May/036785.html) | 23 May 2023 |", "| [Adopted](https://lists.arin.net/pipermail/arin-ppml/2023-August/036925.html) | 18 July 2023 |", "## 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/)", "- [27 January 2023](/about/welcome/ac/meetings/2023_0127/)", "- [16 February 2023](/about/welcome/ac/meetings/2023_0216/)", "- [16 March 2023](/about/welcome/ac/meetings/2023_0316/)", "- [19 April 2023](/about/welcome/ac/meetings/2023_0419/)", "- [18 May 2023](/about/welcome/ac/meetings/2023_0518/)", "### Board of Trustees", "- [18 July 2023](/about/welcome/board/meetings/2023_0718/)", "### ARIN Public Policy Meetings", "- [ARIN 50](/participate/meetings/ARIN50/)", "- [ARIN 51](/participate/meetings/ARIN51/)"], "lastUpdated": "2018-07-02", "url": "https://www.arin.net/participate/policy/drafts/2022_5/" },{ "number": "ARIN-2022-4", "title": "Clean-up of NRPM Sections 2.1 and 2.2", "status": "Implemented", "recommended": true, "shepherds": ["Alison Wood", "Amy Potter"], "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.1 and 2.2. The focus of this proposal is to increase the consistency of terminology employed in the NRPM.\n","policyStatement": "\nIn Section 2.1, change the text "IP address space" to "Internet number resources", and in Section 2.2, change the text "address space" to "number resources" to reflect all of the types of Internet number resources administered by the types of entities defined in those sections.\n","implementationTime": "Immediate","fullText": ["## Current Text (21 March 2023)", "### AC Assessment of Conformance with the [Principles of Internet Number Resource Policy](/participate/policy/pdp/#4-principles-of-internet-number-resource-policy)", "Based on community feedback and AC discussion, we motion to move ARIN-2022-4: Clean-up of NRPM Sections 2.1 and 2.2 to Recommended Draft, with the following change in text: In Section 2.1, change the text "IP address space" to "Internet number resources", and in Section 2.2, change the text "address space" to "number resources". This Draft Policy is fair, impartial, and technically sound and will clarify the intent of the text in sections 2.1 and 2.2.", "### 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.1 and 2.2. The focus of this proposal is to increase the consistency of terminology employed in the NRPM.", "### Policy Statement", "In Section 2.1, change the text "IP address space" to "Internet number resources", and in Section 2.2, change the text "address space" to "number resources" to reflect all of the types of Internet number resources administered by the types of entities defined in those sections.", "### Timetable for implementation", "Immediate", "### Comments", "This proposal is intended to replace Prop-305 in part. Although the proposal was drafted in the course of an editorial review of Sections 2.1 and 2.2, some of the changes proposed may not be considered purely editorial in nature and so this proposal is not being presented as strictly editorial.", "## Staff and Legal Review (14 October 2022)", "<a name="slr"></a>", "### Staff Understanding", "ARIN-edit-2022-4 makes minor editorial changes to NRPM Sections 2.1 and 2.2.", "The policy text is clear and understandable, but does not appear editorial in nature, as it alters multiple definitions in non-grammatical ways.", "### Implementable as Written?", "Yes", "### Impact on ARIN Registry Operations and Services", "None.", "### Legal Review", "No material legal issue in concept; however, I do not believe this is a purely editorial update and is substantive as it expands the terminology.", "### 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/036461.html)", "## History and Earlier Versions", "|Action|Date|", "|--- |--- |", "| [Proposal](/participate/policy/proposals/2022/ARIN_prop_310_orig/) | 14 June 2022 |", "| [Draft Policy](https://lists.arin.net/pipermail/arin-ppml/2022-July/036346.html) | 26 July 2022 |", "| [Classified as Editorial Change](https://lists.arin.net/pipermail/arin-ppml/2022-August/036461.html) | 23 August 2022 |", "| [Reclassified as Draft Policy](https://lists.arin.net/pipermail/arin-ppml/2022-October/036551.html) | 21 October 2022 |", "| [Recommended Draft Policy](https://lists.arin.net/pipermail/arin-ppml/2023-March/036688.html) | 21 March 2023 |", "| [Last Call](https://lists.arin.net/pipermail/arin-ppml/2023-April/036716.html) | 19 April 2023 | ", "| [Advanced to Board of Trustees](https://lists.arin.net/pipermail/arin-ppml/2023-May/036785.html) | 23 May 2023 |", "| [Adopted](https://lists.arin.net/pipermail/arin-ppml/2023-August/036925.html) | 18 July 2023 |", "## 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/)", "- [27 January 2023](/about/welcome/ac/meetings/2023_0127/)", "- [16 February 2023](/about/welcome/ac/meetings/2023_0216/)", "- [16 March 2023](/about/welcome/ac/meetings/2023_0316/)", "- [19 April 2023](/about/welcome/ac/meetings/2023_0419/)", "- [18 May 2023](/about/welcome/ac/meetings/2023_0518/)", "### Board of Trustees ", "- [18 July 2023](/about/welcome/board/meetings/2023_0718/) ", "### ARIN Public Policy Meetings", "- [ARIN 51](/participate/meetings/ARIN51/)"], "lastUpdated": "2018-07-02", "url": "https://www.arin.net/participate/policy/drafts/2022_4/" },{ "number": "ARIN-2022-3", "title": "Remove Officer Attestation Requirement for 8.5.5", "status": "Implemented", "recommended": true, "shepherds": ["Matthew Wilder", "Gerry George"], "problemStatement": "\nRequiring an officer attestation requires unnecessary resources and increases the time to complete an IPv4 transfer.\n","policyStatement": "Policy statement\n8.5.5. Block Size\nOrganizations may qualify for the transfer of a larger initial block, or an additional block, by providing documentation to ARIN which details the use of at least 50% of the requested IPv4 block size within 24 months.\nRemoving "An officer of the organization shall attest to the documentation provided to ARIN."\n","implementationTime": "Immediate","fullText": ["## Current Text (21 June 2022)", "### AC Assessment of Conformance with the [Principles of Internet Number Resource Policy](/participate/policy/pdp/#4-principles-of-internet-number-resource-policy)", "Draft Policy 2022-3 conforms with the principles of the ARIN Policy Development Process. It is fair, impartial, and technically sound. This policy, if adopted, will remove the requirement of officer attestation from specified transfer recipients. The policy has received support from the community.", "### Problem Statement", "Requiring an officer attestation requires unnecessary resources and increases the time to complete an IPv4 transfer.", "### Policy statement", "8.5.5. Block Size", "Organizations may qualify for the transfer of a larger initial block, or an additional block, by providing documentation to ARIN which details the use of at least 50% of the requested IPv4 block size within 24 months.", "Removing "An officer of the organization shall attest to the documentation provided to ARIN."", "### Timetable for implementation", "Immediate", "### Comments", "* This is the only remaining mention outside Section 9 (which makes good use of the restrictions it has).", "* Due to the cost of IPv4 at this time it is safe to say that someone of authority is aware of this transaction without having them provide an attestation.", "## Staff and Legal Review (15 August 2022)", "<a name="slr"></a>", "### Staff Understanding", "ARIN-2022-3 would remove the officer attestation requirement for organizations qualifying for initial transfers larger than a /24 (ARIN's present minimum IPv4 transfer size) or additional transfers. For reference, this requirement became part of the NRPM Section 8 in February 2017 (/vault/participate/policy/archive/nrpm_20170221.pdf) and is not currently in IP address or ASN allocation policy. The requirement was removed from operational practice for IP address and ASN allocation requests via [Consultation 2021.04 Retiring the Officer Attestation Requirement](https://www.arin.net/participate/community/acsp/consultations/2021/2021-4/).", "The policy text is clear and understandable.", "### Implementable as Written?", "Yes", "### Impact on ARIN Registry Operations and Services ", "Minor updates within ARIN Online will need to be made to remove attestation language.", "### Legal Review ", "No material legal issue. Removal of the officer attestation would not materially impact ARIN's ability to pursue cases of fraud.", "### Implementation Timeframe Estimate", "Six months", "### Implementation Requirements", "- Updates to ARIN Online", "- Staff training", "- Updates to public documentation", "- Updates to internal procedures and guidelines", "### Proposal/Draft Policy Text Assessed", "[21 June 2022](https://lists.arin.net/pipermail/arin-ppml/2022-June/036118.html) ", "## History and Earlier Versions", "|Action|Date|", "|--- |--- |", "| [Proposal](/participate/policy/proposals/2022/ARIN_prop_309_orig/) | 6 June 2022 |", "| [Draft Policy](https://lists.arin.net/pipermail/arin-ppml/2022-June/036118.html) | 21 June 2022 |", "| [Recommended](https://lists.arin.net/pipermail/arin-ppml/2022-October/036550.html) | 26 October 2022 |", "| [Last Call](https://lists.arin.net/pipermail/arin-ppml/2023-April/036715.html) | 19 April 2023 |", "| [Advanced to Board of Trustees](https://lists.arin.net/pipermail/arin-ppml/2023-May/036785.html) | 23 May 2023 |", "| [Adopted](https://lists.arin.net/pipermail/arin-ppml/2023-August/036925.html) | 18 July 2023 |", "## Related Meetings", "### Advisory Council", "- [16 June 2022](/about/welcome/ac/meetings/2022_0616/)", "- [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/)", "- [27 January 2023](/about/welcome/ac/meetings/2023_0127/)", "- [16 February 2023](/about/welcome/ac/meetings/2023_0216/)", "- [16 March 2023](/about/welcome/ac/meetings/2023_0316/)", "- [19 April 2023](/about/welcome/ac/meetings/2023_0419/)", "- [18 May 2023](/about/welcome/ac/meetings/2023_0518/)", "### Board of Trustees", "- [18 July 2023](/about/welcome/board/meetings/2023_0718/)", "### ARIN Public Policy Meetings", "- [ARIN 50](/participate/meetings/ARIN50/)", "- [ARIN 51](/participate/meetings/ARIN51/)"], "lastUpdated": "2018-07-02", "url": "https://www.arin.net/participate/policy/drafts/2022_3/" },{ "number": "ARIN-2022-2", "title": "Remove Barrier to BGP Uptake in ASN Policy", "status": "Implemented", "recommended": true, "shepherds": ["Chris Tacit", "Kendrick Knowles"], "problemStatement": "\nThe current requirements for getting an ASN have resulted in confusion particularly for new entrants, who have their hands more than full with the mechanics of getting BGP up and running.The availability of 32 bit ASNs provides an opportunity for the removal of unnecessary constraints and processes for the allocation of ASNs.\nARIN does not provide guidance to use RFC1918 space if possible and likewise ARIN should not require the use of private ASNs in preference to public ASNs.\nFurther Technical Rationale\nFour octet (32 bit) ASNs were defined in May 2007 in RFC 4893. It has taken several years for routing equipment in general use to catch up, but today 32 bit ASNs are generally accepted and it is rare that an organization which has been issued a 32 bit ASN comes back to ARIN and says they need a 16 bit ASN instead.\nThe austerity measure of requiring extensive documentation to get an ASN is left over from the days of 16 bit ASNs (total space 65000). It is no longer appropriate and we should align our conservation requirements with those found in other 32-bit spaces (total space four billion). Consider:\n- A /32 of IPv6 space is the default allocation and will be assigned to any ISP that requests it.\n- Temporary assignment of a /32 of IPv4 space can be acquired on most residential ISPs by issuing a DHCP request.\nWe propose making issuance of the first 32 bit ASN for any ORGID (or each site for organizations that have number resources under multiple discrete networks policy) be pro-forma upon request. If an org’s technical people think they need a public ASN, they probably do!\n","policyStatement": "\nReplace the entirety of Section 5, which currently reads:\nThere are a limited number of available Autonomous System Numbers (AS Numbers), therefore, it is important to determine which sites require unique ASNs and which do not. If a unique ASN is not required for a given network design, one or more of the ASN reserved for private use should be utilized. Those numbers are: 64512 through 65534 and 4200000000 through 4294967294 inclusive.\nIn order to be assigned an ASN, each requesting organization must provide ARIN with verification that it requires a unique routing policy, such as a plan:\n- To originate announcement of IP Number Resources via an accepted protocol (such as Border Gateway Protocol) from an ASN different than that of its upstream provider;\n- To multihome a site with one or more Autonomous Systems; or\n- To use an ASN to interconnect with other Autonomous Systems.\nASNs are issued based on current need, as set out in this section 5.\nWith the following new Section 5:\nAny organization may be issued a single Autonomous System Number (ASN) upon request. Organizations that have space issued under Multiple Discrete Networks policy may be issued one ASN per discrete network upon request.\nAdditional ASN requests should include proof of the requestor's need for a unique routing policy, or other technical justification for the need for more than one ASN.\n","implementationTime": "Any","fullText": ["## Current Text (13 September 2022)", "### AC Assessment of Conformance with the [Principles of Internet Number Resource Policy](/participate/policy/pdp/#4-principles-of-internet-number-resource-policy)", "This Draft Policy is fair, impartial, and technically sound. ARIN-2022-2 would rewrite ARIN's Autonomous System Numbers policy, reducing its overall size and specifying single-ASN issuance as the default action. The Draft Policy deals with issuance and manually vetted request documentation requirements, which have no significant registry impact as a result of implementation.", "### Problem Statement", "The current requirements for getting an ASN have resulted in confusion particularly for new entrants, who have their hands more than full with the mechanics of getting BGP up and running.The availability of 32 bit ASNs provides an opportunity for the removal of unnecessary constraints and processes for the allocation of ASNs.", "ARIN does not provide guidance to use RFC1918 space if possible and likewise ARIN should not require the use of private ASNs in preference to public ASNs.", "Further Technical Rationale", "Four octet (32 bit) ASNs were defined in May 2007 in RFC 4893. It has taken several years for routing equipment in general use to catch up, but today 32 bit ASNs are generally accepted and it is rare that an organization which has been issued a 32 bit ASN comes back to ARIN and says they need a 16 bit ASN instead.", "The austerity measure of requiring extensive documentation to get an ASN is left over from the days of 16 bit ASNs (total space 65000). It is no longer appropriate and we should align our conservation requirements with those found in other 32-bit spaces (total space four billion). Consider:", "- A /32 of IPv6 space is the default allocation and will be assigned to any ISP that requests it.", "- Temporary assignment of a /32 of IPv4 space can be acquired on most residential ISPs by issuing a DHCP request.", "We propose making issuance of the first 32 bit ASN for any ORGID (or each site for organizations that have number resources under multiple discrete networks policy) be pro-forma upon request. If an org’s technical people think they need a public ASN, they probably do!", "### Policy Statement", "Replace the entirety of Section 5, which currently reads:", "There are a limited number of available Autonomous System Numbers (AS Numbers), therefore, it is important to determine which sites require unique ASNs and which do not. If a unique ASN is not required for a given network design, one or more of the ASN reserved for private use should be utilized. Those numbers are: 64512 through 65534 and 4200000000 through 4294967294 inclusive.", "In order to be assigned an ASN, each requesting organization must provide ARIN with verification that it requires a unique routing policy, such as a plan:", "- To originate announcement of IP Number Resources via an accepted protocol (such as Border Gateway Protocol) from an ASN different than that of its upstream provider;", "- To multihome a site with one or more Autonomous Systems; or", "- To use an ASN to interconnect with other Autonomous Systems.", "ASNs are issued based on current need, as set out in this section 5.", "With the following new Section 5:", "Any organization may be issued a single Autonomous System Number (ASN) upon request. Organizations that have space issued under Multiple Discrete Networks policy may be issued one ASN per discrete network upon request.", "Additional ASN requests should include proof of the requestor's need for a unique routing policy, or other technical justification for the need for more than one ASN.", "### Timetable for Implementation", "Any", "## Staff and Legal Review (16 September 2022)", "<a name="slr"></a>", "### Staff Understanding", "ARIN-2022-2 would rewrite ARIN's Autonomous System Numbers policy, reducing its overall size and specifying single-ASN issuance as the default action.", "The text is clear and understandable.", "### Implementable as Written?", "Yes", "### Impact on ARIN Registry Operations and Services ", "None. The Draft Policy deals with issuance and manually vetted request documentation requirements, which have no significant registry impacts as a result of implementation.", "### Legal Review ", "No material legal issue.", "### Implementation Timeframe Estimate", "Three months", "### Implementation Requirements", "- Staff training", "- Updates to public documentation", "- Updates to internal procedures and guidelines", "### Proposal/Draft Policy Text Assessed", "[13 September 2022](https://lists.arin.net/pipermail/arin-ppml/2022-May/036060.html)", "## History and Earlier Versions", "|Action|Date|", "|--- |--- |", "| [Proposal](/participate/policy/proposals/2022/ARIN_prop_307_orig/) | 11 March 2022 |", "| [Draft Policy](https://lists.arin.net/pipermail/arin-ppml/2022-May/036060.html) | 2 May 2022 |", "| [Revised](https://lists.arin.net/pipermail/arin-ppml/2022-September/036513.html) | 13 September 2022 |", "| [Recommended](https://lists.arin.net/pipermail/arin-ppml/2022-October/036549.html) | 26 October 2022 |", "| [Last Call](https://lists.arin.net/pipermail/arin-ppml/2023-April/036714.html) | 19 April 2023 |", "| [Advanced to Board of Trustees](https://lists.arin.net/pipermail/arin-ppml/2023-May/036785.html) | 23 May 2023 |", "| [Adopted](https://lists.arin.net/pipermail/arin-ppml/2023-August/036925.html) | 18 July 2023 |", "## Related Meetings", "### Advisory Council", "- [16 December 2021](/about/welcome/ac/meetings/2021_1216/)", "- [20 January 2022](/about/welcome/ac/meetings/2022_0120/)", "- [25 February 2022](/about/welcome/ac/meetings/2022_0225/)", "- [17 March 2022](/about/welcome/ac/meetings/2022_0317/)", "- [27 April 2022](/about/welcome/ac/meetings/2022_0427/) ", "- [19 May 2022](/about/welcome/ac/meetings/2022_0519/) ", "- [16 June 2022](/about/welcome/ac/meetings/2022_0616/)", "- [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/)", "- [27 January 2023](/about/welcome/ac/meetings/2023_0127/)", "- [16 February 2023](/about/welcome/ac/meetings/2023_0216/)", "- [16 March 2023](/about/welcome/ac/meetings/2023_0316/)", "- [19 April 2023](/about/welcome/ac/meetings/2023_0419/)", "- [18 May 2023](/about/welcome/ac/meetings/2023_0518/)", "### Board of Trustees", "- [18 July 2023](/about/welcome/board/meetings/2023_0718/)", "### ARIN Public Policy Meetings", "- [ARIN 48](/participate/meetings/ARIN48/)", "- [ARIN 49](/participate/meetings/ARIN49/)", "- [ARIN 50](/participate/meetings/ARIN50/)", "- [ARIN 51](/participate/meetings/ARIN51/)"], "lastUpdated": "2018-07-02", "url": "https://www.arin.net/participate/policy/drafts/2022_2/" },{ "number": "ARIN-2022-11", "title": "Clean-up of NRPM – Introduction of Section 2.17", "status": "Implemented", "recommended": true, "shepherds": ["Alison Wood", "Chris Woodfield"], "problemStatement": "\nThe term Internet Number Resources is referenced in several sections of the NRPM but is not defined. \n","policyStatement": "\n"Internet number resources are unique identifiers within the Internet Numbers Registry System [as described in IETF RFC 7020] and this includes ranges (or "blocks") of contiguous Internet Protocol ("IP") addresses and Autonomous System Numbers ("ASNs")."\n","implementationTime": "Immediate","fullText": ["## Current Text (21 March 2023) ", "### AC Assessment of Conformance with the [Principles of Internet Number Resource Policy](/participate/policy/pdp/#4-principles-of-internet-number-resource-policy)", "Based on community feedback and AC discussion we motion to move ARIN-2022-11: Clean-up of NRPM – Introduction of Section 2.17 to Recommended Draft, with the following definition: "Internet number resources are unique identifiers within the Internet Numbers Registry System [as described in IETF RFC 7020] and this includes ranges (or "blocks") of contiguous Internet Protocol ("IP") addresses and Autonomous System Numbers ("ASNs")." This Draft Policy is fair, impartial, and technically sound and will add clarity to the term "Internet number resources".", "### Problem Statement", "The term Internet Number Resources is referenced in several sections of the NRPM but is not defined. ", "### Policy Statement", ""Internet number resources are unique identifiers within the Internet Numbers Registry System [as described in IETF RFC 7020] and this includes ranges (or "blocks") of contiguous Internet Protocol ("IP") addresses and Autonomous System Numbers ("ASNs")."", "### Timetable for Implementation", "Immediate", "### Comments", "Although this proposal was drafted in the course of an editorial review of Section 2 of the NRPM, the addition of a new definition may not be considered purely editorial in nature and so this proposal is not being presented as strictly editorial.", "## Staff and Legal Review (10 February 2023)", "<a name="slr"></a>", "### Staff Understanding", "This Draft Policy inserts a definition of Internet Number Resources into NRPM Section 2, with the intent of broadly applying said definition across all ARIN Internet Number Resource Policy. Staff strongly recommends revising the definition per IETF RFC 7020 as follows:", ""Internet number resources are unique identifiers within the Internet Numbers Registry System [as described in IETF RFC 7020] and this includes ranges (or "blocks") of contiguous Internet Protocol ("IP") addresses and Autonomous System Numbers ("ASNs")."", "### Implementable as Written?", "Yes", "### Impact on ARIN Registry Operations and Services ", "None.", "### Legal Review ", "No material legal issue if revised per staff comments.", "### Implementation Timeframe Estimate", "Three months", "### Implementation Requirements", "- Staff training", "- Updates to public documentation", "- Updates to internal procedures and guidelines", "### Proposal/Draft Policy Text Assessed", "[30 January 2023](https://lists.arin.net/pipermail/arin-ppml/2023-January/036668.html)", "## History and Earlier Versions", "|Action|Date|", "|--- |--- |", "| [Proposal](/participate/policy/proposals/2022/ARIN_prop_314_orig/) | 15 June 2022 |", "| [Draft Policy](https://lists.arin.net/pipermail/arin-ppml/2022-August/036464.html) | 23 August 2022 |", "| [Revised](https://lists.arin.net/pipermail/arin-ppml/2022-September/036536.html) | 28 September 2022 |", "| [Revised](https://lists.arin.net/pipermail/arin-ppml/2023-January/036668.html) | 30 January 2023 |", "| [Recommended Draft Policy](https://lists.arin.net/pipermail/arin-ppml/2023-March/036690.html) | 21 March 2023 |", "| [Last Call](https://lists.arin.net/pipermail/arin-ppml/2023-April/036719.html) | 19 April 2023 |", "| [Advanced to Board of Trustees](https://lists.arin.net/pipermail/arin-ppml/2023-June/036847.html) | 20 June 2023 |", "| [Adopted](https://lists.arin.net/pipermail/arin-ppml/2023-August/036925.html) | 18 July 2023 |", "## 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/)", "- [27 January 2023](/about/welcome/ac/meetings/2023_0127/)", "- [16 February 2023](/about/welcome/ac/meetings/2023_0216/)", "- [16 March 2023](/about/welcome/ac/meetings/2023_0316/)", "- [19 April 2023](/about/welcome/ac/meetings/2023_0419/)", "- [18 May 2023](/about/welcome/ac/meetings/2023_0518/)", "- [15 June 2023](/about/welcome/ac/meetings/2023_0615/)", "### Board of Trustees", "- [18 July 2023](/about/welcome/board/meetings/2023_0718/)", "### ARIN Public Policy Meetings", "- [ARIN 50](/participate/meetings/ARIN50/)", "- [ARIN 51](/participate/meetings/ARIN51/)"], "lastUpdated": "2018-07-02", "url": "https://www.arin.net/participate/policy/drafts/2022_11/" },{ "number": "ARIN-2022-1", "title": "MDN Clarification for Qualification", "status": "Implemented", "recommended": true, "shepherds": ["Chris Woodfield", "Brian Jones"], "problemStatement": "\nThe requirements for transfers involving companies operating multiple discrete networks under section 8.5 of the NRPM are unclear and need clarification.\n","policyStatement": "Policy statement\nReplace the first paragraph of Section 8.5.7 with the following:\nOrganizations may qualify for additional IPv4 address blocks by demonstrating 80% utilization of their currently allocated space. In organizations operating multiple discrete networks, each discrete network may be assessed individually for the 80% utilization threshold. To qualify under this policy, the organization must provide justification that each network is discrete, per the criteria described in section 4.5. Each discrete network must meet the projection requirements in section 8.5.5, and each discrete network for which IP addresses are requested must meet the utilization requirements in section 8.5.6. Organizations may receive one or more transfers up to the total size of their current ARIN IPv4 address holdings, up to a maximum size of /16.\n","implementationTime": "Any","fullText": ["## Current Text (2 May 2022)", "### 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-2022-1 conforms to the principles of the ARIN Policy Development Process as follows:", "- By providing greater clarity concerning transfer requirements for organizations operating Multiple Discrete Networks (MDNs), it promotes fair and impartial number resource administration;", "- It is technically sound because it clarifies the technical requirements for receiving IPv4 resources via transfer if one is an MDN operator; and", "- Community support has been demonstrated throughout the process associated with its development.", "### Problem Statement", "The requirements for transfers involving companies operating multiple discrete networks under section 8.5 of the NRPM are unclear and need clarification.", "### Policy statement", "Replace the first paragraph of Section 8.5.7 with the following:", "Organizations may qualify for additional IPv4 address blocks by demonstrating 80% utilization of their currently allocated space. In organizations operating multiple discrete networks, each discrete network may be assessed individually for the 80% utilization threshold. To qualify under this policy, the organization must provide justification that each network is discrete, per the criteria described in section 4.5. Each discrete network must meet the projection requirements in section 8.5.5, and each discrete network for which IP addresses are requested must meet the utilization requirements in section 8.5.6. Organizations may receive one or more transfers up to the total size of their current ARIN IPv4 address holdings, up to a maximum size of /16.", "### Timetable for Implementation", "Any", "## Staff and Legal Review (21 March 2022)", "<a name="slr"></a>", "### Staff Understanding", "This Draft Policy expands Section 8.5.7: Alternative Additional IPv4 Address Block Criteria to clarify qualification criteria for organizations with Multiple Discrete Networks, specifying that each network must be assessed individually for utilization thresholds. The text codifies current practice, and 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", "Three months", "### Implementation Requirements", "- Staff training", "- Updates to public documentation", "- Updates to internal procedures and guidelines", "### Proposal/Draft Policy Text Assessed", "[17 March 2022](https://lists.arin.net/pipermail/arin-ppml/2022-March/035939.html)", "## History and Earlier Versions", "|Action|Date|", "|--- |--- |", "| [Proposal](/participate/policy/proposals/2021/ARIN_prop_306_orig/) | 9 December 2021 |", "| [Draft Policy](https://lists.arin.net/pipermail/arin-ppml/2022-March/035889.html) | 2 March 2022 |", "| [Revised](https://lists.arin.net/pipermail/arin-ppml/2022-March/035939.html) | 17 March 2022 |", "| [Recommended](https://lists.arin.net/pipermail/arin-ppml/2022-May/036059.html) | 2 May 2022 |", "| [Last Call](https://lists.arin.net/pipermail/arin-ppml/2022-October/036547.html) | 26 October 2022 |", "| [Advanced to Board of Trustees](https://lists.arin.net/pipermail/arin-ppml/2022-November/036626.html) | 17 November 2022 |", "| [Adopted](/about/welcome/board/meetings/2022_1219/) | 19 December 2022 |", "| Implemented | 22 March 2022 |", "## Related Meetings", "### Advisory Council", "- [16 December 2021](/about/welcome/ac/meetings/2021_1216/)", "- [20 January 2022](/about/welcome/ac/meetings/2022_0120/)", "- [25 February 2022](/about/welcome/ac/meetings/2022_0225/)", "- [17 March 2022](/about/welcome/ac/meetings/2022_0317/)", "- [27 April 2022](/about/welcome/ac/meetings/2022_0427/) ", "- [19 May 2022](/about/welcome/ac/meetings/2022_0519/) ", "- [16 June 2022](/about/welcome/ac/meetings/2022_0616/)", "- [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/)", "### Board of Trustees", "- [19 December 2022](/about/welcome/board/meetings/2022_1219/)", "### ARIN Public Policy Meetings", "- [ARIN 48](/participate/meetings/ARIN48/)", "- [ARIN 49](/participate/meetings/ARIN49/)", "- [ARIN 50](/participate/meetings/ARIN50/)"], "lastUpdated": "2018-07-02", "url": "https://www.arin.net/participate/policy/drafts/2022_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/" },{ "number": "ARIN-2022-9", "title": "Leasing Not Intended", "status": "Abandoned", "recommended": false, "shepherds": ["Joe Provo", "Brian Jones"], "problemStatement": "\n"IPv6 Policy (section 6.4.1.) explicitly mention that address space is not a property. This is also stated in the RSA (section 7.) for all the Internet Number Resources.\nHowever, with the spirit of the IPv4 allocation policies being the same, there is not an equivalent text for IPv4, neither for ASNs.\nFurther to that, policies for IPv4 and IPv6 allocations, clearly state that allocations are based on justified need and not solely on a predicted customer base. Similar text can be found in the section related to Transfers (8.1).\nConsequently, resources not only aren’t a property, but also, aren’t allocated for leasing purposes, only for justified need of the resource holder and its directly connected customers.\nTherefore, and so that there are no doubts about it, it should be made explicit in the NRPM that the Internet Resources should not be leased "per se", but only as part of a direct connectivity service. At the same time, section 6.4.1. should be moved to the top of the NRPM (possibly to section 1. "Principles and Goals of the American Registry for Internet Numbers (ARIN)"."\n","policyStatement": "\nActual Text (to be replaced by New Text):\n6.4.1. Address Space Not to be Considered Property\nIt is contrary to the goals of this document and is not in the interests of the Internet community as a whole for address space to be considered freehold property.\nThe policies in this document are based upon the understanding that globally-unique IPv6 unicast address space is allocated/assigned for use rather than owned.\nNew Text\n1.5. Internet Number Resources Not to be Considered Property\nIt is contrary to the goals of this document and is not in the interests of the Internet community as a whole for address space to be considered freehold property.\nThe policies in this document are based upon the understanding that Internet Number Resources are allocated/assigned for use rather than owned.\nARIN allocate and assign Internet resources in a delegation scheme, with an annual validity, renewable as long as the requirements specified by the policies in force at the time of renewal are met, and especially the justification of the need.\nTherefore, the resources can’t be considered property.\nThe justification of the need, generically in the case of addresses, implies their need to directly connect customers. Therefore, the leasing of addresses is not considered acceptable, nor does it justify the need, if they are not part of a set of services based, at least, on direct connectivity.\nEven in cases of networks not connected to the Internet, the leasing of addresses is not admissible, since said sites can request direct assignments from ARIN and even in the case of IPv4, use private addresses or arrange transfers.\n","implementationTime": "Immediate","fullText": ["## Current Text (23 August 2022)", "### Problem Statement", ""IPv6 Policy (section 6.4.1.) explicitly mention that address space is not a property. This is also stated in the RSA (section 7.) for all the Internet Number Resources.", "However, with the spirit of the IPv4 allocation policies being the same, there is not an equivalent text for IPv4, neither for ASNs.", "Further to that, policies for IPv4 and IPv6 allocations, clearly state that allocations are based on justified need and not solely on a predicted customer base. Similar text can be found in the section related to Transfers (8.1).", "Consequently, resources not only aren’t a property, but also, aren’t allocated for leasing purposes, only for justified need of the resource holder and its directly connected customers.", "Therefore, and so that there are no doubts about it, it should be made explicit in the NRPM that the Internet Resources should not be leased "per se", but only as part of a direct connectivity service. At the same time, section 6.4.1. should be moved to the top of the NRPM (possibly to section 1. "Principles and Goals of the American Registry for Internet Numbers (ARIN)"."", "### Policy Statement", "Actual Text (to be replaced by New Text):", "6.4.1. Address Space Not to be Considered Property", "It is contrary to the goals of this document and is not in the interests of the Internet community as a whole for address space to be considered freehold property.", "The policies in this document are based upon the understanding that globally-unique IPv6 unicast address space is allocated/assigned for use rather than owned.", "New Text", "1.5. Internet Number Resources Not to be Considered Property", "It is contrary to the goals of this document and is not in the interests of the Internet community as a whole for address space to be considered freehold property.", "The policies in this document are based upon the understanding that Internet Number Resources are allocated/assigned for use rather than owned.", "ARIN allocate and assign Internet resources in a delegation scheme, with an annual validity, renewable as long as the requirements specified by the policies in force at the time of renewal are met, and especially the justification of the need.", "Therefore, the resources can’t be considered property.", "The justification of the need, generically in the case of addresses, implies their need to directly connect customers. Therefore, the leasing of addresses is not considered acceptable, nor does it justify the need, if they are not part of a set of services based, at least, on direct connectivity.", "Even in cases of networks not connected to the Internet, the leasing of addresses is not admissible, since said sites can request direct assignments from ARIN and even in the case of IPv4, use private addresses or arrange transfers.", "### Timetable for Implementation", "Immediate", "### Situation in other Regions", "In other RIRs, the leasing of addresses is not authorized either and since it is not explicit in their policy manuals either, this proposal will be presented as well.", "Nothing is currently mentioned in RIPE about this and it is not acceptable as a justification of the need. In AFRINIC, APNIC and LACNIC, the staff has confirmed that address leasing is not considered as valid for the justification.", "## History and Earlier Versions", "|Action|Date|", "|--- |--- |", "| [Proposal](/participate/policy/proposals/2022/ARIN_prop_308_orig/) | 28 March 2022 |", "| [Remanded](https://lists.arin.net/pipermail/arin-ppml/2022-June/036117.html) | 21 June 2022 | ", "| [Resubmitted](https://www.arin.net/participate/policy/proposals/2022/ARIN_prop_308_v2/) | 20 July 2022 | ", "| [Draft Policy](https://lists.arin.net/pipermail/arin-ppml/2022-August/036462.html) | 23 August 2022 |", "| [Abandoned](https://lists.arin.net/pipermail/arin-ppml/2022-October/036545.html) | 26 October 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", "- [ARIN 50](/participate/meetings/ARIN50/)"], "lastUpdated": "2018-07-02", "url": "https://www.arin.net/participate/policy/drafts/2022_9/" },{ "number": "ARIN-2022-13", "title": "Clean-up of NRPM Section 2.10", "status": "Abandoned", "recommended": false, "shepherds": ["Chris Woodfield", "Alicia Trotman"], "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 Section 2.10. The focus of this proposal is to both clarify and simplify the wording of the section.\n","policyStatement": "\nReplace the existing text: "The term End Site shall mean a single structure or service delivery address, or, in the case of a multi-tenant structure, a single tenant within said structure (a single customer location)."\nWith the new text: "An End Site is the smallest subnet in a network requiring IPv6 address space."\n","implementationTime": "Immediate","fullText": ["## Current Text (17 November 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 Section 2.10. The focus of this proposal is to both clarify and simplify the wording of the section.", "### Policy Statement", "Replace the existing text: "The term End Site shall mean a single structure or service delivery address, or, in the case of a multi-tenant structure, a single tenant within said structure (a single customer location)."", "With the new text: "An End Site is the smallest subnet in a network requiring IPv6 address space."", "### Timetable for Implementation", "Immediate", "### Comments", "This proposal is intended to replace ARIN-prop-305 in part, but is not considered strictly editorial in nature.", "## History and Earlier Versions", "|Action|Date|", "|--- |--- |", "| [Proposal](/participate/policy/proposals/2022/ARIN_prop_318_orig/) | 9 August 2022 |", "| [Draft Policy](https://lists.arin.net/pipermail/arin-ppml/2022-August/036466.html) | 23 August 2022 |", "| [Revised](https://lists.arin.net/pipermail/arin-ppml/2022-November/036619.html) | 17 November 2022 |", "| [Abandoned](/about/welcome/ac/meetings/2022_1215/) | 21 December 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/)", "- [27 January 2023](/about/welcome/ac/meetings/2023_0127/)", "- [16 February 2023](/about/welcome/ac/meetings/2023_0216/)", "- [16 March 2023](/about/welcome/ac/meetings/2023_0316/)", "### Board of Trustees", "### ARIN Public Policy Meetings", "- [ARIN 50](/participate/meetings/ARIN50/)"], "lastUpdated": "2018-07-02", "url": "https://www.arin.net/participate/policy/drafts/2022_13/" }]