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.
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. Thanks. On Fri, Jan 31, 2025 at 1:46 PM Jones, Brian <[email protected]> wrote: > > 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. > > > > 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. > > > > 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. > > > > The policy experience report given by John Sweeting at ARIN 54 indicated > that *at the current rate* 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. > > > > 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? > > > Thank you in advance for your input and feedback. > > > > > > ------------------------------------------------------------------------------------------------------------- > > > > > On 25 October 2024, the ARIN Advisory Council (AC) accepted > “ARIN-prop-338: IPv4 Transition Efficiency Reallocation Policy (ITERP)” as > a Draft Policy. > > > > *Draft Policy ARIN-2024-11 is below and can be found at: > > > > https://www.arin.net/participate/policy/drafts/2024_11 > > > > 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: > > > > * Enabling Fair and Impartial Number Resource Administration > > * Technically Sound > > * Supported by the Community > > > > The PDP can be found at: > > > > https://www.arin.net/participate/policy/pdp/ > > > > Draft Policies and Proposals under discussion can be found at: > > > > https://www.arin.net/participate/policy/drafts/ > > > > Draft Policy ARIN-2024-11: IPv4 Transition Efficiency Reallocation Policy > (ITERP) > > > > Problem Statement: > > > > As the exhaustion of IPv4 addresses continues, ISPs and end-users face > increasing challenges in managing their transition to IPv6. Many end-users > require small amounts of IPv4 space to implement technologies like > Carrier-Grade NAT (CG-NAT) or dual-stack environments, which are critical > for their own IPv6 deployment efforts. Under the current NRPM 4.10 policy, > ISPs are prohibited from reallocating portions of their IPv4 blocks to > end-users, forcing these organizations to request larger, inefficiently > used blocks (e.g., /24s) from ARIN. > > > > This practice contributes to the unnecessary consumption of scarce IPv4 > resources, as many end-users only need small blocks (e.g., /29s or /28s) > for their CG-NAT and IPv6 transition processes. The inability to reallocate > these smaller blocks results in wasteful allocations and hampers the > overall efficiency of IPv4 address management. > > > > Without a mechanism to allow ISPs to reallocate small portions of their > NRPM 4.10 space to qualified end-users, the current policy inadvertently > encourages inefficient IPv4 address utilization, which conflicts with > ARIN’s goal of maximizing the use of remaining IPv4 resources while > facilitating the widespread adoption of IPv6. > > > > The problem is twofold: > > > > 1. End-users are forced to request larger, underutilized IPv4 blocks for > their IPv6 transition needs. > > > > 2. ISPs are unable to efficiently manage and reallocate their IPv4 > resources under NRPM 4.10 to meet end-user demands for small-scale CG-NAT > and IPv6 transition deployments. > > > > Policy Statement: > > > > Add these bullets to section 4.10 of the NRPM to facilitate ARIN approved > reallocation of 4.10 resources. > > > > * ISPs may reassign a /29 or /28 for their direct downstream customers for > IPv6 transition only. ARIN reserves the right to validate any downstream > allocations from ISPs to direct customers. > > > > * Anyone wishing to perform a reassignment of a 4.10 allocation must be > approved through ARIN and meet all the justification requirements of this > policy. > > > > Comments: > > > > IPv4 Transition Efficiency Reallocation Policy (ITERP) and Its Impact on > CG-NAT, IPv6, and Efficient Resource Use > > > > Utilization of Reallocated IP Space by End-Users and Small ISPs for CG-NAT > > > > Under the IPv4 Transition Efficiency Reallocation Policy (ITERP), > end-users and even small ISPs can efficiently use reallocated IPv4 space > for CG-NAT (Carrier-Grade NAT) while leveraging their IPv6 deployments. > Many smaller ISPs, particularly those that only have NRPM 4.10 space and > limited IPv4 allocations, could benefit from this policy by reallocating > IPv4 subnets (e.g., /29 or /28) to their customers or other ISPs who > require minimal IPv4 addresses for CG-NAT in dual-stack environments. > > > > Through the use of BGP for IPv6, along with alternative IPv4 multi-homing > technologies like source and policy based routing combined with CG-NAT, > end-users or small ISPs could even connect to multiple providers utilizing > IPv6 natively while performing CG-NAT towards multiple providers over IPv4. > This approach helps balance traffic, increase redundancy, and achieve > better failover capabilities. By employing IPv6 for outward-facing traffic > and CG-NAT for IPv4 communication, smaller networks can provide their > customers a seamless experience without consuming large amounts of IPv4 > space. > > > > Eligibility and Address Space Efficiency > > > > This policy amendment is strictly intended for organizations that would > otherwise be eligible for a /24 under NRPM 4.10. Instead of receiving an > entire /24 (256 addresses) that may go largely underutilized, these > end-users could now request smaller blocks (e.g., /29s or /28s) from > multiple providers that only hold NRPM 4.10 space. This allows for much > more efficient use of IPv4 resources, as the smaller allocations can > directly serve CG-NAT needs without wasting a significant portion of the > address space. > > > > Such end-users are typically transitioning to IPv6 and need small amounts > of IPv4 space only for backward compatibility and legacy systems. This > policy ensures that they don’t have to unnecessarily consume large blocks > of IPv4 addresses that are rapidly depleting, especially since most of > their traffic will run over IPv6. > > > > Incentivizing IPv6 Deployment by ISPs > > > > This policy can also incentivize ISPs to evangelize IPv6 deployment to > their customers. As the ISPs are held accountable for monitoring and > reporting the usage of reallocated space, they are motivated to actively > assist their customers in migrating to IPv6 to ensure compliance with > ARIN’s policies. By reallocating IPv4 space under the NRPM 4.10 policy, > ISPs will naturally push for greater IPv6 adoption and encourage their > end-users to take advantage of the superior capabilities and scalability of > IPv6. > > > > In many cases, ISPs can act as trusted technology advocates, guiding their > customers through the transition process, offering resources, and providing > technical support for deploying dual-stack environments. This not only > supports IPv6 growth but also fosters stronger partnerships between ISPs > and their customers as they collectively work toward the next generation of > networking technologies. > > > > Supporting ISPs with Only NRPM 4.10 Space and IPv6 > > > > Many ISPs, particularly newer or smaller ones, may only have access to > NRPM 4.10 IPv4 space and IPv6 allocations. These ISPs often lack sufficient > general-purpose IPv4 space but are fully invested in deploying IPv6 to > their customers. The IPv4 Transition Efficiency Reallocation Policy > provides an efficient and pragmatic way for these ISPs to serve end-users > with small-scale CG-NAT needs, helping them facilitate IPv6 adoption > without having to apply for entire /24s of IPv4 space that they don’t > require. > > > > By allowing the reallocation of small IPv4 blocks to end-users for CG-NAT > and IPv6 dual-stack environments, IPv4 exhaustion can be minimized, and > numbering resources can be more efficiently utilized. These ISPs can push > their customers toward IPv6 while offering minimal IPv4 resources needed > for NAT and legacy services. This policy, therefore, promotes responsible > IPv4 stewardship and accelerates the migration to IPv6. > > > > Conclusion: Efficient Use of Resources and Push for IPv6 Adoption > > > > The IPv4 Transition Efficiency Reallocation Policy (ITERP) ensures that > IPv4 address space is used efficiently by allowing small allocations to > end-users for specific transitional technologies like CG-NAT. By utilizing > BGP for IPv6 and multi-homing technologies, end-users can effectively route > traffic while minimizing their reliance on IPv4. This policy enables ISPs, > particularly those that only have NRPM 4.10 space, to act as leaders in the > push for IPv6, ensuring that numbering resources are preserved while > advancing the deployment of the next generation of Internet technology. > > > > Other technologies are also available, such as routing IPv4 space over > IPv6, which is supported in many modern routing systems, meaning a /32 of > IPv4 space could be routed to an end-user over a native IPv6 network with > no other space involved. This policy would encourage ISPs to evangelize and > accelerate the deployment of an IPv6 Internet by making deploying IPv6 even > more beneficial to end users, while also preserving the precious remaining > IPv4 address space. > > > > By embracing this approach, ARIN can foster greater IPv6 adoption, prevent > IPv4 depletion, and empower ISPs and end-users alike to move forward with > innovative, future-proof network architectures. > > > > This policy provides a more efficient and responsible approach to > achieving the goals initially intended by ARIN-2008-5, which aimed to allow > the use of longer prefixes than /24s without causing the complications > associated with ARIN allocating such longer prefixes directly. > > > > When ARIN-2008-5 was introduced, the idea was to allow networks to receive > smaller allocations than /24, recognizing that many organizations, > particularly those transitioning to IPv6, do not require a full /24 for > their IPv4 needs. However, allocating smaller prefixes directly from ARIN > would have created routing and administrative challenges, including > concerns about route fragmentation and maintaining the integrity of the > global routing table. > > > > The IPv4 Transition Efficiency Reallocation Policy (ITERP) resolves these > issues by enabling ISPs to handle the reallocation of small IPv4 blocks > (such as /29 or /28) from their NRPM 4.10 space, instead of ARIN directly > assigning longer prefixes. This allows for more granular and flexible use > of address space without fragmenting ARIN’s allocations, ensuring that the > allocations remain efficient and manageable. > > > > Furthermore, by placing responsibility on the ISPs to ensure proper > utilization, ITERP: > > > > • Minimizes the risk of route table bloat, as ISPs manage these smaller > blocks within their own infrastructure. > > • Ensures IPv4 allocations are tied to specific, justified use cases (such > as CG-NAT and IPv6 transition), aligning with the original intent of > ARIN-2008-5 to avoid wasteful consumption of IPv4 addresses. > > > > In doing so, this policy not only promotes efficient use of IPv4 space but > also strengthens the transition to IPv6 by encouraging ISPs to work closely > with their customers on deploying dual-stack environments, thus driving > greater IPv6 adoption. This policy balances the need for flexibility in > smaller allocations while preventing the complications that could arise > from direct ARIN allocations of smaller prefixes. > > > > Timetable for implementation: Immediate > > > ------------------------------------------------------------------------------------------------------------- > > _ > Brian Jones > ARIN Advisory Council > > > > > > _______________________________________________ > ARIN-PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List ([email protected]). > Unsubscribe or manage your mailing list subscription at: > https://lists.arin.net/mailman/listinfo/arin-ppml > Please contact [email protected] if you experience any issues. > -- =============================================== David Farmer Email:[email protected] Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 ===============================================
_______________________________________________ ARIN-PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List ([email protected]). Unsubscribe or manage your mailing list subscription at: https://lists.arin.net/mailman/listinfo/arin-ppml Please contact [email protected] if you experience any issues.
