Fail2ban 0.10: New features. Test open

This is the announcement of the new version of fail2ban (for the time being, the alpha test branch), in which, besides many other improvements and goodies, albeit with a delay, the long-planned IPv6 support has appeared.
Time, be it not well - flies at a breakneck pace.

Briefly, the list of the new, already entered (and most likely to be added soon) in fail2ban version 0.10:

• Of course, support for IPv6 (for now only for iptables, iptables-ipset, firewallcmd, pf)
• New syntax for pseudo-conditional sections in configuration files, used for conditional substitution and interpolation of parameters for different host types, example [Init?family=inet6] (currently only used for IPv6 support)
• Significant increase in the performance of fail2ban compared to version 0.9.x
• prevent regression of performance with increasing number of IP addresses ( failure and ban )
• preventing out of memory situations, with a large number of failure from many IPs (maxEntries), as well as optimizing memory usage in the FailManager manager
• (str2seconds) convenient time settings in the configuration, i.e. it is possible to use 1h instead of 3600 or 1d instead of 86400 , etc.
• (seekToTime) - quick start, prevents long reading of large files for the first time after starting the service
• smart caching of everything and everything (dnsToIp, ipToName, pre-interpolation of action call parameters, etc.)
• [soon] merge with my incremental version ( ban-time-incr branch)
• [soon] customizable changeable ban factor (new ban-time-incr version), for example, IP address geo-dependency, below is a configuration example, where an IP address ten times earlier will be considered "bad" if the country is not Russia)
  

   geo.country = RU:1 default:10 

• [shortly] automatic custom blocking of sub-networks
• [soon] completely rewritten client-server (possibility of execution in foreground mode, test coverage, new “restart” command in addition to “reload”, changeable level of detail to heavydebug at start and other improvements)

The significant performance gains in fail2ban version 0.10 can be roughly estimated in the following figures:

A score is quite strongly influenced by many parameters, such as activity (parasitic) logging, quality (and quantity) of regular expressions (fail2ban filter), call speed and type of banaction, lookns-type parameters usedns , etc. etc. However, ceteris paribus, in the case close to the ideal, approximately such figures are obtained.

For those who read my article "Fail2ban [incremental]: Better, faster, more reliable" or use this "incremental" version - everything new 0.10 merged in this thread - https://github.com/sebres/fail2ban/tree/0.10 -full . I will support here until I release (see PR gh-1460 )

Automatically configured blocking of sub-networks is also planned (as it is especially important for IPv6-addresses). Simply putting 2 ¹⁶ (or 65.536) IPv6 addresses in the bank separately if the attacker has the X :: / 112 subnet, which is somehow noncomme (we will keep silent about the higher order subnets).
I hope before the release of 0.10, this functionality will still be finished.

I repeat, 0.10 is still a test branch. Anyone who wants to take part in testing or modify for example the support of other action - welcome.

Download:
https://github.com/fail2ban/fail2ban/archive/0.10.zip

Git:
git clone -b 0.10 https://github.com/fail2ban/fail2ban.git