IPv6 閉域網であることを今までさんざん dis られてきたフレッツ網 (NGN, 次世代ネットワーク) が、 ついに 7月21日からインターネットに接続できるようになった。 これでもう 「NGN と IPv6 インターネットは併用できない」 などとは言わせない。 私は IPv6 を既に PPPoE 接続で使っているのだが、 トンネル方式 (PPPoE) よりネイティブ方式 (IPoE) のほうがいいにきまってる、 ということでさっそく申し込んでみた。
NGN のサービス情報サイト (NGN からでないとアクセスできない) のページで 「サービス申込受付」 をクリック。 「お客様ID」 と 「アクセスキー」 を入力してログインすると、 「フレッツ・v6オプション」 を申し込むことができる (このページから申し込むと無料)。
申込み後、 NGN から流れてくる IPv6 ルータ広告 (RA, Router Advertisement) を tcpdump で監視していたら、 34分経過した頃にプレフィックスが突然変わった。 NGN の契約以来、 今まで一度も変わったことがなかったプレフィックス 2408:82:5fff:86a::/64 が、 2408:282:5fff::/64 になった。 これはきっとインターネットと通信できるプレフィックスに違いないと思って、 他のサイトから ping6 を打ってみた。 が、 NGN からは RA 以外は何も流れてこない。 うーん。 ちなみに RA の送信元 (NGN のエッジ・ルータ) は fe80::21e:13ff:fec2:69c2 のまま変わらず。
その後 1時間ほど放置してみたが何も状況が変化しなかったので、 「フレッツ・v6オプション」 って何? と思い直して (サービス内容をよく確認せずに申し込んでしまっていた)、 あらためて FAQ を見ると、
- Q
- 「フレッツ・v6オプション」を利用してインターネットへの接続はできますか？
- A
- 「フレッツ・v6オプション」 は、NTT東日本が構築するNGN内での通信が可能ですが、 「フレッツ・v6オプション」 のみではインターネットへの接続はできません。 インターネットへの接続には、 別途プロバイダサービスをお申し込みいただく必要があります。
インターネットへ接続するには、 フレッツ・v6オプションとプロバイダ契約の両方が必要らしい。 では、 どのプロバイダの、 どんなサービスを申し込めばいいんだろう? と思って、 フレッツ 光ネクスト IPv6 IPoE対応プロバイダを調べてみると、 神奈川県だと現時点で対応しているのは IIJmio だけだった (神奈川県だけでなく他県も同様)。 IIJ は今まで契約したことがなかったが、 他に選択肢が無いのであれば仕方がない。 さくっとクレジットカード番号を入力して IIJmio FiberAccess/NF を契約した (月額 2100円)。 これで半固定 IPv6 アドレスによる IPoE サービスと、 動的割当て IPv4 アドレスによる PPPoE サービスが利用できる。
Ether 上に IP を流すのはごくごく普通のことなので、 あらたまって 「IPoE」 (IP over Ether) と表現されると何だか妙な感じ。 「半固定」 というのも微妙な表現だが、 注意書きには 「お客様の移転、フレッツ回線の品目変更やNTTのメンテナンスにより、 変更になる場合があります」 と書いてあるので、 普通に使ってる限りプレフィックスが変わることは無さそう。
mio FiberAccess/NFサービスは、 インターネットマルチフィード株式会社が提供する 「transix (トランジックス)」 サービスを利用して、 NTT東西の 「インターネット（IPv6 IPoE）接続」 に対応したIPv6接続を提供します。 IPv6接続に加えて、 PPPoE接続方式によるIPv4接続もあわせて提供するため、 お客様は一つのサービスでIPv6、 IPv4の両方の接続環境を利用することができます。IIJmio FiberAccess/NF概要 から引用
IPv6 接続は全て transix が担っていて、 IIJmio はネットワーク的には何の役割も果たしていない。 IIJmio がやってるのは課金などユーザ管理関連だけ。 プロバイダである IIJmio が絡むから、 IPv4 接続も提供するなどという抱き合わせ商法になる。 動的割当の IPv4 PPPoE 接続サービスなんて要らないから、 もう少し安いプランがあればいいのにと思う。
本来、 ネイティブ方式の IPv6 接続サービスは、 NTT東西だけで提供するのが自然な形だった。 ところが、 NGN を持っていて地域独占な NTT東西が接続サービスまで提供してしまっては、 他のプロバイダの出る幕がなくなると猛反発されて、 BBIX, JPNE, インターネットマルチフィード の三社が接続サービスを提供することになった。 なぜ三社だけかといえば、 プロバイダを増やすと経路情報の処理量が膨大になって NGN の各ルータの処理能力の限界を超えてしまうから。
ところが、 三社だけでは少なすぎると他のプロバイダ達が反対したので、 その他大勢の中小プロバイダにも参入の余地を無理矢理作ったということなのだろう。 でも、 やってることは単なるユーザ管理なので、 通信事業者じゃなくてもできる簡単なお仕事。 この期に及んで業界保護みたいなことはやめてほしい。 インターネット接続サービスは既にコモディティ化しているのだから、 体力のないところは淘汰されるべき。
FiberAccess/NF を契約してから 1時間が経過したとき、 NGN から流れてくる RA のプレフィックスが 2409:82:5fff::/64 に変わった。 今度こそ疎通したかと思い、 senri.gcd.org に IPv6 アドレス 2409:82:5fff::3c20:55dc を割当てて、 他のサイトから 2409:82:5fff::3c20:55dc に対して ping6 を打ってみる。 すると無事、NGN IPoE 経由で senri.gcd.org に ICMPv6 パケットが届いた。
ただし、 まだ senri.gcd.org の routing 設定を行なっていないので、 返りパケットは PPPoE 経由で OCN 側へ行ってしまう (おそらく OCN 内部で捨てられる)。 そこで、 とりあえずの対策として NGN から届いたパケットは NGN へ返すように、 policy routing rule を設定した:
senri:/ # ip -6 rule add from 2409:82:5fff::/64 table 100 pref 25600 senri:/ # ip -6 route add default table 100 via fe80::21e:13ff:fec2:69c2 dev eth1
つまり、 送信元アドレスが 2409:82:5fff::/64 なパケットは routing table 100 を参照するようにして、 routing table 100 において default route を、 fe80::21e:13ff:fec2:69c2 (NGN のエッジ・ルータ) へ向ける。
これで ping に対して応答できるようになった。
fremont:~ $ ping6 -c 3 2409:82:5fff::3c20:55dc PING 2409:82:5fff::3c20:55dc(2409:82:5fff::3c20:55dc) 56 data bytes 64 bytes from 2409:82:5fff::3c20:55dc: icmp_seq=1 ttl=49 time=122 ms 64 bytes from 2409:82:5fff::3c20:55dc: icmp_seq=2 ttl=49 time=122 ms 64 bytes from 2409:82:5fff::3c20:55dc: icmp_seq=3 ttl=49 time=122 ms --- 2409:82:5fff::3c20:55dc ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2003ms rtt min/avg/max/mdev = 122.479/122.526/122.591/0.289 ms fremont:~ $ tcpspray 2409:82:5fff::3c20:55dc Transmitted 102400 bytes in 0.491628 seconds (203.406 kbytes/s)
RTT (Round Trip Time, 往復所要時間) が 122ms もかかってるのは、 fremont.gcd.org が米国の西海岸にあるため。 2400:400d:100::3c20:55dc (OCN の PPPoE 接続) 宛の場合↓ と比べると、 transix は RTT で 50ms ほど速く、 帯域 (tcpspray による簡易測定) で倍くらい広い。
fremont:~ $ ping6 -c 3 2400:400d:100::3c20:55dc PING 2400:400d:100::3c20:55dc(2400:400d:100::3c20:55dc) 56 data bytes 64 bytes from 2400:400d:100::3c20:55dc: icmp_seq=1 ttl=49 time=174 ms 64 bytes from 2400:400d:100::3c20:55dc: icmp_seq=2 ttl=49 time=174 ms 64 bytes from 2400:400d:100::3c20:55dc: icmp_seq=3 ttl=49 time=174 ms --- 2400:400d:100::3c20:55dc ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2002ms rtt min/avg/max/mdev = 174.046/174.386/174.593/0.539 ms fremont:~ $ tcpspray 2400:400d:100::3c20:55dc Transmitted 102400 bytes in 0.905523 seconds (110.433 kbytes/s)
参考までに IPv4 60.32.85.216 (OCN の PPPoE 接続) の場合も測ってみた。 すると RTT も帯域も transix と同程度だった。 つまり OCN の IPv6 PPPoE だけが突出して遅く、 帯域も狭い。
fremont:~ $ ping -c 3 60.32.85.216 PING 60.32.85.216 (60.32.85.216) 56(84) bytes of data. 64 bytes from 60.32.85.216: icmp_req=1 ttl=51 time=130 ms 64 bytes from 60.32.85.216: icmp_req=2 ttl=51 time=130 ms 64 bytes from 60.32.85.216: icmp_req=3 ttl=51 time=129 ms --- 60.32.85.216 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2002ms rtt min/avg/max/mdev = 129.377/129.903/130.202/0.559 ms fremont:~ $ tcpspray 60.32.85.216 Transmitted 102400 bytes in 0.518052 seconds (193.031 kbytes/s)
米国西海岸から transix までの IPv6 の経路はこんな感じ:
fremont:~ $ tracepath6 2409:82:5fff::3c20:55dc
1?: [LOCALHOST] 0.021ms pmtu 1500
1: 2600:3c01:ffff:0:ca4c:75ff:fef5:d63f 0.558ms
1: 2600:3c01:ffff:0:ca4c:75ff:fef5:d63f 0.480ms
2: 10gigabitethernet2-3.core1.fmt1.he.net 3.149ms
3: 10gigabitethernet1-2.core1.sjc2.he.net 11.042ms
4: equi6ix.sv.iij.com 1.834ms asymm 5
5: sjc002bf00.iij.net 9.384ms asymm 7
6: 2001:48b0:bb00:8016::71 120.588ms asymm 7
7: tky009bb11.IIJ.Net 120.730ms asymm 8
8: tky009ip50.IIJ.Net 121.048ms
9: 2001:240:bb5c:1008::cafe 120.365ms
10: 2404:8e00:feed:101::2 121.852ms
11: no reply
12: no reply
13: no reply
14: no reply
15: no reply
16: 2409:82:5fff::3c20:55dc 127.409ms reached
Resume: pmtu 1500 hops 16 back 49
「IIJmio はネットワーク的には何の役割も果たしていない」 が、 日米間の回線は IIJ が担っているようだ (あれっ? ^^;)。 日本に上陸後 (6 以降) はほとんど遅延していない。
OCN の PPPoE の場合だと、こんな感じ:
fremont:~ $ tracepath6 2400:400d:100::3c20:55dc
1?: [LOCALHOST] 0.047ms pmtu 1500
1: 2600:3c01:ffff:0:ca4c:75ff:fef5:d63f 3.935ms
1: 2600:3c01:ffff:0:ca4c:75ff:fef5:d63f 0.852ms
2: 10gigabitethernet2-3.core1.fmt1.he.net 7.978ms
3: 10gigabitethernet1-2.core1.sjc2.he.net 2.532ms
4: xe-0.equinix.snjsca04.us.bb.gin.ntt.net 2.018ms asymm 5
5: as-1.r21.osakjp01.jp.bb.gin.ntt.net 168.074ms asymm 11
6: ae-0.ocn.osakjp01.jp.bb.gin.ntt.net 167.792ms asymm 14
7: 2001:380:8060:6::1 159.446ms asymm 13
8: 2001:380:8170:4::1 167.630ms asymm 14
9: 2001:380:8030:16::1 168.401ms asymm 15
10: 2001:380:8110:d::1 170.344ms asymm 14
11: 2001:380:8110:f::2 178.503ms asymm 13
12: 2001:380:8130:11::13 178.131ms asymm 13
13: 2001:380:8270:8::2 172.448ms
14: 2001:380:4d:101::2 179.036ms
15: 2001:380:4d:182::2 181.317ms
16: no reply
17: 2001:380:4d:181::2 173.127ms pmtu 1454
17: senri.v6.gcd.org 183.023ms reached
Resume: pmtu 1454 hops 17 back 49
日米間に 160ms もかかっている上に、 日本に上陸後 (5 以降) も 15ms ほど遅延がある。 なぜこんなに遅いのだろう? また、PPPoE なので mtu が 1454 になっている。
同じ OCN の PPPoE でも、 IPv4 だと遅くない (というか transix より若干速い) ので、 OCN の IPv6 PPPoE 接続サービスには、 なにか問題がありそう。 まあ、 追加料金無しのサービスなので、 IPv4 のオマケ的な位置づけなのかも?
fremont:~ $ tracepath 60.32.85.216
1: fremont.gcd.org 0.169ms pmtu 1500
1: 184.105.143.85 1.702ms
1: 184.105.143.85 0.418ms
2: 10gigabitethernet2-3.core1.fmt1.he.net 0.665ms
3: 10gigabitethernet1-1.core1.pao1.he.net 8.907ms
4: sjo-bb1-link.telia.net 1.297ms asymm 5
5: verio-119529-sjo-bb1.telia.net 4.568ms
6: ae-8.r20.snjsca04.us.bb.gin.ntt.net 1.922ms
7: as-2.r20.tokyjp01.jp.bb.gin.ntt.net 112.093ms asymm 8
8: ae-1.ocn.tokyjp01.jp.bb.gin.ntt.net 119.692ms asymm 11
9: 60.37.27.137 120.641ms asymm 10
10: 60.37.55.158 119.549ms asymm 11
11: 122.1.173.238 121.243ms
12: 118.23.5.78 128.853ms asymm 14
13: no reply
14: 118.23.8.9 128.712ms pmtu 1454
14: gcd.org 123.788ms reached
Resume: pmtu 1454 hops 14 back 52
7月26日追記:
西海岸から ping6 を打つのは 2階から目薬もびっくりなので、 国内の IPv6 が使える VPS を急遽契約して (2ヵ月無料キャンペーン)、 ping6 を打ってみた。
chiyoda:~ $ ping6 -c 3 senri PING senri(2409:82:5fff::3c20:55dc) 56 data bytes 64 bytes from 2409:82:5fff::3c20:55dc: icmp_seq=1 ttl=49 time=6.96 ms 64 bytes from 2409:82:5fff::3c20:55dc: icmp_seq=2 ttl=49 time=6.72 ms 64 bytes from 2409:82:5fff::3c20:55dc: icmp_seq=3 ttl=49 time=6.51 ms --- senri ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2001ms rtt min/avg/max/mdev = 6.515/6.734/6.969/0.208 ms chiyoda:~ $ tcpspray -n 10000 2409:82:5fff::3c20:55dc Transmitted 10240000 bytes in 0.864344 seconds (11569.468 kbytes/s)
さすがに国内からだと速くて広い。 93Mbps 出れば普通の用途には充分。 OCN PPPoE の IPv6 および IPv4 でも測ってみたが、 有意な差は見られない:
chiyoda:~ $ ping6 -c 3 2400:400d:100::3c20:55dc PING 2400:400d:100::3c20:55dc(2400:400d:100::3c20:55dc) 56 data bytes 64 bytes from 2400:400d:100::3c20:55dc: icmp_seq=1 ttl=54 time=8.84 ms 64 bytes from 2400:400d:100::3c20:55dc: icmp_seq=2 ttl=54 time=6.58 ms 64 bytes from 2400:400d:100::3c20:55dc: icmp_seq=3 ttl=54 time=6.46 ms --- 2400:400d:100::3c20:55dc ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2001ms rtt min/avg/max/mdev = 6.465/7.298/8.843/1.097 ms chiyoda:~ $ tcpspray -n 10000 2400:400d:100::3c20:55dc Transmitted 10240000 bytes in 0.844327 seconds (11843.752 kbytes/s) chiyoda:~ $ ping -c 3 60.32.85.216 PING 60.32.85.216 (60.32.85.216) 56(84) bytes of data. 64 bytes from 60.32.85.216: icmp_req=1 ttl=53 time=6.62 ms 64 bytes from 60.32.85.216: icmp_req=2 ttl=53 time=6.64 ms 64 bytes from 60.32.85.216: icmp_req=3 ttl=53 time=6.95 ms --- 60.32.85.216 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 1999ms rtt min/avg/max/mdev = 6.623/6.740/6.955/0.152 ms chiyoda:~ $ tcpspray -n 10000 60.32.85.216 Transmitted 10240000 bytes in 0.842140 seconds (11874.510 kbytes/s)
経路は、 それぞれ以下のような感じ:
transix IPv6 IPoE:
chiyoda:~ $ tracepath6 2409:82:5fff::3c20:55dc
1?: [LOCALHOST] 0.016ms pmtu 1500
1: 2001:2e8:634:0:2:2:0:1 0.054ms
1: 2001:2e8:634:0:2:2:0:1 0.038ms
2: 2001:2e8:22:202::2 1.192ms asymm 4
3: 2001:2e8:20::22:11 1.466ms asymm 5
4: 2001:7fa:7:1::2497:1 53.299ms asymm 6
5: tky008bf01.IIJ.Net 3.417ms asymm 6
6: tky009bb10.IIJ.Net 2.622ms asymm 8
7: tky009ip50.IIJ.Net 2.763ms asymm 8
8: 2001:240:bb5c:1008::cafe 3.188ms asymm 9
9: 2404:8e00:feed:101::2 3.911ms asymm 10
10: no reply
11: no reply
12: no reply
13: no reply
14: no reply
15: 2409:82:5fff::3c20:55dc 8.107ms reached
Resume: pmtu 1500 hops 15 back 49
OCN IPv6 PPPoE:
chiyoda:~ $ tracepath6 2400:400d:100::3c20:55dc
1?: [LOCALHOST] 0.019ms pmtu 1500
1: 2001:2e8:634:0:2:2:0:1 0.058ms
1: 2001:2e8:634:0:2:2:0:1 0.037ms
2: 2001:2e8:22:202::2 2.505ms asymm 4
3: 2001:2e8:20::22:11 2.464ms asymm 5
4: 2001:380:0:2516::1 3.111ms asymm 6
5: 2001:380:8280:f::1 19.584ms asymm 7
6: 2001:380:8150:f::12 3.486ms asymm 8
7: 2001:380:8270:7::2 5.817ms asymm 8
8: 2001:380:4d:100::2 4.504ms asymm 9
9: 2001:380:4d:181::2 14.276ms asymm 10
10: no reply
11: 2001:380:4d:181::2 7.015ms pmtu 1454
11: senri.v6.gcd.org 7.457ms reached
Resume: pmtu 1454 hops 11 back 54
OCN IPv4 PPPoE:
chiyoda:~ $ tracepath 60.32.85.216
1: v-183-181-54-38.ub-freebit.net 0.117ms pmtu 1500
1: v-183-181-55-247.ub-freebit.net 0.040ms
1: v-183-181-55-247.ub-freebit.net 0.022ms
2: 202.216.248.129 0.515ms asymm 3
3: no reply
4: oi-gate-1.otemachi4.dti.ad.jp 1.899ms asymm 6
5: 122.28.177.109 2.830ms asymm 7
6: 118.23.146.121 8.064ms asymm 8
7: 118.23.168.8 3.123ms asymm 9
8: 60.37.55.154 5.095ms asymm 9
9: 122.1.173.238 4.176ms asymm 10
10: 118.23.5.74 5.482ms asymm 12
11: no reply
12: 118.23.8.9 5.328ms pmtu 1454
12: gcd.org 7.036ms reached
Resume: pmtu 1454 hops 12 back 53
「国際区間で遅延が大きめなのは、 OCNから fremont.gcd.org への帰りのパケットが香港経由になってるため」 というコメントを頂いたので、 返りの経路も調べてみた。 確かに、 hkix.net 経由になっていて、 東京-香港間に 50ms ほどかかっている:
senri:/ # traceroute6 -s 2400:400d:100::3c20:55dc fremont.gcd.org traceroute to fremont.gcd.org (2600:3c01::f03c:91ff:fe96:f285) from 2400:400d:100::3c20:55dc, 30 hops max, 24 byte packets 1 2001:380:4d:1ff::3 (2001:380:4d:1ff::3) 4.876 ms 3.907 ms 4.369 ms 2 2001:380:4d:181::1 (2001:380:4d:181::1) 3.104 ms 2.888 ms 3.556 ms 3 2001:380:4d:100::1 (2001:380:4d:100::1) 5.911 ms 6.002 ms 5.581 ms 4 2001:380:8270:7::1 (2001:380:8270:7::1) 4.072 ms 4.156 ms 3.969 ms 5 2001:380:8150:f::18 (2001:380:8150:f::18) 4.622 ms 4.689 ms 4.584 ms 6 ae-5.r20.tokyjp01.jp.bb.gin.ntt.net (2001:218:0:5000::d) 4.54 ms 4.172 ms 4.577 ms 7 ae-2.r25.tokyjp01.jp.bb.gin.ntt.net (2001:218:0:2000::1c6) 5.063 ms 4.27 ms 4.511 ms 8 as-3.r21.newthk02.hk.bb.gin.ntt.net (2001:218:0:2000::13e) 56.208 ms 56.149 ms 55.959 ms 9 xe-2-1.r01.newthk01.hk.bb.gin.ntt.net (2001:218:0:2000::159) 101.451 ms 57.473 ms 57.487 ms 10 ae-3.a02.newthk01.hk.ra.gin.ntt.net (2001:218:0:6000::156) 56.489 ms 56.368 ms 107.274 ms 11 hurricaneelectric-RGE.hkix.net (2001:7fa:0:1::ca28:a19e) 57.228 ms 57.492 ms 57.619 ms 12 gige-g3-7.core1.lax1.he.net (2001:470:0:16b::1) 174.14 ms 173.967 ms 174.26 ms 13 10gigabitethernet7-4.core1.fmt2.he.net (2001:470:0:18d::1) 180.178 ms 188.238 ms 181.149 ms 14 gige-g4-18.core1.fmt1.he.net (2001:470:0:2d::1) 173.357 ms 173.099 ms 173.85 ms 15 2001:470:1:1db::2 (2001:470:1:1db::2) 173.973 ms 173.424 ms 178.249 ms 16 2600:3c01::f03c:91ff:fe96:f285 (2600:3c01::f03c:91ff:fe96:f285) 174.287 ms 174.162 ms 174.175 ms
8月24日追記:
「fremont.gcd.org と senri.gcd.org 間のIPv6の遅延は改善されたんじゃないか」 というコメントを頂いたので、 再度調べてみた:
senri:/ # traceroute6 -s 2400:400d:100::3c20:55dc fremont.gcd.org traceroute to fremont.gcd.org (2600:3c01::f03c:91ff:fe96:f285) from 2400:400d:100::3c20:55dc, 30 hops max, 24 byte packets 1 asao.v6.gcd.org (2400:400d:100::3c20:55dd) 0.239 ms 0.152 ms 0.14 ms 2 2001:380:4d:1ff::3 (2001:380:4d:1ff::3) 4.61 ms 4.696 ms 3.957 ms 3 2001:380:4d:181::1 (2001:380:4d:181::1) 3.445 ms 3.73 ms 3.347 ms 4 2001:380:4d:100::1 (2001:380:4d:100::1) 5.994 ms 5.893 ms 5.813 ms 5 2001:380:8270:7::1 (2001:380:8270:7::1) 3.727 ms 3.58 ms 3.82 ms 6 2001:380:8150:f::18 (2001:380:8150:f::18) 4.51 ms 4.119 ms 4.769 ms 7 ae-5.r20.tokyjp01.jp.bb.gin.ntt.net (2001:218:0:5000::d) 4.353 ms 4.446 ms 4.526 ms 8 ae-3.r20.osakjp01.jp.bb.gin.ntt.net (2001:218:0:2000::da) 14.744 ms 14.429 ms 14.338 ms 9 as-2.r20.snjsca04.us.bb.gin.ntt.net (2001:218:0:2000::7d) 122.714 ms 122.792 ms 122.84 ms 10 ae-0.r21.snjsca04.us.bb.gin.ntt.net (2001:418:0:2000::66) 130.233 ms 130.342 ms 176.712 ms 11 10gigabitethernet2-3.core1.sjc2.he.net (2001:504:0:1::6939:1) 132.712 ms 122.997 ms 122.804 ms 12 10gigabitethernet1-1.core1.fmt1.he.net (2001:470:0:2f::1) 132.042 ms 141.087 ms 132.982 ms 13 2001:470:1:1db::2 (2001:470:1:1db::2) 124.032 ms 124.21 ms 124.141 ms 14 2600:3c01::f03c:91ff:fe96:f285 (2600:3c01::f03c:91ff:fe96:f285) 125.249 ms 124.642 ms 125.253 ms
確かに、 ntt.net から直接 he.net へ行く経路に変わっていて、 香港に迂回していた時と比べ、 50ms ほど速くなっている。 1hop目が asao になっているのは、 asao と senri で冗長構成になっていて、 前回は senri が master だったが現在は asao が master に切り替わっているため。
国内の15msの差は不明ですが、国際区間で遅延が大きめなのは、OCNから fremont.gcd.org への帰りのパケットが香港経由になってるためと思われます。「IPv4のオマケ的な位置づけ」ということはないと思いますが、実際IPv6は国際区間の接続性がIPv4ほど密ではないため、品質に差が出てしまう場面はあるということでしょうか。(一方、he.net の位置づけがIPv4ネットワークとIPv6ネットワークで少し違っているという理由もありますが)
Comment by clicklog — 2011年7月25日 @ 00:19
OCN から SINET 方面へも日本海を往復してますね。
ntp.nict.jp が v6 だと遠いんですよ。
で、二年半近く前ですが、v4 みたいに国内でつながんないの? とサポートに素朴な疑問を投げてみた事はありますが、返事は
>ご指摘の状況ですが、通信に対する一般的な見解と致しまして、
>60～100ms程の応答時間であれば、通常の通信の許容範囲として
>認識されるものかと存じます。
という事でした。この遅延は今でも一緒です。
まあ、一般的な見解としては理解できるんですが、NTP なんだしさぁ、OCN が IPv6 の NTP サーバ用意してくれてるわけじゃないのに、とこれを読んで思ったものです。ちなみに当時 IPv6 は月 4200 円の有料オプションでした。
Comment by akihiko — 2011年8月16日 @ 21:38
fremont.gcd.org と senri.gcd.org 間のIPv6の遅延は改善されたんじゃないかと思いますがいかがでしょうか。
Comment by clicklog — 2011年8月24日 @ 05:12
御存じとは思いますが、NGN網内に、sntpサーバーがあります。
手元の yamaha NVR500でみると、
D> show status ipv6 dhcp
DHCPv6 status
LAN1 [server]
LAN2 [client]
state: established
server:
DNS server[1]: 2001:a7ff:5f01::a
DNS server[2]: 2001:a7ff:5f01:1::a
Domain name[1]: flets-west.jp
Domain name[2]: iptvf.jp
SNTP server[1]: 2001:a7ff:102::a
SNTP server[2]: 2001:a7ff:102::b
SNTP server[3]: 2001:a7ff:102::c
という具合で、
dns static AAAA ngn-sntp 2001:a7ff:102::b
schedule at 1 */* 04:10 * ntpdate ngn-sntp syslog
ってな感じで、NGN網内で 時刻校正できます。
Comment by 通りがかり — 2013年6月13日 @ 19:18