[{

    "title": "ARIN-prop-349: Taking IP To Other Planets (TIPTOP)",
    "originators": ["Tony Li"],
    "status": "New Proposal",
    "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. \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","implementationTime": "None","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": "Unresolved",
    "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-348: SPARK (Starter Pack for ARIN Resource Kit)",
    "originators": ["Preston Louis Ursini"],
    "status": "Revised 31 October 2025",
    "problemStatement": "\nNew entrant ISPs and LIRs face barriers that make joining ARIN less attractive than leasing IPv4 from brokers.\nProcess Complexity: ASN, IPv4, and IPv6 each require separate requests, which makes the process appear fragmented and difficult. The current fee structure is complex and hard for newcomers to understand, leaving them confused and discouraged.  Brokers with a financial incentive have filled this gap by creating a market for tying IPv4 assets to IP Transit, consulting, and other contracts, creating a feedback loop of IPv4 scarcity and slow IPv6 adoption.\nCost Pressure: The $500 new member registration fee plus ongoing annual fees are not transparent or easy to comprehend to a newer network in presentation, which creates the perception of stacked costs. This drives many small ISPs toward the IPv4 leasing market, where costs are higher but the process is perceived as simpler and even more affordable.\nThe effect of new ISPs simply leasing IPv4 has a side effect of making IPv6 feel like an "add-on" and causes these networks to simply skip IPv6 implementation all together.  By making IPv6+IPv4 through NRPM 4.10 into a simple package the narrative and perception for a new ISP changes: IPv6 is now the default, it is available, and implementing it also gives you a /24 to enable IPv4 access.\nEducational Opportunities: This gives ARIN room for education, showing these ISPs that CGNAT+IPv6 is a reliable default path forward for new networks.  It sets the standard that IPv4 is expected to be delivered via CG-NAT and behind load balancers as a tool for IPv6 transition, rather than as asset to be leased and sold.\nOther RIRs have addressed these very issues by bundling resources for newcomers. RIPE NCC issues IPv4 and IPv6 together to new members, LACNIC requires IPv6 with any IPv4 allocation, and APNIC/AFRINIC both encourage or automatically include IPv6 by default. ARIN needs a comparable, turn-key process that simplifies onboarding while encouraging IPv6 adoption.\n","policyStatement": "\nAmend NRPM §4.10 to establish the SPARK bundle (Starter Pack for ARIN Resource Kit):\n \nSingle Request: A new LIR/ISP may submit one SPARK request covering:\n- One ASN\n- An IPv4 /24 from the IPv6 transition reserve under §4.10\n- An Initial IPv6 allocation\n \nIPv6 Allocation: The minimum IPv6 allocation under SPARK shall be a /40, issued using sparse allocation so it may be expanded to a /36 or /32 without renumbering.\n \nFee Structure:\n \n$500 one-time New Member Registration Fee, consistent with ARIN’s current model.\n \n$250/year ongoing (3X-Small category) covering ASN + IPv4 + IPv6.\n \nNo additional resource-specific application fees.\n \nEligibility: SPARK shall be available only to new organizations with no prior IPv4 allocation from ARIN, consistent with §4.10.\n \nSubsequent Growth: Organizations may request additional IPv6 space or IPv4 resources under existing policies. ARIN shall allocate contiguous IPv6 space reserved through sparse allocation where possible.\n","implementationTime": "Within 90 days of Board adoption","comments": "\nStaff and Legal \nStaff: Implementation would require modest adjustments to ARIN’s request workflows and billing to accommodate SPARK as a bundled option.\n \nLegal: No concerns. The policy aligns with ARIN’s mission to facilitate IPv6 adoption and lower barriers for new entrants.\n \nResource Impact\n \nEngineering: Minor updates to ARIN Online to create a SPARK request path.\n \nIPv4: No impact beyond existing §4.10 allocations.\n \nIPv6: Negligible consumption impact — /40 allocations use a minimal portion of ARIN’s holdings, and sparse allocation ensures efficient future growth.\n \nFinance: Keeps revenue aligned with current structure ($500 application + $250/year). Simplifies cost presentation for newcomers without reducing income.\n \nRationale\n \nSimplified Onboarding: One request, one invoice, one bundle. This removes complexity that discourages newcomers.\n \nTransparent Costs: Makes clear that the entry cost is $500 one-time plus $250/year, covering ASN, IPv4, and IPv6.\n \nIPv6-First Deployment: Every new member receives IPv6 alongside IPv4, ensuring dual-stack or IPv6-first design from the outset.\n \nGlobal Consistency: Aligns ARIN with other RIRs that require or automatically issue IPv6 for new members.\n \nRight-Sized: A /40 IPv6 block is small enough for low-cost entry yet expandable without renumbering, making it practical for new small networks.\n \n \n§4.10.2 SPARK – Starter Pack for ARIN Resource Kit\n \nOrganizations receiving an IPv4 allocation under this section shall automatically receive an ASN and a minimum IPv6 allocation of /40. IPv6 allocations shall be made using sparse allocation to allow expansion to /36 or /32. Both IPv4 and IPv6 shall be billed under the same 3X-Small fee category, with the standard new member registration fee applying at initiation.\n \nThe minimum IPv6 allocation for organizations holding no more than a /24 of IPv4 shall be /40, allocated using sparse allocation to allow expansion.","lastUpdated": "2025-09-17",
    "url": "https://www.arin.net/participate/policy/proposals/2025/ARIN_prop_348/"
    },{
    "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/"
    },{
    "title": "ARIN-prop-338: IPv4 Transition Efficiency Reallocation Policy (ITERP)",
    "originators": ["Preston Louis Ursini"],
    "status": "Abandoned",
    "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:\nEnd-users are forced to request larger, underutilized IPv4 blocks for their IPv6 transition needs.\nISPs 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": "\nISPs that receive IPv4 allocations under NRPM 4.10 may reallocate small blocks (e.g., /29 or /28) to end-users, specifically for CG-NAT or dual-stack IPv6 transition purposes. The ISP remains responsible for ensuring that the reallocated space is used in compliance with ARIN’s policy, with regular reporting to ARIN to confirm proper usage. End-users must otherwise qualify for a /24 under NRPM 4.10, and reallocation is limited to supporting their IPv6 transition.\n","comments": "\nIPv4 Transition Efficiency Reallocation Policy (ITERP) and Its Impact on CG-NAT, IPv6, and Efficient Resource Use\nUtilization of Reallocated IP Space by End-Users and Small ISPs for CG-NAT\nUnder 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.\nThrough 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.\nEligibility and Address Space Efficiency\nThis 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.\nSuch 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.\nIncentivizing IPv6 Deployment by ISPs\nThis 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.\nIn 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.\nSupporting ISPs with Only NRPM 4.10 Space and IPv6\nMany 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.\nBy 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.\nConclusion: Efficient Use of Resources and Push for IPv6 Adoption\nThe 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.\nOther 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.\nBy 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.\nThis 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.\nWhen 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.\nThe 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.\nFurthermore, by placing responsibility on the ISPs to ensure proper utilization, ITERP:\n- Minimizes the risk of route table bloat, as ISPs manage these smaller blocks within their own infrastructure.\n- 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.\nIn 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.\n","implementationTime": "Immediate","lastUpdated": "2024-09-04",
    "url": "https://www.arin.net/participate/policy/proposals/2024/ARIN_prop_338/"
    },{
    "title": "ARIN-prop-337: Registration Requirements and Timing of Requirements With Retirement of Section 4.2.3.7.2",
    "originators": ["Chris Woodfield"],
    "status": "Abandoned",
    "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 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 from "Reassignment Information" to "Reassignment and Reallocation Information".\n","comments": "\nThis is an iteration of abandoned policy ARIN-2023-4. Due to substantial changes in the problem statement, it was preferred to abandon that policy and resubmit, as opposed to modifying the policy during its PDP cycle.\n","implementationTime": "Immediate","lastUpdated": "2024-07-17",
    "url": "https://www.arin.net/participate/policy/proposals/2024/ARIN_prop_337/"
    },{
    "title": "ARIN-prop-336: Remove outdated carveout for Community Networks",
    "originators": ["Tyler O'Meara"],
    "status": "Implemented",
    "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","lastUpdated": "2024-06-18",
    "url": "https://www.arin.net/participate/policy/proposals/2024/ARIN_prop_336/"
    },{
    "title": "ARIN-prop-335: Restrict the largest initial IPv6 allocation to /20",
    "originators": ["Tyler O'Meara"],
    "status": "Abandoned",
    "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\nallocation." with "In no case shall a LIR receive more than a /20 initial\nallocation."\n","comments": "\nA quick look at ARIN's stats shows that only a single IPv6 allocation exceeds a /20 in size:\ngrep "ipv6" delegated-arin-extended-latest | grep allocated | cut -d '|' -f 5 | sort | uniq -c\n1 16  \n8 20  \n22 22  \n39 24  \n2 27  \n127 28  \n15 29  \n6 30  \n21 31  \n4236 32  \n1 33  \n2 35  \n1401 36  \n1 37  \n1 38  \n1050 40  \n11 41  \n13 42  \n9 43  \n851 44  \n16 45  \n15 46  \n26 47  \n1754 48  \n","implementationTime": "Immediate","lastUpdated": "2024-05-31",
    "url": "https://www.arin.net/participate/policy/proposals/2024/ARIN_prop_335/"
    },{
    "title": "ARIN-prop-334: 6.5.1a Definition Update",
    "originators": ["Alison Wood"],
    "status": "Abandoned",
    "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","lastUpdated": "2024-05-03",
    "url": "https://www.arin.net/participate/policy/proposals/2024/ARIN_prop_334/"
    },{
    "title": "ARIN-prop-333: Rewrite of NRPM Section 4.4 Micro-Allocation",
    "originators": ["Randy Epstein", "James Jun", "Martin Hannigan", "Aaron Wendel"],
    "status": "Unresolved",
    "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. Growth and use of Internet Exchanges has 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 assigned prefixes as required.\n##","lastUpdated": "2024-04-23",
    "url": "https://www.arin.net/participate/policy/proposals/2024/ARIN_prop_333/"
    },{
    "title": "ARIN-prop-332: Internet Exchange Point Definition",
    "originators": ["Aaron Wendel", "Martin Hannigan"],
    "status": "Abandoned",
    "problemStatement": "\nThe term "Internet Exchange Point" appears in the NPRM 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, Ethernet switching fabric used by three or more autonomous systems for the exchange of data destined for and between their respective networks.\n","implementationTime": "Immediate. ","comments": "\nNone at this time.","lastUpdated": "2024-04-22",
    "url": "https://www.arin.net/participate/policy/proposals/2024/ARIN_prop_332/"
    },{
    "title": "ARIN-prop-331: Addition of definitions for General and Special Purpose IP Addresses",
    "originators": ["Tyler O'Meara"],
    "status": "Abandoned",
    "problemStatement": "\nThe 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, and in currently pending proposals 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 definitions: \nSpecial Purpose IPv4 Address - An IPv4 address issued by ARIN under sections 4.4, 4.10 or 11.\nGeneral Purpose IPv4 Address - An IPv4 address issued by ARIN that is not a Special Purpose IPv4 Address.\nSpecial Purpose IPv6 Address - An IPv6 address issued by ARIN under sections 6.10 or 11.\nGeneral Purpose IPv6 Address - An IPv6 address issued by ARIN that is not a Special Purpose IPv6 Address.\n","implementationTime": "Immediate. ","comments": "\nI 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.\nNote 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.","lastUpdated": "2024-04-19",
    "url": "https://www.arin.net/participate/policy/proposals/2024/ARIN_prop_331/"
    },{
    "title": "ARIN-prop-330: Edit 6.5.8.3 Section 2",
    "originators": ["Alison Wood"],
    "status": "Implemented",
    "problemStatement": "\nA typo was discovered in the policy language that requires correction. An editorial change will accomplish this.\n","policyStatement": "\nCurrent 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:\nWhen possible subsequent assignments will result in the expansion of an existing assignment by one or more nibble boundaries as justified.\n","implementationTime": "Immediate. ","comments": "\nThis is an editorial change that was pointed out by a member of the community.\n","lastUpdated": "2024-03-01",
    "url": "https://www.arin.net/participate/policy/proposals/2024/ARIN_prop_330/"
    },{
    "title": "ARIN-prop-326: Replace Specified Transfers with Monthly Single-Price Auction",
    "originators": ["Kevin Wallace"],
    "status": "Unresolved",
    "problemStatement": "\nIPv4 addresses are getting too expensive for small organizations. Large cloud providers are amassing huge IPv4 allocations, letting the value of their hoard disincentivize them from offering first-class IPv6. Bad actors are fraudulently obtaining IP addresses and flipping them for profit, interfering with price discovery and wasting resources on investigation and litigation efforts. IP leasing has become a haven for spam and other forms of abuse. The current transfer market approach embodied by NRPM 8.3 incentivizes speculation, hoarding, and fragmentation, rather than efficient allocation. Replacing it with a monthly single-price auction would reduce or eliminate the financial incentives underpinning these issues.\n","policyStatement": "\nThe NRPM is amended to implement the following policy:\nOrgs may no longer transfer IPv4 addresses to specified recipients. They may voluntarily return unneeded addresses to ARIN.\nEvery month, returned IPv4 addresses are allocated back to eligible orgs based on the results of a single-price auction conducted by ARIN.\nReturning organizations receive a non-refundable account credit equal to the winning bid multiplied by the number of addresses returned.\nAuction participation is open to any org who needs addresses for justified operational use.\nReciprocity with other RIRs is maintained: non-ARIN orgs may bid and transfer acquired addresses into their RIR, and ARIN orgs may still obtain addresses out of region and move them into ARIN.\nSpecifically, the following changes are made.\n(1) 4.1.8 is modified:\n"a /22." is replaced with "set forth in section 8.5."\n"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." is removed\n"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." is removed\n(2) 4.1.8.2 is replaced with:\nARIN will fulfill requests on a monthly basis, excluding months in which there are no addresses to distribute. When the quantity of requested addresses exceeds the number of available addresses, distribution will be prioritized based on the results of an auction conducted by ARIN and open to waitlist requestors as well as organizations belonging to other RIRs who need addresses for operational use outside of the ARIN service region. Participants may submit a positive per-IP bid; after auction close, bids are chosen in order of highest value, followed by non-bidding requests, breaking ties by earliest waitlist sequence, until every address has been matched to a request/bid. The final successful requestor may receive a partial allocation and remain on the waitlist for the remaining addresses; all other successful requestors will receive full allocations and be removed from the waitlist. The bid of every successful requestor is adjusted to the bid of the final successful requestor. All organizations returning address space distributed under this section receive a non-refundable account credit equal to the adjusted bid multiplied by the number of addresses they returned. Requests and bids are for a quantity of addresses, rather than for a specific prefix, and ARIN may match them to addresses in a way that aims to minimize overall fragmentation.\n(3) 4.2.3.8 is modified:\n"IP allocations issued through 4.2.3.8 are non-transferable via section 8.3 and section 8.4 for a period of 36 months." is removed\n(4) 8.3 is modified:\n"IPv4 addresses {and,or} ASNs" is replaced with "ASNs"\n"Address resources from a reserved pool (including those designated in Section 4.4 and 4.10) are not eligible for transfer." is removed\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." is removed\n(5) 8.4 is modified:\n"Conditions on source of transfer" is amended to include "For transfers of IPv4 addresses, the source entity must be outside of the ARIN region, or the transfer must be the result of a section 4.1.8.2 auction."\n(6) 8.5 is renamed:\n"Specified Transfer" is replaced with "Specified Transfer and Waitlist\nAuction"\n(7) 8.5.5.1 is modified:\n"transfer the entire larger block" is replaced with "return or transfer the entire larger block"\n(8) 8.6 is retired.\n","implementationTime": "1 year after adoption, to give ARIN time to ready auction procedures, and to provide a "last call" period for organizations to initiate final specified transfers under the old policy.","comments": "\nFollow-up to ACSP Suggestion 2023.14. \nChanges from revision 3 (2024-01-26):\n- Changed references from "LIR" to "org" - end users are eligible too.\nChanges from revision 2 (2023-12-04):\n- Removed the words "price" and "$0" from 4.1.8.2.\nChanges from revision 1 (2023-10-26):\n- Removed references to percentage-based split per ARIN AC feedback\n- Removed the word "revenue" entirely per ARIN AC feedback\n- Clarified problem statement to identify the link between policy\nincentives and transfer market dynamics, to address ARIN AC concerns\nthat the state of the market might not be seen as related to policy.","lastUpdated": "2024-02-13",
    "url": "https://www.arin.net/participate/policy/proposals/2023/ARIN_prop_326_v2/"
    },{
    "title": "ARIN-prop-329: Whois Data Requirements Policy for Non-Personal Information",
    "originators": ["Gabriel Andrews"],
    "status": "Implemented",
    "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": "\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.\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 Street Address, City, State and Zip code (or equivalent)\n- Org Country\nAdd 3.8.3 Point of Contact Record Creation\nAn organization may 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 an organization or resource Point of Contact:\n- Contact Name (this can be an individual representative of the company or a role account)\n- Contact’s Organization Street Address, City, State and Zip code (or equivalent)\n- Contact’s Organization Phone Number\n- Contact’s Organization E-Mail Address\n- Contact’s Organization Country\n","implementationTime": "Immediate. ","comments": "\nNone","lastUpdated": "2024-02-09",
    "url": "https://www.arin.net/participate/policy/proposals/2024/ARIN_prop_329/"
    },{
    "title": "ARIN-prop-328: Definition of Organization ID/Org ID",
    "originators": ["Chris Woodfield"],
    "status": "Abandoned",
    "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 Organizational Identifier (Org ID)\nAn Organizational Identifier (Org ID) is a record that represents a business, non-profit corporation, or government entity in the ARIN database. An entity must have an Organizational Identifier (Org ID) to request Internet Number Resources.\n","implementationTime": "Immediate. ","comments": "\nThis 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.","lastUpdated": "2023-12-18",
    "url": "https://www.arin.net/participate/policy/proposals/2023/ARIN_prop_328/"
    },{
    "title": "ARIN-prop-327: Reduce 4.18 maximum allocation",
    "originators": ["Mike Burns"],
    "status": "Abandoned",
    "problemStatement": "\n4.18 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": "\nIn section 4.18, replace the second sentence "The maximum size aggregate that an organization may qualify for at any one time is a /22." With "The maximum size aggregate that an organization may qualify for is a /24."\nRemove the next sentence "Organizations will be able to elect a smaller block size than they qualify for down to a /24."\nReplace the next sentence "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." With "Organizations which ever held any IPv4 space other than special use space received under section 4.4 or 4.10 are not eligible to apply."\nRemove the sentences: "Multiple requests are not allowed: an organization currently on the waitlist must wait 90 days after receiving a distribution from the waitlist or IPv4 number resources as a recipient of any transfer before applying for additional space. ARIN, at its sole discretion, may waive this requirement if the requester can document a change in circumstances since their last request that could not have been reasonably foreseen at the time of the original request, and which now justifies additional space."\nRemove the sentence: "Restrictions apply for entities who have conducted recent resource transfers. These restrictions are specified in Section 8 for each relevant transfer category."\nAdd the sentence: "Waiting list recipients must demonstrate the need for a /24 on an operating network."  \nIn 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."  \nIn section 4.22 replace the sentence: "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." With "All ISP organizations without direct assignments or allocations from ARIN qualify for an initial allocation of a /24."\n","implementationTime": "Immediate. Needs more careful review for intersection with other elements of the NRPM. Need to be careful with existing list member treatment.","comments": "\nI haven’t scanned the NRPM for other mentions of 4.18 that may need to be addressed. I think section 4 can be drastically simplified further with this change. My intention in requiring demonstrated need is avoidance of the situation at RIPE where every new entrant got an automatic allocation, which resulted in many new entities incorporated only to receive this allocation. I noted a serendipity in the number of waiting list entries (703) and the amount of entries that could have been met with a /24 cap (703) in John Sweeting’s ARIN 52 presentation. Current waitlist entrants should be grandfathered-in but their maximum allocation reduced to /24.","lastUpdated": "2023-10-26",
    "url": "https://www.arin.net/participate/policy/proposals/2023/ARIN_prop_327/"
    },{
    "title": "ARIN-prop-326: Replace Specified Transfers with Monthly Single-Price Auction",
    "originators": ["Kevin Wallace"],
    "status": "Unresolved",
    "problemStatement": "\nIPv4 addresses are getting too expensive for small LIRs. Large cloud providers are amassing huge IPv4 allocations, letting the value of their hoard disincentivize them from offering first-class IPv6. Bad actors are fraudulently obtaining IP addresses and flipping them for profit, interfering with price discovery and wasting resources on investigation and litigation efforts. IP leasing has become a haven for spam and other forms of abuse. The current transfer market approach incentivizes speculation, hoarding, and fragmentation, rather than efficient allocation. Replacing it with a monthly single-price auction would reduce or eliminate the financial incentives underpinning these issues and provide a valuable revenue source to fund ARIN operations.\n","policyStatement": "\nThe NRPM is amended to implement the following policy:\nLIRs may no longer transfer IPv4 addresses to specified recipients.\nThey may voluntarily return unneeded addresses to ARIN.\nEvery month, returned IPv4 addresses are allocated back to eligible LIRs based on the results of a single-price auction conducted by ARIN.\nAuction revenue is split, x% to ARIN and (100-x)% to the returning organization as a non-refundable account credit.\nARIN can adjust the value of x over time to balance incentives to return IPs for supply stability, revenue needs, etc.\nAuction participation is open to any LIR who needs addresses for justified operational use.\nReciprocity with other RIRs is maintained: non-ARIN LIRs may bid and transfer acquired addresses into their RIR, and ARIN LIRs may still obtain addresses out of region and move them into ARIN.\nSpecifically, the following changes are made.\n(1) 4.1.8 is modified:\n"a /22." is replaced with "set forth in section 8.5."\n"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." is removed\n"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." is removed\n(2) 4.1.8.2 is replaced with:\nARIN will fulfill requests on a monthly basis, excluding months in which there are no addresses to distribute. When the quantity of requested addresses exceeds the number of available addresses, distribution will be prioritized based on the results of an auction conducted by ARIN and open to waitlist requestors as well as non-ARIN LIRs who need addresses for operational use outside of the ARIN service region. Bidders may submit a positive per-IP bid; failure of a requestor to submit a bid shall be treated as an implicit bid of $0. After auction close, bids are chosen in order of highest price (breaking ties by earliest waitlist sequence) until every address has been matched to a bid. The lowest successful bidder may receive a partial allocation and remain on the waitlist for the remaining addresses; all other successful bidders will receive full allocations and be removed from the waitlist. All successful bidders pay the lowest winning bid. Auction revenue may be split, at ARIN's discretion, between ARIN and the organization that returned the address space as a non-refundable account credit. Bids are for a quantity of addresses, rather than for a specific prefix, and ARIN may match bids to addresses in a way that aims to minimize overall fragmentation.\n(3) 4.2.3.8 is modified:\n"IP allocations issued through 4.2.3.8 are non-transferable via section 8.3 and section 8.4 for a period of 36 months." is removed\n(4) 8.3 is modified:\n"IPv4 addresses\n{and,or}\nASNs" is replaced with "ASNs"\n"Address resources from a reserved pool (including those designated in Section 4.4 and 4.10) are not eligible for transfer." is removed\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." is removed\n(5) 8.4 is modified:\n"Conditions on source of transfer" is amended to include "For transfers of IPv4 addresses, the source entity must be outside of the ARIN region, or the transfer must be the result of a section 4.1.8.2 auction."\n(6) 8.5 is renamed:\n"Specified Transfer" is replaced with "Specified Transfer and Waitlist Auction"\n(7) 8.5.5.1 is modified:\n"transfer the entire larger block" is replaced with "return or transfer the entire larger block"\n(8) 8.6 is retired.\n","implementationTime": "1 year after adoption, to give ARIN time to ready auction procedures, and to provide a "last call" period for organizations to initiate final specified transfers under the old policy.  ","comments": "\nFollow-up to ACSP Suggestion 2023.14.","lastUpdated": "2023-10-26",
    "url": "https://www.arin.net/participate/policy/proposals/2023/ARIN_prop_326/"
    },{
    "title": "ARIN-prop-325: Clarification of NRPM Sections 4.5 and 6.11 Multiple Discrete Networks and the addition of new Section 2.18 Organizational Identifier (Org ID)",
    "originators": ["Christian Tacit", "Matthew Wilder", "Brian Jones"],
    "status": "Implemented",
    "problemStatement": "\nSection 4.5 and 6.11of 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. Researching changes being proposed for section 4.5 and 6.11 of the NRPM to better reflect style guide models it was determined by the NRPM working group that a definition of Organizational Identifier (Org ID) should be included in the NRPM to add clarity of the term and unify NRPM references to match the use of the term in other ARIN publications such as ARIN online, the proposed section is 2.18.\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:\n4.5 Multiple Discrete Networks\nOrganizations with multiple discrete networks desiring to request a new or additional IP address space allocation under a single Organizational Identifier (Org ID) must meet the following criteria:\nThe organization shall be a single entity and not a consortium of smaller independent entities and must have compelling criteria for creating discrete networks.\nExamples which may result in discrete networks might include:\n· Regulatory restrictions for data- transmission;\n· Geographic distance and diversity between networks; or\n· Autonomous multihomed discrete networks.\nThe organization must keep detailed records on how it has allocated IP addresses to each location, including the date of each allocation. When applying for additional Internet Resource 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 internet IP address allocations by having all unallocated IP address blocks smaller than ARIN’s current minimum allocation size. The organization may not allocate additional IP address space to a location until each of that location’s IP address allocations are 80% utilized. The organization should notify ARIN at the time of the request of their desire to apply this policy to their account. 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.\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:\n6.11. IPv6 Multiple Discrete Networks\nOrganizations with multiple discrete IPv6 networks desiring to request new or additional IPv6 address allocations under a single Organizational Identifier (Org ID) must meet the following criteria:\nThe organization shall be a single entity and not a consortium of smaller independent entities. The organization must have compelling criteria for creating discrete networks.\nExamples which may result in discrete networks might include:\n- Regulatory restrictions for data transmission;\n- Geographic distance and diversity between networks; or\n- Autonomous multihomed discrete networks.\nThe organization must keep detailed records on how it has allocated IPv6 addresses to each location, including the date of each IPv6 address allocation. The organization should notify ARIN at the time of the request their desire to apply this policy to their account.\nRequests for additional space:\n- Organization must specify on the application which discrete network(s) the IPv6 address request applies to\n- 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 (definition):\nSection 2.18 Organizational Identifier (Org ID)\nAn Organizational Identifier (Org ID) is a record that represents a business, non-profit corporation, or government entity in the ARIN database. An entity must have an Organizational Identifier (Org ID) to request Internet Number Resources.\n","comments": "\nThe 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.\n","implementationTime": "Immediate  ","lastUpdated": "2023-08-17",
    "url": "https://www.arin.net/participate/policy/proposals/2023/ARIN_prop_325/"
    },{
    "title": "ARIN-prop-324: ARIN Waitlist Qualification",
    "originators": ["Christian Tacit", "Brian Jones", "Matthew Wilder"],
    "status": "Implemented",
    "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 section 4.1.8 ARIN Waitlist requests on the basis of relevant policies within other section 4 subsections as applicable. For example, staff may refer to section 4.2 for ISPs, section 4.3 for End-users, and section 4.5 for organizations with multiple discrete networks.\n","comments": "\nThe 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.\n","implementationTime": "Immediate  ","lastUpdated": "2023-08-16",
    "url": "https://www.arin.net/participate/policy/proposals/2023/ARIN_prop_324/"
    },{
    "title": "ARIN-prop-323: Clean-up of NRPM Sections 4.3.4, 4.4, 4.10 and 6.10.1",
    "originators": ["Chris Tacit", "Matthew Wilder", "Brian Jones"],
    "status": "Implemented",
    "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 "This block will be subject to a minimum and maximum size allocation of /24." with the text "A /24 block will be allocated."\nFor section 6.10.1, delete the sentence: "Organizations receiving these micro-allocations will be charged under the fee schedule."\n","comments": "\nThe 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.\n","implementationTime": "Immediate  ","lastUpdated": "2023-08-14",
    "url": "https://www.arin.net/participate/policy/proposals/2023/ARIN_prop_323/"
    },{
    "title": "ARIN-prop-322: Modernization of Registration Requirements",
    "originators": ["NRPM Working Group"],
    "status": "Abandoned",
    "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, in a timely manner, to the extent permitted and manner provided by applicable law."\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, in a timely manner, to the extent permitted and manner provided by applicable law. 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  ","lastUpdated": "2023-06-05",
    "url": "https://www.arin.net/participate/policy/proposals/2023/ARIN_prop_322/"
    },{
    "title": "ARIN-prop-321: Amendment of the waitlist agreement to include a restriction on leasing",
    "originators": ["Policy Experience Report Working Group (PERWG)"],
    "status": "Abandoned",
    "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  ","lastUpdated": "2023-06-02",
    "url": "https://www.arin.net/participate/policy/proposals/2023/ARIN_prop_321/"
    },{
    "title": "ARIN-prop-320: /26 initial IPv4 allocation for IXPs",
    "originators": ["Chris Woodfield"],
    "status": "Abandoned",
    "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 https://www.arin.net/reference/research/statistics/#ipv4-reserved-pool-status-nrpm-4-10-ipv6-deployments). 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. 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 to be globally reachable; only members of that IXP must be able to reach the prefix. As such, there is no 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.\nAnd 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 a 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 a larger allocation, the IXP must migrate to the new allocation and return their previous one to ARIN within 6 months of receiving the new allocation.\n","comments": "\nThis 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.\n","implementationTime": "Immediate  ","lastUpdated": "2023-05-25",
    "url": "https://www.arin.net/participate/policy/proposals/2023/ARIN_prop_320/"
    },{
    "title": "ARIN-prop-319: Retire 4.2.1.4. Slow Start",
    "originators": ["Kathleen Hunter", "Matthew Wilder"],
    "status": "Implemented",
    "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  ","lastUpdated": "2023-04-17",
    "url": "https://www.arin.net/participate/policy/proposals/2023/ARIN_prop_319/"
    },{
    "title": "ARIN-prop-318: Editorial Clean-up of NRPM Section 2.10",
    "originators": ["Chris Tacit", "Joe Provo", "Matthew Wilder", "Rob Seastrom"],
    "status": "Abandoned",
    "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": "Policy statement\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 Point is the smallest non-divisible physical or virtual point in a network requiring IPv6 address space."\n","implementationTime": "Immediate  ","lastUpdated": "2022-08-19",
    "url": "https://www.arin.net/participate/policy/proposals/2022/ARIN_prop_318_orig/"
    },{
    "title": "ARIN-prop-314: Clean-up of NRPM – Introduction of Section 2.17",
    "originators": ["Chris Tacit", "Joe Provo", "Matthew Wilder", "Rob Seastrom"],
    "status": "Implemented",
    "problemStatement": "\nAlthough the term "IANA" appears throughout Section 10 of the NRPM, there is no reference to any definition of the term. This proposal defines the term with reference to appropriate ICANN documentation.\n","policyStatement": "Policy statement\nIntroduce a new Section 2.17 that reads as follows:\n"2.17 Internet Assigned Names and Numbers (IANA)\nThe term Internet Assigned Numbers Authority (IANA) refers to a set of functions which includes the global coordination of Internet number resources, consisting of IPv4 and IPv6 IP addresses and ASNs."\n","implementationTime": "Immediate  ","comments": "\nAlthough 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.","lastUpdated": "2022-08-12",
    "url": "https://www.arin.net/participate/policy/proposals/2022/ARIN_prop_314_v2/"
    },{
    "title": "ARIN-prop-317: Direct Assignment Language Update",
    "originators": ["Alison Wood", "Alyssa Quinn", "Anita Nikolich (The ARIN Advisory Council Policy Experience Working Group)"],
    "status": "Unresolved",
    "problemStatement": "\nAs a result of ARIN's fee harmonization direct assignment are no longer being utilized within ARIN databases therefore language around that has been deprecated and should be modernized.\n","policyStatement": "Policy statement\nSection 3.6.3:\nRemove "direct assignment" from "This policy applies to every Organization that has a direct assignment, direct allocation, or AS number from ARIN (or one of its predecessor registries) or a reallocation from an upstream ISP."\nSection 4.2.2, paragraph 1: change "direct assignments or allocations" to "ARIN-issued IPv4 addresses"\nSection 4.2.2, paragraph 2: change "direct allocations, direct assignments, re-allocations or reassignments" to "ARIN-issued IPv4 addresses, re-allocations or reassignments"\nSection 4.3.2: change "direct assignments or allocations" to "ARIN-issued IPv4 addresses"\nSection 6.5.8: change "Direct Assignments from ARIN to End-user Organizations" to "End-user Allocations"\nSection 8.5.4: change "direct assignments or allocations" to "ARIN-issued IPv4 addresses"\nSection 8.5.6: change "direct assignments or allocations" to "ARIN-issued IPv4 addresses"\n","implementationTime": "Immediate  ","lastUpdated": "2022-07-25",
    "url": "https://www.arin.net/participate/policy/proposals/2022/ARIN_prop_317_orig/"
    },{
    "title": "ARIN-prop-308: Leasing not Intended",
    "originators": ["Fernando Frediani", "Jordi Palet Martínez", "Noah Maina"],
    "status": "Abandoned",
    "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": "Policy statement\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","lastUpdated": "2022-07-20",
    "url": "https://www.arin.net/participate/policy/proposals/2022/ARIN_prop_308_v2/"
    },{
    "title": "ARIN-prop-316: Streamlining Section 11 Policy Language",
    "originators": ["Alison Wood", "Alyssa Quinn", "Anita Nikolich (The ARIN Advisory Council Policy Experience Working Group)"],
    "status": "Implemented",
    "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": "Policy statement\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:\nARIN 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.\nThe following are the criteria for this policy:\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. Documentation of Recognized Experimental Activity\nA Recognized Experimental Activity is one where the experiment's description and objectives are described in a publicly accessible document. The experiment's outcomes must be published in a "publicly accessible document" that is publicly and openly available free of charges and free of any constraints of disclosure. Outcomes must be published within one year after the end of the experiment. The conditions for determining the end of the experiment are to be included in the document. 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.\nARIN will not recognize an experimental activity under this policy if the entire research experiment cannot be publicly disclosed.\nSection 11.2\nCurrent text:\n11.2. Technical Coordination\nARIN requires that a recognized experimental activity is able to demonstrate that the activity is technically coordinated.\nTechnical coordination specifically includes consideration of any potential negative impact of the proposed experiment on the operation of the Internet and its deployed services, and consideration of any related experimental activity.\nARIN will review planned experimental activities to ensure that they are technically coordinated. This review will be conducted with ARIN and/or third-party expertise and will include liaison with the IETF.\nProposed text:\n11.2. Technical Coordination\nARIN requires that a recognized experimental activity is able to demonstrate that the activity is technically coordinated.\nTechnical coordination includes consideration of any potential negative impact of the proposed experiment on the operation of the Internet and its deployed services, and a description of experimenter mitigation plans to contain any negative impacts.\nARIN will review planned experimental activities to ensure that they are technically coordinated. This review will be conducted with ARIN and/or third-party expertise.\nRemove Section 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 Numbering Resources are allocated for a period of one year. The allocation can be renewed on application to ARIN providing information as to why an extended time is necessary for a successful experiment. 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.\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 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.\nSection 11.6\nCurrent text:\n11.6. Resource Allocation Fees\nARIN may charge an administration fee to cover each allocation made of these experimental resources. This fee simply covers registration and maintenance, rather than the full allocation process for standard ARIN members. This administration fee should be as low as possible as these requests do not have to undergo the same evaluation process as those requested in the normal policy environment.\nProposed text:\n11.6. Resource Allocation Fees\nARIN may charge an administration fee to cover each allocation made of these experimental resources. This fee simply covers registration and maintenance, rather than the full allocation process for standard ARIN members. This administration fee should be as low as possible as these requests do not have to undergo the same evaluation process as those requested in the normal policy environment.\nSection 11.9\nCurrent text:\n11.9. Resource Request Appeal or Arbitration\nARIN reserves the ability to assess and comment on the objectives of the experiment with regard to the requested amount of Numbering Resources and its technical coordination. ARIN reserves the ability to modify the requested allocation as appropriate, and in agreement with the proposer. In the event that the proposed modifications are not acceptable, the requesting organization may request an appeal or arbitration using the normal ARIN procedures. In this case, the original proposer of the experimental activity may be requested to provide additional information regarding the experiment, its objectives and the manner of technical coordination, to assist in the resolution of the appeal.\nProposed text:\n11.9. Resource Request Appeal or Arbitration\nARIN reserves the ability to modify the requested allocation as appropriate, in agreement with the proposer. In the event that the proposed modifications are not acceptable, the requesting organization may request an appeal or arbitration using the normal ARIN procedures. In this case, the original proposer of the experimental activity may be requested to provide additional information regarding the experiment, its objectives and the manner of technical coordination, to assist in the resolution of the appeal.\n","implementationTime": "Immediate  ","lastUpdated": "2022-06-15",
    "url": "https://www.arin.net/participate/policy/proposals/2022/ARIN_prop_316_orig/"
    },{
    "title": "ARIN-prop-315: Editorial Clean-up of NRPM Section 2.16",
    "originators": ["Chris Tacit", "Joe Provo", "Matthew Wilder", "Rob Seastrom"],
    "status": "Implemented",
    "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\n1.  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\n2.  In 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  ","comments": "\n- This proposal is intended to be editorial in nature and to replace Prop-305 in part.\n- 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.","lastUpdated": "2022-06-14",
    "url": "https://www.arin.net/participate/policy/proposals/2022/ARIN_prop_315_orig/"
    },{
    "title": "ARIN-prop-314: Clean-up of NRPM – Introduction of Section 2.17",
    "originators": ["Chris Tacit", "Joe Provo", "Matthew Wilder", "Rob Seastrom"],
    "status": "Implemented",
    "problemStatement": "\nAlthough the term "IANA" appears throughout Section 10 of the NRPM, there is no reference to any definition of the term. This proposal defines the term with reference to appropriate ICANN documentation.\n","policyStatement": "Policy statement\nIntroduce a new Section 2.17 that reads as follows:\n"2.17 Internet Assigned Names and Numbers (IANA)\nThe term Internet Assigned Names and Numbers (IANA) refers to a set of functions described in the document entitled IANA FUNCTIONS: THE BASICS issued by the Internet Corporation for Assigned Names and Numbers (ICANN).\n","implementationTime": "Immediate  ","comments": "\nAlthough 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.","lastUpdated": "2022-06-14",
    "url": "https://www.arin.net/participate/policy/proposals/2022/ARIN_prop_314_orig/"
    },{
    "title": "ARIN-prop-313: Editorial Clean-up of NRPM Sections 2.12 and 2.14",
    "originators": ["Chris Tacit", "Joe Provo", "Matthew Wilder", "Rob Seastrom"],
    "status": "Implemented",
    "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","comments": "\nThis proposal is intended to be editorial in nature and to replace Prop-305 in part.","lastUpdated": "2022-06-14",
    "url": "https://www.arin.net/participate/policy/proposals/2022/ARIN_prop_313_orig/"
    },{
    "title": "ARIN-prop-312: Clean-up of NRPM Section 2.11",
    "originators": ["Chris Tacit", "Joe Provo", "Matthew Wilder", "Rob Seastrom"],
    "status": "Implemented",
    "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": "Policy statement\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" to "to the community it services" in the second line.\n","implementationTime": "Immediate","comments": "\nThis 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.","lastUpdated": "2022-06-14",
    "url": "https://www.arin.net/participate/policy/proposals/2022/ARIN_prop_312_orig/"
    },{
    "title": "ARIN-prop-311: Editorial Clean-up of NRPM Sections 2.4 and 2.5",
    "originators": ["Chris Tacit", "Joe Provo", "Matthew Wilder", "Rob Seastrom"],
    "status": "Implemented",
    "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": "Policy statement\nIn Section 2.4, change the text "address space" to "IP address space", and remove the comma after the text "(ISPs)", and in Section 2.5, change the text "Address space" to "IP address space" in each of the first four paragraphs and change the text "address space" to "IP address space" in the last paragraph.\n","implementationTime": "Immediate  ","comments": "\nThis proposal is intended to be editorial in nature and to replace Prop-305 in part.","lastUpdated": "2022-06-14",
    "url": "https://www.arin.net/participate/policy/proposals/2022/ARIN_prop_311_orig/"
    },{
    "title": "ARIN-prop-310: Clean-up of NRPM Sections 2.1 and 2.2",
    "originators": ["Chris Tacit", "Joe Provo", "Matthew Wilder", "Rob Seastrom"],
    "status": "Implemented",
    "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": "Policy statement\nIn Section 2.1, change the text "IP address space" to "Internet numbering resources", and in Section 2.2, change the text "address space" to "numbering resources" to reflect all of the types of Internet numbering resources administered by the types of entities defined in those sections.\n","implementationTime": "Immediate","comments": "\nThis 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.","lastUpdated": "2022-06-14",
    "url": "https://www.arin.net/participate/policy/proposals/2022/ARIN_prop_310_orig/"
    },{
    "title": "ARIN-prop-309: Remove officer attestation requirement for 8.5.5",
    "originators": ["Alison Wood", "Alyssa Quinn", "Anita Nikolich (The ARIN Advisory Council Policy Experience Working Group)"],
    "status": "Implemented",
    "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","comments": "\n* This is the only remaining mention outside Section 9 (which makes good use of the restrictions it has).\n* 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.","lastUpdated": "2022-06-06",
    "url": "https://www.arin.net/participate/policy/proposals/2022/ARIN_prop_309_orig/"
    },{
    "title": "ARIN-prop-308: Leasing not Intended",
    "originators": ["Fernando Frediani", "Jordi Palet Martínez", "Noah Maina"],
    "status": "Abandoned",
    "problemStatement": "\nRIRs have been conceived to manage, allocate and assign resources according to need, in such way that a LIR/ISP has addresses to be able to directly connect its customers based on justified need. Addresses are not, therefore, a property with which to trade or do business.\nIPv6 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.\nWhen the justification of the need disappears, for whatever reasons, the most honorable thing would be to return said addresses to the RIR. An alternative is the transfer of these resources and we have appropriate policies for that.\nIf the leasing of addresses is authorized, contrary to the original spirit of the policies and the very existence of the RIRs, the link between connectivity and addresses disappears, which also poses security problems, since, in the absence of connectivity, the resource holder who has received the license to use the addresses does not have immediate physical control to manage/filter them, which can cause damage to the entire community.\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": "Policy statement\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","lastUpdated": "2022-03-28",
    "url": "https://www.arin.net/participate/policy/proposals/2022/ARIN_prop_308_orig/"
    },{
    "title": "ARIN-prop-307: Remove Barrier to BGP Uptake in ASN Policy",
    "originators": ["Robert Seastrom"],
    "status": "Implemented",
    "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.\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!\nVetting as embodied in existing policy or evolved in ARIN-2021-3 should be reserved for those requesting more than one ASN per organization or discrete network.\nNote that this proposal is non-interfering with ARIN-2021-3 which is intended to make the NRPM more understandable.\n","policyStatement": "Policy statement\nInsert the following paragraph at the beginning of section 5:\nAny organization may be issued a single four-octet (32 bit) Autonomous Systen Number (ASN) upon request. Organizations that have space issued under Multiple Discrete Networks policy may be issued a four-octet (32 bit) ASN per discrete network upon request.\nReplace the introductory sentence:\nThere are a limited number of available Autonomous System Numbers (AS Numbers), therefore, it is important to determine which sites require unique AS Numbers and which do not.\nwith\nIssuance of ASNs outside of the scope outlined above is subject to the following constraints:\n","implementationTime": "Immediate","lastUpdated": "2022-03-11",
    "url": "https://www.arin.net/participate/policy/proposals/2022/ARIN_prop_307_orig/"
    }]