Insertion of IPv6 Segment Routing Headers in a Controlled Domain
draft-voyer-6man-extension-header-insertion-07

Abstract

Traffic traversing an SR domain is encapsulated in an outer IPv6 header for its journey through the SR domain.

To implement transport services strictly within the SR domain, the SR domain may require insertion or removal of an SRH after the outer IPv6 header of the SR domain. Any segment within the SRH is strictly contained within the SR domain.

The SR domain always preserves the end-to-end integrity of traffic traversing it. No extension header is manipulated, inserted or removed from an inner transported packet. The packet leaving the SR domain is exactly the same (except for the hop-limit update) as the packet entering the SR domain.

The SR domain is designed with link MTU sufficiently greater than the MTU at the ingress edge of the SR domain.

Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

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 March 23, 2020.

Copyright Notice

Copyright (c) 2019 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.

Table of Contents

• 1. Introduction
• 2. SRH-based Services Within the SR Domain
• 2.1. Actions Within the SR Domain
• 2.2. Constraints
• 3. Detailed Description of Actions in the SR Domain
• 3.1. Action 2: SRH Insertion
• 3.2. Action 3: SRH Removal
• 4. MTU Considerations
• 4.1. ICMP Error Processing
• 4.2. Packet Too Big
• 5. Security Considerations
• 6. Action Within the SR Domain and RFC8200
• 7. IANA Considerations
• 8. Contributors
• 9. References
• 9.1. Normative References
• 9.2. Informative References
• Authors' Addresses

1. Introduction

This document describes insertion and removal of SRH within an SR domain, and explores why and how it is safe to do so.

2. SRH-based Services Within the SR Domain

An SR Domain is defined in [RFC8402].

Section 5.2 of [I-D.ietf-6man-segment-routing-header] further describes the SR domain as a single system with delegation among components. It states:

• All intra SR Domain packets are of the SR Domain. The IPv6 header is originated by a node of the SR Domain, and is destined to a node of the SR Domain.
• All inter domain packets are encapsulated for the part of the packet journey that is within the SR Domain. The outer IPv6 header is originated by a node of the SR Domain, and is destined to a node of the SR Domain.

In other words, all packets within the SR domain have a source and destination address within the SR Domain.

The following illustration shows how traffic is encapsulated within an SR domain, and how an SRH is inserted and processed for a packet traversing the SR domain.

            + * * * * * * * * * * * * * * * * * * * * +

           *                                         *
   [1]----[3]--------[5]----------------[6]---------[4]---[2]
           *          |                  |           *
                      |                  |
           *          |                  |           *
                     [7]----------------[8]
           *                                         *

           + * * * * * * *  SR Domain  * * * * * * * +

Figure 1

• 3 and 4 are SR Domain edge routers
• 5, 6, 7, and 8 are all SR Domain routers
• 1 and 2 are hosts outside the SR Domain
• The SR domain is secured as per Section 5.1 of [I-D.ietf-6man-segment-routing-header] and no external packet can enter the domain with a destination address equal to a segment of the domain.

When host 1 sends a packet to host 2, the packet is

• P1: (A1,A2)

The SR Domain ingress router 3 receives P1 and steers it to SR Domain egress router 4 via an SR Policy <S6, S4>. Router 3 encapsulates the received packet in an outer IPv6 header with an SRH. The packet is

• P2: (A3, S6)(S4; SL=1)(A1, A2)

At node 5, P2 is steered through an SR Policy <S7,S8.PSP> resulting in the insertion of an SRH. S8.PSP is a segment at node 8 that removes the SRH when segments left is decremented to 0

• P3: (A3, S7)(S6,S8.PSP; SL=2)(S4;SL=1)(A1, A2)

At node 7, S7 is processed. The outer most SRH segments left (SL) is decremented and S8 is placed in the destination address of the outer IPv6 header resulting in

• P4: (A3, S8.PSP)(S6,S8.PSP; SL=1)(S4;SL=1)(A1, A2)

At node 8, S8.PSP is processed. The outer most SRH segments left is decremented to 0 and S6 is placed in the destination address of the outer IPv6 header. Since S8.PSP decrements SL to 0 it also removes the SRH resulting in

• P5: (A3, S6)(S4; SL=1)(A1, A2)

At node 6, S6 is processed. SL is decremented and S4 is placed in the destination address of the outer IPv6 header

• P6: (A3, S4)(S4; SL=0)(A1, A2)

At node 4, S4 is processed and the outer IPv6 header chain is removed resulting in

• P7: (A1, A2)

2.1. Actions Within the SR Domain

The illustration above shows the possible actions taken in the SR domain. They can be categorized as follows:

Action 1

IPv6 encapsulation and SRH insertion at SR Domain ingress edge.
Described in [I-D.ietf-6man-segment-routing-header]

Action 2

