Network Working Group J. Abley
Request for Comments: 4786 Afilias Canada
BCP: 126 K. Lindqvist
Category: Best Current Practice Netnod Internet Exchange
December 2006
Operation of Anycast Services
Status of This Memo
このメモのステータス
This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
このドキュメントはインターネットコミュニティのためのインターネットBest Current Practicesを指定し、改善のための議論と提案を要求します。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The IETF Trust (2006).
著作権（C）IETFトラスト（2006）。
Abstract
抽象
As the Internet has grown, and as systems and networked services within enterprises have become more pervasive, many services with high availability requirements have emerged. These requirements have increased the demands on the reliability of the infrastructure on which those services rely.
インターネットが成長したように、そして企業内システムやネットワークサービスがより普及してきたように、高可用性の要件を持つ多くのサービスが出現しています。これらの要件は、これらのサービスが依存している上でのインフラの信頼性への要求が高まっています。
Various techniques have been employed to increase the availability of services deployed on the Internet. This document presents commentary and recommendations for distribution of services using anycast.
様々な技術がインターネット上で展開されたサービスの可用性を向上させるために使用されてきました。この文書では、エニーキャストを使用して、サービスの配信のための解説と推奨事項を提示します。
Table of Contents
目次
1. Introduction ....................................................3
2. Terminology .....................................................4
3. Anycast Service Distribution ....................................5
3.1. General Description ........................................5
3.2. Goals ......................................................5
4. Design ..........................................................6
4.1. Protocol Suitability .......................................6
4.2. Node Placement .............................................7
4.3. Routing Systems ............................................8
4.3.1. Anycast within an IGP ...............................8
4.3.2. Anycast within the Global Internet ..................9
4.4. Routing Considerations .....................................9
4.4.1. Signalling Service Availability .....................9
4.4.2. Covering Prefix ....................................10
4.4.3. Equal-Cost Paths ...................................10
4.4.4. Route Dampening ....................................12
4.4.5. Reverse Path Forwarding Checks .....................13
4.4.6. Propagation Scope ..................................13
4.4.7. Other Peoples' Networks ............................14
4.4.8. Aggregation Risks ..................................14
4.5. Addressing Considerations .................................15
4.6. Data Synchronisation ......................................15
4.7. Node Autonomy .............................................16
4.8. Multi-Service Nodes .......................................17
4.8.1. Multiple Covering Prefixes .........................17
4.8.2. Pessimistic Withdrawal .............................17
4.8.3. Intra-Node Interior Connectivity ...................18
4.9. Node Identification by Clients ............................18
5. Service Management .............................................19
5.1. Monitoring ................................................19
6. Security Considerations ........................................19
6.1. Denial-of-Service Attack Mitigation .......................19
6.2. Service Compromise ........................................20
6.3. Service Hijacking .........................................20
7. Acknowledgements ...............................................21
8. References .....................................................21
8.1. Normative References ......................................21
8.2. Informative References ....................................21
This document is addressed to network operators who are considering whether to deploy or operate a distributed service using anycast. It describes the best current practice for doing so, but does not recommend whether any particular service should or should not be deployed using anycast.
この文書は、エニーキャストを使用して分散サービスを展開するか、動作するかどうかを検討しているネットワークオペレータにアドレス指定されています。それはそうするための最良の現在のプラクティスを説明しますが、任意の特定のサービスがまたはエニーキャストを使用して展開すべきではない必要があるかどうかはお勧めしません。
To distribute a service using anycast, the service is first associated with a stable set of IP addresses, and reachability to those addresses is advertised in a routing system from multiple, independent service nodes. Various techniques for anycast deployment of services are discussed in [RFC1546], [ISC-TN-2003-1], and [ISC-TN-2004-1].
エニーキャストを使用してサービスを配信するために、サービスは、最初のIPアドレスの安定したセットに関連付けられ、これらのアドレスへの到達可能性は、複数の独立したサービスノードからルーティングシステムで広告されています。サービスのエニーキャストの展開のための様々な技術が[RFC1546]、[ISC-TN-2003-1]、および[ISC-TN-2004-1]に記載されています。
The techniques and considerations described in this document apply to services reachable over both IPv4 and IPv6.
この文書に記載された技術と考慮事項は、IPv4とIPv6の両方の上に到達可能なサービスに適用されます。
Anycast has in recent years become increasingly popular for adding redundancy to DNS servers to complement the redundancy that the DNS architecture itself already provides. Several root DNS server operators have distributed their servers widely around the Internet, and both resolver and authority servers are commonly distributed within the networks of service providers. Anycast distribution has been used by commercial DNS authority server operators for several years. The use of anycast is not limited to the DNS, although the use of anycast imposes some additional limitations on the nature of the service being distributed, including transaction longevity, transaction state held on servers, and data synchronisation capabilities.
エニーキャストは、近年のDNSアーキテクチャ自体がすでに提供して冗長性を補完するためにDNSサーバに冗長性を追加するため、ますます人気となっています。いくつかのルートDNSサーバのオペレータは、インターネットを中心に、広くそのサーバを分散している、との両方のリゾルバと権威サーバは、一般的に、サービスプロバイダのネットワーク内で分散されています。エニーキャスト分布は、数年前から、市販のDNS権威サーバのオペレータによって使用されてきました。エニーキャストの使用は、トランザクション・長寿、サーバ上で開催されたトランザクション状態、およびデータ同期機能など、配布されるサービスの性質にいくつかの追加の制限を課すが、エニーキャストの使用は、DNSに限定されるものではありません。
Although anycast is conceptually simple, its implementation introduces some pitfalls for operation of services. For example, monitoring the availability of the service becomes more difficult; the observed availability changes according to the location of the client within the network, and the population of clients using individual anycast nodes is neither static, nor reliably deterministic.
エニーキャストは、概念的には単純ではあるが、その実装は、サービスの操作のためにいくつかの落とし穴を紹介します。例えば、サービスの可用性を監視することがより困難になります。個々のエニーキャストノードを使用して、ネットワーク内のクライアントの場所に応じて観測された可用性の変更、およびクライアントの人口静的な、でも確実に決定論的でもありません。
This document will describe the use of anycast for both local scope distribution of services using an Interior Gateway Protocol (IGP) and global distribution using the Border Gateway Protocol (BGP) [RFC4271]. Many of the issues for monitoring and data synchronisation are common to both, but deployment issues differ substantially.
この文書では、ボーダーゲートウェイプロトコル（BGP）[RFC4271]を使用して、インテリアゲートウェイプロトコル（IGP）とグローバル・ディストリビューションを利用したサービスのローカルスコープ分布の両方のためのエニーキャストの使用を説明します。監視とデータ同期の問題の多くは、両方に共通しているが、展開の問題は、実質的に異なります。
Service Address: an IP address associated with a particular service (e.g., the destination address used by DNS resolvers to reach a particular authority server).
サービス住所：特定のサービスに関連付けられたIPアドレス（例えば、DNSリゾルバによって使用される宛先アドレスは、特定の権限サーバーに到達します）。
Anycast: the practice of making a particular Service Address available in multiple, discrete, autonomous locations, such that datagrams sent are routed to one of several available locations.
エニーキャスト：複数の、個別の、自律場所で特定のサービスアドレスを利用可能にすることの実践、送信されたデータグラムは、いくつかの利用可能な場所のいずれかにルーティングされるようになっています。
Anycast Node: an internally-connected collection of hosts and routers that together provide service for an anycast Service Address. An Anycast Node might be as simple as a single host participating in a routing system with adjacent routers, or it might include a number of hosts connected in some more elaborate fashion; in either case, to the routing system across which the service is being anycast, each Anycast Node presents a unique path to the Service Address. The entire anycast system for the service consists of two or more separate Anycast Nodes.
エニーキャストノード：一緒にエニーキャストサービスアドレスのためのサービスを提供するホストとルータの内部で接続されたコレクション。エニーキャストノードは、隣接するルータとルーティングシステムに参加している単一のホストと同じくらい簡単であるかもしれない、またはそれは、いくつかのより複雑な方法で接続されたホストの数を含み得ます。いずれの場合も、サービスはエニーキャストされている間でルーティングシステムに、各エニーキャストノードは、サービスのアドレスに一意のパスを提示します。サービスの全体エニーキャストシステムは、2つの以上の別個のエニーキャストノードで構成されています。
Catchment: in physical geography, an area drained by a river, also known as a drainage basin. By analogy, as used in this document, the topological region of a network within which packets directed at an Anycast Address are routed to one particular node.
流域：物理的な地理で、川で排水面積は、また流域として知られています。本書で使用されるように類推して、ネットワークのトポロジー領域がその中にある特定のノードにルーティングされるエニーキャストアドレスに向けられたパケット。
Local-Scope Anycast: reachability information for the anycast Service Address is propagated through a routing system in such a way that a particular anycast node is only visible to a subset of the whole routing system.
ローカルスコープエニーキャスト：エニーキャストサービスアドレスの到達可能性情報は、特定のエニーキャストノードが全体ルーティングシステムのサブセットにのみ表示されるように、ルーティングシステムを介して伝播されます。
Local Node: an Anycast Node providing service using a Local-Scope Anycast Address.
ローカル・ノード：ローカルスコープエニーキャストアドレスを使用してサービスを提供するエニーキャストノード。
Global-Scope Anycast: reachability information for the anycast Service Address is propagated through a routing system in such a way that a particular anycast node is potentially visible to the whole routing system.
グローバルスコープエニーキャスト：エニーキャストサービスアドレスの到達可能性情報は、特定のエニーキャストノードが全体のルーティングシステムに潜在的に見えるようにルーティングシステムを介して伝播されます。
Global Node: an Anycast Node providing service using a Global-Scope Anycast Address.
グローバルノード：グローバル・スコープエニーキャストアドレスを使用してサービスを提供するエニーキャストノード。
Anycast is the name given to the practice of making a Service Address available to a routing system at Anycast Nodes in two or more discrete locations. The service provided by each node is generally consistent regardless of the particular node chosen by the routing system to handle a particular request (although some services may benefit from deliberate differences in the behaviours of individual nodes, in order to facilitate locality-specific behaviour; see Section 4.6).
エニーキャストは、二つ以上の別々の場所でのエニーキャストノードのルーティングシステムへのサービスのアドレスを利用可能にすることの練習に与えられた名称です。各ノードが提供するサービスに関係なく、いくつかのサービスは、地域固有の動作を容易にするために、個々のノードの行動の意図的な差から利益を得ることができるが（特定の要求を処理するためのルーティングシステムによって選択された特定のノードの一般的に一致している。参照します4.6節）。
For services distributed using anycast, there is no inherent requirement for referrals to other servers or name-based service distribution ("round-robin DNS"), although those techniques could be combined with anycast service distribution if an application required it. The routing system decides which node is used for each request, based on the topological design of the routing system and the point in the network at which the request originates.
アプリケーションがそれを必要に応じてこれらの技術は、エニーキャストサービス配信と組み合わせることができるものの、エニーキャストを使用して、分散サービスのために、他のサーバまたはネームベースのサービスの分布（「ラウンドロビンDNS」）への紹介のための固有の要件は、存在しません。ルーティングシステムは、ルーティングシステムのトポロジー設計と要求が発信されるネットワーク内のポイントに基づいて、各要求のために使用されているノードを決定します。
The Anycast Node chosen to service a particular query can be influenced by the traffic engineering capabilities of the routing protocols that make up the routing system. The degree of influence available to the operator of the node depends on the scale of the routing system within which the Service Address is anycast.
特定のクエリにサービスを提供するために選ばれたエニーキャストノードは、ルーティングシステムを構成するルーティングプロトコルのトラフィックエンジニアリング機能によって影響を受ける可能性があります。ノードのオペレータが利用可能な影響の程度は、サービスアドレスがエニーキャストである内ルーティングシステムの規模に依存します。
Load-balancing between Anycast Nodes is typically difficult to achieve (load distribution between nodes is generally unbalanced in terms of request and traffic load). Distribution of load between nodes for the purposes of reliability, and coarse-grained distribution of load for the purposes of making popular services scalable, can often be achieved, however.
ロード・バランシング・エニーキャストノード間は（ノード間の負荷分散が要求およびトラフィック負荷の点で、一般的に不平衡である）を達成するために、典型的には困難です。信頼性の目的のために、ノード間の負荷の分散、および人気のあるサービスは、スケーラブルな作りの目的のために、負荷の粗粒度分布は、多くの場合、しかし、実現することができます。
The scale of the routing system through which a service is anycast can vary from a small Interior Gateway Protocol (IGP) connecting a small handful of components, to the Border Gateway Protocol (BGP) [RFC4271] connecting the global Internet, depending on the nature of the service distribution that is required.
サービスは、エニーキャストされ、それを通してルーティングシステムの規模が性質に応じて、グローバルインターネットに接続するボーダーゲートウェイプロトコル（BGP）[RFC4271]に、構成要素の小さな一握りを接続する小さなインテリアゲートウェイプロトコル（IGP）から変えることができます必要とされるサービス配信の。
A service may be anycast for a variety of reasons. A number of common objectives are:
このサービスは、様々な理由のために、エニーキャストかもしれません。共通の目標の数は以下のとおりです。
1. Coarse ("unbalanced") distribution of load across nodes, to allow infrastructure to scale to increased numbers of queries and to accommodate transient query peaks;
1.粗（「アンバランス」）ノード間の負荷の分布、インフラストラクチャは、クエリの数を増加するために、過渡クエリピークを収容するために拡張することを可能にします。
2. Mitigation of non-distributed denial-of-service attacks by localising damage to single Anycast Nodes;
単一エニーキャストノードへのダメージをローカライズすることにより非分散型サービス拒否攻撃の2軽減。
3. Constraint of distributed denial-of-service attacks or flash crowds to local regions around Anycast Nodes. Anycast distribution of a service provides the opportunity for traffic to be handled closer to its source, perhaps using high-performance peering links rather than oversubscribed, paid transit circuits;
エニーキャストノードの周りの局所的領域に分散サービス拒否攻撃やフラッシュ群衆の3制約。サービスのエニーキャスト分布は、トラフィックは、おそらくかなりのオーバーサブスクライブより高性能なピアリングのリンクを使用して、そのソースに近い処理されるための機会を提供し、通過回路を支払いました。
4. To provide additional information to help identify the location of traffic sources in the case of attack (or query) traffic which incorporates spoofed source addresses. This information is derived from the property of anycast service distribution that the selection of the Anycast Node used to service a particular query may be related to the topological source of the request.
4.偽装された送信元アドレスを組み込んで攻撃（またはクエリ）トラフィックの場合、トラフィックソースの場所を識別するのに役立つ追加情報を提供します。この情報は、エニーキャストノードの選択は、特定のクエリ要求のトポロジカルソースに関連することができるサービスを提供するために使用されるエニーキャストサービスの分布の性質に由来します。
5. Improvement of query response time, by reducing the network distance between client and server with the provision of a local Anycast Node. The extent to which query response time is improved depends on the way that nodes are selected for the clients by the routing system. Topological nearness within the routing system does not, in general, correlate to round-trip performance across a network; in some cases, response times may see no reduction, and may increase.
地元のエニーキャストノードの提供と、クライアントとサーバー間のネットワーク距離を減らすことによって、クエリの応答時間の5改善、。クエリ応答時間が改善される程度は、ノードはルーティングシステムによってクライアントのために選択される方法に依存します。ルーティングシステム内のトポロジー近さは、一般的には、ネットワークを介して往復性能に相関しません。いくつかのケースでは、応答時間は何の削減を見ていないこと、及び増加する可能性があります。
6. To reduce a list of servers to a single, distributed address. For example, a large number of authoritative nameservers for a zone may be deployed using a small set of anycast Service Addresses; this approach can increase the accessibility of zone data in the DNS without increasing the size of a referral response from a nameserver authoritative for the parent zone.
6.シングル、分散アドレスにサーバのリストを減らすために。例えば、ゾーンの権限ネームサーバの多数のエニーキャストサービスアドレスの小さな集合を使用して展開することができます。このアプローチは、親ゾーンに対して権限ネームサーバからの紹介応答のサイズを大きくすることなく、DNSでゾーンデータのアクセシビリティを向上させることができます。
When a service is anycast between two or more nodes, the routing system makes the node selection decision on behalf of a client. Since it is usually a requirement that a single client-server interaction is carried out between a client and the same server node for the duration of the transaction, it follows that the routing system's node selection decision ought to be stable for substantially longer than the expected transaction time, if the service is to be provided reliably.
サービスは2つの以上のノード間のエニーキャストである場合には、ルーティングシステムは、クライアントの代わりにノード選択決定を行います。それは、単一のクライアント・サーバ間の対話は、クライアントとの取引の期間中、同じサーバーノードとの間で行われる要件が通常であるので、ルーティングシステムのノード選択の決定は予想よりも長く、実質的に安定であるべきということになりますトランザクション時間、サービスが確実に提供される場合。
Some services have very short transaction times, and may even be carried out using a single packet request and a single packet reply (e.g., DNS transactions over UDP transport). Other services involve far longer-lived transactions (e.g., bulk file downloads and audio-visual media streaming).
一部のサービスは非常に短いトランザクション時間を持ち、さらには単一のパケット要求と単一のパケット応答を用いて行うことができる（例えば、UDPトランスポート上のDNSトランザクション）。その他のサービスにははるかに長い寿命のトランザクション（例えば、バルクファイルのダウンロードおよびオーディオビジュアルメディアストリーミング）を伴います。
Services may be anycast within very predictable routing systems, which can remain stable for long periods of time (e.g., anycast within a well-managed and topologically-simple IGP, where node selection changes only occur as a response to node failures). Other deployments have far less predictable characteristics (see Section 4.4.7).
サービスは、長期間にわたって安定したままであることができる非常に予測可能なルーティングシステム内エニーキャストであってもよい（例えば、ノード選択の変更のみ障害ノードに対する応答として起こる、よく管理され、トポロジー的に、単純なIGP、内エニーキャスト）。その他の展開がはるかに予測しにくい特性（4.4.7項を参照）を持っています。
The stability of the routing system, together with the transaction time of the service, should be carefully compared when deciding whether a service is suitable for distribution using anycast. In some cases, for new protocols, it may be practical to split large transactions into an initialisation phase that is handled by anycast servers, and a sustained phase that is provided by non-anycast servers, perhaps chosen during the initialisation phase.
サービスは、エニーキャストを使用して配布するのに適しているかどうかを決定する際に一緒にサービスの取引時間でルーティングシステムの安定性は、慎重に比較されるべきです。いくつかのケースでは、新しいプロトコルのためには、エニーキャストサーバによって処理される初期化段階、おそらく初期化フェーズ中に選択された非エニーキャストサーバ、によって提供される持続相に大きなトランザクションを分割するために実用的であってもよいです。
This document deliberately avoids prescribing rules as to which protocols or services are suitable for distribution by anycast; to attempt to do so would be presumptuous.
プロトコルまたはサービスがエニーキャストによって配布するのに適しているためにどのようにこの文書では、意図的処方ルールを回避します。おこがましいだろう、そうしようとします。
Operators should be aware that, especially for long running flows, there are potential failure modes using anycast that are more complex than a simple 'destination unreachable' failure using unicast.
オペレータは、特に長時間実行フローのために、ユニキャストを使用して、簡単な「宛先到達不能」の失敗よりも複雑ですエニーキャストを使用して、潜在的な故障モードがある、ということに注意する必要があります。
Decisions as to where Anycast Nodes should be placed will depend to a large extent on the goals of the service distribution. For example:
エニーキャストノードが置かれるべき場所についての決定は、サービス配信の目標に大きく依存するであろう。例えば：
o A DNS recursive resolver service might be distributed within an ISP's network, one Anycast Node per site. o A root DNS server service might be distributed throughout the Internet; Anycast Nodes could be located in regions with poor external connectivity to ensure that the DNS functions adequately within the region during times of external network failure. o An FTP mirror service might include local nodes located at exchange points, so that ISPs connected to that exchange point could download bulk data more cheaply than if they had to use expensive transit circuits.
O DNSの再帰リゾルバサービスは、サイトごとに1つのエニーキャストノード、ISPのネットワーク内に分散される可能性があります。 OルートDNSサーバーサービスは、インターネット全体に分散されることがあります。エニーキャストノードが外部ネットワークに障害が発生した時間帯に十分領域内のそのDNS機能を確保するために貧しい外部接続を有する領域内に配置することができます。その交換ポイントに接続されているISPは、彼らは高価なトランジット回線を使用していた場合よりも、より安く大量のデータをダウンロードできるように、O FTPミラーサービスは、交換ポイントであるローカルノードが含まれる場合があります。
In general, node placement decisions should be made with consideration of likely traffic requirements, the potential for flash crowds or denial-of-service traffic, the stability of the local routing system, and the failure modes with respect to node failure or local routing system failure.
一般的には、ノード配置の決定は、可能性の高いトラフィック要件を考慮して、ノードの障害またはローカルルーティングシステムに関してフラッシュ群衆やサービス拒否トラフィック、ローカルルーティングシステムの安定性、および故障モードの可能性をなされるべきです失敗。
There are several common motivations for the distribution of a Service Address within the scope of an IGP:
IGPの範囲内でサービスのアドレスを配布するためのいくつかの一般的な動機があります。
1. to improve service response times by hosting a service close to other users of the network;
ネットワークのほかのユーザーに近いサービスをホストすることにより、サービスの応答時間を改善するための1。
2. to improve service reliability by providing automatic fail-over to backup nodes; and
自動フェイルオーバーバックアップ・ノードに提供することによって、サービスの信頼性を向上させる2。そして
3. to keep service traffic local in order to avoid congesting wide-area links.
3.渋滞広域リンクを避けるために、ローカルサービスのトラフィックを維持します。
In each case, the decisions as to where and how services are provisioned can be made by network engineers without requiring such operational complexities as regional variances in the configuration of client computers, or deliberate DNS incoherence (causing DNS queries to yield different answers depending on where the queries originate).
それぞれのケースで、どこで、どのようなサービスがプロビジョニングされているに関する決定は、場所に応じて異なった答えを得るために、DNSクエリを起こし、クライアントコンピュータの設定、あるいは意図的なDNSの矛盾（地域分散などの運用の複雑さを必要とせずにネットワークエンジニアにより作製することができますクエリが）始まります。
When a service is anycast within an IGP, the routing system is typically under the control of the same organisation that is providing the service, and hence the relationship between service transaction characteristics and network stability are likely to be well-understood. This technique is consequently applicable to a larger number of applications than Internet-wide anycast service distribution (see Section 4.1).
サービスは、IGP内エニーキャストである場合、ルーティングシステムは、サービスを提供している同じ組織の制御下に、典型的に、ひいてはサービストランザクション特性とネットワークの安定性との関係は十分に理解されやすいです。この技術は、インターネット全体のエニーキャストサービスの分布よりもアプリケーションの多数の結果として適用可能である（4.1節を参照）。
An IGP will generally have no inherent restriction on the length of prefix that can be introduced to it. In this case, there is no need to construct a covering prefix for particular Service Addresses; host routes corresponding to the Service Address can instead be introduced to the routing system. See Section 4.4.2 for more discussion of the requirement for a covering prefix.
IGPは、一般的に、それに導入することができるプレフィックスの長さには固有の制限もありません。この場合、特定のサービス・アドレス用カバー接頭辞を構築する必要はありません。サービスアドレスに対応するホストルートではなく、ルーティングシステムに導入することができます。カバープレフィックスのための要件のより多くの議論については、セクション4.4.2を参照してください。
IGPs often feature little or no aggregation of routes, partly due to algorithmic complexities in supporting aggregation. There is little motivation for aggregation in many networks' IGPs in many cases, since the amount of routing information carried in the IGP is small enough that scaling concerns in routers do not arise. For discussion of aggregation risks in other routing systems, see Section 4.4.8.
IGPは、多くの場合、部分的に集約をサポートするアルゴリズムの複雑さに、ルートのほとんど、あるいは全く凝集を備えています。 IGPで運ばルーティング情報の量は、ルータでのスケーリングの問題が生じないことを十分に小さいため、集約のために少し動機は、多くの場合、多くのネットワークのIGPです。他のルーティングシステムにおける集約リスクの議論については、セクション4.4.8を参照してください。
By reducing the scope of the IGP to just the hosts providing service (together with one or more gateway routers), this technique can be applied to the construction of server clusters. This application is discussed in some detail in [ISC-TN-2004-1].
（一つ以上のゲートウェイ・ルータと一緒に）サービスを提供するだけのホストにIGPの範囲を減少させることにより、この技術は、サーバ・クラスタの構成に適用することができます。このアプリケーションは[ISC-TN-2004-1]でいくらか詳細に考察されています。
Service Addresses may be anycast within the global Internet routing system in order to distribute services across the entire network. The principal differences between this application and the IGP-scope distribution discussed in Section 4.3.1 are that:
サービスアドレスは、ネットワーク全体のサービスを分配するために、グローバルなインターネットルーティングシステムの中にエニーキャストすることができます。本出願およびセクション4.3.1で説明したIGP-範囲分布との主な違いは、以下のとおりです。
2. the routing protocol concerned (BGP), and commonly-accepted practices in its deployment, impose some additional constraints (see Section 4.4).
2.ルーティング当該プロトコル（BGP）、及びその展開で一般的に受け入れられた慣行は、いくつかの追加の制約（セクション4.4を参照）課します。
When a routing system is provided with reachability information for a Service Address from an individual node, packets addressed to that Service Address will start to arrive at the node. Since it is essential for the node to be ready to accept requests before they start to arrive, a coupling between the routing information and the availability of the service at a particular node is desirable.
ルーティングシステムは、個々のノードのサービスアドレスの到達可能性情報が提供される場合、パケットがノードに到着し始めるというサービスアドレス宛て。ノードは、それらが到着し始める前に、要求を受け入れる準備ができてすることが不可欠であるため、特定のノードのルーティング情報とサービスの可用性との間の結合が望ましいです。
Where a routing advertisement from a node corresponds to a single Service Address, this coupling might be such that availability of the service triggers the route advertisement, and non-availability of the service triggers a route withdrawal. This can be achieved using routing protocol implementations on the same server. These implementations provide the service being distributed and are configured to advertise and withdraw the route advertisement in conjunction with the availability (and health) of the software on the host that processes service requests. An example of such an arrangement for a DNS service is included in [ISC-TN-2004-1].
ノードからのルーティング広告は、単一のサービスアドレスに対応する場合、この結合は、サービスの可用性は経路広告をトリガし、及びサービスの非可用性は、ルート離脱をトリガするようかもしれません。これは、同じサーバー上のルーティングプロトコルの実装を使用して達成することができます。これらの実装は、配布されたサービスを提供し、宣伝し、サービス要求を処理し、ホスト上のソフトウェアの利用可能性（と健康）と連携して、ルートの広告を撤回するように構成されています。 DNSサービスのような構成の例は[ISC-TN-2004-1]に含まれています。
Where a routing advertisement from a node corresponds to two or more Service Addresses, it may not be appropriate to trigger a route withdrawal due to the non-availability of a single service. Another approach in the case where the service is down at one Anycast Node is to route requests to a different Anycast Node where the service is working normally. This approach is discussed in Section 4.8.
ノードからのルーティングアドバタイズメントは、2つの以上のサービスアドレスに対応し、原因単一のサービスの非可用性にルート離脱を誘発することが適切ではないかもしれません。サービスがダウンして1エニーキャストノードである場合には別のアプローチは、サービスが正常に動作している別のエニーキャストノードにリクエストをルーティングです。このアプローチは、セクション4.8で説明されています。
Rapid advertisement/withdrawal oscillations can cause operational problems, and nodes should be configured such that rapid oscillations are avoided (e.g., by implementing a minimum delay following a withdrawal before the service can be re-advertised). See Section 4.4.4 for a discussion of route oscillations in BGP.
急速広告/離脱振動は、操作上の問題を引き起こす可能性があり、ノードが（再アドバタイズすることができ、例えば、サービスの前に撤退を次の最小遅延を実装することにより）迅速な振動が回避されるように構成されるべきです。 BGPルート振動の議論については、セクション4.4.4を参照してください。
In some routing systems (e.g., the BGP-based routing system of the global Internet), it is not possible, in general, to propagate a host route with confidence that the route will propagate throughout the network. This is a consequence of operational policy, and not a protocol restriction.
いくつかのルーティングシステムでは（例えば、グローバルインターネットのBGPベースのルーティングシステム）は、ルートがネットワーク全体に伝播することに自信を持ってホストルートを伝搬するために、一般的に、不可能です。これは、運用ポリシーの結果ではなく、プロトコルの制限です。
In such cases it is necessary to propagate a route that covers the Service Address, and that has a sufficiently short prefix that it will not be discarded by commonly-deployed import policies. For IPv4 Service Addresses, this is often a 24-bit prefix, but there are other well-documented examples of IPv4 import polices that filter on Regional Internet Registry (RIR) allocation boundaries, and hence some experimentation may be prudent. Corresponding import policies for IPv6 prefixes also exist. See Section 4.5 for more discussion of IPv6 Service Addresses and corresponding anycast routes.
このような場合には、サービスのアドレスをカバーしてルートを伝播する必要があり、それはそれは一般的に展開され、インポートポリシーによって破棄されないことを十分に短いプレフィックスを持っています。 IPv4のサービス・アドレスの場合、これは多くの場合、24ビットの接頭語であるが、地域インターネットレジストリ（RIR）割当の境界上のフィルタ、したがって、いくつかの実験が賢明であり得るIPv4のインポートポリシーの他の十分に立証例があります。 IPv6プレフィックスのための対応輸入政策も存在します。 IPv6のサービスアドレスと対応するエニーキャストルートのより多くの議論については、セクション4.5を参照してください。
The propagation of a single route per service has some associated scaling issues, which are discussed in Section 4.4.8.
サービスごとに単一経路の伝播は、セクション4.4.8に記載されているいくつかの関連したスケーリングの問題を有しています。
Where multiple Service Addresses are covered by the same covering route, there is no longer a tight coupling between the advertisement of that route and the individual services associated with the covered host routes. The resulting impact on signalling availability of individual services is discussed in Section 4.4.1 and Section 4.8.
複数のサービスのアドレスが同じ被覆ルートで覆われている場合は、そのルートの広告や屋根ホストルートに関連する個々のサービス間の密結合は、もはやありません。個々のサービスの利用可能性をシグナリングに得られた影響は、セクション4.4.1及びセクション4.8で議論されています。
Some routing systems support equal-cost paths to the same destination. Where multiple, equal-cost paths exist and lead to different Anycast Nodes, there is a risk that different request packets associated with a single transaction might be delivered to more than one node. Services provided over TCP [RFC0793] necessarily involve transactions with multiple request packets, due to the TCP setup handshake.
いくつかのルーティングシステムは、同じ宛先への等コスト・パスをサポートします。複数の等コスト・パスが存在し、異なるエニーキャストノードにつながる場合、単一のトランザクションに関連付けられた異なる要求パケットが複数のノードに配信されるかもしれないという危険性があります。 TCP [RFC0793]の上に提供されるサービスは、必ずしもTCPの設定ハンドシェイクによる複数の要求パケットとの取引を伴います。
For services that are distributed across the global Internet using BGP, equal-cost paths are normally not a consideration: BGP's exit selection algorithm usually selects a single, consistent exit for a single destination regardless of whether multiple candidate paths exist. Implementations of BGP exist that support multi-path exit selection, however.
BGPを使用して、グローバルなインターネットに分散されているサービスのために、等コスト・パスは通常考慮されない：BGPの出口選択アルゴリズムは、普通にかかわらず、複数の候補経路が存在するかどうかの単一の宛先のための単一の、一貫性の出口を選択します。 BGPの実装は、しかし、その支持マルチパス出口選択存在します。
Equal-cost paths are commonly supported in IGPs. Multi-node selection for a single transaction can be avoided in most cases by careful consideration of IGP link metrics, or by applying equal-cost multi-path (ECMP) selection algorithms, which cause a single node to be selected for a single multi-packet transaction. For an example of the use of hash-based ECMP selection in anycast service distribution, see [ISC-TN-2004-1].
等コストパスは一般のIGPでサポートされています。単一のトランザクションのためのマルチノードの選択はIGPリンクメトリックを慎重に検討することによって、又は単一のノードが単一のマルチために選択させる等コストマルチパス（ECMP）選択アルゴリズムを適用することによって、ほとんどの場合に回避することができますパケットトランザクション。エニーキャストサービス分布のハッシュベースのECMP選択の使用例については、[ISC-TN-2004-1を参照してください。
Other ECMP selection algorithms are commonly available, including those in which packets from the same flow are not guaranteed to be routed towards the same destination. ECMP algorithms that select a route on a per-packet basis rather than per-flow are commonly referred to as performing "Per Packet Load Balancing" (PPLB).
他のECMP選択アルゴリズムは、同一のフローからのパケットが同じ宛先に向けてルーティングされることが保証されていないものも含め、一般に入手可能です。パケット単位ではなく、フロー単位の経路を選択ECMPアルゴリズムは、一般に（PPLB）「パケットのロードバランシング当たり」を行うと呼ばれます。
With respect to anycast service distribution, some uses of PPLB may cause different packets from a single multi-packet transaction sent by a client to be delivered to different Anycast Nodes, effectively making the anycast service unavailable. Whether this affects specific anycast services will depend on how and where Anycast Nodes are deployed within the routing system, and on where the PPLB is being performed:
エニーキャストサービス配信に関しては、PPLBの一部の使用は、クライアントから送信された単一のマルチパケットトランザクションは異なるパケットが効果的にエニーキャストサービスが利用できなくなって、別のエニーキャストノードに配信される場合があります。これは、特定のエニーキャストサービスに影響するかどうかは、ルーティングシステム内に配備されている方法と場所エニーキャストノードに依存し、PPLBが実行されている場所になります：
1. PPLB across multiple, parallel links between the same pair of routers should cause no node selection problems;
ルータの同一の対の間の複数の平行リンクを横切る1 PPLBにはノード選択の問題を引き起こしてはなりません。
2. PPLB across diverse paths within a single autonomous system (AS), where the paths converge to a single exit as they leave the AS, should cause no node selection problems;
彼らはASを残すようにパスが単一の出口に収束する単一の自律システム（AS）内の多様な経路を横切る2 PPLBは、どのノード選択の問題を引き起こしてはなりません。
3. PPLB across links to different neighbour ASes, where the neighbour ASes have selected different nodes for a particular anycast destination will, in general, cause request packets to be distributed across multiple Anycast Nodes. This will have the effect that the anycast service is unavailable to clients downstream of the router performing PPLB.
ネイバーのASが特定のエニーキャスト先の異なるノードは、一般的に、原因要求パケットが複数のエニーキャストノードに分散されるようになります選択した異なるネイバーのASへのリンクを横切っ3. PPLB。これは、エニーキャストサービスがPPLBを実行するルータの下流の顧客に利用できない効果があります。
The uses of PPLB that have the potential to interact badly with anycast service distribution can also cause persistent packet reordering. A network path that persistently reorders segments will degrade the performance of traffic carried by TCP [Allman2000]. TCP, according to several documented measurements, accounts for the bulk of traffic carried on the Internet ([McCreary2000], [Fomenkov2004]). Consequently, in many cases, it is reasonable to consider networks making such use of PPLB to be pathological.
エニーキャストサービス配信とひどく対話する可能性を秘めているPPLBの用途も永続的なパケットの並べ替えを引き起こす可能性があります。永続セグメントを並べ替えネットワークパスがTCP [Allman2000]によって運ばれるトラフィックの性能を劣化させるであろう。 TCPは、いくつかの文書化の測定によれば、（[Fomenkov2004]、[McCreary2000]）インターネット上に担持されたトラフィックの大部分を占めます。その結果、多くの場合、病的なことPPLBのように利用してネットワークを考慮することが妥当です。
Frequent advertisements and withdrawals of individual prefixes in BGP are known as flaps. Rapid flapping can lead to CPU exhaustion on routers quite remote from the source of the instability, and for this reason rapid route oscillations are frequently "dampened", as described in [RFC2439].
BGPで頻繁に広告や個々の接頭辞の引き出しは、フラップとして知られています。急速なフラッピングは、不安定性の源から非常に遠隔ルータのCPUの消耗につながる可能性があり、この理由のため、迅速なルート振動が頻繁に[RFC2439]に記載されているように、「減衰」。
A dampened path will be suppressed by routers for an interval that increases according to the frequency of the observed oscillation; a suppressed path will not propagate. Hence, a single router can prevent the propagation of a flapping prefix to the rest of an autonomous system, affording other routers in the network protection from the instability.
減衰経路が観察発振の周波数に応じて増加する間隔でルータによって抑制されます。抑制パスが反映されません。したがって、単一のルータは不安定からのネットワークの保護に他のルータを与える、自律システムの残りの部分にフラッピングプレフィックスの伝播を防ぐことができます。
Some implementations of flap dampening penalise oscillating advertisements based on the observed AS_PATH, and not on Network Layer Reachability Information (NLRI; see [RFC4271]). For this reason, network instability that leads to route flapping from a single Anycast Node, will not generally cause advertisements from other nodes (which have different AS_PATH attributes) to be dampened by these implementations.
（[RFC4271]を参照NLRI）フラップのいくつかの実装は、ネットワーク層到達可能性情報で観察AS_PATHに基づいて振動広告を不利としない湿。このため、単一エニーキャストノードからフラッピングルートにつながるネットワークが不安定のため、一般的に（別のAS_PATH属性を持っている）他のノードからの広告は、これらの実装によって減衰されることはありません。
To limit the opportunity of such implementations to penalise advertisements originating from different Anycast Nodes in response to oscillations from just a single node, care should be taken to arrange that the AS_PATH attributes on routes from different nodes are as diverse as possible. For example, Anycast Nodes should use the same origin AS for their advertisements, but might have different upstream ASes.
ただ1つのノードからの振動に応答して異なるエニーキャストノードから発信広告を処罰するような実装の機会を制限するために、注意がAS_PATHが異なるノードからのルートの属性ことを配置するものと解釈されるべきであるできるだけ多様です。例えば、エニーキャストノードは、その広告の場合と同じ起源を使用する必要がありますが、異なる上流のASを持っているかもしれません。
Where different implementations of flap dampening are prevalent, individual nodes' instability may result in stable nodes becoming unavailable. In mitigation, the following measures may be useful:
フラップ減衰の異なる実装が普及している場合、個々のノードの不安定性は、利用できなくなって安定したノードをもたらすことができます。緩和では、次のような対策が役に立つことがあります。
1. Judicious deployment of Local Nodes in combination with especially stable Global Nodes (with high inter-AS path splay, redundant hardware, power, etc.) may help limit oscillation problems to the Local Nodes' limited regions of influence;
（高インターASパススプレイ、冗長ハードウェア、電力、等で）、特に安定したグローバル・ノードと組み合わせたローカルノードの1賢明展開影響のローカルノードの限られた領域への振動の問題を制限するに役立ち得ます。
2. Aggressive flap-dampening of the service prefix close to the origin (e.g., within an Anycast Node, or in adjacent ASes of each Anycast Node) may also help reduce the opportunity of remote ASes to see oscillations at all.
2.（例えば、エニーキャストノード内、または各エニーキャストノードの隣接のASにおける）原点に近いサービスプレフィックスの積極的なフラップ減衰はまた、すべての振動を見るために、リモートのASの機会を減らすことができます。
Reverse Path Forwarding (RPF) checks, first described in [RFC2267], are commonly deployed as part of ingress interface packet filters on routers in the Internet in order to deny packets whose source addresses are spoofed (see also RFC 2827 [RFC2827]). Deployed implementations of RPF make several modes of operation available (e.g., "loose" and "strict").
最初の[RFC2267]に記載の逆方向パス転送（RPF）チェックは、一般にソースアドレススプーフィングされたパケットを拒否するためにインターネットにルータの入力インターフェイスパケットフィルタの一部として配備されている（また、RFC 2827 [RFC2827]を参照）。 RPFの展開の実装が利用可能ないくつかの動作モードを行う（例えば、「ルーズ」および「厳密」）。
Some modes of RPF can cause non-spoofed packets to be denied when they originate from multi-homed sites, since selected paths might legitimately not correspond with the ingress interface of non-spoofed packets from the multi-homed site. This issue is discussed in [RFC3704].
RPFのいくつかのモードが選択されたパスが合法的にマルチホームのサイトから非偽装されたパケットの入力インターフェイスに対応していないかもしれないので、彼らは、マルチホームのサイトから発信時に拒否される非偽装されたパケットを引き起こす可能性があります。この問題は、[RFC3704]で議論されています。
A collection of Anycast Nodes deployed across the Internet is largely indistinguishable from a distributed, multi-homed site to the routing system, and hence this risk also exists for Anycast Nodes, even if individual nodes are not multi-homed. Care should be taken to ensure that each Anycast Node is treated as a multi-homed network, and that the corresponding recommendations in [RFC3704] with respect to RPF checks are heeded.
インターネット上に展開エニーキャストノードの集合は、ルーティングシステムに分散、マルチホームサイトから大きく区別不可能であるため、このリスクはまた、個々のノードがマルチホームではない場合でも、エニーキャストノードが存在します。ケアは、各エニーキャストノードがマルチホームネットワークとして扱われ、RPFチェックに対して[RFC3704]に対応する推奨事項が留意されることであることを保証するために注意しなければなりません。
In the context of anycast service distribution across the global Internet, Global Nodes are those that are capable of providing service to clients anywhere in the network; reachability information for the service is propagated globally, without restriction, by advertising the routes covering the Service Addresses for global transit to one or more providers.
グローバルなインターネットを介しエニーキャストサービス配信のコンテキストでは、グローバル・ノードは、ネットワーク内の任意の場所にあるクライアントにサービスを提供することができるものです。サービスの到達可能性情報は、1つのまたは複数のプロバイダへのグローバルな輸送のためのサービスのアドレスをカバーするルートを広告することで、制限なく、世界的に伝播されます。
More than one Global Node can exist for a single service (and indeed this is often the case, for reasons of redundancy and load-sharing).
複数のグローバル・ノードは、単一のサービスのために存在することができる（実際、これは、冗長性と負荷分散の理由のため、多くの場合そうです）。
In contrast, it is sometimes desirable to deploy an Anycast Node that only provides services to a local catchment of autonomous systems, and that is deliberately not available to the entire Internet; such nodes are referred to in this document as Local Nodes. An example of circumstances in which a Local Node may be appropriate are nodes designed to serve a region with rich internal connectivity but unreliable, congested, or expensive access to the rest of the Internet.
対照的に、それだけで自律システムのローカル流域にサービスを提供するエニーキャストノードを展開することが望ましい場合があり、それは意図的にインターネット全体に使用できません。このようなノードは、ローカル・ノードとして、この文書で言及されています。ローカル・ノードが適切かもしれないような状況の例は、豊富な内部接続が、インターネットの残りの部分に、信頼できない混雑し、高価なアクセスと地域にサービスを提供するために設計されたノードです。
Local Nodes advertise covering routes for Service Addresses in such a way that their propagation is restricted. This might be done using well-known community string attributes such as NO_EXPORT [RFC1997] or NOPEER [RFC3765], or by arranging with peers to apply a conventional
ローカル・ノードは、その伝播が制限されるようにサービスのアドレスのためのルートを覆って宣伝します。これは、このようなNO_EXPORT [RFC1997]またはNOPEER [RFC3765]などのよく知られたコミュニティストリングの属性を使用して、または従来のを適用するために仲間と配置することによって行われるかもしれません
"peering" import policy instead of a "transit" import policy, or some suitable combination of measures.
代わりに「トランジット」の輸入政策、あるいは対策のいくつかの適切な組み合わせの輸入政策を「ピアリング」。
Advertising reachability to Service Addresses from Local Nodes should ideally be done using a routing policy that requires presence of explicit attributes for propagation, rather than relying on implicit (default) policy. Inadvertent propagation of a route beyond its intended horizon can result in capacity problems for Local Nodes, which might degrade service performance network-wide.
ローカル・ノードからサービスアドレスへの広告到達可能性は、理想的ではなく、暗黙的な（デフォルト）政策に頼るよりも、繁殖のために明示的な属性の存在を必要とするルーティングポリシーを使用して行われるべきです。その意図した地平線を越えてルートの不注意による伝播は、サービス・パフォーマンス・ネットワーク全体を低下させる可能性がある、ローカルノードのキャパシティの問題が発生することができます。
When anycast services are deployed across networks operated by others, their reachability is dependent on routing policies and topology changes (planned and unplanned), which are unpredictable and sometimes difficult to identify. Since the routing system may include networks operated by multiple, unrelated organisations, the possibility of unforeseen interactions resulting from the combinations of unrelated changes also exists.
エニーキャストサービスが他の人によって操作さネットワークにわたって展開されている場合、それらの到達可能性は予測できないと識別することが困難な場合があるルーティングポリシーおよびトポロジの変更（計画および計画外）に依存します。ルーティングシステムは、複数の、無関係の組織によって運営ネットワークを含むことができるので、無関係な変更の組み合わせから生じる不測の相互作用の可能性も存在します。
The stability and predictability of such a routing system should be taken into consideration when assessing the suitability of anycast as a distribution strategy for particular services and protocols (see also Section 4.1).
特定のサービスおよびプロトコルの配布戦略としてエニーキャストの適合性を評価する場合、そのようなルーティングシステムの安定性と予測可能性を考慮すべきである（セクション4.1を参照）。
By way of mitigation, routing policies used by Anycast Nodes across such routing systems should be conservative, individual nodes' internal and external/connecting infrastructure should be scaled to support loads far in excess of the average, and the service should be monitored proactively from many points in order to avoid unpleasant surprises (see Section 5.1).
緩和の方法により、そのようなルーティングシステム間エニーキャストノードによって使用されるルーティングポリシーは保守的でなければならない/、個々のノードの内部と外部のインフラストラクチャが遠い平均値を超える荷重を支持するようにスケーリングされなければならない、及びサービスは、多くから積極的に監視しなければならない接続不愉快な驚きを避けるために、ポイント（5.1節を参照してください）。
The propagation of a single route for each anycast service does not scale well for routing systems in which the load of routing information that must be carried is a concern, and where there are potentially many services to distribute. For example, an autonomous system that provides services to the Internet with N Service Addresses covered by a single exported route would need to advertise (N+1) routes, if each of those services were to be distributed using anycast.
各エニーキャストサービスのための単一の経路の伝播が実行されなければならないルーティング情報の負荷が懸念されているシステムをルーティングするためにうまくスケール、および潜在的に配布する多くのサービスがある場合はありません。これらのサービスの各々は、エニーキャストを使用して配信されるならば、例えば、単一のエクスポート経路によって覆われたN個のサービスアドレスでインターネットにサービスを提供する自律システムは、（N + 1）のルートをアドバタイズする必要があります。
The common practice of applying minimum prefix-length filters in import policies on the Internet (see Section 4.4.2) means that for a route covering a Service Address to be usefully propagated the prefix length must be substantially less than that required to advertise just the host route. Widespread advertisement of short prefixes for individual services, hence, also has a negative impact on address conservation.
（4.4.2項を参照）は、インターネット上のインポートポリシーで最小プレフィックス長のフィルタを適用する一般的な方法は、有効プレフィックス長を伝播するサービスのアドレスをカバーするルートのためだけに広告を掲載するために必要とされるよりも実質的に小さくなければならないことを意味しますルートをホストします。個々のサービスのための短いプレフィックスの広範な広告は、したがって、また、アドレスの保全に悪影響を及ぼします。
Both of these issues can be mitigated to some extent by the use of a single covering prefix to accommodate multiple Service Addresses, as described in Section 4.8. This implies a de-coupling of the route advertisement from individual service availability (see Section 4.4.1), however, with attendant risks to the stability of the service as a whole (see Section 4.7).
セクション4.8で説明したように、これらの問題の両方が、複数のサービスアドレスに対応するために、単一の被覆接頭辞を使用することによってある程度緩和することができます。これは、全体として、サービスの安定性に付随するリスク（4.7節を参照）、しかし、（セクション4.4.1を参照）は、個々のサービスの可用性からの経路広告の脱カップリングを意味しています。
In general, the scaling problems described here prevent anycast from being a useful, general approach for service distribution on the global Internet. It remains, however, a useful technique for distributing a limited number of Internet-critical services, as well as in smaller networks where the aggregation concerns discussed here do not apply.
一般的には、ここで説明したスケーリングの問題は、グローバルなインターネット上のサービス配信のための便利な、一般的なアプローチであることから、エニーキャストを防ぎます。それは、しかし、ここで議論集約懸念が適用されない小規模なネットワークでだけでなく、インターネットクリティカルなサービスの限られた数を分配するための有用な技術のまま。
Service Addresses should be unique within the routing system that connects all Anycast Nodes to all possible clients of the service. Service Addresses must also be chosen so that corresponding routes will be allowed to propagate within that routing system.
サービスアドレスは、サービスのすべての可能なクライアントにすべてのエニーキャストノードを接続ルーティングシステム内で一意でなければなりません。対応するルートがそのルーティングシステム内で伝播することを許可されるように、サービスアドレスも選択されなければなりません。
For an IPv4-numbered service deployed across the Internet, for example, an address might be chosen from a block where the minimum RIR allocation size is 24 bits, and reachability to that address might be provided by originating the covering 24-bit prefix.
インターネット上に展開IPv4の番号のサービスのために、例えば、アドレスが最小RIR割り当てサイズが24ビットであるブロックから選択するかもしれない、そのアドレスへの到達可能性をカバーする24ビットのプレフィックスを発信することによって提供されてもよいです。
For an IPv4-numbered service deployed within a private network, a locally-unused [RFC1918] address might be chosen, and reachability to that address might be signalled using a (32-bit) host route.
プライベートネットワーク内に展開さのIPv4番号サービスのために、局所的に使用されていない[RFC1918]アドレスが選択される可能性があり、そのアドレスへの到達可能性は、（32ビット）ホストルートを使用してシグナリングされるかもしれません。
For IPv6-numbered services, Anycast Addresses are not scoped differently from unicast addresses. As such, the guidelines for address suitability presented for IPv4 follow for IPv6. Note that historical prohibitions on anycast distribution of services over IPv6 have been removed from the IPv6 addressing specification in [RFC4291].
IPv6の番号のサービスについては、エニーキャストアドレスはユニキャストアドレスとは異なるスコープされていません。そのため、IPv4のために提示アドレスの適合のためのガイドラインは、IPv6のために従ってください。 IPv6を介したサービスのエニーキャスト配信の履歴禁止は[RFC4291]でのIPv6アドレッシング仕様から削除されていることに留意されたいです。
Although some services have been deployed in localised form (such that clients from particular regions are presented with regionally-relevant content), many services have the property that responses to client requests should be consistent, regardless of where the request originates. For a service distributed using anycast, that implies that different Anycast Nodes must operate in a consistent manner and, where that consistent behaviour is based on a data set, the data concerned be synchronised between nodes.
一部のサービスは、（特定の地域からのクライアントが地域関連コンテンツを提示しているように）ローカライズされた形で展開されてきたが、多くのサービスは、クライアントの要求への応答にかかわらず、要求は発生場所の、整合的であるべきである性質を持っています。サービスが異なるエニーキャストノードが一貫した方法で動作しなければならないことを意味エニーキャストを使用し、その一貫性のある動作をデータセットに基づいて、分散のために、当該データは、ノード間で同期すること。
The mechanism by which data is synchronised depends on the nature of the service; examples are zone transfers for authoritative DNS servers and rsync for FTP archives. In general, the synchronisation of data between Anycast Nodes will involve transactions between non-anycast addresses.
データが同期されるメカニズムは、サービスの性質に依存します。例として、権威DNSサーバーとFTPアーカイブのrsyncのためのゾーン転送です。一般的には、エニーキャストノード間のデータの同期は非エニーキャストアドレスとの間の取引に関与します。
Data synchronisation across public networks should be carried out with appropriate authentication and encryption.
公衆ネットワークを介したデータの同期化は、適切な認証と暗号化を行うべきです。
For an anycast deployment whose goals include improved reliability through redundancy, it is important to minimise the opportunity for a single defect to compromise many (or all) nodes, or for the failure of one node to provide a cascading failure that brings down additional successive nodes until the service as a whole is defeated.
その目標冗長性によって信頼性の向上などがエニーキャストの展開のために、多くの（またはすべて）のノードを危うくするための単一の欠陥のために、または追加の連続したノードをダウンさせカスケードの失敗を提供するために、1つのノードの障害のための機会を最小化することが重要です全体としてサービスが敗北するまで。
Co-dependencies are avoided by making each node as autonomous and self-sufficient as possible. The degree to which nodes can survive failure elsewhere depends on the nature of the service being delivered, but for services which accommodate disconnected operation (e.g., the timed propagation of changes between master and slave servers in the DNS) a high degree of autonomy can be achieved.
共同の依存関係は、自律と自己十分可能な限り各ノードを作ることによって回避されます。ノードが他の場所での失敗を生き残ることができる度合いは、配信されるサービスの性質に依存するが、切断操作（例えば、DNSでマスターとスレーブサーバ間の変化のタイミング伝播）を収容するサービスのために高度の自治をすることができ達成。
The possibility of cascading failure due to load can also be reduced by the deployment of both Global and Local Nodes for a single service, since the effective fail-over path of traffic is, in general, from Local Node to Global Node; traffic that might sink one Local Node is unlikely to sink all Local Nodes, except in the most degenerate cases.
負荷による障害をカスケード接続する可能性もあり、一般に、ローカル・ノードからグローバル・ノードへのトラフィックの有効なフェイルオーバーパスので、グローバルおよび単一のサービスのためのローカルノードの両方の配備によって減少させることができます。 1つのローカル・ノードをシンクかもしれないトラフィックは、ほとんどの縮退の場合を除き、すべてのローカル・ノードをシンクすることはほとんどありません。
The chance of cascading failure due to a software defect in an operating system or server can be reduced in many cases by deploying nodes running different implementations of operating system, server software, routing protocol software, etc., such that a defect that appears in a single component does not affect the whole system.
オペレーティング・システムまたはサーバにおけるソフトウェアの欠陥に起因する障害をカスケード接続の機会は、オペレーティング・システム、サーバーソフトウェア、ルーティング・プロトコル・ソフトウェア、等、の異なる実装を実行しているノードを展開することにより、多くの場合に低減することができるように表示された欠陥単一コンポーネントは、システム全体に影響を与えません。
It should be noted that these approaches to increase node autonomy are, to varying degrees, contrary to the practical goals of making a deployed service straightforward to operate. A service that is overly complex is more likely to suffer from operator error than a service that is more straightforward to run. Careful consideration should be given to all of these aspects so that an appropriate balance may be found.
ノードの自律性を高めるためにこれらのアプローチは、様々な程度に、動作するように展開されたサービスは、簡単な作りの実践的な目標に反していることに留意すべきです。過度に複雑であるサービスを実行することがより簡単であるサービスよりも、オペレータエラーに苦しむ可能性が高いです。適切なバランスを見つけることができるように、慎重に検討は、これらの態様の全てに与えられるべきです。
For a service distributed across a routing system where covering prefixes are required to announce reachability to a single Service Address (see Section 4.4.2), special consideration is required in the case where multiple services need to be distributed across a single set of nodes. This results from the requirement to signal availability of individual services to the routing system so that requests for service are not received by nodes that are not able to process them (see Section 4.4.1).
被覆プレフィックスは、単一のサービスアドレスに到達可能性を発表するために必要とされるルーティングシステムに分散サービス（セクション4.4.2を参照）、特別な配慮が複数のサービスノードの単一のセットに分散する必要がある場合に必要とされます。これは、（セクション4.4.1を参照）サービスに対する要求は、それらを処理することができないノードによって受信されないように、ルーティングシステムに個々のサービスの可用性を通知する必要から生じます。
Several approaches are described in the following sections.
いくつかのアプローチは、次のセクションで説明されています。
Each Service Address is chosen such that only one Service Address is covered by each advertised prefix. Advertisement and withdrawal of a single covering prefix can be tightly coupled to the availability of the single associated service.
各サービスのアドレスは、唯一のサービスアドレスは、各広告を出して接頭辞で覆われているように選択されます。シングルカバーリングのプレフィックスの広告や撤退はしっかりと単一関連するサービスの可用性に結合することができます。
This is the most straightforward approach. However, since it makes very poor utilisation of globally-unique addresses, it is only suitable for use for a small number of critical, infrastructural services such as root DNS servers. General Internet-wide deployment of services using this approach will not scale.
これは、最も簡単な方法です。それはグローバルに一意なアドレスの非常に悪い利用になるしかし、それは、このようなルートDNSサーバーなどの重要な、インフラサービスの数が少ないため、使用に適しているだけです。このアプローチを使用して、サービスの一般的なインターネット規模の展開はスケールしません。
Multiple Service Addresses are chosen such that they are covered by a single prefix. Advertisement and withdrawal of the single covering prefix is coupled to the availability of all associated services; if any individual service becomes unavailable, the covering prefix is withdrawn.
複数のサービスのアドレスは、彼らは、単一の接頭語でカバーされるように選択されています。広告とシングルカバーリングプレフィックスの撤退は、すべての関連するサービスの可用性に結合されています。任意の個々のサービスが利用できなくなった場合、被覆プレフィックスが引き出されます。
The coupling between service availability and advertisement of the covering prefix is complicated by the requirement that all Service Addresses must be available -- the announcement needs to be triggered by the presence of all component routes, and not just a single covered route.
被覆プレフィックスのサービスの可用性と広告との間のカップリングは、すべてのサービスのアドレスが利用可能でなければならないという要件によって複雑になる - 発表は、すべてのコンポーネントのルートが存在する、とだけではなく、単一のカバーされた経路によってトリガする必要があります。
The fact that a single malfunctioning service causes all deployed services in a node to be taken off-line may make this approach unsuitable for many applications.
単一故障したサービスは、ノード内のすべてのデプロイされたサービスを引き起こしているという事実は、多くのアプリケーションのために、このアプローチは適さないかもしれオフラインにします。
Multiple Service Addresses are chosen such that they are covered by a single prefix. Advertisement and withdrawal of the single covering prefix is coupled to the availability of any one service. Nodes have interior connectivity, e.g., using tunnels. Host routes for Service Addresses are distributed using an IGP that extends to include routers at all nodes.
複数のサービスのアドレスは、彼らは、単一の接頭語でカバーされるように選択されています。広告とシングルカバーリングプレフィックスの撤退は、いずれかのサービスの可用性に結合されています。ノードは、トンネルを使用して、例えば、内部の接続性を持っています。サービスアドレスのホストルートは、すべてのノードのルータを含むように延びているIGPを使用して分配されます。
In the event that a service is unavailable at one node, but available at other nodes, a request may be routed over the interior network from the receiving node towards some other node for processing.
サービスが一つのノードで利用できないが、他のノードで利用可能である場合には、要求は、処理のためにいくつかの他のノードに向かって受信ノードから内部ネットワークを介してルーティングすることができます。
In the event that some local services in a node are down and the node is disconnected from other nodes, continued advertisement of the covering prefix might cause requests to become black-holed.
ノード内のいくつかのローカルサービスがダウンしていると、ノードは他のノードから切断された場合には、被覆プレフィックスの継続的な広告は、要求がブラックホールになることがあります。
This approach allows reasonable address utilisation of the netblock covered by the announced prefix, at the expense of reduced autonomy of individual nodes; the IGP in which all nodes participate can be viewed as a single point of failure.
このアプローチは、個々のノードの減少自治を犠牲にして、発表された接頭語でカバーネットブロックの合理的なアドレスの利用を可能にします。すべてのノードが参加するIGPは、単一障害点として見ることができます。
From time to time, all clients of deployed services experience problems, and those problems require diagnosis. A service distributed using anycast imposes an additional variable on the diagnostic process over a simple, unicast service -- the particular Anycast Node that is handling a client's request.
随時、展開されたサービスの経験の問題のすべてのクライアント、およびそれらの問題は診断が必要です。クライアントの要求を処理している特定のエニーキャストノード - サービスは、エニーキャストは、単純な、ユニキャストサービスオーバー診断プロセスに追加の変数を課し使用して配布しました。
In some cases, common network-level diagnostic tools such as traceroute may be sufficient to identify the node being used by a client. However, the use of such tools may be beyond the abilities of users at the client side of a transaction, and, in any case, network conditions at the time of the problem may change by the time such tools are exercised.
いくつかの場合において、このようなトレースルートのような一般的なネットワーク・レベルの診断ツールは、クライアントによって使用されているノードを識別するのに十分であり得ます。しかし、そのようなツールの使用は、トランザクションのクライアント側でのユーザーの能力を超えている可能性がある、と、どのような場合には、問題の時点でのネットワークの状態は、このようなツールが行使された時間によって変更されることがあります。
Troubleshooting problems with anycast services is greatly facilitated if mechanisms to determine the identity of a node are designed into the protocol. Examples of such mechanisms include the NSID option in DNS [NSID] and the common inclusion of hostname information in SMTP servers' initial greeting at session initiation [RFC2821].
ノードのアイデンティティを決定するための機構がプロトコルに設計されている場合にエニーキャストサービスのトラブルシューティングの問題は大幅に促進されます。このような機構の例には、DNSにNSIDオプション[NSID]及びセッション開始[RFC2821]でのSMTPサーバの最初の挨拶でホスト名の情報の一般的な包含を含みます。
Provision of such in-band mechanisms for node identification is strongly recommended for services to be distributed using anycast.
サービスは、エニーキャストを使用して配布するためのノード識別のためのこのようなインバンド・メカニズムの提供が強く推奨されます。
Monitoring a service that is distributed is more complex than monitoring a non-distributed service, since the observed accuracy and availability of the service is, in general, different when viewed from clients attached to different parts of the network. When a problem is identified, it is also not always obvious which node served the request, and hence which node is malfunctioning.
ネットワークの異なる部分に接続されたクライアントから見たサービスの観察精度および可用性は、一般的に異なるため、分散されたサービスを監視することは、非分散型サービスを監視するよりも複雑です。問題が特定された場合、ノードが故障しているので、リクエストなどを務めているノードも常に明白ではありません。
It is recommended that distributed services are monitored from probes distributed representatively across the routing system, and, where possible, the identity of the node answering individual requests is recorded along with performance and availability statistics. The RIPE NCC DNSMON service [DNSMON] is an example of such monitoring for the DNS.
分散サービスは、個々の要求に答えるノードのアイデンティティがパフォーマンスと可用性の統計情報と一緒に記録されている可能性ルーティングシステム全体に代表的に分散したプローブ、および、から監視されていることをお勧めします。 RIPE NCC DNSMONサービス[DNSMON]は、DNSのためのそのようなモニタリングの一例です。
Monitoring the routing system (from a variety of places, in the case of routing systems where perspective is relevant) can also provide useful diagnostics for troubleshooting service availability. This can be achieved using dedicated probes, or public route measurement facilities on the Internet such as the RIPE NCC Routing Information Service [RIS] and the University of Oregon Route Views Project [ROUTEVIEWS].
（視点が関連するルーティングシステムの場合には、さまざまな場所から）ルーティングシステムを監視することも、トラブルシューティングサービスの可用性のために有用な診断を提供することができます。これは、RIPE NCCルーティング情報サービス[RIS]とオレゴン大学の経路として、インターネット上の専用のプローブ、またはパブリックルート測定機能を使用して達成することができるプロジェクト[ROUTEVIEWS]ビュー。
Monitoring the health of the component devices in an anycast deployment of a service (hosts, routers, etc.) is straightforward, and can be achieved using the same tools and techniques commonly used to manage other network-connected infrastructure, without the additional complexity involved in monitoring anycast Service Addresses.
サービス（ホスト、ルータ、等）のエニーキャスト配備におけるコンポーネントデバイスの状態を監視することは簡単であり、そして関与する追加の複雑させずに、一般に他のネットワーク接続されたインフラストラクチャを管理するために使用されるのと同じツールおよび技術を使用して達成することができますエニーキャストサービスのアドレスを監視インチ
This document describes mechanisms for deploying services on the Internet that can be used to mitigate vulnerability to attack:
この文書では、攻撃に対する脆弱性を軽減するために使用することができ、インターネット上のサービスを展開するためのメカニズムについて説明します。
1. An Anycast Node can act as a sink for attack traffic originated within its sphere of influence, preventing nodes elsewhere from having to deal with that traffic;
1】エニーキャストノードは、攻撃トラフィックのシンクが、その影響力の球内で発信されたトラフィックに対処することから他の場所にノードを防止するように作用することができます。
2. The task of dealing with attack traffic whose sources are widely distributed is itself distributed across all the nodes that contribute to the service. Since the problem of sorting between legitimate and attack traffic is distributed, this may lead to better scaling properties than a service that is not distributed.
2.ソースが広く分布している攻撃トラフィックを扱うのタスクは、それ自体は、サービスに貢献するすべてのノードに分散されます。正当な攻撃トラフィックの間で並べ替えの問題が配布されているので、これは配布されていないサービスよりも優れたスケーリング特性につながる可能性があります。
The distribution of a service across several (or many) autonomous nodes imposes increased monitoring as well as an increased systems administration burden on the operator of the service, which might reduce the effectiveness of host and router security.
いくつかの（あるいは多くの）自律ノード全体でサービスの分布が増加し、監視だけでなく、ホストとルータのセキュリティの有効性が低下する可能性がありますサービスのオペレータに増加したシステム管理の負担を課しています。
The potential benefit of being able to take compromised servers off-line without compromising the service can only be realised if there are working procedures to do so quickly and reliably.
迅速かつ確実にそうする作業手順がある場合は、サービスを損なうことなく、オフラインで妥協のサーバーを取ることができるという潜在的な利益のみを実現することができます。
It is possible that an unauthorised party might advertise routes corresponding to anycast Service Addresses across a network, and by doing so, capture legitimate request traffic or process requests in a manner that compromises the service (or both). A rogue Anycast Node might be difficult to detect by clients or by the operator of the service.
不正なパーティがネットワークを介してサービスのアドレスをエニーキャストに対応したルートをアドバタイズし、そうすることによって、サービス（あるいはその両方）を危うくする方法で、正当な要求トラフィックやプロセスの要求を取り込む可能性があることも可能です。不正なエニーキャストノードは、クライアントまたはサービスのオペレータによって検出することは難しいかもしれません。
The risk of service hijacking by manipulation of the routing system exists regardless of whether a service is distributed using anycast. However, the fact that legitimate Anycast Nodes are observable in the routing system may make it more difficult to detect rogue nodes.
ルーティングシステムの操作によるサービスハイジャックの危険性にかかわらず、サービスがエニーキャストを使用して分布しているかどうかに存在します。しかし、正当なエニーキャストノードはルーティングシステムで観察可能であるという事実は、それがより困難に不正なノードを検出することができます。
Many protocols that incorporate authentication or integrity protection provide those features in a robust fashion, e.g., using periodic re-authentication within a single session, or integrity protection at either the channel (e.g., [RFC2845], [RFC3207]) or message (e.g., [RFC4033], [RFC2311]) levels. Protocols that are less robust may be more vulnerable to session hijacking. Given the greater opportunity for undetected session hijack with anycast services, the use of robust protocols is recommended for anycast services that require authentication or integrity protection.
チャネル（例えば、[RFC2845]、[RFC3207]）またはメッセージのいずれかで、多くの認証や完全性保護が堅牢な方法でこれらの機能を提供取り入れるプロトコル、例えば、単一セッション内で定期的な再認証を使用して、または完全性保護（たとえば、 、[RFC4033]、[RFC2311]）レベル。あまり堅牢されるプロトコルは、セッションハイジャックを受けやすいかもしれません。エニーキャストサービスと検出されないセッションハイジャックのための大きな機会を与え、堅牢なプロトコルの使用は、認証や完全性保護を必要とエニーキャストサービスのために推奨されます。
The authors gratefully acknowledge the contributions from various participants of the grow working group, and in particular Geoff Huston, Pekka Savola, Danny McPherson, Ben Black, and Alan Barrett.
作者は感謝して、さまざまなグローワーキンググループの参加者、特にジェフ・ヒューストン、ペッカSavola、ダニー・マクファーソン、ベン・ブラック、アラン・バレットからの貢献を認めます。
This work was supported by the US National Science Foundation (research grant SCI-0427144) and DNS-OARC.
この作品は、米国国立科学財団（研究助成金のSCI-0427144）およびDNS-OARCによってサポートされていました。
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC0793]ポステル、J.、 "伝送制御プロトコル"、STD 7、RFC 793、1981年9月。
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
[RFC1918] Rekhter、Y.、モスコウィッツ、R.、Karrenberg、D.、グルート、G.、およびE.リア、 "個人的なインターネットのための配分"、BCP 5、RFC 1918、1996年2月。
[RFC1997] Chandrasekeran, R., Traina, P., and T. Li, "BGP Communities Attribute", RFC 1997, August 1996.
[RFC1997] Chandrasekeran、R.、Trainaの、P.、およびT.李、 "BGPコミュニティ属性"、RFC 1997、1996年8月。
[RFC2439] Villamizar, C., Chandra, R., and R. Govindan, "BGP Route Flap Damping", RFC 2439, November 1998.
[RFC2439] Villamizar、C.、チャンドラ、R.、およびR.ゴヴィンダン、 "BGPルートフラップダンピング"、RFC 2439、1998年11月。
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, May 2000.
[RFC2827]ファーガソン、P.およびD. Senie、 "ネットワーク入力フィルタリング：IP Source Address Spoofingを使うサービス攻撃の敗北拒否"、BCP 38、RFC 2827、2000年5月。
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, March 2004.
[RFC3704]ベイカー、F.およびP. Savola、 "マルチホームネットワークの入力フィルタリング"、BCP 84、RFC 3704、2004年3月。
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC4271] Rekhter、Y.、李、T.、およびS.野兎、 "ボーダーゲートウェイプロトコル4（BGP-4）"、RFC 4271、2006年1月。
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
[RFC4291] HindenとR.とS.デアリング、 "IPバージョン6アドレッシング体系"、RFC 4291、2006年2月。
[Allman2000] Allman, M. and E. Blanton, "On Making TCP More Robust to Packet Reordering", January 2000, <http:// www.icir.org/mallman/papers/tcp-reorder-ccr.ps>.
[Allman2000]オールマン、M.とE.ブラントン、 "パケットの順序変更にTCPはより強固な作ることに"、2000年1月、<のhttp：// www.icir.org/mallman/papers/tcp-reorder-ccr.ps>。
[DNSMON] "RIPE NCC DNS Monitoring Services", <http://dnsmon.ripe.net/>.
[DNSMON] "RIPE NCC DNS監視サービス"、<http://dnsmon.ripe.net/>。
[Fomenkov2004] Fomenkov, M., Keys, K., Moore, D., and k. claffy, "Longitudinal Study of Internet Traffic from 1999- 2003", January 2004, <http://www.caida.org/ outreach/papers/2003/nlanr/nlanr_overview.pdf>.
【Fomenkov2004] Fomenkov、M.、キー、K.、ムーア、D.、及びk。 claffy、 "1999- 2003からのインターネットトラフィックの縦断的研究"、2004年1月、<http://www.caida.org/アウトリーチ/新聞/ 2003 / NLANR / nlanr_overview.pdf>。
[ISC-TN-2003-1] Abley, J., "Hierarchical Anycast for Global Service Distribution", March 2003, <http://www.isc.org/pubs/tn/isc-tn-2003-1.html>.
[ISC-TN-2003-1] Abley、J.、 "グローバル・サービス分配のための階層エニーキャスト"、2003年3月、<http://www.isc.org/pubs/tn/isc-tn-2003-1.html >。
[ISC-TN-2004-1] Abley, J., "A Software Approach to Distributing Requests for DNS Service using GNU Zebra, ISC BIND 9 and FreeBSD", March 2004, <http://www.isc.org/pubs/tn/isc-tn-2004-1.html>.
[ISC-TN-2004-1] Abley、J.、2004年3月の "GNUゼブラ、ISC BIND 9とFreeBSDを使用してDNSサービスのための要求を分散するソフトウェアのアプローチ"、<http://www.isc.org/pubs /tn/isc-tn-2004-1.html>。
[McCreary2000] McCreary, S. and k. claffy, "Trends in Wide Area IP Traffic Patterns: A View from Ames Internet Exchange", September 2000, <http://www.caida.org/ outreach/papers/2000/AIX0005/AIX0005.pdf>.
【McCreary2000] McCreary、S.及びk。 claffy、 "広域IPトラフィックパターンの動向：エイムズインターネット取引所からの眺め"、2000年9月、<http://www.caida.org/アウトリーチ/新聞/ 2000 / AIX0005 / AIX0005.pdf>。
[NSID] Austein, R., "DNS Name Server Identifier Option (NSID)", Work in Progress, June 2006.
[NSID] Austeinと、R.、 "DNSネームサーバ識別子オプション（NSID）"、進歩、2006年6月に作業。
[RFC1546] Partridge, C., Mendez, T., and W. Milliken, "Host Anycasting Service", RFC 1546, November 1993.
[RFC1546]ウズラ、C.、メンデス、T.、およびW.ミリケン、 "ホストエニーキャストサービス"、RFC 1546、1993年11月。
[RFC2267] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", RFC 2267, January 1998.
[RFC2267]ファーガソン、P.およびD. Senie、 "ネットワーク入力フィルタリング：IP Source Address Spoofingを使うサービス妨害Attacksを破り"、RFC 2267、1998年1月。
[RFC2311] Dusse, S., Hoffman, P., Ramsdell, B., Lundblade, L., and L. Repka, "S/MIME Version 2 Message Specification", RFC 2311, March 1998.
[RFC2311] Dusse、S.、ホフマン、P.、Ramsdell、B.、Lundblade、L.、及びL. Repka、 "S / MIMEバージョン2メッセージ仕様"、RFC 2311、1998年3月。
[RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001.
[RFC2821] Klensin、J.、 "簡易メール転送プロトコル"、RFC 2821、2001年4月。
[RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D., and B. Wellington, "Secret Key Transaction Authentication for DNS (TSIG)", RFC 2845, May 2000.
[RFC2845]いるVixie、P.、グドムンソン、O.、イーストレイク、D.、およびB.ウェリントン、 "DNSのための秘密鍵トランザクション認証（TSIG）"、RFC 2845、2000年5月。
[RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over Transport Layer Security", RFC 3207, February 2002.
[RFC3207]ホフマン、P.、 "トランスポート層セキュリティの安全なSMTPのためのSMTPサービス拡張子"、RFC 3207、2002年2月。
[RFC3765] Huston, G., "NOPEER Community for Border Gateway Protocol (BGP) Route Scope Control", RFC 3765, April 2004.
[RFC3765]ヒューストン、G.、 "NOPEERコミュニティボーダーのためのゲートウェイプロトコル（BGP）ルートスコープコントロール"、RFC 3765、2004年4月。
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005.
[RFC4033]アレンズ、R.、Austeinと、R.、ラーソン、M.、マッシー、D.、およびS.ローズ、 "DNSセキュリティ序論と要件"、RFC 4033、2005年3月。
[RIS] "RIPE NCC Routing Information Service (RIS)", <http://ris.ripe.net>.
[RIS] "RIPE NCCルーティング情報サービス（RIS）"、<http://ris.ripe.net>。
[ROUTEVIEWS] "University of Oregon Route Views Project", <http://www.routeviews.org/>.
[ROUTEVIEWS] "オレゴン大学のルートビュープロジェクト"、<http://www.routeviews.org/>。
Authors' Addresses
著者のアドレス
Joe Abley Afilias Canada, Corp. 204 - 4141 Yonge Street Toronto, ON M2P 2A8 Canada
M2P 2A8カナダON 4141ヤングストリートトロント、 - ジョーAbley Afiliasカナダ、（株）204
Phone: +1 416 673 4176 EMail: jabley@ca.afilias.info URI: http://afilias.info/
電話：+1 416 673 4176 Eメール：URI jabley@ca.afilias.info：http://afilias.info/
Kurt Erik Lindqvist Netnod Internet Exchange Bellmansgatan 30 118 47 Stockholm Sweden
クルト・エリックLindqvist、NetnodインターネットエクスチェンジBellmansgatan 30 118 47ストックホルムスウェーデン
EMail: kurtis@kurtis.pp.se URI: http://www.netnod.se/
電子メール：kurtis@kurtis.pp.se URI：http://www.netnod.se/
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2006).
著作権（C）IETFトラスト（2006）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST, AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書およびここに含まれる情報は、上に提供される基礎とCONTRIBUTOR、ORGANIZATION彼/彼女が表すOR（もしあれば）後援が「そのまま」、インターネット学会、IETFトラスト、インターネットエンジニアリングタスクフォース放棄情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されないすべての保証、明示または黙示、。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。