RAILSIDE WORKS

自宅のインターネット環境を「楽天ひかり」に乗り換えました。SEIL/x86でクロスパス接続を実現するために追加の設定を行ったところ、下り753.2Mbpsを記録することができたので、備忘がてら残しておきます。

「IIJmioひかり」から「楽天ひかり」へ乗り換え

2016年7月から、我が家の光回線は「IIJmioひかり」を使ってきた。モバイル回線とのセット割が適用され、光回線の月額は実質3,360円。IPoEとDS-Lite方式によるIPv4 over IPv6サービス(transix)を使っており、速度にも不満はなかった。

しかし2020年春から、楽天が大々的なキャンペーンを開始。モバイル回線「Rakuten UN-LIMIT」が実質1年無料に加え、「楽天ひかり」をセットで申し込めば光回線も1年無料（以降月額3,800円）になるという。最低利用期間の3年間で平均しても、実質月額2,533円と破格の安さだ。さらに「Rakuten UN-LIMIT」「楽天ひかり」ともにSPU対象となり楽天でのお買い物に対するポイントが合計+2%となるため、楽天で年間数十万円の買い物をしている私にとってはおトクすぎる。肝心な通信環境の面では、口コミを見る限り散々な言われようだが(笑)、2020年5月からはDS-Lite方式によるIPv4 over IPv6サービス(クロスパス)の提供が始まっているため、こちらを使えば問題なさそうだ。

こうして、4年ぶりに光回線(コラボ事業者)を乗り換えることにした。

開通までの流れ

2020年6月3日、「Rakuten UN-LIMIT」に申込み、直後に送られてきたキャンペーンメールから「楽天ひかり」に申込み。光コラボの事業者変更承諾番号は、事前に「IIJmioひかり」の会員ページから発行しておいた。

2020年6月6日、開通日が2020年7月1日に決定したとのメールが届く。転用(事業者変更)なので派遣工事は発生しない。

2020年7月1日、開通日を迎えたが、我が家の通信環境に変化なし(笑)引き続き、「IIJmioひかり」のIPv6 IPoEおよびIPv4 over IPv6サービス(transix)経由でインターネットに接続できている。

2020年7月3日、「IIJmioひかり」のIPv6 IPoEおよびIPv4 over IPv6サービス(transix)との接続が切れ、NGNから2408::/22(NTT東日本)のプレフィックスが降ってきた。これではIPv6でインターネットに接続できない。事前に郵送で届いていたアカウントで「楽天ひかり」IPv4 PPPoE接続に切り替え。うぅ…明らかに遅い…

2020年7月10日、NGNから2001:f70::/29(アルテリアネットワークス)のプレフィックスが降ってきた！これでIPv6 IPoE接続ができるようになった。が、手元のルーター(Buffalo WSR-1166DHPL2)の設定を変更するも、IPv4 over IPv6(クロスパス)接続を確立できない。…そして、このあと約2週間に渡って試行錯誤した末、このルーター、執筆時当時のファームウェアではDS-Lite方式はtransixのみ対応(クロスパス未対応)であることが判明(汗)おそらく、7月10日の時点でクロスパスも開通してのだろう…。

2020年7月16日、NTTからゆうパックが届く。何かと思ったら「楽天ひかり」加入特典のルーター「Aterm WG1200HS4(NE)」だった。NTTから届くのかい(笑)

SEIL/x86を使ってクロスパスへ接続

手元のルーターがクロスパス未対応だったので加入特典のルーターに交換しても良いのだが、我が家の自宅サーバの中にソフトウェアルーター、IIJ「SEIL/x86 Fuji」が余っているので、今回はこちらを使ってクロスパスへ接続することにした。

実は我が家では少し前まで「SEIL/x86 Fuji」をメインルーターとして使っており、transixへの接続もしていた。クロスパスはtransixと同様のDS-Lite方式であるため、当時のConfigをほぼそのまま使いまわすことができる。接続設定はSEILの公式ブログで詳しく解説されているため割愛するが、クロスパスへ接続するにあたって変えるのは下記の1行だけ。

interface tunnel0 tunnel dslite dgw.xpass.jp

また、IPv6経由で外からアクセスされないよう、下記のとおりfilter6を設定。

