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