draft-westerlund-masque-transport-issues-02：Transport Considerations for IP and UDP Proxying in MASQUE，July 2021
梗概
HTTP Connect 方法使用往返代理的背靠背 TCP 连接。这种解决方案处理了许多传输方面以及与 IP 流相关的问题。另一方面，对于 UDP 和 IP 代理，需要考虑多个按数据包和按流的方面以保留端到端 IP/UDP 流的属性。本文档的目的是突出显示与 UDP 和 IP 代理相关的这些问题并提供解决方案。
讨论场地
在作为 RFC 发布之前，将删除此注释。
本文档在 MASQUE 工作组邮件列表 (masque@ietf.org) 上进行讨论，该邮件列表存档于 https://mailarchive.ietf.org/arch/browse/masque/(https://mailarchive.ietf. org/arch/browse/masque/)。
可以在 https://github.com/gloinul/draft-westerlund-masque-transport-issues。
https://github.com/gloinul/draft-westerlund-masque-transport-issues
本备忘录的状态
本互联网草案完全符合 BCP 78 和 BCP 79 的规定。
Internet-Drafts 是 Internet Engineering Task Force (IETF) 的工作文件。请注意，其他组也可以将工作文档作为 Internet 草案分发。当前互联网草案的列表位于 https://datatracker.ietf.org/drafts/current/。
Internet-Drafts 是有效期最长为六个月的草稿文件，可以随时更新、替换或被其他文件淘汰。将互联网草案用作参考材料或引用它们而不是“正在进行的工作”是不合适的。
该互联网草案将于 2022 年 1 月 13 日到期。
版权声明
版权所有 (c) 2021 IETF Trust 和确定为文档作者的人员。版权所有。
本文档受 BCP 78 和 IETF 信托与 IETF 文档相关的法律规定 (https://trustee.ietf.org/license-info) 的约束，该规定在本文档发布之日生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文档中提取的代码组件必须包含 Trust Legal Provisions 第 4.e 节中所述的简化 BSD 许可文本，并且不提供如简化 BSD 许可中所述的保证。
1、 介绍
本文档检查了与 UDP [RFC0768] over IP [RFC0791] [RFC8200] (IP/UDP) 流相关的几个方面，当它们根据 QUIC 上的 MASQUE 提案进行代理并使用 HTTP CONNECT 方法进行流建立 (Connect-UDP) [ ID.ietf-masque-connect-udp]。它还研究了 UDP 之上的传输协议如何使用此信息，并将其与使用 TCP [RFC0793] 或 QUIC [RFC9000] 的 HTTP Connect 方法 [RFC7231] 以及 TURN 协议 [RFC8656] 使用的方法进行对比.
讨论的方面包括 ECN [RFC3168]、差分服务字段及其代码点 (Differentiated Services Field and its codepoint，DSCP) [RFC2474]、分片和 MTU、ICMP [RFC0792]、IPv6 FLOW ID [RFC8200]、IPv6 扩展报文头和 IPv4 选项 [RFC0791]。本文档还讨论了与 UDP 选项 [I-D.ietf-tsvwg-udp-options] 相关的 UDP 校验和的使用和 UDP 长度字段的使用。
1.1、 定义
* UDP Flow：UDP 流，共享一个 5 元组的 UDP 数据包序列。
* ECN：Explicit Congestion Notification，显式拥塞通知 [RFC3168]。
* DSCP：Differentiated Service Code Point，差异化服务代码点 [RFC2474]。
* Proxy：代理，本文档根据上下文使用代理作为 MASQUE 服务器或 HTTP 代理的同义词。
* Client：客户端，发起 MASQUE 隧道和与代理进行 UDP/IP 中继的端点。
* Target：目标，客户端希望与之建立双向通信的远程端点。
* UDP proxying：UDP 代理，代理通过 UDP“连接”将数据转发到目标。数据在代理处解封装，并在转发到目标之前由 UDP 和 IP 报文头修改。需要在客户端和代理之间保留或发送数据报边界。
* IP proxying：IP代理，代理通过IP“连接”将数据转发到目标。数据在代理处解封装并在转发到目标之前由 IP 报文头修改。需要在客户端和代理之间保留或发送数据包边界。
地址 = IP 地址 + UDP 端口
图 1：节点及其地址
图 1 提供了所涉及节点的概览图，即客户端、代理和目标，它们将在下面讨论。我们将名称目标用于客户端打算通过代理与之通信的节点或端点。还有两个网络路径。路径#1 是客户端到代理路径，其中 MASQUE 协议将通过 HTTP/3 会话（通常通过 QUIC）用于隧道 IP/UDP 流。路径#2 是代理和目标之间的路径。
客户端将使用代理的服务地址来建立传输连接，在该连接上使用 MASQUE 协议与代理进行通信。MASQUE 协议将用于建立来自客户端的 IP/UDP 流的中继，使用代理的外部地址作为源地址并发送到目标地址。另外，建立后，在proxy上也进行了反向配置；从目标地址发送到代理的外部地址的 IP/UDP 数据包将被中继到客户端。
1.2、 HTTP Connect
HTTP 连接方法 [RFC7231] 被定义为接收请求的 HTTP 代理将建立一个 TCP 连接到一个提供的（或解析的）目标地址。TCP 连接建立后，代理会将来自客户端的字节流连接到新 TCP 连接的字节流。在字节流级别，这只是隧道。另一方面，在传输层，建立了两个不同的传输连接。如果客户端到代理的连接是 HTTP/3，即通过 QUIC，基本的 HTTP Connect 方法仍然会导致从代理到目标服务器的 TCP 连接建立。在这种情况下，客户端代理 QUIC 流的字节流连接到代理到服务器的 TCP 连接。为简单起见，文档的其余部分将使用背对背 TCP 会话作为比较。
由于字节流语义和传输协议代理的使用，头字段及其值的大部分传输含义是在每个路径的基础上处理的，例如对 ECN 拥塞体验 (Congestion Experienced，CE) 标记的响应。如果代理支持，可以在连接之间复制或转换某些可能端到端相关的信息，例如 DSCP 值。由于在连接中流动的数据的字节流性质，MTU 几乎不相关并且完全处理。如果两条路径之间的 MTU 不同，则发送特定数据对象所需的数据包数量也可能不同。但是，其影响很小，取决于两个连接之间的缓冲量。两个 TCP 连接之间不要求数据包一一对应。
1.3、 TURN
“围绕 NAT 使用中继进行遍历 (Traversal Using Relays around NAT，TURN)：NAT 会话遍历实用程序的中继扩展 (Session Traversal Utilities for NAT，STUN)” [RFC8656] 是一种用于中继 UDP 数据报的解决方案。但是，它是纯封装隧道和代理之间的混合体。下面对该协议进行了稍微简化的描述。
客户端通过 TCP/TLS 连接向 TURN 服务器发出 TURN 请求，以对自身进行身份验证并获取长期机密。请注意，后续请求使用来自长期秘密交换的密钥材料进行保护。接下来，客户端可以通过 UDP 发送请求以在服务器的外部 IP 地址之一上分配 UDP 端口号。之后，客户端知道将用于发送到远程目标或从远程目标接收的任何 UDP 流的 TURN 服务器端的 IP 地址和 UDP 端口号。
TURN 客户端可以通过两种方式发送 UDP 数据包。第一种解决方案是为每个要中继的 UDP 数据包包括一个发送指示。发送指示包含目标目的地地址和端口。另一种解决方案是创建一个绑定，其中客户端和 TURN 服务器之间的通道 ID 绑定到从 TURN 服务器到目标目的地的特定 5 元组。建立的通道是双向的。建立通道后，UDP 数据包可以以 4 字节的低开销进行中继。
要在分配的端口上接收 UDP 数据包，客户端必须指定要允许的源地址和端口（目标地址），这称为建立权限。绑定一个通道同时创建一个权限。当 TURN 服务器从存在许可但没有通道的外部源接收到 UDP 数据包时，它将使用 DATA 指示中继数据，其中包括源地址。
本文档中其余讨论的一个相关方面是 TURN 在客户端和 TURN 服务器之间的 IP/UDP/TURN 消息与在外部接收或发送的 IP/UDP 数据包之间具有一对一的映射关系。此外，虽然 TURN 消息和指示在 UDP 有效载荷中包含报文头信息，但在 TURN 服务器的每一侧都有不同的 IP/UDP 报文头。因此，TURN 协议能够保留存在于 IP/UDP 报文头中的每个流和每个数据包的功能。例如，与特定数据包关联的 ECN 和 DSCP 标记由中继通过将它们从传入数据包复制或转换为传出数据包来保留。
1.4、 HTTP Connect-UDP
MASQUE WG 被授权在客户端和 MASQUE 服务器之间的 QUIC 连接中处理 UDP 数据报的隧道（我们将在本文档的其余部分中将 MASQUE 服务器称为代理以与基本的 HTTP 连接术语保持一致）。代理将隧道传输的 UDP 负载转发到正确的目标地址。HTTP Connect-UDP 请求用于建立隧道并提供所需的寻址信息。
在本文档中执行的审查中，我们假设需要最小化每个数据包的开销。具体来说，我们假设来自代理和目标之间交换的数据包的 IP/UDP 报文头信息不会在隧道内发送。需要为客户端想要与之通信的每个目标执行初始中继交换建立，即代理到目标路径上的每个 IP/UDP 流一个中继交换。在每个 UDP 流的基础上在代理中保持此状态似乎微不足道。因此，审查将确定每个流需要什么 IP/UDP 状态以及每个数据包信息需要什么。
在这篇评论中，我们还旨在通过在流和/或数据报模式下使用 QUIC 作为隧道协议来确定对端到端流的影响。将考虑 IP/UDP 流的属性和更高级别的传输协议，例如 QUIC 或 RTP。
将 Connect-UDP 与 TURN 进行比较时，需要进行两个高级观察。首先是 QUIC 是具有拥塞控制的适当传输协议。这意味着在相对于代理的任一路径上，影响传输的事件（例如拥塞指示）之间可能不存在一对一映射。第二个观察结果是，隧道化 UDP 数据报可以与多个 QUIC 数据包或多个 QUIC 数据报帧合并在单个 UDP 数据报中，单个 QUIC 数据包中。如果使用可靠流而不是数据报帧，则 UDP 有效负载甚至可能会被分割成多个包含 QUIC 数据包的 UDP 数据包。
这一切都激发了对 IP 和 UDP 报文头信息以及如何在流级别或每个数据包级别进行处理以避免破坏流的端到端传输属性的非常仔细的考虑。
2、 IP Header 的审查
2.1、 基本头部字段
本节回顾 IPv4 [RFC0791] 和 IPv6 [RFC8200] 中的报文头字段。它将记录哪些字段是特定于版本的。审查中不考虑大小差异，因为它侧重于功能和影响。
2.1.1、 版本
代理需要知道在代理上使用哪个 IP 版本来定位路径。如果在 Connect-UDP 请求中包含显式 IP 地址，代理将直接从 IP 地址格式中知道这一点。在使用域名获取目标IP地址的情况下，解析域名时需要指定IP版本或根据喜好选择IP版本。
需要注意的是，需要代理进行翻译的两条路径上可能使用不同的IP版本。这也可能导致一个路径上携带的版本特定信息不会转换为另一路径上使用的版本的情况。
2.1.2、 DSCP
Diffserv 代码点主要用于指示转发行为。代理到目标路径上的 IP/UDP 流上的代码点设置在流级别或数据包级别。在流级别设置的代码点在流实例化时设置，并且可以在正在进行的中继期间更新。
在目标到代理方向的 IP/UDP 数据包上接收到的 DSCP 值可以传播到代理到客户端路径。然而，当数据报在 QUIC 中隧道传输时，这是有问题的。面向连接的传输的 DART 考虑 [RFC7657] 在这里适用。如果多个 DSCP 用于单个连接，则需要为不同的转发行为设置单独的拥塞控制状态，这可能需要 QUIC 协议扩展。客户端发送到代理路径上的客户端的数据包存在相同的问题。
通过为每个使用的转发行为建立单独的 QUIC 连接，可以在没有 QUIC 扩展的情况下启用连接客户端和代理的路径的两个方向上的不同转发行为。但是，这要求代理能够将从客户端接收的多个 QUIC 连接绑定到代理上的单个 IP/UDP 流到目标路径。这可能会对安全模型产生重大影响，因为需要授权才能将后续绑定添加到现有流。
让我们考虑代理向目标发送带有数据包级 DSCP 标记的数据包的能力。这将至少需要每个数据包指示机制，并且可以在代理上启用不同的转发行为到目标路径。类似地，代理需要一个按数据包机制，以便能够将从目标接收到的 DSCP 值中继到客户端。后者的用处是确保 MASQUE 之上的传输协议能够确定是否需要针对接收到的 IP/UDP 流中不同分组子集的多个拥塞控制状态。WebRTC IP/UDP 流可以具有此属性。
最基本的 DSCP 中继功能是在代理发送到特定 IP/UDP 流的同一目标的所有 IP/UDP 数据包上设置相同的 DSCP 值。这种能力只需要在流建立时发送所需值的信号。还应考虑为正在进行的流更新 DSCP 值的机制。
DSCP 映射到转发行为的另一个问题是映射是按网络位置定义的，通常在一个路由管理域内。因此，它们可能会被重新映射到相对于代理的不同路径上。当客户端和代理位于两个不同的管理域中时，客户端将面临使用正确 DSCP 值的额外挑战。因此，MASQUE 协议中对 DSCP 的支持应该被限制为考虑每跳行为或映射表的使用，以便代理可以将传入的 DSCP 值转换为本地使用的值。
2.1.3、 ECN
显式拥塞通知 (Explicit Congestion Notification，ECN) [RFC3168] 字段携带每个数据包路径关于拥塞的信号。ECN 能力的讨论可以分为两部分，一个是针对与代理相关的每条路径。在客户端到代理路径上，用于隧道传输 UDP 数据包的 QUIC 连接可以在该路径上启用和使用 ECN。该路径上的任何拥塞经历 (ECN-CE) 标记都会影响客户端代理 QUIC 连接的拥塞窗口，从而间接影响端到端流量。
在代理上使用 ECN 到目标路径的能力需要代理协议支持。这将使 ECN 在上层传输协议中的端到端使用成为可能。为了在使用 MASQUE 代理时支持 ECN 端到端，需要存在两个功能。
首先，在从代理发送到目标的任何 IP/UDP 数据包上设置 ECN 字段值（Not-ECT、ECT(1)、ECT(0)）的能力。该值最初可以设置，但可以在正在进行的 IP/UDP 流代理期间更改，因为端到端传输可能随后确定该路径不支持 ECN。
其次，对于代理从目标接收的每个数据包，客户端必须能够接收每个数据包的 ECN 字段值的指示。这确保上层传输协议接收每个中继 UDP 数据包的 ECN 信息。该信息将用于对 ECN-CE（拥塞经历）标记作出反应并用于验证 ECN 路径能力。
由于多种原因，像 TURN 的 [RFC8656] 转换两条路径之间的 ECN 标记这样的解决方案是不可能的。首先，客户端到代理路径上的 ECN 标记将被用于隧道的 QUIC 连接消耗和响应。其次，前面讨论的 IP/UDP 数据包缺乏一对一关系会妨碍对 ECN 标记的准确跟踪，并使端到端验证失败。因此，代理和客户端之间需要额外的显式信令。
2.1.4、 标识、标志和分片偏移量（仅限 IPv4）
这些字段用于 IPv4 分片解决方案。作者认为应该避免 IP 级别的分片化。然而，由于不保证相对于代理的两条路径之间的一对一数据包关系，任何 IPv4 分片在端点和代理接收时都需要重新组装。
为了支持路径 MTU 发现，需要为从代理到目标的所有传出 IP/UDP 数据包设置不分片 (Don't Fragment，DF) 位。需要支持此位的每流或每包设置。
2.1.5、 流标签（仅限 IPv6）
网络使用 IPv6 流标签来识别流，例如，在执行基于等价多路径 (Equal Cost Multipath，ECMP) 路由 [RFC6438] 的负载平衡时，防止单个流分布在多条路径上。流标签应由发起 IP/UDP 流的端点设置，因为它知道流何时有资格获得唯一的 IPv6 流标签。因此，预计承载客户端代理QUIC连接的IP/UDP流将使用一个IPv6流标签，而MASQUE协议建立到不同目标地址的每个IP/UDP流使用一个IPv6流标签。
基于上述推理，似乎不需要 MASQUE 协议明确地发出信号或指示流标签。
2.1.6、 总长度/有效载荷长度
总长度 (IPv4) / 有效载荷长度 (IPv6) 字段包含 IP 数据包的大小，直接用于 IPv4，或间接用于 IPv6（通过提供固定 40 字节报文头后的长度，即用于扩展报文头和数据） .
这些字段对于接收处理是必需的，但是它不需要基于每个数据包与客户端通信，也不需要由客户端提供，在 UDP 长度的上下文中讨论了一个潜在的例外字段（第 3.2 节）。
2.1.7、 协议/下一个报文头
协议 (IPv4) 和下一个报文头 (IPv6) 字段提供上层协议的标识，在这种情况下是 UDP。对于 IPv6，一个或多个扩展报文头在到达 UDP 之前可能首先在链中被识别。
UDP 中继的使用需要明确通知以将其与其他类型的中继分开，例如 MASQUE 章程中讨论的 IP 隧道/中继。
2.1.8、 生存时间/跳数限制
生存时间 (IPv4) 和跳数限制 (IPv6) 字段的目的是防止数据包在路由循环的情况下具有无限的生命周期。从这里开始使用首字母缩略词 TTL 来描述这些字段中的任何一个。TTL 限制数据包存活的路由跳数，并且在它到期时应该会导致 ICMP 消息返回给发送者。因此，可以使用 TTL 来调查网络路径。
目前尚不清楚在 MASQUE 协议上下文中是否需要支持这种机制。如果要支持跟踪路由之类的东西，则需要对每个数据包设置 TTL 字段。
在从目标到客户端接收 IP/UDP 数据包时回显 TTL 字段值的需要似乎也非常有限。传输数据包时设置的值通常是操作系统设置的默认值。
作者认为代理的默认值足以满足 MASQUE 协议的功能。
2.1.9、 报文头校验和（仅限 IPv4）
IPv4 校验和字段验证完整性，防止传输或处理 IP 报文头中的非故意错误。IPv6 缺少此校验和，而是依赖于传输协议校验和。
该值是在从代理传输 IP 数据包并在接收时进行验证时生成的。不需要进一步的功能。
2.1.10、 源地址和目的地址
在从代理到目标的路径上，源地址将是中继 IP/UDP 数据包时应用的代理的外部地址。该地址将被确定为 IP/UDP 流隧道建立的一部分，并应由代理发回给客户端。使用的目标地址将是目标的 IP 地址。
客户端用于代理路径的源地址仅用于客户端和代理之间的通信，并且是 QUIC 连接状态的一部分。因此，更改它的可能性将取决于 QUIC 中处理客户端地址迁移或多路径的机制。不需要进一步讨论。
在 IP 代理的情况下，由于代理不能使用端口号，代理可能需要维护多个外部 IP 地址，以便识别从多个目标服务器接收的数据包的不同转发过程。如果代理保证在客户端和服务器之间的路径上，代理还可以将客户端的源 IP 地址保存为外部地址。
因此，源地址和目标地址是 IP/UDP 流中继的基本状态的一部分，需要在启动时建立。从代理到目标和反向的 2元组（IP 代理）或 5 元组（IP/UDP 代理）需要明确地发出信号。客户端需要明确提供目标 IP 地址或代理可以解析为目标 IP 地址的域名。当在代理上发送到目标路径时，代理需要通知客户端它使用哪个源 IP 地址。
2.2、 IPv4 选项头
IPv4 选项报文头在一般 Internet 上的使用非常有限。因此很可能不需要任何功能。
2.3、 IPv6 扩展头
这里需要讨论的一个 IPv6 扩展报文头是分片报文头。尽管添加分片报文头的是 IP 发起节点，但 MASQUE 协议可能需要控制是否应使用 IPv6 分片，就像对 IPv4 DF 位一样。
发起节点可以添加一些现有的 IPv6 扩展报文头。需要进一步调查它们是否需要向客户端发送任何明确的信号或中继数据。尤其是 Hop-by-Hop 选项，例如 IPv6 最小路径 MTU Hop-by-Hop 选项 [I-D.ietf-6man-mtu-option]。
还有一些关于未来可能重要的扩展报文头的单独建议：网络令牌 [I-D.yiakoumis-network-tokens]、IPv6 Truncate 选项 [I-D.leddy-6man-truncate]。因此，需要考虑是否有必要在未来证明 Masque 协议，至少使未来的扩展能够支持每个数据包的扩展头。
3、 UDP Header 的回顾
3.1、 源和目的端口
对于 UDP 代理，端点使用 UDP 目标端口来定位应该使用特定 UDP 数据报的目标进程。接收应用程序可以使用源端口来基于 5 元组分离流。
如第 2.1.10 节所述，UDP 源端口和目标端口是 5 元组的一部分，需要在 IP/UDP 流建立时进行通信。
3.2、 UDP长度
UDP 长度字段以八位字节为单位指定 UDP 有效载荷长度。
UDP 长度字段通常表示 UDP 有效载荷填满了 IP 数据包的其余部分。然而，这并非总是如此。具体来说，UDP 选项 [I-D.ietf-tsvwg-udp-options] 旨在利用 UDP 数据段末尾和 IP 数据包末尾之间的剩余区域。
因此，为了让 MASQUE 协议保留在 UDP 中继这个剩余区域中携带 UDP 选项的能力，UDP 有效载荷数据长度字段需要从客户端双向传输到代理。
3.3、 UDP 校验和
UDP 校验和使用 IP 层信息验证 UDP 数据报报文头和有效载荷以及伪报文头。UDP 校验和应始终由接收方验证。UDP 校验和也可以设置为零以不提供验证。这主要用于隧道封装格式。如果希望将 IP/UDP 流从代理发送到具有零 UDP 校验和的目标地址，则 MASQUE 协议需要支持此愿望的指示。
由于缺少 IP 报文头校验和 [RFC6936]，IPv6 零 UDP 校验和的使用比 IPv4 受到更多限制。
作者认为没有必要能够发送带有零 UDP 校验和的 IP/UDP 数据报。也没有必要中继目标生成的 UDP 校验和，因为 QUIC 协议将为 UDP 数据报负载提供更强的加密完整性验证。此外，为了使目标生成的校验和对客户端有意义，需要重建完整的数据报和伪报文头，这可能需要额外的处理和数据复制。虽然通过这种方式可以检测到 MASQUE 协议对 IP/UDP 报文头字段的错误处理的某些情况，但认为这样做并不值得。
对于客户端发送的要中继到目标目的地的数据包，让客户端创建 UDP 校验和将提供一些防止处理或实现错误的保护，尽管开销和额外的处理可能不值得付出努力。
此外，传输报文头校验和的计算和验证是可以卸载到代理中的硬件的这些方面之一。
4、 ICMP
Internet 控制消息协议 (Internet Control Message Protocol，ICMP) [RFC0792][RFC4443] 消息是有关为什么发送的 IP 数据包在网络中消失的有用提示。特别是对于看似间歇性的问题，例如超过路径的 MTU。
让我们首先阐明哪些 ICMP 消息可能与 MASQUE 协议中的处理相关。主要关心的是确保客户端接收任何 ICMP 响应，这些响应作为客户端通过代理向目标目的地中继的数据包的结果而发送回代理。代理应验证和识别与代理发送的特定 IP/UDP 流相关的 ICMP 消息。相关的 ICMP 信息，即类型和代码以及数据包中可用于识别客户端中实际 IP/UDP 数据包的任何包含的字节，应发送到客户端。这样的功能将使客户端能够接收加速路径 MTU 发现的 Packet Too Big 消息（第 5 节）。它还使客户端能够了解何时目标地址上似乎没有人，即端口、主机或网络不可达代码。
从目标地址到达代理的 IP/UDP 数据包可能会导致 ICMP 消息被发送回目标。例如，如果数据包在客户端终止隧道会话后到达，则会发送端口不可达消息。
由客户端和代理之间交换的 IP/UDP 数据包产生的与 QUIC 连接相关的任何 ICMP 数据包都将被 QUIC 实现验证和使用。
因此，根据 ICMP 消息，MASQUE 协议需要考虑一种代理机制，以向客户端表明它已收到并验证了 ICMP 消息。如果 ICMP 消息指示连接失败，则可以使用 HTTP 响应错误代码。但是，对于 HTTP Connect-UDP，响应代码是在创建 UDP 套接字时发送的，而 ICMP 消息仅在中继 UDP 数据包后才会收到。
5、 最大传输单元（MTU）
UDP 有效负载可用的 MTU 取决于 QUIC 连接是使用数据报还是流在客户端到代理路径上携带 UDP 有效负载。当使用流时，外部 QUIC 连接可以对任何大小的 UDP 负载进行分片和重新组装。在这种情况下，代理到目标路径上将出现任何 MTU 问题。
使用数据报时，除非 QUIC 数据报扩展提供分片解决方案，否则外层 QUIC 连接将提供一个 MTU，该 MTU 取决于可以传输的最大数据报负载。一个潜在的问题是，这可能会随着时间的推移而变化，这既是由于基础路径的变化，也是由于 QUIC 协议的可变元素。但是，应该可以根据最大 QUIC 数据包大小计算来自 QUIC 报文头的基本开销。根据需要为 MASQUE 封装提供额外净空的每个数据包信息的数量，可能需要。
要启用 PMTUD 发现，需要某些方面或极大地简化过程。
* 确保在从代理到目标的传出 IPv4/UDP 数据包上将 DF 位设置为 Don't Fragment。对于 IPv6，需要防止使用分片报文头。
* 将代理信号返回给客户端，其当前接口 MTU 限制将从代理发送到目标的数据包。
* 让隧道 QUIC 连接向 MASQUE 实现公开数据报的当前 MTU。这可能是动态的，可以随时更新。
* 当由于代理到目标路径上的 MTU 而丢弃数据包时，从代理向客户端返回 ICMP 数据包太大 (Packet Too Big，PTB) 消息。
应该注意的是，除非 QUIC 数据报扩展提供分片机制，否则在许多情况下这将是最有可能的 MTU 瓶颈并且没有解决方法，IP/UDP 隧道流量将需要适合或被丢弃。
5.1、 IPv6 分片
接收流量的重组将发生在每个节点、客户端、代理和目标上。通过向上传播工作 MTU，应该避免 IP 级分片的需要。流的初始 MTU 信令应该存在。但是，这可能是动态的，并且为客户端到代理路径上的外部 QUIC 隧道运行的 PMTUD 进程将更新支持的 MTU。
应该考虑通过代理控制是否应该发生分片的选项。
5.2、 IPv4 分片
由于 IPv4 分片很灵活，并且允许路径上的节点对数据包进行分片，因此启用分片可以减少 MTU 问题。但是，建议改为使用路径 MTU 发现，原因如下：
* 分片会增加丢包率。
* IP 分片不能很好地穿过 NAT 和防火墙。这与 MASQUE 尤其相关，因为重要的部署将是在从客户端到代理的路径上具有 NAT 或防火墙的接入或住宅网络中的客户端。
6、 总结
让我们在几个类别中总结 IP/UDP 报文头字段和相关协议的各个方面。
6.1、 UDP 流信息和配置
此部分包含报文头字段，其值对于给定的 IP/UDP 流将是静态的，应用直到更改，或者可以在未给出每个数据包值时用作默认值。
首先，IP源地址和目的地址以及UDP源和端口信息直接关系到代理和目标之间双向IP/UDP流的建立。如果地址表示为主机名，则还需要指明所需的 IP 版本，否则将通过地址格式给出。目标始终需要由客户端提供。由于在某些情况下客户端需要知道代理对目标使用的外部地址，因此客户端需要有一种方法来请求此信息。
客户端和目标之间的上层协议可能具有使用 ECN 的不同能力。因此，必须能够用信号通知目标数据包的代理中的 ECN 字段是否应设置为 Not-ECT、ECT(0) 或 ECT(1)。
如果需要除 0 以外的 DSCP 标记，即尽力而为，则可以将默认值设置为中继建立的一部分。这个值可能会在每个数据包的基础上被覆盖，或者在中继流生命周期的未来点被改变。
不分片设置可能会默认为始终为真。但是，如果在某些情况下为某些数据包或所有数据包启用 IP 级分片会更好，我们邀请进一步讨论。
跳数限制可能会使用节点默认值，除非有人提出一个用例，他们实际上想要在每个数据包的基础上调制值或为 IP/UDP 流设置显式值。
代理对指定目标已知的 MTU 应在代理建立中继时发回。
6.2、 每个数据包的潜力信息
此部分包含在客户端请求发送或代理中继接收到的数据包时与特定数据包相关联所需的信息。
对于每个数据包，代理接收到 ECN 字段的值需要中继到客户端，以便上层可以响应指示拥塞的 CE 标记或任何重新标记。
有一些示例，其中 IP/UDP 流包含没有统一 DSCP 标记的数据包。要启用此类流的发送，客户端需要向代理指示除默认值之外的任何 DSCP 值。
如果需要验证客户端中的 UDP 校验和以避免任何潜在错误，MASQUE 协议实现可能会导致接收到的 UDP 校验和值需要中继到客户端。UDP 校验和值也可以由客户端计算并包含在内。
要支持 UDP 选项，需要通知 UDP 选项及其值。
如果支持包含需要客户端信息的 IPv6 扩展报文头，则扩展报文头信息将需要由客户端指示并通过隧道传输。
6.3、 基于事件的交互
本节总结了由事件触发且未直接连接到正在中继的 IP/UDP 流中的特定数据包的信息。相反，这些更多是由网络、上层传输协议或应用程序引起的异步事件的性质。
代理发送到目标的数据包的 ECN 设置可能需要更改。如果上层传输协议确定端到端路径不支持 ECN，则需要将 ECT 标记更改为 Not-ECT。某些协议可能会推迟对 ECT 功能的探测，直到发生某些初始握手和数据包交换之后。
上层应用程序可能会更改其对 IP/UDP 流中的数据包的期望转发行为，因此客户端需要更改由代理发送到目标的数据包的默认应用 DSCP 值。
代理接收 ICMP 消息可能是发送到目标的数据包的结果，但原因可能在网络中。发生这种情况时，需要将此 ICMP 消息通知客户端，尤其是当此事件导致连接失败时。
由于接收到的 ICMP 消息在代理的 IP 堆栈中消耗并影响传出数据包的 MTU，代理可能会检测到代理到目标路径上的 MTU 更改。因此，代理可能需要向客户端指示它不再可以发送大于新 MTU 的非分片数据包。
7、 结论
该文档表明，IP/UDP 报文头中的许多字段可以在流建立时最初发出信号。特别是 IP 地址和潜在的端口需要进行通信，因为它们也需要用于流识别。它还表明某些字段值或相关信息需要根据异步应用程序或网络事件进行中继或发送信号。每个数据包中继可能需要其他字段信息。后者需要代理和客户端之间更活跃的双向通信通道。
这些方面都需要在 CONNECT-UDP 方法的未来协议开发中加以考虑，以确保 MASQUE 协议不会阻止未来的 IP 和传输协议的演进。
8、 参考文献
8.1、 规范参考
[I-D.ietf-masque-connect-udp]Schinazi, D., "The CONNECT-UDP HTTP Method", Work in Progress, Internet-Draft, draft-ietf-masque-connect-udp-03, 5 January 2021, <https://datatracker.ietf.org/doc/html/draft-ietf-masque-connect-udp-03.txt>. [I-D.ietf-tsvwg-udp-options] Touch, J., "Transport Options for UDP", Work in Progress, Internet-Draft, draft-ietf-tsvwg-udp-options-13, 19 June 2021, <https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-udp-options-13.txt>. [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI 10.17487/RFC0768, August 1980, <https://datatracker.ietf.org/doc/html/rfc768>. [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, DOI 10.17487/RFC0791, September 1981, <https://datatracker.ietf.org/doc/html/rfc791>. [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, DOI 10.17487/RFC0792, September 1981, <https://datatracker.ietf.org/doc/html/rfc792>. [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, DOI 10.17487/RFC2474, December 1998, <https://datatracker.ietf.org/doc/html/rfc2474>. [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://datatracker.ietf.org/doc/html/rfc3168>. [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, <https://datatracker.ietf.org/doc/html/rfc8200>. [RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based Multiplexed and Secure Transport", RFC 9000, DOI 10.17487/RFC9000, May 2021, <https://datatracker.ietf.org/doc/html/rfc9000>.
8.2、 参考资料
[I-D.ietf-6man-mtu-option]Hinden, R. M. and G. Fairhurst, "IPv6 Minimum Path MTU Hop-by-Hop Option", Work in Progress, Internet-Draft, draft-ietf-6man-mtu-option-05, 28 April 2021, <https://datatracker.ietf.org/doc/html/draft-ietf-6man-mtu-option-05.txt>. [I-D.leddy-6man-truncate]Leddy, J., Bonica, R., and I. Lubashev, "IPv6 Packet Truncation", Work in Progress, Internet-Draft, draft-leddy-6man-truncate-05, 10 October 2018, <https://datatracker.ietf.org/doc/html/draft-leddy-6man-truncate-05.txt>. [I-D.yiakoumis-network-tokens]Yiakoumis, Y., McKeown, N., and F. Sorensen, "Network Tokens", Work in Progress, Internet-Draft, draft-yiakoumis-network-tokens-02, 22 December 2020, <https://datatracker.ietf.org/doc/html/draft-yiakoumis-network-tokens-02.txt>. [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, DOI 10.17487/RFC0793, September 1981, <https://datatracker.ietf.org/doc/html/rfc793>. [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", STD 89, RFC 4443, DOI 10.17487/RFC4443, March 2006, <https://datatracker.ietf.org/doc/html/rfc4443>. [RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label for Equal Cost Multipath Routing and Link Aggregation in Tunnels", RFC 6438, DOI 10.17487/RFC6438, November 2011, <https://datatracker.ietf.org/doc/html/rfc6438>. [RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement for the Use of IPv6 UDP Datagrams with Zero Checksums", RFC 6936, DOI 10.17487/RFC6936, April 2013, <https://datatracker.ietf.org/doc/html/rfc6936>. [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", RFC 7231, DOI 10.17487/RFC7231, June 2014, <https://datatracker.ietf.org/doc/html/rfc7231>. [RFC7657] Black, D., Ed. and P. Jones, "Differentiated Services (Diffserv) and Real-Time Communication", RFC 7657, DOI 10.17487/RFC7657, November 2015, <https://datatracker.ietf.org/doc/html/rfc7657>. [RFC8656] Reddy, T., Ed., Johnston, A., Ed., Matthews, P., and J. Rosenberg, "Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)", RFC 8656, DOI 10.17487/RFC8656, February 2020, <https://datatracker.ietf.org/doc/html/rfc8656>.
