RIPE台帳のOVH US LLC――「いつでも出られる」BYOIP計画は何を証明すべきか

要約

RIPE NCCの会員一覧はOVH US LLCを米国の会員として掲載する。これは地域インターネットレジストリにおける管理上の手掛かりだが、特定のプレフィックス、ASN、経路、施設、顧客、クラウドサービス、運用成果をOVH US LLCに帰属させる証拠ではない。
OVHcloudの公開資料は、適格な公開IPv4を持ち込み、アドレスと評判への責任を顧客が維持し、OVHcloudのASまたは顧客ASから広告するBYOIPサービスを説明する。ブランドの機能を示す資料であり、各地域の契約・運用主体を証明するものではない。
証拠は四層に分ける必要がある。地域レジストリは番号資源の管理関係を記録し、ROAは特定ASによるプレフィックスの起点広告を許可し、IRRのrouteオブジェクトは経路意図を表し、実際のBGPは現在流れている広告を示す。一つの緑表示で他の三層を代用できない。
RPKI起点検証はValid、Invalid、Unknownを判定する。確認するのはプレフィックス、起点AS、許容長の関係であり、ASパス全体、クラウドのサービス紐付け、アプリケーションの健全性、企業の身元までは検証しない。
出口は導入前に設計する。RIR、ROA、IRRの担当者、通常・移行・復旧時の起点、DNSやセキュリティの依存、重複期間、外部観測、旧経路の撤去順序を事前に決める必要がある。

トップ画像は、身元不明の運用担当者が二台の無印機器の間で一般的な経路切替を演習する、独自生成の写実的な編集画像である。OVH US LLC、OVHcloud、RIPE NCC、ARINの実在する社員、顧客、事務所、施設、ネットワーク、アドレスブロック、事故、障害、弱点、推奨を表すものではない。

同じアドレスが未完成の移行を隠す

地域卸売会社が、顧客ポータル、配送会社向けAPI、送信メールを一つの公開IPv4帯で運用しているとする。大口顧客はその範囲を許可リストに入れ、不正検知、監視、古い手順書も同じ値を参照する。すべてを番号変更するには長い調整が必要なため、会社はBYOIPを選ぶ。

導入時は安心に見える。顧客は同じアドレスへ接続し、取引先は許可リストを変えず、メール担当は積み上げた評判を維持できると期待する。経営層は「アドレスを保持し、後で別のクラウドへ持って行ける」と聞く。

問題は次の移行で現れる。新プロバイダーは別のASから広告する予定だが、ROAは旧起点しか許可していない。IRRのrouteオブジェクトにも古いASNが残る。あるいは、ROAの最大長が実際のより具体的な広告を覆わない。新経路が検証され、外部から見える前に旧プロバイダーが撤回すれば、番号資源の管理権が残っていてもサービスは到達不能になる。

これは一般的な計画例で、OVHcloudの顧客事故ではない。番号の継続とサービスの継続を分けて考えるための例だ。IPは同じでも、許可、フィルター、ルーター、アカウント、アプリケーションの紐付けは動く。全層の整合を観測し、旧状態へ本当に戻れるまで切替は終わらない。

OVH US LLCの会員記録が示す範囲

BTWディレクトリは本稿をOVH US LLCに関連付ける。RIPE NCCの公開会員ページはOVH US LLCを米国の会員として掲載し、管理上のサービス地域文脈を示す。正確なエンティティ名を公共の調整制度に置く点で有用だ。

ただしネットワーク地図ではない。本稿における特定ASN、プレフィックス、経路、キャンパス、顧客を示さず、可用性、性能、サポート、移行結果も測らない。会員関係は定義された行政関係であり、ルーターの瞬間状態ではない。

国際ブランドでは境界が特に重要になる。OVHcloudはグローバルと地域別のページを公開する一方、契約法人、会社、施設、担当範囲は異なり得る。本稿はOVH US LLC、OVH SAS、OVHcloudブランドを使う全企業を一つの法的・運用主体として扱わない。

したがってRIPE会員記録は管理上のアンカー、OVHcloud資料はブランドが公開するBYOIP操作面、RIPE NCC、ARIN、IETF資料はレジストリとプロトコルの説明に使う。それぞれの証拠を本来の範囲に保つ。

実作業でも同じ整理が必要だ。ブランド名、契約相手、資源保有者、起点ASN、クラウドアカウント、ルーターを操作するチームは関連していても同一ではない。緊急時には、誰が署名し、広告し、撤回し、復元できるかを具体的に知らなければならない。

非専門家のためのBYOIP

IPプレフィックスはアドレスのまとまりである。自律システム（AS）は、他ネットワークへ一貫した経路方針を示すネットワークで、ASNによって識別される。BGPは、どのプレフィックスへどの経路で到達できるかをネットワーク同士が交換する仕組みだ。

