要約

  • RFC 9910では、rdap-downは直下の子オブジェクトを探し、rdap-bottomは要求範囲を共同で覆う最も具体的な登録オブジェクト群を探す。
  • ARINの/21に対する実測応答は、有効な/22直接割り振りと管理状態の/8を返した。/8は残余部分を覆うためであり、/21の子であることを意味しない。

上下が逆に見える応答

結果の形は一見すると階層に反する。ARINのRDAPサービスで149.112.152.0/21のbottomオブジェクトを調べると、二つの登録が返る。一つはNET-149-112-152-0-1で、149.112.152.0/22として表される有効な直接割り振り。もう一つはNET-149-0-0-0-0で、149.0.0.0/8として表される管理用オブジェクトである。

/8が/21より具体的な子になることはない。しかしサービスもそう主張していない。矛盾はbottomを「このノードより下にある全ての葉」と読むことから生じる。RFC 9910の問いは別だ。クライアントが渡したインターネット番号資源の全域を、利用可能な最も具体的な登録オブジェクトで共同して覆うには何が必要か、である。

/22は対象/21の半分しか覆わない。残りのアドレスについて、この応答で利用できる最も具体的な登録は広い/8だった。そのためbottom集合は重複を含む。相互に排他的な子区画ではなく、要求範囲全体を説明する登録上のカバレッジである。

DownとBottomは違う

同じ/21に対するrdap-downは、/22の直接割り振りだけを返した。rdap-downがたどるのは直下関係だからだ。入力範囲のすぐ下に存在する登録オブジェクトを探すため、/8は対象にならない。

一方、rdap-bottomはカバレッジを計算する。より具体的なオブジェクトが一部しか覆わない場合、残余アドレスを説明するために包含オブジェクトを集合へ残す。RFC 9910はbottomオブジェクトが互いに素とは限らず、照会値より非具体的なオブジェクトさえ入り得ると明記する。ARINの説明も、発見したbottomオブジェクトが範囲を完全に覆わない場合、残りを覆う最も具体的なネットワークオブジェクトを返すとしている。

この仕組みにより、クライアントは登録木を自ら再帰的に組み立てずに細分化の状態を確認できる。問題は表示側で起きる。全行を「下位割り振り」と表示すれば、カバレッジ用オブジェクトが偽の子関係に変わる。間違っているのはプレフィックスではなく、採用理由を失ったデータモデルである。

応答が持つ証拠の範囲

返された項目はいずれもip networkオブジェクトで、ハンドル、開始・終了アドレス、CIDR表現、RIR固有の種別、状態を持つ。今回の/22はDIRECT ALLOCATIONかつactive、/8はadministrativeだった。

これらは登録面の属性である。BGPでの広報、到達性、通信量、ROAによる認可を証明しない。今回、ARIN独自の任意の起点ASN配列はどちらも空だったが、空配列は経路が存在しない証明ではない。特定時点の一つの登録応答における一フィールドの状態にすぎない。

RFC 9083はIPネットワークオブジェクトを登録情報として定義する。RFC 9082も、通常のIP検索は照会値を完全に含む最も具体的な登録ネットワークを対象にすると説明する。登録の幾何学がそのまま稼働中ネットワークの状態になるわけではない。

関係名をデータから切り離さない

検証可能な記録には、プレフィックスだけでなく、要求した関係、入力範囲、取得時刻、各結果のハンドル、開始・終了、CIDR、種別、状態が必要だ。これらがあれば/8の意味は明確になる。/22が覆わない残りに対する登録上のカバーである。

BGPコレクタ、IRR経路オブジェクト、RPKI検証、内部アドレス台帳は別々に扱うべきだ。bottom検索が示すのは登録カバレッジであり、誰がルータを変更できるか、誰がアカウントを管理するか、法的権利を持つか、現在どの経路が見えるかではない。

関係名が落ちれば、正確な応答から架空の委任木が作られる。最も安全な表記は最も文字どおりのものだ。要求範囲を覆う、利用可能な最下層の登録オブジェクト群である。

情報源