要約

  • APNICのRDAP記録はAS136022をJanani Technologyに関連付け、登録オブジェクトをactiveとしている。これは番号資源の管理上の身元であり、経路、BGPセッション、機器、サービスの稼働状態を示すものではない。
  • 取得時のPeeringDBにはAS136022の行が一件あったが、交換LAN接続行はなく、ウェブサイト、ネットワーク種別、一般的なピアリング方針、IRR AS-set、IPv4・IPv6プレフィックス数も空欄だった。欠けているのは申告であり、ピアリングやアドレス資源が存在しないという証明ではない。
  • 2026年8月7日00時00分UTCの凍結RIS応答は、条件を満たす経路についてIPv4で326/327、IPv6で320/320という可視性を返した。この値は記載されたピア集合、時刻、低可視性の除外条件に限られ、普遍的な到達性、経路認可、容量、復旧性、顧客サービスを保証しない。

AS136022は対象をそろえるための識別子

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

AS136022を共通キーにすれば、Janani Technologyのディレクトリエントリー、APNICの管理オブジェクト、PeeringDBのプロフィール、RISの観測が同じ番号資源を扱っているか確認できる。似た企業名や別のネットワークを取り違えないために、これは重要な出発点になる。

しかし、ASNはセンサーではない。正しい番号を特定できても、その瞬間に経路が広告されていたか、相手が受け入れていたか、アプリケーションが利用できたかは分からない。身元を固定した後、質問に合う証拠へ進む必要がある。

APNIC RDAPが示すのは管理台帳

RDAP（Registration Data Access Protocol）は、インターネット番号資源の登録情報を構造化して取得する仕組みである。凍結されたAPNIC応答では、開始番号と終了番号がともに136022、handleがAS136022、オブジェクト名がJANANITECHNOLOGY-AS-APだった。エンティティ名にはJanani Technologyが含まれている。

登録イベントは2019年2月3日08時31分56秒UTC、最終変更イベントは2021年1月18日03時52分25秒UTCとして記録されている。これらは管理オブジェクトの履歴である。ネットワーク機器の導入、経路変更、サービス開始、顧客影響が起きた時刻とは限らない。

activeも同じ境界で読む。これはAPNICのオブジェクト状態であって、ルーターへの電源供給、BGPセッションの確立、経路の認可、サービスの正常性を検査した結果ではない。登録簿は番号の一意性と追跡可能性を支えるが、稼働中のコードやネットワークの状態を代わりに決めるものではない。

PeeringDBの空欄は否定的な測定ではない

取得時のPeeringDB応答には、ASN 136022に対して一件のnetwork行があった。record idは40097、名称はJanani Technology、プロフィールのstatusはok、更新時刻は2026年4月4日16時50分22秒UTCだった。

一方、その応答にはnetixlan行がなかった。ウェブサイト、情報種別、一般的なピアリング方針、IRR AS-set、IPv4とIPv6のプレフィックス数も空またはnullだった。この状態が示すのは、取得したプロフィールに該当する申告がなかったということだけである。

交換LANの行がないからといって、Janani Technologyがどの交換点にも参加していない、非公開の相互接続を持たない、別の場所でピアリングしていないとは結論できない。方針欄の空白から、open、selective、restrictiveのいずれかを推測することもできない。プレフィックス数の空欄は、アドレス資源や経路がないという測定ではない。

okもプロフィール行の状態であり、BGPセッションや機器、サービスのヘルスチェックではない。PeeringDBは調整に役立つ公開申告の場所だが、空白を稼働上の不在へ置き換えることはできない。

凍結RIS応答は時刻と観測集合を持つ

RISは、参加する観測点からBGP情報を収集する仕組みである。今回のrouting-status応答では、query_timeが2026年8月7日00時00分UTCだった。条件を満たす経路について、一覧にある327のIPv4フルフィードRISピアのうち326、320のIPv6フルフィードRISピアのうち320から可視だったと報告している。

