要約

  • RFC 9897 は MP-DCCP のネゴシエーション、アドレス通知、既存接続への追加サブフローの認証参加を規定する。
  • MP_CONFIRM と MP_JOIN が示すのは限定された制御事実であり、スケジューラーの利用、時間内の受信、並べ替え、切替成功、アプリの耐障害性ではない。

運用画面は緑だ。二本目のサブフローはハンドシェイクを終え、Connection Identifier は一致し、HMAC は最初のフローを開いた当事者に参加を結び付けた。ところがサービス責任者が「主経路が劣化したとき、どの重要データグラムがこの経路を通ったのか」と尋ねると、制御ログは沈黙する。

RFC 9897 は 2026 年 1 月に Proposed Standard として公開され、RFC Editor の記録がその身元を確定している。これは RFC 4340 の DCCP を拡張する規格である。基礎となるサービスは輻輳制御付きの信頼性を保証しないデータグラムのままだ。複数の DCCP サブフローを一つの接続として見せても、信頼できるバイトストリームにはならない。

最初のサブフローは Multipath Capable 機能を交渉し、ホスト固有の鍵材料を交換する。後続フローは MP_JOIN、相手の Connection Identifier、新しい nonce を送り、MP_HMAC により元の接続の当事者であることを確かめる。任意のフローによる自己申告を排除する重要な仕組みだ。しかし、参加が正しいことと、アプリのどのパケットがそこへ割り当てられたかは別である。

アドレス通知はさらに手前の事実だ。MP_ADDADDR はアドレスと任意のポートを通知し、HMAC とシーケンス番号で保護される。受信側はその情報を保持しても捨ててもよい。MP_CONFIRM はオプションの交換を確実にするが、RFC は受信後の処理を確認の対象外としている。通知確認はサブフロー確立ではなく、確立もデータ面での利用ではない。

この境界は意図的である。MP-DCCP は接続単位のシーケンス番号、RTT 情報、経路優先度のヒントを渡すが、送信スケジューラー、受信側の任意の並べ替え、サブフローをいつどの順序で追加・削除するかは端点に残す。最大サブフロー数を交渉する手続きさえなく、実装が資源制限を設ける。

サービスの性質は、そのローカル判断で決まる。モビリティ戦略は主経路が不適切になれば代替経路を試せるが、最適な送信元・宛先の組を選ぶ規則は実装事項だ。並行利用ではパケットごとの選択、輻輳制御、必要なら並べ替えが結果を作る。複数サブフローが同じボトルネックを共有することもあり、本数は独立した障害領域や容量増加を保証しない。

セキュリティの範囲も限定される。RFC 9897 は参加と一部の制御信号を鍵モデル内で守るが、アプリに必要な暗号学的保証をすべて内蔵しない。そのため DCCP 上の DTLSなどのエンドツーエンド保護を挙げる。Address ID もあらゆるミドルボックス問題を消せない。DCCP-UDP は通過用のカプセル化を定めるものの、RFC 9897 はそれを MP-DCCP の範囲外とする。

用語と信号の発想は RFC 8684から借り、経路数の制限では RFC 8041を参照する。これは背景資料であり、MPTCP の配送特性や運用経験を MP-DCCP に移す根拠ではない。IANA の DCCP パラメータは Feature 10、Option 46、version 0、各サブオプションの正規割当を示すが、実装や正しい利用を証明しない。

必要なのは四つの台帳を接続することだ。制御台帳には能力交渉、通知、確認、参加、nonce、鍵種別、終了とフォールバックを残す。経路台帳にはスケジューラー判断、4 タプル、輻輳制御による送信許可、時刻、損失、共有ボトルネックを残す。受信台帳には到着、欠番、遅着、並べ替えを記す。サービス台帳には切替、遅延、継続、集約という具体的目標を達成したかを記す。

Heng Lu の最小初期仕様は、万能スケジューラーを RFC に固定しない理由を示す。共通の相互運用層を薄く保ち、将来の判断を観測・撤回できる現場に置く。動くコードの優位は実パケットとサービス結果を要求し、現実の層は制御ログの認証済み記号が後段の結果を支配することを防ぐ。

規格は二本目の経路に規律ある参加方法を与えた。耐障害性が始まるのは、証拠が参加の先まで続いたときだけだ。

Sources