SRH insertion at a node within the SR Domain applying an SR policy to packets sourced and destined to nodes within the SR Domain. The SR Policy may be applied for multiple reasons including TILFA [I-D.ietf-rtgwg-segment-routing-ti-lfa], or intermediate node TE [I-D.ietf-spring-segment-routing-policy]. All segments are within the SR domain.
Described in this document

Action 3

SRH processing at a segment endpoint, with PSP to remove an SRH when SL is decremented to zero.
Described in this document and formally defined as an instruction of the network programming model [I-D.ietf-spring-srv6-network-programming]

Action 4

IPv6 and SRH decapsulation at SR domain egress edge
Described in draft-ietf-6man-segment-routing-header

2.2. Constraints

This document defines several constraints on the SR domain that enable the safe insertion and removal of an SRH within the SR domain.

Source and destination address:

All traffic within the SR domain has IPv6 source and destination address within the SR domain.

SRH without additional extension headers:

Within the context of this document and the described SRH use-case within the SR domain, the SR domain can guarantee that SRH is the sole extension header after the outer IPv6 header.

SRH insertion:

Only traffic sourced from and destined to nodes in the SR domain may have an SRH inserted.

SRH segment list:

Segments in the SRH segment list are all within the SR domain

MTU of the SR domain:

SR domain link MTU is sufficiently greater than the MTU at the ingress edge of the SR domain. The difference in MTUs should be greater than the sum of the IPv6 header length and the expected length of all inserted SRH within the SR domain.

Packet size in the SR domain:

Packet size in the SR domain:
All traffic forwarded in the SR domain has a packet size less than the MTU of the SR domain.

This document does not limit the ability for future documents to widen the scope.

These constraints reflect the design practices used in commercial SRv6 deployments reported in [I-D.matsushima-spring-srv6-deployment-status]

3. Detailed Description of Actions in the SR Domain

Within an SR domain, constrained as defined in Section 2.1, there are two actions that require detailed description in this document.

Action 2: SRH insertion at a node within the SR Domain

Action 3: SRH processing at a segment endpoint with PSP to remove the SRH when SL is decremented to zero.

3.1. Action 2: SRH Insertion

When an SRH is inserted by an intermediate node it walks the IPv6 header chain to the first header after the IPv6 header and inserts the SRH prior to that header.

 
   +---------------+----------------------+------------
   |  IPv6 header  | SRH                  | IPv4 header
   |               |                      |
   | Next Header = | Next Header =        |
   |      SRH      |       IPv4           |
   +---------------+----------------------+------------
                   ^-SRH insertion here
                              

Figure 2

An SR Policy headend within the SR domain inserts an SRH as follows:

1. Determine where to insert the SRH.
2. Copy the destination address from the IPv6 header to Segment List[0] of the SRH to be inserted. This ensures the original destination address is restored upon execution of the final segment in the inserted SRH.
3. Increase the IPv6 header payload length field by the length in bytes of the inserted SRH.
   If the resulting payload length exceeds 2^16 bytes generate an ICMP "Packet To Big" error message to the source with an MTU of 2^16 minus the length in bytes of the SRH and discard the packet.
   Note: this does not occur in reported deployments given the MTU design constraint.
4. Set the SRH next header field to the value in the next header field of the header that will precede the SRH.
5. Set the next header field of the header that will precede the SRH to the routing extension header (43)
6. Set the IPv6 destination address to the first segment in the segment list of the SRH to be inserted. This segment may or may not be present in the SRH depending on the use of a reduced SRH, see section 4.1.1 of [I-D.ietf-6man-segment-routing-header].
7. Insert the SRH into the packet at the location it should be inserted and resubmit the packet to the IPv6 module for transmission to the new destination.

3.2. Action 3: SRH Removal

An endpoint of the SRH removes an SRH of the SR domain as follows:

1. Decrement payload length by the length in bytes of the SRH being removed.
2. Copy the next header value of the SRH being removed to the next header value of the preceding header.
3. Remove the SRH from the packet.

4. MTU Considerations

This document assumes that the SR domain link MTU is sufficiently greater than the MTU at the ingress edge of the SR domain. The difference in MTUs should be greater than the sum of the IPv6 header length and the expected length of all inserted SRH within the SR domain.

This is in-line with well known mitigation techniques that have been deployed since the early 2000's for the MPLS-based FRR services and numerous VPN services that involve deploying a greater MTU value in the core than at the ingress edge of a domain.

This is also recommended in section 5.3 of [I-D.ietf-6man-segment-routing-header].

4.1. ICMP Error Processing

ICMP errors may be generated for packets with one or more SRH present. In such a case the ICMP process of a source node may receive an ICMP error packet with more SRH's than it originated.

Processing of such packets follows the processing defined in section 5.4 of [I-D.ietf-6man-segment-routing-header] with relevant text copied below:

