summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc3068.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc3068.txt')
-rw-r--r--doc/rfc/rfc3068.txt507
1 files changed, 507 insertions, 0 deletions
diff --git a/doc/rfc/rfc3068.txt b/doc/rfc/rfc3068.txt
new file mode 100644
index 0000000..e4dc49c
--- /dev/null
+++ b/doc/rfc/rfc3068.txt
@@ -0,0 +1,507 @@
+
+
+
+
+
+
+Network Working Group C. Huitema
+Request for Comments: 3068 Microsoft
+Category: Standards Track June 2001
+
+
+ An Anycast Prefix for 6to4 Relay Routers
+
+Status of this Memo
+
+ 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.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2001). All Rights Reserved.
+
+Abstract
+
+ 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 (Internet Assigned Numbers
+ Authority) of the "6to4 relay anycast prefix."
+
+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 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.
+
+ 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 packets will be
+
+
+
+Huitema Standards Track [Page 1]
+
+RFC 3068 An Anycast Prefix for 6to4 Relay Routers June 2001
+
+
+ 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.
+
+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, 6to4 Relay anycast
+ address, 6to4 IPv6 relay anycast address, and Equivalent IPv4 unicast
+ address.
+
+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 192.88.99.0/24
+
+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, 192.88.99.1.
+
+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.
+
+ The value of the address is "2002:c058:6301::".
+
+
+
+
+
+
+Huitema Standards Track [Page 2]
+
+RFC 3068 An Anycast Prefix for 6to4 Relay Routers June 2001
+
+
+2.6 Equivalent IPv4 unicast address
+
+ A regular IPv4 address associated with a specific 6to4 Relay Router.
+ Packets sent to that address are treated by the 6to4 Relay Router as
+ if they had been sent to the 6to4 Relay anycast address.
+
+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.
+
+ Anycast routing is known to cause operational issues: since the
+ sending 6to4 router does not directly identify the specific 6to4
+ relay router to which it forwards the packets, it is hard to identify
+ the responsible router in case of failure, in particular when the
+ failure is transient or intermittent. Anycast solutions must thus
+ include adequate monitoring of the routers performing the service, in
+ order to promptly detect and correct failures, and also adequate
+ fault isolation procedures, in order to find out the responsible
+ element when needed, e.g., following a user's complaint.
+
+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.
+
+
+
+
+Huitema Standards Track [Page 3]
+
+RFC 3068 An Anycast Prefix for 6to4 Relay Routers June 2001
+
+
+ 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].
+
+ Each 6to4 relay router that advertise the 6to4 anycast prefix MUST
+ also provide an equivalent IPv4 unicast address. Packets sent to
+ that unicast address will follow the same processing path as packets
+ sent to the anycast address, i.e., be relayed to the IPv6 Internet.
+
+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 initial AS path must contain the
+ AS number of the announcing AS. The AS path should also include an
+ indication of the actual router providing the service; there is a
+ suggestion to perform this function by documenting the router's
+ equivalent IPv4 address in the BGP aggregator attribute of the path;
+ further work is needed on this point.
+
+ 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
+ multi-homed network, with multiple access points scattered over the
+ whole Internet.
+
+4.4 Monitoring of the 6to4 relay routers
+
+ Any 6to4 relay router corresponding to this specification must
+ include a monitoring function, to check that the 6to4 relay function
+ is operational. The router must stop injecting the route leading to
+ the 6to4 anycast prefix immediately if it detects that the relay
+ function is not operational.
+
+ The equivalent IPv4 address may be used to check remotely that a
+ specific router is operational, e.g., by tunneling a test IPv6 packet
+ through the router's equivalent unicast IPv4 address. When a domain
+ deploys several 6to4 relay routers, it is possible to build a
+ centralized monitoring function by using the list of equivalent IPv4
+ addresses of these routers.
+
+4.5 Fault isolation
+
+ When an error is reported, e.g., by a user, the domain manager should
+ be able to find the specific 6to4 relay router that is causing the
+ problem. The first step of fault isolation is to retrieve the
+ equivalent unicast IPv4 address of the router used by the user. If
+ the router is located within the domain, this information will have
+
+
+
+Huitema Standards Track [Page 4]
+
+RFC 3068 An Anycast Prefix for 6to4 Relay Routers June 2001
+
+
+ to be retrieved from the IGP tables. If the service is obtained
+ through a peering agreement with another domain, the information will
+ be retrieved from the EGP data, e.g., the BGP path attributes.
+
+ The second step is obviously to perform connectivity tests using the
+ equivalent unicast IPv4 address.
+
+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. We expect
+ that adequate monitoring tools will be used to guarantee timely
+ discovery of connectivity losses.
+
+
+
+
+
+
+
+
+
+Huitema Standards Track [Page 5]
+
+RFC 3068 An Anycast Prefix for 6to4 Relay Routers June 2001
+
+
+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
+ 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 /24." The actual limit may vary from
+ network to network, and also over time.
+
+ 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 Do we need a specific AS number?
+
+ A first version of this memo suggested the use of a specific AS
+ number to designate a virtual AS containing all the 6to4 relay
+ routers. The rationale was to facilitate the registration of the
+ access point in databases such as the RADB routing registry [RADB].
+ Further analysis has shown that this was not required for practical
+ operation.
+
+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.
+
+
+
+
+
+
+Huitema Standards Track [Page 6]
+
+RFC 3068 An Anycast Prefix for 6to4 Relay Routers June 2001
+
+
+ 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 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.
+
+ The practical operation of the 6to4 relay routers requires the
+ development of monitoring and testing tools, and the elaboration of
+ gradual management practices. While this document provides general
+ guidelines for the design of tools and practice, we expect that the
+ actual deployment will be guided by operational experience.
+
+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;
+ there is no need for any recurring assignment.
+
+9. Intellectual Property
+
+ The following notice is copied from RFC 2026 [Bradner, 1996], Section
+ 10.4, and describes the position of the IETF concerning intellectual
+ property claims made against this document.
+
+
+
+Huitema Standards Track [Page 7]
+
+RFC 3068 An Anycast Prefix for 6to4 Relay Routers June 2001
+
+
+ The IETF takes no position regarding the validity or scope of any
+ 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
+ copyrights, patents or patent applications, or other proprietary
+ rights which may cover technology that may be required to practice
+ this standard. Please address the information to the IETF Executive
+ Director.
+
+10 Acknowledgements
+
+ The discussion presented here was triggered by a note that Brad
+ 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, Andrew Partan and
+ Dave Thaler.
+
+11 References
+
+ [RFC3056] Carpenter, B. and K. Moore "Connection of IPv6 Domains via
+ IPv4 Clouds", RFC 3056, February 2001.
+
+ [RADB] Introducing the RADB. Merit Networks,
+ http://www.radb.net/docs/intro.html.
+
+12 Author's Address
+
+ Christian Huitema
+ Microsoft Corporation
+ One Microsoft Way
+ Redmond, WA 98052-6399
+
+ EMail: huitema@microsoft.com
+
+
+
+
+
+Huitema Standards Track [Page 8]
+
+RFC 3068 An Anycast Prefix for 6to4 Relay Routers June 2001
+
+
+13 Full Copyright Statement
+
+ Copyright (C) The Internet Society (2001). 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 assigns.
+
+ This document and the information contained herein is provided on an
+ "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.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Huitema Standards Track [Page 9]
+