よくよく考えてみたら、IPv4のDNSサーバからAAAAレコードは拾えるんだし、キャッシュサーバやリゾルバが対応してりゃIPv6アドレスへのグルーとか要らないかー、と思ったのが前回までの話。
　で、割と対応してる場合もあるっぽいので、ならば6to4で一応半端にデュアルスタックになるんじゃね、と思ってさくらのVPSで実験してみたら出来た。前回のやり方に加えて、6to4アドレスをAAAAレコードで足しただけ。IPv6接続テストみたいなサイトもあるので、ホスト名を引かせてpingやHTTPが通るのも確認。何か見落としてそうで不安だ（笑）。
　ただ、LighttpdのIPv6対応はちょうど仕様変更の境目のようで、EPELだったかで入れたバージョンは旧仕様であった。それに合わせて設定を書いたが、バージョン上がったら書き換えないとなあ。他にはPostfixもinet_protocols = allが必要だったが、まあ、この辺は別に書かなくても困らんだろうなー実際んとこ。

　調子に乗って、SaaSesの方も全く同じやり方でやってみようとしたら、

致命的: [ipv6_test] カーネルが IPv6 をサポートするようにコンパイルされていません。

とか出た。/etc/modprobe.confのoptions ipv6 disable=1をコメントアウトして、えーと、rebootで。よし動いた。
　相互にping6をするとRTTは9msくらい。IPv4ネットワークで完結しているのかな。
　最後に、Nginxのserverブロックにlisten [::]:80;を追加して終了。
　Lighttpd（1.4.26まで）とNginxは、Linuxカーネルのnet.ipv6.bindv6onlyの設定に依存せざるを得ないっぽいので落ち着かないが、まあ、ここが勝手に変わることは無かろう。Debianで一度変えて騒動になって戻したらしいし。

　あとはー、逆引きかー。
　もういいやー（笑）。さくらのVPSがIPv6に正式に対応したらー、何とかしてくれるんじゃないのーかーなー。

　ていうか多分要らんことしたよな、これ（笑）。
　リゾルバ依存の対応ではあるしなあ…。やっぱAAAAの設定は消しとくか。という訳で、今は基本的に繋がりません。v6のグルーを設定したいですなあ。
　というより、一番不安だったのは、逆引き出来ないホストからのSMTPを蹴るアレな人達がいるというソレで。まあ、PostfixをIPv4専用にしときゃ平気かもしれんけど。

　前回のserverブロックの中に、

        location ~ \.php$ {
            if (!-f $request_filename) {
                return 404;
            }
            include fastcgi.conf;
            fastcgi_pass 127.0.0.1:9000;
        }

このようなブツを追加したところ、あっさり起動。
　…あっさりというのは嘘だな。この設定は、include付近をNginx Wikiのサンプルに合わせたのだが、EPELから入れたNginxに同梱されているfastcgi_paramsとfastcgi.confは微妙に違っていて、気付かずにWikiのサンプルを混ぜたらSCRIPT_FILENAMEを受け渡す設定がスッポリ抜け落ちてしまい、HTTPからPHPを叩いてもレスポンスヘッダしか返してくれない状態になって激しく悩んだのだ。エラーとは認識されていないので、INFOレベルのログまで吐かせても原因が分からないし。FastCGIの仕様は知らないが、これが仕様通りの動作なのかもしれない。バカな指示をしたからバカな動作をした、と。

　という訳で、Osukini LTの方でもNginx+PHP-FPMが動く状態になった。せっかくだからWordPressでも入れて、今メインになってるさくらのVPSのLighttpd+PHP-FPMと比べてみるかー、と思ったのだが、結構めんどくさいんだよなあ…。実は既にOsukiniの方にもMySQLが入っていて、read-onlyのslaveとしてレプリケーションを行っているのだ。
　つーか正直、Osukiniでもパフォーマンスには不満無いのかもなー、とか思い始めていたので、実際WordPressが体感でどの程度違うのかは比較してみたかったのだが。さくらとSaaSesのVPSの比較は、ネタ的にも面白そうだし。

追記:
　書き忘れてたけど、PHP-FPMはもちろん別口で走らせている。この記事の時の設定を流用で。