Post-write safety check first: the new v6 metal-admin subnet landed on VLAN 5005,
which carries dhcp_on=True for the v4 subnet commissioning depends on. Measured
after -- rack vvr1-dc0 reports 9 services, zero degraded, dhcpd running, dhcpd6
off. Nothing disturbed; dhcpd6 off is legitimate, since MAAS starts it only for a
v6 dynamic range and none exists.

Prior art: dc-rack-net.sh already owns rack bridge legs via a site-keyed LEGS
table installed as a reboot-persistent unit, so v6 legs extend that table rather
than needing a new tool. Current table is three legs per site (rack .2, DNS
forwarder .3, edge-LAN .2), not six planes.

U17 is confirmed at the host layer -- zero global v6 on the rack, zero v6 links
known to MAAS for either rack controller. But nothing consumes a rack v6 leg
today, and the substantive question U17 did not ask is how NODES acquire v6:
MAAS static assignment (needs only the subnet, which now exists), DHCPv6 (needs a
dynamic range and dhcpd6, both absent by design), or SLAAC/RA (needs a router
advertising on the plane). Only the first is already satisfied, and they differ
materially. Presented rather than chosen; legs NOT applied.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01HvCyrwvYTTcDYnRErfMsNf