要約

  • RIPE RDAPはAS212483だけを対象とする管理オブジェクトをactiveとして記録し、組織レコードをLEVEL EIGHTY-SIX COMMUNICATIONS LTDに関連付けている。これは番号資源の識別情報であり、経路、ルーター、BGPセッション、サービスの稼働確認ではない。
  • PeeringDBはLevel 86について十一件の交換接続行を申告している。一方、RIPEstatの時刻付き応答では、IPv4とIPv6で大きく異なるRIS可視性が返された。前者は参加者が管理する申告、後者はしきい値を持つコレクター観測であり、同じ種類の証拠ではない。
  • 調査ではAS212483を共通の対象として固定し、登録、申告、稼働観測を順に照合する必要がある。行数や速度欄、可視性の分母を、物理経路、実効容量、障害、普遍的な到達性へ読み替えてはならない。

AS212483を基準に調査対象を揃える

自律システムは、インターネットに対して共通のルーティング方針を示すネットワーク、またはネットワーク群である。自律システム番号、すなわちASNは、そのルーティングドメインを一意に識別する。ネットワーク同士はBGP（Border Gateway Protocol）を使い、ASNに結び付いた到達性情報を交換する。

企業名やブランド表記は資料ごとに変わることがある。AS212483を軸にすれば、調査担当者はRIPEの管理記録、PeeringDBの申告、RISの観測が同じ番号資源を扱っているか確認できる。インシデント対応や取引先との調整でも、似た名称の別組織や別ネットワークを混同するリスクを下げられる。

ただし、識別子そのものはセンサーではない。AS212483が正しい対象であっても、ある時刻に経路が広告されたか、相手側が受け入れたか、顧客のアプリケーションが利用できたかは別の証拠を要する。最初に対象を固定し、その後に質問に適した観測へ進むことが重要になる。

RIPE RDAPが示す管理台帳

RIPEのRDAP応答は、開始番号と終了番号がともに212483で、handleにAS212483、オブジェクト名にlevel86を記録している。管理状態はactiveである。組織registrantのhandleはORG-LECL2-RIPE、名称はLEVEL EIGHTY-SIX COMMUNICATIONS LTDであり、この組織レコードがLevel 86のディレクトリエントリーとの限定的な身元の橋になる。

登録イベントは2022年8月8日13時34分13秒UTC、最終変更イベントは2025年12月9日10時25分29秒UTCとして返されている。いずれもRDAPオブジェクトの管理イベントである。ルーターの設置、経路広告、セッション確立、製品変更、顧客への影響が起きた時刻を表すものではない。

activeも同じ境界で読む必要がある。これは登録オブジェクトの管理上の状態であり、BGPの到達性や機器、アプリケーションの正常性を測定していない。応答にはregistrant役割を持つ別のオブジェクトも含まれるため、すべての役割表示を商業上の保有者とみなすのも不正確である。ここで身元確認に用いるのは、名称が明記された組織レコードである。

この範囲で、レジストリは有用な台帳になる。番号資源の一意性、関連する名称、管理履歴を追跡可能にする一方、稼働中のネットワークの瞬間的な状態を代わりに決めるものではない。

PeeringDBは参加者による相互接続の申告

PeeringDBの応答にはASN 212483について一件のnetwork行がある。名称はLevel 86、別名は86 COMMUNICATIONS、分類はEnterpriseで、一般的なピアリング方針はOpen、IRR setはAS-86と記載されている。IPv4プレフィックスは100、IPv6プレフィックスは120と申告されている。

これらは参加者が管理する公開ディレクトリ項目である。方針やIRR setは、運用チームが期待する設定と照合するための手掛かりになる。プレフィックス数は申告された範囲を示すが、同じ時刻にコレクターが見た経路数ではなく、他のネットワークが受け入れた経路や現在のトラフィックも示さない。

入れ子になった交換接続データには十一行がある。NetIX、CHIX-CH、LOCIX Frankfurt、Poema IX、FogIXP、NL-ix、Lambda-IX、LOCIX Düsseldorf、BGP.Exchange Zurich、FREMIX、ZXIX Hong Kongが含まれる。十行はoperationalがtrue、一行はfalseで、十一行すべてにroute-server-peerのflagがある。

申告速度の内訳は100 Mbpsが二行、250 Mbps、500 Mbps、10,000 Mbpsが各一行、1,000 Mbpsが六行である。この情報は、どのディレクトリ行や設定を確認すべきか絞り込む助けにはなる。しかし、operationalは継続的なセッション監視ではなく、route-server-peerのflagもBGPセッションの確立や経路交換を証明しない。速度欄は実トラフィック、利用可能な余力、契約容量、性能の測定値ではない。

十一行という数から、十一の独立した施設、光回線、電源系統、上流ネットワークがあるとも判断できない。論理的な申告の数と、障害から独立した物理経路の数は別である。多様性や復旧性を評価するには、実際の依存関係と対象とする障害シナリオについて追加の証拠が必要になる。

RIPE RISが返したのは時点付きの観測