一般的なクラウドでは、顧客はプロバイダーのアドレスを使う。退去時にはそのアドレスを置いていき、サービスを番号変更する。BYOIPでは、顧客が必要な管理権を持つ適格な範囲を持ち込み、プロバイダーがクラウド上のサービスのために広告する。

OVHcloudの現行公開ページは、顧客が持ち込んだアドレスの保有者であり続け、評判への責任も維持する一方、OVHcloudがインターネットへ広告して対応サービスへルーティングすると説明する。ARIN、APNIC、RIPEで登録された範囲、Bring Your Own AS、任意の逆引きDNS、IPv4・サイズ・地域の制約も示す。実際の購入時には、対象製品と契約の最新条件を再確認すべきだ。

ヘルプ文書はRIR、地域、起点ASを選ぶ流れを示す。OVHcloud ASか顧客ASかという選択は、ROA、IRR、監視基準、退出計画に記録すべきASNを変える。画面上の飾りではない。

倉庫の例で考えると分かりやすい。番号資源登録は管理権を示す書類、ROAは「この入口からの配送を許可する」という署名済み指示、IRRは経路計画に使う名簿、BGPは実際に走る配送車、アプリケーションは到着先の倉庫に相当する。書類が正しくても道路が切れ、倉庫の扉が閉じていれば業務は動かない。

同じ番地を保つことと、配送路を保つことは別である。

四つの証拠を一つにまとめない

第一は番号資源登録である。地域インターネットレジストリはIPアドレスとASNの割り当て・登録を調整する。組織には有効なアカウント、責任者、必要に応じて資源を覆う証明書が要る。これは管理権を示すが、BGP広告の存在は示さない。

第二はRPKIである。認証された資源の保有者はRoute Origin Authorization、つまりROAを作れる。RFC 9582は、起点AS、プレフィックス、任意の最大長を含む署名オブジェクトを規定する。検証ソフトウェアは、ルーターの方針判断に使える検証済み情報を作る。

第三はInternet Routing Registryである。routeまたはroute6オブジェクトはプレフィックスと起点ASを主要項目として持つ。RIPE文書は構造と作成時の認可を説明する。ネットワークはIRRからフィルターを作る場合があるが、これは経路意図であり、暗号学的ROAでも稼働中の経路でもない。

第四が動作中のBGPである。プロバイダーがルーターを設定し、隣接ネットワークが各自の方針で受け取り、外部観測点は分散システムの一部を見る。その先でIPが正しいプロジェクト、ロードバランサー、ファイアウォール、サーバーへ結び付いていなければならない。

四層は食い違い得る。登録は正しくてもROAがない。ROAが許可するASは広告していない。IRRは旧起点を残す。BGPはInvalidな経路を流す。経路は正常でもアプリケーションが別テナントに接続されている。

変更記録には証拠名と時刻を書く。「資源保有者を確認」「選んだ検証点でROAを確認」「IRRオブジェクトを照会」「二つの外部地点で起点を観測」「公開経路からアプリを試験」と分ける。プロバイダー画面はその画面の状態を示すだけで、世界の状態ではない。

Validは到達可能の同義語ではない

RIPE NCCは起点検証を三状態で説明する。ROAがプレフィックスを覆い、観測した起点ASを許可し、広告長が上限内ならValid。起点が違うか、広告が許可より具体的ならInvalid。覆うROAがなければUnknownである。

Validでもアプリケーションは停止し得る。検証対象はASパス全体、クラウドのサービス紐付け、TLS、アプリの応答、商業的身元ではない。検証されたのはプレフィックスと起点の関係だ。

Invalidは重大な警告だが、攻撃の自動証明ではない。ASNの入力誤り、プロバイダー変更、想定外のより具体的な広告、資源証明書の変更でも起こる。迅速に扱いつつ、原因は事実から判断する。

Unknownも安全や侵害を意味しない。覆う署名済み許可が検証データにないという意味だ。各ネットワークがローカル方針を適用する。RFC 6811は分散キャッシュの時間差にも触れており、更新中は地点ごとに状態が異なり得る。

ROA作成は世界共通の切替ボタンではない。RIRが公開し、検証器が取得し、ネットワークが自らの周期と方針で使う。ARINのFAQが説明するのは公開と生態系の時間であり、全世界の同時刻ではない。提出、公開、検証済みデータ、BGP観測の時刻を別々に残すべきだ。

起点ASNと最大長は正確でなければならない

ROAの起点ASNは実際に広告するASと一致する必要がある。OVHcloud資料はプロバイダーASまたは顧客ASを選べると説明する。退出時にモデルが変わるなら、署名済み許可も変える。

