INTERNET-DRAFT Hideo Ishii Asia Global Crossing Expires: May 13, 2002 Koichiro Fujimoto NEC Corporation Shinji Sugiyama NEC Corporation Hiroki Ishibashi NEC Corporation November 13, 2001 IPv6 Traffic Engineering Tunnel Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Distribution of this memo is unlimited. The internet-draft will expire in 6 months. The date of expiration will be May 13, 2002. Abstract This document specifies a method to transmit IPv6 traffic over IPv4 MPLS Label Switched Paths (LSPs) constructed by [RSVP-TE]. The way Ishii, et al Expires: May 13, 2002 [Page 1] INTERNET-DRAFT IPv6 Traffic Engineering Tunnel November 2001 to transmit IPv4 and IPv6 traffic over IPv4 MPLS LSPs and the way to exchange routing information are described. This method allows Traffic Engineering for IPv4 and IPv6 separately or both inclusively. 1. Introduction There are many existing networks which have been built by [RSVP-TE]. Building IPv6-capable IPv4 MPLS LSPs enables us to: 1. deploy stable IPv6 networks. 2. make the most of existing network equipment and production software code as core LSR. The method described in this document has the following advantages over the IPv6-over-IPv4 tunnel: 1. efficient packet forwarding by minimizing transmission overheads. 2. making the most of the existing network management tools for IPv4 MPLS. 3. early deployment of IPv6 Traffic Engineering. 2. Mechanism The mechanism to establish IPv4 MPLS LSPs on which IPv6 traffic is to be sent is described in this section. Node.A ----- ( MPLS Cloud ) ----- Node.B 2.1 Setting Up IPv4 MPLS LSPs IPv4 MPLS LSPs are established on the IPv4 control plane using [RSVP- TE]. IPv4 addresses are used to specify each provider edge (PE) router. Therefore, when an explicit route object of [RSVP-TE] is to be used, IPv4 addresses are used, too. On the network diagram above, the steps to establish IPv4 MPLS LSPs are: 1. Send a [RSVP-TE] Path Message from Node.A to Node.B to initiate Label request from Node A. In this step, an IPv4 MPLS LSP in the direction of Node.A to Ishii, et al Expires: May 13, 2002 [Page 2] INTERNET-DRAFT IPv6 Traffic Engineering Tunnel November 2001 Node.B is established. 2. Likewise, an IPv4 MPLS LSP in the direction of Node.B to Node.A is established by sending a [RSVP-TE] Path Message from Node.B to Node.A. 2.2 Setting Up the IP Version By default, both IPv4 and IPv6 are transmitted over the established IPv4 MPLS LSP using [RSVP-TE]. On a PE Router, a user may explicitly configure which LSP should be used to forward IPv4 traffic and IPv6 traffic, independently. An IPv4 MPLS LSP may be configured only for IPv6. Another may be configured for both IPv4 and IPv6. Since an LSP is a unidirectional path, it may be required to configure IP versions on both node.A and Node.B. 2.3 Routing IPv6 Routing Protocols are sent over the established IPv4 MPLS LSP. By doing this, PE routers can exchange routing information directly over Provider (P) routers. Therefore, P routers are not required to have any knowledge of IPv6 Routing information. Using this method, PE routers can detect the loss of reachability and update routing information when the IPv4 MPLS LSP is torn down. This mechanism can prevent packets from going into the black hole. The examples of routing protocol settings are described below: 1. BGP4 and BGP4+ For IPv6, link-local addresses can be specified as neighbors. When IPv6 Global and IPv4 addresses are used, BGP packets may be routed outside of IPv4 MPLS LSPs; therefore, it is desirable to set TTLs to one. 2. RIP, RIPng, OSPFv2, and OSPFv3 Basically, any routing protocols can be configured by setting respective routing protocols on tunnel interfaces which are entry points to IPv4 MPLS LSPs since a neighboring PE router is one hop away over an IPv4 MPLS LPS. 3. Traffic Engineering Consideration By specifying IP versions to be transmitted over a certain IPv4 MPLS LSP as described in 2.2, it is possible to manage and control IPv4 and IPv6 traffic independently. Using this method, IPv4 and IPv6 traffic can be separated on different IPv4 MPLS LSPs or together with Ishii, et al Expires: May 13, 2002 [Page 3] INTERNET-DRAFT IPv6 Traffic Engineering Tunnel November 2001 on a single IPv4 MPLS LSP. 4. Security Consideration The same security consideration as in [RSVP-TE] is applicable. 5. Future Work As described in the section 2.2, currently, it may be required to configure IP versions to be transmitted over IPv4 MPLS LSPs. The way to identifying the version of incoming IP packets and finding the corresponding label automatically are to be discussed in the future. Ishii, et al Expires: May 13, 2002 [Page 4] INTERNET-DRAFT IPv6 Traffic Engineering Tunnel November 2001 6. References [RSVP-TE] Awduche, Berger, Gan, Li, Srinivasan, and Swallow, "RSVP- TE: Extensions to RSVP for LSP Tunnels", draft-ietf-mpls-rsvp-lsp- tunnel-09.txt, work in progress. 7. Author's Addresses Hideo Ishii Asia Global Crossing 17F Kamiyacho Mori Bldg. 4-3-20 Toranomon, Minato-ku, Tokyo 105-0001 Japan Email: hishii@gblx.net Koichiro Fujimoto NEC Corporation 7-1, Shiba 5-Chome, Minato-ku, Tokyo 108-8001 Japan Email: koichiro@ipv6.nec.co.jp Shinji Sugiyama NEC Corporation 1131 Hinode, Abiko City, Chiba 270-1198 Japan sugiyama@ipv6.nec.co.jp Hiroki Ishibashi NEC Corporation 1131 Hinode, Abiko City, Chiba 270-1198 Japan bashi@ipv6.nec.co.jp