要約

  • RFC 1877は、一次・二次のDNSとNBNSのアドレスを得る四つのIPCPオプションを定義した。全ゼロはConfigure-Nakで情報を返してほしいという明示的な要求だった。
  • Nakは候補の提示であり、受諾でも書き換えでもない。要求側は候補を入れた新しいConfigure-Requestを送り、それに一致するAckを受け取る必要があった。
  • 合意済みアドレスは問い合わせ先の候補にすぎない。IPCP Opened、経路、問い合わせ、応答、検証、アプリケーション利用はそれぞれ独立した記録を要する。

接続できたのに名前だけ使えない

PPPリンクが成立し、IPアドレスで通信できても、ホスト名が使えるとは限らない。端末には、どのDNSサーバーへ質問するかという情報が別に必要だった。RFC 1877は1995年12月、その情報をIPCPの交渉に載せた。新しい探索サービスを追加するのではなく、すでにIPを構成していた制御交換を拡張したのである。

オプション129は一次DNS、130は一次NBNS、131は二次DNS、132は二次NBNSを表した。どれもタイプ、長さ6、四オクテットのIPv4アドレスという同じ形を持つ。現在のIANA PPPレジストリにも番号は残っている。ただし、番号が登録されていることと、現在の装置が実装・有効化・利用していることは同じではない。

ただし原文にも証拠上の傷がある。第1.3節のフィールド説明に一次NBNSとする孤立した一句がある一方、節見出し、図、タイプ131の割当はいずれも二次DNSを示す。この不整合は資料の限界として残すべきであり、その一句だけをプロトコルの意味へ昇格させる根拠にはならない。

アドレスを知らないクライアントは、値を全ゼロにできた。これは壊れた入力ではなく、相手にConfigure-Nakで情報を提示させるための符号だった。別の無効値を意図的に要求し、相手が受け入れ可能な値を返す使い方も想定された。

否定が有用なのは、相手の提案権と自分の受諾権を分けられるからだ。Nakを受け取った瞬間にローカル設定へ反映すれば、この分離は失われる。

Nakの次に、もう一度Requestが必要だった

RFC 1877の形式と動作は、RFC 1332のIP-Addressオプションに合わせられた。Configure-Requestは希望を提示し、Configure-Nakは代案を示す。認識できない、または交渉できないオプションはConfigure-Rejectが変更せず返す。Configure-Ackは最新の要求をそのまま受け入れる。

ローカル側がタイプ129と0.0.0.0を送り、相手が192.0.2.53をNakで返したとする。この時点で分かるのは、相手がオプションを理解し、その値なら受け入れると表明したことだ。ローカル側は192.0.2.53を含む新しいConfigure-Requestを送らなければならない。その要求に対応するAckが返って初めて、当該セッションの値が合意されたと言える。

識別子と試行回数も欠かせない。古いNakの遅着、Ackの重複、別の値を含む新要求があり得る。最終アドレスだけを保存すると、誰の提案を誰がいつ受け入れたのか消えてしまう。

RFC 1661では、この交換より前にも段階がある。物理媒体が使用可能になり、LCPがリンクを確立し、必要なら認証を終え、その後にネットワーク層プロトコル段階へ進む。各NCPは個別にOpenされる。IPCPがOpenedに達する前のオプションAckは、IPトラフィックが運べることの証明ではない。

同じ六オクテットでも、DNSとNBNSは別物だった

RFC 1034とRFC 1035のDNSは、リゾルバー、サーバー、分散した名前の権威を扱う。RFC 1001とRFC 1002のNBNSは、TCP/UDP上のNetBIOS名前サービスである。IPCP上の形が同じでも、問い合わせ、データ、信頼の意味は統合されなかった。

一次と二次は独立して交渉された。両方があれば一次から試すようRFC 1877は勧めたが、この「一次」はPPP端末での利用順序である。DNSゾーンの原本を持つ一次権威サーバーを意味しない。同じ言葉から別の権限を推定してはならない。

結果は部分的でもよい。一次DNSだけが合意され、二次はRejectされることも、DNSだけでNBNSがないこともある。四項目をまとめて確定する原子的な手続きはなかった。既定値も各項目で「アドレス提供なし」である。欠落から暗黙のサーバーを作ることはできない。

トポロジーが設定値の有用性を決めた

RFC 1877は、これらをIPCPの推奨オプションに含めないよう示唆した。情報の有用性が、相手側ネットワークのトポロジーとローカル・アプリケーションに依存するからだ。正しい形式で双方が合意したアドレスでも、実際の経路から到達できない可能性がある。DNSには答えてもNBNSを必要とするアプリには使えず、応答が返ってもローカル方針が拒否する場合もある。

したがって証拠は、IPCP Opened、インターフェースと経路の設定、送信パケット、サーバー到達、問い合わせと応答の照合、権威・完全性の評価、アプリケーションによる選択、利用者の結果へと続く。一つ前の段階は次の段階を代行しない。

RFC 1877はInformationalであり、セキュリティ問題を論じていない。前者は普遍的な実装の証明ではなく、後者は安全宣言でもない。相手、提示されたサーバー、その後の回答を認証する仕組みが、沈黙から生まれることはない。

この仕様が慎重だったのは、設定を運びながら成果を約束しなかった点である。合意されたアドレスは、名前解決の終了証明ではなく、試行を始める座標だった。