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],
	are commonly deployed as part of ingress interface packet filters on		are commonly deployed as part of ingress interface packet filters on
	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.32. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/