エニーキャスト(英: anycast)は、ルーティングトポロジーから見てデータを「最も近い」または「最もよい」あて先に送信するネットワークのアドレッシング/ルーティング手法である(anycast―いずれかに送信)。

## 概要

この用語はユニキャスト、ブロードキャスト、マルチキャストという用語と同列に使われる。

- 「ユニキャスト」では、ネットワークアドレスとネットワーク端点に1対1の対応がある。各あて先アドレスは1つの受信端点を一意に識別する。
- 「ブロードキャスト」と「マルチキャスト」では、ネットワークアドレスとネットワーク端点群に1対多の対応がある。各あて先アドレスは受信端点群をまとめて識別し、それぞれに情報が複製される形で届く。
- 「エニーキャスト」でも、ネットワークアドレスとネットワーク端点群に1対多の対応がある。各あて先アドレスは受信端点群をまとめて識別するが、任意の時点ではその中の1つだけを選択し、情報をその端点だけに送られる。

インターネットでは、エニーキャストは一般にBGPを使って実装され、インターネット上の様々な場所から同じIPアドレス範囲を同時に告知する。すると、この範囲のアドレスをあて先とするパケットは、そのアドレスを告知した最も近い地点にルーティングされる。

かつては、エニーキャストはTCPのように状態を保持するコネクション型プロトコルよりもUDPをベースとするコネクションレス型プロトコルに適していた。しかし現在では、TCPによるエニーキャストを様々なケースで使っている。

TCPエニーキャストでは、最適なルートが時と共に変化すると、ある発信源について選択される受信側が変わることもあるが、その際に接続していた対話が突然途切れる。このような現象を一般に "PoP switch" と呼ぶ。この対策として、ステートフルなプロトコルを必要に応じて修復できるようにするIPスタックの独自の改良も行われている。しかし、PoP switch 対策技術を施さない場合は、GeoDNSのようなシステムがより適している。

このためエニーキャストは、複製されたデータへのアクセスなどステートレスなサービスの可用性強化や負荷分散の目的で一般に使用されている。そのようなサービスの代表としてDNSサービスがある。DNSは分散サービスであり、サーバは地理的に離れた複数の地点に分散配置されている。

## DNSでの使用

いくつかのインターネット・ルートサーバは複数のホストのクラスタとして実装されており、エニーキャスト・アドレッシングを使っている。C, F, I, J, K, L, M のサーバ群が異なる大陸の複数の場所にあり、エニーキャスト型のアドレス告知による分散サービスを行っている。これにより、アメリカ合衆国外へのルートサーバの(名目だけでない)物理的な配備が加速された。RFC 3258 は、権威ある (authoritative) DNSサービスの提供にエニーキャストをどのように使うかを文書化したものである。Autonomica、Community DNS、DNSMadeEasy、Dynect、EasyDNS、BlueCat Networks、Infoblox、Netriplex、Neustar Ultra Services(以前はUltraDNS)、Packet Clearing House といった多くの権威あるDNSサービスプロバイダが、クエリ性能と冗長性を向上させるためにIPエニーキャスト環境へ移行している。IPエニーキャスト・アドレッシングを使うことで、高度な回復力のあるDNSサービスを提供できる。DNS AdvantageやOpenDNSのような再帰DNSサービスも、負荷を分散させるためにエニーキャストを利用している。

## IPv6移行での使用

IPv4 から IPv6 への移行期において、IPv4 ホストに IPv6 の接続性を提供する手段のひとつに 6to4 と呼ばれる手法があった。6to4 では、IPv4 エニーキャストアドレス 192.88.99.1 が最寄りの 6to4 リレールータを意味する (RFC 3068)。エニーキャストを使うことで複数のプロバイダが 6to4 ゲートウェイを実装でき、しかも個々のホストは特定のプロバイダのゲートウェイアドレスを知る必要がなかった。

## 実装におけるセキュリティ

エニーキャストアドレスのパケットはルーティング情報を受信する中間のルーターで乗っ取ることが可能である。これは一見すると安全でないように思えるが、通常のIPパケットにも同じことが可能であり、安全性に違いはない。通常のIPルーティングと同様、ルート情報の伝播の注意深いフィルタリングが中間者攻撃やブラックホール攻撃を防ぐのに重要である。

## 信頼性

エニーキャストは一般に非常に信頼性が高く、自動フェイルオーバーを提供できる。エニーキャスト・アプリケーションはサーバ機能を外側からハートビート監視する機能を持つことが多く、サーバで障害が発生したとき経路告知を撤回する。場合によっては、OSPFや他のIGPプロトコル上でルーターにエニーキャストのプレフィックスを告知した実際のサーバがこれを行う。サーバが停止すると、ルーターは自動的にその告知を廃棄する。

ハートビート機能は重要である。何故なら、障害の発生したサーバの告知が継続した場合、そのサーバは付近のクライアントに対して「ブラックホール」として機能することになってしまうからである。ただしそのような事態が発生しても、そのサーバに近いクライアントでしか問題は発生せず、全体的な障害に陥ることはない。

## DoS攻撃とエニーキャスト

エニーキャストはDDoS攻撃の効果を低減させることができる。トラフィックは最も近いノードにルーティングされ、攻撃者はそれを制御できないので、DDoS攻撃のトラフィックは発信地点に最も近いノード群に分散される。このため全ノードが影響されるようにはならない。これを理由としてエニーキャストを採用することもある。

ただし、分散型の攻撃に対するこの技法の効果には疑問もある。何故なら、(保守用の)各ノードのユニキャストアドレスは特にIPv6では容易に取得できるからである。RFC 2373 (オブソリート済み)では「エニーキャストアドレスをIPv6パケットの発信元アドレスに使ってはならない」とある。したがって、エニーキャストアドレスにpingを行うと、最も近いノードのユニキャストアドレスが返ってくる(応答パケットの発信元アドレスとしてエニーキャストアドレスを使えないため)。すると、攻撃者はエニーキャストのアドレッシング機構を迂回して、世界中のどこからでも個別のノードに攻撃をしかけることができる。同じことはIPv4にもほぼ当てはまるが、全く同じではない。

尚、「エニーキャストアドレスをIPv6パケットの発信元アドレスに使ってはならない」との記述は、元々「さらなる経験が蓄積され、ソリューションが考えられるまで」との条件付きで書かれており、後続の RFC 3513 (オブソリート済み)までは存続していたが、その後続の RFC 4291 では記述は削除されている。

## ローカルノードとグローバルノード

エニーキャストをインターネットで実施する場合、ローカルノードとグローバルノードを区別することがある。ローカルノードは、直接のローカルなコミュニティに利点を提供することを意図している。ローカルノードの告知は no-export BGPコミュニティ属性を付与して行われ、告知はローカルの領域に限定される。すると、そのローカルな領域ではグローバルなノードよりもローカルなノードが優先的にルーティングされ、外部からはルーティングされないという状態にできる。

FおよびKのルートサーバは現在、ローカルノードとグローバルノードの構成で運用されている。