L                                                                 H. Jie
Internet-Draft                                           ZTE Corporation
Intended status: Standards Track                        October 29, 2020
Expires: May 2, 2021


             An Enhanced Source Routing Header Based on RH3
            draft-han-6man-enhanced-source-routing-header-00

Abstract

   IPv6 Routing header type 3 (termed as RH3) is defined and used in
   Low-Power and Lossy Networks (LLNs) that are typically constrained in
   resources (limited communication data rate, processing power, energy
   capacity, memory).  Based on the mechanisms introduced by RH3, this
   document specifies an new IPv6 Routing Header type that provides
   encapsulation capability of segments with various lengths and can be
   applied to more scenarios.

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 May 2, 2021.

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



Jie                        Expires May 2, 2021                  [Page 1]


Internet-Draft       Enhanced Source Routing Header         October 2020


   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Requirements Language . . . . . . . . . . . . . . . . . . . .   2
   3.  Format of the Source Routing Header . . . . . . . . . . . . .   3
   4.  Format of the Enhanced Source Routing Header  . . . . . . . .   3
   5.  Generating E-SRH  . . . . . . . . . . . . . . . . . . . . . .   6
   6.  Processing E-SRH  . . . . . . . . . . . . . . . . . . . . . .   7
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   9
   9.  Normative References  . . . . . . . . . . . . . . . . . . . .   9
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  10

1.  Introduction

   Routing headers are defined in [RFC8200].  [RFC6554] specifies the
   Source Routing Header (SRH), i.e., IPv6 Routing header type 3 (termed
   as RH3), for use strictly between RPL routers in the Low-Power and
   Lossy Networks (LLNs) [RFC6550], which are typically constrained in
   resources (limited communication data rate, processing power, energy
   capacity, memory).  It introduces mechanisms to compact the source
   route entries when all entries share the same prefix with the IPv6
   Destination Address of a packet carrying an RH3, a typical scenario
   in LLNs using source routing.  The compaction mechanism reduces
   consumption of scarce resources such as channel capacity.  However,
   it is challenging when all entries do not have the same prefix, for
   example, only a part of entries share the same prefix, but still want
   to encode all routries in a single routing header and reduce the
   overhead.

   This document specifies an enhanced Source Routing Header (termed as
   E-SRH) to enhance the encapsulation capability of segments with
   various lengths and attempt to apply to more scenarios that using
   source routing mechanism.

2.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in BCP
   14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.






Jie                        Expires May 2, 2021                  [Page 2]


Internet-Draft       Enhanced Source Routing Header         October 2020


3.  Format of the Source Routing Header

   The Source Routing Header defined in [RFC6554] has the following
   format:

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |  Next Header  |  Hdr Ext Len  | Routing Type  | Segments Left |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | CmprI | CmprE |  Pad  |               Reserved                |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       .                                                               .
       .                        Addresses[1..n]                        .
       .                                                               .
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                  Figure 1: Source Routing Header format

   Where CmprI, CmprE, and Pad fields allow compaction of the
   Address[1..n] vector when all entries share the same prefix as the
   IPv6 Destination Address field of the packet carrying the RH3.  The
   CmprI and CmprE fields indicate the number of prefix octets that are
   shared with the IPv6 Destination Address of the packet carrying the
   RH3.  The shared prefix octets are not carried within the Routing
   header and each entry in Address[1..n-1] has size (16 - CmprI) octets
   and Address[n] has size (16 - CmprE) octets.

4.  Format of the Enhanced Source Routing Header

   To provide the encapsulation capability of segments with various
   lengths, this section defines the Enhanced Source Routing Header
   (E-SRH).  The basic idea is to place the CmprI or CmprE information
   with each segment element.  The E-SRH has the following format:














Jie                        Expires May 2, 2021                  [Page 3]


