diff --git a/migration/PPPOE-HA.md b/migration/PPPOE-HA.md
index 72dc250..bf88756 100644
--- a/migration/PPPOE-HA.md
+++ b/migration/PPPOE-HA.md
@@ -201,15 +201,52 @@ not `pppoe0`'s.
 > drill produces that figure, the IPv6 behaviour of a failover is *unmeasured*,
 > not "fine".
 >
-> The gap itself is real and open: **IPv6 is single-homed on vyos001 while the
-> WAN beneath it is HA.** Step 0 of the re-sequenced IPv6 plan closes it; see
-> `migration/pulumi-override-he-tunnel-both.json` and
-> `labsim/labsim-ipv6-ha-test.sh`.
+> The gap itself was real: **IPv6 was single-homed on vyos001 while the WAN
+> beneath it was HA.** **Closed and measured 2026-09-06** — see the drill below.
 
 Production takeover (52s) is about twice the sim's `replace` figure (26s), which
 is the expected direction: the VP2440s commit under kea, BGP and conntrack while
 the sim routers are idle.
 
+## IPv6 follows the WAN — measured, 2026-09-06
+
+The second drill of the day, run after IPv6-follows-master was deployed. This is
+the first time the IPv6 behaviour of a failover has been a **measurement** rather
+than an assertion:
+
+```
+TAKEOVER OK: vyos002 held the VIP and reached the internet in 37s
+IPv6 followed in 37s (v4 37s, gap 0s)
+FAILBACK OK in 32s
+IPv6 back in 44s
+tun0 src : 87.192.101.48 -> 87.192.101.48   OK: unchanged across the drill
+HE updates from vyos001: 0
+HE updates from vyos002: 0
+```
+
+Full log: `migration/drill-evidence/wan-drill-2026-09-06-ipv6.log`.
+
+**Zero HE API calls across a full takeover and failback.** This is the invariant
+the design rests on and it now has evidence: the 10 gig lease follows the cloned
+MAC, so the tunnel endpoint is the *same address* on whichever router holds the
+WAN, and there is nothing to tell Hurricane Electric. Only the within-box fall
+back to PPPoE needs an HE update.
+
+**IPv6 is no longer the laggard, but the two directions are not symmetric.** On
+takeover it arrived in the same 5s sample as IPv4; on failback it trailed by 12s.
+That asymmetry is the reconciler's tick, not a fault: on promotion it enables
+`bond0.53` first, and `v6_take` only raises the tunnel once the source address
+actually exists, so it can land on the following 30s tick. Bound is one tick.
+Note the sampling granularity — the drill polls every 5s, so "gap 0s" means
+"within the same sample", not "simultaneous".
+
+Takeover was 37s here against 52s in the morning drill. Do not read that as an
+IPv6 improvement; it is the same IPv4 mechanism on a different run, and the
+morning figure included the first-ever cloned-MAC lease transfer.
+
+**Vodafone confirmed the every-dial-a-new-address behaviour again**: `pppoe0`
+came back as `90.251.152.236`, having been `90.251.142.103` before the drill.
+
 ## config.boot pins `vif 53 disable` on both — fixed 2026-09-06
 
 The convention is that **both** `config.boot`s hold `vif 53 disable`, so a reboot