idnits 2.17.1 draft-dukes-6man-sr-te-intf-address-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 (June 12, 2020) is 1407 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '8' on line 93 -- Looks like a reference, but probably isn't: '9' on line 93 -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6MAN D. Dukes, Ed. 3 Internet-Draft C. Filsfils, Ed. 4 Intended status: Informational Cisco Systems 5 Expires: December 14, 2020 June 12, 2020 7 Segment Routing Traffic Engineering Leveraging Existing IPv6 Interface 8 Addresses 9 draft-dukes-6man-sr-te-intf-address-00 11 Abstract 13 This document illustrates how an operator may re-use an existing IPv6 14 address allocation within its domain to deliver SR-based Traffic 15 Engineering service. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at https://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on December 14, 2020. 34 Copyright Notice 36 Copyright (c) 2020 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (https://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. Reference Topology . . . . . . . . . . . . . . . . . . . . . 2 53 3. Address Allocation . . . . . . . . . . . . . . . . . . . . . 3 54 4. SID Bound To Existing Interface Address . . . . . . . . . . . 3 55 5. Life Of A Packet . . . . . . . . . . . . . . . . . . . . . . 4 56 5.1. Inter SR Domain . . . . . . . . . . . . . . . . . . . . . 4 57 5.2. Intra SR Domain . . . . . . . . . . . . . . . . . . . . . 4 58 6. Upper-Layer Header Processing . . . . . . . . . . . . . . . . 5 59 6.1. ICMPv6 Echo Request and Reply . . . . . . . . . . . . . . 5 60 6.2. ICMPv6 Echo Request via an SR Policy . . . . . . . . . . 6 61 6.3. SSH Session Initiation . . . . . . . . . . . . . . . . . 6 62 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 63 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 64 9. Ecosystem . . . . . . . . . . . . . . . . . . . . . . . . . . 7 65 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 66 10.1. Normative References . . . . . . . . . . . . . . . . . . 7 67 10.2. Informative References . . . . . . . . . . . . . . . . . 8 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 70 1. Introduction 72 This document illustrates how an operator may re-use an existing IPv6 73 address allocation within its domain to deliver SR-based Traffic 74 Engineering service by describing: 76 o A reference topology with IPv6 address allocation. 78 o Binding a SID behavior to existing IPv6 addresses. 80 o The life of a packet forwarded via an SR policy. 82 o Upper-layer header processing for a SID bound to an existing IPv6 83 address. 85 The illustrations cover traffic engineering (TE) SR policy between 86 two border routers of the domain and two hosts of the domain. 88 2. Reference Topology 90 The reference topology is the same as Section 6.2 of [RFC8754]. 92 + * * * * * * * * * * * * * * * * * * * * + 93 * [8] [9] * 94 | | 95 * | | * 96 [1]----[3]--------[5]----------------[6]---------[4]---[2] 97 * | | * 98 | | 99 * | | * 100 +--------[7]-------+ 101 * * 102 + * * * * * * * SR domain * * * * * * * + 104 Figure 1: Reference topology 106 o 3 and 4 are SR domain edge routers 108 o 5, 6, and 7 are all SR domain routers 110 o 8 and 9 are hosts within the SR domain 112 o 1 and 2 are hosts outside the SR domain 114 3. Address Allocation 116 The operator has allocated 2001:db8:0::/48 to their domain. 118 A router K is sub-allocated 2001:db8:0:K::/64. 120 A router K has at least one loopback interface. 122 The first loopback interface of a router K's is assigned 123 2001:db8:0:K::1/128. 125 The interfaces of a router K attached to point to point links 126 connected to other nodes within the domain are assigned link-local 127 addresses. 129 4. SID Bound To Existing Interface Address 131 The operator enables SR segment endpoint node functionality on a few 132 routers within the domain by binding the SID described in 133 Section 4.3.1 of [RFC8754] to the IPv6 address assigned to the 134 loopback interface of router 3 (2001:db8:0:3::1), router 4 135 (2001:db8:0:4::1) and router 7 (2001:db8:0:7::1). 137 Packet processing at these segment endpoint nodes follows that 138 defined in Section 4.3 of [RFC8754]. 140 5. Life Of A Packet 142 This section uses the abstract representation of an SRH as defined in 143 Section 6.1 of [RFC8754]. 145 It illustrates two examples from Section 6 of [RFC8754] for inter SR 146 domain and intra SR domain packets and the processing at SR source 147 nodes, transit nodes and SR segment endpoint nodes using the SIDs 148 bound to interface addresses. 150 5.1. Inter SR Domain 152 Host 1 sends a packet (P1) to host 2 154 P1: (A1,A2) 156 The SR domain ingress router 3 receives P1 and steers it to SR domain 157 egress router 4 via an SR Policy <2001:db8:0:7::1, 2001:db8:0:4::1>. 158 Router 3 encapsulates the received packet P1 in an outer header with 159 a reduced SRH and sends the packet 161 P2: (2001:db8:0:3::1, 2001:db8:0:7::1)(2001:db8:0:4::1; SL=1)(A1,A2) 163 Router 5 acts as a transit node for P2 and forwards it on the 164 interface toward router 7. 166 Router 7 receives packet P2 and, using the logic in Section 4.3.1.1 167 of [RFC8754], decrements the Segments Left value and updates the 168 Destination Address to 2001:db8:0:4::1. It sends the resulting 169 packet 171 P3: (2001:db8:0:3::1, 2001:db8:0:4::1)(2001:db8:0:4::1; SL=0)(A1,A2) 173 on the interface toward router 6. 175 Router 6 acts as a transit node for packet P3 and forwards P3 on the 176 interface toward router 4. 178 Router 4 receives packet P3 and, using the logic in Section 4.3.1.2 179 of [RFC8754], performs IPv6 decapsulation on P2 and forwards the 180 inner packet P1: (A1,A2) on the interface toward host 2. 182 5.2. Intra SR Domain 184 When host 8 sends a TCP packet to host 9 via an SR Policy 185 <2001:db8:0:7::1, 2001:db8:0:9::1> the packet is 187 P4: (2001:db8:0:8::1, 2001:db8:0:7::1)(2001:db8:0:9::1; SL=1) (TCP) 188 Processing of P4 is similar to P2 above; router 5 forwards while 189 router 7 processes the SRH resulting in the following packet 191 P5: (2001:db8:0:8::1, 2001:db8:0:9::1)(2001:db8:0:9::1; SL=0) (TCP) 193 P5 is forwarded by router 6 to host 9 where the packet is consumed 194 and its TCP payload is processed. 196 6. Upper-Layer Header Processing 198 The SID behavior described in [RFC8754] permits some upper-layer 199 processing and blocks others. In some use-cases upper-layer 200 processing may be limited when additional SID's are allocated 201 independently of any existing interface address, and as a 202 conservative security measure. 204 In this use-case the operator re-uses existing interface addresses 205 for SIDs, it is expected that upper-layer processing is preserved and 206 permitted for those addresses. 208 The following sections describe ping, ping via an SR policy and SSH 209 session initiation for these SIDs. 211 6.1. ICMPv6 Echo Request and Reply 213 This section illustrates the life of an ICMPv6 echo request from 214 router 3 (2001:db8:0:3::1) to router 4 (2001:db8:0:4::1) and of the 215 corresponding ICMPv6 echo reply. 217 When router 3 sends an ICMPv6 echo request from 2001:db8:0:3::1 to 218 2001:db8:0:4::1 on router 4, the packet is 220 P6: (2001:db8:0:3::1, 2001:db8:0:4::1)(ICMPv6 echo request) 222 Router 4 receives packet P6 and follows Section 4.3.1 of [RFC8754]. 223 Specifically, P6 does not contain an SRH and, since upper-layer 224 header processing is permitted, router 4 processes packet P3 as per 225 [RFC4443] and sends the response packet 227 P7: (2001:db8:0:4::1, 2001:db8:0:3::1)(ICMPv6 echo reply) 229 on the interface toward router 6. 231 Router 3 receives packet P7 and applies Section 4.3.1 of [RFC8754]. 232 Specifically, P7 does not contain an SRH and, since upper-layer 233 header processing is permitted, router 3 processes packet P4 as per 234 [RFC4443]. 236 6.2. ICMPv6 Echo Request via an SR Policy 238 This section illustrates the life of an ICMPv6 echo request from 239 router 3 (2001:db8:0:3::1) to router 4 (2001:db8:0:4::1) via router 7 240 (2001:db8:0:7::1), and of the corresponding ICMPv6 echo reply. 242 When router 3 sends an ICMPv6 echo request from 2001:db8:0:3::1 to 243 2001:db8:0:4::1 via an SR Policy <2001:db8:0:7::1, 2001:db8:0:4::1> 244 using a reduced SRH, the packet is 246 P8: (2001:db8:0:3::1, 2001:db8:0:7::1)(2001:db8:0:4::1; SL=1)(ICMPv6 247 echo request) 249 Router 7 eventually receives packet P8 and, using the logic in 250 Section 4.3.1.1 of [RFC8754], decrements the Segments Left value and 251 updates the Destination Address to 2001:db8:0:4::1. It sends the 252 resulting packet 254 P9: (2001:db8:0:3::1, 2001:db8:0:4::1)(2001:db8:0:4::1; SL=0)(ICMPv6 255 echo request) 257 on the interface toward router 6. 259 Router 4 receives packet P9 and applies Section 4.3.1 of [RFC8754]. 260 Specifically, it determines that packet P9 contains an SRH with 261 Segments Left equal to 0 and proceeds to process the next header in 262 the extension header chain, as per Section 4.3.1.1 of [RFC8754]. 263 Since upper-layer header processing is permitted, router 4 processes 264 packet P9 as per [RFC4443] and sends the response packet 266 P10: (2001:db8:0:4::1, 2001:db8:0:3::1)(ICMPv6 echo reply) 268 on the interface toward router 6. 270 Packet P10 follows the same return path as packet P7 above. 272 6.3. SSH Session Initiation 274 This section illustrates the initiation of a SSH session between 275 router 3 (2001:db8:0:3::1) and router 4 (2001:db8:0:4::1). 277 SSH first establishes a TCP session between the two routers. Router 278 3 sends an TCP SYN packet from 2001:db8:0:3::1 to 2001:db8:0:4::1 on 279 router 4, resulting in 281 P11: (2001:db8:0:3::1, 2001:db8:0:4::1)(TCP SYN) 282 Router 4 receives packet P11 and applies Section 4.3.1 of [RFC8754]. 283 Specifically, it determines that packet P11 does not contain an SRH 284 and, since upper-layer header processing is permitted, processes 285 packet P11 as per [RFC0793] and sends the response packet 287 P12: (2001:db8:0:4::1, 2001:db8:0:3::1)(TCP SYN-ACK) 289 on the interface toward router 6. 291 The rest of the communication occurs as normal for SSH [RFC4253]. 293 7. Security Considerations 295 The SR domain is secured via ingress filtering of packets as 296 described in [RFC8754] Section 5.1. In this document packets 297 entering the SR domain destined to infrastructure addresses are 298 dropped at ingress edge nodes since the SID and infrastructure 299 address prefixes are the same (eg. 2001:db8:0::/48). 301 When an SRv6-capable node receives an IPv6 packet, it performs a 302 longest-prefix-match lookup on the packet's destination address. It 303 processes any SRH in the packet only when the destination address is 304 bound to a SID ([RFC8754] Section 4.3). This further limits the 305 possible attack surface to a subset of the infrastructure address 306 prefix protected by ingress filtering. 308 The SID behavior bound to an address may limit some upper-layer 309 processing ([RFC8754] Section 4.3.1.2). In the use-case described in 310 this document, upper-layer header processing is not limited for an 311 address the SID behavior is bound to. 313 8. IANA Considerations 315 This document has no IANA actions. 317 9. Ecosystem 319 The use-case described in this document is supported on Arccus, 320 Broadcom, Cisco, and Linux. 322 10. References 324 10.1. Normative References 326 [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., 327 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 328 (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, 329 . 331 10.2. Informative References 333 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 334 RFC 793, DOI 10.17487/RFC0793, September 1981, 335 . 337 [RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 338 Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253, 339 January 2006, . 341 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 342 Control Message Protocol (ICMPv6) for the Internet 343 Protocol Version 6 (IPv6) Specification", STD 89, 344 RFC 4443, DOI 10.17487/RFC4443, March 2006, 345 . 347 Authors' Addresses 349 Darren Dukes (editor) 350 Cisco Systems 351 Canada 353 Email: ddukes@cisco.com 355 Clarence Filsfils (editor) 356 Cisco Systems 357 Belgium 359 Email: cfilsfil@cisco.com