Posted on Tue Feb 22 23:01:17 +0900 2011 by nabeken 
皆さんIPv6してますか？今日は激安でかつnative IPv6が使える vr.org (https://www.vr.org/) のVPSを借りてみたのでご紹介します。
オーダーは https://www.vr.org/plans-and-pricing/ からできます。
電話によるorder verificationがあります。ここがちょっとネックでしょうか。非通知で掛かってきます。 音質が悪い(国際電話なのとたぶんソフトバンクなせい)ので何度も聞き直しましたが、丁寧に何度も言い直してくれました。 主な質問:
以上です。女性でしたがちょっと笑ってました。対応に困っていたんだと思います。。。 質問に答えおわるやいなや、approvalしたというメールがきて使用可能になります。
おそらくハイパーバイザーはXenです。
2011/02/20現在、選択できるOSは以下です(https://www.vr.org/os)。
Debian squeezeがすでに選べるのはとてもよいと思います。ちなみに、vr.orgはGentooの公式スポンサーです。 デプロイ時にOS、ホスト名、root password, ロケーション(NY, CA, ...など)などを入力するとその場でビルドが始まります。 私はもちろん… Debian 6 (64bit) にしましたよ？
ビルド完了後、IPv4アドレスとIPv6アドレスが通知されます。見た感じ、IPv6は 2607:f740:X:/48が振られるようです。 ff02::1へpingすると数十台の反応がありました。
プロセスはDebianの最小構成でcron, atd, ssh, exim, portmap, rsyslogくらいでした。
Debianの /etc/network/interfaces のinet6部分がおかしかったり、/48のprefixとデフォルトゲートウェイをRAで配っているようです。。 /48だとkernelがprefix lengthがおかしいというエラーを吐き続けます。
[ 7.213855] IPv6 addrconf: prefix with wrong length 48 [ 164.116473] IPv6 addrconf: prefix with wrong length 48 [ 320.170341] IPv6 addrconf: prefix with wrong length 48
RFC4862 (Section 5.5.3)ではRAの処理の際、prefix lengthが interface identifier + prefix lengthが128でない場合はそのprefix informationは無視 しなければならない(MUST)としています。
If the sum of the prefix length and interface identifier length does not equal 128 bits, the Prefix Information option MUST be ignored. An implementation MAY wish to log a system management error in this case. The length of the interface identifier is defined in a separate link-type specific document, which should also be consistent with the address architecture RFC4291 (see Section 2).
デプロイ直後の /etc/network/interfaces は以下のようになっていました。
iface eth0 inet6 static
address 2607:f740:000f:0000:0000:0000:0000:XXXX
netmask ffff:ffff:ffff:0000:0000:0000:0000:0000
gateway 2607:f740:000f:0000:0000:0000:0000:XXXX
netmaskの値が間違っています。 man 5 interfaces によれば inet6 の場合netmaskはprefix lengthになります。したがって、以下に修正します。
iface eth0 inet6 static
address 2607:f740:000X::XXXX
netmask 48
gateway fe80::XXXXXX
pre-up sysctl -p
なお、この件はすでにサポートへ報告済みで、問題として認識されています。近いうちに修正されるでしょう。
このネットワークではprefixとdefault gatewayをRAで配布しています。prefixは固定なのでひとまずdefault gatewayだけRAから反映させることにします。 (RAの部分適用)
# grep accept_ra /etc/sysctl.conf net.ipv6.conf.eth0.accept_ra_pinfo=0
interfacesの設定ではpre-upでeth0がupする前に一度sysctl実行しaccept_raの設定を反映させます。 通常のタイミングではeth0がupしたあとなので意味がありません。
再起動後、dmesgからエラーが消えていればprefix informationは無視できています。
ロケーションはNYを選択しましたが、やや遠いようです。手元のIPv6はトンネルですが、VPS側はnativeだけあってほとんどIPv4と変わりません。
$ ping -c 5 nao.vr.tknetworks.org PING nao.vr.tknetworks.org (209.177.145.236) 56(84) bytes of data. 64 bytes from nao.vr.tknetworks.org (209.177.145.236): icmp_req=1 ttl=45 time=200 ms 64 bytes from nao.vr.tknetworks.org (209.177.145.236): icmp_req=2 ttl=45 time=212 ms 64 bytes from nao.vr.tknetworks.org (209.177.145.236): icmp_req=3 ttl=45 time=204 ms 64 bytes from nao.vr.tknetworks.org (209.177.145.236): icmp_req=4 ttl=45 time=195 ms 64 bytes from nao.vr.tknetworks.org (209.177.145.236): icmp_req=5 ttl=45 time=236 ms --- nao.vr.tknetworks.org ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 4004ms rtt min/avg/max/mdev = 195.825/209.755/236.130/14.247 ms $ ping6 -c 5 nao.vr.tknetworks.org PING nao.vr.tknetworks.org(2607:f740:f::f84) 56 data bytes 64 bytes from 2607:f740:f::f84: icmp_seq=1 ttl=47 time=217 ms 64 bytes from 2607:f740:f::f84: icmp_seq=2 ttl=47 time=214 ms 64 bytes from 2607:f740:f::f84: icmp_seq=3 ttl=47 time=218 ms 64 bytes from 2607:f740:f::f84: icmp_seq=4 ttl=47 time=214 ms 64 bytes from 2607:f740:f::f84: icmp_seq=5 ttl=47 time=215 ms --- nao.vr.tknetworks.org ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 4005ms rtt min/avg/max/mdev = 214.074/216.057/218.484/1.739 ms $ traceroute nao.vr.tknetworks.org traceroute to nao.vr.tknetworks.org (209.177.145.236), 30 hops max, 60 byte packets 1 10.3.5.10 (10.3.5.10) 3.946 ms 3.933 ms 3.920 ms 2 61.207.37.195 (61.207.37.195) 7.215 ms 7.194 ms 7.212 ms 3 61.207.37.222 (61.207.37.222) 7.186 ms 7.722 ms 7.874 ms 4 125.206.149.245 (125.206.149.245) 13.603 ms 13.604 ms 13.960 ms 5 60.37.11.41 (60.37.11.41) 9.827 ms 9.820 ms 9.808 ms 6 210.254.188.141 (210.254.188.141) 9.796 ms 7.623 ms 7.406 ms 7 118.23.168.27 (118.23.168.27) 8.550 ms 6.230 ms 6.719 ms 8 ae-11.r21.tokyjp01.jp.bb.gin.ntt.net (129.250.12.201) 14.824 ms 14.784 ms 14.788 ms 9 ae-2.r20.tokyjp01.jp.bb.gin.ntt.net (129.250.3.209) 23.063 ms 22.987 ms 22.988 ms 10 as-1.r20.sttlwa01.us.bb.gin.ntt.net (129.250.4.189) 153.999 ms 154.073 ms 133.499 ms 11 ae-5.r20.chcgil09.us.bb.gin.ntt.net (129.250.3.191) 173.887 ms 174.973 ms 166.713 ms 12 * * * 13 * * * 14 vl851.core2.nyc01.steadfast.net (208.100.32.22) 205.489 ms 201.609 ms 201.407 ms 15 ip30.67-202-117.static.steadfast.net (67.202.117.30) 233.551 ms 238.076 ms 217.846 ms 16 nao.vr.tknetworks.org (209.177.145.236) 205.038 ms 224.162 ms 203.873 ms $ traceroute -6 nao.vr.tknetworks.org traceroute to nao.vr.tknetworks.org (2607:f740:f::f84), 30 hops max, 80 byte packets 1 2001:380:6dc:336::1 (2001:380:6dc:336::1) 0.784 ms 0.770 ms 0.757 ms 2 2001:380:80a0::d (2001:380:80a0::d) 6.768 ms 6.768 ms 7.044 ms 3 2001:380:80a0:5::1 (2001:380:80a0:5::1) 7.791 ms 7.785 ms 7.815 ms 4 2001:380:8130:a::1 (2001:380:8130:a::1) 7.805 ms 7.848 ms 7.833 ms 5 2001:380:8130:11::18 (2001:380:8130:11::18) 7.803 ms 8.067 ms 8.064 ms 6 ae-5.r20.tokyjp01.jp.bb.gin.ntt.net (2001:218:0:5000::d) 76.452 ms 73.301 ms 73.287 ms 7 as-1.r20.sttlwa01.us.bb.gin.ntt.net (2001:218:0:2000::21) 121.544 ms 121.151 ms 121.672 ms 8 ae-5.r20.chcgil09.us.bb.gin.ntt.net (2001:418:0:2000::146) 225.243 ms 225.171 ms 225.169 ms 9 po-2.r00.chcgil09.us.bb.gin.ntt.net (2001:418:0:2000::302) 195.508 ms 196.061 ms 193.374 ms 10 xe-0.steadfast-networks.chcgil09.us.bb.gin.ntt.net (2001:418:2400:5000::26) 180.985 ms 184.048 ms 181.308 ms 11 2607:f128:a:4::2 (2607:f128:a:4::2) 211.863 ms 213.431 ms 213.422 ms 12 2607:f128:a1::a (2607:f128:a1::a) 208.275 ms 207.275 ms 209.897 ms 13 2607:f128:a1::9 (2607:f128:a1::9) 204.134 ms 201.841 ms 205.004 ms 14 2607:f740:f::f84 (2607:f740:f::f84) 218.552 ms 217.434 ms 217.519 ms