摘要

  • AFPUB-2018-V6-002-DRAFT01 的关键贡献，是把原接收方仍在运营的链路上，第三方临时使用一个地址或一个 /64，与控制权真正转移给下游网络区分开来；它不是另一份编号为 AFPUB-2018-V6-001-DRAFT01 的提案。
  • 官方页面分别留下了 2018 年 3 月 14 日“提交”和 3 月 20 日初稿发到 rpd 的记录。5 月 9 日 AFRINIC-28 的结论是“仍需讨论”，草案回到邮件列表修改，不能被写成已经达成共识、批准或实施的规则。
  • 草案以“临时、第三方、原接收方运营的链路”为安全边界，涵盖访客、员工、热点、VPN、设备、服务器和点到点接口，却仍把永久连接或宽带服务留在禁区；这个边界有助于行政辨识，但把服务标签当成决定性标准仍然过宽。
  • AFRINIC 的正当角色是私人技术登记者与协调者：当持有者、独立控制、联系人、唯一性或安全状态真实改变时更新登记；它无权凭“客户”“宽带”或“永久”这些词决定合法网络关系是否可以存在。

L3 — 看似转让、实为临时连接的 /64

先把最小场景说清楚。一家公司是某段 IPv6 地址空间的原接收方，也继续运营办公室的无线接入点、边缘路由器和上游链路。会议当天，一名来访者输入访客网络凭证，手机获得一个 IPv6 地址，或者获得只供该终端使用的 /64。访客没有取得地址空间的处分权，没有接管路由器，没有成为能独立改变登记资料的下游运营者，也没有令同一前缀同时由两个互不协调的主体使用。连接结束，临时配置随之失效。若仅因使用者是“第三方”，就把这一动作归入被禁止的再分配，登记语言便会把设备接入误写成权利或控制的转移。

这正是草案一号针对的困难。它的正式标识是 AFPUB-2018-V6-002-DRAFT01，题为对 IPv6 再分配的澄清。规划指纹里出现过 AFPUB-2018-V6-001-DRAFT01，但那个编号属于另一项 IPv6 政策与引用更新，不能用来替代本案的主文书。编号之差不是排版小节：如果把两个提案混为一谈，事件的对象、文本和讨论轨迹都会错位。本文所分析的只有编号以 V6-002 结尾的第一稿，以及它提出的临时使用例外与资格测试。

日期也必须保留为两项不同记录。官方详情栏把提案记为 2018 年 3 月 14 日提交；同一官方页面的修订历史则把初稿发到 rpd 的日期记为 3 月 20 日。一个字段描述提交，一个字段描述初稿公开进入讨论渠道，二者并不互相取消。因而，准确说法不是从中挑一个日期冒充全部历史，而是说明：3 月 14 日是页面上的提交记录，3 月 20 日是修订历史中的初稿发布记录。后一日期构成本文所聚焦的公开讨论事件，而前一日期仍是不可丢失的官方元数据。

草案拟处理的是 CPM 6.8 中关于 assignment 与 sub-assignment 的边界。它指出，既有语言没有充分照顾某些真实网络形态：点到点链路、VPN、公共或机构热点、访客接入、员工设备、自带设备，以及每个接口或主机拥有唯一 /64 的部署方式。共同问题在于，地址的直接使用者和地址空间的原接收方不是同一个人或同一台设备，但这并不自动意味着网络控制已经转手。IPv6 的拓扑安排可以把一段看起来很大的地址单元放在单个接口或主机上；从十进制直觉看，/64 所含地址极多，可政策动作处理的却只是“一个地址或一个 /64”这一配置单位，而不是把原接收方所持的更大资源整体交付给别人。

草案一号提出的例外有三个互相约束的要素。第一，给予第三方的是唯一地址或唯一 /64，而不是一张可以无限转授的空白支票。第二，使用是非永久的。第三，地址在原接收方运营的链路上使用。只有把三个要素放在一起，才看得出它想保护的并非任何以“临时”为名的安排，而是控制面仍留在原接收方网络内的短期接入。第三方持有终端不等于第三方拥有一张独立网络；终端能发送数据也不等于其使用者能决定前缀如何对外宣告、由谁维护联系人、怎样处理安全事件，或怎样修改登记记录。

