TIPTOP WG @ IETF 126 セッションまとめ

日時: 2026年7月22日 09:00–11:00 CEST / Grand Klimt Hall 1（120分・1セッション）
Chairs: Padma Pillay-Esnault、Zahed Sarker / Technical Advisor: Marc Blanchet / INT AD: Éric Vyncke
参加者: 投票終了時点で86名
情報源: セッションスライド全9件、録画の文字起こし、投票結果

1. ドキュメントステータス

Chairs スライドで2点が報告されました。採択コールの過程で IPR が特定されたが開示されていない件、およびアドレス空間については提案が2件あり、採択コール後も採択に至っていない件です。後者が今回の目玉の議論になりました。

2. WG ドキュメント

2.1 draft-ietf-tiptop-usecase（-01 → -02）— Marc Blanchet

**新設された Section 4「Connectivity Scenarios」**が最大の変更点です。他のドキュメント（特にプロトコルプロファイル）が同じシナリオ記述を繰り返さずに参照できるよう、2文字の略号で名前付けされました。

略号	シナリオ	特性
CS	地球 ↔ 航行中の宇宙機	Voyager 等
LF	地球 ↔ 月・完全接続	片道遅延約1.3秒。月低軌道コンステレーション+OISL で 3GPP 6G 地表網を収容する想定
LI	地球 ↔ 月・間欠接続
MF	地球 ↔ 火星・完全接続	片道遅延 4–24分
MI	地球 ↔ 火星・間欠接続	例：約6時間ごとに1回のパス
SC	太陽合（Solar Conjunction）	火星の場合約26か月ごとに約2週間の全断。数年前から予測可能。地表・周回機のローカル通信は影響なし

Marc は、月コンステレーションによって近い将来「間欠が例外」になる可能性があるため、LF と LI の両方をプロファイルでカバーする必要があると説明しました。

要件セクションの追加分

非同期動作と省電力モード: 送信機オフ／受信機オン、あるいはノード自体がスリープという状態。store-and-forward があれば、宛先が受信していなくても後から届く。「非同期」の意味が地上インターネットとは異なる点を明記し、鍵交換も非同期で成立すべきとした
エネルギー: 制約側からの送信を最小化し、その分を潤沢な側に負担させる非対称な振る舞いが必要になりうる
Store-and-Forward: ネットワーク層でのストレージ（送信時点で転送判断を再評価）と、現行の火星リレーがやっているフレーム下層での "bag of bits" 蓄積との違いを説明。ストレージ DoS 対策として認証・認可・送信元ごとのアカウンティングを追加

スコープ／用語の明確化: 3GPP NTN（RTT がミリ秒〜数百ミリ秒、基本的に連続接続）はスコープ外だが、同じ NTN 技術を他の天体の低軌道で使い地表・軌道資産を収容するケースはスコープ内、と整理。新用語 "surface network"（地表付近の資産、IEEE 802.11 / 3GPP 系リンク、居住区・着陸機・ローバー・クルー装備。ドローンやホッパーも地表資産扱い）を追加。

Security Considerations に3段落追加

非同期な鍵確立・更新（長 RTT ＋間欠下では対話的な再鍵で危殆化鍵が長期間使われる窓が生じる。事前確立や非対話的な更新を選好）
前方秘匿性と post-compromise security を別物として整理（深宇宙資産は物理アクセス不可のため、遅延・間欠下で動作するリモートのトラストアンカー／クレデンシャル更新が必要）
グループ鍵管理（宇宙服の無線ネットワーク、宇宙天気アラート、LunaNet Augmented Forward Signal のようなブロードキャスト航法情報）

ユースケース側の更新: 緊急・SAR トラフィックは有効期限による破棄をせず、ストレージ枯渇時も最優先で保持／キュー長と宇宙用ハードウェアの厳しいメモリ制約／太陽合の約2週間でリレー・周回機のストレージが埋まる問題（容量計画と送信元スロットリング、NASA の有人火星通信ブラックアウト研究を参照追加）／NASA の月南極 Moon Base プログラム／火星の太陽合周期を約26か月（会合周期）に訂正。

議論: Erik Kline から、チャーター策定時に store-and-forward の記述が Bundle Protocol の領域に近づきすぎないよう配慮した経緯があるが、今回の記述はどうか、という指摘。Marc は前バージョンで切り分けを明確にしたつもりなので、読んでコメントが欲しいと回答。Zahed は「このドキュメントが要件と用語の共通基盤になるので、-02、特に要件のフレーミングを必ずレビューしてほしい」と強く呼びかけました。

2.2 draft-ietf-tiptop-ip-architecture — Wesley Eddy

WG 採択済みで、「宇宙ネットワーキングにおいて IP アーキテクチャが地上とどう異なるかを文書化する」というチャーター項目に対応。前回会合以降の変更は、アドレス空間に関する記述の微調整、PCE の明確化（ドメイン内でルーティング判断を集中させる方式について、Tony と Padma のリスト上の議論を受けて記述を拡張）、Security Considerations の用語と攻撃タイプの明確化、および Padma のレビューによるエディトリアル修正です。

