2026-07-14 -- Office1 LAN IPv6 is LIVE (Stage 2 close-out C1: OPEN -> DONE)

The last build item on Office1. Executed against the live edge and proven on the wire, not by self-report. Closes the item pinned since 2026-07-13 (D-115 question 3).

Operator ruling that shaped it (2026-07-14)

The session opened with a proposal to build an IPv4-to-IPv6 NAT (a second OPNsense, or nginx) to simulate the v6 forwarding the lab does not provide. Not built, and the proposal was withdrawn in favour of: "configure IPv6 internally as much as possible and we will configure the IPv6 edge after deployment has been completed."

Why that was the right call, recorded so it is not re-proposed:

D-101 already rules it out: "native GUA routing, no NAT66 -- NAT66 is discouraged and we own the edge." Translation is a REJECTED approach here, not an open one.
D-115's amendment already ruled on this exact symptom: v6 not routing past the lab boundary is "a network issue OUTSIDE this cloud and outside this repo -- it needs the lab/upstream operator, not a change here."
MINIMIZE DELTA TO ROOSEVELT: Roosevelt has a real ISP carrying real v6. A translation box is precisely the component Roosevelt will NOT have, so a NAT shim is the least faithful possible simulation -- it would make the runbooks teach a topology that must later be deleted.
nginx was not a peer option: it is an L7 HTTP(S) reverse proxy, not NAT. It proves nothing about RA, ICMPv6, Ceph-over-v6 or geneve-over-v6 -- i.e. nothing about D-101's family matrix.

Re-measured 2026-07-14, confirming D-115: vcloud holds a GUA and a v6 default route via RA, the v6 gateway is reachable, but v6 internet is 100% loss while v4 from the same host is fine. The lab's upstream advertises RA and a prefix and does not route v6 out. Unchanged, and not ours to fix.

What was done

scripts/opnsense-set-interface-v6.sh --commit 10.10.0.1 lan 2602:f3e2:f01:100::1 64
POST /api/radvd/settings/addEntry {"entries":{"enabled":"1","interface":"lan","mode":"unmanaged"}}
POST /api/radvd/service/reconfigure

Address 2602:f3e2:f01:100::1/64 is the D-115 carve value, not an invented one.

The address half is NOT API-doable -- see the D-113 amendment. The RA half IS API-native. Both halves are now exercised for real, which is what makes them reusable verbatim for the DC0/DC1 edges at Stage 3.

`mode=unmanaged`, deliberately NOT the model's default

The radvd model defaults to mode=stateless, which sets the RA Other-config flag -- telling clients to fetch DNS and other options from a DHCPv6 server. MEASURED on the edge: Kea DHCPv6 is enabled=0 and no DHCPv6 daemon is running. Accepting the default would have advertised a DHCPv6 server that does not exist -- a quiet misconfiguration that would look fine and produce clients that hang waiting on it. unmanaged (M=0, O=0) is the honest configuration for SLAAC-only.

Field names, the request key (entries, from addBase('entries','entries')), the legal mode values, and the apply endpoint were all READ OFF THE EDGE (the model XML and the controller), not recalled. Nothing here was guessed.

PROVEN ON THE WIRE (not by `{"result":"saved"}`)

edge   ifconfig vtnet0  -> inet6 2602:f3e2:f01:100::1 prefixlen 64     [the KERNEL, not the config]
edge   radvd running    -> prefix 2602:f3e2:f01:100::/64, AdvAutonomous on, AdvOnLink on
                          RDNSS 2602:f3e2:f01:100::1, no M/O flags  [= unmanaged took effect]
voffice1                -> inet6 2602:f3e2:f01:100:5054:ff:fe6a:87e5/64  [SLAAC]
                          + 2602:f3e2:f01:100::/64 proto ra           [RA-learned route]
edge -> voffice1 GUA    -> 3 packets, 0.0% loss, 0.838ms avg          [TRAFFIC PASSES]
edge ndp -an            -> neighbour 52:54:00:6a:87:e5                [matches voffice1's Kea
                                                                      lease hwaddr -- it IS voffice1]

No collateral damage (configctl interface reconfigure lan re-applies the LAN that all of Office1 sits behind): v4 10.10.0.1 intact, Kea DHCPv4 still running and listening on udp/67, edge + voffice1 + the routed compose net all still reachable. The interface-count assertion held (3 interfaces, unchanged).

A trap worth recording: `accept_ra=0` does NOT mean "RAs ignored" on Ubuntu

voffice1 has kernel net.ipv6.conf.all.forwarding=1 (it runs LXD) and accept_ra=0 on enp1s0. Classic Linux behaviour says a forwarding host ignores RAs unless accept_ra=2 -- so this looked like it could not possibly have autoconfigured. It did. netplan/systemd-networkd processes RAs in USERSPACE, independent of the kernel sysctl. Do not diagnose "no SLAAC" from the sysctl alone on an Ubuntu box; read ip -6 addr and look for a proto ra route.

What this does and does NOT prove

Proves (most of D-101's family matrix): v6 addressing, RA/SLAAC, on-link routing, and the edge speaking v6 on the LAN. This is the mechanism DC0/DC1 will reuse.

Does NOT prove, and cannot in VR1: internet GUA reachability. The WAN v6 leg is DEFERRED per D-115 -- it would be a path to nowhere and untestable. Per the 2026-07-14 operator ruling, the IPv6 edge is configured AFTER deployment completes. Do not read this green result as "v6 works end to end."

Revert

# RA
bash scripts/opnsense-api.sh POST /api/radvd/settings/delEntry/627e3f12-8150-4909-9910-a275f2a0a6fc
bash scripts/opnsense-api.sh POST /api/radvd/service/reconfigure
# address (clear the two leaves, then reconfigure)
bash scripts/opnsense-set-interface-v6.sh --commit 10.10.0.1 lan :: 64   # or clear via the GUI

(OPNSENSE_API_HOST=10.10.0.1 for the API calls.) Reverting is not expected to be needed: nothing depends on the v6 leg yet, and the v4 LAN is untouched by it.