要約

  • Shim6は通信するホストに経路の文脈を持たせ、状態型NAT64は変換装置にフロー対応を持たせ、rLEDBATはTCP受信側に送信量を制御する役割を置く。
  • 状態の場所は、故障を最初に見つける機器と、調査時に必要なログを決める。この比較は共著の文書から得た編集上の見方であり、Marcelo Bagnuloの個人的な設計思想として語られたものではない。

ログの先にある決定点

アプリケーションから見れば、通信は続くか、切れるか、遅くなるかのどれかだ。ネットワーク側では別々の出来事が起きている。複数回線を持つ拠点で一つの経路が使えなくなることもあれば、IPv6専用の端末がIPv4のサーバーを呼び出すこともある。バックグラウンド転送が、応答性を保ちたい通信と同じ待ち行列を使う場合もある。これらを「継続性」の一語にまとめると、どの機器が情報を持ち、何を判断できるのかが見えにくくなる。

プロトコルにおける状態とは、次の判断を可能にする情報だ。通信相手の識別子と現在使えるアドレスの関係、変換前後のパケットの対応、受信側が許容する未完了データ量のように、仕組みごとに意味が違う。状態がどこにあるかを追うと、監視すべき機器、権限を持つ担当チーム、故障時に集める証拠が明確になる。

ルーターを見ているチームは、ホスト間で保持された経路文脈まで見ていないかもしれない。IPv4サーバーの運用者は、変換装置が戻りパケットに使った対応表を知らないかもしれない。送信側の担当者は、受信端末がTCPウィンドウを小さくした理由を見落としうる。エラーが表面化した機器と、原因を作った機器は一致しない。

Universidad Carlos III de Madrid（UC3M）は、同大学のテレマティクス工学部門に所属する Marcelo Gabriel Bagnulo Braunと、学術・プログラム上の役割を紹介している。RFCや研究論文では、Bagnuloは他の研究者・技術者と共に署名している。著者欄は共同作業への参加を示すが、単独発明や個人の動機まで証明するものではない。

ここでは人物の信条を推測する代わりに、Bagnuloが共著者として関わった文書を、状態が置かれる三つの位置から読む。これは記事の分析軸であり、本人が三つの技術を一つの理論として説明したという意味ではない。

Shim6：ホストが経路の文脈を持つ

IPアドレスは、上位層が通信相手を識別するためにも、ネットワークがパケットを転送するためにも使われている。複数の事業者につながる拠点は、各事業者から割り当てられた複数のIPv6プレフィックスを持つことがある。すでに始まったTCP接続の経路が故障したとき、使用中のアドレスそのものを交換すれば、接続側の識別まで変わってしまう。

2009年のRFC 5533は、Erik NordmarkとMarcelo Bagnuloの共著によるShim6を定義する。これはトランスポート層の下でIPv6ロケーターを切り替えるための仕組みだ。通信するホスト同士で文脈を確立し、最初のロケーター対が使えなくなった場合には別の対を試せる。文書は、拠点の一部の回線や上流で障害が起きた場合に既存通信を維持することを目指し、事業者非依存のプレフィックスをグローバルな経路表に出すことを前提にしない。

この設計では、上位層が使う識別子を維持したまま、その下で実際の転送に使うロケーターを変更できる。どの経路にパケットを載せるかという判断は、アプリケーションから切り離される。ロケーターと識別子の対応を保持するのは端末側であり、経路の変更をサイト全体のルーターだけに委ねるわけではない。

端末に状態を置くことで、個々のホストが持つインターフェース情報を活用できる。一方、通信の両端が互換性のある実装を備え、同じ文脈を扱えることが前提となる。障害の検出、代替ロケーターの到達性確認、変更後の通信の照合も必要だ。RFC 5533は到達性の確認などを関連する仕組みに分けている。端末に別のIPv6アドレスが表示されても、それだけで特定の相手との既存通信が切り替え可能だとは判断できない。

Shim6の適用範囲には境界がある。文書が対象とするのは、複数経路の一部に起きる障害や、管理可能な速度で進むプレフィックス変更などだ。全ロケーターが同時に無効になる改番や、あらゆる移動性を乗り越えるものではない。また、上位層の識別子に使っていたアドレスが無効になったあとも通信を続けると、プレフィックスの再割り当てに伴い相手の識別が曖昧になるおそれがある。この場合、通信は終了させる必要がある。

この境界は「長くつながるほど優れている」という単純な考え方を防ぐ。接続を継続する価値は、正しい相手との通信であることが保たれて初めて成立する。運用担当者は以前のロケーター対、代替先の試験結果、文脈の回復時間、相手側に見えた変化を記録したい。利用者が一時的な遅延しか感じなかったとしても、その下では経路が切り替わっている可能性がある。

そのため、Shim6の意味は「端末にすべてを任せること」ではない。ある条件のIPv6マルチホーミングにおいて、経路と通信識別子の関係をどこで持つかを明示したことにある。端末側の互換性と可観測性が必要になる一方、経路変更をアプリケーションに見せずに済む場合がある。評価は拠点の回線数ではなく、対象となる端末の組み合わせと、実際に試した障害条件に基づくべきだ。

NAT64：変換装置が二つのアドレス空間を結ぶ

