要約

  • RFC 1504 は、独立管理された AppleTalk internet の番号衝突を、トンネル上の一意な UI と受信側のローカル番号に分けて処理した。
  • ローカル番号が冗長経路を通って作成元へ戻り、DI と元の範囲という来歴を失うと、ルーターは自分の写像を実在する新ネットワークと見なし、再写像して shadow network を作り得た。
  • 仮想リンク、split horizon、RI-Ack、MIB 行はいずれも限定された証拠である。完全な判断には写像 epoch、入出力ポート、接続と sequence、snapshot、payload 結果が要る。

仮想リンクは地図であって隣接の測定ではない

RFC 1504 は1993年8月、Apple Computer の Alan Oppenheimer 名義で Informational RFC として公開された。Internet 上を流れる可能性のある Apple のプロトコルを詳しく記録することが目的であり、Internet Standard を定める文書ではない。

AURP は AppleTalk Phase 2 の広域接続を扱った。IP など別のプロトコル網をトンネルとして利用し、その上で AppleTalk データと経路情報を運ぶ。複数の外部ルーターが参加するトンネルは、AppleTalk から一つの仮想データリンクに見えた。

この見せ方には前提があった。トンネル上の外部ルーターは相互に直接通信できる、と AURP は想定した。各ルーターは split horizon を行い、同じトンネルの別ルーターから学んだ経路を、さらに同じトンネルへ転送しない。

実際には、マルチポイントトンネルが部分接続である場合もあった。A と C は互いを知らず、B だけが双方と話せる。意図的な分離か、設定ミスかを B は通常判定できない。論理的には一つのリンクでも、物理的・管理的には二つの関係だった。

抽象化が現実より広いと、split horizon は「別の参加者が直接伝えるはずだ」と考えて情報を止める。RFC 1504 は、必要なら A—B と B—C を独立した二つのトンネルとして表現する方法を示す。名前を変えるのではなく、事実に合わせて境界を描き直す考え方である。

同じ番号を持つ二つのネットワーク

独立運用の AppleTalk internet は、同じネットワーク番号をそれぞれ正当に使っていることがある。相互接続する前には問題がない。トンネルで同じ世界に入った時点で、番号だけでは一意に選べなくなる。

AURP は、トンネル内の identity とローカル表示を分けた。各 export network には UI があり、remapping を行う外部ルーターは DI と元の network number または range を組み合わせて UI を作る。受信側では UI に対し、予約した remapping range から衝突しないローカル番号を割り当てる。

古い端末はグローバルな識別法を理解しなくてよい。普通の AppleTalk 番号として遠隔ネットワークを扱える。境界ルーターが UI と local alias の対応を保持する。

しかしローカル番号は、自分が翻訳結果であることを表さない。同じ UI が場所ごとに違う番号になり、同じ番号が時期ごとに違う UI を指す。表示値の一致も不一致も、identity の結論にはならない。

静的な対応表と動的な時間

static remapping は特定 UI に既知の番号を予約する。管理しやすいが、有限の領域を使う。dynamic remapping は到着したネットワークに順次番号を与え、より多くを収容する。そのかわり番号の意味が時間で変わる。

RFC 1504 は、ほかの番号が残っている間は再利用を避け、down になったネットワークの位置を新しいネットワークへ直ちに渡さないよう勧めた。現在の表から行が消えても、遅延 packet、cache、別経路、監視記録には古い意味が残るからである。

したがって対応表には epoch が必要だ。「47 は X」では足りない。「ルーター R のポート P で、時刻 T1 から T2 まで、47 は <DI, original range> を表示した」と記録する。再利用は値の変更ではなく、identity history の区切りである。

書き換え可能な場所には限りがあった

remapping は単なる外側のカプセル化ではない。ルーターは DDP header の network number、NBP entity address、AURP routing data を書き換え得た。DDP checksum がある場合は変更前に検証し、変更後はゼロに設定する。以前の checksum は新しい packet を証明しない。

一方、未知の third-party protocol が payload 内部に埋め込んだ network number は見つけられない。外側は正しく届き、内側の参照だけが古いまま残る。トンネルも route も正常で、application だけが失敗する状態が生まれる。

network management の応答も、data の中では元の未変換番号を返し得た。管理 station は AURP の remapping database と照合して初めて local view を得る。RFC 1742 は後に AppleTalk port、RTMP table、counter の標準 MIB object を与えたが、一行の値を全層共通の identity にはしなかった。

自分で作った番号が別経路から帰ってきた

