要約

  • RFC 2322は、一時的なイベントネットワークでIP番号を配る物理的な仕組みを記述した。木製の洗濯ばさみ一つが一つの番号を表し、未割り当てのばさみは見えるプールを作った。
  • 割り当て状態は見えるようになったが、ばさみを配り、アドレスや共通設定をコンピューターへ転記するのは人だった。RFC自身の現場報告には、参加者がデフォルトルーターのアドレスを自分のものと取り違え、ネットワークが一時使えなくなった事例がある。

RFC 2322はDHCP標準ではない。1998年4月1日に情報提供文書として公開され、明確な管理組織がない現場ネットワークや小規模イベント向けの「peg-DHCP」を説明した。記述の出発点は、1997年にオランダで開かれた3日間のHacking In Progressだった。主催者は多様なコンピューターを持ち込む参加者を想定し、インターネット接続のあるTCP/IP LANを必要としていた。重複や欠番を避けることに加え、ソフトウェアのDHCPサーバーがさまざまなIPスタックで問題なく動くかも懸念していた。これはRFCが記録した動機であり、通常のDHCPが失敗した証明ではない。

この提案は管理の一部を物理的にした。洗濯ばさみ一つがアドレスを表す。未配布のばさみを物干し綱に並べればプールになり、コンピューターのネットワークケーブル近くに挟んだばさみは、その番号がどこで使われているかを示した。色でサブネットを分けることもできた。短いイベントなら、配布係がいるテントや机を「サーバー」にでき、管理を緩めるなら参加者が自分で取ることもできる。ネットワーク、マスク、ゲートウェイ、プロキシなど全参加者共通の設定は、紙片や掲示に記載した。参加者がそれをコンピューターやアプリケーションへ入力する。

最後の入力作業が重要だ。peg-DHCPはインターフェースを自動設定せず、リースを交渉せず、ばさみを受け取った人の身元も確かめない。サーバー内部に隠れていた割り当て状態の一部を、見て動かせる物に移しただけだ。人は、洗濯ばさみ、紙の案内、オペレーティングシステムをつなぐ役割を担い続ける。RFCは転記時の情報消失や誤りを明記し、具体例も記録している。イベントでは誰かがデフォルトルーターのアドレスを自分のホストアドレスとして入力し、ネットワークがしばらく使えなくなった。

回収もローカルな作業だった。利用を終えた参加者は洗濯ばさみをプールへ返せる。配布係がいなければ、本人が戻す必要がある。イベント終了後にアドレスを無効とすることで、イベント期間をおおよその有効期限として扱うこともできる。これはDHCPのリース交換とは異なる。DHCPではクライアントとサーバーがメッセージで割り当て、更新、再バインド、期限切れを処理する。違いは「手作業は悪く自動化は善」ということではない。目に見える保管と人の判断に対し、プロトコル状態とメッセージ交換があるということだ。

RFCのセキュリティ節は境界を明確にする。洗濯ばさみをなくせば、拾った人が記載されたアドレスを使える。ばさみも共通設定の紙も誰でも読める。個人情報をこの方法で交換すべきではないと記している。ばさみは割り当てを表すだけで、利用者の身元やアドレス使用権を認証しない。ばさみを鳥類キャリアで送る案は、RFC自身が実験段階と明記しており、導入実績の主張ではない。

RFC 2322の歴史的な価値は、冗談めいた前提より狭く、かつ有益だ。範囲の限られた環境で、見えなかったアドレスプールを観察・確認できる状態に変え、同時に人手による引き渡しを表面化させた。可視化は利用中の番号を見つける助けにはなるが、誤った番号がコンピューターに入力されることまでは防げなかった。

参考資料