要約

  • RFC 950は、起動時のホストがローカルサブネットの32ビットマスクを得るためにICMP Address Mask Request/Replyを追加した。無応答時のclassfulな既定値は、仕様自身が誤り得るとした暫定策だった。
  • RFC 1122はReplyを明示的に構成された権威agentだけに限定した。マスクを受信しても他者へ回答する権限は得られず、最初に受理したReplyの後は後続を無視した。
  • DHCPはマスクを他の設定と一緒に運び、旧来の発見役と供給役を個別に有効化できた。RFC 6918は最終的に、代替済みとしてICMP type 17と18をDeprecatedにした。

返事がないだけではネットワークの形は決まらない

RFC 950が解こうとした問題は、アドレスの割り当てと組織内部の境界が別物だという点にあった。ある組織は、一つのInternet network numberのローカル部分を複数のLANへ分割できる。32ビットのaddress maskは、どのビットをsubnet、どのビットをhostとして扱うかを示した。

この値は表示用の注釈ではない。ホストは自分のアドレスと宛先にマスクを適用し、結果が同じなら同一回線への直接配送を試み、違えばgatewayを使う。誤ったマスクは、誰を隣接ノードと見なすかという転送判断を変える。

ディスクのある機械なら設定ファイルを読める。だがLANから起動されるdiskless workstationには永続的な設定がないことがある。新しいホストは、自身のアドレス、gateway、name server、maskなど複数の事実を同時に必要とした。RFC 950はboot serverからまとめて得る方が望ましいとしながら、マスクだけを尋ねるICMPの仕組みも用意した。

Requestを何度か送っても何も届かない場合、三つの現実があり得た。ネットワークが恒久的に孤立している。subnetを使っておらずagentがいない。あるいは、すべてのgatewayが一時停止している。同じ沈黙からは区別できない。

暫定値は結論ではなかった

ホストを停止させないため、RFC 950はInternet network numberに相当する非サブネット化マスクを使わせた。古いアドレスクラスから得る、広い既定境界である。

この判断の「安全」は限定されていた。仕様は、後で誤りと分かる可能性を明記している。無応答がsubnet不存在を証明したのではない。一時的なgateway障害でも同じ観測になる。

沈黙は、今すぐ動くための可逆的な選択を支えただけだった。管理者がどの境界を設定したかという肯定的な証拠にはならない。

負の証拠の扱いとして重要なのはここである。不確実でも動作を選ばなければならない場面はある。しかし、暫定動作を事実認定へ昇格させる必要はない。

問いは回線全体へ送られた

想定された手順では、起動ホストがAddress Mask Requestをブロードキャストする。gateway、またはその代わりを務めるhostが、受信したsubnetの32ビットmaskを返す。要求側がまだ自分のIP addressを知らずsourceをzeroにした場合、Replyもブロードキャストされた。

形式は短い。Type、Code zero、Checksum、Identifier、Sequence Number、そして32ビットAddress Maskである。後のregistryではRequestがtype 17、Replyがtype 18と記録される。

IdentifierとSequenceは照合に使えるが、RFC 950は照合しなくてもよいとした。理由は「一つのLANには一つの正しいmaskしかない」という前提だった。複数gatewayが同時に答えても、値が同じなら問題にならない。

この前提は相関と権威の違いを示す。どの質問への返答かを知っても、回答者がLANの設定を決める資格を持つとは証明できない。maskは共有媒体の設定であり、個別clientとの交渉結果ではなかった。

戻ってきたagentは古い推測を直した

classfulなfallbackは固定されなかった。gatewayが起動すると、unsolicited Address Mask Replyをブロードキャストすることになっていた。推測と異なる値を受けたhostはmaskを変更する。

自発的な通知であることに意味がある。hostはすでにRequestの再送を終えているかもしれない。agentは古い質問を復元せず、復帰時にローカル設定をもう一度公示すればよい。

ただし、推測したmaskからReplyを作ってはならなかった。もし許せば、timeoutしたすべてのhostが暫定値を公式設定のように再配布する。一時障害が多数の偽agentを生むことになる。

自分の動作に値を使うことと、他者の設定として発行することは分離された。可用性を得るための推測は、委任状ではない。

agentであることは明示的な管理設定だった

RFC 1122は境界を強めた。Address Mask Replyを送るsystemはauthoritative agentでなければならず、その役割はexplicitに設定されなければならない。

hostでもgatewayでもagentになり得た。装置の種類が権限を生むのではない。静的maskを持つhostにも、それを回答する権威があるかを別のflagで示すことが推奨された。

最も重要な規則は権威の非継承である。Replyを受け取ってmaskを学んでも、受信者はauthoritativeにならない。その値を根拠に第三者へReplyしてはならない。

仕様のdiscussionは、無効なmaskを気軽に送るhostが深刻な迷惑になっていたと述べる。対策は値の形だけを調べることではなく、administrative actionによって回答者を選ぶことだった。

もちろんICMP packet自体に暗号的証明はない。RFC 1122は誰が話すべきかを定めた。実際に偽装を防ぐには、保護されたLAN、正しい構成、実装の統制が必要だった。

