SFC WG C. Wang Internet-Draft W. Meng Intended status: Standards Track ZTE Corporation Expires: January 3, 2016 July 2, 2015 IPv6 Service function Chain draft-wang-6man-ipv6-service-function-chain-00 Abstract Service function chain is the definition of an ordered set of service functions. After instantiated, the service function path is created and the classified traffic is steered through the corresponding service function path and then forwarded to the final destination. This document tries to describe how to use IPv6 data plane and IPv6 extension headers to realize service function chain in IPv6 network. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on January 3, 2016. Copyright Notice Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as Wang & Meng Expires January 3, 2016 [Page 1] Internet-Draft IPv6 SFC July 2015 described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Convention and Terminology . . . . . . . . . . . . . . . . . . 4 3. An introduction on service function chain . . . . . . . . . . 5 3.1. service function chain components . . . . . . . . . . . . 5 3.2. data plane in service function chain . . . . . . . . . . . 5 4. An analysis on service function chain over IPv6 network . . . 8 4.1. Routing header in IPv6 network . . . . . . . . . . . . . . 8 4.2. Destination options headers in IPv6 network . . . . . . . 9 5. Service function path information header over IPv6 data plane . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 6. Metadata/Context headers over IPv6 data plane . . . . . . . . 11 7. The procedures of IPv6 service function chain . . . . . . . . 12 7.1. Example 1 (Identifier type= a list of addresses which identify SFFs and/or SFs) . . . . . . . . . . . . . . . . 12 7.2. Example 2 (Identifier type = service function path identifier) . . . . . . . . . . . . . . . . . . . . . . . 13 8. Service function chain simple offload over IPv6 network . . . 15 9. Security Considerations . . . . . . . . . . . . . . . . . . . 16 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 11.1. Normative References . . . . . . . . . . . . . . . . . . . 18 11.2. Informative References . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 Wang & Meng Expires January 3, 2016 [Page 2] Internet-Draft IPv6 SFC July 2015 1. Introduction Service function chain is the definition of an ordered set of service functions. After instantiated, the service function path is created and the classified traffic is steered through the corresponding service function path and then forwarded to the final destination. This document tries to describe how to use IPv6 data plane and IPv6 extension headers to realize service function chain in IPv6 network. Specifically, this document tries to provide: In section 3, an introduction on service function chain. In section 4, an analysis on service function chain over IPv6 network In section 5, service function path information header over IPv6 data plane In section 6, context headers over IPv6 data plane In section 7, the procedures of IPv6 service function chain In section 8, simple offload over IPv6 network In section 9, security for IPv6 service function chain Wang & Meng Expires January 3, 2016 [Page 3] Internet-Draft IPv6 SFC July 2015 2. Convention and 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]. The terms about SFC are all defined in [I-D.ietf-sfc-architecture]. The terms about IPv6 are all defined in [RFC2460]. Wang & Meng Expires January 3, 2016 [Page 4] Internet-Draft IPv6 SFC July 2015 3. An introduction on service function chain 3.1. service function chain components Service function chain, defined in [I-D.ietf-sfc-architecture], defines several requisite components to implement SFC, including classifier, which performs classification for incoming packets, and Service Function Forwarder/SFF, which is responsible for forwarding traffic to one or more connected service functions according to the information carried in the SFC encapsulation, as well as handling traffic coming back from the SF and transporting traffic to another SFF and terminating the SFP. And what's more, another significant component is Service Function/SF, which is responsible for specific treatment of received packets. Based on these SFC components, the service function paths are created. Architecturally, within the same SFC-enabled domain, some SFPs may be fully specified, defining the exactly SFFs and SFs visited by classified packets, which are also named as Render Service Paths or RSPs. While other SFPs may be relatively vague, some SFFs or SFs are not designated at the classifier, instead, SFFs can decide which attached SFs to visit when packets arrive. 3.2. data plane in service function chain In SFC data plane, there also defines another important concept named SFC encapsulation. The SFC encapsulation includes service function path information which determines how the packets are forwarded in the SFC domain, and metadata/context data information when such metadata is required. In [I-D.ietf-sfc-nsh], the SFC encapsulation is defined as Network Service Header(NSH). In Figure 1, there is a Service Function Chain described as SFC1: Firewall(SF2) -- > DPI(SF4) -- > IPS(SF6). After instantiated, SFC1 is specified as a SFP: SFF1-->Firewall(SF2)-->SFF3-->DPI(SF4)-->SFF5-->IPS(SF6),which is identified by a SFPID. +------+ +-------+ +-------+ |SF2/Fw| |SF4/DPI| |SF6/IPS| +------+ +-------+ +-------+ | | | +-----------+ +----+ +----+ +----+ +------------+ |Classifier |----|SFF1|------|SFF3|------|SFF5|--------| Destination| +-----------+ +----+ +----+ +----+ +------------+ Wang & Meng Expires January 3, 2016 [Page 5] Internet-Draft IPv6 SFC July 2015 Figure 1: SFC Example In Figure 2, it illustrates the NSH format which is defined in [I-D.ietf-sfc-nsh]. 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Ver|O|C|R|R|R|R|R|R| Length | MD-type | Next Protocol | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Service Path ID | Service Index | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mandatory Context Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mandatory Context Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mandatory Context Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mandatory Context Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Optional Variable Length Context Headers ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: Network Service Header format When packets arrived at classifier, classification is triggered. Packets that satisfy classification rules are forwarded according to a specific SFP. And also, there may be some metadata/context data resulted from the classification. Then, the classifier encapsulates the SFP information and metadata information in the NSH, then encapsulates the NSH in the original packets, after that, chooses the appropriate overlay technology as transport layer to encapsulate the NSH packets, and forwards these encapsulated packets through overlay network to the next SFF. Packets arrive at an SFF from the overlay network. The SFF determines the appropriate SF the packets should be forwarded to via SFP information carried in NSH. After SF, the packets are returned to the SFF. According to the SFP information, if the next hop is another SF associated with that SFF, packets then are forwarded to another SF. If the next hop is not local SFs, packets then are encapsulated with appropriate overlay technology and forwarded to the next SFF along the path. If there is no next hop and the last SF has been serviced, the SFF then removes the NSH and delivers the original packets to the network. Wang & Meng Expires January 3, 2016 [Page 6] Internet-Draft IPv6 SFC July 2015 Sometimes, re-classification may occur on the SFF. After re- classification, the service function path and/or the metadata information may change; new NSH then is encapsulated in the packets instead of original NSH. In some cases, there may be some SFC-unaware SFs attached to the SFF, and then the SFF acts as a SFC Proxy to remove the NSH and forward the packets to the SFC-unaware SF. After receiving the served packets from the SFC-unaware SF, SFF then encapsulates the NSH again. Packets arrive at an SFC-aware SF from the attached SFF with NSH information. The SF acquires the metadata if there is metadata information in the NSH, and then serves the packets. If there is any requisite sharing metadata resulted from this SF, then this SF updates the metadata information in the NSH and then forwards the packets to the attached SFF. Wang & Meng Expires January 3, 2016 [Page 7] Internet-Draft IPv6 SFC July 2015 4. An analysis on service function chain over IPv6 network To achieve Service Function Chain, all the visited SFFs and SFs need recognize NSH. Based on this new technology, there derives several new companion technologies to achieve integrated SFC, such as SFC Proxy, SFC OAM, SFC Loop Detection and avoidance, etc. In fact, in IPv6 network, there has an alternative method to realize service function chain, which may be easier to deploy service function chain function rapidly than SFC technology. In the following sections, how to rapidly realize service fucntion chain in IPv6 is proposed. Specifically, the mechanism tries to encapsulate service function chain information in IPv6 extension headers of IPv6 packets, and then send the IPv6 packet along the path according to the service function chain informaiton. 4.1. Routing header in IPv6 network Section 4.4 in [RFC2460] defines routing headers in IPv6 network. The routing header is used by an IPv6 source to list one or more intermediate nodes to be visited on the way to a packet's destination. And the routing header is not examined or processed until it reaches the node identified in the Destination Address field of the IPv6 header. The routing header is identified by a Next Header value of 43 in the immediately preceding header, and has the following format in Figure 3: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header | Hdr Ext Len | Routing Type | Segments Left | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . type-specific data . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: Routing header in IPv6 network Analyzing the mechanism of the routing header, it is a little similar to some features of service function chain. For example, in IPv6 network, the source node encapsulates routing header according to the packets' destination, and the information in the routing header is the forwarding path information. Similarly, in SFC domain, the Wang & Meng Expires January 3, 2016 [Page 8] Internet-Draft IPv6 SFC July 2015 classifier encapsulates NSH according to the packets' 3-tuple or 5-tuple or other information in the packets, and the information in the NSH includes the forwarding path information. Certainly, there are some differentiated feathers in SFC, such as re-classification, simple offload, bypass and so on. There still has corresponding measures to work them out in IPv6 network. 4.2. Destination options headers in IPv6 network Section 4.6 in [RFC2460] defines destination option headers in IPv6 network. The destination option header is used to carry optional information that need be examined only by a packet's destination node(s), and has the following format in Figure 4: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header | Hdr Ext Len | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | . . . Options . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: Destination options headers in IPv6 network In SFC domain, metadata/context data is the context information shared between classifiers and SFs and among SFs, which means metadata only need be examined by classifiers and SFs. As for classifier, it is the source of SFC packets. As for SFs, they are intermediate destination nodes for SFC packets. Note that there are two possible ways to encode optional destination information in an IPv6 packet: either as an option in the Destination Option header, or as a separate extension header. Wang & Meng Expires January 3, 2016 [Page 9] Internet-Draft IPv6 SFC July 2015 5. Service function path information header over IPv6 data plane To carry service function paths information in IPv6 network, this document tries to extend IPv6 routing header to carry them. A new type of routing header is defined: the Service Function Chain routing type. And it is illustrated as follow in Figure 5: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header | Hdr Ext Len |SFC RoutingType| Segments Left | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Identifier Type| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . service function path information . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5: service funciton path information header over IPv6 data plane Next Header: identifies the type of header immediately following the SFC routing header. Hdr Ext Len: identifies the length of the SFC routing header in 8-octes units. SFC Routing Type: identifies the service function chain information is carried in the following data field, and need to be assigned by IANA. Segments Left: similar to service index in NSH. Segments Left is decremented at each destination node and it is used as a service index to locate the next destination node along the service function path. Identifier Type: identifies how to describe the service function path information. It may be a service function path identifier which identifies the service function path uniquely, or it may be a list of identifiers which identify the SFFs and/or SFs in the service function path, such as a list of addresses. Note that, except IPv6 routing header, carrying the service function paths information in a new IPv6 extension header can work out as well. Wang & Meng Expires January 3, 2016 [Page 10] Internet-Draft IPv6 SFC July 2015 6. Metadata/Context headers over IPv6 data plane To carry metadata/context headers information in IPv6 network, this document tries to extend IPv6 destination option header to carry them. A new option of destination option header is defined: Metadata Option. And it is illustrated as follow in Figure 6: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - |MD Option Type | Opt Data Len | Option Data +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - Figure 6: metadata/context headers over IPv6 network Option data: identifies the metadata/context header information which needs to be shared between classifiers and SFs and among SFs. In order to distinguish different metadata type, here tries to define several metadata sub-options. The format is as follow in Figure 7. For example, in Figure 8, there are network platform context information sub-option, network shared context information sub- option, service platform context information sub-option, service shared context information sub-option and some other optional variable length Context information sub-options. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - - - - - - - |Net-Pla MD Type| Sub-Opt Len | Network Platform Metadata ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - - - - - - - |Net-Sha MD Type| Sub-Opt Len | Network Shared Metadata ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - - - - - - - |Ser-Pla MD Type| Sub-Opt Len | Service Platform Metadata ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - - - - - - - |Ser-Sha MD Type| Sub-Opt Len | Service Shared Metadata ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - - - - - - - ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - - - - - - - Figure 7: sub-options for differentiated metadata/context headers Note that, except IPv6 destination option header, carrying the metadata/context headers in a new IPv6 extension header can work out as well. Wang & Meng Expires January 3, 2016 [Page 11] Internet-Draft IPv6 SFC July 2015 7. The procedures of IPv6 service function chain This section tries to explain how to work out SFC in IPv6 network through IPv6 extension headers. 7.1. Example 1 (Identifier type= a list of addresses which identify SFFs and/or SFs) Here consider the case of a source node S sending a packet to destination node D, after classification on the source node S, it turns out that the packet need to be served by SFC1: SF2 --> SF4. After instantiated, the exactly service function path is: SFF1-->SF2-->SFF3-->SF4. Every SFFs and SFs are identified by an IPv6 address respectively. So the packet is routed via intermediate nodes SFF1, SF2, SFF3, SF4 when traveling from the source node S to the destination node D. Here, tries to put SFF1/SF2/SFF3/SF4/D's IPv6 addresses in a sequence list, and encapsulate this list of address in the extended IPv6 routing header defined in Section 5 in this document, which is illustrated in Figure 8. What's more, the source node S may acquire some metadata/context headers information, which need to be encapsulated in the extended IPv6 routing header defined in Section 6 in this document. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header | Hdr Ext Len | Routing Type=5| Segments Letf | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Iden Type=2 | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Destination-IPv6 ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ SF4-IPv6 ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ SFF3-IPv6 ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ SF2-IPv6 ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ SFF1-IPv6 ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 8: a list of addresses to identify Service funciton path information After that, mostly, the forwarding procedures are similar to the procedures defined in section 4.4 and section 4.6 in RFC2460. Such as, SFFs and SFs as intermediate destination nodes need to process the metadata/context headers information in the destination option Wang & Meng Expires January 3, 2016 [Page 12] Internet-Draft IPv6 SFC July 2015 headers, if needed, update the metadata/context headers information to be shared by the following nodes. And also, SFFs and SFs as intermediate destination nodes need to analyze the service function path information and extract the next destination to update the IPv6 destination address in IPv6 header. In some cases, the SFs' IPv6 address may be local IPv6 address, and then the SFFs need to recognize them and forward them correctly. In some other cases, the source node cannot get all the exactly SFFs/ SFs' IPv6 addresses, then the intermediate nodes may need to update the IPv6 addresses list in the service function path information. Also, re-classification may be occurred in some intermediate nodes to re-steer the packets with updated list of addressed in service function path information and with updated metadata/context headers. What's more, sometimes, according to the IPv6 destination address, packets are forwarded to the next destination nodes may be through different transport layer protocols, such as native IPv6 transport layer protocol or MPLS transport layer protocol, or GRE transport layer protocol or other transport layer protocols. 7.2. Example 2 (Identifier type = service function path identifier) Here still consider the case of a source node S sending a packet to destination node D, after classification on the source node S, it turns out that the packet need to be served by SFC1: SF2 --> SF4. After instantiated, the exactly service function path is: SFF1-->SF2-->SFF3-->SF4, which is correspond to a service function path identifier: SFPID1. Here tries to encapsulate a SFPID to describe the whole service function path information in the IPv6 extended header defined in section 5 in this document, which is relatively short and simple to carry and is illustrated in Figure 9. After acquiring the SFPID information, then acquire the corresponding metadata/context header, and encapsulate them in the extended IPv6 routing header defined in Section 6 in this document. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header | Hdr Ext Len | Routing Type=5| Segments Left | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Iden Type=1 | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ SFPID ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Wang & Meng Expires January 3, 2016 [Page 13] Internet-Draft IPv6 SFC July 2015 Figure 9: Network Service Header format The source node S analyzes the SFPID and Segments Left in the routing header, and extracts the next SFF IPv6 address to update the IPv6 destination address in IPv6 header, then forwards the packet to the destination through transport layer protocols, including native IPv6 transport layer protocol or MPLS transport layer protocol, or GRE transport layer protocol or other transport layer protocols. When SFFs and/or SFs receive the packets, analyze the service function path information and metadata/context headers information, and take advantage of these information to determine the next destination node. To help extract the next destination node, here may be need a service function path forwarding table corresponding to each SFPID to identifier where is the next station. Sometimes, re-classification may be occurred in some intermediate nodes to re-steer the packets with updated SFPID in service function path information and with updated metadata/context headers. Wang & Meng Expires January 3, 2016 [Page 14] Internet-Draft IPv6 SFC July 2015 8. Service function chain simple offload over IPv6 network TBD Wang & Meng Expires January 3, 2016 [Page 15] Internet-Draft IPv6 SFC July 2015 9. Security Considerations TBD Wang & Meng Expires January 3, 2016 [Page 16] Internet-Draft IPv6 SFC July 2015 10. IANA Considerations TBD Wang & Meng Expires January 3, 2016 [Page 17] Internet-Draft IPv6 SFC July 2015 11. References 11.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. 11.2. Informative References [I-D.ietf-sfc-architecture] Halpern, J. and C. Pignataro, "Service Function Chaining (SFC) Architecture", draft-ietf-sfc-architecture-09 (work in progress), June 2015. [I-D.ietf-sfc-nsh] Quinn, P. and U. Elzur, "Network Service Header", draft-ietf-sfc-nsh-00 (work in progress), March 2015. Wang & Meng Expires January 3, 2016 [Page 18] Internet-Draft IPv6 SFC July 2015 Authors' Addresses Cui Wang ZTE Corporation No.50 Software Avenue, Yuhuatai District Nanjing China Email: wang.cui1@zte.com.cn Wei Meng ZTE Corporation No.50 Software Avenue, Yuhuatai District Nanjing China Email: meng.wei2@zte.com.cn,vally.meng@gmail.com Wang & Meng Expires January 3, 2016 [Page 19]