idnits 2.17.1 draft-ietf-spring-sr-service-programming-04.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 : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 1369: '...e defined in this document. SHOULD be...' RFC 2119 keyword, line 1370: '...transmission and MUST be ignored on re...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 10, 2021) is 1143 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) -- Looks like a reference, but probably isn't: '0' on line 1252 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-09 == Outdated reference: A later version (-09) exists of draft-xu-mpls-payload-protocol-identifier-08 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SPRING F. Clad, Ed. 3 Internet-Draft Cisco Systems, Inc. 4 Intended status: Standards Track X. Xu, Ed. 5 Expires: September 11, 2021 Alibaba 6 C. Filsfils 7 Cisco Systems, Inc. 8 D. Bernier 9 Bell Canada 10 C. Li 11 Huawei 12 B. Decraene 13 Orange 14 S. Ma 15 Mellanox 16 C. Yadlapalli 17 AT&T 18 W. Henderickx 19 Nokia 20 S. Salsano 21 Universita di Roma "Tor Vergata" 22 March 10, 2021 24 Service Programming with Segment Routing 25 draft-ietf-spring-sr-service-programming-04 27 Abstract 29 This document defines data plane functionality required to implement 30 service segments and achieve service programming in SR-enabled MPLS 31 and IPv6 networks, as described in the Segment Routing architecture. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at https://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on September 11, 2021. 50 Copyright Notice 52 Copyright (c) 2021 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (https://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 3. Classification and Steering . . . . . . . . . . . . . . . . . 4 70 4. Service Segments . . . . . . . . . . . . . . . . . . . . . . 5 71 4.1. SR-Aware Services . . . . . . . . . . . . . . . . . . . . 5 72 4.2. SR-Unaware Services . . . . . . . . . . . . . . . . . . . 6 73 5. SR Service Policies . . . . . . . . . . . . . . . . . . . . . 7 74 5.1. SR-MPLS Data Plane . . . . . . . . . . . . . . . . . . . 8 75 5.2. SRv6 Data Plane . . . . . . . . . . . . . . . . . . . . . 10 76 6. SR Proxy Behaviors . . . . . . . . . . . . . . . . . . . . . 11 77 6.1. Static SR Proxy . . . . . . . . . . . . . . . . . . . . . 14 78 6.1.1. SR-MPLS Pseudocode . . . . . . . . . . . . . . . . . 16 79 6.1.2. SRv6 Pseudocode . . . . . . . . . . . . . . . . . . . 17 80 6.2. Dynamic SR Proxy . . . . . . . . . . . . . . . . . . . . 23 81 6.2.1. SR-MPLS Pseudocode . . . . . . . . . . . . . . . . . 24 82 6.2.2. SRv6 Pseudocode . . . . . . . . . . . . . . . . . . . 24 83 6.3. Shared Memory SR Proxy . . . . . . . . . . . . . . . . . 25 84 6.4. Masquerading SR Proxy . . . . . . . . . . . . . . . . . . 25 85 6.4.1. SRv6 Masquerading Proxy Pseudocode . . . . . . . . . 27 86 6.4.2. Destination NAT Flavor . . . . . . . . . . . . . . . 28 87 6.4.3. Caching Flavor . . . . . . . . . . . . . . . . . . . 28 88 7. Metadata . . . . . . . . . . . . . . . . . . . . . . . . . . 29 89 7.1. MPLS Data Plane . . . . . . . . . . . . . . . . . . . . . 29 90 7.2. IPv6 Data Plane . . . . . . . . . . . . . . . . . . . . . 30 91 7.2.1. SRH TLV Objects . . . . . . . . . . . . . . . . . . . 30 92 7.2.2. SRH Tag . . . . . . . . . . . . . . . . . . . . . . . 31 93 8. Implementation Status . . . . . . . . . . . . . . . . . . . . 31 94 8.1. SR-Aware Services . . . . . . . . . . . . . . . . . . . . 32 95 8.2. Proxy Behaviors . . . . . . . . . . . . . . . . . . . . . 32 96 9. Related Works . . . . . . . . . . . . . . . . . . . . . . . . 32 97 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 98 10.1. SRv6 Endpoint Behaviors . . . . . . . . . . . . . . . . 33 99 10.2. Segment Routing Header TLVs . . . . . . . . . . . . . . 33 100 11. Security Considerations . . . . . . . . . . . . . . . . . . . 33 101 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 34 102 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 34 103 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 35 104 14.1. Normative References . . . . . . . . . . . . . . . . . . 35 105 14.2. Informative References . . . . . . . . . . . . . . . . . 36 106 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37 108 1. Introduction 110 Segment Routing (SR) [RFC8402] is an architecture based on the source 111 routing paradigm that seeks the right balance between distributed 112 intelligence and centralized programmability. SR can be used with an 113 MPLS or an IPv6 data plane to steer packets through an ordered list 114 of instructions, called segments. These segments may encode simple 115 routing instructions for forwarding packets along a specific network 116 path, but also steer them through Virtual Network Functions (VNFs) or 117 physical service appliances available in the network. 119 In an SR network, each of these services, running either on a 120 physical appliance or in a virtual environment, are associated with a 121 segment identifier (SID). These service SIDs are then leveraged as 122 part of a SID-list to steer packets through the corresponding 123 services. Service SIDs may be combined together in a SID-list to 124 achieve service programming, but also with other types of segments as 125 defined in [RFC8402]. SR thus provides a fully integrated solution 126 for overlay, underlay and service programming. Furthermore, the IPv6 127 instantiation of SR (SRv6) [RFC8986] supports metadata transportation 128 in the Segment Routing Header [RFC8754], either natively in the tag 129 field or with extensions such as TLVs. 131 This document describes how a service can be associated with a SID, 132 including legacy services with no SR capabilities, and how these 133 service SIDs are integrated within an SR policy. The definition of 134 an SR Policy and the traffic steering mechanisms are covered in 135 [I-D.ietf-spring-segment-routing-policy] and hence outside the scope 136 of this document. 138 The definition of control plane components, such as service segment 139 discovery, is outside the scope of this data plane document. For 140 reference, the option of using BGP extensions to support SR service 141 programming is proposed in [I-D.dawra-idr-bgp-sr-service-chaining]. 143 2. Terminology 145 This document leverages the terminology proposed in [RFC8402], 146 [RFC8660], [RFC8754], [RFC8986] and 147 [I-D.ietf-spring-segment-routing-policy]. It also introduces the 148 following new terms. 150 Service segment: A segment associated with a service. The service 151 may either run on a physical appliance or in a virtual environment 152 such as a virtual machine or container. 154 SR-aware service: A service that is fully capable of processing SR 155 traffic. An SR-aware service can be directly associated with a 156 service segment. 158 SR-unaware service: A service that is unable to process SR traffic or 159 may behave incorrectly due to presence of SR information in the 160 packet headers. An SR-unaware service can be associated with a 161 service segment through an SR proxy function. 163 3. Classification and Steering 165 Classification and steering mechanisms are defined in section 8 of 166 [I-D.ietf-spring-segment-routing-policy] and are independent from the 167 purpose of the SR policy. From the perspective of a headend node 168 classifying and steering traffic into an SR policy, there is no 169 difference whether this policy contains IGP, BGP, peering, VPN or 170 service segments, or any combination of these. 172 As documented in the above reference, traffic is classified when 173 entering an SR domain. The SR policy headend may, depending on its 174 capabilities, classify the packets on a per-destination basis, via 175 simple FIB entries, or apply more complex policy routing rules 176 requiring to look deeper into the packet. These rules are expected 177 to support basic policy routing such as 5-tuple matching. In 178 addition, the IPv6 SRH tag field defined in [RFC8754] can be used to 179 identify and classify packets sharing the same set of properties. 180 Classified traffic is then steered into the appropriate SR policy and 181 forwarded as per the SID-list(s) of the active candidate path. 183 SR traffic can be re-classified by an SR endpoint along the original 184 SR policy (e.g., DPI service) or a transit node intercepting the 185 traffic. This node is the head-end of a new SR policy that is 186 imposed onto the packet, either as a stack of MPLS labels or as an 187 IPv6 SRH. 189 4. Service Segments 191 In the context of this document, the term service refers to a 192 physical appliance running on dedicated hardware, a virtualized 193 service inside an isolated environment such as a Virtual Machine 194 (VM), container or namespace, or any process running on a compute 195 element. A service may also comprise multiple sub-components running 196 in different processes or containers. Unless otherwise stated, this 197 document does not make any assumption on the type or execution 198 environment of a service. 200 The execution of a service can be integrated as part of an SR policy 201 by assigning a segment identifier, or SID, to the service and 202 including this service SID in the SR policy SID-list. Such a service 203 SID may be of local or global significance. In the former case, 204 other segments, such as prefix or adjacency segments, can be used to 205 steer the traffic up to the node where the service segment is 206 instantiated. In the latter case, the service is directly reachable 207 from anywhere in the routing domain. This is realized with SR-MPLS 208 by assigning a SID from the global label block ([RFC8660]), or with 209 SRv6 by advertising the SID locator in the routing protocol 210 ([RFC8986]). It is up to the network operator to define the scope 211 and reachability of each service SID. This decision can be based on 212 various considerations such as infrastructure dynamicity, available 213 control plane or orchestration system capabilities. 215 This document categorizes services in two types, depending on whether 216 they are able to behave properly in the presence of SR information or 217 not. These are respectively named SR-aware and SR-unaware services. 219 4.1. SR-Aware Services 221 An SR-aware service can process the SR information in the packets it 222 receives. This means being able to identify the active segment as a 223 local instruction and move forward in the segment list, but also that 224 the service's own behavior is not hindered due to the presence of SR 225 information. For example, an SR-aware firewall filtering SRv6 226 traffic based on its final destination must retrieve that information 227 from the last entry in the SRH rather than the Destination Address 228 field of the IPv6 header. 230 An SR-aware service is associated with a locally instantiated service 231 segment, which is used to steer traffic through it. 233 If the service is configured to intercept all the packets passing 234 through the appliance, the underlying routing system only has to 235 implement a default SR endpoint behavior (e.g., SR-MPLS node segment 236 or SRv6 End behavior), and the corresponding SID will be used to 237 steer traffic through the service. 239 If the service requires the packets to be directed to a specific 240 virtual interface, networking queue or process, a dedicated SR 241 behavior may be required to steer the packets to the appropriate 242 location. The definition of such service-specific functions is out 243 of the scope of this document. 245 SR-aware services also enable advanced network programming 246 functionalities such as conditional branching and jumping to 247 arbitrary SIDs in the segment list. In addition, SRv6 provides 248 several ways of passing and exchanging information between services 249 (e.g., SID arguments, tag field and TLVs). An example scenario 250 involving these features is described in [IFIP18], which discusses 251 the implementation of an SR-aware Intrusion Detection System. 253 Examples of SR-aware services are provided in section Section 8.1. 255 4.2. SR-Unaware Services 257 Any service that does not meet the above criteria for SR-awareness is 258 considered as SR-unaware. 260 An SR-unaware service is not able to process the SR information in 261 the traffic that it receives. It may either drop the traffic or take 262 erroneous decisions due to the unrecognized routing information. In 263 order to include such services in an SR policy, it is thus required 264 to remove the SR information as well as any other encapsulation 265 header before the service receives the packet, or to alter it in such 266 a way that the service can correctly process the packet. 268 In this document, we define the concept of an SR proxy as an entity, 269 separate from the service, that performs these modifications and 270 handle the SR processing on behalf of a service. The SR proxy can 271 run as a separate process on the service appliance, on a virtual 272 switch or router on the compute node or on a different host. 274 An SR-unaware service is associated with a service segment 275 instantiated on the SR proxy, which is used to steer traffic through 276 the service. Section 6 describes several SR proxy behaviors to 277 handle the encapsulation headers and SR information under various 278 circumstances. 280 5. SR Service Policies 282 An SR service policy is an SR policy, as defined in 283 [I-D.ietf-spring-segment-routing-policy], that includes at least one 284 service. This service is represented in the SID-list by its 285 associated service SID. In case the policy should include several 286 services, the service traversal order is indicated by the relative 287 position of each service SID in the SID-list. Using the mechanisms 288 described in [I-D.ietf-spring-segment-routing-policy], it is possible 289 to load balance the traffic over several services, or instances of 290 the same service, by associating with the SR service policy a 291 weighted set of SID-lists, each containing a possible sequence of 292 service SIDs to be traversed. Similarly, several candidate paths can 293 be specified for the SR service policy, each with its own set of SID- 294 lists, for resiliency purposes. 296 Furthermore, binding SIDs (BSIDs) [RFC8402] can be leveraged in the 297 context of service policies to reduce the number of SIDs imposed by 298 the headend, provide opacity between domains and improve scalability. 299 For example, a network operator may want a policy in its core domain 300 to include services that are running in one of its datacenters. One 301 option is to define an SR policy at ingress edge of the core domain 302 that explicitly includes all the SIDs needed to steer the traffic 303 through the core and in the DC, but that may result in a long SID- 304 list and requires to update the ingress edge configuration every time 305 the DC part of the policy is modified. Alternatively, a separate 306 policy can be defined at the ingress edge of the datacenter with only 307 the SIDs that needs to be executed there and its BSID included in the 308 core domain policy. That BSID remains stable when the DC policy is 309 modified and can even be shared among several core domain policies 310 that would require the same type of processing in the DC. 312 This section describes how services can be integrated within an SR- 313 MPLS or SRv6 service policy. 315 +------------------------------------------+ 316 | SR network | 317 | | 318 +----+----+ +---------+ +----+-----+ 319 | H +----------+ S +-----------+ E | 320 |(headend)| |(service)| |(endpoint)| 321 +----+----+ +---------+ +----+-----+ 322 | =====================================> | 323 | P1(H,E,C) | 324 +------------------------------------------+ 326 Figure 1: SR service policy 328 Figure 1 illustrates a basic SR service policy instantiated on a 329 headend node H towards an endpoint E and traversing a service S. The 330 SR policy may also include additional requirements, such as traffic 331 engineering or VPN. On the head-end H, the SR policy P1 is created 332 with a color C and endpoint E and associated with an SR path that can 333 either be explicitly configured, dynamically computed on H or 334 provisioned by a network controller. 336 In its most basic form, the SR policy P1 would be resolved into the 337 SID-list < SID(S), SID(E) >. This is assuming that SID(S) and SID(E) 338 are directly reachable from H and S, respectively, and that the 339 forwarding path meets the policy requirement. However, depending on 340 the dataplane and the segments available in the network, additional 341 SIDs may be required to enforce the SR policy. 343 This model applies regardless of the SR-awareness of the service. If 344 it is SR-unaware, then S simply represents the proxy that takes care 345 of transmitting the packet to the actual service. 347 Traffic can then be steered into this policy using any of the 348 mechanisms described in [I-D.ietf-spring-segment-routing-policy]. 350 The following subsections describe the specificities of each SR 351 dataplane. 353 5.1. SR-MPLS Data Plane 354 +-----------------------------------------------+ 355 | SR-MPLS network | 356 | | 357 +----+----+ ------> +---------+ ------> +----+-----+ 358 | H +-------------+ S +-------------+ E | 359 |(headend)| |(service)| |(endpoint)| 360 +----+----+ +---------+ +----+-----+ 361 | (1) (2) (3) (4) | 362 |+---------+ +---------+ +---------+ +---------+| 363 || ... | | L(S) | | ... | | L(E) || 364 |+---------+ +---------+ +---------+ +---------+| 365 || L(S) | | ... | | L(E) | |Inner pkt|| 366 |+---------+ +---------+ +---------+ +---------+| 367 || ... | | L(E) | |Inner pkt| | 368 |+---------+ +---------+ +---------+ | 369 || L(E) | |Inner pkt| | 370 |+---------+ +---------+ | 371 ||Inner pkt| | 372 |+---------+ | 373 +-----------------------------------------------+ 375 Figure 2: Packet walk in an SR-MPLS network 377 In an SR-MPLS network, the SR policy SID-list is encoded as a stack 378 of MPLS labels [RFC8660] and pushed on top of the packet. 380 In the example shown on Figure 2, the SR policy should steer the 381 traffic from the head-end H to the endpoint E via a service S. This 382 translates into an MPLS label stack that includes at least a label 383 L(S) associated to service S and a label L(E) associated to the 384 endpoint E. The label stack may also include additional intermediate 385 SIDs if these are required for traffic engineering (e.g., to encode a 386 low latency path between H and S and / or between S and E) or simply 387 for reachability purposes. Indeed, the service SID L(S) may be taken 388 from the global or local SID block of node S and, in the latter case, 389 one or more SIDs might be needed before L(S) in order for the packet 390 to reach node S (e.g., a prefix-SID of S), where L(S) can be 391 interpreted. The same applies for the SID L(E) at the SR policy 392 endpoint. 394 Special consideration must be taken into account when using Local 395 SIDs for service identification due to increased label stack depth 396 and the associated impacts. 398 When the packet arrives at S, this node determines the MPLS payload 399 type and the appropriate behavior for processing the packet based on 400 the semantic locally associated to the top label L(S). If S is an 401 SR-aware service, the SID L(S) may provide additional context or 402 indication on how to process the packet (e.g., a firewall SID may 403 indicate which rule set should be applied onto the packet). If S is 404 a proxy in front of an SR-unaware service, L(S) indicates how and to 405 which service attached to this proxy the packet should be 406 transmitted. At some point in the process, L(S) is also popped from 407 the label stack in order to expose the next SID, which may be L(E) or 408 another intermediate SID. 410 5.2. SRv6 Data Plane 412 +-----------------------------------------------+ 413 | SRv6 network | 414 | | 415 +----+----+ ------> +---------+ ------> +----+-----+ 416 | H +-------------+ S +-------------+ E | 417 |(headend)| |(service)| |(endpoint)| 418 +----+----+ +---------+ +----+-----+ 419 | (1) (2) (3) (4) | 420 |+---------+ +---------+ +---------+ +---------+| 421 ||IP6(H,..)| |IP6(H, S)| |IP6(H,..)| |IP6(H, E)|| 422 |+---------+ +---------+ +---------+ +---------+| 423 ||SRH(E,..,| |SRH(E,..,| |SRH(E,..,| |SRH(E,..,|| 424 || S,..;| | S,..;| | S,..;| | S,..;|| 425 || SL=i)| | SL=j)| | SL=k)| | SL=0)|| 426 |+---------+ +---------+ +---------+ +---------+| 427 ||Inner pkt| |Inner pkt| |Inner pkt| |Inner pkt|| 428 |+---------+ +---------+ +---------+ +---------+| 429 +-----------------------------------------------+ 431 Figure 3: Packet walk in an SRv6 network 433 In an SRv6 network, the SR Policy is encoded into the packet as an 434 IPv6 header possibly followed by a Segment Routing Header (SRH) 435 [RFC8754]. 437 In the example shown on Figure 3, the SR policy should steer the 438 traffic from the head-end H to the endpoint E via a service S. This 439 translates into Segment-List that includes at least a segment SID(S) 440 to the service, or service proxy, S and a segment SID(E) to the 441 endpoint E. The Segment-List may also include additional 442 intermediate SIDs if these are required for traffic engineering 443 (e.g., the encode a low latency path between H and S and / or between 444 S and E) or simply for reachability purposes. Indeed, the service 445 SID locator may or may not be advertised in the routing protocol and, 446 in the latter case, one or more SIDs might be needed before SID(S) in 447 order to bring the packet up to node S, where SID(S) can be 448 interpreted. The same applies for the segment SID(E) at the SR 449 policy endpoint. 451 When the packet arrives at S, this node determines how to process the 452 packet based on the semantic locally associated to the active segment 453 SID(S). If S is an SR-aware service, then SID(S) may provide 454 additional context or indication on how to process the packet (e.g., 455 a firewall SID may indicate which rule set should be applied onto the 456 packet). If S is a proxy in front of an SR-unaware service, SID(S) 457 indicates how and to which service attached to this proxy the packet 458 should be transmitted. At some point in the process, the SRv6 End 459 function is also applied in order to make the next SID, which may be 460 SID(E) or another intermediate SID, active. 462 The "Inner pkt" on Figure 3 represents the SRv6 payload, which may be 463 an encapsulated IP packet, an Ethernet frame or a transport-layer 464 payload, for example. 466 6. SR Proxy Behaviors 468 This section describes several SR proxy behaviors designed to enable 469 SR service programming through SR-unaware services. A system 470 implementing one of these behaviors may handle the SR processing on 471 behalf of an SR-unaware service and allows the service to properly 472 process the traffic that is steered through it. 474 A service may be located at any hop in an SR policy, including the 475 last segment. However, the SR proxy behaviors defined in this 476 section are dedicated to supporting SR-unaware services at 477 intermediate hops in the segment list. In case an SR-unaware service 478 is at the last segment, it is sufficient to ensure that the SR 479 information is ignored (IPv6 routing extension header with Segments 480 Left equal to 0) or removed before the packet reaches the service 481 (MPLS PHP, SRv6 decapsulation behavior or PSP flavor). 483 As illustrated on Figure 4, the generic behavior of an SR proxy has 484 two parts. The first part is in charge of passing traffic from the 485 network to the service. It intercepts the SR traffic destined for 486 the service via a locally instantiated service segment, modifies it 487 in such a way that it appears as non-SR traffic to the service, then 488 sends it out on a given interface, IFACE-OUT, connected to the 489 service. The second part receives the traffic coming back from the 490 service on IFACE-IN, restores the SR information and forwards it 491 according to the next segment in the list. IFACE-OUT and IFACE-IN 492 are respectively the proxy interface used for sending traffic to the 493 service and the proxy interface that receives the traffic coming back 494 from the service. These can be physical interfaces or sub-interfaces 495 (VLANs) and, unless otherwise stated, IFACE-OUT and IFACE-IN can 496 represent the same interface. 498 +----------------------------+ 499 | | 500 | Service | 501 | | 502 +----------------------------+ 503 ^ Non SR | 504 | traffic | 505 | v 506 +-----------+----------+ 507 +--| IFACE OUT | IFACE IN |--+ 508 SR traffic | +-----------+----------+ | SR traffic 509 ---------->| SR proxy |----------> 510 | | 511 +----------------------------+ 513 Figure 4: Generic SR proxy 515 In the next subsections, the following SR proxy mechanisms are 516 defined: 518 o Static proxy 520 o Dynamic proxy 522 o Shared-memory proxy 524 o Masquerading proxy 526 Each mechanism has its own characteristics and constraints, which are 527 summarized in the below table. It is up to the operator to select 528 the best one based on the proxy node capabilities, the service 529 behavior and the traffic type. It is also possible to use different 530 proxy mechanisms within the same service policy. 532 +-----+-----+-----+-----+ 533 | | | | M | 534 | | | S | a | 535 | | | h | s | 536 | | | a | q | 537 | | | r | u | 538 | | D | e | e | 539 | S | y | d | r | 540 | t | n | | a | 541 | a | a | m | d | 542 | t | m | e | i | 543 | i | i | m | n | 544 | c | c | . | g | 545 +---------------------------------------+-----+-----+-----+-----+ 546 | | SR-MPLS | Y | Y | Y | - | 547 | | | | | | | 548 | SR flavors | Inline SRv6 | P | P | P | Y | 549 | | | | | | | 550 | | SRv6 encapsulation | Y | Y | Y | - | 551 +----------------+----------------------+-----+-----+-----+-----+ 552 | Chain agnostic configuration | N | N | Y | Y | 553 +---------------------------------------+-----+-----+-----+-----+ 554 | Transparent to chain changes | N | Y | Y | Y | 555 +----------------+----------------------+-----+-----+-----+-----+ 556 | | DA modification | Y | Y | Y | NAT | 557 | | | | | | | 558 | | Payload modification | Y | Y | Y | Y | 559 | | | | | | | 560 |Service support | Packet generation | Y | Y |cache|cache| 561 | | | | | | | 562 | | Packet deletion | Y | Y | Y | Y | 563 | | | | | | | 564 | | Packet re-ordering | Y | Y | Y | Y | 565 | | | | | | | 566 | | Transport endpoint | Y | Y |cache|cache| 567 +----------------+----------------------+-----+-----+-----+-----+ 568 | | Ethernet | Y | Y | Y | - | 569 | Supported | | | | | | 570 | traffic | IPv4 | Y | Y | Y | - | 571 | | | | | | | 572 | | IPv6 | Y | Y | Y | Y | 573 +----------------+----------------------+-----+-----+-----+-----+ 575 Figure 5: SR proxy summary 577 Note: The use of a shared memory proxy requires both the service 578 (VNF) and the proxy to be running on the same node. 580 6.1. Static SR Proxy 582 The static proxy is an SR endpoint behavior for processing SR-MPLS or 583 SRv6 encapsulated traffic on behalf of an SR-unaware service. This 584 proxy thus receives SR traffic that is formed of an MPLS label stack 585 or an IPv6 header on top of an inner packet, which can be Ethernet, 586 IPv4 or IPv6. 588 A static SR proxy segment is associated with the following mandatory 589 parameters 591 o INNER-TYPE: Inner packet type 593 o NH-ADDR: Next hop Ethernet address (only for inner type IPv4 and 594 IPv6) 596 o IFACE-OUT: Local interface for sending traffic towards the service 598 o IFACE-IN: Local interface receiving the traffic coming back from 599 the service 601 o CACHE: SR information to be attached on the traffic coming back 602 from the service, including at least 604 * CACHE.SA: IPv6 source address (SRv6 only) 606 * CACHE.LIST: Segment list expressed as MPLS labels or IPv6 607 address 609 A static SR proxy segment is thus defined for a specific service, 610 inner packet type and cached SR information. It is also bound to a 611 pair of directed interfaces on the proxy. These may be both 612 directions of a single interface, or opposite directions of two 613 different interfaces. The latter is recommended in case the service 614 is to be used as part of a bi-directional SR service policy. If the 615 proxy and the service both support 802.1Q, IFACE-OUT and IFACE-IN can 616 also represent sub-interfaces. 618 The first part of this behavior is triggered when the proxy node 619 receives a packet whose active segment matches a segment associated 620 with the static proxy behavior. It removes the SR information from 621 the packet then sends it on a specific interface towards the 622 associated service. This SR information corresponds to the full 623 label stack for SR-MPLS or to the encapsulation IPv6 header with any 624 attached extension header in the case of SRv6. 626 The second part is an inbound policy attached to the proxy interface 627 receiving the traffic returning from the service, IFACE-IN. This 628 policy attaches to the incoming traffic the cached SR information 629 associated with the SR proxy segment. If the proxy segment uses the 630 SR-MPLS data plane, CACHE contains a stack of labels to be pushed on 631 top of the packets. With the SRv6 data plane, CACHE is defined as a 632 source address, an active segment and an optional SRH (tag, segments 633 left, segment list and metadata). The proxy encapsulates the packets 634 with an IPv6 header that has the source address, the active segment 635 as destination address and the SRH as a routing extension header. 636 After the SR information has been attached, the packets are forwarded 637 according to the active segment, which is represented by the top MPLS 638 label or the IPv6 Destination Address. An MPLS TTL or IPv6 Hop Limit 639 value may also be configured in CACHE. If it is not, the proxy 640 should set these values according to the node's default setting for 641 MPLS or IPv6 encapsulation. 643 In this scenario, there are no restrictions on the operations that 644 can be performed by the service on the stream of packets. It may 645 operate at all protocol layers, terminate transport layer 646 connections, generate new packets and initiate transport layer 647 connections. This behavior may also be used to integrate an 648 IPv4-only service into an SRv6 policy. However, a static SR proxy 649 segment can be used in only one service policy at a time. As opposed 650 to most other segment types, a static SR proxy segment is bound to a 651 unique list of segments, which represents a directed SR service 652 policy. This is due to the cached SR information being defined in 653 the segment configuration. This limitation only prevents multiple 654 segment lists from using the same static SR proxy segment at the same 655 time, but a single segment list can be shared by any number of 656 traffic flows. Besides, since the returning traffic from the service 657 is re-classified based on the incoming interface, an interface can be 658 used as receiving interface (IFACE-IN) only for a single SR proxy 659 segment at a time. In the case of a bi-directional SR service 660 policy, a different SR proxy segment and receiving interface are 661 required for the return direction. 663 The static proxy behavior may also be used for sending traffic 664 through "bump in the wire" services that are transparent to the IP 665 and Ethernet layers. This type of processing is assumed when the 666 inner traffic type is Ethernet, since the original destination 667 address of the Ethernet frame is preserved when the packet is steered 668 into the SR Policy and likely associated with a node downstream of 669 the policy tail-end. In case the inner type is IP (IPv4 or IPv6), 670 the NH-ADDR parameter may be set to a dummy or broadcast Ethernet 671 address, or simply to the address of the proxy receiving interface 672 (IFACE-IN). 674 6.1.1. SR-MPLS Pseudocode 676 6.1.1.1. Static Proxy for Inner Type Ethernet 678 When processing an MPLS packet whose top label matches a locally 679 instantiated MPLS static proxy SID for Ethernet traffic, the 680 following pseudocode is executed. 682 S01. POP all labels in the MPLS label stack. 683 S02. Submit the frame to the Ethernet module for transmission via 684 interface IFACE-OUT. 686 Figure 6: SID processing for MPLS static proxy (Ethernet) 688 When processing an Ethernet frame received on the interface IFACE-IN 689 and with a destination MAC address that is neither a broadcast 690 address nor matches the address of IFACE-IN, the following pseudocode 691 is executed. 693 S01. Retrieve the CACHE entry associated with IFACE-IN. 694 S02. If the CACHE entry is not empty { 695 S03. Remove the preamble or Frame Check Sequence (FCS). 696 S04. PUSH all labels from the retrieved CACHE entry. 697 S05. Submit the packet to the MPLS module for transmission as per 698 the top label in the MPLS label stack. 699 S06. } 701 Figure 7: Inbound policy for MPLS static proxy (Ethernet) 703 6.1.1.2. Static Proxy for Inner Type IPv4 705 When processing an MPLS packet whose top label matches a locally 706 instantiated MPLS static proxy SID for IPv4 traffic, the following 707 pseudocode is executed. 709 S01. POP all labels in the MPLS label stack. 710 S02. Submit the packet to the IPv4 module for transmission on 711 interface IFACE-OUT via NH-ADDR. 713 Figure 8: SID processing for MPLS static proxy (IPv4) 715 When processing an IPv4 packet received on the interface IFACE-IN and 716 with a destination address that does not match any address of IFACE- 717 IN, the following pseudocode is executed. 719 S01. Retrieve the CACHE entry associated with IFACE-IN. 720 S02. If the CACHE entry is not empty { 721 S03. Decrement the TTL and adjust the checksum accordingly. 722 S04. PUSH all labels from the retrieved CACHE entry. 723 S05. Submit the packet to the MPLS module for transmission as per 724 the top label in the MPLS label stack. 725 S06. } 727 Figure 9: Inbound policy for MPLS static proxy (IPv4) 729 6.1.1.3. Static Proxy for Inner Type IPv6 731 When processing an MPLS packet whose top label matches a locally 732 instantiated MPLS static proxy SID for IPv6 traffic, the following 733 pseudocode is executed. 735 S01. POP all labels in the MPLS label stack. 736 S02. Submit the packet to the IPv6 module for transmission on 737 interface IFACE-OUT via NH-ADDR. 739 Figure 10: SID processing for MPLS static proxy (IPv6) 741 When processing an IPv6 packet received on the interface IFACE-IN and 742 with a destination address that does not match any address of IFACE- 743 IN, the following pseudocode is executed. 745 S01. Retrieve the CACHE entry associated with IFACE-IN. 746 S02. If the CACHE entry is not empty { 747 S03. Decrement the Hop Limit. 748 S04. PUSH all labels from the retrieved CACHE entry. 749 S05. Submit the packet to the MPLS module for transmission as per 750 the top label in the MPLS label stack. 751 S06. } 753 Figure 11: Inbound policy for MPLS static proxy (IPv6) 755 6.1.2. SRv6 Pseudocode 757 6.1.2.1. Static Proxy for Inner Type Ethernet 759 When processing an IPv6 packet matching a FIB entry locally 760 instantiated as an SRv6 static proxy SID for Ethernet traffic, the 761 following pseudocode is executed. 763 S01. When an SRH is processed { 764 S02. If (Segments Left == 0) { 765 S03. Proceed to process the next header in the packet. 766 S04. } 767 S05. If (IPv6 Hop Limit <= 1) { 768 S06. Send an ICMP Time Exceeded message to the Source Address, 769 Code 0 (hop limit exceeded in transit), 770 Interrupt packet processing and discard the packet. 771 S07. } 772 S08. max_last_entry = (Hdr Ext Len / 2) - 1 773 S09. If ((Last Entry > max_last_entry) or 774 (Segments Left > (Last Entry + 1))) { 775 S10. Send an ICMP Parameter Problem message to the Source Address, 776 Code 0 (Erroneous header field encountered), 777 Pointer set to the Segments Left field, 778 Interrupt packet processing and discard the packet. 779 S11. } 780 S12. Decrement Hop Limit by 1. 781 S13. Decrement Segments Left by 1. 782 S14. Copy Segment List[Segments Left] from the SRH to the 783 Destination Address of the IPv6 header. 784 S15. If (Upper-layer header type != 143 (Ethernet)) { 785 S16. Resubmit the packet to the IPv6 module for transmission to 786 the new destination. 787 S17. } 788 S18. Perform IPv6 decapsulation. 789 S19. Submit the frame to the Ethernet module for transmission via 790 interface IFACE-OUT. 791 S20. } 793 Figure 12: SID processing for SRv6 static proxy (Ethernet) 795 S15: 143 (Ethernet) refers to the value assigned by IANA for 796 "Ethernet" in the "Internet Protocol Numbers" registry. 798 When processing the Upper-layer header of a packet matching a FIB 799 entry locally instantiated as an SRv6 static proxy SID for Ethernet 800 traffic, the following pseudocode is executed. 802 S01. If (Upper-layer header type != 143 (Ethernet)) { 803 S02. Process as per [RFC8986] Section 4.1.1 804 S03. } 805 S04. Perform IPv6 decapsulation. 806 S05. Submit the frame to the Ethernet module for transmission via 807 interface IFACE-OUT. 809 Figure 13: Upper-layer header processing for SRv6 static proxy 810 (Ethernet) 812 When processing an Ethernet frame received on the interface IFACE-IN 813 and with a destination MAC address that is neither a broadcast 814 address nor matches the address of IFACE-IN, the following pseudocode 815 is executed. 817 S01. Retrieve the CACHE entry associated with IFACE-IN. 818 S02. If the CACHE entry is not empty { 819 S03. Remove the preamble or Frame Check Sequence (FCS). 820 S04. Perform IPv6 encapsulation with an SRH 821 Source Address of the IPv6 header is set to CACHE.SA, 822 Destination Address of the IPv6 header is set to 823 CACHE.LIST[0], 824 Next Header of the SRH is set to 143 (Ethernet), 825 Segment List of the SRH is set to CACHE.LIST. 826 S05. Submit the packet to the IPv6 module for transmission to the 827 next destination. 828 S06. } 830 Figure 14: Inbound policy for SRv6 static proxy (Ethernet) 832 S04: CACHE.LIST[0] represents the first entry in CACHE.LIST. Unless 833 a local configuration indicates otherwise, the SIDs in CACHE.LIST 834 should be encoded in the Segment List field in reversed order, the 835 Segment Left and Last Entry values should be set of the length of 836 CACHE.LIST minus 1. If CACHE.LIST contains a single entry, the SRH 837 can be omitted and the Next Header field of the IPv6 header set to 838 143 (Ethernet). 840 6.1.2.2. Static Proxy for Inner Type IPv4 842 When processing an IPv6 packet matching a FIB entry locally 843 instantiated as an SRv6 static proxy SID for IPv4 traffic, the 844 following pseudocode is executed. 846 S01. When an SRH is processed { 847 S02. If (Segments Left == 0) { 848 S03. Proceed to process the next header in the packet. 849 S04. } 850 S05. If (IPv6 Hop Limit <= 1) { 851 S06. Send an ICMP Time Exceeded message to the Source Address, 852 Code 0 (hop limit exceeded in transit), 853 Interrupt packet processing and discard the packet. 854 S07. } 855 S08. max_last_entry = (Hdr Ext Len / 2) - 1 856 S09. If ((Last Entry > max_last_entry) or 857 (Segments Left > (Last Entry + 1))) { 858 S10. Send an ICMP Parameter Problem message to the Source Address, 859 Code 0 (Erroneous header field encountered), 860 Pointer set to the Segments Left field, 861 Interrupt packet processing and discard the packet. 862 S11. } 863 S12. Decrement Hop Limit by 1. 864 S13. Decrement Segments Left by 1. 865 S14. Copy Segment List[Segments Left] from the SRH to the 866 Destination Address of the IPv6 header. 867 S15. If (Upper-layer header type != 4 (IPv4)) { 868 S16. Resubmit the packet to the IPv6 module for transmission to 869 the new destination. 870 S17. } 871 S18. Perform IPv6 decapsulation. 872 S19. Submit the packet to the IPv4 module for transmission on 873 interface IFACE-OUT via NH-ADDR. 874 S20. } 876 Figure 15: SID processing for SRv6 static proxy (IPv4) 878 When processing the Upper-layer header of a packet matching a FIB 879 entry locally instantiated as an SRv6 static proxy SID for IPv4 880 traffic, the following pseudocode is executed. 882 S01. If (Upper-layer header type != 4 (IPv4)) { 883 S02. Process as per [RFC8986] Section 4.1.1 884 S03. } 885 S04. Perform IPv6 decapsulation. 886 S05. Submit the packet to the IPv4 module for transmission on 887 interface IFACE-OUT via NH-ADDR. 889 Figure 16: Upper-layer header processing for SRv6 static proxy (IPv4) 891 When processing an IPv4 packet received on the interface IFACE-IN and 892 with a destination address that does not match any address of IFACE- 893 IN, the following pseudocode is executed. 895 S01. Retrieve the CACHE entry associated with IFACE-IN. 896 S02. If the CACHE entry is not empty { 897 S03. Decrement the TTL and adjust the checksum accordingly. 898 S04. Perform IPv6 encapsulation with an SRH 899 Source Address of the IPv6 header is set to CACHE.SA, 900 Destination Address of the IPv6 header is set to 901 CACHE.LIST[0], 902 Next Header of the SRH is set to 4 (IPv4), 903 Segment List of the SRH is set to CACHE.LIST. 904 S05. Submit the packet to the IPv6 module for transmission to the 905 next destination. 906 S06. } 908 Figure 17: Inbound policy for SRv6 static proxy (IPv4) 910 S04: CACHE.LIST[0] represents the first entry in CACHE.LIST. Unless 911 a local configuration indicates otherwise, the SIDs in CACHE.LIST 912 should be encoded in the Segment List field in reversed order, the 913 Segment Left and Last Entry values should be set of the length of 914 CACHE.LIST minus 1. If CACHE.LIST contains a single entry, the SRH 915 can be omitted and the Next Header field of the IPv6 header set to 4 916 (IPv4). 918 6.1.2.3. Static Proxy for Inner Type IPv6 920 When processing an IPv6 packet matching a FIB entry locally 921 instantiated as an SRv6 static proxy SID for IPv6 traffic, the 922 following pseudocode is executed. 924 S01. When an SRH is processed { 925 S02. If (Segments Left == 0) { 926 S03. Proceed to process the next header in the packet. 927 S04. } 928 S05. If (IPv6 Hop Limit <= 1) { 929 S06. Send an ICMP Time Exceeded message to the Source Address, 930 Code 0 (hop limit exceeded in transit), 931 Interrupt packet processing and discard the packet. 932 S07. } 933 S08. max_last_entry = (Hdr Ext Len / 2) - 1 934 S09. If ((Last Entry > max_last_entry) or 935 (Segments Left > (Last Entry + 1))) { 936 S10. Send an ICMP Parameter Problem message to the Source Address, 937 Code 0 (Erroneous header field encountered), 938 Pointer set to the Segments Left field, 939 Interrupt packet processing and discard the packet. 940 S11. } 941 S12. Decrement Hop Limit by 1. 942 S13. Decrement Segments Left by 1. 943 S14. Copy Segment List[Segments Left] from the SRH to the 944 Destination Address of the IPv6 header. 945 S15. If (Upper-layer header type != 41 (IPv6)) { 946 S16. Resubmit the packet to the IPv6 module for transmission to 947 the new destination. 948 S17. } 949 S18. Perform IPv6 decapsulation. 950 S19. Submit the packet to the IPv6 module for transmission on 951 interface IFACE-OUT via NH-ADDR. 952 S20. } 954 Figure 18: SID processing for SRv6 static proxy (IPv6) 956 When processing the Upper-layer header of a packet matching a FIB 957 entry locally instantiated as an SRv6 static proxy SID for IPv6 958 traffic, the following pseudocode is executed. 960 S01. If (Upper-layer header type != 41 (IPv6)) { 961 S02. Process as per [RFC8986] Section 4.1.1 962 S03. } 963 S04. Perform IPv6 decapsulation. 964 S05. Submit the packet to the IPv6 module for transmission on 965 interface IFACE-OUT via NH-ADDR. 967 Figure 19: Upper-layer header processing for SRv6 static proxy (IPv6) 969 When processing an IPv6 packet received on the interface IFACE-IN and 970 with a destination address that does not match any address of IFACE- 971 IN, the following pseudocode is executed. 973 S01. Retrieve the CACHE entry associated with IFACE-IN. 974 S02. If the CACHE entry is not empty { 975 S03. Decrement the Hop Limit. 976 S04. Perform IPv6 encapsulation with an SRH 977 Source Address of the IPv6 header is set to CACHE.SA, 978 Destination Address of the IPv6 header is set to 979 CACHE.LIST[0], 980 Next Header of the SRH is set to 41 (IPv6), 981 Segment List of the SRH is set to CACHE.LIST. 982 S05. Submit the packet to the IPv6 module for transmission to the 983 next destination. 984 S06. } 986 Figure 20: Inbound policy for SRv6 static proxy (IPv6) 988 S04: CACHE.LIST[0] represents the first entry in CACHE.LIST. Unless 989 a local configuration indicates otherwise, the SIDs in CACHE.LIST 990 should be encoded in the Segment List field in reversed order, the 991 Segment Left and Last Entry values should be set of the length of 992 CACHE.LIST minus 1. If CACHE.LIST contains a single entry, the SRH 993 can be omitted and the Next Header field of the (outer) IPv6 header 994 set to 41 (IPv6). 996 6.2. Dynamic SR Proxy 998 The dynamic proxy is an improvement over the static proxy that 999 dynamically learns the SR information before removing it from the 1000 incoming traffic. The same information can then be re-attached to 1001 the traffic returning from the service. As opposed to the static SR 1002 proxy, no CACHE information needs to be configured. Instead, the 1003 dynamic SR proxy relies on a local caching mechanism on the node 1004 instantiating this segment. 1006 Upon receiving a packet whose active segment matches a dynamic SR 1007 proxy function, the proxy node pops the top MPLS label or applies the 1008 SRv6 End behavior, then compares the updated SR information with the 1009 cache entry for the current segment. If the cache is empty or 1010 different, it is updated with the new SR information. The SR 1011 information is then removed and the inner packet is sent towards the 1012 service. 1014 The cache entry is not mapped to any particular packet, but instead 1015 to an SR service policy identified by the receiving interface (IFACE- 1016 IN). Any non-link-local IP packet or non-local Ethernet frame 1017 received on that interface will be re-encapsulated with the cached 1018 headers as described in Section 6.1. The service may thus drop, 1019 modify or generate new packets without affecting the proxy. 1021 6.2.1. SR-MPLS Pseudocode 1023 The dynamic proxy SR-MPLS pseudocode is obtained by inserting the 1024 following instructions at the beginning of the static SR-MPLS 1025 pseudocode (Section 6.1.1). 1027 S01. If the top label S bit is different from 0 { 1028 S02. Discard the packet. 1029 S03. } 1030 S04. POP the top label. 1031 S05. Copy the MPLS label stack in a CACHE entry associated with the 1032 interface IFACE-IN. 1034 Figure 21: SID processing for MPLS dynamic proxy 1036 S01: As mentioned at the beginning of Section 6, an SR proxy is not 1037 needed to include an SR-unaware service at the end of an SR policy. 1039 S05: An implementation may optimize the caching procedure by copying 1040 information into the cache only if it is different from the current 1041 content of the cache entry. Furthermore, a TTL margin can be 1042 configured for the top label stack entry to prevent constant cache 1043 updates when multiple equal-cost paths with different hop counts are 1044 used towards the SR proxy node. In that case, a TTL difference 1045 smaller than the configured margin should not trigger a cache update 1046 (provided that the labels are the same). 1048 When processing an Ethernet frame, an IPv4 packet or an IPv6 packet 1049 received on the interface IFACE-IN and with a destination address 1050 that does not match any address of IFACE-IN, the pseudocode reported 1051 in Figure 7, Figure 9 or Figure 11, respectively, is executed. 1053 6.2.2. SRv6 Pseudocode 1055 When processing an IPv6 packet matching a FIB entry locally 1056 instantiated as an SRv6 dynamic proxy SID, the same pseudocode as 1057 described in Figure 12, Figure 15 and Figure 18, respectively for 1058 Ethernet, IPv4 and IPv6 traffic, is executed with the following 1059 addition between lines S17 and S18. 1061 (... S17. }) 1062 S17.1. Copy the IPv6 encapsulation in a CACHE entry associated with 1063 the interface IFACE-IN. 1064 (S18. Perform IPv6 decapsulation...) 1066 Figure 22: SID processing for SRv6 dynamic proxy 1068 An implementation may optimize the caching procedure by copying 1069 information into the cache only if it is different from the current 1070 content of the cache entry. A Hop Limit margin can be configured to 1071 prevent constant cache updates when multiple equal-cost paths with 1072 different hop counts are used towards the SR proxy node. In that 1073 case, a Hop Limit difference smaller than the configured margin 1074 should not trigger a cache update. Similarly, the Flow Label value 1075 can be ignored when comparing the current packet IPv6 header with the 1076 cache entry. In this case, the Flow Label should be re-computed by 1077 the proxy node when it restores the IPv6 encapsulation from the cache 1078 entry. 1080 When processing the Upper-layer header of a packet matching a FIB 1081 entry locally instantiated as an SRv6 dynamic proxy SID, process the 1082 packet as per [RFC8986] Section 4.1.1. 1084 When processing an Ethernet frame, an IPv4 packet or an IPv6 packet 1085 received on the interface IFACE-IN and with a destination address 1086 that does not match any address of IFACE-IN, the same pseudocode as 1087 in Figure 14, Figure 17 or Figure 20, respectively, is executed. 1089 6.3. Shared Memory SR Proxy 1091 The shared memory proxy is an SR endpoint behavior for processing SR- 1092 MPLS or SRv6 encapsulated traffic on behalf of an SR-unaware service. 1093 This proxy behavior leverages a shared-memory interface with a 1094 virtualized service (VNF) in order to hide the SR information from an 1095 SR-unaware service while keeping it attached to the packet. We 1096 assume in this case that the proxy and the VNF are running on the 1097 same compute node. A typical scenario is an SR-capable vrouter 1098 running on a container host and forwarding traffic to VNFs isolated 1099 within their respective container. 1101 6.4. Masquerading SR Proxy 1103 The masquerading proxy is an SR endpoint behavior for processing SRv6 1104 traffic on behalf of an SR-unaware service. This proxy thus receives 1105 SR traffic that is formed of an IPv6 header and an SRH on top of an 1106 inner payload. The masquerading behavior is independent from the 1107 inner payload type. Hence, the inner payload can be of any type but 1108 it is usually expected to be a transport layer packet, such as TCP or 1109 UDP. 1111 A masquerading SR proxy segment is associated with the following 1112 mandatory parameters: 1114 o NH-ADDR: Next hop Ethernet address 1115 o IFACE-OUT: Local interface for sending traffic towards the service 1117 o IFACE-IN: Local interface receiving the traffic coming back from 1118 the service 1120 A masquerading SR proxy segment is thus defined for a specific 1121 service and bound to a pair of directed interfaces or sub-interfaces 1122 on the proxy. As opposed to the static and dynamic SR proxies, a 1123 masquerading segment can be present at the same time in any number of 1124 SR service policies and the same interfaces can be bound to multiple 1125 masquerading proxy segments. The only restriction is that a 1126 masquerading proxy segment cannot be the last segment in an SR 1127 service policy. 1129 The first part of the masquerading behavior is triggered when the 1130 proxy node receives an IPv6 packet whose Destination Address matches 1131 a masquerading proxy SID. The proxy inspects the IPv6 extension 1132 headers and substitutes the Destination Address with the last SID in 1133 the SRH attached to the IPv6 header, which represents the final 1134 destination of the IPv6 packet. The packet is then sent out towards 1135 the service. 1137 The service receives an IPv6 packet whose source and destination 1138 addresses are respectively the original source and final destination. 1139 It does not attempt to inspect the SRH, as RFC8200 specifies that 1140 routing extension headers are not examined or processed by transit 1141 nodes. Instead, the service simply forwards the packet based on its 1142 current Destination Address. In this scenario, we assume that the 1143 service can only inspect, drop or perform limited changes to the 1144 packets. For example, Intrusion Detection Systems, Deep Packet 1145 Inspectors and non-NAT Firewalls are among the services that can be 1146 supported by a masquerading SR proxy. Flavors of the masquerading 1147 behavior are defined in Section 6.4.2 and Section 6.4.3 to support a 1148 wider range of services. 1150 The second part of the masquerading behavior, also called de- 1151 masquerading, is an inbound policy attached to the proxy interface 1152 receiving the traffic returning from the service, IFACE-IN. This 1153 policy inspects the incoming traffic and triggers a regular SRv6 1154 endpoint processing (End) on any IPv6 packet that contains an SRH. 1155 This processing occurs before any lookup on the packet Destination 1156 Address is performed and it is sufficient to restore the right active 1157 SID as the Destination Address of the IPv6 packet. 1159 6.4.1. SRv6 Masquerading Proxy Pseudocode 1161 Masquerading: When processing an IPv6 packet matching a FIB entry 1162 locally instantiated as an SRv6 masquerading proxy SID, the following 1163 pseudocode is executed. 1165 S01. When an SRH is processed { 1166 S02. If (Segments Left == 0) { 1167 S03. Proceed to process the next header in the packet. 1168 S04. } 1169 S05. If (IPv6 Hop Limit <= 1) { 1170 S06. Send an ICMP Time Exceeded message to the Source Address, 1171 Code 0 (hop limit exceeded in transit), 1172 Interrupt packet processing and discard the packet. 1173 S07. } 1174 S08. max_last_entry = (Hdr Ext Len / 2) - 1 1175 S09. If ((Last Entry > max_last_entry) or 1176 (Segments Left > (Last Entry + 1))) { 1177 S10. Send an ICMP Parameter Problem message to the Source Address, 1178 Code 0 (Erroneous header field encountered), 1179 Pointer set to the Segments Left field, 1180 Interrupt packet processing and discard the packet. 1181 S11. } 1182 S12. Decrement Hop Limit by 1. 1183 S13. Decrement Segments Left by 1. 1184 S14. Copy Segment List[0] from the SRH to the Destination Address 1185 of the IPv6 header. 1186 S15. Submit the packet to the IPv6 module for transmission on 1187 interface IFACE-OUT via NH-ADDR. 1188 S16. } 1190 Figure 23: SID processing for SRv6 masquerading proxy 1192 When processing the Upper-layer header of a packet matching a FIB 1193 entry locally instantiated as an SRv6 masquerading proxy SID, process 1194 the packet as per [RFC8986] Section 4.1.1. 1196 De-masquerading: When processing an IPv6 packet received on the 1197 interface IFACE-IN and with a destination address that does not match 1198 any address of IFACE-IN, the following pseudocode is executed. 1200 S01. When an SRH is processed { 1201 S02. If (IPv6 Hop Limit <= 1) { 1202 S03. Send an ICMP Time Exceeded message to the Source Address, 1203 Code 0 (hop limit exceeded in transit), 1204 Interrupt packet processing and discard the packet. 1205 S04. } 1206 S05. If (Segments Left != 0) { 1207 S06. max_last_entry = (Hdr Ext Len / 2) - 1 1208 S07. If ((Last Entry > max_last_entry) or 1209 (Segments Left > Last Entry)) { 1210 S08. Send an ICMP Parameter Problem message to the Source Address, 1211 Code 0 (Erroneous header field encountered), 1212 Pointer set to the Segments Left field, 1213 Interrupt packet processing and discard the packet. 1214 S09. } 1215 S10. Copy Segment List[Segments Left] from the SRH to the 1216 Destination Address of the IPv6 header. 1217 S11. } 1218 S12. Decrement Hop Limit by 1. 1219 S13. Submit the packet to the IPv6 module for transmission to the 1220 next destination. 1221 S14. } 1223 Figure 24: Inbound policy for SRv6 masquerading proxy 1225 6.4.2. Destination NAT Flavor 1227 Services modifying the destination address in the packets they 1228 process, such as NATs, can be supported by reporting the updated 1229 Destination Address back into the Segment List field of the SRH. 1231 The Destination NAT flavor of the SRv6 masquerading proxy is enabled 1232 by adding the following instruction between lines S09 and S10 of the 1233 de-masquerading pseudocode in Figure 24. 1235 (... S09. }) 1236 S09.1. Copy the Destination Address of the IPv6 header to the 1237 Segment List[0] entry of the SRH. 1238 (S10. Copy Segment List[Segments Left] from the SRH to the 1239 Destination Address of the IPv6 header...) 1241 6.4.3. Caching Flavor 1243 Services generating packets or acting as endpoints for transport 1244 connections can be supported by adding a dynamic caching mechanism 1245 similar to the one described in Section 6.2. 1247 The caching flavor of the SRv6 masquerading proxy is enabled by: 1249 o Adding the following instruction between lines S14 and S15 of the 1250 masquerading pseudocode in Figure 23. 1252 (... S14. Copy Segment List[0] from the SRH to the Destination 1253 Address of the IPv6 header. 1254 S14.1. Copy the IPv6 encapsulation in a CACHE entry associated with 1255 the interface IFACE-IN. 1256 (S15. Submit the packet to the IPv6 module for transmission on 1257 interface IFACE-OUT via NH-ADDR.) 1259 o Updating the de-masquerading pseudocode such that, in addition to 1260 the SRH processing in Figure 24, the following pseudocode is 1261 executed when processing an IPv6 packet (received on the interface 1262 IFACE-IN and with a destination address that does not match any 1263 address of IFACE-IN) that does not contain an SRH. 1265 S01. Retrieve the CACHE entry associated with IFACE-IN. 1266 S02. If the CACHE entry is not empty { 1267 S03. If (IPv6 Hop Limit <= 1) { 1268 S04. Send an ICMP Time Exceeded message to the Source Address, 1269 Code 0 (hop limit exceeded in transit), 1270 Interrupt packet processing and discard the packet. 1271 S05. } 1272 S06. Decrement Hop Limit by 1. 1273 S07. Update the IPv6 encapsulation according to the retrieved CACHE 1274 entry. 1275 S08. Submit the packet to the IPv6 module for transmission to the 1276 next destination. 1277 S09. } 1279 7. Metadata 1281 7.1. MPLS Data Plane 1283 Metadata can be carried for SR-MPLS traffic in a Segment Routing 1284 Header inserted between the last MPLS label and the MPLS payload. 1285 When used solely as a metadata container, the SRH does not carry any 1286 segment but only the mandatory header fields, including the tag and 1287 flags, and any TLVs that is required for transporting the metadata. 1289 Since the MPLS encapsulation has no explicit protocol identifier 1290 field to indicate the protocol type of the MPLS payload, how to 1291 indicate the presence of metadata in an MPLS packet is a potential 1292 issue to be addressed. One possible solution is to add the 1293 indication about the presence of metadata in the semantic of the 1294 SIDs. Note that only the SIDs whose behavior involves looking at the 1295 metadata or the MPLS payload would need to include such semantic 1296 (e.g., service segments). Other segments, such as topological 1297 segments, are not affected by the presence of metadata. Another, 1298 more generic, solution is to introduce a protocol identifier field 1299 within the MPLS packet as described in 1300 [I-D.xu-mpls-payload-protocol-identifier]. 1302 7.2. IPv6 Data Plane 1304 7.2.1. SRH TLV Objects 1306 The IPv6 SRH TLV objects are designed to carry all sorts of metadata. 1307 TLV objects can be imposed by the ingress edge router that steers the 1308 traffic into the SR service policy. 1310 An SR-aware service may impose, modify or remove any TLV object 1311 attached to the first SRH, either by directly modifying the packet 1312 headers or via a control channel between the service and its 1313 forwarding plane. 1315 An SR-aware service that re-classifies the traffic and steers it into 1316 a new SR service policy (e.g. DPI) may attach any TLV object to the 1317 new SRH. 1319 Metadata imposition and handling will be further discussed in a 1320 future version of this document. 1322 7.2.1.1. Opaque Metadata TLV 1324 This document defines an SRv6 TLV called Opaque Metadata TLV. This 1325 is a fixed-length container to carry any type of Service Metadata. 1326 No assumption is made by this document on the structure or the 1327 content of the carried metadata. The Opaque Metadata TLV has the 1328 following format: 1330 0 1 2 3 1331 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 1332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1333 | Type | Length | | 1334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1335 | | 1336 | Service Metadata | 1337 | | 1338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1340 where: 1342 o Type: to be assigned by IANA. 1344 o Length: 14. 1346 o Service Metadata: 14 octets of opaque data. 1348 7.2.1.2. NSH Carrier TLV 1350 This document defines an SRv6 TLV called NSH Carrier TLV. It is a 1351 container to carry Service Metadata in the form of Variable-Length 1352 Metadata as defined in [RFC8300] for NSH MD Type 2. The NSH Carrier 1353 TLV has the following format: 1355 0 1 2 3 1356 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 1357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1358 | Type | Length | Flags | 1359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1360 // Service Metadata // 1361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1363 where: 1365 o Type: to be assigned by IANA. 1367 o Length: the total length of the TLV. 1369 o Flags: 8 bits. No flags are defined in this document. SHOULD be 1370 set to 0 on transmission and MUST be ignored on receipt. 1372 o Service Metadata: a list of Service Metadata TLV as defined in 1373 [RFC8300] for NSH MD Type 2. 1375 7.2.2. SRH Tag 1377 The SRH tag identifies a packet as part of a group or class of 1378 packets [RFC8754]. 1380 In the context of service programming, this field can be used to 1381 encode basic metadata in the SRH. An example use-case is to leverage 1382 the SRH tag to encode a policy ID. This policy ID can then be used 1383 by an SR-aware function to identify a particular processing policy to 1384 be applied on that packet. 1386 8. Implementation Status 1388 This section is to be removed prior to publishing as an RFC. 1390 8.1. SR-Aware Services 1392 Specific SRv6 support has been implemented for the below open-source 1393 services: 1395 o Iptables (1.6.2 and later) [IPTABLES] 1397 o Nftables (0.8.4 and later) [NFTABLES] 1399 o Snort [SNORT] 1401 In addition, any service relying on the Linux kernel, version 4.10 1402 and later, or FD.io VPP for packet forwarding can be considered as 1403 SR-aware. 1405 8.2. Proxy Behaviors 1407 The static SR proxy is available for SR-MPLS and SRv6 on various 1408 Cisco hardware and software platforms. Furthermore, the following 1409 proxies are available on open-source software. 1411 +-------------+-------------+ 1412 | VPP | Linux | 1413 +---+-----------------------------------+-------------+-------------+ 1414 | M | Static proxy | Available | In progress | 1415 | P | | | | 1416 | L | Dynamic proxy | In progress | In progress | 1417 | S | | | | 1418 | | Shared memory proxy | In progress | In progress | 1419 +---+-----------------------------------+-------------+-------------+ 1420 | | Static proxy | Available | In progress | 1421 | S | | | | 1422 | R | Dynamic proxy | Available | Available | 1423 | v | | | | 1424 | 6 | Shared memory proxy | In progress | In progress | 1425 | | | | | 1426 | | Masquerading proxy | Available | Available | 1427 +---+-----------------------------------+-------------+-------------+ 1429 Figure 25: Open-source implementation status table 1431 9. Related Works 1433 The Segment Routing solution addresses a wide problem that covers 1434 both topological and service policies. The topological and service 1435 instructions can be either deployed in isolation or in combination. 1436 SR has thus a wider applicability than the architecture defined in 1437 [RFC7665]. Furthermore, the inherent property of SR is a stateless 1438 network fabric. In SR, there is no state within the fabric to 1439 recognize a flow and associate it with a policy. State is only 1440 present at the ingress edge of the SR domain, where the policy is 1441 encoded into the packets. This is completely different from other 1442 proposals such as [RFC8300] and the MPLS label swapping mechanism 1443 described in [RFC8595], which rely on state configured at every hop 1444 of the service chain. 1446 10. IANA Considerations 1448 10.1. SRv6 Endpoint Behaviors 1450 This I-D requests the IANA to allocate, within the "SRv6 Endpoint 1451 Behaviors" sub-registry belonging to the top-level "Segment-routing 1452 with IPv6 dataplane (SRv6) Parameters" registry, the following 1453 allocations: 1455 Value Description Reference 1456 -------------------------------------------------------------- 1457 TBA1-1 End.AN - SR-aware function (native) [This.ID] 1458 TBA1-2 End.AS - Static proxy [This.ID] 1459 TBA1-3 End.AD - Dynamic proxy [This.ID] 1460 TBA1-4 End.AM - Masquerading proxy [This.ID] 1461 TBA1-5 End.AM - Masquerading proxy with NAT [This.ID] 1462 TBA1-6 End.AM - Masquerading proxy with Caching [This.ID] 1463 TBA1-7 End.AM - Masquerading proxy with NAT & [This.ID] 1464 Caching 1466 10.2. Segment Routing Header TLVs 1468 This I-D requests the IANA to allocate, within the "Segment Routing 1469 Header TLVs" registry, the following allocations: 1471 Value Description Reference 1472 ---------------------------------------------- 1473 TBA2-1 Opaque Metadata TLV [This.ID] 1474 TBA2-2 NSH Carrier TLV [This.ID] 1476 11. Security Considerations 1478 The security requirements and mechanisms described in [RFC8402], 1479 [RFC8754] and [RFC8986] also apply to this document. 1481 This document does not introduce any new security vulnerabilities. 1483 12. Acknowledgements 1485 The authors would like to thank Thierry Couture, Ketan Talaulikar, 1486 Loa Andersson, Andrew G. Malis, Adrian Farrel, Alexander Vainshtein 1487 and Joel M. Halpern for their valuable comments and suggestions on 1488 the document. 1490 13. Contributors 1492 The following people have contributed to this document: 1494 Pablo Camarillo 1495 Cisco Systems, Inc. 1496 Spain 1498 Email: pcamaril@cisco.com 1500 Bart Peirens 1501 Proximus 1502 Belgium 1504 Email: bart.peirens@proximus.com 1506 Dirk Steinberg 1507 Lapishills Consulting Limited 1508 Cyprus 1510 Email: dirk@lapishills.com 1512 Ahmed AbdelSalam 1513 Cisco Systems, Inc. 1514 Italy 1516 Email: ahabdels@cisco.com 1518 Gaurav Dawra 1519 LinkedIn 1520 United States of America 1522 Email: gdawra@linkedin.com 1524 Stewart Bryant 1525 Futurewei Technologies Inc 1527 Email: stewart.bryant@gmail.com 1529 Hamid Assarpour 1530 Broadcom 1531 Email: hamid.assarpour@broadcom.com 1533 Himanshu Shah 1534 Ciena 1536 Email: hshah@ciena.com 1538 Luis M. Contreras 1539 Telefonica I+D 1540 Spain 1542 Email: luismiguel.contrerasmurillo@telefonica.com 1544 Jeff Tantsura 1545 Individual 1547 Email: jefftant@gmail.com 1549 Martin Vigoureux 1550 Nokia 1552 Email: martin.vigoureux@nokia.com 1554 Jisu Bhattacharya 1555 Cisco Systems, Inc. 1556 United States of America 1558 Email: jisu@cisco.com 1560 14. References 1562 14.1. Normative References 1564 [I-D.ietf-spring-segment-routing-policy] 1565 Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and 1566 P. Mattes, "Segment Routing Policy Architecture", draft- 1567 ietf-spring-segment-routing-policy-09 (work in progress), 1568 November 2020. 1570 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 1571 Decraene, B., Litkowski, S., and R. Shakir, "Segment 1572 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 1573 July 2018, . 1575 [RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S., 1576 Decraene, B., Litkowski, S., and R. Shakir, "Segment 1577 Routing with the MPLS Data Plane", RFC 8660, 1578 DOI 10.17487/RFC8660, December 2019, 1579 . 1581 [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., 1582 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 1583 (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, 1584 . 1586 [RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, 1587 D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 1588 (SRv6) Network Programming", RFC 8986, 1589 DOI 10.17487/RFC8986, February 2021, 1590 . 1592 14.2. Informative References 1594 [I-D.dawra-idr-bgp-sr-service-chaining] 1595 Dawra, G., Filsfils, C., daniel.bernier@bell.ca, d., 1596 Uttaro, J., Decraene, B., Elmalky, H., Xu, X., Clad, F., 1597 and K. Talaulikar, "BGP Control Plane Extensions for 1598 Segment Routing based Service Chaining", draft-dawra-idr- 1599 bgp-sr-service-chaining-02 (work in progress), January 1600 2018. 1602 [I-D.xu-mpls-payload-protocol-identifier] 1603 Xu, X., Assarpour, H., Ma, S., and F. Clad, "MPLS Payload 1604 Protocol Identifier", draft-xu-mpls-payload-protocol- 1605 identifier-08 (work in progress), December 2020. 1607 [IFIP18] Abdelsalam, A., Salsano, S., Clad, F., Camarillo, P., and 1608 C. Filsfils, "SEgment Routing Aware Firewall For Service 1609 Function Chaining scenarios", IFIP Networking conference , 1610 May 2018. 1612 [IPTABLES] 1613 "iptables-1.6.2 changes", February 2018, 1614 . 1617 [NFTABLES] 1618 "nftables-0.8.4 changes", May 2018, 1619 . 1622 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 1623 Chaining (SFC) Architecture", RFC 7665, 1624 DOI 10.17487/RFC7665, October 2015, 1625 . 1627 [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., 1628 "Network Service Header (NSH)", RFC 8300, 1629 DOI 10.17487/RFC8300, January 2018, 1630 . 1632 [RFC8595] Farrel, A., Bryant, S., and J. Drake, "An MPLS-Based 1633 Forwarding Plane for Service Function Chaining", RFC 8595, 1634 DOI 10.17487/RFC8595, June 2019, 1635 . 1637 [SNORT] "SR-Snort", March 2018, 1638 . 1640 Authors' Addresses 1642 Francois Clad (editor) 1643 Cisco Systems, Inc. 1644 France 1646 Email: fclad@cisco.com 1648 Xiaohu Xu (editor) 1649 Alibaba 1651 Email: xiaohu.xxh@alibaba-inc.com 1653 Clarence Filsfils 1654 Cisco Systems, Inc. 1655 Belgium 1657 Email: cf@cisco.com 1659 Daniel Bernier 1660 Bell Canada 1661 Canada 1663 Email: daniel.bernier@bell.ca 1664 Cheng Li 1665 Huawei 1667 Email: chengli13@huawei.com 1669 Bruno Decraene 1670 Orange 1671 France 1673 Email: bruno.decraene@orange.com 1675 Shaowen Ma 1676 Mellanox 1678 Email: mashaowen@gmail.com 1680 Chaitanya Yadlapalli 1681 AT&T 1682 USA 1684 Email: cy098d@att.com 1686 Wim Henderickx 1687 Nokia 1688 Belgium 1690 Email: wim.henderickx@nokia.com 1692 Stefano Salsano 1693 Universita di Roma "Tor Vergata" 1694 Italy 1696 Email: stefano.salsano@uniroma2.it