[{

    "title": "ARIN-prop-352: Harmonize Section 1 and Section 6, Principles and Goals Statements",
    "originators": ["Chris Woodfield"],
    "status": "New Proposal",
    "problemStatement": "\nThere are two main sections of the NRPM that discuss principles and goals; one is found in Section 1, and the other in Section 6; similar language in Section 4 has been previously retired. Given the history of these two sections, there are multiple redundancies and incongruities in their language. This proposal seeks to clarify the language of both sections in order to better communicate ARIN’s principles and goals.\nThis policy proposal is not intended to make meaningful changes to these goals and principles, but to clarify their language and remove duplication. Any analysis that suggests otherwise should be addressed.\n","policyStatement": "\nOriginal Text:\n1. Principles and Goals of the American Registry for Internet Numbers (ARIN)\n1.1. Registration\nThe principle of registration guarantees the uniqueness of Internet number resources. Provision of this public registry documenting Internet number resource allocation, reallocation, assignment, and reassignment is necessary:\n1. to ensure uniqueness,\n2. to provide a contact in case of operational/security problems,\n3. to provide the transparency required to ensure that Internet number resources are efficiently utilized, and\n4. to assist in IP allocation studies.\n1.2. Conservation\nThe principle of conservation guarantees sustainability of the Internet through efficient utilization of unique number resources.\nDue to the requirement for uniqueness, Internet number resources of each type are drawn from a common number space. Conservation of these common number spaces requires that Internet number resources be efficiently distributed to those organizations who have a technical need for them in support of operational networks.\n1.3. Routability\nThe principle of routability guarantees that Internet number resources are managed in such a manner that they may be routed on the Internet in a scalable manner.\nWhile routing scalability is necessary to ensure proper operation of Internet routing, allocation or assignment of Internet number resources by ARIN in no way guarantees that those addresses will be routed by any particular network operator.\n1.4. Stewardship\nThe principle of stewardship guarantees the application of these principles when managing Internet number resources.\nThe fundamental purpose of Internet number stewardship is to distribute unique number resources to entities building and operating networks thereby facilitating the growth and sustainability of the Internet for the benefit of all.\nIt should be noted that the above goals may sometimes be in conflict with each other and with the interests of individual end-users or network operators. Care must be taken to ensure balance with these conflicting goals given the resource availability, relative size of the resource, and number resource specific technical dynamics, for each type of number resource.\n6.3. Goals of IPv6 Address Space Management\n6.3.1. Goals\nIPv6 address space is a public resource that must be managed in a prudent manner with regards to the long-term interests of the internet. Responsible address space management involves balancing a set of sometimes competing goals. The following are the goals relevant to IPv6 address policy.\n6.3.2. Uniqueness\nEvery assignment and/or allocation of address space must guarantee uniqueness worldwide. This is an absolute requirement for ensuring that every public host on the Internet can be uniquely identified.\n6.3.3. Registration\nInternet address space must be registered in a registry database accessible to appropriate members of the Internet community. This is necessary to ensure the uniqueness of each Internet address and to provide reference information for Internet troubleshooting at all levels, ranging from all RIRs and IRs to end users.\nThe goal of registration should be applied within the context of reasonable privacy considerations and applicable laws.\n6.3.4. Aggregation\nWherever possible, address space should be distributed in a hierarchical manner, according to the topology of network infrastructure. This is necessary to permit the aggregation of routing information by ISPs, and to limit the expansion of Internet routing tables.\nThis goal is particularly important in IPv6 addressing, where the size of the total address pool creates significant implications for both internal and external routing.\nIPv6 address policies should seek to avoid fragmentation of address ranges.\nFurther, RIRs should apply practices that maximize the potential for subsequent allocations to be made contiguous with past allocations currently held. However, there can be no guarantee of contiguous allocation.\n6.3.5. Conservation\nAlthough IPv6 provides an extremely large pool of address space, address policies should avoid unnecessarily wasteful practices. Requests for address space should be supported by appropriate documentation and stockpiling of unused addresses should be avoided.\n6.3.6. Fairness\nAll policies and practices relating to the use of public address space should apply fairly and equitably to all existing and potential members of the Internet community, regardless of their location, nationality, size or any other factor.\n6.3.7. Minimized Overhead\nIt is desirable to minimize the overhead associated with obtaining address space. Overhead includes the need to go back to RIRs for additional space too frequently, the overhead associated with managing address space that grows through a number of small successive incremental expansions rather than through fewer, but larger, expansions.\n6.3.8. Conflict of Goals\nThe goals described above will often conflict with each other, or with the needs of individual IRs or end users. All IRs evaluating requests for allocations and assignments must make judgments, seeking to balance the needs of the applicant with the needs of the Internet community as a whole.\nIn IPv6 address policy, the goal of aggregation is considered to be the most important.\nProposal Text:\n1. Principles and Goals of the American Registry for Internet Numbers (ARIN)\nUpdate Sections 1.1, 1.2, 1.3 and 1.4 as follows:\n1.1. Registration (refactor of original language)\nThe provisioning of a public registry documenting Internet number resource allocation, reallocation, assignment, and reassignment is necessary:\n1. to ensure the uniqueness of allocated resources,\n2. to provide operational and security contacts for resource holders,\n3. to provide the transparency required to ensure that Internet number resources are efficiently utilized, and\n4. to provide data for the research and reporting of allocation activity.\n1.2. Conservation (moving language from 6.3.5, integrating into existing)\nDue to the requirement for uniqueness, Internet number resources of each type are drawn from a common number space. Conservation of these common number spaces requires that these resources be efficiently distributed to those organizations who have a technical need for them in support of operational networks. Requests for address space should be supported by appropriate documentation; stockpiling of unused addresses should be discouraged.\n1.3. Routability and Scalability (moving language from 6.3.4, integrating into existing)\nWherever possible, address space should be distributed in a hierarchical manner, according to the topology of network infrastructure. This is necessary to permit the aggregation of routing information by ISPs, and to limit the expansion of Internet routing tables.\nWhere possible, address policies should seek to avoid fragmentation of address ranges.\nWhile routing scalability is necessary to ensure proper operation of Internet routing, allocation or assignment of Internet number resources by ARIN in no way guarantees that those addresses will be routed by any particular network operator.\n1.4. Stewardship (removing language and moving to new sections harmonized with original 6.3. sections)\nThe fundamental purpose of Internet number stewardship is to distribute unique number resources to entities building and operating networks thereby facilitating the growth and sustainability of the Internet for the benefit of all.\nAdd new sections, with language borrowed from original section 1.4 and sections 6.3.6 and 6.3.7:\n1.5 Fairness\nAll policies and practices relating to the use of public address space should apply fairly and equitably to all existing and potential members of the Internet community, regardless of their location, nationality, size or any other factor.\n1.6 Conflict of Goals\nIt should be noted that the above goals may sometimes be in conflict with each other and with the interests of individual end-users or network operators. Care must be taken to ensure balance with these conflicting goals given the resource availability, relative size of the resource, and number resource specific technical dynamics, for each type of number resource.\n6.3. Goals of IPv6 Address Space Management\nUpdate 6.3.1 to reference earlier principals and goals statements:\n6.3.1. Goals\nIPv6 address space, like other resources under ARIN’s purview, must be managed in a prudent manner in keeping with the long-term interests of the internet. Responsible address space management involves balancing a set of sometimes competing goals. In addition to the general principles and goals in Section 1, the following principles and goals should be followed in managing IPv6 address resources:\nRemove 6.3.2 and 6.3.3 as redundant to 1.2 and 1.1:\n6.3.2. (retired)\n6.3.3. (retired)\nModify 6.3.4, moving more generic language to 1.3 while keeping IPv6-specific language\n6.3.4. Aggregation\nWherever possible, address space should be distributed in a hierarchical manner, according to the topology of network infrastructure. This is necessary to permit the aggregation of routing information by ISPs, and to limit unnecessary expansion of the size of Internet routing tables.\nIPv6 address policies should seek to avoid fragmentation of address ranges. ARIN will apply practices that maximize the potential for subsequent allocations to be made contiguous with past allocations currently held; however, there can be no guarantee of contiguous allocation.\nWhen managing IPv6 address resources, the goal of Aggregation should be considered the most important.\n6.3.7. Minimized Overhead\nIt is desirable to minimize the overhead associated with obtaining address space. Overhead includes the need to request additional space too frequently and the overhead associated with managing address space that grows through a number of small successive incremental expansions, rather than through fewer, but larger, expansions.\nRemove 6.3.8 as redundant to 1.6 (which now calls out the IPv6-specific priority of conflicting goals)\n6.3.8. (retired)\n","comments": "\nThis proposal is being submitted as a work product of the ARIN Advisory Council Policy Experience Report Working Group (PERWG).\nAs stated earlier, this is intended to be solely a language cleanup and harmonization, and is submitted with no intention to materially change allocation policies. All parties should carefully review the updated language and call out potential changes in policy that may happen unintentionally with the adoption of this language.","lastUpdated": "2025-09-17",
    "url": "https://www.arin.net/participate/policy/proposals/2026/ARIN_prop_352/"
    },{
    "title": "ARIN-prop-351: NRPM Section 6.4.1 Retirement",
    "originators": ["Alison Wood", "Chris Woodfield", "Gus Reese", "Elizabeth Goodson"],
    "status": "New Proposal",
    "problemStatement": "\nCurrent NRPM Section 6.4.1 contains language referring to property rights of IPv6 direct allocations made by ARIN.  Past references to any rights on IP resources was defined in legacy versions of the Resource Services Agreement between an entity and ARIN.  Any mention of property or other rights do not belong in the Number Resource Policy Manual, this should be referenced in the Registration Services Agreement.  Section 6 of the Number Resource Policy Manual was modeled on a framework the other RIRs added to their policy manuals going back as far as 2004.\n","policyStatement": "\nRetire 6.4.1 Address Space Not to be Considered Property\n","comments": "\nNone","lastUpdated": "2025-09-17",
    "url": "https://www.arin.net/participate/policy/proposals/2026/ARIN_prop_351/"
    },{
    "title": "ARIN-prop-350: NRPM Section 6.5 Revision",
    "originators": ["Alison Wood"],
    "status": "New Proposal",
    "problemStatement": "\nCurrent NRPM Section 6.5 contains allocation mechanisms that are complex and formula driven. These mechanisms include rigid sizing calculations, utilization-based thresholds, and IPv4-dependent qualification criteria.\n \nIPv6 deployment is based on hierarchical planning, aggregation, and projected growth.\n \nARIN’s IPv6 network planning guide emphasizes structured planning instead of mathematical formulas, including the use of hierarchical addressing, aggregation, and multi-year growth projections.\n \nThe current policy is complex, is difficult for applicants to interpret consistently and does not align with ARIN’s published guidance.\n","policyStatement": "\n: Modify NRPM Section 6.5 (IPv6 Allocations) to simplify allocation criteria and align policy with IPv6 network planning practices. \nThe revised policy replaces formula-based and utilization-based allocation mechanisms with a planning-based evaluation model. \nUnder this model:\n- Eligibility is based on demonstrated operational requirements for IPv6 address space, including service provider operations, multihoming, and internal infrastructure needs \n- All requests must include a network plan describing intended addressing use, hierarchical structure, and projected growth over defined time horizons \n- Allocation sizes are determined based on the documented network plan and need for aggregation and contiguous growth \n- Subsequent allocations are based on demonstrated implementation consistent with prior plans and updated growth projections \n- End-user allocations and LIR allocations are evaluated using consistent planning-based criteria appropriate to their operational context \n \n \nSection 6.5: IPv6 Allocations \n6.5 Policies for IPv6 Address Space \nIPv6 address space is issued to support scalable, hierarchical network design, efficient aggregation, and long-term operational requirements. \nIPv6 policy emphasizes minimizing fragmentation of the global routing table and supporting structured network growth.\n \n6.5.1 Eligibility \nAn organization is eligible to receive IPv6 address space if it meets one or more of the following criteria: \na. It operates as a Local Internet Registry (LIR) or intends to make reallocations to downstream networks or customers; or  \nb. It operates infrastructure or internal networks that require provider-independent IPv6 address space to meet operational or architectural requirements.\n \n6.5.2 Network Plan Requirements \nRequests for IPv6 address space must include a documented network plan. Consistent with IPv6 network planning best practices, the plan must: \na. Identify typical assignment sizes for your remote sites or customers (e.g., /48, /56, or /64);  \nb. Describe the addressing hierarchy and logical structure of the network;  \nc. Provide projected utilization of addressing units at approximately 1-year, 2-year, and 5-year intervals.\n \n6.5.3 Initial Allocation to LIRs \nAn organization acting as a Local Internet Registry (LIR) may receive an initial IPv6 allocation when it demonstrates a requirement to make assignments or reallocations to downstream networks or customers. \nInitial allocation requests must include a network plan that: \na. Identifies the intended customer or downstream assignment model, including typical prefix sizes;  \nb. Describes how address space will be distributed across the network to support aggregation;  \nc. Provides projected growth in the number of assignments or sites over approximately 1-year, 2-year, and 5-year intervals.\nIn evaluating initial allocation requests, ARIN will consider:\ni. The anticipated number and type of downstream assignments;  \nii. The need to support hierarchical addressing and route aggregation;  \niii. The ability to accommodate growth through contiguous address space.\nInitial allocations will be issued at sizes sufficient to support the documented plan and allow for efficient expansion. Assignments will be no smaller than a /48, unless the documented network plan justifies a different size.\n \n6.5.4 Subsequent Requests\nTo ensure scalable growth while maintaining registry integrity, additional IPv6 address space may be granted when an organization demonstrates:\na. The organization has assigned or reallocated at least 75% of the prefix units defined in its current 2-year network plan;  \nb. Documented evidence that the address space has been deployed according to the hierarchical structure previously submitted, or a technical justification for architectural changes;  \nc. A revised network plan showing projected requirements for additional prefix units over a new 5-year horizon;  \nd. The request supports the continued aggregation of prefixes. To minimize global routing table growth, ARIN will—whenever possible—issue additional space contiguously by extending the organization's existing allocation.\n \n6.5.5 Deployment Timeline\nOrganizations are expected to begin using issued IPv6 address space within 12 months of issuance.\n \n6.5.6 End-User Allocations (Provider-Independent)\nEnd-user organizations may receive provider-independent (PI) IPv6 address space when they demonstrate a need for stable, non-provider-dependent addressing for internal infrastructure or operational continuity.\nRequests must include a documented network plan that:\na. Identifies the number of sites and associated addressing requirements;  \nb. Describes the internal addressing structure, including segmentation of infrastructure, services, and end systems;  \nc. Supports hierarchical addressing and aggregation within the organization;  \nd. Includes projected growth in addressing requirements over approximately 1-year, 2-year, and 5-year intervals.\nInitial allocations will be issued on nibble boundaries and will be based on the organization’s network plan and projected growth.\nIn evaluating requests, ARIN will consider:\ni. The number and type of sites or operational units;  \nii. The need to support internal hierarchy and segmentation;  \niii. The ability to accommodate growth without renumbering.\nAllocations will be issued at sizes sufficient to support the documented plan and allow for efficient expansion.\n \n6.5.7 Registration (Whois/RDAP)\nOrganizations must maintain records sufficient to document their use of IPv6 address space.\nReassignments or reallocations to external entities of a /64 or larger must be registered in ARIN’s directory services, in accordance with applicable requirements.\n","comments": "\nNone","lastUpdated": "2025-09-17",
    "url": "https://www.arin.net/participate/policy/proposals/2026/ARIN_prop_350/"
    },{
    "title": "ARIN-prop-349: Taking IP To Other Planets (TIPTOP)",
    "originators": ["Tony Li"],
    "status": "Under Discussion",
    "problemStatement": "\nToday, space agencies are using part of their IPv4 address allocations for numbering missions to the moon, and in outer space. Various agencies come from different continents and thus have allocations from different RIRs. They plan on interconnecting networks across agencies to provide mutual backup and to share scarce deep-space communications resources. As missions proliferate, the concern is that aggregation will become challenging because the addressing is not at all tied to the topology.\n \nFor the purposes of this discussion, we consider the moon to be part of 'outer space'.  We exclude low and geostationary Earth orbit.\n","policyStatement": "\nThe IETF would like to recommend that addressing be done in a way that maximizes the possibilities for aggregation. There should be one organization responsible for addessing for outer space. This could be one of the existing RIRs or a new entity. An address space block should be reserved for use in outer space. Within this block, prefixes should be reserved for\n- The moon and its environs\n- Earth's Lagrange points\n- The asteroid belt\n- Each other planet\n- Other regions not covered by the above\nWithin these prefixes, allocation will be done on a per-agency basis, as is done for ISPs by other RIRs. Space agencies can be regarded as both service providers and consumers, and are generally cooperative, providing each other mutual support and services.\nThe physical constraints of providing communications across outer space creates natural barriers, which suggests that eventually there will be a topology that is more dense around celestial bodies, with a limited number of links between these bodies. These links for a natural cut set on the topology and provide a natural location for additional aggregation of the prefixes on the body.\nThis policy does not mandate aggregation. Aggregation requires the consent of all the agencies that are being aggregated. Consent can be granted or withdrawn at any time. Aggregation need not cover all of the prefixes for the celestial body. This policy establishes addressing allocations that will enable this aggregation.\nIf agencies choose not to aggregate, then more specific prefixes will need to be distributed, as usual.\n","comments": "\nThis 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.","lastUpdated": "2025-09-17",
    "url": "https://www.arin.net/participate/policy/proposals/2026/ARIN_prop_349/"
    },{
    "title": "ARIN-prop-348: SPARK (Starter Pack for ARIN Resource Kit)",
    "originators": ["Preston Louis Ursini"],
    "status": "Rejected due to scope",
    "problemStatement": "\nNew entrants to the ARIN region must file separate requests for an Autonomous System Number (ASN), IPv4 addresses under Section 4.10, and IPv6 addresses under Section 6. This creates unnecessary administrative complexity at the very point when operators most need clarity and predictability.\nIn practice, this complexity drives many small networks to engage consultants who often steer them into IPv4 leasing markets instead of working directly with ARIN. This increases costs, delays IPv6 deployment, and introduces reliance on third-party arrangements that do not build long-term resource stability.\nBy providing a bundled entry category that delivers an ASN, a small IPv4 allocation, and an IPv6 allocation through a single request, ARIN can lower barriers for new entrants, reduce reliance on leasing markets, and encourage IPv6 adoption from day one.\n","policyStatement": "\n4.11 SPARK Allocations\nPurpose\nSPARK Allocations are intended to provide new entrants with a simplified, bundled set of Internet Number Resources in order to facilitate IPv6 deployment and reduce reliance on IPv4 leasing markets.\nEligibility\nOrganizations that do not currently hold Internet Number Resources from ARIN may apply under this section.\nResources Issued\nUpon approval of a single request, ARIN shall issue:\nAn Autonomous System Number, pursuant to the criteria in Section 5.1.\nA /24 of IPv4 address space from the transition block described in Section 4.10.\nAn IPv6 allocation sized according to Section 6.5.8 (end-user) or Section 6.5.1 (ISP), depending on the nature of the applicant.\nOther Requirements\nAll normal justification and utilization requirements in Sections 4, 5, and 6 remain in effect, except that applicants may request these bundled resources under a single application.\nOrganizations receiving a SPARK Allocation are subject to all standard ARIN policies regarding conservation, aggregation, and registration.\n","implementationTime": "Immediately","lastUpdated": "2025-10-31",
    "url": "https://www.arin.net/participate/policy/proposals/2025/ARIN_prop_348_v2/"
    },{
    "title": "ARIN-prop-347: Reserve 4.10 space for In-Region Use",
    "originators": ["Chris Woodfield"],
    "status": "Unresolved",
    "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."\n \nto:\n \n"This IPv4 allocation will be set aside and dedicated to facilitate IPv6 deployment within the ARIN service area"\n","implementationTime": "Immediate","comments": "\nThis 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.","lastUpdated": "2025-07-14",
    "url": "https://www.arin.net/participate/policy/proposals/2025/ARIN_prop_347/"
    },{
    "title": "ARIN-prop-346: Make policy in 6.5.8.2 match the examples",
    "originators": ["Tyler O'Meara"],
    "status": "Unresolved",
    "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": "\nIn 6.5.8.2 replace "An organization qualifies for an assignment on the next larger nibble boundary when their sites exceed 75% of the /48s available in a prefix."\nwith "An organization qualifies for an assignment on the next larger nibble boundary when their sites exceed 75% of the /48s available in a prefix unless they only have a single site."\n","implementationTime": "Immediate","comments": "\nAnother way to fix the discrepancy would be to allocate a /44 for end users with a single site, but given the context of 6.5.8.2 it appears that the current intent of policy is for a single site end user to receive a /48.","lastUpdated": "2025-05-19",
    "url": "https://www.arin.net/participate/policy/proposals/2025/ARIN_prop_346/"
    },{
    "title": "ARIN-prop-345: Fix formula in 6.5.2.1c",
    "originators": ["Tyler O'Meara"],
    "status": "Unresolved",
    "problemStatement": "\nThe formula in 6.5.2.1c does not match the text, and is exponentially more generous than the text.\n","policyStatement": "\nIn 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."\n \nwith "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).\n","implementationTime": "Immediate","comments": "\nNone","lastUpdated": "2025-05-19",
    "url": "https://www.arin.net/participate/policy/proposals/2025/ARIN_prop_345/"
    },{
    "title": "ARIN-prop-344: Clarify Justification Requirements for Reserved IP Addresses",
    "originators": ["Tyler O'Meara"],
    "status": "Abandoned",
    "problemStatement": "\nThe NRPM text is ambiguous about whether out of region use cases can justify requests for Reserved IP addresses, as well as whether Reserved 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 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 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","comments": "\nNone","lastUpdated": "2025-04-29",
    "url": "https://www.arin.net/participate/policy/proposals/2025/ARIN_prop_344/"
    },{
    "title": "ARIN-prop-343: Resource Issuance to Natural Persons",
    "originators": ["Preston Louis Ursini"],
    "status": "Abandoned",
    "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.12 as follows:\nCurrent:\n2.12 Organization\nAn organization is a company, corporation, or other legally recognized entity.\nProposed:\n2.12 Organization\nAn organization is a company, corporation, sole proprietorship, government agency, non-profit entity, or a natural person acting in a capacity consistent with operating a network and who meets ARIN’s resource eligibility criteria.\nAdditionally:\n- 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.\n- Staff may develop identity verification and residency requirements appropriate to individuals (e.g., government-issued photo ID and proof of address).\n- All resource justification, utilization, and RSA signing requirements remain unchanged.\n","implementationTime": "Recommend implementation within 3–6 months of ratification to allow ARIN staff and legal counsel to develop supporting processes.","comments": "\nThere 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.\n","lastUpdated": "2025-04-21",
    "url": "https://www.arin.net/participate/policy/proposals/2025/ARIN_prop_343/"
    },{
    "title": "ARIN-prop-342: Require newly created AS-SETs to have hierarchical names",
    "originators": ["James Bensley"],
    "status": "Unresolved",
    "problemStatement": "\nThere is a long running issue of AS-SET names not being unique across authoritative IRR databases. This happens because at the time of AS-SET creation, an authoritative IRR server can't be sure that the proposed set name doesn't exist in all other IRR databases.\nThis creates a problem for resolving IRR servers in particular. Resolving IRR servers typically mirror multiple authoritative IRR databases and as a result contain AS-SET with non-unique names. When a resolving IRR server is queried to compile a prefix or AS path filter list for example, the wrong data may be returned, leading to prefix leaking, or no data may be returned in the case an empty AS-SET is referenced instead of a populated one, resulting in the disconnection of networks.\nThere has been many incidents over the years, but incidents which relate to hyperscalers are implicitly more visible to the community. MANRS documented the incident with AS-AMAZON back in 2022, https://manrs.org/2022/12/why-network-operators-should-use-hierarchical-as-sets/. At the time of writing Google's official source for their AS-SET is RADB as documented in their PeeringDB entry https://www.peeringdb.com/net/433, but AS-GOOGLE currently exists as an empty AS-SET in the RIPE DB https://apps.db.ripe.net/db-web-ui/lookup?source=ripe&key=AS-GOOGLE&type=as-set.\nNot only do name collisions exist, but getting them fixed is extremely difficult because a network operator does not own a specific AS-SET name. AS-SET names are essentially ambiguous, meaning any name can be used, however it has become industry standard practice to use an AS-SET name which easily identifies the network using the AS-SET i.e, AS-AMAZON is used by Amazon. If name squatting takes place intentionally as part of a malicious act, the victim has no rights to get the squatting AS-SET removed, especially if it is in a different IRR DB.\nTherefore, there is a need for AS-SET names to be unique across authoritative IRR database, and to authorize the name assigned to the AS-SET. This can be achieved by enforcing newly created AS-SETs to have hierarchical names. This makes the AS-SET name unique because the AS number at the front of the AS-SET is uniquely assigned by the RIR which assigned the AS number. This also authorizes the user of the AS-SET because only the operator of the AS number can create hierarchical AS-SET names which start with that AS number.\nTo date:\n- APNIC have implemented this under PROP-151: https://www.apnic.net/community/policy/proposals/prop-151/\n- RIPE have implemented this under NWI-19: https://www.ripe.net/manage-ips-and-asns/db/numbered-work-items/\n- LACNIC implemented this as part of their initial IRR daemon deployment.\nEnforcing hierarchical names for AS-SETs doesn't rectify existing naming collisions, but it stops the problem from growing any larger than it already has.\n","policyStatement": "\nThe creation of an AS-SET in the ARIN DB requires the AS-SET name to be hierarchical.\nBy using hierarchical set naming which starts with an AS number, only the maintainer of the AS number is able to create such an AS-SET.\nThis requirement is not currently extended to any other set types such as route sets, to keep the scope of this change to a more manageable level. Also, existing AS-SETs will not be renamed due to the massive data inconsistencies this would create, and because there is no way to programmatically determine which ASNs the existing AS-SETs in the ARIN DB relate to. Additionally, the existing AS-SETs which have a non-hierarchical name may continue to do so; editing an existing AS-SET MUST NOT require the maintainer to also rename the set to have a hierarchical name. The scope of the change is simply to disallow the creation of new AS-SETs unless they have a hierarchical set name.\nThe definition of a hierarchical set name is already defined in RFC 2622 Section 5 (https://www.rfc-editor.org/rfc/rfc2622.html#page-13). A summary is provided below:\n- There must be at least one colon ( : ) character in the name\n- The first element of the name must be an ASN\n- The second element of the name must be an AS-SET name starting with 'AS-'\n- Any further elements can be either ASNs or AS-SET names\n","implementationTime": "TBD","lastUpdated": "2025-03-27",
    "url": "https://www.arin.net/participate/policy/proposals/2025/ARIN_prop_342/"
    },{
    "title": "ARIN-prop-341: Change Section 9 Out Of Region Use Minimum Criteria",
    "originators": ["Eddie Stauble"],
    "status": "Unresolved",
    "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 current text in  from:\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 /22 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\nTo:\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","comments": "\nIn 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.\nIn 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.\nLooking back over the history of Section 9, it was first proposed by Terri Stumme in PROP 189 in May 2013, and was abandoned.\nThe Second proposal was by David Farmer in PROP 192 in January 2014 and was abandoned. .\nThe 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.\nIn 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.\nThere was a fear of the additional expenses and complexity involved in verifying out of region use. Since the policy has been in effect for almost 9 years, what has ARIN’s experience been in verification of out of region use? Is out of region use invoked often? Are there any statistics as to how often it is denied due to less than a /22 used in region?\nThere were also concerns expressed about unlimited out of region use. There is a lower limit on in-region use, but there is no upper limit to how much space can be used out of region, as long as you have a /22 in region. Has this been a problem?\nThe current policy requirement of a /22 in region appears to be arbitrary, and is detrimental to and discriminates against smaller entities.\n","implementationTime": "Immediate","lastUpdated": "2025-02-13",
    "url": "https://www.arin.net/participate/policy/proposals/2025/ARIN_prop_341/"
    },{
    "title": "ARIN-prop-340: Clarify 8.5.1 Registration Services Agreement",
    "originators": ["Doug Camin", "Liz Goodson", "Chris Woodfield", "Alison Wood", "Matt Wilder"],
    "status": "Unresolved",
    "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 policy.\n","implementationTime": "Immediate","lastUpdated": "2025-02-10",
    "url": "https://www.arin.net/participate/policy/proposals/2025/ARIN_prop_340/"
    },{
    "title": "ARIN-prop-339: Clarify ISP and LIR Definitions and References to Address Ambiguity in NRPM Text",
    "originators": ["Doug Camin"],
    "status": "Unresolved",
    "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, removing an ambiguous word and clarification on usage for the term LIR, removing an ambiguous terminology statement in Section 6.5.1a, and changing terms in Section 6.5 to explicitly state it applies to "LIR/ISP," thus fulfilling the original intent of 6.5.1a, in all appropriate locations.\n","policyStatement": "\nAdd Internet Service Provider definition:\nRemove the word "primarily" from the definition of LIR and add usage clarification:\nFROM:\n2.4. Local Internet Registry (LIR)\nA Local Internet Registry (LIR) is primarily an IR that assigns IP addresses to the users of the network services that it provides. LIRs are generally Internet Service Providers (ISPs) whose customers are primarily end users and possibly other ISPs.\nTO:\n2.4. Local Internet Registry (LIR)\nA Local Internet Registry (LIR) is an IR that assigns IP addresses to the users of the network services that it provides. LIRs are generally Internet Service Providers (ISPs) whose customers are primarily end users and possibly other ISPs. The term LIR originates from and is in more common use in other RIR regions.\nAdd definition for ISP:\n2.18 Internet Service Provider\nAn Internet Service Provider (ISP) is a type of LIR 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. \nReplace Section 6.5.1a\nOriginal Text: "The terms ISP and LIR are used interchangeably in this document and any use of either term shall be construed to include both meanings."\nNew Text: "[Retired]"\nChange all references in section 6.5 to use LIR/ISP, where appropriate:\n_[Editing note: For the purposes of clarity in plaintext communication mediums, any addition of LIR or ISP to the text is denoted with the underscore character before and after the insertion. The underscore character is not considered a part of the final text.]_\nAmend Section 6.5.2 to add ISP and LIR in 15 locations \n6.5.2. Initial Allocation to LIR_/ISPs_\n6.5.2.1. Size  \na. All allocations shall be made on nibble boundaries.  \nb. In no case shall an LIR_/ISP_ receive smaller than a /32 unless they specifically request a /36 or /40. In order to be eligible for a /40, an _LIR/_ISP must meet the following requirements:  \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)\nIn no case shall an _LIR/_ISP receive more than a /16 initial allocation.  \nc. The maximum allowable allocation shall be the smallest nibble-boundary aligned block that can provide an equally sized nibble-boundary aligned block to each of the requesters serving sites large enough to satisfy the needs of the requesters largest single serving site using no more than 75% of the available addresses. \nThis 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.\nd. For purposes of the calculation in (c), an end site which can justify more than a /48 under the end-user assignment criteria in  6.5.8 shall count as the appropriate number of /48s that would be assigned under that policy.\ne. For purposes of the calculation in (c), an LIR_/ISP_ which has subordinate LIR_/ISPs_ shall make such reallocations according to the same policies and criteria as ARIN. In such a case, the prefixes necessary for such a reallocation should be treated as fully utilized in determining the block sizing for the parent LIR_/ISP_. LIR_/ISPs_ which do not receive resources directly from ARIN will not be able to make such reallocations to subordinate LIR_/ISPs_ and subordinate LIR_/ISPs_ which need more than a /32 shall apply directly to ARIN.\nf. An LIR_/ISP_ is not required to design or deploy their network according to this structure. It is strictly a mechanism to determine the largest IP address block to which the LIR_/ISP_ is entitled.\ng. An LIR_/ISP_ that requests a smaller /36 or /40 allocation is entitled to expand the allocation to any nibble aligned size up to /32 at any time without renumbering or additional justification. /40 allocations shall be automatically upgraded to /36 if at any time said LIR_/ISP_’s IPv4 direct allocations exceed a /24. Expansions up to and including a /32 are not considered subsequent allocations, however any expansions beyond /32 are considered subsequent allocations and must conform to section 6.5.3. Partial returns of any IPv6 allocation that results in less than a /36 of holding are not permitted regardless of the _LIR/_ISP’s current or former IPv4 address holdings.\nAmend Section 6.5.2.2 to add LIR in 2 locations:\n6.5.2.2. Qualifications\nAn organization qualifies for an allocation under this policy if they meet any of the following criteria:\na. Have a previously justified IPv4 _LIR/_ISP allocation from ARIN or one of its predecessor registries or can qualify for an IPv4 _LIR/_ISP allocation under current criteria.\nb. Are currently multihomed for IPv6 or will immediately become multihomed for IPv6 using a valid assigned global AS number. In either case, they will be making reassignments or reallocations from allocation(s) under this policy to other organizations.\nc. Provide ARIN a reasonable technical justification indicating why an allocation is necessary. Justification must include the intended purposes for the allocation and describe the network infrastructure the allocation will be used to support. Justification must also include a plan detailing anticipated reassignments and reallocations to other organizations or customers for one, two and five year periods, with a minimum of 50 assignments within 5 years.\nAmend Section 6.5.3 to add ISP in 4 locations:\n6.5.3. Subsequent Allocations to LIR_/ISPs_\na. Where possible ARIN will make subsequent allocations by expanding the existing allocation.  \nb. An LIR_/ISP_ qualifies for a subsequent allocation if they meet any of the following criteria:  \n- Shows utilization of 75% or more of their total address space\n- Shows utilization of more than 90% of any serving site\n- Has allocated more than 90% of their total address space to serving sites, with the block size allocated to each serving site being justified based on the criteria specified in section 6.5.2  \nc. If ARIN can not expand one or more existing allocations, ARIN shall make a new allocation based on the initial allocation criteria above. The LIR_/ISP_ is encouraged, but not required to renumber into the new allocation over time and return any allocations no longer in use.  \nd. If an LIR_/ISP_ has already reached a /12 or more, ARIN will allocate a single additional /12 rather than continue expanding nibble boundaries.\nAmend Section 6.5.4.1 to add ISP in 1 location:\n6.5.4.1. Reassignment to Operator’s Infrastructure  \nAn LIR_/ISP_ may reassign up to a /48 per PoP as well as up to an additional /48 globally for its own infrastructure.\nAmend Section 6.5.5 to add LIR in 1 location:  \n6.5.5. Registration\n_LIR/_ISPs are required to demonstrate efficient use of IP address space allocations by providing appropriate documentation, including but not limited to reassignment and reallocation histories, showing their efficient use.\nAmend Section 6.5.5.4 to add LIR in 1 location:\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 _LIR/_ISP shall register that assignment as described in section 6.5.5.1.\nAmend Section 6.5.7 to add ISP in 1 location:\n6.5.7. Existing IPv6 Address Space Holders  \nLIR_/ISPs_ which received an allocation under previous policies which is smaller than what they are entitled to under this policy may receive a new initial allocation under this policy. If possible, ARIN will expand their existing allocation.\nAmend Section 6.5.9 to add LIR and ISP in 2 locations:  \n6.5.9. Community Network Allocations\nWhile community networks would normally be considered to be _LIR/_ISP type organizations under existing ARIN criteria, they tend to operate on much tighter budgets and often depend on volunteer labor. As a result, they tend to be much smaller and more communal in their organization rather than provider/customer relationships of commercial ISPs. This section seeks to provide a policy that is more friendly to those environments by allowing community network to receive a smaller allocation than other LIRs or commercial ISPs.\nCommunity networks may also qualify under section 6.5.2 as a regular LIR_/ISP_.\nAmend Section 6.5.9.2 to add ISP in 1 location:\n6.5.9.2. Allocation Size  \nCommunity networks are eligible only to receive an allocation of /40 of IPv6 resources under this section. Community networks that wish to receive a larger initial allocation or any subsequent allocations must qualify as a regular LIR_/ISP_, see sections 6.5.2 or 6.5.3 respectively.\nAmend Section 6.5.9.3 to add ISP in 1 location:\n6.5.9.3. Reassignments by Community Networks  \nSimilar to other LIR_/ISPs_, Community networks shall make reassignments to end-users in accordance with applicable policies, in particular, but not limited to sections 6.5.4 and 6.5.5. However, they shall not reallocate resources under this section.\n","comments": "\nThis proposal was submitted after the abandonment of Proposal 2024-6, which proposed clarifying 6.5.1a’s language. The community feedback indicated a more explicit approach was desired to remove ambiguity, resulting in this follow up proposal. \nThe changes in Section 6.5 adding LIR or ISP were reviewed with the context of each reference in mind, and only those that clearly fit the contextual change of needing the "LIR/ISP" definition were included. This did not necessarily include every reference to LIR or ISP in Section 6.5\n","implementationTime": "Immediate","lastUpdated": "2025-01-08",
    "url": "https://www.arin.net/participate/policy/proposals/2025/ARIN_prop_339/"
    }]