idnits 2.17.00 (12 Aug 2021) /tmp/idnits46468/draft-jacquenet-sfc-ipv6-eh-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 7, 2016) is 2319 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'IPFIX' Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Jacquenet 3 Internet-Draft M. Boucadair 4 Intended status: Standards Track Orange 5 Expires: July 10, 2016 January 7, 2016 7 An IPv6 Extension Header for Service Function Chaining (SFC) 8 draft-jacquenet-sfc-ipv6-eh-01 10 Abstract 12 This document specifies an IPv6 extension header for Service Function 13 Chaining (SFC) purposes. This extension header is used by SFC data 14 plane elements to make forwarding decisions in an IPv6-enabled SFC 15 domain and it conveys metadata that are processed by SFC-aware nodes. 17 This extension is intended to be used within a single administrative 18 domain. 20 Requirements Language 22 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 23 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 24 document are to be interpreted as described in RFC 2119 [RFC2119]. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on July 10, 2016. 43 Copyright Notice 45 Copyright (c) 2016 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3. SFC IPv6 Extension Header Format . . . . . . . . . . . . . . 3 63 3.1. Source Routed SFP . . . . . . . . . . . . . . . . . . . . 6 64 4. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 7 65 4.1. Generic Considerations . . . . . . . . . . . . . . . . . 7 66 4.2. Generating the SFC Extension Header . . . . . . . . . . . 8 67 4.3. Processing the SFC Extension Header . . . . . . . . . . . 8 68 4.3.1. Processing Source-Routed SFP Information . . . . . . 8 69 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 70 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 71 6.1. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 10 72 6.2. Invalid Context Information . . . . . . . . . . . . . . . 10 73 6.3. Forwarding Threats . . . . . . . . . . . . . . . . . . . 10 74 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 75 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 76 8.1. Normative References . . . . . . . . . . . . . . . . . . 11 77 8.2. Informative References . . . . . . . . . . . . . . . . . 11 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 80 1. Introduction 82 Service Function Chaining (SFC) can be seen as a technique that 83 facilitates the dynamic enforcement of differentiated traffic 84 forwarding policies within an SFC-enabled domain. SFC operation 85 assumes the manipulation of some information that is typically 86 carried by packets within an SFC-enabled domain. In particular, this 87 information is meant to assist Service Function Forwarders (SFFs) in 88 making forwarding decisions within the SFC-enabled domain. 90 The overall SFC problem space is discussed in [RFC7498], while a data 91 plane architecture is documented in [RFC7665]. 93 Several options can be used to carry SFC-specific information. Some 94 of them can take advantage of various existing tools such as 95 encapsulation schemes (e.g., IP-in-IP), or specific fields in an IP 96 header. This document specifies an IPv6 Extension Header ( 97 [RFC6564]) to carry SFC-related information. 99 The SFC extension header is intended to be used within a single 100 administrative domain. 102 The reader should be familiar with the terms defined in [RFC7498] and 103 [RFC7665]. 105 2. Overview 107 Unlike some other solutions that require the use of yet another shim 108 layer to carry SFC information, the use of an IPv6 Extension Header 109 (EH) in IPv6-enabled SFC domains has the advantage to get rid of any 110 specific transport encapsulation scheme when forwarding packets 111 between nodes that are connected to the same subnet. Figure 1 shows 112 the case of a packet that carries the SFC EH and which is forwarded 113 to the SFC Next Hop that is connected to the same subnet. 115 Figure 2 shows a packet that is encapsulated in an IPv6 packet that 116 contains the SFC EH. Such encapsulation scheme can also be used to 117 carry IPv4 packets within an IPv6-enabled SFC domain. 119 +--------+--------------+-------------..-+ 120 | IPv6 | SFC | IPv6 | 121 | Header | Ext. Header | Payload | 122 +--------+--------------+-------------..-+ 124 Figure 1 126 +----------+-------------+---------+-------------..-+ 127 |Outer IPv6| SFC |Inner IP | IP | 128 | Header | Ext. Header | Header | Payload | 129 +----------+-------------+---------+-------------..-+ 131 |--Original IP packet------| 132 |-----------Encapsulated IPv6 packet----------------| 134 Figure 2 136 3. SFC IPv6 Extension Header Format 138 The IPv6 Extension Header to carry SFC metadata has format shown in 139 Figure 3. 141 0 1 2 3 142 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 143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 144 | Next Header | Hdr Ext Len | Flags | SF Index | 145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 146 | Service Function Chain Identifier (SFC ID) | 147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 148 | (Optional) Service Function Path Identifier (SFP ID) | 149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 150 | | 151 . . 152 . (Optional) Information Elements . 153 . . 154 | | 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 157 Figure 3 159 The description of the fields is as follows: 161 Next Header: 8-bit selector. Identifies the type of header 162 immediately following the extension header. 164 Hdr Ext Len: 8-bit unsigned integer. Length of the extension header 165 in 8-octet units, excluding the first 8 octets. 167 Flags: The Flags field comprises a set of 8 flags: 169 +-+-+-+-+-+-+-+-+ 170 |P|E|r|r|r|r|r|M| 171 +-+-+-+-+-+-+-+-+ 173 where "rrrrr" are reserved bits for future assignment as 174 additional flag bits. r bits MUST each be sent as zero and MUST be 175 ignored on receipt. 177 When set, the P-flag indicates that a Service Function Path 178 Identifier (SFP ID) field is present in the SFC EH. This flag is 179 set to 0 by default: this means that there is no SFP ID 180 information carried in the SFC EH. 182 When set, the E-flag indicates that a source routed SFP field is 183 present in the SFC EH. This flag is set by default to 0, meaning 184 there is no source routed SFP field present in the SFC EH. 186 When set, the M-flag indicates that an extended set of a 32-bit 187 encoded Flags field is present in the SFC EH. The default value 188 of the M flag is 0. This feature allows to extend the SFC EH with 189 new flags while ensuring backward compatibility. When present, 190 the extended flag field MUST be positioned right after the SFC ID 191 field. 193 SF Index: 8-bit unsigned integer. This field is decremented by 1 194 and used to detect SFC loops. 196 Service Function Chain Identifier (SFC ID): 8-bit unsigned integer. 197 Identifies the Service Function Chain that is associated to the 198 IPv6 packet. 200 (Optional) Service Function Path Identifier (SFP ID): This field 201 MUST be supplied only if 'P' flag is set. This field is used to 202 convey an identifier of a path that is bound to a given service 203 function chain. A null value of this field means that no specific 204 constraint is to be applied when forwarding this packet with this 205 service function chain. It is RECOMMENDED to use this field only 206 if non-null identifiers are to be carried in the SFC EH. A null 207 value with P-flag set leads to the same behavior as with P-flag 208 set to 0. 210 (Optional) Information Elements: Conveys one or multiple optional 211 data that may be supplied within an SFC-enabled domain. The 212 format of an optional Information Element can either be associated 213 with the definition of a new flag or encoded according to the 214 following TLV format Figure 4. 216 0 1 2 3 217 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 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 | Registry ID | Type | Length | Originator Len| 220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 221 // Originator ID (Variable) // 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 // Data (Variable) // 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 226 Figure 4 228 The description of the fields is as follows: 230 Registry ID: In order to foster service innovation, this field 231 allows to inherit from existing code point registries that are 232 likely to be useful in a SFC context. The following value is 233 reserved by this specification: 235 1: IPFIX [IPFIX]. 237 Type: Indicates the code point of the information element. If 238 Registry ID is set, then the interpretation of this field must 239 conform to the one defined for that specific registry. 241 Length: Indicates, in octets, the length of the data carried in 242 the Information Element (including the "Originator Len" and 243 "Originator ID" fields). 245 Originator Len: Indicates, in octets, the length of the 246 "Originator ID" field. 248 Originator ID: Provides the identifier of the entity that 249 injected this Information Element in the SFC Extension Header. 251 Originator ID: Conveys the identifier of the entity that injected 252 this Information Element in the SFC header (e.g., a service 253 function identifier, a classifier, etc.). This document does 254 not make any assumption about the structure of the information 255 carried in this field because this is deployment-specific. 256 This information is used by SFC-aware elements to enforce 257 policies such as: process a context information if and only if 258 it was supplied by a given entity. This information can be 259 used as a safeguard against misbehaving nodes that inject 260 illegitimate data in the SFC EH. 262 Data (Variable): The semantics of this field depend on the 263 "Registry ID" and "Type" fields. 265 3.1. Source Routed SFP 267 If the E-flag is set, a "Source Routed SFP" field MUST be present in 268 the SFC Extension Header. This field MUST be positioned right after 269 the "Service Function Path Identifier (SFP ID)" field and "Extended 270 Flag bits", if P-flag or M-flag are set. It MUST be positioned right 271 after the "Service Function Chain Identifier (SFC ID)" field if 272 P-flag and M-flag are both set to 0. 274 0 1 2 3 275 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 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 277 // (Optional) Locators[1..n] (Variable) // 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 Figure 5 282 The optional "Source Routed SFP" field is structured as a vector of 283 SF locators (whereas a SF locator could be an IP address, a MAC 284 address or a FQDN, for example). 286 A SFP Source Route is said to be "strict" when the exact set of all 287 the SF instances that need to be invoked along the SFP is explicitly 288 and exhaustively mentioned in the field. Each locator in the list is 289 encoded as follows: 291 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 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 | Locator Len | Locator (Variable) // 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 Figure 6 298 A SFP Source Route is said to be "loose" when only a subset of the SF 299 instances, that need to be invoked in the context of a given service 300 function chain, is mentioned in the field. The other SFs that need 301 to be invoked will be set to "ANY" in the field, meaning that SFF are 302 free to forward the packet towards the next SF instance that needs to 303 be invoked as per the SFC instructions and according to SFC next hop 304 resolution procedure or a result of load-balancing scheme. "ANY" 305 corresponds to "Locator Len" set to "0" and no "Locator" field. 307 For the sake of optimization, the encoding of loose source routes 308 could be improved by indicating only explicit hops (i.e., 309 Locator!=ANY). A Hop Index is also provided for each included 310 locator to help identifying the node when progressing a packet 311 within an SFC-enabled domain. 313 A locator in the list set to 'ANY' is an indication that the 314 selection of the exact SF instance to invoke is left to the SFF or to 315 some kind of SF load-balancing mechanism. 317 The Source Routed SFP field of the SFC EH MUST NOT include a list of 318 locators that are all set to "ANY". 320 4. Operation 322 4.1. Generic Considerations 324 Routers MUST NOT process the SFC EH unless they are explicitly 325 configured to do so. Processing the SFC EH MUST be disabled by 326 default. Typically, routers that are not within an SFC-enabled 327 domain MUST NOT be configured to process the SFC EH. 329 To minimize fragmentation issues, it is recommended to configure MTU 330 sizes that allow for the SFC EH to be inserted/updated in-path. 332 4.2. Generating the SFC Extension Header 334 A classifier typically inserts the SFC EH to every incoming packet 335 that matches one of the entries of the SFC classification policy 336 table maintained by the classifier. The classifier is supposed to be 337 configured with the set of context information that must be supplied 338 for each service function. If no such instruction is provided, the 339 classifier inserts by default an identifier of the service chain and 340 optionally an identifier of the service function path. 342 The classifier may also inject a source SFP as part of the SFC EH 343 that will be injected in packet matching its classification policies. 345 The SFC EH is inserted either following the format in Figure 1 (if 346 the next hop is within the same subnet as the classifier) or as shown 347 in Figure 2 otherwise. When an encapsulation is required, the 348 destination IP address is set to the IPv6 address of the first hop in 349 the chain. 351 SFC-aware nodes that are configured to inject context information for 352 a given service function chain can update the context of an SFC EH. 354 4.3. Processing the SFC Extension Header 356 Upon receipt of an IPv6 packet that carries the SFC EH, a SFF must, 357 eventually decapsulate the packet, and process the metadata 358 information carried in the SFC EH: typically, the SF node that embeds 359 the SFF capability will use these metadata to (1) position itself in 360 the forwarding path, (2) determine which SF instance(s) need to be 361 invoked next and (3) make its forwarding decision according to the 362 SFC instructions carried in the SFC EH and as per the matching entry 363 of its SFC Forwarding Policy Table. 365 Once the packet is processed by the corresponding SF, SF Index is 366 decremented by 1. 368 An SFC-aware node MUST discard packets with an "SF Index" equal to 0. 369 This event must be logged locally. 371 4.3.1. Processing Source-Routed SFP Information 373 If the SFC EH carried in the incoming IPv6 packet contains Source- 374 Routed SFP (Section 3.1), the SFF will forward the packet according 375 to the instructions carried in the corresponding field: if this is a 376 Strict Source Route, the SFF will forward the packet towards the next 377 SF node that embeds the SF instance identified by the SF Locator 378 carried in the Source-Routed SFP field, possibly upon completion of 379 some SF operation, depending on the nature of the chain and its 380 corresponding instructions. 382 If the explicit route happens to be a loose source route: 384 1. If the next SF instance that needs to be invoked is explicitly 385 identified by its Locator, then the SFF forwards the packet 386 accordingly: the next SF to be invoked can be reached according 387 to the corresponding entry of its SFC Forwarding Policy Table. 389 2. If the next SF instance that needs to be invoked is valued to 390 "ANY", then the SFF forwards the packet according to the best 391 matching entry of its SFC Forwarding Policy Table, as per the SFC 392 ID and Hop Index carried in the SFC EH. 394 By default, packets destined outside the SFC-enabled domain MUST be 395 strip any SFC EH that is carried in the packet. 397 When a node receives an IPv6 packet with a"ICMPv6 Destination 398 Unreachable Code, "Error in Source Routing Header"xxx 400 5. IANA Considerations 402 This document requests IANA to assign the following values from the 403 register in http://www.iana.org/assignments/ipv6-parameters/ipv6- 404 parameters.xhtml#extension-header: 406 +-----------------+----------------------+-----------------+ 407 | Protocol Number | Description | Reference | 408 +-----------------+----------------------+-----------------+ 409 | TBD | SFC Extension Header | [This document] | 410 +-----------------+----------------------+-----------------+ 412 Also, this document requests IANA to assign a sub-registry for 413 Registry ID. The following value is reserved by this specification: 415 1: IPFIX 417 6. Security Considerations 419 Security considerations discussed in [RFC7045] and [RFC7112] apply. 420 Additional considerations are discussed in the following sub- 421 sections. 423 6.1. Privacy 425 Because context headers may reveal privacy information (e.g., IMSI, 426 user name, user profile, location, etc.). SFC Extension Headers MUST 427 NOT be exposed outside the SFC domain. Also, means to protect 428 context headers from eavesdroppers SHOULD be enforced. 430 6.2. Invalid Context Information 432 In order to control the information that can be supplied by a SFC- 433 aware node, and therefore influence the behavior of an SFC-aware node 434 within the SFC-enabled domain, the Originator ID field can be used as 435 a first safeguard to check that the node is entitled to supply such 436 information. If so, the Originator ID field can also be used to 437 check whether the supplied information can be processed as part of 438 the instructions that pertain to a given service function chain. 440 An SFC-aware node can be provided with the appropriate SFC 441 instructions by the SFC control plane or by configuration. 443 6.3. Forwarding Threats 445 This specification is not subject to infinite forwarding loops 446 because a loop can be detected by an SF Index equal to 0. 448 Several attacks (e.g., evade access controls based on destination 449 addresses, amplification attacks) have been identified in [RFC4942]. 450 Such attacks can be prevented in the SFC context by the enforcement 451 of adequate policies at the boundaries of the SFC domain. Typically, 452 SFC border nodes of a SFC-enabled domain can be configured to discard 453 any SFC EH that may be present in a packet that enters the domain, 454 and strip the SFC EH when the packet is forwarded outside of the SFC- 455 enabled domain, so that the information carried by the SFC EH is not 456 leaked outside the domain when the packet exits the SFC-enabled 457 domain. 459 Nevertheless, a node of a SFC-enabled domain may alter the contents 460 of the SFC EH, thereby possibly distorting the SFP. Misbehaving 461 nodes can be detected and countermeasures applied, if adequate 462 monitoring is enforced. Also, means to protect traffic against 463 illegitimate SFs/SFFs that do not belong to the SFC-enabled domain 464 must be enabled. Such means should typically be defined in service 465 function discovery specifications. 467 7. Acknowledgements 469 TBD 471 8. References 473 8.1. Normative References 475 [IPFIX] International Organization for Standardization, "IP Flow 476 Information Export (IPFIX) Entities", 1992, 477 . 479 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 480 Requirement Levels", BCP 14, RFC 2119, 481 DOI 10.17487/RFC2119, March 1997, 482 . 484 [RFC6564] Krishnan, S., Woodyatt, J., Kline, E., Hoagland, J., and 485 M. Bhatia, "A Uniform Format for IPv6 Extension Headers", 486 RFC 6564, DOI 10.17487/RFC6564, April 2012, 487 . 489 [RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing 490 of IPv6 Extension Headers", RFC 7045, 491 DOI 10.17487/RFC7045, December 2013, 492 . 494 8.2. Informative References 496 [RFC4942] Davies, E., Krishnan, S., and P. Savola, "IPv6 Transition/ 497 Co-existence Security Considerations", RFC 4942, 498 DOI 10.17487/RFC4942, September 2007, 499 . 501 [RFC7112] Gont, F., Manral, V., and R. Bonica, "Implications of 502 Oversized IPv6 Header Chains", RFC 7112, 503 DOI 10.17487/RFC7112, January 2014, 504 . 506 [RFC7498] Quinn, P., Ed. and T. Nadeau, Ed., "Problem Statement for 507 Service Function Chaining", RFC 7498, 508 DOI 10.17487/RFC7498, April 2015, 509 . 511 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 512 Chaining (SFC) Architecture", RFC 7665, 513 DOI 10.17487/RFC7665, October 2015, 514 . 516 Authors' Addresses 518 Christian Jacquenet 519 Orange 521 Email: christian.jacquenet@orange.com 523 Mohamed Boucadair 524 Orange 526 Email: mohamed.boucadair@orange.com