摘要

  • 日期为2026年8月2日、研究时仍列为“新提案”的ARIN-prop-353，拟把区外使用限定为只在ARIN服务区外使用或宣告的资源；只要区内也有使用或宣告，便不适用该定义。
  • “只在区外”必然涉及观察对象与时间，可是提案没有说明按前缀、资源集合、申请还是机构判断，也没有规定区外状态须持续多久。
  • 一个受保护的四态记录——仅区内、仅区外、内外混合、证据不足或冲突——应保存观察窗口、证据类型、短暂事件、文本版本、理由、纠错与失效日期，而不公开私密拓扑。

网络没有变，标签却可能来回跳

开头的例子是为了检验文字而设计的假设，不是已发生的ARIN案件。它所描述的运行机制却非常普通。一个服务地址从多个地点宣告，区内节点因维护退出；此时剩余节点全在区外。节点恢复后，部署又成为内外混合。

8月2日提案的公开镜像针对一个真实的文字空白：第9节规定了区外使用的条件，却没有定义“区外使用”。提案称，社区反复担心任播等同时覆盖区内外的部署会被纳入区外使用。它提出，只有资源单独在ARIN区域外使用，或单独从区外地点宣告，才属于该类别；如果区内也有使用或宣告，定义便不适用。

保护混合部署的方向很清楚。仅仅增加一个海外任播节点，不应把整个服务变成“只在区外”。问题在于，“单独”不是前缀与生俱来的静态属性，而是对某段时间内完整状态的判断。若没有时间段，维护、故障、路由收敛和计划迁移都能让分类短暂开关，而行政记录根本来不及辨别其中含义。

分类与后果应当分账

第353号提案提出的是一个边界清楚的问题：哪一种部署状态属于“区外使用”？决定记录应先回答这个问题，再附加任何后续政策后果。

第一步把限定范围内的证据归入仅区内、仅区外、混合或无法判定；第二步记录文字版本，并写明该版本之下适用的后果。若把二者揉在一起，外界将无法知道结果来自地理谓词，还是后续规则。

文件状态也必须准确保留。它目前只是新提案，不是已经由咨询委员会接纳的政策草案，更不是已经形成共识、获准或实施的规则。提案人甚至把定义应放在第2节还是第9节留给后续讨论。报道可以分析文字的效果，却不能把讨论稿写成现行义务。

任播把时间问题照了出来

RFC 4786对任播的说明很直接：同一个服务地址在两个或更多彼此分离、独立的地点可用，路由系统把数据包送往其中一个。每个节点都向共同地址提供一条路径。某节点的“汇水区”是拓扑概念，即哪些网络位置会把包送到该节点，而不是登记机构地图上的政治区域。

这份文件还指出，客户端看到的可用性取决于其网络位置，抵达每个节点的客户端群体并不固定，也无法可靠预测。一台路由收集器看得到的路径，另一处观察点未必看到；一次撤路可能是维护，而不是放弃该节点；全局服务的设计仍然是多点的，瞬时路由图却可能只剩区外节点。

这并不意味着定义无法执行，而是文字必须补上关键参数：判断单位是整项分配、一个前缀，还是更具体的路由？一个正常工作的区内节点是否足以构成混合状态？计划维护允许持续多久？意外故障何时从混合架构中的异常，变成真正的区外单独使用？证据不足时，是否允许明确写下“不确定”？

“使用”与“宣告”不能共用一栏

提案的句子同时谈到在某地点“使用”资源和从某地点“宣告”资源。二者相关，却不是同一事实。路由可以从一个设施发出，再把流量送往另一个地点；服务可以在路由表没有逐一显露的节点后运行；设备、客户、合同和流量也可能分处不同司法和运营空间。

BGP观察只能证明某个观察点在某个时刻收到了某项路由信息。它本身不能证明服务器的物理位置、客户居住地或业务的法律中心。因此，最终文字需要说明：使用和宣告是两个独立测试、两个任选入口，还是必须结合权衡的证据。

RFC 8805提供了另一类材料。网络运营者可以用其格式自行发布前缀的简化地理信息，但地点字段并非必填；消费者应核验发布者对地址的管理权，并在可行时核验准确性；数据会出现错误，也可以不经通知而改变。地理馈送能够支持运营者的陈述，却不是所有任播节点的强制、完整、永久清单。

因此，受保护的案件记录至少要分开三类证据：运营者对特定范围和期间的部署陈述；写明观察点和时间的路由观测；带有发布权、更新时间和精度说明的可选地理资料。三者一致可以提高置信度，彼此冲突则应导向“不确定”，而不是选择最方便的一项制造确定性。

全球部署并非纸面想象

一段2025年8月的NANOG公开存档提供了有边界的现实背景。一位运营者回忆，某CDN在多个注册区域有基础设施，并在全球使用ARIN地址。讨论也质疑把IP地址与地理地址视为必然绑定，并提到不同地理信息供应者的纠错质量差异很大。

这是一位参与者对历史经验的叙述，不是经过裁判的事实。它不能证明ARIN当前如何解释政策，也不能证明第353号提案的具体动机或某个现存争议。它只说明，跨区域部署是日常架构而不是抽象例外；越是分布式的网络，越不能用没有时间的二元格子草率分类。

第四种状态约束谁来解释疑点

最小而诚实的结果应有四种：证据只支持区内、只支持区外、同时支持内外、证据不足或互相冲突。第353号提案的新定义只应连接第二种。第四种不是拖延，而是防止掌握某个观察点的人顺手掌握结论。

受保护的分类凭据应注明资源范围、申请或决定类型、适用文本版本、观察开始与结束。区内使用、区内宣告、区外使用和区外宣告各自保存来源、时间与置信度。任播、维护、故障和计划迁移要有标记；可选地理材料需保留发布者与新鲜度；冲突不得被覆盖。随后才写入四态结果、负责决定的角色与理由。

最后几项同样重要：通知、回应、纠正、复核和失效。八月的混合部署不是永恒事实；已经恢复的路由或已纠正的地理资料，不应继续产生隐蔽后果。公开层可以很窄，只列资源范围、状态、规则版本、决定日期、理由代码和复核状态。客户名单、流量、设施地址与安全敏感拓扑仍留在保护层。可复核不等于监控一切。

服务地理可以描述现实，不能创造权利

Lu Heng在Running-Code Primacy中给出了制度边界：号码资源共同层的正当功能是唯一性、控制证明、互操作、安全断言和运行连续性。服务区域不是一个人民，登记记录可以描述运行现实，却不能创造现实。

这条边界并不排斥改进第353号提案。相反，如果ARIN保留地理测试，它就更应当确定、可审计、可纠正，而且不索取超出需要的私密数据。地理分类不能让登记机构成为路由的所有者、运营者拓扑的设计者，也不能把一次故障当作扩大权力的契机。

现有证据没有显示该提案造成过拒绝、伤害或争议。它显示的是一项有保护意图的简短定义，以及尚未完成的时间接口。在“单独”产生任何行政后果之前，文字应回答：对什么范围单独、由谁观察、持续多久、依据什么、适用哪个版本、发现错误后如何回来？

来源

  • TeamARIN镜像，ARIN-prop-353: Define Out Of Region Use
  • RFC Editor，RFC 4786: Operation of Anycast Services
  • RFC Editor，RFC 8805: A Format for Self-Published IP Geolocation Feeds
  • SecLists的NANOG公开存档：全球部署与IP地理信息讨论
  • Heng Lu, Running-Code Primacy: The Patch Needed to Preserve the Internet's Original Design