[arin-ppml] Draft Policy ARIN-2023-2: /26 initial IPv4 allocation for IXPs
Ron Grant
ron+arin-ppml at balansoft.com
Tue Jun 20 13:36:32 EDT 2023
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 at 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 <info at 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 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.
>
> _______________________________________________
> 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.
>
>
> _______________________________________________
> 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 contactinfo at arin.net if you experience any issues.
--
Ron Grant
Balan Software/Networks
Network Architecture & Programming
604-737-2113
ca.linkedin.com/in/obiron
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20230620/3881382c/attachment.htm>
More information about the ARIN-PPML
mailing list