RIR ポリシーガイダンスの扱いが最も議論を呼んだ点。TIPTOP リストのみならず RIPE と ARIN の場でも議論が行われ、draft-kumari が draft-li に加わりました。エディタの立場は「両提案の合意領域（宇宙用アドレス空間は必要で、集約を促すポリシーで管理されるべき）だけを書き、具体的ポリシーは本文書外で独立に進める」というもの。どちらの提案とも互換であり、アーキテクチャ的にはどれが採用されても影響しない、としました。

Éric Vyncke（AD と個人の両方の立場と断りつつ）は、「集約を最大化するために……」という中間の示唆的な一文を削除し、実際の要件部分と「潜在的なアプローチが議論されている」という部分だけを残してほしいと要望。Wes は対応可能と回答しました。

Zahed は今後2週間以内のレビュー志願者を募り、Éric ほか数名が挙手。チャットで活発だった George にも期待、としました。

3. Non-WG ドキュメント

3.1 アドレス空間 — 構造化ディスカッション

Chairs は今回、両提案者に基本思想を短く提示させた後、二人を壇上に残したまま合同討議を行う形式を採りました。

draft-li-tiptop-address-space（Tony Li / Marshall Eubanks）

目的はルーティングの最適化と最大限の集約。現在の DFZ が100万経路を抱えている状態を宇宙に持ち込みたくない、という動機です。天体ごとに連続ブロックのプレフィックスを割り当て、それを単一の RIR が管理する。混乱を最小化でき、そもそも要求レートは低い（年10件程度）という主張。

IETF 125 からの変更は、アーキテクチャドラフトへの参照追加、小惑星帯用プレフィックス要求の削除（どう集約されるか不明なため、将来のミッションが見えるまで先送り）、プレフィックスサイズとタイミングを管理 RIR に明示的に委任、の3点。「Warren のコメント以外はすべて対応した」と述べました。

質疑では Rick Taylor が「月軌道から小惑星帯へ移動したらどうなるか」と質問し、Tony は「アドレス的には無関係、ホストルートになるだけ」と回答。続けて Rick は「技術的な仕組みは完全に理解できるが、地政学がどう機能するのかが分からない。これが阻害要因であり、全体として nonstarter だと思う」と述べ、Tony は「地政学は排除したい。中立的な第三者が必要で、それが誰かは問わない」と応じました。

Jim Reid は、RIR がアドレス要求をどう認証・検証するのか、宇宙機関の中で誰が正しい窓口かをどう知るのかを質問。Tony は「RIR は既にそれを日常的にやっている」と回答しましたが、Jim は ENUM で各国の電話番号レンジの権限保持者を特定するのが困難だった経験を挙げて反論しました（Tony は「電話番号は RIR が割り当てていない」と返答）。

draft-kumari-tiptop-address-space "Addressing the Final Frontier"（Warren Kumari）

Warren はまず「両提案の距離は思われているほど大きくない」と前置きした上で、単一プレフィックス・単一 RIR は美しいが、世界はもっと醜く厄介であると論じました。天体上には競合する国家・民間企業・NGO が併存し、インターネットは政治と無縁ではなく、宇宙はより戦略的資産であるため政治の影響はむしろ強まる、と。

決定的な論点は「アドレス空間を取得できない組織はミッションを諦めるのではなく、単に自分の地上アドレス空間を宇宙で使う」——結果として集約は破綻し断片化する、というものです。

具体例として米国大統領令 14024（ロシアの航空宇宙・電子・海洋分野への経済制裁）を挙げ、米国の RIR が現実的にロシアにサービスできない状況を提示。RIPE 配下では制裁対象国の扱いに特別な運用があり、イランには約650〜680の LIR と（スライド作成時点で）約3,600個の /32 IPv6 が存在し増加傾向、ロシアも約2,000 LIR を持つ、というデータを示しました。

提案は、IANA が大きなブロックを確保し、各 RIR がそこから引き出す方式。分割順序は「天体 → RIR」または「RIR → 天体」の2通りで、前者なら天体ごとの集約が保たれます。スライドの例示（値はあくまで例）は、IANA 4000::/3 の下に Jupiter 4000::/8、Mercury 4100::/8、Mars 4200::/8 を置き、各天体の下に RIR ごとの /11 を配置。NASA と SpaceX は ARIN から、Roscosmos は RIPE から取得しても、天体単位の集約は維持されるという図です。

経路数の比較としては、単一 RIR なら約（天体数+1）、5 RIR ならその5倍。ただし「宇宙が戦略的資産である場合」も「宇宙がコモディティ化する場合」も、結論は複数 RIR になる、と整理しました（前者は単一の捕捉点を作らないため、後者は RIR 制度を生んだ公平性・コミュニティ・スケーリングの議論がそのまま当てはまるため）。

合同討議

