要約

  • RFC 3319は、ローカルのSIP発信プロキシを見つけるため、順序付きドメイン名リストとIPv6アドレスリストという二つのDHCPv6オプションを定めた。
  • 両方届いた場合、クライアントはドメイン名を優先してSIPの位置特定手順を使う。候補先が示されても、プロキシの信頼性や通話成立までは証明されない。

リースが答えるのは、通話より狭い問い

RFC 3319の課題は誤解されやすい。SIPクライアントはSIP URIに記された宛先を知っていても、ローカルの発信プロキシを必要とすることがある。ファイアウォール、地域の発信計画、緊急サービスなどが中継役を求める場合だ。手動設定も可能だが、このRFCはDHCPv6で候補を知らせる別の方法を示した。

ここでは「プロキシ」の範囲が重要になる。RFC 3261はユーザーエージェント、プロキシ、リダイレクトサーバー、レジストラを区別する。RFC 3319でいうSIPサーバーは、発信プロキシを実行するホストを指す。DHCPの応答にそのホストが載っていても、利用者の登録、宛先への許可、SIPダイアログの完了、メディアの交渉や通話成功を示すわけではない。

二つの形式と、一つの優先順位

オプション21のOPTION_SIP_SERVER_Dはドメイン名リスト、オプション22のOPTION_SIP_SERVER_AはIPv6アドレスリストを運ぶ。どちらも優先順に並び、仕様準拠の実装は両方をサポートする。クライアントはDHCPv6のOption Request Option（ORO）で一方または両方を要求できるが、サーバーが返す内容は設定と要求に左右される。二種類を要求しても一種類だけ返す場合があり、その際はドメイン名オプションを優先すべきとされる。

両方のリストが届けば、クライアントはまずドメイン名を使う。数値アドレスは条件付きの代替手段で、最初のリストの名前がどれも解決できないか到達できない場合に限って試せる。後続の名前も一斉には解決しない。優先順に進み、先行する試行が失敗する、共通のトランスポートがない、またはクライアントのポリシーがそのドメインを禁じる場合に次へ移る。

名前はSIP位置特定への入力であり、代用品ではない

ドメイン名はRFC 3263が定めるSIPサーバーの位置特定手順につながる。リストには別々のAレコードより、異なるNAPTRレコードに結び付く名前を並べることが望ましい。これにより一つのDHCPサーバーが、異なる事業者のプロキシ候補を示せる。ただしRFC 3319はNAPTRやSRVを置き換えない。候補名の後には、SIPの位置特定手順やトランスポート選択が続く。

したがって「フォールバック」は具体的な条件を伴う。後ろに書かれた名前が自動的に予備になるわけではなく、先行項目で定められた失敗が起きて初めて試される。ドメイン名とアドレスが両方あるとき、数値のIPv6一覧はさらに後の段階だ。候補と順番を配るのはネットワーク、名前解決やトランスポート、利用可否の判断はクライアントという分担になる。

この制御面の分担は便利だ。各端末に同じプロキシを固定記述せず、ネットワーク側からローカルの候補を配れる。一方で、そのホストが応答するか、共通のトランスポートを話せるか、利用者の要求を受け付けるか、セッションを運べるかは別問題である。「優先候補に設定」と「実際に成功して利用」は異なる状態だ。

設定経路は、信頼を別方向へ導く入口にもなる

セキュリティ節が示すのは、DHCP応答を攻撃者が改変または挿入すると、ユーザーエージェントが不正なSIPサーバーへ誘導され得るという脅威だ。相手は呼の要求を傍受したり、サービスを妨げたりするかもしれない。改ざんされた応答がTLS対応サーバーに結び付く名前を省けば、傍受を容易にする可能性もある。

これはRFCの脅威モデルであり、実際の攻撃事例の報告ではない。受信アドレスが認証済みだとも、すべての名前がTLSへ解決するとも述べていない。DHCPの返答は、アプリケーションが次にどこへシグナリングを送るかを左右するため、信頼の連鎖の一部になる。本人確認、ポリシー、システム全体の保護は別途必要だ。サーバーを見つけることと、その身元を確かめることは同じではない。

古いオプションは新しいDHCPv6記録にも残る

DHCPv6の一般仕様は進み、RFC 9915がRFC 8415を置き換えた。それでもIANAのDHCPv6 Option Codes登録簿はコード21と22をRFC 3319に対応付け、後年のRFC 9243も二種類のSIPサーバーオプションを設定するYANGグループを示す。これらは登録簿とデータモデル上の継続的な参照を示すだけで、運用者の採用率、クライアント対応、代替先への切り替え成功や通話完了を測るものではない。

RFC 3319の成果は「DHCPで電話サーバーを見つける」より限定的だが、その分正確に評価できる。ドメイン名を先に、条件を満たした場合だけアドレスを後に試す、ローカル発信プロキシの優先順位付き探索を定めた。通話の成否はこのオプションの外側にある。発見はシグナリングの行き先を示せても、その後を保証しない。

参考資料