摘要

  • RFC 1681 建议把谁付费的类别，或计费算法表的索引，编码进目的地址，让客户端与边界路由器能在接触服务前采取行动。
  • 文档认为事后才知道成本不可接受；有些网络交互没有人工确认环节，Gopher 重定向甚至可能绕过应有的付费提示。
  • 地址只能提供政策输入。它不能独自证明真实用户、当时有效的价格、知情授权、有效交付、准确计量、合法账单或最终结算。

问题不是有没有提示，而是提示是否来得及

RFC 1681 在计费章节里设想了一种风险：某个 Gopher 服务把调用者重定向到按次付费的地址，却不显示所需警告。这里没有一宗被证实的 Gopher 欺诈案。它是一项设计压力测试，追问软件会不会在用户理解成本之前，已经替用户越过商业边界。

文档因此否定了“连接时再弹出消息”这个看似简单的方案。许多交互根本没有插入人工动作的接口。等远端接触已经发生，警告即使可见，也可能晚于计费事件。

Bellovin 的建议，是让目的地址先说话：地址中的一些比特决定谁承担费用；如果使用更多比特，地址还可以成为计费算法表的索引。机构边界路由器据此识别付费服务，并在转发前执行本地规则。

这不是把发票塞进 IP 地址。它把一个可供机器判断的类别提前放到普通网络路径能看到的位置。地址是选择器，真正的金额、单位、期限与责任仍在地址之外。

“一台主机一个地址”的估算失去了把握

RFC 1681 的起点其实是地址容量。当时多数终端主机只有一个地址，地址空间需求也常按主机数量估算。文档提醒：一台主机若为了不同服务、不同访问政策、不同用户或短程移动而需要多份地址，按机器计数可能严重低估需求。

第二地址可以代表服务，而不是当前承载服务的那台机器。服务迁移后保留原地址，可以减少外部变化。同一主机也可以用不同地址提供不同视图，让防火墙只开放其中一个服务地址。前提是进程正确绑定，而且地址认证原有的风险并没有消失。

文档也考虑过让 DNS 连同地址返回端口信息，但担心所有相关客户端都要升级。把差异放进地址，是在利用已部署客户端本来就认识的连接对象。

便利的另一面，是一个字段开始背负多个时间尺度：主机定位、服务身份、访问类别、登录会话、移动锚点和计费政策。服务地址可能跨越机器寿命，会话地址只活到退出，计费表却可能在地址不变时更新。仅凭一串比特，无法保存这些变化发生时的版本关系。

四种付款关系，仍不足以组成一张账单

RFC 1681 列出四种可能的按使用量收费方式。传统模式让每台主机为自己发送的分组付费，因此一场通信的双方都可能承担成本。第二种是呼叫方付费。第三种类似电话的对方付费。第四种像美国“900”电话，由调用者为访问服务支付溢价。

文档由此提出硬条件：调用方与接收方必须预先知道谁付费。事后才得知已经产生费用，不可接受。

但“谁付费”只是计费合同的一格。RFC 1125 早先把计费政策拆成记账单位、计费依据、实际金额、付款或收款主体、采用谁的分组计数，以及费用上限。即使路由器正确识别了付费类别，它仍不知道哪一版价格表有效、按字节还是按分组收费、哪个计数器有权、是否超过授权额度。

RFC 1681 提出的表索引，反而把这一缺口照得更清楚。地址如果指向第 37 行，含义存在于某个运营者在某个时刻维护的第 37 行。只保存地址、不保存当时的表与版本，日后只能知道“选了哪一行”，却无法还原那一行曾经承诺什么。

路由器可以拒绝，但不能替人同意

文档设想机构边界路由器限制付费服务，例如不允许宿舍机房里的匿名工作站接受对方付费呼叫。这是清楚而有限的控制面：本机构管理的一台设备，依据本地规则，对某类流量作出放行或拒绝。

放行并不等于用户同意。源地址可能由多人共享，程序可能自动行动，账户所有人可能只授予有限额度，远端服务使用的条款也可能已经不同于边界设备看到的表。网络决定完全正确，商业责任仍可能有争议。

RFC 1681 进一步设想：每次登录给用户分配一个临时 IP 地址。路由器继续按地址收集用量，主机记录地址与会话的对应关系，之后离线计费；不同用户类别还可获得允许或禁止昂贵服务的不同地址形式。

这提高的是记录可拼接性，而不是身份魔法。调查者至少要同时取得路由器计数与主机的带时间会话表，还要验证登录主体、授权范围、适用价格和服务记录。用户专属地址可以缩小候选范围，却不能证明当时是谁操控会话、谁批准了具体费用。

历史记录不能被倒写成部署事实

RFC Editor 的记录 把 RFC 1681 列为 Informational。它回应的是 RFC 1550 发起的 IPng 白皮书征集；RFC 1681 自己明确说，发表不代表 IPng 领域接受其观点。RFC 1550 也把这些白皮书定位为选择过程的参考材料和历史记录。

后来，接口拥有多个 IPv6 地址成为标准架构的一部分。RFC 4291 规定地址分配给接口，一个接口可以有不同类型和作用域的多个地址。这不能倒推为 IPv6 采用了 RFC 1681 的计费比特，更不能证明两者存在因果传承。

服务定位也有了专门记录。RFC 2782 的 SRV 记录明确携带服务、协议、优先级、权重、端口与目标，并要求相关应用协议规定使用方式和安全考虑。它帮助客户端找到服务，却没有标准化价格、付款人、同意、计量或账单。

RFC 1681 建议为每台主机预留 2^6、甚至 2^8 个额外地址的增长空间。这是面对多种潜在用途的规划余量，尤其考虑了昂贵的“每用户一地址”设想；它不是实际平均用量，也不是已经分配的权益。

从信号到结算，每一步都要留下自己的凭证

若真要让这类系统可审计，至少要分别保存：选中的目的地址；地址类别或表索引；当时有效的解释表及其所有者；边界放行结果；经过认证的用户或账户；承诺前展示的条款与同意；远端接纳和实际服务；计量单位、计数器与时间段；账单算法、付款人与上限；最后的支付、撤销或争议结果。

前一步不能自动证明后一步。识别类别不证明表是最新的；路由器放行不证明人同意；连接成功不证明服务有用；分组计数不证明单价正确；开出账单也不证明已经支付。

Heng Lu 的 Running-Code Primacy 提供第一条纪律：提案、出版物与地址标签都不能冒充已经采用并被观察到的运行事实。Minimum Initial Specification 要求把真正需要共享的互操作语义，与可以留给参与者本地决定的商业安排分开。Reality, Not Advocacy 则限定叙事：既不复活这套计费地址，也不嘲讽它，只报告它解决了什么、又没有证明什么。

RFC 1681 想让网络在花掉某个人的钱之前，先从地址读到一项规则。留下来的价值不是那组未被证明部署的比特，而是一条次序原则：机器可读的事前信号只有在身份、授权、交付、计量和结算仍可独立核验时，才真正减少意外。

来源