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

Abstract

The network operator and vendor community has clearly indicated that IPv6 header insertion is useful and required. This is notably the case when the entire journey of the packet remains in its source domain. In such a context, it does not matter where the extension header is inserted. The source domain may decide to place the IPv6 extension header insertion where it suits its best: at the source of the packet or at any midpoint within the source 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 December 24, 2018.

Copyright Notice

Copyright (c) 2018 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. Source Domain and Packet Journey
• 3. Transit Through a Source Domain
• 4. Impact of SRH Insertion Within a Source Domain
• 4.1. ICMP Error message processing
• 4.1.1. ICMP Error message processing with routing header
• 4.2. Destination outside the Source Domain
• 5. Security Considerations
• 6. IANA Considerations
• 7. Manageability Considerations
• 8. Contributors
• 9. Acknowledgements
• 10. References
• 10.1. Normative References
• 10.2. Informative References
• Authors' Addresses

1. Introduction

We define the concept of "domain" as the set of nodes under the same administration. For example, a network operator infrastructure including routers and links grouped into BGP autonomous systems (ASs) and routing domains (running OSFP or IS-IS).

We define "source domain" as the domain of the source of the packet.

2. Source Domain and Packet Journey

 (-- Source Domain D --)
 (                     )
 ( 1-----2-----3-----9 )
 (       |     |       )
 (       4-----5       )
 (---------------------)

Figure 1: Source Domain

In the previous diagram:

• All the nodes 1 to 9 are in the same Source Domain D.
• Node 1 originates a packet P1 destined to 9 (SA=1, DA=9).
• Domain D runs a link-state routing protocols which implements the Fast Reroute (FRR) service through the Topology Independent Loop Free Alternates (TI-LFA, [I-D.bashandy-rtgwg-segment-routing-ti-lfa]).
• All link metrics are set to 10.
• Node 2's TI-LFA pre-computed backup path for the destination 9 is the Segment Routing Policy <5, 9> via outgoing interface (OIF) to node 4 according to [I-D.filsfils-spring-segment-routing-policy], [I-D.filsfils-spring-srv6-network-programming], and [I-D.ietf-6man-segment-routing-header]

Within the 50 milliseconds of link 2-3 failure detection, node 2 reroutes the traffic destined to 9 by inserting the pre-computed segment routing header (SRH) with SID list <5, 9> and forwards the packet to node 4. Node 4 forwards based on DA=5 to neighbor 5. Node 5 updates the DA to 9 and removes the SRH. Node 9 receives the packet with (SA=1, DA=9).

This FRR service is clearly beneficial for the operator of domain D: without this FRR operation, depending on the scale of the domain and the quality of the routing convergence implementation, traffic could be dropped for hundreds to thousands of milliseconds waiting for the routing plane to converge.

This FRR service is largely deployed with MPLS.

It is important to note that the operators industry is strongly requiring the same TI-LFA FRR service without the need to deploy or maintain the MPLS layer.

Obviously, this FRR service increases the size of the packet during its journey within domain D. This is well-known to operators. Well- known mitigation techniques have been deployed for more than 15 years for the MPLS-based FRR service and the numerous VPN services. This is often achieved by deploying a greater MTU value higher in the core than at the ingress edge.

3. Transit Through a Source Domain

     (-- Source Domain D --)
     (                     )
 A---( 1-----2-----3-----9 )---B
     (       |     |       )
     (       4-----5       )
     (---------------------)

Figure 2: Transit Through a Source Domain

Consider a packet sent from A to B called P2 (A,B). A and B are external nodes to the Source Domain D.

Any packet transiting through source domain D must be unchanged when it exits domain D.

Therefore, node 1 encapsulates the packet P2 in an outer IPv6 header with SA=1 and DA=9. Resulting in packet P3 (1,9)(A,B).

From the viewpoint of domain D, packet P3 is the same as packet P1 of the previous use-case. Indeed, domain D only considers the outer header when forwarding P3 and the outer header is: (SA=1, DA=9). As with packet P1, the entire journey of packet P3 is contained within source domain D.

Node 2 may thus rightfully insert an SRH on packet P3 to implement a sub-50 milliseconds FRR operation upon the loss of the link 2-to-3 and node 5 can remove this SRH.

The transparency of the service is guaranteed: the insertion and removal of the SRH on packet P3 has no impact on packet P2. P2 at the exit of the domain D is the same as at the entrance of the domain D.

Customers of the transit service offered by source domain D do demand FRR services. The 50 millisecond FRR operation provides a much better service availability than 100's to 1000's of milliseconds of loss for each routing transition.

4. Impact of SRH Insertion Within a Source Domain

This section discusses the impact of SRH insertion within a source domain for traffic transiting the source domain, or traffic generated within the source domain.

Any SRH inserted on a packet within a source domain MUST be removed before delivery to destination. This requirement ensures the destination node will not receive a packet with an SRH not inserted by the source SR Node. Therefore there is no impact of an inadvertent SRH being received at a destination node.

There are however two points of impact associated with ICMP error generation back to the source:

• Path MTU discovery [RFC8201] may generate ICMP error messages to the packet source.
• Hop Limit may be exhausted and generate ICMP error messages to the packet source.

4.1. ICMP Error message processing

Using the example packet P1 from Section 3. If Hop Limit decrements to 0 or a Packet Too Big (PTB) error is generated at node 4, after the SRH is inserted, the destination address in P1 is 5.

This results in an ICMP error message generated to node 1, as per [RFC4443] but with an unfamiliar destination address.

4.1.1. ICMP Error message processing with routing header

During parsing of the ICMP error message at node 1, the invoking packet's protocol receives the error. In the case of UDP and TCP, the invoking packet four-tuple (source address, source port, destination address, destination port) identifies a UDP or TCP session.

Since the original destination (node 9) is not the current destination of the invoking packet, the lookup cannot succeed in current implementations, and the error is not delivered to the source UDP or TCP session.

This is common for any use of routing headers regardless of whether a routing header is inserted at source or by an intermediate node.

4.2. Destination outside the Source Domain

Since the SRH inserted within an intermediate node MUST be removed when all segments within the SRH have been visited, it is not possible to leak the SRH to the destination outside the source domain.

5. Security Considerations

This document proposes to insert an SRH to a transit packet if such packet is originated and destined within a controlled/trusted domain.

Insertion of SRH is safe when confined within a source domain.

In such conditions, the security of the original packet is not compromised by header insertion. The packet reaches the destination or leaves the source domain without any inserted header.

A source domain can operate SRv6-based services for internal traffic while preventing any external traffic from accessing these internal SRv6-based services. Several mechanisms exists and are currently used today, for example:

• Access-lists (ACL) on the each externally facing interface in order to drop any incoming traffic with SA or DA belonging to the internal SID space.
• ACL to prevent access to local SIDs from outside the operator's infrastructure.
• Support Unicast-RPF on source address on external interface.

6. IANA Considerations

This document doesn't introduce any IANA request.

7. Manageability Considerations

TBD

8. Contributors

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

9. Acknowledgements

TBD

10. References

10.1. Normative References

10.2. Informative References

Authors' Addresses