Comment 2 for bug 717083

First thing I tried.

31/1 00:15:37 --sBNC- password - Set
31/1 00:15:37 --sBNC- vhost - 207.192.75.169
31/1 00:15:37 --sBNC- server - [tripwire.uk.eu.SwiftIRC.net]:6667
31/1 00:15:37 --sBNC- serverpass - Not set
31/1 00:15:37 --sBNC- realname - iDM Control Bot
31/1 00:15:37 --sBNC- awaynick - iDM[Control]
31/1 00:15:37 --sBNC- away - iDM Control Bot
31/1 00:15:37 --sBNC- awaymessage - Not set
31/1 00:15:37 --sBNC- usequitasaway - Off
31/1 00:15:37 --sBNC- ssl - Off
31/1 00:15:37 --sBNC- automodes - -x
31/1 00:15:37 --sBNC- dropmodes - -x
31/1 00:15:37 --sBNC- autobacklog - Off

iDM[Control] is ~quantum@2001:470:c0ad:8:0:0:0:20 * iDM Control Bot

Seriously though, removing the function to control this is rather silly, even if that vhost suggestion worked. While it might be desirable to have the system failback to the alternative transport method, this is just not acceptable for some systems. For example on a system with 1 IPv4 and multiple IPv6, 10 users could easily use the BNC, if the IPv6 ever failed however and the users tried to connect on the single IPv4, this would trigger most IRC services to ban access from that IP due to session limits.