Silos and IP Pools can be linked, which means resources like instances or Floating IPs in those silos can draw addresses from those pools. That's a many-to-many relationship, tracked in the database by the ip_pool_resource table. We also have exactly two IP Pools, one for each IP version, reserved for Oxide services. That's created at RSS time and never modified.

Moving forward, we need to allow operators to more flexibly associated multiple IP Pools with the Oxide silo. That way, they can control which networks the Oxide services are run on, including doing so on more than one (say an IPv4 and IPv6 address for Nexus).

As part of this, we need to completely reserve the IP Pools for use by the Oxide silo. That means IP Pools can be:

• unlinked to any silo
• linked to many, non-Oxide silos, or
• linked only to the Oxide silo, but many pools may be so linked

Ideally, we'd enforce this in the database, so that we can avoid interactive transactions when operating on these. A check constraint or some creative indexes could work. OCC might also help, but we'd need to augment the tables with generation numbers.

As part of this, we probably want to ensure the is_default column is never set to true for the Pools delegated to us. I can't imagine a scenario in which we don't want to know which pool we're using for external addressing of our services.

Another note, we need to ensure that there is always at least one IP Pool delegated to the Oxide service pool. It'd be really bad to let customers cut themselves off from the rack.