[arin-ppml] Draft Policy ARIN-2024-5: Rewrite of NRPM Section 4.4 Micro-Allocation

[Martin Hannigan]

On Wed, May 29, 2024 at 1:24 PM Dale W. Carder <dwcarder at es.net> wrote:

>
> I agree and think that is a better path forward.  Already in my career
> I have been on exchanges with (3) different L2 technologies (fddi,
> atm, and ethernet) and I'm not even that old!  We should not have to
> come back to update policy for each new layer 2 technology of the day.
>

Understood. It is a fact that currently, IXs are operating almost
exclusively on Ethernet within the ARIN region, if not globally.

The policy aims to achieve several goals. Firstly, it addresses the staff
policy experience report comments, clarifying that 4.4 prefixes are
optionally routable as part of a defined "system" to support valid CI. This
includes supporting systems bound by a commonly accepted core, which today
is almost exclusively an "Ethernet" switch*. Let's set that aside.
Secondly, it seeks to ensure that the dedicated pool is allocated as
expected and exclusively for valid CI needs as determined by the ARIN
staff. The idea that providing an Ethernet (or an L2 option) to a virtual
IX is "trivial," implying it would be eligible for 4.4 resources, is
misguided. However, as long as the final policy ensures that the staff have
the tools to evaluate and approve or deny using a policy that is clear and
understandable, that's great. Additionally, the policy has been tightened
to allow staff to review participating peers and their ASNs (implying BGP
without explicitly stating it), which should address another component of
non-CI needs.

If specifying L2 accomplishes the above goals, then it sounds acceptable
for the proposal going forward.

I also agree there are reasons in support of stewardship to be
prescriptive. I would simply argue this is also one of them, along with
(for example only) 4.2.2, 4.2.2.2, 4.2.4, 6.5.2, 8.3, 8.4  and 4.2.3.7.

HTH, and good inputs.

-M<

-

*Initial IPv4 Allocation Criteria (Section 4.2.2)*:

   - ARIN requires that an organization must demonstrate the efficient
   utilization of existing IP address space and a detailed 12-month plan for
   the use of at least 50% of the requested IPv4 address space.
   - Specific documentation requirements are listed to justify the request,
   including network engineering plans and customer demand.

-

*Multi-homed Requirement for IPv4 (Section 4.2.2.2)*:

   - Organizations requesting IPv4 address space must be multi-homed,
   meaning they must be connected to more than one ISP.
   - Documentation must include evidence of current or planned multi-homing
   within a 30-day window.

-

*Subsequent IPv4 Allocations (Section 4.2.4)*:

   - Organizations must show efficient utilization of at least 80% of their
   currently allocated space before receiving additional IPv4 addresses.
   - They must also submit a detailed plan for the use of the requested
   space within three months.

-

*IPv6 Initial Allocation Criteria (Section 6.5.2)*:

   - Organizations must provide detailed technical justification to receive
   an initial IPv6 allocation.
   - Requirements include showing an immediate need for IPv6 space and
   plans for at least 50 assignments to other organizations within five years.

-

*Transfer Policies (Section 8.3 and 8.4)*:

   - Policies for the transfer of IPv4 addresses between organizations are
   strictly defined.
   - For example, Section 8.3 requires that the recipient must demonstrate
   a justified need for the IP addresses under the same criteria as initial
   allocations, and Section 8.4 details the process and conditions for
   inter-RIR transfers.

-

*Reassignment and Reallocation Information (Section 4.2.3.7)*:

   - ISPs must provide reassignment and reallocation information via SWIP
   (Shared Whois Project) or an RWhois server to ensure the efficient and
   accurate maintenance of the ARIN database.
   - This includes providing detailed information about downstream
   customers and their utilization of the IP address space.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20240529/97cadfcc/attachment.htm>