Hans Petter Holen（RIPE NCC CEO）: 政治的現実には Warren の案の方が近い、と評価。ただし重要な訂正として、オランダ外務省からの「特別な免除（dispensation）」というものは存在せず、制裁の解釈についての共通理解があるだけ、と説明。制裁対象は国ではなく個人・企業（およびその所有者や役員を遡って）であり、RIPE は制裁レポートを公開している。制裁は EU の政治勢力が決め、オランダ政府が実務的に実装する構造で、今後どうなるかは不明。また新しい RIR ガバナンス原則では「ある地域の RIR はその地域内に所在すべき」とされている点に触れ、それが宇宙にどう適用されるのかと問いかけました。
Kim Davies（IANA）: 今週この議論に初めて触れての最大の印象は「技術要件と、運用現実に対する設計案とが混同されている」こと。IETF と ICANN の責務分界（グローバルなアドレスポリシーの実装は ICANN 側）を想起すべきで、技術要件と実装提案を明確に切り分けてほしい。1 RIR か 5 RIR か、そもそも RIR モデルが適切かについては意見を持たない（第三の構造もありうる）し、この WG がその結論を出す場かどうかも疑問。IANA は仕様と解の中間に立つ存在になるだろうが、「成功とは何かをどう定義するのか。提案された実装を検証できる基準セットは何か」を問いました。
Tony Li: オッカムの剃刀を持ち出し、年10件程度の要求規模なら凝った仕組みは不要、と主張。
Martin Duke（Google）: 階層性についての明確化質問。木星は巨大で衛星も多く、木星系内でも光速が問題になる規模。木星ブロックが未分化のまま扱われると、将来その広大な領域でアドレスが救いようもなく断片化するのではないか。軸が2つある Warren の案の方が難しい問題では、と。Tony は「アドレッシングはトポロジに従う」という公理を挙げ、将来のトポロジが未定である以上、決めうちせず柔軟性を残す必要があると回答。Warren は木星周回軌道の RTT が120〜130秒規模になると試算した上で、「移動のたびに宇宙機をリナンバーすることはない。完全な集約は必要なく、100万経路に対して1経路か5経路かという話」と述べ、かつてボーイング機のプレフィックスが大西洋上で北米経由から欧州経由に切り替わっていた事例を引きました。Martin は SF 的な思弁になるリスクを認めつつ、「アドレスはフラグデーが難しいので、将来の IoT 規模の展開が袋小路に入る事態は避けたい」と締めました。
Padma: 「惑星ごとに独立したネットワーク」という発想は避けるべきで、リレーが複数の惑星系や近接する系を同時にサービスする構成が現実になる。問題はもっと複雑だと指摘。また、宇宙機のメモリ・処理能力は固定で「大きいルータに交換する」ことができないため、計画不足で既に飛んでいる機体を圧迫しないよう今のうちに議論する意義がある、と述べました。
Peter Koch（DENIC）: 議論の高度を上げるべき（「地政学を迂回するルーティング」は既に細部に入りすぎ）と提言した上で、核心は「ポリシー策定とポリシー執行の分離」であり、IETF はアドレスポリシー策定の経験に乏しいと指摘。さらに「これは我々が慣れ親しんできたグローバルにルーティングされる IPv6 アドレスではない」——別種のポリシーセットと配布メカニズムが必要かもしれず、RIR に紐づけることは可能でも、各 RIR 個別のポリシー策定機構をそのまま継承させたら機能しない、と論じました。まず問うべきは「この種のアドレスの配布ポリシーを設定する適切な body はどこか」であり、**IGF（Internet Governance Forum）**のような場に提案を出して該当する諸機関と広いコミュニティを集めるマルチステークホルダーな進め方を一案として提示。WG 側は、予約プールから切り出したグローバルにルーティングされない専用フレーバーを定義して引き渡し、誤った主体に掴まれないよう担保する役割、という整理でした。Warren が「IGF より NRO/ASO/既存 RIR コミュニティの方がアドレスポリシー策定の実績がある」と反論すると、Peter は「そのうち何人が別の惑星に住んでいますか（物理的に）」と応じ、会場が沸きました。Zahed は「まさにそれが我々の意図。IETF で技術・アーキテクチャの議論を行い、文書化した上でよりマルチステークホルダーな場に持ち込む」と応答しました。
Rick Taylor: RIR あるいは RIR 的なアプローチが最も適用可能な既存の仕組みだという点には強く同意。一方で単一プレフィックスには懐疑的で、運用現実としては複数になるだろうと予想。さらに地理的（天体的）集約そのものにも懐疑的で、集約されるのは商用契約の関数であって天体の所在ではない、と主張。また「まず巨大なチャンクを割り当てて後で整理する、という順序は間違っている」とも述べました。
Jen Linkova: 純粋に技術的な集約レベルで見れば、両案の経路数は同じ（どちらも天体単位で集約するため）。違いは宇宙機関がどこに取りに行くかだけ。既に関係のある RIR を使えるほうが顧客側の手続きが簡単で、そうしなければ望ましくない抜け道を取られる、と Warren 案を技術的・短期戦術的に支持。Tony は「単一 RIR なら RIR 同士が同一ブロックからの割り当てで相互運用する必要がなく簡単」と反論し、Jen は「機関にとっては、これまで話したことのない RIR との新しいプロセスを作るほうが大変」と応じました。
Tim Chown: アーキテクチャは集約の最大化を謳う一方で v4 と v6 の両方をサポートしている。v6 を集約しても v4 の残滓が散らばるのでは。アーキテクチャを IPv6 only にできないのか、それとももう船（宇宙船）は出てしまったのか、と質問。Tony は「継続中の論点。v4 にはオーバーヘッドが小さいという利点があり、宇宙機設計者がそちらを選ぶ可能性がある」と回答。
Lars Eggert（Mozilla）: 「maximize」という言葉自体が危険な目標だと指摘。最後の一経路まで削り取ることより、まずい結果を避けることを優先すべきで、最大化しない運用上の理由もありうる以上、アーキテクチャはそれを許容すべき。またアドレス空間に意味論を過剰に載せる試みは過去に数多くあり、その多くが失敗している——今見えている範囲での完璧な設計が、予見できなかった柔軟性の必要に後で足を掬われる、として柔軟性を主張しました。Peter への反論として、IGF のような極めて広いマルチステークホルダーの場でゼロから作るのは適切でないとし、RIR 関連コミュニティと IETF の人々がまず「誰も強く反対しない」提案を書き、その後 IGF のような場へロードショーに出るべき、と提案。政治的に発するべきトップラインのメッセージは「現行のインターネットガバナンスモデルは宇宙にも拡張される」だと締めました。Tony はこれに「まずい議論を避けてきた結果が IPv4 の100万経路であり、IPv6 も25万経路で同じ方向に向かっている。エンジニアリング組織としてもっと高い目標を設定すべきだ」と反発。Warren は「他のグループと話すなら、要件と望ましい形を先に文書化しておくべき。さもないと『伝書鳩を検討しましたか』と言われる」と補足しました。
Dan York（ISOC、個人の立場）: IETF の役割を明確にすべき。あの割り当て図を描くことが我々の役割ではない。「宇宙用の IP アドレス割り当てが必要な技術的理由がある（単一プレフィックスか複数かは未定）」「集約その他の理由でブロックが必要だ」と述べる文書を作り、IANA や NRO の同僚に引き渡すのが役割だ、と主張。Tony は「そして我々の目標は最大限の集約。割り当て主体を複数にすれば集約は減る」と応じ、Warren は「目標は運用上の有用性、宇宙で可能な最良のルーティングアーキテクチャ。成功の姿を定義し、実際の割り当て方法は専門家に委ねる。あの図は提案ではなく例示だ」と補足しました。Dan はさらに、最初期の主体は結局自前のアドレスブロックを使い自前のネットワークにバックホールするだろうから、当面は現実がそうなる、とも述べました。

