From bjones at vt.edu  Fri Nov  8 15:26:05 2024
From: bjones at vt.edu (Jones, Brian)
Date: Fri, 8 Nov 2024 20:26:05 +0000
Subject: [arin-ppml] Draft Policy ARIN-2024-11: IPv4 Transition
 Efficiency Reallocation Policy (ITERP)
In-Reply-To: <1dc996fd6b4344edc735c480159cccb447a565b8.camel@tyleromeara.com>
References: <1CED16E0-BC3A-4AFC-8169-B1EDBA18EEB0@arin.net>
 <1dc996fd6b4344edc735c480159cccb447a565b8.camel@tyleromeara.com>
Message-ID: <2B9C3531-DB3A-4265-B659-8A6ED8A3B742@vt.edu>

Thank you for the feedback Tyler.


In my discussions with the author of this proposal my summation is as follows; the problem boils down to the inability for an ISP to reallocate 4.10 IP space that they have acquired from ARIN for their small downstream customers who don?t require an entire /24 for converting to IPv6. The author is proposing that 4.10 space could be conserved by allowing an ISP to reallocate a /29 or /28 of their acquired /24 4.10 space to their customers for IPv6 transition versus having their customer acquire an entire /24 themselves when they only need a handful of IPv4 addresses for say DNS/DHCP and or  some sort of NAT?ing purposes for their IPv6 transition. The thinking is that one /24 of 4.10 space could serve multiple downstream customers instead of each one requesting  their own /24 for IPv6 transition purposes.

You are correct that the current 4.10 policy does not allow for reallocations. The two added bullets restated here:

* 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.


^^ These are the proposed 4.10 changes (additions) that this Draft policy puts forward to allow for these type reallocations should the community so choose to support it.


Co-shepherd of this Draft policy.
_
Brian Jones
ARIN Advisory Council





On Oct 30, 2024, at 13:12, Tyler O'Meara via ARIN-PPML <arin-ppml at arin.net> wrote:

The Policy Statement does not match the Problem Statement or the comments. ARIN
staff's current reading of NRPM 4.10 (for NAT at least) is that 4.10 space must
"be utilized to EXCLUSIVELY provide IPv6 ONLY clients/equipment access to IPv4
networks (IPv6 Transition)". Very few ISPs actually only give IPv6 addresses to
their end users (mobile networks using 464XLAT are the only ones I'm familiar
with).

Also dual stack environments are mentioned repeatedly as well. As per NRPM 4.10,
only infrastructure critical to using IPv6 can be dual stacked with 4.10 space.

Therefore I think this policy will not have the effects its author intends.



Personally, I think 4.10 is probably too restrictive and would support allowing
a single /24 of 4.10 space to be used for NAT44/dual stack/whatever to a LIR
that has 100% IPv6 deployment, but that is not what the policy currently
permits.

