要約

  • RFC 3361 は DHCPv4 オプション120に、優先される DNS 名一覧と、順序付き IPv4 アドレス一覧という排他的な二つの符号化を与えた。
  • 名前はトランスポート、ポート、インスタンス、代替選択を DNS に委ね得る一方、アドレスはホスト順を固定した。どちらも後続の SIP トランザクションや通話経路を証明しない。

設定は最初に届くため、最後の結果まで説明できるように見えやすい。端末が DHCP リースを受け取り、ローカルの SIP プロキシを知れば、通信の準備は終わったように見える。しかし、出発点を知ることと相手まで届くことの間には、名前解決、トランスポート、トランザクション状態、後続プロキシ、セッション交渉、メディアがある。

2002年8月に Standards Track で発行された RFC 3361 は、ローカル SIP アウトバウンドプロキシ用の DHCPv4 オプション120を定めた。環境によっては SIP URI の宛先へ直接接触できる。一方、ファイアウォールなどがある場合には、外向き要求をローカルサーバーへ渡す必要があった。DHCP は複数の発見方法の一つで、手動設定も残った。

コードと長さの後ろに一つの符号化バイトが置かれた。ゼロなら RFC 1035 形式のドメイン名列、一なら一つ以上のバイナリ IPv4 アドレス列である。文書は名前を好ましい形式としつつ、全実装に両方の対応を求めた。

これは同じ情報の表記差ではない。ドメイン名は RFC 3263 の SIP サーバー探索へ入る。NAPTR が利用可能なトランスポートを、SRV がサービスインスタンス、ポート、優先度、重みを示し、A または AAAA がアドレスを返す。クライアントはドメインの提示と自らの能力・方針の共通部分を選ぶ。名前は、後から変更できるサービスグラフへ判断を委譲する。

IPv4 一覧が持つ情報は狭い。アドレスは優先順に並ぶが、オプション自身には NAPTR サービス、SRV ポート、優先度、重み、トランスポート情報がない。候補ホストを DHCP の値として固定するため、変更には設定の更新と再配布が必要になる。

二形式は変更権限の置き場所を変えた。名前なら DNS 管理者がリースを更新せずにインスタンスや順序、サービス記録を変えられる。リテラルなら DHCP 管理者がホスト選択をより直接に握る。どちらでもクライアント版、キャッシュ、対応トランスポート、方針、プロキシの稼働状態までは支配できない。

RFC 3361 は複数ドメインの意味も限定した。同一ドメインの複数 A レコードの代わりではなく、異なる提供者など別々の NAPTR ドメインを表すべきだとした。クライアントは記載順に試し、接触失敗、共通トランスポートなし、またはクライアント方針による禁止の場合だけ次へ進む。

ここでは複数の順序が重なる。DHCP は提供者ドメインを並べ、NAPTR はトランスポートサービスを選び、SRV は優先度と重みでインスタンスを配列する。解決はアドレスを返し、クライアント能力と方針がさらに候補を削る。「設定されたプロキシ」という一語では、この連続した統制面が見えなくなる。

RFC 3263 は選択が止まる境界も定めた。一つの SIP トランザクションでサーバーへの接触が成功した後は、再送、CANCEL、非2xx最終応答への ACK を同じサーバーへ送る必要がある。接触前の探索は動的でも、状態が生まれた後に DNS 変化が一つのトランザクションを分散させてはならない。

符号化バイトには意味上の整合性規則があった。サーバーは一つの DHCP メッセージ内で名前形式とアドレス形式を混ぜてはならず、別々のオプション120として送ってもいけない。DHCP は同一オプションの複数出現を先に連結し、その後で処理するからだ。異なる文法の断片が合体すれば、受信側は誤った一つの値として読む。

同年後半の RFC 3396 は、反復する DHCPv4 オプションを連結する厳密な順序と、長い値を複数箇所へ分割する方法を整えた。同時に、多くの配備済み DHCP エージェントが連結を実装していないことも記録した。送信側が規則どおり分割しても、実在する受信側が再構成できないことがあった。

RFC 3361 は、名前一覧が単一オプションの上限を超える場合にその方法を要求した。つまり DNS 問い合わせ以前に、長い一覧は断片順、オプションオーバーロード、クライアント実装へ依存していた。サーバーが全バイトを送ったことは、クライアントが同じ値を読んだ証拠ではない。

翌年の RFC 3319 は DHCPv6 で別の設計を採用した。ドメイン名用と IPv6 アドレス用に二つのオプションコードを割り当てた。DHCPv6 にはコード不足がないため、IPv4 の符号化バイトを避けられたと明記している。分離により短く、解析しやすく、数値アドレスの整列も容易になり、クライアントは望む形式を個別に要求できた。一つの番号空間の希少性が、別の場所でメッセージ複雑性になっていた。

名前形式にも将来への意図があった。RFC 1035 のラベル符号化と DNS 圧縮を使い、国際化ドメイン名の仕組みに備えた。サービス選択の下層には RFC 2782 の SRV と RFC 3403 で体系化された NAPTR がある。小さなオプションは、別管理の大きな機構を参照することで小さく保てた。

参照は柔軟性と信頼面を同時に広げる。RFC 3361 は、DHCP 応答を改変または挿入できる攻撃者が、ユーザーエージェントを不正な SIP サーバーへ導き、要求の傍受やサービス拒否を起こせると警告した。TLS ベースの SIP サーバーへ解決する名前を応答から外すこともできる。設定パケットは通話そのものではないが、シグナリングが最初に向かう門と、選択前に消える安全な候補を決め得た。

現在の IANA BOOTP/DHCP Parameters 登録簿にも、コード120は SIP Servers DHCP Option として残る。これは番号と用途の調整記録である。特定ネットワークでの配布、クライアント実装、現在の利用、プロキシの応答を証明しない。

観測したリースの証明範囲も限られる。パケットキャプチャはオプションの到着とバイトを示し、デコーダーは名前かアドレスかを示す。それでも DNS 応答、トランスポートの共通部分、接続、SIP 応答、後続経路、セッション成立、メディア流通は別問題である。

DHCP ではサーバー、リレー、原データ、形式、順序、有効期間を保存する。名前なら NAPTR、SRV、A/AAAA、TTL、フィルター後の選択を残す。アドレスなら試行順、ポート、トランスポートを記録する。その後に、プロキシ接触、トランザクション応答、次のルーティング、セッション記述、メディアを別々に観測する。

本稿は Lu Heng の二論考を分析上の視点として明示する。「Minimum Initial Specification」は、共通部分を狭いオプションに限定し、提供者運用、DNS 方針、導入判断をローカルに残す価値を説明する。「Reality Layers」は登録コード、受信設定、解決されたサービス、動作実装、通話結果の混同を防ぐ。これは編集上の読解で、RFC 3361 の著者性や意図についての主張ではない。

オプション120が作ったのは待ち合わせ場所であり、到着証明ではない。符号化バイトは次の判断を生きた名前体系へ渡すか、アドレス順へ部分固定するかを選んだ。リースはシグナリングの始点を示した。その先が動いたかは、次の証拠が答える。

出典