Internet DRAFT - draft-dukes-6man-sr-te-intf-address
draft-dukes-6man-sr-te-intf-address
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,
<https://www.rfc-editor.org/info/rfc8754>.
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,
<https://www.rfc-editor.org/info/rfc793>.
[RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253,
January 2006, <https://www.rfc-editor.org/info/rfc4253>.
[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,
<https://www.rfc-editor.org/info/rfc4443>.
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]