| 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
This document illustrates how an operator may re-use an existing IPv6 address allocation within its domain to deliver SR-based Traffic Engineering service.
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 (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.
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:
The illustrations cover traffic engineering (TE) SR policy between two border routers of the domain and two hosts of the domain.
The reference topology is the same as Section 6.2 of [RFC8754].
+ * * * * * * * * * * * * * * * * * * * * +
* [8] [9] *
| |
* | | *
[1]----[3]--------[5]----------------[6]---------[4]---[2]
* | | *
| |
* | | *
+--------[7]-------+
* *
+ * * * * * * * SR domain * * * * * * * +
Figure 1: Reference topology
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.
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].
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.
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.
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)
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.
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.
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].
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.
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)
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].
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.
This document has no IANA actions.
The use-case described in this document is supported on Arccus, Broadcom, Cisco, and Linux.
| [RFC8754] | Filsfils, C., Dukes, D., Previdi, S., Leddy, J., Matsushima, S. and D. Voyer, "IPv6 Segment Routing Header (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020. |
| [RFC0793] | Postel, J., "Transmission Control Protocol", STD 7, RFC 793, DOI 10.17487/RFC0793, September 1981. |
| [RFC4253] | Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253, January 2006. |
| [RFC4443] | Conta, A., Deering, S. and M. Gupta, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", STD 89, RFC 4443, DOI 10.17487/RFC4443, March 2006. |