要約

  • RFC 1191 の IPv4 PMTUD では source が Don't Fragment を設定し、転送できない router が next-hop MTU を ICMP で返す。router は制約を観測し、endpoint は推定値と送信方針を変更する。
  • RFC 2923 は ICMP が戻らない black hole を記録した。TCP handshake や小さな packet は通っても、大きな segment から止まる。MSS は path 全体の測定値ではない。
  • Cloudflare の2015年事例では、TCP と ICMP の ECMP hash が異なり、有効な警告が接続を担当しない backend に届いた。組織まで到達することと、正しい state まで到達することは別だった。
  • PLPMTUD と DPLPMTUD は endpoint が probe と delivery confirmation で size を探せるようにした。ICMP 依存を減らす代わりに、traffic、state、loss interpretation の負担が endpoint 側へ移った。

1280への縮小は、限界が不明だったからではない

Cloudflare は2015年2月、IPv6 tunnel を利用する少数の user から接続問題の報告を受けたと説明した。同社は応急措置として IPv6 MTU を1280に下げた。この数字は、未知の path を解明した結果ではない。IPv6 が保証する最小値に退避し、壊れた evidence channel への依存を減らす選択だった。

内部では ECMP の利用が拡大していた。TCP packet は source/destination の IP と port からなる tuple で hash され、同じ connection は同じ backend に届いた。一方、ICMP は source と destination の IP だけで振り分けられたと Cloudflare は記す。

その結果、Packet Too Big は別の server に入ることがあった。同社は、それが実際に起きたと明記している。control message は network から消えたのではない。意味を持つ state との関係だけが失われた。

Cloudflare は IPv4 で RFC 4821 probing も有効にした。さらに、IPv4 fragmentation-needed と IPv6 Packet Too Big を capture し、Ethernet broadcast で全 backend に配る pmtud daemon を公開した。

repository の default rate limit は一つの source につき毎秒1 packet、一つの interface につき毎秒10 packet だった。これは安全性の証明ではない。connection-specific な evidence を共有物へ変えると、検証、容量、abuse control という新しい運用責任が生じることを示す。

576という安全策にも、見えない費用があった

RFC 1191 は1990年、Path MTU を source から destination までの hop にある MTU の最小値と定義した。route が変われば最小の link も変わる。tunnel が header を追加すれば、original packet に残る余地も小さくなる。

それ以前の保守的な方法は、576 octets と first-hop MTU の小さい方を選ぶものだった。未知の path に大きな packet を押しつけない利点がある反面、広い path でも小さく送ることになる。途中にさらに狭い hop があれば、IPv4 router はなお fragmentation を行う可能性があった。

fragmentation は調整を network 内へ移す。router が datagram を分割し、destination が再構成する。fragment の一つが失われるだけで元の datagram が使えなくなる。RFC 8900 が後に整理したように、stateful device、filter、tunnel、非対称 path も脆弱性を増やした。

当時の選択肢は、常に小さく送る、router に分割させる、path から明示的な制約を返す、あるいはそれらを組み合わせることだった。RFC 1191 は、routine fragmentation を避けつつ実際の path capacity に近づくため、明示的な feedback を選んだ。

RFC 1191が作った二つの権限

classic IPv4 PMTUD では source が Don't Fragment を設定する。next hop へそのまま転送できない router は datagram を捨て、ICMP Destination Unreachable の fragmentation needed code を返す。

RFC 1191 はその message に next-hop MTU を入れるよう求めた。host は path estimate を下げる。小さく送ることも、DF を外すこともできるが、その policy を router が代わりに決めるわけではない。

router が持つのは local interface の直接観測である。endpoint が持つのは packetization と transport の決定権である。どちらも相手の control surface を操作できず、ICMP だけが evidence と corrective power を結んだ。

逆に size を上げる判断は ICMP に委ねられなかった。大きな値を告げる message を受けても estimate を増やしてはならず、後で自ら probe する。RFC 1191 は減少後、少なくとも5分、推奨10分を空けるよう述べた。

これは歴史的 guidance であり、現在の全 stack の動作ではない。ただし意味は明確だ。route は変化し、control message は古くも偽にもなり得る。local observation を永続的な許可へ変えてはならない。

IPv6はrouter fragmentationをなくし、sourceの責任を強めた

現行の IPv6 base specification は、各 link が1280-octet packet を運べるか、IP より下で fragmentation/reassembly を提供するよう求める。IPv6 router は転送中の packet を fragment しない。Fragment header を付けられるのは source だけである。

RFC 8200 は1280を超える capacity を利用するため PMTUD を強く推奨する。一方、minimal implementation は1280以下だけを送ることもできる。これは discovery から退く合法的な方法だが、より広い path を使い切らない可能性がある。

