Network Working Group J. Wu Internet-Draft Y. Cui Expires: August 26, 2006 X. Li Tsinghua University February 22, 2006 4over6 Transit using Encapsulation and BGP-MP Extension draft-wu-softwire-4over6-00 Status of this Memo By submitting this Internet-Draft, each author represents that any 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 aware will be disclosed, in accordance with Section 6 of BCP 79. 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. This Internet-Draft will expire on August 26, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract Due to the rapid deployment of IPv6 networks, especially IPv6 backbones, the existing long-live IPv4 networks are connected to these IPv6 networks. In the environment that ISP hopes to use IPv6 backbones while still provides end users IPv4 access to support existing IPv4 applications, IPv4 traffic needs to be transported over IPv6 backbones. Along with the growth of IPv6 backbones, the number of IPv4 access networks becomes large and the IPv4/v6 interconnection Wu, et al. Expires August 26, 2006 [Page 1] Internet-Draft 4over6 February 2006 topology becomes complex. Therefore, the manual configuration to a large number of these end-2-end tunnels will be an insufferable burden. This draft addresses this problem and presents a mechanism of automatic 4over6 tunnel-end discovery with BGP extensions. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. 4over6-related terminology . . . . . . . . . . . . . . . . 4 3. Intra-domain 4over6 framework . . . . . . . . . . . . . . . . 5 4. 4over6 packet forwarding . . . . . . . . . . . . . . . . . . . 7 5. BGP-MP 4over6 protocol definition . . . . . . . . . . . . . . 10 6. Behavior of BGP-MP 4over6 extension . . . . . . . . . . . . . 12 6.1. Receiving routing information from CE . . . . . . . . . . 12 6.2. Receiving routing information from PE . . . . . . . . . . 12 7. 4over6 Error Processing . . . . . . . . . . . . . . . . . . . 14 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 9. Security Considerations . . . . . . . . . . . . . . . . . . . 16 10. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 17 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 12.1. Normative References . . . . . . . . . . . . . . . . . . . 19 12.2. Informative References . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 Intellectual Property and Copyright Statements . . . . . . . . . . 21 Wu, et al. Expires August 26, 2006 [Page 2] Internet-Draft 4over6 February 2006 1. Introduction With the rapid deployment of IPv6 networks, especially IPv6 backbones, some IPv6 backbones need to act as IPv6 transit cores to provide packet transport service to IPv4 access networks. Although there are some related tunneling protocols or mechanisms in the literature, most of the existing tunneling mechanisms focus on the problem of IPv6 over IPv4, rather than the upcoming one of IPv4 over IPv6. Additionally, although some encapsulation methods, e.g. [RFC2473], present specifications for generic packet tunneling in IPv6, the insufferable burden of manual configuration prevents the wide deployment of existing related end-2-end tunnels in a large- scale IPv4/v6 interconnected networks. Thus, new techniques need to provide automatic tunneling mechanism for scalable IPv4 packet transmission over an IPv6 backbone, which is abbreviated as 4over6. Generally speaking, 4over6 mechanism concerns two aspects: the control plane and the data plane. The control plane needs to solve the problem of how to setup an IPv4 over IPv6 tunnel with proper method of tunnel end-point discovery. This document extends BGP-MP to carry the tunnel end information to the other side of the IPv6 backbone to setup of a stateless 4over6 tunnel on the dual-stack Provider Edge (PE) router. Based on the 4over6 tunnel, the data plane focuses on the data packet forwarding process with encapsulation and decapsulation. In order to avoid redundant definition of packet encapsulation, this document reuses the existing techniques in this part. Wu, et al. Expires August 26, 2006 [Page 3] Internet-Draft 4over6 February 2006 2. Terminology 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 [RFC2119]. 2.1. 4over6-related terminology 4over6 A framework of IPv4 packet transmission over IPv6 networks. 4over6 PE Router A dual-stack provider edge router connecting IPv4 access networks and an IPv6 backbone with 4over6 functionality. 4over6 Virtual Interface A virtual interface with configured both IPv4 and IPv6 addresses on the 4over6 PE router, where the encapsulated 4over6 packet is generated. 4over6 virtual interface is abbreviated as 4over6 VIF. 4over6 Encapsulation Table A table maintained on AFBR consisting of mappings from destination IPv4 network address with mask to a specific IPv6 address. Wu, et al. Expires August 26, 2006 [Page 4] Internet-Draft 4over6 February 2006 3. Intra-domain 4over6 framework In the IPv4/v6 interconnected network topology shown in figure 1, a number of P routers, only running the IPv6 network stack, compose a native IPv6 backbone. In order to provide IPv4 access to the current IPv4 users/applications, PE routers run both IPv6 and IPv4 stacks. The IPv6 backbone acts as a transit core to transport IPv4 packets over the IPv6 backbone. Therefore, each of IPv4 access islands can communicate with each other via the virtual softwires over the IPv6 transit core. The functionality of IPv4 connections over IPv6 backbone is called 4over6. ._._._._ ._._._._ | IPv4 | | IPv4 | |access | |access | |island | |island | ._._._._ ._._._._ | | Dual-Stack Dual-Stack "AFBR" "AFBR" [Peering PE] [Peering PE] | | __+____________________+__ / : : : : \ IPv6 only softwires | : : : : | transit core between | : [P] : | with multiple PEs | : : : : | [P routers] | : : : : | \_._._._._._._._._._._._._./ | / \ | [Peering PE] [Peering PE] Dual-Stack Dual-Stack "AFBR" "AFBR" | | | ._._._._ ._._._._ | IPv4 | | IPv4 | |access | |access | |island | |island | ._._._._ ._._._._ Figure 1: IPv4 over IPv6 network topology In addition to a general router and network topology, all additional things to implement 4over6 are 4over6 routing and 4over forwarding on the dual-stack PE routers. The IPv4 access island often uses default routing to a particular PE router on the IPv4 stack. However, since there are multiple PE Wu, et al. Expires August 26, 2006 [Page 5] Internet-Draft 4over6 February 2006 routers connected to an IPv6 transit core, in order to forward the IPv4 packet directly to an egress PE router with encapsulation mechanism, the ingress PE router needs to know which PE should be the egress one. BGP-MP will be extended to carry the destination IPv4 networks over the IPv6 backbone. Section 4 presents the definition of 4over6 protocol field in BGP-MP and section 5 describes the extended behavior of BGP-MP. After ingress PE router finds the exact egress PE router, ingress one will use a particular encapsulation method to forward the original IPv4 packet over the IPv6 backbone. Receiving the encapsulated packet from the IPv6 transit core, the egress router will decapsulate the packet to its original IPv4 format and then forwards the packet to its final IPv4 destination. Section 6 describes the procedure of packet forwarding. Wu, et al. Expires August 26, 2006 [Page 6] Internet-Draft 4over6 February 2006 4. 4over6 packet forwarding 4over6 packet forwarding includes the following 3 parts: encapsulation of the incoming IPv4 packet with IPv6 header; transmission of the encapsulated packet over the IPv6 transit backbone; and decapsulation to the original IPv4 format. Since the IPv6 transit backbone is unaware of the transmitted packet, the transmission of the encapsulated packet is as usual as other IPv6 packet on the IPv6 backbone. As characteristics of 4over6 packet forwarding, both encapsulation and decapsulation are processed on the PE routers, so they will be described further as follows. Tunnel from Ingress PE to Egress PE -----------------------> Tunnel Tunnel Entry-Point Exit-Point Node Node +-+ +--+ +--+ +-+ |S|-->--//-->--|PE|=====>=====//=====>=====|PE|-->--//-->--|D| +-+ +--+ +--+ +-+ Original Ingress Egress Original Packet Packet Source Destination Node Node Figure 1: Packet forwarding along 4over6 Tunnel As shown in Figure 1, packet encapsulation and decapsulaion are both on the 4over6 AFBR routers. Figure 2 shows the format of packet encapsulation and decapsulation. Wu, et al. Expires August 26, 2006 [Page 7] Internet-Draft 4over6 February 2006 +----------------------------------//-----+ | IPv4 Header | Packet Payload | +----------------------------------//-----+ < Original IPv4 Packet > | |(Encapsulation on ingress PE) | v < Tunnel IPv6 Headers > < Original IPv4 Packet > +-----------+ - - - - - +-------------+-----------//--------------+ | IPv6 | IPv6 | IPv4 | | | | Extension | | Packet Payload | | Header | Headers | Header | | +-----------+ - - - - - +-------------+-----------//--------------+ < Tunnel IPv6 Packet > | |(Decapsulation on egress PE) | v +----------------------------------//-----+ | IPv4 Header | Packet Payload | +----------------------------------//-----+ < Original IPv4 Packet > Figure 2: Packet encapsulation and decapsulation on 4over6 PE router Each 4over6 router maintain an Encapsulation Table, as shown in Figure 3. Each item in the encapsulation table consists of the destination IPv4 network address and its mask, and the IPv6 4over6 VIF address of the corresponding advertising AFBR. +------------------+-------------+------------------------+ | Length of prefix | IPv4 Prefix | IPv6 Advertising AFBR | +------------------+-------------+------------------------+ | Length of prefix | IPv4 Prefix | IPv6 Advertising AFBR | +------------------+-------------+------------------------+ | ...... | | | Figure 3: Encapsulation Table When an IPv4 packet is coming into IPv6 backbone on the dual-stack PE router, the PE is called ingress 4over6 PE router or tunnel entry- point node, on which the IPv4 packet is encapsulated by a new IPv6 header. In this IPv6 header, the source IPv6 address is the IPv6 address of the virtual 4over6 interface on this PE, while the destination IPv6 address is the one of the next hop of the corresponding route maintained by BGP 4over6 extensions. When an Wu, et al. Expires August 26, 2006 [Page 8] Internet-Draft 4over6 February 2006 encapsulated 4over6 packet is coming out of the IPv6 backbone on the dual-stack PE router, the PE is called egress 4over6 PE router or tunnel exit-point node, on which the encapsulated packet is decapsulated to its original IPv4 format. Details of packet encapsulation and decapsulation should refer to the definitions in [RFC2473]. In addition to such encapsulation with IPv4 over IPv6 described in [RFC2473], other existing method like GRE tunnel [RFC2784] can also be used directly for 4over6 encapsulation. Furthermore, 4over6 encapsulation can also use emerging technologies for IPv4 encapsulation over IPv6. Wu, et al. Expires August 26, 2006 [Page 9] Internet-Draft 4over6 February 2006 5. BGP-MP 4over6 protocol definition [BGP-MP] defines the multiprotocol extension of BGP to carry different kinds of routing information [RFC2842] [RFC2858]. Optional parameter in the OPEN message indicates the capability of BGP entity by Address Family Identifier (AFI) and Subsequent Address Family Identifier (SAFI). Path attribute in BGP UPDATE Message includes AFI, SAFI, Network Address of Next Hop, and Network Layer Reachability Information (NLRI), as shown in figure 4. +---------------------------------------------------------+ | Address Family Identifier (2 octets): AFI_IP6=2 | +---------------------------------------------------------+ | Subsequent AFI (1 octet): SAFI_4OVER6 = 67 | +---------------------------------------------------------+ | Length of Next Hop (1 octet): 16 | +---------------------------------------------------------+ | Next Hop: IPv6 Address of 4over6 Virtual Interface | +---------------------------------------------------------+ | Number of SNPAs (1 octet) | +---------------------------------------------------------+ | Length of first SNPA(1 octet) | +---------------------------------------------------------+ | First SNPA (variable) | +---------------------------------------------------------+ | Length of second SNPA (1 octet) | +---------------------------------------------------------+ | Second SNPA (variable) | +---------------------------------------------------------+ | ... | +---------------------------------------------------------+ | Length of Last SNPA (1 octet) | +---------------------------------------------------------+ | Last SNPA (variable) | +---------------------------------------------------------+ | NLRI (variable): Destination IPv4 Network Address | +---------------------------------------------------------+ Figure 4: Path attribute in BGP UPDATE Message 4over6 BGP extension takes AFI as AFI_IP6=2, and defines SAFI as SAFI_4OVER6 = 67, based on the FCFS policy of SAFI application. 4over6 BGP extension uses the above AFI and SAFI to indicate the 4over6 capability in its OPEN message, and to describe the 4over6 routing information in its Path attribute within UPDATE Message. Each PE router with 4over6 functionality should maintain a 4over6 virtual interface with both IPv4 address and IPv6 address. In the Wu, et al. Expires August 26, 2006 [Page 10] Internet-Draft 4over6 February 2006 path attribute, Network Address of Next Hop should be IPv6 interface address, while the NLRI contains the destination IPv4 network address and corresponding IPv4 network prefix. Wu, et al. Expires August 26, 2006 [Page 11] Internet-Draft 4over6 February 2006 6. Behavior of BGP-MP 4over6 extension Standing on the edge between IPv4 address family and IPv6 address family, each PE router with 4over6 functionality should run both IPv4 and IPv6 stack as AFBR. The PE router has at least one IPv4 interface connecting with IPv4 access networks. It can use either IGP or EGP routing protocol to learn the local IPv4 routing information on the IPv4 network. Configured static routing may be also used on the IPv4 network. Similarly, the PE router has at least one IPv6 interface connecting with IPv6 transit backbone. The 4over6 I-BGP entity should setup the peering relationship with other 4over6 PE routers on the edge of IPv6 backbone. The 4over6 I-BGP should have the 4over6 capability defined in the above section. 6.1. Receiving routing information from CE When a 4over6 PE router learns routing information about the local edge network, the 4over6 I-BGP entity should have following functions. 1. The 4over6 I-BGP entity should maintain the local IPv4 routing information it learns from the local IPv4 access network or configuration. 2. Construct new items in local encapsulation table. IPv4 destination should be set with proper prefix with the local IPv4 routing information it learns. The PE router uses the IPv6 address on its 4over6 VIF to set the advertising router. 3. The 4over6 I-BGP entity should broadcast the local IPv4 routing information to its peers by BGP-MP with 4over6 BGP extension. * Taking AFI as AFI_IP6=2 and SAFI as SAFI_4OVER6 = 67. * Destination network address should be the original destination IPv4 network address. * Nexthop should be the IPv6 address of its 4over6 virtual interface. 6.2. Receiving routing information from PE For a local PE running 4over6 I-BGP protocol, if the remote peering PE learns new routing information from static configuration or dynamic routing protocol from its local CEs, the remote peering PE Wu, et al. Expires August 26, 2006 [Page 12] Internet-Draft 4over6 February 2006 will send the corresponding routing information to the local one. Then, the local PE will process the routing information as follows. 1. Confirm the type of received routing information. * Confirm AFI as AFI_IP6=2; * Confirm SAFI as SAFI_4OVER6 = 67; * Confirm destination in NLRI is in IPv4 AF; * Confirm the next hop is in IPv6 AF. 2. Add new items in the encapsulation table * Use the destination network address as the received original destination IPv4 network address; * Set the corresponding advertising router as the Next Hop field in the BGP UPDATE message. 3. Add a new routing item in the IPv4 routing table * Use the destination network address as the received original destination IPv4 network address; * Set the Next Hop as N/A. * Set the OUTPUT IF as the 4over6 virtual interface on the PE router. Wu, et al. Expires August 26, 2006 [Page 13] Internet-Draft 4over6 February 2006 7. 4over6 Error Processing Because 4over6 reuses existing encapsulation technologies, Error Processing should be also reused as much as possible. In the data plane of packet forwarding process, error reporting and processing should be refered to [RFC2473]. In the control plane of I-BGP peering communication, error reporting and processing should be refered to [RFC4271]. Wu, et al. Expires August 26, 2006 [Page 14] Internet-Draft 4over6 February 2006 8. IANA Considerations As stated above, this document requests that IANA assigns a Subsequent Address Family Identifier (SAFI). Since SAFI is allocated in a FCFS policy for number 64-128, 4over6 BGP extension applies for SAFI number, SAFI_4OVER6, at 67. Wu, et al. Expires August 26, 2006 [Page 15] Internet-Draft 4over6 February 2006 9. Security Considerations Tunneling mechanisms, especially automatic ones, often have potential problems of DDoS attacks on the tunnel-entry point or tunnel-end point. However, since 4over6 BGP extension don't allocate resources to a particular flow or maintain the state of a particular flow, the 4over6 PE routers will have a capacity of enduring DDoS attacks as a common router. I-BGP peering relationship may be maintained over IPSec or other security communications. Wu, et al. Expires August 26, 2006 [Page 16] Internet-Draft 4over6 February 2006 10. Conclusion Due to the rapid deployment of IPv6 networks, especially IPv6 backbones, these IPv6 backbones may need to provide the access of existing IPv4 networks to support long lived IPv4 applications as IPv6 transit core. For the complex IPv4/v6 interconnection, this document describes an automatic tunnel endpoint discovery for transmission of IPv4 over IPv6 by BGP 4over6 extensions. The provider core routers (P router) only runs with native IPv6, and the provider edge (PE) router runs in dual stacks. In the control plane, 4over6 PE router maintains an I-BGP peering relationship with each other, and sends the routing information of local IPv4 access network to other peers. In the data plane, PE router encapsulates local IPv4 packets and decapsulates the tunnel packet to its original IPv4 format to its destination IPv4 networks. Therefore, this 4over6 solution with 4over6 BGP extensions only needs to enhance the 4over6 functionality on the PE routers, while there is no need to change P routers and custom routers. Wu, et al. Expires August 26, 2006 [Page 17] Internet-Draft 4over6 February 2006 11. Acknowledgements During the design procedure of the 4over6 framework and definition of BGP-MP 4over6 extension, Professor Ke Xu and Professor Mingwei Xu gave the authors many valuable suggestions. Wu, et al. Expires August 26, 2006 [Page 18] Internet-Draft 4over6 February 2006 12. References 12.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 Specification", RFC 2473, December 1998. [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000. [RFC2842] Chandra, R. and J. Scudder, "Capabilities Advertisement with BGP-4", RFC 2842, May 2000. [RFC2858] Bates, T., Rekhter, Y., Chandra, R., and D. Katz, "Multiprotocol Extensions for BGP-4", RFC 2858, June 2000. [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006. 12.2. Informative References [I-D.ietf-softwire-problem-statement] Li, X., "Softwire Problem Statement", draft-ietf-softwire-problem-statement-00 (work in progress), December 2005. Wu, et al. Expires August 26, 2006 [Page 19] Internet-Draft 4over6 February 2006 Authors' Addresses Jianping Wu Tsinghua University Department of Computer Science, Tsinghua University Beijing 100084 P.R.China Phone: +86-10-6278-5983 Email: jianping@cernet.edu.cn Yong Cui Tsinghua University Department of Computer Science, Tsinghua University Beijing 100084 P.R.China Phone: +86-10-6278-5822 Email: cuiyong@tsinghua.edu.cn Xing Li Tsinghua University Department of Electronic Engineering, Tsinghua University Beijing 100084 P.R.China Phone: +86-10-6278-5983 Email: xing@cernet.edu.cn Wu, et al. Expires August 26, 2006 [Page 20] Internet-Draft 4over6 February 2006 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in 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 made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Wu, et al. Expires August 26, 2006 [Page 21]