RFC4786 日本語訳
4786 Operation of Anycast Services. J. Abley, K. Lindqvist. December 2006. (Format: TXT=56818 bytes) (Also BCP0126) (Status: BEST CURRENT PRACTICE)
プログラムでの自動翻訳です。
英語原文
Network Working Group J. Abley
Request for Comments: 4786 Afilias Canada
BCP: 126 K. Lindqvist
Category: Best Current Practice Netnod Internet Exchange
December 2006
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
Operation of Anycast Services
Status of This Memo
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.
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 Notice
Copyright (C) The IETF Trust (2006).
Copyright (C) The IETF Trust (2006).
Abstract
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.
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.
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.
Abley & Lindqvist Best Current Practice [Page 1] RFC 4786 Anycast BCP December 2006
Abley & Lindqvist Best Current Practice [Page 1] RFC 4786 Anycast BCP December 2006
Table of Contents
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
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
Abley & Lindqvist Best Current Practice [Page 2] RFC 4786 Anycast BCP December 2006
Abley & Lindqvist Best Current Practice [Page 2] RFC 4786 Anycast BCP December 2006
1. Introduction
1. Introduction
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.
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].
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].
The techniques and considerations described in this document apply to services reachable over both IPv4 and IPv6.
The techniques and considerations described in this document apply to services reachable over both IPv4 and 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 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.
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.
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.
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.
Abley & Lindqvist Best Current Practice [Page 3] RFC 4786 Anycast BCP December 2006
Abley & Lindqvist Best Current Practice [Page 3] RFC 4786 Anycast BCP December 2006
2. Terminology
2. Terminology
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).
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).
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: 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.
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.
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.
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-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.
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-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.
Global Node: an Anycast Node providing service using a Global-Scope Anycast Address.
Abley & Lindqvist Best Current Practice [Page 4] RFC 4786 Anycast BCP December 2006
Abley & Lindqvist Best Current Practice [Page 4] RFC 4786 Anycast BCP December 2006
3. Anycast Service Distribution
3. Anycast Service Distribution
3.1. General Description
3.1. General Description
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 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).
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.
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.
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.
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.
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.
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.
3.2. Goals
3.2. Goals
A service may be anycast for a variety of reasons. A number of common objectives are:
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. Coarse ("unbalanced") distribution of load across nodes, to allow infrastructure to scale to increased numbers of queries and to accommodate transient query peaks;
Abley & Lindqvist Best Current Practice [Page 5] RFC 4786 Anycast BCP December 2006
Abley & Lindqvist Best Current Practice [Page 5] RFC 4786 Anycast BCP December 2006
2. Mitigation of non-distributed denial-of-service attacks by
localising damage to single Anycast Nodes;
2. Mitigation of non-distributed denial-of-service attacks by localising damage to single Anycast Nodes;
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. 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;
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. 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.
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. 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.
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. 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.
4. Design
4. Design
4.1. Protocol Suitability
4.1. Protocol Suitability
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.
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.
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
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
Abley & Lindqvist Best Current Practice [Page 6] RFC 4786 Anycast BCP December 2006
Abley & Lindqvist Best Current Practice [Page 6] RFC 4786 Anycast BCP December 2006
far longer-lived transactions (e.g., bulk file downloads and audio- visual media streaming).
far longer-lived transactions (e.g., bulk file downloads and audio- visual media streaming).
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).
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).
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.
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.
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.
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.
4.2. Node Placement
4.2. Node Placement
Decisions as to where Anycast Nodes should be placed will depend to a large extent on the goals of the service distribution. For example:
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 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.
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.
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.
Abley & Lindqvist Best Current Practice [Page 7] RFC 4786 Anycast BCP December 2006
Abley & Lindqvist Best Current Practice [Page 7] RFC 4786 Anycast BCP December 2006
4.3. Routing Systems
4.3. Routing Systems
4.3.1. Anycast within an IGP
4.3.1. Anycast within an IGP
There are several common motivations for the distribution of a Service Address within the scope of an IGP:
There are several common motivations for the distribution of a Service Address within the scope of an IGP:
1. to improve service response times by hosting a service close to
other users of the network;
1. to improve service response times by hosting a service close to other users of the network;
2. to improve service reliability by providing automatic fail-over
to backup nodes; and
2. to improve service reliability by providing automatic fail-over to backup nodes; and
3. to keep service traffic local in order to avoid congesting wide-
area links.
3. to keep service traffic local in order to avoid congesting wide- area links.
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).
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).
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).
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).
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.
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.
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.
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.
Abley & Lindqvist Best Current Practice [Page 8] RFC 4786 Anycast BCP December 2006
Abley & Lindqvist Best Current Practice [Page 8] RFC 4786 Anycast BCP December 2006
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].
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].
4.3.2. Anycast within the Global Internet
4.3.2. Anycast within the Global Internet
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:
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:
1. the routing system is, in general, controlled by other people;
1. the routing system is, in general, controlled by other people;
2. the routing protocol concerned (BGP), and commonly-accepted
practices in its deployment, impose some additional constraints
(see Section 4.4).
2. the routing protocol concerned (BGP), and commonly-accepted practices in its deployment, impose some additional constraints (see Section 4.4).
4.4. Routing Considerations
4.4. Routing Considerations
4.4.1. Signalling Service Availability
4.4.1. Signalling Service Availability
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.
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].
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].
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.
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.
Abley & Lindqvist Best Current Practice [Page 9] RFC 4786 Anycast BCP December 2006
Abley & Lindqvist Best Current Practice [Page 9] RFC 4786 Anycast BCP December 2006
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.
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.
4.4.2. Covering Prefix
4.4.2. Covering Prefix
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.
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.
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.
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.
The propagation of a single route per service has some associated scaling issues, which are discussed in Section 4.4.8.
The propagation of a single route per service has some associated scaling issues, which are discussed in Section 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.
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.3. Equal-Cost Paths
4.4.3. Equal-Cost Paths
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.
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.
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
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
Abley & Lindqvist Best Current Practice [Page 10] RFC 4786 Anycast BCP December 2006
Abley & Lindqvist Best Current Practice [Page 10] RFC 4786 Anycast BCP December 2006
single destination regardless of whether multiple candidate paths exist. Implementations of BGP exist that support multi-path exit selection, however.
single destination regardless of whether multiple candidate paths exist. Implementations of BGP exist that support multi-path exit selection, however.
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].
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].
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選択アルゴリズムは一般的に利用可能です、同じ流れからのパケットが同じ目的地に向かって発送されるために保証されないそれらを含んでいて。 流れ単位でというよりむしろ1パケットあたり1個のベースのルートを選択する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サービス分配に関して、PPLBのいくつかの用途でクライアントによって送られたただ一つのマルチパケットトランザクションからの異なったパケットを異なったAnycast Nodesに提供するかもしれません、事実上anycastサービスを入手できなくして。 これが特定のanycastサービスに影響するかどうかがAnycast Nodesは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. リンクの向こう側のPPLBは、複数のAnycast Nodesの向こう側に特定のanycastの目的地で一般にリクエスト・パケットを分配するので、異なるとASesに近くに住みます。そこでは、隣人ASesが異なったノードを選択しました。 これには、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の用途は永続的なパケット再命令を引き起こす場合があります。 Aは経路をそんなに持続してネットワークでつなぎます。追加注文セグメントはTCP[Allman2000]によって運ばれたトラフィックの性能を下げるでしょう。 [Fomenkov2004)、いくつかの記録された測定値によると、TCPはインターネット[McCreary2000]で運ばれたトラフィックの大半を占めます。 その結果、多くの場合、PPLBのそのような使用をするネットワークが病理学的であると考えるのは妥当です。
Abley & Lindqvist Best Current Practice [Page 11] RFC 4786 Anycast BCP December 2006
Ableyとリンクヴィスト最も良い現在の習慣[11ページ]RFC4786Anycast BCP2006年12月
4.4.4. Route Dampening
4.4.4. ルートの湿り
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.
フラップの湿りのいくつかの実装が広告がNetwork Layer Reachability情報ではなく、観測されたAS_PATHに基礎づけた振動を罰します(NLRI; [RFC4271]を見てください)。 この理由で、それで独身のAnycast Nodeからのばたつくことを発送するように導いて、一般に、これらの実装で他のノード(異なった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.
注意は、そのような実装がまさしくただ一つのノードからの振動に対応して異なったAnycast Nodesから発する広告を罰する機会を制限するためには、それをアレンジするために取って、異なったノードからのルートのAS_PATH属性ができるだけさまざまであるということであるべきです。 例えば、Anycast Nodesには、彼らの広告に同じ発生源ASを使用するべきですが、異なった上流のASesがあるかもしれません。
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. 特に安定したGlobal Nodes(高い相互AS経路広がり、余分なハードウェア、パワーなどがある)と組み合わせたLocal Nodesの賢明な展開は、振動問題をLocal Nodesの影響の限られた範囲に制限するのを助けるかもしれません。
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 Node、またはそれぞれのAnycast Nodeの隣接しているASesの)の近くのサービス接頭語の攻撃的なフラップ湿りは、リモートASesが全く振動を見る機会を減少させるのを助けるかもしれません。
Abley & Lindqvist Best Current Practice [Page 12] RFC 4786 Anycast BCP December 2006
Ableyとリンクヴィスト最も良い現在の習慣[12ページ]RFC4786Anycast BCP2006年12月
4.4.5. Reverse Path Forwarding Checks
4.4.5. 経路推進チェックを逆にしてください。
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]で説明された逆のPath Forwarding(RPF)チェックは、ソースアドレスが偽造されるパケットを否定するためにイングレスインタフェースパケットフィルタの一部としてインターネットのルータで一般的に配布されます(また、RFC2827[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 Nodesの収集が分配されたaから主に区別がつかない、マルチ、家へ帰り、ルーティングシステムへのサイト、したがって、また、個々のノードが存在していなくてもこのリスクがAnycast Nodesのために存在している、マルチ、家へ帰り 各Anycast Nodeがaとして扱われるのを保証するために注意するべきである、マルチ、家へ帰り、ネットワーク、そして、RPFチェックに関する[RFC3704]の対応する推薦は意に介されます。
4.4.6. Propagation Scope
4.4.6. 伝播範囲
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サービス分配の文脈では、Global Nodesはクライアントに対するサービスをネットワークでどこでも提供できるものです。 サービスのための可到達性情報はグローバルに伝播されます、制限なしで、グローバルなトランジットのために1つ以上のプロバイダーにService Addressesをカバーするルートの広告を出すことによって。
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).
1Global Nodeがただ一つのサービスのために存在できます(冗長と負荷分割法の理由で本当に、しばしばこれはそうです)。
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 Nodeを配布するのは時々望ましいです。 そのようなノードは本書ではLocal Nodesと呼ばれます。 Local Nodeが適切であるかもしれない事情に関する例は豊かな内部の接続性にもかかわらず、インターネットの残りへの頼り無いか、混雑しているか、高価なアクセスを領域に供給するように設計されたノードです。
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
地方のNodesはService Addressesのために彼らの伝播が制限されるような方法で覆いルートの広告を出します。 これは_EXPORT[RFC1997]でないNOPEERがないことなど[RFC3765]のよく知られる共同体ストリング属性を使用するか、または同輩と共に従来でaを適用するように手配し終わるかもしれません。
Abley & Lindqvist Best Current Practice [Page 13] RFC 4786 Anycast BCP December 2006
Ableyとリンクヴィスト最も良い現在の習慣[13ページ]RFC4786Anycast BCP2006年12月
"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.
Local NodesからのService Addressesへの広告の可到達性は理想的に伝播のために暗黙の(デフォルト)方針を当てにするよりむしろ明白な属性を存在に要求するルーティング方針を使用し終わるべきです。 意図している地平線を超えたルートの不注意な伝播はLocal Nodesのための容量問題をもたらすことができます。(Local Nodesはネットワーク全体でサービス性能を下げるかもしれません)。
4.4.7. Other Peoples' Networks
4.4.7. 他の民族のネットワーク
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 Nodesによって使用されたルーティング方針は保守的であるべきです、そして、個々のノードは内部です、そして、外部の、または、接続しているインフラストラクチャは平均を超えて遠くにサポート負荷に合わせて調整されるべきです、そして、サービスは、不快な驚きを避けるために多くのポイントから予測してモニターされるべきです(セクション5.1を見てください)。
4.4.8. Aggregation Risks
4.4.8. 集合リスク
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 Service Addressesにインターネットに対するサービスを供給する自律システムは、ルートの広告を出す(N+1)必要があるでしょう、それぞれのそれらのサービスがanycastを使用することで分配されることであったなら。
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
インターネット(セクション4.4.2を見る)に関する輸入政策で最小の接頭語長さのフィルタを適用する一般的な習慣は、それがまさしくホストルートの広告を出すのが必要であるというよりも有効に伝播されるためにService Addressをカバーするルートに関して接頭語の長さが実質的に少なくなければならないことを意味します。 短い接頭語の広範囲の広告
Abley & Lindqvist Best Current Practice [Page 14] RFC 4786 Anycast BCP December 2006
Ableyとリンクヴィスト最も良い現在の習慣[14ページ]RFC4786Anycast BCP2006年12月
individual services, hence, also has a negative impact on address conservation.
個人は、負の衝撃をしたがって、修理して、また、アドレス保護に持っています。
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).
複数のService Addressesを収容するためにただ一つの覆い接頭語の使用でこれらの問題の両方をある程度緩和できます、セクション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がサービス分配のための役に立って、一般的なアプローチであることを防ぎます。 それは残っていて、限られた数のインターネット重要なサービスを広げるための役に立つテクニックでありしかしながら、また、ここで議論した集合関心がどこでするかが、より小さいネットワークのように適用しません。
4.5. Addressing Considerations
4.5. 問題を扱います。
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.
サービスAddressesはすべての可能なサービスのクライアントにすべてのAnycast Nodesを接続するルーティングシステムの中でユニークであるべきです。 また、対応するルートがそのルーティングシステムの中で伝播できるように、サービスAddressesを選ばなければなりません。
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 Addressesはユニキャストアドレスと異なって見られません。 そういうものとして、IPv4のために提示されたアドレス適合のためのガイドラインはIPv6のために従います。 [RFC4291]で仕様を扱うIPv6からIPv6の上のサービスのanycast分配での歴史的な禁止を取り除いてあることに注意してください。
4.6. Data Synchronisation
4.6. データ同期
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,
多くのサービスには、いくつかのサービスが局限されたフォームで配布されましたが(地方的に関連している内容を特定の領域からのクライアントに与えるように)、クライアントへの応答が一貫しているべきであるよう要求する特性があります、どこにかかわらず。要求は起因します。 そしてanycastを使用することで広げられたサービスのためにそれが、異なったAnycast Nodesが一貫した方法で作動しなければならないのを含意する。
Abley & Lindqvist Best Current Practice [Page 15] RFC 4786 Anycast BCP December 2006
Ableyとリンクヴィスト最も良い現在の習慣[15ページ]RFC4786Anycast BCP2006年12月
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です。 一般に、Anycast Nodesの間のデータの連動は非anycastのアドレスの間のトランザクションにかかわるでしょう。
Data synchronisation across public networks should be carried out with appropriate authentication and encryption.
公衆通信回線の向こう側のデータ同期が適切な認証と暗号化で行われるべきです。
4.7. Node Autonomy
4.7. ノード自治
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.
目標が冗長を通して改良された信頼性を含んでいるanycast展開のために、それは、単一欠陥が多くの(すべて)ノードに感染する機会を最小とならせるように重要であるか、または全体でサービスが破られるまで、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.
また、ロードするのにおいて当然の失敗をどっと落させる可能性はただ一つのサービスのためのGlobalとLocal Nodesの両方の展開で減少できます、Local NodeからGlobal Nodeまでトラフィックの有効なフェイルオーバー経路が一般にあるので。 1Local Nodeを沈めるかもしれないトラフィックは最も堕落したケース以外のすべてのLocal Nodesを沈めそうにはありません。
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.
ノード自治を増強するこれらのアプローチがいろいろな度合いで配布しているサービスを操作するために簡単にするという実用的な目標とは逆にあることに注意されるべきです。 稼働することではひどく複雑なサービスは、より簡単なサービスよりオペレータエラーに苦しみそうです。 熟慮は、適切なバランスを見つけることができるようにこれらの局面をすべてに与えるべきです。
Abley & Lindqvist Best Current Practice [Page 16] RFC 4786 Anycast BCP December 2006
Ableyとリンクヴィスト最も良い現在の習慣[16ページ]RFC4786Anycast BCP2006年12月
4.8. Multi-Service Nodes
4.8. マルチサービスノード
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).
ルーティングシステムの向こう側に覆い接頭語が独身のService Addressに可到達性を発表するのに必要である(セクション4.4.2を見てください)広げられたサービスにおいて、特別の配慮が複数のサービスが1セットのノードの向こう側に分配される必要がある場合で必要です。 これが個々にルーティングシステムに対するサービスの有用性に合図するという要件から生じるので、サービスを求める要求はそれらを処理できないノードによって受け取られません(セクション4.4.1を見てください)。
Several approaches are described in the following sections.
いくつかのアプローチが以下のセクションで説明されます。
4.8.1. Multiple Covering Prefixes
4.8.1. 複数の覆い接頭語
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.
各Service Addressが選ばれているので、1Service Addressだけがそれぞれの広告を出している接頭語でカバーされています。 ただ一つの覆い接頭語の広告と退出はただ一つに関連サービスの有用性への密結合であるかもしれません。
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サーバなどの重要で、インフラストラクチャの少ない数のサービスの使用に適しています。 一般インターネット全体のこのアプローチを使用するサービスの展開は比例しないでしょう。
4.8.2. Pessimistic Withdrawal
4.8.2. 悲観的な退出
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.
複数のService Addressesが選ばれているので、彼らはただ一つの接頭語でカバーされています。 ただ一つの覆い接頭語の広告と退出はすべての関連サービスの有用性と結合されます。 何か個々のサービスが入手できなくなるなら、覆い接頭語はよそよそしいです。
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.
すべてのService Addressesが利用可能であるに違いないという要件によって覆い接頭語のサービスの有用性と広告の間のカップリングは複雑にされます--発表は、ただ一つのカバーされたルートだけではなく、すべてのコンポーネントルートの存在によって引き起こされる必要があります。
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.
ただ一つの誤動作サービスでノードにおけるサービスであると配布されたすべてをオフラインで取るという事実で、このアプローチは多くのアプリケーションに不適当になるかもしれません。
Abley & Lindqvist Best Current Practice [Page 17] RFC 4786 Anycast BCP December 2006
Ableyとリンクヴィスト最も良い現在の習慣[17ページ]RFC4786Anycast BCP2006年12月
4.8.3. Intra-Node Interior Connectivity
4.8.3. イントラノードの内部の接続性
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.
複数のService Addressesが選ばれているので、彼らはただ一つの接頭語でカバーされています。 ただ一つの覆い接頭語の広告と退出はどんなサービスの有用性とも結合されます。 ノードには、内部の接続性があります、例えば、使用はトンネルを堀ります。 Service Addressesのためのホストルートは、すべてのノードにルータを含むように広がる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.
このアプローチは発表された接頭語でカバーされたnetblockの合理的なアドレス利用を許します、個々のノードの減少している自治を犠牲にして。 1ポイントの失敗としてすべてのノードが参加するIGPを見なすことができます。
4.9. Node Identification by Clients
4.9. クライアントによるノード識別
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 Node。
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].
ノードのアイデンティティを決定するメカニズムがプロトコルに設計されるなら、anycastサービスに関する問題を障害調査するのは大いに容易にされます。 そのようなメカニズムに関する例はセッション開始[RFC2821]にDNS[NSID]のNSIDオプションとSMTPサーバーの初期の挨拶でのホスト名情報の一般的な包含を含んでいます。
Provision of such in-band mechanisms for node identification is strongly recommended for services to be distributed using anycast.
サービスがanycastを使用することでノード識別のためのバンドにおけるそのようなメカニズムに関する条項が広げられることが強く勧められます。
Abley & Lindqvist Best Current Practice [Page 18] RFC 4786 Anycast BCP December 2006
Ableyとリンクヴィスト最も良い現在の習慣[18ページ]RFC4786Anycast BCP2006年12月
5. Service Management
5. サービス管理
5.1. Monitoring
5.1. モニターであること
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経路情報Service[RIS]やオレゴン大学Route Views Project[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展開における、コンポーネントデバイスの健康をモニターするのは、簡単であり、同じツールを使用することで実現できます、そして、テクニックは一般的に以前はよく他のネットワークによって接続されたインフラストラクチャを管理していました、モニターしているanycast Service Addressesに伴われる追加複雑さなしで。
6. Security Considerations
6. セキュリティ問題
6.1. Denial-of-Service Attack Mitigation
6.1. サービス不能攻撃緩和
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 Nodeは行動できます、ほかの場所のノードがそのトラフィックに対処しなければならないのを防いで。
Abley & Lindqvist Best Current Practice [Page 19] RFC 4786 Anycast BCP December 2006
Ableyとリンクヴィスト最も良い現在の習慣[19ページ]RFC4786Anycast BCP2006年12月
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. ソースが広く配布される攻撃トラフィックに対処するタスクはサービスに貢献するすべてのノードの向こう側に分配されます。 正統、そして、攻撃トラフィックの間のソーティングの問題が分配されているので、これは分配されなかったサービスより良いスケーリング特性に通じるかもしれません。
6.2. Service Compromise
6.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.
あまりにすぐに、そして確かにする働く手順がある場合にだけ、サービスに感染しないての系列の感染しているサーバを取ることができる潜在的利益はわかることができます。
6.3. Service Hijacking
6.3. サービスハイジャック
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 Service Addressesに対応するルートの広告を出すか、正統の要求トラフィックを得るか、または要求を処理するのが、可能です。 凶暴なAnycast Nodeはクライアントかサービスのオペレータで検出するのが難しいかもしれません。
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 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])レベルを例えば、強健なファッション、ただ一つのセッション以内に周期的な再認証を使用するか、またはどちらかでの保全保護におけるそれらの特徴に提供します。 それほど強健でないプロトコルはセッションハイジャックにより被害を受け易いかもしれません。 anycastサービスによる非検出されたセッションハイジャックの、より大きい機会を考えて、強健なプロトコルの使用は認証か保全保護を必要とするanycastサービスのために推薦されます。
Abley & Lindqvist Best Current Practice [Page 20] RFC 4786 Anycast BCP December 2006
Ableyとリンクヴィスト最も良い現在の習慣[20ページ]RFC4786Anycast BCP2006年12月
7. Acknowledgements
7. 承認
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、ダニーMcPherson、ベンBlack、およびアラン・バーレットを育ててください。
This work was supported by the US National Science Foundation (research grant SCI-0427144) and DNS-OARC.
この仕事は米国科学基金(研究助成金SCI-0427144)とDNS-OARCによってサポートされました。
8. References
8. 参照
8.1. Normative References
8.1. 引用規格
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, September 1981.
[RFC0793] ポステル、J.、「通信制御プロトコル」、STD7、RFC793、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.リア、「個人的なインターネットのためのアドレス配分」BCP5、RFC1918(1996年2月)。
[RFC1997] Chandrasekeran, R., Traina, P., and T. Li, "BGP
Communities Attribute", RFC 1997, August 1996.
[RFC1997] ChandrasekeranとR.とTraina、P.とT.李、「BGP共同体属性」、RFC1997、1996年8月。
[RFC2439] Villamizar, C., Chandra, R., and R. Govindan, "BGP
Route Flap Damping", RFC 2439, November 1998.
[RFC2439] VillamizarとC.とチャンドラ、R.とR.Govindan、「BGPルートフラップ湿気」、RFC2439、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を使うサービス妨害Attacksを破ります」、BCP38、RFC2827、2000年5月。
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for
Multihomed Networks", BCP 84, RFC 3704, March 2004.
[RFC3704]ベイカー、F.とP.Savola、「Multihomedのためにネットワークをフィルターにかけるイングレス」BCP84、2004年3月のRFC3704。
[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)」、RFC4271 2006年1月。
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006.
[RFC4291] HindenとR.とS.デアリング、「IPバージョン6アドレッシング体系」、RFC4291、2006年2月。
8.2. Informative References
8.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.ブラントン、「パケットReorderingにより強健な作成TCP」、2000年1月、<tcp-追加注文http://www.icir.org/mallman/書類/ccr.ps>。
[DNSMON] "RIPE NCC DNS Monitoring Services",
<http://dnsmon.ripe.net/>.
[DNSMON]「熟しているNCCのDNSモニターサービス」、<http://dnsmon.ripe.net/>。
Abley & Lindqvist Best Current Practice [Page 21] RFC 4786 Anycast BCP December 2006
Ableyとリンクヴィスト最も良い現在の習慣[21ページ]RFC4786Anycast BCP2006年12月
[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>.
Fomenkov、M.、キーズ、K.、ムーア、D.、およびk.がclaffyする[Fomenkov2004]、「1999- 2003からのインターネット交通の縦断的研究。」_(<http://www.caida.org/奉仕活動/書類/2003/nlanr/nlanr2004年1月の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テネシー2003-1] Abley、J.、「グローバルなサービス分配のための階層的なAnycast」、2003年3月、<http://www.isc.org/パブ/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テネシー2004-1]Abley、J.、「分配へのソフトウェアアプローチはDNSのためにヌーシマウマ、ISCひも9、および無料OSの一つを使用することでサービスを要求します」、2004年3月、<http://www.isc.org/パブ/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>.
マクレーリー、S.、およびk.がclaffyする[McCreary2000]、「広い領域IP交通における傾向は型に基づいて作ります」。 「エームズインターネット交換からの視点」、<http://www.caida.org/奉仕活動/書類/2000/AIX0005/AIX0005.pdf2000年9月の>。
[NSID] Austein, R., "DNS Name Server Identifier Option
(NSID)", Work in Progress, June 2006.
R.、「DNSネームサーバ識別子オプション(NSID)」という[NSID]Austeinは進歩、2006年6月に働いています。
[RFC1546] Partridge, C., Mendez, T., and W. Milliken, "Host
Anycasting Service", RFC 1546, November 1993.
[RFC1546] ヤマウズラとC.とメンデス、T.とW.ミリケン、「ホストAnycastingサービス」、RFC1546、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を破ります」、RFC2267、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メッセージ仕様」、RFC2311(1998年3月)。
[RFC2821] Klensin, J., "Simple Mail Transfer Protocol",
RFC 2821, April 2001.
[RFC2821] Klensin、J.、「簡単なメール転送プロトコル」、RFC2821、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)のための秘密鍵取引認証」、RFC2845)は2000がそうするかもしれません。
[RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP
over Transport Layer Security", RFC 3207,
February 2002.
[RFC3207]ホフマン、P.、「トランスポート層セキュリティの安全なSMTPのためのSMTPサービス拡張子」、RFC3207、2002年2月。
[RFC3765] Huston, G., "NOPEER Community for Border Gateway
Protocol (BGP) Route Scope Control", RFC 3765,
April 2004.
[RFC3765]ヒューストン、G.、「ボーダ・ゲイトウェイ・プロトコル(BGP)ルート範囲制御装置のためのNOPEER共同体」、RFC3765、2004年4月。
Abley & Lindqvist Best Current Practice [Page 22] RFC 4786 Anycast BCP December 2006
Ableyとリンクヴィスト最も良い現在の習慣[22ページ]RFC4786Anycast BCP2006年12月
[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.、ラーソン、M.、マッシー、D.、およびS.ローズ、「DNSセキュリティ序論と要件」(RFC4033)は2005を行進させます。
[RIS] "RIPE NCC Routing Information Service (RIS)",
<http://ris.ripe.net>.
[リス] 「熟している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
ジョー・Ableyアフィリアスカナダ、M2P 2A8カナダの社の204--4141ヤング・通りトロント
Phone: +1 416 673 4176 EMail: jabley@ca.afilias.info URI: http://afilias.info/
以下に電話をしてください。 +1 4176年の416 673メール: jabley@ca.afilias.info ユリ: http://afilias.info/
Kurt Erik Lindqvist Netnod Internet Exchange Bellmansgatan 30 118 47 Stockholm Sweden
カートエリックリンクヴィストNetnodインターネット交換Bellmansgatan30 118 47ストックホルムスウェーデン
EMail: kurtis@kurtis.pp.se URI: http://www.netnod.se/
メール: kurtis@kurtis.pp.se ユリ: http://www.netnod.se/
Abley & Lindqvist Best Current Practice [Page 23] RFC 4786 Anycast BCP December 2006
Ableyとリンクヴィスト最も良い現在の習慣[23ページ]RFC4786Anycast BCP2006年12月
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2006).
IETFが信じる著作権(C)(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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機能のための基金は現在、インターネット協会によって提供されます。
Abley & Lindqvist Best Current Practice [Page 24]
AbleyとリンクヴィストBest現在の習慣[24ページ]
一覧
スポンサーリンク
