要約

  • RFC 793はTCPヘッダーの6ビットを予約し、送信時にゼロとするよう定めた。
  • RFC 3168はそのうち2つをECEとCWRに割り当て、明示的輻輳通知に使った。
  • RFC 9293は4つの予約ビットを残し、未実装の将来ビットを送信時にはゼロ、受信時には無視するよう求めている。

ルールに守られた空白

1981年のRFC 793は、Data Offsetの直後に6ビットのReservedフィールドを置いた。Data Offsetはペイロードの開始位置を示す。一方、Reservedフィールドは将来利用のために確保され、値はゼロでなければならなかった。これは隠れたオプションでも、ヘッダーを延長する仕組みでもない。

この指定によって、TCPセグメントの基本的な形は保たれた。送信側はローカルな意味を勝手に作れず、受信側は安定した基礎レイアウトを扱えた。空間は不活性だったが、後の標準化に使える形で可視化されていた。

2つの位置に輻輳の意味が入る

2001年のRFC 3168は、ビット9をECE、ビット8をCWRに割り当てた。ビット4から7は予約のまま残った。つまり、新しい機能は既存のヘッダーを再利用し、基本ヘッダーの境界を動かさなかった。

動作は連鎖する。輻輳したルーターは、損失だけに頼らず、IPパケットをCongestion Experiencedとしてマークできる。受信側はTCPのACKでECEを立て、その通知を送信側へ返す。送信側は輻輳に応じ、輻輳ウィンドウを縮小した後、CWRを立ててその処理を知らせる。

RFC 3168は、TCP接続の確立時にECN対応を交渉することも求める。ビット位置が存在するだけでは、両端がその意味を利用できることにはならない。

現在の規則は送信と受信を分ける

RFC 9293はReservedフィールドを4ビットとしている。実装していない将来機能については、生成するセグメントで該当ビットをゼロにし、受信時には無視しなければならない。ゼロ送信は偶発的・私的な信号を防ぎ、無視する規則は未知のビットだけを理由に基本セグメントを拒否することを防ぐ。

割り当ての境界はIANAのTCP Header Flagsレジストリが管理する。RFC 9293では、CWRとECEが従来の6つの制御フラグとともに記載され、オフセット4から7は将来用に予約されている。予約位置の意味は自由解釈ではなく、公開仕様と管理された割り当てに依存する。

この仕組みから言えないこと

1981年の予約がECNを具体的に予見していたとは言えない。言えるのは、将来の制御用途に位置を残し、後の標準がそのうち2つを特定の輻輳通知に使ったという範囲である。

予約ビットだけで展開も保証されない。実装の遅れや中間装置の異なる前提があり、新機能には交渉、状態機械の変更、運用上の証拠が必要になることもある。引用したRFCは、こうした摩擦を定量化していない。

出典