要約

  • RFC 5149 は Mobile IPv6 の Binding Update に載せる Service Selection Mobility Option を定義する。
  • オプションは要求するサービスを識別するだけで、利用資格を付与しない。
  • 一つの Binding Update に置けるのは一個までで、MN-NAI があればその後、認可・認証関連オプションの前に置く。
  • タイプ 20 の識別子は 1～255 オクテット、UTF-8、NFKC 正規化である。
  • 識別子の一意性は、その端末が登録を許されたホームエージェント群の中だけでよい。
  • ホームエージェントは端末を認証したうえで、選択されたサービスを別途認可する。
  • 認可できなければ状態 151 SERVICE_AUTHORIZATION_FAILED で登録を拒否する。
  • サービス変更時の再認可失敗は、既存バインディングの削除を伴い得る。
  • 選択はアドレス、プレフィックス、経路、ファイアウォール、セキュリティー、QoS に影響し得るが、適用済みとは限らない。
  • サービス知識を共有しない相手ノードは、このオプションを黙って無視する。
  • ESP による秘匿は識別子の露出を抑えるだけで、資格や配送を証明しない。
  • 登録結果、ポリシー反映、データ経路、課金、利用者の結果には別々の証拠が要る。

名前が届いても意味が届くとは限らない

ホームエージェントは契約情報とサービスカタログを持ち、識別子から適用すべき認可やポリシーを判断できる。通常の相手ノードにはその前提がない。そこで RFC 5149 は、移動ノードが相手ノードへ選択オプションを送るべきではないとし、知識のない相手は受信しても黙って無視すべきだとする。

同じ管理ドメインに属し、ホームエージェントと相手ノードが同一のカタログを共有する配置なら、サービスに応じた処理は可能である。しかし同じ文字列を解釈できることと、同じ動作を実行したことは別だ。カタログの版、契約キャッシュ、ポリシー生成物、ファイアウォール、転送経路のいずれかがずれれば、名称は一致しても結果は一致しない。

したがって相手ノードの無反応は、必ずしも不正なパケットでも実装障害でもない。仕様に従った「意味を共有していない」という結果かもしれない。運用記録は、オプション送信、相手の知識範囲、実際の処理、アプリケーション応答を分離しなければならない。

タイプ 20 は問いを運び、答えを運ばない

一つの移動契約に通常のインターネット接続、企業内アクセス、分離された専用ドメイン、サービス固有の QoS が並ぶと、端末の身元だけでは今回の希望を区別できない。Service Selection Mobility Option は、その不足を埋める要求ラベルである。

線上形式は限定されている。タイプは 20、値は空でない 1～255 オクテットの UTF-8 文字列で、NFKC に正規化する。一つの Binding Update に複数は置けない。MN-NAI がある場合はその後、認可や認証に関係するモビリティーオプションより前に置く。この順序により保護対象へ組み込めるが、正しい暗号検証から正しい契約内容までは導けない。

識別子は世界共通の名前である必要もない。その移動ノードが登録可能なホームエージェント間で一意ならよい。ドメイン名に似た値でも、DNS の支配、商標、外部サービスの所有権を表さない。文字列は「どのサービスを認可するか」を指定し、認可の答えは契約プロファイルから得る。

再認可は既存状態を消し得る

ホームエージェントはまず移動ノードを認証し、登録そのものを認可する。サービス選択を実装していれば、指定されたサービスについても契約上の資格を確認する。許可できなければ登録を拒否し、状態 151 SERVICE_AUTHORIZATION_FAILED を返す。

危険が大きいのは変更時である。別サービスは別の Home Address や Home Network Prefix を必要とすることがある。サービス変更を示す Binding Update では再認可が必要で、失敗するとホームエージェントは既存アドレスまたはプレフィックスのバインディングも削除する。状態 151 を受けた移動ノード側も一致するバインディングを削除しなければならない。

つまり、新しい選択の失敗が古い接続を保存するとは限らない。「拒否した」ことと「安全に元へ戻した」ことは異なる。変更前のバインディング、削除決定、代替登録、利用者セッションの復旧を時系列で検証しなければ、無停止切り替えとは報告できない。

登録成功の先に六つの不確実性が残る

サービス選択は、アドレスやプレフィックス割り当て、出力経路、ファイアウォール設定、セキュリティーポリシー、一般ポリシー、QoS を変え得る。Binding Acknowledgement の成功はホームエージェントにおける登録結果であって、それらすべての適用確認ではない。

割り当てられたプレフィックスに戻り経路があるとは限らない。コントローラーが規則を生成しても実行点が読み込んだとは限らない。QoS クラスが付いても実測品質は分からない。外部管理ドメインが厳しい入出力フィルタリングを持てば、あるサービスの選択が別サービスへの同時アクセスを制限することもある。

選択オプションがない場合、ホームエージェントは通常のインターネットアクセスが要求されたものとして扱う。仕様は基本接続のためにこの既定値を許可するよう強く勧めるが、全契約者への提供を義務づけない。既定コンテキストは保証書ではない。

暗号化と標準番号にも限界がある

選択したサービスは、所属組織や業務目的を推測させる可能性がある。RFC 5149 は秘匿が必要なら、Binding Update と Acknowledgement を非 null 暗号化の ESP トランスポートモードで守るよう勧める。これは盗み見への対策であり、サービス資格、契約データ、ポリシー写像、データ経路の正しさを保証しない。

反対方向も同じである。認可に成功しても、識別子が秘匿されていたとは限らない。メッセージ完全性、機密性、端末認証、サービス認可、実際の配送を一個の緑色ランプにまとめてはならない。

IANA のタイプ 20 と状態 151 は標準上の安定した座標を与えるが、特定製品の実装や現在の展開を証明しない。RFC 3775 の基盤は後に RFC 6275 で置き換えられた。後続文書の参照も、概念の系譜を示すだけで、現場の稼働証明ではない。

情報源

  1. RFC 5149（HTML）
  2. RFC 5149（テキスト）
  3. RFC Editor の記録
  4. IETF Datatracker の記録
  5. RFC 5149 の履歴
  6. RFC 5149 の参照関係
  7. RFC 5149 の正誤表
  8. RFC 3775
  9. RFC 6275
  10. RFC 4877
  11. RFC 4283
  12. RFC 6089
  13. RFC 5778
  14. RFC 5779
  15. RFC 6097
  16. RFC 7222
  17. Minimum Initial Specification
  18. On Reality Layers
  19. Running-Code Primacy