Network Working Group Shaji Radhakrishnan Internet Draft Watercove Networks June, 2001 Satish Amara 3COM corporation Rajesh Ramankutty YingChun Xu Ellis Wong WaterCove Networks MPLS label stack encapsulation in Ipv6 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 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 anytime. 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 In certain cases it may be useful to encapsulate MPLS packets in IPV6 packets. This document describes a method to encapsulate MPLS in IPV6 networks. 1. Encapsulation in IPv6 The IPv6 destination option or Flow-field will be used to encapsulate the MPLS label. The LDP on the Egress router and LDP on the ingress router will agree on what label to use and this label is encapsulated in the IPV6 flow label. Presently, there are two mechanisms for LDP peers discovery namely basic discovery and extended discovery. Basic discovery is used to discover LDP peers, which are directly connected. Extended discovery is used to discover LDP peers, which are not directly connected. This mechanism will be used to establish peering relationship between the LDP running on Egress and Ingress routers. A new option in the LDP message is Radhakrishnan, Amara et.al &Expires Nov. 2001 1 < draft-mpls-label-encaps-ipv6-00.txt> November 2001 introduced to convey that extended label is encapsulated in IPV6 destination option or flow-field. Once the label is distributed by the LDP on egress router to the LDP on Ingress router, then the egress router will label the packet. The forwarding decision at Ingress router will be based on destination option or flow-field in IPV6 packet. If the egress node sets the flow-id field to zero (i.e., the flow-id is not used for anything else like QoS), then the flow-id can be used to encapsulate the top field in label stack. If the flow-id is used to set QoS fields, then the destination extension header options are used to carry the label or label stack. If only one label is present in the label stack, the best way is to use the flow-id for carrying the label, if the flow-id is not used for any other purpose. But another argument to simplify the processing at both egress as well as ingress nodes, the extension header is only used to specify the label stack. With this, the egress node always use Ipv6 extension header to place the label stack (whether label stack contains single or multiple labels) and the ingress node always looks for label extension header to check label stack. 2. MPLS label stack transport in Ipv6 Extension header The format of destination option header is the following. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header | Hdr Ext Len | | |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | . . . Options . . . | | |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The options are in TLV format as follows. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - | Option Type | Opt Data Len | Option Data +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - Option Type :: 8-bit identifier of the type of option. The proposed value is 2 for the MPLS label stack. Opt Data Len :: 8-bit unsigned integer. Length of the Option Data field of this option, in octets. The length of each label is 32 bits which 4 bytes, i.e. 20bit label, 1 bit for label stack, 3 bits for experimental bits and 8 bit for TTL. I.e. if the label stack contains 3 labels, the size will be 12 bytes. Radhakrishnan & Amara et. Al, Expires Nov. 2001 2 < draft-mpls-label-encaps-ipv6-00.txt> November 2001 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Label | Label | Exp |S| TTL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Label: Label Value, 20 bits Exp: Experimental Use, 3 bits S: Bottom of Stack, 1 bit TTL: Time To Live field, 8bits Option Data :: Variable-length field. Option-Type-specific data. The data contains the encoded MPLS label stack. When placing the label stack, the label in the top of the stack as the first label, the next one in the stack will be the second label etc.. +----+ +----+ +----+ +----+ Cloud> Egress |<------------IPV6Cloud------------>|Ingress LSR LSR 3. Label processing at egress node The outgoing packet will be a normal Ipv6 packet. If the flow-id is set to zero, then the outgoing label is placed in the flow-id of the Ipv6 packet. If there is a label stack, each label is placed in the destination header options in order as described above. The destination of this Ipv6 packet will be the ingress MPLS router, which support Ipv6 on the ingress interface. A field in destination option specifies that the top label (in label stack) is encapsulated in flow-id. The TTL field from the label is copied to the Hop Limit field in the Ipv6 header of the tunneled packet. In the ingress node, the Hop Limit filed value is copied back to the TTL field of the label. 4. Label processing at ingress node The ingress node looks for incoming Ipv6 packet and gets the incoming flow label from the flow-Id of the Ipv6 packets for the NHFLE entry. The ingress node also looks for any destination header options for MPLS label stack. If any label stack is present, each label from the destination option is taken in the order. The first label should be the top of the stack, the second label will be the second one from the top etc.. The label and stack processing are done as described in the MPLS architecture. In certain cases (i.e., when security is not applied to the original packet end-to-end) instead of tunneling MPLS packet in IPV6 packets by the egress node, the packets can be transported in IPV6 packets Radhakrishnan & Amara et. Al, Expires Nov. 2001 3 < draft-mpls-label-encaps-ipv6-00.txt> November 2001 using routing header option. In that case the routing header would specify the route. Routing header will contain two entries. The first hop in the routing header will be Ingress router and the final hop will be destination IP address of the packet. 5. Security Considerations Security issues are not discussed in this document. 6. References [1] E. Rosen et.al ôMPLS Label Stack Encodingö. RFC3032, January 2001. [2] E. Rosen et.al ôMultiprotocol Label Switching Architectureö. RFC3031 [3] L. Andersson et al, "LDP Specification," Internet-RFC 3036, Jan 2001. [4] Internet Protocol, Version 6 (IPv6) Internet-RFC 2460 [5] J. Reynolds and J. Postel. "ASSIGNED NUMBERS". RFC1700, October 1994. Author's Addresses Shaji Radhakrishnan WaterCove Networks 1750 East Golf Road, Suite 550 Schaumburg, IL 60173 Phone: (847) 621-8913 Email: sradhakrishnan@watercove.com Satish Amara 3Com Corporation 3800, Golf Road, Rolling Meadows, IL 60008 Phone: 847-262-2563 Email: satish_amara@3com.com Rajesh Ramankutty 3Com Corporation 3800, Golf Road, Rolling Meadows, IL 60008 Phone: 847-262-2580 Email: rajesh_ramankutty@3com.com Yingchun Xu WaterCove Networks Radhakrishnan & Amara et. Al, Expires Nov. 2001 4 < draft-mpls-label-encaps-ipv6-00.txt> November 2001 1750 East Golf Road, Suite 550 Schaumburg, IL - 60173 Phone: (847) 477-9280 Email: yxu@watercove.com Ellis Wong WaterCove Networks 285 Billerica Road Chelmsford, MA - 01824 Phone: (978) 608-2089 Email: ewong@watercove.com Radhakrishnan & Amara et. Al, Expires Nov. 2001 5