どうも、チェーン生成が絡んだ場合、iptablesを立て続けに操作した時に「そんなチェーン無いし」とか言われるっぽい。多分。それが起きると、Fail2banのログに

fail2ban.actions.action: ERROR  iptables -N fail2ban-何とか
iptables -A fail2ban-何とか -j RETURN
iptables -I INPUT -p tcp -j fail2ban-何とか returned 100

などと吐き出される。また、service iptables statusまたはiptables -L -nを実行すると、出力にChain fail2ban-何とか (0 references)が含まれている。ここも本来は(1 references)でなければならない。
　よって、小手先の対応としては、Fail2banを起動したらすぐにFail2banのログかiptablesのステータスを確認し、エラーが出ていたら出なくなるまでfail2ban-client reloadを繰り返し実行、くらいで大丈夫だと思う。または壊れている定義を自前で修復するか。
　というより、そんなアホな作業をしたくなかったので、iptables系アクションのiptables -N fail2ban-<name>の次の行にperl -e 'select undef,undef,undef,0.1'とか短時間のスリープを埋め込んでやれば幸せになるんじゃね、と思ったのだが、全然役に立たなかったのでやめた。
　つーか、チェーン生成は事前に自前でやってservice iptables saveしといて、iptables系アクションのチェーン生成削除処理を削除するのが一番安定だな。そうしよう。ついでに-j DROPを-j REJECT --reject-with icmp-admin-prohibitedに変更してみたけど、大抵は帯域の無駄という話もあったり。

　などとiptables系のアクションを弄っていたら、次に思ったのが「ここにip6tablesへの分岐処理とか埋めたら普通にIPv6対応になるんじゃね？」であった。
　が、Fail2banは、ログからIPv6アドレスを拾ってくれるのだろうか。公式Wikiのマニュアルを見てみると、<HOST>のマッチングは

(?:::f{4,6}:)?(?P<host>\S+)

となっているが、添付filterのコメントには

(?:::f{4,6}:)?(?P<host>[\w\-.^_]+)

とある。まあ、多分駄目だろうな。
　とは言っても、要するにPythonの名前付きキャプチャで拾ってるだけ、ということらしいから、filterも自前で

(?:::f{4,6}:)?(?P<host>[\w\-.^_:]+)

とかに書き換えればいいのだけど。

　ということで、意外と簡単に何とかなりそうだなー、と思ったが、IPv6ホストをbanするのって単純なソースアドレスマッチングで行けるのかなー、とか考えてるうちに、実際に困り始めたらやればいいかー、と思ったのであった。

追記:
　確かにREJECTは帯域の無駄だった。むしろバルクメーラー的にはメモリ節約出来て嬉しいという逆効果の予感も。