Update to new networking API shape, with IPv6

[charliepark]

This PR updates console to work with the new API shape for IP pool selection introduced in oxidecomputer/omicron#9598 and other Omicron networking PRs, like oxidecomputer/omicron#9665. These are summarized in #3000, and I have screenshots of each of the UX changes over in #3017.

I'll go over the main changes and how they relate to Console, both for us and for aipr as we go through it. There are still a few decisions to make in terms of forms / UI, but I'll try to note those as well.

Claude's summary of the changes in this PR:

Key API Shape Changes

1. Pool Selection: pool → poolSelector (Breaking Change)

Before:
pool?: NameOrId | null

After:
poolSelector?: PoolSelector // discriminated union

type PoolSelector =
| { type: 'explicit'; pool: NameOrId }
| { type: 'auto'; ipVersion?: IpVersion | null } // Required when dual defaults exist

Why: Enables explicit IPv4 vs IPv6 selection when both default pools exist.

---

2. Private IPs: Single Field → Structured IP Stack (Major Breaking Change)

Before:
// Single IP + transit IPs
ip?: string
transitIps?: IpNet[]

After:
// Discriminated union supporting v4-only, v6-only, or dual-stack
ipConfig?: PrivateIpStackCreate

type PrivateIpStackCreate =
| { type: 'v4'; value: PrivateIpv4StackCreate }
| { type: 'v6'; value: PrivateIpv6StackCreate }
| { type: 'dual_stack'; value: { v4: ..., v6: ... } }

Each stack has ip: Ipv4Assignment | Ipv6Assignment (auto or explicit) and version-specific transitIps.

---

3. Instance Network Interface Defaults: Expanded Options

Before:
type: 'default' // Single default option

After:
type: 'default_ipv4' | 'default_ipv6' | 'default_dual_stack'

Why: Explicit control over default interface IP version(s).

---

4. Dual Defaults: Now Allowed

Before: Max 1 default pool per silo

After: Max 4 defaults per silo:

• 1 IPv4 unicast default
• 1 IPv6 unicast default
• 1 IPv4 multicast default
• 1 IPv6 multicast default

---

5. Pool Types: Unicast vs Multicast

Added poolType: 'unicast' | 'multicast' field:

• Ephemeral/floating IPs → unicast only
• UI now filters pools by type in relevant contexts

---

6. New Core Types

• IpVersion: 'v4' | 'v6' used throughout
• Ipv4Assignment / Ipv6Assignment: { type: 'auto' } | { type: 'explicit'; value: string }
• PrivateIpStack: Discriminated union for runtime IP stack representation
• AddressAllocator: New allocator pattern for floating IPs

---

UI/Form Impact Summary

Form	Old Pattern	New Pattern
Instance Create	externalIps: [{ type: 'ephemeral', pool? }]	externalIps: [{ type: 'ephemeral', poolSelector? }]
Floating IP	pool?: string	poolSelector?: PoolSelector + ipVersion field
Network Interface	Single ip?: string field	ipStackType + separate ipv4/ipv6 fields → builds ipConfig

New Component: IpPoolSelector – radio-button UI for "IPv4 default" / "IPv6 default" / "custom pool" selection with version filtering.

Also, a quick note on selecting Ephemeral IPs for instances:

Scenario	Client Specifies	Behavior
No unicast defaults	{ type: 'ephemeral' } or omit pool_selector	FAILS with "No default IP pool configured for this silo"
One unicast default (v4 OR v6)	{ type: 'ephemeral' } (defaults to auto)	SUCCEEDS - Uses the one default pool via Auto { ip_version: None }
Dual defaults (v4 AND v6)	{ type: 'ephemeral' } without ip_version	FAILS with "Multiple default pools... please specify ip_version"
Dual defaults (v4 AND v6)	{ poolSelector: { type: 'auto', ipVersion: 'v4' }}	SUCCEEDS - Uses specified version's default pool
Multicast defaults only	{ type: 'ephemeral' }	FAILS - Ephemeral IPs require unicast pools (see external_ip.rs:177)

---

Also …
Closes #2901
Closes #3000

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
console	Ready	Preview	Feb 3, 2026 4:50am

[david-crespo]

You have e2e test failures in IP pools.

[david-crespo]

I'm assuming this was related to reducing flake?

[charliepark]

Yes; the theory from Claude was that with some animation changes in #3007 were causing some flaking in the e2e tests, though all of my local runs were working as expected, so I'm not sure if that was it. It just seemed to be an issue with the CI runs, and they ended up getting resolved by adding a .blur step, so it's possible the reducedMotion was moot. But if it speeds things CI runs up a tiny bit, and maybe fixes one or two flakey tests along the way, I'm okay with keeping it.

[david-crespo]

Not 100% sure, but I think only one or two of the side modals actually changed behavior in #3007 — mostly it was a slightly neater way of doing what we were already doing.