概要
- インドの Department of Telecommunications は、Cloudnet Internet Service Private Limited がタミル・ナードゥをサービスエリアとするカテゴリーB のインターネットサービス認可を保有しており、2023 年 4 月 10 日付けで有効化されたことを公表している。企業情報データベースでは、同じ住所および連絡先が 2021 年にチェンナイで設立された企業と一致している。このことは、同社がクラウドコンピューティング製品ポートフォリオではなく、規制下にある ISP としての実体を持つことを裏付けている。
- AS150069 は 2026 年 7 月 10 日時点でアクティブであり、
103.21.6.0/23、その構成要素である 2 つの/24経路、および2001:df1:66c0::/48を発信していた。IPv4 集約経路は 2022 年 10 月以降、IPv6 経路は 2022 年 11 月以降可視化されている。現在の経路認証は RPKI で有効であり、レジストリレコードも最近更新されている。 - 公開経路コレクタによれば、AS150069 の直接の隣接 AS は Niss Internet Services Private Limited の AS132774 のみである。このことは、外部ルーティング経路が可視化された 1 つであることを示すが、Cloudnet がプライベート相互接続やバックアップ回線を持たないこと、物理経路の冗長性、自動フェイルオーバー、または予備容量を証明するものではない。
- IPinfo は AS150069 をコンシューマーISP と分類しており、昼夜の顕著なトラフィックリズムがあると指摘し、当該アドレス空間内のホストドメインは 1 件のみと報告している。これらは参考情報ではあるが、監査済みの顧客数や製品数ではない。公開された Cloudnet のサービスカタログ、データセンター所在地、ラックインベントリ、仮想マシン提供、ベアメタルサービス、ストレージサービス、稼働率保証、バックアップポリシー、マイグレーション手順は、いずれも確認されていない。
- したがって、想定されていたクラウドサービス事業者から、現在ルーティングが確認されている小規模なタミル・ナードゥの ISP へと評価を引き下げることが妥当である。ただし、正確な小売提供範囲や物理ネットワークは明らかにされていない。その耐障害性は、ローカルのアクセス設備、通電された集約機器、Niss への接続ポイント、Niss の上流接続性、およびサポート要員に依存している。Cloudnet をクラウドプロバイダーとして議論するには、実際のホスティングワークロードの証拠が必要となる。
クラウド仮説は最初の製品の問いで破綻する
「Cloudnet」という言葉は、許容されるなら過大な意味を持ちうる。これはネットワーク用語の流行りの二語を組み合わせたものであり、同社はインターネット番号リソースを管理している。しかし、どちらの事実も、顧客が仮想マシン、マネージドデータベース、ストレージバケット、ベアメタルサーバー、あるいは通常のウェブホスティングアカウントさえ購入できることを示すものではない。この区別は重要である。クラウドサービスには、アクセスプロバイダーがこれまで引き受けたことのないような障害対応や復旧義務が伴うからだ。
同社に関する最も有力な公開文書はクラウドカタログではない。それは2025 年 1 月 31 日時点のインターネットサービス認可リスト（Department of Telecommunications）である。当該エントリには、Cloudnet Internet Service Private Limited、ライセンス番号DS-11/401/2022-DS-III、カテゴリーB、サービスエリア：タミル・ナードゥ、発効日 2023 年 4 月 10 日と明記されている。認可を受けた連絡先、登記上の事務所住所、電話番号は、同社の法人登記情報やインターネットレジストリ記録と一致している。
Department of Telecommunications のインターネットサービスページによれば、カテゴリーB とは、1 つの認可サービスエリア（通信サークルまたは都市圏として定義）でインターネットサービスを提供する権限を意味する。統一ライセンス要綱には、認可の範囲内でインターネットアクセス、IPTV、および特定のインターネット電話が含まれると記載されている。このライセンスは、Cloudnet がタミル・ナードゥで ISP として事業を行いうる重要な証拠である。これは同社が州全域のカバレッジを構築したことを証明するものではなく、アクセス認可がホスティングコンピューティングの証拠に転化するわけでもない。
ネットワーク記録も同じ方向性を示している。IPinfo の AS150069 概要では、このネットワークをコンシューマーISP に分類し、可聴時間帯に利用者が接続を使用するタイプの顕著な日次アクティビティリズムを検出している。そこでは、512 個の IPv4 アドレスに対してホストドメインは 1 件と報告されている。ホストドメイン数の計測には限界がある。ドメインはコンテンツ配信ネットワークの背後に置かれることもあれば、1 つのアドレスで多数の名前をホストすることもあり、プライベートサービスは発見不可能な場合もあり、アクセス顧客がサーバーを運用することもある。しかし、そうした留保を考慮しても、観測された 1 つのドメインがホスティング事業の存在を示す積極的証拠にはならない。
Cloudnet の公開情報には、コンピューティング、ストレージ、バックアップ、コロケーション、マネージドインフラストラクチャの料金や仕様は一切示されていない。データセンターの住所も明示されていない。サーバーベンダー、ラック数、電源設計、認証、アベイラビリティゾーン、カスタマーポータル、サービスレベルアグリーメント、データ処理補遺、インシデント履歴、復旧目標、エクスポート形式のいずれも記載がない。企業は公開ウェブ上で全てのサービスを文書化せずに個別販売することもありうるが、立証責任は逆転しない。製品と運用基盤が存在しない限り、クラウドの主張は裏付けられるのではなく、棄却されるべきである。
したがって、異なる、より根拠のあるストーリーが残る。Cloudnet は稼働中の自律システム、タミル・ナードゥの ISP 認可、小規模な IPv4 割り当て、IPv6 割り当て、および可視化された単一の上流依存関係を有している。これらはアクセスネットワークの骨組みである。その背後にある物理的設備はほぼ露出しておらず、耐障害性の評価を難しくしているが、ネットワークが架空のものであることにはならない。
チェンナイの企業とタミル・ナードゥの認可
企業情報アグリゲーターは、Cloudnet Internet Service Private Limited を企業識別番号U64120TN2021PTC142654で特定している。Tofler の企業ページでは、2021 年 4 月 8 日に設立、授権資本金 100 万ルピー、払込資本金 10 万ルピー、取締役として Logasundari および Gopikrishnan の氏名が記載されている。ZaubaCorp のレコードも同一の CIN、チェンナイ登記、Kottivakkam の住所を提供するが、その表示上の一部日付フィールドには不整合があり、最新の登記書類の代用とすべきではない。
この住所は identity resolution において特に有用である。認可リストでは、同社はチェンナイ、Kottivakkam、Vivekanandar Third Street、11/236A 区画の 3 階に所在するとされている。APNIC の AS150069 登録情報では、略称の法人名 CLOUDNET INTERNET SERVICE PVT LTD が使用され、その管理担当窓口には同一の住所と電話番号が記載されている。IPv4 割り当てレコードおよびIPv6 割り当てレコードには、ネットワーク名CNISPLが同一であり、連絡先も同じである。これらは、単に類似した名称を持つ別事業者ではなく、一つの企業に収束する記録である。
この収束により、類似名称の企業を混同するリスクも排除される。別の Cloudnet Broadband Services Private Limited が過去のハリヤナ州の許認可資料に登場し、Cloudnet Communications Private Limited が加入者テーブルに現れる。また、「Cloud Net」や「Cloudnet」を商号として使用する他地域の事業者も存在する。それらを、当該企業のサービスカタログ、顧客数、沿革の穴埋めに使用してはならない。ここでのアイデンティティの基礎は、タミル・ナードゥのライセンス、CIN、Kottivakkam の住所、そして AS150069 である。
2025 年の DoT リストは、当該報告日時点での認可の証拠である。2026 年 7 月時点での日次運営証明書ではない。一方で、実際に経路が存在し、最近まで維持されていたインターネットレジストリオブジェクトは、より新しい技術的証拠を提供する。したがって、同社を単に「登録済み」や「過去にライセンスを有していた」と表現するのは適切でない。その自律システムは、観測時点でグローバルに可視の経路広報を行っていた。
ただし、住所はネットワーク機器の設置場所を示すものではない。登記上の事務所は、管理事務所、接続拠点（POP）、その両方、またはいずれでもない場合がある。IPv4 レコードには座標13.427804, 80.14154212が含まれるが、レジストリの地理位置情報は事業者が提供するメタデータであり、ルーター室の調査結果ではない。IPinfo は、観測されたアドレスやルーターがチェンナイや Nagari 周辺に位置すると推定し、最近のプローブにはチェンナイエリアの観測ポイントから応答があった。このような地理位置情報は確率的なものであり、光回線終端装置の特定、ファイバールートの所有権証明、あるいは特定の道路での顧客サービス提供を確定することはできない。
したがって、地理的な記述は限定的なものとなる。Cloudnet はタミル・ナードゥサービスエリアの認可を受け、チェンナイで登記され、独立した測定によってインドおよびチェンナイ地域に関連付けられるアドレス空間を運用している。公開証拠からは、タミル・ナードゥ内での小売提供範囲、チェンナイ全域をカバーしていること、あるいは登記住所以外の接続拠点の存在は明らかになっていない。
AS150069 は現在の運用証拠を提供する
自律システムはルーティングポリシーの単位であり、完全な事業を示すものではない。それでも、AS150069 は Cloudnet が現在何かを運用していることの最も明確な証拠である。RIPEstat の AS 概要によると、2026 年 7 月 10 日時点で ASN がアナウンスされていた。同ツールの発表プレフィックス応答には、IPv4 集約103.21.6.0/23、より詳細な 2 経路103.21.6.0/24と103.21.7.0/24、および IPv6 プレフィックス2001:df1:66c0::/48がリストされていた。
IPv4 集約には 512 アドレスが含まれる。現在のルーティングステータスでは、AS150069 が/23の唯一可視の発信元であり、327 の報告 IPv4 ピアのうち 326 で観測された。集約の下位にある両/24も表示された。103.21.6.0/24と103.21.7.0/24の個別ステータスレスポンスでも、同一の発信元と可視性が記録された。これは、単一の観測者のみが観測したものではなかった。
経時変化も重要である。/23のルーティング履歴によれば、Cloudnet の集約アナウンスは 2022 年 10 月に開始され、調査日まで継続している。2 つの/24は 2022 年 12 月に初めて出現した。それらの可視性は 2025 年 3 月から急激に低下した期間があったが、カバーする/23は広く可視のままであり、その後 2026 年 5 月に再び広範な可視性に戻った。これは経路の粒度と伝搬の変化であり、顧客サービスが停止した証拠ではない。より詳細な経路が可視でないときでも、当該 2 ブロック宛てのトラフィックはカバーする集約経路を辿ることができた。
IPv6 も単なるレジストリ上の予約ではない。2001:df1:66c0::/48のルーティングステータスでは、7 月 10 日に AS150069 が全 321 の報告 IPv6 ピアに対してプレフィックスを発信していることが示された。この経路は 2022 年 11 月に初観測された。APNIC のルートオブジェクトは観測の 2 日前である 2026 年 7 月 8 日に更新され、関連するコンタクトレコードも 6 月に更新されていた。これらの日付は継続的なリソース管理を示す。ただし、どれだけの顧客トラフィックが IPv6 を利用しているか、あるいは何人のユーザーがそれを受信しているかは分からない。
設置済み容量と利用可能容量の区別は本質的である。/23はアドレスプールであり、帯域購入量ではない。512 の IPv4 アドレスは、512 の顧客、サーバー、ポート、メガビットを意味しない。プロバイダーは、ルーターインターフェイス、キャリアグレード NAT プール、ビジネス回線、インフラストラクチャ、または予備在庫にアドレスを使用できる。1 世帯が複数のパブリックアドレスを使用することもあれば、多数の世帯が 1 つのアドレスを共有することもある。IPv6/48内のほぼ想像を絶する数のアドレスは、容量指標としてはさらに有用性が低い。
また、同時に発生する 3 つの IPv4 アナウンスがネットワークを 3 倍にするわけではない。/23とその構成要素である 2 つの/24は、同一のアドレス空間をカバーしている。より詳細なアナウンスは、ルーティングポリシー、トラフィックエンジニアリング、または運用上の移行をサポートしうるが、可視のルーティングデータからその目的を特定することはできない。集約と構成要素を一意の 1024 IPv4 アドレスとカウントすることは、同じ 512 アドレスを二重に数えることになる。
現在の経路は、実在する稼働中のネットワークを裏付けている。ただし、加入者アクセス技術、ポート数、集約トランジット、ピーク使用率、競合、バックホール、キャッシュ容量、サービス速度は示されない。これらの量は、販売された接続が夜間のピーク時に使用可能かどうかを決定するが、ASN から算出することはできない。
1 つの直接隣接 AS が可視の外部境界である
RIPEstat の AS 隣接ビューでは、2026 年 7 月 10 日に 1 つの直接隣接 AS のみが検出された：AS132774。APNIC はこの ASN をNiss Internet Services Private Limitedと特定しており、ティルネルヴェリで登録されたタミル・ナードゥのネットワークである。CIDR Report の AS150069 ビューも、同一の隣接関係を示し、下流 ASN は存在しない。
経路コレクタはトポロジーを観測するが、契約関係は観測しない。観測経路において Cloudnet の直前に位置する AS は、Niss がトランジット、マネージドルーティング、または他の形態の上流到達性を提供していることと整合する。しかし、価格、コミット帯域、バースト条件、物理的接続、ファイバーサプライヤー、解約予告期間、復旧義務、あるいは Cloudnet が直接そのサービスを購入しているかどうかは明らかにならない。ここで「上流」という商業ラベルは妥当な推論だが、公開情報から得られる結果は、あくまで「1 つの可視の外部 BGP 隣接」である。
この区別は冗長性を議論する際に重要になる。1 つの可視隣接は、公に実証された上流の多様性を主張することに対する反証となる。しかし、Cloudnet がケーブルを 1 本しか持たないことの証明にはならない。Cloudnet が、同じ ASN パスを提示しつつ、物理的に分離された 2 つの回線で Niss の異なるルーターに接続している可能性はある。観測時にアイドル状態のバックアップセッションが存在するかもしれない。コレクタから見えない接続を介してデフォルトルートを受信している可能性もある。逆に、1 プロバイダーへの複数の BGP セッションが、単一のダクト、建物、ルーター、電源ドメインに収束していることもありうる。セッション数と物理的多様性は別物である。
Niss 自身はより広範なトポロジーを持つ。PeeringDB エントリには、NIXI Chennai でのピアリングと、チェンナイおよびティルネルヴェリの施設が記載されている。また、bgp.toolsは AS132774 の複数の上流をリストしている。これらは Niss に関する自己申告および観測事実であり、Cloudnet が継承する特性ではない。Cloudnet のパケットは AS132774 に到達した後、Niss の後続オプションの恩恵を受ける可能性はあるが、Niss が複数の上流を持つことは、Cloudnet が Niss に到達する独立した 2 経路を持つことを証明しない。
ライブのRIPEstat ルッキンググラスによる/23の表示では、収集されたパスにおいて、AS132774 が繰り返し AS150069 の直前に位置していた。その後、多くのパスは Niss の先で Bharti Airtel の AS9498 を経由していた。これは、その瞬間の可視チェーンを示す：Cloudnet、Niss、そしてより大規模なトランジットネットワークである。Cloudnet が Airtel と直接契約していることや、物理的接続がどこで行われるかを示すものではない。
この境界は明確な障害メカニズムを生み出す。Cloudnet の Niss への唯一のアクティブな接続に障害が発生した場合、またはルーティングセッションが機能する代替手段なしに撤回された場合、顧客ファイバーやローカルスイッチに通電していても、グローバルに経路広報されるすべての Cloudnet アドレスが到達不能になる可能性がある。Niss 接続が維持されてもコミット容量が枯渇した場合、ユーザーはクリーンな停止ではなく輻輳を経験するかもしれない。経路フィルターや認証に誤りがある場合、一方のアドレスファミリや一方のプレフィックス長のみが障害を起こし、他は継続する可能性がある。
復旧は、公開されていない事実に依存する：Cloudnet に第 2 の回線があるかどうか、それが異なるエッジデバイスで終端しているかどうか、その回線が分離した経路を辿るかどうか、フェイルオーバーが自動かどうか、バックアップが通常ピークに対して十分な容量を持つかどうか、IPv4 と IPv6 の両方が運ばれるかどうか、そして初期対応をどの企業が担当するか。2 本の線が描かれたダイアグラムは、物理的および契約上の共通点を特定しない限り、これらのいずれも証明しない。
物理ネットワークは BGP が説明し終えた場所から始まる
BGP は AS150069 がアドレスブロックを到達可能にすることを示せる。しかし、顧客宅内から最初のアクティブデバイスまでのケーブルを示すことはできない。その間には、光回線終端装置（ONU）、ドロップファイバー、スプリッター、架空または地下の配線ファイバー、OLT、イーサネット集約、リースバックホール、パッチパネル、電源装置、冷却装置が存在しうる。公開証拠は、Cloudnet がこれらのうちどれを使用または所有しているかを特定していない。
同社のカテゴリーB 認可は、タミル・ナードゥの認可サービスエリア全域でのサービス提供を許可するが、特定のアクセス設計を保証するものではない。Cloudnet は FTTH、ビジネス向けイーサネット、無線リンク、地元ケーブル事業者経由のサービス、あるいはそれらの混合で事業を行っている可能性がある。公開のカバレッジマップ、設計図、光ネットワーク仕様、タワー記録、地元ケーブル提携は見つかっていない。IPinfo の最近のスキャンで応答のあった 2 つの IP アドレスは、エンドポイントが計測に応答したことを示すが、ラストワンマイルがどのように構築されたかは示さない。
この不明確な所有権境界は、障害時の修理担当者を変える。切断された顧客ドロップは Cloudnet の責任かもしれないし、地元事業者の責任かもしれない。フィーダーファイバーの障害は、電柱作業班、土木工事業者、またはリースファイバー所有者を必要とするかもしれない。集約障害は、交換用光学部品、スイッチ、OLT カード、または電源装置を必要とするかもしれない。バックホール障害は、別の通信事業者に委ねられるかもしれない。顧客は 1 つの利用不能なサービスを認識する一方、修理は複数の組織にまたがる。
電力はそれ自体の連鎖を生み出す。顧客設備は電力を必要とする。街頭キャビネット、無線サイト、OLT、集約スイッチ、エッジルーターも電力を必要とする。登記上の事務所に電力があることは、遠隔の分配ノードについては何も語らない。UPS は短時間の停電を橋渡しできるが、ランタイムは有限であり、バッテリーは経年劣化する。発電機は、設置され、燃料が補給され、保守され、影響を受けるサイトに接続されて初めて役立つ。Cloudnet によるバックアップランタイム、発電機のカバレッジ、バッテリー保守、二重給電、サイトの電源アーキテクチャに関する公開声明はない。
小規模ネットワークにとってハードウェアインベントリは重要である。故障した部品は安価でも、運用上特殊である可能性があるからだ。互換性があり手元にあれば、予備の光モジュールがリンクを迅速に復旧できる。故障したラインカード、電源装置、アクセスシャーシは、取り寄せが必要であれば時間がかかる。コンフィグレーションバックアップは最新で、交換機器で使用可能である必要がある。公開記録には、平均修復時間、在庫方針、ベンダーリスト、保守ウィンドウは一切含まれていない。
したがって、サポート要員はキャパシティの一部である。ネットワークに未使用帯域があっても、技術者が切断箇所に到着できず、エンジニアが経路を変更できず、認可された担当者が上流事業者にエスカレーションできなければ、サービスは利用不可能なままである。Cloudnet のレジストリおよびライセンス記録には、単一の管理窓口連絡先が公表されているが、それらの記録は、有人のネットワークオペレーションセンター、24 時間のフィールドカバレッジ、チケットシステム、またはエスカレーションローテーションを説明するものではない。連絡先番号をサービスレベル保証に転化させるのは誤りである。
物理的な所在地の問題は未解決のままだ。Kottivakkam は登記上の事務所所在地である。レジストリ座標はタミル・ナードゥ北部の別の地点を示唆し、第三者測定はアドレスをチェンナイ、 Nagari、その他タミル・ナードゥのラベルと関連付ける。IP ジオロケーションデータベースは、アドレス登録情報、推定ユーザー所在地、または計測バイアスを反映しうる。いずれも、Cloudnet が特定のデータセンターにラックを有することや、特定のサイトに機器を所有していることを証明しない。
請求、サポート、契約は無傷のネットワークを中断させうる
すべてのサービス障害がケーブル切断から始まるわけではない。アクセスプロバイダーは、顧客を識別し、セッションを認証し、請求書を発行し、支払いを受け付け、プラン変更を適用し、滞納アカウントとネットワーク障害を区別する必要がある。設計によっては、認証は加入者データベース、RADIUS サーバー、ブロードバンドネットワークゲートウェイ、光ネットワーク管理システム、または再販業者のプラットフォームに依存しうる。公開記録は、Cloudnet がこれらのうちどれを使用しているかを開示していない。ただし、顧客管理が BGP とは別の運用層であることは確立している。
この区別は外部から容易に観察できる。AS150069 はグローバルに可視のままでありながら、1 つのアカウントが接続できない状況が発生しうる。誤った台帳に記帳された支払い、失効した認証情報、障害が発生した認証サーバー、または誤った停止フラグは、顧客ルーターでの停止として現れうる。フィールドスタッフは健全な光レベルと無傷の上流経路を確認するかもしれないが、アカウント制御が修正されるまでサービスは利用不可能なままである。経路コレクタはそのいずれも記録しない。
広範なインシデントの間は、請求の継続性も重要である。顧客は、障害を報告し、支払い、デバイス、またはエリア停止のいずれが原因かを判断するための到達可能なチャネルを必要とする。スタッフは最新のアカウントおよびネットワーク記録を必要とする。同じ電源、サーバー、または接続障害がアクセスサービスとそのサポートシステムの両方を停止させた場合、診断は遅延する。Cloudnet の公開された規制上およびレジストリ上の連絡先は、別個のカスタマーケアプラットフォーム、オフサイト記録、緊急電話ルーティング、またはテスト済みの手動プロセスを有するかどうかを明らかにしない。
可視の隣接事業者との卸売契約も、もう一つの制御点となりうる。ファイバーとルーターが技術的に健全であっても、プロバイダー間の紛争、期限切れ注文、未払い請求、容量上限、または失効した経路認証がサービスを中断させる可能性がある。Cloudnet と Niss の間でそのような紛争が発生した証拠はない。重要なのは構造的な点である：到達可能性が他の事業者に依存する場合、商業的継続性は光学部品や電力と並んで耐障害性評価に含まれるべきである。
実証された代替手段がない場合、プロバイダー契約の破綻はより深刻な結果をもたらす。上流を変更するには、回線を注文する以上のことが必要である。新しいプロバイダーは、ハンドオフに到達し、Cloudnet の経路を受け入れ、フィルターを適用し、IPv4 と IPv6 を運び、有効な経路認証をサポートし、十分な容量を提供しなければならない。顧客トラフィックは、新しいデフォルト、DNS 経路、アドレスポリシーを必要とするかもしれない。既存サービス終了後にマイグレーションが急がれる場合、Cloudnet が自身の ASN とプレフィックスを管理し続けていても、ネットワークはオフラインになりうる。
個々のアクセス顧客の移行は、別の移行問題を提起する。Cloudnet がエリアへのサービス提供を停止したり、加入者を他の事業者に引き渡したりした場合、継続性は、ドロップファイバーと顧客設備の所有権、アカウント記録の移植性、予告期間、返金、および代替プロバイダーのサービス提供能力に依存する。公開 BGP は、アドレスと発信元が同じままであれば変化を示さないかもしれないし、顧客がリナンバーされれば大きな変化を示すかもしれない。どちらの結果も、小売義務を誰が引き受けたかを単独で説明するものではない。
真のホスティングサービスの場合、マイグレーションはさらに困難になる。顧客はデータエクスポート、マシンイメージ、DNS 制御、および再構築のための時間を必要とするだろう。これが、裏付けのないクラウド仮説を軽々しく扱えない理由の一つである。それは、証拠に欠けるデータ管理義務と退出義務を含意するからである。実際に可視化されているアクセスネットワークについては、当面の疑問はより単純だが未回答のままである：加入者関係を誰が所有し、誰が認証を復旧でき、誰が Niss にエスカレーションし、その関係が終了した場合に顧客がどのように移行されるか。
設置容量は小売容量ではない
ネットワークと比較できる公開された Cloudnet の料金表や速度表は存在しない。たとえ存在したとしても、広告されたアクセス速度は容量問題の外縁に過ぎないだろう。100 Mbps の加入者プランは、すべての時間帯において、すべての集約スイッチ、バックホール、トランジットリンクを通じて 100 Mbps を予約するわけではない。プロバイダーは、顧客が同時に最大レートを要求しないという仮定の下で容量をプールする。
関連する運用上の数量は存在しない。Cloudnet は、アクティブな加入者数、速度の組み合わせ、コミットされたトランジット、ピアリング容量、バックホール設計、ポート使用率、ピーク時間帯のスループット、オーバーサブスクリプション比率、または輻輳記録を公開していない。512 アドレスの IPv4 プールはこれらのギャップを埋めない。キャリアグレード NAT は、512 をはるかに超える顧客デバイスにプールを共有させることができる。スタティックなビジネスサービスは、1 アカウントあたり複数のアドレスを消費しうる。そして IPv6 は、それ自体ではトランジット容量を 1 ビットも追加することなく、アドレッシングの計算を変える。
Cloudflare Radar は、AS150069 の推定人口を数百人規模で表示しており、表示される推定値はスナップショットやサブページ間で変動する。このような推定は、プロバイダーの課金システムではなく、トラフィックおよび測定シグナルを使用している。それらは観測可能なユーザー人口が小さく、コンシューマー ISP という解釈を補強することを示すが、加入者台帳として引用すべきではない。1 つの加入契約が、多数の人々を含む世帯や事業所にサービスを提供する可能性があり、一部のユーザーは基礎となる測定に現れないかもしれない。
同様の注意は測定パフォーマンスにも適用される。Cloudflare の AS150069 インターネット品質ページは、利用可能な速度テストとネットワーク観測を集約する。応答アドレスから取得された測定は、特定の時間と場所において経路が機能したことを示しうる。しかし、全加入者に対するプラン速度を保証したり、アクセスフットプリント全体での停止頻度を定量化したり、テストされた回線が代表的であるかどうかを明らかにすることはできない。小規模なサンプルは構成の変化に対して特に脆弱である。
TRAI の2024 年ブロードバンド品質規則は、サービス提供、ネットワークパフォーマンス、障害修理、苦情処理を含む、アクセスおよびブロードバンドプロバイダーに対するベンチマークと報告義務を定めている。2024 年 12 月の四半期パフォーマンスレポートは、公開されたブロードバンドパフォーマンスサマリーが 10,000 を超える加入者を有するプロバイダーを対象としていると説明している。Cloudnet は、これらの大規模プロバイダーの一つとして公開サマリーに特定されていない。この省略は、その規模を確定したり、適用される義務を免除するものではない。単に、全国サマリーを Cloudnet 固有のパフォーマンス証拠として使用できないことを意味する。
利用可能容量とは、競合、障害、ポリシーの後に残るものである。バックアップ経路が通常トラフィックの一部しか運べない場合、名目上の冗長性でも深刻な輻輳を生み出す可能性がある。IPv4 の詳細経路が撤回されても集約経路が残る場合、到達可能性はトラフィックエンジニアリングが変更されつつ継続しうる。IPv6 が故障し IPv4 が稼働し続ける場合、ユーザーは完全な切断ではなく、遅延やアプリケーション固有の障害を経験する可能性がある。信頼できる容量の記述には、割り当てプレフィックスのサイズではなく、両アドレスファミリのピーク時間帯の測定値が必要となるだろう。
クラウドサービスには異なる証拠セットが必要である
アクセスプロバイダーとクラウドプロバイダーは、ルーター、アドレス、スタッフを共有できるが、販売する約束は異なる。アクセスサービスは、顧客のトラフィックを他のシステムに運ぶ。ホスティングされたコンピュートは、顧客のアプリケーション、データ、またはサーバーを、プロバイダー自身またはリースされたインフラストラクチャ上で稼働し続ける。後者の約束は、AS150069 の記録では答えられない疑問を導入する。
第一は資産である。信頼できる仮想サーバー提供には、コンピュートプラットフォームの特定、または少なくとも CPU、メモリ、ストレージ、ネットワーク、テナンシーの特性の開示が必要である。ベアメタルでは、サーバークラスとプロビジョニング条件を特定すべきだ。コロケーションでは、施設、ラック電源、リモートハンズのアレンジを特定すべきだ。マネージドホスティングでは、プロバイダーがどの運用タスクを実行するかを定義すべきだ。ここで見つかった企業固有の資料は、これらの製品をいずれも説明していない。
第二は所在地である。「インドでホスト」または「チェンナイでホスト」という主張には、データおよびコンピュートが存在する施設の証拠が必要となる。インドで登録された ASN はサーバーの所在地を示さない。トラフィックは、インドのネットワークを経由して、別の施設や管轄区域の機器にルーティングされる可能性があり、逆に Cloudnet が、自身のアドレス空間には現れないサードパーティのインドのインフラストラクチャを使用している可能性もある。レジストリ上の国とデータ所在地は別個の主張である。
第三は管理である。Cloudnet が他プロバイダーの仮想マシンを再販する場合、Cloudnet は請求とサポートを管理し、基盤となるプロバイダーがラック、ハイパーバイザー、電源、部品を管理するかもしれない。Cloudnet がコロケーションをリースする場合、サーバーを所有するが建物設備は所有しないかもしれない。自前の部屋を運用する場合でも、大家や回線事業者に依存する可能性がある。顧客は、誰が電源を復旧し、ディスクを交換し、バックアップをリカバリし、緊急アクセスを承認できるかを知る必要がある。公開文書はこの境界線を描いていない。
第四は冗長性である。クラウドサービスは、それぞれが異なる障害から保護するように、ドライブ、ホスト、ラック、部屋、建物、またはリージョン間でデータを複製できる。1 台のホスト上の 2 つのコピーは、ホスト障害を乗り切れない。1 つのラック内の 2 つのホストは、電力分配ユニットを共有するかもしれない。1 つの建物内の 2 つのラックは、商用電力、冷却、上流ファイバーを共有するかもしれない。2 つの建物であっても、1 つの都市ダクトまたはコントロールプレーンに依存しうる。開示されたアーキテクチャとテスト済みの復旧経路なしには、「クラウド」という言葉は障害ドメインについて何も語らない。
第五は退出である。プロバイダー障害から復旧する顧客は、エクスポート可能なイメージ、データベースダンプ、オブジェクトコピー、DNS 制御、そして移行のための十分な時間と帯域を必要とする。契約終了、請求紛争、企業破綻は、認証情報やデータが 1 つのアカウントにロックされている場合、ハードウェア障害と同様に破壊的になりうる。データ返却、削除、移行支援、バックアップ保持、アカウント停止に関する Cloudnet の条件は見つかっていない。
これらは Cloudnet にケイパビリティが欠如しているとの主張ではない。これらは、それらのケイパビリティを割り当てる前に公開証拠が答える必要がある最低限の疑問である。個別の見積もり、契約、または技術スケジュールは、特定の顧客にとって結論を変えうる。そのような証拠が現れるまで、AS150069 はクラウド製品ではなく、ネットワーク運用の証拠として読まれるべきである。
RPKI は有用なルーティング衛生であり、それ自体で耐障害性ではない
Cloudnet は具体的なルーティングセキュリティ措置を講じている。RIPEstat の IPv4 集約の検証では、AS150069 をカバーし、/24までのアナウンスを許可する有効な Route Origin Authorisation が見つかった。したがって、構成経路も同認証の下で有効である。IPv6/48の検証も有効であった。
RPKI は、署名された認証と矛盾する発信元アナウンスを他ネットワークが拒否するのを助ける。これにより、ルーティングミスやハイジャックの一クラスが低減される。しかし、パス内のすべての AS を検証したり、トラフィックを暗号化したり、ファイバー切断を止めたり、第 2 の上流を提供したり、輻輳を阻止したり、ルーターの電源を保ったりするものではない。有効な経路は、発信元ネットワークに顧客への有効なパスがない場合、利用不能なサービスにつながりうる。
それにもかかわらず、現在の組み合わせは意味がある：登録されたリソース、アクティブな IPv4 および IPv6 発信元、ルートオブジェクト、有効な発信元認証。これは休眠状態の企業名以上の運用成熟度を示す。しかし、可視トポロジーが依然として狭いため、耐障害性の問題を鮮明にする。1 つの観測された隣接を通じた正しく認証された到達可能性は、依然として 1 つの観測された隣接である。
より詳細な IPv4 アナウンスは、別の運用上のひねりを加える。/24が低可視性だった期間、/23集約は広く可視のままだった。集約と詳細の両方を広報することで、詳細が消えた場合にカバー経路を保持できる。これはポリシーや緩和のためにも使用されうる。公開コレクタは意図された設計を明らかにできず、集約経路は第 2 の物理パスを作り出すわけではない。ルーティング冗長性と回線冗長性は混同すべきでない。
IPv6 についても境界を定めた結論が妥当である。/48は何年もグローバルに広報されており、そのルートオブジェクトは最近更新された。これはネットワークエッジでのライブ IPv6 ルーティングをサポートする。すべての小売顧客が IPv6 プレフィックスを受け取ること、顧客機器がそれをサポートすること、サポートスタッフが両プロトコルを同等にトラブルシューティングすることは証明されない。展開深度を確立するには、プロバイダー固有の開示または顧客側の測定が必要となるだろう。
影響を受けるのはおそらくアクセス顧客であり、ホストされたワークロードではない
IPinfo の日次リズム、ISP ライセンス、そしてホスティングカタログの不在は、アクセスネットワークを示している。Cloudflare の観測ユーザー推定値と応答するチェンナイエリアのアドレスは、その方向性を支持する。それらは、名前、正確な所在地、または顧客タイプを明らかにしない。したがって、影響を受ける可能性のある人口は条件的である：AS150069 または Cloudnet のアクセスサービスを通じて接続を受ける世帯、小規模事業所、または機関ユーザーである。
世帯にとって、停止はメッセージング、ストリーミング、リモートワーク、教育、支払い、接続デバイスを中断させる。小規模事業所にとって、同じ障害がクラウドアプリケーション、カード認証、サプライヤーとの連絡、顧客コミュニケーションを停止させうる。Cloudnet の固定アドレスを使用している企業は、カメラ、VPN エンドポイント、または自己ホストサービスへのインバウンド到達可能性も失う可能性がある。これらはメカニズムであり、特定の組織が Cloudnet のサービスを購入しているとの主張ではない。
依存関係はアカウント保有者を超えて広がる。地元事業者や再販業者は、Cloudnet の経路空間の背後に顧客を配置している可能性がある。可視の下流 ASN はなかったが、下流の小売契約には別個の ASN は必要ない。Cloudnet が別のアクセス事業者に容量を供給している場合、Cloudnet-Niss 境界での障害は、どちらの企業名も認識しないユーザーに影響を及ぼす可能性がある。公開ルーティングはそうした契約をカウントできない。
異なる障害は異なる症状を生む。切断されたドロップは 1 つの宅内に影響する。スプリッターやアクセスポートの障害はクラスターに影響する。集約やバックホールの障害はより広いエリアに影響する。Niss ハンドオフの喪失は、ルーティングされたフットプリント全体に影響しうる。DNS や認証の障害は、リンクがアップしたままでセッションを失敗させうる。請求やアカウントシステムのエラーは、ネットワーク障害なしに個人を切断しうる。公開記録は、Cloudnet がどのシステムを自社運用しているかを特定しない。
復旧は顧客エッジから測定されるべきである。BGP アナウンスを復旧しても、フィーダーファイバーが切断されたままでは不十分である。ファイバーを修理しても、認証がダウンしていれば不十分である。スイッチに通電しても、上流セッションが未だ利用可能でなければ不十分である。健全なインシデント報告は、障害が発生したレイヤー、責任事業者、開始および復旧時間、影響エリア、回避策、および容量が完全に復旧したかどうかを特定するだろう。
公開インシデントページやサービスステータス履歴の不在は、パフォーマンス判断を妨げる。沈黙は完全な信頼性を証明せず、散発的なユーザー報告は検証なしにネットワーク全体のレートを確立しない。現在の証拠は、障害連鎖をマッピングすることをサポートするが、Cloudnet の過去の稼働時間を評価するものではない。
より強固な運用状況を確立するもの
最初に欠けているのは、現在の顧客向けサービス記述である。アクセスサービスについては、カバレッジ、アクセス技術、プラン速度、競合または公正使用ルール、設置条件、障害連絡先、サービス目標を明示すべきだ。ホスティングサービスについては、コンピュート、ストレージ、ネットワーク、バックアップ、移行機能を指定すべきだ。ロゴと高速サービスの一般的な約束では不十分である。
第二は、適切な抽象度での物理的および契約上のネットワークマップである。Cloudnet は機密性の高い街路レベルの経路を公開する必要はない。アクティブな接続拠点数、カバーする都市またはサービスゾーン、バックホールが自前かリースか、上流回線が異なるサイトで終端し多様な経路を辿るかどうかを開示できる。鍵となるのは、運用上の秘密を暴露することなく、共通の障害ドメインを特定することである。
第三は容量の証拠である。有用な指標には、総トラフィックとピーク時間帯トラフィック、ポート使用率、コミットおよびバーストトランジット、フェイルオーバー容量、アクセスノードの飽和度、IPv4/IPv6 顧客採用率が含まれる。スナップショットには日付が付与されるべきである。設計容量、実装インターフェース、点灯容量、顧客利用可能スループットは別々に報告されるべきだ。
第四は復旧の証拠である。Cloudnet は、サイトクラスごとのバックアップ電源ランタイム、予備ハードウェア方針、エスカレーション所有権、メンテナンスウィンドウ、および最近の復旧パフォーマンスを表明できる。耐障害性の主張は、経路撤回、上流喪失、電源遮断、ハードウェア交換、コンフィグレーション復元といった障害がテストされて初めて信頼性を帯びる。結果は、サービスが実際に移行したかどうか、そしてどれだけの容量が保持されたかを示すべきである。
第五は、独立したトポロジー裏付けである。第二の可視隣接はルーティング多様性の主張を強化するが、それでも物理経路の証拠を必要とするだろう。同じ AS へのバックアップ回線は、異なる施設に接続し共通ダクトを回避する場合に価値がある。逆に、2 つのプロバイダー名が同一のラストワンマイル回線事業者を共有することもある。契約、ハンドオフ所在地、経路サーベイは、BGP だけでは解決できないことを解決する。
第六は、クラウドの主張に対する証明である。施設名または独立して検証可能なサイト、顧客条件、インフラストラクチャ仕様、データ所在地表明、バックアップアーキテクチャ、セキュリティ責任マトリックス、退出手順があれば、議論は推論から製品分析へと進むだろう。/23から応答する単一のホストドメインやサーバーは、商用クラウドプラットフォームを証明しない。
これらの項目が存在するまで、Cloudnet の最も強力な証拠は、規制された ISP としてのアイデンティティとライブルーティングのままである。不明点は装飾的なギャップではない。それらはまさにサービスが失敗しうる場所である：アクセス回線、集約電源、バックホール、Niss ハンドオフ、後続トランジット、サポートエスカレーション、顧客復旧。
稼働中の小規模ネットワーク、その名称が示すよりも限定された実態
CLOUDNET INTERNET SERVICE PVT LTD は空っぽの法人格ではない。タミル・ナードゥ州カテゴリーB インターネットサービス認可を有し、公開記録全体で一貫したチェンナイのアイデンティティ、アクティブな自律システム、512 アドレスの IPv4 割り当て、アナウンスされた IPv6/48、有効な Route Origin Authorisation を備えている。その経路は 2022 年から可視であり、レジストリデータは観測日近くまで維持されていた。
同じ証拠は明確な境界を設定する。可視の直接ルーティング隣接は 1 つであった。上流または物理的な多様性、マッピングされたアクセスフットプリント、設置帯域、バックアップ電源ランタイム、フィールド修理パフォーマンス、または有人のサポートオペレーションを確立する公開資料はなかった。最も重要なのは、商用クラウド、VPS、ベアメタル、コロケーション、ストレージ、またはマネージドホスティングサービスを立証するものは何もなかったことである。
これは残念な結果ではない。より有用な結果である。名称は、実際に観測可能な運用基盤をもはや覆い隠さない。Cloudnet は、AS150069 および Niss Internet Services を通じて、タミル・ナードゥでアクセストラフィックを搬送しているように見える。その耐障害性は、ケーブル、通電された電子機器、バックホール、経路設定、予備部品、それらを復旧できる人々といった、通常のインフラストラクチャによって決定されるだろう。
ネットワーク証拠のグレードは、ASN がアクティブであるという強力な証拠にもかかわらず、完全なインフラストラクチャ評価にとっては「弱い」である。ルーティングは可視だが、その背後にある物理的および商業的システムは可視ではない。より高いグレードには、顧客がどこで接続し、トラフィックがどのように退出し、何がフェイルオーバーし、ストレス下で容量がどのように振る舞い、各レイヤーを誰が修理するのかの証明が必要である。将来のクラウドサービスの主張は、評価すべきホスティングサービスが存在することを証明することから、一歩手前で始めなければならない。