摘要

  • MASQUE 工作组草案第 15 版定义了经 HTTP 传送完整以太网帧的方法，但 HTTP 主体与帧内源 MAC 是两条不同的身份声明。
  • 101 或 2xx 只确认隧道建立；源地址过滤、VLAN 解释、环路防护、帧出接口和目的端效果各自需要凭据。

设想一个最容易误判的场景：员工用双向 TLS 通过认证，授权系统允许其访问实验网，HTTP/3 的 Extended CONNECT 收到 200，运维屏幕显示绿色。随后第一帧宣称自己来自实验网默认网关。认证过程可以完全正确，问题出在运营系统把“谁开启隧道”错误地当成了“他可以在隧道里代表谁”。

draft-ietf-masque-connect-ethernet-15 发布于 2026 年 9 月 30 日，是 IETF MASQUE 工作组拟走 Proposed Standard 的互联网草案。Datatracker 当前把它列在 IESG Evaluation、子状态 AD Followup；第 15 版发布后，IANA 审查回到“Version Changed - Review Needed”。它尚不是 RFC，冻结证据也不能证明部署、采用、实现一致性、性能或事故。

隧道成功的权限很窄

HTTP/1.1 以 GET、Connection: Upgrade 和 Upgrade: connect-ethernet 发起请求，成功必须返回 101 Switching Protocols。HTTP/2 和 HTTP/3 使用 Extended CONNECT，:protocol 为 connect-ethernet，符合条件的 2xx 启动 Capsule Protocol。草案对成功的定义很明确：代理已经建立以太网隧道，并愿意代理以太网帧。

这是一张隧道收据，不是未来每一帧的授权书。草案要求 TLS、QUIC 加密或同等机制，因而可以保护 HTTP 传输关系的机密性、完整性和认证。但加密外壳并不会替内部字段证明身份。

草案的安全考虑直接指出，用户可以发送任意以太网帧，包括任意源 MAC。这可能导致主机冒充、ARP 欺骗、IPv6 邻居发现欺骗、交换机 CAM 表污染以及拒绝服务。现代 HTTP 安全栈并没有消除二层接入的传统权力；它只是换了一条到达方式。

ARP、NDP 与 CAM 看到的是帧，不是 HTTP 账号

广播域内的其他设备通常不会看到开启隧道的 HTTP 主体。ARP 邻居收到的是地址映射声明，NDP 邻居看到的是 IPv6 邻居消息，交换机学习的是源 MAC 与端口的关联。若代理不把这些二层声明绑定到已经授权的主体，它们就会按各自协议运行。

因此，控制面至少要回答：一个账号允许使用哪些源 MAC；允许访问哪些目的 MAC、EtherType 和 VLAN；虚拟机或容器新增地址由谁批准；设备替换后旧地址何时撤销；应急权限何时到期。只把策略挂在 URI 上，可能把“进入实验网”的授权扩大成“扮演实验网任意节点”的能力。

草案列出若干本地办法：点到站连接可限制为单一源 MAC，端点可配置允许列表，也可以引入 IEEE 802.1X；代理应限制为已认证、已授权用户，并可限速。动态 MAC 过滤协商留给未来扩展。这意味着部署者不能等待协议替自己完成政策。

Context ID 0 只说明字节怎样解析

CONNECT-ETHERNET 使用 HTTP Datagram。Context ID 0 表示载荷是一帧以太网数据，从目的地址字段开始，到 FCS 之前结束。原 FCS 被省略，因为网卡通常在入站时剥离，在出站时重新生成。

这很好地说明了“完整性”与“来源”的区别。隧道保护能证明字节在受保护路径中没有被未授权更改，新的 FCS 能检查新的链路传输；两者都不能倒推源 MAC 属于 HTTP 用户。Context ID 也是请求内的格式状态，不是全局身份。未知 Context 可能因乱序而先到，接收方可静默丢弃或短暂缓存。

VLAN 与桥接另有一套治理

802.1Q 标签默认透明穿越隧道。如果入口或出口解释标签，双方需要通过信令或人工配置达成一致，但草案不定义这一程序。部署可以让每个 VLAN 对应不同 URI，也可以剥离后在出口重加标签。于是 URI—VLAN 映射、优先级和改写规则成为独立的高价值配置。

隧道概念上是一条点到点以太网链路。把它接入外部网络后，端点可能要承担交换或桥接职责，包括广播、多播、PAUSE 帧处理和环路防护；这些都不在机制范围内。两个各自正确的隧道和两个各自正确的桥接端口，仍可能组合成环路，触发广播风暴。STP/RSTP、由内核接管、已知无环拓扑、帧率监控与广播限速必须另行证明。

绿色隧道也会选择性丢帧

HTTP/3 的 QUIC DATAGRAM 不能分片。以太网帧若超过可用载荷，端点必须丢弃，不能暗中改用 DATAGRAM capsule。流上的 capsule 可以跨多个包可靠传输更大帧，但并非所有路径都保证帧顺序，尤其当中间设备重编码为 QUIC DATAGRAM 时。

解封装后，超过出口接口、目的网络或接收端帧长上限的帧也必须丢弃；草案建议保留超长帧计数。端点若不能把帧交给底层以太网段，同样丢弃。隧道存活与某一帧送达从来不是同一个事实。

完整凭据链应依次保留：HTTP 端点与主体；授权策略和版本；URI/VLAN 服务；101 或 2xx；Context 与传输模式；单帧源/目的策略；标签处理；桥拓扑和环路状态；队列与出口结果；目的端或上层应用观察。前四项不能替后六项签字。

本文以 Heng Lu 关于运行代码优先、最小初始规范与代理问题的论述作为公开的编辑视角：共享规范应精确协调共同部分，本地系统仍须为额外权力与效果举证；关键问题不仅是谁能连入，还包括谁能在广播域制造状态、谁能撤销和审计。这是分析框架，不是对 IETF 意图的陈述。

来源