IPv4 over IPv6 DS-Lite MTU不適切問題 1420を1460に改善

[@atsuya0916]

仮説と検証と考察の流れが非常に秀逸で毎度ながら聞き入ってしまいました。 これからも興味深い動画を期待しております。

[@TwoWheelJunkie]

ありがとうございます！ニッチな世界を進みます。

[@yama--chan]

勉強になります！私もMTU1420で生き恥を晒していましたw　早速 "ip tunnel tcp mss limit off" にしました。

[@TwoWheelJunkie]

やはり1420仲間がいましたか！1460になるとよく眠れます。

[@ka2from]

素晴らしい！ この探究心と情報整理カッコいいっす！ 動画有難うございます♪

[@TwoWheelJunkie]

ありがとうございます！ニッチ街道を進みます。

[@omotek2001]

ちなみに SG TCP/IP Analyzerサイトの「Optimize Your Connection」には 和訳すると 「TCP/IP アナライザーの結果は、コンピューターとサーバー間の TCP 3 ウェイ ハンドシェイクからのパケット ヘッダー情報を提供します。上記の情報は、TCP/IP 設定を微調整し、インターネット接続を最適化するために使用できます。」 とあり 該当サイトで表示されるMSSが自サーバの受信MSS値、おそらくMTU値は+40を出しているのではないかと思われますので まさしく動画の通りMSS値による減算という考察と合致しますね。 さらに、MSSによる末端（PCとサーバ）に対してのTCPレベルのみの減算であるため pingによる測定では経路上のMTUが減算されていないのも納得できます。 やはり、とてもすばらしい問題提起です。 勉強になりました

[@TwoWheelJunkie]

ありがとうございます。その記載は気づきませんでした。いま確認したら確かに下段にありました。MTUと書かれるとpingとかUDP/IPにも関連するように見えるので誤解につながりますよね。

[@唐揚弁当-p4f]

この17分の情報量 凄い、勉強になりました 講義2時間分くらいあるように感じました

[@TwoWheelJunkie]

ありがとうございます！内容がニッチすぎて・・・と思っていたのですが、興味がある人がいてくれてうれしいです。

[@4wdcat17]

MTU調整とか物凄い久しぶりに聞いて懐かしい想い出が… 20年以上前にRWIN弄りとセットで散々やりましたねぇ…まさか令和になっても必要だとは🥲

[@TwoWheelJunkie]

現在ではMTUはお任せでも使えるようにはなっているわけですが、性分として最適化せずにはいられないです。RWINチューニングで検索すると、Win98とかでてきますね。たしかにあった気がします。

[@uguu0x0]

組み込み実装の視点から考察すると 高頻度に処理される箇所ほど実装効率化の恩恵が受けられるので 使っているCPUのアーキテクチャ上､条件分岐命令を挟むよりも 無条件で直接転送させたほうが高速に処理できる、という理由が考えられます。 実装の最適化によってハードウェアのスペック要件を引き下げ、 製造コストの低下に繋げる取り組みの結果の一部と考えれば至って自然です。

[@TwoWheelJunkie]

ありがとうございます！なるほど。たしかにAFTRの方は大量の通信をさばきまくるわけで、単純に40減算するほうがシンプルで高速に処理できるというわけですね。

[@omotek2001]

