[Witarea] Re: [v6ops] Re: How to make an elegant IPv4 outage

As I told before, I implemented [ https://datatracker.ietf.org/doc/draft-martin-retry-over-ipv6/ | draft-martin-retry-over-ipv6 ] on [ https://pacific.ipv6forum.com/ | https://pacific.ipv6forum.com/  ] on 6/6 (IPv6 Day) 

I (with help from Jarvis) created a short report: 



# IPv4 outage drill report — 2026-06-06 UTC 

Generated: 2026-06-07 19:48:05 UTC Host: bookerpal-main 




## Summary 

- 566 events (journald): 6912 

- Recovery events (journald): 0 

- Probe events (journald): 0 

- Matched recovery tokens: 0 

- Token recovery rate: 0.0% (0 / 6912 unique 566 tokens) 

- Unique IPv4 client_ip blocked (journald): 2716 

- Main-host nginx requests excluded (exempt paths): 6264 

- Main-host nginx requests (blockable paths): 39619 

- Main-host nginx ×566 (blockable paths): 6466 

- Main-host ×566 rate (blockable): 16.3% 




## Impact by connection stack (main host, blockable paths) 

(Excludes /api/healthz, embed assets, and crawler paths — still HTTP 200 on IPv4 during the drill.) 

Stack Requests ×566 %566 Unique IPs 

----- -------- ---- ----- ---------- 

IPV4 8202 6465 78.8% 2852 

IPV6 31417 1 0.0% 2339 




## Impact by client family (main host, blockable paths) 

Family Total IPv4 reqs IPv6 reqs ×566 %566 Unique IPv4 Unique IPv6 

---------------- ----- ------------ ------------- ---- ----- ----------- ----------- 

Chrome 19746 4362 (22.1%) 15384 (77.9%) 3515 17.8% 1268 908 

Other 8110 1610 (19.9%) 6500 (80.1%) 970 12.0% 870 801 

Safari iOS 5910 1023 (17.3%) 4887 (82.7%) 823 13.9% 444 396 

Firefox 3759 728 (19.4%) 3031 (80.6%) 721 19.2% 247 197 

Bot/scanner 204 177 (86.8%) 27 (13.2%) 161 78.9% 71 22 

Safari macOS 910 126 (13.8%) 784 (86.2%) 121 13.3% 49 32 

Edge 610 84 (13.8%) 526 (86.2%) 77 12.6% 33 27 

Samsung Internet 206 49 (23.8%) 157 (76.2%) 44 21.4% 12 12 

iOS system fetch 163 43 (26.4%) 120 (73.6%) 34 20.9% 8 16 

Empty/unknown 1 0 (0.0%) 1 (100.0%) 0 0.0% 0 1 

I had some implementation issues, my /api/healthz probe (tell you which IPs we see and which one is preferred) was blocked on IPv4, while it should have been excluded, so I fixed it life. 
Logs could have been better, (I need to add some geographic/network information) so I'm fixing it for next drill on July 6th. 

I posted about this experiment: 
[ https://www.reddit.com/r/ipv6/comments/1ty2quu/if_you_dont_have_ipv6_and_try_to_visit/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button | https://www.reddit.com/r/ipv6/comments/1ty2quu/if_you_dont_have_ipv6_and_try_to_visit/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button ] 
[ https://www.threads.com/@franckhlmartin/post/DZOYxf7ifTQ?xmt=AQG01i9WNECHC-BrPN3tUC4q_GH6qYwe8VeHATFMPXTjEQ | https://www.threads.com/@franckhlmartin/post/DZOYxf7ifTQ?xmt=AQG01i9WNECHC-BrPN3tUC4q_GH6qYwe8VeHATFMPXTjEQ ] 

There were some interesting comments (that could find their way in the next ID revision): 
- I need to improve the visible error message 
- it seems some browsers, do not prefer IPv6, a few refresh may help. I think not all do a late start for IPv4 to give the chance for IPv6 to succeed. 
- it does not seem browsers perform any action around a 5xx even when they know the endpoint is at several IPs. This is something I noticed on some email clients, when they have a list of hostnames to connect to, some try only one IP by hostname. 
- I need to be clearer on the advice that, you should not do an IPv4 outage, it has business implications and may annoy people because there are little they can do, but if you have to do it, this is a a intermediary method you can do 
- There are plenty methods to collect data about who connects to IPv4 or IPv6 but this is not about this, it is about sending clear messages that get recorded in clients and servers logs, therefore get acted (see: you have to remove IPv4 capability) 
- Bots are terrible at IPv6 

I want to reaffirm, I consider this draft to be more of an helper in closed controlled environment, than on the public Internet, but it needs to work well in both. 

Finally, I want to separate the discussion, if we should do a coordinated IPv4 outage, or if others would like to do an IPv4 outage on a regular basis, from the technicality of the best way to do it if you feel compelled to do it. 

If you try to check the site, or have opinions, suggestions, please let me know. 

Franck Martin 
https://www.peachymango.org

-- 
Witarea mailing list -- [email protected]
To unsubscribe send an email to [email protected]