Is there reason to think someone will want IPv6-only behavior? If not, perhaps the command-line parameter can be eliminated. In GH-17851, I've taken a more surgical approach that avoids altering the HTTPServer or the command-line interface.

If this command-line argument is desirable, I'd recommend --dual-stack={on,off,auto} with default of on and the values corresponding to how setsockopt IPv6ONLY is called:

• auto: not called
• on: called with 0
• off: called with 1

I think there is no special reason to keep the IPv6-only function, I just want the backward compatibility when I create this patch.
Microsoft also keeps the "IPv6 Dual-Stack" off. Maybe very few people need it. For example, a server between Internet and Intranet, administrator don't want Intranet user access the server by IPv6.
↑Firewall would be better

Okay, so if the main motivation was to retain backward compatibility, that's no longer an issue, as it was unintentional not to be binding dual-stack. In my experience on the CherryPy project, binding dual stack has never been a concern. If a service binds IPv6, they almost always want IPv4 connectivity as well. I'd recommend to defer adding the option until someone requests it, which I think is unlikely to happen, or until someone adds the option to the HTTPServer API, in which case the CLI could support that interface.