[arin-ppml] Draft Policy ARIN-2024-11: IPv4 Transition
Jones, Brian
bjones at vt.edu
Mon Feb 3 09:19:38 EST 2025
Thank you for the clarification Preston.
_
Brian Jones
ARIN Advisory Council
On Jan 31, 2025, at 18:14, Preston Ursini via ARIN-PPML <arin-ppml at arin.net> wrote:
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 <jsweeting at arin.net>
To: scott <scott at solarnetone.org>
Cc: Jones Brian <bjones at vt.edu>, ARIN-PPML <arin-ppml at arin.net>, Jones
Brian <bjones at vt.edu>
Subject: Re: [arin-ppml] Draft Policy ARIN-2024-11: IPv4 Transition
Efficiency Reallocation Policy (ITERP)
Message-ID: <6805FF61-48C6-4BB4-8341-959173DF3FA2 at arin.net>
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 <scott at solarnetone.org> 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://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.arin.net%2Fparticipate%2Fpolicy%2Fdrafts%2F2024_11&data=05%7C02%7Cbjones%40vt.edu%7C35bbb01328e0419f5f1708dd424cfffc%7C6095688410ad40fa863d4f32c1e3a37a%7C0%7C0%7C638739620725859076%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=VIFgv2aK%2FalR%2B5iDTfbuuIfJLr1iNRyrBPKtEgcbEPY%3D&reserved=0
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://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.arin.net%2Fparticipate%2Fpolicy%2Fpdp%2F&data=05%7C02%7Cbjones%40vt.edu%7C35bbb01328e0419f5f1708dd424cfffc%7C6095688410ad40fa863d4f32c1e3a37a%7C0%7C0%7C638739620725886157%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=gcUFpzhC9YvfjfjUMzWXnzQZhMeCdEBUI50aYEcfuqM%3D&reserved=0
Draft Policies and Proposals under discussion can be found at:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.arin.net%2Fparticipate%2Fpolicy%2Fdrafts%2F&data=05%7C02%7Cbjones%40vt.edu%7C35bbb01328e0419f5f1708dd424cfffc%7C6095688410ad40fa863d4f32c1e3a37a%7C0%7C0%7C638739620725902012%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=cHh%2F2QyZdMHp0C4xtYle%2BQuZ1EOq55R9ElQ7MZ0facQ%3D&reserved=0
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://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.arin.net%2Fmailman%2Flistinfo%2Farin-ppml&data=05%7C02%7Cbjones%40vt.edu%7C35bbb01328e0419f5f1708dd424cfffc%7C6095688410ad40fa863d4f32c1e3a37a%7C0%7C0%7C638739620725917764%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=NVhnb%2FOTSCXonYLKqtfZTCKuZ1E631ycp%2Fb%2F89GZtrU%3D&reserved=0
Please contact info at arin.net if you experience any issues.
------------------------------
Message: 2
Date: Fri, 31 Jan 2025 17:05:42 -0600
From: David Farmer <farmer at umn.edu>
To: "Jones, Brian" <bjones at vt.edu>
Cc: ARIN-PPML <arin-ppml at arin.net>
Subject: Re: [arin-ppml] Draft Policy ARIN-2024-11: IPv4 Transition
Efficiency Reallocation Policy (ITERP)
Message-ID:
<CAN-Dau09EC-HtrdZWxcAeksa6qhRtbfCyuTJH_mBQy2+HYud9A at 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 <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://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.arin.net%2Fparticipate%2Fpolicy%2Fdrafts%2F2024_11&data=05%7C02%7Cbjones%40vt.edu%7C35bbb01328e0419f5f1708dd424cfffc%7C6095688410ad40fa863d4f32c1e3a37a%7C0%7C0%7C638739620725931288%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=wep7Q2Vl7lUcX%2BU9mExzjoJCvbcVty6dYBn6oIz82uk%3D&reserved=0
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://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.arin.net%2Fparticipate%2Fpolicy%2Fpdp%2F&data=05%7C02%7Cbjones%40vt.edu%7C35bbb01328e0419f5f1708dd424cfffc%7C6095688410ad40fa863d4f32c1e3a37a%7C0%7C0%7C638739620725943295%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=%2F26bD29iD8%2F93Kif4lItMUjHaJ5votZzGWOuNYQX0zY%3D&reserved=0
Draft Policies and Proposals under discussion can be found at:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.arin.net%2Fparticipate%2Fpolicy%2Fdrafts%2F&data=05%7C02%7Cbjones%40vt.edu%7C35bbb01328e0419f5f1708dd424cfffc%7C6095688410ad40fa863d4f32c1e3a37a%7C0%7C0%7C638739620725958520%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=geyadg%2FcoLOg5zTK2%2BkXw%2BlYviwfdwnz3%2Fa8JVcwAYA%3D&reserved=0
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://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.arin.net%2Fmailman%2Flistinfo%2Farin-ppml&data=05%7C02%7Cbjones%40vt.edu%7C35bbb01328e0419f5f1708dd424cfffc%7C6095688410ad40fa863d4f32c1e3a37a%7C0%7C0%7C638739620725971222%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=cRG%2BCOzNqxSmmouqJE9pmYKOjSn7ystPg8%2FMtpNZJ0I%3D&reserved=0
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://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.arin.net%2Fpipermail%2Farin-ppml%2Fattachments%2F20250131%2F63619e2d%2Fattachment.htm&data=05%7C02%7Cbjones%40vt.edu%7C35bbb01328e0419f5f1708dd424cfffc%7C6095688410ad40fa863d4f32c1e3a37a%7C0%7C0%7C638739620725985838%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=p0oRB67sup5%2BAm96CoaZlPflZNIMDiL2yRqDVbgzHwg%3D&reserved=0>
------------------------------
Subject: Digest Footer
_______________________________________________
ARIN-PPML mailing list
ARIN-PPML at arin.net
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.arin.net%2Fmailman%2Flistinfo%2Farin-ppml&data=05%7C02%7Cbjones%40vt.edu%7C35bbb01328e0419f5f1708dd424cfffc%7C6095688410ad40fa863d4f32c1e3a37a%7C0%7C0%7C638739620726001728%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=jVupQJDc3heSl4BU%2F1AQMivYMoVr6QFNkFgkxePdoh4%3D&reserved=0
------------------------------
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 (ARIN-PPML at arin.net).
Unsubscribe or manage your mailing list subscription at:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.arin.net%2Fmailman%2Flistinfo%2Farin-ppml&data=05%7C02%7Cbjones%40vt.edu%7C35bbb01328e0419f5f1708dd424cfffc%7C6095688410ad40fa863d4f32c1e3a37a%7C0%7C0%7C638739620726018749%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=9muNw6N840GrT9H7fq4Me77jAyprVYNBxSL%2B%2FfrNSlY%3D&reserved=0
Please contact info at arin.net if you experience any issues.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20250203/036be5d8/attachment-0001.htm>
More information about the ARIN-PPML
mailing list