[要約] RFC 4786は、Anycastサービスの運用に関するガイドラインであり、Anycastアドレスの使用方法と運用上の考慮事項を提供しています。このRFCの目的は、Anycastサービスの効果的な運用と管理を支援することです。
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
Anycastサービスの運用
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.
このドキュメントは、インターネットコミュニティのインターネットの最良のプラクティスを指定し、改善のための議論と提案を要求します。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The IETF Trust (2006).
Copyright（c）The IETF Trust（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.
インターネットに展開されているサービスの可用性を高めるために、さまざまな手法が採用されています。このドキュメントでは、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.
このドキュメントは、Anycastを使用して分散サービスを展開または運営するかどうかを検討しているネットワークオペレーターに宛てられています。そうするための最良の現在のプラクティスについて説明していますが、特定のサービスを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].
Anycastを使用してサービスを配布するために、サービスは最初にIPアドレスの安定したセットに関連付けられ、それらのアドレスへの到達可能性は、複数の独立したサービスノードのルーティングシステムで宣伝されます。Anycastサービスの展開のためのさまざまな手法については、[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.
Anycastは近年、DNSサーバーに冗長性を追加して、DNSアーキテクチャ自体がすでに提供している冗長性を補完するためにますます人気が高まっています。いくつかのルートDNSサーバーオペレーターがインターネット上にサーバーを広く配布しており、リゾルバーとオーソリティサーバーの両方が、サービスプロバイダーのネットワーク内で一般的に配布されています。Anycast Distributionは、商業DNS Authority Serverオペレーターによって数年間使用されてきました。AnyCastの使用はDNSに限定されませんが、AnyCastの使用は、トランザクションの長寿、サーバーに保持されているトランザクション状態、データ同期機能など、配布されるサービスの性質にいくつかの追加の制限を課します。
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.
Anycastは概念的に簡単ですが、その実装はサービスの運用にいくつかの落とし穴を導入します。たとえば、サービスの可用性を監視することはより困難になります。観測された可用性は、ネットワーク内のクライアントの位置に応じて変化し、個々のAnycastノードを使用するクライアントの母集団は静的でも、確実に決定論的でもありません。
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.
このドキュメントでは、内部ゲートウェイプロトコル（IGP）を使用したサービスのローカルスコープ分布と、Border Gateway Protocol（BGP）[RFC4271]を使用したグローバル配信の両方にAnycastの使用について説明します。監視とデータの同期に関する問題の多くは両方に共通していますが、展開の問題は大きく異なります。
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：特定のサービスアドレスを複数の個別の自律的な場所で利用できるようにする慣行は、送信されたデータグラムがいくつかの利用可能な場所の1つにルーティングされます。
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.
Anycastノード：HostsとRouterの内部に接続されたコレクションは、Anycastサービスアドレスにサービスを提供します。Anycastノードは、隣接するルーターを備えたルーティングシステムに参加する単一のホストと同じくらい簡単かもしれません。または、いくつかの精巧な方法で接続された多くのホストが含まれる場合があります。どちらの場合でも、サービスがAnycastであるルーティングシステムに、各Anycastノードはサービスアドレスへの一意のパスを提示します。サービス用のAnycastシステム全体は、2つ以上の個別のAnycastノードで構成されています。
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.
集水域：物理的な地理では、川で排水された地域で、排水盆地としても知られています。このドキュメントで使用されているアナロジーにより、Anycastアドレスに向けられたパケットが特定のノードにルーティングされるネットワークのトポロジ領域。
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-Scope Anycast：AnycastサービスアドレスのReachability情報は、特定のAnycastノードがルーティングシステム全体のサブセットにのみ表示されるように、ルーティングシステムを介して伝播されます。
Local Node: an Anycast Node providing service using a Local-Scope Anycast Address.
ローカルノード：ローカルスコープAnycastアドレスを使用してサービスを提供するAnycastノード。
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-Scope Anycast：AnycastサービスアドレスのReachability情報は、特定のAnycastノードがルーティングシステム全体に潜在的に表示できるように、ルーティングシステムを介して伝播されます。
Global Node: an Anycast Node providing service using a Global-Scope Anycast Address.
グローバルノード：グローバルスコープAnycastアドレスを使用してサービスを提供するAnycastノード。
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).
Anycastは、2つ以上の個別の場所にあるAnycastノードで、ルーティングシステムでサービスアドレスを使用できるようにする慣行に与えられた名前です。各ノードが提供するサービスは、特定の要求を処理するためにルーティングシステムによって選択された特定のノードに関係なく、一般に一貫しています（ただし、一部のサービスは、地域固有の動作を促進するために、個々のノードの動作の意図的な違いから利益を得ることができます。セクション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.
Anycastを使用して配布されるサービスの場合、他のサーバーへの紹介や名前ベースのサービス配布（「ラウンドロビンDNS」）への固有の要件はありませんが、アプリケーションが必要とする場合、それらの手法はAnycastサービス配布と組み合わせることができます。ルーティングシステムは、ルーティングシステムのトポロジデザインと、リクエストが発生するネットワークのポイントに基づいて、各要求に使用されるノードを決定します。
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.
特定のクエリを使用するために選択されたAnycastノードは、ルーティングシステムを構成するルーティングプロトコルのトラフィックエンジニアリング機能の影響を受ける可能性があります。ノードのオペレーターが利用できる影響の程度は、サービスアドレスが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.
Anycastノード間の負荷分散は通常、達成が困難です（ノード間の負荷分布は、要求とトラフィックの負荷の点で一般的に不均衡です）。ただし、信頼性の目的でノード間の負荷の分布、および人気のあるサービスをスケーラブルにするための粗粒の負荷分布は、しばしば達成できます。
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.
サービスがAnycastであるルーティングシステムのスケールは、少数のコンポーネントを接続する小さなインテリアゲートウェイプロトコル（IGP）から、自然に応じてグローバルインターネットを接続するボーダーゲートウェイプロトコル（BGP）[RFC4271]まで変化する可能性があります。必要なサービス配布の。
A service may be anycast for a variety of reasons. A number of common objectives are:
サービスは、さまざまな理由でAnycastになる場合があります。多くの一般的な目的は次のとおりです。
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. 単一のAnycastノードへの損傷をローカルすることにより、分散されていないサービス拒否攻撃の緩和。
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. 分散されたサービス拒否攻撃またはフラッシュクラウドの制約Anycastノード周辺の地元の地域へのフラッシュクラウド。サービスのAnycast Distributionは、おそらく過剰にサブスクライブされた有料トランジットサーキットではなく、高性能のピアリングリンクを使用して、トラフィックをソースの近くで処理する機会を提供します。
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. スプーフィングされたソースアドレスを組み込んだ攻撃（またはクエリ）トラフィックの場合のトラフィックソースの位置を特定するのに役立つ追加情報を提供するため。この情報は、特定のクエリのサービスに使用されるAnycastノードの選択がリクエストのトポロジ源に関連している可能性があるというAnycast Service Distributionのプロパティから派生しています。
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. ローカルAnycastノードの提供でクライアントとサーバー間のネットワーク距離を削減することにより、クエリ応答時間の改善。クエリ応答時間が改善される範囲は、ルーティングシステムによってクライアントにノードが選択される方法によって異なります。ルーティングシステム内のトポロジーの近さは、一般に、ネットワーク全体の往復性能と相関していません。場合によっては、応答時間は減少せず、増加する可能性があります。
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. サーバーのリストを単一の分散アドレスに削減します。たとえば、ゾーン用の多数の権威ある名前アーバーは、小さなセットのAnycastサービスアドレスを使用して展開できます。このアプローチは、親ゾーンの権威ある名前サーバーからの紹介応答のサイズを増やすことなく、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つ以上のノードの間にAnycastの場合、ルーティングシステムはクライアントに代わってノード選択決定を行います。通常、クライアントと同じサーバーノードの間に単一のクライアントサーバーインタラクションがトランザクションの期間中に実行されることは要件であるため、ルーティングシステムのノード選択決定は、予想よりも実質的に長く安定する必要があります。サービスが確実に提供される場合は、トランザクション時間。
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).
サービスは、非常に予測可能なルーティングシステム内でAnycastである場合があります。非常に予測可能なルーティングシステムは、長期間安定したままである可能性があります（たとえば、ノードの選択がノード障害への応答としてのみ発生するために、よく管理されたトポロジ型のIGP内のAnycast）。他の展開には、予測可能な特性がはるかに少ない（セクション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.
ルーティングシステムの安定性は、サービスのトランザクション時間とともに、サービスがAnycastの配布に適しているかどうかを決定する際に慎重に比較する必要があります。場合によっては、新しいプロトコルの場合、大規模なトランザクションをAnycastサーバーによって処理される初期化フェーズに分割することが実用的かもしれません。また、おそらく初期化フェーズ中に選択された非ANYCASTサーバーによって提供される持続フェーズです。
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.
このドキュメントは、どのプロトコルまたはサービスがAnycastによる配布に適しているかに関する規則の規則を意図的に回避します。そうしようとすることは想定されるでしょう。
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.
オペレーターは、特に長時間のフローの場合、ユニキャストを使用した単純な「宛先のない」障害よりも複雑なAnycastを使用する潜在的な障害モードがあることに注意する必要があります。
Decisions as to where Anycast Nodes should be placed will depend to a large extent on the goals of the service distribution. For example:
Anycastノードを配置する場所に関する決定は、サービス分布の目標に大きく依存します。例えば：
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再帰リゾルバーサービスは、ISPのネットワーク内で分散している場合があります。oルートDNSサーバーサービスは、インターネット全体に配布される場合があります。Anycastノードは、外部ネットワーク障害時にDNSが地域内で適切に機能するように、外部接続が不十分な地域に配置できます。o FTPミラーサービスには、交換ポイントにあるローカルノードが含まれる場合があります。そのため、その交換ポイントに接続されたISPは、高価なトランジットサーキットを使用する必要がある場合よりも安価にバルクデータをダウンロードできます。
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クエリ（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内でAnycastである場合、ルーティングシステムは通常、サービスを提供しているのと同じ組織の制御下にあり、したがってサービストランザクションの特性とネットワークの安定性の関係は十分に理解される可能性があります。したがって、この手法は、インターネット全体のAnycastサービス分布よりも多くのアプリケーションに適用されます（セクション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の範囲を（1つ以上のゲートウェイルーターと一緒に）サービスを提供するホストのみに縮小することにより、この手法はサーバークラスターの構築に適用できます。このアプリケーションについては、[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:
サービスアドレスは、ネットワーク全体にサービスを配布するために、グローバルインターネットルーティングシステム内でAnycastになる場合があります。このアプリケーションとセクション4.3.1で説明したIGPスコープ分布の主な違いは次のとおりです。
1. the routing system is, in general, controlled by other people;
1. ルーティングシステムは、一般に、他の人によって制御されます。
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つのAnycastノードでサービスがダウンしている場合の別のアプローチは、サービスが正常に機能している別のAnycastノードにリクエストをルーティングすることです。このアプローチについては、セクション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サービスアドレスと対応するAnycastルートの詳細については、セクション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.
一部のルーティングシステムは、同じ宛先への平等なパスをサポートしています。複数の等しいコストのパスが存在し、異なるaycastノードにつながる場合、単一のトランザクションに関連付けられた異なる要求パケットが複数のノードに配信される可能性があるというリスクがあります。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].
等しいコストパスは、IGPSで一般的にサポートされています。ほとんどの場合、IGPリンクメトリックを慎重に検討するか、等しいコストマルチパス（ECMP）選択アルゴリズムを適用することにより、単一のトランザクションのマルチノード選択は回避できます。パケットトランザクション。Anycastサービス配布でのハッシュベースの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:
Anycast Serviceの配布に関して、PPLBの一部の使用により、クライアントが送信した単一のマルチパケットトランザクションからさまざまなパケットが異なるキャストノードに配信される可能性があり、Anycastサービスを効果的に利用できなくなります。これが特定のAnycastサービスに影響するかどうかは、ルーティングシステム内でAnycastノードが展開される方法と場所、および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;
2. 単一の自律システム（AS）内の多様なパスを横切るPPLBは、ASを離れるときにパスが単一の出口に収束し、ノードの選択の問題を引き起こさないはずです。
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.
3. さまざまな隣接ASEへのリンクを横切るPPLB。近隣ASESが特定のAnycastの宛先に対して異なるノードを選択した場合、一般に、要求パケットは複数のAnycastノードに配布されます。これは、Anycastサービスが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.
Anycastサービスの配布とひどく相互作用する可能性があるPPLBの使用は、持続的なパケットの並べ替えを引き起こす可能性があります。セグメントを永続的に再測定するネットワークパスは、TCP [Allman2000]によって運ばれるトラフィックのパフォーマンスを分解します。TCPは、いくつかの文書化された測定によると、インターネットで運ばれるトラフィックの大部分を説明しています（[McCreary2000]、[Fomenkov2004]）。その結果、多くの場合、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の個々のプレフィックスの引き出しは、フラップとして知られています。迅速な羽ばたきは、[RFC2439]に記載されているように、不安定性の源からかなり遠く離れたルーターのCPU疲労につながる可能性があります。
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.
フラップ減衰のいくつかの実装は、観測されたAS_PATHに基づいて振動する広告をペナルティにします。このため、単一のAnycastノードからのルートフラップにつながるネットワークの不安定性は、通常、他のノード（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.
単一のノードからの振動に応じて、異なるアニカストノードに由来する広告を罰するような実装の機会を制限するには、異なるノードからのルートのAS_PATH属性が可能な限り多様であることを手配するように注意する必要があります。たとえば、Anycastノードは広告と同じオリジンを使用する必要がありますが、上流のASEが異なる場合があります。
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;
1. 特に安定したグローバルノードと組み合わせたローカルノードの賢明な展開（高いAS Inter-AS Path Splay、冗長ハードウェア、パワーなど）は、ローカルノードの限られた影響領域に振動の問題を制限するのに役立ちます。
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. オリジンに近いサービスプレフィックスの積極的なフラップ減衰（たとえば、Anycastノード内、または各Anycastノードの隣接するASE）も、リモートASESの機会を減らすことができます。
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.
インターネット全体に展開された任意のキャストノードのコレクションは、個々のノードがマルチホームでなくても、分散型のマルチホームサイトとルーティングシステムにほとんど区別できないため、このリスクも存在します。各Anycastノードがマルチホームネットワークとして扱われ、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.
グローバルインターネット全体のAnycastサービスの配信のコンテキストでは、グローバルノードは、ネットワーク内のどこでもクライアントにサービスを提供できるものです。サービスの到達可能性情報は、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.
対照的に、自律システムの地元の集水域にのみサービスを提供するAnycastノードを展開することが望ましい場合があり、それは意図的にインターネット全体で利用できません。このようなノードは、このドキュメントでローカルノードと呼ばれます。ローカルノードが適切である可能性のある状況の例は、豊富な内部接続を備えた地域にサービスを提供するように設計されたノードですが、インターネットの残りの部分への信頼性が低い、混雑している、または高価なアクセスです。
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]やnoper [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.
他の人が動作するネットワーク全体にAnycastサービスが展開されると、それらの到達可能性は、ルーティングポリシーとトポロジの変更（計画および計画外）に依存します。ルーティングシステムには、複数の無関係な組織が運営するネットワークが含まれる場合があるため、無関係な変更の組み合わせに起因する予期せぬ相互作用の可能性も存在します。
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).
このようなルーティングシステムの安定性と予測可能性は、特定のサービスとプロトコルの配布戦略としてAnycastの適合性を評価する際に考慮する必要があります（セクション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).
緩和により、このようなルーティングシステム全体でAnycastノードで使用されるルーティングポリシーは保守的である必要があり、個々のノードの内部および接続インフラストラクチャは、平均をはるかに超える負荷をサポートするためにスケーリングする必要があり、サービスは多くの人から積極的に監視する必要があります。不快な驚きを避けるためのポイント（セクション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.
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.4.1を参照）。ただし、サービス全体の安定性に付随するリスクがあります（セクション4.7を参照）。
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.
一般に、ここで説明するスケーリングの問題は、Anycastがグローバルインターネット上のサービス配信のための有用で一般的なアプローチではないことを防ぎます。しかし、これは、限られた数のインターネット批判的なサービスを配布するための有用な手法であり、ここで説明する集約に関する懸念が適用されない小規模なネットワークでは、有用な手法であり続けています。
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.
サービスアドレスは、すべてのAnycastノードをサービスのすべての可能なクライアントに接続するルーティングシステム内で一意である必要があります。また、対応するルートがそのルーティングシステム内で伝播できるように、サービスアドレスも選択する必要があります。
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番号のサービスの場合、Anycastアドレスはユニキャストアドレスとは異なる方法でスコープされていません。そのため、IPv4に提示されたアドレス適合性のガイドラインは、IPv6に続きます。[RFC4291]のIPv6アドレス指定の仕様から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.
一部のサービスはローカライズされた形式で展開されていますが（特定の地域のクライアントには地域に関連するコンテンツが表示されます）、多くのサービスには、リクエストがどこにあるかに関係なく、クライアント要求への応答が一貫している必要があるプロパティがあります。Anycastを使用して配布されるサービスの場合、異なるAnycastノードが一貫した方法で動作する必要があり、その一貫した動作がデータセットに基づいている場合、関係するデータはノード間で同期します。
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です。一般に、Anycastノード間のデータの同期には、非Anycastアドレス間のトランザクションが含まれます。
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.
各サービスアドレスは、広告された各プレフィックスで1つのサービスアドレスのみがカバーされるように選択されます。単一のカバーのプレフィックスの広告と撤回は、単一の関連サービスの可用性にしっかりと結合できます。
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.
複数のサービスアドレスが選択されており、単一のプレフィックスでカバーされています。シングルカバーのプレフィックスの広告と撤回は、1つのサービスの可用性と結び付けられています。ノードには、トンネルを使用して内部接続があります。サービスアドレスのホストルートは、すべてのノードのルーターを含むように拡張される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.
1つのノードでサービスが利用できないが、他のノードで利用可能である場合、受信ノードから他のノードに向けて処理のためにインテリアネットワークを介してリクエストをルーティングできます。
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.
展開されているサービスのすべてのクライアントが時々問題を経験しており、これらの問題は診断が必要です。Anycastを使用して配布されたサービスは、クライアントの要求を処理している特定のAnycastノードである、単純でユニキャストサービスに診断プロセスに追加の変数を課します。
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.
場合によっては、Tracerouteなどの一般的なネットワークレベルの診断ツールが、クライアントが使用しているノードを識別するのに十分な場合があります。ただし、そのようなツールの使用は、トランザクションのクライアント側でのユーザーの能力を超えている可能性があり、いずれにせよ、問題の時点でのネットワーク条件は、そのようなツールが行使されるまでに変更される場合があります。
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].
ノードのアイデンティティを決定するメカニズムがプロトコルに設計されている場合、Anycastサービスのトラブルシューティングの問題は非常に促進されます。このようなメカニズムの例には、DNS [NSID]のNSIDオプションと、セッション開始時のSMTPサーバーの最初の挨拶[RFC2821]でのホスト名情報の一般的な包含が含まれます。
Provision of such in-band mechanisms for node identification is strongly recommended for services to be distributed using anycast.
ノード識別のためのこのような帯域内メカニズムの提供は、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.
分散サービスは、ルーティングシステム全体に分散されたプローブから監視されることをお勧めします。可能であれば、個々のリクエストに応答するノードのIDは、パフォーマンスと可用性の統計とともに記録されます。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.
サービス（ホスト、ルーターなど）のエンジャスト展開でコンポーネントデバイスの健康を監視することは簡単であり、他のネットワークに接続されたインフラストラクチャを管理するために一般的に使用される同じツールと技術を使用して達成できます。Anycastサービスアドレスの監視。
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. Anycastノードは、影響力の範囲内で発信される攻撃トラフィックのシンクとして機能し、他の場所のノードがそのトラフィックに対処する必要がないようにすることができます。
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.
無許可の当事者が、ネットワーク全体のAnycastサービスアドレスに対応するルートを宣伝する可能性があり、そうすることで、サービス（またはその両方）を損なう方法で合法的な要求トラフィックまたはプロセス要求をキャプチャする可能性があります。Rogue Anycastノードは、クライアントまたはサービスのオペレーターが検出するのが難しい場合があります。
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.
ルーティングシステムの操作によるハイジャックのリスクは、サービスがAnycastを使用して配布されるかどうかに関係なく存在します。ただし、正当なAnycastノードがルーティングシステムで観察可能であるという事実により、Rogueノードの検出がより困難になる可能性があります。
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]）レベル。堅牢性が低いプロトコルは、セッションのハイジャックに対してより脆弱な場合があります。Anycast Servicesで検出されないセッションハイジャックの機会が増えることを考えると、認証または整合性保護を必要とするAnycastサービスには、堅牢なプロトコルの使用が推奨されます。
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.
著者は、Grow Working Group、特にGeoff Huston、Pekka Savola、Danny McPherson、Ben Black、Alan Barrettのさまざまな参加者からの貢献に感謝しています。
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] Postel、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.、Moskowitz、R.、Karrenberg、D.、Groot、G。、およびE. Lear、「Private Internetsのアドレス割り当て」、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. Li、「BGP Communities属性」、RFC 1997、1996年8月。
[RFC2439] Villamizar, C., Chandra, R., and R. Govindan, "BGP Route Flap Damping", RFC 2439, November 1998.
[RFC2439] Villamizar、C.、Chandra、R。、およびR. Govindan、「BGP Route Flap Damping」、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] Ferguson、P。およびD. Senie、「ネットワークイングレスフィルタリング：IPソースアドレススプーフィングを採用するサービス拒否攻撃の敗北」、BCP 38、RFC 2827、2000年5月。
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, March 2004.
[RFC3704] Baker、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.、Li、T。、およびS. Hares、「A Border Gateway Protocol 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. Deering、「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] Allman、M。and E. Blanton、「TCPをパケットの再注文により堅牢にすることについて」、2000年1月、<http：// www.icir.org/mallman/papers/tcp-reorder-ccr.ps>。
[DNSMON] "RIPE NCC DNS Monitoring Services", <http://dnsmon.ripe.net/>.
[dnsmon]「熟した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.、Keys、K.、Moore、D。、およびK。Claffy、「1999年から2003年までのインターネットトラフィックの縦断的研究」、2004年1月、<http://www.caida.org/ outreach/papers/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] EBLEY、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] EBLEY、J。、「GNU Zebra、ISC Bind 9およびFreeBSDを使用したDNSサービスのリクエストを配布するためのソフトウェアアプローチ」、2004年3月<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トラフィックパターンの傾向：Ames Internet Exchangeからの見解」、2000年9月、<http://www.caida.org/ outreach/Papers/2000/aix0005/aix0005.pdf>。
[NSID] Austein, R., "DNS Name Server Identifier Option (NSID)", Work in Progress, June 2006.
[NSID] Austein、R。、「DNS Name Server Identifier Option（NSID）」、2006年6月の作業。
[RFC1546] Partridge, C., Mendez, T., and W. Milliken, "Host Anycasting Service", RFC 1546, November 1993.
[RFC1546] Partridge、C.、Mendez、T。、およびW. Milliken、「Host Anycasting Service」、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] Ferguson、P。およびD. Senie、「ネットワークイングレスフィルタリング：IPソースアドレススプーフィングを採用するサービス拒否攻撃の敗北」、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.、Hoffman、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]クレンシン、J。、「Simple Mail Transfer Protocol」、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.、Gudmundsson、O.、Eastlake、D。、およびB. Wellington、「DNSのシークレットキートランザクション認証」、RFC 2845、2000年5月。
[RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over Transport Layer Security", RFC 3207, February 2002.
[RFC3207] Hoffman、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] Huston、G。、「ボーダーゲートウェイプロトコル（BGP）ルートスコープ制御のためのNoper Community」、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] Arends、R.、Austein、R.、Larson、M.、Massey、D。、およびS. Rose、「DNSセキュリティの紹介と要件」、RFC 4033、2005年3月。
[RIS] "RIPE NCC Routing Information Service (RIS)", <http://ris.ripe.net>.
[ris]「熟した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
Joeabley Afilias Canada、Corp。204-4141Yongge Street Toronto、M2P 2A8カナダ
Phone: +1 416 673 4176
EMail: jabley@ca.afilias.info
URI: http://afilias.info/
Kurt Erik Lindqvist Netnod Internet Exchange Bellmansgatan 30 118 47 Stockholm Sweden
Kurt Erik Lindqvist Netnod Internet Exchange Bellmansgatan 30 118 47 Stockholm Sweden
EMail: kurtis@kurtis.pp.se
URI: http://www.netnod.se/
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2006).
Copyright（c）The IETF Trust（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.
このドキュメントとここに含まれる情報は、「現状」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。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エディター機能の資金は現在、インターネット協会によって提供されています。