Independent Submission F. Templin, Ed.
Request for Comments: 5320 Boeing Research & Technology
Category: Experimental February 2010
ISSN: 2070-1721
Independent Submission F. Templin, Ed.
Request for Comments: 5320 Boeing Research & Technology
Category: Experimental February 2010
ISSN: 2070-1721
The Subnetwork Encapsulation and Adaptation Layer (SEAL)
子网封装和适配层（密封）
Abstract
摘要
For the purpose of this document, subnetworks are defined as virtual topologies that span connected network regions bounded by encapsulating border nodes. These virtual topologies may span multiple IP and/or sub-IP layer forwarding hops, and can introduce failure modes due to packet duplication and/or links with diverse Maximum Transmission Units (MTUs). This document specifies a Subnetwork Encapsulation and Adaptation Layer (SEAL) that accommodates such virtual topologies over diverse underlying link technologies.
在本文档中，子网络定义为虚拟拓扑，跨越由封装边界节点限定的连接网络区域。这些虚拟拓扑可能跨越多个IP和/或子IP层转发跃点，并且可能由于分组复制和/或具有不同最大传输单元（MTU）的链路而引入故障模式。本文件规定了一个子网封装和适配层（SEAL），该层通过不同的底层链路技术容纳此类虚拟拓扑。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
本文件不是互联网标准跟踪规范；它是为检查、实验实施和评估而发布的。
This document defines an Experimental Protocol for the Internet community. This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文档为互联网社区定义了一个实验协议。这是对RFC系列的贡献，独立于任何其他RFC流。RFC编辑器已选择自行发布此文档，并且未声明其对实现或部署的价值。RFC编辑批准发布的文件不适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5320.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc5320.
IESG Note
IESG注释
This RFC is not a candidate for any level of Internet Standard. The IETF disclaims any knowledge of the fitness of this RFC for any purpose and in particular notes that the decision to publish is not based on IETF review for such things as security, congestion control, or inappropriate interaction with deployed protocols. The RFC Editor has chosen to publish this document at its discretion. Readers of this document should exercise caution in evaluating its value for implementation and deployment. See RFC 3932 for more information.
本RFC不适用于任何级别的互联网标准。IETF不承认本RFC适用于任何目的的任何知识，特别注意到，发布决定并非基于IETF对安全、拥塞控制或与已部署协议的不当交互等事项的审查。RFC编辑已自行决定发布本文件。本文档的读者在评估其实施和部署价值时应谨慎。有关更多信息，请参阅RFC 3932。
Copyright Notice
版权公告
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2010 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
Table of Contents
目录
1. Introduction ....................................................4
1.1. Motivation .................................................4
1.2. Approach ...................................................6
2. Terminology and Requirements ....................................6
3. Applicability Statement .........................................7
4. SEAL Protocol Specification - Tunnel Mode .......................8
4.1. Model of Operation .........................................8
4.2. ITE Specification .........................................10
4.2.1. Tunnel Interface MTU ...............................10
4.2.2. Accounting for Headers .............................11
4.2.3. Segmentation and Encapsulation .....................12
4.2.4. Sending Probes .....................................14
4.2.5. Packet Identification ..............................15
4.2.6. Sending SEAL Protocol Packets ......................15
4.2.7. Processing Raw ICMPv4 Messages .....................15
4.2.8. Processing SEAL-Encapsulated ICMPv4 Messages .......16
4.3. ETE Specification .........................................17
4.3.1. Reassembly Buffer Requirements .....................17
4.3.2. IPv4-Layer Reassembly ..............................17
4.3.3. Generating SEAL-Encapsulated ICMPv4
Fragmentation Needed Messages ......................18
4.3.4. SEAL-Layer Reassembly ..............................19
4.3.5. Delivering Packets to Upper Layers .................20
5. SEAL Protocol Specification - Transport Mode ...................20
6. Link Requirements ..............................................21
7. End System Requirements ........................................21
8. Router Requirements ............................................21
9. IANA Considerations ............................................21
10. Security Considerations .......................................21
11. Related Work ..................................................22
12. SEAL Advantages over Classical Methods ........................22
13. Acknowledgments ...............................................24
14. References ....................................................24
14.1. Normative References .....................................24
14.2. Informative References ...................................24
Appendix A. Historic Evolution of PMTUD ...........................27
Appendix B. Reliability Extensions ................................29
1. Introduction ....................................................4
1.1. Motivation .................................................4
1.2. Approach ...................................................6
2. Terminology and Requirements ....................................6
3. Applicability Statement .........................................7
4. SEAL Protocol Specification - Tunnel Mode .......................8
4.1. Model of Operation .........................................8
4.2. ITE Specification .........................................10
4.2.1. Tunnel Interface MTU ...............................10
4.2.2. Accounting for Headers .............................11
4.2.3. Segmentation and Encapsulation .....................12
4.2.4. Sending Probes .....................................14
4.2.5. Packet Identification ..............................15
4.2.6. Sending SEAL Protocol Packets ......................15
4.2.7. Processing Raw ICMPv4 Messages .....................15
4.2.8. Processing SEAL-Encapsulated ICMPv4 Messages .......16
4.3. ETE Specification .........................................17
4.3.1. Reassembly Buffer Requirements .....................17
4.3.2. IPv4-Layer Reassembly ..............................17
4.3.3. Generating SEAL-Encapsulated ICMPv4
Fragmentation Needed Messages ......................18
4.3.4. SEAL-Layer Reassembly ..............................19
4.3.5. Delivering Packets to Upper Layers .................20
5. SEAL Protocol Specification - Transport Mode ...................20
6. Link Requirements ..............................................21
7. End System Requirements ........................................21
8. Router Requirements ............................................21
9. IANA Considerations ............................................21
10. Security Considerations .......................................21
11. Related Work ..................................................22
12. SEAL Advantages over Classical Methods ........................22
13. Acknowledgments ...............................................24
14. References ....................................................24
14.1. Normative References .....................................24
14.2. Informative References ...................................24
Appendix A. Historic Evolution of PMTUD ...........................27
Appendix B. Reliability Extensions ................................29
As Internet technology and communication has grown and matured, many techniques have developed that use virtual topologies (including tunnels of one form or another) over an actual network that supports the Internet Protocol (IP) [RFC0791][RFC2460]. Those virtual topologies have elements that appear as one hop in the virtual topology, but are actually multiple IP or sub-IP layer hops. These multiple hops often have quite diverse properties that are often not even visible to the endpoints of the virtual hop. This introduces failure modes that are not dealt with well in current approaches.
随着互联网技术和通信的发展和成熟，许多技术已经发展起来，在支持互联网协议（IP）[RFC0791][RFC2460]的实际网络上使用虚拟拓扑（包括各种形式的隧道）。这些虚拟拓扑的元素在虚拟拓扑中显示为一个跃点，但实际上是多个IP或子IP层跃点。这些多个跃点通常具有各种各样的属性，这些属性甚至对虚拟跃点的端点都不可见。这引入了在当前方法中未得到很好处理的故障模式。
The use of IP encapsulation has long been considered as the means for creating such virtual topologies. However, the insertion of an outer IP header reduces the effective path MTU as-seen by the IP layer. When IPv4 is used, this reduced MTU can be accommodated through the use of IPv4 fragmentation, but unmitigated in-the-network fragmentation has been found to be harmful through operational experience and studies conducted over the course of many years [FRAG][FOLK][RFC4963]. Additionally, classical path MTU discovery [RFC1191] has known operational issues that are exacerbated by in-the-network tunnels [RFC2923][RFC4459]. In the following subsections, we present further details on the motivation and approach for addressing these issues.
长期以来，IP封装的使用一直被认为是创建此类虚拟拓扑的手段。然而，外部IP报头的插入减少了IP层看到的有效路径MTU。当使用IPv4时，可以通过使用IPv4分段来适应这种减少的MTU，但通过多年的运营经验和研究发现，未经缓解的网络分段是有害的[FRAG][FOLK][RFC4963]。此外，经典路径MTU发现[RFC1191]已知网络隧道[RFC2923][RFC4459]中的操作问题会加剧。在以下小节中，我们将进一步详细介绍解决这些问题的动机和方法。
Before discussing the approach, it is necessary to first understand the problems. In both the Internet and private-use networks today, IPv4 is ubiquitously deployed as the Layer 3 protocol. The two primary functions of IPv4 are to provide for 1) addressing, and 2) a fragmentation and reassembly capability used to accommodate links with diverse MTUs. While it is well known that the addressing properties of IPv4 are limited (hence, the larger address space provided by IPv6), there is a lesser-known but growing consensus that other limitations may be unable to sustain continued growth.
在讨论方法之前，有必要首先了解问题。在当今的互联网和私人使用网络中，IPv4作为第3层协议被广泛部署。IPv4的两个主要功能是提供1）寻址和2）用于容纳不同MTU的链路的分段和重组功能。众所周知，IPv4的寻址特性是有限的（因此，IPv6提供了更大的地址空间），但有一种鲜为人知但日益增长的共识，即其他限制可能无法维持持续增长。
First, the IPv4 header Identification field is only 16 bits in length, meaning that at most 2^16 packets pertaining to the same (source, destination, protocol, Identification)-tuple may be active in the Internet at a given time. Due to the escalating deployment of high-speed links (e.g., 1Gbps Ethernet), however, this number may soon become too small by several orders of magnitude. Furthermore, there are many well-known limitations pertaining to IPv4 fragmentation and reassembly -- even to the point that it has been deemed "harmful" in both classic and modern-day studies (cited above). In particular, IPv4 fragmentation raises issues ranging from
首先，IPv4报头标识字段的长度仅为16位，这意味着在给定时间，最多有2^16个属于相同（源、目标、协议、标识）元组的数据包在Internet中处于活动状态。然而，由于高速链路（如1Gbps以太网）的部署不断升级，这一数字可能很快就会变得太小几个数量级。此外，IPv4碎片化和重组存在许多众所周知的局限性——甚至在经典和现代研究中都被认为是“有害的”（如上所述）。特别是，IPv4碎片化引发了以下问题：
minor annoyances (e.g., slow-path processing in routers) to the potential for major integrity issues (e.g., mis-association of the fragments of multiple IP packets during reassembly).
可能出现重大完整性问题的小麻烦（例如，路由器中的路径处理缓慢）（例如，重新组装期间多个IP数据包片段的错误关联）。
As a result of these perceived limitations, a fragmentation-avoiding technique for discovering the MTU of the forward path from a source to a destination node was devised through the deliberations of the Path MTU Discovery Working Group (PMTUDWG) during the late 1980's through early 1990's (see Appendix A). In this method, the source node provides explicit instructions to routers in the path to discard the packet and return an ICMP error message if an MTU restriction is encountered. However, this approach has several serious shortcomings that lead to an overall "brittleness".
由于这些可感知的限制，通过路径MTU发现工作组（PMTUDWG）在20世纪80年代末至90年代初的审议，设计了一种用于发现从源节点到目的节点的前向路径的MTU的碎片避免技术（见附录a）。在这种方法中，源节点向路径中的路由器提供明确的指令，以便在遇到MTU限制时丢弃数据包并返回ICMP错误消息。然而，这种方法有几个严重的缺点，会导致整体的“脆弱性”。
In particular, site border routers in the Internet are being configured more and more to discard ICMP error messages coming from the outside world. This is due in large part to the fact that malicious spoofing of error messages in the Internet is made simple since there is no way to authenticate the source of the messages. Furthermore, when a source node that requires ICMP error message feedback when a packet is dropped due to an MTU restriction does not receive the messages, a path MTU-related black hole occurs. This means that the source will continue to send packets that are too large and never receive an indication from the network that they are being discarded.
特别是，Internet中的站点边界路由器被越来越多地配置为丢弃来自外部世界的ICMP错误消息。这在很大程度上是由于互联网上错误消息的恶意欺骗变得简单，因为无法验证消息的来源。此外，当由于MTU限制而丢弃数据包时需要ICMP错误消息反馈的源节点没有收到消息时，就会出现与路径MTU相关的黑洞。这意味着源将继续发送过大的数据包，并且从未从网络接收到丢弃数据包的指示。
The issues with both IPv4 fragmentation and this "classical" method of path MTU discovery are exacerbated further when IP-in-IP tunneling is used. For example, site border routers that are configured as ingress tunnel endpoints may be required to forward packets into the subnetwork on behalf of hundreds, thousands, or even more original sources located within the site. If IPv4 fragmentation were used, this would quickly wrap the 16-bit Identification field and could lead to undetected data corruption. If classical IPv4 path MTU discovery were used instead, the site border router may be bombarded by ICMP error messages coming from the subnetwork that may be either untrustworthy or insufficiently provisioned to allow translation into error message to be returned to the original sources.
当使用IP-in-IP隧道时，IPv4碎片和这种“经典”路径MTU发现方法的问题会进一步恶化。例如，配置为入口隧道端点的站点边界路由器可能需要代表位于站点内的数百、数千或甚至更多原始源将分组转发到子网中。如果使用IPv4分段，这将快速包装16位标识字段，并可能导致未检测到的数据损坏。如果改用传统的IPv4路径MTU发现，则站点边界路由器可能会受到来自子网的ICMP错误消息的轰炸，这些错误消息可能不可信，或者配置不足，无法将转换成的错误消息返回到原始源。
The situation is exacerbated further still by IPsec tunnels, since only the first IPv4 fragment of a fragmented packet contains the transport protocol selectors (e.g., the source and destination ports) required for identifying the correct security association rendering fragmentation useless under certain circumstances. Even worse, there may be no way for a site border router that configures an IPsec tunnel to transcribe the encrypted packet fragment contained in an
IPsec隧道进一步加剧了这种情况，因为只有片段化数据包的第一个IPv4片段包含识别正确的安全关联所需的传输协议选择器（例如，源端口和目标端口），从而使片段在某些情况下变得无用。更糟糕的是，对于配置IPsec隧道的站点边界路由器来说，可能没有办法转录IPsec隧道中包含的加密数据包片段
ICMP error message into a suitable ICMP error message to return to the original source. Due to these many limitations, a new approach to accommodate links with diverse MTUs is necessary.
将ICMP错误消息转换为适当的ICMP错误消息以返回原始源。由于这些限制，有必要采用一种新的方法来容纳与不同MTU的链接。
For the purpose of this document, subnetworks are defined as virtual topologies that span connected network regions bounded by encapsulating border nodes. Examples include the global Internet interdomain routing core, Mobile Ad hoc Networks (MANETs) and enterprise networks. Subnetwork border nodes forward unicast and multicast IP packets over the virtual topology across multiple IP and/or sub-IP layer forwarding hops that may introduce packet duplication and/or traverse links with diverse Maximum Transmission Units (MTUs).
在本文档中，子网络定义为虚拟拓扑，跨越由封装边界节点限定的连接网络区域。示例包括全球互联网域间路由核心、移动自组织网络（MANET）和企业网络。子网边界节点跨多个IP和/或子IP层转发跃点在虚拟拓扑上转发单播和多播IP数据包，这些转发跃点可能引入数据包复制和/或通过具有不同最大传输单元（MTU）的链路。
This document introduces a Subnetwork Encapsulation and Adaptation Layer (SEAL) for tunnel-mode operation of IP over subnetworks that connect Ingress and Egress Tunnel Endpoints (ITEs/ETEs) of border nodes. Operation in transport mode is also supported when subnetwork border node upper-layer protocols negotiate the use of SEAL during connection establishment. SEAL accommodates links with diverse MTUs and supports efficient duplicate packet detection by introducing a minimal mid-layer encapsulation.
本文档介绍了用于连接边界节点的入口和出口隧道端点（ITE/ETE）的子网上IP隧道模式操作的子网封装和适配层（SEAL）。当子网边界节点上层协议在连接建立期间协商使用密封时，也支持传输模式下的操作。SEAL可容纳具有不同MTU的链路，并通过引入最小的中间层封装来支持有效的重复数据包检测。
The SEAL encapsulation introduces an extended Identification field for packet identification and a mid-layer segmentation and reassembly capability that allows simplified cutting and pasting of packets. Moreover, SEAL senses in-the-network IPv4 fragmentation as a "noise" indication that packet sizing parameters are "out of tune" with respect to the network path. As a result, SEAL can naturally tune its packet sizing parameters to eliminate the in-the-network fragmentation.
密封封装引入了用于数据包标识的扩展标识字段和中间层分段和重新组装功能，从而简化了数据包的剪切和粘贴。此外，SEAL将网络IPv4碎片感测为分组大小参数相对于网络路径“失调”的“噪声”指示。因此，SEAL可以自然地调整其数据包大小参数，以消除网络中的碎片。
The SEAL encapsulation layer and protocol are specified in the following sections.
密封封装层和协议在以下章节中指定。
The terms "inner", "mid-layer", and "outer", respectively, refer to the innermost IP (layer, protocol, header, packet, etc.) before any encapsulation, the mid-layer IP (protocol, header, packet, etc.) after any mid-layer '*' encapsulation, and the outermost IP (layer, protocol, header, packet etc.) after SEAL/*/IPv4 encapsulation.
术语“内部”、“中间层”和“外部”分别指任何封装前的最内层IP（层、协议、报头、数据包等），任何中间层“*”封装后的中间层IP（协议、报头、数据包等），以及密封/*/IPv4封装后的最外层IP（层、协议、报头、数据包等）。
The term "IP" used throughout the document refers to either Internet
Protocol version (IPv4 or IPv6). Additionally, the notation
IPvX/*/SEAL/*/IPvY refers to an inner IPvX packet encapsulated in any
The term "IP" used throughout the document refers to either Internet
Protocol version (IPv4 or IPv6). Additionally, the notation
IPvX/*/SEAL/*/IPvY refers to an inner IPvX packet encapsulated in any
mid-layer '*' encapsulations, followed by the SEAL header, followed by any outer '*' encapsulations, followed by an outer IPvY header, where the notation "IPvX" means either IP protocol version (IPv4 or IPv6).
中间层“*”封装，后跟密封头，后跟任何外部“*”封装，后跟外部IPvY头，其中符号“IPvX”表示IP协议版本（IPv4或IPv6）。
The following abbreviations correspond to terms used within this document and elsewhere in common Internetworking nomenclature:
以下缩略语与本文件和通用互联术语中其他地方使用的术语相对应：
ITE - Ingress Tunnel Endpoint
ITE-入口隧道端点
ETE - Egress Tunnel Endpoint
ETE-出口隧道端点
PTB - an ICMPv6 "Packet Too Big" or an ICMPv4 "Fragmentation Needed" message
PTB-ICMPv6“数据包太大”或ICMPv4“需要碎片”消息
DF - the IPv4 header "Don't Fragment" flag
DF-IPv4标头“不分段”标志
MHLEN - the length of any mid-layer '*' headers and trailers
MHLEN-任何中间层“*”标头和拖车的长度
OHLEN - the length of the outer encapsulating SEAL/*/IPv4 headers
OHLEN - the length of the outer encapsulating SEAL/*/IPv4 headers
HLEN - the sum of MHLEN and OHLEN
HLEN-MHLEN和OHLEN之和
S_MRU - the per-ETE SEAL Maximum Reassembly Unit
S_MRU-每个ETE密封件的最大重新组装单元
S_MSS - the SEAL Maximum Segment Size
S_MSS-密封件最大段尺寸
SEAL_ID - a 32-bit Identification value, randomly initialized and monotonically incremented for each SEAL protocol packet
SEAL_ID-一个32位标识值，随机初始化，并为每个SEAL协议数据包单调递增
SEAL_PROTO - an IPv4 protocol number used for SEAL
SEAL_PROTO-用于SEAL的IPv4协议号
SEAL_PORT - a TCP/UDP service port number used for SEAL
SEAL_端口-用于SEAL的TCP/UDP服务端口号
SEAL_OPTION - a TCP option number used for (transport-mode) SEAL
密封选项-用于（传输模式）密封的TCP选项编号
The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in [RFC2119].
本文件中出现的关键词必须、不得、要求、应、不应、应、不应、建议、可能和可选时，应按照[RFC2119]中的说明进行解释。
SEAL was motivated by the specific case of subnetwork abstraction for Mobile Ad hoc Networks (MANETs); however, the domain of applicability also extends to subnetwork abstractions of enterprise networks, the interdomain routing core, etc. The domain of application therefore
SEAL的动机是移动自组网（MANET）子网抽象的具体案例；然而，应用领域也扩展到企业网络的子网抽象、域间路由核心等。因此，应用领域
also includes the map-and-encaps architecture proposals in the IRTF Routing Research Group (RRG) (see http://www3.tools.ietf.org/group/ irtf/trac/wiki/RoutingResearchGroup).
还包括IRTF路由研究组（RRG）中的map和encaps架构提案（参见http://www3.tools.ietf.org/group/ irtf/trac/wiki/RoutingSearchGroup）。
SEAL introduces a minimal new sublayer for IPvX in IPvY encapsulation (e.g., as IPv6/SEAL/IPv4), and appears as a subnetwork encapsulation as seen by the inner IP layer. SEAL can also be used as a sublayer for encapsulating inner IP packets within outer UDP/IPv4 headers (e.g., as IPv6/SEAL/UDP/IPv4) such as for the Teredo domain of applicability [RFC4380]. When it appears immediately after the outer IPv4 header, the SEAL header is processed exactly as for IPv6 extension headers.
SEAL在IPvY封装中为IPvX引入了一个最小的新子层（例如，作为IPv6/SEAL/IPv4），并显示为一个子网封装，如内部IP层所示。SEAL还可以用作子层，用于将内部IP数据包封装在外部UDP/IPv4报头中（例如，作为IPv6/SEAL/UDP/IPv4），例如适用于Teredo域[RFC4380]。当它紧跟在外部IPv4标头之后出现时，SEAL标头的处理与IPv6扩展标头的处理完全相同。
SEAL can also be used in "transport-mode", e.g., when the inner layer includes upper-layer protocol data rather than an encapsulated IP packet. For instance, TCP peers can negotiate the use of SEAL for the carriage of protocol data encapsulated as TCP/SEAL/IPv4. In this sense, the "subnetwork" becomes the entire end-to-end path between the TCP peers and may potentially span the entire Internet.
SEAL还可用于“传输模式”，例如，当内层包括上层协议数据而不是封装的IP分组时。例如，TCP对等方可以协商使用SEAL传输封装为TCP/SEAL/IPv4的协议数据。从这个意义上说，“子网”成为TCP对等点之间的整个端到端路径，并且可能跨越整个互联网。
The current document version is specific to the use of IPv4 as the outer encapsulation layer; however, the same principles apply when IPv6 is used as the outer layer.
当前文档版本特定于使用IPv4作为外部封装层；但是，当IPv6用作外层时，同样的原则也适用。
SEAL supports the encapsulation of inner IP packets in mid-layer and outer encapsulating headers/trailers. For example, an inner IPv6 packet would appear as IPv6/*/SEAL/*/IPv4 after mid-layer and outer encapsulations, where '*' denotes zero or more additional encapsulation sublayers. Ingres Tunnel Endpoints (ITEs) add mid-layer inject into a subnetwork, where the outermost IPv4 header contains the source and destination addresses of the subnetwork entry/exit points (i.e., the ITE/ETE), respectively. SEAL uses a new Internet Protocol type and a new encapsulation sublayer for both unicast and multicast. The ITE encapsulates an inner IP packet in mid-layer and outer encapsulations as shown in Figure 1:
SEAL支持在中间层和外部封装头/尾中封装内部IP数据包。例如，内部IPv6数据包将在中间层和外部封装后显示为IPv6/*/SEAL/*/IPv4，其中“*”表示零个或多个附加封装子层。入口隧道端点（ITEs）将中间层注入添加到子网中，其中最外层的IPv4报头分别包含子网入口/出口点（即ITE/ETE）的源地址和目标地址。SEAL为单播和多播使用了新的Internet协议类型和新的封装子层。ITE将内部IP包封装在中间层和外部封装中，如图1所示：
+-------------------------+
| |
~ Outer */IPv4 headers ~
| |
I +-------------------------+
n | SEAL Header |
n +-------------------------+ +-------------------------+
e ~ Any mid-layer * headers ~ ~ Any mid-layer * headers ~
r +-------------------------+ +-------------------------+
| | | |
I --> ~ Inner IP ~ --> ~ Inner IP ~
P --> ~ Packet ~ --> ~ Packet ~
| | | |
P +-------------------------+ +-------------------------+
a ~ Any mid-layer trailers ~ ~ Any mid-layer trailers ~
c +-------------------------+ +-------------------------+
k ~ Any outer trailers ~
e +-------------------------+
t
(After mid-layer encaps.) (After SEAL/*/IPv4 encaps.)
+-------------------------+
| |
~ Outer */IPv4 headers ~
| |
I +-------------------------+
n | SEAL Header |
n +-------------------------+ +-------------------------+
e ~ Any mid-layer * headers ~ ~ Any mid-layer * headers ~
r +-------------------------+ +-------------------------+
| | | |
I --> ~ Inner IP ~ --> ~ Inner IP ~
P --> ~ Packet ~ --> ~ Packet ~
| | | |
P +-------------------------+ +-------------------------+
a ~ Any mid-layer trailers ~ ~ Any mid-layer trailers ~
c +-------------------------+ +-------------------------+
k ~ Any outer trailers ~
e +-------------------------+
t
(After mid-layer encaps.) (After SEAL/*/IPv4 encaps.)
Figure 1: SEAL Encapsulation
图1：密封封装
where the SEAL header is inserted as follows:
插入密封集管的位置如下：
o For simple IPvX/IPv4 encapsulations (e.g., [RFC2003][RFC2004][RFC4213]), the SEAL header is inserted between the inner IP and outer IPv4 headers as: IPvX/SEAL/IPv4.
o 对于简单的IPvX/IPv4封装（例如，[RFC2003][RFC2004][RFC4213]），密封头插入内部IP和外部IPv4头之间，如：IPvX/SEAL/IPv4。
o For tunnel-mode IPsec encapsulations over IPv4, [RFC4301], the SEAL header is inserted between the {AH,ESP} header and outer IPv4 headers as: IPvX/*/{AH,ESP}/SEAL/IPv4.
o 对于IPv4上的隧道模式IPsec封装，[RFC4301]，密封头插入在{AH，ESP}头和外部IPv4头之间，如：IPvX/*/{AH，ESP}/SEAL/IPv4。
o For IP encapsulations over transports such as UDP, the SEAL header is inserted immediately after the outer transport layer header, e.g., as IPvX/*/SEAL/UDP/IPv4.
o 对于UDP等传输上的IP封装，将在外部传输层头之后立即插入密封头，例如IPvX/*/SEAL/UDP/IPv4。
SEAL-encapsulated packets include a 32-bit SEAL_ID formed from the concatenation of the 16-bit ID Extension field in the SEAL header as the most-significant bits, and with the 16-bit Identification value in the outer IPv4 header as the least-significant bits. (For tunnels that traverse IPv4 Network Address Translators, the SEAL_ID is instead maintained only within the 16-bit ID Extension field in the SEAL header.) Routers within the subnetwork use the SEAL_ID for duplicate packet detection, and ITEs/ETEs use the SEAL_ID for SEAL segmentation and reassembly.
密封封装的分组包括32位密封ID，该32位密封ID由密封报头中的16位ID扩展字段串联而成，作为最高有效位，并且外部IPv4报头中的16位标识值作为最低有效位。（对于穿越IPv4网络地址转换器的隧道，SEAL_ID仅保留在SEAL标头中的16位ID扩展字段中。）子网内的路由器使用SEAL_ID进行重复数据包检测，ITEs/ETE使用SEAL_ID进行密封分段和重新组装。
SEAL enables a multi-level segmentation and reassembly capability.
SEAL实现了多级分段和重新组装功能。
First, the ITE can use IPv4 fragmentation to fragment inner IPv4 packets with DF=0 before SEAL encapsulation to avoid lower-layer segmentation and reassembly. Secondly, the SEAL layer itself provides a simple cutting-and-pasting capability for mid-layer packets to avoid IPv4 fragmentation on the outer packet. Finally, ordinary IPv4 fragmentation is permitted on the outer packet after SEAL encapsulation and used to detect and dampen any in-the-network fragmentation as quickly as possible.
首先，ITE可以在密封封装之前使用IPv4碎片对DF=0的内部IPv4数据包进行碎片化，以避免低层分段和重新组装。其次，密封层本身为中间层数据包提供了简单的剪切和粘贴功能，以避免外部数据包上的IPv4碎片。最后，在密封封装后，允许在外部数据包上使用普通IPv4碎片，并用于尽快检测和抑制网络中的任何碎片。
The following sections specify the SEAL-related operations of the ITE and ETE, respectively:
以下章节分别规定了ITE和ETE的密封相关操作：
The ITE configures a tunnel virtual interface over one or more underlying links that connect the border node to the subnetwork. The tunnel interface must present a fixed MTU to the inner IP layer (i.e., Layer 3) as the size for admission of inner IP packets into the tunnel. Since the tunnel interface may support a potentially large set of ETEs, however, care must be taken in setting a greatest-common-denominator MTU for all ETEs while still upholding end system expectations.
ITE通过将边界节点连接到子网络的一个或多个基础链路配置隧道虚拟接口。隧道接口必须向内部IP层（即第3层）提供一个固定的MTU，作为允许内部IP数据包进入隧道的大小。然而，由于隧道接口可能支持一组潜在的大型ETE，因此必须注意为所有ETE设置最大公分母MTU，同时仍保持终端系统预期。
Due to the ubiquitous deployment of standard Ethernet and similar networking gear, the nominal Internet cell size has become 1500 bytes; this is the de facto size that end systems have come to expect will either be delivered by the network without loss due to an MTU restriction on the path or a suitable PTB message returned. However, the network may not always deliver the necessary PTBs, leading to MTU-related black holes [RFC2923]. The ITE therefore requires a means for conveying 1500 byte (or smaller) packets to the ETE without loss due to MTU restrictions and without dependence on PTB messages from within the subnetwork.
由于标准以太网和类似网络设备的普遍部署，标称互联网单元大小已达到1500字节；这是终端系统所期望的事实上的大小，它将由网络交付而不会由于路径上的MTU限制或返回的适当PTB消息而丢失。然而，网络可能并不总是提供必要的PTB，从而导致与MTU相关的黑洞[RFC2923]。因此，ITE需要一种将1500字节（或更小）的数据包传输到ETE的方法，而不会因MTU限制而丢失，也不会依赖子网内的PTB消息。
In common deployments, there may be many forwarding hops between the original source and the ITE. Within those hops, there may be additional encapsulations (IPSec, L2TP, etc.) such that a 1500 byte packet sent by the original source might grow to a larger size by the time it reaches the ITE for encapsulation as an inner IP packet. Similarly, additional encapsulations on the path from the ITE to the ETE could cause the encapsulated packet to become larger still and trigger in-the-network fragmentation. In order to preserve the end system expectations, the ITE therefore requires a means for conveying these larger packets to the ETE even though there may be links within the subnetwork that configure a smaller MTU.
在常见部署中，原始源和ITE之间可能存在许多转发跃点。在这些跃点内，可能存在额外的封装（IPSec、L2TP等），使得原始源发送的1500字节数据包在到达ITE时可能会增长为更大的大小，以便封装为内部IP数据包。类似地，从ITE到ETE的路径上的额外封装可能会导致封装的数据包变得更大，并触发网络碎片。为了保持终端系统预期，因此，即使子网内可能存在配置较小MTU的链路，ITE也需要将这些较大数据包传输到ETE的方法。
The ITE should therefore set a tunnel virtual interface MTU of 1500 bytes plus extra room to accommodate any additional encapsulations that may occur on the path from the original source (i.e., even if the path to the ETE does not support an MTU of this size). The ITE can set larger MTU values still, but should select a value that is not so large as to cause excessive PTBs coming from within the tunnel interface (see Sections 4.2.2 and 4.2.6). The ITE can also set smaller MTU values; however, care must be taken not to set so small a value that original sources would experience an MTU underflow. In particular, IPv6 sources must see a minimum path MTU of 1280 bytes, and IPv4 sources should see a minimum path MTU of 576 bytes.
因此，ITE应设置1500字节的隧道虚拟接口MTU加上额外的空间，以容纳可能在原始源路径上发生的任何额外封装（即，即使到ETE的路径不支持此大小的MTU）。ITE仍然可以设置更大的MTU值，但应选择一个不太大的值，以避免隧道接口内产生过多的PTB（见第4.2.2节和第4.2.6节）。ITE还可以设置较小的MTU值；但是，必须注意不要设置太小的值，以免原始震源会出现MTU下溢。特别是，IPv6源必须看到1280字节的最小路径MTU，IPv4源应该看到576字节的最小路径MTU。
The inner IP layer consults the tunnel interface MTU when admitting a packet into the interface. For inner IPv4 packets larger than the tunnel interface MTU and with the IPv4 Don't Fragment (DF) bit set to 0, the inner IPv4 layer uses IPv4 fragmentation to break the packet into fragments no larger than the tunnel interface MTU (but, see also Section 4.2.3), then admits each fragment into the tunnel as an independent packet. For all other inner packets (IPv4 or IPv6), the ITE admits the packet if it is no larger than the tunnel interface MTU; otherwise, it drops the packet and sends an ICMP PTB message with an MTU value of the tunnel interface MTU to the source.
当允许数据包进入接口时，内部IP层咨询隧道接口MTU。对于大于隧道接口MTU且IPv4不分段（DF）位设置为0的内部IPv4数据包，内部IPv4层使用IPv4分段将数据包分解为不大于隧道接口MTU的片段（但也请参见第4.2.3节），然后将每个片段作为独立数据包送入隧道。对于所有其他内部数据包（IPv4或IPv6），如果数据包不大于隧道接口MTU，则ITE允许该数据包；否则，它会丢弃数据包，并向源发送带有隧道接口MTU MTU值的ICMP PTB消息。
As for any transport layer protocol, ITEs use the MTU of the underlying IPv4 interface, the length of any mid-layer '*' headers and trailers, and the length of the outer SEAL/*/IPv4 headers to determine the maximum size for a SEAL segment (see Section 4.2.3). For example, when the underlying IPv4 interface advertises an MTU of 1500 bytes and the ITE inserts a minimum-length (i.e., 20-byte) IPv4 header, the ITE sees a maximum segment size of 1480 bytes. When the ITE inserts IPv4 header options, the size is further reduced by as many as 40 additional bytes (the maximum length for IPv4 options) such that as few as 1440 bytes may be available for the upper-layer payload. When the ITE inserts additional '*' encapsulations, the maximum segment size is reduced further still.
对于任何传输层协议，ITE使用底层IPv4接口的MTU、任何中间层“*”头和尾的长度以及外部密封/*/IPv4头的长度来确定密封段的最大尺寸（见第4.2.3节）。例如，当基础IPv4接口播发1500字节的MTU，并且ITE插入最小长度（即20字节）的IPv4报头时，ITE看到的最大段大小为1480字节。当ITE插入IPv4报头选项时，该大小将进一步减少多达40个额外字节（IPv4选项的最大长度），这样上层有效负载的可用字节数可能只有1440个。当ITE插入额外的“*”封装时，最大段大小将进一步减小。
The ITE must additionally account for the length of the SEAL header itself as an extra encapsulation that further reduces the maximum segment size. The length of the SEAL header is not incorporated in the IPv4 header length; therefore, the network does not observe the SEAL header as an IPv4 option. In this way, the SEAL header is inserted after the IPv4 options but before the upper-layer payload in exactly the same manner as for IPv6 extension headers.
ITE还必须考虑密封集管本身的长度，作为进一步减小最大管段尺寸的额外封装。密封头的长度不包含在IPv4头长度中；因此，网络不会将密封头视为IPv4选项。通过这种方式，密封头插入IPv4选项之后，但在上层有效负载之前，插入方式与IPv6扩展头完全相同。
For each ETE, the ITE maintains the length of any mid-layer '*' encapsulation headers and trailers (e.g., for '*' = AH, ESP, NULL, etc.) in a variable 'MHLEN' and maintains the length of the outer SEAL/*/IPv4 encapsulation headers in a variable 'OHLEN'. The ITE further maintains a variable 'HLEN' set to MHLEN plus OHLEN. The ITE maintains a SEAL Maximum Reassembly Unit (S_MRU) value for each ETE as soft state within the tunnel interface (e.g., in the IPv4 destination cache). The ITE initializes S_MRU to a value no larger than 2KB and uses this value to determine the maximum-sized packet it will require the ETE to reassemble. The ITE additionally maintains a SEAL Maximum Segment Size (S_MSS) value for each ETE. The ITE initializes S_MSS to the maximum of (the underlying IPv4 interface MTU minus OHLEN) and S_MRU/8 bytes, and decreases or increases S_MSS based on any ICMPv4 Fragmentation Needed messages received (see Section 4.2.6).
对于每个ETE，ITE在变量“MHLEN”中维护任何中间层“*”封装头和尾部的长度（例如，对于“*”=AH、ESP、NULL等），并在变量“OHLEN”中维护外部密封/*/IPv4封装头的长度。ITE进一步将变量“HLEN”设置为MHLEN加上OHLEN。ITE将每个ETE的密封最大重组单元（S_MRU）值保持为隧道接口内的软状态（例如，在IPv4目标缓存中）。ITE将_MRU初始化为不大于2KB的值，并使用该值确定ETE重新组装所需的最大数据包大小。ITE还为每个ETE保留了密封件最大段尺寸（S_MSS）值。ITE将S_MSS初始化为最大值（底层IPv4接口MTU减去OHLEN）和S_MRU/8字节，并根据接收到的任何ICMPv4碎片所需消息减少或增加S_MSS（见第4.2.6节）。
The ITE performs segmentation and encapsulation on inner packets that have been admitted into the tunnel interface. For inner IPv4 packets with the DF bit set to 0, if the length of the inner packet is larger than (S_MRU - HLEN), the ITE uses IPv4 fragmentation to break the packet into IPv4 fragments no larger than (S_MRU - HLEN). For unfragmentable inner packets (e.g., IPv6 packets, IPv4 packets with DF=1, etc.), if the length of the inner packet is larger than (MAX(S_MRU, S_MSS) - HLEN), the ITE drops the packet and sends an ICMP PTB message with an MTU value of (MAX(S_MRU, S_MSS) - HLEN) back to the original source.
ITE对已进入隧道接口的内部数据包执行分段和封装。对于DF位设置为0的内部IPv4数据包，如果内部数据包的长度大于（S_MRU-HLEN），则ITE使用IPv4碎片将数据包分解为不大于（S_MRU-HLEN）的IPv4片段。对于不可拆分的内部数据包（例如，IPv6数据包、DF=1的IPv4数据包等），如果内部数据包的长度大于（MAX（S_MRU，S_MSS）-HLEN），则站点会丢弃数据包，并将MTU值为（MAX（S_MRU，S_MSS）-HLEN）的ICMP PTB消息发送回原始源。
The ITE then encapsulates each inner packet/fragment in the MHLEN
bytes of mid-layer '*' headers and trailers. For each such resulting
mid-layer packet of length 'M', if (S_MRU >= (M + OHLEN) > S_MSS),
the ITE must perform SEAL segmentation. To do so, it breaks the mid-
layer packet into N segments (N <= 8) that are no larger than
(MIN(1KB, S_MSS) - OHLEN) bytes each. Each segment, except the final
one, MUST be of equal length, while the final segment MUST be no
larger than the initial segment. The first byte of each segment MUST
begin immediately after the final byte of the previous segment, i.e.,
the segments MUST NOT overlap. The ITE should generate the smallest
number of segments possible, e.g., it should not generate 6 smaller
segments when the packet could be accommodated with 4 larger
segments.
The ITE then encapsulates each inner packet/fragment in the MHLEN
bytes of mid-layer '*' headers and trailers. For each such resulting
mid-layer packet of length 'M', if (S_MRU >= (M + OHLEN) > S_MSS),
the ITE must perform SEAL segmentation. To do so, it breaks the mid-
layer packet into N segments (N <= 8) that are no larger than
(MIN(1KB, S_MSS) - OHLEN) bytes each. Each segment, except the final
one, MUST be of equal length, while the final segment MUST be no
larger than the initial segment. The first byte of each segment MUST
begin immediately after the final byte of the previous segment, i.e.,
the segments MUST NOT overlap. The ITE should generate the smallest
number of segments possible, e.g., it should not generate 6 smaller
segments when the packet could be accommodated with 4 larger
segments.
Note that this SEAL segmentation ignores the fact that the mid-layer packet may be unfragmentable. This segmentation process is a mid-layer (not an IP layer) operation employed by the ITE to adapt the mid-layer packet to the subnetwork path characteristics, and the ETE will restore the packet to its original form during reassembly.
注意，该密封分段忽略了中间层分组可能不可分割的事实。该分段过程是中间层（而非IP层）操作，由ITE采用，以使中间层数据包适应子网路径特征，ETE将在重新组装期间将数据包恢复为其原始形式。
Therefore, the fact that the packet may have been segmented within the subnetwork is not observable outside of the subnetwork.
因此，分组可能已经在子网内被分段的事实在子网外是不可观察的。
The ITE next encapsulates each segment in a SEAL header formatted as follows:
ITE接下来将每个段封装在密封头中，格式如下：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ID Extension |A|R|M|RSV| SEG | Next Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ID Extension |A|R|M|RSV| SEG | Next Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: SEAL Header Format
图2：密封头格式
where the header fields are defined as follows:
其中，标题字段定义如下：
ID Extension (16) a 16-bit extension of the Identification field in the outer IPv4 header; encodes the most-significant 16 bits of a 32 bit SEAL_ID value.
ID扩展（16）外部IPv4报头中标识字段的16位扩展；对32位SEAL_ID值的最高有效16位进行编码。
A (1) the "Acknowledgement Requested" bit. Set to 1 if the ITE wishes to receive an explicit acknowledgement from the ETE.
A（1）“请求确认”位。如果ITE希望收到ETE的明确确认，则设置为1。
R (1) the "Report Fragmentation" bit. Set to 1 if the ITE wishes to receive a report from the ETE if any IPv4 fragmentation occurs.
R（1）“报告碎片”位。如果ITE希望在出现任何IPv4碎片时从ETE接收报告，则设置为1。
M (1) the "More Segments" bit. Set to 1 if this SEAL protocol packet contains a non-final segment of a multi-segment mid-layer packet.
M（1）“更多段”位。如果此密封协议数据包包含多段中间层数据包的非最终段，则设置为1。
RSV (2) a 2-bit field reserved for future use. Must be set to 0 for the purpose of this specification.
RSV（2）保留供将来使用的2位字段。在本规范中，必须将设置为0。
SEG (3) a 3-bit segment number. Encodes a segment number between 0 - 7.
SEG（3）一个3位的段号。对0-7之间的段编号进行编码。
Next Header (8) an 8-bit field that encodes an Internet Protocol number the same as for the IPv4 protocol and IPv6 next header fields.
Next Header（8）一个8位字段，用于编码与IPv4协议和IPv6 Next Header字段相同的Internet协议编号。
For single-segment mid-layer packets, the ITE encapsulates the segment in a SEAL header with (M=0; SEG=0). For N-segment mid-layer packets (N <= 8), the ITE encapsulates each segment in a SEAL header with (M=1; SEG=0) for the first segment, (M=1; SEG=1) for the second segment, etc., with the final segment setting (M=0; SEG=N-1).
对于单段中间层数据包，ITE将数据段封装在带有（M=0；SEG=0）的密封头中。对于N段中间层数据包（N<=8），ITE将每个数据段封装在一个密封头中，第一个数据段采用（M=1；SEG=0），第二个数据段采用（M=1；SEG=1）等，最后一个数据段设置为（M=0；SEG=N-1）。
The ITE next sets RSV='00' and sets the A and R bits in the SEAL header of the first segment according to whether the packet is to be used as an explicit/implicit probe as specified in Section 4.2.4. The ITE then writes the Internet Protocol number corresponding to the mid-layer packet in the SEAL 'Next Header' field and encapsulates each segment in the requisite */IPv4 outer headers according to the specific encapsulation format (e.g., [RFC2003], [RFC4213], [RFC4380], etc.), except that it writes 'SEAL_PROTO' in the protocol field of the outer IPv4 header (when simple IPv4 encapsulation is used) or writes 'SEAL_PORT' in the outer destination service port field (e.g., when UDP/IPv4 encapsulation is used). The ITE finally sets packet identification values as specified in Section 4.2.5 and sends the packets as specified in Section 4.2.6.
ITE接下来设置RSV='00'，并根据数据包是否将用作第4.2.4节中规定的显式/隐式探测，在第一段的密封头中设置A和R位。然后，ITE将与中间层数据包对应的互联网协议号写入“下一个报头”字段中，并根据特定的封装格式（例如，[RFC2003]、[RFC4213]、[RFC4380]等）将每个段封装在必要的*/IPv4外部报头中，除了在外部IPv4标头的协议字段中写入“SEAL_PROTO”（当使用简单IPv4封装时）或在外部目标服务端口字段中写入“SEAL_PORT”（例如，当使用UDP/IPv4封装时）。ITE最终按照第4.2.5节的规定设置数据包标识值，并按照第4.2.6节的规定发送数据包。
When S_MSS is larger than S_MRU/8 bytes, the ITE sends ordinary encapsulated data packets as implicit probes to detect in-the-network IPv4 fragmentation and to determine new values for S_MSS. The ITE sets R=1 in the SEAL header of a packet with SEG=0 to be used as an implicit probe, and will receive ICMPv4 Fragmentation Needed messages from the ETE if any IPv4 fragmentation occurs. When the ITE has already reduced S_MSS to the minimum value, it instead sets R=0 in the SEAL header to avoid generating fragmentation reports for unavoidable in-the-network fragmentation.
当S_MSS大于S_MRU/8字节时，ITE发送普通封装数据包作为隐式探测，以检测网络中的IPv4碎片并确定S_MSS的新值。ITE将SEG=0的数据包的密封头中的R=1设置为用作隐式探测，并且如果出现任何IPv4碎片，将从ETE接收ICMPv4碎片所需的消息。当ITE已经将S_MSS降低到最小值时，它将在密封头中设置R=0，以避免生成网络碎片中不可避免的碎片报告。
The ITE should send explicit probes periodically to manage a window of SEAL_IDs of outstanding probes as a means to validate any ICMPv4 messages it receives. The ITE sets A=1 in the SEAL header of a packet with SEG=0 to be used as an explicit probe, where the probe can be either an ordinary data packet or a NULL packet created by setting the 'Next Header' field in the SEAL header to a value of "No Next Header" (see Section 4.7 of [RFC2460]).
ITE应定期发送显式探测，以管理未完成探测的封存ID窗口，作为验证其收到的任何ICMPv4消息的手段。ITE在SEG=0的数据包的密封头中设置A=1，用作显式探测，其中探测可以是普通数据包，也可以是通过将密封头中的“下一个头”字段设置为“无下一个头”值而创建的空数据包（见[RFC2460]第4.7节）。
The ITE should further send explicit probes, periodically, to detect increases in S_MSS by resetting S_MSS to the maximum of (the underlying IPv4 interface MTU minus OHLEN) and S_MRU/8 bytes, and/or by sending explicit probes that are larger than the current S_MSS.
ITE还应定期发送显式探测，通过将S_MSS重置为最大值（底层IPv4接口MTU减去OHLEN）和S_MRU/8字节，和/或发送大于当前S_MSS的显式探测，检测S_MSS的增加。
Finally, the ITE MAY send "expendable" probe packets with DF=1 (see Section 4.2.6) in order to generate ICMPv4 Fragmentation Needed messages from routers on the path to the ETE.
最后，ITE可发送DF=1的“消耗性”探测包（见第4.2.6节），以便从ETE路径上的路由器生成ICMPv4碎片所需的消息。
For the purpose of packet identification, the ITE maintains a 32-bit SEAL_ID value as per-ETE soft state, e.g., in the IPv4 destination cache. The ITE randomly initializes SEAL_ID when the soft state is created and monotonically increments it (modulo 2^32) for each successive SEAL protocol packet it sends to the ETE. For each packet, the ITE writes the least-significant 16 bits of the SEAL_ID value in the Identification field in the outer IPv4 header, and writes the most-significant 16 bits in the ID Extension field in the SEAL header.
出于数据包识别的目的，ITE根据ETE软状态（例如，在IPv4目标缓存中）保持32位SEAL_ID值。当创建软状态时，ITE随机初始化SEAL_ID，并对发送给ETE的每个连续SEAL协议包单调递增（模2^32）。对于每个数据包，ITE在外部IPv4报头的标识字段中写入SEAL_ID值的最低有效16位，并在SEAL报头的ID扩展字段中写入最高有效16位。
For SEAL encapsulations specifically designed for the traversal of IPv4 Network Address Translators (NATs), e.g., for encapsulations that insert a UDP header between the SEAL header and outer IPv4 header such as IPv6/SEAL/UDP/IPv4, the ITE instead maintains SEAL_ID as a 16-bit value that it randomly initializes when the soft state is created and monotonically increments (modulo 2^16) for each successive packet. For each packet, the ITE writes SEAL_ID in the ID extension field of the SEAL header and writes a random 16-bit value in the Identification field in the outer IPv4 header. This is due to the fact that the ITE has no way to control IPv4 NATs in the path that could rewrite the Identification value in the outer IPv4 header.
对于专门为遍历IPv4网络地址转换器（NAT）而设计的密封封装，例如，对于在密封头和外部IPv4头之间插入UDP头的封装，如IPv6/SEAL/UDP/IPv4，相反，ITE将SEAL_ID保持为16位值，在创建软状态时随机初始化，并为每个连续数据包单调递增（模2^16）。对于每个数据包，ITE在SEAL报头的ID扩展字段中写入SEAL_ID，并在外部IPv4报头的标识字段中写入随机16位值。这是因为ITE无法控制路径中的IPv4 NAT，该路径可能会重写外部IPv4报头中的标识值。
Following SEAL segmentation and encapsulation, the ITE sets DF=0 in the outer IPv4 header of every outer packet it sends. For "expendable" packets (e.g., for NULL packets used as probes -- see Section 4.2.4), the ITE may instead set DF=1.
在密封分段和封装之后，ITE在其发送的每个外部数据包的外部IPv4报头中设置DF=0。对于“消耗性”数据包（例如，用作探测的空数据包——见第4.2.4节），ITE可将DF设置为1。
The ITE then sends each outer packet that encapsulates a segment of the same mid-layer packet into the tunnel in canonical order, i.e., segment 0 first, followed by segment 1, etc. and finally segment N-1.
然后，ITE发送每个外部数据包，这些数据包按照规范顺序将同一中间层数据包的一段封装到隧道中，即先是段0，然后是段1，等等，最后是段N-1。
The ITE may receive "raw" ICMPv4 error messages from either the ETE or routers within the subnetwork that comprise an outer IPv4 header, followed by an ICMPv4 header, followed by a portion of the SEAL packet that generated the error (also known as the "packet-in-error"). For such messages, the ITE can use the 32-bit SEAL ID encoded in the packet-in-error as a nonce to confirm that the ICMP message came from either the ETE or an on-path router. The ITE MAY process raw ICMPv4 messages as soft errors indicating that the path to the ETE may be failing.
ITE可以从ETE或子网内的路由器接收“原始”ICMPv4错误消息，该子网包括外部IPv4报头，后面是ICMPv4报头，后面是生成错误的密封数据包的一部分（也称为“错误数据包”）。对于此类消息，ITE可以使用错误数据包中编码的32位密封ID作为nonce，以确认ICMP消息来自ETE或路径路由器。ITE可能将原始ICMPv4消息处理为软错误，表明ETE的路径可能失败。
The ITE should specifically process raw ICMPv4 Protocol Unreachable messages as a hint that the ETE does not implement the SEAL protocol.
ITE应专门处理原始ICMPv4协议无法访问的消息，作为ETE未实现SEAL协议的提示。
In addition to any raw ICMPv4 messages, the ITE may receive SEAL-encapsulated ICMPv4 messages from the ETE that comprise outer ICMPv4/ */SEAL/*/IPv4 headers followed by a portion of the SEAL-encapsulated packet-in-error. The ITE can use the 32-bit SEAL ID encoded in the packet-in-error as well as information in the outer IPv4 and SEAL headers as nonces to confirm that the ICMP message came from a legitimate ETE. The ITE then verifies that the SEAL_ID encoded in the packet-in-error is within the current window of transmitted SEAL_IDs for this ETE. If the SEAL_ID is outside of the window, the ITE discards the message; otherwise, it advances the window and processes the message.
除了任何原始ICMPv4消息外，ITE还可以从ETE接收密封封装的ICMPv4消息，该消息包括外部ICMPv4/*/SEAL/*/IPv4报头，后跟错误的密封封装数据包的一部分。ITE可以使用错误数据包中编码的32位密封ID以及外部IPv4和密封头中的信息作为nonce，以确认ICMP消息来自合法ETE。然后，ITE验证错误数据包中编码的SEAL_ID是否在该ETE传输的SEAL_ID的当前窗口内。如果封条ID在窗口外，ITE将丢弃该消息；否则，它将推进窗口并处理消息。
The ITE processes SEAL-encapsulated ICMPv4 messages other than ICMPv4 Fragmentation Needed exactly as specified in [RFC0792].
ITE处理密封封装的ICMPv4消息，而不是完全按照[RFC0792]中的规定处理所需的ICMPv4碎片。
For SEAL-encapsulated ICMPv4 Fragmentation Needed messages, the ITE
sets a variable 'L' to the IPv4 length of the packet-in-error minus
OHLEN. If (L > S_MSS), or if the packet-in-error is an IPv4 first
fragment (i.e., with MF=1; Offset=0) and (L >= (576 - OHLEN)), the
ITE sets (S_MSS = L).
For SEAL-encapsulated ICMPv4 Fragmentation Needed messages, the ITE
sets a variable 'L' to the IPv4 length of the packet-in-error minus
OHLEN. If (L > S_MSS), or if the packet-in-error is an IPv4 first
fragment (i.e., with MF=1; Offset=0) and (L >= (576 - OHLEN)), the
ITE sets (S_MSS = L).
Note that 576 in the above corresponds to the nominal minimum MTU for IPv4 links. When an ITE instead receives an IPv4 first fragment packet-in-error with (L < (576 - OHLEN)), it discovers that IPv4 fragmentation is occurring in the network but it cannot determine the true MTU of the restricting link due to a router on the path generating runt first fragments. The ITE should therefore search for a reduced S_MSS value (to a minimum of S_MRU/8) through an iterative searching strategy that parallels (Section 5 of [RFC1191]).
请注意，上面的576对应于IPv4链路的标称最小MTU。当ITE接收到错误的IPv4第一个片段数据包时（L<（576-OHLEN）），它会发现网络中正在发生IPv4片段，但由于路径上的路由器生成runt first片段，它无法确定限制链路的真实MTU。因此，ITE应通过并行迭代搜索策略（RFC1191第5节）搜索减少的S_MSS值（最小S_MRU/8）。
This searching strategy may require multiple iterations of sending SEAL packets with DF=0 using a reduced S_MSS and receiving additional Fragmentation Needed messages, but it will soon converge to a stable value. During this process, it is essential that the ITE reduce S_MSS based on the first Fragmentation Needed message received, and refrain from further reducing S_MSS until ICMPv4 Fragmentation Needed messages pertaining to packets sent under the new S_MSS are received.
这种搜索策略可能需要多次迭代，使用减少的S_MSS发送DF=0的密封包，并接收额外的碎片所需消息，但很快就会收敛到一个稳定值。在此过程中，ITE必须根据接收到的第一条需要分段的消息减少S_MSS，并且在收到与在新S_MSS下发送的数据包相关的ICMPv4需要分段的消息之前，不要进一步减少S_MSS。
As an optimization only, the ITE MAY transcribe SEAL-encapsulated Fragmentation Needed messages that contain sufficient information into corresponding PTB messages to return to the original source.
仅作为优化，ITE可以将包含足够信息的密封封装碎片所需消息转录到相应的PTB消息中，以返回到原始源。
ETEs MUST be capable of using IPv4-layer reassembly to reassemble SEAL protocol outer IPv4 packets up to 2KB in length, and MUST also be capable of using SEAL-layer reassembly to reassemble mid-layer packets up to (2KB - OHLEN). Note that the ITE must retain the SEAL/*/IPv4 header during both IPv4-layer and SEAL-layer reassembly for the purpose of associating the fragments/segments of the same packet.
ETE必须能够使用IPv4层重组来重组长度不超过2KB的密封协议外部IPv4数据包，并且还必须能够使用密封层重组来重组长度不超过2KB的中间层数据包。请注意，在IPv4层和密封层重新组装期间，ITE必须保留SEAL/*/IPv4报头，以便关联同一数据包的片段/段。
The ETE performs IPv4 reassembly as normal, and should maintain a conservative high- and low-water mark for the number of outstanding reassemblies pending for each ITE. When the size of the reassembly buffer exceeds this high-water mark, the ETE actively discards incomplete reassemblies (e.g., using an Active Queue Management (AQM) strategy) until the size falls below the low-water mark. The ETE should also use a reduced IPv4 maximum segment lifetime value (e.g., 15 seconds), i.e., the time after which it will discard an incomplete IPv4 reassembly for a SEAL protocol packet. Finally, the ETE should also actively discard any pending reassemblies that clearly have no opportunity for completion, e.g., when a considerable number of new IPv4 fragments have been received before a fragment that completes a pending reassembly has arrived.
ETE正常执行IPv4重新组装，并应为每个ITE待完成的重新组装数量保持保守的高低水位线。当重新组装缓冲区的大小超过此高水位线时，ETE会主动丢弃不完整的重新组装（例如，使用主动队列管理（AQM）策略），直到大小降至低水位线以下。ETE还应使用减少的IPv4最大段生存期值（例如，15秒），即在该时间之后，ETE将放弃针对SEAL协议数据包的不完整IPv4重新组装。最后，ETE还应主动放弃任何显然没有机会完成的未决重组，例如，在完成未决重组的片段到达之前，已收到相当数量的新IPv4片段。
After reassembly, the ETE either accepts or discards the reassembled packet based on the current status of the IPv4 reassembly cache (congested versus uncongested). The SEAL_ID included in the IPv4 first fragment provides an additional level of reassembly assurance, since it can record a distinct arrival timestamp useful for associating the first fragment with its corresponding non-initial fragments. The choice of accepting/discarding a reassembly may also depend on the strength of the upper-layer integrity check if known (e.g., IPSec/ESP provides a strong upper-layer integrity check) and/or the corruption tolerance of the data (e.g., multicast streaming audio/video may be more corruption-tolerant than file transfer, etc.). In the limiting case, the ETE may choose to discard all IPv4 reassemblies and process only the IPv4 first fragment for SEAL-encapsulated error generation purposes (see the following sections).
重新组装后，ETE根据IPv4重新组装缓存的当前状态（拥挤与未拥挤）接受或丢弃重新组装的数据包。IPv4第一个片段中包含的SEAL_ID提供了额外的重组保证级别，因为它可以记录一个独特的到达时间戳，用于将第一个片段与其对应的非初始片段关联起来。接受/放弃重组的选择还可能取决于上层完整性检查的强度（如果已知）（例如，IPSec/ESP提供强大的上层完整性检查）和/或数据的损坏容忍度（例如，多播流音频/视频可能比文件传输等更耐损坏）。在限制性情况下，ETE可能会选择放弃所有IPv4重新组装，并仅处理IPv4第一个片段以生成密封封装的错误（请参阅以下部分）。
4.3.3. Generating SEAL-Encapsulated ICMPv4 Fragmentation Needed Messages
4.3.3. 生成密封封装的ICMPv4碎片所需消息
During IPv4-layer reassembly, the ETE determines whether the packet belongs to the SEAL protocol by checking for SEAL_PROTO in the outer IPv4 header (i.e., for simple IPv4 encapsulation) or for SEAL_PORT in the outer */IPv4 header (e.g., for '*'=UDP). When the ETE processes the IPv4 first fragment (i.e, one with DF=1 and Offset=0 in the IPv4 header) of a SEAL protocol IPv4 packet with (R=1; SEG=0) in the SEAL header, it sends a SEAL-encapsulated ICMPv4 Fragmentation Needed message back to the ITE with the MTU field set to 0. (Note that setting a non-zero value in the MTU field of the ICMPv4 Fragmentation Needed message would be redundant with the length value in the IPv4 header of the first fragment, since this value is set to the correct path MTU through in-the-network fragmentation. Setting the MTU field to 0 therefore avoids the ambiguous case in which the MTU field and the IPv4 length field of the first fragment would record different non-zero values.)
在IPv4层重新组装期间，ETE通过检查外部IPv4报头中的SEAL_协议（即简单IPv4封装）或外部*/IPv4报头中的SEAL_端口（例如，'*'=UDP），确定数据包是否属于SEAL协议。当ETE处理SEAL协议IPv4数据包的IPv4第一个片段（即，IPv4报头中DF=1和Offset=0的片段）和SEAL报头中的（R=1；SEG=0）时，ETE会将密封封装的ICMPv4碎片需要消息发送回ITE，MTU字段设置为0。（请注意，在ICMPv4 Fragmentation Required消息的MTU字段中设置非零值与第一个片段的IPv4标头中的长度值是冗余的，因为此值设置为网络片段中MTU通过的正确路径。因此，将MTU字段设置为0可避免MTU字段不明确的情况d和第一个片段的IPv4长度字段将记录不同的非零值。）
When the ETE processes a SEAL protocol IPv4 packet with (A=1; SEG=0) for which no IPv4 reassembly was required, or for which IPv4 reassembly was successful and the R bit was not set, it sends a SEAL-encapsulated ICMPv4 Fragmentation Needed message back to the ITE with the MTU value set to 0. Note therefore that when both the A and R bits are set and fragmentation occurs, the ETE only sends a single ICMPv4 Fragmentation Needed message, i.e., it does not send two separate messages (one for the first fragment and a second for the reassembled whole SEAL packet).
当ETE处理的密封协议IPv4数据包（a=1；SEG=0）不需要IPv4重新组装，或者IPv4重新组装成功且未设置R位时，ETE会将密封封装的ICMPv4碎片需要消息发送回ITE，MTU值设置为0。因此，请注意，当A和R位都设置且出现碎片时，ETE仅发送一条ICMPv4碎片所需消息，即它不发送两条单独的消息（一条用于第一个碎片，另一条用于重新组装的整个密封数据包）。
The ETE prepares the ICMPv4 Fragmentation Needed message by encapsulating as much of the first fragment (or the non-fragmented packet) as possible in outer */SEAL/*/IPv4 headers without the length of the message exceeding 576 bytes, as shown in Figure 3:
ETE通过将尽可能多的第一个片段（或非片段数据包）封装在outer*/SEAL/*/IPv4报头中而不使消息长度超过576字节来准备ICMPv4碎片所需的消息，如图3所示：
+-------------------------+ -
| | ~ Outer */SEAL/*/IPv4 hdrs~ |
| | |
+-------------------------+ |
| ICMPv4 Header | |
|(Dest Unreach; Frag Need)| |
+-------------------------+ |
| | > Up to 576 bytes
~ IP/*/SEAL/*/IPv4 ~ |
~ hdrs of packet/fragment ~ |
| | |
+-------------------------+ |
| | |
~ Data of packet/fragment ~ |
| | /
+-------------------------+ -
+-------------------------+ -
| | ~ Outer */SEAL/*/IPv4 hdrs~ |
| | |
+-------------------------+ |
| ICMPv4 Header | |
|(Dest Unreach; Frag Need)| |
+-------------------------+ |
| | > Up to 576 bytes
~ IP/*/SEAL/*/IPv4 ~ |
~ hdrs of packet/fragment ~ |
| | |
+-------------------------+ |
| | |
~ Data of packet/fragment ~ |
| | /
+-------------------------+ -
Figure 3: SEAL-Encapsulated ICMPv4 Fragmentation Needed Message
图3：需要密封封装的ICMPv4碎片消息
The ETE next sets A=0, R=0, and SEG=0 in the outer SEAL header, sets the SEAL_ID the same as for any SEAL packet, then sets the SEAL Next Header field and the fields of the outer */IPv4 headers the same as for ordinary SEAL encapsulation. The ETE then sets the outer IPv4 destination and source addresses to the source and destination addresses (respectively) of the packet/fragment. If the destination address in the packet/fragment was multicast, the ETE instead sets the outer IPv4 source address to an address assigned to the underlying IPv4 interface. The ETE finally sends the SEAL-encapsulated ICMPv4 message to the ITE the same as specified in Section 4.2.5, except that when the A bit in the packet/fragment is not set, the ETE sends the messages subject to rate limiting since it is not entirely critical that all fragmentation be reported to the ITE.
ETE接下来在外部密封头中设置A=0、R=0和SEG=0，将密封ID设置为与任何密封包相同，然后将密封下一个头字段和外部*/IPv4头字段设置为与普通密封封装相同。ETE然后将外部IPv4目标和源地址分别设置为数据包/片段的源地址和目标地址。如果数据包/片段中的目标地址是多播，ETE会将外部IPv4源地址设置为分配给基础IPv4接口的地址。ETE最终向ITE发送密封封装的ICMPv4消息，与第4.2.5节中规定的相同，但当数据包/片段中的A位未设置时，ETE发送消息时会受到速率限制，因为向ITE报告所有碎片并不完全重要。
Following IPv4 reassembly of a SEAL packet with (RSV!=0; SEG=0), if the packet is not a SEAL-encapsulated ICMPv4 message, the ETE generates a SEAL-encapsulated ICMPv4 Parameter Problem message with pointer set to the flags field in the SEAL header, sends the message back to the ITE in the same manner specified in Section 4.3.3, then drops the packet. For all other SEAL packets, the ETE adds the packet to a SEAL-Layer pending-reassembly queue if either the M bit or the SEG field in the SEAL header is non-zero.
在IPv4重新组装带有（RSV！=0；SEG=0）的密封数据包后，如果该数据包不是密封封装的ICMPv4消息，ETE生成密封封装的ICMPv4参数问题消息，指针设置为密封头中的标志字段，并以第4.3.3节规定的相同方式将该消息发送回ITE，然后丢下包。对于所有其他密封数据包，如果密封头中的M位或SEG字段非零，ETE将数据包添加到密封层待重新组装队列。
The ETE performs SEAL-layer reassembly through simple in-order concatenation of the encapsulated segments from N consecutive SEAL protocol packets from the same mid-layer packet. SEAL-layer
ETE通过将来自同一中间层数据包的N个连续SEAL协议数据包的封装段按顺序简单串联，执行密封层重组。密封层
reassembly requires the ETE to maintain a cache of recently received segments for a hold time that would allow for reasonable inter-segment delays. The ETE uses a SEAL maximum segment lifetime of 15 seconds for this purpose, i.e., the time after which it will discard an incomplete reassembly. However, the ETE should also actively discard any pending reassemblies that clearly have no opportunity for completion, e.g., when a considerable number of new SEAL packets have been received before a packet that completes a pending reassembly has arrived.
重新组装要求ETE在允许合理的段间延迟的保持时间内保持最近接收段的缓存。ETE为此目的使用最大密封段寿命为15秒，即在该时间之后，ETE将放弃不完整的重新组装。然而，ETE还应主动放弃任何明显没有机会完成的未决重新组装，例如，在完成未决重新组装的数据包到达之前已收到相当数量的新密封数据包。
The ETE reassembles the mid-layer packet segments in SEAL protocol packets that contain segment numbers 0 through N-1, with M=1/0 in non-final/final segments, respectively, and with consecutive SEAL_ID values. That is, for an N-segment mid-layer packet, reassembly entails the concatenation of the SEAL-encapsulated segments with (segment 0, SEAL_ID i), followed by (segment 1, SEAL_ID ((i + 1) mod 2^32)), etc. up to (segment N-1, SEAL_ID ((i + N-1) mod 2^32)). (For SEAL encapsulations specifically designed for traversal of IPv4 NATs, the ETE instead uses only a 16-bit SEAL_ID value, and uses mod 2^16 arithmetic to associate the segments of the same packet.)
ETE重新组装SEAL协议数据包中的中间层数据包段，这些数据包包含段号0到N-1，非最终/最终数据段中的M=1/0，并且具有连续的SEAL_ID值。也就是说，对于N段中间层分组，重新组装需要将密封封装段与（段0，密封ID i）连接起来，然后是（段1，密封ID（（i+1）mod 2^32））等，直到（段N-1，密封ID（（i+N-1）mod 2^32））。（对于专门为穿越IPv4 NAT而设计的密封封装，ETE只使用16位密封ID值，并使用mod 2^16算法关联同一数据包的段。）
Following SEAL-layer reassembly, the ETE silently discards the reassembled packet if it was a NULL packet (see Section 4.2.4). In the same manner, the ETE silently discards any reassembled mid-layer packet larger than (2KB - OHLEN) that either experienced IPv4 fragmentation or did not arrive as a single SEAL segment.
密封层重新组装后，如果重新组装的数据包为空数据包，ETE将自动丢弃该数据包（见第4.2.4节）。以同样的方式，ETE悄悄地丢弃任何重新组装的中间层数据包，该数据包大于（2KB-OHLEN），这些数据包要么经历了IPv4碎片，要么没有作为单个密封段到达。
Next, if the ETE determines that the inner packet would cause an ICMPv4 error message to be generated, it generates a SEAL-encapsulated ICMPv4 error message, sends the message back to the ITE in the same manner specified in Section 4.3.3, then either accepts or drops the packet according to the type of error. Otherwise, the ETE delivers the inner packet to the upper-layer protocol indicated in the Next Header field.
接下来，如果ETE确定内部数据包将导致生成ICMPv4错误消息，它将生成密封封装的ICMPv4错误消息，以第4.3.3节规定的相同方式将消息发送回ITE，然后根据错误类型接受或丢弃数据包。否则，ETE将内部数据包传送到下一个报头字段中指示的上层协议。
Section 4 specifies the operation of SEAL in "tunnel mode", i.e., when there are both an inner and outer IP layer with a SEAL encapsulation layer between. However, the SEAL protocol can also be used in a "transport mode" of operation within a subnetwork region in which the inner-layer corresponds to a transport layer protocol (e.g., UDP, TCP, etc.) instead of an inner IP layer.
第4节规定了“隧道模式”下的密封操作，即当内外IP层之间都有密封封装层时。然而，SEAL协议也可以在子网区域内的“传输模式”操作中使用，其中内层对应于传输层协议（例如，UDP、TCP等），而不是内部IP层。
For example, two TCP endpoints connected to the same subnetwork region can negotiate the use of transport-mode SEAL for a connection by inserting a 'SEAL_OPTION' TCP option during the connection establishment phase. If both TCPs agree on the use of SEAL, their protocol messages will be carried as TCP/SEAL/IPv4 and the connection will be serviced by the SEAL protocol using TCP (instead of an encapsulating tunnel endpoint) as the transport layer protocol. The SEAL protocol for transport mode otherwise observes the same specifications as for Section 4.
例如，连接到同一子网区域的两个TCP端点可以通过在连接建立阶段插入“SEAL_OPTION”TCP选项来协商连接的传输模式SEAL的使用。如果两个TCP都同意使用SEAL，则它们的协议消息将作为TCP/SEAL/IPv4进行传输，并且SEAL协议将使用TCP（而不是封装隧道端点）作为传输层协议为连接提供服务。运输模式的密封协议遵守与第4节相同的规范。
Subnetwork designers are expected to follow the recommendations in Section 2 of [RFC3819] when configuring link MTUs.
在配置链路MTU时，子网设计者应遵循[RFC3819]第2节中的建议。
SEAL provides robust mechanisms for returning PTB messages; however, end systems that send unfragmentable IP packets larger than 1500 bytes are strongly encouraged to use Packetization Layer Path MTU Discovery per [RFC4821].
SEAL为返回PTB消息提供了强大的机制；但是，强烈建议发送大于1500字节的不可拆分IP数据包的终端系统按照[RFC4821]使用数据包化层路径MTU发现。
IPv4 routers within the subnetwork are strongly encouraged to implement IPv4 fragmentation such that the first fragment is the largest and approximately the size of the underlying link MTU, i.e., they should avoid generating runt first fragments.
强烈鼓励子网内的IPv4路由器实施IPv4分段，以使第一个分段最大，且大约等于基础链路MTU的大小，即，它们应避免生成矮小的第一个分段。
SEAL_PROTO, SEAL_PORT, and SEAL_OPTION are taken from their respective range of experimental values documented in [RFC3692] and [RFC4727]. These values are for experimentation purposes only, and not to be used for any kind of deployments (i.e., they are not to be shipped in any products).
SEAL_PROTO、SEAL_PORT和SEAL_OPTION取自[RFC3692]和[RFC4727]中记录的各自实验值范围。这些值仅用于实验目的，不用于任何类型的部署（即，它们不会在任何产品中提供）。
Unlike IPv4 fragmentation, overlapping fragment attacks are not possible due to the requirement that SEAL segments be non-overlapping.
与IPv4碎片不同，重叠碎片攻击是不可能的，因为要求密封段不重叠。
An amplification/reflection attack is possible when an attacker sends IPv4 first fragments with spoofed source addresses to an ETE, resulting in a stream of ICMPv4 Fragmentation Needed messages
当攻击者向ETE发送带有伪造源地址的IPv4第一个片段时，可能会发生放大/反射攻击，从而产生ICMPv4碎片所需的消息流
returned to a victim ITE. The encapsulated segment of the spoofed IPv4 first fragment provides mitigation for the ITE to detect and discard spurious ICMPv4 Fragmentation Needed messages.
回到一个受害者那里。伪造的IPv4第一个片段的封装段为ITE检测和丢弃虚假ICMPv4碎片所需的消息提供了缓解措施。
The SEAL header is sent in-the-clear (outside of any IPsec/ESP encapsulations) the same as for the outer */IPv4 headers. As for IPv6 extension headers, the SEAL header is protected only by L2 integrity checks and is not covered under any L3 integrity checks.
SEAL标头以与外部*/IPv4标头相同的方式发送（在任何IPsec/ESP封装之外）。对于IPv6扩展头，SEAL头仅受二级完整性检查的保护，不受任何三级完整性检查的保护。
Section 3.1.7 of [RFC2764] provides a high-level sketch for supporting large tunnel MTUs via a tunnel-level segmentation and reassembly capability to avoid IP level fragmentation, which is in part the same approach used by tunnel-mode SEAL. SEAL could therefore be considered as a fully functioned manifestation of the method postulated by that informational reference; however, SEAL also supports other modes of operation including transport-mode and duplicate packet detection.
[RFC2764]第3.1.7节提供了通过隧道级分段和重新组装功能支持大型隧道MTU的高级草图，以避免IP级分段，这部分与隧道模式密封使用的方法相同。因此，印章可被视为该信息参考所假定的方法的一种功能完备的表现形式；但是，SEAL还支持其他操作模式，包括传输模式和重复数据包检测。
Section 3 of [RFC4459] describes inner and outer fragmentation at the tunnel endpoints as alternatives for accommodating the tunnel MTU; however, the SEAL protocol specifies a mid-layer segmentation and reassembly capability that is distinct from both inner and outer fragmentation.
[RFC4459]第3节描述了隧道端点处的内部和外部碎片，作为容纳隧道MTU的备选方案；但是，SEAL协议规定了一种中间层分段和重新组装能力，这与内部和外部分段不同。
Section 4 of [RFC2460] specifies a method for inserting and processing extension headers between the base IPv6 header and transport layer protocol data. The SEAL header is inserted and processed in exactly the same manner.
[RFC2460]的第4节规定了在基本IPv6报头和传输层协议数据之间插入和处理扩展报头的方法。密封集管的插入和处理方式完全相同。
The concepts of path MTU determination through the report of fragmentation and extending the IP Identification field were first proposed in deliberations of the TCP-IP mailing list and the Path MTU Discovery Working Group (MTUDWG) during the late 1980's and early 1990's. SEAL supports a report fragmentation capability using bits in an extension header (the original proposal used a spare bit in the IP header) and supports ID extension through a 16-bit field in an extension header (the original proposal used a new IP option). A historical analysis of the evolution of these concepts, as well as the development of the eventual path MTU discovery mechanism for IP, appears in Appendix A of this document.
20世纪80年代末和90年代初，TCP-IP邮件列表和路径MTU发现工作组（MTUDWG）在审议中首次提出了通过碎片报告确定路径MTU和扩展IP标识字段的概念。SEAL支持使用扩展标头中的位（原始方案在IP标头中使用了一个备用位）的报告分段功能，并支持通过扩展标头中的一个16位字段进行ID扩展（原始方案使用了一个新的IP选项）。本文件附录A中对这些概念的演变以及IP的最终路径MTU发现机制的发展进行了历史分析。
The SEAL approach offers a number of distinct advantages over the classical path MTU discovery methods [RFC1191] [RFC1981]:
与经典路径MTU发现方法[RFC1191][RFC1981]相比，SEAL方法具有许多明显的优势：
1. Classical path MTU discovery *always* results in packet loss when an MTU restriction is encountered. Using SEAL, IPv4 fragmentation provides a short-term interim mechanism for ensuring that packets are delivered while SEAL adjusts its packet sizing parameters.
1. 当遇到MTU限制时，经典路径MTU发现*始终*会导致数据包丢失。通过使用SEAL，IPv4分段提供了一种短期的临时机制，以确保在SEAL调整其数据包大小参数时发送数据包。
2. Classical path MTU discovery requires that routers generate an ICMP PTB message for *all* packets lost due to an MTU restriction; this situation is exacerbated at high data rates and becomes severe for in-the-network tunnels that service many communicating end systems. Since SEAL ensures that packets no larger than S_MRU are delivered, however, it is sufficient for the ETE to return ICMPv4 Fragmentation Needed messages subject to rate limiting and not for every packet-in-error.
2. 经典路径MTU发现要求路由器为因MTU限制而丢失的*所有*数据包生成ICMP PTB消息；这种情况在高数据速率下会加剧，并在为许多通信终端系统提供服务的网络隧道中变得严重。但是，由于SEAL确保发送的数据包不大于S_MRU，ETE可以根据速率限制返回ICMPv4碎片所需的消息，而不是返回每个出错的数据包。
3. Classical path MTU may require several iterations of dropping packets and returning ICMP PTB messages until an acceptable path MTU value is determined. Under normal circumstances, SEAL determines the correct packet sizing parameters in a single iteration.
3. 经典路径MTU可能需要多次丢弃数据包和返回ICMP PTB消息，直到确定可接受的路径MTU值。在正常情况下，SEAL在一次迭代中确定正确的数据包大小参数。
4. Using SEAL, ordinary packets serve as implicit probes without exposing data to unnecessary loss. SEAL also provides an explicit probing mode not available in the classic methods.
4. 使用SEAL，普通数据包充当隐式探测，而不会使数据暴露在不必要的丢失中。SEAL还提供了经典方法中不可用的显式探测模式。
5. Using SEAL, ETEs encapsulate ICMP error messages in an outer SEAL header such that packet-filtering network middleboxes can distinguish them from "raw" ICMP messages that may be generated by an attacker.
5. ETE使用SEAL将ICMP错误消息封装在外部SEAL头中，以便包过滤网络中间盒能够将其与攻击者可能生成的“原始”ICMP消息区分开来。
6. Most importantly, all SEAL packets have a 32-bit Identification value that can be used for duplicate packet detection purposes and to match ICMP error messages with actual packets sent without requiring per-packet state. Moreover, the SEAL ITE can be configured to accept ICMP feedback only from the legitimate ETE; hence, the packet spoofing-related denial-of-service attack vectors open to the classical methods are eliminated.
6. 最重要的是，所有SEAL数据包都具有32位标识值，可用于重复数据包检测目的，并将ICMP错误消息与发送的实际数据包相匹配，而无需每个数据包的状态。此外，SEAL-ITE可配置为仅接受来自合法ETE的ICMP反馈；因此，消除了经典方法中与数据包欺骗相关的拒绝服务攻击向量。
In summary, the SEAL approach represents an architecturally superior method for ensuring that packets of various sizes are either delivered or deterministically dropped. When end systems use their own end-to-end MTU determination mechanisms [RFC4821], the SEAL advantages are further enhanced.
总之，SEAL方法代表了一种架构上优越的方法，用于确保各种大小的数据包要么被交付，要么被决定性地丢弃。当终端系统使用其自己的端到端MTU确定机制[RFC4821]时，密封优势进一步增强。
The following individuals are acknowledged for helpful comments and suggestions: Jari Arkko, Fred Baker, Iljitsch van Beijnum, Teco Boot, Bob Braden, Brian Carpenter, Steve Casner, Ian Chakeres, Remi Denis-Courmont, Aurnaud Ebalard, Gorry Fairhurst, Joel Halpern, John Heffner, Thomas Henderson, Bob Hinden, Christian Huitema, Joe Macker, Matt Mathis, Erik Nordmark, Dan Romascanu, Dave Thaler, Joe Touch, Magnus Westerlund, Robin Whittle, James Woodyatt, and members of the Boeing PhantomWorks DC&NT group.
以下个人的有用意见和建议得到了认可：贾里·阿尔科、弗雷德·贝克、伊尔吉茨·范·贝伊纳姆、特科·布特、鲍勃·布拉登、布赖恩·卡彭特、史蒂夫·卡斯纳、伊恩·查克斯、雷米·丹尼斯·库尔蒙、奥纳德·埃巴拉德、戈里·费尔赫斯特、乔尔·哈尔彭、约翰·赫夫纳、托马斯·亨德森、鲍勃·欣登、克里斯蒂安·惠特马、乔·麦克尔，Matt Mathis、Erik Nordmark、Dan Romascanu、Dave Thaler、Joe Touch、Magnus Westerlund、Robin Whittle、James Woodyatt以及波音幻影工厂DC&NT集团的成员。
Path MTU determination through the report of fragmentation was first proposed by Charles Lynn on the TCP-IP mailing list in 1987. Extending the IP identification field was first proposed by Steve Deering on the MTUDWG mailing list in 1989.
1987年，Charles Lynn在TCP-IP邮件列表上首次提出通过碎片报告确定MTU路径。1989年，Steve Deering在MTUDWG邮件列表中首次提出了扩展IP标识字段的建议。
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC0791]Postel，J.，“互联网协议”，STD 5，RFC 7911981年9月。
[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981.
[RFC0792]Postel，J.，“互联网控制消息协议”，STD 5，RFC 792，1981年9月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460]Deering，S.和R.Hinden，“互联网协议，第6版（IPv6）规范”，RFC 2460，1998年12月。
[FOLK] C, C., D, D., and k. k, "Beyond Folklore: Observations on Fragmented Traffic", December 2002.
C，C，D，D，k。k、 “超越民俗：对零散交通的观察”，2002年12月。
[FRAG] Kent, C. and J. Mogul, "Fragmentation Considered Harmful", October 1987.
[FRAG]Kent，C.和J.Mogul，“碎片化被认为是有害的”，1987年10月。
[MTUDWG] "IETF MTU Discovery Working Group mailing list, gatekeeper.dec.com/pub/DEC/WRL/mogul/mtudwg-log, November 1989 - February 1995.".
[MTUDWG]“IETF MTU发现工作组邮件列表，gatekeeper.dec.com/pub/dec/WRL/mogul/MTUDWG-log，1989年11月-1995年2月。”。
[RFC1063] Mogul, J., Kent, C., Partridge, C., and K. McCloghrie, "IP MTU discovery options", RFC 1063, July 1988.
[RFC1063]Mogul，J.，Kent，C.，Partridge，C.，和K.McCloghrie，“IP MTU发现选项”，RFC 1063，1988年7月。
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990.
[RFC1191]Mogul，J.和S.Deering，“MTU发现路径”，RFC1191，1990年11月。
[RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, August 1996.
[RFC1981]McCann，J.，Deering，S.，和J.Mogul，“IP版本6的路径MTU发现”，RFC 1981，1996年8月。
[RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996.
[RFC2003]Perkins，C.，“IP内的IP封装”，RFC 2003，1996年10月。
[RFC2004] Perkins, C., "Minimal Encapsulation within IP", RFC 2004, October 1996.
[RFC2004]Perkins，C.，“IP内的最小封装”，RFC 2004，1996年10月。
[RFC2764] Gleeson, B., Lin, A., Heinanen, J., Armitage, G., and A. Malis, "A Framework for IP Based Virtual Private Networks", RFC 2764, February 2000.
[RFC2764]Gleeson，B.，Lin，A.，Heinanen，J.，Armitage，G.，和A.Malis，“基于IP的虚拟专用网络框架”，RFC 2764，2000年2月。
[RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery", RFC 2923, September 2000.
[RFC2923]Lahey，K.，“路径MTU发现的TCP问题”，RFC 29232000年9月。
[RFC3692] Narten, T., "Assigning Experimental and Testing Numbers Considered Useful", BCP 82, RFC 3692, January 2004.
[RFC3692]Narten，T.，“分配被认为有用的实验和测试数字”，BCP 82，RFC 3692，2004年1月。
[RFC3819] Karn, P., Ed., Bormann, C., Fairhurst, G., Grossman, D., Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L. Wood, "Advice for Internet Subnetwork Designers", BCP 89, RFC 3819, July 2004.
[RFC3819]Karn，P.，Ed.，Bormann，C.，Fairhurst，G.，Grossman，D.，Ludwig，R.，Mahdavi，J.，黑山，G.，Touch，J.，和L.Wood，“互联网子网络设计师的建议”，BCP 89，RFC 3819，2004年7月。
[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for IPv6 Hosts and Routers", RFC 4213, October 2005.
[RFC4213]Nordmark，E.和R.Gilligan，“IPv6主机和路由器的基本转换机制”，RFC 4213，2005年10月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]Kent，S.和K.Seo，“互联网协议的安全架构”，RFC 43012005年12月。
[RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)", RFC 4380, February 2006.
[RFC4380]Huitema，C.，“Teredo：通过网络地址转换（NAT）通过UDP传输IPv6”，RFC 43802006年2月。
[RFC4459] Savola, P., "MTU and Fragmentation Issues with In-the-Network Tunneling", RFC 4459, April 2006.
[RFC4459]Savola，P.，“网络隧道中的MTU和碎片问题”，RFC 4459，2006年4月。
[RFC4727] Fenner, B., "Experimental Values In IPv4, IPv6, ICMPv4, ICMPv6, UDP, and TCP Headers", RFC 4727, November 2006.
[RFC4727]Fenner，B.，“IPv4、IPv6、ICMPv4、ICMPv6、UDP和TCP报头中的实验值”，RFC 4727，2006年11月。
[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU Discovery", RFC 4821, March 2007.
[RFC4821]Mathis，M.和J.Heffner，“打包层路径MTU发现”，RFC 48212007年3月。
[RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly Errors at High Data Rates", RFC 4963, July 2007.
[RFC4963]Heffner，J.，Mathis，M.，和B.Chandler，“高数据速率下的IPv4重组错误”，RFC 4963，2007年7月。
[TCP-IP] "Archive/Hypermail of Early TCp-IP Mail List", http://www-mice.cs.ucl.ac.uk/multimedia/misc/tcp_ip/, May 1987 - May 1990.
[TCP-IP]“早期TCP IP邮件列表的存档/超级邮件”，http://www-mice.cs.ucl.ac.uk/multimedia/misc/tcp_ip/，1987年5月至1990年5月。
(Taken from "Neighbor Affiliation Protocol for IPv6-over-(foo)-over-IPv4"; written 10/30/2002):
（摘自“IPv6 over-（foo）-over-IPv4的邻居从属协议”；编写于2002年10月30日）：
The topic of Path MTU discovery (PMTUD) saw a flurry of discussion and numerous proposals in the late 1980's through early 1990. The initial problem was posed by Art Berggreen on May 22, 1987 in a message to the TCP-IP discussion group [TCP-IP]. The discussion that followed provided significant reference material for [FRAG]. An IETF Path MTU Discovery Working Group [MTUDWG] was formed in late 1989 with charter to produce an RFC. Several variations on a very few basic proposals were entertained, including:
在20世纪80年代末到90年代初，MTU路径发现（PMTUD）这一主题引起了一阵讨论，并提出了许多建议。最初的问题是由Art Berggreen于1987年5月22日在给TCP-IP讨论组[TCP-IP]的一封邮件中提出的。随后的讨论为[FRAG]提供了重要的参考资料。IETF Path MTU发现工作组[MTUDWG]于1989年末成立，其章程旨在生成RFC。对极少数基本提案进行了几次修改，包括：
1. Routers record the PMTUD estimate in ICMP-like path probe messages (proposed in [FRAG] and later [RFC1063])
1. 路由器在类似ICMP的路径探测消息中记录PMTUD估计值（在[FRAG]和更高版本[RFC1063]中提出）
2. The destination reports any fragmentation that occurs for packets received with the "RF" (Report Fragmentation) bit set (Steve Deering's 1989 adaptation of Charles Lynn's Nov. 1987 proposal)
2. 目的地报告使用“RF”（报告碎片）位集接收的数据包出现的任何碎片（Steve Deering 1989年对Charles Lynn 1987年11月提案的改编）
3. A hybrid combination of 1) and Charles Lynn's Nov. 1987 (straw RFC draft by McCloughrie, Fox and Mogul on Jan 12, 1990)
3. 1987年11月，查尔斯·林恩（Charles Lynn）和《麦考弗里、福克斯和莫卧儿（Mogul）于1990年1月12日撰写的草编RFC草稿》（straw RFC草稿）
4. Combination of the Lynn proposal with TCP (Fred Bohle, Jan 30, 1990)
4. Lynn提案与TCP的结合（Fred Bohle，1990年1月30日）
5. Fragmentation avoidance by setting "IP_DF" flag on all packets and retransmitting if ICMPv4 "fragmentation needed" messages occur (Geof Cooper's 1987 proposal; later adapted into [RFC1191] by Mogul and Deering).
5. 通过在所有数据包上设置“IP_DF”标志并在出现ICMPv4“需要碎片”消息时重新传输来避免碎片（Geof Cooper 1987年的提案；后来由Mogul和Deering改编为[RFC1191]）。
Option 1) seemed attractive to the group at the time, since it was believed that routers would migrate more quickly than hosts. Option 2) was a strong contender, but repeated attempts to secure an "RF" bit in the IPv4 header from the IESG failed and the proponents became discouraged. 3) was abandoned because it was perceived as too complicated, and 4) never received any apparent serious consideration. Proposal 5) was a late entry into the discussion from Steve Deering on Feb. 24th, 1990. The discussion group soon thereafter seemingly lost track of all other proposals and adopted 5), which eventually evolved into [RFC1191] and later [RFC1981].
选项1）当时似乎对该团队很有吸引力，因为人们认为路由器的迁移速度比主机快。选项2）是一个强有力的竞争者，但多次试图从IESG获得IPv4报头中的“RF”位的尝试都失败了，支持者们变得灰心丧气。3） 被放弃是因为它被认为太复杂了，而且从未得到任何明显的认真考虑。提案5）是Steve Deering于1990年2月24日晚加入讨论的项目。此后不久，讨论小组似乎失去了所有其他提案的踪迹，并通过了第5条），最终演变为[RFC1191]和[RFC1981]。
In retrospect, the "RF" bit postulated in 2) is not needed if a "contract" is first established between the peers, as in proposal 4) and a message to the MTUDWG mailing list from jrd@PTT.LCS.MIT.EDU on Feb 19. 1990. These proposals saw little discussion or rebuttal, and were dismissed based on the following the assertions:
回想起来，如果在对等方之间首先建立了“合同”（如提案4）并从中向MTUDWG邮件列表发送消息，则不需要2）中假定的“RF”位jrd@PTT.LCS.MIT.EDU2月19日。1990这些建议很少受到讨论或反驳，并基于以下主张而被驳回：
o routers upgrade their software faster than hosts
o 路由器升级软件的速度比主机快
o PCs could not reassemble fragmented packets
o PC无法重新组装碎片数据包
o Proteon and Wellfleet routers did not reproduce the "RF" bit properly in fragmented packets
o Proteon和Wellfleet路由器没有在碎片数据包中正确复制“RF”位
o Ethernet-FDDI bridges would need to perform fragmentation (i.e., "translucent" not "transparent" bridging)
o 以太网FDDI网桥需要执行分段（即，“半透明”而非“透明”网桥）
o the 16-bit IP_ID field could wrap around and disrupt reassembly at high packet arrival rates
o 16位IP_ID字段可能在高数据包到达率下缠绕并中断重新组装
The first four assertions, although perhaps valid at the time, have been overcome by historical events leaving only the final to consider. But, [FOLK] has shown that IP_ID wraparound simply does not occur within several orders of magnitude the reassembly timeout window on high-bandwidth networks.
前四个断言，尽管也许当时是有效的，已经被历史事件所克服，只剩下最后要考虑的。但是，[FOLK]已经表明，IP_ID环绕并不会在高带宽网络上重组超时窗口的几个数量级内发生。
(Author's 2/11/08 note: this final point was based on a loose interpretation of [FOLK], and is more accurately addressed in [RFC4963].)
（作者2008年11月2日注：这最后一点是基于对[民俗]的松散解释，在[RFC4963]中有更准确的阐述。）
The SEAL header includes a Reserved (RSV) field that is set to zero for the purpose of this specification. This field may be used by future updates to this specification for the purpose of improved reliability in the face of loss due to congestion, signal intermittence, etc. Automatic Repeat-ReQuest (ARQ) mechanisms are used to ensure reliable delivery between the endpoints of physical links (e.g., on-link neighbors in an IEEE 802.11 network) as well as between the endpoints of an end-to-end transport (e.g., the endpoints of a TCP connection). However, ARQ mechanisms may be poorly suited to in-the-network elements such as the SEAL ITE and ETE, since retransmission of lost segments would require unacceptable state maintenance at the ITE and would result in packet reordering within the subnetwork.
密封头包括一个保留（RSV）字段，该字段在本规范中设置为零。该字段可用于本规范的未来更新，以提高因拥塞、信号间歇等造成的丢失时的可靠性。自动重复请求（ARQ）机制用于确保物理链路端点之间的可靠传输（例如，IEEE 802.11网络中的链路邻居）以及端到端传输的端点之间（例如，TCP连接的端点）。然而，ARQ机制可能不适合在诸如SEAL-ITE和ETE之类的网络元件中使用，因为丢失段的重新传输将需要在ITE处进行不可接受的状态维护，并且将导致子网内的分组重新排序。
Instead, alternate reliability mechanisms such as Forward Error Correction (FEC) may be specified in future updates to this specification for the purpose of improved reliability. Such mechanisms may entail the ITE performing proactive transmissions of redundant data, e.g., by sending multiple copies of the same data. Signaling from the ETE (e.g., by sending SEAL-encapsulated ICMPv4 Source Quench messages) may be specified in a future document as a means for the ETE to dynamically inform the ITE of changing FEC conditions.
相反，为了提高可靠性，可在本规范的未来更新中指定替代可靠性机制，如前向纠错（FEC）。此类机制可能需要ITE执行冗余数据的主动传输，例如，通过发送相同数据的多个副本。来自ETE的信令（例如，通过发送密封封装的ICMPv4源猝灭消息）可以在未来的文档中指定为ETE动态通知ITE FEC条件变化的手段。
Author's Address
作者地址
Fred L. Templin, Editor Boeing Research & Technology P.O. Box 3707 Seattle, WA 98124 USA
Fred L.Templin，编辑波音研究与技术公司美国华盛顿州西雅图3707号邮政信箱98124
EMail: fltemplin@acm.org
EMail: fltemplin@acm.org