< draft-ietf-ngtrans-6to4anycast-02.txt		draft-ietf-ngtrans-6to4anycast-03.txt >
	INTERNET DRAFT C. Huitema		A new Request for Comments is now available in online RFC libraries.
	<draft-ietf-ngtrans-6to4anycast-02.txt> Microsoft
	Expires August 19, 2001 February 19, 2001
	An anycast prefix for 6to4 relay routers
	Status of this memo
	This document is an Internet-Draft and is in full conformance with
	all provisions of Section 10 of RFC2026.
	This document is an Internet-Draft. Internet-Drafts are working
	documents of the Internet Engineering Task Force (IETF), its areas,
	and its working groups. Note that other groups may also distribute
	working documents as Internet-Drafts.
	Internet-Drafts are draft documents valid for a maximum of six
	months and may be updated, replaced, or obsoleted by other documents
	at any time. It is inappropriate to use Internet- Drafts as
	reference material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.
	Abstract
	The operation of 6to4 routers requires either that the routers
	participate in IPv6 inter-domain routing, or that the routers be
	provisioned with a default route. This memo proposes a standard
	method to define the default route. It introduces the IANA assigned
	"6to4 Relay anycast prefix" from which 6to4 routers can derive the
	static "6to4 anycast address". In order to enable efficient
	management of the "6to4 Relay anycast prefix" in IPv4 inter-domain
	routing, this memo also documents the reservation by IANA of a "6to4
	Autonomous System ID." With this definition, the proposed scheme
	guarantees that 6to4 packets will be automatically routed to the
	nearest available router. It allows the managers of the 6to4 relay
	routers to control the sources authorized to use their resource. It
	makes it easy to set up a large number of 6to4 relay routers, thus
	enabling scalability.
	1 Introduction
	According to [RFC3056], there are two deployment options for a 6to4
	routing domain, depending on whether or not the domain is using an
	IPv6 exterior routing protocol. If a routing protocol is used, then
	the 6to4 routers acquire routes to all existing IPv6 networks
	through the combination of EGP and IGP. If no IPv6 exterior routing
	protocol is used, the 6to4 routers using a given relay router each
	have a default IPv6 route pointing to the relay router. This second
	INTERNET DRAFT Anycast Prefix for 6to4
	case is typically used by small networks; for these networks,
	finding and configuring the default route is in practice a
	significant hurdle. In addition, even when the managers of these
	networks find an available route, this route often points to a
	router on the other side of the Internet, leading to very poor
	performance.
	This memo introduces a "6to4 anycast address" in order to simplify
	the configuration of 6to4 routers. It also defines how this address
	will be used by 6to4 relay routers, how the corresponding "6to4
	anycast prefix" will be advertised in the IGP and in the EGP. The
	memo documents the reservation by IANA of the "6to4 relay anycast
	prefix" and of a "6to4 Autonomous System ID."
	2 Definitions
	This memo uses the definitions introduced in [RFC3056], in
	particular the definition of a 6to4 router and a 6to4 Relay Router.
	It adds the definition of the 6to4 Relay anycast prefix,
	2.1 6to4 router (or 6to4 border router)
	An IPv6 router supporting a 6to4 pseudo-interface. It is normally
	the border router between an IPv6 site and a wide-area IPv4 network.
	2.2 6to4 Relay Router
	A 6to4 router configured to support transit routing between 6to4
	addresses and native IPv6 addresses.
	2.3 6to4 Relay anycast prefix
	An IPv4 address prefix used to advertise an IPv4 route to an
	available 6to4 Relay Router, as defined in this memo.
	The value of this prefix is x.x.x.0/nn [Length and value TBD IANA]
	2.4 6to4 Relay anycast address
	An IPv4 address used to reach the nearest 6to4 Relay Router, as
	defined in this memo.
	The address corresponds to host number 1 in the 6to4 Relay anycast
	prefix, x.x.x.1. [Derived from the 6to4 Relay anycast prefix, TBD
	IANA]
	2.5 6to4 IPv6 relay anycast address
	The IPv6 address derived from the 6to4 Relay anycast address
	according to the rules defined in 6to4, using a null prefix and a
	null host identifier.
	INTERNET DRAFT Anycast Prefix for 6to4
	The value of the address is "2002:XXXX:XX01::". [Derived from the
	6to4 Relay anycast address, TBD IANA]
	2.6 6to4 Autonomous System ID
	A 16-bit Autonomous system ID, for use in BGP in accordance to this
	memo.
	The value of the 6to4 Autonomous System ID is YYYY. [TBD IANA]
	3 Model, requirements
	Operation of 6to4 routers in domains that don't run an IPv6 EGP
	requires that these routers be configured with a default route to
	the IPv6 Internet. This route will be expressed as a 6to4 address.
	The packets bound to this route will be encapsulated in IPv4 whose
	source will be an IPv4 address associated to the 6to4 router, and
	whose destination will be the IPv4 address that is extracted from
	the default route. We want to arrive at a model of operation in
	which the configuration is automatic.
	It should also be easy to set up a large number of 6to4 relay
	routers, in order to cope with the demand. The discovery of the
	nearest relay router should be automatic; if a router fails, the
	traffic should be automatically redirected to the nearest available
	router. The managers of the 6to4 relay routers should be able to
	control the sources authorized to use their resource.
	4 Description of the solution
	4.1 Default route in the 6to4 routers
	The 6to4 routers are configured with the default IPv6 route (::/0)
	pointing to the 6to4 IPv6 anycast address.
	4.2 Behavior of 6to4 relay routers
	The 6to4 relay routers that follow the specification of this memo
	shall advertise the 6to4 anycast prefix, using the IGP of their IPv4
	autonomous system, as if it where a connection to an external
	network.
	The 6to4 relay routers that advertise the 6to4 anycast prefix will
	receive packets bound to the 6to4 anycast address. They will relay
	these packets to the IPv6 Internet, as specified in [RFC3056].
	4.3 Interaction with the EGP
	If the managers of an IPv4 autonomous domain that includes 6to4
	relay routers want to make these routers available to neighbor ASes,
	they will advertise reachability of the 6to4 anycast prefix. When
	this advertisement is done using BGP, the AS path leading to the
	INTERNET DRAFT Anycast Prefix for 6to4
	6to4 anycast prefix shall include the identifier of the local AS and
	the 6to4 Autonomous System ID.
	The path to the 6to4 anycast prefix may be propagated using standard
	EGP procedures. The whole v6 network will appear to v4 as a single
	AS, with multiple peering points scattered over the whole Internet.
	5 Discussion of the solution
	The initial surfacing of the proposal in the NGTRANS working group
	helped us discover a number of issues, such as scaling concerns, the
	size of the address prefix, the need for an AS number, and concerns
	about risking to stay too long in a transition state.
	5.1 Does it scale?
	With the proposed scheme, it is easy to first deploy a small number
	of relay routers, which will carry the limited 6to4 traffic during
	the initial phases of IPv6 deployment. The routes to these routers
	will be propagated according to standard peering agreements.
	As the demand for IPv6 increases, we expect that more ISPs will
	deploy 6to4 relay routers. Standard IPv4 routing procedures will
	direct the traffic to the nearest relay router, assuring good
	performance.
	5.2 Discovery and failover
	The 6to4 routers send packets bound to the v6 Internet by tunneling
	them to the 6to4 anycast address. These packets will reach the
	closest 6to4 relay router provided by their ISP, or by the closest
	ISP according to inter-domain routing.
	The routes to the relay routers will be propagated according to
	standard IPv4 routing rules. This ensures automatic discovery.
	If a 6to4 relay router somehow breaks, or loses connectivity to the
	v6 Internet, it will cease to advertise reachability of the 6to4
	anycast prefix. At that point, the local IGP will automatically
	compute a route towards the "next best" 6to4 relay router.
	5.3 Access control
	Only those ASes that run 6to4 relay routers and are willing to
	provide access to the v6 network announce a path to the 6to4 anycast
	prefix. They can use the existing structure of peering and transit
	agreements to control to whom they are willing to provide service,
	and possibly to charge for the service.
	5.4 Why do we need a large prefix"
	In theory, a single IP address, a.k.a. a /32 prefix, would be
	INTERNET DRAFT Anycast Prefix for 6to4
	sufficient: all IGPs, and even BGP, can carry routes that are
	arbitrarily specific. In practice, however, such routes are almost
	guaranteed not to work.
	The size of the routing table is of great concern for the managers
	of Internet "default free" networks: they don't want to waste a
	routing entry, which is an important resource, for the sole benefit
	of a small number of Internet nodes. Many have put in place filters
	that automatically drop the routes that are too specific; most of
	these filters are expressed as a function of the length of the
	address prefix, such as "my network will not accept advertisements
	for a network that is smaller than a /19." The actual limit may vary
	from network to network, and also over time. We consider that a /16,
	from the old class B, would be very safe.
	It could indeed be argued that using a large network is a waste of
	the precious addressing resource. However, this is a waste for the
	good cause of actually moving to IPv6, i.e. providing a real relief
	to the address exhaustion problem.
	5.5 Why do we need a specific AS number?
	Erroneous advertisements are a frequent source of errors in inter-
	domain routing. A misconfigured AS will advertise that it can reach
	some random network, divert the traffic, and effectively cut that
	network from some parts of the Internet. As a protection, many
	managers of border routers use databases to check the relation
	between the advertised network and the last hop in the AS path. If
	we use a specific AS to denote that "this is a path to IPv6", then
	we can enter the relation between that AS and the 6to4 access prefix
	in the databases used to check inter-domain routing.
	5.6 Will this slow down the move to IPv6?
	Some have expressed a concern that, while the assignment of an
	anycast address to 6to4 access routers would make life a bit easier,
	it would also tend to leave things in a transition state in
	perpetuity. In fact, we believe that the opposite is true.
	A condition for easy migration out of the "tunnelling" state is that
	it be easy to have connectivity to the "real" IPv6 network; this
	means that people trust that opting for a real IPv6 address will not
	somehow result in lower performances. So the anycast proposal
	actually ensures that we don't stay in a perpetual transition.
	6 Future Work
	Using a default route to reach the IPv6 Internet has a potential
	drawback: the chosen relay may not be on the most direct path to the
	target v6 address. In fact, one might argue that, in the early phase
	of deployment, a relay close to the 6to4 site would probably not be
	the site's ISP or the native destination's ISP... it would probably
	INTERNET DRAFT Anycast Prefix for 6to4
	be some third party ISP's relay which would be used for transit and
	may have lousy connectivity. Using the relay closest to the native
	destination would more closely match the v4 route, and quite
	possibly provide a higher degree of reliability. A potential way to
	deal with this issue is to use a "redirection" procedure, by which
	the 6to4 router learns the most appropriate route for a specific
	destination. This is left for further study.
	7 Security Considerations
	The generic security risks of 6to4 tunneling and the appropriate
	protections are discussed in [RFC3056]. The anycast technique
	introduces an additional risk, that a rogue router or a rogue AS
	would introduce a bogus route to the 6to4 anycast prefix, and thus
	divert the traffic. IPv4 network managers have to guarantee the
	integrity of their routing to the 6to4 anycast prefix in much the
	same way that they guarantee the integrity of the generic v4
	routing.
	8 IANA Considerations
	The purpose of this memo is to document the allocation by IANA of an
	IPv4 prefix dedicated to the 6to4 gateways to the native v6
	Internet, and an autonomous system number dedicated to a pseudo-AS.
	This is a one time effort; there is no need for any recurring
	assignment.
	9 Copyright
	The following copyright notice is copied from RFC 2026 [Bradner,
	1996], Section 10.4, and describes the applicable copyright for this
	document.
	Copyright (C) The Internet Society XXX 0, 0000. All Rights Reserved.
	This document and translations of it may be copied and furnished to
	others, and derivative works that comment on or otherwise explain it
	or assist in its implementation may be prepared, copied, published
	and distributed, in whole or in part, without restriction of any
	kind, provided that the above copyright notice and this paragraph
	are included on all such copies and derivative works. However, this
	document itself may not be modified in any way, such as by removing
	the copyright notice or references to the Internet Society or other
	Internet organizations, except as needed for the purpose of
	developing Internet standards in which case the procedures for
	copyrights defined in the Internet Standards process must be
	followed, or as required to translate it into languages other than
	English.
	The limited permissions granted above are perpetual and will not be
	revoked by the Internet Society or its successors or assignees.
	INTERNET DRAFT Anycast Prefix for 6to4
	This document and the information contained herein is provided on an		RFC 3068
	"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
	TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
	BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
	HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
	MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
	10 Intellectual Property		Title: An Anycast Prefix for 6to4 Relay Routers
			Author(s): C. Huitema
			Status: Standards Track
			Date: June 2001
			Mailbox: huitema@exchange.microsoft.com
			Pages: 9
			Characters: 20120
			Updates/Obsoletes/SeeAlso: None
	The following notice is copied from RFC 2026 [Bradner, 1996],		I-D Tag: draft-ietf-ngtrans-6to4anycast-03.txt
	Section 10.4, and describes the position of the IETF concerning
	intellectual property claims made against this document.
	The IETF takes no position regarding the validity or scope of any		URL: ftp://ftp.rfc-editor.org/in-notes/rfc3068.txt
	intellectual property or other rights that might be claimed to
	pertain to the implementation or use other technology described in
	this document or the extent to which any license under such rights
	might or might not be available; neither does it represent that it
	has made any effort to identify any such rights. Information on the
	IETF's procedures with respect to rights in standards-track and
	standards-related documentation can be found in BCP-11. Copies of
	claims of rights made available for publication and any assurances
	of licenses to be made available, or the result of an attempt made
	to obtain a general license or permission for the use of such
	proprietary rights by implementers or users of this specification
	can be obtained from the IETF Secretariat.
	The IETF invites any interested party to bring to its attention any		This memo introduces a "6to4 anycast address" in order to simplify the
	copyrights, patents or patent applications, or other proprietary		configuration of 6to4 routers. It also defines how this address will
	rights which may cover technology that may be required to practice		be used by 6to4 relay routers, how the corresponding "6to4 anycast
	this standard. Please address the information to the IETF Executive		prefix" will be advertised in the IGP and in the EGP. The memo
	Director.		documents the reservation by IANA (Internet Assigned Numbers
			Authority) of the "6to4 relay anycast prefix."
	11 Acknowledgements		This document is a product of the Next Generation Transistion Working
			Group of the IETF.
	The discussion presented here was triggered by a note that Brad		This is now a Proposed Standard Protocol.
	Huntting sent to the NGTRANS and IPNG working groups. The note
	revived previous informal discussions, for which we have to
	acknowledge the members of the NGTRANS and IPNG working groups, in
	particular Scott Bradner, Randy Bush, Brian Carpenter, Steve
	Deering, Bob Fink, Tony Hain, Bill Manning, Keith Moore and Dave
	Thaler.
	12 References		This document specifies an Internet standards track protocol for
			the Internet community, and requests discussion and suggestions
			for improvements. Please refer to the current edition of the
			"Internet Official Protocol Standards" (STD 1) for the
			standardization state and status of this protocol. Distribution
			of this memo is unlimited.
	[RFC3056] B. Carpenter, K. Moore. Connection of IPv6 Domains via		This announcement is sent to the IETF list and the RFC-DIST list.
	IPv4 Clouds. RFC 3056, February 2001.		Requests to be added to or deleted from the IETF distribution list
			should be sent to IETF-REQUEST@IETF.ORG. Requests to be
			added to or deleted from the RFC-DIST distribution list should
			be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG.
	13 Author's Addresses		Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
			an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body
			help: ways_to_get_rfcs. For example:
	Christian Huitema		To: rfc-info@RFC-EDITOR.ORG
	Microsoft Corporation		Subject: getting rfcs
	INTERNET DRAFT Anycast Prefix for 6to4
	One Microsoft Way		help: ways_to_get_rfcs
	Redmond, WA 98052-6399
	Email: huitema@exchange.microsoft.com		Requests for special distribution should be addressed to either the
			author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless
			specifically noted otherwise on the RFC itself, all RFCs are for
			unlimited distribution.echo
			Submissions for Requests for Comments should be sent to
			RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC
			Authors, for further information.
End of changes. 14 change blocks.
	369 lines changed or deleted		38 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/