RIPEstatのrouting-status応答では、query_timeが2026年8月7日00時00分UTCとされている。その応答は、一覧にある327のIPv4フルフィードRISピアに対して、条件を満たして可視となったIPv4プレフィックスをゼロと報告した。IPv6については16プレフィックス、31個の/48相当を報告し、一覧の320のIPv6フルフィードRISピアすべてから可視だったとしている。

RISは、参加する観測点からルーティング情報を受け取るコレクションシステムである。このendpointは、十未満のRISフルフィードピアでしか見えない経路を結果から除外する。したがってIPv4の値は、このしきい値と観測集合で返された結果を表す。世界中の全経路が消えた、Level 86の全IPv4サービスが使えなかった、障害が発生した、と証明するものではない。

IPv6の320/320も、指定されたコレクター集合に対しては強い観測だが、普遍的な到達性、経路の正当性、低遅延、冗長性、顧客アプリケーションの正常性までは保証しない。経路が見えていても、その先のDNSやアプリケーションが失敗することはあり得る。逆に、一つのサービス試験だけでインターネット全体の経路状態を説明することもできない。

応答には2,964というobserved neighboursの値もある。これはendpointのモデルが算出したコレクター由来の値であり、直接ピア、商業契約、施設、物理経路の数ではない。

query_timeとlast_seenを一つの時刻にしない

同じrouting-status応答には、IPv6プレフィックス2401:5a0:ff03::/48のlast_seenとして2026年8月7日00時00分UTCが記録されている。これは応答が示すquery_timeと同じ時刻値だが、別のフィールドに属する。二つを無理に結合して単一の「現在時刻」や運用上の変化の時系列を作るのではなく、それぞれのフィールド名と値をそのまま保持するのが適切である。

query_timeはendpointの問い合わせ文脈に属し、last_seenは返されたlast-seenプレフィックスの欄に属する。処理や更新方法について追加情報がない限り、二つのフィールドが同じ時刻値を持つことを、経路変更や障害の証拠にしてはならない。

応答はまた、41.216.185.0/24をorigin 212483のfirst-seenプレフィックスとして挙げ、時刻を2021年10月13日00時00分UTCとしている。これはendpointがfirst seenと呼ぶ履歴値である。プレフィックスの所有、経路認可、その後の継続的な広告を立証するものではない。

実務では証拠を順番に追加する

調査の第一段階は身元確認である。対象をAS212483に固定し、Level 86のディレクトリ名とRIPEの組織レコードが同じ番号資源を指すか確認する。次に、RDAPのhandle、組織、管理状態、イベント履歴を記録する。これで、似たブランド名を持つ別の対象へ調査がずれることを防げる。

PeeringDBは調整用のチェックリストとして使う。名称、方針、IRR set、プレフィックス欄、交換接続行を、調べたい設計や設定と比較する。特定の交換接続をサービス診断に使うなら、権限のある運用データで実際のセッション状態、受信経路、広告経路を確認する必要がある。

その後に、時刻と観測点を備えた稼働証拠へ進む。経路の質問では、コレクター、query_time、しきい値、address family、対象プレフィックスを残す。サービスの質問ならend-to-end試験とアプリケーションの観測を加え、容量の質問なら対象インターフェースやサービスについて期間を定めた測定を使う。

この順序なら、RDAPは資源を識別し、PeeringDBは申告された文脈を示し、RISは限定された観測を提供する。どの層も別の層の代わりにはならないため、結論を証拠の範囲内に保てる。

公開記録だけでは決められないこと

四つの公開情報から確認できるのは、Level 86とAS212483の身元、申告された相互接続面、時刻付きのRIS観測である。企業の完全な物理トポロジー、関係者間の商業条件、特定顧客が使う経路は確認できない。

トラフィック量、空き容量、経路認可、障害の原因、セキュリティ対策、性能、復旧性、サービス可用性も、この記録だけでは判断できない。IPv4の返却値から障害を結論せず、IPv6の返却値から普遍的な到達性を結論せず、交換接続の行数から物理的な多様性を結論しないことが、最も重要な読み方になる。

公開記録は、稼働中のシステムと照合するための現実的な基準層として強い。RIPEはAS212483を名称のある組織レコードに結び付け、PeeringDBは複数の交換接続を申告し、RISは指定条件下でIPv4とIPv6の異なる可視性を返した。サービスへの影響を述べるには、同じ時刻と対象に結び付いた追加の運用証拠が必要である。

今後の注視点

  • RIPE RDAPにおけるAS212483の組織レコード、管理状態、イベント履歴の変更。
  • PeeringDBにおける名称、方針、IRR set、プレフィックス欄、十一件の交換接続行の変更。
  • query_time、address family、ピア分母、低可視性の除外条件を保持した後続のrouting-status観測。
  • 特定のディレクトリ申告を確認または否定する、権威あるセッション情報や経路情報。
  • 可用性、性能、顧客影響を問う場合の、サービス固有かつ時刻付きのテレメトリー。

情報源