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

[Douglas Camin]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20240419/1e5298eb/attachment.htm>