デザインチーム形成の議論

Zahed が Tony と Warren に「デザインチームが必要か」と問うと、Tony は「デザインチームは不要、選択をすればよい」、Warren は「アーキテクチャ文書が形を記述するなら、自分たちの文書は不要かもしれない」と応答。

Éric Vyncke は「アドレッシングの決着を待たず、アーキテクチャ文書を先に RFC として出すべき。そこは曖昧なままにして、例えばグローバルユニキャストの一部かどうか、集約の重要性といった点だけ書けば十分」と主張しました。

Zahed の方針は「アドレス空間の議論はアーキテクチャから分離し、アーキテクチャは示唆だけ与えて参照する」というもので、Tony と Warren に今回の入力をまとめ、異なる割り当て案を例として併記した1つの文書にできないかと打診。Padma は、十分前もって告知した専用のサイドミーティングを開き、議事録と要件を残す形を提案し、Chairs はこれを進め方として会を閉じました。

3.2 QUIC プロファイリング

Evaluation of QUIC in Interplanetary Networks — Johannes Frisch（TU Darmstadt、修士論文）

スコープは深宇宙（地球から200万km超）のみで、地球〜火星のトポロジ（MOC / DSN アンテナ / 火星周回機 / 火星ローバー）を例として使用。GEO/LEO 衛星とシスルナ領域は対象外。目的は draft-many-tiptop-quic-profile の検証です。

手法: 離散イベントシミュレーション（アイドル時間をスキップして数時間の通信を即座に模擬でき、決定的で再現性がある）。パラメータは RTT 1–20分（実際の火星 4–21分から、ラップトップの性能制約で若干縮小）、ボトルネック帯域 2 Mbps（MRO の実績 0.5–6 Mbps の現実的な平均）、パケットロス率 0–30%（30% は自由空間光通信のみ）、リンク断 0–60分（MRO の軌道周期1時間52分のうち約1/3が火星背後で遮蔽される範囲）。ツールは Adolfo と Marc による DIPT QUIC Workbench（Rust 製の I/O フリー離散シミュレータ、RFC 適合性の高い Quinn を統合、JSON でトポロジ記述）で、PCAP と qlog からメトリクスを抽出。

