ISPは大規模なIPアドレス割り当てをどう管理するのか

アドレスプールは、利用者に合わせてサービスを編成するためのものだ。その計画は、利用者をつなぐ実際のネットワークとも整合していなければならない。

新しい顧客が接続し、別の顧客は拠点を移し、さらに別の顧客はホストしているサービスに固定アドレスを必要とする。ISPの規模では、こうした変化が絶えず起こる。アドレス管理では、一つひとつの顧客の要望を、収容能力、ルーティング、そして次の運用担当者にも理解できる記録につなげなければならない。

出発点として役立つのは、稼働中のネットワークそのものだ。どのサービスへの到達性を維持しなければならないのか。アドレスはどのように顧客に届けられるのか。既存の接続を妨げずに、どのような変更ができるのか。

アドレス空間の確保と利用を分けて考える

ISPが利用できるアドレス資源には、長年保有してきたもの、登録上の移転で取得したもの、リースしたアドレス空間、別のプロバイダーから提供されたものが含まれる場合がある。それぞれに適用される取り決めは異なる。運用者が資源を利用できるようになっても、内部での計画、機能する経路、顧客向けのプロビジョニングは別途必要だ。

レジストリの登録情報と経路広告は、異なる役割を担う。登録は調整に必要な情報を記録し、ルーターは自らの設定と受け入れた経路に従ってトラフィックを転送する。この2つの層の整合性を保つことは、運用上重要だ。しかし、管理層をその下にあるすべてのネットワークの所有者とみなすのは、それを超えた政治的な主張であり、Lu Hengはノート67で異議を唱えている。

サービスに合わせてアドレス空間を分ける

アクセス地域、顧客区分、インフラ上の役割ごとにプールを配分し、拡張や復旧のための余地を意図的に確保しよう。CIDRはプレフィックス長でブロックを表す。IPv4の/24には256個のアドレス値が含まれる。ただし、この計算だけでは、その設計で何人の顧客にサービスを提供できるかは分からない。

単一のアドレスを必要とする顧客もいれば、多数のアドレスを含み、顧客側へルーティングされるプレフィックスを必要とする顧客もいる。ネットワークアドレス、ブロードキャストアドレス、プロバイダー用の予約分は設計によって異なる。都市の人口や「全国規模のISP」という呼び名だけで、安易にブロックのサイズを決めてはならない。

CIDRのルーティングと経路集約のモデルからは、整合性のあるアドレス計画によって、個別に広告する経路の数を減らせる理由も分かる。ただし、経路集約も実際の経路と一致していなければならない。台帳をきれいに整理しただけで、到達できない宛先に届くようにはならない。

個々の割り当てを追跡可能にする

顧客またはサービス、プレフィックスまたはアドレス、アクセスノード、ルーティングのコンテキスト、割り当て方法、関連する開始時刻と終了時刻を記録しよう。動的なセッションと固定割り当てでは、ライフサイクルが異なる。DHCPリース、アクセスセッション管理システム、プロビジョニングAPIから、運用担当者が使う記録に情報が反映される必要がある。

プールを拡張する前に、予定している割り当てと繁忙時に観測された需要を比較しよう。割り振られた総量が多くても、個々のプールが枯渇していることはある。逆に、一見空いているアドレス範囲が、放置されているのではなく、フェイルオーバー用に確保されている場合もある。

アドレス共有とプロトコル対応を意識的に選ぶ

アドレスとポートの変換は、NAPTと呼ばれ、一般に「NAT」に含めて扱われる。この仕組みによって、複数の顧客や機器がパブリックIPv4アドレス空間を共有できる。キャリアグレードNATを導入すると、容量計画、アプリケーションとの互換性、各時点の対応関係の記録など、運用上の要件が増える。その場合、1つのパブリックアドレスに複数の利用者が対応することになる。

IPv6は、はるかに広いアドレス空間を提供し、顧客向けプレフィックスの設計にも異なる選択肢をもたらす。ただし、IPv4にしか対応していない宛先へ、自動的にアクセスできるようになるわけではない。ネイティブIPv4、デュアルスタック、変換を使う構成を、顧客が実際に利用するサービスに照らし、サポートの負担や復旧時の挙動も含めて評価しよう。どの選択肢も、単なるスローガンにしてしまうべきではない。

日常的な変更の中で継続性を守る

顧客の利用終了は小さな変更だが、いくつもの依存関係が伴う。割り当ての終了を確認し、関連する経路情報や名前のレコードを削除または更新し、サービス側に残る参照を確認する。その後で初めて、資源を適切なプールに戻す。以前の割り当て履歴は、上書きせずに残そう。

ルーティングの監視、送信元アドレスのフィルタリング、DNSのセキュリティは、それぞれ異なる障害や問題に対処する。DNSSECはDNSデータを認証するものであり、IPアドレスの割り当てを検証したり、あらゆるルーティング攻撃を防いだりするものではない。役に立つ運用画面は、1つの対策で全部解決できるとはうたわず、それぞれの状況を区別して示す。

調整の仕組みをネットワークの運用者のために生かす

地域ごとのチームは、共有され、確認可能な記録を維持しながら、自分たちのプールを管理できる。組織には、誤りを訂正し、意味のあるデータを書き出し、機能しなくなった管理サービスの提供元を交代させる手段が必要だ。番号を整理するための階層構造は、それだけで、その番号を使うすべての人に政治的な権力を行使する根拠にはならない。

必要な調整と組織による支配の間に、Lu Hengがどのような境界を提案しているかについては、ノート72を参照してほしい。組織内での実務的な確認事項については、IP資源管理でよくある間違いを続けて読んでほしい。