<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">
Good observations Dave, thank you for the feedback.
<div><br id="lineBreakAtBeginningOfMessage">
<div>
<div dir="auto" style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">
<div>_</div>
<div>Brian Jones</div>
<div>ARIN Advisory Council</div>
<div><br>
</div>
<div><br>
</div>
</div>
<br class="Apple-interchange-newline">
<br class="Apple-interchange-newline">
</div>
<div><br>
<blockquote type="cite">
<div>On Jan 31, 2025, at 18:05, David Farmer <farmer@umn.edu> wrote:</div>
<br class="Apple-interchange-newline">
<div>
<div dir="ltr">
<div>The current 4.10 envisions directly allocating a whole /24 to an end user and having them operate their own NAT64 IPv6 transition service; in some cases, this isn't very efficient. Some smaller end users may not need a full 24 for their NAT64 needs.</div>
<div><br>
</div>
<div>I interpret the proposal as allowing for NAT64-as-a-Service where the customer is IPv6-only, and a service provider provides the NAT64, dedicating a small IPv4 pool, less than /24 per customer for each customer's NAT64 needs. This would allow for more
efficient use of the 4.10 pool, and such a use case would be consistent with 4.10 rules if the NAT64-as-a-Service provided reassignments of smaller blocks to its customers.</div>
<div><br>
</div>
<div>Thanks.</div>
<br>
<div class="gmail_quote gmail_quote_container">
<div dir="ltr" class="gmail_attr">On Fri, Jan 31, 2025 at 1:46 PM Jones, Brian <<a href="mailto:bjones@vt.edu">bjones@vt.edu</a>> wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<div><br>
</div>
<div>
<div style="">
<div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;">As shepherds of Draft Policy ARIN-2024-11 Kaitlyn and I would very much like to refocus the discussion surrounding it. When this was circulated to the PPML last October there was some
discussion, but much of it was not directed at the root issues associated with these proposed changes. <span style="color:rgb(255,0,0)"><u></u><u></u></span></div>
</div>
<div style="">
<div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;"><u></u> <u></u></div>
</div>
<div style="">
<div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;">My very unofficial hallway discussions indicate the space that gets allocated from section 4.10 of the Number Resource Policy Manual is a large target for those wishing to do other things
with that space than convert their organization to IPv6. <u></u><u></u></div>
</div>
<div style="">
<div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;"><u></u> <u></u></div>
</div>
<div style="">
<div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;">This section was never intended to allocate resources that would then be reallocated to another entity or used for any other purpose than to allow for the conversion of the applicant
to IPv6. <u></u><u></u></div>
</div>
<div style="">
<div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;"><u></u> <u></u></div>
</div>
<div style="">
<div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;">The policy experience report given by John Sweeting at ARIN 54 indicated that <i>at the current rate</i> of allocations from section 4.10 of the NRPM there should be enough to last through
the year 2050 or approximately 25 years. Keep in mind that the 4.10 dedicated pool has a mandate to be replenished when it gets down below a 3 year supply. This would mean any ARIN recovered IPv4 address space would come back into this pool for replenishment
instead of the waitlist once this threshold is reached.<u></u><u></u></div>
</div>
<div style="">
<div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;"><u></u> <u></u></div>
</div>
<div style="">
<div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;">So with these things in mind my question to the community is do we really need to allow reallocations from applicants of this dedicated space as this policy is suggesting or should each
entity that needs IPv4 space to facilitate their transition to IPv6 continue to apply for their own /24 as the policy is currently written?</div>
<div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;"><br>
</div>
<div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;">Thank you in advance for your input and feedback.</div>
<div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;"><br>
</div>
<div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;"><br>
</div>
<div>
<div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;"><span style="font-size:11pt"><br>
</span></div>
<div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;"><span style="font-size:11pt">-------------------------------------------------------------------------------------------------------------</span></div>
<div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;"><span style="font-size:11pt"><br>
</span></div>
<div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;"><span style="font-size:11pt"><br>
</span></div>
<div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;"><span style="font-size:11pt"><br>
</span></div>
<div style="margin: 0in; font-size: 11pt; font-family: Aptos, sans-serif;">On 25 October 2024, the ARIN Advisory Council (AC) accepted “ARIN-prop-338: IPv4 Transition Efficiency Reallocation Policy (ITERP)” as a Draft Policy.<u></u><u></u></div>
<div style="margin: 0in; font-size: 11pt; font-family: Aptos, sans-serif;"><u></u> <u></u></div>
<div style="margin: 0in; font-size: 11pt; font-family: Aptos, sans-serif;">*Draft Policy ARIN-2024-11 is below and can be found at:<u></u><u></u></div>
<div style="margin: 0in; font-size: 11pt; font-family: Aptos, sans-serif;"><u></u> <u></u></div>
<div style="margin: 0in; font-size: 11pt; font-family: Aptos, sans-serif;"><a href="https://www.arin.net/participate/policy/drafts/2024_11" originalsrc="https://www.arin.net/participate/policy/drafts/2024_11" shash="xWOxGv8WmVyYSVWPs92W4kFBoAVkFRH1Yy6fVQ5yKEVhzy5uEvfJ2l3rDVBINqfpcNmKguiJVTGf241JolHisGU6gb3tDGigP+niKO7ux/9uyHp5AwmRQaZhKW+FOhfOLdlYRfCeA7TV4Sus1vE0+yujclazt0KZkZvOaE+PaW8=" target="_blank">https://www.arin.net/participate/policy/drafts/2024_11</a><u></u><u></u></div>
<div style="margin: 0in; font-size: 11pt; font-family: Aptos, sans-serif;"><u></u> <u></u></div>
<div style="margin: 0in; font-size: 11pt; font-family: Aptos, sans-serif;">You are encouraged to discuss all Draft Policies on PPML. The AC will evaluate the discussion to assess the conformance of this draft policy with ARIN's Principles of Internet number
resource policy as stated in the Policy Development Process (PDP). Specifically, these principles are:<u></u><u></u></div>
<div style="margin: 0in; font-size: 11pt; font-family: Aptos, sans-serif;"><u></u> <u></u></div>
<div style="margin: 0in; font-size: 11pt; font-family: Aptos, sans-serif;">* Enabling Fair and Impartial Number Resource Administration<u></u><u></u></div>
<div style="margin: 0in; font-size: 11pt; font-family: Aptos, sans-serif;">* Technically Sound<u></u><u></u></div>
<div style="margin: 0in; font-size: 11pt; font-family: Aptos, sans-serif;">* Supported by the Community<u></u><u></u></div>
<div style="margin: 0in; font-size: 11pt; font-family: Aptos, sans-serif;"><u></u> <u></u></div>
<div style="margin: 0in; font-size: 11pt; font-family: Aptos, sans-serif;">The PDP can be found at:<u></u><u></u></div>
<div style="margin: 0in; font-size: 11pt; font-family: Aptos, sans-serif;"><u></u> <u></u></div>
<div style="margin: 0in; font-size: 11pt; font-family: Aptos, sans-serif;"><a href="https://www.arin.net/participate/policy/pdp/" originalsrc="https://www.arin.net/participate/policy/pdp/" shash="blYZ0Ac14/wXgQbDhAbj6YQw5A7JPyGVBDsjASsPcyIql4DhbqFoWRyGDUdoCAe1SHoYUjEO0tSRnhe5/p5uQQmdD59R10mY1yjEZN2RNLIgKai5Rxr7dLXN10oB/Eprsx+jm01w36d/TICpDVVyqzhhf235BWUyym9mtLHCKyk=" target="_blank">https://www.arin.net/participate/policy/pdp/</a> <u></u><u></u></div>
<div style="margin: 0in; font-size: 11pt; font-family: Aptos, sans-serif;"><u></u> <u></u></div>
<div style="margin: 0in; font-size: 11pt; font-family: Aptos, sans-serif;">Draft Policies and Proposals under discussion can be found at:<u></u><u></u></div>
<div style="margin: 0in; font-size: 11pt; font-family: Aptos, sans-serif;"><u></u> <u></u></div>
<div style="margin: 0in; font-size: 11pt; font-family: Aptos, sans-serif;"><a href="https://www.arin.net/participate/policy/drafts/" originalsrc="https://www.arin.net/participate/policy/drafts/" shash="JrrZgMuf+pDlDFy2WCEr4L6mU/Jt1YvjP0owMZH6vyR7qB3xjSDo67kx8duORRHZOsJpWaQMiQoztufXTP7hfdSk98TlygN2cQb1bC2iBk7R6T7cW/fwG65Lbd4k4l4xBDWaKRduc2HDY+3duHVmtnGyCsMs8rA9B9ZOZVPf90k=" target="_blank">https://www.arin.net/participate/policy/drafts/</a></div>
<div style="margin: 0in; font-size: 11pt; font-family: Aptos, sans-serif;"><br>
</div>
<div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;"><span style="font-size:11pt"><br>
</span></div>
<div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;"><span style="font-size:11pt">Draft Policy ARIN-2024-11: IPv4 Transition Efficiency Reallocation Policy (ITERP)<u></u><u></u></span></div>
</div>
<div>
<div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;"><span style="font-size:11pt"> <u></u><u></u></span></div>
</div>
<div>
<div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;"><span style="font-size:11pt">Problem Statement:<u></u><u></u></span></div>
</div>
<div>
<div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;"><span style="font-size:11pt"> <u></u><u></u></span></div>
</div>
<div>
<div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;"><span style="font-size:11pt">As the exhaustion of IPv4 addresses continues, ISPs and end-users face increasing challenges in managing their transition to IPv6. Many end-users require
small amounts of IPv4 space to implement technologies like Carrier-Grade NAT (CG-NAT) or dual-stack environments, which are critical for their own IPv6 deployment efforts. Under the current NRPM 4.10 policy, ISPs are prohibited from reallocating portions of
their IPv4 blocks to end-users, forcing these organizations to request larger, inefficiently used blocks (e.g., /24s) from ARIN.<u></u><u></u></span></div>
</div>
<div>
<div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;"><span style="font-size:11pt"> <u></u><u></u></span></div>
</div>
<div>
<div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;"><span style="font-size:11pt">This practice contributes to the unnecessary consumption of scarce IPv4 resources, as many end-users only need small blocks (e.g., /29s or /28s) for their
CG-NAT and IPv6 transition processes. The inability to reallocate these smaller blocks results in wasteful allocations and hampers the overall efficiency of IPv4 address management.<u></u><u></u></span></div>
</div>
<div>
<div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;"><span style="font-size:11pt"> <u></u><u></u></span></div>
</div>
<div>
<div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;"><span style="font-size:11pt">Without a mechanism to allow ISPs to reallocate small portions of their NRPM 4.10 space to qualified end-users, the current policy inadvertently encourages
inefficient IPv4 address utilization, which conflicts with ARIN’s goal of maximizing the use of remaining IPv4 resources while facilitating the widespread adoption of IPv6.<u></u><u></u></span></div>
</div>
<div>
<div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;"><span style="font-size:11pt"> <u></u><u></u></span></div>
</div>
<div>
<div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;"><span style="font-size:11pt">The problem is twofold:<u></u><u></u></span></div>
</div>
<div>
<div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;"><span style="font-size:11pt"> <u></u><u></u></span></div>
</div>
<div>
<div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;"><span style="font-size:11pt">1. End-users are forced to request larger, underutilized IPv4 blocks for their IPv6 transition needs.<u></u><u></u></span></div>
</div>
<div>
<div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;"><span style="font-size:11pt"> <u></u><u></u></span></div>
</div>
<div>
<div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;"><span style="font-size:11pt">2. ISPs are unable to efficiently manage and reallocate their IPv4 resources under NRPM 4.10 to meet end-user demands for small-scale CG-NAT and IPv6 transition
deployments.<u></u><u></u></span></div>
</div>
<div>
<div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;"><span style="font-size:11pt"> <u></u><u></u></span></div>
</div>
<div>
<div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;"><span style="font-size:11pt">Policy Statement:<u></u><u></u></span></div>
</div>
<div>
<div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;"><span style="font-size:11pt"> <u></u><u></u></span></div>
</div>
<div>
<div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;"><span style="font-size:11pt">Add these bullets to section 4.10 of the NRPM to facilitate ARIN approved reallocation of 4.10 resources.<u></u><u></u></span></div>
</div>
<div>
<div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;"><span style="font-size:11pt"> <u></u><u></u></span></div>
</div>
<div>
<div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;"><span style="font-size:11pt">* ISPs may reassign a /29 or /28 for their direct downstream customers for IPv6 transition only. ARIN reserves the right to validate any downstream allocations
from ISPs to direct customers.<u></u><u></u></span></div>
</div>
<div>
<div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;"><span style="font-size:11pt"> <u></u><u></u></span></div>
</div>
<div>
<div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;"><span style="font-size:11pt">* Anyone wishing to perform a reassignment of a 4.10 allocation must be approved through ARIN and meet all the justification requirements of this policy.<u></u><u></u></span></div>
</div>
<div>
<div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;"><span style="font-size:11pt"> <u></u><u></u></span></div>
</div>
<div>
<div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;"><span style="font-size:11pt">Comments:<u></u><u></u></span></div>
</div>
<div>
<div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;"><span style="font-size:11pt"> <u></u><u></u></span></div>
</div>
<div>
<div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;"><span style="font-size:11pt">IPv4 Transition Efficiency Reallocation Policy (ITERP) and Its Impact on CG-NAT, IPv6, and Efficient Resource Use<u></u><u></u></span></div>
</div>
<div>
<div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;"><span style="font-size:11pt"> <u></u><u></u></span></div>
</div>
<div>
<div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;"><span style="font-size:11pt">Utilization of Reallocated IP Space by End-Users and Small ISPs for CG-NAT<u></u><u></u></span></div>
</div>
<div>
<div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;"><span style="font-size:11pt"> <u></u><u></u></span></div>
</div>
<div>
<div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;"><span style="font-size:11pt">Under the IPv4 Transition Efficiency Reallocation Policy (ITERP), end-users and even small ISPs can efficiently use reallocated IPv4 space for CG-NAT (Carrier-Grade
NAT) while leveraging their IPv6 deployments. Many smaller ISPs, particularly those that only have NRPM 4.10 space and limited IPv4 allocations, could benefit from this policy by reallocating IPv4 subnets (e.g., /29 or /28) to their customers or other ISPs
who require minimal IPv4 addresses for CG-NAT in dual-stack environments.<u></u><u></u></span></div>
</div>
<div>
<div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;"><span style="font-size:11pt"> <u></u><u></u></span></div>
</div>
<div>
<div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;"><span style="font-size:11pt">Through the use of BGP for IPv6, along with alternative IPv4 multi-homing technologies like source and policy based routing combined with CG-NAT, end-users
or small ISPs could even connect to multiple providers utilizing IPv6 natively while performing CG-NAT towards multiple providers over IPv4. This approach helps balance traffic, increase redundancy, and achieve better failover capabilities. By employing IPv6
for outward-facing traffic and CG-NAT for IPv4 communication, smaller networks can provide their customers a seamless experience without consuming large amounts of IPv4 space.<u></u><u></u></span></div>
</div>
<div>
<div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;"><span style="font-size:11pt"> <u></u><u></u></span></div>
</div>
<div>
<div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;"><span style="font-size:11pt">Eligibility and Address Space Efficiency<u></u><u></u></span></div>
</div>
<div>
<div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;"><span style="font-size:11pt"> <u></u><u></u></span></div>
</div>
<div>
<div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;"><span style="font-size:11pt">This policy amendment is strictly intended for organizations that would otherwise be eligible for a /24 under NRPM 4.10. Instead of receiving an entire /24
(256 addresses) that may go largely underutilized, these end-users could now request smaller blocks (e.g., /29s or /28s) from multiple providers that only hold NRPM 4.10 space. This allows for much more efficient use of IPv4 resources, as the smaller allocations
can directly serve CG-NAT needs without wasting a significant portion of the address space.<u></u><u></u></span></div>
</div>
<div>
<div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;"><span style="font-size:11pt"> <u></u><u></u></span></div>
</div>
<div>
<div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;"><span style="font-size:11pt">Such end-users are typically transitioning to IPv6 and need small amounts of IPv4 space only for backward compatibility and legacy systems. This policy ensures
that they don’t have to unnecessarily consume large blocks of IPv4 addresses that are rapidly depleting, especially since most of their traffic will run over IPv6.<u></u><u></u></span></div>
</div>
<div>
<div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;"><span style="font-size:11pt"> <u></u><u></u></span></div>
</div>
<div>
<div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;"><span style="font-size:11pt">Incentivizing IPv6 Deployment by ISPs<u></u><u></u></span></div>
</div>
<div>
<div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;"><span style="font-size:11pt"> <u></u><u></u></span></div>
</div>
<div>
<div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;"><span style="font-size:11pt">This policy can also incentivize ISPs to evangelize IPv6 deployment to their customers. As the ISPs are held accountable for monitoring and reporting the
usage of reallocated space, they are motivated to actively assist their customers in migrating to IPv6 to ensure compliance with ARIN’s policies. By reallocating IPv4 space under the NRPM 4.10 policy, ISPs will naturally push for greater IPv6 adoption and
encourage their end-users to take advantage of the superior capabilities and scalability of IPv6.<u></u><u></u></span></div>
</div>
<div>
<div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;"><span style="font-size:11pt"> <u></u><u></u></span></div>
</div>
<div>
<div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;"><span style="font-size:11pt">In many cases, ISPs can act as trusted technology advocates, guiding their customers through the transition process, offering resources, and providing technical
support for deploying dual-stack environments. This not only supports IPv6 growth but also fosters stronger partnerships between ISPs and their customers as they collectively work toward the next generation of networking technologies.<u></u><u></u></span></div>
</div>
<div>
<div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;"><span style="font-size:11pt"> <u></u><u></u></span></div>
</div>
<div>
<div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;"><span style="font-size:11pt">Supporting ISPs with Only NRPM 4.10 Space and IPv6<u></u><u></u></span></div>
</div>
<div>
<div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;"><span style="font-size:11pt"> <u></u><u></u></span></div>
</div>
<div>
<div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;"><span style="font-size:11pt">Many ISPs, particularly newer or smaller ones, may only have access to NRPM 4.10 IPv4 space and IPv6 allocations. These ISPs often lack sufficient general-purpose
IPv4 space but are fully invested in deploying IPv6 to their customers. The IPv4 Transition Efficiency Reallocation Policy provides an efficient and pragmatic way for these ISPs to serve end-users with small-scale CG-NAT needs, helping them facilitate IPv6
adoption without having to apply for entire /24s of IPv4 space that they don’t require.<u></u><u></u></span></div>
</div>
<div>
<div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;"><span style="font-size:11pt"> <u></u><u></u></span></div>
</div>
<div>
<div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;"><span style="font-size:11pt">By allowing the reallocation of small IPv4 blocks to end-users for CG-NAT and IPv6 dual-stack environments, IPv4 exhaustion can be minimized, and numbering
resources can be more efficiently utilized. These ISPs can push their customers toward IPv6 while offering minimal IPv4 resources needed for NAT and legacy services. This policy, therefore, promotes responsible IPv4 stewardship and accelerates the migration
to IPv6.<u></u><u></u></span></div>
</div>
<div>
<div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;"><span style="font-size:11pt"> <u></u><u></u></span></div>
</div>
<div>
<div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;"><span style="font-size:11pt">Conclusion: Efficient Use of Resources and Push for IPv6 Adoption<u></u><u></u></span></div>
</div>
<div>
<div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;"><span style="font-size:11pt"> <u></u><u></u></span></div>
</div>
<div>
<div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;"><span style="font-size:11pt">The IPv4 Transition Efficiency Reallocation Policy (ITERP) ensures that IPv4 address space is used efficiently by allowing small allocations to end-users
for specific transitional technologies like CG-NAT. By utilizing BGP for IPv6 and multi-homing technologies, end-users can effectively route traffic while minimizing their reliance on IPv4. This policy enables ISPs, particularly those that only have NRPM 4.10
space, to act as leaders in the push for IPv6, ensuring that numbering resources are preserved while advancing the deployment of the next generation of Internet technology.<u></u><u></u></span></div>
</div>
<div>
<div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;"><span style="font-size:11pt"> <u></u><u></u></span></div>
</div>
<div>
<div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;"><span style="font-size:11pt">Other technologies are also available, such as routing IPv4 space over IPv6, which is supported in many modern routing systems, meaning a /32 of IPv4 space
could be routed to an end-user over a native IPv6 network with no other space involved. This policy would encourage ISPs to evangelize and accelerate the deployment of an IPv6 Internet by making deploying IPv6 even more beneficial to end users, while also
preserving the precious remaining IPv4 address space.<u></u><u></u></span></div>
</div>
<div>
<div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;"><span style="font-size:11pt"> <u></u><u></u></span></div>
</div>
<div>
<div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;"><span style="font-size:11pt">By embracing this approach, ARIN can foster greater IPv6 adoption, prevent IPv4 depletion, and empower ISPs and end-users alike to move forward with innovative,
future-proof network architectures.<u></u><u></u></span></div>
</div>
<div>
<div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;"><span style="font-size:11pt"> <u></u><u></u></span></div>
</div>
<div>
<div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;"><span style="font-size:11pt">This policy provides a more efficient and responsible approach to achieving the goals initially intended by ARIN-2008-5, which aimed to allow the use of
longer prefixes than /24s without causing the complications associated with ARIN allocating such longer prefixes directly.<u></u><u></u></span></div>
</div>
<div>
<div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;"><span style="font-size:11pt"> <u></u><u></u></span></div>
</div>
<div>
<div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;"><span style="font-size:11pt">When ARIN-2008-5 was introduced, the idea was to allow networks to receive smaller allocations than /24, recognizing that many organizations, particularly
those transitioning to IPv6, do not require a full /24 for their IPv4 needs. However, allocating smaller prefixes directly from ARIN would have created routing and administrative challenges, including concerns about route fragmentation and maintaining the
integrity of the global routing table.<u></u><u></u></span></div>
</div>
<div>
<div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;"><span style="font-size:11pt"> <u></u><u></u></span></div>
</div>
<div>
<div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;"><span style="font-size:11pt">The IPv4 Transition Efficiency Reallocation Policy (ITERP) resolves these issues by enabling ISPs to handle the reallocation of small IPv4 blocks (such as
/29 or /28) from their NRPM 4.10 space, instead of ARIN directly assigning longer prefixes. This allows for more granular and flexible use of address space without fragmenting ARIN’s allocations, ensuring that the allocations remain efficient and manageable.<u></u><u></u></span></div>
</div>
<div>
<div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;"><span style="font-size:11pt"> <u></u><u></u></span></div>
</div>
<div>
<div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;"><span style="font-size:11pt">Furthermore, by placing responsibility on the ISPs to ensure proper utilization, ITERP:<u></u><u></u></span></div>
</div>
<div>
<div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;"><span style="font-size:11pt"> <u></u><u></u></span></div>
</div>
<div>
<div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;"><span style="font-size:11pt">• Minimizes the risk of route table bloat, as ISPs manage these smaller blocks within their own infrastructure.<u></u><u></u></span></div>
</div>
<div>
<div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;"><span style="font-size:11pt">• Ensures IPv4 allocations are tied to specific, justified use cases (such as CG-NAT and IPv6 transition), aligning with the original intent of ARIN-2008-5
to avoid wasteful consumption of IPv4 addresses.<u></u><u></u></span></div>
</div>
<div>
<div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;"><span style="font-size:11pt"> <u></u><u></u></span></div>
</div>
<div>
<div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;"><span style="font-size:11pt">In doing so, this policy not only promotes efficient use of IPv4 space but also strengthens the transition to IPv6 by encouraging ISPs to work closely with
their customers on deploying dual-stack environments, thus driving greater IPv6 adoption. This policy balances the need for flexibility in smaller allocations while preventing the complications that could arise from direct ARIN allocations of smaller prefixes.<u></u><u></u></span></div>
</div>
<div>
<div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;"><span style="font-size:11pt"> <u></u><u></u></span></div>
</div>
<div>
<div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;"><span style="font-size:11pt">Timetable for implementation: Immediate</span></div>
</div>
</div>
</div>
<div><br>
</div>
<div><span style="font-family: Aptos, sans-serif; font-size: 14.6667px;">-------------------------------------------------------------------------------------------------------------</span></div>
<br>
<div>
<div dir="auto" style="letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; text-decoration: none;">
<div>_</div>
<div>Brian Jones</div>
<div>ARIN Advisory Council</div>
<div><br>
</div>
<div><br>
</div>
</div>
<br>
<br>
</div>
<br>
</div>
_______________________________________________<br>
ARIN-PPML<br>
You are receiving this message because you are subscribed to<br>
the ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net" target="_blank">ARIN-PPML@arin.net</a>).<br>
Unsubscribe or manage your mailing list subscription at:<br>
<a href="https://lists.arin.net/mailman/listinfo/arin-ppml" originalsrc="https://lists.arin.net/mailman/listinfo/arin-ppml" shash="KsMjyJA444Yi5Cs2TpGquaj3/P4ah50bJaLnk1HxXHmG3Kd4FWGAkb35JzMNulCTLrjIoTcm3eUEQXlsNIBiUU7XGcgO/DpW68UC4RP3GCgPJRaZAi8NzceTwKiF5TQsaLgnnp5TFMddJwvufYzh6o+Aq/miGwL9w52/xRk2vqA=" rel="noreferrer" target="_blank">https://lists.arin.net/mailman/listinfo/arin-ppml</a><br>
Please contact <a href="mailto:info@arin.net" target="_blank">info@arin.net</a> if you experience any issues.<br>
</blockquote>
</div>
<div><br clear="all">
</div>
<div><br>
</div>
<span class="gmail_signature_prefix">-- </span><br>
<div dir="ltr" class="gmail_signature">===============================================<br>
David Farmer <a href="mailto:Email%3Afarmer@umn.edu" target="_blank">
Email:farmer@umn.edu</a><br>
Networking & Telecommunication Services<br>
Office of Information Technology<br>
University of Minnesota <br>
2218 University Ave SE Phone: 612-626-0815<br>
Minneapolis, MN 55414-3029 Cell: 612-812-9952<br>
=============================================== </div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</body>
</html>