結果

ベースライン成立性: 既定値のままでは接続不成立。QUIC の idle timeout 既定30秒でタイムアウトし、initial RTT 既定333ミリ秒のため Initial パケットの無駄な再送が多発。両者を調整すればハンドシェイクは成立する。ただし次にフロー制御がスループットを縛る——quinn の既定バッファ1.25 MB に対し例示シナリオの BDP は300 MB で、数学的上限が約1.04 kbps。解決策は 2 BDP 相当の受信ウィンドウとバッファ。
高 BDP と遅延: CUBIC / NewReno のスロースタートが極端に長い（BDP が既知なら初期輻輳ウィンドウの調整で緩和可能）。中間ノードのバッファが大きいとバッファブロート。遅いフィードバックループ自体は残る。
ロス耐性: ロスベースの輻輳制御は使い物にならず（CUBIC はウィンドウを縮めて崩壊）、BBRv1 のみが耐性を示す。ただし Johannes 自身が、これは Quinn に実装されていた BBRv1 に限った話であり、後続の BBR バージョンはロスをシグナルとして取り込むため同様の問題を抱えうる、と注記。
リンク非対称性: 既定では2データパケットにつき1 ACK を返すため上りが飽和し、ACK 輻輳で送信側も停止。1:20 から1:640 まで試した結果、1:20 という穏やかな比でも下りグッドプットが絞られる。ACK Frequency 拡張で 1/4、1/8 に落とすと性能が回復。
間欠接続: L3 バッファリングで30分の断を橋渡し。ACK が返らず輻輳ウィンドウが枯渇して送信が止まり、ACK 再開とともに復帰する。断の後に BBR のプロービングが乱れるのは、30分バッファされたパケットにより RTT 計測が不正確になるため。それでも転送自体は完了。

結論のプロファイル表: idle timeout と initial RTT は「物理 RTT + 断の時間」、フロー制御は ≥2 BDP、輻輳制御は BBRv1 または固定レート（当面は固定レートが実用的）、ACK frequency は帯域比に合わせてスケール。必要なのはプロファイリングのみで、プロトコル自体の変更は不要という点が主要な結論です。今後の課題は FEC、宇宙での証明書管理と長期 TLS 接続、そして真の惑星間ネットワークで動的フローに対応する輻輳制御。

質疑: Lars Eggert が「ロスはランダムか、宇宙リンクをモデル化したものか」と確認（ランダムのみ）。その上で「BBR は特定のリンクモデルを前提としているが、そのモデルが宇宙リンクに適合するのか」「宇宙では容量と送信がスケジュールされていると理解しているので、送信機会を最大限使うには CUBIC のようにパイプを埋めるものが欲しいのでは」と問い、「シミュレートしたのは理想化されたランダムロスのリンクであり、そこで BBR が適していても実際の宇宙リンクで適しているとは限らない。修士論文であって博士論文ではないので批判ではなく、この調査からさらに何を引き出したいかという話」と補足しました。Rick Taylor は非常に価値ある仕事だと評価しつつ、ボローニャ大学の Carlo Caini 教授のグループが ESA 実データを使って代替輻輳制御アルゴリズムを検討している（DTN 向け QUIC コンバージェンスレイヤも開発）ことを紹介。もう1名からは「単一の QUIC 実装に依拠すべきでない——実装によって、輻輳制御の実装によっても挙動が異なるので、WG として結果を解釈する際は幅広い実装をカバーすべき」というコメントがありました。Zahed は「天体間リンクのモデル化をもう少し詰めること」を持ち帰り事項として挙げました。

draft-many-tiptop-quic-profile -02 → -03 — Marc Blanchet

数か月にわたる構造化されたシミュレーション群（多くは再実施）に基づく大改訂。全シミュレーションは月曜のサイドミーティングで詳細に提示され、入出力ファイル一式が GitHub（github.com/deepspaceip）で検証可能な形で公開されています。

構造の再編: 接続ライフサイクルに沿って再構成し、ユースケースドラフトの接続シナリオ（CS/LF/LI/MF/MI/SC）に全推奨事項を紐づけました。-02 までの「フラットな長大リスト（買い物リスト）」を、Connection Establishment（initial RTT、careful resume、マイグレーション、0-RTT）／Connection Maintenance（idle timeout、キープアライブとミドルボックス）／Bandwidth Management（輻輳制御、フロー制御、パケットサイズ、ペーシング、パディング、PMTUD）／Reliable Delivery under Loss and Intermittence（ACK frequency、FEC、リレーバッファリング、間欠性認識）／TLS にグルーピング。新設が Keep Alive and Middleboxes、Padding、Relay Buffering、TLS、Per-Scenario Applicability、削除が Example Scenario、Moon Deployment、New Connection IDs。Informational ながら、シミュレーションが裏付ける箇所には MUST/SHOULD の規範表現を導入しました。

主な知見

