Independent Submission D. Dolson, Ed.
Request for Comments: 8517
Category: Informational J. Snellman
ISSN: 2070-1721
M. Boucadair, Ed.
C. Jacquenet
Orange
February 2019
Independent Submission D. Dolson, Ed.
Request for Comments: 8517
Category: Informational J. Snellman
ISSN: 2070-1721
M. Boucadair, Ed.
C. Jacquenet
Orange
February 2019
An Inventory of Transport-Centric Functions Provided by Middleboxes: An Operator Perspective
中间箱提供的以运输为中心的功能清单：运营商视角
Abstract
摘要
This document summarizes an operator's perception of the benefits that may be provided by intermediary devices that execute functions beyond normal IP forwarding. Such intermediary devices are often called "middleboxes".
本文档总结了运营商对执行正常IP转发以外功能的中间设备可能带来的好处的看法。这种中间设备通常被称为“中间盒”。
RFC 3234 defines a taxonomy of middleboxes and issues in the Internet. Most of those middleboxes utilize or modify application-layer data. This document primarily focuses on devices that observe and act on information carried in the transport layer, and especially information carried in TCP packets.
RFC 3234定义了互联网中的中间包和问题的分类。大多数中间盒利用或修改应用程序层数据。本文档主要关注观察和处理传输层中携带的信息的设备，尤其是TCP数据包中携带的信息。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
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 candidates for any level of Internet Standard; see Section 2 of RFC 7841.
这是对RFC系列的贡献，独立于任何其他RFC流。RFC编辑器已选择自行发布此文档，并且未声明其对实现或部署的价值。RFC编辑批准发布的文件不适用于任何级别的互联网标准；见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/rfc8517.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8517.
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
1.1. Operator Perspective . . . . . . . . . . . . . . . . . . 3
1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Measurements . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Packet Loss . . . . . . . . . . . . . . . . . . . . . . . 5
2.2. Round-Trip Times . . . . . . . . . . . . . . . . . . . . 6
2.3. Measuring Packet Reordering . . . . . . . . . . . . . . . 6
2.4. Throughput and Bottleneck Identification . . . . . . . . 7
2.5. Congestion Responsiveness . . . . . . . . . . . . . . . . 7
2.6. Attack Detection . . . . . . . . . . . . . . . . . . . . 8
2.7. Packet Corruption . . . . . . . . . . . . . . . . . . . . 8
2.8. Application-Layer Measurements . . . . . . . . . . . . . 9
3. Functions beyond Measurement: A Few Examples . . . . . . . . 9
3.1. NAT . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2. Firewall . . . . . . . . . . . . . . . . . . . . . . . . 10
3.3. DDoS Scrubbing . . . . . . . . . . . . . . . . . . . . . 10
3.4. Implicit Identification . . . . . . . . . . . . . . . . . 11
3.5. Performance-Enhancing Proxies . . . . . . . . . . . . . . 11
3.6. Network Coding . . . . . . . . . . . . . . . . . . . . . 12
3.7. Network-Assisted Bandwidth Aggregation . . . . . . . . . 13
3.8. Prioritization and Differentiated Services . . . . . . . 13
3.9. Measurement-Based Shaping . . . . . . . . . . . . . . . . 14
3.10. Fairness to End-User Quota . . . . . . . . . . . . . . . 14
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
5. Security Considerations . . . . . . . . . . . . . . . . . . . 14
5.1. Confidentiality and Privacy . . . . . . . . . . . . . . . 14
5.2. Active On-Path Attacks . . . . . . . . . . . . . . . . . 15
5.3. Improved Security . . . . . . . . . . . . . . . . . . . . 15
6. Informative References . . . . . . . . . . . . . . . . . . . 16
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Operator Perspective . . . . . . . . . . . . . . . . . . 3
1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Measurements . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Packet Loss . . . . . . . . . . . . . . . . . . . . . . . 5
2.2. Round-Trip Times . . . . . . . . . . . . . . . . . . . . 6
2.3. Measuring Packet Reordering . . . . . . . . . . . . . . . 6
2.4. Throughput and Bottleneck Identification . . . . . . . . 7
2.5. Congestion Responsiveness . . . . . . . . . . . . . . . . 7
2.6. Attack Detection . . . . . . . . . . . . . . . . . . . . 8
2.7. Packet Corruption . . . . . . . . . . . . . . . . . . . . 8
2.8. Application-Layer Measurements . . . . . . . . . . . . . 9
3. Functions beyond Measurement: A Few Examples . . . . . . . . 9
3.1. NAT . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2. Firewall . . . . . . . . . . . . . . . . . . . . . . . . 10
3.3. DDoS Scrubbing . . . . . . . . . . . . . . . . . . . . . 10
3.4. Implicit Identification . . . . . . . . . . . . . . . . . 11
3.5. Performance-Enhancing Proxies . . . . . . . . . . . . . . 11
3.6. Network Coding . . . . . . . . . . . . . . . . . . . . . 12
3.7. Network-Assisted Bandwidth Aggregation . . . . . . . . . 13
3.8. Prioritization and Differentiated Services . . . . . . . 13
3.9. Measurement-Based Shaping . . . . . . . . . . . . . . . . 14
3.10. Fairness to End-User Quota . . . . . . . . . . . . . . . 14
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
5. Security Considerations . . . . . . . . . . . . . . . . . . . 14
5.1. Confidentiality and Privacy . . . . . . . . . . . . . . . 14
5.2. Active On-Path Attacks . . . . . . . . . . . . . . . . . 15
5.3. Improved Security . . . . . . . . . . . . . . . . . . . . 15
6. Informative References . . . . . . . . . . . . . . . . . . . 16
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
From [RFC3234], "A middlebox is defined as any intermediary device performing functions other than the normal, standard functions of an IP router on the datagram path between a source host and destination host."
根据[RFC3234]，“中间盒被定义为在源主机和目标主机之间的数据报路径上执行IP路由器的正常标准功能以外的任何中间设备。”
Middleboxes are usually (but not exclusively) deployed at locations permitting observation of bidirectional traffic flows. Such locations are typically points where leaf networks connect to the Internet, for example:
中间箱通常（但不限于）部署在允许观察双向交通流的位置。这些位置通常是叶网络连接到Internet的点，例如：
o Where a residential or business customer connects to its service provider(s), which may include multihoming;
o 如果住宅或商业客户与其服务提供商连接，其中可能包括多主服务；
o On the Gi interface where a Gateway General Packet Radio Service (GPRS) Support Node (GGSN) connects to a Packet Data Network (PDN) (Section 3.1 of [RFC6459]).
o 在网关通用分组无线业务（GPRS）支持节点（GGSN）连接到分组数据网络（PDN）的Gi接口上（RFC6459第3.1节）。
For the purposes of this document (and to be consistent with the definition in RFC 3234), middlebox functions may be found in routers and switches in addition to dedicated devices.
为了本文件的目的（并与RFC 3234中的定义一致），除了专用设备外，路由器和交换机中还可以找到中间盒功能。
This document itemizes a variety of features provided by middleboxes and by ad hoc analysis performed by operators using packet analyzers.
本文档详细列出了中间盒提供的各种功能，以及运营商使用数据包分析器执行的特殊分析。
Many of the techniques described in this document require stateful analysis of transport streams. A generic state machine is described in [PATH-STATE].
本文档中描述的许多技术都需要对传输流进行状态分析。[PATH-state]中描述了通用状态机。
This document summarizes an operator's perception of the benefits that may be provided by middleboxes. A primary goal is to provide information to the Internet community to aid understanding of what might be gained or lost by decisions that may affect (or be affected by) middlebox operation in the design of new transport protocols. See Section 1.1 for more details.
本文件总结了运营商对中间箱可能提供的好处的看法。一个主要目标是向互联网社区提供信息，以帮助理解在设计新的传输协议时，可能影响（或受）中间箱操作的决策可能获得或失去什么。详见第1.1节。
Network operators are often the ones first called upon when applications fail to function properly, often with user reports about application behaviors (not about packet behaviors). Therefore, it isn't surprising that operators (wanting to be helpful) desire some visibility into flow information to identify how well the problem flows are progressing and how well other flows are progressing.
当应用程序无法正常运行时，网络运营商通常是第一个被调用的人，用户通常会报告应用程序行为（而不是数据包行为）。因此，运营商（希望提供帮助）希望对流程信息有一定的可见性，以确定问题流程的进展情况以及其他流程的进展情况，这并不奇怪。
Advanced service functions (e.g., Network Address Translators (NATs), firewalls, etc.) [RFC7498] are widely used to achieve various objectives such as IP address sharing, firewalling, avoiding covert channels, detecting and protecting against ever-increasing Distributed Denial of Service (DDoS) attacks, etc. For example, environment-specific designs may require a number of service functions, such as those needed at the Gi interface of a mobile infrastructure [USE-CASE].
高级服务功能（例如，网络地址转换器（NAT）、防火墙等）[RFC7498]被广泛用于实现各种目标，如IP地址共享、防火墙、避免隐蔽通道、检测和防止不断增加的分布式拒绝服务（DDoS）攻击等，特定于环境的设计可能需要许多服务功能，例如移动基础设施的Gi接口所需的服务功能[用例]。
These sophisticated service functions are located in the network but also in service platforms or intermediate entities (e.g., Content Delivery Networks (CDNs)). Network maintenance and diagnostic operations are complicated, particularly when responsibility is shared among various players.
这些复杂的服务功能位于网络中，但也位于服务平台或中间实体（例如，内容交付网络（CDN））中。网络维护和诊断操作非常复杂，尤其是当责任由不同参与者分担时。
Network Providers are challenged to deliver differentiated services as a competitive business advantage while mastering the complexity of the applications, (continuously) evaluating the impacts on middleboxes, and enhancing customers' quality of experience.
网络提供商面临的挑战是，在掌握应用程序的复杂性的同时，（不断）评估对中间包的影响，并提高客户的体验质量，提供差异化服务，以此作为竞争性业务优势。
Despite the complexity, removing all those service functions is not an option because they are used to address constraints that are often typical of the current (and changing) Internet. Operators must deal with constraints such as global IPv4 address depletion and support a plethora of services with different requirements for QoS, security, robustness, etc.
尽管存在复杂性，但删除所有这些服务功能并不是一个选项，因为它们用于解决当前（和不断变化的）互联网的典型约束。运营商必须处理诸如全局IPv4地址耗尽等约束，并支持对QoS、安全性、健壮性等有不同要求的大量服务。
Although many middleboxes observe and manipulate application-layer content (e.g., session boarder controllers [RFC5853]), they are out of scope for this document, the aim being to describe middleboxes using transport-layer features. [RFC8404] describes the impact of pervasive encryption of application-layer data on network monitoring, protecting, and troubleshooting.
尽管许多中间盒观察和操作应用层内容（例如，会话boarder控制器[RFC5853]），但它们不在本文档的范围内，目的是使用传输层功能描述中间盒。[RFC8404]描述了应用层数据的普及加密对网络监控、保护和故障排除的影响。
The current document is not intended to recommend (or prohibit) middlebox deployment. Many operators have found the value provided by middleboxes to outweigh the added cost and complexity; this document attempts to provide that perspective as a reference in discussion of protocol design trade-offs.
当前文档无意建议（或禁止）部署中间盒。许多运营商发现，中间商提供的价值超过了增加的成本和复杂性；本文件试图提供该观点，作为协议设计权衡讨论的参考。
This document is not intended to discuss issues related to middleboxes. These issues are well known and are recorded in existing documents such as [RFC3234] and [RFC6269]. This document aims to elaborate on the motivations leading operators to enable such functions in spite of complications.
本文件无意讨论与中间盒相关的问题。这些问题众所周知，并记录在[RFC3234]和[RFC6269]等现有文件中。本文件旨在阐述主要运营商在复杂情况下启用此类功能的动机。
This document takes an operator perspective that measurement and management of transport connections is of benefit to both parties: the end user receives a better quality of experience, and the network operator improves resource usage, the former being a consequence of the latter.
本文件从运营商的角度出发，认为运输连接的测量和管理对双方都有利：最终用户获得了更好的体验质量，网络运营商提高了资源利用率，前者是后者的结果。
This document does not discuss whether exposing some data to on-path devices for network-assistance purposes can be achieved by using in-band or out-of-band mechanisms.
本文档不讨论是否可以通过使用带内或带外机制将某些数据公开给路径设备以实现网络辅助。
A number of measurements can be made by network devices that are either on-path or off-path. These measurements can be used either by automated systems or for manual network troubleshooting purposes (e.g., using packet-analysis tools). The automated systems can further be classified into two types: 1) monitoring systems that compute performance indicators for single connections or aggregates of connections and generate aggregated reports from them; and 2) active systems that make decisions also on how to handle packet flows based on these performance indicators.
许多测量可以由路径上或路径外的网络设备进行。这些测量可以由自动化系统使用，也可以用于手动网络故障排除目的（例如，使用数据包分析工具）。自动化系统可进一步分为两类：1）监控系统，用于计算单个连接或连接聚合的性能指标，并从中生成聚合报告；2）主动系统，根据这些性能指标决定如何处理数据包流。
Long-term trends in these measurements can aid an operator in capacity planning.
这些测量的长期趋势可以帮助运营商进行产能规划。
Short-term anomalies revealed by these measurements can identify network breakages, attacks in progress, or misbehaving devices/ applications.
通过这些测量发现的短期异常可以识别网络中断、正在进行的攻击或行为不端的设备/应用程序。
It is very useful for an operator to be able to detect and isolate packet loss in a network.
运营商能够检测和隔离网络中的数据包丢失是非常有用的。
Network problems and underprovisioning can be detected if packet loss is measurable. TCP packet loss can be detected by observing gaps in sequence numbers, retransmitted sequence numbers, and selective acknowledgement (SACK) options [RFC2018]. Packet loss can be detected per direction.
如果数据包丢失是可测量的，则可以检测到网络问题和资源不足。TCP数据包丢失可以通过观察序列号、重传序列号和选择性确认（SACK）选项中的间隔来检测[RFC2018]。每个方向都可以检测到数据包丢失。
Gaps indicate loss upstream of the traffic observation point; retransmissions indicate loss downstream of the traffic observation point. SACKs can be used to detect either upstream or downstream packet loss (although some care needs to be taken to avoid misidentifying packet reordering as packet loss) and to distinguish between upstream versus downstream losses.
间隙表示交通观测点上游的损失；重传表示交通观察点下游的损失。SACK可用于检测上游或下游数据包丢失（尽管需要注意避免将数据包重新排序错误识别为数据包丢失），并区分上游和下游丢失。
Packet-loss measurements on both sides of the measurement point are an important component in precisely diagnosing insufficiently dimensioned devices or links in networks. Additionally, packet losses are one of the two main ways for congestion to manifest, the others being queuing delay or Explicit Congestion Notification (ECN) [RFC3168]; therefore, packet loss is an important measurement for any middlebox that needs to make traffic handling decisions based on observed levels of congestion.
测量点两侧的丢包测量是精确诊断网络中尺寸不足的设备或链路的重要组成部分。此外，数据包丢失是拥塞表现的两种主要方式之一，其他方式为排队延迟或显式拥塞通知（ECN）[RFC3168]；因此，对于需要根据观察到的拥塞水平做出流量处理决策的任何中间盒，数据包丢失都是一个重要的度量。
The ability to measure partial-path round-trip times (RTTs) is valuable in diagnosing network issues (e.g., abnormal latency, abnormal packet loss). Knowing if latency is poor on one side of the observation point or the other provides more information than is available at either endpoint, which can only observe full RTTs.
测量部分路径往返时间（RTT）的能力对于诊断网络问题（例如，异常延迟、异常数据包丢失）很有价值。了解观察点一侧或另一侧的延迟是否很差，可以提供比任一端点更多的信息，这两个端点只能观察完整的RTT。
For example, a TCP packet stream can be used to measure the RTT on each side of the measurement point. During the connection handshake, the SYN, SYN/ACK, and ACK timings can be used to establish a baseline RTT in each direction. Once the connection is established, the RTT between the server and the measurement point can only reliably be determined using TCP timestamps [RFC7323]. On the side between the measurement point and the client, the exact timing of data segments and ACKs can be used as an alternative. For this latter method to be accurate when packet loss is present, the connection must use selective acknowledgements.
例如，TCP数据包流可用于测量测量点每侧的RTT。在连接握手期间，SYN、SYN/ACK和ACK定时可用于在每个方向上建立基线RTT。一旦建立连接，服务器和测量点之间的RTT只能使用TCP时间戳可靠地确定[RFC7323]。在测量点和客户端之间的一侧，数据段和ack的精确定时可以用作替代。为了使后一种方法在出现数据包丢失时准确，连接必须使用选择性确认。
In many networks, congestion will show up as increasing packet queuing, and congestion-induced packet loss will only happen in extreme cases. RTTs will also show up as a much smoother signal than the discrete packet-loss events. This makes RTTs a good way to identify individual subscribers for whom the network is a bottleneck at a given time or geographical sites (such as cellular towers) that are experiencing large-scale congestion.
在许多网络中，拥塞将表现为不断增加的数据包排队，而拥塞导致的数据包丢失只会在极端情况下发生。RTT也将显示为比离散丢包事件更平滑的信号。这使得RTT成为一种很好的方法，可以识别在给定时间或地理位置（如蜂窝塔）遇到大规模拥塞的网络瓶颈的个人用户。
The main limit of RTT measurement as a congestion signal is the difficulty of reliably distinguishing between the data segments being queued versus the ACKs being queued.
RTT测量作为拥塞信号的主要限制是难以可靠地区分正在排队的数据段和正在排队的ACK。
If a network is reordering packets of transport connections, caused perhaps by Equal-Cost Multipath (ECMP) misconfiguration (described in [RFC2991] and [RFC7690], for example), the endpoints may react as if packet loss is occurring and retransmit packets or reduce forwarding rates. Therefore, a network operator desires the ability to diagnose packet reordering.
如果网络正在对传输连接的数据包进行重新排序，这可能是由等成本多路径（ECMP）错误配置（例如[RFC2991]和[RFC7690]中所述）引起的，则端点可能会做出反应，就好像发生了数据包丢失一样，重新传输数据包或降低转发速率。因此，网络运营商希望能够诊断数据包重新排序。
For TCP, packet reordering can be detected by observing TCP sequence numbers per direction. See, for example, a number of standard packet-reordering metrics in [RFC4737] and informational metrics in [RFC5236].
对于TCP，可以通过观察每个方向的TCP序列号来检测数据包的重新排序。例如，参见[RFC4737]中的许多标准数据包重新排序度量和[RFC5236]中的信息度量。
Although throughput to or from an IP address can be measured without transport-layer measurements, the transport layer provides clues about what the endpoints were attempting to do.
虽然可以在不进行传输层测量的情况下测量到IP地址或从IP地址到IP地址的吞吐量，但传输层提供了有关端点尝试执行的操作的线索。
One way of quickly excluding the network as the bottleneck during troubleshooting is to check whether the speed is limited by the endpoints. For example, the connection speed might instead be limited by suboptimal TCP options, the sender's congestion window, the sender temporarily running out of data to send, the sender waiting for the receiver to send another request, or the receiver closing the receive window.
在故障排除过程中，快速排除网络瓶颈的一种方法是检查速度是否受到端点的限制。例如，连接速度可能会受到次优TCP选项、发送方的拥塞窗口、发送方暂时没有要发送的数据、发送方等待接收方发送另一个请求或接收方关闭接收窗口的限制。
This data is also useful for middleboxes used to measure network quality of service. Connections, or portions of connections, that are limited by the endpoints do not provide an accurate measure of the network's speed and can be discounted or completely excluded in such analyses.
这些数据对于用于测量网络服务质量的中间盒也很有用。受端点限制的连接或部分连接不能提供网络速度的准确测量值，在此类分析中可以忽略或完全排除。
Congestion control mechanisms continue to evolve. Tools exist that can interpret protocol sequence numbers (e.g., from TCP or RTP) to infer the congestion response of a flow. Such tools can be used by operators to help understand the impact of specific transport protocols on other traffic that shares their network. For example, packet sequence numbers can be analyzed to help understand whether an application flow backs off its load in the face of persistent congestion (as TCP does) and, hence, whether the behavior is appropriate for sharing limited network capacity.
拥塞控制机制不断发展。现有的工具可以解释协议序列号（例如，来自TCP或RTP）以推断流的拥塞响应。运营商可以使用这些工具来帮助了解特定传输协议对共享其网络的其他流量的影响。例如，可以对数据包序列号进行分析，以帮助了解应用程序流在面临持续拥塞时（如TCP）是否会退出其负载，从而了解该行为是否适合共享有限的网络容量。
These tools can also be used to determine whether mechanisms are needed in the network to prevent flows from acquiring excessive network capacity under severe congestion (e.g., by deploying rate limiters or network transport circuit breakers [RFC8084]).
这些工具还可用于确定网络中是否需要机制来防止流量在严重拥塞情况下获取过多的网络容量（例如，通过部署速率限制器或网络传输断路器[RFC8084]）。
When an application or network resource is under attack, it is useful to identify this situation from the network perspective, upstream of the attacked resource.
当应用程序或网络资源受到攻击时，从网络角度识别这种情况非常有用，即受攻击资源的上游。
Although detection methods tend to be proprietary, attack detection from within the network may comprise:
尽管检测方法往往是专有的，但来自网络内部的攻击检测可能包括：
o Identifying uncharacteristic traffic volumes or sources;
o 识别非特征交通量或来源；
o Identifying congestion, possibly using techniques in Sections 2.1 and 2.2;
o 识别拥堵，可能使用第2.1节和第2.2节中的技术；
o Identifying incomplete connections or transactions, from attacks that attempt to exhaust server resources;
o 从试图耗尽服务器资源的攻击中识别不完整的连接或事务；
o Fingerprinting based on whatever available fields are determined to be useful in discriminating an attack from desirable traffic.
o 基于任何可用字段的指纹识别被确定为有助于区分攻击和期望流量。
Two trends in protocol design will make attack detection more difficult:
协议设计的两个趋势将使攻击检测更加困难：
o The desire to encrypt transport-layer fields;
o 对传输层字段进行加密的愿望；
o The desire to avoid statistical fingerprinting by adding entropy in various forms.
o 希望通过增加各种形式的熵来避免统计指纹。
While improving privacy, those approaches may hinder attack detection.
在改善隐私的同时，这些方法可能会阻碍攻击检测。
One notable source of packet loss is packet corruption. This corruption will generally not be detected until the checksums are validated by the endpoint and the packet is dropped. This means that detecting the exact location where packets are lost is not sufficient when troubleshooting networks. An operator would like to find out where packets are being corrupted. IP and TCP checksum verification allows a measurement device to correctly distinguish between upstream packet corruption and normal downstream packet loss.
数据包丢失的一个显著原因是数据包损坏。在端点验证校验和并丢弃数据包之前，通常不会检测到这种损坏。这意味着在对网络进行故障排除时，仅检测数据包丢失的确切位置是不够的。操作员希望找出数据包损坏的位置。IP和TCP校验和验证允许测量设备正确区分上游数据包损坏和正常下游数据包丢失。
Transport protocol designers should consider whether a middlebox will be able to detect corrupted or tampered packets.
传输协议设计者应该考虑MealBox是否能够检测损坏或篡改的数据包。
Information about network health may also be gleaned from application-layer diagnosis, such as:
还可以从应用层诊断中收集有关网络健康的信息，例如：
o DNS response times and retransmissions calculated by correlating answers to queries;
o 通过关联查询的答案计算DNS响应时间和重传；
o Various protocol-aware voice and video quality analyses.
o 各种协议感知语音和视频质量分析。
Could this type of information be provided in a transport layer?
这种类型的信息可以在传输层中提供吗？
This section describes features provided by on-path devices that go beyond measurement by modifying, discarding, delaying, or prioritizing traffic.
本节描述了路径设备提供的功能，这些功能通过修改、丢弃、延迟或优先处理通信量而超出了测量范围。
Network Address Translators (NATs) allow multiple devices to share a public address by dividing the transport-layer port space among the devices.
网络地址转换器（NAT）允许多个设备通过在设备之间划分传输层端口空间来共享公共地址。
NAT behavior recommendations are found for UDP in BCP 127 [RFC4787] and for TCP in BCP 142 [RFC7857].
对于BCP 127[RFC4787]中的UDP和BCP 142[RFC7857]中的TCP，可以找到NAT行为建议。
To support NAT, there must be transport-layer port numbers that can be modified by the NAT. Note that required fields (e.g., port numbers) are visible in all IETF-defined transport protocols.
为了支持NAT，必须有NAT可以修改的传输层端口号。请注意，在所有IETF定义的传输协议中，必填字段（例如端口号）都是可见的。
The application layer must not assume the port number was left unchanged (e.g., by including it in a checksum or signing it).
应用层不得假定端口号保持不变（例如，通过将其包含在校验和中或对其签名）。
Address sharing is also used in the context of IPv6 transition. For example, DS-Lite Address Family Transition Router (AFTR) [RFC6333], NAT64 [RFC6146], or A+P [RFC7596][RFC7597] are features that are enabled in the network to allow for IPv4 service continuity over an IPv6 network.
地址共享也用于IPv6转换的上下文中。例如，DS-Lite地址系列转换路由器（AFTR）[RFC6333]、NAT64[RFC6146]或A+P[RFC7596][RFC7597]是网络中启用的功能，允许通过IPv6网络实现IPv4服务连续性。
Further, because of some multihoming considerations, IPv6 prefix translation may be enabled by some enterprises by means of IPv6-to-IPv6 Network Prefix Translation (NPTv6) [RFC6296].
此外，由于一些多归属考虑，一些企业可以通过IPv6到IPv6网络前缀转换（NPTv6）[RFC6296]来启用IPv6前缀转换。
Firewalls are pervasive and essential components that inspect incoming and outgoing traffic. Firewalls are usually the cornerstone of a security policy that is enforced in end-user premises and other locations to provide strict guarantees about traffic that may be authorized to enter/leave the said premises, as well as end users who may be assigned different clearance levels regarding which networks and portions of the Internet they access.
防火墙是检查传入和传出流量的普遍且重要的组件。防火墙通常是在最终用户场所和其他位置强制执行的安全策略的基石，以对可能被授权进入/离开所述场所的流量提供严格的保证，以及最终用户，他们可能会被分配不同的许可级别，以了解他们访问的互联网网络和部分。
An important aspect of a firewall policy is differentiating internally initiated from externally initiated communications.
防火墙策略的一个重要方面是区分内部启动和外部启动的通信。
For TCP, this is easily done by tracking the TCP state machine. Furthermore, the ending of a TCP connection is indicated by RST or FIN flags.
对于TCP，这可以通过跟踪TCP状态机轻松完成。此外，TCP连接的结束由RST或FIN标志指示。
For UDP, the firewall can be opened if the first packet comes from an internal user, but the closing is generally done by an idle timer of arbitrary duration, which might not match the expectations of the application.
对于UDP，如果第一个数据包来自内部用户，则可以打开防火墙，但关闭通常由任意持续时间的空闲计时器完成，这可能与应用程序的预期不符。
Simple IPv6 firewall capabilities for customer premises equipment (both stateless and stateful) are described in [RFC6092].
[RFC6092]中描述了客户场所设备（无状态和有状态）的简单IPv6防火墙功能。
A firewall functions better when it can observe the protocol state machine, described generally by "Transport-Independent Path Layer State Management" [PATH-STATE].
当防火墙能够观察协议状态机时，它的功能会更好，这通常由“传输独立路径层状态管理”[Path-state]来描述。
In the context of a DDoS attack, the purpose of a scrubber is to discard attack traffic while permitting useful traffic. Such a mitigator is described in [DOTS].
在DDoS攻击的环境中，清除器的目的是在允许有用流量的同时丢弃攻击流量。此类缓解措施如[DOTS]所述。
When attacks occur against constrained resources, some traffic will be discarded before reaching the intended destination. A user receives better experience and a server runs more efficiently if a scrubber can discard attack traffic, leaving room for legitimate traffic.
当对受限资源进行攻击时，一些流量将在到达预定目的地之前被丢弃。如果洗涤器可以丢弃攻击流量，为合法流量留出空间，那么用户将获得更好的体验，服务器将运行得更高效。
Scrubbing must be provided by an on-path network device, because neither endpoint of a legitimate connection has any control over the source of the attack traffic.
清除必须由路径上的网络设备提供，因为合法连接的端点都不能控制攻击流量的来源。
Source-spoofed DDoS attacks can be mitigated at the source using BCP 38 [RFC2827], but it is more difficult if source address filtering cannot be applied.
可以使用BCP 38[RFC2827]在源位置缓解源欺骗DDoS攻击，但如果无法应用源地址过滤，则更难。
In contrast to devices in the core of the Internet, middleboxes statefully observing bidirectional transport connections can reject source-spoofed TCP traffic based on the inability to provide sensible acknowledgement numbers to complete the three-way handshake. Obviously, this requires middlebox visibility into a transport-layer state machine.
与互联网核心中的设备不同，有状态地观察双向传输连接的中间盒可以基于无法提供合理的确认号码来完成三方握手而拒绝源伪造的TCP流量。显然，这需要对传输层状态机的中间盒可见性。
Middleboxes may also scrub on the basis of statistical classification: testing how likely a given packet is to be legitimate. As protocol designers add more entropy to headers and lengths, this test becomes less useful, and the best scrubbing strategy becomes random drop.
中间包也可以基于统计分类进行过滤：测试给定数据包合法性的可能性。随着协议设计人员向标头和长度添加更多的熵，此测试变得不太有用，最好的清除策略变成随机丢弃。
In order to enhance the end user's quality of experience, some operators deploy implicit identification features that rely upon the correlation of network-related information to access some local services. For example, service portals operated by some operators may be accessed immediately by end users without any explicit identification for the sake of improved service availability. This is doable thanks to on-path devices that inject appropriate metadata that can be used by the remote server to enforce per-subscriber policies. The information can be injected at the application layer or at the transport layer (when an address-sharing mechanism is in use).
为了提高最终用户的体验质量，一些运营商部署了依赖于网络相关信息相关性的隐式识别功能来访问一些本地服务。例如，为了提高服务可用性，最终用户可以在没有任何明确标识的情况下立即访问某些运营商操作的服务门户。这是可行的，因为路径上的设备注入了适当的元数据，远程服务器可以使用这些元数据强制实施每订户策略。信息可以在应用层或传输层注入（当使用地址共享机制时）。
An experimental implementation using a TCP option is described in [RFC7974].
[RFC7974]中描述了使用TCP选项的实验实现。
For the intended use of implicit identification, it is more secure to have a trusted middlebox mark this traffic than to trust end-user devices.
对于隐式标识的预期用途，使用受信任的中间盒标记此流量比信任最终用户设备更安全。
Performance-Enhancing Proxies (PEPs) can improve performance in some types of networks by improving packet spacing or generating local acknowledgements; they are most commonly used in satellite and cellular networks. Transport-Layer PEPs are described in Section 2.1.1 of [RFC3135].
性能增强代理（PEP）可以通过改进数据包间隔或生成本地确认来提高某些类型网络的性能；它们最常用于卫星和蜂窝网络。[RFC3135]第2.1.1节描述了传输层PEP。
PEPs allow central deployment of congestion control algorithms more suited to the specific network, most commonly for delay-based congestion control. More advanced TCP PEPs deploy congestion control systems that treat all of a single end user's TCP connections as a single unit, improving fairness and allowing faster reaction to
PEP允许集中部署更适合特定网络的拥塞控制算法，通常用于基于延迟的拥塞控制。更高级的TCP PEP部署了拥塞控制系统，将单个最终用户的所有TCP连接视为一个单元，从而提高了公平性并允许更快地响应请求
changing network conditions. For example, it was reported that splitting the TCP connections in some network accesses can result in a halved page downloading time [ICCRG].
不断变化的网络状况。例如，据报道，在某些网络访问中拆分TCP连接可导致页面下载时间减半[ICCRG]。
Local acknowledgements generated by PEPs speed up TCP slow start by splitting the effective latency, and they allow for retransmissions to be done from the PEP rather than from the actual sender. Local acknowledgements will also allow a PEP to maintain a local buffer of data appropriate to the actual network conditions, whereas the actual endpoints would often send too much or too little.
PEP生成的本地确认通过分割有效延迟来加速TCP慢启动，并且允许从PEP而不是从实际发送方进行重传。本地确认还允许PEP维护适合实际网络条件的本地数据缓冲区，而实际端点通常发送太多或太少。
A PEP function requires transport-layer fields that allow chunks of data to be identified (e.g., TCP sequence numbers), acknowledgements to be identified (e.g., TCP ACK numbers), and acknowledgements to be created from the PEP.
PEP功能需要传输层字段，这些字段允许识别数据块（例如TCP序列号）、识别确认（例如TCP确认号）以及从PEP创建确认。
Note that PEPs are only useful in some types of networks. In particular, PEPs are very useful in contexts wherein the congestion control strategies of the endpoints are inappropriate for the network connecting them. That being said, poor design can result in degraded performances when PEPs are deployed.
请注意，PEP仅在某些类型的网络中有用。特别地，pep在端点的拥塞控制策略不适合连接它们的网络的上下文中非常有用。也就是说，当部署PEP时，糟糕的设计可能会导致性能下降。
Network Coding is a technique for improving transmission performance over low-bandwidth, long-latency links such as some satellite links. Coding may involve lossless compression and/or adding redundancy to headers and payload. A Network Coding Taxonomy is provided by [RFC8406]; an example of end-to-end coding is FECFRAME [RFC6363]. It is typically deployed with network-coding gateways at each end of those links, with a network-coding tunnel between them via the slow/lossy/long-latency links.
网络编码是一种提高低带宽、长延迟链路（如某些卫星链路）传输性能的技术。编码可能涉及无损压缩和/或向报头和有效负载添加冗余。[RFC8406]提供了网络编码分类法；端到端编码的一个例子是FECFRAME[RFC6363]。它通常在这些链路的每一端部署网络编码网关，通过慢/有损/长延迟链路在它们之间部署网络编码隧道。
Network-coding implementations may be specific to TCP, taking advantage of known properties of the protocol.
利用协议的已知属性，网络编码实现可能特定于TCP。
The network-coding gateways may employ some techniques of PEPs, such as creating acknowledgements of queued data, removing retransmissions, and pacing data rates to reduce queue oscillation.
网络编码网关可采用PEP的一些技术，例如创建排队数据的确认、移除重传以及调整数据速率以减少队列振荡。
The interest in more network coding in some specific networks is discussed in [SATELLITES].
[SATELLITES]中讨论了在某些特定网络中对更多网络编码的兴趣。
Note: This is not to be confused with transcoding, which performs lossy compression on transmitted media streams and is not in scope for this document.
注意：这不能与转码混淆，转码对传输的媒体流执行有损压缩，不在本文档的范围内。
The Hybrid Access Aggregation Point is a middlebox that allows customers to aggregate the bandwidth of multiple access technologies.
混合接入聚合点是一个中间盒，允许客户聚合多接入技术的带宽。
One of the approaches uses Multipath TCP (MPTCP) proxies [TCP-CONVERT] to forward traffic along multiple paths. The MPTCP proxy operates at the transport layer while being located in the operator's network.
其中一种方法使用多路径TCP（MPTCP）代理[TCP-CONVERT]沿多条路径转发流量。MPTCP代理位于运营商网络中，在传输层运行。
The support of multipath transport capabilities by communicating hosts remains a privileged target design so that such hosts can directly use the available resources provided by a variety of access networks they can connect to. Nevertheless, network operators do not control end hosts, whereas the support of MPTCP by content servers remains marginal.
通信主机对多路径传输能力的支持仍然是一种特权目标设计，因此这些主机可以直接使用它们可以连接到的各种接入网络提供的可用资源。然而，网络运营商并不控制终端主机，而内容服务器对MPTCP的支持仍然很少。
Network-assisted MPTCP deployment models are designed to facilitate the adoption of MPTCP for the establishment of multipath communications without making any assumption about the support of MPTCP capabilities by communicating peers. Network-assisted MPTCP deployment models rely upon MPTCP Conversion Points (MCPs) that act on behalf of hosts so that they can take advantage of establishing communications over multiple paths [TCP-CONVERT].
网络辅助MPTCP部署模型旨在促进采用MPTCP建立多路径通信，而无需假设通信对等方支持MPTCP功能。网络辅助MPTCP部署模型依赖于代表主机的MPTCP转换点（MCP），以便它们可以利用在多条路径上建立通信[TCP-CONVERT]。
Note there are cases when end-to-end MPTCP cannot be used even though both client and server are MPTCP-compliant. An MPTCP proxy can provide multipath utilization in these cases. Examples of such cases are listed below:
注意：在某些情况下，即使客户端和服务器都符合MPTCP，也无法使用端到端MPTCP。在这些情况下，MPTCP代理可以提供多路径利用。下面列出了此类案例的示例：
1. The use of private IPv4 addresses in some access networks. Typically, additional subflows cannot be added to the MPTCP connection without the help of an MCP.
1. 在某些接入网络中使用专用IPv4地址。通常，如果没有MCP的帮助，无法将其他子流添加到MPTCP连接。
2. The assignment of IPv6 prefixes only by some networks. If the server is IPv4-only, IPv6 subflows cannot be added to an MPTCP connection established with that server, by definition.
2. 仅由某些网络分配IPv6前缀。如果服务器仅为IPv4，则根据定义，无法将IPv6子流添加到与该服务器建立的MPTCP连接中。
3. Subscription to some service offerings is subject to volume quota.
3. 对某些服务产品的订阅受数量配额的限制。
Bulk traffic may be served with a higher latency than interactive traffic with no reduction in throughput. This fact allows a middlebox function to improve response times in interactive applications by prioritizing, policing, or remarking interactive transport connections differently from bulk-traffic transport
批量流量可能比交互式流量具有更高的延迟，且吞吐量不会降低。这一事实允许中间箱功能通过区分交互传输连接与批量传输的优先级、管理或标记来改进交互应用程序中的响应时间
connections. For example, gaming traffic may be prioritized over email or software updates. Configuration guidelines for Diffserv service classes are discussed in [RFC4594].
连接。例如，游戏流量可能优先于电子邮件或软件更新。[RFC4594]中讨论了区分服务类的配置指南。
Middleboxes may identify different classes of traffic by inspecting multiple layers of header and length of payload.
中间盒可以通过检查多个报头层和有效负载长度来识别不同类别的流量。
Basic traffic-shaping functionality requires no transport-layer information. All that is needed is a way of mapping each packet to a traffic shaper quota. For example, there may be a rate limit per 5-tuple or per subscriber IP address. However, such fixed traffic shaping rules are wasteful as they end up rate-limiting traffic even when the network has free resources available.
基本流量整形功能不需要传输层信息。所需要的只是一种将每个数据包映射到流量整形器配额的方法。例如，每个5元组或每个订户IP地址可能有速率限制。然而，这种固定的流量整形规则是浪费的，因为即使网络有可用的免费资源，它们也会限制流量的速率。
More advanced traffic-shaping devices use transport-layer metrics described in Section 2 to detect congestion on either a per-site or a per-user level and use different traffic-shaping rules when congestion is detected [RFC3272]. This type of device can overcome limitations of downstream devices that behave poorly (e.g., by excessive buffering or suboptimally dropping packets).
更高级的流量整形设备使用第2节中描述的传输层度量来检测每个站点或每个用户级别的拥塞，并在检测到拥塞时使用不同的流量整形规则[RFC3272]。这种类型的设备可以克服下游设备性能差的限制（例如，通过过度缓冲或次优丢弃数据包）。
Several service offerings rely upon a volume-based charging model (e.g., volume-based data plans offered by cellular providers). Operators may assist end users in conserving their data quota by deploying on-path functions that shape traffic that would otherwise be aggressively transferred.
一些服务产品依赖于基于容量的收费模式（例如，蜂窝提供商提供的基于容量的数据计划）。运营商可以通过部署路径上的功能来帮助最终用户保存其数据配额，这些功能可以塑造流量，否则流量将被大量传输。
For example, a fast download of a video that won't be viewed completely by the subscriber may lead to quick exhaustion of the data quota. Limiting the video download rate conserves quota for the benefit of the end user. Also, discarding unsolicited incoming traffic prevents the user's quota from being unfairly exhausted.
例如，快速下载订户无法完全观看的视频可能会导致数据配额的快速耗尽。为了最终用户的利益，限制视频下载速率可以节省配额。此外，丢弃未经请求的传入流量可以防止用户配额被不公平地耗尽。
This document has no IANA actions.
本文档没有IANA操作。
This document intentionally excludes middleboxes that observe or manipulate application-layer data.
本文档有意排除观察或操作应用程序层数据的中间盒。
The measurements and functions described in this document can all be implemented without violating confidentiality [RFC6973]. However, there is always the question of whether the fields and packet properties used to achieve operational benefits may also be used for harm.
本文档中描述的测量和功能都可以在不违反保密性的情况下实现[RFC6973]。然而，始终存在一个问题，即用于实现操作效益的字段和数据包属性是否也可能被用于危害。
In particular, the question is what confidentiality is lost by exposing transport-layer fields beyond what can be learned by observing IP-layer fields:
特别是，问题在于，除了通过观察IP层字段可以了解的信息外，暴露传输层字段会丢失什么机密性：
o Sequence numbers: an observer can learn how much data is transferred.
o 序列号：观察者可以了解传输了多少数据。
o Start/Stop indicators: an observer can count transactions for some applications.
o 开始/停止指示器：观察者可以对某些应用程序的事务进行计数。
o Device fingerprinting: an observer may be more easily able to identify a device type when different devices use different default field values or options.
o 设备指纹：当不同的设备使用不同的默认字段值或选项时，观察者可能更容易识别设备类型。
An on-path attacker being able to observe sequence numbers or session identifiers may make it easier to modify or terminate a transport connection. For example, observing TCP sequence numbers allows generation of a RST packet that terminates the connection. However, signing transport fields softens this attack. The attack and solution are described for the TCP authentication option [RFC5925]. Still, an on-path attacker can also drop the traffic flow.
能够观察序列号或会话标识符的路径上攻击者可能更容易修改或终止传输连接。例如，观察TCP序列号可以生成终止连接的RST数据包。但是，对传输字段进行签名会软化这种攻击。针对TCP身份验证选项[RFC5925]描述了攻击和解决方案。不过，路径上的攻击者也可以丢弃流量。
Network maintainability and security can be improved by providing firewalls and DDoS mechanisms with some information about transport connections. In contrast, it would be very difficult to secure a network in which every packet appears unique and filled with random bits (from the perspective of an on-path device).
通过向防火墙和DDoS机制提供一些有关传输连接的信息，可以提高网络的可维护性和安全性。相比之下，要保护一个每个数据包都是唯一的并且充满随机比特的网络（从路径设备的角度来看）是非常困难的。
Some features providing the ability to mitigate/filter attacks owing to a network-assisted mechanism will therefore improve security -- e.g., by means of Distributed-Denial-of-Service Open Threat Signaling (DOTS) [DOTS-SIGNAL].
因此，通过网络辅助机制提供缓解/过滤攻击能力的某些功能将提高安全性，例如，通过分布式拒绝服务开放威胁信令（DOTS）[DOTS-SIGNAL]。
[DOTS] Mortensen, A., Andreasen, F., Reddy, T., Compton, R., and N. Teague, "Distributed-Denial-of-Service Open Threat Signaling (DOTS) Architecture", Work in Progress, draft-ietf-dots-architecture-07, September 2018.
[DOTS]Mortensen，A.，Andreasen，F.，Reddy，T.，Compton，R.，和N.Teague，“分布式拒绝服务开放威胁信号（DOTS）架构”，正在进行的工作，草稿-ietf-DOTS-Architecture-07，2018年9月。
[DOTS-SIGNAL] Reddy, T., Boucadair, M., Patil, P., Mortensen, A., and N. Teague, "Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Specification", Work in Progress, draft-ietf-dots-signal-channel-25, September 2018.
[DOTS-SIGNAL]Reddy，T.，Boucadair，M.，Patil，P.，Mortensen，A.，和N.Teague，“分布式拒绝服务开放威胁信令（DOTS）信号通道规范”，正在进行的工作，草案-ietf-DOTS-SIGNAL-Channel-252018年9月。
[ICCRG] Kuhn, N., "MPTCP and BBR performance over Internet satellite paths", IETF 100, 2017, <https://datatracker.ietf.org/meeting/100/materials/ slides-100-iccrg-mptcp-and-bbr-performance-over-satcom-links-00>.
[ICCRG]Kuhn，N.，“互联网卫星路径上的MPTCP和BBR性能”，IETF 1002017<https://datatracker.ietf.org/meeting/100/materials/ 幻灯片-100-iccrg-mptcp-and-bbr-performance-over-satcom-links-00>。
[PATH-STATE] Kuehlewind, M., Trammell, B., and J. Hildebrand, "Transport-Independent Path Layer State Management", Work in Progress, draft-trammell-plus-statefulness-04, November 2017.
[路径状态]Kuehlewind，M.，Trammell，B.，和J.Hildebrand，“运输独立路径层状态管理”，正在进行的工作，草稿-Trammell-plus-statefulness-042017年11月。
[RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP Selective Acknowledgment Options", RFC 2018, DOI 10.17487/RFC2018, October 1996, <https://www.rfc-editor.org/info/rfc2018>.
[RFC2018]Mathis，M.，Mahdavi，J.，Floyd，S.，和A.Romanow，“TCP选择性确认选项”，RFC 2018，DOI 10.17487/RFC2018，1996年10月<https://www.rfc-editor.org/info/rfc2018>.
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, May 2000, <https://www.rfc-editor.org/info/rfc2827>.
[RFC2827]Ferguson，P.和D.Senie，“网络入口过滤：击败利用IP源地址欺骗的拒绝服务攻击”，BCP 38，RFC 2827，DOI 10.17487/RFC2827，2000年5月<https://www.rfc-editor.org/info/rfc2827>.
[RFC2991] Thaler, D. and C. Hopps, "Multipath Issues in Unicast and Multicast Next-Hop Selection", RFC 2991, DOI 10.17487/RFC2991, November 2000, <https://www.rfc-editor.org/info/rfc2991>.
[RFC2991]Thaler，D.和C.Hopps，“单播和多播下一跳选择中的多路径问题”，RFC 2991，DOI 10.17487/RFC2991，2000年11月<https://www.rfc-editor.org/info/rfc2991>.
[RFC3135] Border, J., Kojo, M., Griner, J., Montenegro, G., and Z. Shelby, "Performance Enhancing Proxies Intended to Mitigate Link-Related Degradations", RFC 3135, DOI 10.17487/RFC3135, June 2001, <https://www.rfc-editor.org/info/rfc3135>.
[RFC3135]Border，J.，Kojo，M.，Griner，J.，黑山，G.，和Z.Shelby，“旨在缓解链路相关降级的性能增强代理”，RFC 3135，DOI 10.17487/RFC3135，2001年6月<https://www.rfc-editor.org/info/rfc3135>.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, DOI 10.17487/RFC3168, September 2001, <https://www.rfc-editor.org/info/rfc3168>.
[RFC3168]Ramakrishnan，K.，Floyd，S.，和D.Black，“向IP添加显式拥塞通知（ECN）”，RFC 3168，DOI 10.17487/RFC3168，2001年9月<https://www.rfc-editor.org/info/rfc3168>.
[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>.
[RFC3272] Awduche, D., Chiu, A., Elwalid, A., Widjaja, I., and X. Xiao, "Overview and Principles of Internet Traffic Engineering", RFC 3272, DOI 10.17487/RFC3272, May 2002, <https://www.rfc-editor.org/info/rfc3272>.
[RFC3272]Awduche，D.，Chiu，A.，Elwalid，A.，Widjaja，I.，和X.Xiao，“互联网流量工程概述和原则”，RFC 3272，DOI 10.17487/RFC3272，2002年5月<https://www.rfc-editor.org/info/rfc3272>.
[RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration Guidelines for DiffServ Service Classes", RFC 4594, DOI 10.17487/RFC4594, August 2006, <https://www.rfc-editor.org/info/rfc4594>.
[RFC4594]Babiarz，J.，Chan，K.，和F.Baker，“区分服务服务类的配置指南”，RFC 4594，DOI 10.17487/RFC4594，2006年8月<https://www.rfc-editor.org/info/rfc4594>.
[RFC4737] Morton, A., Ciavattone, L., Ramachandran, G., Shalunov, S., and J. Perser, "Packet Reordering Metrics", RFC 4737, DOI 10.17487/RFC4737, November 2006, <https://www.rfc-editor.org/info/rfc4737>.
[RFC4737]Morton，A.，Ciavattone，L.，Ramachandran，G.，Shalunov，S.，和J.Perser，“数据包重新排序度量”，RFC 4737，DOI 10.17487/RFC4737，2006年11月<https://www.rfc-editor.org/info/rfc4737>.
[RFC4787] Audet, F., Ed. and C. Jennings, "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787, DOI 10.17487/RFC4787, January 2007, <https://www.rfc-editor.org/info/rfc4787>.
[RFC4787]Audet，F.，Ed.和C.Jennings，“单播UDP的网络地址转换（NAT）行为要求”，BCP 127，RFC 4787，DOI 10.17487/RFC4787，2007年1月<https://www.rfc-editor.org/info/rfc4787>.
[RFC5236] Jayasumana, A., Piratla, N., Banka, T., Bare, A., and R. Whitner, "Improved Packet Reordering Metrics", RFC 5236, DOI 10.17487/RFC5236, June 2008, <https://www.rfc-editor.org/info/rfc5236>.
[RFC5236]Jayasumana，A.，Piratla，N.，Banka，T.，Bare，A.，和R.Whitner，“改进的数据包重新排序度量”，RFC 5236，DOI 10.17487/RFC5236，2008年6月<https://www.rfc-editor.org/info/rfc5236>.
[RFC5853] Hautakorpi, J., Ed., Camarillo, G., Penfield, R., Hawrylyshen, A., and M. Bhatia, "Requirements from Session Initiation Protocol (SIP) Session Border Control (SBC) Deployments", RFC 5853, DOI 10.17487/RFC5853, April 2010, <https://www.rfc-editor.org/info/rfc5853>.
[RFC5853]Hautakorpi，J.，Ed.，Camarillo，G.，Penfield，R.，Hawrylyshen，A.，和M.Bhatia，“会话启动协议（SIP）会话边界控制（SBC）部署的要求”，RFC 5853，DOI 10.17487/RFC5853，2010年4月<https://www.rfc-editor.org/info/rfc5853>.
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP Authentication Option", RFC 5925, DOI 10.17487/RFC5925, June 2010, <https://www.rfc-editor.org/info/rfc5925>.
[RFC5925]Touch，J.，Mankin，A.，和R.Bonica，“TCP认证选项”，RFC 5925，DOI 10.17487/RFC5925，2010年6月<https://www.rfc-editor.org/info/rfc5925>.
[RFC6092] Woodyatt, J., Ed., "Recommended Simple Security Capabilities in Customer Premises Equipment (CPE) for Providing Residential IPv6 Internet Service", RFC 6092, DOI 10.17487/RFC6092, January 2011, <https://www.rfc-editor.org/info/rfc6092>.
[RFC6092]Woodyatt，J.，Ed.，“提供住宅IPv6互联网服务的客户场所设备（CPE）中推荐的简单安全功能”，RFC 6092，DOI 10.17487/RFC6092，2011年1月<https://www.rfc-editor.org/info/rfc6092>.
[RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, April 2011, <https://www.rfc-editor.org/info/rfc6146>.
[RFC6146]Bagnulo，M.，Matthews，P.，和I.van Beijnum，“有状态NAT64：从IPv6客户端到IPv4服务器的网络地址和协议转换”，RFC 6146，DOI 10.17487/RFC6146，2011年4月<https://www.rfc-editor.org/info/rfc6146>.
[RFC6269] Ford, M., Ed., Boucadair, M., Durand, A., Levis, P., and P. Roberts, "Issues with IP Address Sharing", RFC 6269, DOI 10.17487/RFC6269, June 2011, <https://www.rfc-editor.org/info/rfc6269>.
[RFC6269]福特，M.，Ed.，Boucadair，M.，Durand，A.，Levis，P.，和P.Roberts，“IP地址共享问题”，RFC 6269，DOI 10.17487/RFC62692011年6月<https://www.rfc-editor.org/info/rfc6269>.
[RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix Translation", RFC 6296, DOI 10.17487/RFC6296, June 2011, <https://www.rfc-editor.org/info/rfc6296>.
[RFC6296]Wasserman，M.和F.Baker，“IPv6到IPv6网络前缀转换”，RFC 6296DOI 10.17487/RFC62962011年6月<https://www.rfc-editor.org/info/rfc6296>.
[RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion", RFC 6333, DOI 10.17487/RFC6333, August 2011, <https://www.rfc-editor.org/info/rfc6333>.
[RFC6333]Durand，A.，Droms，R.，Woodyatt，J.，和Y.Lee，“IPv4耗尽后的双栈Lite宽带部署”，RFC 6333，DOI 10.17487/RFC6333，2011年8月<https://www.rfc-editor.org/info/rfc6333>.
[RFC6363] Watson, M., Begen, A., and V. Roca, "Forward Error Correction (FEC) Framework", RFC 6363, DOI 10.17487/RFC6363, October 2011, <https://www.rfc-editor.org/info/rfc6363>.
[RFC6363]Watson，M.，Begen，A.和V.Roca，“前向纠错（FEC）框架”，RFC 6363，DOI 10.17487/RFC6363，2011年10月<https://www.rfc-editor.org/info/rfc6363>.
[RFC6459] Korhonen, J., Ed., Soininen, J., Patil, B., Savolainen, T., Bajko, G., and K. Iisakkila, "IPv6 in 3rd Generation Partnership Project (3GPP) Evolved Packet System (EPS)", RFC 6459, DOI 10.17487/RFC6459, January 2012, <https://www.rfc-editor.org/info/rfc6459>.
[RFC6459]Korhonen，J.，Ed.，Soininen，J.，Patil，B.，Savolainen，T.，Bajko，G.，和K.Iisakkila，“第三代合作伙伴关系项目（3GPP）中的IPv6演进包系统（EPS）”，RFC 6459，DOI 10.17487/RFC6459，2012年1月<https://www.rfc-editor.org/info/rfc6459>.
[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., Morris, J., Hansen, M., and R. Smith, "Privacy Considerations for Internet Protocols", RFC 6973, DOI 10.17487/RFC6973, July 2013, <https://www.rfc-editor.org/info/rfc6973>.
[RFC6973]Cooper，A.，Tschofenig，H.，Aboba，B.，Peterson，J.，Morris，J.，Hansen，M.，和R.Smith，“互联网协议的隐私考虑”，RFC 6973，DOI 10.17487/RFC6973，2013年7月<https://www.rfc-editor.org/info/rfc6973>.
[RFC7323] Borman, D., Braden, B., Jacobson, V., and R. Scheffenegger, Ed., "TCP Extensions for High Performance", RFC 7323, DOI 10.17487/RFC7323, September 2014, <https://www.rfc-editor.org/info/rfc7323>.
[RFC7323]Borman，D.，Braden，B.，Jacobson，V.，和R.Scheffenegger，编辑，“高性能TCP扩展”，RFC 7323，DOI 10.17487/RFC73232014年9月<https://www.rfc-editor.org/info/rfc7323>.
[RFC7498] Quinn, P., Ed. and T. Nadeau, Ed., "Problem Statement for Service Function Chaining", RFC 7498, DOI 10.17487/RFC7498, April 2015, <https://www.rfc-editor.org/info/rfc7498>.
[RFC7498]Quinn，P.，Ed.和T.Nadeau，Ed.，“服务功能链接的问题陈述”，RFC 7498，DOI 10.17487/RFC7498，2015年4月<https://www.rfc-editor.org/info/rfc7498>.
[RFC7596] Cui, Y., Sun, Q., Boucadair, M., Tsou, T., Lee, Y., and I. Farrer, "Lightweight 4over6: An Extension to the Dual-Stack Lite Architecture", RFC 7596, DOI 10.17487/RFC7596, July 2015, <https://www.rfc-editor.org/info/rfc7596>.
[RFC7596]Cui，Y.，Sun，Q.，Boucadair，M.，Tsou，T.，Lee，Y.，和I.Farrer，“轻量级4over6：双栈精简架构的扩展”，RFC 7596，DOI 10.17487/RFC75962015年7月<https://www.rfc-editor.org/info/rfc7596>.
[RFC7597] Troan, O., Ed., Dec, W., Li, X., Bao, C., Matsushima, S., Murakami, T., and T. Taylor, Ed., "Mapping of Address and Port with Encapsulation (MAP-E)", RFC 7597, DOI 10.17487/RFC7597, July 2015, <https://www.rfc-editor.org/info/rfc7597>.
[RFC7597]Troan，O.，Ed.，Dec，W.，Li，X.，Bao，C.，Matsushima，S.，Murakami，T.，和T.Taylor，Ed.，“地址和端口的封装映射（MAP-E）”，RFC 7597，DOI 10.17487/RFC7597，2015年7月<https://www.rfc-editor.org/info/rfc7597>.
[RFC7690] Byerly, M., Hite, M., and J. Jaeggli, "Close Encounters of the ICMP Type 2 Kind (Near Misses with ICMPv6 Packet Too Big (PTB))", RFC 7690, DOI 10.17487/RFC7690, January 2016, <https://www.rfc-editor.org/info/rfc7690>.
[RFC7690]Byerly，M.，Hite，M.，和J.Jaeggli，“ICMP类型2的近距离遭遇（ICMPv6数据包太大（PTB））的未遂事件”，RFC 7690，DOI 10.17487/RFC7690，2016年1月<https://www.rfc-editor.org/info/rfc7690>.
[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>.
[RFC7974] Williams, B., Boucadair, M., and D. Wing, "An Experimental TCP Option for Host Identification", RFC 7974, DOI 10.17487/RFC7974, October 2016, <https://www.rfc-editor.org/info/rfc7974>.
[RFC7974]Williams，B.，Boucadair，M.，和D.Wing，“用于主机识别的实验性TCP选项”，RFC 7974，DOI 10.17487/RFC7974，2016年10月<https://www.rfc-editor.org/info/rfc7974>.
[RFC8084] Fairhurst, G., "Network Transport Circuit Breakers", BCP 208, RFC 8084, DOI 10.17487/RFC8084, March 2017, <https://www.rfc-editor.org/info/rfc8084>.
[RFC8084]Fairhurst，G.，“网络传输断路器”，BCP 208，RFC 8084，DOI 10.17487/RFC8084，2017年3月<https://www.rfc-editor.org/info/rfc8084>.
[RFC8404] Moriarty, K., Ed. and A. Morton, Ed., "Effects of Pervasive Encryption on Operators", RFC 8404, DOI 10.17487/RFC8404, July 2018, <https://www.rfc-editor.org/info/rfc8404>.
[RFC8404]Moriarty，K.，Ed.和A.Morton，Ed.，“普及加密对运营商的影响”，RFC 8404，DOI 10.17487/RFC8404，2018年7月<https://www.rfc-editor.org/info/rfc8404>.
[RFC8406] Adamson, B., Adjih, C., Bilbao, J., Firoiu, V., Fitzek, F., Ghanem, S., Lochin, E., Masucci, A., Montpetit, M-J., Pedersen, M., Peralta, G., Roca, V., Ed., Saxena, P., and S. Sivakumar, "Taxonomy of Coding Techniques for Efficient Network Communications", RFC 8406, DOI 10.17487/RFC8406, June 2018, <https://www.rfc-editor.org/info/rfc8406>.
[RFC8406]亚当森，B.，阿吉，C.，毕尔巴鄂，J.，菲罗乌，V.，菲泽克，F.，加尼姆，S.，洛钦，E.，马苏奇，A.，蒙佩蒂特，M-J.，佩德森，M.，佩拉尔塔，G.，罗卡，V.，编辑，萨克森纳，P.，和S.西瓦库马尔，“有效网络通信编码技术的分类”，RFC 8406，DOI 10.17487/RFC8406，2018年6月， <https://www.rfc-editor.org/info/rfc8406>.
[SATELLITES] Kuhn, N. and E. Lochin, "Network coding and satellites", Work in Progress, draft-irtf-nwcrg-network-coding-satellites-02, November 2018.
[卫星]Kuhn，N.和E.Lochin，“网络编码和卫星”，正在进行的工作，草稿-irtf-nwcrg-Network-coding-SATELLITES-022018年11月。
[TCP-CONVERT] Bonaventure, O., Boucadair, M., Gundavelli, S., and S. Seo, "0-RTT TCP Convert Protocol", Work in Progress, draft-ietf-tcpm-converters-04, October 2018.
[TCP-CONVERT]Bonaventure，O.，Boucadair，M.，Gundavelli，S.，和S.Seo，“0-RTT TCP转换协议”，正在进行的工作，草案-ietf-tcpm-CONVERTS-042018年10月。
[USE-CASE] Napper, J., Stiemerling, M., Lopez, D., and J. Uttaro, "Service Function Chaining Use Cases in Mobile Networks", Work in Progress, draft-ietf-sfc-use-case-mobility-08, May 2018.
[用例]Napper，J.，Stiemerling，M.，Lopez，D.，和J.Uttaro，“移动网络中的服务功能链接用例”，正在进行的工作，草稿-ietf-sfc-USE-CASE-mobility-08，2018年5月。
Acknowledgements
致谢
The authors thank Brian Trammell, Brian Carpenter, Mirja Kuehlewind, Kathleen Moriarty, Gorry Fairhurst, Adrian Farrel, and Nicolas Kuhn for their review and suggestions.
作者感谢Brian Trammell、Brian Carpenter、Mirja Kuehlewind、Kathleen Moriarty、Gorry Fairhurst、Adrian Farrel和Nicolas Kuhn的评论和建议。
Authors' Addresses
作者地址
David Dolson (editor)
大卫·多尔森（编辑）
Email: ddolson@acm.org
Email: ddolson@acm.org
Juho Snellman
朱霍斯内尔曼
Email: jsnell@iki.fi
Email: jsnell@iki.fi
Mohamed Boucadair (editor) Orange 4 rue du Clos Courtel Rennes 35000 France
Mohamed Boucadair（编辑）法国雷恩市克洛斯科特尔街4号橙色35000
Email: mohamed.boucadair@orange.com
Email: mohamed.boucadair@orange.com
Christian Jacquenet Orange 4 rue du Clos Courtel Rennes 35000 France
克里斯蒂安·雅克内特·奥兰治法国克莱斯·科特尔·雷恩街4号35000
Email: christian.jacquenet@orange.com
Email: christian.jacquenet@orange.com