< draft-ietf-grow-anycast-03.txt   draft-ietf-grow-anycast-04.txt >
Network Working Group J. Abley Network Working Group J. Abley
Internet-Draft ISC Internet-Draft Afilias Canada
Expires: July 28, 2006 K. Lindqvist Expires: July 5, 2006 K. Lindqvist
Netnod Internet Exchange Netnod Internet Exchange
January 24, 2006 January 2006
Operation of Anycast Services Operation of Anycast Services
draft-ietf-grow-anycast-03 draft-ietf-grow-anycast-04
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 35 skipping to change at page 1, line 35
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on July 28, 2006. This Internet-Draft will expire on July 5, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
Abstract Abstract
As the Internet has grown, and as systems and networked services As the Internet has grown, and as systems and networked services
within enterprises have become more pervasive, many services with within enterprises have become more pervasive, many services with
high availability requirements have emerged. These requirements have high availability requirements have emerged. These requirements have
increased the demands on the reliability of the infrastructure on increased the demands on the reliability of the infrastructure on
which those services rely. which those services rely.
Various techniques have been employed to increase the availability of Various techniques have been employed to increase the availability of
services deployed on the Internet. This document presents commentary services deployed on the Internet. This document presents commentary
and recommendations for distribution of services using anycast. and recommendations for distribution of services using anycast.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Anycast Service Distribution . . . . . . . . . . . . . . . . . 5 3. Anycast Service Distribution . . . . . . . . . . . . . . . . . 6
3.1. General Description . . . . . . . . . . . . . . . . . . . 5 3.1. General Description . . . . . . . . . . . . . . . . . . . 6
3.2. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.2. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4. Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.1. Protocol Suitability . . . . . . . . . . . . . . . . . . . 7 4.1. Protocol Suitability . . . . . . . . . . . . . . . . . . . 8
4.2. Node Placement . . . . . . . . . . . . . . . . . . . . . . 7 4.2. Node Placement . . . . . . . . . . . . . . . . . . . . . . 8
4.3. Routing Systems . . . . . . . . . . . . . . . . . . . . . 8 4.3. Routing Systems . . . . . . . . . . . . . . . . . . . . . 9
4.3.1. Anycast within an IGP . . . . . . . . . . . . . . . . 8 4.3.1. Anycast within an IGP . . . . . . . . . . . . . . . . 9
4.3.2. Anycast within the Global Internet . . . . . . . . . . 9 4.3.2. Anycast within the Global Internet . . . . . . . . . . 10
4.4. Routing Considerations . . . . . . . . . . . . . . . . . . 9 4.4. Routing Considerations . . . . . . . . . . . . . . . . . . 10
4.4.1. Signalling Service Availability . . . . . . . . . . . 9 4.4.1. Signalling Service Availability . . . . . . . . . . . 10
4.4.2. Covering Prefix . . . . . . . . . . . . . . . . . . . 10 4.4.2. Covering Prefix . . . . . . . . . . . . . . . . . . . 11
4.4.3. Equal-Cost Paths . . . . . . . . . . . . . . . . . . . 10 4.4.3. Equal-Cost Paths . . . . . . . . . . . . . . . . . . . 11
4.4.4. Route Dampening . . . . . . . . . . . . . . . . . . . 12 4.4.4. Route Dampening . . . . . . . . . . . . . . . . . . . 13
4.4.5. Reverse Path Forwarding Checks . . . . . . . . . . . . 13 4.4.5. Reverse Path Forwarding Checks . . . . . . . . . . . . 14
4.4.6. Propagation Scope . . . . . . . . . . . . . . . . . . 13 4.4.6. Propagation Scope . . . . . . . . . . . . . . . . . . 14
4.4.7. Other Peoples' Networks . . . . . . . . . . . . . . . 14 4.4.7. Other Peoples' Networks . . . . . . . . . . . . . . . 15
4.4.8. Aggregation Risks . . . . . . . . . . . . . . . . . . 14 4.4.8. Aggregation Risks . . . . . . . . . . . . . . . . . . 15
4.5. Addressing Considerations . . . . . . . . . . . . . . . . 15 4.5. Addressing Considerations . . . . . . . . . . . . . . . . 16
4.6. Data Synchronisation . . . . . . . . . . . . . . . . . . . 15 4.6. Data Synchronisation . . . . . . . . . . . . . . . . . . . 16
4.7. Node Autonomy . . . . . . . . . . . . . . . . . . . . . . 16 4.7. Node Autonomy . . . . . . . . . . . . . . . . . . . . . . 17
4.8. Multi-Service Nodes . . . . . . . . . . . . . . . . . . . 17 4.8. Multi-Service Nodes . . . . . . . . . . . . . . . . . . . 18
4.8.1. Multiple Covering Prefixes . . . . . . . . . . . . . . 17 4.8.1. Multiple Covering Prefixes . . . . . . . . . . . . . . 18
4.8.2. Pessimistic Withdrawal . . . . . . . . . . . . . . . . 17 4.8.2. Pessimistic Withdrawal . . . . . . . . . . . . . . . . 18
4.8.3. Intra-Node Interior Connectivity . . . . . . . . . . . 18 4.8.3. Intra-Node Interior Connectivity . . . . . . . . . . . 19
5. Service Management . . . . . . . . . . . . . . . . . . . . . . 19 4.9. Node Identification by Clients . . . . . . . . . . . . . . 19
5.1. Monitoring . . . . . . . . . . . . . . . . . . . . . . . . 19 5. Service Management . . . . . . . . . . . . . . . . . . . . . . 20
6. Security Considerations . . . . . . . . . . . . . . . . . . . 20 5.1. Monitoring . . . . . . . . . . . . . . . . . . . . . . . . 20
6.1. Denial-of-Service Attack Mitigation . . . . . . . . . . . 20 6. Security Considerations . . . . . . . . . . . . . . . . . . . 21
6.2. Service Compromise . . . . . . . . . . . . . . . . . . . . 20 6.1. Denial-of-Service Attack Mitigation . . . . . . . . . . . 21
6.3. Service Hijacking . . . . . . . . . . . . . . . . . . . . 20 6.2. Service Compromise . . . . . . . . . . . . . . . . . . . . 21
7. Protocol Considerations . . . . . . . . . . . . . . . . . . . 21 6.3. Service Hijacking . . . . . . . . . . . . . . . . . . . . 21
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 7. Protocol Considerations . . . . . . . . . . . . . . . . . . . 23
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25
10.1. Normative References . . . . . . . . . . . . . . . . . . . 24 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
10.2. Informative References . . . . . . . . . . . . . . . . . . 24 10.1. Normative References . . . . . . . . . . . . . . . . . . . 26
Appendix A. Change History . . . . . . . . . . . . . . . . . . . 27 10.2. Informative References . . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28 Appendix A. Change History . . . . . . . . . . . . . . . . . . . 29
Intellectual Property and Copyright Statements . . . . . . . . . . 29 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30
Intellectual Property and Copyright Statements . . . . . . . . . . 31
1. Introduction 1. Introduction
To distribute a service using anycast, the service is first To distribute a service using anycast, the service is first
associated with a stable set of IP addresses, and reachability to associated with a stable set of IP addresses, and reachability to
those addresses is advertised in a routing system from multiple, those addresses is advertised in a routing system from multiple,
independent service nodes. Various techniques for anycast deployment independent service nodes. Various techniques for anycast deployment
of services are discussed in [RFC1546], [ISC-TN-2003-1] and [ISC-TN- of services are discussed in [RFC1546], [ISC-TN-2003-1] and [ISC-TN-
2004-1]. 2004-1].
skipping to change at page 3, line 34 skipping to change at page 4, line 34
years. The use of anycast is not limited to the DNS, although the years. The use of anycast is not limited to the DNS, although the
use of anycast imposes some additional limitations on the nature of use of anycast imposes some additional limitations on the nature of
the service being distributed, including transaction longevity, the service being distributed, including transaction longevity,
transaction state held on servers and data synchronisation transaction state held on servers and data synchronisation
capabilities. capabilities.
Although anycast is conceptually simple, its implementation Although anycast is conceptually simple, its implementation
introduces some pitfalls for operation of services. For example, introduces some pitfalls for operation of services. For example,
monitoring the availability of the service becomes more difficult; monitoring the availability of the service becomes more difficult;
the observed availability changes according to the location of the the observed availability changes according to the location of the
client within the network, and the client catchment of individual client within the network, and the population of clients using
anycast nodes is neither static, nor reliably deterministic. individual anycast nodes is neither static, nor reliably
deterministic.
This document will describe the use of anycast for both local scope This document will describe the use of anycast for both local scope
distribution of services using an Interior Gateway Protocol (IGP) and distribution of services using an Interior Gateway Protocol (IGP) and
global distribution using BGP [RFC1771]. Many of the issues for global distribution using the Border Gateway Protocol (BGP)
monitoring and data synchronisation are common to both, but [RFC4271]. Many of the issues for monitoring and data
deployment issues differ substantially. synchronisation are common to both, but deployment issues differ
substantially.
2. Terminology 2. Terminology
Service Address: an IP address associated with a particular service Service Address: an IP address associated with a particular service
(e.g. the destination address used by DNS resolvers to reach a (e.g. the destination address used by DNS resolvers to reach a
particular authority server). particular authority server).
Anycast: the practice of making a particular Service Address Anycast: the practice of making a particular Service Address
available in multiple, discrete, autonomous locations, such that available in multiple, discrete, autonomous locations, such that
datagrams sent are routed to one of several available locations. datagrams sent are routed to one of several available locations.
skipping to change at page 5, line 42 skipping to change at page 6, line 42
Load-balancing between Anycast Nodes is typically difficult to Load-balancing between Anycast Nodes is typically difficult to
achieve (load distribution between nodes is generally unbalanced in achieve (load distribution between nodes is generally unbalanced in
terms of request and traffic load). Distribution of load between terms of request and traffic load). Distribution of load between
nodes for the purposes of reliability, and coarse-grained nodes for the purposes of reliability, and coarse-grained
distribution of load for the purposes of making popular services distribution of load for the purposes of making popular services
scalable can often be achieved, however. scalable can often be achieved, however.
The scale of the routing system through which a service is anycast The scale of the routing system through which a service is anycast
can vary from a small Interior Gateway Protocol (IGP) connecting a can vary from a small Interior Gateway Protocol (IGP) connecting a
small handful of components, to the Border Gateway Protocol (BGP) small handful of components, to the Border Gateway Protocol (BGP)
[RFC1771] connecting the global Internet, depending on the nature of [RFC4271] connecting the global Internet, depending on the nature of
the service distribution that is required. 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 A service may be anycast for a variety of reasons. A number of
common objectives are: common objectives are:
1. Coarse ("unbalanced") distribution of load across nodes, to allow 1. Coarse ("unbalanced") distribution of load across nodes, to allow
infrastructure to scale to increased numbers of queries and to infrastructure to scale to increased numbers of queries and to
accommodate transient query peaks; accommodate transient query peaks;
2. Mitigation of non-distributed denial of service attacks by 2. Mitigation of non-distributed denial of service attacks by
localising damage to single anycast nodes; localising damage to single anycast nodes;
3. Constraint of distributed denial of service attacks or flash 3. Constraint of distributed denial of service attacks or flash
crowds to local regions around anycast nodes (perhaps restricting crowds to local regions around anycast nodes. Anycast
query traffic to local peering links, rather than paid transit distribution of a service provides the opportunity for traffic to
circuits); 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 locate location of 4. To provide additional information to help identify the location
traffic sources in the case of attack (or query) traffic which of traffic sources in the case of attack (or query) traffic which
incorporates spoofed source addresses. This information is incorporates spoofed source addresses. This information is
derived from the property of anycast service distribution that derived from the property of anycast service distribution that
the selection of the Anycast Node used to service a particular the selection of the Anycast Node used to service a particular
query may be related to the topological source of the request. query may be related to the topological source of the request.
5. Improvement of query response time, by reducing the network 5. Improvement of query response time, by reducing the network
distance between client and server with the provision of a local distance between client and server with the provision of a local
Anycast Node. The extent to which query response time is Anycast Node. The extent to which query response time is
improved depends on the way that nodes are selected for the improved depends on the way that nodes are selected for the
clients by the routing system. Topological nearness within the clients by the routing system. Topological nearness within the
skipping to change at page 12, line 30 skipping to change at page 13, line 30
described in [RFC2439]. described in [RFC2439].
A dampened path will be suppressed by routers for an interval which A dampened path will be suppressed by routers for an interval which
increases according to the frequency of the observed oscillation; a increases according to the frequency of the observed oscillation; a
suppressed path will not propagate. Hence a single router can suppressed path will not propagate. Hence a single router can
prevent the propagation of a flapping prefix to the rest of an prevent the propagation of a flapping prefix to the rest of an
autonomous system, affording other routers in the network protection autonomous system, affording other routers in the network protection
from the instability. from the instability.
Some implementations of flap dampening penalise oscillating Some implementations of flap dampening penalise oscillating
advertisements based on the observed AS_PATH, and not on the NLRI. advertisements based on the observed AS_PATH, and not on Network
For this reason, network instability which leads to route flapping Layer Reachability Information (NLRI; see [RFC4271]). For this
from a single anycast node ought not to cause advertisements from reason, network instability which leads to route flapping from a
other nodes (which have different AS_PATH attributes) to be dampened. single anycast node will not generally cause advertisements from
other nodes (which have different AS_PATH attributes) to be dampened
by these implementations.
To limit the opportunity of such implementations to penalise To limit the opportunity of such implementations to penalise
advertisements originating from different Anycast Nodes in response advertisements originating from different Anycast Nodes in response
to oscillations from just a single node, care should be taken to to oscillations from just a single node, care should be taken to
arrange that the AS_PATH attributes on routes from different nodes arrange that the AS_PATH attributes on routes from different nodes
are as diverse as possible. For example, Anycast Nodes should use are as diverse as possible. For example, Anycast Nodes should use
the same origin AS for their advertisements, but might have different the same origin AS for their advertisements, but might have different
upstream ASes. upstream ASes.
Where different implementations of flap dampening are prevalent, Where different implementations of flap dampening are prevalent,
individual nodes' instability may result in stable nodes becoming individual nodes' instability may result in stable nodes becoming
unavailable. In mitigation, the following measures may be useful: unavailable. In mitigation, the following measures may be useful:
1. Judicious deployment of Local Nodes in combination with 1. Judicious deployment of Local Nodes in combination with
especially stable Global Nodes (with high inter-AS path splay, especially stable Global Nodes (with high inter-AS path splay,
redundant hardware, power, etc) may help limit oscillation redundant hardware, power, etc.) may help limit oscillation
problems to the Local Nodes' limited regions of influence; problems to the Local Nodes' limited regions of influence;
2. Aggressive flap-dampening of the service prefix close to the 2. Aggressive flap-dampening of the service prefix close to the
origin (e.g. within an Anycast Node, or in adjacent ASes of each origin (e.g. within an Anycast Node, or in adjacent ASes of each
Anycast Node) may also help reduce the opportunity of remote ASes Anycast Node) may also help reduce the opportunity of remote ASes
to see oscillations at all. to see oscillations at all.
4.4.5. Reverse Path Forwarding Checks 4.4.5. Reverse Path Forwarding Checks
Reverse Path Forwarding (RPF) checks, first described in [RFC2267], Reverse Path Forwarding (RPF) checks, first described in [RFC2267],
skipping to change at page 15, line 46 skipping to change at page 16, line 46
For an IPv4-numbered service deployed within a private network, a For an IPv4-numbered service deployed within a private network, a
locally-unused [RFC1918] address might be chosen, and reachability to locally-unused [RFC1918] address might be chosen, and reachability to
that address might be signalled using a (32-bit) host route. that address might be signalled using a (32-bit) host route.
For IPv6-numbered services, Anycast Addresses are not scoped For IPv6-numbered services, Anycast Addresses are not scoped
differently from unicast addresses. As such the guidelines presented differently from unicast addresses. As such the guidelines presented
for IPv4 with respect to address suitability follow for IPv6. Note for IPv4 with respect to address suitability follow for IPv6. Note
that historical prohibitions on anycast distribution of services over that historical prohibitions on anycast distribution of services over
IPv6 have been removed from the IPv6 addressing specification in IPv6 have been removed from the IPv6 addressing specification in
[I-D.ietf-ipv6-addr-arch-v4]. [RFC4291].
4.6. Data Synchronisation 4.6. Data Synchronisation
Although some services have been deployed in localised form (such Although some services have been deployed in localised form (such
that clients from particular regions are presented with regionally- that clients from particular regions are presented with regionally-
relevant content) many services have the property that responses to relevant content) many services have the property that responses to
client requests should be consistent, regardless of where the request client requests should be consistent, regardless of where the request
originates. For a service distributed using anycast, that implies originates. For a service distributed using anycast, that implies
that different Anycast Nodes must operate in a consistent manner and, that different Anycast Nodes must operate in a consistent manner and,
where that consistent behaviour is based on a data set, that the data where that consistent behaviour is based on a data set, that the data
skipping to change at page 16, line 45 skipping to change at page 17, line 45
The possibility of cascading failure due to load can also be reduced The possibility of cascading failure due to load can also be reduced
by the deployment of both Global and Local Nodes for a single by the deployment of both Global and Local Nodes for a single
service, since the effective fail-over path of traffic is, in service, since the effective fail-over path of traffic is, in
general, from Local Node to Global Node; traffic that might sink one 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 Local Node is unlikely to sink all Local Nodes, except in the most
degenerate cases. degenerate cases.
The chance of cascading failure due to a software defect in an The chance of cascading failure due to a software defect in an
operating system or server can be reduced in many cases by deploying operating system or server can be reduced in many cases by deploying
nodes running different implementations of operating system, server nodes running different implementations of operating system, server
software, routing protocol software, etc, such that a defect which software, routing protocol software, etc., such that a defect which
appears in a single component does not affect the whole system. appears in a single component does not affect the whole system.
It should be noted that these approaches to increase node autonomy It should be noted that these approaches to increase node autonomy
are, to varying degrees, contrary to the practical goals of making a are, to varying degrees, contrary to the practical goals of making a
deployed service straightforward to operate. A service which is deployed service straightforward to operate. A service which is
over-complex is more likely to suffer from operator error than a over-complex is more likely to suffer from operator error than a
service which is more straightforward to run. Careful consideration service which is more straightforward to run. Careful consideration
should be given to all of these aspects so that an appropriate should be given to all of these aspects so that an appropriate
balance may be found. balance may be found.
skipping to change at page 19, line 5 skipping to change at page 19, line 27
In the event that some local services in a node are down and the node In the event that some local services in a node are down and the node
is disconnected from other nodes, continued advertisement of the is disconnected from other nodes, continued advertisement of the
covering prefix might cause requests to become black-holed. covering prefix might cause requests to become black-holed.
This approach allows reasonable address utilisation of the netblock This approach allows reasonable address utilisation of the netblock
covered by the announced prefix, at the expense of reduced autonomy covered by the announced prefix, at the expense of reduced autonomy
of individual nodes; the IGP in which all nodes participate can be of individual nodes; the IGP in which all nodes participate can be
viewed as a single point of failure. viewed as a single point of failure.
4.9. Node Identification by Clients
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 which is handling a client's request.
In some cases, common network-level diagnostic tools such as
traceroute may be sufficient to identify the node being used by a
client. However, the use of such tools may be beyond the abilities
of users at the client side of a transaction, and in any case network
conditions at the time of the problem may change by the time such
tools are exercised.
Troubleshooting problems with anycast services is greatly facilitated
if mechanisms to determine the identity of a node are designed in to
the protocol. Examples of such mechanisms include the NSID option in
DNS [I-D.ietf-dnsext-nsid] and the common inclusion of hostname
information in SMTP servers' initial greeting at session initiation
[RFC2821].
Provision of such in-band mechanisms for node identification is
strongly recommended for services to be distributed using anycast.
5. Service Management 5. Service Management
5.1. Monitoring 5.1. Monitoring
Monitoring a service which is distributed is more complex than Monitoring a service which is distributed is more complex than
monitoring a non-distributed service, since the observed accuracy and monitoring a non-distributed service, since the observed accuracy and
availability of the service is, in general, different when viewed availability of the service is, in general, different when viewed
from clients attached to different parts of the network. When a from clients attached to different parts of the network. When a
problem is identified, it is also not always obvious which node problem is identified, it is also not always obvious which node
served the request, and hence which node is malfunctioning. served the request, and hence which node is malfunctioning.
skipping to change at page 19, line 31 skipping to change at page 20, line 31
DNS. DNS.
Monitoring the routing system (from a variety of places, in the case Monitoring the routing system (from a variety of places, in the case
of routing systems where perspective is relevant) can also provide of routing systems where perspective is relevant) can also provide
useful diagnostics for troubleshooting service availability. This useful diagnostics for troubleshooting service availability. This
can be achieved using dedicated probes, or public route measurement can be achieved using dedicated probes, or public route measurement
facilities on the Internet such as the RIPE NCC Routing Information facilities on the Internet such as the RIPE NCC Routing Information
Service [2] and the University of Oregon Route Views Project [3]. Service [2] and the University of Oregon Route Views Project [3].
Monitoring the health of the component devices in an Anycast Monitoring the health of the component devices in an Anycast
deployment of a service (hosts, routers, etc) is straightforward, and deployment of a service (hosts, routers, etc.) is straightforward,
can be achieved using the same tools and techniques commonly used to and can be achieved using the same tools and techniques commonly used
manage other network-connected infrastructure, without the additional to manage other network-connected infrastructure, without the
complexity involved in monitoring Anycast service addresses. additional complexity involved in monitoring Anycast service
addresses.
6. Security Considerations 6. Security Considerations
6.1. Denial-of-Service Attack Mitigation 6.1. Denial-of-Service Attack Mitigation
This document describes mechanisms for deploying services on the This document describes mechanisms for deploying services on the
Internet which can be used to mitigate vulnerability to attack: Internet which can be used to mitigate vulnerability to attack:
1. An Anycast Node can act as a sink for attack traffic originated 1. An Anycast Node can act as a sink for attack traffic originated
within its sphere of influence, preventing nodes elsewhere from within its sphere of influence, preventing nodes elsewhere from
skipping to change at page 21, line 5 skipping to change at page 21, line 48
doing so capture legitimate request traffic or process requests in a doing so capture legitimate request traffic or process requests in a
manner which compromises the service (or both). A rogue Anycast Node manner which compromises the service (or both). A rogue Anycast Node
might be difficult to detect by clients or by the operator of the might be difficult to detect by clients or by the operator of the
service. service.
The risk of service hijacking by manipulation of the routing system The risk of service hijacking by manipulation of the routing system
exists regardless of whether a service is distributed using anycast. exists regardless of whether a service is distributed using anycast.
However, the fact that legitimate Anycast Nodes are observable in the However, the fact that legitimate Anycast Nodes are observable in the
routing system may make it more difficult to detect rogue nodes. routing system may make it more difficult to detect rogue nodes.
Many protocols which 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], [RFC2487]) or
message (e.g. [RFC4033], [RFC2311]) levels. Protocols which 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.
7. Protocol Considerations 7. Protocol Considerations
This document does not impose any protocol considerations. This document does not impose any protocol considerations.
8. IANA Considerations 8. IANA Considerations
This document requests no action from IANA. This document requests no action from IANA.
9. Acknowledgements 9. Acknowledgements
skipping to change at page 24, line 9 skipping to change at page 26, line 9
participants of the grow working group, and in particular Geoff participants of the grow working group, and in particular Geoff
Huston, Pekka Savola, Danny McPherson, Ben Black and Alan Barrett. Huston, Pekka Savola, Danny McPherson, Ben Black and Alan Barrett.
This work was supported by the US National Science Foundation This work was supported by the US National Science Foundation
(research grant SCI-0427144) and DNS-OARC. (research grant SCI-0427144) and DNS-OARC.
10. References 10. References
10.1. Normative References 10.1. Normative References
[I-D.ietf-ipv6-addr-arch-v4]
Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", draft-ietf-ipv6-addr-arch-v4-04 (work in
progress), May 2005.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, [RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, September 1981. RFC 793, September 1981.
[RFC1771] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4
(BGP-4)", RFC 1771, March 1995.
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
E. Lear, "Address Allocation for Private Internets", E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, February 1996. BCP 5, RFC 1918, February 1996.
[RFC1997] Chandrasekeran, R., Traina, P., and T. Li, "BGP [RFC1997] Chandrasekeran, R., Traina, P., and T. Li, "BGP
Communities Attribute", RFC 1997, August 1996. Communities Attribute", RFC 1997, August 1996.
[RFC2439] Villamizar, C., Chandra, R., and R. Govindan, "BGP Route [RFC2439] Villamizar, C., Chandra, R., and R. Govindan, "BGP Route
Flap Damping", RFC 2439, November 1998. Flap Damping", RFC 2439, November 1998.
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", BCP 38, RFC 2827, May 2000. Address Spoofing", BCP 38, RFC 2827, May 2000.
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
Networks", BCP 84, RFC 3704, March 2004. Networks", BCP 84, RFC 3704, March 2004.
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006.
10.2. Informative References 10.2. Informative References
[Allman2000] [Allman2000]
Allman, M. and E. Blanton, "On Making TCP More Robust to Allman, M. and E. Blanton, "On Making TCP More Robust to
Packet Reordering", January 2000, Packet Reordering", January 2000,
<http://www.icir.org/mallman/papers/tcp-reorder-ccr.ps>. <http://www.icir.org/mallman/papers/tcp-reorder-ccr.ps>.
[Fomenkov2004] [Fomenkov2004]
Fomenkov, M., Keys, K., Moore, D., and k. claffy, Fomenkov, M., Keys, K., Moore, D., and k. claffy,
"Longitudinal Study of Internet Traffic from 1999-2003", "Longitudinal Study of Internet Traffic from 1999-2003",
January 2004, <http://www.caida.org/outreach/papers/2003/ January 2004, <http://www.caida.org/outreach/papers/2003/
nlanr/nlanr_overview.pdf>. nlanr/nlanr_overview.pdf>.
[I-D.ietf-dnsext-nsid]
Austein, R., "DNS Name Server Identifier Option (NSID)",
draft-ietf-dnsext-nsid-02 (work in progress), June 2006.
[ISC-TN-2003-1] [ISC-TN-2003-1]
Abley, J., "Hierarchical Anycast for Global Service Abley, J., "Hierarchical Anycast for Global Service
Distribution", March 2003, Distribution", March 2003,
<http://www.isc.org/pubs/tn/isc-tn-2003-1.html>. <http://www.isc.org/pubs/tn/isc-tn-2003-1.html>.
[ISC-TN-2004-1] [ISC-TN-2004-1]
Abley, J., "A Software Approach to Distributing Requests Abley, J., "A Software Approach to Distributing Requests
for DNS Service using GNU Zebra, ISC BIND 9 and FreeBSD", for DNS Service using GNU Zebra, ISC BIND 9 and FreeBSD",
March 2004, March 2004,
<http://www.isc.org/pubs/tn/isc-tn-2004-1.html>. <http://www.isc.org/pubs/tn/isc-tn-2004-1.html>.
skipping to change at page 25, line 25 skipping to change at page 27, line 27
September 2000, <http://www.caida.org/outreach/papers/ September 2000, <http://www.caida.org/outreach/papers/
2000/AIX0005/AIX0005.pdf>. 2000/AIX0005/AIX0005.pdf>.
[RFC1546] Partridge, C., Mendez, T., and W. Milliken, "Host [RFC1546] Partridge, C., Mendez, T., and W. Milliken, "Host
Anycasting Service", RFC 1546, November 1993. Anycasting Service", RFC 1546, November 1993.
[RFC2267] Ferguson, P. and D. Senie, "Network Ingress Filtering: [RFC2267] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", RFC 2267, January 1998. Address Spoofing", RFC 2267, January 1998.
[RFC2311] Dusse, S., Hoffman, P., Ramsdell, B., Lundblade, L., and
L. Repka, "S/MIME Version 2 Message Specification",
RFC 2311, March 1998.
[RFC2487] Hoffman, P., "SMTP Service Extension for Secure SMTP over
TLS", RFC 2487, January 1999.
[RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
April 2001.
[RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D., and B.
Wellington, "Secret Key Transaction Authentication for DNS
(TSIG)", RFC 2845, May 2000.
[RFC3765] Huston, G., "NOPEER Community for Border Gateway Protocol [RFC3765] Huston, G., "NOPEER Community for Border Gateway Protocol
(BGP) Route Scope Control", RFC 3765, April 2004. (BGP) Route Scope Control", RFC 3765, April 2004.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements",
RFC 4033, March 2005.
URIs URIs
[1] <http://dnsmon.ripe.net/> [1] <http://dnsmon.ripe.net/>
[2] <http://ris.ripe.net> [2] <http://ris.ripe.net>
[3] <http://www.route-views.org> [3] <http://www.route-views.org>
Appendix A. Change History Appendix A. Change History
This section should be removed before publication. This section should be removed before publication.
Intended category: BCP.
draft-kurtis-anycast-bcp-00: Initial draft. Discussed at IETF 61 in draft-kurtis-anycast-bcp-00: Initial draft. Discussed at IETF 61 in
the grow meeting and adopted as a working group document shortly the grow meeting and adopted as a working group document shortly
afterwards. afterwards.
draft-ietf-grow-anycast-00: Missing and empty sections completed; draft-ietf-grow-anycast-00: Missing and empty sections completed;
some structural reorganisation; general wordsmithing. Document some structural reorganisation; general wordsmithing. Document
discussed at IETF 62. discussed at IETF 62.
draft-ietf-grow-anycast-01: This appendix added; acknowledgements draft-ietf-grow-anycast-01: This appendix added; acknowledgements
section added; commentary on RFC3513 prohibition of anycast on section added; commentary on RFC3513 prohibition of anycast on
hosts removed; minor sentence re-casting and related jiggery- hosts removed; minor sentence re-casting and related jiggery-
pokery. This revision published for discussion at IETF 63. pokery. This revision published for discussion at IETF 63.
draft-ietf-grow-anycast-02: Normative reference to [I-D.ietf-ipv6- draft-ietf-grow-anycast-02: Normative reference to
addr-arch-v4] added (in the RFC editor's queue at the time of draft-ietf-ipv6-addr-arch-v4" added (in the RFC editor's queue at
writing; reference should be updated to an RFC number when the time of writing; reference should be updated to an RFC number
available). Added commentary on per-packet load balancing. when available). Added commentary on per-packet load balancing.
draft-ietf-grow-anycast-03: Editorial changes and language clean-up draft-ietf-grow-anycast-03: Editorial changes and language clean-up
at the request of the IESG. at the request of the IESG.
draftt-ietf-grow-anycast-04: Replaced reference to RFC1771 with a
reference to RFC4271. Replaced reference to
draft-ietf-ipv6-addr-arch-v4 with a reference to RFC 4291.
Changed author address for Abley. Wordsmithing in response to
Gen-ART review by Sharon Chrisholm and Secdir review by Rob
Austein. Added Section 4.9 at the suggestion of Rob Austein.
Authors' Addresses Authors' Addresses
Joe Abley Joe Abley
Internet Systems Consortium, Inc. Afilias Canada, Corp.
950 Charter Street 204 - 4141 Yonge Street
Redwood City, CA 94063 Toronto, ON M2P 2A8
USA Canada
Phone: +1 650 423 1317 Phone: +1 416 673 4176
Email: jabley@isc.org Email: jabley@ca.afilias.info
URI: http://www.isc.org/ URI: http://afilias.info/
Kurt Erik Lindqvist Kurt Erik Lindqvist
Netnod Internet Exchange Netnod Internet Exchange
Bellmansgatan 30 Bellmansgatan 30
118 47 Stockholm 118 47 Stockholm
Sweden Sweden
Email: kurtis@kurtis.pp.se Email: kurtis@kurtis.pp.se
URI: http://www.netnod.se/ URI: http://www.netnod.se/
 End of changes. 28 change blocks. 
88 lines changed or deleted 159 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/