Deterministic Source Route Header
draft-p-6man-deterministic-eh-01
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
Document | Type | Active Internet-Draft (individual) | |
---|---|---|---|
Author | Shaofu Peng | ||
Last updated | 2024-10-10 | ||
RFC stream | (None) | ||
Intended RFC status | (None) | ||
Formats | |||
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-p-6man-deterministic-eh-01
Network Shaofu. Peng Internet-Draft ZTE Corporation Intended status: Standards Track 11 October 2024 Expires: 14 April 2025 Deterministic Source Route Header draft-p-6man-deterministic-eh-01 Abstract This document introduces a new IPv6 Routing Header that is a variant of RPL Source Route Header (SRH) and used for deterministic forwarding wihch is generally a strict explicit path. This Routing Header contains the decoupled topology instructions and deterministic forwarding resource indications. The target is low cost of encapasultion and less amount of allocated SIDs. 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 14 April 2025. Copyright Notice Copyright (c) 2024 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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Peng Expires 14 April 2025 [Page 1] Internet-Draft Deterministic Source Route Header October 2024 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 2. The Source Route Headers for DetNet (DetNet SRH) . . . . . . 3 3. Processing Rules . . . . . . . . . . . . . . . . . . . . . . 8 3.1. Processing on the Headend Node . . . . . . . . . . . . . 8 3.2. Processing on the Transit or Endpoint Node . . . . . . . 10 4. Other Design Considerations . . . . . . . . . . . . . . . . . 11 4.1. Heterogeneous Segment List . . . . . . . . . . . . . . . 11 4.2. Packet Parsing by Offline Tool . . . . . . . . . . . . . 12 4.3. ICMP Error Processing . . . . . . . . . . . . . . . . . . 12 4.4. Upper-Layer Checksums . . . . . . . . . . . . . . . . . . 12 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 8.1. Normative References . . . . . . . . . . . . . . . . . . 14 8.2. Informative References . . . . . . . . . . . . . . . . . 15 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16 1. Introduction [RFC8655] describes the architecture of Deterministic Networking (DetNet) and defines the QoS goals: Minimum and maximum end-to-end latency from source to destination, timely delivery, and bounded jitter (packet delay variation); packet loss ratio under various assumptions as to the operational states of the nodes and links; an upper bound on out-of-order packet delivery. In order to achieve these goals, DetNet use resource reservation, explicit routing, service protection and other means. In general, the strictly explicit path is calculated by the centralized controller. There is such a need that metadata related to each hop used to provide DetNet QoS needs to be carried in the packet to avoid network core maintenance flow states and meet large scaling requirements. [RFC8200] defines the Routing Header. The source node of the IPv6 packet can include some segment information in the Routing Header to control the packet's access to these segments before reaching the final destination node. How to reduce the cost of Routing Header, especially in scenarios with strict explicit deterministic forwarding paths, is a concern. Generally, there are two categories of optimization methods. One is to use short indexes to map to IPv6 addresses, and the other is to rely on a common prefix for all segments. For example, [RFC9631] defines two new routing headers called CRH-16 and CRH-32, containing a short index for mapping to 128-bit IPv6 addresses, and retrieving all forwarding information from the CRH-FIB entries matched by the index. And, [RFC6554] Peng Expires 14 April 2025 [Page 2] Internet-Draft Deterministic Source Route Header October 2024 defines RPL Source Route Header (SRH), where only the different parts of each segment need to be stored in the segment list, and the common prefix of all elements is stored in the Destination Address field of the IPv6 header. [I-D.ietf-spring-srv6-srh-compression] also describes another common prefixes based compression method suitable for SRv6 network. To meet the requirement of deterministic forwarding, [I-D.pb-6man-deterministic-crh] defines an Routing Header based on short index optimization category, that is a variant of CRH and termed as CRH-20. This document continue to introduce another Routing Header based on common prefix category, as a variant of RPL SRH and termed as DetNet SRH. DetNet SRH inherits the idea of RPL SRH relying completely on the packet itself to provide encapsulation knowledge, which is beneficial in many scenarios. DetNet SRH contains the decoupled topology instructions and deterministic forwarding resource indications. Here, the decoupled means that the SIDs for topology instructions and resource indications for DetNet QoS are defined, signaled in control plane or forwarded in data plane, independently. Considering that there are many resource types and the huge amount of resource instances supported by each type, this document does not recommend distinguishing different resource instances by allocating different SIDs. The target of DetNet SRH is low cost of encapasultion and less amount of SIDs. 1.1. 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. 2. The Source Route Headers for DetNet (DetNet SRH) Peng Expires 14 April 2025 [Page 3] Internet-Draft Deterministic Source Route Header October 2024 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |iES|nES| RT |P| Common RI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Segments j+2 ~ n ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MBZ |CmprL|R| Individual RI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SID j+1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |nES| MBZ | Individual RI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ SID j (128-bit) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SID j-1 |CmprL|R| Individual RI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Segments i+2 ~ j-2 ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SID i+1 |CmprL|R| Individual RI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |nES| MBZ | Individual RI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ SID i (128-bit) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SID i-1 |CmprL|R| Individual RI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Segments 2 ~ i-2 ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SID 1 |CmprL|R| Individual RI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: DetNet SRH Format DetNet SRH contains the following fields: * Next Header: Defined in [RFC8200]. * Hdr Ext Len: Defined in [RFC8200]. * Routing Type: TBA for DetNet SRH. Peng Expires 14 April 2025 [Page 4] Internet-Draft Deterministic Source Route Header October 2024 * Segments Left: Represents how many units of 4-octets remain to be processed. Typically, the length of each segment element (including topology instruction and resource indication) is 4 octets. However, segment elements with larger lengths (resulting in lower compression efficiency) may also exist in the DetNet SRH segment list as needed. * Type-specific Data: Described in [RFC8200]. In the DetNet SRH, the Type-specific data field contains topology instructions and forwarding resource indications. In detailed: * iES (initial Element Style): 2 bits for the strcuture style of the first segment element actually stored in the DetNet SRH segment list. 4 styles are defined as below: - 0: termed as style-0, the structure of the segment element is <SID(128), nES(2), MBZ(18), Individual RI(12)>, which occupies 5 units. For example, in Figure 1, the style of segment element i or j is style-0. - 1: termed as style-1, the structure of the segment element is <SID(16), CmprL(3), R(1), Individual RI(12)>, which occupies 1 unit. For example, in Figure 1, the styles of segment elements 1 to i-1 are all style-1. - 2: termed as style-2, the structure of the segment element is <SID(20), CmprL(3), R(1), Individual RI(8)>, which occupies 1 unit. For example, in Figure 1, the styles of segment elements i+1 to j-1 are all style-2. - 3: termed as style-3, the structure of the segment element is <SID(32), MBZ(16), CmprL(3), R(1), Individual RI(12)>, which occupies 2 units. For example, in Figure 1, the styles of segment elements j+1 to n are all style-3. * nES (next Element Style): 2 bits for the strcuture style of the next segment element. The header.nES field indicates the style of the next segment element of the active segment, while the style-0 element.nES field indicates the style of the next segment element in the DetNet SRH segment list. * RT (Resource Type): 3 bits for the forwarding resource types. The following only defines the corresponding resource types for DetNet queueing mechanisms that need specify different resources per hop. Peng Expires 14 April 2025 [Page 5] Internet-Draft Deterministic Source Route Header October 2024 - 0: undefined. In this case, Common RI field and Individual RI fields may also be 0 and ignored during forwarding procedure of the packet, or other values used for user defined purposes. - 1: Indicates that the forwarding resources is timeslot resources. [I-D.peng-detnet-packet-timeslot-mechanism] defines the Timeslot Queueing and Forwarding (TQF) mechanism that can be used in IP/MPLS network. Timeslot resources are defined as multiple equally time slots contained within a fixed length of periodic time (known as orchestration period). Different nodes interoperate on the same orchestration period, but for the same orchestration period, different nodes may configure different timeslot lengths. In this case, Common RI field contains orchestration period length (OPL) information, and Individual RI field contains the specific timeslot for the corresponding segment. - 2: Indicates that the forwarding resources is delay resources. [I-D.peng-detnet-deadline-based-forwarding] defines the Earliest Deadline First (EDF) mechanism that can be used in IP/ MPLS network. The network may provide multiple delay levels each ensuring a bounded latency according to the schedulability condition of EDF. In this case, Common RI field contains the latency deviation (E) value which is dynamically changed per hop, and Individual RI field contains the planned residence time (D) for the corresponding segment. All segments may have the same planned residence time (D) by evenly dividing the total residence time budget, but this is not mandatory. - 3: Indicates that the forwarding resources is damper resources. [ATS_Damper] or [I-D.eckert-detnet-glbf] defines the damper mechanism that can be used in IP/MPLS network. It actually combines two sub-functions: the worst-case latency guarantee component (e.g., ATS) and the damper component. In this case, Common RI field contains the damper delay (D) value which is dynamically changed per hop, and Individual RI field contains the worst-case latency (M) for the corresponding segment. All segments may have the same worst-case latency (M), but this is not the often case because the admitted flow aggregation of each traffic class at different hop may be different. Peng Expires 14 April 2025 [Page 6] Internet-Draft Deterministic Source Route Header October 2024 - 4: Indicate that forwarding resources is network slice resources, also known as Network Resource Partition (NRP) resources. [I-D.ietf-teas-ns-ip-mpls] defines a network slicing mechanism in IP/MPLS network. The physical network may be partitioned into multiple slices dedicated to specific services or customers. It is possible to directly reuse network slices to get DetNet QoS. In this case, Common RI field contains the default NRP-ID, and Individual RI field contains the overrided NRP-ID when necessary. - Other types may be defined in the future. * P (Pad) flag: 1 bit to indicate whether there are padding field. If P flag is 0, there are no padding. If P flag is 1, there are padding with 4 bytes. * Common RI (Resource Indication): 24 bits for the common forwarding resource information that all segments shared. The information contained in Common RI depends on RT. Please see the above explanation of Resource Type field. * SID (Segment Identifier): 16 bits (for style-1), or 20 bits (for style-2), or 32 bits (for style-3), or 128 bits (for style-0), for the topology instruction used to forward packets to specific outgoing interface. * MBZ (Must Be Zero): used to match the length of segment element to a multiple of units. * CmprL (Common Prefix Length): 3 bits for the indication of common prefix length that is shared by multiple segments. This document recommend supporting only a few typical lengths, such as 4 to 10 bytes. This field is only included in style-1, 2, 3, since style-0 element contains the complete 128 bits address. The compaction rule of the complete 128 bits address based on CmprL is defined as below: - If CmprL is zero, the address is Common_Prefix::SID. That is, the SID is placed in the least significant bits of the address. - If CmprL is non zero, the common prefix length equals to CmprL + 3, and the address is Common_Prefix:SID::. That is, the SID is placed behind common prefix in the most significant bits of the address. Peng Expires 14 April 2025 [Page 7] Internet-Draft Deterministic Source Route Header October 2024 * R (Revert) flag: 1 bit to indicate whether the style of the next segment element will revert back to style-0. If R flag is 0, the next segment element's style remains unchanged from the current element's style, otherwise, it will revert back to style-0. * Individual RI (Resource Indication): 8 bits (for style-2), or 12 bits (for style-0, 1, 3), for the forwarding resource that is specific for the individual segment. The information contained in Individual RI depends on RT. Please see the above explanation of Resource Type field. * Padding: 0 or 4 bytes to ensure 8-octet alignment. In DetNet SRH, each segment is constructed by one or more units of 4-octets. Segments are listed in reverse order. So, the first segment in the DetNet SRH list represents the final interface in the path. Because segments are listed in reverse order, the Segments Left field can be used as an index into the segment list. The first segment in the path can be omitted from the list. 3. Processing Rules 3.1. Processing on the Headend Node The headend node is responsible for encapsulating the DetNet SRH for the packet. For a logical Segment List <S1, S2, ..., Sn>, set the topology instructions and resource information corresponding to each segment in DetNet SRH. According to the compaction result of the logical Segment List, set iES, nES, RT, P and Common RI fields in the header, set CmprL and R fields for style-1, 2, 3 segment elements, and set nES field for style-0 elements. Typically, a single style, e.g., style-1, may be used, and all segment elements in the DetNet SRH segment list will be encapsulated using that style. In this case, the R flag of all segment elements is set to 0, because there is no style switching. If there are multiple styles used, as shown in Figure 1, the R flag or nES field of each segment element will be set to indicate the style of the next segment element. For example, the R flag of segment element i-1 is TRUE, indicating that the style of the next segment element will revert back to style-0; The nES field of segment element i is 2, indicating that the style of the next segment element will be switched to style-2; The nES of segment element j is 3, indicating that the style of the next segment element will be switched to style-3. Peng Expires 14 April 2025 [Page 8] Internet-Draft Deterministic Source Route Header October 2024 A single style is common in intra-domain scenarios, while multiple styles are usually occurs in inter-domain cases (in which case the common prefix, or the common prefix length, or the length of compressed SID used in each domain may be different). The header.iES field is set to the style of the first segment element that is actually placed in DetNet SRH segment list. The first segment element may be the first logical segment S1, or may be the second logical segment S2 if S1 is not stored in DetNet SRH. iES will never be changed on the journey of the packet forwarding. The header.nES field is set to the style of the second logical segment S2. If there is no S2 in the logical segment list, it must be set to style-0. In one implementation, the header.nES field may also be set based on the R flag or nES field of the first logical segment S1 (although S1 itself may not be actually included in DetNet SRH). Namely: If S1 is not style-0: - If S1.R equals to 0, header.nES = S1.style; - If S1.R equals to 1, header.nES = style-0; If S1 is style-0, header.nES = S1.nES; RT, Common RI, and Individual RI are set based on the type of resource that the packet wants to consume. For example of timeslot based TE path, RT is set to 1 (timeslot resource type), Common RI is set to orchestration period length, and each Individual RI is set to the timeslot id that is reserved for the flow. If DetNet SRH segment list is aligned with 8 bytes, then the Padding field is empty, and the P flag is set to 0; Otherwise, the Padding field has 4 bytes, and the P flag is set to 1. For each non style-0 segment element, its ComprL field is set according to the above compaction rule. Copy the complete 128 bit IPv6 address related to the first logical segment S1 to the DA field of the IPv6 header. Calculate the number of units of the compressed segment list (excluding the first logical segment S1), and set the Segment Left field to that number. Peng Expires 14 April 2025 [Page 9] Internet-Draft Deterministic Source Route Header October 2024 In one implementation, the Segment Left field may also be set based on the style the first logical segment S1 (although S1 itself may not be actually included in DetNet SRH). Namely: Calculate the number of units of the compressed segment list, e.g., m. If the style of S1 is style-0, then SL = m - 5; If the style of S1 is style-1,2, then SL = m - 1; If the style of S1 is style-3, then SL = m - 2; In order to further save the cost of DetNet SRH, because the destination IPv6 address corresponding to the first logical segment S1 has already been copied to the DA field of the IPv6 header, the headend node may exclude the first logical segment S1 from the DetNet SRH segment list. Note that this attempting to reduce overhead may not make sense due to the need for 8-octet alignment. The headend must ensure that when forwarding packets to the first logical segment S1, it consume the forwarding resources associated with S1. Especially for the resources provided by EDF or damper mechanisms, the common RI field is set when the packet leaves the queue. 3.2. Processing on the Transit or Endpoint Node When a transit or endpoint node receives an IPv6 packet, if the DA in the IPv6 header matches the local IP address, and the Next Header field of the IPv6 header indicates that the next layer header is DetNet SRH, then continue to process DetNet SRH as below: Peng Expires 14 April 2025 [Page 10] Internet-Draft Deterministic Source Route Header October 2024 S01. When a DetNet SRH is processed { S02. if (Segments Left == 0) { S03. Stop processing the DetNet SRH, and proceed to process the next header in the packet, whose type is identified by the Next Header field in the routing header. S04. } S05. if (IPv6 Hop Limit <= 1) { S06. Send an ICMP Time Exceeded message to the Source Address with Code 0 (Hop limit exceeded in transit), interrupt packet processing, and discard the packet. S07. } S08. Decrement IPv6 Hop Limit by 1 S09. Decrement Segments Left by 1 S10. Read the the next segment from Segment List[Segments Left] (i.e., read 1 unit when SRH.nES is style-1,2, or read 2 units and subtract Segment Left by 1 again when SRH.nES is style-3, or read 5 units and subtract Segment Left by 4 again when SRH.nES is style-0). S11. Update the DA field of the IPv6 header based on the next segment read (i.e., DA = common_prefix:SID:: or common_prefix::SID for next non style-0 segment, or DA = SID for next style-0 segment). S12. Update SRH.nES based on the next segment read (i.e., for next non style-0 segment, if R flag is zero, SRH.nES remains unchanged, otherwise SRH.nES is changed to style-0; for next style-0 segment, SRH.nES = segment.nES.). } S13. Submit the packet to the egress IPv6 FIB lookup for transmission to the new destination, and, consume the forwarding resource indicated by Common RI field and Individual RI field of the next segment read. Especially for the resources provided by EDF or damper mechanisms, the common RI field is set when the packet leaves the queue. S14. } 4. Other Design Considerations 4.1. Heterogeneous Segment List DetNet SRH can support a combination of various type of segments in a single Segment List to reduce encapsulation size. This can be used in scenarios that an E2E Segment List may across multiple domains and each domain has different common prefix. In this case, a style-0 segment element may be inserted in the DetNet SRH Segment List, to provide new prefix information for the next domain. Peng Expires 14 April 2025 [Page 11] Internet-Draft Deterministic Source Route Header October 2024 4.2. Packet Parsing by Offline Tool DetNet SRH is friendly to offline tool parsing of packet and does not rely on FIB states maintained on network nodes to provide encapsulation knowledge of the packet. Following this principle is beneficial, otherwise, an asynchronous FIB state, that may be updated, deleted, or occasionally mismatched, may provide unexpected compaction length information of each segment field, and result in a failure to obtain the correct segment list. The length of the DetNet SRH segment list can be obtained based on Hdr Ext Len and P flag, to locate the first actually stored segment element. Then, the iTS field indicate the style and number of units of the first segment element. Using the R flag or nES of the first segment element, the style and number of units of the second segment element can be obtained, and so on. 4.3. ICMP Error Processing The invoking packet in the ICMP error message may contain an DetNet SRH. Since the destination address of a packet with an DetNet SRH changes as each segment is processed, it may not be the destination used by the socket or application that generated the invoking packet. For the source of an invoking packet to process the ICMP error message, the ultimate destination address of the IPv6 header may be required. The following logic is used to determine the destination address for use by protocol-error handlers. Walk all extension headers of the invoking IPv6 packet to the routing extension header preceding the upper-layer header. - If routing header is type DetNet SRH o Walk to the last segment element which may be used as the destination address of the invoking packet. 4.4. Upper-Layer Checksums [RFC8200] specifies that any transport or other upper-layer protocol that includes the addresses from the IP header in its checksum computation must be modified for use over IPv6, to include the 128-bit IPv6 addresses. If the IPv6 packet contains a Routing header, the Destination Address used in the pseudo-header is that of the final destination. At the originating node, that address will be in the last element of the Routing header; at the recipient(s), that address will be in the Destination Address field of the IPv6 header. Peng Expires 14 April 2025 [Page 12] Internet-Draft Deterministic Source Route Header October 2024 For DetNet SRH, at the originating node, the Destination Address field in the pseudo-header will be the last segment that is before compaction; At the recipient(s), that address will be naturally restored and placed in the Destination Address field of the IPv6 header; And, at the midpoint, the final address can also be retrieved by parsing the DetNet SRH segment list. 5. IANA Considerations This document request to register the following in the "Routing Types" subregistry within the "Internet Protocol Version 6 (IPv6) Parameters" registry: +==========+=============+===============+ | Value | Description | Reference | +==========+=============+===============+ | TBA | DetNet SRH | this document | +----------+-------------+---------------+ 6. Security Considerations The DetNet SRH domain is treated as a trusted domain, and the nodes outside the DetNet SRH domain are not trusted. This is enforced by two levels of access control lists: On the ingress of DetNet SRH domain, any packet entering the DetNet SRH domain and destined to an IPv6 address within the DetNet SRH domain, is dropped. On the transit or egress of DetNet SRH domain, any packet with a destination address within the DetNet SRH domain but the source address not within, is dropped. It will block the attacks documented in [RFC5095] from outside the DetNet 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, DetNet 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]. Peng Expires 14 April 2025 [Page 13] Internet-Draft Deterministic Source Route Header October 2024 The generation of ICMPv6 error messages may be used to attempt denial-of-service attacks by sending an error-causing DetNet 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. 7. Acknowledgements TBD 8. References 8.1. Normative References [I-D.eckert-detnet-glbf] Eckert, T. T., Clemm, A., Bryant, S., and S. Hommes, "Deterministic Networking (DetNet) Data Plane - guaranteed Latency Based Forwarding (gLBF) for bounded latency with low jitter and asynchronous forwarding in Deterministic Networks", Work in Progress, Internet-Draft, draft-eckert- detnet-glbf-03, 5 July 2024, <https://datatracker.ietf.org/doc/html/draft-eckert- detnet-glbf-03>. [I-D.ietf-teas-ns-ip-mpls] Saad, T., Beeram, V. P., Dong, J., Wen, B., Ceccarelli, D., Halpern, J. M., Peng, S., Chen, R., Liu, X., Contreras, L. M., Rokui, R., and L. Jalil, "Realizing Network Slices in IP/MPLS Networks", Work in Progress, Internet-Draft, draft-ietf-teas-ns-ip-mpls-04, 28 May 2024, <https://datatracker.ietf.org/doc/html/draft-ietf- teas-ns-ip-mpls-04>. [I-D.peng-detnet-deadline-based-forwarding] Peng, S., Du, Z., Basu, K., cheng, Yang, D., and C. Liu, "Deadline Based Deterministic Forwarding", Work in Progress, Internet-Draft, draft-peng-detnet-deadline- based-forwarding-12, 8 August 2024, <https://datatracker.ietf.org/doc/html/draft-peng-detnet- deadline-based-forwarding-12>. [I-D.peng-detnet-packet-timeslot-mechanism] Peng, S., Liu, P., Basu, K., Liu, A., Yang, D., and G. Peng, "Timeslot Queueing and Forwarding Mechanism", Work in Progress, Internet-Draft, draft-peng-detnet-packet- timeslot-mechanism-09, 12 August 2024, <https://datatracker.ietf.org/doc/html/draft-peng-detnet- packet-timeslot-mechanism-09>. Peng Expires 14 April 2025 [Page 14] Internet-Draft Deterministic Source Route Header October 2024 [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>. [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>. [RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas, "Deterministic Networking Architecture", RFC 8655, DOI 10.17487/RFC8655, October 2019, <https://www.rfc-editor.org/info/rfc8655>. [RFC9631] Bonica, R., Kamite, Y., Alston, A., Henriques, D., and L. Jalil, "The IPv6 Compact Routing Header (CRH)", RFC 9631, DOI 10.17487/RFC9631, August 2024, <https://www.rfc-editor.org/info/rfc9631>. 8.2. Informative References Peng Expires 14 April 2025 [Page 15] Internet-Draft Deterministic Source Route Header October 2024 [ATS_Damper] "Constant Delay Switching: Asynchronous Traffic Shaping with Jitter Control", 2022, <https://ieeexplore.ieee.org/document/9829777>. [I-D.ietf-spring-srv6-srh-compression] Cheng, W., Filsfils, C., Li, Z., Decraene, B., and F. Clad, "Compressed SRv6 Segment List Encoding", Work in Progress, Internet-Draft, draft-ietf-spring-srv6-srh- compression-18, 22 July 2024, <https://datatracker.ietf.org/doc/html/draft-ietf-spring- srv6-srh-compression-18>. [I-D.pb-6man-deterministic-crh] Peng, S. and R. Bonica, "Deterministic Routing Header", Work in Progress, Internet-Draft, draft-pb-6man- deterministic-crh-00, 29 February 2024, <https://datatracker.ietf.org/doc/html/draft-pb-6man- deterministic-crh-00>. [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 Shaofu Peng ZTE Corporation China Email: peng.shaofu@zte.com.cn Peng Expires 14 April 2025 [Page 16]