To clarify, ITERP does not propose to allow the transfer of 4.10 space, but instead allow ISPs to reallocate /28 and /29, (or even /30 /31) to an End-User wanting to do things such as run their own Dual-Stack DNS, Dual Stack Load Balancers, or even CG-NAT implementations. IPv6-only networks large enough but not multi-homed via BGP. Many enterprise networks or other content networks don’t run BGP or require an entire /24, but only need a very small address space reallocated to them for their IPv6 networks. Limiting the reallocations to a maximum of a /28 makes abusing this policy difficult.
Preston Ursini > > Message: 1 > Date: Fri, 31 Jan 2025 21:32:31 +0000 > From: John Sweeting <[email protected]> > To: scott <[email protected]> > Cc: Jones Brian <[email protected]>, ARIN-PPML <[email protected]>, Jones > Brian <[email protected]> > Subject: Re: [arin-ppml] Draft Policy ARIN-2024-11: IPv4 Transition > Efficiency Reallocation Policy (ITERP) > Message-ID: <[email protected]> > Content-Type: text/plain; charset="utf-8" > > 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. > > ------------------------------ > > Message: 2 > Date: Fri, 31 Jan 2025 17:05:42 -0600 > From: David Farmer <[email protected]> > To: "Jones, Brian" <[email protected]> > Cc: ARIN-PPML <[email protected]> > Subject: Re: [arin-ppml] Draft Policy ARIN-2024-11: IPv4 Transition > Efficiency Reallocation Policy (ITERP) > Message-ID: > <can-dau09ec-htrdzwxcaeksa6qhrtbfcyutjh_mbqy2+hyu...@mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > 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 > =============================================== > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > <https://lists.arin.net/pipermail/arin-ppml/attachments/20250131/63619e2d/attachment.htm> > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > ARIN-PPML mailing list > [email protected] > https://lists.arin.net/mailman/listinfo/arin-ppml > > > ------------------------------ > > End of ARIN-PPML Digest, Vol 235, Issue 10 > ****************************************** _______________________________________________ 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.