announced-space欄は、IPv4を一プレフィックス・256アドレス、IPv6を二プレフィックス・二つの/48相当として返した。observed neighboursは1だった。ただし、この1はendpointの観測モデルに属する値で、直接ピア、契約、交換セッション、施設、独立した物理経路の数ではない。

応答は、十未満のRISフルフィードピアにしか見えない低可視性の経路を結果から除外すると明記している。したがって326/327と320/320は、指定された時刻、ピア集合、製品、しきい値の中で読む必要がある。世界中の全ネットワークからの到達性、経路認可、選好、トラフィック、遅延、容量、復旧性、顧客体験を示す値ではない。

query_time、first seen、last seenを混ぜない

同じ応答のlast-seen欄は、103.134.41.0/24、origin 136022、時刻2026年8月7日00時00分UTCを記録している。first-seen欄は別のプレフィックス103.134.42.0/24について、2019年2月13日16時00分UTCを返した。

query timeとlast-seenの時刻が同じでも、二つのフィールドは同じ意味ではない。query timeは返されたrouting-statusの観測文脈、last seenはendpointが選んだ一つのプレフィックス欄、first seenは別の履歴欄である。三つをつないで、ネットワークの開始、停止、障害、継続的な広告の時系列を作ることはできない。

コレクターがorigin ASNを伴うプレフィックスを見たことは、アドレス保有者による認可や有効なroute-origin authorizationも自動的には証明しない。認可を問うなら、その目的に合う登録・セキュリティ記録が別に必要になる。

検証は証拠層を順に追加する

最初にAS136022を対象として固定し、APNICの番号とエンティティ名がJanani Technologyのディレクトリ記録と対応しているか確かめる。ここでは管理上の身元、handle、イベント履歴を確認し、似た名称との混同を避ける。

次にPeeringDBで、実際に申告されている項目だけを読む。空欄は未解決の質問として残す。特定の交換接続やセッションを確認する必要がある場合、権限のある運用担当者は設定、契約、セッション状態、送受信経路を別の情報で確認しなければならない。

経路について判断するときは、コレクター製品、query time、アドレスファミリー、ピア分母、除外しきい値、対象プレフィックスを一緒に保存する。経路認可には対応する認可記録、顧客サービスには時刻をそろえたend-to-end試験とアプリケーション観測が要る。一つの公開記録に別の層の答えを背負わせないことが、誤判定を減らす。

APNICの登録、PeeringDBのプロフィール、凍結されたRIPE RISスナップショットは別々の証拠層である。どれか一つだけで、稼働中のピアリングセッション、普遍的な到達性、経路認可、容量、復旧性、顧客サービスを証明することはできない。

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

この資料から確認できるのは、Janani TechnologyとAS136022の管理上の対応、取得時のPeeringDBプロフィールに含まれた申告、そして一つの時刻におけるRISコレクターの観測である。会社のサービス、運用地域、顧客、施設、機器、上流ネットワーク、物理構成、事業規模、市場での位置は確認できない。

交換点への参加、route-serverとの関係、セッション状態、トラフィック量、スループット、遅延、空き容量、障害原因、復旧性、サービス性能も未解決である。空欄を不在と決めず、可視性を普遍的な保証と決めないことが、公開記録を現実に即した検証層として使う条件になる。

今後の注視点

  • APNIC RDAPにおけるAS136022のオブジェクト名、エンティティ、管理状態、イベント履歴の変更。
  • PeeringDBにおけるJanani Technologyの名称、方針、プレフィックス数、交換接続の申告の追加や変更。
  • query time、アドレスファミリー、RISピア分母、低可視性の除外条件を明記した後続の観測。
  • 経路認可を問う場合に参照できるroute-origin関連の登録情報。
  • ピアリングや顧客体験を問う場合の、権限のあるセッション情報またはサービス固有の時刻付き試験。

情報源