Internet-Draft       Enhanced Source Routing Header         October 2020


        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |  Next Header  |  Hdr Ext Len  | Routing Type  | Segments Left |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |    List Len   |         Offset        |        Reserved       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |  Type | Cmpr  |           Segment 1          //
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       // Type | Cmpr  |           Segment 2          //
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       //                    ... ...                  //
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       // Type | Cmpr  |           Segment N          //
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       //                          Padding                             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       //                                                             //
       //         Optional Type Length Value objects (variable)       //
       //                                                             //
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


              Figure 2: Enhanced Source Routing Header format

   where:

   Next Header: Defined in [RFC8200], Section 4.4.  It identifies the
   type of header immediately following the Routing header.

   Hdr Ext Len: Defined in [RFC8200], Section 4.4.  It represents the
   length of the Routing header in 8-octet units, not including the
   first 8 octets.

   Routing Type: TBA.

   Segments Left: Defined in [RFC8200], Section 4.4.  It represents the
   number of route segments remaining, i.e., number of explicitly listed
   intermediate nodes still to be visited before reaching the final
   destination.  Note that it represents the count of intermediate
   nodes, instead of the count of segments always in constant 128-bit
   units in the routing header.  Both this document and [RFC6554] may
   take segments less than 128 bits, for example, 32 bits, in the
   routing header.

   List Len: 8-bit unsigned integer.  It represents the length of the
   Segment List field in 8-octet units.  Note that the size of the
   entire Segment List must be aligned to 8 bytes.  For this purpose, it



Jie                        Expires May 2, 2021                  [Page 4]


Internet-Draft       Enhanced Source Routing Header         October 2020


   may be necessary to pad meaningless zeros after the last segment
   (i.e., segment N).  List Len field must be less than Hdr Ext Len, or
   equal to Hdr Ext Len when E-SRH does not contain optional TLVs.

   Offset: 12-bit unsigned integer.  It represents the index of
   currently active segment in segment list, when the segment list
   contained in E-SRH is regarded as an array in bytes.  When an element
   in a segment list array is accessed according to Offset field, its
   access range must not exceed the range represented by List Len * 8.

   Reserved: This field is unused.  It MUST be initialized to zero by
   the sender and MUST be ignored by the receiver.

   Each <Type, Cmpr, Segment> tuple provide the information of each
   segment element in the segment list, and it has variable length.

   Type: 4 bits.  It represents the type of the segment.  The following
   types are defined:

      0: Indicates that the corresponding Segment field is a complete
      IPv6 address.  Note that the corresponding Segment field does not
      necessarily occupy 16 bytes, and its length is given by Cmpr
      field.  This is because the low-order position of many IPv6
      addresses is 0, and it is not necessary to store the entire 16
      bytes in the Segment field.

      1: Indicates that the corresponding Segment field is 1-octet of
      IPv6 address fragment.  Similar with [RFC6554], the value of
      Segment field can be stiched with the prefix contained in the IPv6
      Destination Address to form a complete IPv6 address.  The Cmpr
      field indicates the number of prefix octets that are shared with
      the IPv6 Destination Address.  For the stiched IPv6 address, the
      high-order position is the prefix, immediately preceding the value
      of the Segment field, and the low-order position is filled with
      zeros.

      2: Indicates that the corresponding Segment field is 2-octet of
      IPv6 address fragment.  The stiching method is the same as Type-1.

      3: Indicates that the corresponding Segment field is 3-octet of
      IPv6 address fragment.  The stiching method is the same as Type-1.

      4: Indicates that the corresponding Segment field is 4-octet of
      IPv6 address fragment.  The stiching method is the same as Type-1.

      5: Indicates that the corresponding Segment field is 5-octet of
      IPv6 address fragment.  The stiching method is the same as Type-1.




Jie                        Expires May 2, 2021                  [Page 5]


