IPv6 control

[KHobbits]

IPv6 in its current state deployment is rather unstable, most places it is rolled out, its rolled out dual stack so that both IPv4 and IPv6 are available side by side.

With the removal of the IPv6 toggle in the user settings, it is no longer possible for the admin/user to decide which of these services to use, this needs fixed.

IPv6 and IPv4 should not be able to failover to each other, users should be bound to whichever vhost they have set.

ADDITIONAL INFORMATION:
For an IRC server for example 'tripwire.swiftirc.net' which has both IPv6 and IPv4 addresses, it is not satisfactory for sBNC to be able to decide which protocol it is to use, itself.

My server runs with a full /64 range and 3 IPv4 addresses, on sbnc 1.2 I had 3 clients running on IPv4, for stability with another 15 clients connected to the same server on IPv6.

[Gunnar Beutner (gunnarbeutner)]

As a workaround I would suggest binding the client to an IPv4 or IPv6 vhost.

[KHobbits (khobbits)]

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.