filter6 add OUTGOING_V6 interface lan1 direction out action pass state enable logging off enable
filter6 add INCOMING_ICMP6 interface lan1 direction in action pass protocol ipv6-icmp state disable logging off enable
filter6 add INCOMING_LOCAL1 interface lan1 direction in action pass dst fe80::/10 state disable logging off enable
filter6 add INCOMING_LOCAL2 interface lan1 direction in action pass src fe80::/10 state disable logging off enable
filter6 add INCOMING_MCAST1 interface lan1 direction in action pass dst ff00::/8 state disable logging off enable
filter6 add INCOMING_MCAST2 interface lan1 direction in action pass src ff00::/8 state disable logging off enable
filter6 add INCOMING_DHCP6 interface lan1 direction in action pass protocol udp srcport 0-65535 dstport 546 state disable logging off enable
filter6 add INCOMING_V6 interface lan1 direction in action block state disable logging on enable

IPv4 over IPv6(クロスパス)接続が不安定…

こうして「SEIL/x86 Fuji」により無事にクロスパスへ接続確立、およそ1ヶ月ぶりにIPv4 over IPv6接続が復活した。…が、従来使っていたtransixに比べて物凄く不安定だ。具体的には「一部速度測定サイトで計測に100%失敗する」ほか、「数分に1回程度の確率でWebページの読み込みがタイムアウトする」など通常利用にストレスを感じるレベルである。ちなみに、一部速度測定サイトでは測定に成功したが、下り30Mbps程度しか出ない。

原因はTCP MSSにあった

ネットの掲示板に同様事象が見当たらないため、我が家の環境に起因する問題と考え調査開始。過去の経験から、速度測定のような巨大なファイルをダウンロードする場面でコケる場合はMTU周りが怪しいが、ルーターのConfigには下記の1行は打ってある。その他のインタフェースはMTU値を明示していないが、デフォルト値が1,500であるため問題ないはずだ。

interface tunnel0 mtu 1500

WireSharkを使ってTCPのハンドシェイクを眺めてみると、原因が見えてきた。クライアント側からのSYNパケットにおいてMSSは1,460(Bytes)を提示、サーバ側からのSYN+ACKパケットでもMSSは1,460(Bytes)を提示、よってMSSは1,460(Bytes)で合意している。これにTCPヘッダが20(Bytes)、IPv4ヘッダが20(Bytes)、合計でパケットサイズは1,500(Bytes)…いやいや、DS-Lite方式ではさらにIPv6ヘッダ40(Bytes)が付くじゃあないか！合計1,540(Bytes)のパケットはNGN網内は通れない。

ここから逆算すると、MSSは1,420(Bytes)以下で合意されなければならないはずだ。

そこで「SEIL/x86 Fuji」のConfigに、MSS値を明示する下記の1行を追記した。結果的に、これで前述の問題は解決した。

interface tunnel0 tcp-mss 1420

改めてWireSharkを使ってTCPのハンドシェイクを眺めると、サーバ側からのSYN+ACKパケットでMSSとして1,420(Bytes)を提示しているのがわかる。

何故クロスパス接続ではMSSの設定が必要なのか？

問題は解決したが、逆に、何故今までのtransix接続ではMSSの設定が不要だったのだろう？事業者は違えど、方式は全く同じDS-Liteである。調べると、これもSEILの公式ブログにヒントがあった。

IIJmio FA/NF サービスではサーバ(AFTR)側で TCP MSS の調整が行われるため、SEIL 側で tcp-mss を設定する必要はありません。

SEIL/x86 で DS-Lite

transixの場合、IPv4 over IPv6の対向サーバ(AFTR)でMSSの調整をしてくれていたので、クライアント側で気にする必要がなかったのだ。

改めて、IPv4 over IPv6(クロスパス)接続は超快適！

まだ始まったばかりのサービスで利用者も少ないのだろうか、適切な設定の下ではクロスパスによるIPv4 over IPv6接続はtransix以上に快適に感じる。改めて速度測定サイトで測定を行うと、IPv4のダウンロードで安定的に600～750Mbpsの帯域幅が出ている。十分過ぎる結果だ！

自宅サーバ兼ルーター(SEIL/x86)の設置場所が光コンセントから離れているため、一時的に剥き出しのケーブルが部屋の中を行ったり来たりしてしまっている。Buffaloには早いところWSR-1166DHPL2のクロスパス接続対応を実現してもらいたい(笑)