CINXE.COM

<!DOCTYPE html> <html lang="en-us"> <head> <title>Number Resource Policy Manual - American Registry for Internet Numbers</title> <meta charset="utf-8" /> <meta http-equiv="X-UA-Compatible" content="IE=edge" /> <meta name="viewport" content="width=device-width,minimum-scale=1" /> <meta name="description" content="Version 2024.1 - 21 August 2024 This is ARIN’s Number Resource Policy Manual (NRPM). It is available at: https://www.arin.net/policy/. This version …" /> <meta name="keywords" content="" /> <meta name="revised" content="1731444244" /> <meta name="priority" content="1" /> <meta property="og:url" content="https://www.arin.net/participate/policy/nrpm/" /> <meta property="og:type" content="website" /> <meta property="og:title" content="Number Resource Policy Manual" /> <meta property="og:description" content="Version 2024.1 - 21 August 2024 This is ARIN’s Number Resource Policy Manual (NRPM). It is available at: https://www.arin.net/policy/. This version …" /> <meta property="og:image" content="https://www.arin.net/img/logo-social.png" /> <meta name="twitter:card" content="summary" /> <meta name="twitter:site" content="@teamarin" /> <link rel="canonical" href="https://www.arin.net/participate/policy/nrpm/" /> <link rel="shortcut icon" href="/img/favicon.ico" /> <link rel="alternate" type="application/rss+xml" href="https://www.arin.net/participate/policy/nrpm/rss.xml" title="American Registry for Internet Numbers" /> <link href="/css/styles.min.6c6669958b555f97880037d753019294043c6a4ca4bd29527905afd52d1f9507.css" rel="stylesheet" type="text/css" /> <link href="/css/font-awesome.min.css" rel="stylesheet" type="text/css" /> <script src="/js/head-scripts.min.js"></script> <script src="/js/externals.js"></script> </head> <body class="d-flex flex-column"> <noscript><iframe src="https://www.googletagmanager.com/ns.html?id=GTM-5VJ67SD" height="0" width="0" style="display:none;visibility:hidden"></iframe></noscript> <div class="flex-shrink-0"> <header> <div class="container-fluid" id="top-bar"> <a href="#main-con" class="skip-link visually-hidden-focusable">Skip to main content</a> <div class="header-con"> <div class="row"> <div id="top-bar-logo"><a href="/"><img src="/img/logo-inverse-nowords.svg" alt="The ARIN logo" /></a></div> <div id="display-ip"> <p> <a id="scroll-icon-link" href="/" aria-label="Home"><img id="scroll-icon" src="/img/icon-inverse-color.svg" alt="The ARIN logo" /></a> Your IP<span id="ip-type"></span> address is <strong id="ip-address"></strong> </p> </div> <div id="login-links"><a id="login-link-outage" href="https://www.arin.net/notices" data-bs-toggle="tooltip" data-bs-placement="left" data-bs-container="#top-bar" title="Services currently unavailable" style="display:none"> <i class="fa fa-ban fa-fw" aria-hidden="true"></i> <span>Log in</span> </a> <span id="notification-link-container"></span> <a id="login-link" href="https://account.arin.net/public/login"> <i class="fa fa-user fa-fw" aria-hidden="true"></i> <span>Log in</span> </a> <a id="account-link-container" aria-expanded="false" href="javascript:void(0)"> <i class="fa fa-user fa-fw" aria-hidden="true"></i> <span id="account-link">User</span> <i class="fa fa-caret-down fa-fw" aria-hidden="true"></i> </a> </p> <div id="account-link-dropdown"> <ul id="account-link-dropdown-list"> <li id="account-dashboard-item"> <a id="account-dashboard-link" class="account-link-action" href="https://account.arin.net/public/secure/dashboard"> <i class="fa fa-fw fa-dashboard"></i> Dashboard </a> </li> <li id="account-settings-item"> <a id="account-settings-link" class="account-link-action" href="https://account.arin.net/public/secure/profile"> Settings <small>Profile and security information</small> </a> </li> <li> <a id="account-logout-link" href="https://account.arin.net/public/logout"> Log Out </a> </li> </ul> </div> </div> </div> </div> </div> <div class="container-fluid" id="logo-bar"> <div class="header-con"> <div class="row" id="universal-links"> <div id="logo-con"> <a href="/" aria-label="Home"> <img src="/img/logo-stnd.svg" alt="The ARIN logo" /> </a> </div> <div id="search-con"> <div class="input-group" role="search" aria-label="Universal Search"> <input type="text" name="q" id="input-box" class="form-control" placeholder="Search Site or Whois" aria-label="Search Site or Whois" onkeyup="InputChanged(event, document.getElementById('input-box').value)" /> <button class="btn btn-navbar" type="button" onclick="Search(document.getElementById('input-box').value)">Search</button> </div> </div> <span class="search-tou">all requests subject to <a href="/resources/registry/whois/tou/">terms of use</a>  </span> </div> </div> </div> <script src="https://code.jquery.com/jquery-3.4.1.min.js" integrity="sha256-CSXorXvZcTkaix6Yvo6HppcZGetbYMGWSFlBw8HfCJo=" crossorigin="anonymous"></script> <script type="text/javascript">var $aj2 = jQuery.noConflict();</script> </header> <div class="container-fluid" id="nav-wrapper" data-sj-ignore> <div class="container"> <nav class="navbar navbar-expand-lg bg-light navbar-light yamm" aria-label="main navigation"> <a class="navbar-brand" href="/" aria-label="Home"><i class='fa fa-home fa-fw'></i></a> <button class="btn btn-navbar" id="navbar-search-btn" type="button" href="javascript:void(0)" onclick="Search()"> <span class="visually-hidden">Search</span> <i class="fa fa-lg fa-search"></i> </button> <button class="navbar-toggler" type="button" data-bs-toggle="collapse" data-bs-target="#js-navbar-collapse" aria-controls="js-navbar-collapse" aria-expanded="false" aria-label="Toggle navigation"> <span class="navbar-toggler-icon"></span> </button> <div id="js-navbar-collapse" class="collapse navbar-collapse js-navbar-collapse"> <ul class="navbar-nav"> <li class="nav-item drophover yamm-fw"> <a href="/resources/" class="nav-link drophover-toggle">IP Addresses & ASNs</a><ul class="drophover-menu"> <li> <div class="yamm-content"> <div class="row"> <ul> <li class="mega-header"> <a href="/resources/guide/">Get Started</a> </li> <li><a href="/resources/guide/account/">ARIN Account Management</a></li> <li><a href="/resources/guide/request/">Requesting IP Addresses or ASNs</a></li> <li><a href="/resources/guide/ipv6/">IPv6 Information</a></li> <li><a href="/resources/guide/ipv4/">IPv4 Addressing Options</a></li> <li><a href="/resources/guide/asn/">Autonomous System Numbers</a></li> <li><a href="/resources/guide/legacy/">Legacy Resources at ARIN</a></li> </ul> <ul> <li class="mega-header"> <a href="/resources/fees/">Fee & Billing Information</a> </li> <li><a href="/resources/fees/fee_schedule/">Fee Schedule</a></li> <li><a href="/resources/fees/psp/">Premier Support Plan (PSP)</a></li> <li><a href="/resources/fees/payment/">Make a Payment</a></li> <li><a href="/resources/fees/contact/">How Billing Works</a></li> <li><a href="/resources/fees/returns/">Resource Revocation, Returns, and Reinstatement</a></li> </ul> <ul> <li class="mega-header"> <a href="/resources/registry/">IP & ASN Registry Services</a> </li> <li><a href="/resources/registry/manage/">Managing Resource Records</a></li> <li><a href="/resources/registry/transfers/">Transferring IP Addresses & ASNs</a></li> <li><a href="/resources/registry/reassignments/">Reporting Reassignments</a></li> <li><a href="/resources/registry/originas/">Autonomous System Originations (Origin AS)</a></li> <li><a href="/resources/registry/whois/">Using Whois</a></li> </ul> <ul> <li class="mega-header"> <a href="/resources/manage/">Resource Management Services</a> </li> <li><a href="/resources/manage/regrws/">Automating Record Management with Reg-RWS</a></li> <li><a href="/resources/manage/dnssec/">Securing DNS (DNSSEC)</a></li> <li><a href="/resources/manage/routingsecurity/">Routing Security Eligibility FAQs</a></li> <li><a href="/resources/manage/rpki/">Resource Certification (RPKI)</a></li> <li><a href="/resources/manage/irr/">Internet Routing Registry (IRR)</a></li> <li><a href="/resources/manage/reverse/">Reverse DNS</a></li> </ul> </div> </div> </li> </ul></li> <li class="nav-item drophover yamm-fw wayfinder"> <a href="/participate/" class="nav-link drophover-toggle">Policy & Participation</a><ul class="drophover-menu"> <li> <div class="yamm-content"> <div class="row"> <ul> <li class="mega-header"> <a href="/participate/policy/">Policy</a> </li> <li><a href="/participate/policy/nrpm/">Number Resource Policy Manual</a></li> <li><a href="/participate/policy/pdp/">Policy Development Process (PDP)</a></li> <li><a href="/participate/policy/drafts/">Draft and Recommended Draft Policies</a></li> <li><a href="/participate/policy/proposals/">Policy Proposals</a></li> </ul> <ul> <li class="mega-header"> <a href="/participate/meetings/">Meetings & Events</a> </li> <li><a href="/participate/meetings/upcoming/">Public Policy and Members Meetings</a></li> <li><a href="/participate/meetings/outreach/">Outreach Events</a></li> <li><a href="/participate/meetings/fellowships/">ARIN Fellowship Program</a></li> <li><a href="/participate/meetings/sponsors/">Sponsorship</a></li> <li><a href="/participate/meetings/past/">Past Meetings</a></li> </ul> <ul> <li class="mega-header"> <a href="/participate/oversight/">Membership & Elections</a> </li> <li><a href="/participate/oversight/membership/">Membership</a></li> <li><a href="/participate/oversight/elections/">Elections</a></li> </ul> <ul> <li class="mega-header"> <a href="/participate/community/">Community Interaction</a> </li> <li><a href="/participate/community/community_surveys/">ARIN Community Satisfaction Surveys</a></li> <li><a href="/participate/community/mailing_lists/">Mailing Lists</a></li> <li><a href="/participate/community/acsp/">Consultations & Suggestions</a></li> </ul> </div> </div> </li> </ul></li> <li class="nav-item drophover yamm-fw"> <a href="/reference/" class="nav-link drophover-toggle">Reference & Tools</a><ul class="drophover-menu"> <li> <div class="yamm-content"> <div class="row"> <ul> <li class="mega-header"> <a href="/reference/tools/">Tools</a> </li> <li><a href="/reference/tools/testing/">Operational Test and Evaluation (OT&E) Environment</a></li> <li><a href="/reference/tools/cidr/">CIDR Calculator</a></li> <li><a href="/reference/tools/software/">Community Software Repository</a></li> <li><a href="/reference/tools/fraud_report/">Internet Number Resource Fraud Reporting</a></li> </ul> <ul> <li class="mega-header"> <a href="/reference/materials/">Reference</a> </li> <li><a href="/reference/materials/abuse/">Spam & Network Abuse Reporting</a></li> <li><a href="/reference/materials/data/">Registry Data Description</a></li> <li><a href="/reference/materials/accuracy/">Data Accuracy</a></li> <li><a href="/reference/materials/security/">Information Security at ARIN</a></li> <li><a href="/reference/materials/software/">ARIN Software Releases</a></li> </ul> <ul> <li class="mega-header"> <a href="/reference/research/">Research</a> </li> <li><a href="/reference/research/statistics/">Statistics & Reporting</a></li> <li><a href="/reference/research/whowas/">Historical Whois Data (WhoWas)</a></li> <li><a href="/reference/research/bulkwhois/">Bulk Whois Data</a></li> </ul> <ul> <li class="mega-header"> <a href="/reference/training/">Training & Education</a> </li> <li><a href="/reference/training/leadership/">ARIN Leadership Development Program</a></li> <li><a href="/reference/training/webinars/">Instructional Webinars</a></li> <li><a href="/reference/training/resources/">Resource Materials</a></li> <li><a href="/reference/training/help_videos/">ARIN Online Help Videos</a></li> </ul> </div> </div> </li> </ul></li> <li class="nav-item drophover yamm-fw"> <a href="/about/" class="nav-link drophover-toggle">About</a><ul class="drophover-menu"> <li> <div class="yamm-content"> <div class="row"> <ul> <li class="mega-header"> <a href="/about/welcome/">Welcome to ARIN</a> </li> <li><a href="/about/welcome/staff/">Organization Structure & Staff</a></li> <li><a href="/about/welcome/region/">Our Region</a></li> <li><a href="/about/welcome/board/">ARIN Board of Trustees</a></li> <li><a href="/about/welcome/ac/">Advisory Council</a></li> <li><a href="/about/welcome/nronc/">NRO Number Council</a></li> <li><a href="/about/welcome/careers/">Careers</a></li> </ul> <ul> <li class="mega-header"> <a href="/about/corporate/">Corporate Documentation</a> </li> <li><a href="/about/corporate/documents/">Corporate Documents</a></li> <li><a href="/about/corporate/annual/">Annual Reports</a></li> <li><a href="/about/corporate/planning/">Strategic Planning & Budgeting</a></li> <li><a href="/about/corporate/agreements/">Agreements</a></li> <li><a href="/about/corporate/history/">History of ARIN</a></li> <li><a href="/about/corporate/vendors/">Third-Party Vendors and IPv6</a></li> </ul> <ul> <li class="mega-header"> <a href="/about/community_grants/">Community Grants</a> </li> <li><a href="/about/community_grants/program/">ARIN Community Grant Program</a></li> <li><a href="/about/community_grants/recipients/">Community Grant Program Recipients</a></li> </ul> <ul> <li class="mega-header"> <a href="/about/relations/">External Relations</a> </li> <li><a href="/about/relations/governance/">Internet Governance</a></li> <li><a href="/about/relations/membership/">Memberships, Sponsorships, and MOUs</a></li> <li><a href="/about/relations/law_enforcement/">Law Enforcement & Public Safety</a></li> <li><a href="/about/relations/community/">Technical Community</a></li> </ul> </div> </div> </li> </ul></li> <li class="nav-item drophover yamm-fw"> <a href="/blog/" class="nav-link drophover-toggle no-caret">Blog</a></li> </ul> <a id="payment-btn" class="btn navbar-btn ms-auto" href="/resources/fees/payment" role="button">Pay Now</a> <a id="feedback-btn" class="btn navbar-btn outage-guard" href="javascript:void(0)" role="button">Feedback</a> </div> </nav> </div> </div> <nav class="container" id="bread-con" aria-label="Breadcrumb"> <ol class="breadcrumb"> <li class="breadcrumb-item"><a href="https://www.arin.net" aria-label="Home">Home</a></li> <li class="breadcrumb-item"><a href="https://www.arin.net/participate/">Policy & Participation</a></li> <li class="breadcrumb-item"><a href="https://www.arin.net/participate/policy/">Policy</a></li> <li class="breadcrumb-item active" aria-current="page">Number Resource Policy Manual</li> </ol> <ol class="breadcrumb breadcrumb-mobile"> <li class="breadcrumb-item"><a href="https://www.arin.net/participate/policy/">Policy</a></li> </ol> </nav> <div class="container" id="main-con" role="main"> <h1>Number Resource Policy Manual</h1> <div class="row"> <div id="main-text" class="two-col-text"> <p><strong>Version 2024.1 - 21 August 2024</strong></p> <p>This is ARIN’s Number Resource Policy Manual (NRPM). It is available at: <a href="/participate/policy/">https://www.arin.net/policy/</a>. This version supersedes all previous versions.</p> <p>Number resource policies in the ARIN region are created in accordance with the “Policy Development Process” (<a href="/participate/policy/pdp/">https://www.arin.net/policy/pdp.html</a>). The status of current and historical policy proposals can be found on the Policy Proposal page (<a href="/participate/policy/drafts/">https://www.arin.net/policy/proposals/</a>).</p> <p>Each policy consists of a number of component parts separated by dots. The first figure to the far left and preceding the first dot (.), refers to the chapter number. The figure following the first dot indicates a policy section. Any subsequent figures are for the purpose of identifying specific parts of a given policy.</p> <div class="toc-nrpm"> <h2 id="toc-header" class="has-toggle nrpm-toc" aria-label="Click to hide the table of contents">Contents</h2> <a href="#nrpm-main" class="btn btn-light toc-skip visually-hidden-focusable">Skip to main text</a> <nav id="TableOfContents"> <ul> <li><a href="#1-principles-and-goals-of-the-american-registry-for-internet-numbers-arin">1. Principles and Goals of the American Registry for Internet Numbers (ARIN)</a> <ul> <li><a href="#1-1-registration">1.1. Registration</a></li> <li><a href="#1-2-conservation">1.2. Conservation</a></li> <li><a href="#1-3-routability">1.3. Routability</a></li> <li><a href="#1-4-stewardship">1.4. Stewardship</a></li> </ul> </li> <li><a href="#2-definitions">2. Definitions</a> <ul> <li><a href="#2-1-internet-registry-ir">2.1. Internet Registry (IR)</a></li> <li><a href="#2-2-regional-internet-registry-rir">2.2. Regional Internet Registry (RIR)</a></li> <li><a href="#2-3-retired">2.3. [Retired]</a></li> <li><a href="#2-4-local-internet-registry-lir">2.4. Local Internet Registry (LIR)</a></li> <li><a href="#2-5-allocation-assignment-reallocation-reassignment">2.5. Allocation, Assignment, Reallocation, Reassignment</a></li> <li><a href="#2-6-end-user">2.6. End-user</a></li> <li><a href="#2-7-multihomed">2.7. Multihomed</a></li> <li><a href="#2-8-registration-services-agreement-rsa">2.8. Registration Services Agreement (RSA)</a></li> <li><a href="#2-9-autonomous-system-number-asn">2.9. Autonomous System Number (ASN)</a></li> <li><a href="#2-10-end-site">2.10. End Site</a></li> <li><a href="#2-11-community-network">2.11. Community Network</a></li> <li><a href="#2-12-organizational-information">2.12. Organizational Information</a></li> <li><a href="#2-13-residential-customer">2.13. Residential Customer</a></li> <li><a href="#2-14-serving-site-ipv6">2.14. Serving Site (IPv6)</a></li> <li><a href="#2-15-provider-assignment-unit-ipv6">2.15. Provider Assignment Unit (IPv6)</a></li> <li><a href="#2-16-utilized-ipv6">2.16. Utilized (IPv6)</a></li> <li><a href="#2-17-internet-number-resources">2.17. Internet Number Resources</a></li> </ul> </li> <li><a href="#3-directory-services">3. Directory Services</a> <ul> <li><a href="#3-1-bulk-copies-of-arin-s-whois">3.1. Bulk Copies of ARIN’s Whois</a></li> <li><a href="#3-2-distributed-information-service-use-requirements">3.2. Distributed Information Service Use Requirements</a></li> <li><a href="#3-3-privatizing-poc-information">3.3. Privatizing POC Information</a></li> <li><a href="#3-4-routing-registry">3.4. Routing Registry</a> <ul> <li><a href="#3-4-1-acceptable-use-policy">3.4.1. Acceptable Use Policy</a></li> </ul> </li> <li><a href="#3-5-retired">3.5. [Retired]</a></li> <li><a href="#3-6-annual-validation-of-arin-s-public-whois-point-of-contact-data">3.6. Annual Validation of ARIN’s Public Whois Point of Contact Data</a> <ul> <li><a href="#3-6-1-annual-poc-verification">3.6.1. Annual POC Verification</a></li> <li><a href="#3-6-2-specified-public-whois-points-of-contact-for-verification">3.6.2. Specified Public Whois Points of Contact for Verification</a></li> <li><a href="#3-6-3-organizations-covered-by-this-policy">3.6.3. Organizations Covered by this Policy</a></li> <li><a href="#3-6-4-procedure-for-verification">3.6.4. Procedure for Verification</a></li> <li><a href="#3-6-5-non-responsive-point-of-contact-records">3.6.5. Non-Responsive Point of Contact Records</a></li> </ul> </li> <li><a href="#3-7-poc-notification-and-validation-upon-reassignment-or-reallocation">3.7 POC Notification and Validation Upon Reassignment or Reallocation</a></li> <li><a href="#3-8-directory-service-records">3.8. Directory Service Records</a> <ul> <li><a href="#3-8-1-organization-record-creation">3.8.1 Organization Record Creation</a></li> </ul> </li> </ul> </li> <li><a href="#4-ipv4">4. IPv4</a> <ul> <li><a href="#4-1-general-principles">4.1. General Principles</a> <ul> <li><a href="#4-1-1-4-1-2-4-1-3-4-1-4-retired">4.1.1., 4.1.2., 4.1.3., 4.1.4. [Retired]</a></li> <li><a href="#4-1-5-resource-request-size">4.1.5. Resource Request Size</a></li> <li><a href="#4-1-6-aggregation">4.1.6. Aggregation</a></li> <li><a href="#4-1-7-reserved-pool-replenishment">4.1.7. Reserved Pool Replenishment</a> <ul> <li><a href="#4-1-7-1-disposition-of-resources">4.1.7.1. Disposition of Resources</a></li> <li><a href="#4-1-7-2-precedence-for-replenishment">4.1.7.2. Precedence for Replenishment</a></li> </ul> </li> <li><a href="#4-1-8-arin-waitlist">4.1.8. ARIN Waitlist</a> <ul> <li><a href="#4-1-8-1-sequencing">4.1.8.1. Sequencing</a></li> <li><a href="#4-1-8-2-fulfillment">4.1.8.2. Fulfillment</a></li> <li><a href="#4-1-8-3-qualification">4.1.8.3. Qualification</a></li> </ul> </li> <li><a href="#4-1-9-retired">4.1.9. [Retired]</a></li> </ul> </li> <li><a href="#4-2-allocations-to-isps-requirements-for-requesting-initial-address-space">4.2. Allocations to ISPs (Requirements for Requesting Initial Address Space)</a> <ul> <li><a href="#4-2-1-principles">4.2.1. Principles</a> <ul> <li><a href="#4-2-1-1-purpose">4.2.1.1. Purpose</a></li> <li><a href="#4-2-1-2-retired">4.2.1.2. [Retired]</a></li> <li><a href="#4-2-1-3-utilization-rate">4.2.1.3. Utilization Rate</a></li> <li><a href="#4-2-1-4-retired">4.2.1.4. [Retired]</a></li> <li><a href="#4-2-1-5-minimum-allocation">4.2.1.5. Minimum Allocation</a></li> <li><a href="#4-2-1-6-retired">4.2.1.6. [Retired]</a></li> </ul> </li> <li><a href="#4-2-2-initial-allocation-to-isps">4.2.2. Initial Allocation to ISPs</a></li> <li><a href="#4-2-3-reassigning-and-reallocating-address-space-to-customers">4.2.3. Reassigning and Reallocating Address Space to Customers</a> <ul> <li><a href="#4-2-3-1-efficient-utilization">4.2.3.1. Efficient Utilization</a></li> <li><a href="#4-2-3-2-vlsm">4.2.3.2. VLSM</a></li> <li><a href="#4-2-3-3-contiguous-blocks">4.2.3.3. Contiguous Blocks</a></li> <li><a href="#4-2-3-4-downstream-customer-adherence">4.2.3.4. Downstream Customer Adherence</a></li> <li><a href="#4-2-3-4-1-utilization">4.2.3.4.1. Utilization</a></li> <li><a href="#4-2-3-4-2-downstream-isps">4.2.3.4.2. Downstream ISPs</a></li> <li><a href="#4-2-3-5-retired">4.2.3.5. [Retired]</a></li> <li><a href="#4-2-3-6-reassignments-to-multihomed-downstream-customers">4.2.3.6. Reassignments to Multihomed Downstream Customers</a></li> <li><a href="#4-2-3-7-registration">4.2.3.7. Registration</a> <ul> <li><a href="#4-2-3-7-1-reassignment-and-reallocation-information">4.2.3.7.1. Reassignment and Reallocation Information</a></li> </ul> </li> <li><a href="#4-2-3-7-2-reassignments-and-reallocations-visible-within-seven-days">4.2.3.7.2. Reassignments and Reallocations Visible Within Seven Days</a></li> <li><a href="#4-2-3-7-3-residential-subscribers">4.2.3.7.3. Residential Subscribers</a></li> <li><a href="#4-2-3-7-3-1-retired">4.2.3.7.3.1. [Retired]</a></li> <li><a href="#4-2-3-7-3-2-residential-customer-privacy">4.2.3.7.3.2. Residential Customer Privacy</a></li> <li><a href="#4-2-3-8-reassignments-for-third-party-internet-access-tpia-over-cable">4.2.3.8. Reassignments for Third Party Internet Access (TPIA) over Cable</a></li> </ul> </li> <li><a href="#4-2-4-isp-additional-requests">4.2.4. ISP Additional Requests</a> <ul> <li><a href="#4-2-4-1-utilization-percentage-80">4.2.4.1. Utilization Percentage (80%)</a></li> <li><a href="#4-2-4-2-return-address-space-as-agreed">4.2.4.2. Return Address Space as Agreed</a></li> <li><a href="#4-2-4-3-request-size">4.2.4.3. Request Size</a></li> <li><a href="#4-2-4-4-retired">4.2.4.4. [Retired]</a></li> </ul> </li> <li><a href="#4-2-5-4-2-6-retired">4.2.5., 4.2.6. [Retired]</a></li> </ul> </li> <li><a href="#4-3-end-users-assignments-to-end-users">4.3. End-users - Assignments to End-users</a> <ul> <li><a href="#4-3-1-end-users">4.3.1. End-users</a></li> <li><a href="#4-3-2-minimum-assignment">4.3.2. Minimum Assignment</a></li> <li><a href="#4-3-3-utilization-rate">4.3.3. Utilization Rate</a></li> <li><a href="#4-3-4-retired">4.3.4. [Retired]</a></li> <li><a href="#4-3-5-non-connected-networks">4.3.5. Non-connected Networks</a></li> <li><a href="#4-3-6-additional-assignments">4.3.6. Additional Assignments</a> <ul> <li><a href="#4-3-6-1-utilization-requirements-for-additional-assignment">4.3.6.1. Utilization Requirements for Additional Assignment</a></li> </ul> </li> </ul> </li> <li><a href="#4-4-micro-allocation">4.4. Micro-allocation</a></li> <li><a href="#4-5-multiple-discrete-networks">4.5. Multiple Discrete Networks</a></li> <li><a href="#4-6-4-7-4-8-4-9-retired">4.6., 4.7., 4.8., 4.9. [Retired]</a></li> <li><a href="#4-10-dedicated-ipv4-allocation-to-facilitate-ipv6-deployment">4.10. Dedicated IPv4 Allocation to Facilitate IPv6 Deployment</a></li> </ul> </li> <li><a href="#5-as-numbers">5. AS Numbers</a> <ul> <li><a href="#5-1-retired">5.1. [Retired]</a></li> </ul> </li> <li><a href="#6-ipv6">6. IPv6</a> <ul> <li><a href="#6-1-introduction">6.1. Introduction</a> <ul> <li><a href="#6-1-1-overview">6.1.1. Overview</a></li> </ul> </li> <li><a href="#6-2-retired">6.2. [Retired]</a></li> <li><a href="#6-3-goals-of-ipv6-address-space-management">6.3. Goals of IPv6 Address Space Management</a> <ul> <li><a href="#6-3-1-goals">6.3.1. Goals</a></li> <li><a href="#6-3-2-uniqueness">6.3.2. Uniqueness</a></li> <li><a href="#6-3-3-registration">6.3.3. Registration</a></li> <li><a href="#6-3-4-aggregation">6.3.4. Aggregation</a></li> <li><a href="#6-3-5-conservation">6.3.5. Conservation</a></li> <li><a href="#6-3-6-fairness">6.3.6. Fairness</a></li> <li><a href="#6-3-7-minimized-overhead">6.3.7. Minimized Overhead</a></li> <li><a href="#6-3-8-conflict-of-goals">6.3.8. Conflict of Goals</a></li> </ul> </li> <li><a href="#6-4-ipv6-policy-principles">6.4. IPv6 Policy Principles</a> <ul> <li><a href="#6-4-1-address-space-not-to-be-considered-property">6.4.1. Address Space Not to be Considered Property</a></li> <li><a href="#6-4-2-routability-not-guaranteed">6.4.2. Routability Not Guaranteed</a></li> <li><a href="#6-4-3-retired">6.4.3. [Retired]</a></li> <li><a href="#6-4-4-consideration-of-ipv4-infrastructure">6.4.4. Consideration of IPv4 Infrastructure</a></li> </ul> </li> <li><a href="#6-5-policies-for-allocations-and-assignments">6.5. Policies for Allocations and Assignments</a> <ul> <li><a href="#6-5-1-terminology">6.5.1. Terminology</a></li> <li><a href="#6-5-2-initial-allocation-to-lirs">6.5.2. Initial Allocation to LIRs</a> <ul> <li><a href="#6-5-2-1-size">6.5.2.1. Size</a></li> <li><a href="#6-5-2-2-qualifications">6.5.2.2. Qualifications</a></li> </ul> </li> <li><a href="#6-5-3-subsequent-allocations-to-lirs">6.5.3. Subsequent Allocations to LIRs</a> <ul> <li><a href="#6-5-3-1-subsequent-allocations-for-transition">6.5.3.1. Subsequent Allocations for Transition</a></li> </ul> </li> <li><a href="#6-5-4-reassignments-from-lirs-isps">6.5.4. Reassignments from LIRs/ISPs</a> <ul> <li><a href="#6-5-4-1-reassignment-to-operator-s-infrastructure">6.5.4.1. Reassignment to Operator’s Infrastructure</a></li> </ul> </li> <li><a href="#6-5-5-registration">6.5.5. Registration</a> <ul> <li><a href="#6-5-5-1-reassignment-information">6.5.5.1. Reassignment Information</a></li> <li><a href="#6-5-5-2-reassignments-and-reallocations-visible-within-seven-days">6.5.5.2. Reassignments and Reallocations Visible Within Seven Days</a></li> <li><a href="#6-5-5-3-residential-subscribers">6.5.5.3. Residential Subscribers</a></li> <li><a href="#6-5-5-3-1-residential-customer-privacy">6.5.5.3.1. Residential Customer Privacy</a></li> <li><a href="#6-5-5-4-registration-requested-by-recipient">6.5.5.4. Registration Requested by Recipient</a></li> </ul> </li> <li><a href="#6-5-6-retired">6.5.6. [Retired]</a></li> <li><a href="#6-5-7-existing-ipv6-address-space-holders">6.5.7. Existing IPv6 Address Space Holders</a></li> <li><a href="#6-5-8-direct-assignments-from-arin-to-end-user-organizations">6.5.8. Direct Assignments from ARIN to End-user Organizations</a> <ul> <li><a href="#6-5-8-1-initial-assignment-criteria">6.5.8.1. Initial Assignment Criteria</a></li> <li><a href="#6-5-8-2-initial-assignment-size">6.5.8.2. Initial Assignment Size</a></li> <li><a href="#6-5-8-2-1-standard-sites">6.5.8.2.1. Standard Sites</a></li> <li><a href="#6-5-8-2-2-extra-large-sites">6.5.8.2.2. Extra-large Sites</a></li> <li><a href="#6-5-8-3-subsequent-assignments">6.5.8.3. Subsequent Assignments</a></li> <li><a href="#6-5-8-4-consolidation-and-return-of-separate-assignments">6.5.8.4. Consolidation and Return of Separate Assignments</a></li> </ul> </li> <li><a href="#6-5-9-community-network-allocations">6.5.9. Community Network Allocations</a> <ul> <li><a href="#6-5-9-1-qualification-criteria">6.5.9.1. Qualification Criteria</a></li> <li><a href="#6-5-9-2-allocation-size">6.5.9.2. Allocation Size</a></li> <li><a href="#6-5-9-3-reassignments-by-community-networks">6.5.9.3. Reassignments by Community Networks</a></li> </ul> </li> </ul> </li> <li><a href="#6-6-6-7-6-8-6-9-retired">6.6., 6.7., 6.8., 6.9. [Retired]</a></li> <li><a href="#6-10-micro-allocations">6.10. Micro-allocations</a> <ul> <li><a href="#6-10-1-micro-allocations-for-critical-infrastructure">6.10.1. Micro-allocations for Critical Infrastructure</a></li> <li><a href="#6-10-2-micro-allocations-for-internal-infrastructure">6.10.2. Micro-allocations for Internal Infrastructure</a></li> </ul> </li> <li><a href="#6-11-ipv6-multiple-discrete-networks">6.11. IPv6 Multiple Discrete Networks</a></li> </ul> </li> <li><a href="#7-retired">7. [Retired]</a></li> <li><a href="#8-transfers">8. Transfers</a> <ul> <li><a href="#8-1-principles">8.1. Principles</a></li> <li><a href="#8-2-mergers-acquisitions-and-reorganizations">8.2. Mergers, Acquisitions, and Reorganizations</a></li> <li><a href="#8-3-transfers-between-specified-recipients-within-the-arin-region">8.3. Transfers Between Specified Recipients Within the ARIN Region</a></li> <li><a href="#8-4-inter-rir-transfers-to-specified-recipients">8.4. Inter-RIR Transfers to Specified Recipients</a></li> <li><a href="#8-5-specified-transfer-recipient-requirements">8.5. Specified Transfer Recipient Requirements</a> <ul> <li><a href="#8-5-1-registration-services-agreement">8.5.1. Registration Services Agreement</a></li> <li><a href="#8-5-2-operational-use">8.5.2 Operational Use</a></li> <li><a href="#8-5-3-minimum-transfer-size">8.5.3. Minimum Transfer Size</a></li> <li><a href="#8-5-4-initial-block">8.5.4. Initial Block</a></li> <li><a href="#8-5-5-block-size">8.5.5. Block Size</a> <ul> <li><a href="#8-5-5-1-transfer-for-the-purpose-of-renumbering">8.5.5.1. Transfer for the Purpose of Renumbering</a> <ul> <li><a href="#8-5-5-1-1-smaller-block-size">8.5.5.1.1 Smaller Block Size</a></li> </ul> </li> </ul> </li> <li><a href="#8-5-6-efficient-utilization-of-previous-blocks">8.5.6. Efficient Utilization of Previous Blocks</a> <ul> <li><a href="#8-5-6-1-transfer-for-the-purpose-of-renumbering">8.5.6.1 Transfer for the Purpose of Renumbering</a></li> </ul> </li> <li><a href="#8-5-7-alternative-additional-ipv4-address-block-criteria">8.5.7. Alternative Additional IPv4 Address Block Criteria</a></li> </ul> </li> <li><a href="#8-6-wait-list-restrictions">8.6. Wait List Restrictions</a></li> </ul> </li> <li><a href="#9-out-of-region-use">9. Out of Region Use</a></li> <li><a href="#10-global-number-resource-policy">10. Global Number Resource Policy</a> <ul> <li><a href="#10-1-iana-to-rir-allocation-of-ipv4-address-space">10.1. IANA to RIR Allocation of IPv4 Address Space</a></li> <li><a href="#10-2-allocation-of-ipv6-address-space-by-the-internet-assigned-numbers-authority-iana-policy-to-regional-internet-registries">10.2. Allocation of IPv6 Address Space by the Internet Assigned Numbers Authority (IANA) Policy to Regional Internet Registries</a></li> <li><a href="#10-3-iana-policy-for-allocation-of-asn-blocks-to-rirs">10.3. IANA Policy for Allocation of ASN Blocks to RIRs</a></li> <li><a href="#10-4-global-policy-for-the-allocation-of-the-remaining-ipv4-address-space">10.4. Global Policy for the Allocation of the Remaining IPv4 Address Space</a> <ul> <li><a href="#10-4-1-existing-policy-phase">10.4.1. Existing Policy Phase</a></li> <li><a href="#10-4-2-exhaustion-phase">10.4.2. Exhaustion Phase</a> <ul> <li><a href="#10-4-2-1-size-of-the-final-ipv4-allocations">10.4.2.1. Size of the Final IPv4 Allocations</a></li> <li><a href="#10-4-2-2-allocation-of-the-remaining-ipv4-address-space">10.4.2.2. Allocation of the Remaining IPv4 Address Space</a></li> </ul> </li> </ul> </li> <li><a href="#10-5-global-policy-for-post-exhaustion-ipv4-allocation-mechanisms-by-the-iana">10.5. Global Policy for Post Exhaustion IPv4 Allocation Mechanisms by the IANA</a></li> </ul> </li> <li><a href="#11-experimental-internet-resource-allocations">11. Experimental Internet Resource Allocations</a> <ul> <li><a href="#11-1-eligibility-criteria-for-recognized-experimental-activity">11.1. Eligibility Criteria for Recognized Experimental Activity</a></li> <li><a href="#11-2-retired">11.2. [Retired]</a></li> <li><a href="#11-3-retired">11.3. [Retired]</a></li> <li><a href="#11-4-resource-allocation-term-and-renewal">11.4. Resource Allocation Term and Renewal</a></li> <li><a href="#11-5-single-resource-allocation-per-experiment">11.5. Single Resource Allocation per Experiment</a></li> <li><a href="#11-6-retired">11.6. [Retired]</a></li> <li><a href="#11-7-resource-allocation-guidelines">11.7. Resource Allocation Guidelines</a></li> <li><a href="#11-8-commercial-use-prohibited">11.8. Commercial Use Prohibited</a></li> <li><a href="#11-9-retired">11.9. [Retired]</a></li> </ul> </li> <li><a href="#12-resource-review">12. Resource Review</a></li> <li><a href="#appendix-a-change-log">Appendix A - Change Log</a></li> </ul> </nav> </div> <div id="nrpm-main" class="nrpm-text"> <div class="indent-2"> <h2 id="1-principles-and-goals-of-the-american-registry-for-internet-numbers-arin">1. Principles and Goals of the American Registry for Internet Numbers (ARIN)</h2> </div> <div class="indent-3"> <h3 id="1-1-registration">1.1. Registration</h3> <p>The principle of registration guarantees the uniqueness of Internet number resources. Provision of this public registry documenting Internet number resource allocation, reallocation, assignment, and reassignment is necessary:</p> <span class="alphabet-list"> <ol> <li>to ensure uniqueness,</li> <li>to provide a contact in case of operational/security problems,</li> <li>to provide the transparency required to ensure that Internet number resources are efficiently utilized, and</li> <li>to assist in IP allocation studies.</li> </ol> </span> </div> <div class="indent-3"> <h3 id="1-2-conservation">1.2. Conservation</h3> <p>The principle of conservation guarantees sustainability of the Internet through efficient utilization of unique number resources.</p> <p>Due to the requirement for uniqueness, Internet number resources of each type are drawn from a common number space. Conservation of these common number spaces requires that Internet number resources be efficiently distributed to those organizations who have a technical need for them in support of operational networks.</p> </div> <div class="indent-3"> <h3 id="1-3-routability">1.3. Routability</h3> <p>The principle of routability guarantees that Internet number resources are managed in such a manner that they may be routed on the Internet in a scalable manner.</p> <p>While routing scalability is necessary to ensure proper operation of Internet routing, allocation or assignment of Internet number resources by ARIN in no way guarantees that those addresses will be routed by any particular network operator.</p> </div> <div class="indent-3"> <h3 id="1-4-stewardship">1.4. Stewardship</h3> <p>The principle of stewardship guarantees the application of these principles when managing Internet number resources.</p> <p>The fundamental purpose of Internet number stewardship is to distribute unique number resources to entities building and operating networks thereby facilitating the growth and sustainability of the Internet for the benefit of all.</p> <p>It should be noted that the above goals may sometimes be in conflict with each other and with the interests of individual end-users or network operators. Care must be taken to ensure balance with these conflicting goals given the resource availability, relative size of the resource, and number resource specific technical dynamics, for each type of number resource.</p> </div> <div class="indent-2"> <h2 id="2-definitions">2. Definitions</h2> <p>Responsibility for management of number resources is distributed globally in accordance with the following procedures:</p> <ul> <li>Global number resource management is performed by the Internet Assigned Numbers Authority (IANA). IANA distributes number resources to RIRs (AfriNIC, APNIC, ARIN, LACNIC, and the RIPE NCC), but not directly to LIRs (Local Internet Registries) or end users.</li> <li>RIRs, such as ARIN, distribute number resources to LIRs and directly to end-user organizations.</li> <li>LIRs may further delegate number resources to other LIRs, as well as to other end-user organizations.</li> </ul> <p><img src="/participate/policy/images/distribution.png" alt="Chart showing hierarchical structure of Internet number resource distribution." /></p> </div> <div class="indent-3"> <h3 id="2-1-internet-registry-ir">2.1. Internet Registry (IR)</h3> <p>An Internet Registry (IR) is an organization that is responsible for distributing Internet number resources to its members or customers and for registering those distributions.</p> </div> <div class="indent-3"> <h3 id="2-2-regional-internet-registry-rir">2.2. Regional Internet Registry (RIR)</h3> <p>Regional Internet Registries (RIRs) are established and authorized by respective regional communities, and recognized by the IANA to serve and represent large geographical regions. The primary role of RIRs is to manage and distribute public Internet number resources within their respective regions.</p> </div> <div class="indent-3"> <h3 id="2-3-retired">2.3. [Retired]</h3> </div> <div class="indent-3"> <h3 id="2-4-local-internet-registry-lir">2.4. Local Internet Registry (LIR)</h3> <p>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.</p> </div> <div class="indent-3"> <h3 id="2-5-allocation-assignment-reallocation-reassignment">2.5. Allocation, Assignment, Reallocation, Reassignment</h3> <p>Allocation - IP addresses delegated to an organization directly by ARIN for the purpose of subsequent distribution by the recipient organization to other parties.</p> <p>Assignment - IP addresses delegated to an organization directly by ARIN for the exclusive use of the recipient organization.</p> <p>Reallocation - IP addresses sub-delegated to an organization by an upstream provider for the purpose of subsequent distribution by the recipient organization to other parties.</p> <p>Reassignment - IP addresses sub-delegated to an organization by an upstream provider for the exclusive use of the recipient organization.</p> <p>Note that the authorized incidental or transient use by third parties of IP addresses delegated to an organization shall not be considered a reassignment or a violation of the exclusive use provision.</p> </div> <div class="indent-3"> <h3 id="2-6-end-user">2.6. End-user</h3> <p>An end-user is an organization receiving assignments of IP addresses exclusively for use in its operational networks.</p> </div> <div class="indent-3"> <h3 id="2-7-multihomed">2.7. Multihomed</h3> <p>An organization is multihomed if it receives full-time connectivity from more than one ISP and has one or more routing prefixes announced by at least two of its upstream ISPs.</p> </div> <div class="indent-3"> <h3 id="2-8-registration-services-agreement-rsa">2.8. Registration Services Agreement (RSA)</h3> <p>Number resources allocated or assigned by ARIN under these policies are subject to a contractual agreement between ARIN and the resource holder. Throughout this document, any and all forms of this agreement, past or future, are simply referred to as the Registration Services Agreement (RSA).</p> </div> <div class="indent-3"> <h3 id="2-9-autonomous-system-number-asn">2.9. Autonomous System Number (ASN)</h3> <p>An Autonomous System Number (ASN) is a unique identifier which represents a collection of network resources operated under a common routing policy administration, known as an autonomous system.</p> </div> <div class="indent-3"> <h3 id="2-10-end-site">2.10. End Site</h3> <p>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).</p> </div> <div class="indent-3"> <h3 id="2-11-community-network">2.11. Community Network</h3> <p>A community network is one that is deployed, operated, and governed by its users, for the purpose of providing free or low-cost connectivity to the community it services. Users of the network or other volunteers must play a primary role in the governance of the organization, whereas other functions may be handled by either paid staff or volunteers.</p> </div> <div class="indent-3"> <h3 id="2-12-organizational-information">2.12. Organizational Information</h3> <p>When required, organization information must include at a minimum: Legal name, street address, city, state, zip code equivalent and at least one valid technical and one valid abuse POC. Each POC shall be designated by the organization and must include at least a verifiable email address and phone number.</p> </div> <div class="indent-3"> <h3 id="2-13-residential-customer">2.13. Residential Customer</h3> <p>End-users who are individual persons and not organizations and who receive service at a place of residence for personal use only are considered residential customers.</p> </div> <div class="indent-3"> <h3 id="2-14-serving-site-ipv6">2.14. Serving Site (IPv6)</h3> <p>When applied to IPv6 policies, the term serving site means a location where an ISP terminates or aggregates customer connections, including, but, not limited to points of presence (POPs), datacenters, central or local switching office or regional or local combinations thereof.</p> </div> <div class="indent-3"> <h3 id="2-15-provider-assignment-unit-ipv6">2.15. Provider Assignment Unit (IPv6)</h3> <p>When applied to IPv6 policies, the term “provider assignment unit” shall mean the prefix of the smallest block a given ISP assigns to end sites (recommended /48).</p> </div> <div class="indent-3"> <h3 id="2-16-utilized-ipv6">2.16. Utilized (IPv6)</h3> <p>When applied to IPv6 policies the term “utilized” shall be interpreted as follows:</p> <ol> <li>A provider assignment unit shall be considered fully utilized when it is assigned to an end-site.</li> <li>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).</li> </ol> </div> <div class="indent-3"> <h3 id="2-17-internet-number-resources">2.17. Internet Number Resources</h3> <p>Internet number resources are unique identifiers within the Internet Numbers Registry System [as described in the IETF RFC 7020] and this includes ranges (or “blocks”) of contiguous Internet Protocol (“IP”) addresses and Autonomous System Numbers (“ASNs”).</p> </div> <div class="indent-2"> <h2 id="3-directory-services">3. Directory Services</h2> </div> <div class="indent-3"> <h3 id="3-1-bulk-copies-of-arin-s-whois">3.1. Bulk Copies of ARIN’s Whois</h3> <p>ARIN will provide a bulk copy of Whois output, including point of contact information, on the ARIN site for download by any organization that wishes to obtain the data providing they agree to ARIN’s acceptable use policy. This point of contact information will not include data marked as private.</p> <p>[The Request Form for ARIN Bulk Whois Data, which contains the Acceptable Use Policy (AUP) for Bulk Copies of ARIN Whois Data, can be found at:</p> <p><a href="/about/corporate/agreements/bulkwhois.pdf">https://www.arin.net/resources/agreements/bulkwhois.pdf</a>]</p> </div> <div class="indent-3"> <h3 id="3-2-distributed-information-service-use-requirements">3.2. Distributed Information Service Use Requirements</h3> <p>The minimal requirements for an organization to setup a distributed information service to advertise reassignment and reallocation information are:</p> <ul> <li>The distributed information service must be operational 24 hours a day, 7 days a week to both the general public and ARIN staff. The service is allowed reasonable downtime for server maintenance according to generally accepted community standards.</li> <li>The distributed information service must allow public access to reassignment and reallocation information. The service may restrict the number of queries allowed per time interval from a host or subnet to defend against DDOS attacks, remote mirroring attempts, and other nefarious acts.</li> <li>The distributed information service must return reassignment and reallocation information for the IP address queried. The service may allow for privacy protections for customers. For residential users, the service may follow ARIN’s residential privacy policy that includes displaying only the city, state, zip code, and country. For all other reassignments and reallocations, the service shall follow ARIN’s privacy policy for publishing data in a public forum.</li> <li>The distributed information service may return results for non-IP queries.</li> <li>The distributed information service must respond to a query with the minimal set of attributes per object as defined by ARIN staff.</li> <li>The distributed information service may include optional attributes per object that are defined locally. The distributed information service must return results that are up-to-date on reassignment and reallocation information.</li> </ul> </div> <div class="indent-3"> <h3 id="3-3-privatizing-poc-information">3.3. Privatizing POC Information</h3> <p>Organizations may designate certain points of contact as private from ARIN Whois, with the exception that, at the minimum, one point of contact must be viewable.</p> </div> <div class="indent-3"> <h3 id="3-4-routing-registry">3.4. Routing Registry</h3> </div> <div class="indent-4"> <h4 id="3-4-1-acceptable-use-policy">3.4.1. Acceptable Use Policy</h4> <ul> <li>The ARIN Routing Registry data is for Internet operational purposes only. Mirroring is only allowed by other routing registries.</li> <li>The user may only distribute this data using a Whois service unless prior, written permission from ARIN has been obtained.</li> <li>To protect those registered in the ARIN routing registry, ARIN may need to specify additional conditions on access permissions for this data in the future. The permission to access the data is based on agreement to the conditions stipulated in this document in addition to any others that may be added in the future.</li> <li>Please see the <a href="http://www.irr.net/docs/list.html">http://www.irr.net/docs/list.html</a> URL for information about the replicated Routing Registry data.</li> </ul> </div> <div class="indent-3"> <h3 id="3-5-retired">3.5. [Retired]</h3> </div> <div class="indent-3"> <h3 id="3-6-annual-validation-of-arin-s-public-whois-point-of-contact-data">3.6. Annual Validation of ARIN’s Public Whois Point of Contact Data</h3> </div> <div class="indent-4"> <h4 id="3-6-1-annual-poc-verification">3.6.1. Annual POC Verification</h4> <p>ARIN will perform an annual verification of specific Points of Contact registered in the public Whois using the criteria and procedures outlined in sections 3.6.2, 3.6.3, and 3.6.4.</p> </div> <div class="indent-4"> <h4 id="3-6-2-specified-public-whois-points-of-contact-for-verification">3.6.2. Specified Public Whois Points of Contact for Verification</h4> <p>Each of the following Points of Contact are to be verified annually, and will be referred to as Point of Contact or POC throughout this policy, and should be understood to be both organization and resource POCs:</p> <ul> <li>Admin</li> <li>Tech</li> <li>NOC</li> <li>Abuse</li> </ul> </div> <div class="indent-4"> <h4 id="3-6-3-organizations-covered-by-this-policy">3.6.3. Organizations Covered by this Policy</h4> <p>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. This includes but is not limited to upstream ISPs and their downstream ISP customers (as defined by NRPM 2.5 and 2.6), but not reassignments made to their downstream end user customers.</p> </div> <div class="indent-4"> <h4 id="3-6-4-procedure-for-verification">3.6.4. Procedure for Verification</h4> <p>An annual email notification will be sent to each of the Points of Contact outlined in section 3.6.2 on an annual basis. Each Point of Contact will have up to sixty (60) days from the date of the notification in which to respond with an affirmative that their Whois contact information is correct and complete or to submit new data to correct and complete it. If after careful analysis, ARIN staff deems a POC to be completely and permanently abandoned or otherwise illegitimate, the POC record shall be marked invalid in Whois.</p> </div> <div class="indent-4"> <h4 id="3-6-5-non-responsive-point-of-contact-records">3.6.5. Non-Responsive Point of Contact Records</h4> <p>An invalid POC is restricted to payment and contact update functionality within ARIN Online. As a result, an organization without any valid POCs will be unable to access further functionalities within ARIN Online until at least one Admin or Tech POC validates that their information is accurate or modifies a POC to contain accurate information.</p> </div> <div class="indent-3"> <h3 id="3-7-poc-notification-and-validation-upon-reassignment-or-reallocation">3.7 POC Notification and Validation Upon Reassignment or Reallocation</h3> <p>When a request for reallocation or detailed reassignment is made to ARIN, the receiving organization must already be in the ARIN database and associated with at least one validated POC object. If there are no validated POC objects associated with the receiving organization, ARIN shall reject the request.</p> <p>In addition to notifying the requester, ARIN will also notify, via email, all POCs associated with the receiving organization, whether the request was successful or not, and will request validation of any invalid POC objects associated with the receiving organization.</p> <p>Note: Simple reassignments are made without any linkage to an organization or POC objects in the ARIN database.</p> </div> <div class="indent-3"> <h3 id="3-8-directory-service-records">3.8. Directory Service Records</h3> </div> <div class="indent-4"> <h4 id="3-8-1-organization-record-creation">3.8.1 Organization Record Creation</h4> <p>New organization records shall be created upon ARIN receiving a request directly from an authorized contact representing an entity that ARIN is able to validate. Organization records shall not be created upon the request of third-parties.</p> </div> <div class="indent-2"> <h2 id="4-ipv4">4. IPv4</h2> </div> <div class="indent-3"> <h3 id="4-1-general-principles">4.1. General Principles</h3> </div> <div class="indent-4"> <h4 id="4-1-1-4-1-2-4-1-3-4-1-4-retired">4.1.1., 4.1.2., 4.1.3., 4.1.4. [Retired]</h4> </div> <div class="indent-4"> <h4 id="4-1-5-resource-request-size">4.1.5. Resource Request Size</h4> <p>Determining the validity of the amount of requested IP address resources is the responsibility of ARIN.</p> </div> <div class="indent-4"> <h4 id="4-1-6-aggregation">4.1.6. Aggregation</h4> <p>In order to preserve aggregation, ARIN attempts to issue blocks of addresses on appropriate “CIDR-supported” bit boundaries. ARIN may reserve space to maximize aggregation possibilities until the implementation of section <a href="#10-4-2-2-allocation-of-the-remaining-ipv4-address-space">10.4.2.2</a>, at which time ARIN will make each allocation and assignment as a single continuous range of addresses.</p> </div> <div class="indent-4"> <h4 id="4-1-7-reserved-pool-replenishment">4.1.7. Reserved Pool Replenishment</h4> </div> <div class="indent-5"> <h5 id="4-1-7-1-disposition-of-resources">4.1.7.1. Disposition of Resources</h5> <p>Any resources allocated from a reserved pool created in Sections 4.4 or 4.10, or any other reserved pools created in the future, that become available for re-issuance will be returned to the reserved pool they were originally allocated from, regardless of the current level of each pool. Further, any other resources which become available for re-issuance will be prioritized for the replenishment of any reserved pool that falls below a running three-year supply, which is based on the previous three years of allocations from each pool.</p> </div> <div class="indent-5"> <h5 id="4-1-7-2-precedence-for-replenishment">4.1.7.2. Precedence for Replenishment</h5> <p>Staff shall return groups of blocks to the pools in scheduled batches (staff shall set a reasonable schedule). Each available block in a batch shall be returned in order from largest to smallest to the pool which at that point has the lowest percentage of a 3-year supply for that particular pool.</p> </div> <div class="indent-4"> <h4 id="4-1-8-arin-waitlist">4.1.8. ARIN Waitlist</h4> <p>ARIN will only issue future IPv4 assignments/allocations (excluding 4.4 and 4.10 space) from the ARIN Waitlist. The maximum size aggregate that an organization may qualify for at any one time is a /22. Organizations will be able to elect a smaller block size than they qualify for down to a /24. Organizations which hold more than a /20 equivalent of IPv4 space in aggregate (exclusive of special use space received under section 4.4 or 4.10) are not eligible to apply. Address space distributed from the waitlist will not be eligible for transfer, with the exception of Section 8.2 transfers, for a period of 60 months. This policy will be applied to all future distributions from the waitlist to include those currently listed.</p> <p>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. 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.</p> <p>Restrictions apply for entities who have conducted recent resource transfers. These restrictions are specified in Section 8 for each relevant transfer category.</p> </div> <div class="indent-5"> <h5 id="4-1-8-1-sequencing">4.1.8.1. Sequencing</h5> <p>The position of each qualified request on the waiting list will be determined by the date it was approved. Each organization may have one approved request on the waiting list at a time.</p> </div> <div class="indent-5"> <h5 id="4-1-8-2-fulfillment">4.1.8.2. Fulfillment</h5> <p>ARIN will fulfill requests on a first-approved basis, subject to the size of each available address block as address blocks become available for distribution. A timely review of the original request may be conducted by ARIN staff. Requests will not be partially filled. Any requests met through a transfer will be considered fulfilled and removed from the waiting list.</p> </div> <div class="indent-5"> <h5 id="4-1-8-3-qualification">4.1.8.3. Qualification</h5> <p>ARIN staff will evaluate all Waitlist requests against the requirements of otherwise applicable Section 4 policies.</p> </div> <div class="indent-4"> <h4 id="4-1-9-retired">4.1.9. [Retired]</h4> </div> <div class="indent-3"> <h3 id="4-2-allocations-to-isps-requirements-for-requesting-initial-address-space">4.2. Allocations to ISPs (Requirements for Requesting Initial Address Space)</h3> </div> <div class="indent-4"> <h4 id="4-2-1-principles">4.2.1. Principles</h4> </div> <div class="indent-5"> <h5 id="4-2-1-1-purpose">4.2.1.1. Purpose</h5> <p>ARIN allocates blocks of IP addresses to ISPs for the purpose of reassigning and reallocating that space to their customers.</p> </div> <div class="indent-5"> <h5 id="4-2-1-2-retired">4.2.1.2. [Retired]</h5> </div> <div class="indent-5"> <h5 id="4-2-1-3-utilization-rate">4.2.1.3. Utilization Rate</h5> <p>Utilization rate of address space is a key factor, among others, in determining address allocation.</p> </div> <div class="indent-5"> <h5 id="4-2-1-4-retired">4.2.1.4. [Retired]</h5> </div> <div class="indent-5"> <h5 id="4-2-1-5-minimum-allocation">4.2.1.5. Minimum Allocation</h5> <p>In general, ARIN allocates /24 and larger IP address prefixes to ISPs. If allocations smaller than /24 are needed, ISPs should request address space from their upstream provider.</p> </div> <div class="indent-5"> <h5 id="4-2-1-6-retired">4.2.1.6. [Retired]</h5> </div> <div class="indent-4"> <h4 id="4-2-2-initial-allocation-to-isps">4.2.2. Initial Allocation to ISPs</h4> <p>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.</p> <p>All ISP organizations without direct allocations, direct assignments, re-allocations or reassignments automatically qualify for a /24. These organizations are exempt from requirements of showing the efficient utilization of previously held IPv4 space. These organizations may qualify for a larger than a /24 by documenting how the requested allocation will be utilized within the request size specified in <a href="#4-2-4-3-request-size">4.2.4.3</a>.</p> <p>ISPs holding re-allocations and/or reassignments must show the efficient utilization of their resources consistent with the requirements in sections <a href="#4-2-3-reassigning-and-reallocating-address-space-to-customers">4.2.3</a> and <a href="https://www.arin.net/participate/policy/nrpm/#4-2-4-isp-additional-requests">4.2.4</a>.</p> </div> <div class="indent-4"> <h4 id="4-2-3-reassigning-and-reallocating-address-space-to-customers">4.2.3. Reassigning and Reallocating Address Space to Customers</h4> </div> <div class="indent-5"> <h5 id="4-2-3-1-efficient-utilization">4.2.3.1. Efficient Utilization</h5> <p>ISPs are required to apply a utilization efficiency criterion in providing address space to their customers. To this end, ISPs should have documented justification available for each reassignment and reallocation. ARIN may request this justification at any time. If justification is not provided, future receipt of allocations may be impacted.</p> </div> <div class="indent-5"> <h5 id="4-2-3-2-vlsm">4.2.3.2. VLSM</h5> <p>To increase utilization efficiency of IPv4 address space, ISPs reassigning IP address space to their customers should require their customers to use variable length subnet mask (VLSM) and classless technologies (CIDR) within their networks. ISPs should issue blocks smaller than /24 wherever feasible.</p> </div> <div class="indent-5"> <h5 id="4-2-3-3-contiguous-blocks">4.2.3.3. Contiguous Blocks</h5> <p>IP addresses are allocated to ISPs in contiguous blocks, which should remain intact. Fragmentation of blocks is discouraged. To avoid fragmentation, ISPs are encouraged to require their customers to return address space if they change ISPs. Therefore, if a customer moves to another service provider or otherwise terminates a contract with an ISP, it is recommended that the customer return the network addresses to the ISP and renumber into the new provider’s address space. The original ISP should allow sufficient time for the renumbering process to be completed before requiring the address space to be returned.</p> </div> <div class="indent-5"> <h5 id="4-2-3-4-downstream-customer-adherence">4.2.3.4. Downstream Customer Adherence</h5> <p>ISPs must require their downstream customers to adhere to the following criteria:</p> </div> <div class="indent-5"> <h5 id="4-2-3-4-1-utilization">4.2.3.4.1. Utilization</h5> <p>A downstream customer requesting address space from an upstream ISP must document a plan to the allocating ISP for their utilization to conform to Section 4.3.3. Reassignment and reallocation information for prior allocations must show that each customer meets the 80% utilization criteria and must be available via SWIP / a distributed service which meets the standards set forth in section 3.2 prior to issuing them additional space.</p> </div> <div class="indent-5"> <h5 id="4-2-3-4-2-downstream-isps">4.2.3.4.2. Downstream ISPs</h5> <p>Customers must follow ARIN policy for ISPs.</p> </div> <div class="indent-5"> <h5 id="4-2-3-5-retired">4.2.3.5. [Retired]</h5> </div> <div class="indent-5"> <h5 id="4-2-3-6-reassignments-to-multihomed-downstream-customers">4.2.3.6. Reassignments to Multihomed Downstream Customers</h5> <p>If a downstream customer has a requirement to multihome, that requirement alone will serve as justification for a /24 allocation. Downstream customers must provide contact information for all of their upstream providers to the ISP from whom they are requesting a /24, and utilize a border routing protocol between the customer and the ISP. Customers may receive a /24 from only one of their upstream providers under this policy without providing additional justification. ISPs may demonstrate they have made an assignment to a downstream customer under this policy by supplying ARIN with the information they collected from the customer, as described above, or by identifying the AS number of the customer.</p> </div> <div class="indent-5"> <h5 id="4-2-3-7-registration">4.2.3.7. Registration</h5> <p>ISPs are required to demonstrate efficient use of IP address space allocations by providing appropriate documentation, including but not limited to assignment histories, showing their efficient use.</p> </div> <div class="indent-6"> <h6 id="4-2-3-7-1-reassignment-and-reallocation-information">4.2.3.7.1. Reassignment and Reallocation Information</h6> <p>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.</p> <p>Reassignment registrations must include each customer name, except where specifically exempted by this policy. Reassignment registrations shall only include point of contact (POC) information if either: (1) requested by the customer; or (2) the reassigned block is intended to be routed and announced outside of the provider’s network.</p> <p>Reallocation registrations must contain the customer’s organization name and appropriate point of contact (POC) information.</p> </div> <div class="indent-5"> <h5 id="4-2-3-7-2-reassignments-and-reallocations-visible-within-seven-days">4.2.3.7.2. Reassignments and Reallocations Visible Within Seven Days</h5> <p>All reassignments and reallocations shall be made visible as required in section 4.2.3.7.1 within seven calendar days of reassignment or reallocation.</p> </div> <div class="indent-5"> <h5 id="4-2-3-7-3-residential-subscribers">4.2.3.7.3. Residential Subscribers</h5> </div> <div class="indent-5"> <h5 id="4-2-3-7-3-1-retired">4.2.3.7.3.1. [Retired]</h5> </div> <div class="indent-5"> <h5 id="4-2-3-7-3-2-residential-customer-privacy">4.2.3.7.3.2. Residential Customer Privacy</h5> <p>To maintain the privacy of their residential customers, an organization with downstream residential customers holding /29 and larger blocks may substitute that organization’s name for the customer’s name, e.g. ‘Private Customer - XYZ Network’, and the customer’s street address may read ‘Private Residence’. Each private downstream residential reassignment must have accurate upstream Abuse and Technical POCs visible on the WHOIS or Distributed Information Service record for that block.</p> </div> <div class="indent-5"> <h5 id="4-2-3-8-reassignments-for-third-party-internet-access-tpia-over-cable">4.2.3.8. Reassignments for Third Party Internet Access (TPIA) over Cable</h5> <p>IP addresses reassigned by an ISP to an incumbent cable operator for use with Third Party Internet Access (TPIA) will be counted as fully used once they are assigned to equipment by the underlying cable carrier provided they meet the following requirements:</p> <ul> <li>initial assignments to each piece of hardware represent the smallest subnet reasonably required to deploy service to the customer base served by the hardware</li> <li>additional assignments to each piece of hardware are made only when all previous assignments to that specific piece of hardware are at least 80% used and represent a 24-month supply</li> <li>IP allocations issued through 4.2.3.8 are non-transferable via section <a href="#8-3-transfers-between-specified-recipients-within-the-arin-region">8.3</a> and section <a href="#8-4-inter-rir-transfers-to-specified-recipients">8.4</a> for a period of 36 months. In the case of a section <a href="#8-2-mergers-acquisitions-and-reorganizations">8.2</a> transfer the IP assignment must be utilized for the same purpose or needs based justification at a rate consistent with intended use.</li> </ul> </div> <div class="indent-4"> <h4 id="4-2-4-isp-additional-requests">4.2.4. ISP Additional Requests</h4> </div> <div class="indent-5"> <h5 id="4-2-4-1-utilization-percentage-80">4.2.4.1. Utilization Percentage (80%)</h5> <p>ISPs must have efficiently utilized all allocations, in aggregate, to at least 80% and at least 50% of every allocation in order to receive additional space. This includes all space reassigned or reallocated to their customers.</p> </div> <div class="indent-5"> <h5 id="4-2-4-2-return-address-space-as-agreed">4.2.4.2. Return Address Space as Agreed</h5> <p>Return prior address space designated for return as agreed.</p> </div> <div class="indent-5"> <h5 id="4-2-4-3-request-size">4.2.4.3. Request Size</h5> <p>ISPs may request up to a 24-month supply of IPv4 addresses.</p> </div> <div class="indent-5"> <h5 id="4-2-4-4-retired">4.2.4.4. [Retired]</h5> </div> <div class="indent-4"> <h4 id="4-2-5-4-2-6-retired">4.2.5., 4.2.6. [Retired]</h4> </div> <div class="indent-3"> <h3 id="4-3-end-users-assignments-to-end-users">4.3. End-users - Assignments to End-users</h3> </div> <div class="indent-4"> <h4 id="4-3-1-end-users">4.3.1. End-users</h4> <p>ARIN assigns blocks of IP addresses to end-users who request address space for their internal use in running their own networks, but not for sub-delegation of those addresses outside their organization. End-users must meet the requirements described in these guidelines for justifying the assignment of an address block.</p> </div> <div class="indent-4"> <h4 id="4-3-2-minimum-assignment">4.3.2. Minimum Assignment</h4> <p>ARIN’s minimum assignment for end-user organizations is a /24.</p> <p>End-user organizations without direct assignments or allocations from ARIN qualify for an initial assignment of ARIN’s minimum assignment size.</p> </div> <div class="indent-4"> <h4 id="4-3-3-utilization-rate">4.3.3. Utilization Rate</h4> <p>Organizations may qualify for a larger initial allocation by providing appropriate details to verify their 24-month growth projection.</p> <p>The basic criterion that must be met is a 50% utilization rate within 24 months.</p> <p>A greater utilization rate may be required based on individual network requirements.</p> </div> <div class="indent-4"> <h4 id="4-3-4-retired">4.3.4. [Retired]</h4> </div> <div class="indent-4"> <h4 id="4-3-5-non-connected-networks">4.3.5. Non-connected Networks</h4> <p>End-users not currently connected to an ISP and/or not planning to be connected to the Internet are encouraged to use private IP address numbers reserved for non-connected networks (see RFC 1918). When private, non-connected networks require interconnectivity and the private IP address numbers are ineffective, globally unique addresses may be requested and used to provide this interconnectivity.</p> </div> <div class="indent-4"> <h4 id="4-3-6-additional-assignments">4.3.6. Additional Assignments</h4> </div> <div class="indent-5"> <h5 id="4-3-6-1-utilization-requirements-for-additional-assignment">4.3.6.1. Utilization Requirements for Additional Assignment</h5> <p>End-users must have efficiently utilized all assignments, in aggregate, to at least 80% and at least 50% of every assignment in order to receive additional space, and must provide ARIN with utilization details.</p> </div> <div class="indent-3"> <h3 id="4-4-micro-allocation">4.4. Micro-allocation</h3> <p>ARIN will make IPv4 micro-allocations to critical infrastructure providers of the Internet, including public exchange points, core DNS service providers (e.g. ICANN-sanctioned root and ccTLD operators) as well as the RIRs and IANA. These allocations will be no smaller than a /24. Multiple allocations may be granted in certain situations.</p> <p>Exchange point allocations MUST be allocated from specific blocks reserved only for this purpose. All other micro-allocations WILL be allocated out of other blocks reserved for micro-allocation purposes. ARIN will make a list of these blocks publicly available.</p> <p>Exchange point operators must provide justification for the allocation, including: connection policy, location, other participants (minimum of three total), ASN, and contact information. This policy does not preclude exchange point operators from requesting address space under other policies.</p> <p>ARIN will place an equivalent of a /15 of IPv4 address space in a reserve for Critical Infrastructure, as defined in section 4.4.</p> <p>ICANN-sanctioned gTLD operators may justify up to the equivalent of an IPv4 /23 block for each authorized gTLD, allocated from the free pool or received via transfer, but not from the above reservation. This limit of a /23 equivalent per gTLD does not apply to gTLD allocations made under previous policy.</p> </div> <div class="indent-3"> <h3 id="4-5-multiple-discrete-networks">4.5. Multiple Discrete Networks</h3> <p>Organizations with multiple discrete networks desiring to request new or additional address space under a single Organization ID must meet the following criteria:</p> <ol> <li>The organization shall be a single entity and not a consortium of smaller independent entities.</li> <li>The organization must have compelling criteria for creating discrete networks. Examples of a discrete network might include:</li> <li>Regulatory restrictions for data transmission,</li> <li>Geographic distance and diversity between networks,</li> <li>Autonomous multihomed discrete networks.</li> <li>The organization must keep detailed records on how it has allocated space to each location, including the date of each allocation.</li> <li>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.</li> <li>The organization may not allocate additional address space to a location until each of that location’s address blocks are 80% utilized.</li> <li>The organization should notify ARIN at the time of the request their desire to apply this policy to their account.</li> <li>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.</li> </ol> </div> <div class="indent-3"> <h3 id="4-6-4-7-4-8-4-9-retired">4.6., 4.7., 4.8., 4.9. [Retired]</h3> </div> <div class="indent-3"> <h3 id="4-10-dedicated-ipv4-allocation-to-facilitate-ipv6-deployment">4.10. Dedicated IPv4 Allocation to Facilitate IPv6 Deployment</h3> <p>ARIN shall allocate a contiguous /10 from its last /8 IPv4 allocation from IANA. This IPv4 allocation will be set aside and dedicated to facilitate IPv6 deployment. Allocations and assignments from this block must be justified by immediate IPv6 deployment requirements. Examples of such needs include: IPv4 addresses for key dual stack DNS servers, and NAT-PT or NAT464 translators. ARIN staff will use their discretion when evaluating justifications.</p> <p>A /24 will be allocated. ARIN should use sparse allocation when possible within that /10 block.</p> <p>In order to receive an allocation or assignment under this policy:</p> <ul> <li>the applicant may not have received resources under this policy in the preceding six months, except to the extent that the applicant is requesting resources for a discrete network in respect of which it has not received any resources under this policy in the preceding six months;</li> <li>previous allocations/assignments under this policy must continue to meet the justification requirements of this policy;</li> <li>previous allocations/assignments under this policy must be utilized to at least 80% to obtain an additional allocation or assignment;</li> <li>the applicant must demonstrate that no other allocations or assignments will meet this need.</li> <li>An applicant requesting multiple allocations under this policy to support Multiple Discrete Networks, as defined under Section 4.5, may not receive more than the equivalent of a /21 of IPv4 address space in any one six-month period hereunder.</li> </ul> </div> <div class="indent-2"> <h2 id="5-as-numbers">5. AS Numbers</h2> <p>Any organization may be issued a single Autonomous System Number (ASN) upon request. Organizations that have space issued under Multiple Discrete Networks policy may be issued one ASN per discrete network upon request.</p> <p>Additional ASN requests should include proof of the requestor’s need for a unique routing policy, or other technical justification for the need for more than one ASN.</p> </div> <div class="indent-3"> <h3 id="5-1-retired">5.1. [Retired]</h3> </div> <div class="indent-2"> <h2 id="6-ipv6">6. IPv6</h2> </div> <div class="indent-3"> <h3 id="6-1-introduction">6.1. Introduction</h3> </div> <div class="indent-4"> <h4 id="6-1-1-overview">6.1.1. Overview</h4> <p>This document describes policies for the allocation and assignment of globally-unique Internet Protocol Version 6 (IPv6) address space. It updates and obsoletes the existing Provisional IPv6 Policies in effect since 1999. Policies described in this document are intended to be adopted by each registry. However, adoption of this document does not preclude local variations in each region or area.</p> <p>RFC 2373, RFC 2373bis designate 2000::/3 to be global unicast address space that IANA may allocate to the RIRs. In accordance with RFC 2928, RFC 2373bis, IAB-Request, IANA has allocated initial ranges of global unicast IPv6 address space from the 2001::/16 address block to the existing RIRs. This document concerns the initial and subsequent allocations of the 2000::/3 unicast address space, for which RIRs formulate allocation and assignment policies.</p> </div> <div class="indent-3"> <h3 id="6-2-retired">6.2. [Retired]</h3> </div> <div class="indent-3"> <h3 id="6-3-goals-of-ipv6-address-space-management">6.3. Goals of IPv6 Address Space Management</h3> </div> <div class="indent-4"> <h4 id="6-3-1-goals">6.3.1. Goals</h4> <p>IPv6 address space is a public resource that must be managed in a prudent manner with regards to the long-term interests of the internet. Responsible address space management involves balancing a set of sometimes competing goals. The following are the goals relevant to IPv6 address policy.</p> </div> <div class="indent-4"> <h4 id="6-3-2-uniqueness">6.3.2. Uniqueness</h4> <p>Every assignment and/or allocation of address space must guarantee uniqueness worldwide. This is an absolute requirement for ensuring that every public host on the Internet can be uniquely identified.</p> </div> <div class="indent-4"> <h4 id="6-3-3-registration">6.3.3. Registration</h4> <p>Internet address space must be registered in a registry database accessible to appropriate members of the Internet community. This is necessary to ensure the uniqueness of each Internet address and to provide reference information for Internet troubleshooting at all levels, ranging from all RIRs and IRs to end users.</p> <p>The goal of registration should be applied within the context of reasonable privacy considerations and applicable laws.</p> </div> <div class="indent-4"> <h4 id="6-3-4-aggregation">6.3.4. Aggregation</h4> <p>Wherever possible, address space should be distributed in a hierarchical manner, according to the topology of network infrastructure. This is necessary to permit the aggregation of routing information by ISPs, and to limit the expansion of Internet routing tables.</p> <p>This goal is particularly important in IPv6 addressing, where the size of the total address pool creates significant implications for both internal and external routing.</p> <p>IPv6 address policies should seek to avoid fragmentation of address ranges.</p> <p>Further, RIRs should apply practices that maximize the potential for subsequent allocations to be made contiguous with past allocations currently held. However, there can be no guarantee of contiguous allocation.</p> </div> <div class="indent-4"> <h4 id="6-3-5-conservation">6.3.5. Conservation</h4> <p>Although IPv6 provides an extremely large pool of address space, address policies should avoid unnecessarily wasteful practices. Requests for address space should be supported by appropriate documentation and stockpiling of unused addresses should be avoided.</p> </div> <div class="indent-4"> <h4 id="6-3-6-fairness">6.3.6. Fairness</h4> <p>All policies and practices relating to the use of public address space should apply fairly and equitably to all existing and potential members of the Internet community, regardless of their location, nationality, size or any other factor.</p> </div> <div class="indent-4"> <h4 id="6-3-7-minimized-overhead">6.3.7. Minimized Overhead</h4> <p>It is desirable to minimize the overhead associated with obtaining address space. Overhead includes the need to go back to RIRs for additional space too frequently, the overhead associated with managing address space that grows through a number of small successive incremental expansions rather than through fewer, but larger, expansions.</p> </div> <div class="indent-4"> <h4 id="6-3-8-conflict-of-goals">6.3.8. Conflict of Goals</h4> <p>The goals described above will often conflict with each other, or with the needs of individual IRs or end users. All IRs evaluating requests for allocations and assignments must make judgments, seeking to balance the needs of the applicant with the needs of the Internet community as a whole.</p> <p>In IPv6 address policy, the goal of aggregation is considered to be the most important.</p> </div> <div class="indent-3"> <h3 id="6-4-ipv6-policy-principles">6.4. IPv6 Policy Principles</h3> <p>To address the goals described in the previous section, the policies in this document discuss and follow the basic principles described below.</p> </div> <div class="indent-4"> <h4 id="6-4-1-address-space-not-to-be-considered-property">6.4.1. Address Space Not to be Considered Property</h4> <p>It is contrary to the goals of this document and is not in the interests of the Internet community as a whole for address space to be considered freehold property.</p> <p>The policies in this document are based upon the understanding that globally-unique IPv6 unicast address space is allocated/assigned for use rather than owned.</p> </div> <div class="indent-4"> <h4 id="6-4-2-routability-not-guaranteed">6.4.2. Routability Not Guaranteed</h4> <p>There is no guarantee that any address allocation or assignment will be globally routable.</p> <p>However, RIRs must apply procedures that reduce the possibility of fragmented address space which may lead to a loss of routability.</p> </div> <div class="indent-4"> <h4 id="6-4-3-retired">6.4.3. [Retired]</h4> </div> <div class="indent-4"> <h4 id="6-4-4-consideration-of-ipv4-infrastructure">6.4.4. Consideration of IPv4 Infrastructure</h4> <p>Where an existing IPv4 service provider requests IPv6 space for eventual transition of existing services to IPv6, the number of present IPv4 customers may be used to justify a larger request than would be justified if based solely on the IPv6 infrastructure.</p> </div> <div class="indent-3"> <h3 id="6-5-policies-for-allocations-and-assignments">6.5. Policies for Allocations and Assignments</h3> </div> <div class="indent-4"> <h4 id="6-5-1-terminology">6.5.1. Terminology</h4> <span class="alphabet-list"> <ol> <li>The terms ISP and LIR are used interchangeably in this document and any use of either term shall be construed to include both meanings.</li> <li>The term nibble boundary shall mean a network mask which aligns on a 4-bit boundary (in slash notation, /n, where n is evenly divisible by 4, allowing unit quantities of X such that 2^n=X where n is evenly divisible by 4, such as 16, 256, 4096, etc.)</li> </ol> </span> </div> <div class="indent-4"> <h4 id="6-5-2-initial-allocation-to-lirs">6.5.2. Initial Allocation to LIRs</h4> </div> <div class="indent-5"> <h5 id="6-5-2-1-size">6.5.2.1. Size</h5> <span class="alphabet-list"> <ol> <li>All allocations shall be made on nibble boundaries.</li> <li>In no case shall an LIR receive smaller than a /32 unless they specifically request a /36 or /40. In order to be eligible for a /40, an ISP must meet the following requirements:</li> </ol> <ul> <li> <p>Hold IPv4 direct allocations totaling a /24 or less (to include zero)</p> </li> <li> <p>Hold IPv4 reassignments/reallocations totaling a /22 or less (to include zero)</p> <p>In no case shall an ISP receive more than a /16 initial allocation.</p> </li> </ul> <ol start="3"> <li>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.<br /> 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.</li> <li>For purposes of the calculation in (c), an end site which can justify more than a /48 under the end-user assignment criteria in <a href="#6-5-8-direct-assignments-from-arin-to-end-user-organizations">6.5.8</a> shall count as the appropriate number of /48s that would be assigned under that policy.</li> <li>For purposes of the calculation in (c), an LIR which has subordinate LIRs 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. LIRs which do not receive resources directly from ARIN will not be able to make such reallocations to subordinate LIRs and subordinate LIRs which need more than a /32 shall apply directly to ARIN.</li> <li>An LIR 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 is entitled.</li> <li>An LIR that requests a smaller /36 or /40 allocation is entitled to expand the allocation to any nibble aligned size up to /32 at any time without renumbering or additional justification. /40 allocations shall be automatically upgraded to /36 if at any time said LIR’s IPv4 direct allocations exceed a /24. Expansions up to and including a /32 are not considered subsequent allocations, however any expansions beyond /32 are considered subsequent allocations and must conform to section 6.5.3. Partial returns of any IPv6 allocation that results in less than a /36 of holding are not permitted regardless of the ISP’s current or former IPv4 address holdings.</li> </ol> </span> </div> <div class="indent-5"> <h5 id="6-5-2-2-qualifications">6.5.2.2. Qualifications</h5> <p>An organization qualifies for an allocation under this policy if they meet any of the following criteria:</p> <span class="alphabet-list"> <ol> <li>Have a previously justified IPv4 ISP allocation from ARIN or one of its predecessor registries or can qualify for an IPv4 ISP allocation under current criteria.</li> <li>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.</li> <li>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.</li> </ol> </span> </div> <div class="indent-4"> <h4 id="6-5-3-subsequent-allocations-to-lirs">6.5.3. Subsequent Allocations to LIRs</h4> <span class="alphabet-list"> <ol> <li>Where possible ARIN will make subsequent allocations by expanding the existing allocation.</li> <li>An LIR qualifies for a subsequent allocation if they meet any of the following criteria:</li> </ol> <ul> <li>Shows utilization of 75% or more of their total address space</li> <li>Shows utilization of more than 90% of any serving site</li> <li>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 <a href="#6-5-2-initial-allocation-to-lirs">6.5.2</a></li> </ul> <ol start="3"> <li>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 is encouraged, but not required to renumber into the new allocation over time and return any allocations no longer in use.</li> <li>If an LIR has already reached a /12 or more, ARIN will allocate a single additional /12 rather than continue expanding nibble boundaries.</li> </ol> </span> </div> <div class="indent-5"> <h5 id="6-5-3-1-subsequent-allocations-for-transition">6.5.3.1. Subsequent Allocations for Transition</h5> <p>Subsequent allocations will also be considered for deployments that cannot be accommodated by, nor were accounted for, under the initial allocation. Justification for the subsequent subnet size will be based on the plan and technology provided with a /24 being the maximum allowed for a transition technology. Justification for transitional allocations will be reviewed every 3 years and reclaimed if they are no longer in use for transitional purposes. All such allocations for transitional technology will be made from a block designated for this purpose.</p> </div> <div class="indent-4"> <h4 id="6-5-4-reassignments-from-lirs-isps">6.5.4. Reassignments from LIRs/ISPs</h4> <p>Reassignments to end users shall be governed by the same practices adopted by the community in section <a href="#6-5-8-direct-assignments-from-arin-to-end-user-organizations">6.5.8</a> except that the requirements in <a href="#6-5-8-1-initial-assignment-criteria">6.5.8.1</a> do not apply.</p> </div> <div class="indent-5"> <h5 id="6-5-4-1-reassignment-to-operator-s-infrastructure">6.5.4.1. Reassignment to Operator’s Infrastructure</h5> <p>An LIR may reassign up to a /48 per PoP as well as up to an additional /48 globally for its own infrastructure.</p> </div> <div class="indent-4"> <h4 id="6-5-5-registration">6.5.5. Registration</h4> <p>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.</p> </div> <div class="indent-5"> <h5 id="6-5-5-1-reassignment-information">6.5.5.1. Reassignment Information</h5> <p>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.</p> </div> <div class="indent-5"> <h5 id="6-5-5-2-reassignments-and-reallocations-visible-within-seven-days">6.5.5.2. Reassignments and Reallocations Visible Within Seven Days</h5> <p>All reassignments and reallocations shall be made visible as required in section 6.5.5.1 within seven calendar days of reassignment or reallocation.</p> </div> <div class="indent-5"> <h5 id="6-5-5-3-residential-subscribers">6.5.5.3. Residential Subscribers</h5> </div> <div class="indent-5"> <h5 id="6-5-5-3-1-residential-customer-privacy">6.5.5.3.1. Residential Customer Privacy</h5> <p>To maintain the privacy of their residential customers, an organization with downstream residential customers may substitute that organization’s name for the customer’s name, e.g. ‘Private Customer - XYZ Network’, and the customer’s street address may read ‘Private Residence’. Each private downstream residential reassignment must have accurate upstream Abuse and Technical POCs visible on the WHOIS or Distributed Information Service record for that block.</p> </div> <div class="indent-5"> <h5 id="6-5-5-4-registration-requested-by-recipient">6.5.5.4. Registration Requested by Recipient</h5> <p>If the downstream recipient of a static assignment of /64 or more addresses requests publishing of that assignment in ARIN’s registration database, the ISP shall register that assignment as described in section 6.5.5.1.</p> </div> <div class="indent-4"> <h4 id="6-5-6-retired">6.5.6. [Retired]</h4> </div> <div class="indent-4"> <h4 id="6-5-7-existing-ipv6-address-space-holders">6.5.7. Existing IPv6 Address Space Holders</h4> <p>LIRs 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.</p> </div> <div class="indent-4"> <h4 id="6-5-8-direct-assignments-from-arin-to-end-user-organizations">6.5.8. Direct Assignments from ARIN to End-user Organizations</h4> </div> <div class="indent-5"> <h5 id="6-5-8-1-initial-assignment-criteria">6.5.8.1. Initial Assignment Criteria</h5> <p>Organizations may justify an initial assignment for addressing devices directly attached to their own network infrastructure, with an intent for the addresses to begin operational use within 12 months, by meeting one of the following criteria:</p> <span class="alphabet-list"> <ol> <li>Having a previously justified IPv4 end-user assignment from ARIN or one of its predecessor registries, or;</li> <li>Currently being IPv6 Multihomed or immediately becoming IPv6 Multihomed and using an assigned valid global AS number, or;</li> <li>By having a network that makes active use of a minimum of 2000 IPv6 addresses within 12 months, or;</li> <li>By having a network that makes active use of a minimum of 200 /64 subnets within 12 months, or;</li> <li>By having a contiguous network that has a minimum of 13 active sites within 12 months, or;</li> <li>By providing a reasonable technical justification indicating why IPv6 addresses from an ISP or other LIR are unsuitable.</li> </ol> </span> <p>Examples of justifications for why addresses from an ISP or other LIR may be unsuitable include, but are not limited to:</p> <ul> <li>An organization that operates infrastructure critical to life safety or the functioning of society can justify the need for an assignment based on the fact that renumbering would have a broader than expected impact than simply the number of hosts directly involved. These would include: hospitals, fire fighting, police, emergency response, power or energy distribution, water or waste treatment, traffic management and control, etc.</li> <li>Regardless of the number of hosts directly involved, an organization can justify the need for an assignment if renumbering would affect 2000 or more individuals either internal or external to the organization.</li> <li>An organization with a network not connected to the Internet can justify the need for an assignment by documenting a need for guaranteed uniqueness, beyond the statistical uniqueness provided by ULA (see RFC 4193).</li> <li>An organization with a network not connected to the Internet, such as a VPN overlay network, can justify the need for an assignment if they require authoritative delegation of reverse DNS.</li> </ul> </div> <div class="indent-5"> <h5 id="6-5-8-2-initial-assignment-size">6.5.8.2. Initial Assignment Size</h5> <p>Organizations that meet at least one of the initial assignment criteria above are eligible to receive an initial assignment of /48. Requests for larger initial assignments, reasonably justified with supporting documentation, will be evaluated based on the number of sites in an organization’s network and the number of subnets needed to support any extra-large sites defined below.</p> <p>The initial assignment size will be determined by the number of sites justified below. An organization qualifies for an assignment on the next larger nibble boundary when their sites exceed 75% of the /48s available in a prefix. For example:</p> <p>More than 1 but less than or equal to 12 sites justified, receives a /44 assignment;</p> <p>More than 12 but less than or equal to 192 sites justified, receives a /40 assignment;</p> <p>More than 192 but less than or equal to 3,072 sites justified, receives a /36 assignment;</p> <p>More than 3,072 but less than or equal to 49,152 sites justified, receives a /32 assignment; etc…</p> </div> <div class="indent-5"> <h5 id="6-5-8-2-1-standard-sites">6.5.8.2.1. Standard Sites</h5> <p>A site is a discrete location that is part of an organization’s network. A campus with multiple buildings may be considered as one or multiple sites, based on the implementation of its network infrastructure. For a campus to be considered as multiple sites, reasonable technical documentation must be submitted describing how the network infrastructure is implemented in a manner equivalent to multiple sites.</p> <p>An organization may request up to a /48 for each site in its network, and any sites that will be operational within 12 months.</p> </div> <div class="indent-5"> <h5 id="6-5-8-2-2-extra-large-sites">6.5.8.2.2. Extra-large Sites</h5> <p>In rare cases, an organization may request more than a /48 for an extra-large site which requires more than 16,384 /64 subnets. In such a case, a detailed subnet plan must be submitted for each extra-large site in an organization’s network. An extra-large site qualifies for the next larger prefix when the total subnet utilization exceeds 25%. Each extra-large site will be counted as an equivalent number of /48 standard sites.</p> </div> <div class="indent-5"> <h5 id="6-5-8-3-subsequent-assignments">6.5.8.3. Subsequent Assignments</h5> <p>Requests for subsequent assignments with supporting documentation will be evaluated based on the same criteria as an initial assignment under <a href="#6-5-8-2-initial-assignment-size">6.5.8.2</a> with the following modifications:</p> <ol> <li>A subsequent assignment is justified when the total utilization based on the number of sites justified exceeds 75% across all of an organization’s assignments. If the organization received an assignment per section <a href="#6-11-ipv6-multiple-discrete-networks">6.11</a> IPv6 Multiple Discrete Networks, such assignments will be evaluated as if they were to a separate organization.</li> <li>When possible subsequent assignments will result in the expansion of an existing assignment by one or more nibble boundaries as justified.</li> <li>If it is not possible to expand an existing assignment, or to expand it adequately to meet the justified need, then a separate new assignment will be made of the size justified.</li> </ol> </div> <div class="indent-5"> <h5 id="6-5-8-4-consolidation-and-return-of-separate-assignments">6.5.8.4. Consolidation and Return of Separate Assignments</h5> <p>Organizations with multiple separate assignments should consolidate into a single aggregate, if feasible. If an organization stops using one or more of its separate assignments, any unused assignments must be returned to ARIN.</p> </div> <div class="indent-4"> <h4 id="6-5-9-community-network-allocations">6.5.9. Community Network Allocations</h4> <p>While community networks would normally be considered to be 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.</p> <p>Community networks may also qualify under section 6.5.2 as a regular LIR.</p> </div> <div class="indent-5"> <h5 id="6-5-9-1-qualification-criteria">6.5.9.1. Qualification Criteria</h5> <p>To qualify under this section, a community network must demonstrate to ARIN’s satisfaction that it meets the definition of a community network under section <a href="#2-11-community-network">2.11</a> of the NRPM.</p> </div> <div class="indent-5"> <h5 id="6-5-9-2-allocation-size">6.5.9.2. Allocation Size</h5> <p>Community networks are eligible only to receive an allocation of /40 of IPv6 resources under this section. Community networks that wish to receive a larger initial allocation or any subsequent allocations must qualify as a regular LIR, see sections 6.5.2 or 6.5.3 respectively.</p> </div> <div class="indent-5"> <h5 id="6-5-9-3-reassignments-by-community-networks">6.5.9.3. Reassignments by Community Networks</h5> <p>Similar to other LIRs, 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.</p> </div> <div class="indent-3"> <h3 id="6-6-6-7-6-8-6-9-retired">6.6., 6.7., 6.8., 6.9. [Retired]</h3> </div> <div class="indent-3"> <h3 id="6-10-micro-allocations">6.10. Micro-allocations</h3> </div> <div class="indent-4"> <h4 id="6-10-1-micro-allocations-for-critical-infrastructure">6.10.1. Micro-allocations for Critical Infrastructure</h4> <p>ARIN will make micro-allocations to critical infrastructure providers of the Internet, including public exchange points, core DNS service providers (e.g. ICANN-sanctioned root, gTLD, and ccTLD operators) as well as the RIRs and IANA. These allocations will be no longer than a /48. Multiple allocations may be granted in certain situations. - Exchange point allocations MUST be allocated from specific blocks reserved only for this purpose. All other micro-allocations WILL be allocated out of other blocks reserved for micro-allocation purposes. ARIN will make a list of these blocks publicly available. - Exchange point operators must provide justification for the allocation, including: connection policy, location, other participants (minimum of two total), ASN, and contact information. This policy does not preclude exchange point operators from requesting address space under other policies.</p> </div> <div class="indent-4"> <h4 id="6-10-2-micro-allocations-for-internal-infrastructure">6.10.2. Micro-allocations for Internal Infrastructure</h4> <p>Organizations that currently hold IPv6 allocations may apply for a micro-allocation for internal infrastructure. Applicant must provide technical justification indicating why a separate non-routed block is required. Justification must include why a sub-allocation of currently held IP space cannot be utilized. Internal infrastructure allocations must be allocated from specific blocks reserved only for this purpose.</p> </div> <div class="indent-3"> <h3 id="6-11-ipv6-multiple-discrete-networks">6.11. IPv6 Multiple Discrete Networks</h3> <p>Organizations with multiple discrete IPv6 networks desiring to request new or additional address space under a single Organization ID must meet the following criteria:</p> <ol> <li>The organization shall be a single entity and not a consortium of smaller independent entities.</li> <li>The organization must have compelling criteria for creating discrete networks. Examples of a discrete network might include:</li> </ol> <ul> <li>Regulatory restrictions for data transmission,</li> <li>Geographic distance and diversity between networks,</li> <li>Autonomous multihomed discrete networks.</li> </ul> <ol start="3"> <li>The organization must keep detailed records on how it has allocated space to each location, including the date of each allocation.</li> <li>The organization should notify ARIN at the time of the request their desire to apply this policy to their account.</li> <li>Requests for additional space:</li> <li>Organization must specify on the application which discrete network(s) the request applies to</li> <li>Each network will be judged against the existing utilization criteria specified in <a href="#6-5-2-initial-allocation-to-lirs">6.5.2</a> and <a href="#6-5-3-subsequent-allocations-to-lirs">6.5.3</a> as if it were a separate organization, rather than collectively as would be done for requests outside of this policy.</li> </ol> </div> <div class="indent-2"> <h2 id="7-retired">7. [Retired]</h2> </div> <div class="indent-2"> <h2 id="8-transfers">8. Transfers</h2> </div> <div class="indent-3"> <h3 id="8-1-principles">8.1. Principles</h3> <p>Number resources are nontransferable and are not assignable to any other organization unless ARIN has expressly and in writing approved a request for transfer. ARIN is tasked with making prudent decisions on whether to approve the transfer of number resources.</p> <p>It should be understood that number resources are not ‘sold’ under ARIN administration. Rather, number resources are assigned to an organization for its exclusive use for the purpose stated in the request, provided the terms of the Registration Services Agreement continue to be met and the stated purpose for the number resources remains the same. Number resources are administered and assigned according to ARIN’s published policies.</p> <p>Number resources are issued, based on justified need, to organizations, not to individuals representing those organizations. Thus, if a company goes out of business, regardless of the reason, the point of contact (POC) listed for the number resource does not have the authority to sell, transfer, assign, or give the number resource to any other person or organization. The POC must notify ARIN if a business fails so the assigned number resources can be returned to the available pool of number resources if a transfer is not requested and justified.</p> </div> <div class="indent-3"> <h3 id="8-2-mergers-acquisitions-and-reorganizations">8.2. Mergers, Acquisitions, and Reorganizations</h3> <p>ARIN will consider requests for the transfer of number resources in the<br /> case of mergers, acquisitions, and reorganizations under the following<br /> conditions:</p> <ul> <li>The current registrant must not be involved in any dispute as to the status of the resources to be transferred.</li> <li>The new entity must sign an RSA covering all resources to be transferred.</li> <li>The resources to be transferred will be subject to ARIN policies.</li> <li>The minimum transfer size is the smaller of the original allocation size or the applicable minimum allocation size in current policy.</li> <li>The Internet number resources being transferred as part of a transfer under section 8.2 will not be subject to a needs-based assessment during the process of the transfer.</li> </ul> <p>AND one or more of the following:</p> <ul> <li>The recipient must provide evidence that it has acquired the assets that use the resources to be transferred from the current registrant.</li> </ul> <p>OR</p> <ul> <li>The recipient must show that it has acquired the entire entity which is the current registrant.</li> </ul> <p>An organization which serves as the source of an IPv4 under section 8.2 will not be allowed to apply for IPv4 address space under section 4.1.8 ARIN Waitlist for a period of 36 months following said transfer unless the recipient organization remains a subsidiary, parent company, or under common ownership with the source organization.</p> <p>Mergers, acquisitions, and reorganization activity resulting in the surviving entity ceasing to have a real and substantial connection with the ARIN region shall be permitted to continue holding any numbering resources issued (directly or indirectly) by ARIN prior to the merger, acquisition or reorganization activity, but shall not qualify for any additional numbering resources (directly or indirectly) from ARIN, unless and until it once again has a real and substantial connection with the ARIN region as required by the Numbering Resource Policy Manual.</p> </div> <div class="indent-3"> <h3 id="8-3-transfers-between-specified-recipients-within-the-arin-region">8.3. Transfers Between Specified Recipients Within the ARIN Region</h3> <p>In addition to transfers under section 8.2, IPv4 addresses and ASNs may be transferred according to the following conditions.</p> <p>Conditions on source of the transfer:</p> <ul> <li>The source entity must be the current registered holder of the IPv4 addresses or ASNs, and not be involved in any dispute as to the status of those resources.</li> <li>With the exception of M&A transfers under section 8.2, the source entity must not have received a transfer, allocation, or assignment from ARIN for the past 12 months. This requirement may be waived by ARIN for transfers made in connection with a renumbering exercise designed to more efficiently utilize number resources under section 8.5.5.1.</li> <li>Address resources from a reserved pool (including those designated in Section 4.4 and 4.10) are not eligible for transfer.</li> <li>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.</li> </ul> <p>Conditions on recipient of the transfer:</p> <ul> <li>The recipients must meet the transfer requirements as defined in section 8.5.</li> <li>The resources transferred will be subject to current ARIN policies.</li> <li>If applicable the recipient will be removed from the ARIN Waitlist and will not be allowed to reapply under section 4.1.8. ARIN Waitlist for a period of 90 days.</li> </ul> </div> <div class="indent-3"> <h3 id="8-4-inter-rir-transfers-to-specified-recipients">8.4. Inter-RIR Transfers to Specified Recipients</h3> <p>Inter-regional transfers of IPv4 addresses or ASNs may take place only via RIRs who agree to the transfer and share reciprocal, compatible needs-based policies.</p> <p>Conditions on source of the transfer:</p> <ul> <li>The source entity must be the current rights holder of the IPv4 addresses or ASN recognized by the RIR responsible for the resources, and not be involved in any dispute as to the status of those resources.</li> <li>Source entities outside of the ARIN region must meet any requirements defined by the RIR where the source entity holds the registration.</li> <li>With the exception of M&A transfers under section 8.2, the source entity must not have received a transfer, allocation, or assignment from ARIN for the past 12 months. This requirement may be waived by ARIN for transfers made in connection with a renumbering exercise designed to more efficiently utilize number resources under section 8.5.5.1.</li> <li>Address resources from a reserved pool (including those designated in Section 4.4 and 4.10) are not eligible for transfer.</li> <li>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.</li> </ul> <p>Conditions on recipient of the transfer:</p> <ul> <li>The conditions on a recipient outside of the ARIN region will be defined by the policies of the receiving RIR.</li> <li>Specified recipients within the ARIN region must meet the transfer requirements as defined in section 8.5.</li> <li>Recipients within the ARIN region will be subject to current ARIN policies.</li> <li>If applicable the recipient will be removed from the ARIN Waitlist and will not be allowed to reapply under section 4.1.8. ARIN Waitlist for a period of 90 days.</li> </ul> </div> <div class="indent-3"> <h3 id="8-5-specified-transfer-recipient-requirements">8.5. Specified Transfer Recipient Requirements</h3> </div> <div class="indent-4"> <h4 id="8-5-1-registration-services-agreement">8.5.1. Registration Services Agreement</h4> <p>The receiving entity must sign an RSA covering all resources to be transferred unless that entity has a current (within the last two versions) RSA on file.</p> </div> <div class="indent-4"> <h4 id="8-5-2-operational-use">8.5.2 Operational Use</h4> <p>ARIN allocates or assigns number resources to organizations via transfer solely for the purpose of use on an operational network.</p> </div> <div class="indent-4"> <h4 id="8-5-3-minimum-transfer-size">8.5.3. Minimum Transfer Size</h4> <p>ARIN’s minimum IPv4 transfer size is a /24.</p> </div> <div class="indent-4"> <h4 id="8-5-4-initial-block">8.5.4. Initial Block</h4> <p>Organizations without direct assignments or allocations from ARIN qualify for transfer of an initial IPv4 block of ARIN’s minimum transfer size.</p> </div> <div class="indent-4"> <h4 id="8-5-5-block-size">8.5.5. Block Size</h4> <p>Organizations may qualify for the transfer of a larger initial block, or an additional block, by providing documentation to ARIN which details the use of at least 50% of the requested IPv4 block size within 24 months.</p> </div> <div class="indent-5"> <h5 id="8-5-5-1-transfer-for-the-purpose-of-renumbering">8.5.5.1. Transfer for the Purpose of Renumbering</h5> <p>Organizations with larger direct allocations or assignments than they require may receive transfer of a smaller block for the purpose of renumbering onto the smaller block if they transfer the entire larger block to a qualified recipient under section 8 within one year of receipt of transfer of the smaller block. If the larger block is not transferred within one year of receipt of the smaller block, the organization will be ineligible to receive any further transfers under this section until the larger block is transferred.</p> </div> <div class="indent-6"> <h6 id="8-5-5-1-1-smaller-block-size">8.5.5.1.1 Smaller Block Size</h6> <p>Organizations may qualify to receive transfer of a smaller block by providing documentation to ARIN which details the use of at least 50% of the smaller block size within 24 months. Current use of the larger block may be used to satisfy this criteria.</p> </div> <div class="indent-4"> <h4 id="8-5-6-efficient-utilization-of-previous-blocks">8.5.6. Efficient Utilization of Previous Blocks</h4> <p>Organizations with direct assignments or allocations from ARIN must have efficiently utilized at least 50% of their cumulative IPv4 address blocks in order to receive additional IPv4 addresses. This includes all IPv4 space reassigned to their customers.</p> </div> <div class="indent-5"> <h5 id="8-5-6-1-transfer-for-the-purpose-of-renumbering">8.5.6.1 Transfer for the Purpose of Renumbering</h5> <p>Organizations receiving transfer of a smaller block under section 8.5.5.1 may deduct the larger block they are transferring to a qualified recipient when calculating their efficient utilization of previous blocks under section 8.5.6.</p> </div> <div class="indent-4"> <h4 id="8-5-7-alternative-additional-ipv4-address-block-criteria">8.5.7. Alternative Additional IPv4 Address Block Criteria</h4> <p>Organizations may qualify for additional IPv4 address blocks by demonstrating 80% utilization of their currently allocated space. In organizations operating multiple discrete networks, each discrete network may be assessed individually for the 80% utilization threshold. To qualify under this policy, the organization must provide justification that each network is discrete, per the criteria described in section 4.5. Each discrete network must meet the projection requirements in section 8.5.5, and each discrete network for which IP addresses are requested must meet the utilization requirements in section 8.5.6. Organizations may receive one or more transfers up to the total size of their current ARIN IPv4 address holdings, up to a maximum size of /16.</p> <p>An organization may qualify via section 8.5.7 for a total of a /16 equivalent in any 6 month period.</p> </div> <div class="indent-3"> <h3 id="8-6-wait-list-restrictions">8.6. Wait List Restrictions</h3> <p>Any organization which is on the wait list and submits a request to be the source of a transfer under any provision in section 8 will be removed from the wait list.</p> </div> <div class="indent-2"> <h2 id="9-out-of-region-use">9. Out of Region Use</h2> <p>ARIN registered resources may be used outside the ARIN service region. Out of region use of ARIN registered resources are valid justification for additional number resources, provided that the applicant has a real and substantial connection with the ARIN region which applicant must prove (as described below) and is using the same type of resources (with a delegation lineage back to an ARIN allocation or assignment) within the ARIN service region as follows:</p> <ul> <li>IPv4: At least a /22 used in region</li> <li>IPv6: At least a /44 used in region</li> <li>ASN: At least one ASN present on one or more peering sessions and/or routers within the region.</li> </ul> <p>A real and substantial connection shall be defined as carrying on business in the ARIN region in a meaningful manner. The determination as to whether an entity is carrying on business in the ARIN region in a meaningful manner shall be made by ARIN. Simply being incorporated in the ARIN region shall not be sufficient, on its own, to prove that an entity is carrying on business in the ARIN region in a meaningful manner. Methods that entities may consider using, including cumulatively, to prove that they are carrying on business in the ARIN region in a meaningful manner include:</p> <ul> <li>Demonstrating a physical presence in the ARIN region through a bricks and mortar location that is actually used for the purposes of conducting business in the ARIN region in a meaningful manner. That is to say, the location is not merely a registered office that serves no other business purpose.</li> <li>Demonstrating that the entity has staff in the ARIN region. The greater the number of staff, the stronger this connecting factor is.</li> <li>Demonstrating that the entity holds assets in the ARIN region. The greater the asset value, the stronger this connecting factor is.</li> <li>Demonstrating that the entity provides services to and solicits sales from residents of the ARIN region.</li> <li>Demonstrating that the entity holds periodic meetings in the ARIN region.</li> <li>Demonstrating that the entity raises investment capital from investors in the ARIN region.</li> <li>Demonstrating that the entity has a registered corporation in the ARIN region, although this factor on its own shall not be sufficient.</li> <li>Other fact based criterion that the entity considers appropriate and submits for ARIN’s review.</li> </ul> <p>The weight accorded to any of the above-noted factors, if any, shall be determined solely by ARIN.</p> <p>The services and facilities used to justify the need for ARIN resources that will be used out of region cannot also be used to justify resource requests from another RIR. When a request for resources from ARIN is justified by need located within another RIR’s service region, an officer of the application must attest that the same services and facilities have not been used as the basis for a resource request in the other region(s). ARIN reserves the right to obtain from the applicant a listing of all the applicant’s number holdings in the region(s) of proposed use, when there are factual reasons to support the request.</p> </div> <div class="indent-2"> <h2 id="10-global-number-resource-policy">10. Global Number Resource Policy</h2> </div> <div class="indent-3"> <h3 id="10-1-iana-to-rir-allocation-of-ipv4-address-space">10.1. IANA to RIR Allocation of IPv4 Address Space</h3> <p>This document describes the policies governing the allocation of IPv4 address space from the IANA to the Regional Internet Registries (RIRs). This document does not stipulate performance requirements in the provision of services by IANA to an RIR in accordance with these policies. Such requirements should be specified by appropriate agreements among the RIRs and ICANN.</p> <p><strong>1. Allocation Principles</strong></p> <ul> <li>The IANA will allocate IPv4 address space to the RIRs in /8 units.</li> <li>The IANA will allocate sufficient IPv4 address space to the RIRs to support their registration needs for at least an 18 month period.</li> <li>The IANA will allow for the RIRs to apply their own respective chosen allocation and reservation strategies in order to ensure the efficiency and efficacy of their work.</li> </ul> <p><strong>2. Initial Allocations</strong></p> <p>Each new RIR shall, at the moment of recognition, be allocated a new /8 by the IANA. This allocation will be made regardless of the newly formed RIR’s projected utilization figures and shall be independent of the IPv4 address space that may have been transferred to the new RIR by the already existing RIRs as part of the formal transition process.</p> <p><strong>3. Additional Allocations</strong></p> <p>A RIR is eligible to receive additional IPv4 address space from the IANA when either of the following conditions are met.</p> <ul> <li>The RIR’s AVAILABLE SPACE of IPv4 addresses is less than 50% of a /8 block.</li> <li>The RIR’s AVAILABLE SPACE of IPv4 addresses is less than its established NECESSARY SPACE for the following 9 months.</li> </ul> <p>In either case, IANA shall make a single allocation of a whole number of /8 blocks, sufficient to satisfy the established NECESSARY SPACE of the RIR for an 18 month period.</p> <p>3.1 Calculation of AVAILABLE SPACE</p> <p>The AVAILABLE SPACE of IPv4 addresses of a RIR shall be determined as follows:</p> <p>AVAILABLE SPACE = CURRENTLY FREE ADDRESSES + RESERVATIONS EXPIRING DURING THE FOLLOWING 3 MONTHS - FRAGMENTED SPACE</p> <p>FRAGMENTED SPACE is determined as the total amount of available blocks smaller than the RIR’s minimum allocation size within the RIR’s currently available stock.</p> <p>3.2 Calculation of NECESSARY SPACE</p> <p>If the applying Regional Internet Registry does not establish any special needs for the period concerned, NECESSARY SPACE shall be determined as follows:</p> <p>NECESSARY SPACE = AVERAGE NUMBER OF ADDRESSES ALLOCATED MONTHLY DURING THE PAST 6 MONTHS * LENGTH OF PERIOD IN MONTHS</p> <p>If the applying RIR anticipates that due to certain special needs the rate of allocation for the period concerned will be greater than the previous 6 months, it may determine its NECESSARY SPACE as follows:</p> <p>A) Calculate NECESSARY SPACE as its total needs for that period according to its projection and based on the special facts that justify these needs.</p> <p>B) Submit a clear and detailed justification of the above mentioned projection (Item A).</p> <p>If the justification is based on the allocation tendency prepared by the Regional Internet Registry, data explaining said tendency must be enclosed.</p> <p>If the justification is based on the application of one or more of the Regional Internet Registry’s new allocation policies, an impact analysis of the new policy/policies must be enclosed.</p> <p>If the justification is based on external factors such as new infrastructure, new services within the region, technological advances or legal issues, the corresponding analysis must be enclosed together with references to information sources that will allow verification of the data.</p> <p>If IANA does not have elements that clearly question the Regional Internet Registry’s projection, the special needs projected for the following 18 months, indicated in Item A above, shall be considered valid.</p> <p><strong>4. Announcement of IANA Allocations</strong></p> <p>When address space is allocated to a RIR, the IANA will send a detailed announcement to the receiving RIR. The IANA will also make announcements to all other RIRs, informing them of the recent allocation. The RIRs will coordinate announcements to their respective membership lists and any other lists they deem necessary.</p> <p>The IANA will make appropriate modifications to the “Internet Protocol V4 Address Space” page of the IANA website and may make announcements to its own appropriate announcement lists. The IANA announcements will be limited to which address ranges, the time of allocation and to which Registry they have been allocated.</p> </div> <div class="indent-3"> <h3 id="10-2-allocation-of-ipv6-address-space-by-the-internet-assigned-numbers-authority-iana-policy-to-regional-internet-registries">10.2. Allocation of IPv6 Address Space by the Internet Assigned Numbers Authority (IANA) Policy to Regional Internet Registries</h3> <p>This document describes the policy governing the allocation of IPv6 address space from the IANA to the Regional Internet Registries (RIRs). This document does not stipulate performance requirements in the provision of services by IANA to an RIR in accordance with this policy. Such requirements will be specified by appropriate agreements between ICANN and the NRO.</p> <p><strong>1. Allocation Principles</strong></p> <ul> <li>The unit of IPv6 allocation (and therefore the minimum IPv6 allocation) from IANA to an RIR is a /12</li> <li>The IANA will allocate sufficient IPv6 address space to the RIRs to support their registration needs for at least an 18 month period.</li> <li>The IANA will allow for the RIRs to apply their own respective chosen allocation and reservation strategies in order to ensure the efficiency and efficacy of their work.</li> </ul> <p><strong>2. Initial Allocations</strong></p> <ul> <li>On inception of this policy, each current RIR with less than a /12 unallocated address space, shall receive an IPv6 allocation from IANA</li> <li>Any new RIR shall, on recognition by ICANN receive an IPv6 allocation from the IANA</li> </ul> <p><strong>3. Additional Allocations</strong></p> <p>A RIR is eligible to receive additional IPv6 address space from the IANA when either of the following conditions are met.</p> <ul> <li>The RIR’s AVAILABLE SPACE of IPv6 addresses is less than 50% of a /12.</li> <li>The RIR’s AVAILABLE SPACE of IPv6 addresses is less than its established NECESSARY SPACE for the following 9 months.</li> </ul> <p>In either case, IANA shall make a single IPv6 allocation, sufficient to satisfy the established NECESSARY SPACE of the RIR for an 18 month period.</p> <p>3.1 Calculation of AVAILABLE SPACE</p> <p>The AVAILABLE SPACE of IPv6 addresses of a RIR shall be determined as follows:</p> <p>AVAILABLE SPACE = CURRENTLY FREE ADDRESSES + RESERVATIONS EXPIRING DURING THE FOLLOWING 3 MONTHS - FRAGMENTED SPACE</p> <p>FRAGMENTED SPACE is determined as the total amount of available blocks smaller than the RIR’s minimum allocation size within the RIR’s currently available stock.</p> <p>3.2 Calculation of NECESSARY SPACE</p> <p>If the applying Regional Internet Registry does not establish any special needs for the period concerned, NECESSARY SPACE shall be determined as follows:</p> <p>NECESSARY SPACE = AVERAGE NUMBER OF ADDRESSES ALLOCATED MONTHLY DURING THE PAST 6 MONTHS * LENGTH OF PERIOD IN MONTHS</p> <p>If the applying RIR anticipates that due to certain special needs the rate of allocation for the period concerned will be different from the previous 6 months, it may determine its NECESSARY SPACE as follows:</p> <p>Calculate NECESSARY SPACE as its total needs for that period according to its projection and based on the special facts that justify these needs.</p> <p>Submit a clear and detailed justification of the above mentioned projection (Item A).</p> <p>If the justification is based on the allocation tendency prepared by the Regional Internet Registry, data explaining said tendency must be enclosed.</p> <p>If the justification is based on the application of one or more of the Regional Internet Registry’s new allocation policies, an impact analysis of the new policy/policies must be enclosed.</p> <p>If the justification is based on external factors such as new infrastructure, new services within the region, technological advances or legal issues, the corresponding analysis must be enclosed together with references to information sources that will allow verification of the data.</p> <p>If IANA does not have elements that clearly question the Regional Internet Registry’s projection, the special needs projected for the following 18 months, indicated in Item A above, shall be considered valid.</p> <p><strong>4. Announcement of IANA Allocations</strong></p> <p>The IANA, the NRO, and the RIRs will make announcements and update their respective web sites regarding an allocation made by the IANA to an RIR. ICANN and the NRO will establish administrative procedures to manage this process.</p> </div> <div class="indent-3"> <h3 id="10-3-iana-policy-for-allocation-of-asn-blocks-to-rirs">10.3. IANA Policy for Allocation of ASN Blocks to RIRs</h3> <p>Abstract</p> <p>This document describes the policy governing the allocation of Autonomous System Numbers (ASNs) from the IANA to the Regional Internet Registries (RIRs).</p> <p>This policy document does not stipulate performance requirements in the provision of services by the IANA to an RIR. Such requirements will be specified by appropriate agreements between ICANN and the Number Resource Organization (NRO).</p> <p><strong>1. Allocation Principles</strong></p> <p>IANA allocates ASNs to RIRs in blocks of 1024 ASNs. In this document the term “ASN block” refers to a set of 1024 ASNs. Until 31 December 2010, allocations of 2-byte only and 4-byte only ASN blocks will be made separately and independent of each other.</p> <p>This means until 31 December 2010, RIRs can receive two separate ASN blocks, one for 2-byte only ASNs and one for 4-byte only ASNs from the IANA under this policy. After this date, IANA and the RIRs will cease to make any distinction between 2-byte only and 4-byte only ASNs, and will operate ASN allocations from an undifferentiated 4-byte ASN allocation pool.</p> <p><strong>2. Initial Allocations</strong></p> <p>Each new RIR will be allocated a new ASN block.</p> <p><strong>3. Additional Allocations</strong></p> <p>An RIR is eligible to receive (an) additional ASN block(s) from the IANA if one of the following conditions is met:</p> <ol> <li>The RIR has assigned/allocated 80% of the previously received ASN block, or</li> <li>The number of free ASNs currently held by the RIR is less than two months need. This projection is based on the monthly average number of ASNs assigned/allocated by the RIR over the previous six months.</li> </ol> <p>An RIR will be allocated as many ASN blocks as are needed to support their registration needs for the next 12 months, based on their average assignment/allocation rate over the previous six months, unless the RIR specifically requests fewer blocks than it qualifies for.</p> <p><strong>4. Announcement of IANA Allocations</strong></p> <p>The IANA, the NRO and the RIRs will make announcements and update their respective websites/databases when an allocation is made by the IANA to an RIR. ICANN and the NRO will establish administrative procedures to manage this process.</p> </div> <div class="indent-3"> <h3 id="10-4-global-policy-for-the-allocation-of-the-remaining-ipv4-address-space">10.4. Global Policy for the Allocation of the Remaining IPv4 Address Space</h3> <p>This policy describes the process for the allocation of the remaining IPv4 space from IANA to the RIRs. When a minimum amount of available space is reached, one /8 will be allocated from IANA to each RIR, replacing the current IPv4 allocation policy.</p> <p>In order to fulfill the requirements of this policy, at the time it is adopted, one /8 will be reserved by IANA for each RIR. The reserved allocation units will no longer be part of the available space at the IANA pool. IANA will also reserve one /8 to any new RIR at the time it is recognized.</p> <p>The process for the allocation of the remaining IPv4 space is divided in two consecutive phases:</p> </div> <div class="indent-4"> <h4 id="10-4-1-existing-policy-phase">10.4.1. Existing Policy Phase</h4> <p>During this phase IANA will continue allocating IPv4 addresses to the RIRs using the existing allocation policy. This phase will continue until a request for IPv4 address space from any RIR to IANA either cannot be fulfilled with the remaining IPv4 space available at the IANA pool or can be fulfilled but leaving the IANA remaining IPv4 pool empty.</p> <p>This will be the last IPv4 address space request that IANA will accept from any RIR. At this point the next phase of the process (Exhaustion Phase) will be initiated.</p> </div> <div class="indent-4"> <h4 id="10-4-2-exhaustion-phase">10.4.2. Exhaustion Phase</h4> <p>During this phase IANA will automatically allocate the reserved IPv4 allocation units to each RIR (one /8 to each one) and respond to the last request with the remaining available allocation units at the IANA pool (M units).</p> </div> <div class="indent-5"> <h5 id="10-4-2-1-size-of-the-final-ipv4-allocations">10.4.2.1. Size of the Final IPv4 Allocations</h5> <p>In this phase IANA will automatically allocate one /8 to each RIR from the reserved space as defined in this policy. IANA will also allocate M allocation units to the RIR that submitted the last request for IPv4 addresses.</p> </div> <div class="indent-5"> <h5 id="10-4-2-2-allocation-of-the-remaining-ipv4-address-space">10.4.2.2. Allocation of the Remaining IPv4 Address Space</h5> <p>After the completion of the evaluation of the final request for IPv4 addresses, IANA MUST:</p> <ol> <li>Immediately notify the NRO about the activation of the second phase (Exhaustion Phase) of this policy.</li> <li>Proceed to allocate M allocation units to the RIR that submitted the last request for IPv4 address space.</li> <li>Proceed to allocate one /8 to each RIR from the reserved space.</li> </ol> </div> <div class="indent-3"> <h3 id="10-5-global-policy-for-post-exhaustion-ipv4-allocation-mechanisms-by-the-iana">10.5. Global Policy for Post Exhaustion IPv4 Allocation Mechanisms by the IANA</h3> <p>The IANA shall establish a Recovered IPv4 Pool to be utilized post RIR IPv4 exhaustion. The Recovered IPv4 Pool will initially contain any fragments that may be left over in the IANA. It will also hold<br /> any space returned to the IANA by any other means.</p> <p>The Recovered IPv4 Pool will be administered by the IANA. It will contain:</p> <p>a. Any fragments left over in the IANA inventory after the last /8s of IPv4 space are delegated to the RIRs</p> <ul> <li>The IANA inventory excludes “Special use IPv4 addresses” as defined in BCP 153 and any addresses allocated by the IANA for experimental use.</li> </ul> <p>b. Any IPv4 space returned to the IANA by any means.</p> <p>The Recovered IPv4 Pool will stay inactive until the first RIR has less than a total of a /9 in its inventory of IPv4 address space. When one of the RIRs declares it has less than a total of a /9 in its inventory, the Recovered IPv4 pool will be declared active, and IP addresses from the Recovered IPv4 Pool will be allocated as follows:</p> <p>a. Allocations from the IANA may begin once the pool is declared active.</p> <p>b. In each “IPv4 allocation period”, each RIR will receive a single “IPv4 allocation unit” from the IANA.</p> <p>c. An “IPv4 allocation period” is defined as a 6-month period following 1 March or 1 September in each year.</p> <p>d. The IANA will calculate the size of the “IPv4 allocation unit” at the following times:</p> <ul> <li>When the Recovered IPv4 Pool is first activated</li> <li>At the beginning of each IPv4 allocation period</li> </ul> <p>To calculate the “IPv4 allocation unit” at these times, the IANA will use the following formula:</p> <p>IPv4 allocation unit = 1/5 of Recovered IPv4 pool, rounded down to the next CIDR (power-of-2) boundary.</p> <p>No RIR may get more than this calculation used to determine the IPv4 allocation unit even when they can justify a need for it.</p> <p>The minimum “IPv4 allocation unit” size will be a /24. If the calculation used to determine the IPv4 allocation unit results in a block smaller than a /24, the IANA will not distribute any addresses in that IPv4 allocation period.</p> <p>The IANA may make public announcements of IPv4 address transactions that occur under this policy. The IANA will make appropriate modifications to the “Internet Protocol V4 Address Space” page of the IANA website and may make announcements to its own appropriate announcement lists. The IANA announcements will be limited to which address ranges, the time of allocation, and to which Registry they have been allocated.</p> </div> <div class="indent-2"> <h2 id="11-experimental-internet-resource-allocations">11. Experimental Internet Resource Allocations</h2> <p>ARIN will allocate Internet Number Resources to organizations requiring temporary Internet Number Resources for a fixed period of time under the terms of a recognized experimental activity.</p> </div> <div class="indent-3"> <h3 id="11-1-eligibility-criteria-for-recognized-experimental-activity">11.1. Eligibility Criteria for Recognized Experimental Activity</h3> <p>The eligibility criteria for a recognized experimental activity under this policy are:</p> <ul> <li>The experiment’s description and objectives are published in a publicly accessible document, which for the purposes of this policy means that the document is readily available free of charge to the public, and free of any constraints of disclosure within one year after the end of the experiment;</li> <li>The experiment’s outcomes must also be published in a publicly accessible document;</li> <li>Demonstration to ARIN that the experimental activity is technically sound; and</li> <li>Demonstration to ARIN that the experimental activity is technically coordinated in that consideration of any potential negative impact of the proposed experiment on the operation of the Internet and its deployed services has been considered, and a description of experimenter mitigation plans to contain any negative impacts has been provided.</li> </ul> </div> <div class="indent-3"> <h3 id="11-2-retired">11.2. [Retired]</h3> </div> <div class="indent-3"> <h3 id="11-3-retired">11.3. [Retired]</h3> </div> <div class="indent-3"> <h3 id="11-4-resource-allocation-term-and-renewal">11.4. Resource Allocation Term and Renewal</h3> <p>The Internet Number Resources are allocated for a period of one year under this policy. The allocation can be renewed on application to ARIN, prior to the expiry of the one-year period, providing information as to why an extension is necessary for a successful experiment. The resources allocated under this policy must be returned to ARIN at the earliest of: (1) the recognized experimental activity has ended; or (2) the end of the one-year period and any extension thereof.</p> </div> <div class="indent-3"> <h3 id="11-5-single-resource-allocation-per-experiment">11.5. Single Resource Allocation per Experiment</h3> <p>ARIN will make only one allocation per recognized experiment. An allocation may consist of multiple Internet Number Resources if required to conduct the recognized activity. Additional allocations to an organization already holding experimental activity resources will not be made under this policy unless justified by a subsequent complete application relating to a different experimental activity.</p> </div> <div class="indent-3"> <h3 id="11-6-retired">11.6. [Retired]</h3> </div> <div class="indent-3"> <h3 id="11-7-resource-allocation-guidelines">11.7. Resource Allocation Guidelines</h3> <p>The Internet Number Resources requested come from the global Internet Number Resource space, shall not overlap any currently assigned space, and shall not be from private or other non-routable Internet Number Resource space. The allocation size shall be consistent with existing ARIN minimum allocation sizes, unless smaller allocations are explicitly required due to the nature of the experiment. If an organization requires more resources than stipulated by the minimum allocation size in force at the time of its request, the request must clearly describe and justify why a larger allocation is required. All research allocations must be registered publicly in ARIN’s directory services. Each research allocation will be designated as a research allocation with a comment indicating when the allocation will end.</p> </div> <div class="indent-3"> <h3 id="11-8-commercial-use-prohibited">11.8. Commercial Use Prohibited</h3> <p>If there is any evidence that the temporary resource is being used for commercial purposes or is being used for any activities not documented in the original experiment description provided to ARIN, ARIN reserves the right to immediately withdraw the resource.</p> </div> <div class="indent-3"> <h3 id="11-9-retired">11.9. [Retired]</h3> </div> <div class="indent-2"> <h2 id="12-resource-review">12. Resource Review</h2> <ol> <li>ARIN may review the current usage of any resources maintained in the ARIN database. The organization shall cooperate with any request from ARIN for reasonable related documentation.</li> <li>ARIN may conduct such reviews: <span class="alphabet-list"> <ol> <li>when any new resource is requested,</li> <li>whenever ARIN has reason to believe that the resources were originally obtained fraudulently or in contravention of existing policy, or</li> <li>whenever ARIN has reason to believe that an organization is not complying with reassignment or reallocation policies, or</li> <li>at any other time without having to establish cause unless a full review has been completed in the preceding 24 months.</li> </ol> </span> </li> <li>At the conclusion of a review in which ARIN has solicited information from the resource holder, ARIN shall communicate to the resource holder that the review has been concluded and what, if any, further actions are required.</li> <li>Organizations found by ARIN to be materially out of compliance with current ARIN policy shall be requested or required to return resources as needed to bring them into (or reasonably close to) compliance. <span class="alphabet-list"> <ol> <li>The degree to which an organization may remain out of compliance shall be based on the reasonable judgment of the ARIN staff and shall balance all facts known, including the organization’s utilization rate, available address pool, and other factors as appropriate so as to avoid forcing returns which will result in near-term additional requests or unnecessary route de-aggregation.</li> <li>To the extent possible, entire blocks should be returned. Partial address blocks shall be returned in such a way that the portion retained will comprise a single aggregate block.</li> </ol> </span> </li> <li>If the organization does not voluntarily return resources as requested, ARIN may revoke any resources issued by ARIN as required to bring the organization into overall compliance. ARIN shall follow the same guidelines for revocation that are required for voluntary return in the previous paragraph.</li> <li>Except in cases of fraud, or violations of policy, an organization shall be given a minimum of six months to effect a return. ARIN shall negotiate a longer term with the organization if ARIN believes the organization is working in good faith to substantially restore compliance and has a valid need for additional time to renumber out of the affected blocks.</li> <li>In case of a return under paragraphs 12.4 through 12.6, ARIN shall continue to provide services for the resource(s) while their return or revocation is pending, except any maintenance fees assessed during that period shall be calculated as if the return or revocation was complete.</li> <li>This policy does not create any additional authority for ARIN to revoke legacy address space. However, the utilization of legacy resources shall be considered during a review to assess overall compliance.</li> <li>In considering compliance with policies which allow a timeframe (such as a requirement to assign some number of prefixes within 5 years), failure to comply cannot be measured until after the timeframe specified in the applicable policy has elapsed. Blocks subject to such a policy shall be assumed in compliance with that policy until such time as the specified time since issuance has elapsed.</li> </ol> </div> <div class="indent-2"> <h2 id="appendix-a-change-log">Appendix A - Change Log</h2> <p>The Change Log can be found at:</p> <p><a href="/participate/policy/nrpm/changelog/">https://www.arin.net/participate/policy/nrpm/changelog/</a></p> </div> </div> </div> <div class="right-rail right-rail-wide" role="region"> <div class="rr-content"> <a name="related-jump"></a> <h2 class="sidebar">Number Resource Policy Manual</h2> <ul><li><a href="/participate/policy/nrpm/changelog/">Number Resource Policy Manual Appendix A: Change Log </a></li> </ul> <h2 class="sidebar">Related</h2> <ul> <li><a href="/participate/policy/nrpm/nrpm.pdf">PDF Format</a></li> <li><a href="/participate/policy/nrpm/nrpm.txt">Text Version</a></li> </ul></div> </div> </div> </div> </div> <footer> <nav id="foot-top" class="btt" aria-labelledby="foot-top-label"><span id="foot-top-label"><a href="javascript:void(0)">Back to top</a></span></nav> <div id="scroll-btt" class="btt" aria-hidden="true"><i class="fa fa-lg fa-chevron-up"></i><p>Back<br>to top</p></div> <div class="foot-content"> <div class="row"> <div class="foot-col"> <ul class="foot-links"> <li><a href="https://account.arin.net/public/terms-of-service">Terms of Service</a></li> <li><a href="/sitemap/">Site Map</a></li> <li><a href="/about/privacy/">Privacy Policy</a></li> <li><a href="/reference/materials/abuse/">Network Abuse</a></li> <li><a href="/reference/accessibility">Accessibility</a></li> <li><a href="/about/corporate/standards/">Standards of Behavior</a></li> </ul> </div> <div class="foot-col"> <p class="foot-copy"> <img src="/img/logo-reverse.svg" alt="The ARIN logo" style="max-width:300px" /> © Copyright 1997 – 2024, American Registry for Internet Numbers, Ltd. </p> <p class="foot-copy"> <a href="http://www.nro.net/"><img src="/img/nro-logo2.png" alt="Visit the NRO website" /></a> </p> <p class="foot-copy"> A member of the Number Resource Organization </p> </div> <div class="foot-col"> <p class="foot-contact"> <a href="https://arin.statuspage.io/">Service Status</a> </p> <p class="foot-contact"> <a href="/contact/">Contact Us</a> </p> <p class="foot-contact"> Registration Services: <a href="tel:+1-703-227-0660">+1.703.227.0660</a><br /> Financial Services: <a href="tel:+1-703-227-9886">+1.703.227.9886</a><br /> Main: <a href="tel:+1-703-227-9840">+1.703.227.9840</a> </p> <p class="foot-contact"> <ul class="foot-social list-inline"> <li class="list-inline-item"><a href="https://www.facebook.com/TeamARIN"><i class="fa fa-facebook-official fa-fw" aria-hidden="true"></i><span>Visit ARIN on Facebook</span></a></li> <li class="list-inline-item" id="x-logo"><a href="https://x.com/TeamARIN"><svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 100 100"><path d="m99.45,9.05c0-5.62-2.88-8.52-8.44-8.52-27.32-.02-54.65-.02-81.97,0C3.28.53.54,3.34.54,9.17c0,13.66,0,27.32,0,40.98,0,13.58,0,27.16,0,40.73,0,5.73,2.84,8.58,8.62,8.59,27.16.02,54.31.02,81.47,0,5.91,0,8.82-2.87,8.83-8.7.02-27.24.02-54.48,0-81.72Zm-32.66,83.26c-7.38-10.72-14.86-21.6-22.48-32.68-9.55,11.1-18.94,22.01-28.25,32.83h-7.29c10.94-12.72,21.58-25.09,32.3-37.56C30.37,39.31,19.7,23.77,8.81,7.92h24.64c6.96,10.12,14.07,20.45,21.34,31.01,9.06-10.53,17.95-20.86,26.79-31.12h7.28c-10.42,12.12-20.57,23.93-30.82,35.86,11.08,16.13,22.14,32.23,33.41,48.64h-24.65Z"/><path d="m81.49,87.11h-11.23C53.25,62.79,36.14,38.32,18.81,13.52h11.23c16.94,24.23,34.05,48.7,51.45,73.59Z"/></svg><span>Visit ARIN on X</span></a></li> <li class="list-inline-item"><a href="https://www.linkedin.com/company/arin"><i class="fa fa-linkedin-square fa-fw" aria-hidden="true"></i><span>Visit ARIN on LinkedIn</span></a></li> <li class="list-inline-item"><a href="https://www.youtube.com/c/teamarin/"><i class="fa fa-youtube-square fa-fw" aria-hidden="true"></i><span>Visit ARIN on YouTube</span></a></li> </ul> </p> <p class="foot-contact"> <a href="/about/media/">Media</a> </p> </div> </div> </div> </footer> <div id="preload" aria-hidden="true"></div> <script src="/js/bootstrap.bundle.min.js"></script> <script src="/js/static-utils.js"></script> <script src="/js/nrpm.min.f577ea2c1a17cf7b82a2b5fb8b82c9ca0bcfb51f34828fdc0bf87061fbcd13d6.js"></script> <script src="/js/global.min.0ef2ed40d591a578ab9ef1d92a617c55a1b2253ebffbdb3e9101f5a13677c6f5.js"></script> <script src="/js/transition.min.532400102cb125cceb3210af6a66cb60004761fb4a4bc6f7f597c77096a2e903.js"></script> <script src="https://c2y23vzfb5cg.statuspage.io/embed/script.js"></script> </body> </html>