要約

  • RFC 832はNICホスト表のTCP申告と、Telnet・FTP・SMTPへの接続結果を別欄に置き、未受理、拒否、到達不能、無応答、受理を区別した。
  • 負の結果は翌日に再試行され、調査そのものも週ごとに更新された。結果はホストの永久属性ではなく、ある経路・時刻・観測者に属した。
  • RFC 844は別のClass Cネットワークから再検査し、先にTelnetを受理した187台のうち127台にしか成功しなかった。稼働証拠は申告より強いが、普遍的到達性や完全準拠ではない。

前週の写真を保存する

RFC 832が参照したのは、1982年12月2日付のNICホスト表だった。そこにはTCP一般、あるいはTelnet、FTP、SMTPを提供するという印があった。文書はその列を Claims と呼ぶ。申告は検索の出発点であって、接続結果の代用品ではなかった。

右側には三つのサービスについて実測欄が並ぶ。申告がなくても受理するホストがあり、申告があっても答えないホストがある。二つを同じ表に残したことで、名簿が現実を書き換えることも、一度の観測が名簿の履歴を消すことも避けられた。

RFC 801の移行計画は、それ以前の証拠が何であったかを示す。付録にはサイトやベンダーから寄せられた実装状況が載り、利用可能、実験中、開発中、予定といった記述が混在した。情報はすぐ古くなるとも警告した。また、チェックサム未検証、IP再構成の欠落、TCPセグメントの並べ替え不足、オプション無視など、見かけの動作だけでは分からない欠陥も列挙した。

したがって、ポートが開くことはTCP全体の合格証ではない。調査が答えたのは、もっと限定された問いである。この送信元から、この時間帯に、このサービスへ接続すると、どの応答が観測できるか。

無応答と拒否を混ぜない

refused は宛先が拒否を返したこと、unreachable は経路から到達不能が返ったこと、dead は測定条件内で有用な応答がなかったことを示した。空欄は受理されなかったという最小限の記録であり、原因を作り上げない。accepted は接続試行が設定された敷居を越えたことだけを示す。

FTPには accepted+ があり、anonymous とパスワード guest で入れた場合を区別した。この追加項目は、通常の受理がログイン成功、転送完了、サービス品質、運用者の身元を証明しないことを逆に明確にする。

12月7日の試験は二つの時間帯にわたった。dead、refused、unreachable は8日に再試行された。再試行は一時停止や瞬間的な経路障害の影響を小さくするが、観測地点そのものを増やすわけではない。

315台のうち、Telnetは83、FTPは70、SMTPは63が受理した。残りを違反者と数えることはできない。特殊用途のホスト、停止中の機械、三つのサービスを公開する必要がないシステムが含まれていた。

数字が下がる週も移行の一部だった

RFC 833は12月14日に再調査し、重複ホストの除き方が前週と少し異なるため行総数が変わった、と明記した。分母の処理変更をネットワークの変化に見せかけないための重要な注記である。

RFC 847は12回分をまとめた。12月7日から2月22日までに、Telnetの受理数は83から190、FTPは70から181、SMTPは63から178へ増えた。移行は計画書の締切ではなく、応答するサービスとして観測可能になった。

ただし、毎週上昇したわけではない。12月のTelnetは103、102、95と下がった。停止、経路、測定時間、表の改訂、サービス公開方針が違えば、一時点の値は動く。稼働ネットワークは行政用の進捗バーではない。

最終回のRFC 846も、2月18日版ホスト表、22日のISI-VAXAからの試験、23日の負結果再試行を記した。「完了」という永続ラベルではなく、次の観測座標を公開した。

観測地点を移すと依存関係が見えた

RFC 843は2月8日と9日にISI-VAXAからTelnetを受理した187台を記録した。RFC 844はその集合を、BBNのClass Cネットワーク 192.1.2.0/24 にある端末集線装置から手作業で再試験した。

今度は待受けポートだけでは足りない。ゲートウェイがClass C宛ての戻り経路を扱い、ホストがアドレスを正しく解釈し、ICMPを含む経路処理が協調する必要がある。OK は127台、67.9%だった。

残る60台がTCPを失ったわけではない。RFC 844自身が、手入力で三巡しか行わず、停止中のホストを取り逃した可能性を記している。最初の測定はISIからの受理、次の測定は別のアドレス環境からの到達を問う。命題が違うので答えも違った。

この比較は、中央の監視者が持てない知識を示す。経路、送信元、アドレス処理が変われば、同じ遠端でも別の結果になる。観測は強いが、観測者の外側を自動的には代表しない。

集計表も監査対象だった

RFC 847は特殊用途の37台、全体の11%について、三サービスを期待すべきでないと見積もり、合理的な上限を89%とした。InternetホストであることとTelnetを公開することを同一視しなかった。

一方、集計には目で確認できる不整合も残る。70/315を26%とするFTP行、周囲が328なのに382となるRFC 842の分母、329のところを389とするRFC 843の値、1983年2月の調査を1982年とする日付である。

だから集計を捨てるのではない。分子、分母、計算法、元の調査を一緒に残す。出典のある誤りは直せるが、由来を失った滑らかな割合は信じるしかない。

測る権利は命令する権利ではない

調査側は試すポート、時刻、結果語彙を選んだ。遠隔側は何を実装し公開するかを選び、その運用結果を引き受けた。accepted はホスト操作の許可ではなく、timeout は所有権や過失の証明ではない。

実行結果は、他の参加者が局所的に再現できるため、申告を規律できる。しかし権威は測った命題までで止まる。接続受理からTCP全要件、本人性、実用性、全経路到達性を推論してはいけない。

RFC 832の歴史的価値は、完璧な国勢調査ではなく、申告、実験、型付き結果、再試行、次の版という連鎖を公開した点にある。毎週失効する写真だからこそ、変化を記録できた。

出典と証拠の限界

これらは計画、日付付き申告、接続実験、集計を記録する。現在の普及、完全準拠、運用者の身元、権限、処理完了は証明しない。負の結果は、記載された観測地点、経路、方法、時刻の範囲を出ない。