要約

  • ipn URIは割当者識別子、ノード番号、サービス番号から成り、共通の衝突回避と各組織の番号管理を分離する。
  • BPv7はEIDをホップごとに遅延バインドするため、同じ名前が続いても位置、到達可能性、次の経路は証明されない。
  • LocalNodeとPrivate Useは境界を越えれば一意性を失い、処理主体の本人性には別のBPSec検証が要る。

ipn:977000.100.1 は短い。数字が三つ並ぶと、機械はそこに座標を読み込みたくなる。しかしRFC 9758が守ろうとするのは、まさにその読み込みをしない規律である。

最上位の番号が示すのは組織

三つの成分には別々の仕事がある。割当者識別子は、ノード番号を発行する組織を示す。ノード番号は同じBundleノード上の資源を束ねる。サービス番号はそのノード内の機能を分ける。割当者識別子とノード番号を合わせたものがFQNNであり、サービスを載せるノードの完全な識別子になる。

IANAはすべてのノードを一冊に書くのではなく、割当者識別子を調整する。各割当者は自分の番号が重複しないよう管理し、他の割当者の個々の付番と調整する必要はない。階層を持つ組織は連続範囲を下位組織へ分けられる。CIDRに着想を得た並びでも、標準はそれをアドレスと呼ばない。組織上の関連を示す番号だからである。

ここで台帳の効力は尽きる。IANAの行は割当者番号の管理主体を示せる。割当者の公開記録はノード番号の発行先を示せる。どちらも、いま利用できる接触、次ホップ、稼働中のサービス、相手の暗号学的本人性、配送完了を観測していない。

移動を許すために経路を捨てた

BPv7の遅延バインディングでは、Bundleが進むたびに中継ノードがEIDをローカルな宛先アドレスへ結び直す。名前が場所を含まないから、ノードは移動しても改名せずに済む。反対に、古い対応表を名前そのものの意味だと扱うこともできない。

RFC 9758はipnの要素から位置、到達可能性、アドレス、経路を推測することを禁じる。割当者がリンク層アドレスを材料にノード番号を作ったとしても、受信側にとっては番号でしかない。発行方法は転送権限を運んでこない。

運用証拠は段階ごとに残すべきだ。登録記録は重複の有無を示す。バインディングは、ある時刻に選んだ対応を示す。転送ログは接触を試みたことを示す。ステータス報告は後続のプロトコル事象を示す。アプリケーションの受領記録だけが、期待した仕事の完了に近づく。名前の一意性は、この列を一気に飛び越えない。

端点の名前と、そこにいる主体

標準は、ipn EIDが示す端点が常時到達可能だとは保証しない。さらにBundle Protocolだけでは、端点で処理する主体の本人性も保証しない。主ブロックを対象にしたBPSecのBlock Integrity Blockを検証することが、その主張に対する別の手続きとなる。ただし鍵、セキュリティ源、受入主体、ローカルポリシーが揃って初めて結果になる。

構文に適合した悪意あるEIDも作れる。偽の送信元を名乗らせたり、到着が害になる処理先へBundleを向けたりできるため、受信ノードは処理前に真正性と妥当性を確認する必要がある。TLSを使うTCPCLv4も別の輸送境界を守る。URI、輸送路、内容の認証を一つのチェック印にしてはならない。

ローカルな一意性は国境を持つ

全成分がゼロのNull URIは「どこにもない」を表す。サービス番号ゼロは管理端点を表す。一方、LocalNodeの予約値は現在のBundleノードだけで意味を持つ。外へ送ってはならず、外から届けば無効として捨て、発見ディレクトリやセッションのピア識別子にも載せてはならない。

Private Useは一つの管理ドメインまで広げたローカル性である。調査時のIANA表では、Default Allocatorのノード番号1から0x3FFFが私用に確保されていた。そのFQNNは域内では調整できても、域外で同じ番号が使われていない保証はない。ドメイン間ゲートウェイは私用の送信元・宛先を越境させない設定能力を持ち、運用者は実際に有効化しなければならない。

これは単なる命名作法ではない。LocalNodeやPrivate Useが漏れると、ipnが必要とする一意性が成立しなくなる。RFC 9758がネットワーク全体への悪用可能性まで述べるのは、境界制御が名前の意味を構成しているからだ。

値の同一性とバイト列の同一性

更新仕様は、従来の二要素CBOR形式に加えて、割当者・ノード・サービスを明示する三要素形式を設けた。EIDとしての比較は復号後の値で行うため、二つの異なるバイト列が同じEIDを表せる。対して、構文を対象にする完全性確認はバイトの違いを扱いうる。

旧実装が新形式を理解するとは限らない。二要素しか知らないノードは、意味上正しい三要素を不正形式として拒否しうる。混在環境では宛先ごとのエンコード方針、観測された拒否理由、復帰経路を管理する必要がある。

共通部分を薄く保つ

IANAの現行グループには、恒久URI schemeとしてのipn、割当者識別子、Default Allocatorのノード番号、BPv7のWell-Known Service Numberが並ぶ。小さい割当者番号ほどCBORで短くなるため、番号の低い領域には効率という希少価値もある。専門家審査が必要なのは、台帳が無限でも中立でもないからである。

Heng Luの最小初期仕様は、共通にしなければ衝突する部分だけを共通化し、その後の判断を現場へ返す。RFC 9758の設計も、割当者の一意性は共有し、ノード番号、バインディング、経路、認証、結果はそれぞれの実行者に残す。この層を守る限り、永続的な名前は便利である。台帳が現実そのものを名乗った瞬間、便利さは権力の誤配へ変わる。

出典

  1. IANA Uniform Resource Identifier (URI) Schemes
  2. RFC 1918：Address Allocation for Private Internets
  3. RFC 3986：Uniform Resource Identifier Generic Syntax
  4. RFC 4838：Delay-Tolerant Networking Architecture
  5. RFC 6260：Compressed Bundle Header Encoding
  6. RFC 7116：Bundle Protocol関連のIANAレジストリ
  7. RFC 8126：IANA Considerations作成指針
  8. RFC 9171：Bundle Protocol Version 7
  9. RFC 9172：Bundle Protocol Security
  10. RFC 9174：TCP Convergence-Layer Protocol Version 4
  11. RFC 9758：Updates to the 'ipn' URI Scheme
  12. Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption
  13. On Reality Layers, Symbolic Power, and Why Clarity Feels So Hostile
  14. Running-Code Primacy