说明：本文翻译自RFC 8754 IPv6 Segment Routing Header (SRH)，以用自学
摘要
分段路由可以使用一种称为分段路由头（SRH）的新型路由扩展头应用于IPv6数据平面。本文档描述SRH以及具有段路由（SR）功能的节点如何使用它。
1. 简介
可以使用称为段路由头（SRH）的新型路由头将段路由（SR）应用于IPv6数据平面。本文档介绍了SRH及其支持SR的节点如何使用SRH。
“段路由体系结构”RFC8402描述了段路由及其在两个数据平面中的实例化：MPLS和IPv6。
本文档中定义了SRH中IPv6段的编码。
1.1. 术语
本文档使用RFC8402中定义的术语段路由（SR），SR域，基于IPv6的SR（SRv6），段标识符（SID），SRv6SID，活动段和SR策略。
1.2. 需求语言
关键字“必须MUST”，“必须MUST NOT”，“必须REQUIRED”，“应SHALL”，“应不SHALL NOT”，“应SHOULD”，“不应SHOULD NOT”，“建议RECOMMENDED”，“不建议NOT RECOMMENDED”，“可以MAY”和“可选OPTIONAL”如此处所示，当且仅当本文档中它们以所有字母大写的情况出现时，才应按照BCP 14 RFC2119RFC8174中的说明来解释。
2. 段路由头
路由头在RFC8200中定义。段路由头（SRH）具有新的路由类型（4）。SRH的定义如下：
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 | Segment Left |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Last Entry | Flags | Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Segment List[0] (128-bit IPv6 address) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| |
. . .
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Segment List[n] (128-bit IPv6 address) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// //
// Optional Type Length Value objects (variable) //
// //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
其中：
Next Header：在RFC8200第4.4节中定义。
Hdr Ext Len：在RFC8200第4.4节中定义。
Routing Type：4。
Segments Left：在RFC8200第4.4节中定义。
Last Entry：在细分列表中包含细分列表最后一个元素的索引（从零开始）。
Flags：8位标志。第8.1节为要定义的新标志创建了IANA注册中心。定义了以下标志：
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|U U U U U U U U|
+-+-+-+-+-+-+-+-+
U：未使用和将来使用。传输时MUST为0，而在接收时则忽略。
Tag：将数据包标记为数据包类或数据包的一部分——例如，共享相同属性集的数据包。如果在源端不使用标签，则在传输时MUST将其设置为零。如果在SRH处理期间未使用标签，则SHOULD将其忽略。处理第4.3.1节中定义的SID时不使用标签。在处理本文档中未定义的其他SID时可以使用它。标签的分配和使用不在本文档的范围之内。
Segment List[0...n]：表示段列表中第n个段的128位IPv6地址。段列表是从SR策略的最后一个段开始编码的。也就是说，段列表的第一个元素（段列表[0]）包含SR策略的最后一个片段，第二个元素包含SR策略的倒数第二个片段，依此类推。
TLV：类型长度值（TLV）在第2.1节中描述。
在SRH中，RFC8200的第4.4节定义了“下一个报头”，“Hdr扩展长度”，“路由类型”和“左段”字段。基于该部分中的约束，“下一个报头”，“报头扩展名”和“路由类型”是不可变的，而“左段”是可变的。
TLV值的可变性由类型中的最高有效位定义，如第2.1节中所述。
第4.3节在本文档中定义的SID上下文中定义了SRH（标记，标签，段列表）中其余字段的可变性。
将来新定义的SID** MUST**指定Flags，Tag和Segment List的可变性属性，并指示哈希消息验证码（HMAC）TLV（第2.1.2节）验证的工作方式。注意，实际上，这些字段是可变的。
与SR模型相同，SRH的源始终知道如何设置SR域中使用的SRH的Segment List，Flags，Tag和TLV。它如何实现此目的超出了本文的范围，但是可能基于拓扑，可用的SID及其可变性属性，目标的SRH可变性要求或任何其他信息。
2.1. SRH****TLVs
本部分定义了段路由头的TLV。
TLV提供用于段处理的元数据。本文档中定义的唯一TLV是HMAC（第2.1.2节）和填充TLV（第2.1.1节）。在处理第4.3.1节中定义的SID时，除非本地配置另有说明（第4.3.1.1.1节），否则将忽略所有TLV。因此，对于任何实施方式，TLV和HMAC支持都是可选的。但是，添加或解析TLV的实现MUST支持PAD TLVs。其他文档可能会定义其他TLV和处理规则。
当Hdr Ext Len大于（Last Entry+1）*2时，将显示TLV。
在段端点处处理TLV时，TLV MUST完全包含在Hdr Ext Len确定的SRH中。检测到超出SRH Hdr Ext Len边界的TLV会导致ICMP参数问题代码0，向源地址发送消息，指向SRH的Hdr Ext Len字段，并且数据包被丢弃。
一个实现MAY根据本地配置限制它处理的TLVs的数量和/或长度。它MAY会限制：
- 连续的Pad1（第2.1.1.1节）选项的数量为1。如果需要填充一个以上的字节，则应使用PadN（第2.1.1.2节）。
- PadN中的长度为5。
- 待处理的非Pad TLVs的最大数量。
- 所有要处理的TLVs的最大长度。
当超过这些配置的限制时，实现MAY停止在SRH中处理其他TLV。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-----------------------
| Type | Length | Variable-length data
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-----------------------
Type：来自“段路由头TLV”IANA-SRHTLV的8位代码点。无法识别的类型在收到时MUST被忽略。
Length：可变长度数据字段的长度（以字节为单位）。
Variable-length data：类型专用的数据。
类型长度值（TLV）条目包含OPTIONAL信息，该信息可以由数据包的目标地址（DA）中标识的节点使用。
每个TLV都有自己的长度，格式和语义。（由IANA）分配给每个TLV类型的代码点定义了TLV中携带的信息的格式和语义。多个TLV可以在同一SRH中进行编码。
TLV类型的最高位（bit 0）指定该类型的TLV数据是否可以在到达数据包最终目的地的途中更改：
0：途中TLV数据不变
1：TLV数据在途中确实发生了变化
所有TLVs均使用xn+y格式指定其对齐要求。xn+y格式是根据RFC8200定义的。在构造SRH时，SR源节点使用TLV和填充TLV的xn+y对齐要求。
TLV的“长度”字段用于在检查SRH时跳过TLV，以防节点不支持或无法识别类型。长度以字节为单位定义TLV长度，不包括“类型”和“长度”字段。
本文档中定义了以下TLV：
Padding TLVs（填充TLV ）
HMAC TLV
将来可能会定义其他TLV。
2.1.1. 填充TLV
填充TLV有两种类型，Pad1和PadN，以下两种情况均适用：
填充TLV用于满足后续TLV的对齐要求。
填充TLV用于将SRH填充到8个八位字节的倍数。
填充TLV将被处理SRH TLV的节点忽略。
多个填充TLV MAY在一个SRH中使用。
2.1.1.1. Pad1
对齐要求：无
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Type |
+-+-+-+-+-+-+-+-+
Type：0
当需要单个填充字节时，MUST使用单个Pad1TLV。如果需要多个连续的填充字节，则MUST NOT使用Pad1TLV。
2.1.1.2. PadN
对齐要求：无
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Padding (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Padding (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type：4
Length：0到5。Padding字段的长度以字节为单位。
Padding：填充位没有语义。传输时MUST将其设置为0，而在接收时将其忽略。
当需要一个以上的填充字节时，MUST使用PadN TLV。
2.1.2. HMAC TLV
对齐要求：8n
密钥的哈希消息验证码（HMAC）TLV是OPTIONAL的，并且具有以下格式：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |D| RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HMAC Key ID (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| //
| HMAC (variable) //
| //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
其中：
Type：5
Length：可变长度数据的长度以字节为单位。
D：1bit。1表示由于使用了缩小的段列表，所以禁用了目标地址验证（请参阅第4.1.1节）。
RESERVED：15位。传输时MUST为0。
HMAC Key ID：一个4字节的不透明数字，唯一标识用于生成HMAC的预共享密钥和算法。
HMAC：密钥HMAC，以8个八位位组的倍数为单位，最多32个八位位组。
HMAC TLV用于验证授权方选择了应用于数据包的SRH，并确保在生成后未修改段列表。这也允许验证当前段（由于在授权段列表中）被授权使用。SR域通过BCP 84RFC3704中定义的入口过滤机制或其他适当策略，确保允许源节点使用数据包中的源地址。
2.1.2.1. HMAC生成和验证
本地配置确定何时检查HMAC。此本地配置超出了本文档的范围。它可能基于SR Segment端点节点上的活动网段，访问控制列表（ACL）的结果，其中考虑了传入接口，HMAC密钥ID或其他数据包字段。
根据本节其余部分的定义，支持HMAC生成和验证的实现支持以下默认行为。
HMAC验证开始于检查当前段是否等于IPv6标头的目标地址。在以下任一情况下检查成功：
HMACD位为1，且Segments Left大于Last Entry，或者
HMAC Left Segments小于或等于Last Entry，并且目的地址等于Segment List[Segments Left]。
HMAC字段是RFC2104中定义的HMAC计算的输出，使用：
key（密钥）：由HMAC密钥ID标识的预共享密钥
HMAC算法：由HMAC密钥ID标识
Text（文本）：来自IPv6标头和SRH的以下字段的串联，这将在验证HMAC的节点处接收到：
◦ IPv6 header：源地址（16八位位组）
◦ SRH：Last Entry（1八位位组）
◦ SRH：Flags（1八位位组）
◦ SRH：HMAC长度后16位
◦ SRH：HMAC Key ID（4八位位组）
◦ SRH：段列表中的所有地址（可变八位字节）
HMAC摘要被截断为32个八位位组，并放置在HMAC TLV的HMAC字段中。
对于产生长度少于32个八位位组摘要的HMAC算法，该摘要将放置在HMAC字段的最低阶八位位组中。后续字节必须设置为零，以使HMAC长度是8个字节的倍数。
如果HMAC验证成功，则处理将照常进行。
如果HMAC验证失败，则应生成ICMP错误消息（参数问题，错误代码0，指向HMAC TLV）并进行记录，但应丢弃该包。
2.1.2.2. HMAC预共享密钥算法
HMAC密钥ID字段允许同时存在多个哈希算法（SHA-256，SHA3-256...或将来的哈希算法）以及预共享密钥。
HMAC密钥ID字段是不透明的-即它既没有语法也没有语义，只是作为预共享密钥和哈希算法的正确组合的标识符。
在HMACTLV生成和验证节点上，密钥ID唯一标识预共享密钥和HMAC算法。
在HMACTLV生成节点上，将HMAC计算的文本设置为IPv6标头字段和SRH字段，因为它们将出现在验证节点上，而不必与发送带有HMACTLV的数据包的源节点相同。
通过在HMACTLV生成节点和验证节点收敛到新密钥的同时使用两个密钥ID，可以支持预共享密钥翻转。
HMACTLV生成节点可能需要撤销先前为其生成HMAC的SRH。通过分配新的密钥和密钥ID，然后在与要撤销的SRH相关联的密钥ID上滚动来实现撤销。HMACTLV验证节点丢弃具有已撤销SRH的数据包。
支持HMAC的实现可以支持多个哈希函数。支持HMAC的实现MUST以其SHA-256变体实现SHA-2FIPS180-4。
预共享密钥和算法及其分配的选择超出了本文档的范围。一些选项可能包括：
- 通过静态配置或任何面向SDN的方法在HMAC生成或验证节点的配置中设置这些项目
- 动态地使用受信任的密钥分发协议，例如RFC6407
尽管密钥管理不在本文档的范围之内，但是在选择密钥管理系统时应考虑BCP 107RFC4107的建议。
3. SR节点
段路由网络中可能涉及不同类型的节点：SR源节点（其始发具有IPv6标头的目标地址中的段的数据包），转发目的地为远程段的数据包的中转节点以及处理IPv6标头的目标地址中的本地段。
3.1. SR Source Node
SR源节点是任何在IPv6标头的目标地址中生成带有段（即SRv6 SID）的IPv6数据包的节点。离开SR源节点的数据包可能包含也可能不包含SRH。这包括：
- 发起IPv6数据包的主机，或
- SR域入口路由器将接收到的数据包封装在外部IPv6标头中，后跟可选的SRH。
描述通过其导出IPv6标头的目标地址中的段和SRH中的段列表的机制超出了本文档的范围。
3.2. Transit Node
传输节点是任何转发IPv6数据包的节点，其中该数据包的目标地址未在本地配置为网段或本地接口。不需要中转节点能够处理段或SRH。
3.3. SR Segment Endpoint Node
SR段端点节点是接收IPv6数据包的任何节点，其中该数据包的目标地址在本地配置为段或本地接口。
4. 数据包处理
本节描述了SR源，Transit和SR段端点节点上的SRv6数据包处理。
4.1. SR Source Node
源节点将数据包引导到SR策略中。如果SR策略导致包含单个段的段列表，则无需在SRH标志中添加信息或添加TLV；DA设置为单个Segment List条目，并且MAY省略SRH。
需要时，将按以下方式创建SRH：
Next Header和Hdr Ext Len字段的设置如RFC8200中所指定。
路由类型字段设置为4。
数据包的DA设置为first segment的值。
SRH Segment List的第一个元素是最终段。第二个元素是倒数第二个细分，依此类推。
Segments Left字段设置为n-1，其中n是SR策略中的元素数。
Last Entry字段设置为n-1，其中n是SR策略中的元素数。
TLVs（包括HMAC）可以根据其规范进行设置。
数据包被转发到数据包的目的地址（the first segment）。
4.1.1. 降低SRH
当源不要求将整个SID列表保留在SRH中时，可以使用简化的SRH。
精简的SRH不包含相关SR策略的第一部分（第一部分是IPv6标头的DA中已经存在的部分），并且Last Entry字段设置为n-2，其中n是SR政策中的元素数。
4.2. Transit Node
如RFC8200中所指定，唯一允许检查路由扩展头（以及SRH）的节点是与数据包的DA对应的节点。任何其他传输节点都MUST NOT检查下面的路由报头，并且MUST根据其IPv6路由表将数据包转发给DA。
当SID位于数据包的IPv6标头的目标地址中时，它将作为IPv6地址通过IPv6网络进行路由。SID或覆盖SID的前缀及其可达性可能会通过本文范围之外的方式进行分发。例如，RFC5308或RFC5340可用于通告覆盖节点上SID的前缀。
4.3. SR Segment Endpoint Node
在不限制实现细节的情况下，SR段端点节点为其本地SID创建转发信息库（FIB）条目。
当具有SRv6的节点接收到IPv6数据包时，它将在数据包的目标地址上执行最长前缀匹配查找。此查询可以返回以下任何内容：
代表本地实例化SRv6 SID的FIB条目
代表本地接口的FIB条目，未在本地实例化为SRv6 SID
表示非本地路由的FIB条目
没有匹配
4.3.1. FIB条目是本地实例化的SRv6 SID
本文档和本节定义单个SRv6 SID。将来的文档可能会定义其他SRv6 SID。在这种情况下，本节的全部内容将在该文档中定义。
如果FIB条目表示本地实例化的SRv6 SID，则按RFC8200的第4节中的定义处理IPv6标头的下一个标头链。第4.3.1.1节介绍了如何处理SRH；第4.3.1.2节介绍了如何处理上层报头或缺少下一个报头。
处理此SID会修改“Letf Segment”，如果配置为处理TLV，则可能会修改在途中更改的TLV类型的“可变长度数据”。因此，左段是可变的，并且在途中更改的TLV是可变的。在处理此SID时，其余的SRH（标记，标签，段列表和TLV在途中不会更改）是不可变的。
4.3.1.1. SRH处理
S01. When an SRH is processed {
S02. If Segments Left is equal to zero {
S03. Proceed to process the next header in the packet,
whose type is identified by the Next Header field in
the routing header.
S04. }
S05. Else {
S06. If local configuration requires TLV processing {
S07. Perform TLV processing (see TLV Processing)
S08. }
S09. max_last_entry = ( Hdr Ext Len / 2 ) - 1
S10. If ((Last Entry > max_last_entry) or
S11. (Segments Left is greater than (Last Entry+1)) {
S12. Send an ICMP Parameter Problem, Code 0, message to
the Source Address, pointing to the Segments Left
field, and discard the packet.
S13. }
S14. Else {
S15. Decrement Segments Left by 1.
S16. Copy Segment List[Segments Left] from the SRH to the
destination address of the IPv6 header.
S17. If the IPv6 Hop Limit is less than or equal to 1 {
S18. Send an ICMP Time Exceeded -- Hop Limit Exceeded in
Transit message to the Source Address and discard
the packet.
S19. }
S20. Else {
S21. Decrement the Hop Limit by 1
S22. Resubmit the packet to the IPv6 module for transmission
to the new destination.
S23. }
S24. }
S25. }
S26. }
4.3.1.1.1. TLV处理
当活动段是本文档中定义的本地SID时，本地配置确定如何处理TLV。本地配置的定义超出了本文档的范围。
仅出于说明目的，下面提供了可以与SID关联的两个示例本地配置。
Example 1:
For any packet received from interface I2
Skip TLV processing
Example 2:
For any packet received from interface I1
If first TLV is HMAC {
Process the HMAC TLV
}
Else {
Discard the packet
}
4.3.1.2. Upper-Layer Header or No Next Header
在处理与FIB条目匹配的数据包的上层标头时，该FIB条目在本地实例化为本文档中定义的SRv6SID：
IF (Upper-layer Header is IPv4 or IPv6) and
local configuration permits {
Perform IPv6 decapsulation
Resubmit the decapsulated packet to the IPv4 or IPv6 module
}
ELSE {
Send an ICMP parameter problem message to the Source Address and
discard the packet. Error code (4) "SR Upper-layer
Header Error", pointer set to the offset of the upper-layer
header.
}
唯一的错误代码允许SR源节点在端点上的SID处理中识别错误。
4.3.2. FIB条目是本地接口
如果FIB条目表示本地接口，并且未在本地实例化为SRv6 SID，则SRH的处理如下：
如果Segments Left为零，则节点必须忽略路由头，并继续处理数据包中的下一个头， 其类型由路由头中的Next Header字段标识。
如果Segments Left为非零值，则该节点必须丢弃该数据包，并向该数据包的“源地址” 发送“ICMP参数问题代码0消息，指向无法识别的路由类型。
4.3.3. FIB进入是非本地路线
该文档未更改处理。
4.3.4. FIB条目不匹配
该文档未更改处理。
5. SR内域部署模型
重要的部署模型是，仅在SR域内且仅对SR域的数据包使用SID。
这使SR域可以充当单个路由系统。
本节内容包括：
保护SR域免受外部尝试使用其SID的侵害
将SR域用作具有组件之间委派的单个系统
处理SR域的数据包
5.1. 保护SR域
SR域之外的节点不受信任：它们不能直接使用域的SID。这由访问控制列表的两个级别强制执行：
-
任何进入SR域并发往SR域内SID的数据包都将被丢弃。这可以通过以下逻辑来实现。结果相同的其他方法也被认为是合规的：
◦ 分配块S/s中的所有SID
◦ 使用入站基础结构访问列表（IACL）配置域的每个边缘节点的每个外部接口，该列表将丢弃目标地址为S/s的任何传入数据包
◦ 如RFC5095中所描述和引用的那样，未能实现这种入口过滤方法会使SR域遭受源路由攻击。
-
＃1中的分布式保护与每个节点保护相辅相成，将数据包从SR域之外的源地址丢弃到SID。这可以通过以下逻辑来实现。结果相同的其他方法也被认为是合规的：
◦ 从前缀A/a分配所有接口地址
◦ 在节点k，从前缀Sk/sk分配k的所有本地SID。
◦ 使用入站IACL配置SR域中每个SR节点k的每个内部接口，如果源地址不在A/a中，则该IACL将丢弃目标地址在Sk/sk中的所有传入数据包。
5.2. SR域作为具有组件之间委派的单个系统
所有SR域内数据包均属于SR域。IPv6标头由SR域的节点发起，并发往SR域的节点。
对于SR域内的部分数据包行程，将对所有域间数据包进行封装。外部IPv6标头由SR域的节点发起，并发往SR域的节点。
结果，SR域内的任何数据包都属于SR域。
SR域是一个系统，在该系统中，操作员可能希望将最外层标头的不同操作分配或委派给系统内的不同节点。
SR域的运营商可以选择将SRH添加到SR域内的主机节点，并将任何SRH内容的验证委派给与主机连接的更受信任的路由器或交换机。考虑通过接口I连接到主机H的架顶式交换机T。H通过本文档范围之外的某些SDN方法接收带有计算的HMAC的SRH（SRH1）。H对来源的流量进行分类，并将SRH1添加到需要特定服务水平协议（SLA）的流量中。T在I上配置了IACL，要求对发往SR域（S/s）的SID块的任何数据包进行SRH验证。T检查并确认SRH1有效并包含HMAC TLV；然后，T验证HMAC。
SR域的运营商可以选择让SR域中的所有段都验证HMAC。此机制将验证遍历SR域时未修改SRH段列表。
5.3. MTU注意事项
SR域入口边缘节点封装了穿越SR域的数据包，并且需要考虑SR域的MTU。在SR域内，建议采用众所周知的缓解技术，例如，在SR域内比在入口边缘部署更大的MTU值。
使用外部IPv6标头和SRH进行封装与RFC2473中描述的IPv6隧道具有相同的MTU和分段注意事项。在INTAREA-TUNNELS中讨论了对各种隧道方法（包括IPv6隧道）的限制的进一步研究，运营商在考虑SR域内的MTU时应考虑采用这种方法。
5.4. ICMP错误处理
SR域内生成的ICMP错误数据包将发送到SR域内的源节点。ICMP错误消息中的调用数据包可能包含SRH。由于带有SRH的数据包的目标地址随着每个段的处理而变化，因此它可能不是生成调用数据包的套接字或应用程序使用的目标地址。
为了使调用数据包的源能够处理ICMP错误消息，可能需要IPv6标头的最终目标地址。以下逻辑用于确定协议错误处理程序使用的目标地址。
-
将调用IPv6数据包的所有扩展标头移到上层标头之前的路由扩展标头。
◦ 如果路由标头是类型4段路由标头（SRH）
▪ 段列表[0]处的SID可以用作调用分组的目的地地址。
然后，ICMP错误由RFC4443中定义的上层传输处理。
对于封装在外部IPv6标头中的IP数据包，ICMP错误处理如RFC2473中所定义。
5.5. 负载均衡****和ECMP
对于任何域间包，SR源节点MUST施加基于内部包计算的流标签。流标签的计算如RFC6438中关于发送隧道端点的建议。
对于任何域内数据包，SR源节点都SHOULD施加流标签，如RFC6437中所述，该流标签应在无法计算超出SRH的5元组的传输节点处辅助ECMP负载平衡。
在SR域内的任何传输节点上，都MUST按照RFC6438的定义使用流标签来计算朝向目标地址的ECMP哈希。如果未使用流标签，则传输节点可能会将一对SR Edge节点之间的所有数据包散列到同一链路。
在SR网段端点节点上，必须按照RFC6438的定义使用流标签来计算用于将已处理的数据包转发到下一个网段的任何ECMP哈希。
5.6. 其他部署
其他部署模型及其对安全性，MTU，HMAC，ICMP错误处理以及与其他扩展标头的交互的含义不在本文档的范围之内。
6. 插图
本节说明了SR源，中转和SR段端点节点上的SRv6数据包处理。
6.1. SRH的抽象表示
对于节点k，其IPv6地址表示为Ak，其SRv6 SID表示为Sk。
IPv6标头表示为（source，destination）的元组。例如，将具有源地址A1和目标地址A2的数据包表示为（A1，A2）。分组的有效载荷被省略。
SR策略是细分列表。段的列表表示为
（SA，DA）（S3，S2，S1；SL）表示具有以下内容的IPv6数据包：
源地址SA，目标地址DA和下一个标头SRH。
SID列表为
注意<>和（）符号之间的区别。
在其SR策略头端，段列表
Segments Left=2
Last Entry=2
Flags=0
Tag=0
Segment List[0]=S3
Segment List[1]=S2
Segment List[2]=S1
6.2. 拓扑示例
以下示例中使用了以下拓扑：
+ * * * * * * * * * * * * * * * * * * * * +
* [8] [9] *
| |
* | | *
[1]----[3]--------[5]----------------[6]---------[4]---[2]
* | | *
| |
* | | *
+--------[7]-------+
* *
+ * * * * * * * SR domain * * * * * * * +
图1
- 3和4是SR域边缘路由器
- 5、6和7都是SR域路由器
- 8和9是SR域内的主机
- 1和2是SR域之外的主机
- SR域根据第5.1节实现入口过滤，并且任何外部数据包都不能以目标地址等于该域的一部分的形式进入该域。
6.3. SR源节点
6.3.1. SR域内数据包
当主机8通过SR策略
6.3.1.1. 减少变体
当主机8通过SR策略
6.3.2. Inter-SR-Domain Packet--Transit
当主机1向主机2发送数据包时，该数据包为
SR域入口路由器3接收P3，并通过SR策略
如果SR策略仅包含一个网段（出口路由器4），则入口路由器3将P3封装到没有SRH的外部报头（A3，S4）中。包是
6.3.2.1. 减少变体
SR域入口路由器3接收P3，并通过SR策略
6.3.3. SR间域数据包-内部到外部
当主机8将数据包发送到主机1时，该数据包将在SR域中对其行程的一部分进行封装。从8到3
在相反的方向上，从1到8生成的数据包是
在节点3处，P8封装了其在SR域内的行程部分，外部标头指定为段S8。这导致
在节点8，外部IPv6标头通过S8处理除去，然后在被A8接收时再次处理。
6.4. 运输节点
节点5充当数据包P1的传输节点并发送数据包
在指向节点7的接口上。
6.5. SR段端点节点
节点7接收数据包P1，并使用第4.3.1节中的逻辑发送数据包
在通往路由器6的接口上。
6.6. HMAC验证的功能委派
本节介绍如何在SR域内委派功能。在以下各节中，请考虑连接到机架5顶部的主机8。
6.6.1. SID列表验证
运营商可能更喜欢在源8处应用SRH，而5则验证SID列表有效。
出于说明目的，SDN控制器提供了一个在节点9终止的SRH，其中段列表
节点8使用接收到的SRH（包括HMACTLV）发起数据包。
节点5接收并验证SRH的HMAC，然后将数据包转发到下一个网段
节点6接收
节点9接收
HMAC的这种使用在基于企业的SR域SRN中特别有价值。
7. 安全注意事项
考虑到本文档中讨论的SRH处理和部署模型，本节将回顾与SRH相关的安全注意事项。
如第5节所述，有必要过滤发往SR域内SID（即，在目标地址中带有SID）的SR域的数据包进入。通过SR域入口边界节点上的IACL进行入口过滤。通过在每个SR网段端点节点上的IACL应用额外的保护，过滤不是来自SR域内，发往SR域中SID的数据包。少量很少更改的前缀很容易支持ACL，因此摘要很重要。
另外，应该使用BCP 38RFC2827中推荐的IPv6源地址的入口过滤。
7.1. SR攻击
SR域实现了5.1节中所述的分布式和按节点保护。此外，域通过实施BCP 84RFC3704中的建议来拒绝具有欺骗性地址的流量。
完全实施建议的保护措施，可以阻止SR域之外的RFC5095中记录的攻击，包括绕过过滤设备，到达否则无法访问的Internet系统，网络拓扑发现，带宽耗尽以及阻止任播。
未能实施分布式保护和按节点保护，攻击者将绕过过滤设备并使SR域暴露于这些攻击中。
SR域中受损的节点可能会在IP网络上发起上面列出的攻击以及其他已知攻击（例如DoS/DDoS，拓扑发现，中间人，流量拦截/虹吸）。
7.2. 服务盗窃
服务盗窃定义为未经授权使用服务的节点对SR域提供的服务的使用。
SR域内的服务盗窃不是问题，因为域内的所有SR源节点和SR段终结点节点都能够利用域的服务。如果SR域外部的节点获悉SR域中的网段或拓扑服务，则IACL过滤会拒绝访问这些网段。
7.3. 拓扑暴力
SRH是未加密的，并且可能包含指向SR域内到目的地的路径中的某些中间SR节点的SID。如果可以在SR域内侦听数据包，则SRH可能会显示拓扑，业务流和服务使用情况。
这适用于SR域，但是由于攻击者具有其他了解拓扑，流量和服务使用情况的方式，因此本公开内容的相关性较低。
7.4. ICMP生成
通过在背对背数据包中发送导致错误的目标地址或SRH，ICMPv6错误消息的生成可用于尝试拒绝服务攻击。正确遵循RFC4443第2.4节的实现将受到ICMPv6速率限制机制的保护。
7.5. AH的适用性
SR域是可信域，如RFC8402第2和8.2节中所定义。信任SR源添加一个SRH（可选地验证为已由可信源通过本文档中的HMAC TLV生成），并且信任域中发布的段是准确的，并由信任源通过安全控制平面发布。因此，SR域不依赖RFC4302中定义的身份验证标头（AH）来保护SRH。
在本文档中未定义SR源节点对AH使用AH以及在SR段终结点节点上对其进行处理。将来的文档可能会定义SRH与AH的结合使用及其处理方式。
8. IANA注意事项
本文档在IANA维护的“Internet协议版本6（IPv6）参数”“路由类型”子注册表中进行了以下注册：
| Value | Description | Reference |
|---|---|---|
| 4 | Segment Routing Heade r(SRH) | This document |
表1：SRH注册
本文档在IANA维护的“Internet控制消息协议版本6（ICMPv6）参数”注册表的“类型4-参数问题”消息中进行了以下注册：
| Code | Name |
|---|---|
| 4 | SR Upper-layer Header Error |
表2：SR上层报头错误注册
8.1. 段路由标头标志注册表
本文档介绍了一个新的IANA管理的注册表，用于标识SRH标志位。注册过程为“IETF审查”RFC8126。注册表名称是“段路由标头标志”。标志是8位。
8.2. 段路由标题TLVs注册表
本文档介绍了一个新的IANA管理的注册表，用于标识SRHTLV。注册过程为“IETF审查”。注册表名称是“段路由头TLV”。通过无符号的8位代码点值来标识TLV，对于在途中不变的TLV，分配值是0-127，对于在途中可能变动的TLV，分配值是128-255。本文档中定义了以下代码点：
| Value | Description | Reference |
|---|---|---|
| 0 | Pad1 TLV | This document |
| 1 | Reserved | This document |
| 2 | Reserved | This document |
| 3 | Reserved | This document |
| 4 | Pad NTLV | This document |
| 5 | HMAC TLV | This document |
| 6 | Reserved | This document |
| 124-126 | Experimentation and Test | This document |
| 127 | Reserved | This document |
| 252-254 | Experimentation and Test | This document |
| 255 | Reserved | This document |
表3：段路由头TLV注册表
值1、2、3和6在此规范的草稿版本中定义，保留这些值是为了与早期实现向后兼容，因此不应重新分配。如果需要，保留值127和255，以允许在将来的规范中扩展“类型”字段。