shadow network は、トンネルのほかに冗長経路があるとき生じる。外部ルーターが remote UI を local alias に変換する。その alias がローカル側へ広がり、別経路を通って元のルーターへ戻る。

戻った情報には、最初の DI と original range が付いていない。見た目は本物の local network range と同じである。ルーターは自分の出力だと認識できず、新しいネットワークとして再び UI を作り、別の local range に写し、トンネルへ export する。

物理ネットワークは一つのまま、routing table には複数の range が現れる。RFC 1504 はこれを shadow network と呼ぶ。周回ごとに見かけの個体数が増え、最終的には hop-count limit を超えて到達不能になる。

hop limit は無限転送を抑えるが、identity を修復しない。消えた route がどの元ネットワークの影だったかは、mapping history がなければ残らない。

一部だけ remapping すると検出も非対称になる

remapping は各ルーターの管理者が個別に設定した。同じトンネルで一部だけ有効にすると、番号衝突が起きやすい。さらに RFC 1504 は、remapping 有効ルーターは関連する loop detection を行うが、無効ルーターは行わないと説明する。

非 remapping ルーター同士に loop があれば、そこで返る情報は検出されず、remapping ルーターへ複数の shadow copy として現れる。安全機能を一部導入したことで、全体の安全が一部だけ成立する。

remapping を行う冗長ルーター同士は、同じ local internet に同じ DI を用い、remote UI を同じ local number に写す必要があった。RFC は手作業の共通設定や将来の共有を挙げるが、AURP は当時その同期を支援しないと明記した。

経路の redundancy と identity state の redundancy は別の納品物だった。

類似した route は調査開始の根拠

RFC 1504 は、受信した range size と zone list が local network に一致するとき、loop-indicative だとした。ただしそれだけで loop と断定しない。トンネルへ AppleTalk packet を送り、local port から戻るか観察する loop-investigation を提案した。

属性の一致は仮説である。同じ probe instance の帰還は現在の path evidence である。それでも管理者の意図、将来の topology、全 application の結果までは証明しない。

security についても文書は範囲を狭く保つ。network hiding と device hiding を weak form と呼び、一般の security concern を扱わない。Chooser に表示されないことは、認証された不在ではない。

snapshot の途中へ delta が到着する

AURP は最初に routing information を交換し、その後 event で更新する。one-way connection には connection ID があり、packet は sequence number を持つ。sender は RI-Ack を待って次へ進む。

しかし、pending event がある間に新しい peer が接続すると、initial RI-Rsp と後続 RI-Upd の関係が一見矛盾することがある。RFC 1504 は recovery rule を定めた。未知 network の distance change は addition として扱い、既知 network の addition は distance change として扱い、未知 network の一部 down event は無視する。

これは不完全な観測から usable state を作る規則であり、全 peer の同時 snapshot ではない。RI-Ack は一つの sequence の受信を示す。local RTMP propagation、remapping table の一致、payload delivery は別に観測する必要がある。

receiver の table が overflow して情報を失った場合、sender は全 delta を自動再送しない。receiver は RI-Req で complete routing table を取り直すべきだとされた。履歴に穴があれば、最新イベントだけでは現在を証明できない。

影を一つの object へ戻すための記録

調査では、少なくとも次を結ぶ必要がある。

  • original <DI, range> と export peer
  • router、port、local alias、mapping epoch
  • connection ID、sequence、snapshot または event
  • return を観測した ingress path
  • table version と selected next hop
  • 対象 service に結び付く probe または payload result

異なる二つの番号が同じ original UI に戻るなら shadow の可能性がある。同じ番号が異なる epoch の UI に戻るなら reuse である。route が正常で payload の内部参照だけ失敗するなら翻訳範囲の問題である。

番号は execution key として役立つ。provenance record なしには object key にならない。

資料が証明しないこと

資料は AURP の配備数、特定製品の完全な実装、実在した shadow-network incident、現在の利用率を示さない。Informational RFC の詳しさは実行証明ではない。

RFC 1378 は PPP 上で AppleTalk を交渉し、AURP routing information を運ぶ形式を示すが、convergence を保証しない。RFC 1742 は management vocabulary を定めるが、ある agent が complete remapping state を公開した証拠ではない。Lu Heng の論考は、specification、local choice、presentation、running result を別の receipt として扱う読み方を与える。

古い AppleTalk の話が現在にも通じるのは、製品名が残ったからではない。compatibility layer が有効に働くほど、その local alias は自然な identity に見える。RFC 1504 は、その見え方が戻り経路を得た瞬間に object を増殖させる様子を記録した。

出典