[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07

Network Working Group                                      D. Voyer, Ed.
Internet-Draft                                               Bell Canada
Intended status: Standards Track                             C. Filsfils
Expires: March 23, 2020                                    D. Dukes, Ed.
                                                     Cisco Systems, Inc.
                                                           S. Matsushima
                                                                Softbank
                                                                J. Leddy
                                                  Individual Contributor
                                                      September 20, 2019


    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 [RFC2119].

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




Voyer, et al.            Expires March 23, 2020                 [Page 1]


Internet-Draft                SRH Insertion               September 2019


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






Voyer, et al.            Expires March 23, 2020                 [Page 2]


Internet-Draft                SRH Insertion               September 2019


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

   o  3 and 4 are SR Domain edge routers

   o  5, 6, 7, and 8 are all SR Domain routers

   o  1 and 2 are hosts outside the SR Domain



Voyer, et al.            Expires March 23, 2020                 [Page 3]


Internet-Draft                SRH Insertion               September 2019


   o  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)








Voyer, et al.            Expires March 23, 2020                 [Page 4]


Internet-Draft                SRH Insertion               September 2019


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




Voyer, et al.            Expires March 23, 2020                 [Page 5]


Internet-Draft                SRH Insertion               September 2019


   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.





Voyer, et al.            Expires March 23, 2020                 [Page 6]


Internet-Draft                SRH Insertion               September 2019


   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.




Voyer, et al.            Expires March 23, 2020                 [Page 7]


Internet-Draft                SRH Insertion               September 2019


   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:

   o  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)



Voyer, et al.            Expires March 23, 2020                 [Page 8]


Internet-Draft                SRH Insertion               September 2019


   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.




Voyer, et al.            Expires March 23, 2020                 [Page 9]


Internet-Draft                SRH Insertion               September 2019


             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



Voyer, et al.            Expires March 23, 2020                [Page 10]


Internet-Draft                SRH Insertion               September 2019


   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

   [I-D.ietf-6man-segment-routing-header]
              Filsfils, C., Dukes, D., Previdi, S., Leddy, J.,
              Matsushima, S., and d. daniel.voyer@bell.ca, "IPv6 Segment
              Routing Header (SRH)", draft-ietf-6man-segment-routing-
              header-22 (work in progress), August 2019.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC2473]  Conta, A. and S. Deering, "Generic Packet Tunneling in
              IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473,
              December 1998, <https://www.rfc-editor.org/info/rfc2473>.

   [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>.

   [RFC8200]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", STD 86, RFC 8200,
              DOI 10.17487/RFC8200, July 2017,
              <https://www.rfc-editor.org/info/rfc8200>.





Voyer, et al.            Expires March 23, 2020                [Page 11]


Internet-Draft                SRH Insertion               September 2019


   [RFC8402]  Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
              Decraene, B., Litkowski, S., and R. Shakir, "Segment
              Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
              July 2018, <https://www.rfc-editor.org/info/rfc8402>.

9.2.  Informative References

   [I-D.ietf-rtgwg-segment-routing-ti-lfa]
              Litkowski, S., Bashandy, A., Filsfils, C., Decraene, B.,
              Francois, P., daniel.voyer@bell.ca, d., Clad, F., and P.
              Camarillo, "Topology Independent Fast Reroute using
              Segment Routing", draft-ietf-rtgwg-segment-routing-ti-
              lfa-01 (work in progress), March 2019.

   [I-D.ietf-spring-segment-routing-policy]
              Filsfils, C., Sivabalan, S., daniel.voyer@bell.ca, d.,
              bogdanov@google.com, b., and P. Mattes, "Segment Routing
              Policy Architecture", draft-ietf-spring-segment-routing-
              policy-03 (work in progress), May 2019.

   [I-D.ietf-spring-srv6-network-programming]
              Filsfils, C., Camarillo, P., Leddy, J.,
              daniel.voyer@bell.ca, d., Matsushima, S., and Z. Li, "SRv6
              Network Programming", draft-ietf-spring-srv6-network-
              programming-01 (work in progress), July 2019.

   [I-D.matsushima-spring-srv6-deployment-status]
              Matsushima, S., Filsfils, C., Ali, Z., and Z. Li, "SRv6
              Implementation and Deployment Status", draft-matsushima-
              spring-srv6-deployment-status-01 (work in progress), May
              2019.

Authors' Addresses

   Daniel Voyer (editor)
   Bell Canada

   Email: daniel.voyer@bell.ca


   Clarence Filsfils
   Cisco Systems, Inc.
   Brussels
   BE

   Email: cfilsfil@cisco.com





Voyer, et al.            Expires March 23, 2020                [Page 12]


Internet-Draft                SRH Insertion               September 2019


   Darren Dukes (editor)
   Cisco Systems, Inc.
   Ottawa
   Canada

   Email: ddukes@cisco.com


   Satoru Matsushima
   Softbank

   Email: satoru.matsushima@g.softbank.co.jp


   John Leddy
   Individual Contributor
   USA

   Email: john@leddy.net
































Voyer, et al.            Expires March 23, 2020                [Page 13]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/