7
09
2017
IPv6ネットワーク環境をテスト中
自宅回線をIPv6(IPoE)対応してみた
先日、とは言っても既に5ヶ月も前の事になるが、自宅のインターネット回線をCATV回線（グローバルIP 1個 DHCP付与）から建物に既設のLANインターネット回線（WAKWAK BB-East）に切り替えた．以前のWAKWAK BB-EastサービスはグローバルIP 1個がDHCPで振り出されるタイプで、値段（2,000円弱でアクセス回線とプロバイダ機能が込み込み）の割にはまともなサービスだったのだが、WAKWAK BB-Eastサービスの足回りが、昨年の12月からNTT東日本のフレッツ網とNTTComのOCNサービスに変更になってしまった．WAKWAKを運営するNTT-Meさん自身もインターネットサービスプロバイダの筈だが．．．
これに伴いユーザに振り出されるIPアドレスがプライベートIPに変更になり、IPSecなどのVPN接続に支障がでるようになってしまった．グローバルIPからプライベートIPへの変更だけで有れば、外部のグローバルIPサーバとSSHトンネルを張るなどの方法で制約を回避することも可能なのだが、FLETS 網の網終端装置の糞詰まりとOCNの品質の悪さから、夜間の混雑時間帯の通信品質の劣化に耐えられなくなってしまった．
そこで巷で話題のIPoE方式によるインターネットアクセスを試みることにした．IPoEによるIPv6ネイティブ接続については、IIJのテクログ http://techlog.iij.ad.jp で色々と紹介されているので、技術的な内容についてはそちらを参考にすると良いだろう．
・『IIJmioひかりの混雑の理由とバイパス手段(IPoE・DS-Lite対応)』
・『【試してみた】IPv6「ネイティブ接続」』
・『DS-LiteでIPv4してみませんか？』
今回自宅にテスト導入したのは、NTT東日本のフレッツ光ネクスト（マンションタイプ VDSL配線方式）アクセス回線とIPoE（DS-Lite方式）対応のインターネットサービスプロバイダとしてインターリンクの ZOOT Native だ．数あるインターネットサービスプロバイダの中からインターリンクを選んだのは2ヶ月間の無料お試し期間が有るからだ．インターリンクには ZOOT NEXTというPPPoE 方式の固定IPサービスも安価で提供されている．一般的な素人には殆ど無縁のプロバイダだが、インターネットサービスプロバイダとして実績のある確かなプロバイダだろう．
IPoE（DS-Lite方式）対応のルータを用意する
今回、自宅のインターネット環境をIPv6対応にするために検討しなければならなかった項目は幾つかあるが、最大の問題は所有しているルータがIPoE（DS-Lite方式）に対応可能かどうかどうかだった．インターリンクのホームページにはインターリンクが動作確認した代表的なホームルータ数機種についての設定マニュアルが載っているので、これらのルータであれば専門知識が無くても何とかなるだろう．勿論、此処に載っているルータ以外でも、最近の小規模サイト用の高機能ルータは対応可能な物が多いので、挑戦してみては如何だろう．
今回の私のテスト環境としては、「ZOOT NATIVE」と「ZOOT NEXT」の同時接続環境を構築を試してみることにした．インターリンクのホームページの図では、
「ZOOT NATIVE」と「ZOOT NEXT」の同時接続のイメージ図
（インターリンクのZOOT NATIVEの説明図より引用）
が分かり易いだろう．この図を見る限りインターリンクさんは何処？と言う感じがしないでもないが、DS-Lite方式によるインターネット接続を提供しているのは、『ZOOT NATIVE上位組織』と記されている機関（IIJの子会社のインターネットマルチフィードが運営するtransixサービス)なのでこの図の通りなのだ．
さて、今回のIPv6テスト環境構築のために新たなルータを調達しようかと思い、導入実績の多いYAMAHAのRTX1210（実売価格7〜8万円前後）の新規調達を検討したが、手持ちのYAMAHA RTX1100でも問題無く動くという情報もあるので、とりあえず最初はRTX1100でテストするつもりでいた．VDSLモデムなので100MbpsポートしかないRTX1100でも何の問題もない筈だが、NECのIX2215というRTX1210とほぼ同じクラスのSOHO用ルータを中古で2万円程で手に入れることができたので、今後のGigabit光回線直収を睨んでIX2215でテストすることにした．
IX2215はまだ現役バリバリの機種なので、ファームウェアなどの更新もそれなりにきちんと受けられる筈だ．それなりと断ったのは、正規の販売店経由の購入で保守契約等が結ばれていればの話で、Ciscoなどでも同じ事だが中古などの場合は、ファームウェア等のアップデートを行おうとするとそれなりの苦労が待ち受けている．エンタープライズ系のネットワーク業界とコネがあれば裏ルートで入手することもできるだろうが、ごく普通の一般人にとっては中々難しいだろう．
その点、YAMAHAのルータで有ればメーカのホームページから誰でも最新ファームウェアをダウンロード可能なので、中古を入手するならYAMAHAのルータが無難だろう．CiscoやJuniper、NECなどよりかはYAMAHAの方がインターネット等で情報を拾い易いだろう．ルータのようなセキュリティー的にシビアな装置は保守契約が有ろうが無かろうが、メーカーとしてきちんとセキュリティーパッチを提供し続けるのが義務だろう．NECさんもYAMAHAを見習って欲しいところだ．
ルータの設定を行う前に、お約束の中身チェックから．
IX2215の外観（コンソールポートはCisco互換のRJ-45タイプでOK）
蓋を開けて中身を確認（中はコーセルのSW電源 [+5V 5A] とメインボード1枚だけ）
メイン基板はカスタムASICやFPGAなどでコンパクトに実装されている
IX2215の設定中に大問題発生
今回は、ZOOT NATIVEによる IPv6ネイティブ方式の接続と、ZOOT NEXTによる PPPoE方式によるIPv4接続（固定グローバルIP 1個）を、このIX2215ルータ1台だけで何とか稼働させてみることにする．
先ずは、NECのホームページに『DS-Lite 設定ガイド』が載っているので、この設定例を参考に設定する．この例を参考に、内側のインタフェースとして GigaEthernet1.0 ポートに 192.168.200.254/24 を割り当て、DHCPでクライアントPC側にIPv4アドレスを振り出し、この内側ルータIP 192.168.200.254 をDNS Proxyサーバに設定する．勿論、別立てのDNSサーバが内部に有る場合はそのDNSサーバのIPアドレスを渡せば良い．
GigaEthernet1.0 ポートに届いたIPv4パケットを Tunnel0.0 インタフェースを使ってIPv6に包んで相手側の”gw.transix.jp” に送り届け、そこで IPv4 パケットに戻されて、インターネット側へ出て行くだけのシンプルな設定だ．勿論IPv6のパケットであればTunnel0.0を経由せずにそのまま直接IPv6インターネット側へ出て行くことになる．
設定は以下の様になるだろう．．．
ip route default Tunnel0.0
ip ufs-cache enable
ip dhcp enable
!
proxy-dns ip enable request both
!
ip dhcp profile dhcpv4-sv
dns-server 192.168.200.254 ⇒【又は自前のDNS(IPv4）サーバを指定】
!
ipv6 dhcp client-profile dhcpv6-cl
information-request
option-request dns-servers
!
interface GigaEthernet0.0
ipv6 address autoconfig receive-default
ipv6 dhcp client dhcpv6-cl
no shutdown
!
interface GigaEthernet1.0
ip address 192.168.200.254/24
ip dhcp binding dhcpv4-sv
no shutdown
!
interface Tunnel0.0
tunnel mode 4-over-6
no tunnel adjust-mtu
tunnel source GigaEthernet0.0
tunnel destination fqdn gw.transix.jp ⇒【 上位IXの"gw.transix.jp" をFQDNで指定 】
⇒ tunnel destination 2404:8e00::feed:101 【 FQDNでつながらないのでIP直打ちに変更 】
ip unnumbered GigaEthernet1.0
ip tcp adjust-mss 1460
no shutdown
．．．がしかし、幾つかの設定コマンドの入力でエラーとなり設定できない！！！
y2home-ix2015(config)# proxy-dns ip enable request both
% request -- Invalid command.
y2home-ix2015(config)#
y2home-ix2015(config)# proxy-dns ip enable ?
compatibility -- Refer to DNS cache in Proxy DNS
-- Enter carriage return
y2home-ix2015(config)# proxy-dns ip enable
“proxy-dns ip enable request both” がエラーとなってしまう．”proxy-dns ip enable” の後は “compatibility” しかパラメータを設定出来ない．？？？ IX2215のバージョンを確認すると、
y2home-ix2015(config)# show version
NEC Portable Internetwork Core Operating System Software
IX Series IX2215 (magellan-sec) Software, Version 8.9.17B, MAINTENANCE RELEASE SOFTWARE
Compiled May 17-Fri-2013 16:03:05 JST #2 by sw-build, coregen-8.9(17)
ROM: System Bootstrap, Version 2.1
System Diagnostic, Version 2.1
Initialization Program, Version 2.1
System uptime is 4 hours 13 minutes
System woke up by reload, caused by command execution
System started at Jul 09-Sun-2017 14:26:56 JST
System image file is "ix2215-ms-8.9.17.b.ldc"
Processor board ID <0>
IX2215 (P1010E) processor with 262144K bytes of memory.
3 GigaEthernet/IEEE 802.3 interfaces
1 ISDN Basic Rate interface
1 USB interface
1024K bytes of non-volatile configuration memory.
32768K bytes of processor board System flash (Read/Write)
Current configuration is based on "startup-configuration"
y2home-ix2015(config)#
ファームウェアのバージョンは V8.9.17のようだ．因みに現在の最新バージョンは脆弱性情報『IX2000/IX3000シリーズ 「OpenSSLに複数の脆弱性（JVNVU#98667810）」に関する御報告』を見る限り、少なくとも V9.4.17以降ということのようだ．公開されている各種マニュアルのバージョンがV9.5になっているので、要するに、ファームウェアが古すぎて新しい機能が実装されていないということだろう．最新ファームウェアを何処かから調達しなければならない．うーん困った．．．
という訳で、今回は IX2215に関しては、ZOOT NATIVE (DS-Lite)を諦めて、ZOOT NEXT IPv4 固定IPで使うことにする．IPv4の固定IP1個(PPPoE)を通常のIPv4ルーティングに設定し、IPv6はブリッジ接続で内側のインタフェースと直結させる．ブリッジにはIPv4を通さない設定にしておく．IPv6アドレスはZOOT NATIVEの契約があるので、プロバイダからIPv6グローバルアドレスが振り出されることになる．
この場合の設定例が、NECのホームページ 『フレッツ 光ネクスト向け 設定ガイド（IPv6ブリッジ）』で紹介されている．設定としてはこんな物だろうか．．．
access-list mflt-list permit src any dest any type ipv6
access-list mflt-list permit src any dest any type ip
ppp profile internet
authentication myname abcdefg@hijk.lmn.net 【 プロバイダから渡された PPPoEのID 】
authentication password abcdefg@hijk.lmn.net xxxxxxxx
!
ip ufs-cache enable
ip route default GigaEthernet0.1
interface GigaEthernet0.0
filter mflt-list 1 in
no ip address
bridge-group 1
no shutdown
!
interface GigaEthernet1.0
filter mflt-list 1 in
ip address 192.168.200.254/24
bridge-group 1
no shutdown
!
interface GigaEthernet2.0
no ip address
shutdown
!
interface GigaEthernet0.1
encapsulation pppoe
auto-connect
ppp binding internet
ip address 117.xxx.yyy.zzz/32
ip tcp adjust-mss auto
ip napt enable
no shutdown
!
上記の設定ではIPv4通信は固定グローバルIP(PPPoE)のNAPTで行われることになる. IPv6に関してはIX2215は内側の”GigaEthernet1.0″ と外側の”interface GigaEthernet0.0″ とがブリッジ接続されているので、プロバイダ側のルータから通知されたIPv6アドレスが内側のネットワークに届くことになる．内側のネットワークからIPv6通信が行えるのだが、IPv6はインターネット側から丸見えになってしまうので、IX2215側でIPv6フィルタリング設定を行うか、間にIPv6対応ファイアウォールを入れる必要がある.
IPoE(DS-Lite)をYAMAHA RTX1100に設定
とりあえず、IPoE(DS-Lite)方式を現有の YAMAHA RTX1100に設定してみることにする．RTX1200での設定例が、インターリンクのホームページ https://faq.interlink.or.jp/faq2/View/wcDisplayContent.aspx?id=220に有るので、それを参考に設定すれば難しいことはないだろう．尤も、RTX1100のGUI設定画面では細かな設定はできそうもないので、コマンドラインで設定するのが確実かつ無難な方法だ．ネットワーク屋さんは今も昔も皆コマンドラインだ．GUIを当てにするようではネットワーク屋さん失格だ！！！
ip route default gateway tunnel 1
ipv6 prefix 1 ra-prefix@lan2::/64
ipv6 lan1 address ra-prefix@lan2::1/64
ipv6 lan1 rtadv send 1 o_flag=on
ipv6 lan1 dhcp service server
ipv6 lan2 dhcp service client ir=on
tunnel select 1
tunnel encapsulation ipip
tunnel endpoint address 2404:8e00::feed:100 ⇒【 YAMAHAのルータ場合はFQDNアドレスが使えないので、IP直打ち 】
tunnel enable 1
上記の設定は、IPoE(DS-Lite)を行うための追加設定部分だけで、通常のIPv4関連の設定やACL、staticルーティング等の情報は含まれていない．私のRTX1100のコンフィグ情報はVPN関連の設定などが含まれているので、今回は関係のある極一部だけしか記載していない．
YAMAHA RTX1100 のLAN側のIPは 192.168.100.254(VLAN100）に設定されており、今回のテスト環境では IPv6(DS-Lite方式）でのインターネットアクセスが RTX1100側から、IPv4（グローバル固定IP）接続が IX2215 の 192.168.200.254(VLAN200) 側から接続されている．変則的なマルチホーム環境なのだが、PPPoE環境とDS-Lite環境の両方を比較テストできるので都合が良い．IX2215側のファームウェア更新が成されてIX2215の1台体制になったら、ポリシールーティングなどの設定を行い、用途に応じて IPv4固定IPとIPv6(DS-Lite）を使い分ける想定だ．
【蛇足】RTX1100でもGUIベースでIPoEを設定できるかも？
NTT東日本のフレッツ用VDSLモデムとNEC IX2215ルータ
今回はRTX1100をIPv6(DS-Lite方式）用の暫定用ルータとして借用
![IPv6 Test [ http://ipv6-test.com/ ]](https://y2tech.net/blog/wp-content/uploads/2017/07/IPv6Test.png)
IPv6 Test サイトで接続を確認 [ http://ipv6-test.com/ ]
Alaska(U.S.A.）にあるサイトでも20Mbps台をたたいている [ 7/09（日）夜10時台(JST) ]
ついでにこのサイトのIPv6適合度もチェック
このサイトのDNS情報はさくらインターネットのDNSサーバ（ns1.dns.ne.jp, Ns2.dns.ne.jp）でホスティングされているのだけど、どうもこのDNSサーバ自体はIPv6での問い合わせには対応していないようだ． まあ、IPv6環境しか使えないユーザはこのサイトのDNS情報は引けないということになるが、現時点でそのようなユーザが居るとも思えないので今のところ問題はないと言えるのだが、やはりすっきりしないので、何とかIPv6環境でまともにDNSが引けるようにしなければ．．．
iMac27:~ yasuaki$ dig y2tech.net NS
; <<>> DiG 9.8.3-P1 <<>> y2tech.net NS
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 27773
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; QUESTION SECTION:
;y2tech.net. IN NS
;; ANSWER SECTION:
y2web.net. 3599 IN NS ns1.dns.ne.jp.
y2web.net. 3599 IN NS ns2.dns.ne.jp.
;; ADDITIONAL SECTION:
ns1.dns.ne.jp. 378 IN A 61.211.236.1
;; Query time: 125 msec
;; SERVER: 192.168.100.1#53(192.168.100.1)
;; WHEN: Sun Jul 9 23:23:12 2017
;; MSG SIZE rcvd: 88
----
iMac27:~ yasuaki$ dig ns1.dns.ne.jp AAAA
; <<>> DiG 9.8.3-P1 <<>> ns1.dns.ne.jp AAAA
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46717
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;ns1.dns.ne.jp. IN AAAA
;; AUTHORITY SECTION:
dns.ne.jp. 601 IN SOA dns.sakura.ad.jp. dns.sakura.ad.jp. 2017070301 900 300 3600000 3600
;; Query time: 77 msec
;; SERVER: 192.168.100.1#53(192.168.100.1)
;; WHEN: Sun Jul 9 23:18:37 2017
;; MSG SIZE rcvd: 81
----
iMac27:~ yasuaki$ dig y2tech.net AAAA
; <<>> DiG 9.8.3-P1 <<>> y2tech.net AAAA
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17653
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 1
;; QUESTION SECTION:
;y2tech.net. IN AAAA
;; ANSWER SECTION:
y2web.net. 3297 IN AAAA 2001:e42:102:1816:160:16:228:218
;; AUTHORITY SECTION:
y2web.net. 3507 IN NS ns1.dns.ne.jp.
y2web.net. 3507 IN NS ns2.dns.ne.jp.
;; ADDITIONAL SECTION:
ns1.dns.ne.jp. 286 IN A 61.211.236.1
;; Query time: 0 msec
;; SERVER: 192.168.100.1#53(192.168.100.1)
;; WHEN: Sun Jul 9 23:24:44 2017
;; MSG SIZE rcvd: 116
----
iMac27:~ yasuaki$ dig ns1.dns.ne.jp NS -6
; <<>> DiG 9.8.3-P1 <<>> ns1.dns.ne.jp NS -6
;; global options: +cmd
;; connection timed out; no servers could be reached
----
iMac27:~ yasuaki$ dig ns1.dns.ne.jp NS -4
; <<>> DiG 9.8.3-P1 <<>> ns1.dns.ne.jp NS -4
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5569
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;ns1.dns.ne.jp. IN NS
;; AUTHORITY SECTION:
dns.ne.jp. 565 IN SOA dns.sakura.ad.jp. dns.sakura.ad.jp. 2017070301 900 300 3600000 3600
;; Query time: 1 msec
;; SERVER: 192.168.100.1#53(192.168.100.1)
;; WHEN: Mon Jul 10 21:31:07 2017
;; MSG SIZE rcvd: 81
----
iMac27:~ yasuaki$ dig @2001:4860:4860:0:0:0:0:8888 ns1.dns.ne.jp AAAA -6
; <<>> DiG 9.8.3-P1 <<>> @2001:4860:4860:0:0:0:0:8888 ns1.dns.ne.jp AAAA -6
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4477
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;ns1.dns.ne.jp. IN AAAA
;; AUTHORITY SECTION:
dns.ne.jp. 856 IN SOA dns.sakura.ad.jp. dns.sakura.ad.jp. 2017070301 900 300 3600000 3600
;; Query time: 47 msec
;; SERVER: 2001:4860:4860::8888#53(2001:4860:4860::8888)
;; WHEN: Wed Jul 12 08:50:36 2017
;; MSG SIZE rcvd: 81
----
iMac27:~ yasuaki$ ping ns1.dns.ne.jp
PING ns1.dns.ne.jp (61.211.236.1): 56 data bytes
64 bytes from 61.211.236.1: icmp_seq=0 ttl=56 time=7.762 ms
64 bytes from 61.211.236.1: icmp_seq=1 ttl=56 time=5.913 ms
^C
--- ns1.dns.ne.jp ping statistics ---
2 packets transmitted, 2 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 5.913/6.838/7.762/0.924 ms
iMac27:~ yasuaki$ ping6 ns1.dns.ne.jp
ping6: getaddrinfo -- nodename nor servname provided, or not known
----
iMac27:~ yasuaki$ ping6 y2tech.net
PING6(56=40+8+8 bytes) 2409:10:ad40:1200:c5bf:xxxx:yyyy:zzzz --> 2001:e42:102:1816:160:16:228:218
16 bytes from 2001:e42:102:1816:160:16:228:218, icmp_seq=0 hlim=54 time=6.722 ms
16 bytes from 2001:e42:102:1816:160:16:228:218, icmp_seq=1 hlim=54 time=5.986 ms
16 bytes from 2001:e42:102:1816:160:16:228:218, icmp_seq=2 hlim=54 time=5.957 ms
^C
--- y2tech.net ping6 statistics ---
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 5.957/6.222/6.722/0.354 ms
----
iMac27:~ yasuaki$ dig @2001:4860:4860:0:0:0:0:8888 y2tech.net AAAA -6
; <<>> DiG 9.8.3-P1 <<>> @2001:4860:4860:0:0:0:0:8888 y2tech.net AAAA -6
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13235
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;y2tech.net. IN AAAA
;; ANSWER SECTION:
y2web.net. 3599 IN AAAA 2001:e42:102:1816:160:16:228:218
;; Query time: 95 msec
;; SERVER: 2001:4860:4860::8888#53(2001:4860:4860::8888)
;; WHEN: Wed Jul 12 08:30:12 2017
;; MSG SIZE rcvd: 55
IPv6環境の設定については、今後折に触れて紹介して行く予定だ．とりあえず今回のIPv6(DS-Lite方式）導入で我が家のインターネット接続環境がどの程度変わったか、smokeping の画像サンプルを載せておく．
自宅環境でsmokepingサーバを立ててインターネット側のレスポンスを測定
smokeping でWAKWAK のpingレスポンスをグラフ化してみる（IPoE切り替え前）
上記のチャートは WAKWAK (BB-EAST) の経路上のルータに対して、pingのレスポンスを測定したものである．上から順に、RTX1100のLAN側(192.168.100.254) 、建物内(MDF）に設置?されたWAKWAK側の対向L3-SW（ルータ）、バックボーン回線のOCN上のルータ1 & 2 のpingレスポンスの平均値となっている．夜になるとOCN側の遅延が目立つようになっているので、やはりFLETS網の網終端装置がボトルネックになっているのだろう．
切り替え前と切り替え後（土曜日14時頃）のOCN-GWに対するpingレスポンス
このチャートはIPoE(DS-Lite)へ切り替える前とその後の様子を現したものである．OCNのルータに関しては切り替え後は別経路となるので、レスポンス時間そのものは若干増えているが、これまで発生していた夜間の遅延が全く無いことが分かるだろう．pingレスポンスだけではなく、アプリケーションレイヤーでも測定しているので、DNSとHTTPのレスポンスを載せておく.
切り替え前と切り替え後（土曜日14時頃）のHTTPテストサイトに対するレスポンス
切り替え前と切り替え後（土曜日14時頃）のOCNユーザ用DNSサーバに対するレスポンス
切り替え前と切り替え後（土曜日14時頃）のGoogle Public DNSサーバに対するレスポンス
WAKWAK(BB-EAST)、ZOOT NATIVE(DS-Lite)、ZOOT NEXT(PPPoE）のPingレスポンス（対OCN-GW：60.37.54.77）
GoogleのパブリックDNSサーバに関しては、IPoE(DS-Lite)へ切り替え後にレスポンスタイムが大幅に劣化している．原因はハッキリしないが、GoogleのパブリックDNSサーバへの経路が大きく迂回してしまうのだろう．
【上記のsmokepingの測定間隔は緻密な計測データ取得のため短めに設定してあるが、日常の監視用途では間隔を広めに設定しておくべきだ．HTTPについては今回の測定のためにわざわざ外部にテストサーバを立ててある．】
IPoE（DS-Lite) 方式は夜間の糞詰まり対策にはとても有効だ
まだ長期間テストした訳ではないが、一番混雑する土曜日の夜の時間帯でも全くネットワーク遅延が発生しなかったのは朗報だろう．やはりNTT東日本のフレッツ網の網終端装置がボトルネックになっているのは間違いない事実のようだ．VDSL環境でのPPPoE方式のIPv4環境でも昼間はRadishなどのスピード計測サイトで70〜90Mbps程度はコンスタントに出ているが、やはり夜間は大幅なスピードダウンは避けられないようだ．IPoE（DS-Lite) 方式では夜間でもコンスタントに70〜90Mbpsは確保できている．
IPv6(DS-Lite)方式が一般のユーザに普及するまでにはもう少し時間が掛かりそうだが、BuffaloやIOデータなどの素人向けの無線ルータ機器などが出まわるようになると一気に普及しそうだ．問題は、IPv6からIPv4への変換とNAT変換を行う事業者が、現状では日本国内に三機関しかないそうなので、ユーザのアクセス元を限定したアクセス制限などが難しくなる点だろう．変な事をするユーザが居て、そのIPをブラックリスト登録されてしまうと、多くのユーザがその影響を被ることになりやしないか心配だ．
世の中が全てIPv6対応になればこのような問題は起きないだろうが、IPv6なんて面倒で複雑なものが普及しそうもないのはここ10数年の流れを見てきても明白だろう．Docomoなどの光インターネット回線抱き合わせ商法（光コラボ回線）の影響でこれまでニッチなマニア向け市場だった光ファイバインターネット回線が、必要も無いような一般の人達にまで広まってしまったのは、NTTさんも大きな誤算（嬉しい誤算？）だったのではないだろうか．一番迷惑を被ったのはコアなインターネットユーザの人達で、今回のIPoE（DS-Lite) もこのような人達が率先して飛びついたというのが現状だろう．
とりあえずここ暫くはIPoE（DS-Lite) 方式でスイスイと接続できることを願うことにしよう．めでたしめでたし．．．(^^)/
