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

[Bill Woodcock]

> On Apr 19, 2024, at 00:44, Ryan Woolley <rwoolley at communityix.org> wrote:
> 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.

Speaking for PCH, we agree with the specifics of Ryan’s response.

A few additional notes, not to belabor the obvious, but in case there are folks interested in the issue, but without a background in IX operation:

> 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.

Indeed.  The primary purpose of this is to reduce the impact of a variety of cyber-attacks which rely upon being able to speak to the IX-facing side of peering routers or simply DDoS the peering switch fabric.

The best-practice at this point is for IX switch fabric subnets to not be BGP originated.  That generally leaves each IXP switch fabric reachable via IGP from the networks which peer there, and thus reachable via default routes, where they exist, downward throughout the transit cone of each of those peers.  This is beneficial because it allows traceroute to function.

Non-unique address blocks (RFC1918 etc.) are not practical for use at IXPs because they do not support unique in-addr/ip6.arpa PTR records (again, for traceroute), and because this has played havoc with the internal routing of networks which peer at multiple IXPs which try to use the same non-unique space.  These reasons would be true even if non-unique space were allocated for the exclusive use of IXPs as a class, and is doubly true for RFC1918, which is already prolifically handled specially in filters.

As Ryan also says, IXPs _also_ need a separate, globally routable, address block for the provision of services: their web site, email list server, nameserver, management, et cetera.  If blocks smaller than /24 were ever to become globally routable in the future, most IXPs could accommodate these needs with a /27 or /28, but that’s immaterial at this point.

> To the extent that filtering based on IP addressing may have been contemplated in the past, is it now obsoleted by RPKI.

I guess my one caveat is that I’m not sure I’d go so far as to say that.

> On Apr 19, 2024, at 02:34, Matt Peterson <matt at peterson.org> wrote:
> ...offering an allocation scheme that allows for an IXP to expand easily from a /24 to /23. Renumbering events span years for IXP's and this is a very painful process.

For what it’s worth, here’s how things currently stand:

https://imgur.com/a/U2viMX4

https://www.pch.net/ixp/dir#!mt-sort=prts%2Cdesc!mt-pivot=prts

PTT Sao Paulo is using 67% of 187.16.208.0/20, so they’ve got a bit of headroom.  OpenIXP Jakarta is in a jam, with 1846 networks trying to peer across two /24s and a /22, which together would make 90% of a /21, so they urgently need a /20 to renumber into, but they’re going to have to coordinate nearly two thousand participant networks to make it happen.  DE-CIX Frankfurt is using 57% of 80.81.192.0/21, so they have plenty of headroom.

There are seven IXPs using /22s, with an average utilization of 61% and two of them over 75%.  There are twenty-six using /23s, with an average utilization of 66%, but seven of them over 75%.  Everybody else fits into a /24, for now, but eighteen of them are over 75% utilized.

So, yeah, renumbering becomes an ever-harder problem the larger an IXP grows, and although there are some IXPs for which growing beyond a /24 may seem like a distant prospect, I think all of the currently-really-big ones thought themselves to be in that category when they applied for address space.  The unadvertised also-ran IXP in Jakarta probably wasn’t on a lot of people’s lists of “going to need more than 2,048 IP addresses on their peering LAN” before they took off, Johar included.

                                -Bill