最初のReplyが窓を閉じた

RFC 1122はstatic configurationとdynamic discoveryの両方を認め、方法を選択可能にした。discoveryが有効ならRequestを再送し、対象local addressについて最初に受けたReplyでmaskを設定する。solicitedでもunsolicitedでもよい。後続Replyはsilentに無視された。

first-winsは遅延や重複による揺れを抑える。しかし認証ではない。構造上もっともらしい偽Replyが正規agentより早く届けば、窓を閉じられる。

hostはreasonableness checkを行うことが推奨された。all-one maskではなく、zeroでない場合は最上位8ビットがonである、といった検査である。明らかな異常は排除できても、管理者の意図までは証明できない。

Address Mask messageを無効にした場合、Requestを送らず、受信したReplyも無視する。typeを理解することと、設定変更を受け入れることも別だった。

一つのLANに一つという前提の代償

共通maskという前提はmessageを単純化した。複数agentが同じ答えを出せばavailabilityが上がり、request-responseの厳密な紐付けも不要になる。

一方、誤った共有値は発見中のすべてのhostへ影響する。複数agentは値が一致するときだけ冗長性になる。異なるmaskを発行すれば、同じ物理媒体に複数の近隣観が生じる。

複数LANへ接続するhostはinterfaceごとにmaskを知る必要がある。これはmaskがhost全体のidentityではなく、addressとattachmentの組に属することを示す。

また、maskだけを別の交換で受け取ると、address、router、その他のboot情報との整合を外部の慣習に頼る。同じ起動について別々のprotocolが異なる時点やauthorityを表す可能性があった。

DHCPは旧mechanismを直ちに消さなかった

RFC 2131は、RARP、ICMP、BOOTPなどがboot情報の断片を分担していた状況を説明する。DHCPはaddress allocationとconfigurationを状態のある一つの交換へまとめた。

それでもICMP mask requestは利用可能な旧手段として記載された。subnet maskはinterfaceごとのhost configuration parameterだった。

RFC 2132のOption 1は4オクテットのSubnet Maskを直接運ぶ。Router optionと同時にある場合、maskを先に置く。clientがrouter addressを解釈する前にlocal boundaryを知るためである。

さらにOption 29のPerform Mask DiscoveryはICMP discoveryを実行するかを指示し、Option 30のMask SupplierはICMP requestへ答えるかを指示する。新しいconfiguration channelは値だけでなく、古い質問者と発行者の役割も管理した。

この形は移行を示す。DHCPの公開日にtype 17/18が消えたわけではない。直接値を渡し、冗長な発見を止め、必要なら旧機能を意図的に残す選択肢があった。

設定の単位が大きくなった

addressを割り当てたり確認したりするserverがmaskも同じ関係の中で渡せば、ICMPの沈黙だけにsubnet存在判断を背負わせずに済む。

DHCPが必ず正しいという意味ではない。provenanceと整合を一つのconfig relationshipへ集め、legacy pathをexplicitに閉じられるようにしたことが変化だった。

共存中も権威規則は変わらない。DHCPがMask Supplierを有効にする指示は明示的設定である。ICMP Replyを聞いただけのhostにはその役割がない。

孤立した一事実を尋ねる仕組みから、関連する複数事実を一緒に扱う仕組みへの移行が、最終的なsupersessionの実体だった。

Deprecatedは番号を消すことではなかった

RFC 6918は複数のICMPv4 message typeを正式にdeprecateした。Address Mask Request/Replyについては、host configuration用途がDHCPなどにsupersedeされたと説明する。

これは全実装が同時に停止したという測定ではない。新しい依存を作らないようにし、registry statusを既に変化した運用へ合わせる行為だった。

RFC 7279もtype 17と18をDeprecatedとして列挙する。番号を歴史上の座標として残せば、古いpacketを新しい意味へ再割り当てする混乱を避けられる。

流れは段階的だった。単独のlocal discovery、明確化されたagent authority、DHCP optionによる共存管理、そして正式なdeprecationである。

Captureから言える範囲

type 18をcaptureすれば、その場所で32ビットmaskを主張するICMP messageが観測されたこと、visibleなaddress、checksum、Identifier、Sequenceは確認できる。requestとの対応を推定する材料にもなる。

送信者がexplicitにagentへ設定されていたこと、値が管理者の設計と一致すること、受信hostがinstallしたこと、もっと早いReplyがなかったことは証明できない。syntaxはadministrative authorityではない。

無応答のRequestは、ある期間にReplyを観測しなかったことしか示さない。agent不存在、停止、filter、lossは同じ見え方をする。fallback maskはhostのruleの証拠であり、LAN topologyの証明ではない。

この歴史の核心は、事実を受け取ることと、その事実を公式に発行する権限を分けた点にある。沈黙も回答も、単独では他者を設定する権力を生まない。

情報源と証拠の限界

閉じた情報源はRFC 950、RFC 1122、RFC 2131、RFC 2132、RFC 6918、RFC 7279である。設計、host要件、DHCP共存、deprecationは確立するが、過去や現在のdeployment、個別senderのauthority、vendor compliance、実際のmaskの正しさは測定しない。