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]