接続確立: 片道遅延15秒以上では既定値でタイムアウトするため initial_rtt の設定は MUST。地球〜火星の直接接続は既定値ではハンドシェイクが決して完了しない。適切に設定すれば1往復で完了し、2日 RTT（Voyager 相当）までスケールしても正常動作。設定値は想定最大 RTT に近く、過大なマージンは掛けない。
接続維持: idle timeout の境界がシミュレーションで確認され、RTT 29.8秒は成立、30秒で切断（既定30秒）。max_idle_timeout は最長のコンタクトギャップを超えるか、その内側でキープアライブを送る必要がある。実効値は両ピアの最小値。一般的な30秒の UDP マッピングタイムアウトを持つミドルボックスは深宇宙接続を壊すため、非推奨またははるかに大きなタイムアウトが必要。
輻輳制御: 下り5%ロスの6つの regime で CUBIC と open-loop を比較。信頼性は影響なし（QUIC のロスリカバリにより全実行で100%配送）。CUBIC は連続的なロスありリンクで約1.5倍遅く（月で+46%、最接近火星で+60%）、間欠パスではさらに悪化して火星で3.6倍、コンタクトスケジュール次第では容易に10倍に達しうる。BBR は使用中の Quinn スタックに未統合のため未試験。レートベースの open-loop を推奨する方針が裏付けられ、新たに SHOULD として「送信レートを最も遅い下流リンクに合わせ、リレーのバッファリングを1パケットに抑える」を追加。
ACK frequency: 月・火星それぞれの直接／間欠パスでパラメータスイープ。ACK のバッチ化により全 regime で戻り方向の ACK パケットを80〜99%削減。安全な設定は ack-eliciting 閾値10パケット前後、max_ack_delay は RTT の約1/10。max_ack_delay を数 RTT にすると常に悪化（完了時間 +16〜+143%）。口頭で重要な補足があり、閾値を既定より上げると送信側がその分多くのデータをメモリに保持するため、メモリの限られた火星等の資産では使うべきでない場合がある。
リレーバッファリング（新設）: リレーは再起動、シングルイベントアップセット、メモリリセットで store-and-forward バッファを失いうる。QUIC はエンドツーエンドで回復するが、コストは RTT とブラックアウト長の比に依存。RTT ≪ ブラックアウト（月）ならロスプローブがバッファを埋め直し、コストはほぼ無視できる。RTT がコンタクト周期に近い（最接近火星）と1回のバッファ喪失が約1周回分のコストとなりスループットが半減。最長44分 RTT では喪失ごとに数周回。複数回の喪失（ほぼ機能していないリレー）でも回復を確認。
TLS（新設）: 証明書チェーンサイズ、0-RTT 再利用の7日制限、鍵更新のタイミング（3× PTO）を扱う。長寿命の深宇宙接続には Extended Key Update を推奨。シミュレーションでは連続的な地球〜火星で19回、間欠リレー越しで13回の前方秘匿な更新を無停止で実施。1回の更新のコストは約2 RTT・約3パケット。鍵更新は壁時計時間ではなく RTT またはコンタクト周期の単位でスケジュールすべきで、更新は store-and-forward でブラックアウトを特別扱いなしに通過。副次的な逸話として、Extended Key Update に未対応の現行 Wireshark ディセクタでは最初の鍵更新以降は復号できなくなり、それが機構が実際に働いている証拠になった、と紹介されました。
シナリオ別適用性（新設）: CS は片道15秒超で initial_rtt 必須。LF は無設定でも動くが無駄が多く BBR の方が良好。LI はスケジュールが既知なら各パスで再接続、不明なら open-loop。MF は initial_rtt 必須かつ max_idle_timeout を最大 RTT の倍数で設定。MI は1接続を複数周回にわたり維持し、22分遅延で1周回あたり約1往復。SC は合の前に graceful に閉じる（careful resume が再起動時に有効）か、合の期間を超える idle timeout で開いたまま維持。
参照更新: careful resume は RFC 9959 に、アーキテクチャドラフトは draft-ietf-tiptop-ip-architecture に。RFC 9308、BBR、TVR YANG スケジュールモデル、Extended Key Update、CCSDS coding Blue Books を追加。コミュニティによる測定（Piotrowski の "QUIC to the Moon"、Frisch の惑星間 QUIC 評価）も参照。

WG 採択の要請に対する質疑

