Summary

  • RFC 1383は、周縁の複数接続ネットワークへ入るゲートウェイを逆引きDNSのRX情報で探し、内部ネットワークを一つずつ世界の経路表へ載せずに済ませる構想だった。
  • 記された試作はICMPの到達不能通知を受けてからDNSを調べた。原文は最初のパケットを失う危険を認め、DNS上の掲載と現時点の到達性を分けている。

パケットを送る。ルーターが宛先への道を知らないと返す。その失敗を合図に、別のプログラムがDNSに行き先の入口を尋ねる。Christian Huitemaが1992年12月に書いたRFC 1383では、経路がないという返答が経路発見の始まりだった。通常のIPルーティングコードを大きく変えずに試せる。そのぶん最初のパケットは失われうる。

背景には経路表の膨張があった。文書は当時のNSFNETに5,000超、EBONEに7,000超のネットワークが載っていたと記す。新しい広告は中継ルーターの記憶容量、経路交換量、運用者のポリシー判断を増やす。階層的なアドレス集約は有力だったが、複数の接続事業者を使い、アドレスを保ったまま乗り換えたい利用者には窮屈な面があった。

HuitemaはメールのMXレコードから発想を借りた。周縁のドメインDには、外から見える二つのゲートウェイI1とI2がある。両者はDの内部経路を知っているが、その全件を世界へ広告しない。送信元は宛先アドレスについてin-addr.arpaを引き、実験的なRX情報から入口を選び、ソースルートを付けてそこへ送る。初期実験のRXは新しい専用DNSレコードではなく、TXTの中に識別子、優先度、ゲートウェイIPアドレスを書いたものだった。

入口は送信元か、その近くのルーターが一度だけ選ぶ。途中の全ルーターがDNSを引けば改造が広がり、前後で違う入口を選んで回り道やループを作りかねない。二つの入口は単一障害点と一社への依存を減らすが、DNSに名前があるだけでは通れる証拠にならない。送信元は故障が判明した入口を候補から外さなければならず、検知の速さは未解決だった。

DNS自体にも到達可能な置き場所が要る。DのRX情報はインターネットの中核側からアクセスできるサーバーに複製する必要があった。閉ざされたドメインの内側だけに道案内を置いても、外からは読めない。

説明されたソフトは、カーネル内の転送部とDNS照会管理部を分ける。ICMP到達不能を見て検索を始め、応答待ちのパケットは列で寿命を減らす。RX情報がなければ宛先を到達不能とし、列のパケットを破棄する。RFCは、IPコードを変更できるなら直接そこへ接続する方がよいとも述べる。最初のパケットをICMPの呼び鈴に使わずに済むからだ。公式記録ではExperimentalであり、結論はINRIAでコードを開発中と記している。

提案には価格の問題も潜んだ。独立したネットワーク広告に費用がかかれば、利用者は一社のアドレス空間へ移る圧力を受ける。RXは別の選択肢を作ろうとした。中継網が抱える共通知識を減らす一方、送信元には検索、入口の健康確認、失敗からの回復が残る。DNSは門の場所を教えられる。門が開いているかは配送で確かめるしかない。

Sources