正当な重複期間に二つの起点を許可する設計もある。ARIN FAQは一つのROAに起点ASは一つで、複数ASNには追加ROAが必要だと説明する。重複が適切かはアーキテクチャとプロバイダー手順次第で、障害中に決めるべきではない。

最大長はどこまで具体的なプレフィックスを許すかを決める。狭すぎれば正当なより具体的広告がInvalidになり、広すぎれば計画外の下位プレフィックスまで許可する。ARINは実際の広告に正確に合うROAと、不要に広いmaxLengthを避ける考え方を示す。

経営者が問うべきなのは計算式ではなく、「通常、移行、復旧の各状態で、署名済み許可が実際のプレフィックスと起点を正確に記述しているか」である。

IRRは意図の記録であり、可視性の証明ではない

RIPE Databaseはrouteとroute6オブジェクトを説明し、プレフィックスと起点を組み合わせたキーや作成認可を定める。多くのネットワークがフィルター作成に使うため、正しいIRR情報は実務上重要だ。

しかしIRRとROAは信頼モデルが異なる。一方だけが存在することもある。どちらもBGPそのものではない。旧オブジェクトは退出後に残り、新オブジェクトはルーターが広告する前に現れ得る。

事前確認では、計画上の値、IRR、検証済みROA、BGP観測起点を別々に比較する。RIPE REST APIは反復可能な照会を助けるが、自動化は不一致時に安全停止すべきで、似た値を選んで進めてはならない。

導入前に出口を作る

新プロバイダーが初めて広告する前なら、旧経路はまだ動作している。権限不足を低コストで直せる時期である。

資源保有者、RIRアカウント、証明書範囲、承認済み管理者、復旧連絡先を記録する。範囲が直接保有か上位事業者からの再割当かも確認する。ARINのBYOIP資料は、再割当空間では利用者がRPKI権限を持たず、上位保有者にROA作成を頼む場合があると説明する。

次に実際のサービス関係を記録する。契約法人、地域、サポート窓口、起点ASN、サイズ制限、撤回手順、逆引きDNSの担当である。ブランドページは出発点であり、現在の注文確認が本番根拠になる。

現在のROA、最大長、IRR、実起点を保存し、各項目を変更できる担当者と第三者のリードタイムを明示する。複数の外部視点から経路とアプリの基準も作る。

最後に逆順を書く。新ASの広告前に何が必要か。何が外部観測されたら旧起点を撤回できるか。重複はどれだけ続くか。復旧のため何を残すか。古い許可はいつ消すか。入口だけの手順は携帯可能とはいえない。

検証できる十段階

第一に、IPv4範囲、RIR権限、証明書、アカウント、ASN、現行製品要件を確認する。第二に、ROAとIRRの予定値を書き、別の有資格者が文字単位で確認する。

第三に、正逆DNS、証明書、ファイアウォール、許可リスト、評判、位置情報、abuse連絡先、監視、取引先を棚卸しする。同じIPでも周辺は変化する。

第四に、通常トラフィックを載せずにプロバイダー側の準備を完了する。OVHcloudの別文書にあるBGP Serviceは、現時点でalphaかつ本番利用を意図しないと明記される。名称だけでBYOIPの本番保証と混同しない。

第五に、正規経路で必要なROAとIRRを公開し、復旧に必要な旧状態は残す。第六に、広告前にRIR、検証器、IRR、プロバイダー状態を照合し、フィールド不一致なら不可逆作業を止める。

第七に、有界な広告を行い、複数外部点でプレフィックス、長さ、起点を観測する。第八に、公開経路からTLS、HTTP、API、メールなどの業務プロトコルを試す。

第九に、事前の誤り閾値を使って段階的に流量を移し、旧経路を維持する。第十に、新状態が十分観測された後で旧起点を撤回し、復旧期間終了後に古いROA、IRR、アカウント、ルール、資格情報、サービス紐付けを片付ける。

各段階に担当者と停止条件が必要だ。「ネットワークチーム担当」だけでは深夜の意思決定者にならない。

復旧は完全な状態を戻すこと

注文取消、新経路撤回、旧経路再広告、アプリ紐付け切替、変更停止はそれぞれ違う。新経路がValidでもアプリが失敗している場合、新広告を止めるだけで復旧するのは、旧経路と旧サービスが健全な場合に限られる。

ASN誤りでInvalidなら、アプリコードを戻しても直らない。ROA、広告、または旧起点を直す必要がある。意図せず二起点が見える場合、両社へ同時に「全部戻して」と頼むと空白を作り得る。

復旧は状態で定義する。旧起点が外部から見え、許可記録が合い、アプリが結び付き、外部試験が通り、判断者が確認した状態だ。「新経路を消した」は一操作にすぎない。