Lars Eggert: 採択に向けて順調だとした上で、「Space QUIC」を Internet QUIC と互換でないものにプロファイルしてしまっていないか点検するパスを採択の前後どちらかで入れるべきと指摘。分かりやすい例としてパディングを挙げ、「宇宙ではパディングはオーバーヘッドかもしれないが、QUIC 仕様が MUST として要求するパディング（Initial を1200バイトへ、等）は宇宙でも交渉不能」であり、どこは変えられてどこは変えられないかについてより丁寧な記述が必要、と述べました。さらに実効的なベースラインテストとして「プロファイル適用済みの Space QUIC 実装が、インターネット上の Google や Cloudflare と依然として通信できるか——できないなら仕様適合から外れた強い兆候」を提案。加えて「QUIC コミュニティはこの作業に注目しているが、代わりに作業をするつもりはない。我々は惑星向けの QUIC をやっている」と釘を刺しました。Marc はパディングをトラフィック解析対策の文脈で RFC を引用して記載した経緯を説明しつつ、そのレンズでの見直しに同意。Zahed が互換性テストのモデルを確認し（宇宙リンク越しに Cloudflare と話すのではなく、地上で動く Space QUIC スタックが非宇宙の QUIC 相手と通信できること）、Lars もその通りだと応じました。
Alexander Pelov: この環境向けの QUIC ヘッダ圧縮にも取り組んでおり、金曜の SCHC で発表予定と告知。
Tim Chown: Security Considerations に関して、slowloris のような低速 DoS 攻撃のプロファイルになるリスクはないか、と質問。Marc はその角度からはまだ見ていないと回答しました。

採択投票: 会場で読了者は10名程度、リモートでは挙手なし。「この文書は WG 採択の準備ができているか」に対し Yes 16 / No 2 / 意見なし 22（投票終了時の参加者86名）。Chairs は No 投票の理由を聞くためマイクを開けましたが発言者なし。「採択への rough consensus あり」と判断した上で、メーリングリストで確認することとし、「意見なし」に投じた人（多くは未読と思われる）にはドキュメントを読んで判断してほしいと呼びかけました。

3.3 CoAP in Space — Carles Gomez（UPC、共著 Sergio Aguilar / Sateliot）

draft-gomez-tiptop-coap-01。番号上は -01 ですが実質6版目で、WG 発足前の deep space サイドミーティングで4版を経ています（Informational 想定）。

プレゼンの導入が巧みで、深宇宙通信の特性（長遅延、間欠的な通信機会、低帯域、非対称帯域、限られた計算資源とエネルギー）を列挙したスライドの次に、「Deep Space」を「IoT」に置き換えただけの同一スライドを出し、両者がプロトコルに課す制約は大きく重なると示しました。だからこそ CoAP のような IoT 向け設計を検討する価値がある、という論立てです。CoAP は制約ノードネットワーク向けに設計され、固定4バイトヘッダ、非同期メッセージ交換、柔軟性とセキュリティ、REST ベースで HTTP へのマッピングが容易。アーキテクチャドラフトのアプリケーション層セクションは HTTP と CoAP を扱い、CoAP についてはこの文書を明示的に引用しています。

トランスポート: 信頼性のあるトランスポート上の CoAP（RFC 8323、TCP/TLS/WebSockets）は初期ハンドシェイク、信頼性が任意でなくなる点、マルチキャスト非対応、ヘッダ増大といった深刻な問題があるため、深宇宙では本来設計の UDP 上の CoAP（RFC 7252）を推奨。メッセージ副層は CON（ACK 必須、ストップアンドウェイト、指数バックオフによる再送）と NON の2種。

深宇宙向けに調整が必要なパラメータ: NSTART（既定1）、ACK_TIMEOUT / ACK_RANDOM_FACTOR（初期 RTO が既定2〜3秒からランダム選択）、MAX_RETRANSMIT（既定4だが指数バックオフのため既定より小さい方が適切かもしれない）、MAX_LATENCY（100秒）、NON_LIFETIME、EXCHANGE_LIFETIME（247秒）——後半3つは深宇宙では増加が必須。

その他のセクション: キャッシング（プロキシがキャッシュ応答を返せばエネルギー・帯域・時間を節約。Max-Age は既定60秒、最大約136年まで設定可能で、オリジンサーバからキャッシュ端点までの想定遅延に基づいて設定）、プロキシング（CoAP-to-CoAP、HTTP-to-CoAP）、Observe（RFC 7641、都度リクエストせず通知を受け取れる）、ブロック単位転送（RFC 7959 / 9177、アプリ層フラグメンテーション）、メッセージ集約（別文書で定義中。接続の切れる区間があるため深宇宙で特に有用）、グループ通信／マルチキャスト（groupcomm-bis の MIN_TOKEN_REUSE_TIME 既定500秒超を多くの深宇宙シナリオで増加させる必要）、セキュリティ（DTLS はハンドシェイクのため深宇宙では一般に非推奨、OSCORE（RFC 8613）はオブジェクトセキュリティで事前共有コンテキストによりハンドシェイクを回避でき、プロキシ存在下でもエンドツーエンド保護が効くため推奨）。

-01 の主な追加は Appendix B——地球〜月、地球〜火星の参照 CoAP パラメータ表。時間系パラメータ（送信タイムアウト、メッセージが生存しうる最大時間、最大再送回数等）を伝播遅延成分のみに基づいて算出しており、蓄積遅延などが加わる具体シナリオでは加算が必要、と明示。地球〜月は最大距離、地球〜火星は変動が大きいため最小・最大の両方を考慮した範囲として提示されています。

