要約

  • RIPEstat の routing-status レコードは query_time 2026-10-17T16:00:00 において、328 の RIS IPv4 ピアのうち 0、318 の IPv6 ピアのうち 0 がこの AS 番号を認識し、宣告された IPv4・IPv6 プレフィックスはいずれも 0、観測された近隣も 0 であると示す。
  • 一方、識別層は何かを返す。保有者文字列は LINX-ROUTE-SERV-AZURE London Internet Exchange Ltd. であり、PeeringDB には id 26805、org_id 791、名称 LINX MAPS のネットワークレコードがある。
  • aut-num オブジェクト、その RDAP 表現、経路オブジェクトの照会はいずれも 2026-10-18 に本文を返さなかった。したがってこれらのレコードは空ではなく、読めていない。

一つの番号に二つの名前

RIPEstat の AS-overview 呼び出しは AS211386 について、帰属を示す単一のフィールド holder だけを返し、その内容は LINX-ROUTE-SERV-AZURE London Internet Exchange Ltd. である（AS-overview レコード）。同じ番号について別途照会した PeeringDB は、id 26805、org_id 791、name LINX MAPS、asn 211386、status ok を持つネットワークオブジェクトを返す（PeeringDB ネットワーク照会）。この二番目の応答は到着時に省略記号で切り詰められており、そこには本稿が使わないフィールドが入っていた。ここに挙げた五つの値が、このレコードから得られるすべてである。

二つのカタログ、一つの番号、いずれも London Internet Exchange を指し、片方には Azure が付く名前。この番号を交換事業者とクラウド基盤に関連づけて記述できる根拠は、現時点でこれだけである。保有者文字列はデータ製品内部の帰属表示であって、サービス記述でも、会社構造の文書でも、記述された機能が動いている証拠でもない。本稿のために取得した資料の中に London Internet Exchange と Microsoft の関係を記述したものはなく、本稿もそれを主張しない。ディレクトリの AZURE London Internet Exchange Ltd. はこの名称を繰り返しているが、カタログ間の反復は運用の裏づけにはならない。

収集層が測ったもの

RIPEstat の routing-status レコードは AS211386 について query_time 2026-10-17T16:00:00 を持つ（routing-status レコード）。328 の RIS IPv4 ピアのうち 0 がこの AS 番号を認識し、318 の IPv6 ピアのうち 0 が認識する。宣告空間は IPv4 プレフィックス 0、IPv4 アドレス 0、IPv6 プレフィックス 0、IPv6 の /48 は 0 である。first_seen と last_seen のオブジェクトは空で、observed_neighbours は 0 である。first_seen が空であるとは、RIS がこの起点について最初の観測を一つも持っていないという意味であり、これは収集側の記録についての言明であって、世界についての言明ではない。

同じ番号の announced-prefixes 呼び出しは、2026-10-03T16:00:00 から 2026-10-17T16:00:00 の窓について空のプレフィックス一覧を返し、latest_time は 2026-10-17T16:00:00、アーカイブの earliest_time は 2000-08-01T00:00:00 である（announced-prefixes レコード）。この応答は本文中に自らの限界を記している。すなわち、可視性が極端に低い経路、具体的には 10 未満の RIS フルフィードピアしか見ていない経路は結果から除外される。したがって空の一覧は、二週間の窓と可視性の下限という二重の境界を持つものであり、かつて一度も宣告がなかったことの証明にはならない。それが確立するのはより狭く、それでも有用な事実である。328 の IPv4 と 318 の IPv6 の観測点からなる収集網において、記録された窓の内側で、AS211386 を起点とするプレフィックスでこの下限を越えたものはなかった。

近隣も同じ形を裏づける。RIPEstat の asn-neighbours 呼び出しは neighbour_counts として left 0、right 0、unique 0、uncertain 0 を返し、neighbours 配列は空である（asn-neighbours レコード）。観測された近隣を持たない話者は、どちらの方向にも観測された経路を持たない。収集層が見ることのできるトポロジーには参加していない。

読み取りが止まる場所

2026-10-18 に三つの登録層の読み取りが失敗しており、その失敗は脚注ではなく結論の一部である。RIPE データベースの aut-num AS211386 への REST 要求はオブジェクト本文を返さなかった（aut-num 要求）。したがってオブジェクトの status、スポンサー組織、maintainer、作成および最終更新の属性は未確立のままである。同じオブジェクトの RDAP 表現は取得時に到達できなかった（RDAP 要求）。AS211386 を起点とする経路オブジェクトの REST 照会はアクセス失敗を返した（経路オブジェクト照会）。この起点の下に route あるいは route6 オブジェクトが存在するかは未検証であり、本稿はその存在も不在も主張しない。

さらに二つの不在がこの節に属する。AS211386 を覆う RPKI リソース証明書も ROA も取得されておらず、IRR の as-set、aut-num ポリシー文、ピアリングポリシーの項目も取得されていない。したがってこの番号に付随する経路セキュリティやポリシーの意図については何も述べない。Azure の内部で運用されるルートサーバーを記述した、London Internet Exchange または Microsoft の公開文書も取得されていない。保有者文字列が示唆する機能は未確認のままである。これらは本稿の読み取りの空白であり、日付は 2026-10-18 であって、背後のレコードについての所見ではない。

この空白が変えるもの

実務上の帰結は、登録レコードがどの問いに答えるかという点にある。aut-num の登録は、誰がその番号のために行為する権限を持つかを述べる。トラフィックが存在するとは述べない。IRR に基づくプレフィックスフィルタや RPKI 検証を運用する事業者にとって、これらは別個の入力であり、故障の仕方も別である。登録に現れながら何も宣告しない番号は珍しいことではなく、矛盾でもない。この区別が高くつくのは、調達やデューデリジェンスの手続きが登録の存在を運用面の証拠——交換点への参加、クラウドへの接続、ルートサーバー——として扱い、そこで止まるときだけである。

AS211386 について、二つのレコードは具体的かつ測定可能な仕方ですれ違う。識別層は名前と PeeringDB の一件を返し、観測層は分母を伴うゼロを返す。取得したものの中に、この番号が 2026-10-17T16:00:00 にトラフィックを運んでいたことを示すものはなく、かつて運んだことがないことを示すものもない。

何がこの読み取りを変えるか

この読み取りは通常の手段で反証できる。それが測定の有用な性質である。announced-prefixes の一覧が空でないこと、ris_peers_seeing がゼロでないこと、first_seen や last_seen が埋まること、近隣数がゼロでないこと。いずれも単独でこれを崩し、しかもそのどれもが、ここで観測された内容と矛盾せずに次の窓に現れうる。これを変えないのは、さらなるカタログ項目である。二件目のディレクトリ掲載、第三者データベースの記述、展開のように読める名前。それらが増やすのは名前であって経路ではない。

現時点でこの番号は、帰属を伴う登録と、PeeringDB の一件と、2026-10-17T16:00:00 に観測された経路がゼロという状態にある。登録レコードが答えられない問い、すなわち買い手が通常決着させたい問い——holder フィールドに記されたものがこれまで運用されたことがあるのか——に対する正直な答えの形は、読み取りが 2026-10-18 の三つの失敗した照会と、10 のフルフィードピアという可視性の下限で止まった、というものである。