<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, May 29, 2024 at 1:24 PM Dale W. Carder <<a href="mailto:dwcarder@es.net">dwcarder@es.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
I agree and think that is a better path forward.  Already in my career<br>
I have been on exchanges with (3) different L2 technologies (fddi,<br>
atm, and ethernet) and I'm not even that old!  We should not have to<br>
come back to update policy for each new layer 2 technology of the day.<br></blockquote></div><div class="gmail_quote"><br></div><p>Understood. It is a fact that currently, IXs are operating almost exclusively on Ethernet within the ARIN region, if not globally.</p><p>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.</p><p>If specifying L2 accomplishes the above goals, then it sounds acceptable for the proposal going forward.</p><p>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.<br></p><p>HTH, and good inputs.<br></p><p>-M<<br></p><div class="gmail_quote"><div><div class="gmail_quote"><br></div><div class="gmail_quote"><li><p><strong>Initial IPv4 Allocation Criteria (Section 4.2.2)</strong>:</p><ul><li>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.</li><li>Specific documentation requirements are listed to justify the request, including network engineering plans and customer demand.</li></ul></li><li><p><strong>Multi-homed Requirement for IPv4 (Section 4.2.2.2)</strong>:</p><ul><li>Organizations requesting IPv4 address space must be multi-homed, meaning they must be connected to more than one ISP.</li><li>Documentation must include evidence of current or planned multi-homing within a 30-day window.</li></ul></li><li><p><strong>Subsequent IPv4 Allocations (Section 4.2.4)</strong>:</p><ul><li>Organizations must show efficient utilization of at least 80% of their currently allocated space before receiving additional IPv4 addresses.</li><li>They must also submit a detailed plan for the use of the requested space within three months.</li></ul></li><li><p><strong>IPv6 Initial Allocation Criteria (Section 6.5.2)</strong>:</p><ul><li>Organizations must provide detailed technical justification to receive an initial IPv6 allocation.</li><li>Requirements include showing an immediate need for IPv6 space and plans for at least 50 assignments to other organizations within five years.</li></ul></li><li><p><strong>Transfer Policies (Section 8.3 and 8.4)</strong>:</p><ul><li>Policies for the transfer of IPv4 addresses between organizations are strictly defined.</li><li>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.</li></ul></li><li><p><strong>Reassignment and Reallocation Information (Section 4.2.3.7)</strong>:</p><ul><li>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.</li><li>This includes providing detailed information about downstream customers and their utilization of the IP address space.</li></ul></li></div><div class="gmail_quote"><div><br><br></div></div> </div></div></div>