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

[Tyler O'Meara]

I would consider both the non-globally routed peering LAN, as well as a /24 for
globally routed administrative uses (IXManager, Looking Glass, even the IX's
website) to be valid uses for 4.4 space.

In my opinion, any use of IPs on the peering LAN, so long as it's used to peer
on the IX, is legitimate; whether it's an IX run CDN cache, a CDN run CDN cache,
a router to an end-user ISP, AS112, or anything else - if it's peering over the
IX, it's legitimate.

However, I would expect that all uses of the adminstrative allocation (that is
globally routable) to be strictly involved in the administration of the IX; if
anyone were using those IPs to serve non-IX specific traffic (such as filling
CDN requests), I would consider that against the spirit of the policy.

I do think there is a theoretical avenue of abuse here, but I think the
downsides of us being overly prescriptive in how critical Internet
infrastructure is run far outweighs the theoretical benefits of clamping down on
this abuse. Particularly since IXs must provide substantial justification
(including 3 networks intending to connect on the IX) in order to qualify, I
think this avenue of abuse is fairly difficult to accomplish, and provides
limited benefits.

I would support the addition of something along the lines of "All uses of these
IPv4 micro-allocations must be in support of maintaining critical internet
infrastructure.", which is implied, but not explicitly stated. This is similar
to a requirement already in existence for 4.10 allocations.

I would also recommend removing the entire paragraph "Exchange point allocations
MUST be allocated from specific blocks reserved only for this purpose. All other
micro-allocations WILL be allocated out of other blocks reserved for micro-
allocation purposes. ARIN will make a list of these blocks publicly available.",
in particular because it seems to be in conflict with 4.1.7.1.

Tyler O'Meara
AS53727

On Fri, 2024-04-19 at 12:22 +0000, Douglas Camin 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.