IPv6しか使えないクライアントが、IPv4のみで動くサーバーに接続したい場合、状態型NAT64はパケットを変換する。DNS64と組み合わせれば、クライアントは合成されたアドレスを通じて変換装置に到達できる。サーバーからの応答を元のクライアントへ返すため、変換装置はフローの対応を覚えていなければならない。

RFC 6146は、Marcelo Bagnulo、Philip Matthews、Iljitsch van Beijnumの共著で、UDP、TCP、ICMPの状態型変換を定める。複数のIPv6クライアントは一つ以上の公開IPv4アドレスを共有できる。往復パケットの変換に必要な対応とセッション状態は、ホストではなくネットワーク上の変換サービスに置かれる。

この中間配置により、クライアントとサーバーを一度に改修しなくても通信できる。その代わり、変換サービスが止まる、状態が失われる、資源が不足するなどすれば、端末自体は稼働していても通信が維持できないことがある。クライアント、サーバー、変換装置の記録はそれぞれ違う側面を示すため、担当チームは三つを対応づけて調べる必要がある。

ここではNAT64を状態の置き場所の比較対象としてだけ扱う。公開IPv4のプール管理やポート帰属、フィルタリング政策は、別のBTW記事が対象としている論点だ。本稿で焦点を当てるのは、変換装置がIPv4とIPv6の通信をつなぐ記憶を持つこと、そして障害の説明がどのチームの観測記録に依存するかである。

rLEDBAT：受信側から速度を調整する

バックグラウンド転送が共有回線の待ち行列を占有すると、応答性が必要な通信に影響する。通常は送信側が輻輳のフィードバックに反応する。rLEDBATは、受信側がTCP受信ウィンドウを調整することで、rLEDBAT専用の送信側実装なしに未完了データを抑えられるかを検討する。

RFC 9840は、2025年9月にIRTFのInternet Congestion Control Research Groupから実験的RFCとして公表された。受信側はTCPタイムスタンプなどの到着情報を使い、キューの遅延を推定して受信ウィンドウを調整する。送信側がウィンドウを越えてデータを送ることはできないため、受信側が既存のTCP機構を通じて転送に影響を与える。

受信端末は、自分のアプリケーションの応答性を守りたくても、遠隔送信側のソフトウェアを管理できないことがある。そのとき受信ウィンドウは一つの制御手段になる。ただし、受信側が経路全体を見ているわけではなく、送信側の輻輳制御を置き換えるわけでもない。パケットの時刻、端点間のクロック差、損失と再送、すでに転送中のデータなどを考慮しなければ、抑制の効き方が変わる。

2023年のComputer Networks論文は、Bagnuloらが共著者としてrLEDBATを実装・実験評価した内容を報告している。論文中の実験条件では、送信側主導のLEDBAT++と同様の結果が得られたとされる。これは設定された実験の結論であり、あらゆるアクセス回線や端末で同じ性能が得られることを示さない。

RFC 9840は公表時点の実装・展開状況として、Windows 11、Windows Server 2022、Appleのシステム、Linux、ns-3、Microsoftのサービスを挙げている。ここで確認できるのは、RFCがその時点の状況として何を報告したかだ。各製品の現行版や個々のサービスを本稿が独立に監査したわけではなく、すべての負荷に対する性能保証でもない。

この場合、診断の入口も受信側へ移る。送信側でスループットが下がって見えても、受信側がウィンドウを縮めていた可能性がある。受信スタックの版、ウィンドウ履歴、遅延推定、再送を時間順に照合すれば、送信側の問題なのか、受信側のポリシーなのか、経路の混雑なのかを切り分けやすくなる。受信側に制御を置いても、経路全体を把握できるとは限らない。

RFCから運用証拠へ

RFC 6417は、Peter Eardley、Lars Eggert、Marcelo Bagnulo、Rolf Winterが2011年に共同執筆した、研究成果をインターネット標準化に結び付ける際の考え方を論じる文書だ。課題の設定、変更が必要なノード、段階的導入、実装作業や運用への配慮を扱う。公開区分はInformational Independent Submissionであり、IETFの拘束力ある規則や標準化仕様ではない。同文書は、公開されたプロトコルが必ず使われるわけではないと述べるが、ここで扱うShim6、NAT64、rLEDBATの導入実績を保証してはいない。

UC3M研究ポータルは、BagnuloをPIONEERS-6Gの主任研究者として掲載している。公開期間は2026年5月から2029年4月までで、地上・非地上ネットワークをまたぐ、省電力で安全かつレジリエントなIoT接続基盤を開発・検証するのが目標だ。これは計画上の目標であり、すでに稼働するプラットフォームや、過去の三つの仕組みの採用が確認されたという意味ではない。

過去の仕様と現在の研究を同じ「連続性」の問題に重ねても、直接の技術的継承まで証明されるわけではない。各文書が示すのは、それぞれ異なる場所で状態を使う設計と、公開された範囲の証拠だ。実運用者にとっては、採用のラベルよりも、現場でどの端末が対応し、どの故障を試し、状態の変化をどのログで追えるかの方が重要になる。

三つの配置からわかるのは、常に優れた置き場があるわけではないということだ。ホストは自分のインターフェースを把握し、中間変換器は両側のアドレスを対応づけ、受信側は自分が引き受けられるデータ量を制御する。それぞれが得意な観測と、別の当事者に残す責任がある。サービスを止めないと約束する前に、どの機器が何を覚えているのかを確かめる必要がある。

出典