FYI 4.10 space can only be transferred under NRPM section 8.2 Mergers, Acquisitions and Reorganizations. When being transferred under 8.2 the recipient organization must submit a notarized affidavit that the space will continue to be used in compliance with section 4.10 or return the space.
Sent from my iPhone > On Jan 31, 2025, at 3:00 PM, scott <[email protected]> wrote: > > Hi Brian, > > My take on this is that folks may want to abuse 4.10 if they can then > transfer the resources to another entity. The cost of organizing an entity > is far less than the "market value" of a /24, which will encourage gaming > this system. IMHO, 4.10 is for "I am building a network, and I need these > resources to transition or support my v6 deployment." As such, M&A is > problably the only legit reason to want to transfer these resources, but that > can be gamed too... IIRC John Sweeting reported the recovery of some 7M > addresses from a similar scheme a couple of years ago. > > In summary, we should restrict the transfer of 4.10, IMHO. > > Scott > > > >> On Fri, 31 Jan 2025, Jones, Brian 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. _______________________________________________ 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.
