要約

  • RFC 1419 は TCP/IP を持たない AppleTalk 対応機器にも通常の SNMP メッセージを運んだ。PDU の意味は保ち、UDP/IP の宛先だけを DDP のネットワーク・ノード・ソケットの組へ置き換えた。
  • AppleTalk の住所は再起動で変わり得るため、比較的安定した NBP 名を継続的な参照にし、名前から住所へのキャッシュを管理局の再起動後も保持するよう勧めた。名前解決が壊れても、既知の住所への直接通信は残り得た。
  • ただし古い住所は本人確認ではない。別のノードが同じ DDP 住所を取得すると、SET は誤った代理へ届き、その応答を本来の相手から区別できない場合があった。

SNMP の中身を変えず、下の道だけを替えた

1993 年3月の RFC 1419 は、AppleTalk は実装していても TCP/IP を持たないネットワーク要素を対象にした。標準の SNMP メッセージを DDP データグラムのデータ部へ入れる。複数のスタックを持ち UDP が使える機器には UDP を優先すると明記した点が重要である。既存機器を管理に参加させる追加経路であって、全機器を AppleTalk へ寄せる計画ではなかった。

この移植性は RFC 1157 の薄い境界から生まれた。SNMP の各メッセージは一つのデータグラムとして独立し、双方向性とアドレス可能性を備える別の輸送も使える。GetRequest、GetNextRequest、GetResponse、SetRequest、Trap は同じまま、輸送アドレスの定義だけが変わる。

DDP の住所はネットワーク番号、ノード番号、ソケット番号を組み合わせ、さらにプロトコル種別を持つ。データ部は最大586オクテットだった。要求はソケット8、プロトコル種別8へ送る。応答は要求元のソケットへ返り、その送信元は要求時の宛先に対応する。Trap はソケット9、種別8を使った。

この対応は配送と多重化を決める。しかし、正しいソケットから返事が来たことは、永続的な装置名や管理権限まで確定しない。

住所が動くため、名前を長く生かした

AppleTalk の Name Binding Protocol は object:type@zone という論理名を DDP 住所へ結び付けた。各欄は大文字小文字を区別せず、通常は読める文字列で、最大32オクテットである。代理は SNMP Agent、Trap の受信局は SNMP Trap Handler という種別を広告した。

object には同じ機械が他サービスでも使う名前を選ぶよう勧められた。Macintosh なら System 7 の Macintosh Name である。ファイル共有と管理を同じネットワーク上の装置概念へ寄せられる。

だが、これは暗号学的な身元ではない。AppleTalk のネットワーク住所は再起動ごと、あるいはそれ以上の頻度で変わり得た。一方、代理や Trap 処理局の NBP 名は、典型的な TCP/IP 終端の IP アドレスより頻繁には変えず、PRAM やディスクなどの安定記憶へ置くことが期待された。

「何を管理したいか」は名前に残る。「今どこへ送るか」は DDP 住所で決まる。その対応をいつ、どの方法で確認したかが第三の記録になる。RFC 1419 の後半は、この三つを混ぜると何が起きるかを示した。

キャッシュは発見系から運用を切り離した

NBP 検索は通信量と CPU を使う。しかも、ゾーン表の不整合、ルータ内のブロードキャスト要求から転送要求への変換障害、対象ノードの NBP 障害などに弱い。これらは管理局と代理の直接 DDP 通信を必ずしも壊さない。名前から住所を尋ねられなくても、既知の住所へは届く場合がある。

そこで RFC は、NBP 検索を主としてキャッシュ作成に使い、その対応を管理局の再起動後も保持するよう勧めた。反復検索の負荷を下げるだけでなく、基本の名前変換が壊れたときにも障害調査を続けられる。

保存は永久承認ではない。最後の確認から T1 秒を過ぎたエントリを使うときは確認を試みる。T1 の最小既定値は60秒で、設定可能とされた。ルータなど重要な基盤ノードを他より新鮮に保つこともできる。