Internet-Draft       Enhanced Source Routing Header         October 2020


      6: Indicates that the corresponding Segment field is 6-octet of
      IPv6 address fragment.  The stiching method is the same as Type-1.

      7: Indicates that the corresponding Segment field is 7-octet of
      IPv6 address fragment.  The stiching method is the same as Type-1.

      8: Indicates that the corresponding Segment field is 8-octet of
      IPv6 address fragment.  The stiching method is the same as Type-1.

      9: Indicates that the corresponding Segment field is 3-octet of
      MPLS Label.  The MPLS Label can be mapped to a complete IPv6
      address.

      10: Indicates that the corresponding Segment field is 4 bytes of
      SID index([RFC8402]).  The index can be mapped to a complete IPv6
      address.

      11: Indicates that the corresponding Segment field is 4 bytes of
      BIER index([RFC8279]).  The index can be mapped to a complete IPv6
      address.

      15: Indicates that the corresponding Segment field is an argument
      that is used by the previous Segment element in E-SRH.  The
      segment's length is given by Cmpr field.

   Cmpr: 4 bits.  It represents the length of the prefix in octet units
   for Type-1 to Type-8.  For Type-0, it represents the actual length of
   the Segment field, For Type-9 and Type-10, it has no meaning and can
   be set to 0.

   Segment: Represents the nth segment in the Segment List.  Similar
   with [RFC6554], the Segment List is encoded in E-SRH in positive
   order.  The Segment field has variable length.

   Padding: Optional padding field immediately following Segment N
   field.  It is used to pad the Segment List to a multiple of 8 octets.
   If the Segment List is already 8-byte aligned, there is no need to
   have a Padding field.

   Optional TLVs: To be defined in future.

5.  Generating E-SRH

   For a segment list <S1, S2, S3,..., Sn>, the headend can encode it in
   E-SRH.  S1 is placed to DA field of IPv6 header, and S1 to Sn can be
   also placed in the Segment 1 to Segment N fields respectively.
   Because S1 is also placed in the Segment 1 field, Offset field needs
   to be set to the value that point to <Type, Cmpr, Segment 2> tuple,



Jie                        Expires May 2, 2021                  [Page 6]


Internet-Draft       Enhanced Source Routing Header         October 2020


   i.e., Offset = sizeof <Type, Cmpr, Segment 1>.  In addition, Segment
   Left field is set to n-1, which means there are n-1 Segments left to
   be processed in the Segment List.

   For the above segment list <S1, S2, S3,..., Sn>, the headend may not
   place S1 in E-SRH again, then E-SRH only needs to contain n-1
   segments.  In this case, S2 to Sn will be placed in the Segment 1 to
   Segment N-1 fields respectively.  Offset needs to be set to the value
   that point to <Type, Cmpr, Segment 1>, i.e., Offset = 0.  In
   addition, Segment Left field is still set to n-1, which means there
   are n-1 segments left to be processed in the Segment List.

6.  Processing E-SRH

   E-SRH is examined and processed when the IPv6 packet reaches the node
   identified in the Destination Address field of the IPv6 header.  In
   that node, dispatching on the Next Header field of the immediately
   preceding header causes the Routing header module to be invoked.

   The following describes the algorithm performed when processing an
   E-SRH:

     If next argument item is needed in the current segment processing {
       Read the next <Type, Cmpr, Segment> tuple which is pointed by
       current Offset field:
         Type 15(Arg), Segment's length is determined by Cmpr field;

       If Type is not 15 {
         Send an ICMP Parameter Problem, Code 0, message to the Source
         Address, pointing to the Offset field, and discard the packet;
       }

       Offset += sizeof (next <Type, Cmpr, Segment>);
       if Offset > List Len * 8 {
         Send an ICMP Parameter Problem, Code 0, message to the Source
         Address, pointing to the Offset field, and discard the packet;
       }

       Continues the remaining processing of the current element with
       additional aruguments (note: long argument if necessary, instead
       of using multiple arguments);
     }

     if Segments Left = 0 {
       proceed to process the next header in the packet, whose type is
       identified by the Next Header field in the Routing header;
     }
     else {



Jie                        Expires May 2, 2021                  [Page 7]


Internet-Draft       Enhanced Source Routing Header         October 2020


       Read the next <Type, Cmpr, Segment> tuple which is pointed by
       current Offset field, in detailed:
         For Type 0, Segment's length is determined by Cmpr field;
         For Type 1-8, Segment's length is 1-8 bytes respectively;
         For Type 9(MPLS), Segment's length is 3 bytes;
         For Type 10-11(index), Segment's length is 4 bytes;

       If Type is 15 or unknown {
         Send an ICMP Parameter Problem, Code 0, message to the Source
         Address, pointing to the Offset field, and discard the packet;
       }

       Offset += sizeof (next <Type, Cmpr, Segment>);

       if Offset > List Len * 8 {
         Send an ICMP Parameter Problem, Code 0, message to the Source
         Address, pointing to the Offset field, and discard the packet;
       }

       decrement Segments Left by 1;
       Copy the stiched/mapped IPv6 address to the destination address
       of the IPv6 header;

       if the IPv6 Hop Limit is less than or equal to 1 {
         send an ICMP Time Exceeded -- Hop Limit Exceeded in Transit
         message to the Source Address and discard the packet;
       }
       else {
         decrement the Hop Limit by 1;
         resubmit the packet to the IPv6 module for transmission to the
         new destination;
       }
     }

