摘要
- RFC 4084 用中性术语区分网页接入、仅客户端接入、防火墙接入与完整互联网连接;它不是服务等级裁判,而是要求供应商把功能和限制说清楚。
- 一份有效的能力回执必须把宣传、合同、供应商配置和实测结果分栏记录。临时可用的中继、隧道或穿透方案,不能自动升级为供应商承诺。
同一个名称,五种不同的可运营边界
采购合同上写着“互联网接入”,上线验收却常被缩成两个动作:打开网页和运行测速。随后,真正的业务才开始暴露差异。分支办公室的 VPN 空闲后失联;外部监控无法主动进入;点对点应用在一条网络上直连,在另一条网络上只能走中继;邮件必须经过供应商服务器;终端看到的是私网地址,而网站看到的公网地址由多人共享。
这些现象并不一定说明供应商违约。更基础的问题是,合同从未明确承诺那些能力。
RFC 4084 于 2005 年作为 BCP 104 发布,正是为了处理这种语义空洞。它提出网页连接、无公网地址的仅客户端连接、有公网地址的仅客户端连接、防火墙互联网连接和完整互联网连接。文件特意强调,这些称呼不是贬义排序。较窄的服务可能适合较窄的需求;列出一种模式也不等于 IETF 推荐它。关键在于,用户必须知道自己买到的功能。
因此,能力回执不是给“完整互联网”贴金,而是把购买对象从一个大词拆成一组可检验的动词。
公网地址、入站可达与合同许可彼此独立
RFC 4084 最有价值的地方,是不把地址与能力混为一谈。没有公网地址的客户通常依赖 NAT,服务器和许多点对点功能受到限制。有公网地址的客户,多数 VPN 可能可用,但供应商仍可通过合同禁止服务器,或过滤外部发起的连接。完整互联网连接则要求地址和流量限制达到更强的边界,供应商施加的 NAT、代理、拦截和端口限制与该名称不相容。
所以验收表不能只写“IPv4:有”。它至少要记录 IPv4/IPv6、是否独享、是否稳定、是否被外部标为动态地址、反向 DNS、地址转换位置、入站连接范围,以及谁拥有配置权。如果防火墙是客户购买的托管安全选项,就应明确标为客户请求;如果是接入产品默认限制,也应明确归给供应商。
RFC 4787 又把 NAT 的两个事实拆开:映射行为不等于过滤行为。映射可能相对稳定,外来数据包仍要按另一套条件被允许;状态会超时,外发流量可能刷新映射,不同远端也可能得到不同结果。一次 P2P 直连,只证明某一时刻、某一对端和某一状态组合成功。
这也是“绕过方法”不能冒充产品能力的原因。ICE、中继或应用层隧道可以让业务恢复,这是工程成果;但它不能证明供应商支持入站服务,也不能证明合同允许运行服务器,更不能保证网络调整后仍然有效。
回执应有四本账
第一本是宣传账:产品名、版本、页面承诺、销售说明与发布时间。它保留购买前供应商如何描述服务。
第二本是合同账:服务器、P2P、地址稳定性、VPN、邮件、过滤、客户自选防火墙、可接受使用规则和支持责任。它回答哪些成功结果有义务继续维持。
第三本是配置账:供应商控制的 NAT、防火墙、入站/出站端口、代理、流量改写、DNS、ICMP、隧道、邮件转发,以及客户要求的安全规则。它必须带日期或变更标识,不能只有一个永久的“已开启”。
第四本是观察账:测试时间、内外测量点、两端看到的地址、协议、端口、方向、空闲间隔、重复次数、成功与失败、已知不确定性。它不替合同改口,也不从现象猜测动机。
回执还需要三个醒目标志:客户请求、依赖绕过、重新测试触发器。它们能阻止两种常见误判:把企业自己的防火墙怪到接入网头上,或把供应商限制笼统归入“安全需要”而无人负责。
邮件是一面最诚实的镜子
RFC 4084 对邮件限制着墨很重,因为“网页邮件能用”最容易制造假完整性。供应商可能强制使用自己的提交服务器,阻断外部 SMTP,改道邮件流量,限制 POP3/IMAP4,或者把地址标为动态,从而影响外部系统接收邮件。
回执要分别记录认证提交、任意外部 SMTP、远程收取、允许的发件域、反向 DNS、地址信誉处理和流量改道。一次邮件成功,并不能证明自建邮件服务可持续运营。
同样,VPN 不能只写“支持”:要写隧道类型、方向、空闲状态、地址变化与后备传输。DNS 要写能否访问任意解析器、是否被重定向。ICMP 要写哪些诊断信息能通过。HTTP、HTTPS、SMTP、FTP 以及供应商不识别的应用,都要区分禁止、过滤、拦截与未测试。
每项限制都要有责任主体
RFC 7754 区分制定规则的人与执行规则的人。一次超时、一条复位或一个异常 DNS 答复,只是观察,不能独自证明动机、合法性、授权链或政策来源。
能力回执因此不能只写“被封”。它应说明谁要求限制、谁实施限制、在哪个技术边界观察到、合同有没有对应条款。比如:“从两个独立外部网络发起的 TCP 25 入站测试均失败;客户托管防火墙未启用该规则;合同列明供应商出站邮件限制,但没有入站条款。”这种小而精确的陈述,既方便修复,也经得起复核。
来源
- RFC 4084 / BCP 104 — Terminology for Describing Internet Connectivity
- RFC 4787 / BCP 127 — NAT Behavioral Requirements for Unicast UDP
- RFC 7754 — Technical Considerations for Internet Service Blocking and Filtering
- Lu Heng — Running-Code Primacy
- Lu Heng — Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption
会员简报
档案背景详情
使用相应会员等级登录,即可解锁完整简报与来源注释。
仅限 Strategic Circle
Strategic Circle
所有读者均可浏览。加入并登录后可解锁档案简报。
加入 Strategic Circle仅限 Leadership Alliance
Leadership Alliance
符合条件的 IP 资产所有者和管理层可登录查看 Leadership Alliance 简报。
加入 Leadership Alliance

