diff --git a/docs/design-decisions.md b/docs/design-decisions.md index 2df87ea..499ad56 100644 --- a/docs/design-decisions.md +++ b/docs/design-decisions.md @@ -2571,3 +2571,105 @@ ACCEPTED delta, bought deliberately: it is what makes a geographic-failure drill executable at all in a virtual rehearsal. The LXD half carries NO delta -- it is exactly what VR0 runs today and what Roosevelt would run on real hardware (a service host running LXD, registered to MAAS). + +## D-115: VR1 Office1 addressing -- the office carve, and the v4 role gaps it exposed + +**Status:** **PROPOSED / OPEN (2026-07-13). Operator to rule.** Found during Office1 deployment +testing: the headend was built on address space that NetBox never assigned. Per the operator, the +IPAM carve matters MORE than the deployment already standing on it -- "we can always change the +current IP addressing on the deployment; getting the IPAM carve proper and correct is more +important than going back and correcting deployment work." Nothing here is blocked; Office1 runs. +This is about ratifying or replacing what it runs on, BEFORE NetBox/GitBucket land on it. + +### What the IPAM apex actually encodes (MEASURED 2026-07-13 against netbox.baldurkeep.com) + +**IPv6 is a complete, consistent, region-hierarchical model.** `2602:f3e2::/36` (ARIN, Abysius Inc). +Every REGION gets a `/40`; inside it, SITES are `/48`s on a FIXED slot pattern: + +| slot | meaning | VR0 (`e00::/40`) | VR1 (`f00::/40`) | Eugene (`100::/40`) | +|---|---|---|---|---| +| `X00::/48` | Infrastructure / site-to-site links | `e00::` | `f00::` | `100::` | +| `X01::/48` | **Offices** | `e01::` | **`f01::`** | `101::` | +| `X02::/48` | Datacenter (first) | `e02::` (VR0 DC0) | `f02::` | `102::` Willamette | +| `X03::/48` | Datacenter (second) | `e03::` (VR0 DC1) | `f03::` | `103::` Roosevelt | + +Inside an office `/48`: a reserved `/56`, then ONE `/56` PER OFFICE, then a `/64` office subnet. +VR0 Off0 = `e01:100::/56` -> `e01:100::/64`. Eugene's Charnelton = `101:100::/56`. Inside a DC `/48`: +the D-111 NN mnemonic (`:10` provider, `:11` provider API VIP, `:20` metal, `:30` data, `:40` +storage, `:50` replication, `:80` lbaas-mgmt, `:e0` VPN, `:f0` OOB), each `/60` + `/64`. +Also global: `2602:f3e2::/40` inter-regional infrastructure, `2602:f3e2:fe::/48` **Edge Networks**, +`2602:f3e2:ff::/48` OpenStack tenant reservation. + +**IPv6 for Office1 therefore has NO design freedom** -- the pattern determines it: +`2602:f3e2:f01:100::/56`, office subnet `2602:f3e2:f01:100::/64`. VR1's office `/48` already exists. + +**IPv4 is a much thinner, ROLE-based model** -- and this is where the gaps are: +`10.0.0.0/8` "Corp Private" has exactly three children: `10.12.0.0/16` **Cloud**, `10.16.0.0/16` +Datacenter (Willamette dev), `10.17.0.0/16` Datacenter (Roosevelt dev -- the physical lab net that +vcloud and the VR0 jumphost actually sit on). Plus `172.16.0.0/12` "Corp OOB Private". + +### The gaps (all four are real; none was known before today) + +1. **There is NO Office role in v4.** Office1's LAN `10.10.0.0/24` (chosen during the OPNsense edge + build, 2026-07-12) and its LXD compose network `10.10.1.0/24` (chosen 2026-07-13) are SQUAT -- + unallocated, unregistered, colliding with nothing but blessed by nothing. +2. **DC2's planned `10.13.0.0/19` is OUTSIDE the Cloud `/16`.** `docs/dc-dc-netbox-buildout-scope.md` + recommends it, but NetBox's Cloud role is `10.12.0.0/16`; `10.13.x` is unallocated. DC2 was + already set to squat, and nobody had noticed. +3. **`office1-wan` (`172.30.1.0/24`) squats INSIDE `172.16.0.0/12` "Corp OOB Private"** -- and it is + not OOB, it is a SIMULATED ISP UPLINK. That is a wrong-role problem, not merely an unregistered one. +4. **"Edge Networks" has a v6 `/48` (`2602:f3e2:fe::/48`) but NO v4 counterpart**, so the simulated + ISP/WAN segments have nowhere legitimate to live in v4 at all. + +(Also, still open and pre-existing: NetBox holds ZERO aggregates -- gap G2 -- so nothing declares +these allocations at the RIR level. And `2602:f3e2:f01:100::/56` needs a `VR1 Off1` SITE, which +does not exist in NetBox either.) + +### The design tension the operator must rule on + +**v6 here is REGION-hierarchical; v4 is ROLE-based.** That asymmetry is defensible and, I think, +correct: v6 is abundant, so it can afford geography; v4 is scarce, so it is pooled by function. +The alternative -- forcing v4 to mirror the v6 region tree -- burns scarce v4 AND requires +RENUMBERING DC1 off `10.12.x`, which is exactly the inheritance D-101 bought in order to reuse +VR0 DC0's bundle unchanged (minimize delta to Roosevelt). That is a large cost for conceptual tidiness. + +### Options + +**(a) RECOMMENDED -- keep v4 role-based; fill in the MISSING roles. Ratify the deployed addresses.** +- New v4 role **Office**: `10.10.0.0/16`, carved **`/22` per office**. + VR1 Office1 = **`10.10.0.0/22`** -> LAN `10.10.0.0/24` (as deployed) + LXD compose `10.10.1.0/24` + (as deployed) + `.2`/`.3` spare. **This BLESSES exactly what is already running -- zero renumber.** +- New v4 role **Edge** (mirroring v6's `2602:f3e2:fe::/48`): `172.30.0.0/16` for simulated ISP/WAN + segments, carved out of the `172.16.0.0/12` container but with its OWN role, not OOB. + Office1's WAN `172.30.1.0/24` (as deployed) becomes legitimate; DC1/DC2 edges take `.2`/`.3`. +- **DC2 moves INSIDE the Cloud `/16`**: `10.12.64.0/19` (free -- DC1's six `/22`s occupy + `10.12.4/8/12/16/32/36`, so `10.12.64.0/19` collides with nothing and DC1<->DC2 stay routable + over the dark fiber). SUPERSEDES the scope doc's `10.13.0.0/19` recommendation. +- IPv6 per the pattern: Office1 = `2602:f3e2:f01:100::/56` + `/64` subnet; create the `VR1 Off1` site. +- COST: two NetBox roles + a handful of prefixes. **No deployment renumber at all.** + +**(b) Mirror the v6 region model in v4.** Give each virtual region a v4 `/16` (e.g. VR1 = `10.15.0.0/16`) +and carve sites inside it (infra / office / DC1 / DC2). Conceptually cleanest; the two families would +read identically. COST: RENUMBERS DC1's six planes off `10.12.x`, which BREAKS D-101's +inherit-DC0-unchanged economy and forces edits to `lib-net.sh`, MAAS subnets, and the bundle's VIPs. +It also spends a whole `/16` per virtual region on a test environment. Recommended ONLY if the +operator wants v4 and v6 structurally identical and accepts the DC renumber. + +**(c) Ratify the squat as-is and register it verbatim.** Record `10.10.0.0/24`, `10.10.1.0/24`, +`172.30.1.0/24`, `10.13.0.0/19` in NetBox exactly as deployed, with no new roles and no structure. +Cheapest today, and WRONG: it enshrines an ISP-sim network inside the corp OOB block, leaves offices +with no allocatable block for the next office, and leaves DC2 outside the Cloud role. Rejected +unless the operator wants pure speed. + +### What is NOT at stake + +Nothing is blocked and nothing is broken. Office1 is live and routing on the squat addresses. The +question is only what to write into the IPAM apex -- and the renumber cost is LOWEST RIGHT NOW, +before NetBox and GitBucket are deployed onto that network. Under option (a) the renumber cost is +ZERO, because (a) is shaped to bless what is already there. + +**References:** measured 2026-07-13 against `netbox.baldurkeep.com` (read-only; SEC-006 token). +D-101 (family matrix + DC1-inherits-DC0), D-111 (NN mnemonic subcarve), D-016 (tenant pool +`10.20.0.0/16` -- the reason the obvious `10.20.x` was NOT used for the compose net), +`docs/dc-dc-netbox-buildout-scope.md` (whose `DC2_V4_SUPERNET = 10.13.0.0/19` recommendation this +decision would supersede under option (a)), D-114 (which built the headend that exposed all of this).