仙石浩明の日記

2011年7月24日

フレッツ 光ネクストの IPv6 IPoE 接続 (ネイティブ方式) を使ってみた

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 に切り替わっているため。

Filed under: IPv6,システム構築・運用 — hiroaki_sengoku @ 18:33

4件のコメント »

  1. 国内の15msの差は不明ですが、国際区間で遅延が大きめなのは、OCNから fremont.gcd.org への帰りのパケットが香港経由になってるためと思われます。「IPv4のオマケ的な位置づけ」ということはないと思いますが、実際IPv6は国際区間の接続性がIPv4ほど密ではないため、品質に差が出てしまう場面はあるということでしょうか。(一方、he.net の位置づけがIPv4ネットワークとIPv6ネットワークで少し違っているという理由もありますが)

    コメント by clicklog — 2011年7月25日 @ 00:19

  2. OCN から SINET 方面へも日本海を往復してますね。
    ntp.nict.jp が v6 だと遠いんですよ。

    で、二年半近く前ですが、v4 みたいに国内でつながんないの? とサポートに素朴な疑問を投げてみた事はありますが、返事は
    >ご指摘の状況ですが、通信に対する一般的な見解と致しまして、
    >60~100ms程の応答時間であれば、通常の通信の許容範囲として
    >認識されるものかと存じます。
    という事でした。この遅延は今でも一緒です。

    まあ、一般的な見解としては理解できるんですが、NTP なんだしさぁ、OCN が IPv6 の NTP サーバ用意してくれてるわけじゃないのに、とこれを読んで思ったものです。ちなみに当時 IPv6 は月 4200 円の有料オプションでした。

    コメント by akihiko — 2011年8月16日 @ 21:38

  3. fremont.gcd.org と senri.gcd.org 間のIPv6の遅延は改善されたんじゃないかと思いますがいかがでしょうか。

    コメント by clicklog — 2011年8月24日 @ 05:12

  4. 御存じとは思いますが、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網内で 時刻校正できます。

    コメント by 通りがかり — 2013年6月13日 @ 19:18

この投稿へのコメントの RSS フィード。

コメントする