大量の名前を持つ長時間稼働の管理局は、起動時に一斉解決してはならない。一定期間へ分散し、設定した優先順位に従う。標準が共通にしたのは確認可能な形式であり、どの装置を先に扱うかという将来判断ではなかった。

Trap の相手は検索結果ではなく設定で決まった

代理が Trap を送るには、特定の管理局または管理局群の名前が事前設定されていなければならない。設定がなければ Trap は送らない。受信者を探すためのワイルドカード NBP 検索は明確に禁止された。

設定ツールが利用者にネットワークを見せ、候補から管理局を選ばせることはできる。だが候補の発見と、実行中の代理がイベントを渡す相手の決定は別である。名前サービスが返しただけの相手へ、運用イベントの流れを任せなかった。

代理自身はキャッシュを先に埋めず、実際に Trap を送る時だけ検索または確認する。要求への応答は別で、要求の外側に返送先ソケットがあるため、返信前のキャッシュ確認は不要だった。

Trap のゼロは、輸送層が知らないものを隠さなかった

SNMPv1 の Trap-PDU には Internet のネットワーク住所を入れる agent-addr があった。AppleTalk 専用代理に IP アドレスはない。RFC 1419 は架空の値で欄を満たさず、全ビットをゼロにした。

その代わり、Trap は SNMP Agent 登録に対応する nbpObject と nbpZone を VarBind に含める。RFC 1243 はこれらを nbpType、nbpState と別々の管理対象として定義した。外側の DDP 送信元、ゼロの IP 欄、名前とゾーンは、同じ事実の重複ではない。

ゼロは欠陥ではなく、証拠能力の境界である。この欄は AppleTalk 輸送上の送信者を名指せない。NBP 値はキャッシュとの照合材料になるが、イベントの真偽、送信権限、対応完了までは証明しない。

読み取りによる確認と、書き込みの競合

古いかもしれない住所は、そこへ単播 NBP confirm を送るためのヒントとして使える。管理局は SNMP の GetRequest に対象の NBP object と zone も加え、返答の DDP 送信元と返された名前欄をまとめて確認することもできた。

ここでは、一回の読み取りが到達性と名前対応の追加証拠を生む。それでも SET には時間差が残る。古いノードが停止し、新しいノードが同じ DDP 住所を取得した直後なら、古いキャッシュから送った SetRequest は新しい代理へ届く。

新しい代理が正しい形式で返答し、その送信元住所も要求の宛先と一致すれば、管理局は本来の相手の応答と区別できないことがある。住所一致は通信の整合性を示しても、装置継続性を示さない。

RFC は、将来 SNMP のセキュリティが宛先で各パケットを認証すれば、この競合を防げると書いた。未来形であり、当時の NBP 名、community、住所がすでに強い認証だったという意味ではない。RFC 1157 は community、MIB view、access policy を分けたが、Security Considerations では安全性を論じないと記していた。

名前解決が壊れた時の局所的な迂回

専用の AppleTalk 管理局は、必要なら NBP のルータ側機能を自ら持つことができた。ゾーンとネットワークの対応を知っていれば、代理が最後にいたネットワークへ転送要求を送り、さらに各ネットワーク番号へ directed DDP multicast で検索できる。

これは限定された単一障害への対処であり、分断、全面的な設定誤り、消えた代理、再利用済み住所をすべて直すものではない。重要なのは、回復判断が管理局側に残ったことである。全ノードへ厚い回復制度を強制せず、共通形式だけで局所的な運用判断を可能にした。

RFC 1419 のキャッシュは、発見サービスへの依存を減らした。同時に、運用記憶が現実より長く残る危険を明示した。名前、住所、確認時刻、確認方法、要求種別を残さなければ、「応答あり」という一行が、読み取りと誤書き込みの差を消してしまう。