Skip to main content

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

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Authors Daniel Voyer , Clarence Filsfils , Darren Dukes , Satoru Matsushima , John Leddy
Last updated 2019-09-20 (Latest revision 2019-07-08)
RFC stream (None)
Formats
Additional resources
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-voyer-6man-extension-header-insertion-07

   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]