<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Consolas;
panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
pre
{mso-style-priority:99;
mso-style-link:"HTML Preformatted Char";
margin:0in;
font-size:10.0pt;
font-family:"Courier New";}
span.HTMLPreformattedChar
{mso-style-name:"HTML Preformatted Char";
mso-style-priority:99;
mso-style-link:"HTML Preformatted";
font-family:Consolas;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;
mso-ligatures:none;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style>
</head>
<body lang="EN-US" link="blue" vlink="purple" style="word-wrap:break-word">
<div class="WordSection1">
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">BTW, fundamentally they are “right”. What is missing is the usefulness of a routable prefix in using it to a) service multiple IXPs in a region and b) provide network services to them using it. Consider a region where you could have five
or six nonprofits cooperating via a 501(c)6. The 501 is the ORG facing ARIN and the IXPs are members and beneficiaries of a shared prefix. An assigned /24 is broken up into /26’s and they tie back into “home” and share resources such as VM’s, RS, and other
costly items. This approach provides a ~75% reduction in overall paid fees and another reduction in IXP opex. I guess one could simply not ask for a 4.4 micro allocation, it’s not required to do so, and avoid the technical limitations and regain the cost savings.
That seems to make this not worth doing to be honest. Seems like a lot of work for little benefit and a charting unknown territory filter wise to force some out of 4.4 to avoid the technical limitation. I added a second analogous slide to provide a visual
of plans (work in progress and only a fraction of work).<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Perhaps a compromise is the option of an IXP selecting an initial /26? I suspect if that existed you’d see legitimate uptake of it while still maintaining the flexibility to allow competition with a less limited prefix. And of course there’s
a corresponding fee decrease that would drive that behavior. Right? <span style="font-family:"Apple Color Emoji"">
😊</span> <o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Hope that helps.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Warm regards,<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">-M<<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div id="mail-editor-reference-message-container">
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal" style="margin-bottom:12.0pt"><b><span style="font-size:12.0pt;color:black">From:
</span></b><span style="font-size:12.0pt;color:black">ARIN-PPML <arin-ppml-bounces@arin.net> on behalf of Andrew Dul <andrew.dul@quark.net><br>
<b>Date: </b>Tuesday, June 20, 2023 at 2:04 PM<br>
<b>To: </b>Chris Woodfield <chris@semihuman.com><br>
<b>Cc: </b>arin-ppml@arin.net <arin-ppml@arin.net><br>
<b>Subject: </b>Re: [arin-ppml] Draft Policy ARIN-2023-2: /26 initial IPv4 allocation for IXPs<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal">Indeed, we therefore have to define priorities of allocations for the depleted IPv4 pool.</p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">I wanted to point out that if the community believed that sticking with the /24 allocations is best for IXPs then it appears we have sufficient resources to do so into the future. At the present time the policy states that IXP (4.4) allocations
have a higher priority than a generic wait-list request. The community created this priority believing that IXPs are critical infrastructure that require these resources.</p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Andrew</p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">On 6/20/2023 10:53 AM, Chris Woodfield wrote:</p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal">Andrew - You are correct that the micro-allocation pool can be replenished as needed from returned allocations. That said, it should be noted that IPv4 allocations used for this purpose would be resources that, under current policy, would
have presumably been allocated to organizations via the wait list otherwise. </p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Thanks,</p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">- Chris</p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal"><br>
<br>
</p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal">On Jun 20, 2023, at 10:42, Andrew Dul <a href="mailto:andrew.dul@quark.net">
<andrew.dul@quark.net></a> wrote:</p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<div>
<p class="MsoNormal">I'd also like to point out that we already have a method for refilling the IXP pool as needed. The current policy states that ARIN should maintain at least a 3 year supply for these reserved pools and so far it would also seem that the
returns to ARIN appear to be sufficient to add to the reserved pools as necessary.</p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<p class="MsoNormal"><a href="https://www.arin.net/participate/policy/nrpm/#4-1-7-2-precedence-for-replenishment">https://www.arin.net/participate/policy/nrpm/#4-1-7-2-precedence-for-replenishment</a>
</p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Andrew</p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">On 6/20/2023 10:10 AM, Chris Woodfield wrote:</p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<pre>Speaking as the proposal author: It appears that a URL included in the draft language has been inadvertently eaten by formatting. The Statistics & Reporting link is here: <a href="https://www.arin.net/reference/research/statistics/#ipv4-reserved-pool-status-nrpm-4-10-ipv6-deployments">https://www.arin.net/reference/research/statistics/#ipv4-reserved-pool-status-nrpm-4-10-ipv6-deployments</a></pre>
<pre><o:p> </o:p></pre>
<pre>I’ll also note that this page appears to have been updated since the policy was originally submitted - it now appears that the NPRM 4.4 Micro-Allocation pool is 65% allocated, with 35% remaining. (There’s a good chance I was rounding down when I said 50% in the problem statement)</pre>
<pre><o:p> </o:p></pre>
<pre>Thanks,</pre>
<pre><o:p> </o:p></pre>
<pre>-Chris</pre>
<pre><o:p> </o:p></pre>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<pre>On Jun 20, 2023, at 08:54, ARIN <a href="mailto:info@arin.net"><info@arin.net></a> wrote:</pre>
<pre><o:p> </o:p></pre>
<pre>On 15 June 2023, the ARIN Advisory Council (AC) accepted “ARIN-prop-320: /26 initial IPv4 allocation for IXPs” as a Draft Policy.</pre>
<pre> </pre>
<pre>Draft Policy ARIN-2023-2 is below and can be found at:</pre>
<pre> </pre>
<pre><a href="https://www.arin.net/participate/policy/drafts/2023_2">https://www.arin.net/participate/policy/drafts/2023_2</a></pre>
<pre> </pre>
<pre>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:</pre>
<pre> </pre>
<pre>* Enabling Fair and Impartial Number Resource Administration</pre>
<pre>* Technically Sound</pre>
<pre>* Supported by the Community</pre>
<pre> </pre>
<pre>The PDP can be found at:</pre>
<pre> </pre>
<pre><a href="https://www.arin.net/participate/policy/pdp/">https://www.arin.net/participate/policy/pdp/</a></pre>
<pre> </pre>
<pre>Draft Policies and Proposals under discussion can be found at: <a href="https://www.arin.net/participate/policy/drafts/">https://www.arin.net/participate/policy/drafts/</a></pre>
<pre> </pre>
<pre>Regards,</pre>
<pre> </pre>
<pre>Eddie Diego</pre>
<pre>Policy Analyst</pre>
<pre>American Registry for Internet Numbers (ARIN)</pre>
<pre><o:p> </o:p></pre>
<pre><o:p> </o:p></pre>
<pre>Draft Policy ARIN-2023-2: /26 initial IPv4 allocation for IXPs</pre>
<pre><o:p> </o:p></pre>
<pre>Problem Statement: </pre>
<pre><o:p> </o:p></pre>
<pre>Per NRPM Section 4.4, ARIN has reserved a /15 for micro-allocations for critical internet infrastructure, such as internet exchange points (IXPs) and core DNS service providers. The majority of these allocation requests are made by IXPs. As of the last ARIN report, roughly half of this reservation is allocated (see Statistics & Reporting Projections from ARIN staff suggest that at current allocation rates, the remaining reserved space may be exhausted in the next few years.</pre>
<pre><o:p> </o:p></pre>
<pre>In parallel, an analysis of PeeringDB data conducted by the RIPE Address Policy Working Group shows that approximately 70% of global IXPs have fewer than 32 members registered with that site. An IXP this size could readily operate with a /26 allocation, which would provide 100% overprovisioning beyond their existing peer count. (Source: <a href="https://github.com/mwichtlh/address-policy-wg">https://github.com/mwichtlh/address-policy-wg</a> )</pre>
<pre><o:p> </o:p></pre>
<pre>Unlike other types of allocations, IXP peering networks are not required by member networks to be globally reachable; only members of the IXP must be able to reach the prefix. As such, there is no technical requirement that an IXP allocation must be no smaller than a /24.</pre>
<pre><o:p> </o:p></pre>
<pre>Policy statement:</pre>
<pre><o:p> </o:p></pre>
<pre>Existing text:</pre>
<pre><o:p> </o:p></pre>
<pre>4.4. Micro-allocation</pre>
<pre><o:p> </o:p></pre>
<pre>ARIN will make IPv4 micro-allocations to critical infrastructure providers of the Internet, including public exchange points, core DNS service providers (e.g. ICANN-sanctioned root and ccTLD operators) as well as the RIRs and IANA. These allocations will be no smaller than a /24. Multiple allocations may be granted in certain situations.</pre>
<pre><o:p> </o:p></pre>
<pre>Replace with:</pre>
<pre><o:p> </o:p></pre>
<pre>4.4 Micro-allocation</pre>
<pre><o:p> </o:p></pre>
<pre>ARIN will make IPv4 micro-allocations to critical infrastructure providers of the Internet, including public internet exchange points (IXPs), core DNS service providers (e.g. ICANN-sanctioned root and ccTLD operators) as well as the RIRs and IANA. These allocations will be no smaller than a /26 for IXPs, or a /24 for other allocations that require global reachability of the assigned allocation. Multiple allocations may be granted in certain situations.</pre>
<pre><o:p> </o:p></pre>
<pre>4.4.1 Micro-allocations for Internet Exchange Points (IXPs)</pre>
<pre><o:p> </o:p></pre>
<pre>An IXP requesting an initial IPv4 allocation from this reserved space will be assigned a /26 by default. An IXP requesting an allocation larger than a /26 must show an immediate need to utilize more than 25% of the requested allocation size upon initial commissioning.</pre>
<pre><o:p> </o:p></pre>
<pre>An IXP requesting an allocation under this section must have also requested, or already received, an IPv6 allocation for the same purpose under Section 6.10.1.</pre>
<pre><o:p> </o:p></pre>
<pre>An allocation made to an IXP under this section may only be used for the operation of its public peering LAN. No other uses are allowed.</pre>
<pre><o:p> </o:p></pre>
<pre>An IXP that has received an IPv4 allocation under this section may request a larger allocation once they have utilized more than 50% of their existing one. Upon receiving the larger allocation, the IXP must migrate to the new allocation and return their previous one to ARIN within 6 months.</pre>
<pre><o:p> </o:p></pre>
<pre>Comments:</pre>
<pre><o:p> </o:p></pre>
<pre>This proposal mirrors RIPE policy proposal 2023-01 (see <a href="https://www.ripe.net/participate/policies/proposals/2023-01">https://www.ripe.net/participate/policies/proposals/2023-01</a>) which is currently under consideration in that region and appears to have sufficient community support for adoption at the time of this writing.</pre>
<pre><o:p> </o:p></pre>
<pre>Timetable for implementation: Immediate</pre>
<pre><o:p> </o:p></pre>
<pre><o:p> </o:p></pre>
<pre>_______________________________________________</pre>
<pre>ARIN-PPML</pre>
<pre>You are receiving this message because you are subscribed to</pre>
<pre>the ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net">ARIN-PPML@arin.net</a>).</pre>
<pre>Unsubscribe or manage your mailing list subscription at:</pre>
<pre><a href="https://lists.arin.net/mailman/listinfo/arin-ppml">https://lists.arin.net/mailman/listinfo/arin-ppml</a></pre>
<pre>Please contact <a href="mailto:info@arin.net">info@arin.net</a> if you experience any issues.</pre>
</blockquote>
<pre>_______________________________________________</pre>
<pre>ARIN-PPML</pre>
<pre>You are receiving this message because you are subscribed to</pre>
<pre>the ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net">ARIN-PPML@arin.net</a>).</pre>
<pre>Unsubscribe or manage your mailing list subscription at:</pre>
<pre><a href="https://lists.arin.net/mailman/listinfo/arin-ppml">https://lists.arin.net/mailman/listinfo/arin-ppml</a></pre>
<pre>Please contact <a href="mailto:info@arin.net">info@arin.net</a> if you experience any issues.</pre>
</blockquote>
<p><o:p> </o:p></p>
</div>
<p class="MsoNormal">_______________________________________________<br>
ARIN-PPML<br>
You are receiving this message because you are subscribed to<br>
the ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net">ARIN-PPML@arin.net</a>).<br>
Unsubscribe or manage your mailing list subscription at:<br>
<a href="https://lists.arin.net/mailman/listinfo/arin-ppml">https://lists.arin.net/mailman/listinfo/arin-ppml</a><br>
Please contact <a href="mailto:info@arin.net">info@arin.net</a> if you experience any issues.</p>
</div>
</blockquote>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</blockquote>
<p><o:p> </o:p></p>
</div>
</div>
</div>
</body>
</html>