端的にいうとルータからすると 自分のIFのMTU値と整合するMSS値であればよいという話だからです 　 大前提として MTUはNW機器がIPフラグメンテーションを行う際の閾値 MSSは端末がTCPセグメンテーションを行うの閾値 です MSSは相互通信する末端の機器(A端末B端末)が TCPの3way Handshakeのときに端末間でTCP MSS値を各々通知し合うのです (TCP synとTCP syn/ackでおくりつける 動画の中のパケットダンプでもTCP synとかでMSSの指定が載っていましたよね） これをみて端末はTCPセグメンテーションを行います 通常ルータがMSSを見てTCPセグメンテーションを行うことはありません 　 さて通信途中にルータがあった場合です ルータのMTU設定がA端末またはB端末より小さい場合 端末がTCPセグメンテーションを行ったのにさらにルータでIPフラグメンテーションが発生する可能性があります それをさけたいならなら端末のMSSを下げればいいじゃないという考えで MSSアジャスト機能という機能をもつルータがあります （MSSが下がればそれ以上のサイズのペイロードはこないので結果としてIPフラグメンテーションはさけられる） MSSアジャスト機能はTCPを監視してMSSの通知が行われた場合に それを自分がコンフィグで指定されているMSS値に書き換えてしまいます そうすると A端末B端末で自分達のMSSを申告し合っているはずなのに 途中ルータにより書き換えられたMSS値を申告しあったかの様にだまされます で この機能実はRTX830にも存在します "RTX830 TCP セッションの MSS 制限の設定" くらいのキーワードで検索すれば出てきます で RTX830もMTU値から自動的にMSSアジャスト値を変更できる様になったのはファームRev.15.02.03以降からで それ以前は固定値設定ですね autoの説明を引用すると 「autoを指定した場合には、インタフェースのMTU、 もしくは PPインタフェースの場合で相手のMRU値が分かる場合にはそのMRU値から計算した値に書き換える。」 PPというのは"Point-to-Point"の略らしいです ということで PPでない通常の通信の場合RTX830もautoにしても「自分のIF」のMTU値から40引いてるだけです 　 Path MTU Discoveryなどが働いた場合も MTU超過を検知したルータから「末端の送信端末」へMSS調整をかける動作になります 他ルータでMTU超過検知してもそのルータから「末端の送信端末」へMSS調整をかける動作なので 自ルータのMTUを更新したり自ルータにMTUを知らせる通知が来るわけではないので 自ルータのMTU値が自動変更されることはありません 自ルータでMTU超過検知しても「末端の送信端末」へMSS調整をかける動作になりその値の根拠は自ルータのMTUです よって末端の通信端末へ通知するMSS値も自ルーターのMTU - 40で固定するしかありません 　 あとMSSは「TCP」フラグメンテーションに関わる話なので UDPには関係ありません よってUDPでP2Pやってるときとかは関係しません

[@TwoWheelJunkie]

なるほど。 「「自分のIF」のMTU値から40引いてる」という動作だと納得感があるのですが、どうもv6コネクトのAFTRは「どのようなMSSがきても（自IFのMTUとは無関係に）無条件に到着したMTUを40を減算して上書きしている」ように見えるんです。（上り下り共通） なので、RTX830のauto設定の挙動とも違うような気がしています。 シスコの設定方法も調べてみたのですが下記になっていて、上限設定方式に読み取れました。 ip tcp adjust-mssmax-segment-size 最初は私の勘違いかAFTRの挙動が特殊なのかと思ったのですが、撤去したNECの1200HS4も同じ挙動をしているようで？？？となった次第です。

[@omotek2001]

@@TwoWheelJunkie はい この場合DS-LiteはガワがIPv6で経路上のルータがパケットをフラグメントできない かつ DS-Liteの端点まではどの経由ルーターもIPv4については見ることができない DS-Liteの端点でIPv4が見られるようになる と 考えると DS-Liteの端点ではIPv4における対向のMTUも知ることができてそれによる調整を行う機構があるというのは確かにありそうです

[@TwoWheelJunkie]

@@omotek2001 ヤマハやシスコでは相対減算方式は無いようなのですが、下記をみると相対減算方式の設定ができるみたいなので、全くない話ではないのかもしれないです。 documentation.a10networks.com/ACOS/414x/ACOS_4_1_4/html/axapiv3/cgnv6_lsn_tcp_mss_clamp.html

[@omotek2001]

@@TwoWheelJunkie CGN and IPv6 Migration commands CGNでIPv6マイグレーションというとまさしくDS-Liteをイメージしますね

[@akb9343]

貼ってあるURLを確認したら「MTU=1260」と出てきました。GoogleでMTUの変更の仕方を調べて、コマンドでWindows標準が1500と書かれていたので、1500に設定したところ「MTU=1420」になりました。

[@TwoWheelJunkie]

なんと1260ですか！1260と1420では誤差ではない速度差が出そうですね。なぜ1260になったんですかね。何かのソフトのインストール時ですかね。しかしまだ1420なので、そのさきがあります。

[@akb9343]

@@TwoWheelJunkie PPPoE接続時に、どこかのサイトを確認しながら変更をした覚えはあるのですが、WindowsのMTU値を1500に変更した後に、元のサイズは何だったのかメモを忘れてしまいました。 概要欄のサイトでは何度やってもMTU=1420ですね。YahooにPINGを飛ばすと自分の環境でも1432までは通信が成立していました。 自分はアサヒネットと1200HS4の組み合わせで利用しています。

[@kanryukato5656]

私の環境でも「MTU=1260」と表示されています。手元のWindows PCとYAMAHA RTX830のMTUを1500に統一してもサイトの表示は変わりませんでした。不思議ですね…。

[@TwoWheelJunkie]

@@akb9343以前、MTU設定をご自身で変更されたということですね。 1200HS4との組み合わせで1420とはまさに私の以前の状況とおなじかとおもいます！

[@TwoWheelJunkie]

@@kanryukato5656 なるほど、謎が深い状況ですね。通信事業者はどちらでしょうか？通信事業者側で、大きく減算している可能性もあるのかと思います。

[@paseri9697]

v4 over v6が絡むと色々問題起こりますよね… 私はWindowsのリモートデスクトップがMTUのせいで絶対に切断される問題に遭遇したことがあります

[@TwoWheelJunkie]

なるほど。そういう事象もあるんですね。VPNの確立で不具合が出る感じですかね。

[@イデオンチャンネル]

わたしも NEC Aterm WX6000HPを使用中で、SG TCP/IP Analyzer で見ると勝手にMTUが1420になっており、MTUリライトが行われてました。MTUリライトがされない無線WiFiルーターを取説の内容見ながら探してたところ、BUFFALO WXR-5700AX7B/Nがインターネット側のMTU設定が出来ることがわかり、ワンちゃんMTUリライトがされないルーターかもしれないと思い、購入しました。SG TCP/IP Analyzerで確認したとろこ、MTUは1460で表示されました。MTUリライトされてませんでした!! ルーターのアマゾン価格は、25,400円でした。

[@TwoWheelJunkie]

貴重な情報ありがとうございます。早速その機種のマニュアルをDLして読みました。確かにinternet MTUという設定があり、1500が初期値になっていました。推測なんですが、ここを1500のままで使用するとリライトしない状態で実測1460、1460設定とすると実際のパケットサイズが1420になる気がします。今回検証したヤマハルーターの挙動は以下の通りでした。現状は3で運用しています。上記バッファローの状況は１の状態かなと推測します。（結果として同じ動きになっています） 1. MTU1500設定 MSSリライトあり設定　＞　観測サイズ1460 2. MTU1460設定 MSSリライトあり設定　＞　観測サイズ1420 3. MTU1460設定 MSSリライト無し設定　＞　観測サイズ1460

[@yushiokunishi6162]

いつも動画を楽しく拝見しています！ 動画の内容と関係なく申し訳ないのですが、インターネットに詳しい投稿者さまに質問をしたいです インターネット無料（壁からLANポートが直で生えているタイプ）の物件について、速度やセキュリティは大丈夫なのでしょうか？ 速度に関しては、大家もしくは仲介会社に回線、プロバイダの詳細を質問するしかないでしょうか？ セキュリティに関しては、適当なルーターを使用すれば問題ないでしょうか？

[@TwoWheelJunkie]

入居前にセキュリティと速度を見極めたいという事かと思います。インターネット無料物件にも様々な形態があるようなのですが、各部屋にルーターを設置する形態であればセキュリティ上の問題はないかと思います。各部屋にルーターを設置しない形態ですと、部屋間の通信が抑止されているかが気になりますが、多くの場合は抑止されていると思います。物件管理者による盗聴については、現在の通信はＰＣとサーバー間で暗号化されているので大きな問題はないと思います。 速度についてはケースバイケースなので何とも言えないのですが、ケーブルテレビ系のネット無料物件では高速契約は有料とかがあるようです。

[@alicey]

面白い検証ありがとうございます。 自分もWireGuardVPNを構築していたときに、DSLite回線から通信するとVPNインターフェースのMTU設定によってはうまいこと疎通せず、なんかおかしくね？となりあれこれ検証している際に同じ沼にハマっていました。

[@TwoWheelJunkie]

なるほど。WireGuardってたしかにMTUの最適化できそうですよね。我が家もラズパイでWireGuardの口（PPPoE側利用）をつくっているのですが、MTUの最適化はしたことがなかったです。ちょっと見てみたいと思います。

[@ててて-v4q]

これ自分も過去に悩みました。接続先によってMTU起因の相性が出て速度が極端に遅くなる場合があったのです。DS-LiteからMAP-Eの業者に変更してルーターも変えたら解決したのですが、どちらが原因だったのかは謎です。

[@TwoWheelJunkie]

興味深い情報ありがとうございます。MAP-Eで改善した原因として考えられるのは 1.MTUの影響 2.DNSサーバーの変更の影響（引き当てられるサーバーが変わった） かなと思います。 ダウンロードの速度が改善した場合は２の可能性もあると思います。 オンラインゲームでの改善の場合は１かなと思います。

[@stastallone28]

初めまして、コメント失礼致します。スピードガイドドットネットにて、MTU値が1420と出るのですが、MSSリライト設定ができないとなると、ルーターで設定できるMTU値は1500のままでいいということなのでしょうか。ネット使い方としてはパソコンでゲームしたり、ネットを見るぐらいしかしてないです。

[@TwoWheelJunkie]

MTUが設定できるルータの場合はMTU値1500とすると、通信としてはMT1460が実現できると思います。これは「ＭTU1460, ＭSSリライト無し」とは微妙に異なる状況なのですが、結果として正常系では同じ効果が得られます。ヤマハルーターで比較検証したところ、異なるのはパケットのサイズが大きすぎた際の挙動で、MTU1500設定の場合はタイムアウトになるのに対し、「ＭTU1460, ＭSSリライト無し」の場合は即時でエラーとなります。

[@stastallone28]

@@TwoWheelJunkie 答えていただきまして、ありがとうございます🙇‍♂️

[@hnasg]

SwitchもDS-Liteもネットワークの方かゲームの方か紛らわしいですねｗ 私がv4 over v6のMTUで遭遇した問題として、Encapsulation limitの拡張ヘッダを外さないと8バイト減った上に、不適切なパケットと判定されたのか帯域制限が掛かりましたね

[@TwoWheelJunkie]

Encapsulation limitの拡張ヘッダというのは読んだことがあります。なかなか謎めいたヘッダですよね。

[@classix44]

まさか1年以上時給が1420円だったとは...騙された気分ですね。ネットをよく知らずに使ってる身としてはこんな仕組みになってるんだと勉強になりましたし、難しい話でも分かりやすい解説でなるほどと思いました。 長嶋さんや“大人のおもちゃ”、最後の締めの言葉には笑ってしまいましたよ笑 謎解きとおっしゃってたのでコナン君も登場しそうな勢いでしたね。

[@TwoWheelJunkie]

たしかに謎解きといえばコナン君ですね。未来少年ではないほうですね。

[@3go_No.3]

これはとんでもない事を発見してしまいましたね、、、ｗｗ

[@TwoWheelJunkie]

そーなんです。たかが40バイト、されど40バイトです。40バイトを笑うものは40バイトに泣くと祖母に言われたことがあります。

[@murayamamikio]

コメント消しましたが投稿者さまには履歴の通知来たと思います。変なコメント申し訳ありませんでした。 毎度ながらすばらしい動画だと思います。理解できるまで何回も見させていただきます。有難うございました。

[@TwoWheelJunkie]

コメントありがとうございます。元のコメントがなにか確信が持てていないのですが、NETGEARについてだったでしょうか？今回のamazonセールで久しぶりに買いました。違っていたらすいません。

[@murayamamikio]

@@TwoWheelJunkie ご返答ありがとうございます。NTTのインターネット網は音声データと普通データと２つが混在している為、音声データをNTT外のインターネット網に出さない為のIPv6の仕様が関係しているのではないか？と思ったものでコメントさせていただきました。 これを確認するにはNTT以外のインターネットを使われる方に依頼され同様のテストをやっても結果は同じか？を確認する必要があると思います。ちなみに私もはNTTのIPv6（OCNバーチャルコネクト）なのでMTU=1460と表示されています。無知故に的外れなコメントかもしれません。もしそうならお許しください。今後も貴殿の動画楽しみにしています。

[@tifuyu511]

興味深く見ました。 MTUの設定はややこしいですね。 そもそもLAN側がジャンボの場合はどうなるんだろ？・・・考えたら頭が爆発しそうだw

[@TwoWheelJunkie]

今回の事象は体感できる害はないレベルなんですが、弊害がないのに最適化されていないのはエンジニア心が耐えられない感じです。

[@dockerkun]

今回使用したRTX830のコンフィグはどのようなものか公開することは難しいでしょうか

[@TwoWheelJunkie]

大丈夫です。ヤマハが出してくれているサンプルに少し加えただけです。 network.yamaha.com/setting/router_firewall/ipv6/ds-lite のDS-Lite部を以下にしています。 tunnel select 1 tunnel encapsulation ipip tunnel endpoint remote address dslite.v6connect.net ip tunnel mtu 1460 ip tunnel tcp mss limit off tunnel enable 1

[@てっしー-l3b]

なるほどよく分からん笑　 今自分の環境を調べてみたところ、 MTU:1500 MSS:1460 でした。 ケーブルインターネット、NECルーターです。

[@TwoWheelJunkie]

ケーブルの情報は不足しているので助かります！MTU1500、MSS:1460ということはこの部分の環境としてはNUROと同じく最強ですね。

[@てっしー-l3b]

@@TwoWheelJunkie 田舎町ですが、ケーブルと言ってもまだ最大100Mの同軸ケーブルによるネットです。ここ最近地域の電柱に光ケーブル設置の工事が終わってますが半導体不足の影響で各家庭の光契約(1Gもしくは250M)がストップしているみたいです。まだ先になると思うけど光契約したら再度計測?してみます。

[@TwoWheelJunkie]

@@てっしー-l3b そんなところにも半導体不足がでてるんですねえ。こまったものです。

[@てっしー-l3b]

@@TwoWheelJunkie 同軸ケーブルのネットから同会社の光回線に変わりました。最大1G契約です。 MTU1500、MSS1460と変わりませんでした。

[@TwoWheelJunkie]

@@てっしー-l3b 最近のケーブル会社の回線はよやそうですね。スループットもよい感じがします。

[@tubemimimi]

ネットゲーム界隈では細かいパケットが連続する通信では大きくしすぎると良くないと言われています

[@TwoWheelJunkie]

興味深い情報、ありがとうございます。現状、私はゲーム界隈の情報が薄いので大変助かります。関連としては以下になります。 「細かいパケットが連続する通信では大きくしすぎると良くない」というのは端末（PCやSWITCH）において、大きすぎるMTUを設定すべきでないという事となり、その意味においては正しいということになります。これは前回の動画で示したSWITCHのMTUを1400から1500にしない方がよいという事とそのものとなります。 kzbin.info/www/bejne/b4K3q4uXrdN5gdk 一方で、今回の話はルーターの挙動を変える行為となります。これは「端末が最大のMTUを使おうとした際に使えるようにする」という事になります。端末が大きなMTUを使おうとするかどうかとは独立した話となります。ですので、今回の対応についてはオンラインゲーマーの方にもお勧めできる内容となります。（ソフトのダウンロードが少し速くなります。） また、ややこしいのですがオンラインゲーム中に使用されるUDP/IPにはTCP/IPとは異なりMSSという概念がなく今回の話は関係ないということなります。

[@tubemimimi]

@@TwoWheelJunkie 詳しい解説ありがとうございました

[@YakumoSagiri]

MSS調整は往復により確定するのですが、戻りパケットのMSSはいくつでしたでしょうか？ (画面上では見切れていて確認できませんでした) サーバによって、受けたサイズ(今回は1380)で返す場合と最大サイズ(1460)を返す場合があるようなのでちょっと気になりました。 ①1460→②1420→③1380→サーバ→③1xxx→②1xxx→①1xxx

[@YakumoSagiri]

あと、WG1200HS4は本当に相対減算方式でしょうか？ ①を1260等に小さくした場合、②が1220になってしまう状態でしょうか？

[@TwoWheelJunkie]

おそくなりました！実は話が複雑になるので、動画には入れなかったのですが、下りも観測していました。 ①1460→②1420→③1380→サーバ→③1460→②1374→①1334 です。つまり、私のサブPC（Web-SV）はMTU1500前提で返したということになります。また上記の流れが二番目にいただいた質問への回答となっていて、WG1200HS4はここでも40減算をしているので、相対減算方式ということになります。今回のケースは通常はあり得ないケース（SV側にPPPoE）で、かつ相対減算方式と上限設定方式がまざったので、上り下りでMSSが異なる結果となっています。検証はしていませんが、おそらく上り下りで異なるサイズのパケットが観測されるのではと思います。

[@TwoWheelJunkie]

上記の相対減算方式の件は下りの話になるので、今しがたSWITCHのMTU設定の下限値576測定時のwiresharkデータを確認しました。下りのパケットの大きさは 510-14＝496 となっています。576-496＝80ですので、やはりここも80減となっていますので、相対減算方式で間違いないかと思います。

[@YakumoSagiri]

@@TwoWheelJunkie さん お忙しい中、丁寧なご回答ありがとうございます。 上りも下りも減算されてしまうんですね。 新しいAtermではパスMTU問題回避のために--clamp-mss-to-pmtu指定が追加された感じでしょうか。 コンシューマ向けルータでは、問い合わせ増加回避のためにフールプルーフ設計にしたいのかもしれませんね。 もしもオプションを追加したら、高速化指南を見て設定したユーザーが不具合に遭遇して大量に問い合わせたり悪評をばら撒いたりしかねないので。

[@grenadenn]

いきなりネタをぶっ込んで来るその姿勢が大好きです。 ですが流石に長嶋さんの事は存じて居られない方も増えている予感が(笑)。

[@TwoWheelJunkie]

身の回りで調査したところ、セコムしてますかは３５歳限界説が有力でした！

[@tskikoh]

今のルーターは自動で最適なMTUの減算がされる仕組みであると勝手に思っていましたが、まだそこまで賢く無かったんですね。 通信事業者側で自動判別をするのは流石に負荷が大きすぎるので、毎回固定値40で減算するのは仕方ないと思いますが、家庭側ルーターで減算するべきかどうかを自動判別できないのには何か理由があるのでしょうか。 私が思いつくものは、定期的にpingを飛ばすとDDoS攻撃みたいなことになるからとかですかね。

[@TwoWheelJunkie]

今回の動画で紹介したpingでのMTU探索とRFC4821のMTU探索は本質的には同じことをしているのですが、方式の特性上、時間がかかります。動画では少し早く回していますが、今回のケースですとRFC4821の方は約１０秒かかりました。ですので、通信の相手先ごとにこれをやるのは現実的ではなく、この方式が実装されているのは特定の通信先に安定的なパスを張る必要があるVPNのような場合にしか実装されていないと思います。 そのような理由でMSSリライトが実装されているかと思います。

[@tskikoh]

@@TwoWheelJunkie なるほどです。 ただ、通信事業者側でMSSのリライトをしているかどうかって、家庭側のルータで検知する方法とかって無いんでしょうか。 例えば初回起動時と、一日に一回ほどルータのメーカーのサーバーに通信を行って、自分が発したMSSとサーバーに到達した時点のMSSを比較するとか。

[@TwoWheelJunkie]

@@tskikoh そーなんですよね。実際のとこと、MTUが細くなるのはユーザーに近い方なので、Nintendoスイッチなんかでは、起動時にそれを計測して、サーバーに報告するとか原理的には出来そうなんですよね。でもMTUが細くなるのは「絶対に」ユーザー側だけか？ときかれると、絶対とはいいがたく、結局全経路ごとに測定しないと不具合が起きる場合があるということかと思います。

[@biospv]

RFC側で曖昧にするからRFC違反に成らずに問題が大きくなるんだよ。 この手のトラブルって現場でわかって工場に問い合わせても「理屈はおかしいけどRFC違反じゃないからね」って現場が被るんだよ

[@TwoWheelJunkie]

そうですねえ。RFC策定側の気持ちも分かる部分はありますが、B4とAFTRという表現で関与するルーターを非対称に定義しているので、MSSリライトをどちらでやるのが標準なのかがあると混乱は少ないかもしれないですね。

[@chanponcham]

NECルーターの流れからNECのIXルーター買うかと思ったらRTXにしたんですね！

[@TwoWheelJunkie]

するどいご指摘。じつは迷ったんですが、NECの方は更新用ファームウェアを公開してないんですよね。申請すれば中古購入者でもダウンロードできるらしいのですが、やはり普通にダウンロードできる方がよく、ヤマハにしました。

[@chanponcham]

僕は安さ重視からNECのIX2215を中古で買いましたが、ファームウェアをNECに申請してみたら形式的な申請フォームだけで、国内ユーザーにはほぼ誰にでも配ってる様子でした。 しかもver10.x.x以上のFWに１回なれば管理画面からFW更新できるようになりますしいいですよ！ ぜひ追加で買ってしまいましょう こういうふうにお勧めするのも、YAMAHAで簡単にできるPPPoEとIPoE通信を同時に使う設定をIXの方だと情報が多くなく設定がわからないのでトゥーエルジャンキーさんに使ってもらってあわよくば情報公開してくれたりするんじゃないかという魂胆があります🎉

[@TwoWheelJunkie]

そういわれてみると、たしかにヤマハのほうがネット上の情報が多いですね。IX2215の価格をメルカリで見てみると、なかなか惹かれるねだんではありますねえ

[@nb774]

厳密な仕様決めがあるものと思ってましただ、案外グレーな部分あるんですね

[@TwoWheelJunkie]

そうなんですよね。DS-Liteがどのように使われるか流動的なので、ガチガチに決めるとそれはそれで不便なのでバランスかと思います。

[@そよ風太郎-o5j]

大人になった今でも RTX830 は買えません。我が家はさらに古い RTX810 をメルカリで買っています。

[@TwoWheelJunkie]

RTX810でもDS-Lite対応可能ですね。IPv4 over IPv6ってやってることは複雑ではないですもんね。今回、WiresharkがIPv4 over IPv6のIPv4を通常のPv4と同様に観測できることをしりました。こんな便利なものを無料で使えてありがたいです。

[@kohji386]

ルーターはYAMAHAに限る。

[@TwoWheelJunkie]

現在、ごくごく一部の設定しか利用していないのですが、DHCP一つでいろいろあるのは驚きました。

[@sattoman]

途中までNDS Liteの話してるものと勘違いしてました

[@TwoWheelJunkie]

そうなんです。DS-Liteの情報を調べようとすると、NDSの方が大量にでてきてしまい難しい状況です。

[@ii_chan__love]

1460だ　良かった

[@TwoWheelJunkie]

ルーターでonuが設定できて1500にしていると1460になるようです バッファローはできるみたいです

[@Yukkuri-jido]

その家庭用のルーターにOpenwrtをインストールすれば業務用ルーターを買う必要がなかったのでは

[@TwoWheelJunkie]

wrtはだいぶ前に一度使ったことがあります。今調べたらDS-Liteにも対応しているんですね。MSSクランプの設定もありました。ただ、NECのルーターでの稼働実績は少なそうです。バッファロが多い感じですね。

[@wongdi0201]

My v6 MTU 1492-60-4=1428

[@TwoWheelJunkie]

これはまた謎めいた数値ですね・・・・1500-8＝1492というのは見たことがあるのですが、-60-4はなんでしょうか・・

[@wongdi0201]

@@TwoWheelJunkie 私は使っているRB5009+PonStickインターネットに接続して、フォーラムでアドバイスをもらいました。1500-8-40-4 および 1500-8-60-4 を使用しますMTU。良い結果が得られました，これらの値はRouteroOS。

[@TwoWheelJunkie]

@@wongdi0201 MikroTikですか！私も10Gスイッチを探してラトビアサイト覗いています

[@ポンコツ太郎-f1o]

これって美味しいの？。 mtuって久しぶりに聴いた。

[@TwoWheelJunkie]

Win98,xpのころはMTU調整、RWIN調整をやってましたよね。今回の事象は通信速度がほんの少し遅くなっているだけなのですが、やはり最適化を追求するのがエンジニアなのです！

[@ideonjapan]

うーん、同じ型番のルーター使ってる。

[@TwoWheelJunkie]

むむむ、そうすると多分・・・でも、MSS減算をしないDS-Lite事業者もあるようです。

[@ネオジオヨシオ]

MTU = 1454 MSS = 1414 って出ました。

[@TwoWheelJunkie]

その数値ですと、NTT系のPPPoE接続かと思われます。（MTUは最適化されています）夜間などの速度低下がおおきいようですと、IPv4 over IPv6契約で改善する可能性があります。

[@sat600]

そういや昔、フレッツ光プレミアムだと1438じゃなきゃ駄目だったな( ´ー｀)y-~~

[@TwoWheelJunkie]

東京なのでそれは知りませんでした！1438はかなり低めですよね。なぜなんだろうか・・

[@ytmz5d]

インターネットぜんぜんワカラン

[@TwoWheelJunkie]

今回の話はかなりマニアックになってます。クロスワードパズルに通じる魅力がある分野かと思います。

[@モンカゼ]

ばななぁ

[@TwoWheelJunkie]

そんなばななあです。ホント

[@I_have_no_money_yeah]

TCP　ってのは最低保証が578バイトなんでそれ以上のパケットを通す義務は無いんだよ。MTUのちょっとした違いが体感できることは無い。何のためのフラグメントとTCPフローコントロールなのかと小一時間　以下ry

[@TwoWheelJunkie]

たしかに今回のMTU差により影響は小さいんですが、最適化されていないことがなんとも気持ち悪い次第です。利用者全員が最適化するとAFTRの負荷も低減すると思うんですよね。