Internet Architecture Board (IAB) T. Hardie, Ed.
Request for Comments: 8558 April 2019
Category: Informational
ISSN: 2070-1721
Internet Architecture Board (IAB) T. Hardie, Ed.
Request for Comments: 8558 April 2019
Category: Informational
ISSN: 2070-1721
Transport Protocol Path Signals
传输协议路径信号
Abstract
摘要
This document discusses the nature of signals seen by on-path elements examining transport protocols, contrasting implicit and explicit signals. For example, TCP's state machine uses a series of well-known messages that are exchanged in the clear. Because these are visible to network elements on the path between the two nodes setting up the transport connection, they are often used as signals by those network elements. In transports that do not exchange these messages in the clear, on-path network elements lack those signals. Often, the removal of those signals is intended by those moving the messages to confidential channels. Where the endpoints desire that network elements along the path receive these signals, this document recommends explicit signals be used.
本文档讨论了检查传输协议的路径元素所看到的信号的性质，对比了隐式和显式信号。例如，TCP的状态机使用一系列在clear中交换的已知消息。由于这些信号对建立传输连接的两个节点之间的路径上的网络元件可见，因此它们通常被这些网络元件用作信号。在不以透明方式交换这些消息的传输中，路径上的网络元素缺少这些信号。通常，那些将消息移动到机密通道的人打算删除这些信号。如果端点希望沿路径的网络元素接收这些信号，本文档建议使用显式信号。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This document is a product of the Internet Architecture Board (IAB) and represents information that the IAB has deemed valuable to provide for permanent record. It represents the consensus of the Internet Architecture Board (IAB). Documents approved for publication by the IAB are not candidates for any level of Internet Standard; see Section 2 of RFC 7841.
本文件是互联网体系结构委员会（IAB）的产品，代表IAB认为有价值提供永久记录的信息。它代表了互联网体系结构委员会（IAB）的共识。IAB批准发布的文件不适用于任何级别的互联网标准；见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8558.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8558.
Copyright Notice
版权公告
Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.
版权（c）2019 IETF信托基金和被确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
Table of Contents
目录
1. Introduction ....................................................3
2. Signal Types Inferred ...........................................4
2.1. Session Establishment ......................................4
2.1.1. Session Identity ....................................4
2.1.2. Routability and Intent ..............................4
2.1.3. Flow Stability ......................................5
2.1.4. Resource Requirements ...............................5
2.2. Network Measurement ........................................5
2.2.1. Path Latency ........................................5
2.2.2. Path Reliability and Consistency ....................5
3. Options .........................................................5
3.1. Do Not Restore These Signals ...............................6
3.2. Replace These with Network-Layer Signals ...................6
3.3. Replace These with Per-Transport Signals ...................6
3.4. Create a Set of Signals Common to Multiple Transports ......6
4. Recommendation ..................................................7
5. IANA Considerations .............................................8
6. Security Considerations .........................................8
7. Informative References ..........................................9
IAB Members at the Time of Approval ...............................10
Acknowledgements ..................................................10
Author's Address ..................................................10
1. Introduction ....................................................3
2. Signal Types Inferred ...........................................4
2.1. Session Establishment ......................................4
2.1.1. Session Identity ....................................4
2.1.2. Routability and Intent ..............................4
2.1.3. Flow Stability ......................................5
2.1.4. Resource Requirements ...............................5
2.2. Network Measurement ........................................5
2.2.1. Path Latency ........................................5
2.2.2. Path Reliability and Consistency ....................5
3. Options .........................................................5
3.1. Do Not Restore These Signals ...............................6
3.2. Replace These with Network-Layer Signals ...................6
3.3. Replace These with Per-Transport Signals ...................6
3.4. Create a Set of Signals Common to Multiple Transports ......6
4. Recommendation ..................................................7
5. IANA Considerations .............................................8
6. Security Considerations .........................................8
7. Informative References ..........................................9
IAB Members at the Time of Approval ...............................10
Acknowledgements ..................................................10
Author's Address ..................................................10
This document discusses the nature of signals seen by on-path elements examining transport protocols, contrasting implicit and explicit signals. For example, TCP's state machine uses a series of well-known messages that are exchanged in the clear. Because these are visible to network elements on the path between the two nodes setting up the transport connection, they are often used as signals by those network elements. While the architecture of the Internet may be best realized by end-to-end protocols [RFC1958], there are cases such as the use of Network Address Translators [RFC3234] where some functions are commonly provided by on-path network elements. In transports that do not exchange these messages in the clear, on-path network elements lack those signals. Often, the removal of those signals is intended by those moving the messages to confidential channels. Where the endpoints desire that network elements along the path receive these signals, this document recommends explicit signals be used.
本文档讨论了检查传输协议的路径元素所看到的信号的性质，对比了隐式和显式信号。例如，TCP的状态机使用一系列在clear中交换的已知消息。由于这些信号对建立传输连接的两个节点之间的路径上的网络元件可见，因此它们通常被这些网络元件用作信号。虽然互联网的体系结构最好通过端到端协议[RFC1958]实现，但也有一些情况，例如使用网络地址转换器[RFC3234]，其中一些功能通常由路径上的网络元件提供。在不以透明方式交换这些消息的传输中，路径上的网络元素缺少这些信号。通常，那些将消息移动到机密通道的人打算删除这些信号。如果端点希望沿路径的网络元素接收这些信号，本文档建议使用显式信号。
The interpretation of TCP [RFC0793] by on-path elements is an example of implicit signal usage. It uses cleartext handshake messages to establish, maintain, and close connections. While these are primarily intended to create state between two communicating nodes, these handshake messages are visible to network elements along the path between them. It is common for certain network elements to treat the exchanged messages as signals that relate to their own functions.
路径元素对TCP[RFC0793]的解释是隐式信号使用的一个示例。它使用明文握手消息来建立、维护和关闭连接。虽然这些握手消息主要用于在两个通信节点之间创建状态，但这些握手消息对它们之间路径上的网络元素是可见的。某些网络元件通常将交换的消息视为与其自身功能相关的信号。
A firewall may, for example, create a rule that allows traffic from a specific host and port to enter its network when the connection was initiated by a host already within the network. It may subsequently remove that rule when the communication has ceased. In the context of TCP handshake, it sets up the pinhole rule on seeing the initial TCP SYN acknowledgement and then removes it upon seeing a RST or FIN and ACK exchange. Note that in this case, it does nothing to rewrite any portion of the TCP packet; it simply enables a return path that would otherwise have been blocked.
例如，防火墙可以创建一个规则，当连接由网络中已经存在的主机启动时，该规则允许来自特定主机和端口的流量进入其网络。它随后可在通信停止时删除该规则。在TCP握手的上下文中，它在看到初始TCP SYN确认时设置针孔规则，然后在看到RST或FIN和ACK交换时将其删除。注意，在这种情况下，它不重写TCP数据包的任何部分；它只是启用了一条原本会被阻塞的返回路径。
When a transport encrypts the fields it uses for state mechanics, these signals are no longer accessible to path elements. The behavior of path elements will then depend on which signal is not available, on the default behavior configured by the path element administrator, and by the security posture of the network as a whole.
当传输对其用于状态机制的字段进行加密时，路径元素将无法再访问这些信号。然后，路径元素的行为将取决于哪个信号不可用、路径元素管理员配置的默认行为以及整个网络的安全态势。
The following list of signals that may be inferred from transport state messages includes those that may be exchanged during session establishment and those that derive from the ongoing flow.
以下可从传输状态消息推断的信号列表包括可在会话建立期间交换的信号和源自正在进行的流的信号。
Some of these signals are derived from the direct examination of packet sequences, such as using a sequence number gap pattern to infer network reliability; others are derived from association, such as inferring network latency by timing a flow's packet inter-arrival times.
其中一些信号来自于对分组序列的直接检查，例如使用序列号间隔模式来推断网络可靠性；另一些是从关联中派生出来的，例如通过对流的数据包到达时间计时来推断网络延迟。
This list is not exhaustive, and it is not the full set of effects due to encrypting data and metadata in flight. Note as well that because these are derived from inference, they do not include any path signals that would not be relevant to the endpoint state machines; indeed, an inference-based system cannot send such signals.
此列表并非详尽无遗，而且由于在飞行中对数据和元数据进行加密，它也不是完整的效果集。还要注意的是，因为这些都是从推理中派生出来的，所以它们不包括任何与端点状态机无关的路径信号；事实上，基于推理的系统无法发送这样的信号。
One of the most basic inferences made by examination of transport state is that a packet will be part of an ongoing flow; that is, an established session will continue until messages are received that terminate it. Path elements may then make subsidiary inferences related to the session.
通过检查传输状态得出的最基本推论之一是，数据包将是正在进行的流的一部分；也就是说，已建立的会话将继续，直到收到终止会话的消息为止。路径元素随后可以作出与会话相关的辅助推断。
Path elements that track session establishment will typically create a session identity for the flow, commonly using a tuple of the visible information in the packet headers. This is then used to associate other information with the flow.
跟踪会话建立的路径元素通常会为流创建会话标识，通常使用数据包头中可见信息的元组。然后，这将用于将其他信息与流关联。
A second common inference that session establishment provides is that the communicating pair of hosts can each reach each other and are interested in continuing communication. The firewall example given above is a consequence of that inference; because the internal host initiates the connection, it is presumed to want to receive return traffic. That, in turn, justifies the pinhole.
会话建立提供的第二个常见推论是，通信的主机对可以彼此联系，并且对继续通信感兴趣。上面给出的防火墙示例就是该推断的结果；由于内部主机启动连接，因此假定它希望接收返回流量。这反过来证明了针孔的合理性。
Some other on-path elements assume that a host that asked to communicate with a remote address has authorized receiving incoming communications from any other host (e.g., Endpoint-Independent Mapping or Endpoint-Independent Filtering [RFC7857]). This is, for example, the default behavior in Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers (NAT64).
一些其他路径上元素假定请求与远程地址通信的主机已授权接收来自任何其他主机的传入通信（例如，端点独立映射或端点独立筛选[RFC7857]）。例如，这是从IPv6客户端到IPv4服务器（NAT64）的网络地址和协议转换中的默认行为。
Some on-path devices that are responsible for load-sharing or load-balancing may be instructed to preserve the same path for a given flow rather than dispatching packets belonging to the same flow on multiple paths as this may cause packets in the flow to be delivered out of order.
一些负责负载共享或负载平衡的路径上设备可以被指示为给定流保留相同的路径，而不是在多个路径上调度属于相同流的分组，因为这可能导致流中的分组被无序地传送。
An additional common inference is that network resources will be required for the session. These may be requirements within the network element itself, such as table entry space for a firewall or NAT; they may also be communicated by the network element to other systems. For networks that use resource reservations, this might result in reservation of radio air time, energy, or network capacity.
另一个常见的推论是会话将需要网络资源。这些可能是网元本身内的要求，例如防火墙或NAT的表条目空间；它们也可以由网元传送到其他系统。对于使用资源预留的网络，这可能会导致保留无线电广播时间、能量或网络容量。
Some network elements will also observe transport messages to engage in measurement of the paths that are used by flows on their network. The list of measurements below is illustrative, not exhaustive.
一些网元还将观察传输消息，以测量其网络上的流所使用的路径。下面的测量列表是说明性的，并非详尽无遗。
There are several ways in which a network element may measure path latency using transport messages, but two common ones are examining exposed timestamps and associating sequence numbers with a local timer. These measurements are necessarily limited to measuring only the portion of the path between the system that assigned the timestamp or sequence number and the network element.
网元可以通过几种方式使用传输消息测量路径延迟，但有两种常见方式是检查公开的时间戳和将序列号与本地计时器关联。这些测量必须仅限于测量分配时间戳或序列号的系统与网络元件之间的路径部分。
A network element may also measure the reliability of a particular path by examining sessions that expose sequence numbers; retransmissions and gaps are then associated with the path segments on which they might have occurred.
网元还可以通过检查公开序列号的会话来测量特定路径的可靠性；然后，重传和间隙与可能发生重传和间隙的路径段相关联。
The set of options below are alternatives that optimize very different things. Though it comes to a preliminary conclusion, this document intends to foster a discussion of those trade-offs, and any discussion of them must be understood as preliminary.
下面的一组选项是优化非常不同事物的备选方案。虽然得出了初步结论，但本文件旨在促进对这些权衡的讨论，对它们的任何讨论都必须理解为初步的。
It is possible, of course, to do nothing. The transport messages were not necessarily intended for consumption by on-path network elements, and encrypting them so they are not visible may be taken by some as a benefit. Each network element would then treat packets without these visible elements according to its own defaults. While our experience of that is not extensive, one consequence has been that state tables for flows of this type are generally not kept as long as those for which sessions are identifiable. The result is that heartbeat traffic must be maintained to keep any bindings (e.g., NAT or firewall) from early expiry. When those bindings are not kept, methods like a QUIC connection-id [QUIC] may be necessary to allow load balancers or other systems to continue to maintain a flow's path to the appropriate peer.
当然，什么也不做是可能的。传输消息不一定是供路径上的网络元素使用的，对其进行加密以使其不可见可能被一些人视为一种好处。然后，每个网络元素将根据自己的默认值处理没有这些可见元素的数据包。虽然我们在这方面的经验并不广泛，但一个结果是，这种类型的流的状态表通常不会像会话可识别的流那样长期保存。结果是必须维护心跳流量，以防止任何绑定（例如NAT或防火墙）提前到期。当不保留这些绑定时，可能需要像QUIC连接id[QUIC]这样的方法来允许负载平衡器或其他系统继续维护流到适当对等方的路径。
It would be possible to replace these implicit signals with explicit signals at the network layer. Though IPv4 has relatively few facilities for this, IPv6 hop-by-hop headers [RFC7045] might suit this purpose. Further examination of the deployability of these headers may be required.
可以在网络层用显式信号替换这些隐式信号。虽然IPv4对此的功能相对较少，但IPv6逐跳标头[RFC7045]可能适合此用途。可能需要进一步检查这些封头的可展开性。
It is possible to replace these implicit signals with signals that are tailored to specific transports, just as the initial signals are derived primarily from TCP. There is a risk here that the first transport that develops these will be reused for many purposes outside its stated purpose, simply because it traverses NATs and firewalls better than other traffic. If done with an explicit intent to reuse the elements of the solution in other transports, the risk of ossification might be slightly lower.
可以将这些隐式信号替换为针对特定传输的信号，就像初始信号主要来自TCP一样。这里存在一个风险，即开发这些功能的第一个传输将被重用用于其声明用途之外的许多用途，这仅仅是因为它比其他通信更好地穿越NAT和防火墙。如果明确打算在其他运输中重复使用溶液的成分，骨化的风险可能会略低。
Several proposals use UDP [RFC0768] as a demux layer, onto which new transport semantics are layered. For those transports, it may be possible to build a common signaling mechanism and set of signals, such as that proposed in "Transport-Independent Path Layer State Management" [PLUS].
有几个方案使用UDP[RFC0768]作为解复用层，新的传输语义被分层到该层上。对于这些传输，可以构建公共信令机制和信号集，如“传输独立路径层状态管理”[PLUS]中提出的。
This may be taken as a variant of the reuse of common elements mentioned in the section above, but it has a greater chance of avoiding the ossification of the solution into the first moving protocol.
这可以看作是上述部分中提到的公共元素重用的一种变体，但它有更大的机会避免将解决方案僵化为第一个移动协议。
The IAB urges protocol designers to design for confidential operation by default. We strongly encourage developers to include encryption in their implementations and to make them encrypted by default. We similarly encourage network and service operators to deploy encryption where it is not yet deployed, and we urge firewall policy administrators to permit encrypted traffic. One of the consequences of the change will be the loss of implicit signals.
IAB敦促协议设计者在默认情况下为保密操作进行设计。我们强烈鼓励开发人员在其实现中包含加密，并在默认情况下对其进行加密。我们同样鼓励网络和服务运营商在尚未部署加密的地方部署加密，并敦促防火墙策略管理员允许加密流量。这种变化的后果之一是隐式信号的丢失。
Fundamentally, this document recommends that implicit signals should be avoided and that an implicit signal should be replaced with an explicit signal only when the signal's originator intends that it be used by the network elements on the path. For many flows, this may result in the signal being absent but allows it to be present when needed.
从根本上说，本文件建议应避免隐式信号，并且仅当信号的发起者希望路径上的网络元件使用隐式信号时，才应将其替换为显式信号。对于许多流，这可能导致信号缺失，但允许在需要时出现。
Discussion of the appropriate mechanism(s) for these signals is continuing, but at a minimum, any method should aim to adhere to these basic principles:
关于这些信号的适当机制的讨论仍在继续，但至少，任何方法都应遵循以下基本原则：
o The portion of protocol signaling that is intended for end-system state machines should be protected by confidentiality and integrity protection such that it is only available to those end systems.
o 用于终端系统状态机的协议信令部分应通过保密性和完整性保护进行保护，以便仅对这些终端系统可用。
o Anything exposed to the path should be done with the intent that it be used by the network elements on the path. This information should be integrity protected, so that end systems can detect if path elements have made changes in flight.
o 任何暴露于路径的操作都应该是为了让路径上的网络元素使用它。该信息应受到完整性保护，以便终端系统能够检测路径元素是否在飞行中发生了变化。
o Signals exposed to the path should be decoupled from signals that drive the protocol state machines in endpoints. This avoids creating opportunities for additional inference.
o 暴露于路径的信号应与驱动端点中协议状态机的信号解耦。这避免了产生额外推断的机会。
o Intermediate path elements should not add visible signals that identify the user, origin node, or origin network [RFC8164]. Note that if integrity protection is provided as suggested above, any signals added by intermediate path elements will be clearly distinguishable from those added by endpoints, as they will not be within the integrity-protected portion of the packet.
o 中间路径元素不应添加标识用户、源节点或源网络的可见信号[RFC8164]。注意，如果如上所述提供完整性保护，则由中间路径元素添加的任何信号将与由端点添加的信号明确区分，因为它们将不在数据包的完整性保护部分内。
The IAB notes that methods for allowing on-path actors to verify integrity protection are not available unless those actors have shared keys with the end systems or share a common set of trust points. As a result, integrity protection can generally be reliably applied by and verified only by endpoints.
IAB指出，除非路径参与者与终端系统共享密钥或共享一组公共信任点，否则无法使用允许路径参与者验证完整性保护的方法。因此，完整性保护通常可以由端点可靠地应用和验证。
Verifying the authenticity of signals generated by on-path actors is similarly difficult. Endpoints that consume signals generated by on-path actors, particularly where those signals are unauthenticated, need to fully consider the implications of doing so. Managing the authentication of on-path signals is an area of active research, and defining or recommending methods for it is outside the scope of this document.
验证路径参与者生成的信号的真实性同样困难。消耗由路径路径行动者产生的信号的端点，特别是在那些信号未经验证的情况下，需要充分考虑这样做的含义。管理路径信号的认证是一个积极研究的领域，定义或推荐认证方法不在本文件范围内。
This document has no IANA actions.
本文档没有IANA操作。
Path-visible signals allow network elements along the path to act based on the signaled information, whether the signal is implicit or explicit. If the network element is controlled by an attacker, those actions can include dropping, delaying, or mishandling the constituent packets of a flow. An attacker may also characterize the flow or attempt to fingerprint the communicating nodes based on the pattern of signals.
路径可见信号允许沿路径的网络元件基于信号信息进行操作，无论信号是隐式的还是显式的。如果网元由攻击者控制，则这些操作可能包括丢弃、延迟或错误处理流的组成数据包。攻击者还可以根据信号模式对流进行特征化或试图对通信节点进行指纹识别。
Note that actions that do not benefit the flow or the network may be perceived as an attack even if they are conducted by a responsible network element. Designing a system that minimizes the ability to act on signals at all by removing as many signals as possible may reduce this possibility. This approach also comes with risks, principally that the actions will continue to take place on an arbitrary set of flows.
请注意，即使由负责的网元执行，对流量或网络没有好处的操作也可能被视为攻击。设计一个系统，通过尽可能多地去除信号来最小化对信号的作用，可以减少这种可能性。这种方法也有风险，主要是操作将继续在任意一组流上进行。
Addition of visible signals to the path also increases the information available to an observer and may, when the information can be linked to a node or user, reduce the privacy of the user.
向路径添加可见信号也增加了观察者可用的信息，并且当信息可以链接到节点或用户时，可能会降低用户的隐私。
When signals from endpoints to the path are independent from the signals used by endpoints to manage the flow's state mechanics, they may be falsified by an endpoint without affecting the peer's understanding of the flow's state. For encrypted flows, this divergence is not detectable by on-path devices. The intent of this practice may be to garner improved treatment from the network or to avoid strictures. Protocol designers should be cautious when introducing explicit signals to consider how falsified signals would impact protocol operation and deployment. Similarly, operators should be cautious in deployments to be sure that default operation without these signals does not encourage gaming the system by providing false signals.
当从端点到路径的信号独立于端点用于管理流状态机制的信号时，端点可能会伪造这些信号，而不会影响对等方对流状态的理解。对于加密流，路径设备无法检测到这种差异。这种做法的目的可能是从网络获得更好的治疗或避免狭窄。协议设计者在引入显式信号时要谨慎，以考虑篡改的信号将如何影响协议操作和部署。同样，运营商在部署时应谨慎，以确保没有这些信号的默认操作不会通过提供虚假信号来鼓励对系统进行游戏。
[PLUS] Kuehlewind, M., Trammell, B., and J. Hildebrand, "Transport-Independent Path Layer State Management", Work in Progress, draft-trammell-plus-statefulness-04, November 2017.
[PLUS]Kuehlewind，M.，Trammell，B.，和J.Hildebrand，“运输独立路径层状态管理”，在建工程，草稿-Trammell-PLUS-statefulness-042017年11月。
[QUIC] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based Multiplexed and Secure Transport", Work in Progress, draft-ietf-quic-transport-19, March 2019.
[QUIC]Iyengar，J.，Ed.和M.Thomson，Ed.，“QUIC：基于UDP的多路复用和安全传输”，正在进行的工作，草案-ietf-QUIC-Transport-19，2019年3月。
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI 10.17487/RFC0768, August 1980, <https://www.rfc-editor.org/info/rfc768>.
[RFC0768]Postel，J.，“用户数据报协议”，STD 6，RFC 768，DOI 10.17487/RFC0768，1980年8月<https://www.rfc-editor.org/info/rfc768>.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, DOI 10.17487/RFC0793, September 1981, <https://www.rfc-editor.org/info/rfc793>.
[RFC0793]Postel，J.，“传输控制协议”，标准7，RFC 793，DOI 10.17487/RFC0793，1981年9月<https://www.rfc-editor.org/info/rfc793>.
[RFC1958] Carpenter, B., Ed., "Architectural Principles of the Internet", RFC 1958, DOI 10.17487/RFC1958, June 1996, <https://www.rfc-editor.org/info/rfc1958>.
[RFC1958]Carpenter，B.，Ed.，“互联网的架构原则”，RFC 1958，DOI 10.17487/RFC19581996年6月<https://www.rfc-editor.org/info/rfc1958>.
[RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and Issues", RFC 3234, DOI 10.17487/RFC3234, February 2002, <https://www.rfc-editor.org/info/rfc3234>.
[RFC3234]Carpenter，B.和S.Brim，“中间盒：分类和问题”，RFC 3234，DOI 10.17487/RFC3234，2002年2月<https://www.rfc-editor.org/info/rfc3234>.
[RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing of IPv6 Extension Headers", RFC 7045, DOI 10.17487/RFC7045, December 2013, <https://www.rfc-editor.org/info/rfc7045>.
[RFC7045]Carpenter，B.和S.Jiang，“IPv6扩展头的传输和处理”，RFC 7045，DOI 10.17487/RFC70452013年12月<https://www.rfc-editor.org/info/rfc7045>.
[RFC7857] Penno, R., Perreault, S., Boucadair, M., Ed., Sivakumar, S., and K. Naito, "Updates to Network Address Translation (NAT) Behavioral Requirements", BCP 127, RFC 7857, DOI 10.17487/RFC7857, April 2016, <https://www.rfc-editor.org/info/rfc7857>.
[RFC7857]Penno，R.，Perreault，S.，Boucadair，M.，Ed.，Sivakumar，S.，和K.Naito，“网络地址转换（NAT）行为要求的更新”，BCP 127，RFC 7857，DOI 10.17487/RFC7857，2016年4月<https://www.rfc-editor.org/info/rfc7857>.
[RFC8164] Nottingham, M. and M. Thomson, "Opportunistic Security for HTTP/2", RFC 8164, DOI 10.17487/RFC8164, May 2017, <https://www.rfc-editor.org/info/rfc8164>.
[RFC8164]诺丁汉，M.和M.汤姆森，“HTTP/2的机会主义安全”，RFC 8164，DOI 10.17487/RFC8164，2017年5月<https://www.rfc-editor.org/info/rfc8164>.
IAB Members at the Time of Approval
批准时的IAB成员
Jari Arkko Alissa Cooper Ted Hardie Christian Huitema Gabriel Montenegro Erik Nordmark Mark Nottingham Melinda Shore Robert Sparks Jeff Tantsura Martin Thomson Brian Trammell Suzanne Woolf
雅丽·阿尔科·艾莉莎·库珀·泰德·哈迪·克里斯蒂安·惠特玛·加布里埃尔·黑山埃里克·诺德马克·马克·诺丁汉·梅林达海岸罗伯特·斯帕克斯·杰夫·坦特拉·马丁·汤姆森·布莱恩·特拉梅尔·苏珊娜·伍尔夫
Acknowledgements
致谢
In addition to the editor listed in the header, this document incorporates contributions from Brian Trammell, Mirja Kuehlewind, Martin Thomson, Aaron Falk, Mohamed Boucadair, and Joe Hildebrand. These ideas were also discussed at the PLUS BoF, sponsored by Spencer Dawkins. The ideas around the use of IPv6 hop-by-hop headers as a network-layer signal benefited from discussions with Tom Herbert. The description of UDP as a demuxing protocol comes from Stuart Cheshire. Mark Smith, Kazuho Oku, Stephen Farrell, and Eliot Lear provided valuable comments on earlier draft versions of this document.
除了标题中列出的编辑之外，本文档还包含了Brian Trammell、Mirja Kuehlewind、Martin Thomson、Aaron Falk、Mohamed Boucadair和Joe Hildebrand的贡献。斯宾塞·道金斯（Spencer Dawkins）赞助的PLUS BoF也讨论了这些想法。使用IPv6逐跳报头作为网络层信号的想法得益于与Tom Herbert的讨论。UDP作为解复用协议的描述来自Stuart Cheshire。Mark Smith、Kazuho Oku、Stephen Farrell和Eliot Lear对本文件的早期草稿提供了宝贵的意见。
All errors are those of the editor.
所有的错误都是编辑的错误。
Author's Address
作者地址
Ted Hardie (editor)
特德·哈迪（编辑）
Email: ted.ietf@gmail.com
Email: ted.ietf@gmail.com