[arin-ppml] Feedback on ARIN 53 question on micro-allocations for IXPs

Ryan Woolley rwoolley at communityix.org
Fri Apr 19 10:45:12 EDT 2024


Doug,

The current FL-IX space was requested in September 2014 (prior to
run-out.)  The peering LAN /24 appears on the "Micro-allocations for
Internet Exchange Points" list at
https://www.arin.net/reference/research/statistics/microallocations/  The
infrastructure /24 does not.  Both the CIX-ATL /24s are IXP allocations.  A
newly assigned /23 which we'll use to renumber FL-IX is within the /16
mentioned on the page but itself does not yet appear.

The FL-IX /24 is >75% utilized.  Prior to the assignment of the /23, we
were challenged about the routing of the existing /24s.  As you can see
from the other responses, our long-standing use is consistent with the need
and there is no reasonable alternative.  Fortunately, we were able to
obtain the /23, but under a different interpretation, a 158-member
non-profit IXP wouldn't be able to expand with ARIN space, which I don't
think would have been an outcome consistent with the intent of the critical
infrastructure policy.

As mentioned by Bill, other IXPs in the ARIN region will also face a
renumbering need soon, so the question about appropriate use of existing
assignments is timely.

Regards,
Ryan Woolley
Community IX

On Fri, Apr 19, 2024 at 8:23 AM Douglas Camin <doug at dougcamin.com> wrote:

> Ryan –
>
>
>
> Thanks so much for surfacing this discussion on PPML.
>
>
>
> Reading through the responses from everyone, I think it’s clear there are
> use cases for IXPs to reasonably need a block of routable space for
> administrative purposes, particularly independent ones where there is no
> guaranteed sponsor pool to pull from. Ryan – did your IXP use a 4.4
> allocation for the administrative prefix, or pull that from elsewhere?
>
>
>
> I think a follow up question, from a policy perspective, would be: The
> policy (4.4) as written defines several critical infrastructure categories,
> but does not create a boundary for what services can run on those
> allocations. Does this create an avenue for abuse of this pool?
>
>
>
> I think the example already shared of using this as a fast way to get v4
> space to use as a CDN node seems like a good one – there may be a use case
> for it to exist on the member network, but using that IP for access for the
> Internet at large would appear (to me) to be in violation of the spirit of
> the policy and the reason for the allocation.
>
>
>
> In the current setup, ARIN staff is almost certainly having to make
> interpretations and judgement calls, which leads to the additional question
> – does the community want more than that?
>
>
>
> Thank you –
>
>
>
>
>
> Doug
>
>
>
>
>
> --
>
> Douglas J. Camin
>
> ARIN Advisory Council
>
> doug at dougcamin.com
>
>
>
> *From: *ARIN-PPML <arin-ppml-bounces at arin.net> on behalf of Ryan Woolley <
> rwoolley at communityix.org>
> *Date: *Thursday, April 18, 2024 at 6:44 PM
> *To: *arin-ppml at arin.net <arin-ppml at arin.net>
> *Subject: *[arin-ppml] Feedback on ARIN 53 question on micro-allocations
> for IXPs
>
> At ARIN 53, John Sweeting asked for clarification from the community on
> whether an internet exchange needs IP space beyond that used for the
> switching fabric, and whether IP allocations made to an IXP operator may
> need to be routable.  Additionally, John shared a suggestion that the
> historical basis for maintaining a pool specific to IXPs was to enable the
> building of filters to prevent those addresses from being globally routable.
>
> Community IX operates two IXPs, FL-IX in south Florida and CIX-ATL in
> Atlanta.  FL-IX was founded in 2015 and now connects 158 member networks.
> CIX-ATL began operations in 2019 and currently connects 66 member networks.
>
> Both IXPs have been assigned IP address space from ARIN.  Each IXP uses
> one prefix for the member LAN, which is not announced outside of our
> members’ networks, and a second, routed, prefix for the IXP infrastructure.
>
> The routed prefix supports operations critical to the operation of the
> exchange.  Our member portal, network management systems, and equipment
> loopback addresses are, by need and design, addressed in routable IP
> space.  For example, route servers build filters based on ROAs and IRR
> databases, and configurations are replicated off-site.
>
> Unlike an IXP affiliated with an ISP or data center operator, we have no
> line of business which would enable us to borrow IP space from, for
> example, a pool maintained for allocation to IP transit customers.  Our
> transit is provided as a donation by members, who may come or go as their
> connectivity needs require, so we cannot reasonably use
> non-provider-independent IP space.
>
> On the second question of whether space reserved for IXP allocations
> should be unroutable as a feature, we have not, in our years of operation,
> encountered any issues with reachability for these allocations.  If
> networks are building filters for this purpose, our experience suggests
> that is not a common practice.
>
> IXPs do commonly have a desire to prevent their member LAN prefix from
> being routable.  The current best practice is that this prefix is signed in
> RPKI with an origin ASN of zero (as described in RFC 6483), and Community
> IX does this for both our IXPs’ member LANs.  To the extent that filtering
> based on IP addressing may have been contemplated in the past, is it now
> obsoleted by RPKI.
>
> Regards,
>
> Ryan Woolley
> Community IX
> _______________________________________________
> 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20240419/dae85cbb/attachment.htm>


More information about the ARIN-PPML mailing list