要約

  • Who-Provides? は提供者のアドレスを知らないときに使うブロードキャスト質問であり、該当しないホストは黙ってよかった。
  • 特定ホストへの Do-You-Provide? は空リストを含む応答を義務づけ、第三者の They-Provide は通常、本人への再確認を要する手掛かりだった。
  • リソース名は下位プロトコルから上位機能へ進む長さ付きの経路で、下位層の対応だけでは未知の特殊機能まで対応したことにならなかった。

1983年12月のRFC 887には、再起動したホストが最初の外部パケットを渡すゲートウェイを探す例がある。アドレス一覧を持っていなくても、ローカルネットワークへ問いを投げ、応答した候補を得られる。

しかしResource Location Protocolの核心は、単に「見つける」ことではない。群衆への質問、名指しの質問、第三者の記憶、本人の証言を別々のメッセージにしたことにある。

名前はプロトコル階層をたどる検査票だった

リソース指定は、アクセスに使う最下位のInternet Protocol番号から始まる。その後ろに識別子の長さと、上位レベルを順にdemultiplexする自然な値を置く。UDPのDomain Name Serverなら、プロトコル17とポート53である。さらに特殊な機能なら、追加成分を続けられる。

長さフィールドがあるため、未知の指定子でも終端を見失わず、次の項目へ進める。受信ホストは成分を順番に検査する。途中のプロトコルを持たなければ非対応。要求名が成功した検査の位置でちょうど終われば対応。理解できる範囲を越えて成分が残れば、下位サービスへの対応だけでは全体を肯定できない。

たとえばTFTPを提供するホストでも、TFTP上の特定crash dump機能を提供するとは限らない。RFC 887は、ポート、アプリケーション族、具体的機能をひとつの「対応」に潰さなかった。

全員への問いでは、肯定者だけが答えた

Who-Provides? は通常ブロードキャストされる。要求リストのどれかを提供するホストは I-Provide を返し、ひとつも提供しないホストは応答しなくてよい。

応答数は減るが、無応答の意味は増える。本当に提供者がいない、要求が失われた、返答が失われた、サービスはあるがRLPがない、という状況を区別できない。RFC 919が述べるように、IPブロードキャストは信頼できず、順序もなく、重複し得る。また、受信した全ホストに処理コストを課す。

未知の相手を探せることと、ネットワーク全体の不在を証明することは別だった。

名指しの問いだけが、空の返答を意味ある否定にした

Do-You-Provide? は特定アドレスへ送る。受信者は該当リソースがなくても応答しなければならない。空の I-Provide は、そのホストがその要求に対して提供を否定した証拠になる。

この要求をブロードキャストすることは禁止された。全ホストに空応答を義務づければ、問い合わせ一件がreply floodを生む。大勢には肯定だけを求め、一人には肯定と否定の両方を求める。この非対称性が、負荷と証拠の強さを両立させた。

それでも否定は一台、一時点、一つのリソース名に限られる。別のホストや将来まで代表しない。

案内役の知識は、現場の確認ではなかった

Who-Anywhere-Provides? と Does-Anyone-Provide? は、他ホストについて知る“smart” hostへの質問である。ブロードキャストできないネットワークや、別ネットワークの情報を集めたゲートウェイに利用できる。

返答 They-Provide は候補アドレスを示す。ただしRFC 887は、照会者がその間接情報を無条件で信じる必要はなく、通常は候補へ直接 Do-You-Provide? を送るべきだとした。

DNSの例では、案内役がSを挙げるが、S自身は空リストを返す。照会者はSを除外して再び尋ね、Tを得て、最後にTからUDP 53の直接確認を受ける。案内役が虚偽を述べたとは限らない。知識が古くなった可能性がある。

ここでは“誰が述べたか”が訂正可能性を作る。第三者の記憶と現在のendpoint応答を同じ値にすれば、更新の根拠を失う。

Local-Only flagは候補を照会者と同じIPネットワークに限定した。multi-homed hostが適切なlocal source addressを選ぶ規則も含む。scopeは後処理の表示条件ではなく、質問の意味だった。

Message-IDは認証情報ではない

16-bit Message-IDはrequestとreplyの対応を助けるだけである。送信者の身元、利用権限、再送攻撃への耐性を与えない。UDP checksumも偶発的な破損検出であり、cryptographic signatureではない。

本人からの I-Provide でさえ、名付けられたリソースを提供するとそのホストが述べたことを示すだけだ。次の処理の成功、完全な仕様適合、継続的な健全性、clientの権限は別に確認する必要がある。

後の方式は別の語彙と統制面を選んだ

比較はできるが、直接の系譜は資料から証明できない。RFC 2608のSLPv2は、service typeとattribute、User Agent、Service Agent、Directory Agent、administrative scopeを使った。service URLとattributeの認証も定義したが、confidentialityは提供しない。

RFC 6762は通常のUnicast DNS serverがなくてもlocal linkでDNS-like operationを可能にした。RFC 6763はservice typeとdomainからnamed instanceを見つけるDNS-SDを定めた。表現は変わっても、発行者、範囲、時点、実際の効果は同じ事実にはならない。

登録された39番は稼働証明ではない

RFC 887はUDP port 39を割り当てた。現在のIANA Service Name and Transport Protocol Port Number Registryには、TCPとUDPの39番に rlp が残る。これは行政的な割当の継続であり、稼働台数ではない。

RFC 6335は、service nameやportの割当がendorsementではなく、そのportのtrafficが登録serviceのものとも限らないと明記する。番号は衝突を防ぐが、endpointの現在を語らない。

情報源と限界

本稿はRFC 887、RFC 919、RFC 2608、RFC 6762、RFC 6763、RFC 6335、IANA registryに基づく。RLPの普及率、後続方式への直接的影響、現在の製品実装や特定サービスの可用性は証明しない。