idnits 2.17.1 draft-eden-srv6-tagging-proxy-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 27, 2019) is 1642 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) == Missing Reference: 'ARG' is mentioned on line 195, but not defined == Missing Reference: 'ToS' is mentioned on line 178, but not defined == Missing Reference: 'TC' is mentioned on line 208, but not defined == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-03 Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SPRING Y. Ueno, Ed. 3 Internet-Draft NTT Communications Corporation 4 Intended status: Standards Track R. Nakamura 5 Expires: April 29, 2020 The University of Tokyo 6 T. Kamata 7 Cisco Systems, Inc. 8 October 27, 2019 10 SRv6 Tagging proxy 11 draft-eden-srv6-tagging-proxy-00 13 Abstract 15 This document describes the tagging method of SRv6 proxy. SRv6 proxy 16 is an SR endpoint behavior for processing SRv6 traffic on behalf of 17 an SR-unaware service. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on April 29, 2020. 36 Copyright Notice 38 Copyright (c) 2019 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (https://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. SRv6 Tagging proxy . . . . . . . . . . . . . . . . . . . . . 3 56 3.1. SRv6 pseudocode . . . . . . . . . . . . . . . . . . . . . 4 57 3.1.1. Tagging proxy for inner type IPv4 . . . . . . . . . . 4 58 3.1.2. Tagging proxy for inner type IPv6 . . . . . . . . . . 5 59 4. Implementation status . . . . . . . . . . . . . . . . . . . . 5 60 5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 6 61 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 62 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 63 7.1. SRv6 Endpoint Behaviors . . . . . . . . . . . . . . . . . 6 64 8. Security Considerations . . . . . . . . . . . . . . . . . . . 6 65 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 66 9.1. Normative References . . . . . . . . . . . . . . . . . . 6 67 9.2. Informative References . . . . . . . . . . . . . . . . . 7 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 70 1. Introduction 72 Segment Routing (SR) is a source routing architecture defined in 73 [RFC8402]. SR uses segment identifiers (SIDs) to identify each 74 entity in an SR network. SR can be applied two types of data plane, 75 MPLS and IPv6. IPv6 based SR is called Segment Routing IPv6 (SRv6) 76 and its header format is defined in 77 [I-D.ietf-6man-segment-routing-header]. As for the SRv6 packets, the 78 SIDs are embedded in packets in the form of a list with the current 79 index of the list, called SegmentsLeft (SL). Packets with Segment 80 Routing Headers (SRHs) are steered through the ordered list of SIDs. 81 Note that the proxy behavior defined in this document can only be 82 applied for SRv6 packets. 84 Because SR can steer packets through arbitrary SR nodes, SR can be 85 applied to Service Function Chaining (SFC). SFC, defined in 86 [RFC7665], is an architecture that realizes the on-demand 87 instantiation of an ordered set of service functions. Although there 88 are differences in the specific packet steering method, SR defined in 89 [RFC8402] can realize SFC and 90 [I-D.xuclad-spring-sr-service-programming] describes SR proxy 91 behaviors to integrate SR-unaware services to it. 93 This document describes a new SRv6 proxy, called tagging proxy. The 94 tagging proxy, which is a variant of the dynamic SR proxy, supports 95 both IPv4 and IPv6 and multiple service chains by one proxy instance 96 without state management. 98 2. Terminology 100 This document leverages the terminology proposed in [RFC8402], 101 [I-D.ietf-spring-segment-routing-policy], and 102 [I-D.xuclad-spring-sr-service-programming]. 104 3. SRv6 Tagging proxy 106 The proxy is a variant of the dynamic proxy defined in 107 [I-D.xuclad-spring-sr-service-programming]. The dynamic proxy caches 108 the outer IPv6 header and SRH before removing it from the incoming 109 traffic. After removal of the outer IPv6 and SRH headers, the 110 dynamic proxy sends the traffic to an associating service and the 111 same headers are re-attached to the traffic returning from the 112 service. 114 For caching outer headers, the tagging proxy uses arguments of SRv6 115 SIDs as indexes for cache entires. The arguments are determined by 116 the operator to correspond one-to-one with the service chains, and 117 the process could be automated by the network controllers. Upon 118 receiving a packet whose active segment matches a tagging SR proxy 119 function, the proxy node caches the IPv6 header and SRH. 120 Corresponding cache entry for a packet is indicated by an argument 121 part of the SRv6 SID. Every time a packet arrives, a corresponding 122 cache entry is updated. 124 The tagging proxy removes the IPv6 header and SRH for sending the 125 inner packet to the SR-unaware service. At that time the tagging 126 proxy treats the index as a "tag", that is embedded into the inner 127 packet. As a field to embed the tag, Type of Service (ToS) is used 128 for IPv4 packets and Traffic Class (TC) is used for IPv6 packets. 129 Note that the argument length of the SID for tagging proxy cannot be 130 greater than 8-bit because of the length of ToS and TC fields. 132 When the proxy node receives the packet returning from the SR-unawre 133 service, the proxy node pushes the IPv6 header and SRH onto the 134 packet. The headers are retrieved from the cache entry that 135 corresponds to the tag extracted from the ToS or TC field of the 136 packet. 138 A tagging SR proxy segment is associated with the following mandatory 139 parameters: 141 o NH-ADDR: Next hop Ethernet address (only for inner type IPv4 and 142 IPv6) 144 o IFACE-OUT: Local interface for sending traffic towards the service 146 o IFACE-IN: Local interface receiving the traffic coming back from 147 the service 149 A tagging SR proxy segment is thus defined for a specific service. 150 It is also bound to a pair of directed interfaces on the proxy. 151 These may be both directions of a single interface, or opposite 152 directions of two different interfaces. The latter is recommended in 153 case the service is to be used as part of a bi-directional SR SC 154 policy. If the proxy and the service both support 802.1Q, IFACE-OUT 155 and IFACE-IN can also represent sub-interfaces. 157 3.1. SRv6 pseudocode 159 3.1.1. Tagging proxy for inner type IPv4 161 Upon receiving an IPv6 packet destined for S, where S is an IPv6 162 tagging proxy segment for IPv4 traffic, a node N does: 164 1. IF NH=SRH & SL > 0 & ENH == 4 THEN 165 2. Cache IPv6 Header and SRH into CACHE[ARG] 166 3. Remove the (outer) IPv6 header and its extension headers 167 4. Embed ARG into the ToS field of the (inner) IPv4 header 168 5. Forward the exposed packet on IFACE-OUT towards NH-ADDR 169 6. ELSE 170 7. Drop the packet 172 Upon receiving a non-link-local IPv4 packet on IFACE-IN, a node N 173 does: 175 1. IF CACHE[ToS] THEN 176 2. Set ToS value to 0 177 3. Decrement TTL and update checksum of the inner IPv4 header 178 4. Push the IPv6 header and SRH in CACHE[ToS] 179 5. Set ENH value to 4 180 6. Update the payload length of the outer IPv6 header 181 7. Lookup outer DA in appropriate table and proceed accordingly 182 8. ELSE 183 9. Drop the packet 185 Note that the proxy may cache and restore the ToS value of inner IPv4 186 packet in addition to outer IPv6 header and SRH if the service chain 187 uses single ToS value. 189 3.1.2. Tagging proxy for inner type IPv6 191 Upon receiving an IPv6 packet destined for S, where S is an IPv6 192 tagging proxy segment for IPv6 traffic, a node N does: 194 1. IF NH=SRH & SL > 0 & ENH == 41 THEN 195 2. Cache IPv6 Header and SRH into CACHE[ARG] 196 3. Remove the (outer) IPv6 header and its extension headers 197 4. Embed ARG into the TC field of the (inner) IPv6 header 198 5. Forward the exposed packet on IFACE-OUT towards NH-ADDR 199 6. ELSE 200 7. Drop the packet 202 Upon receiving a non-link-local IPv6 packet on IFACE-IN, a node N 203 does: 205 1. IF CACHE[TC] THEN 206 2. Set TC value to 0 207 3. Decrement Hop Limit of the inner IPv6 header 208 4. Push the IPv6 header and SRH in CACHE[TC] 209 5. Set ENH value to 41 210 6. Update the payload length of the outer IPv6 header 211 7. Lookup outer DA in appropriate table and proceed accordingly 212 8. ELSE 213 9. Drop the packet 215 Note that the proxy may cache and restore the TC value of inner IPv6 216 packet in addition to outer IPv6 header and SRH if the service chain 217 uses single ToS value. 219 4. Implementation status 221 This section is to be removed before publishing as an RFC. 223 The tagging SR proxy is available on the below open-source 224 implementations. 226 o Linux XDP based implementation by Yukito Ueno 228 o Linux kernel based implementation (out-of-tree) by Ryo Nakamura 230 Also, both implementations were operated for the traffic of 231 exhibitors and visitors at Interop Tokyo 2019 ShowNet. 233 5. Discussion 235 This tagging proxy uses ToS or Traffic Class field as a container of 236 an index of a cache entry. Upon receiving a packet returning from an 237 SR-unaware service, the index is needed for the proxy node to decide 238 which cache entry should be pushed to the packet. On the other hand, 239 the usage is different from the original purpose of ToS and TC 240 fields. 242 6. Acknowledgements 244 The authors would like to thank all the members and contributors of 245 Interop Tokyo 2019 ShowNet. The authors are also thankful to 246 Francois Clad for his comments. 248 7. IANA Considerations 250 7.1. SRv6 Endpoint Behaviors 252 This I-D requests the IANA to allocate, within the "SRv6 Endpoint 253 Behaviors" sub-registry belonging to the top-level "Segment-routing 254 with IPv6 dataplane (SRv6) Parameters" registry, the following 255 allocations: 257 Value Description Reference 258 -------------------------------------------------------------- 259 TBA End.AT - Tagging proxy [This.ID] 261 8. Security Considerations 263 The security requirements and mechanisms described in [RFC8402], 264 [I-D.ietf-6man-segment-routing-header] and 265 [I-D.filsfils-spring-srv6-network-programming] also apply to this 266 document. This document does not introduce any new security 267 vulnerabilities. 269 9. References 271 9.1. Normative References 273 [I-D.filsfils-spring-srv6-network-programming] 274 Filsfils, C., Camarillo, P., Leddy, J., 275 daniel.voyer@bell.ca, d., Matsushima, S., and Z. Li, "SRv6 276 Network Programming", draft-filsfils-spring-srv6-network- 277 programming-07 (work in progress), February 2019. 279 [I-D.ietf-6man-segment-routing-header] 280 Filsfils, C., Dukes, D., Previdi, S., Leddy, J., 281 Matsushima, S., and d. daniel.voyer@bell.ca, "IPv6 Segment 282 Routing Header (SRH)", draft-ietf-6man-segment-routing- 283 header-26 (work in progress), October 2019. 285 [I-D.ietf-spring-segment-routing-policy] 286 Filsfils, C., Sivabalan, S., daniel.voyer@bell.ca, d., 287 bogdanov@google.com, b., and P. Mattes, "Segment Routing 288 Policy Architecture", draft-ietf-spring-segment-routing- 289 policy-03 (work in progress), May 2019. 291 [I-D.xuclad-spring-sr-service-programming] 292 Clad, F., Xu, X., Filsfils, C., daniel.bernier@bell.ca, 293 d., Li, C., Decraene, B., Ma, S., Yadlapalli, C., 294 Henderickx, W., and S. Salsano, "Service Programming with 295 Segment Routing", draft-xuclad-spring-sr-service- 296 programming-02 (work in progress), April 2019. 298 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 299 Decraene, B., Litkowski, S., and R. Shakir, "Segment 300 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 301 July 2018, . 303 9.2. Informative References 305 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 306 Chaining (SFC) Architecture", RFC 7665, 307 DOI 10.17487/RFC7665, October 2015, 308 . 310 Authors' Addresses 312 Yukito Ueno (editor) 313 NTT Communications Corporation 314 Tokyo 315 JP 317 Phone: +80 90 3085 5274 318 Email: yukito.ueno@ntt.com 319 Ryo Nakamura 320 The University of Tokyo 321 Tokyo 322 JP 324 Phone: +81 3 5841 2710 325 Email: upa@haeena.net 327 Teppei Kamata 328 Cisco Systems, Inc. 329 Tokyo 330 JP 332 Email: tkamata@cisco.comt