Next steps: チャーターに CoAP の明示的なワークアイテムがないため採択は要請せず、「TIPTOP は CoAP ガイダンスを今後のワークアイテムに加えるべきか」を WG と Chairs に問う形にしました。

議論: Padma は、WG は QUIC から始めて他プロトコルには開かれた状態にしているがチャーターには入っていないと確認した上で、「Marc がユースケースを精密に定義したのだから、どのユースケースで CoAP が使えるか、どこでプラスをもたらすかを対応付ける作業が有益」（例えばマルチキャスト／グループ通信）と助言。Alexander Pelov は、非常に大きな遅延と強い非対称性を持つ LPWAN で CoAP を適用してきた実績を挙げ、「MOC が船上の1つのセンサーに接触するだけなら、QUIC 接続をフルに開くほどでもない」——特定のセンサーを直接読む、あるいはプロキシ経由という traffic pattern が検討に値する、と述べました。Laurent（Toutain）は、CoAP が CORECONF（YANG モデルをコンパクトに扱う）メッセージの搬送にも使われており、他惑星上の要素の制御にも有用だと補足。将来この作業を行う場合は CORE WG との調整が必要という点も確認されました。Chairs は、まずユースケースへの対応付けに注力し、その上で改めて支持の温度感を測る、という進め方を示しました。

4. 時間が許せば枠

Interplanetary hops: should path constraints be signaled to hosts? — Alexander Pelov（IMT Atlantique）

draft-pelov-icmpv6-sec-01。残り2分での発表となり、Alexander 自身が「先に解を持ってきてしまったが、そもそもこの WG が解きたい問いが存在するのかが論点」と前置きしました。

問いは「パケットが惑星間の境界を越えるとき、送信元にそれを伝える機構があるべきか」。MOC の TIPTOP エンドホストから TIPTOP フォワーダを経て他天体のエンドホストに至る経路上には多数のホップがあり、同じ計算機が複数のスタックを持ってインターネット上の他機器とも通信しうる状況を想定しています。天体ごとのプレフィックスがあれば「特定の色のパケットだけ通す」「誰がその色のパケットを送れるかを制御する」形で多くの問題は解けるが、その先に検討事項が残る、という構成です。

スライドで提示された論点は次の通り。宛先プレフィックスだけで TIPTOP 扱いすべきトラフィックを識別できるか（VPN / IP トンネル / NAT をどう扱うか）。認可されていないホストが TIPTOP プレフィックス宛に送った場合、既存の ICMPv6 unreachable コードとフィルタリング挙動で十分か（そもそも何に対して十分なのか）。そして情報提供的な signaling 機構——「あなたにはこのプレフィックスに接触する権限がない」「パケットに正しく色付けができていない（正規のソフトウェアが誤った設定、例えばタイマー設定をしている場合）」「参考までに、あなたのパケットは惑星間セグメントを通過している。その特性はこれこれ」——を用意すべきか。

動機として最も具体的なのは QUIC で、「今からあなたのパケットは惑星間リンクを通る」というメッセージを受け取ってタイマーを調整できれば、標準のインターネット QUIC スタックとの互換性を保ったまま適応できる、という点です。加えて、ある天体上に異なる RIR 由来の複数プレフィックスがあり、それらが直接ルーティングできず惑星間リンク経由になるケースにも関係します（3.1 のアドレス空間議論と接続する論点）。

Chairs は時間切れのため、関心のある人はメーリングリストで Alexander に返信するよう促して閉会しました。

全体を通した論点

アドレス空間が最大の未解決事項。技術的には両提案の経路数は同等（天体単位で集約）で、争点は「誰が割り当てるか」という地政学・ガバナンスの問題。会場の合意に近いのは「IETF は技術要件と成功の定義を書き、割り当ての実装は IANA / NRO / RIR に委ねる」という役割分担（Dan York、Kim Davies、Peter Koch、Lars Eggert がそれぞれの角度から同じ方向を指した）。一方 Tony は集約最大化という工学目標を譲らず、Warren は単一障害点の政治的リスクを譲らないまま。進め方は専用サイドミーティング＋アーキテクチャ文書の先行 RFC 化。
QUIC は最も成熟。draft-many-tiptop-quic-profile が rough consensus で採択方向（ML 確認待ち）。Johannes の独立検証と Marc らのシミュレーション群が同じ結論——プロファイリングのみで足り、プロトコル変更は不要——に収束した点が説得力を持ちました。今後の宿題は、実際の宇宙リンクのモデル化、複数 QUIC 実装でのクロスチェック、そして Lars が指摘したインターネット QUIC との互換性を壊していないかの点検。
CoAP と ICMPv6 signaling はどちらも「WG の作業範囲に入れるか」の段階で、いずれも Chairs から「ユースケースへの対応付けを示してから戻ってこい／リストで議論せよ」という同じ形の宿題が出されました。

TIPTOP WG @ IETF 126 セッションまとめ — アドレス空間の2提案、QUIC プロファイル採択、CoAP と惑星間ホップ signaling