[arin-ppml] Draft Policy ARIN-2024-11: IPv4 Transition Efficiency Reallocation Policy (ITERP)

[David Farmer]

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 <bjones at vt.edu> 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 (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> https://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>


-- 
===============================================
David Farmer               Email:farmer at umn.edu
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
===============================================
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20250131/63619e2d/attachment-0001.htm>