時間も復旧資源である。リポジトリ、検証器、ルーター、キャッシュは同時に変わらない。旧環境を保つ費用は、試験済み復旧路を買う費用だ。短時間の節約で早期破棄すれば、大きな停止リスクへ変わる。

IPが同じでも周辺は変わる

BYOIPは番号変更を減らすが、環境を凍結しない。逆引きDNSは新しいプロバイダーまたは委任経路で管理されることがある。OVHcloudページは任意の逆引き管理を挙げるため、既存PTRの継続、変更権、外部検証を確認すべきだ。

正引きアドレスが同じでも、ヘルスチェック、トラフィック制御、証明書自動化は変わり得る。評判や位置情報サービスが新しい経路文脈を反映することもある。abuse対応は資源保有者、クラウド、アプリ運用者で役割が分かれる。

監視は経路とサービスを分ける。経路監視は可視性、起点、検証状態を見る。サービス監視は公開経路からアプリを見る。片方の正常は他方を保証しない。

同じアドレスは継続を助けるが、それ自体が継続ではない。

よくある失敗と人のコスト

資源権限不足は、窓口で初めて上位事業者のROAが必要と判明する。誤ASNは注文、ROA、広告を食い違わせる。誤最大長は一部プレフィックスだけをInvalidにする。古いIRRは一部ネットワークのフィルターを残す。早すぎる撤回は機能する起点をゼロにする。

偽のロールバックは新状態を止めるだけで旧状態を戻さない。誤サービス紐付けはBGPを正常に見せたまま利用者を止める。不完全な清掃は意図と合わない許可、アカウント、秘密を残す。エンティティ混同は正しい担当探しに事故時間を浪費する。

結果は夜間作業、取引先の遮断、重複問い合わせ、顧客説明、証拠不足での経営判断として現れる。機能料金が小さくても調整費は小さくない。

最低限の責任表には、資源、ROA、IRR、プロバイダー広告、アプリ、DNS、監視、変更調整、撤去を置く。担当のない行は、未割当の本番制御である。

30日で準備する

1〜5日目は重要プレフィックス、業務、保有者、起点、ROA、IRR、外部基準を棚卸しする。6〜10日目は二名以上の管理者と復旧経路を確認する。11〜15日目は通常、移行、復旧、最終状態を定義し、独立レビューを行う。

16〜20日目はDNS、証明書、メール、許可リスト、セキュリティ、監視、第三者を確認する。21〜25日目は安全な範囲で演習し、一回の時間をSLAにしない。26〜28日目はInvalid起点、Valid経路のアプリ障害、部分可視性を机上演習する。

29〜30日目は調整責任者、復旧権限、重複予算、証拠様式、清掃期限を承認する。終了時、別の担当者が個人の記憶なしに旧・新状態と復旧路を説明できるべきだ。

公開資料からは分からないこと

本稿の資料はOVH US LLCに特定ASN、プレフィックス、経路、顧客、施設、実配備を割り当てない。RIPE会員ページは資源一覧ではない。

OVHcloudページはブランド機能を説明するが、個別案件の契約・運用法人や成果を証明しない。実顧客のROA、IRR、経路を示さず、障害や弱点の証拠でもない。

世界共通の反映時間も保証しない。検証器、ネットワーク、観測点は分散周期と方針を持つ。アプリ可用性、メール配信、評判、遅延、防御性能も起点許可だけでは分からない。

参照した別のBGP Serviceガイドはalphaかつ本番向けでないとする。本稿はそれを本番依存として推奨しない。

画像は一般的な編集文脈で、OVH US LLCやOVHcloudの実在人物、機器、場所、経路、事故を表さない。

結論

OVH US LLCのRIPE会員記録は限定的な管理アンカーである。OVHcloud文書は適格なIPv4をプロバイダーASまたは顧客ASから広告するBYOIP操作面を示す。これで制御を分析できるが、特定経路や顧客成果は作れない。

携帯性は層で成り立つ。レジストリが権限を記録し、ROAが起点許可を署名し、IRRが意図を公開し、BGPが経路を実行し、アプリが流量を受ける。Validは重要だがサービス完成ではない。

出口は入口より前に設計する。アクセス、ASN、正確なオブジェクト、周辺依存、外部基準、旧経路、清掃順序を用意し、新状態を観測してから旧状態を消す。

非専門家が守るべき問いは五つだ。誰が資源を管理するか。誰が起点を署名できるか。どのネットワークが広告すべきか。外部はいま何を見るか。誰が旧状態を復元できるか。現在の台帳と演習で答えられるなら、BYOIPは運用上の可逆性になる。画面の緑表示だけなら、同じアドレスが脆い移行を隠しているかもしれない。