As an aside, although IPv4 addresses generally are scarce, 4.10 addresses are
not (although I agree we shouldn't waste them).

Tyler O'Meara

On Wed, 2024-10-30 at 12:49 -0400, ARIN wrote:
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%7C6f8216a9b9374f6de6a108dcf905fc37%7C6095688410ad40fa863d4f32c1e3a37a%7C0%7C0%7C638659051364268381%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=aeOVkpQEnE7AIitNAi6bWhujbCKIOEpvvpa6J4ljMuQ%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%7C6f8216a9b9374f6de6a108dcf905fc37%7C6095688410ad40fa863d4f32c1e3a37a%7C0%7C0%7C638659051364293433%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=Kw0O7kKgdX9XatPkEeDiSVWJzNBfiKzmlu7fRyg61wQ%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%7C6f8216a9b9374f6de6a108dcf905fc37%7C6095688410ad40fa863d4f32c1e3a37a%7C0%7C0%7C638659051364308903%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=ZidRIZBgPZzf67Qiw6gtQOwg86cXWqprrsD0kasqzF0%3D&reserved=0

Regards,

Eddie Diego
Policy Analyst
American Registry for Internet Numbers (ARIN)



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

_______________________________________________
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%7C6f8216a9b9374f6de6a108dcf905fc37%7C6095688410ad40fa863d4f32c1e3a37a%7C0%7C0%7C638659051364323892%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=3wlMBBn2%2F5wFppPJM8dZifpn9SWnD4btPw9UmnFDIKY%3D&reserved=0
Please contact info at arin.net if you experience any issues.

_______________________________________________
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%7C6f8216a9b9374f6de6a108dcf905fc37%7C6095688410ad40fa863d4f32c1e3a37a%7C0%7C0%7C638659051364339154%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=D%2BR1VqtLFzMYHTDDnWqUNUhxzL13EtsEToKXJ9fE2cQ%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/20241108/4c057f84/attachment-0001.htm>

From bill at herrin.us  Fri Nov  8 16:59:22 2024
From: bill at herrin.us (William Herrin)
Date: Fri, 8 Nov 2024 13:59:22 -0800
Subject: [arin-ppml] Draft Policy ARIN-2024-11: IPv4 Transition
 Efficiency Reallocation Policy (ITERP)
In-Reply-To: <1CED16E0-BC3A-4AFC-8169-B1EDBA18EEB0@arin.net>
References: <1CED16E0-BC3A-4AFC-8169-B1EDBA18EEB0@arin.net>
Message-ID: <CAP-guGVuB2ypvLMua2Hfu0bvava3M1ES9+FPK80D69e4+L4PTQ@mail.gmail.com>

On Wed, Oct 30, 2024 at 9:49?AM ARIN <info at arin.net> wrote:
> 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.

Howdy,

Why wouldn't the customer just do IPv4 with the ISP on RFC 6598
addresses and let the ISP implement the CGNAT? Seems like a LOT of
effort for tiny CGNAT implementations.

Regards,
Bill Herrin


-- 
William Herrin
bill at herrin.us
https://bill.herrin.us/

From john at egh.com  Fri Nov  8 17:30:17 2024
From: john at egh.com (John Santos)
Date: Fri, 8 Nov 2024 17:30:17 -0500
Subject: [arin-ppml] Draft Policy ARIN-2024-11: IPv4 Transition
 Efficiency Reallocation Policy (ITERP)
In-Reply-To: <2B9C3531-DB3A-4265-B659-8A6ED8A3B742@vt.edu>
References: <1CED16E0-BC3A-4AFC-8169-B1EDBA18EEB0@arin.net>
 <1dc996fd6b4344edc735c480159cccb447a565b8.camel@tyleromeara.com>
 <2B9C3531-DB3A-4265-B659-8A6ED8A3B742@vt.edu>
Message-ID: <914380c0-3edc-4e24-bc69-9774476e1bdd@egh.com>

If routing table space and routing tiny subnets are issues, the published route 
for the entire /24 should point to the ISP, and the ISP can then route subnets 
to each of its customers that require 4.10 space.  Routing one /24 would have 
much less impact than routing dozens of them, and the ISP must have direct 
connections to each of its customers if it is really an ISP.

Given those provisions, this proposal makes perfect sense to me.


On 11/8/2024 3:26 PM, Jones, Brian wrote:
> Thank you for the feedback Tyler.
> 
> 
> In my discussions with the author of this proposal my summation is as follows; 
> the problem boils down to the inability for an ISP to reallocate 4.10 IP space 
> that they have acquired from ARIN for their small downstream customers who don?t 
> require an entire /24 for converting to IPv6. The author is proposing that 4.10 
> space could be conserved by allowing an ISP to reallocate a /29 or /28 of their 
> acquired /24 4.10 space to their customers for IPv6 transition versus having 
> their customer acquire an entire /24 themselves when they only need a handful of 
> IPv4 addresses for say DNS/DHCP and or ?some sort of NAT?ing purposes for their 
> IPv6 transition. The thinking is that one /24 of 4.10 space could serve multiple 
> downstream customers instead of each one requesting ?their own /24 for IPv6 
> transition purposes.
> 
> You are correct that the current 4.10 policy does not allow for reallocations. 
> The two added bullets restated here:
> 
>>> * 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.
> 
> 
> ^^ These are the proposed 4.10 changes (additions) that this Draft policy puts 
> forward to allow for these type reallocations should the community so choose to 
> support it.
> 
> 
> Co-shepherd of this Draft policy.
> _
> Brian Jones
> ARIN Advisory Council
> 
> 
> 
> 
> 
>> On Oct 30, 2024, at 13:12, Tyler O'Meara via ARIN-PPML <arin-ppml at arin.net> wrote:
>>
>> The Policy Statement does not match the Problem Statement or the comments. ARIN
>> staff's current reading of NRPM 4.10 (for NAT at least) is that 4.10 space must
>> "be utilized to EXCLUSIVELY provide IPv6 ONLY clients/equipment access to IPv4
>> networks (IPv6 Transition)". Very few ISPs actually only give IPv6 addresses to
>> their end users (mobile networks using 464XLAT are the only ones I'm familiar
>> with).
>>
>> Also dual stack environments are mentioned repeatedly as well. As per NRPM 4.10,
>> only infrastructure critical to using IPv6 can be dual stacked with 4.10 space.
>>
>> Therefore I think this policy will not have the effects its author intends.
>>
>>
>>
>> Personally, I think 4.10 is probably too restrictive and would support allowing
>> a single /24 of 4.10 space to be used for NAT44/dual stack/whatever to a LIR
>> that has 100% IPv6 deployment, but that is not what the policy currently
>> permits.
>>
>> As an aside, although IPv4 addresses generally are scarce, 4.10 addresses are
>> not (although I agree we shouldn't waste them).
>>
>> Tyler O'Meara
>>
>> On Wed, 2024-10-30 at 12:49 -0400, ARIN wrote:
>>> 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%7C6f8216a9b9374f6de6a108dcf905fc37%7C6095688410ad40fa863d4f32c1e3a37a%7C0%7C0%7C638659051364268381%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=aeOVkpQEnE7AIitNAi6bWhujbCKIOEpvvpa6J4ljMuQ%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%7C6f8216a9b9374f6de6a108dcf905fc37%7C6095688410ad40fa863d4f32c1e3a37a%7C0%7C0%7C638659051364293433%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=Kw0O7kKgdX9XatPkEeDiSVWJzNBfiKzmlu7fRyg61wQ%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%7C6f8216a9b9374f6de6a108dcf905fc37%7C6095688410ad40fa863d4f32c1e3a37a%7C0%7C0%7C638659051364308903%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=ZidRIZBgPZzf67Qiw6gtQOwg86cXWqprrsD0kasqzF0%3D&reserved=0
>>>
>>> Regards,
>>>
>>> Eddie Diego
>>> Policy Analyst
>>> American Registry for Internet Numbers (ARIN)
>>>
>>>
>>>
>>> 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
>>>
>>> _______________________________________________
>>> 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%7C6f8216a9b9374f6de6a108dcf905fc37%7C6095688410ad40fa863d4f32c1e3a37a%7C0%7C0%7C638659051364323892%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=3wlMBBn2%2F5wFppPJM8dZifpn9SWnD4btPw9UmnFDIKY%3D&reserved=0
>>> Please contact info at arin.net?if you experience any issues.
>>
>> _______________________________________________
>> 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%7C6f8216a9b9374f6de6a108dcf905fc37%7C6095688410ad40fa863d4f32c1e3a37a%7C0%7C0%7C638659051364339154%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=D%2BR1VqtLFzMYHTDDnWqUNUhxzL13EtsEToKXJ9fE2cQ%3D&reserved=0
>> Please contact info at arin.net if you experience any issues.
> 
> 
> _______________________________________________
> 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.

-- 
John Santos
Evans Griffiths & Hart, Inc.
781-861-0670 ext 539


From bill at herrin.us  Fri Nov  8 17:42:38 2024
From: bill at herrin.us (William Herrin)
Date: Fri, 8 Nov 2024 14:42:38 -0800
Subject: [arin-ppml] Draft Policy ARIN-2024-11: IPv4 Transition
 Efficiency Reallocation Policy (ITERP)
In-Reply-To: <1CED16E0-BC3A-4AFC-8169-B1EDBA18EEB0@arin.net>
References: <1CED16E0-BC3A-4AFC-8169-B1EDBA18EEB0@arin.net>
Message-ID: <CAP-guGW9eyWf-LLBLCYM3HEqud1WqpKoj=fh+eC5m0k9m0srgg@mail.gmail.com>

On Wed, Oct 30, 2024 at 9:49?AM ARIN <info at arin.net> wrote:
> 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.

For the sake of the discussion, I would remind everybody that an IPv4
web reverse proxy facilitating access to an IPv6 web server is a
permitted use of 4.10 address space. So is an ordinary NAT server.
Under the suggested policy, a customer who proposed to run an ordinary
NAT server and a reverse proxy for their single web server would
qualify for a /29 reassignment from an ISP's 4.10 space.

Regards,
Bill Herrin


-- 
William Herrin
bill at herrin.us
https://bill.herrin.us/