Network Working Group Tissa Senevirathne Internet Draft Document: draft-tsenevir-ipv6-bgp-tun-00.txt June 2002 Category: Informational Identification of IPv6 Routes that need Tunneling - Use of BGP Extended Community Attribute Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. 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 obsolete 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. For potential updates to the above required-text see: http://www.ietf.org/ietf/1id-guidelines.txt 1. Abstract In this document we provide methods to discover and connect native IPV6 clouds that are separated by IPV4 Internet. BGP-MP [2] is used as protocol to discover IPV6 relay routers. BGP-MP(BGP4+) [3] is used to distribute IPV6 routes. Encapsulation of IPV6 presented in [4] is used to tunnel IPv6 traffic across IPV4 Internet. The method presented here is known as 6in4 as opposed to 6to4 [4] or 6over4[5]. Senevirathne Informational û December 2002 1 draft-tsenevir-ipv6-bgp-tun-00.txt June 2002 Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [6]. 2. Introduction During the IPv6 adaptation period it is likely that new sites may acquire native IPV6 addresses. If these new sites to communicate with each other presently there are two choices. 1. Obtain dedicated connectivity between the sites. 2. Use an experimental IPV6 backbone. Connection to the experimental backbone may need a dedicated connection. On the other hand, experimental backbone may not provide the required bandwidth and services that a more established provider may provision. Either of the above methods has its own drawbacks. It is attractive to have a solution that provide ability to identify IPV6 routes that need tunneling over IPv4 and IPV6 routes that are natively connected. Presently there are two popular solutions namely; 6to4 [4] and 6over4 [5]. 6to4 and 6over4 provide tunneling of IPv6 across IPv4 networks. 6to4 has two major limitations, 1. Inability to connect across Autonomous Systems when using 6to4 addressing. 2. Lack of automatic procedures to identify routes that need IPV6 routing and routes that need tunneling. (RFC suggest to use manual configurations to achieve this). 6over4 requires having multicast IPV4 network. Most service providers do not provide Internet wide Multicast services. If they do provide, such services can be expensive. As an example compare the cost of 1G IP routing service to 1G multicast service.. In this document we present extension to BGP-MP that allow routers to identify IPV6 routes that need IPV4 tunneling and discover IPv4 address of tunnel end points (relay routers). Also we suggest some procedures how non-relay routes can properly forward IPv6 traffic that require tunneling to the appropriate relay routers. Key words: Relay router - A router that has at least one IPv4 connection and one IPv6 interface and provide 6in4 or 6to4 tunneling services. Native IPV6 Router - A router that has only IPv6 interfaces. Senevirathne Informational û December 2002 2 draft-tsenevir-ipv6-bgp-tun-00.txt June 2002 3. Reference Model ======================== # --------- # # | AS3 | # # | | # # --------- # # --------- --------- # #| AS1 | | AS2 |# Example IPV4 Internet # --------- --------- # ======================== To IPV6 || || To IPV6 \\ || || // \\ || || // \\ || || // %%%%%%%%%%%%%%%%%%%%%%%%% %%%%%%%%%%%%%%%%%%%%%%%%% % ------- ------ % % ------- ------ % % | ipv6 | | Relay| % % |Relay | |IPv6 |% % ------- ------ % % ------- ------ % %%%%%%%%%%%%%%%%%%%%%%%%% %%%%%%%%%%%%%%%%%%%%%%%%% IPV6 site A IPv6 site B Fig: Reference model for Discovery of IPv6 relay routers for 6in4 It is possible that a given IPV6 site have more than one Relay router and more than one connection to IPV4 Internet and more than one connection to IPv6. or any combination of all that.. 4. Distribution and processing of routes. Key problem in hand is to distinguish between IPV6 routes that have native connectivity and IPv6 routes that do not have native connectivity. IPV6 routes are distributed using methods specified in BGP4+[3]. We define a new extended community attribute that will specify the Relay routers IPv4 address required for tunnels. This attribute will be associated with such routes that require IPv4 tunneling and distributed with BGP4+. 4.1 IPV4-IPV6 extended community attribute IPV4-IPV6 extended community attribute is transitive across autonomous system boundary. It is the IPV4-IPV6 extended community attribute that allow routers to discover the IPV6 routes that need tunneling and the end-point IPv4 address of the originating relay router Senevirathne Informational û December 2002 3 draft-tsenevir-ipv6-bgp-tun-00.txt June 2002 IPV4-IPV6 attribute is of extended type [7]. We propose to use IPV4 address specific extended community attribute specified in [7], with sub-type 0x05 to indicate this is IPV4-IPV6 tunnel attribute. Relay routers that peer with IPv4 BGP speakers SHOULD append IPV4- IPV6 tunnel attribute to the IPV6 routes, it learnt or locally originated, before propagating. 4.2 Processing of routes Theoretically, an IPV6 destination can either be reached via tunnel or via native connection. It is local route policy to select the appropriate route. 4.2.1 Relay routers Relay router may select the tunnel connectivity based on local route policies. If chosen to route IPV6 via the tunnel it MAY advertise it self as the next hop router for those IPV6 routes that it provides tunneling. Relay routers are also required to obtain other IPV4 routing information. This may be achieved either through BGP4 or other means. next hop connectivity for IPV4 is required to be resolved using established routing policies and considered out of scope of this document. 4.2.2 IPV6 Native routers All native IPV6 routers should peer with relay routers of the site. Native routers may receive IPV6 route updates for both native IPV6 connectivity as well as tunnel connectivity. It is a local policy to determine the required connectivity. Native routers SHOULD not consider the IPV4-IPV6 attribute for any reason other than local policies. 5. Security Considerations Specification of IPV4-IPV6 attribute is according to [7]. Security issues applicable to [7] are directly applicable to method presented here. There are no additional issues known at the time of writing. 6. References 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. 2 Bates, T. et.al, Multiprotocol Extensions for BGP-4, RFC 2283, February 1998. Senevirathne Informational û December 2002 4 draft-tsenevir-ipv6-bgp-tun-00.txt June 2002 3 Marques, P., and et.al , Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing, RFC 2545, March 1999. 4 Carpenter, B., and et.al Connection of IPV6 Domains via IPv4 Clouds, RFC 3056, February 2001. 5 Carpenter, B., and et.al Transmission of IPv6 over IPv4 Domains without Explicit Tunnels, RFC 2529, Marc 1999. 6 Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 7 Sangli, S., and et.al, BGP Extended Communities Attribute, Work in Progress, November 2002. 7. Acknowledgments 8. Author's Addresses Tissa Senevirathne 1567 Belleville Way, Sunnyvale, CA 94087 Phone: 408-245-5897 Email: tsenevir@hotmail.com Senevirathne Informational û December 2002 5 draft-tsenevir-ipv6-bgp-tun-00.txt June 2002 Full Copyright Statement "Copyright (C) The Internet Society (2002). 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 implmentation 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 Senevirathne Informational û December 2002 6