draft-ietf-grow-anycast-01.txt		draft-ietf-grow-anycast-02.txt
	Network Working Group J. Abley		Network Working Group J. Abley
	Internet-Draft ISC		Internet-Draft ISC
	Expires: January 19, 2006 K. Lindqvist		Expires: April 24, 2006 K. Lindqvist
	Netnod Internet Exchange		Netnod Internet Exchange
	July 18, 2005		October 21, 2005
	Operation of Anycast Services		Operation of Anycast Services
	draft-ietf-grow-anycast-01		draft-ietf-grow-anycast-02
	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 January 19, 2006.		This Internet-Draft will expire on April 24, 2006.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2005).		Copyright (C) The Internet Society (2005).
	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
	skipping to change at page 2, line 24		skipping to change at page 2, line 24
	4. Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7		4. Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
	4.1 Protocol Suitability . . . . . . . . . . . . . . . . . . . 7		4.1 Protocol Suitability . . . . . . . . . . . . . . . . . . . 7
	4.2 Node Placement . . . . . . . . . . . . . . . . . . . . . . 7		4.2 Node Placement . . . . . . . . . . . . . . . . . . . . . . 7
	4.3 Routing Systems . . . . . . . . . . . . . . . . . . . . . 8		4.3 Routing Systems . . . . . . . . . . . . . . . . . . . . . 8
	4.3.1 Anycast within an IGP . . . . . . . . . . . . . . . . 8		4.3.1 Anycast within an IGP . . . . . . . . . . . . . . . . 8
	4.3.2 Anycast within the Global Internet . . . . . . . . . . 9		4.3.2 Anycast within the Global Internet . . . . . . . . . . 9
	4.4 Routing Considerations . . . . . . . . . . . . . . . . . . 9		4.4 Routing Considerations . . . . . . . . . . . . . . . . . . 9
	4.4.1 Signalling Service Availability . . . . . . . . . . . 9		4.4.1 Signalling Service Availability . . . . . . . . . . . 9
	4.4.2 Covering Prefix . . . . . . . . . . . . . . . . . . . 10		4.4.2 Covering Prefix . . . . . . . . . . . . . . . . . . . 10
	4.4.3 Equal-Cost Paths . . . . . . . . . . . . . . . . . . . 10		4.4.3 Equal-Cost Paths . . . . . . . . . . . . . . . . . . . 10
	4.4.4 Route Dampening . . . . . . . . . . . . . . . . . . . 11		4.4.4 Route Dampening . . . . . . . . . . . . . . . . . . . 12
	4.4.5 Reverse Path Forwarding Checks . . . . . . . . . . . . 12		4.4.5 Reverse Path Forwarding Checks . . . . . . . . . . . . 13
	4.4.6 Propagation Scope . . . . . . . . . . . . . . . . . . 12		4.4.6 Propagation Scope . . . . . . . . . . . . . . . . . . 13
	4.4.7 Other Peoples' Networks . . . . . . . . . . . . . . . 13		4.4.7 Other Peoples' Networks . . . . . . . . . . . . . . . 14
	4.4.8 Aggregation Risks . . . . . . . . . . . . . . . . . . 14		4.4.8 Aggregation Risks . . . . . . . . . . . . . . . . . . 14
	4.5 Addressing Considerations . . . . . . . . . . . . . . . . 14		4.5 Addressing Considerations . . . . . . . . . . . . . . . . 15
	4.6 Data Synchronisation . . . . . . . . . . . . . . . . . . . 15		4.6 Data Synchronisation . . . . . . . . . . . . . . . . . . . 15
	4.7 Node Autonomy . . . . . . . . . . . . . . . . . . . . . . 15		4.7 Node Autonomy . . . . . . . . . . . . . . . . . . . . . . 16
	4.8 Multi-Service Nodes . . . . . . . . . . . . . . . . . . . 16		4.8 Multi-Service Nodes . . . . . . . . . . . . . . . . . . . 16
	4.8.1 Multiple Covering Prefixes . . . . . . . . . . . . . . 16		4.8.1 Multiple Covering Prefixes . . . . . . . . . . . . . . 17
	4.8.2 Pessimistic Withdrawal . . . . . . . . . . . . . . . . 16		4.8.2 Pessimistic Withdrawal . . . . . . . . . . . . . . . . 17
	4.8.3 Intra-Node Interior Connectivity . . . . . . . . . . . 17		4.8.3 Intra-Node Interior Connectivity . . . . . . . . . . . 17
	5. Service Management . . . . . . . . . . . . . . . . . . . . . . 18		5. Service Management . . . . . . . . . . . . . . . . . . . . . . 19
	5.1 Monitoring . . . . . . . . . . . . . . . . . . . . . . . . 18		5.1 Monitoring . . . . . . . . . . . . . . . . . . . . . . . . 19
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 19		6. Security Considerations . . . . . . . . . . . . . . . . . . . 20
	6.1 Denial-of-Service Attack Mitigation . . . . . . . . . . . 19		6.1 Denial-of-Service Attack Mitigation . . . . . . . . . . . 20
	6.2 Service Compromise . . . . . . . . . . . . . . . . . . . . 19		6.2 Service Compromise . . . . . . . . . . . . . . . . . . . . 20
	6.3 Service Hijacking . . . . . . . . . . . . . . . . . . . . 19		6.3 Service Hijacking . . . . . . . . . . . . . . . . . . . . 20
	7. Protocol Considerations . . . . . . . . . . . . . . . . . . . 20		7. Protocol Considerations . . . . . . . . . . . . . . . . . . . 21
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
	9. Acknowlegements . . . . . . . . . . . . . . . . . . . . . . . 22		9. Acknowlegements . . . . . . . . . . . . . . . . . . . . . . . 23
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 23		10. References . . . . . . . . . . . . . . . . . . . . . . . . . 24
	10.1 Normative References . . . . . . . . . . . . . . . . . . . 23		10.1 Normative References . . . . . . . . . . . . . . . . . . . 24
	10.2 Informative References . . . . . . . . . . . . . . . . . . 23		10.2 Informative References . . . . . . . . . . . . . . . . . . 24
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 25		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 26
	A. Change History . . . . . . . . . . . . . . . . . . . . . . . . 26		A. Change History . . . . . . . . . . . . . . . . . . . . . . . . 27
	Intellectual Property and Copyright Statements . . . . . . . . 27		Intellectual Property and Copyright Statements . . . . . . . . 28
	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 11, line 10		skipping to change at page 11, line 10
	4.4.3 Equal-Cost Paths		4.4.3 Equal-Cost Paths
	Some routing systems support equal-cost paths to the same		Some routing systems support equal-cost paths to the same
	destination. Where multiple, equal-cost paths exist and lead to		destination. Where multiple, equal-cost paths exist and lead to
	different anycast nodes, there is a risk that different request		different anycast nodes, there is a risk that different request
	packets associated with a single transaction might be delivered to		packets associated with a single transaction might be delivered to
	more than one node. Services provided over TCP [RFC0793] necessarily		more than one node. Services provided over TCP [RFC0793] necessarily
	involve transactions with multiple request packets, due to the TCP		involve transactions with multiple request packets, due to the TCP
	setup handshake.		setup handshake.
			For services which are distributed across the global Internet using
			BGP, equal-cost paths are normally not a consideration: BGP's exit
			selection algorithm usually selects a single, consistent exit for a
			single destination regardless of whether multiple candidate paths
			exist. Implementations of BGP exist that support multi-path exit
			selection, however.
	Equal cost paths are commonly supported in IGPs. Multi-node		Equal cost paths are commonly supported in IGPs. Multi-node
	selection for a single transaction can be avoided in most cases by		selection for a single transaction can be avoided in most cases by
	careful consideration of IGP link metrics, or by applying equal-cost		careful consideration of IGP link metrics, or by applying equal-cost
	multi-path (ECMP) selection algorithms which cause a single node to		multi-path (ECMP) selection algorithms which cause a single node to
	be selected for a single multi-packet transaction. For an example of		be selected for a single multi-packet transaction. For an example of
	the use of hash-based ECMP selection in anycast service distribution,		the use of hash-based ECMP selection in anycast service distribution,
	see [ISC-TN-2004-1].		see [ISC-TN-2004-1].
	For services which are distributed across the global Internet using		Other ECMP selection algorithms are commonly available, including
	BGP, equal-cost paths are normally not a consideration: BGP's exit		those in which packets from the same flow are not guaranteed to be
	selection algorithm usually selects a single, consistent exit for a		routed towards the same destination. ECMP algorithms which select a
	single destination regardless of whether multiple candidate paths		route on a per-packet basis rather than per-flow are commonly
	exist. Implementations of BGP exist that support multi-path exit		referred to as performing "Per Packet Load Balancing" (PPLB).
	selection, however, and corner cases where dual selected exits route
	to different nodes are possible. Analysis of the likely incidence of		With respect to anycast service distribution, some uses of PPLB may
	such corner cases for particular distributions of Anycast Nodes are		cause different packets from a single multi-packet transaction sent
	recommended for services which involve multi-packet transactions.		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:
			1. PPLB across multiple, parallel links between the same pair of
			routers should cause no node selection problems;
			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;
			3. PPLB across links to different neighbour ASes where 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.
			The uses of PPLB which 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.
	4.4.4 Route Dampening		4.4.4 Route Dampening
	Frequent advertisements and withdrawals of individual prefixes in BGP		Frequent advertisements and withdrawals of individual prefixes in BGP
	are known as flaps. Rapid flapping can lead to CPU exhaustion on		are known as flaps. Rapid flapping can lead to CPU exhaustion on
	routers quite remote from the source of the instability, and for this		routers quite remote from the source of the instability, and for this
	reason rapid route oscillations are frequently "dampened", as		reason rapid route oscillations are frequently "dampened", as
	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
	skipping to change at page 15, line 10		skipping to change at page 15, line 44
	For an IPv4-numbered service deployed across the Internet, for		For an IPv4-numbered service deployed across the Internet, for
	example, an address might be chosen from a block where the minimum		example, an address might be chosen from a block where the minimum
	RIR allocation size is 24 bits, and reachability to that address		RIR allocation size is 24 bits, and reachability to that address
	might be provided by originating the covering 24-bit prefix.		might be provided by originating the covering 24-bit prefix.
	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 rechability to		locally-unused [RFC1918] address might be chosen, and rechability 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 [RFC3513]. As such the guidelines		differently from unicast addresses. As such the guidelines presented
	presented for IPv4 with respect to address suitability follow for		for IPv4 with respect to address suitability follow for IPv6. Note
	IPv6.		that historical prohibitions on anycast distribution of services over
			IPv6 have been removed from the IPv6 addressing specification in
			[I-D.ietf-ipv6-addr-arch-v4].
	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 22, line 9		skipping to change at page 23, line 9
	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. Acknowlegements		9. Acknowlegements
	The authors gratefully acknowledge the contributions from various		The authors gratefully acknowledge the contributions from various
	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 and Ben Black.		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		[RFC1771] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4
	(BGP-4)", RFC 1771, March 1995.		(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.
	[RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6
	(IPv6) Addressing Architecture", RFC 3513, April 2003.
	[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.
	10.2 Informative References		10.2 Informative References
			[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>.
			[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>.
	[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>.
			[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>.
	[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.
	[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.
	skipping to change at page 26, line 17		skipping to change at page 27, line 17
	This section should be removed before publication.		This section should be removed before publication.
	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-ietd-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-
			addr-arch-v4] added (in the RFC editor's queue at the time of
			writing; reference should be updated to an RFC number when
			available). Added commentary on per-packet load balancing.
	Intellectual Property Statement		Intellectual Property Statement
	The IETF takes no position regarding the validity or scope of any		The IETF takes no position regarding the validity or scope of any
	Intellectual Property Rights or other rights that might be claimed to		Intellectual Property Rights or other rights that might be claimed to
	pertain to the implementation or use of the technology described in		pertain to the implementation or use of the technology described in
	this document or the extent to which any license under such rights		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		might or might not be available; nor does it represent that it has
	made any independent effort to identify any such rights. Information		made any independent effort to identify any such rights. Information
	on the procedures with respect to rights in RFC documents can be		on the procedures with respect to rights in RFC documents can be
	found in BCP 78 and BCP 79.		found in BCP 78 and BCP 79.
End of changes. 19 change blocks.
	45 lines changed or deleted		105 lines changed or added
This html diff was produced by rfcdiff 1.27, available from http://www.levkowetz.com/ietf/tools/rfcdiff/