• Walk all extension headers of the invoking IPv6 packet to the routing extension header preceding the upper layer header.
  • If routing header is type 4 (SRH)
    • Use the SID at Segment List[0] as the destination address of the invoking packet.

ICMP errors are then processed by upper layer transports as defined in [RFC4443].

For IP packets encapsulated in an outer IPv6 header, ICMP error handling is as defined in [RFC2473].

4.2. Packet Too Big

When a larger MTU is deployed within the SR domain than at the ingress edge ICMP "Packet Too Big" error messages should not be generated within the SR domain.

They must be handled regardless, so in addition to the ICMP processing defined in this document, a source node in the SR domain receiving and processing an ICMP error "Packet Too Big" message SHOULD decrement the MTU received in the message by the size in bytes of the SRH's present in the invoking packet. This is required to compensate for any SRH inserted along the packets path.

The SR domain ingress edge processing the ICMP error SHOULD log the error and decrement the ingress edge MTU for traffic traversing the SR domain (if it's greater than the IPv6 minimum MTU of 1280 bytes) or fragment the encapsulated packet to avoid reducing the ingress edge MTU.

5. Security Considerations

To implement transport services strictly within the SR domain, the SR domain may require the insertion or removal of an SRH after the outer IPv6 header of the SR domain.

This document details the actions and reminds the reader of the conditions that ensure

1. the integrity of the transported inner packet,
2. the security of the SR domain,
3. the non-leakage of intra SR domain SRH on external traffic.

The SR domain always preserves the end-to-end integrity of traffic traversing it. No extension header is manipulated, inserted or removed from an inner transported packet. The packet leaving the SR domain is exactly the same (except for the hop-limit update) as the packet entering the SR domain.

The SR domain is secured as per Section 5.1 of [SRH] and no external packet can enter the domain with a destination address equal to a segment of the domain.

An SRH of the SR domain is only added after the outer IPv6 header. An SRH of the SR domain only contains segments within the domain. Under these conditions, the SRH of the SR domain cannot leave the domain. Additionally, egress edge nodes SHOULD ensure packets sourced from within the SR domain (IPv6 source prefix), destined to nodes outside the SR domain (IPv6 destination prefix) do not contain an SRH.

All security considerations discussed in [I-D.ietf-6man-segment-routing-header] are equally applicable to an SRH applied by a non-source node within the SR domain.

6. Action Within the SR Domain and RFC8200

The four actions within the SR domain have the following association with [RFC8200]

Action 1

IPv6 encapsulation and optional insertion of SRH at the SR domain ingress edge generates a new IPv6 packet.
Insertion of the SRH, if done, is obviously intended by the SR source node.
The source node also intends for the SR domain to apply any other SRH required.
This is in-line with RFC8200 as the source of the outer header inserts the extension header.

Action 2

SRH insertion at a node within the SR Domain.
Insertion of the SRH at a node within the SR domain is intended by any source node in the SR domain.
The source node has ensured the packet length it sends is sufficient for the domain to insert an SRH.

Action 3

SRH processing and removal at a segment endpoint node
The node in the destination address parses the SRH and removes the SRH when segments left is decremented to 0.
The node removing the SRH is the destination address of the packet as per RFC8200.

Action 4

IPv6 and SRH decapsulation at SR domain egress edge
The node in the destination address of the IPv6 header decapsulates the outer IPv6 header when no further segments are left.
This is in-line with [RFC8200] as the destination of the outer header removes the outer header and its extension header.

Actions 1, 3, and 4 are all directly supported by [RFC8200] section 4

• Extension headers (except for the Hop-by-Hop Options header) are not processed, inserted, or deleted by any node along a packet's delivery path, until the packet reaches the node (or each of the set of nodes, in the case of multicast) identified in the Destination Address field of the IPv6 header.
• Each extension header should occur at most once, except for the Destination Options header, which should occur at most twice (once before a Routing header and once before the upper-layer header).
• IPv6 nodes must accept and attempt to process extension headers in any order and occurring any number of times in the same packet

Action 2 inserts an SRH in a packet within the SR domain at a node not in the destination address, and inserts more than one SRH in a packet. This does not appear to be permitted by the statements quoted above from RFC8200. However, the restrictions above are not applicable within the SR domain. Every source node participating in the SR domain expects SRH insertion, relies on it for services provided by the SR domain, correctly processes ICMP errors, and according to RFC8200 must process multiple SRH in the same packet.

7. IANA Considerations

This document doesn't introduce any IANA request.

8. Contributors

The authors would like to thank the following for their contributions: Robert Raszuk, Stefano Previdi, Stefano Salsano, Antonio Cianfrani, David Lebrun, Olivier Bonaventure, Prem Jonnalagadda, Milad Sharif, Hani Elmalky, Ahmed Abdelsalam, Arthi Ayyangar, Dirk Steinberg, Wim Henderickx.

9. References

9.1. Normative References

9.2. Informative References

Authors' Addresses