The policy properly differentiates between allocations for IXPs which do
NOT need global reachability and allocations which do - however it
places a too-onerous restriction on the initial allocation:
4.4.1 Micro-allocations for Internet Exchange Points (IXPs)
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.
I wonder how much automation software will break when you take away the
assumption that the first three quads of a dotted-quad will be unique
per-IXP? (I am not suggesting this is good practice, I am suggesting
that good practice is not a good assumption).
But more importantly, I wonder what the percentage of Existing,
Functional and wildly successful IXPs have actually reached 128
participants yet?
This policy would force EVERY successful IXP to have a renumbering event
on their horizon. And if you think that that won't matter because "we're
at peak IXP anyway" then the policy is pointless anyway.
On 2023-06-20 10:05 a.m., Matthew Wilder via ARIN-PPML wrote:
Hi Owen,
It sounds as though your opposition to this draft policy includes a
concern that it is not technically sound.
In what ways do you believe that this change would break the Internet
or contort it?
Thanks,
Matthew
On Tue, Jun 20, 2023 at 9:45 AM Owen DeLong via ARIN-PPML
<arin-ppml@arin.net> wrote:
We’re 12 years past IANA runout and only 50% of this reservation
has been depleted.
Seems to me that things are working as intended.
There is no plan or expectation that n IPv4 free pool will last
indefinitely into the future, nor should we be making attempts to
do so on any level.
I oppose this proposal and suggest that those that think that
parceling out IPv4 in ever smaller chunks and breaking more and
more of the internet contorting it to adapt to the whims of those
who have failed to implement IPv6 should find a way to encourage
those failing to deploy IPv6 to get off the dime already.
Owen
> On Jun 20, 2023, at 08:54, ARIN <i...@arin.net> wrote:
>
> On 15 June 2023, the ARIN Advisory Council (AC) accepted
“ARIN-prop-320: /26 initial IPv4 allocation for IXPs” as a Draft
Policy.
>
> Draft Policy ARIN-2023-2 is below and can be found at:
>
> https://www.arin.net/participate/policy/drafts/2023_2
>
> 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://www.arin.net/participate/policy/pdp/
>
> Draft Policies and Proposals under discussion can be found at:
https://www.arin.net/participate/policy/drafts/
>
> Regards,
>
> Eddie Diego
> Policy Analyst
> American Registry for Internet Numbers (ARIN)
>
>
> Draft Policy ARIN-2023-2: /26 initial IPv4 allocation for IXPs
>
> Problem Statement:
>
> 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.
>
> 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: https://github.com/mwichtlh/address-policy-wg )
>
> 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.
>
> Policy statement:
>
> Existing text:
>
> 4.4. Micro-allocation
>
> 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.
>
> Replace with:
>
> 4.4 Micro-allocation
>
> 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.
>
> 4.4.1 Micro-allocations for Internet Exchange Points (IXPs)
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> Comments:
>
> This proposal mirrors RIPE policy proposal 2023-01 (see
https://www.ripe.net/participate/policies/proposals/2023-01) which
is currently under consideration in that region and appears to
have sufficient community support for adoption at the time of this
writing.
>
> Timetable for implementation: Immediate
>
>
> _______________________________________________
> ARIN-PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
> Unsubscribe or manage your mailing list subscription at:
> https://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact i...@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@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@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@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contacti...@arin.net if you experience any issues.
--
Ron Grant
Balan Software/Networks
Network Architecture & Programming
604-737-2113
ca.linkedin.com/in/obiron
_______________________________________________
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.