7.  Security Considerations

   The E-SRH domain is treated as a trusted domain, and the nodes
   outside the E-SRH domain are not trusted.  This is enforced by two
   levels of access control lists:

      On the ingress of E-SRH domain, any packet entering the E-SRH
      domain and destined to an IPv6 address within the E-SRH domain, is
      dropped.

      On the transit or egress of E-SRH domain, any packet with a
      destination address within the E-SRH domain but the source address
      not within, is dropped.




Jie                        Expires May 2, 2021                  [Page 8]


Internet-Draft       Enhanced Source Routing Header         October 2020


   It will block the attacks documented in [RFC5095] from outside the
   E-SRH domain, including bypassing filtering devices, reaching
   otherwise-unreachable Internet systems, network topology discovery,
   bandwidth exhaustion, and defeating anycast.

   Additionally, domains deny traffic with spoofed addresses by
   implementing the recommendations in BCP 84 [RFC3704].

   [RFC6554] requires RPL routers to check for loops in the SRH and drop
   datagrams that contain such loops.  However, for the flexibility of
   Segment List programming for any scenario, E-SRH doesn't do this
   check, but relevant security mechanisms to avoid tampering with
   Segment List should be adopted, such as HMAC mechanism introduced in
   [RFC8754].

   The generation of ICMPv6 error messages may be used to attempt
   denial-of-service attacks by sending an error-causing E-SRH in back-
   to-back datagrams.  An implementation that correctly follows
   Section 2.4 of [RFC4443] would be protected by the ICMPv6 rate-
   limiting mechanism.

8.  Acknowledgements

   TBD

9.  Normative References

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

   [RFC3704]  Baker, F. and P. Savola, "Ingress Filtering for Multihomed
              Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704, March
              2004, <https://www.rfc-editor.org/info/rfc3704>.

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

   [RFC5095]  Abley, J., Savola, P., and G. Neville-Neil, "Deprecation
              of Type 0 Routing Headers in IPv6", RFC 5095,
              DOI 10.17487/RFC5095, December 2007,
              <https://www.rfc-editor.org/info/rfc5095>.





Jie                        Expires May 2, 2021                  [Page 9]


Internet-Draft       Enhanced Source Routing Header         October 2020


   [RFC6550]  Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J.,
              Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur,
              JP., and R. Alexander, "RPL: IPv6 Routing Protocol for
              Low-Power and Lossy Networks", RFC 6550,
              DOI 10.17487/RFC6550, March 2012,
              <https://www.rfc-editor.org/info/rfc6550>.

   [RFC6554]  Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6
              Routing Header for Source Routes with the Routing Protocol
              for Low-Power and Lossy Networks (RPL)", RFC 6554,
              DOI 10.17487/RFC6554, March 2012,
              <https://www.rfc-editor.org/info/rfc6554>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

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

   [RFC8279]  Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A.,
              Przygienda, T., and S. Aldrin, "Multicast Using Bit Index
              Explicit Replication (BIER)", RFC 8279,
              DOI 10.17487/RFC8279, November 2017,
              <https://www.rfc-editor.org/info/rfc8279>.

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

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

Author's Address

   Han Jie
   ZTE Corporation
   China

   Email: han.jie1@zte.com.cn






Jie                        Expires May 2, 2021                 [Page 10]