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 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 , 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 tuple, Jie Expires May 2, 2021 [Page 6] Internet-Draft Enhanced Source Routing Header October 2020 i.e., Offset = sizeof . 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 , 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 , 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 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 ); 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 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 ); 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, . [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704, March 2004, . [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, . [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, . 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, . [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, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, . [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, . [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, . [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, . Author's Address Han Jie ZTE Corporation China Email: han.jie1@zte.com.cn Jie Expires May 2, 2021 [Page 10]