6MAN D. Dukes, Ed. Internet-Draft C. Filsfils, Ed. Intended status: Informational Cisco Systems Expires: December 14, 2020 June 12, 2020 Segment Routing Traffic Engineering Leveraging Existing IPv6 Interface Addresses draft-dukes-6man-sr-te-intf-address-00 Abstract This document illustrates how an operator may re-use an existing IPv6 address allocation within its domain to deliver SR-based Traffic Engineering service. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on December 14, 2020. Copyright Notice Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Dukes & Filsfils Expires December 14, 2020 [Page 1] Internet-Draft SR TE Leveraging Existing IPv6 Addresses June 2020 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Reference Topology . . . . . . . . . . . . . . . . . . . . . 2 3. Address Allocation . . . . . . . . . . . . . . . . . . . . . 3 4. SID Bound To Existing Interface Address . . . . . . . . . . . 3 5. Life Of A Packet . . . . . . . . . . . . . . . . . . . . . . 4 5.1. Inter SR Domain . . . . . . . . . . . . . . . . . . . . . 4 5.2. Intra SR Domain . . . . . . . . . . . . . . . . . . . . . 4 6. Upper-Layer Header Processing . . . . . . . . . . . . . . . . 5 6.1. ICMPv6 Echo Request and Reply . . . . . . . . . . . . . . 5 6.2. ICMPv6 Echo Request via an SR Policy . . . . . . . . . . 6 6.3. SSH Session Initiation . . . . . . . . . . . . . . . . . 6 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 9. Ecosystem . . . . . . . . . . . . . . . . . . . . . . . . . . 7 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 10.1. Normative References . . . . . . . . . . . . . . . . . . 7 10.2. Informative References . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 1. Introduction This document illustrates how an operator may re-use an existing IPv6 address allocation within its domain to deliver SR-based Traffic Engineering service by describing: o A reference topology with IPv6 address allocation. o Binding a SID behavior to existing IPv6 addresses. o The life of a packet forwarded via an SR policy. o Upper-layer header processing for a SID bound to an existing IPv6 address. The illustrations cover traffic engineering (TE) SR policy between two border routers of the domain and two hosts of the domain. 2. Reference Topology The reference topology is the same as Section 6.2 of [RFC8754]. Dukes & Filsfils Expires December 14, 2020 [Page 2] Internet-Draft SR TE Leveraging Existing IPv6 Addresses June 2020 + * * * * * * * * * * * * * * * * * * * * + * [8] [9] * | | * | | * [1]----[3]--------[5]----------------[6]---------[4]---[2] * | | * | | * | | * +--------[7]-------+ * * + * * * * * * * SR domain * * * * * * * + Figure 1: Reference topology o 3 and 4 are SR domain edge routers o 5, 6, and 7 are all SR domain routers o 8 and 9 are hosts within the SR domain o 1 and 2 are hosts outside the SR domain 3. Address Allocation The operator has allocated 2001:db8:0::/48 to their domain. A router K is sub-allocated 2001:db8:0:K::/64. A router K has at least one loopback interface. The first loopback interface of a router K's is assigned 2001:db8:0:K::1/128. The interfaces of a router K attached to point to point links connected to other nodes within the domain are assigned link-local addresses. 4. SID Bound To Existing Interface Address The operator enables SR segment endpoint node functionality on a few routers within the domain by binding the SID described in Section 4.3.1 of [RFC8754] to the IPv6 address assigned to the loopback interface of router 3 (2001:db8:0:3::1), router 4 (2001:db8:0:4::1) and router 7 (2001:db8:0:7::1). Packet processing at these segment endpoint nodes follows that defined in Section 4.3 of [RFC8754]. Dukes & Filsfils Expires December 14, 2020 [Page 3] Internet-Draft SR TE Leveraging Existing IPv6 Addresses June 2020 5. Life Of A Packet This section uses the abstract representation of an SRH as defined in Section 6.1 of [RFC8754]. It illustrates two examples from Section 6 of [RFC8754] for inter SR domain and intra SR domain packets and the processing at SR source nodes, transit nodes and SR segment endpoint nodes using the SIDs bound to interface addresses. 5.1. Inter SR Domain Host 1 sends a packet (P1) to host 2 P1: (A1,A2) The SR domain ingress router 3 receives P1 and steers it to SR domain egress router 4 via an SR Policy <2001:db8:0:7::1, 2001:db8:0:4::1>. Router 3 encapsulates the received packet P1 in an outer header with a reduced SRH and sends the packet P2: (2001:db8:0:3::1, 2001:db8:0:7::1)(2001:db8:0:4::1; SL=1)(A1,A2) Router 5 acts as a transit node for P2 and forwards it on the interface toward router 7. Router 7 receives packet P2 and, using the logic in Section 4.3.1.1 of [RFC8754], decrements the Segments Left value and updates the Destination Address to 2001:db8:0:4::1. It sends the resulting packet P3: (2001:db8:0:3::1, 2001:db8:0:4::1)(2001:db8:0:4::1; SL=0)(A1,A2) on the interface toward router 6. Router 6 acts as a transit node for packet P3 and forwards P3 on the interface toward router 4. Router 4 receives packet P3 and, using the logic in Section 4.3.1.2 of [RFC8754], performs IPv6 decapsulation on P2 and forwards the inner packet P1: (A1,A2) on the interface toward host 2. 5.2. Intra SR Domain When host 8 sends a TCP packet to host 9 via an SR Policy <2001:db8:0:7::1, 2001:db8:0:9::1> the packet is P4: (2001:db8:0:8::1, 2001:db8:0:7::1)(2001:db8:0:9::1; SL=1) (TCP) Dukes & Filsfils Expires December 14, 2020 [Page 4] Internet-Draft SR TE Leveraging Existing IPv6 Addresses June 2020 Processing of P4 is similar to P2 above; router 5 forwards while router 7 processes the SRH resulting in the following packet P5: (2001:db8:0:8::1, 2001:db8:0:9::1)(2001:db8:0:9::1; SL=0) (TCP) P5 is forwarded by router 6 to host 9 where the packet is consumed and its TCP payload is processed. 6. Upper-Layer Header Processing The SID behavior described in [RFC8754] permits some upper-layer processing and blocks others. In some use-cases upper-layer processing may be limited when additional SID's are allocated independently of any existing interface address, and as a conservative security measure. In this use-case the operator re-uses existing interface addresses for SIDs, it is expected that upper-layer processing is preserved and permitted for those addresses. The following sections describe ping, ping via an SR policy and SSH session initiation for these SIDs. 6.1. ICMPv6 Echo Request and Reply This section illustrates the life of an ICMPv6 echo request from router 3 (2001:db8:0:3::1) to router 4 (2001:db8:0:4::1) and of the corresponding ICMPv6 echo reply. When router 3 sends an ICMPv6 echo request from 2001:db8:0:3::1 to 2001:db8:0:4::1 on router 4, the packet is P6: (2001:db8:0:3::1, 2001:db8:0:4::1)(ICMPv6 echo request) Router 4 receives packet P6 and follows Section 4.3.1 of [RFC8754]. Specifically, P6 does not contain an SRH and, since upper-layer header processing is permitted, router 4 processes packet P3 as per [RFC4443] and sends the response packet P7: (2001:db8:0:4::1, 2001:db8:0:3::1)(ICMPv6 echo reply) on the interface toward router 6. Router 3 receives packet P7 and applies Section 4.3.1 of [RFC8754]. Specifically, P7 does not contain an SRH and, since upper-layer header processing is permitted, router 3 processes packet P4 as per [RFC4443]. Dukes & Filsfils Expires December 14, 2020 [Page 5] Internet-Draft SR TE Leveraging Existing IPv6 Addresses June 2020 6.2. ICMPv6 Echo Request via an SR Policy This section illustrates the life of an ICMPv6 echo request from router 3 (2001:db8:0:3::1) to router 4 (2001:db8:0:4::1) via router 7 (2001:db8:0:7::1), and of the corresponding ICMPv6 echo reply. When router 3 sends an ICMPv6 echo request from 2001:db8:0:3::1 to 2001:db8:0:4::1 via an SR Policy <2001:db8:0:7::1, 2001:db8:0:4::1> using a reduced SRH, the packet is P8: (2001:db8:0:3::1, 2001:db8:0:7::1)(2001:db8:0:4::1; SL=1)(ICMPv6 echo request) Router 7 eventually receives packet P8 and, using the logic in Section 4.3.1.1 of [RFC8754], decrements the Segments Left value and updates the Destination Address to 2001:db8:0:4::1. It sends the resulting packet P9: (2001:db8:0:3::1, 2001:db8:0:4::1)(2001:db8:0:4::1; SL=0)(ICMPv6 echo request) on the interface toward router 6. Router 4 receives packet P9 and applies Section 4.3.1 of [RFC8754]. Specifically, it determines that packet P9 contains an SRH with Segments Left equal to 0 and proceeds to process the next header in the extension header chain, as per Section 4.3.1.1 of [RFC8754]. Since upper-layer header processing is permitted, router 4 processes packet P9 as per [RFC4443] and sends the response packet P10: (2001:db8:0:4::1, 2001:db8:0:3::1)(ICMPv6 echo reply) on the interface toward router 6. Packet P10 follows the same return path as packet P7 above. 6.3. SSH Session Initiation This section illustrates the initiation of a SSH session between router 3 (2001:db8:0:3::1) and router 4 (2001:db8:0:4::1). SSH first establishes a TCP session between the two routers. Router 3 sends an TCP SYN packet from 2001:db8:0:3::1 to 2001:db8:0:4::1 on router 4, resulting in P11: (2001:db8:0:3::1, 2001:db8:0:4::1)(TCP SYN) Dukes & Filsfils Expires December 14, 2020 [Page 6] Internet-Draft SR TE Leveraging Existing IPv6 Addresses June 2020 Router 4 receives packet P11 and applies Section 4.3.1 of [RFC8754]. Specifically, it determines that packet P11 does not contain an SRH and, since upper-layer header processing is permitted, processes packet P11 as per [RFC0793] and sends the response packet P12: (2001:db8:0:4::1, 2001:db8:0:3::1)(TCP SYN-ACK) on the interface toward router 6. The rest of the communication occurs as normal for SSH [RFC4253]. 7. Security Considerations The SR domain is secured via ingress filtering of packets as described in [RFC8754] Section 5.1. In this document packets entering the SR domain destined to infrastructure addresses are dropped at ingress edge nodes since the SID and infrastructure address prefixes are the same (eg. 2001:db8:0::/48). When an SRv6-capable node receives an IPv6 packet, it performs a longest-prefix-match lookup on the packet's destination address. It processes any SRH in the packet only when the destination address is bound to a SID ([RFC8754] Section 4.3). This further limits the possible attack surface to a subset of the infrastructure address prefix protected by ingress filtering. The SID behavior bound to an address may limit some upper-layer processing ([RFC8754] Section 4.3.1.2). In the use-case described in this document, upper-layer header processing is not limited for an address the SID behavior is bound to. 8. IANA Considerations This document has no IANA actions. 9. Ecosystem The use-case described in this document is supported on Arccus, Broadcom, Cisco, and Linux. 10. References 10.1. Normative References [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, . Dukes & Filsfils Expires December 14, 2020 [Page 7] Internet-Draft SR TE Leveraging Existing IPv6 Addresses June 2020 10.2. Informative References [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, DOI 10.17487/RFC0793, September 1981, . [RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253, January 2006, . [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", STD 89, RFC 4443, DOI 10.17487/RFC4443, March 2006, . Authors' Addresses Darren Dukes (editor) Cisco Systems Canada Email: ddukes@cisco.com Clarence Filsfils (editor) Cisco Systems Belgium Email: cfilsfil@cisco.com Dukes & Filsfils Expires December 14, 2020 [Page 8]