RFC 8201 では転送不能の router が ICMPv6 Packet Too Big を返す。endpoint は、message が引用する packet が自分の送信したものか検証しなければならない。有効な message なら estimate を下げられるが、1280を下回ってはならない。

PTB で size を上げることも禁止される。減少後の上向き probe は5分より頻繁にせず、10分が推奨される。router の authority は制約の報告までで、context の検証と retention は endpoint に残る。

RFC 4890 は Packet Too Big を firewall が drop してはならない ICMPv6 traffic に分類した。communication の成立や維持が妨げられるからである。これは firewall guidance であって、全 operator が従う証拠でも、全 ICMP を無条件に通す要求でもない。

black holeで消えたのはMTUではなく説明だった

RFC 2923 は2000年、すでに長く知られていた PMTUD black hole を記録した。router、kernel bug、configuration、firewall によって ICMP error が source へ戻らず、endpoint は大きすぎる packet を送り続ける。

TCP は症状を部分的な成功に見せる。小さな SYN で handshake は通る。初期の data も動く。大きな segment が現れた時点で drop され、retransmission は同じ size を繰り返す。RFC の FTP 例では、小さな control connection は成功し、bulk transfer が止まる。

しかし、これは診断の入口でしかない。congestion、corruption、非対称 policy も同じ loss pattern を作れる。packet size、IP family、DF/Fragment、retransmission、引用された ICMP を記録しなければ MTU と断定できない。

TCP MSS も path の代替測定ではない。receiver が受け取れる TCP payload の上限を示すもので、forward path の全 tunnel を観測しない。reverse path が同じとも限らない。

RFC 2923 は可能なら ICMP black hole 自体を直すことを望んだ。endpoint が timeout 後に小さく送る検出方法もあるが、回復まで数秒を要し、他の flow に残る path defect を隠すことになる。

filterする権限は、pathを証明する権限ではない

operator には自分の network で filter policy を定める正当な権限があり得る。残された資料から、特定の firewall や provider に違法性、悪意、私的動機を帰すことはできない。

検証可能な境界は別にある。Packet Too Big を落としても、original packet が転送可能になるわけではない。filter は制約を残したまま evidence を消す。adaptation を事実上 veto できても、link の知識や transport の責任を得たわけではない。

tunnel は endpoint が size を決めた後で header を足す。ECMP と anycast は data と error を異なる instance へ送ることがある。MTU という数字は、time、direction、flow、encapsulation と結びつけなければ prefix の恒久的属性にはならない。

address-resource holder にとっても同じである。RIR は number resource を配分するが、holder への全 route の end-to-end MTU を保証しない。ASN、prefix、service IP が不変でも、tunnel や firewall の変更で大きな packet だけが失敗し得る。

PLPMTUDは沈黙をprobeへ置き換えた

RFC 4821 は2007年、packetization layer が size を段階的に probe する方法を定義した。delivery/loss feedback を endpoint 内で使うため、ICMP が届かなくても探索を続けられる。

ただし loss の意味は一つではない。大きな probe だけが孤立して失われれば MTU limit の証拠になり得る。周辺の packet も失われていれば congestion などを排除できず、結論は保留になる。search state と timer が必要になる理由である。

IETF PMTUD Working Group charter は旧 PMTUD の weakness を新しい link や tunnel の deployment に対する慢性的障害と記し、小さく始めて ICMP に依存せず上向きに probe する方針を掲げた。これは institutional work scope の記録で、universal consensus や adoption の証明ではない。

RFC 8899 は datagram packetization layer に方法を広げた。DPLPMTUD は size を試し、delivery confirmation があれば confirmed size を上げ、black hole を検出すれば下げる。validated PTB は利用できるが、それだけに依存せず、size の増加には使わない。

UDP 自身には acknowledgement がない。そのため application か packetization layer が probe の到達を確認する。ICMP 依存を減らす代償として、endpoint software が traffic、state、loss interpretation を引き受ける。

現在の制度は置換ではなく併存である

現行 TCP specification は PMTUD を強く推奨し、PLPMTUD も推奨する。小さな fallback size は残るが、RFC 9293 は performance への負担を指摘する。endpoint probing は router feedback を廃止せず、silence からの出口を加えた。

現在の Linux documentation では tcp_mtu_probing=0 が probing 無効、mode 1 が ICMP black hole 検出後に有効、mode 2 が base MSS から常時有効である。documented probe interval の default は10分である。

これは global deployment の測定ではない。installed software が異なる operator choice を持つ証拠である。firewall、tunnel、kernel、transport、application が同時に入れ替わらないことが lock-in を作った。

RFC 8900 も fragmentation を deprecated にはしなかった。fragility を整理し、upper layer に依存軽減を求めた。結果として explicit signal、validation、endpoint probing、conservative fallback が同時に残った。