草案列出的例子说明了这一结构。访客和员工可以在机构运营的网络上使用地址；设备或服务器可以获得地址或 /64；热点用户可以在热点经营者控制的接入设施上联网；VPN 端点可以在会话中使用配置；点到点接口则需要地址来构成链路。这些例子不是把每台设备抬升为独立的法律主体，也不是宣告任何短期技术配置都免除一切记录责任。它们展示的是一个更窄的事实：地址出现在第三方终端上，不足以证明持有关系、运营控制或登记责任已经从原接收方迁出。

这里尤其要区分点到点链路地址和链路背后承载的实际通信。草案允许点到点链路的寻址本身具有永久性，但又加上严格限定：该寻址不能被直接或间接用于实际通信。换句话说，永久存在的接口配置不必等同于向链路另一侧提供可独立使用的下游地址空间；然而，一旦所谓“链路地址”实际上被拿去承载其后方的通信，事实性质便可能不同。草案的这一句虽然技术上试图区分链路标识与服务资源，却也容易产生理解分歧：什么算“间接用于”，仅凭简短文字并不总能在复杂拓扑中一眼确定。

另一条线画在永久连接和宽带服务之前。草案明确没有把永久连接或宽带服务纳入临时例外，仍把它们留在再分配禁令一侧。由此形成鲜明对照：短期访客 Wi-Fi 可以不算再分配，长期客户连接则按类别被排除；临时 VPN 端点可以落入例外，持续为下游提供网络的安排则不行。这个切分抓住了一种常见概率——持续服务更可能伴随独立下游控制、不同的故障联系人和长期责任——但“更可能”并不等于“必然”。草案一号把一个有用的事实提示提高成了类别结论，这也正是后续制度分析必须继续追问的地方。

2017 年 12 月发布的 RFC 8273 为技术现实提供了一面镜子。它描述在服务提供者管理的共享接入网络中，为每台主机使用唯一 IPv6 前缀的做法，并讨论主机隔离、订户管理等好处，也提醒当一个前缀可以与某个订户关联时可能出现隐私权衡。这份 RFC 是信息类文档，不是 Standards Track 标准。它能说明“每主机一前缀”并非凭空设想，也能说明大地址单元服务于细粒度接入控制具有工程语境；它不能赋予 AFRINIC 立法权，更不能替登记政策决定哪种商业关系正当。

草案进入公开讨论后，关键的行政问题在 2018 年 5 月 9 日 AFRINIC-28 会议上浮现。官方会议记录显示，提案在达喀尔被介绍，讨论涉及 PPP、VPN、热点等场景。工作人员询问这些临时使用是否需要在 WHOIS 中登记，提案作者的回答是：它们是临时的，因此不需要登记。这个回答必须按其当时语境理解。它说明作者如何看待草案所列的临时例子，并不构成“任何第三方使用都永远无需记录”的普遍原则，也不排除持久、独立控制发生时需要更新联系人或控制状态。

会议记录还同时记载了正面反馈、误解和未解决的文本意见。这一组合很重要：有人看见笼统禁令造成的实际问题，不代表所有参与者已对边界的每个词形成共同理解；存在支持，也不等于文本已经成熟。会议纪要只是正式摘要，而非完整逐字记录，因此不能据此补写每位发言人的原话、动机或立场。能够稳妥确认的是，措辞和理解问题仍在，联合主席给出的结果是 More discussion needed，即“仍需讨论”，并将提案送回邮件列表继续完善。

因此，这一历史节点证明的是第一稿的发布、讨论和未形成共识的会议处置。它不证明草案一号获得共识，不证明它被批准、确认、实施或在某起具体事件中得到执行。官方索引能够显示这一提案系列后来还有 Draft 2，后来的手册也能说明实施历史属于另一个时间层，但这些材料不能倒过来把后续文本、状态或结果安到 2018 年 3 月至 5 月的第一稿上。本文也不重建后稿；否则会把第一稿的优点、缺口和当时仍未解决的问题用事后答案覆盖。

从这段历史可以得到一个有限却坚实的判断。草案一号正确地看到，“第三方正在用地址”与“地址空间已经交给独立下游网络”不是同义句。它用临时性和原接收方运营链路两个条件，为普通拓扑建立了一道安全港；但它仍以永久连接、宽带服务等类别词决定另一侧。第一步纠正了明显的假阳性，第二步却还没有把制度目的完全还原为登记簿真正需要知道的事实。正因为提案停留在“仍需讨论”，我们应当分析它当时提出的测试，而不能把它包装成已经解决一切的终局规则。