idnits 2.17.1 draft-wang-6man-ipv6-service-function-chain-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 3 instances of too long lines in the document, the longest one being 6 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (January 6, 2016) is 3033 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Downref: Normative reference to an Informational RFC: RFC 7665 == Outdated reference: A later version (-28) exists of draft-ietf-sfc-nsh-01 Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SFC WG C. Wang 3 Internet-Draft W. Meng 4 Intended status: Standards Track ZTE Corporation 5 Expires: July 9, 2016 January 6, 2016 7 IPv6 Service function Chain 8 draft-wang-6man-ipv6-service-function-chain-01 10 Abstract 12 Service function chain is the definition of an ordered set of service 13 functions. After instantiated, the service function path is created 14 and the classified traffic is steered through the corresponding 15 service function path and then forwarded to the final destination. 16 This document tries to describe how to use IPv6 data plane and IPv6 17 extension headers to realize service function chain in IPv6 network. 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on July 9, 2016. 36 Copyright Notice 38 Copyright (c) 2016 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Convention and Terminology . . . . . . . . . . . . . . . . . . 4 55 3. An introduction on service function chain . . . . . . . . . . 5 56 3.1. service function chain components . . . . . . . . . . . . 5 57 3.2. data plane in service function chain . . . . . . . . . . . 5 58 4. An analysis on service function chain over IPv6 network . . . 8 59 4.1. Routing header in IPv6 network . . . . . . . . . . . . . . 8 60 4.2. Destination options headers in IPv6 network . . . . . . . 9 61 5. Service function path information header over IPv6 data 62 plane . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 63 6. Metadata/Context headers over IPv6 data plane . . . . . . . . 11 64 7. The procedures of IPv6 service function chain . . . . . . . . 12 65 7.1. Example 1 (Identifier type= a list of addresses which 66 identify SFFs and/or SFs) . . . . . . . . . . . . . . . . 12 67 7.2. Example 2 (Identifier type = service function path 68 identifier) . . . . . . . . . . . . . . . . . . . . . . . 13 69 8. Service function chain simple offload over IPv6 network . . . 15 70 9. Security Considerations . . . . . . . . . . . . . . . . . . . 16 71 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 72 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 73 11.1. Normative References . . . . . . . . . . . . . . . . . . . 18 74 11.2. Informative References . . . . . . . . . . . . . . . . . . 18 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 77 1. Introduction 79 Service function chain is the definition of an ordered set of service 80 functions. After instantiated, the service function path is created 81 and the classified traffic is steered through the corresponding 82 service function path and then forwarded to the final destination. 84 This document tries to describe how to use IPv6 data plane and IPv6 85 extension headers to realize service function chain in IPv6 network. 86 Specifically, this document tries to provide: 88 In section 3, an introduction on service function chain. 90 In section 4, an analysis on service function chain over IPv6 network 92 In section 5, service function path information header over IPv6 data 93 plane 95 In section 6, context headers over IPv6 data plane 97 In section 7, the procedures of IPv6 service function chain 99 In section 8, simple offload over IPv6 network 101 In section 9, security for IPv6 service function chain 103 2. Convention and Terminology 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 107 document are to be interpreted as described in [RFC2119]. 109 The terms about SFC are all defined in [RFC7665]. 111 The terms about IPv6 are all defined in [RFC2460]. 113 3. An introduction on service function chain 115 3.1. service function chain components 117 Service function chain, defined in [RFC7665], defines several 118 requisite components to implement SFC, including classifier, which 119 performs classification for incoming packets, and Service Function 120 Forwarder/SFF, which is responsible for forwarding traffic to one or 121 more connected service functions according to the information carried 122 in the SFC encapsulation, as well as handling traffic coming back 123 from the SF and transporting traffic to another SFF and terminating 124 the SFP. And what's more, another significant component is Service 125 Function/SF, which is responsible for specific treatment of received 126 packets. 128 Based on these SFC components, the service function paths are 129 created. Architecturally, within the same SFC-enabled domain, some 130 SFPs may be fully specified, defining the exactly SFFs and SFs 131 visited by classified packets, which are also named as Render Service 132 Paths or RSPs. While other SFPs may be relatively vague, some SFFs 133 or SFs are not designated at the classifier, instead, SFFs can decide 134 which attached SFs to visit when packets arrive. 136 3.2. data plane in service function chain 138 In SFC data plane, there also defines another important concept named 139 SFC encapsulation. The SFC encapsulation includes service function 140 path information which determines how the packets are forwarded in 141 the SFC domain, and metadata/context data information when such 142 metadata is required. In [I-D.ietf-sfc-nsh], the SFC encapsulation 143 is defined as Network Service Header(NSH). 145 In Figure 1, there is a Service Function Chain described as SFC1: 146 Firewall(SF2) -- > DPI(SF4) -- > IPS(SF6). After instantiated, SFC1 147 is specified as a SFP: 148 SFF1-->Firewall(SF2)-->SFF3-->DPI(SF4)-->SFF5-->IPS(SF6),which is 149 identified by a SFPID. 151 +------+ +-------+ +-------+ 152 |SF2/Fw| |SF4/DPI| |SF6/IPS| 153 +------+ +-------+ +-------+ 154 | | | 155 +-----------+ +----+ +----+ +----+ +------------+ 156 |Classifier |----|SFF1|------|SFF3|------|SFF5|--------| Destination| 157 +-----------+ +----+ +----+ +----+ +------------+ 158 Figure 1: SFC Example 160 In Figure 2, it illustrates the NSH format which is defined in 161 [I-D.ietf-sfc-nsh]. 163 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 164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 165 |Ver|O|C|R|R|R|R|R|R| Length | MD-type | Next Protocol | 166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 167 | Service Path ID | Service Index | 168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 169 | Mandatory Context Header | 170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 171 | Mandatory Context Header | 172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 173 | Mandatory Context Header | 174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 175 | Mandatory Context Header | 176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 177 | | 178 ~ Optional Variable Length Context Headers ~ 179 | | 180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 182 Figure 2: Network Service Header format 184 When packets arrived at classifier, classification is triggered. 185 Packets that satisfy classification rules are forwarded according to 186 a specific SFP. And also, there may be some metadata/context data 187 resulted from the classification. Then, the classifier encapsulates 188 the SFP information and metadata information in the NSH, then 189 encapsulates the NSH in the original packets, after that, chooses the 190 appropriate overlay technology as transport layer to encapsulate the 191 NSH packets, and forwards these encapsulated packets through overlay 192 network to the next SFF. 194 Packets arrive at an SFF from the overlay network. The SFF 195 determines the appropriate SF the packets should be forwarded to via 196 SFP information carried in NSH. After SF, the packets are returned 197 to the SFF. According to the SFP information, if the next hop is 198 another SF associated with that SFF, packets then are forwarded to 199 another SF. If the next hop is not local SFs, packets then are 200 encapsulated with appropriate overlay technology and forwarded to the 201 next SFF along the path. If there is no next hop and the last SF has 202 been serviced, the SFF then removes the NSH and delivers the original 203 packets to the network. 205 Sometimes, re-classification may occur on the SFF. After re- 206 classification, the service function path and/or the metadata 207 information may change; new NSH then is encapsulated in the packets 208 instead of original NSH. 210 In some cases, there may be some SFC-unaware SFs attached to the SFF, 211 and then the SFF acts as a SFC Proxy to remove the NSH and forward 212 the packets to the SFC-unaware SF. After receiving the served 213 packets from the SFC-unaware SF, SFF then encapsulates the NSH again. 215 Packets arrive at an SFC-aware SF from the attached SFF with NSH 216 information. The SF acquires the metadata if there is metadata 217 information in the NSH, and then serves the packets. If there is any 218 requisite sharing metadata resulted from this SF, then this SF 219 updates the metadata information in the NSH and then forwards the 220 packets to the attached SFF. 222 4. An analysis on service function chain over IPv6 network 224 To achieve Service Function Chain, all the visited SFFs and SFs need 225 recognize NSH. Based on this new technology, there derives several 226 new companion technologies to achieve integrated SFC, such as SFC 227 Proxy, SFC OAM, SFC Loop Detection and avoidance, etc. 229 In fact, in IPv6 network, there has an alternative method to realize 230 service function chain, which may be easier to deploy service 231 function chain function rapidly than SFC technology. 233 In the following sections, how to rapidly realize service fucntion 234 chain in IPv6 is proposed. Specifically, the mechanism tries to 235 encapsulate service function chain information in IPv6 extension 236 headers of IPv6 packets, and then send the IPv6 packet along the path 237 according to the service function chain informaiton. 239 4.1. Routing header in IPv6 network 241 Section 4.4 in [RFC2460] defines routing headers in IPv6 network. 243 The routing header is used by an IPv6 source to list one or more 244 intermediate nodes to be visited on the way to a packet's 245 destination. And the routing header is not examined or processed 246 until it reaches the node identified in the Destination Address field 247 of the IPv6 header. The routing header is identified by a Next 248 Header value of 43 in the immediately preceding header, and has the 249 following format in Figure 3: 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 | Next Header | Hdr Ext Len | Routing Type | Segments Left | 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 | | 255 . . 256 . type-specific data . 257 . . 258 | | 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 Figure 3: Routing header in IPv6 network 263 Analyzing the mechanism of the routing header, it is a little similar 264 to some features of service function chain. For example, in IPv6 265 network, the source node encapsulates routing header according to the 266 packets' destination, and the information in the routing header is 267 the forwarding path information. Similarly, in SFC domain, the 268 classifier encapsulates NSH according to the packets' 3-tuple or 269 5-tuple or other information in the packets, and the information in 270 the NSH includes the forwarding path information. Certainly, there 271 are some differentiated feathers in SFC, such as re-classification, 272 simple offload, bypass and so on. There still has corresponding 273 measures to work them out in IPv6 network. 275 4.2. Destination options headers in IPv6 network 277 Section 4.6 in [RFC2460] defines destination option headers in IPv6 278 network. 280 The destination option header is used to carry optional information 281 that need be examined only by a packet's destination node(s), and has 282 the following format in Figure 4: 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 | Next Header | Hdr Ext Len | | 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 287 | | 288 . . 289 . Options . 290 . . 291 | | 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 Figure 4: Destination options headers in IPv6 network 296 In SFC domain, metadata/context data is the context information 297 shared between classifiers and SFs and among SFs, which means 298 metadata only need be examined by classifiers and SFs. As for 299 classifier, it is the source of SFC packets. As for SFs, they are 300 intermediate destination nodes for SFC packets. 302 Note that there are two possible ways to encode optional destination 303 information in an IPv6 packet: either as an option in the Destination 304 Option header, or as a separate extension header. 306 5. Service function path information header over IPv6 data plane 308 To carry service function paths information in IPv6 network, this 309 document tries to extend IPv6 routing header to carry them. A new 310 type of routing header is defined: the Service Function Chain routing 311 type. And it is illustrated as follow in Figure 5: 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 314 | Next Header | Hdr Ext Len |SFC RoutingType| Segments Left | 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 |Identifier Type| Reserved | 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 . . 319 . service function path information . 320 . . 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 Figure 5: service funciton path information header over IPv6 data 324 plane 326 Next Header: identifies the type of header immediately following the 327 SFC routing header. 329 Hdr Ext Len: identifies the length of the SFC routing header in 330 8-octes units. 332 SFC Routing Type: identifies the service function chain information 333 is carried in the following data field, and need to be assigned by 334 IANA. 336 Segments Left: similar to service index in NSH. Segments Left is 337 decremented at each destination node and it is used as a service 338 index to locate the next destination node along the service function 339 path. 341 Identifier Type: identifies how to describe the service function path 342 information. It may be a service function path identifier which 343 identifies the service function path uniquely, or it may be a list of 344 identifiers which identify the SFFs and/or SFs in the service 345 function path, such as a list of addresses. 347 Note that, except IPv6 routing header, carrying the service function 348 paths information in a new IPv6 extension header can work out as 349 well. 351 6. Metadata/Context headers over IPv6 data plane 353 To carry metadata/context headers information in IPv6 network, this 354 document tries to extend IPv6 destination option header to carry 355 them. A new option of destination option header is defined: Metadata 356 Option. And it is illustrated as follow in Figure 6: 358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - 359 |MD Option Type | Opt Data Len | Option Data 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - 362 Figure 6: metadata/context headers over IPv6 network 364 Option data: identifies the metadata/context header information which 365 needs to be shared between classifiers and SFs and among SFs. 367 In order to distinguish different metadata type, here tries to define 368 several metadata sub-options. The format is as follow in Figure 7. 369 For example, in Figure 8, there are network platform context 370 information sub-option, network shared context information sub- 371 option, service platform context information sub-option, service 372 shared context information sub-option and some other optional 373 variable length Context information sub-options. 375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - - - - - - - 376 |Net-Pla MD Type| Sub-Opt Len | Network Platform Metadata ~ 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - - - - - - - 378 |Net-Sha MD Type| Sub-Opt Len | Network Shared Metadata ~ 379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - - - - - - - 380 |Ser-Pla MD Type| Sub-Opt Len | Service Platform Metadata ~ 381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - - - - - - - 382 |Ser-Sha MD Type| Sub-Opt Len | Service Shared Metadata ~ 383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - - - - - - - 384 ~ ~ 385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - - - - - - - 387 Figure 7: sub-options for differentiated metadata/context headers 389 Note that, except IPv6 destination option header, carrying the 390 metadata/context headers in a new IPv6 extension header can work out 391 as well. 393 7. The procedures of IPv6 service function chain 395 This section tries to explain how to work out SFC in IPv6 network 396 through IPv6 extension headers. 398 7.1. Example 1 (Identifier type= a list of addresses which identify 399 SFFs and/or SFs) 401 Here consider the case of a source node S sending a packet to 402 destination node D, after classification on the source node S, it 403 turns out that the packet need to be served by SFC1: SF2 --> SF4. 404 After instantiated, the exactly service function path is: 405 SFF1-->SF2-->SFF3-->SF4. Every SFFs and SFs are identified by an 406 IPv6 address respectively. So the packet is routed via intermediate 407 nodes SFF1, SF2, SFF3, SF4 when traveling from the source node S to 408 the destination node D. Here, tries to put SFF1/SF2/SFF3/SF4/D's IPv6 409 addresses in a sequence list, and encapsulate this list of address in 410 the extended IPv6 routing header defined in Section 5 in this 411 document, which is illustrated in Figure 8. What's more, the source 412 node S may acquire some metadata/context headers information, which 413 need to be encapsulated in the extended IPv6 routing header defined 414 in Section 6 in this document. 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 | Next Header | Hdr Ext Len | Routing Type=5| Segments Letf | 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 419 | Iden Type=2 | Reserved | 420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 ~ Destination-IPv6 ~ 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 423 ~ SF4-IPv6 ~ 424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 425 ~ SFF3-IPv6 ~ 426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 427 ~ SF2-IPv6 ~ 428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 429 ~ SFF1-IPv6 ~ 430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 432 Figure 8: a list of addresses to identify Service funciton path 433 information 435 After that, mostly, the forwarding procedures are similar to the 436 procedures defined in section 4.4 and section 4.6 in RFC2460. Such 437 as, SFFs and SFs as intermediate destination nodes need to process 438 the metadata/context headers information in the destination option 439 headers, if needed, update the metadata/context headers information 440 to be shared by the following nodes. And also, SFFs and SFs as 441 intermediate destination nodes need to analyze the service function 442 path information and extract the next destination to update the IPv6 443 destination address in IPv6 header. 445 In some cases, the SFs' IPv6 address may be local IPv6 address, and 446 then the SFFs need to recognize them and forward them correctly. 448 In some other cases, the source node cannot get all the exactly SFFs/ 449 SFs' IPv6 addresses, then the intermediate nodes may need to update 450 the IPv6 addresses list in the service function path information. 452 Also, re-classification may be occurred in some intermediate nodes to 453 re-steer the packets with updated list of addressed in service 454 function path information and with updated metadata/context headers. 456 What's more, sometimes, according to the IPv6 destination address, 457 packets are forwarded to the next destination nodes may be through 458 different transport layer protocols, such as native IPv6 transport 459 layer protocol or MPLS transport layer protocol, or GRE transport 460 layer protocol or other transport layer protocols. 462 7.2. Example 2 (Identifier type = service function path identifier) 464 Here still consider the case of a source node S sending a packet to 465 destination node D, after classification on the source node S, it 466 turns out that the packet need to be served by SFC1: SF2 --> SF4. 467 After instantiated, the exactly service function path is: 468 SFF1-->SF2-->SFF3-->SF4, which is correspond to a service function 469 path identifier: SFPID1. Here tries to encapsulate a SFPID to 470 describe the whole service function path information in the IPv6 471 extended header defined in section 5 in this document, which is 472 relatively short and simple to carry and is illustrated in Figure 9. 473 After acquiring the SFPID information, then acquire the corresponding 474 metadata/context header, and encapsulate them in the extended IPv6 475 routing header defined in Section 6 in this document. 477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 478 | Next Header | Hdr Ext Len | Routing Type=5| Segments Left | 479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 480 | Iden Type=1 | Reserved | 481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 482 ~ SFPID ~ 483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 484 Figure 9: Network Service Header format 486 The source node S analyzes the SFPID and Segments Left in the routing 487 header, and extracts the next SFF IPv6 address to update the IPv6 488 destination address in IPv6 header, then forwards the packet to the 489 destination through transport layer protocols, including native IPv6 490 transport layer protocol or MPLS transport layer protocol, or GRE 491 transport layer protocol or other transport layer protocols. 493 When SFFs and/or SFs receive the packets, analyze the service 494 function path information and metadata/context headers information, 495 and take advantage of these information to determine the next 496 destination node. To help extract the next destination node, here 497 may be need a service function path forwarding table corresponding to 498 each SFPID to identifier where is the next station. 500 Sometimes, re-classification may be occurred in some intermediate 501 nodes to re-steer the packets with updated SFPID in service function 502 path information and with updated metadata/context headers. 504 8. Service function chain simple offload over IPv6 network 506 TBD 508 9. Security Considerations 510 TBD 512 10. IANA Considerations 514 TBD 516 11. References 518 11.1. Normative References 520 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 521 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 522 RFC2119, March 1997, 523 . 525 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 526 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 527 December 1998, . 529 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 530 Chaining (SFC) Architecture", RFC 7665, DOI 10.17487/ 531 RFC7665, October 2015, 532 . 534 11.2. Informative References 536 [I-D.ietf-sfc-nsh] 537 Quinn, P. and U. Elzur, "Network Service Header", 538 draft-ietf-sfc-nsh-01 (work in progress), July 2015. 540 Authors' Addresses 542 Cui(Linda) Wang 543 ZTE Corporation 544 No.50 Software Avenue, Yuhuatai District 545 Nanjing 546 China 548 Email: wang.cui1@zte.com.cn 550 Wei Meng 551 ZTE Corporation 552 No.50 Software Avenue, Yuhuatai District 553 Nanjing 554 China 556 Email: meng.wei2@zte.com.cn,vally.meng@gmail.com