MTU/MSS計算機

3つのモードで層を分離します。経路MTUモードは、すでに有効なL3の経路MTUから内側の固定IPヘッダ(IPv4は20、IPv6は40)と固定20バイトのTCPヘッダだけを引きます。これはRFC 9293 3.7.1 が MSS Option に入れる値 (MMS_R − 20) として定義しているものそのもので、1500 なら IPv4 は 1460、IPv6 は 1440 になります。Timestamps や SACK などのTCP option、IPv4 option / IPv6 extension header は、この広告値からは決して引きません。これらは送信側が各セグメントに載せられるペイロードを減らすもので、「このMTUでの最大TCPペイロード」として別に表示します。この値はローカルのMTUによる上限であり、意図的に Eff.snd.MSS とは呼んでいません。RFC 9293 の Eff.snd.MSS は min(SendMSS + 20, MMS_S) − TCPhdrsize − IPoptionsize で、peer が広告した MSS にも依存しますが、本ツールはそれを入力として受け取らないためです。peer がより小さい MSS を広告していれば、実際の1セグメントあたりのペイロードはさらに小さくなります。1280 未満の IPv6 経路 MTU は計算せず reject します。RFC 8200 5章 がすべての IPv6 リンクに 1280 オクテットを要求し、RFC 8201 が 1280 未満の Path MTU estimate を保持することを禁じているためです。設計モードは underlay link MTU から始めます。PPPoE は L3 MTU を 1492 に下げる link adaptation (RFC 2516。それ以上は RFC 4638 が必要)、tunnel overhead は outer/underlay の IP version で決まり、内側の TCP パケットの IP version はそれとは独立に選べます。802.1Q / 802.1ad tag は L2 ヘッダのバイトです。Ethernet frame を 1522 / 1526 に広げますが L3 MTU は減らさないため、差し引かずに framing として表示します。IPsec ESP は cipher profile ごとに計算します。RFC 4303 2.4 のパディング規則は2つあり transform によって異なるためです (AES-CBC は 16 バイトの block、AES-GCM は ICV を整列させる 4 バイト境界のみ)。WireGuard は内側パケットが暗号化前に 16 バイト境界へパディングされるため inner MTU を 16 の倍数に切り下げます。切り下げによって underlay MTU の一部が使えないまま残りますが、これは padding ではなく未使用の headroom として報告します。最大サイズの inner packet では padding は発生しないため、underlay から inner への MTU 減少量は、カプセル化が実際に wire に載せるバイト数より大きくなります。設計モードでは両方と、結果として得られる外側 packet サイズを表示します。IPv6 の underlay または inner MTU が 1280 を下回る構成は reject します。そのようなリンクは IPv6 より下の層での link-specific fragmentation を必要とし、それは MSS を小さくする話ではなく tunnel 実装側の性質だからです。リバースモードは固定ヘッダだけを戻した計算値を表示したうえで、そのIPバージョンが要求する最小リンクMTUまで必要値を引き上げてから underlay と link の要件を組み立て直します。IPv6 で目標 MSS 536 でも必要なリンクは 1280 バイトです。この大きな MTU が引き上げるのは MSS Option が使える上限 (1220) であって、実際に広告する値ではありません。RFC 9293 が求めるのは MSS Option が MMS_R − 20 以下であることだけなので、536 は引き続き送出可能な値です。目標値とこの上限は別の行として表示します。制限: ESP transport mode、GRE の任意 key/sequence field、スタックした tunnel の層ごとの outer family はモデル化していません。必要な場合は追加オーバーヘッド欄を使ってください。