目录
- 在签署协议之前,确认协议明确要求持有者签发 LOA,并规定具体交付时间。
- 在付款之前取得 LOA,或者至少取得书面的交付保证。
- 核实准确的前缀与实际租赁或取得的地址块完全一致。
- 核实 ASN 与实际将作为起源网络进行公告的 ASN 完全一致。
- 检查有效期是否覆盖整个租赁或部署周期。
- 确认文件使用注册持有者的正式公司抬头,企业资料与注册记录一致,并有可以识别的授权签署人。
- 按照上游要求的格式提交——PDF 是最稳妥的默认选择;图片格式经常会被拒绝。
- 确认如果上游、ASN 或授权范围发生变化,重新签发的流程以及处理时间。
- 确保 LOA、ROA 和 IRR route object 保持一致,让三种授权记录不会互相冲突。
- 保存一份副本——增加其他服务提供商、进行审计或未来修改部署时,都可能再次需要。
来自 i.lease 的实用说明
LOA 是一份很小的文件,但其运营影响远远超过文件本身的复杂程度。它在技术上并不复杂,只要有权签署的人愿意配合,通常几分钟就可以制作出来,但它却是租赁或新取得的地址块已经付费、却迟迟无法投入使用的最常见原因之一。问题几乎从来不是真正存在授权争议,而是协议签署之前没有人明确规定:由谁签发这份文件、多久内必须交付,以及文件中应该写些什么。
正因如此,LOA 的处理方式其实可以作为判断整体地址资源安排质量的一个很好指标。如果出租方能够快速提供正确的 LOA,一次就准确写明正确的 ASN 和前缀,不需要来回修改三次;当你更换上游时能够迅速重新签发;并且同时保持 ROA 与 route object 一致,那么它实际上正在展示生产环境路由所需要的运营纪律。相反,如果出租方认为 LOA 只是以后再处理的文书工作,那么整个合作关系中的其他环节很可能也会以类似方式处理。文件本身并不复杂,真正重要的是背后的协调能力,而正是这种协调,才能把一段地址空间变成真正可运行的网络基础设施。无论你是租赁还是直接取得地址空间,都应该把路由授权视为一个具有明确期限的正式交付成果,而不是默认它自然会出现。
总结
授权书(LOA)是注册持有者以书面形式授予某个指定方,通过指定 ASN 公告特定前缀的许可。上游服务提供商之所以要求 LOA,是因为仅凭注册数据无法确认公告方是否真正获得授权,而接受未经授权的公告就意味着参与路由劫持。文件会列出持有者、被授权方及 ASN、具体前缀和有效期,并由有权授予该项授权的人签署——它正处于“拥有地址空间”与“能够真正将其路由上线”之间的关键路径上。
最值得记住的区别,是 LOA 能做什么,以及不能做什么。它授权路由公告;它不会转移所有权、不会更改注册信息,也不会授予任何注册管理层面的权利。在租赁关系中,地址空间仍然注册在持有者名下,而租户的公告权来自持有者授予的授权——这也正是为什么 LOA 必须存在,而且必须由持有者出具。再加上由路由器验证的 ROA,以及供过滤系统查询的 route object,LOA 才共同组成将合同权利转化为被网络接受的路由公告所需要的完整记录体系。在部署之前让三者保持一致,在付款之前核实 LOA 的具体内容,才能真正把你已经安排好的地址空间变成可以实际使用的基础设施。
相关阅读
什么是 BGP 劫持?路由劫持如何发生、著名事件以及网络如何防范
RPKI 与 ROA 详解:路由起源授权如何保护你的 IPv4 前缀
什么是 BGP?边界网关协议如何让 IP 地址成为可访问的服务
- 付款前取得 LOA,或者取得书面的交付承诺。 最好直接拿到文件;如果做不到,也应在协议中明确规定,必须在一个确定且较短的时间内交付。如果出租方连这两者中的任何一种都不愿意承诺,那已经说明了后续合作关系可能会是什么样子。
- 确认 LOA 中列出了正确的前缀。 应当准确列出你实际租赁的地址块。LOA 如果覆盖了不同地址块或过大的范围,上游可能会提出质疑;如果覆盖范围小于你所需,也无法授权剩余部分。
- 确认 LOA 中列出了正确的 ASN。 必须是实际会成为起源网络的 ASN——根据你的部署方式,这可能是你自己的 ASN,也可能是上游的 ASN。错误的 ASN 是一份形式上有效的 LOA 仍然无法帮助部署上线的最常见原因之一。
- 核对有效期与租赁期限。 如果授权比租赁期限更早到期,就会在部署过程中产生重新签发 LOA 的依赖。
- 确认文件确实来自注册持有者。 公司抬头和企业资料应与注册记录一致,并由可以识别且确实有授权权限的人签署。
- 确认重新签发流程。 如果你更换上游、更换 ASN,或需要为第二家服务提供商增加一份 LOA,更新文件最快可以在多久内提供?实际部署会发生变化,而授权文件必须能够同步更新。
- 询问 LOA 如何与 ROA 和 route object 配合。 单独拥有 LOA 并不够——正如上面的比较所示,ROA 和 IRR 记录也必须保持一致。能够完整处理这三项内容的出租方,比只提供一份文件然后把其余事情全部交给你的出租方,更适合生产环境部署。
这些问题在签约之前提出几乎没有成本,但签约之后才提出往往代价高昂。综合来看,它们也是判断租赁质量非常可靠的信号:如果一个地址安排将路由授权明确视为具有交付期限的正式交付成果,那么它通常是按照生产环境需求设计的;反之,如果把授权当成事后再处理的细节,那么这个问题往往会在最糟糕的时候暴露出来。
常见 LOA 问题
大多数 LOA 问题并不是围绕授权本身产生争议,而是文件交付太迟、内容错误或已经过期。 常见情况包括:
- 交付延迟。 这是最常见、也是成本最高的问题。只要文件一天没有到位,地址空间就一天无法正常公告,无论其他部分准备得多么充分。
- ASN 错误。 LOA 授权了一个与实际发起公告不同的 ASN——通常是因为文件起草之后部署方案发生变化,或出租方误解了租户的上游安排。
- 前缀错误或不够准确。 文件列出的地址块不正确、范围比协议约定更大,或者描述过于模糊,以至于上游不愿据此配置路由。
- 授权已经过期。 有效期已经结束,通常是在服务提供商重新审核文件,或租赁期内新增上游时才被发现。
- 签署人没有授权或无法验证。 文件由上游无法确认其权限的人签署,或者文件本身无法明确关联到注册持有者。
- 协议中完全没有规定 LOA。 租赁协议完全没有提到 LOA 的签发,因此交付时间和责任都没有定义——而交付延迟问题通常就是从这里开始。
这六类问题都可以在协议阶段提前避免,这也是为什么上面的核实清单比事后进行任何故障排查都更加重要。
实用检查清单
- 在签署协议之前,确认协议明确要求持有者签发 LOA,并规定具体交付时间。
- 在付款之前取得 LOA,或者至少取得书面的交付保证。
- 核实准确的前缀与实际租赁或取得的地址块完全一致。
- 核实 ASN 与实际将作为起源网络进行公告的 ASN 完全一致。
- 检查有效期是否覆盖整个租赁或部署周期。
- 确认文件使用注册持有者的正式公司抬头,企业资料与注册记录一致,并有可以识别的授权签署人。
- 按照上游要求的格式提交——PDF 是最稳妥的默认选择;图片格式经常会被拒绝。
- 确认如果上游、ASN 或授权范围发生变化,重新签发的流程以及处理时间。
- 确保 LOA、ROA 和 IRR route object 保持一致,让三种授权记录不会互相冲突。
- 保存一份副本——增加其他服务提供商、进行审计或未来修改部署时,都可能再次需要。
来自 i.lease 的实用说明
LOA 是一份很小的文件,但其运营影响远远超过文件本身的复杂程度。它在技术上并不复杂,只要有权签署的人愿意配合,通常几分钟就可以制作出来,但它却是租赁或新取得的地址块已经付费、却迟迟无法投入使用的最常见原因之一。问题几乎从来不是真正存在授权争议,而是协议签署之前没有人明确规定:由谁签发这份文件、多久内必须交付,以及文件中应该写些什么。
正因如此,LOA 的处理方式其实可以作为判断整体地址资源安排质量的一个很好指标。如果出租方能够快速提供正确的 LOA,一次就准确写明正确的 ASN 和前缀,不需要来回修改三次;当你更换上游时能够迅速重新签发;并且同时保持 ROA 与 route object 一致,那么它实际上正在展示生产环境路由所需要的运营纪律。相反,如果出租方认为 LOA 只是以后再处理的文书工作,那么整个合作关系中的其他环节很可能也会以类似方式处理。文件本身并不复杂,真正重要的是背后的协调能力,而正是这种协调,才能把一段地址空间变成真正可运行的网络基础设施。无论你是租赁还是直接取得地址空间,都应该把路由授权视为一个具有明确期限的正式交付成果,而不是默认它自然会出现。
总结
授权书(LOA)是注册持有者以书面形式授予某个指定方,通过指定 ASN 公告特定前缀的许可。上游服务提供商之所以要求 LOA,是因为仅凭注册数据无法确认公告方是否真正获得授权,而接受未经授权的公告就意味着参与路由劫持。文件会列出持有者、被授权方及 ASN、具体前缀和有效期,并由有权授予该项授权的人签署——它正处于“拥有地址空间”与“能够真正将其路由上线”之间的关键路径上。
最值得记住的区别,是 LOA 能做什么,以及不能做什么。它授权路由公告;它不会转移所有权、不会更改注册信息,也不会授予任何注册管理层面的权利。在租赁关系中,地址空间仍然注册在持有者名下,而租户的公告权来自持有者授予的授权——这也正是为什么 LOA 必须存在,而且必须由持有者出具。再加上由路由器验证的 ROA,以及供过滤系统查询的 route object,LOA 才共同组成将合同权利转化为被网络接受的路由公告所需要的完整记录体系。在部署之前让三者保持一致,在付款之前核实 LOA 的具体内容,才能真正把你已经安排好的地址空间变成可以实际使用的基础设施。
相关阅读
什么是 BGP 劫持?路由劫持如何发生、著名事件以及网络如何防范
RPKI 与 ROA 详解:路由起源授权如何保护你的 IPv4 前缀
什么是 BGP?边界网关协议如何让 IP 地址成为可访问的服务
- LOA 授权的是公告,并不转移所有权。 签署 LOA 只是授予对地址空间进行路由的许可。它不会让被授权方成为该地址空间的持有者,不会更改注册记录,也不会转移任何注册管理层面的权利。当授权终止时,该项公告权限也随之终止。
- 在整个租赁期间,注册信息仍然保留在持有者名下。 在租赁安排中,注册管理机构的记录会继续显示原持有者为注册方。这并不是租赁关系中的漏洞——这正是租赁模式本身的结构。租户的公告权来自所获得的授权,而不是来自注册信息的改变。
- 进行公告不等于持有地址空间。 一个网络公告某个前缀,意味着它正在作为起源网络发布该前缀,这反映的是它获得了授权。公告本身并不能证明所有权。这种区分在概念和实际操作上都非常重要,因为未经授权的公告本身正是路由劫持的定义之一。
对于接收公告的上游服务提供商来说,这些区别最终会转化成一个验证问题:签署人真的拥有他们所声称的授权权力吗?这就是为什么 LOA 通常需要使用持有者的公司抬头纸、公司资料必须与注册记录相符,并由身份和职位明确的人签署。任何无法追溯到注册持有者的文件,都不能算真正的授权——那只能算是一项单方面声明。
LOA 与租赁 IPv4:付款之前应该核实什么?
由于 LOA 位于路由上线流程的关键路径上,因此应该在付款之前确认其处理方式,而不是付款之后才发现问题。 这个失败模式在行业中非常常见:企业签署了租赁协议、配置好路由、通知了上游,然后才被要求提供一份租赁协议中从未提及、而出租方又迟迟无法出具的 LOA。在文件到达之前,地址已经付费,却无法使用。
以下事项应当提前确认:
- 付款前取得 LOA,或者取得书面的交付承诺。 最好直接拿到文件;如果做不到,也应在协议中明确规定,必须在一个确定且较短的时间内交付。如果出租方连这两者中的任何一种都不愿意承诺,那已经说明了后续合作关系可能会是什么样子。
- 确认 LOA 中列出了正确的前缀。 应当准确列出你实际租赁的地址块。LOA 如果覆盖了不同地址块或过大的范围,上游可能会提出质疑;如果覆盖范围小于你所需,也无法授权剩余部分。
- 确认 LOA 中列出了正确的 ASN。 必须是实际会成为起源网络的 ASN——根据你的部署方式,这可能是你自己的 ASN,也可能是上游的 ASN。错误的 ASN 是一份形式上有效的 LOA 仍然无法帮助部署上线的最常见原因之一。
- 核对有效期与租赁期限。 如果授权比租赁期限更早到期,就会在部署过程中产生重新签发 LOA 的依赖。
- 确认文件确实来自注册持有者。 公司抬头和企业资料应与注册记录一致,并由可以识别且确实有授权权限的人签署。
- 确认重新签发流程。 如果你更换上游、更换 ASN,或需要为第二家服务提供商增加一份 LOA,更新文件最快可以在多久内提供?实际部署会发生变化,而授权文件必须能够同步更新。
- 询问 LOA 如何与 ROA 和 route object 配合。 单独拥有 LOA 并不够——正如上面的比较所示,ROA 和 IRR 记录也必须保持一致。能够完整处理这三项内容的出租方,比只提供一份文件然后把其余事情全部交给你的出租方,更适合生产环境部署。
这些问题在签约之前提出几乎没有成本,但签约之后才提出往往代价高昂。综合来看,它们也是判断租赁质量非常可靠的信号:如果一个地址安排将路由授权明确视为具有交付期限的正式交付成果,那么它通常是按照生产环境需求设计的;反之,如果把授权当成事后再处理的细节,那么这个问题往往会在最糟糕的时候暴露出来。
常见 LOA 问题
大多数 LOA 问题并不是围绕授权本身产生争议,而是文件交付太迟、内容错误或已经过期。 常见情况包括:
- 交付延迟。 这是最常见、也是成本最高的问题。只要文件一天没有到位,地址空间就一天无法正常公告,无论其他部分准备得多么充分。
- ASN 错误。 LOA 授权了一个与实际发起公告不同的 ASN——通常是因为文件起草之后部署方案发生变化,或出租方误解了租户的上游安排。
- 前缀错误或不够准确。 文件列出的地址块不正确、范围比协议约定更大,或者描述过于模糊,以至于上游不愿据此配置路由。
- 授权已经过期。 有效期已经结束,通常是在服务提供商重新审核文件,或租赁期内新增上游时才被发现。
- 签署人没有授权或无法验证。 文件由上游无法确认其权限的人签署,或者文件本身无法明确关联到注册持有者。
- 协议中完全没有规定 LOA。 租赁协议完全没有提到 LOA 的签发,因此交付时间和责任都没有定义——而交付延迟问题通常就是从这里开始。
这六类问题都可以在协议阶段提前避免,这也是为什么上面的核实清单比事后进行任何故障排查都更加重要。
实用检查清单
- 在签署协议之前,确认协议明确要求持有者签发 LOA,并规定具体交付时间。
- 在付款之前取得 LOA,或者至少取得书面的交付保证。
- 核实准确的前缀与实际租赁或取得的地址块完全一致。
- 核实 ASN 与实际将作为起源网络进行公告的 ASN 完全一致。
- 检查有效期是否覆盖整个租赁或部署周期。
- 确认文件使用注册持有者的正式公司抬头,企业资料与注册记录一致,并有可以识别的授权签署人。
- 按照上游要求的格式提交——PDF 是最稳妥的默认选择;图片格式经常会被拒绝。
- 确认如果上游、ASN 或授权范围发生变化,重新签发的流程以及处理时间。
- 确保 LOA、ROA 和 IRR route object 保持一致,让三种授权记录不会互相冲突。
- 保存一份副本——增加其他服务提供商、进行审计或未来修改部署时,都可能再次需要。
来自 i.lease 的实用说明
LOA 是一份很小的文件,但其运营影响远远超过文件本身的复杂程度。它在技术上并不复杂,只要有权签署的人愿意配合,通常几分钟就可以制作出来,但它却是租赁或新取得的地址块已经付费、却迟迟无法投入使用的最常见原因之一。问题几乎从来不是真正存在授权争议,而是协议签署之前没有人明确规定:由谁签发这份文件、多久内必须交付,以及文件中应该写些什么。
正因如此,LOA 的处理方式其实可以作为判断整体地址资源安排质量的一个很好指标。如果出租方能够快速提供正确的 LOA,一次就准确写明正确的 ASN 和前缀,不需要来回修改三次;当你更换上游时能够迅速重新签发;并且同时保持 ROA 与 route object 一致,那么它实际上正在展示生产环境路由所需要的运营纪律。相反,如果出租方认为 LOA 只是以后再处理的文书工作,那么整个合作关系中的其他环节很可能也会以类似方式处理。文件本身并不复杂,真正重要的是背后的协调能力,而正是这种协调,才能把一段地址空间变成真正可运行的网络基础设施。无论你是租赁还是直接取得地址空间,都应该把路由授权视为一个具有明确期限的正式交付成果,而不是默认它自然会出现。
总结
授权书(LOA)是注册持有者以书面形式授予某个指定方,通过指定 ASN 公告特定前缀的许可。上游服务提供商之所以要求 LOA,是因为仅凭注册数据无法确认公告方是否真正获得授权,而接受未经授权的公告就意味着参与路由劫持。文件会列出持有者、被授权方及 ASN、具体前缀和有效期,并由有权授予该项授权的人签署——它正处于“拥有地址空间”与“能够真正将其路由上线”之间的关键路径上。
最值得记住的区别,是 LOA 能做什么,以及不能做什么。它授权路由公告;它不会转移所有权、不会更改注册信息,也不会授予任何注册管理层面的权利。在租赁关系中,地址空间仍然注册在持有者名下,而租户的公告权来自持有者授予的授权——这也正是为什么 LOA 必须存在,而且必须由持有者出具。再加上由路由器验证的 ROA,以及供过滤系统查询的 route object,LOA 才共同组成将合同权利转化为被网络接受的路由公告所需要的完整记录体系。在部署之前让三者保持一致,在付款之前核实 LOA 的具体内容,才能真正把你已经安排好的地址空间变成可以实际使用的基础设施。
相关阅读
什么是 BGP 劫持?路由劫持如何发生、著名事件以及网络如何防范
RPKI 与 ROA 详解:路由起源授权如何保护你的 IPv4 前缀
什么是 BGP?边界网关协议如何让 IP 地址成为可访问的服务
- 它由持有者签发,而不是由公告方自行签发。 有权授予许可的一方,是地址空间的持有者。租户不能自己给自己写一份 LOA。
- 它必须具有明确的针对性。 文件需要列出具体的前缀以及具体的 ASN。仅仅说明某方“信誉良好”并不能构成 LOA;文件中的内容必须与实际将要公告的内容完全匹配。
为什么上游服务提供商要求 LOA?
服务提供商之所以要求 LOA,是因为接受一个未经授权方发出的路由公告,正是前缀劫持发生的方式——而任何负责任的网络都不希望成为传播这种错误公告的一方。
正如我们在BGP 如何运作的指南中所解释的,路由系统在很大程度上是基于信任接受公告的,而各个网络之所以会过滤接收到的路由,正是因为虚假公告可能将属于其他人的流量重定向。这个风险并不是理论上的:未经授权的路由公告正是我们在BGP 劫持指南中所介绍事件的核心机制。如果上游服务提供商在未核实授权的情况下接受公告,那么它就会无意间成为后续事件的参与者。
LOA 填补的正是一个具体的信息缺口。注册记录可以确认地址持有者,但在租赁情况下,注册记录仍然显示原持有者,而实际进行公告的是另一方——因此,上游服务提供商无法仅通过数据库查询来验证租户。LOA 补上了缺失的这一环:由注册记录中可识别的那一方,以书面形式确认实际进行公告的一方已经获得许可。
在实际部署中,这意味着 LOA 位于整个上线流程的关键路径上。路由器已经配置、租赁协议已经签署、地址块已经分配——这些都无法真正带来可达性,直到上游服务提供商接受这条路由公告,而在没有 LOA 的情况下,上游通常不会接受。
LOA 包含哪些内容?
LOA 会明确授权方、被授权方及其 ASN、具体前缀,以及有权授予该项授权人员的签名。 各家服务提供商通常要求的标准组成部分包括:
- 授权方。 即地址空间的注册持有者,其公司名称和相关资料应与注册记录一致。
- 被授权方和 ASN。 文件需要说明谁被允许公告该地址空间,以及最关键的——将通过哪个自治系统编号进行公告。Cloudflare 的文档明确要求 LOA 同时写明被授权的前缀和公告所使用的 ASN——ASN 并不是可有可无的附加信息。
- 准确的前缀。 必须精确列出受授权覆盖的地址块(例如某个具体的 /24)。任何超出 LOA 所列范围的公告,都不属于该授权范围。
- 有效期。 授权的持续时间。对于租赁地址空间,其有效期应与租赁期限保持一致。
- 授权签署人。 包括姓名、职位以及有权代表持有者签署文件的人员签名,并附上联系方式,以便上游服务提供商在有需要时进行核实。
- 公司抬头和文件格式。 LOA 通常应以持有者公司的正式抬头纸制作。Cloudflare 指出,Transit 服务提供商可能会拒绝以图片格式提交的 LOA,而要求使用 PDF;数字签名通常可以接受,但签署人必须能够被清楚识别。
这些要求并不是毫无意义的行政装饰。公司抬头、与注册记录一致的企业资料,以及可识别的授权签署人,正是接收方用于确认文件真实性,以及签署人确实有权授予所声称授权的依据。
什么时候需要 LOA?
只要将由注册持有者以外的一方公告地址空间,通常都需要 LOA——这涵盖了绝大多数 IPv4 租赁、BYOIP 和由服务提供商代为公告的情况。 常见场景包括:
- 通过自己的 ASN 公告租赁的 IPv4。 这是最典型的情况:你租赁了一个地址块,并自行对外公告,因此你的上游需要看到持有者提供的授权。关于这个更完整的租赁流程,可以参考我们的IPv4 租赁指南以及IP 地址租赁如何运作的说明。
- 由服务提供商代表你公告地址空间。 当你的托管服务商、数据中心或平台通过其 ASN 公告你的前缀时,它需要获得你的授权——而它的上游同样需要看到这一授权。
- BYOIP 接入。 将自有 IP 地址空间(BYOIP)带入云平台或边缘平台时,需要授权该平台公告你的前缀,Cloudflare 的要求就是一个典型例子。
- 紧急路由变更。 例如 DDoS 清洗服务,在攻击发生时由服务提供商临时公告你的前缀,这类安排依赖于事先完成授权——这一点我们也在DDoS 缓解指南中进行了介绍。
判断标准其实很简单:如果进行公告的 ASN 并不属于注册持有者本身,那么几乎可以确定需要 LOA。
LOA vs ROA vs IRR Route Object
LOA、ROA 和 IRR route object 都在说明谁可以公告某个前缀——但它们面对不同的受众、采用不同形式,并且作用于不同层面。 它们彼此互补,而不是相互替代。一个正确部署的前缀,通常需要三者保持一致。
LOA vs ROA vs IRR Route Object
项目
LOA
ROA
IRR route object
它是什么
授予路由公告权限的签署文件
RPKI 中经过加密签名的记录
Internet Routing Registry 数据库中的记录
面向对象
人员——上游开通和 NOC 工作人员
执行路由起源验证的路由器
自动生成过滤规则的系统
形式
人类可读、合同性质
加密签名、机器验证
数据库记录
由谁创建
注册持有者(或授权代表)
注册持有者,通过其 RIR 创建
对象的持有者或 maintainer
缺失或错误时的影响
上游拒绝配置该路由公告
公告可能被执行 RPKI 验证的网络判定为 RPKI-Invalid 并拒绝
使用 IRR 数据生成过滤规则的服务提供商可能过滤该公告
最清楚的理解方式是:LOA 决定你的上游工作人员是否愿意配置并接受这项公告;ROA 决定互联网上执行验证的路由器是否认为该起源 ASN 合法;route object 则影响自动化过滤系统是否允许该公告通过。三者都可能独立出现问题,而且每一种失败都会产生不同的症状——这也是为什么部署有时会以看似完全不同的方式卡住,取决于究竟缺少哪一项记录。
这三者之间的互动也越来越紧密。例如,Cloudflare 的自动生成 LOA 流程会依赖经过 RPKI 签名的 ROA 以及所有权验证检查——也就是说,加密记录用于支持这份人工文件,而不是取代它。关于 ROA 的具体机制,包括它如何授权某个特定的起源 ASN,以及配置错误时会发生什么,请参阅我们的RPKI 和 ROA指南。
谁可以合法签发 LOA?
只有地址空间的注册持有者——或者被授权代表该持有者行事的人——才有资格合法签发 LOA。 这一点必须非常准确地说明,因为现实中经常有人把相关概念混淆。
有三个概念值得明确区分:
- LOA 授权的是公告,并不转移所有权。 签署 LOA 只是授予对地址空间进行路由的许可。它不会让被授权方成为该地址空间的持有者,不会更改注册记录,也不会转移任何注册管理层面的权利。当授权终止时,该项公告权限也随之终止。
- 在整个租赁期间,注册信息仍然保留在持有者名下。 在租赁安排中,注册管理机构的记录会继续显示原持有者为注册方。这并不是租赁关系中的漏洞——这正是租赁模式本身的结构。租户的公告权来自所获得的授权,而不是来自注册信息的改变。
- 进行公告不等于持有地址空间。 一个网络公告某个前缀,意味着它正在作为起源网络发布该前缀,这反映的是它获得了授权。公告本身并不能证明所有权。这种区分在概念和实际操作上都非常重要,因为未经授权的公告本身正是路由劫持的定义之一。
对于接收公告的上游服务提供商来说,这些区别最终会转化成一个验证问题:签署人真的拥有他们所声称的授权权力吗?这就是为什么 LOA 通常需要使用持有者的公司抬头纸、公司资料必须与注册记录相符,并由身份和职位明确的人签署。任何无法追溯到注册持有者的文件,都不能算真正的授权——那只能算是一项单方面声明。
LOA 与租赁 IPv4:付款之前应该核实什么?
由于 LOA 位于路由上线流程的关键路径上,因此应该在付款之前确认其处理方式,而不是付款之后才发现问题。 这个失败模式在行业中非常常见:企业签署了租赁协议、配置好路由、通知了上游,然后才被要求提供一份租赁协议中从未提及、而出租方又迟迟无法出具的 LOA。在文件到达之前,地址已经付费,却无法使用。
以下事项应当提前确认:
- 付款前取得 LOA,或者取得书面的交付承诺。 最好直接拿到文件;如果做不到,也应在协议中明确规定,必须在一个确定且较短的时间内交付。如果出租方连这两者中的任何一种都不愿意承诺,那已经说明了后续合作关系可能会是什么样子。
- 确认 LOA 中列出了正确的前缀。 应当准确列出你实际租赁的地址块。LOA 如果覆盖了不同地址块或过大的范围,上游可能会提出质疑;如果覆盖范围小于你所需,也无法授权剩余部分。
- 确认 LOA 中列出了正确的 ASN。 必须是实际会成为起源网络的 ASN——根据你的部署方式,这可能是你自己的 ASN,也可能是上游的 ASN。错误的 ASN 是一份形式上有效的 LOA 仍然无法帮助部署上线的最常见原因之一。
- 核对有效期与租赁期限。 如果授权比租赁期限更早到期,就会在部署过程中产生重新签发 LOA 的依赖。
- 确认文件确实来自注册持有者。 公司抬头和企业资料应与注册记录一致,并由可以识别且确实有授权权限的人签署。
- 确认重新签发流程。 如果你更换上游、更换 ASN,或需要为第二家服务提供商增加一份 LOA,更新文件最快可以在多久内提供?实际部署会发生变化,而授权文件必须能够同步更新。
- 询问 LOA 如何与 ROA 和 route object 配合。 单独拥有 LOA 并不够——正如上面的比较所示,ROA 和 IRR 记录也必须保持一致。能够完整处理这三项内容的出租方,比只提供一份文件然后把其余事情全部交给你的出租方,更适合生产环境部署。
这些问题在签约之前提出几乎没有成本,但签约之后才提出往往代价高昂。综合来看,它们也是判断租赁质量非常可靠的信号:如果一个地址安排将路由授权明确视为具有交付期限的正式交付成果,那么它通常是按照生产环境需求设计的;反之,如果把授权当成事后再处理的细节,那么这个问题往往会在最糟糕的时候暴露出来。
常见 LOA 问题
大多数 LOA 问题并不是围绕授权本身产生争议,而是文件交付太迟、内容错误或已经过期。 常见情况包括:
- 交付延迟。 这是最常见、也是成本最高的问题。只要文件一天没有到位,地址空间就一天无法正常公告,无论其他部分准备得多么充分。
- ASN 错误。 LOA 授权了一个与实际发起公告不同的 ASN——通常是因为文件起草之后部署方案发生变化,或出租方误解了租户的上游安排。
- 前缀错误或不够准确。 文件列出的地址块不正确、范围比协议约定更大,或者描述过于模糊,以至于上游不愿据此配置路由。
- 授权已经过期。 有效期已经结束,通常是在服务提供商重新审核文件,或租赁期内新增上游时才被发现。
- 签署人没有授权或无法验证。 文件由上游无法确认其权限的人签署,或者文件本身无法明确关联到注册持有者。
- 协议中完全没有规定 LOA。 租赁协议完全没有提到 LOA 的签发,因此交付时间和责任都没有定义——而交付延迟问题通常就是从这里开始。
这六类问题都可以在协议阶段提前避免,这也是为什么上面的核实清单比事后进行任何故障排查都更加重要。
实用检查清单
- 在签署协议之前,确认协议明确要求持有者签发 LOA,并规定具体交付时间。
- 在付款之前取得 LOA,或者至少取得书面的交付保证。
- 核实准确的前缀与实际租赁或取得的地址块完全一致。
- 核实 ASN 与实际将作为起源网络进行公告的 ASN 完全一致。
- 检查有效期是否覆盖整个租赁或部署周期。
- 确认文件使用注册持有者的正式公司抬头,企业资料与注册记录一致,并有可以识别的授权签署人。
- 按照上游要求的格式提交——PDF 是最稳妥的默认选择;图片格式经常会被拒绝。
- 确认如果上游、ASN 或授权范围发生变化,重新签发的流程以及处理时间。
- 确保 LOA、ROA 和 IRR route object 保持一致,让三种授权记录不会互相冲突。
- 保存一份副本——增加其他服务提供商、进行审计或未来修改部署时,都可能再次需要。
来自 i.lease 的实用说明
LOA 是一份很小的文件,但其运营影响远远超过文件本身的复杂程度。它在技术上并不复杂,只要有权签署的人愿意配合,通常几分钟就可以制作出来,但它却是租赁或新取得的地址块已经付费、却迟迟无法投入使用的最常见原因之一。问题几乎从来不是真正存在授权争议,而是协议签署之前没有人明确规定:由谁签发这份文件、多久内必须交付,以及文件中应该写些什么。
正因如此,LOA 的处理方式其实可以作为判断整体地址资源安排质量的一个很好指标。如果出租方能够快速提供正确的 LOA,一次就准确写明正确的 ASN 和前缀,不需要来回修改三次;当你更换上游时能够迅速重新签发;并且同时保持 ROA 与 route object 一致,那么它实际上正在展示生产环境路由所需要的运营纪律。相反,如果出租方认为 LOA 只是以后再处理的文书工作,那么整个合作关系中的其他环节很可能也会以类似方式处理。文件本身并不复杂,真正重要的是背后的协调能力,而正是这种协调,才能把一段地址空间变成真正可运行的网络基础设施。无论你是租赁还是直接取得地址空间,都应该把路由授权视为一个具有明确期限的正式交付成果,而不是默认它自然会出现。
总结
授权书(LOA)是注册持有者以书面形式授予某个指定方,通过指定 ASN 公告特定前缀的许可。上游服务提供商之所以要求 LOA,是因为仅凭注册数据无法确认公告方是否真正获得授权,而接受未经授权的公告就意味着参与路由劫持。文件会列出持有者、被授权方及 ASN、具体前缀和有效期,并由有权授予该项授权的人签署——它正处于“拥有地址空间”与“能够真正将其路由上线”之间的关键路径上。
最值得记住的区别,是 LOA 能做什么,以及不能做什么。它授权路由公告;它不会转移所有权、不会更改注册信息,也不会授予任何注册管理层面的权利。在租赁关系中,地址空间仍然注册在持有者名下,而租户的公告权来自持有者授予的授权——这也正是为什么 LOA 必须存在,而且必须由持有者出具。再加上由路由器验证的 ROA,以及供过滤系统查询的 route object,LOA 才共同组成将合同权利转化为被网络接受的路由公告所需要的完整记录体系。在部署之前让三者保持一致,在付款之前核实 LOA 的具体内容,才能真正把你已经安排好的地址空间变成可以实际使用的基础设施。
相关阅读
什么是 BGP 劫持?路由劫持如何发生、著名事件以及网络如何防范
RPKI 与 ROA 详解:路由起源授权如何保护你的 IPv4 前缀
什么是 BGP?边界网关协议如何让 IP 地址成为可访问的服务
- 它由持有者签发,而不是由公告方自行签发。 有权授予许可的一方,是地址空间的持有者。租户不能自己给自己写一份 LOA。
- 它必须具有明确的针对性。 文件需要列出具体的前缀以及具体的 ASN。仅仅说明某方“信誉良好”并不能构成 LOA;文件中的内容必须与实际将要公告的内容完全匹配。
为什么上游服务提供商要求 LOA?
服务提供商之所以要求 LOA,是因为接受一个未经授权方发出的路由公告,正是前缀劫持发生的方式——而任何负责任的网络都不希望成为传播这种错误公告的一方。
正如我们在BGP 如何运作的指南中所解释的,路由系统在很大程度上是基于信任接受公告的,而各个网络之所以会过滤接收到的路由,正是因为虚假公告可能将属于其他人的流量重定向。这个风险并不是理论上的:未经授权的路由公告正是我们在BGP 劫持指南中所介绍事件的核心机制。如果上游服务提供商在未核实授权的情况下接受公告,那么它就会无意间成为后续事件的参与者。
LOA 填补的正是一个具体的信息缺口。注册记录可以确认地址持有者,但在租赁情况下,注册记录仍然显示原持有者,而实际进行公告的是另一方——因此,上游服务提供商无法仅通过数据库查询来验证租户。LOA 补上了缺失的这一环:由注册记录中可识别的那一方,以书面形式确认实际进行公告的一方已经获得许可。
在实际部署中,这意味着 LOA 位于整个上线流程的关键路径上。路由器已经配置、租赁协议已经签署、地址块已经分配——这些都无法真正带来可达性,直到上游服务提供商接受这条路由公告,而在没有 LOA 的情况下,上游通常不会接受。
LOA 包含哪些内容?
LOA 会明确授权方、被授权方及其 ASN、具体前缀,以及有权授予该项授权人员的签名。 各家服务提供商通常要求的标准组成部分包括:
- 授权方。 即地址空间的注册持有者,其公司名称和相关资料应与注册记录一致。
- 被授权方和 ASN。 文件需要说明谁被允许公告该地址空间,以及最关键的——将通过哪个自治系统编号进行公告。Cloudflare 的文档明确要求 LOA 同时写明被授权的前缀和公告所使用的 ASN——ASN 并不是可有可无的附加信息。
- 准确的前缀。 必须精确列出受授权覆盖的地址块(例如某个具体的 /24)。任何超出 LOA 所列范围的公告,都不属于该授权范围。
- 有效期。 授权的持续时间。对于租赁地址空间,其有效期应与租赁期限保持一致。
- 授权签署人。 包括姓名、职位以及有权代表持有者签署文件的人员签名,并附上联系方式,以便上游服务提供商在有需要时进行核实。
- 公司抬头和文件格式。 LOA 通常应以持有者公司的正式抬头纸制作。Cloudflare 指出,Transit 服务提供商可能会拒绝以图片格式提交的 LOA,而要求使用 PDF;数字签名通常可以接受,但签署人必须能够被清楚识别。
这些要求并不是毫无意义的行政装饰。公司抬头、与注册记录一致的企业资料,以及可识别的授权签署人,正是接收方用于确认文件真实性,以及签署人确实有权授予所声称授权的依据。
什么时候需要 LOA?
只要将由注册持有者以外的一方公告地址空间,通常都需要 LOA——这涵盖了绝大多数 IPv4 租赁、BYOIP 和由服务提供商代为公告的情况。 常见场景包括:
- 通过自己的 ASN 公告租赁的 IPv4。 这是最典型的情况:你租赁了一个地址块,并自行对外公告,因此你的上游需要看到持有者提供的授权。关于这个更完整的租赁流程,可以参考我们的IPv4 租赁指南以及IP 地址租赁如何运作的说明。
- 由服务提供商代表你公告地址空间。 当你的托管服务商、数据中心或平台通过其 ASN 公告你的前缀时,它需要获得你的授权——而它的上游同样需要看到这一授权。
- BYOIP 接入。 将自有 IP 地址空间(BYOIP)带入云平台或边缘平台时,需要授权该平台公告你的前缀,Cloudflare 的要求就是一个典型例子。
- 紧急路由变更。 例如 DDoS 清洗服务,在攻击发生时由服务提供商临时公告你的前缀,这类安排依赖于事先完成授权——这一点我们也在DDoS 缓解指南中进行了介绍。
判断标准其实很简单:如果进行公告的 ASN 并不属于注册持有者本身,那么几乎可以确定需要 LOA。
LOA vs ROA vs IRR Route Object
LOA、ROA 和 IRR route object 都在说明谁可以公告某个前缀——但它们面对不同的受众、采用不同形式,并且作用于不同层面。 它们彼此互补,而不是相互替代。一个正确部署的前缀,通常需要三者保持一致。
LOA vs ROA vs IRR Route Object
项目
LOA
ROA
IRR route object
它是什么
授予路由公告权限的签署文件
RPKI 中经过加密签名的记录
Internet Routing Registry 数据库中的记录
面向对象
人员——上游开通和 NOC 工作人员
执行路由起源验证的路由器
自动生成过滤规则的系统
形式
人类可读、合同性质
加密签名、机器验证
数据库记录
由谁创建
注册持有者(或授权代表)
注册持有者,通过其 RIR 创建
对象的持有者或 maintainer
缺失或错误时的影响
上游拒绝配置该路由公告
公告可能被执行 RPKI 验证的网络判定为 RPKI-Invalid 并拒绝
使用 IRR 数据生成过滤规则的服务提供商可能过滤该公告
最清楚的理解方式是:LOA 决定你的上游工作人员是否愿意配置并接受这项公告;ROA 决定互联网上执行验证的路由器是否认为该起源 ASN 合法;route object 则影响自动化过滤系统是否允许该公告通过。三者都可能独立出现问题,而且每一种失败都会产生不同的症状——这也是为什么部署有时会以看似完全不同的方式卡住,取决于究竟缺少哪一项记录。
这三者之间的互动也越来越紧密。例如,Cloudflare 的自动生成 LOA 流程会依赖经过 RPKI 签名的 ROA 以及所有权验证检查——也就是说,加密记录用于支持这份人工文件,而不是取代它。关于 ROA 的具体机制,包括它如何授权某个特定的起源 ASN,以及配置错误时会发生什么,请参阅我们的RPKI 和 ROA指南。
谁可以合法签发 LOA?
只有地址空间的注册持有者——或者被授权代表该持有者行事的人——才有资格合法签发 LOA。 这一点必须非常准确地说明,因为现实中经常有人把相关概念混淆。
有三个概念值得明确区分:
- LOA 授权的是公告,并不转移所有权。 签署 LOA 只是授予对地址空间进行路由的许可。它不会让被授权方成为该地址空间的持有者,不会更改注册记录,也不会转移任何注册管理层面的权利。当授权终止时,该项公告权限也随之终止。
- 在整个租赁期间,注册信息仍然保留在持有者名下。 在租赁安排中,注册管理机构的记录会继续显示原持有者为注册方。这并不是租赁关系中的漏洞——这正是租赁模式本身的结构。租户的公告权来自所获得的授权,而不是来自注册信息的改变。
- 进行公告不等于持有地址空间。 一个网络公告某个前缀,意味着它正在作为起源网络发布该前缀,这反映的是它获得了授权。公告本身并不能证明所有权。这种区分在概念和实际操作上都非常重要,因为未经授权的公告本身正是路由劫持的定义之一。
对于接收公告的上游服务提供商来说,这些区别最终会转化成一个验证问题:签署人真的拥有他们所声称的授权权力吗?这就是为什么 LOA 通常需要使用持有者的公司抬头纸、公司资料必须与注册记录相符,并由身份和职位明确的人签署。任何无法追溯到注册持有者的文件,都不能算真正的授权——那只能算是一项单方面声明。
LOA 与租赁 IPv4:付款之前应该核实什么?
由于 LOA 位于路由上线流程的关键路径上,因此应该在付款之前确认其处理方式,而不是付款之后才发现问题。 这个失败模式在行业中非常常见:企业签署了租赁协议、配置好路由、通知了上游,然后才被要求提供一份租赁协议中从未提及、而出租方又迟迟无法出具的 LOA。在文件到达之前,地址已经付费,却无法使用。
以下事项应当提前确认:
- 付款前取得 LOA,或者取得书面的交付承诺。 最好直接拿到文件;如果做不到,也应在协议中明确规定,必须在一个确定且较短的时间内交付。如果出租方连这两者中的任何一种都不愿意承诺,那已经说明了后续合作关系可能会是什么样子。
- 确认 LOA 中列出了正确的前缀。 应当准确列出你实际租赁的地址块。LOA 如果覆盖了不同地址块或过大的范围,上游可能会提出质疑;如果覆盖范围小于你所需,也无法授权剩余部分。
- 确认 LOA 中列出了正确的 ASN。 必须是实际会成为起源网络的 ASN——根据你的部署方式,这可能是你自己的 ASN,也可能是上游的 ASN。错误的 ASN 是一份形式上有效的 LOA 仍然无法帮助部署上线的最常见原因之一。
- 核对有效期与租赁期限。 如果授权比租赁期限更早到期,就会在部署过程中产生重新签发 LOA 的依赖。
- 确认文件确实来自注册持有者。 公司抬头和企业资料应与注册记录一致,并由可以识别且确实有授权权限的人签署。
- 确认重新签发流程。 如果你更换上游、更换 ASN,或需要为第二家服务提供商增加一份 LOA,更新文件最快可以在多久内提供?实际部署会发生变化,而授权文件必须能够同步更新。
- 询问 LOA 如何与 ROA 和 route object 配合。 单独拥有 LOA 并不够——正如上面的比较所示,ROA 和 IRR 记录也必须保持一致。能够完整处理这三项内容的出租方,比只提供一份文件然后把其余事情全部交给你的出租方,更适合生产环境部署。
这些问题在签约之前提出几乎没有成本,但签约之后才提出往往代价高昂。综合来看,它们也是判断租赁质量非常可靠的信号:如果一个地址安排将路由授权明确视为具有交付期限的正式交付成果,那么它通常是按照生产环境需求设计的;反之,如果把授权当成事后再处理的细节,那么这个问题往往会在最糟糕的时候暴露出来。
常见 LOA 问题
大多数 LOA 问题并不是围绕授权本身产生争议,而是文件交付太迟、内容错误或已经过期。 常见情况包括:
- 交付延迟。 这是最常见、也是成本最高的问题。只要文件一天没有到位,地址空间就一天无法正常公告,无论其他部分准备得多么充分。
- ASN 错误。 LOA 授权了一个与实际发起公告不同的 ASN——通常是因为文件起草之后部署方案发生变化,或出租方误解了租户的上游安排。
- 前缀错误或不够准确。 文件列出的地址块不正确、范围比协议约定更大,或者描述过于模糊,以至于上游不愿据此配置路由。
- 授权已经过期。 有效期已经结束,通常是在服务提供商重新审核文件,或租赁期内新增上游时才被发现。
- 签署人没有授权或无法验证。 文件由上游无法确认其权限的人签署,或者文件本身无法明确关联到注册持有者。
- 协议中完全没有规定 LOA。 租赁协议完全没有提到 LOA 的签发,因此交付时间和责任都没有定义——而交付延迟问题通常就是从这里开始。
这六类问题都可以在协议阶段提前避免,这也是为什么上面的核实清单比事后进行任何故障排查都更加重要。
实用检查清单
- 在签署协议之前,确认协议明确要求持有者签发 LOA,并规定具体交付时间。
- 在付款之前取得 LOA,或者至少取得书面的交付保证。
- 核实准确的前缀与实际租赁或取得的地址块完全一致。
- 核实 ASN 与实际将作为起源网络进行公告的 ASN 完全一致。
- 检查有效期是否覆盖整个租赁或部署周期。
- 确认文件使用注册持有者的正式公司抬头,企业资料与注册记录一致,并有可以识别的授权签署人。
- 按照上游要求的格式提交——PDF 是最稳妥的默认选择;图片格式经常会被拒绝。
- 确认如果上游、ASN 或授权范围发生变化,重新签发的流程以及处理时间。
- 确保 LOA、ROA 和 IRR route object 保持一致,让三种授权记录不会互相冲突。
- 保存一份副本——增加其他服务提供商、进行审计或未来修改部署时,都可能再次需要。
来自 i.lease 的实用说明
LOA 是一份很小的文件,但其运营影响远远超过文件本身的复杂程度。它在技术上并不复杂,只要有权签署的人愿意配合,通常几分钟就可以制作出来,但它却是租赁或新取得的地址块已经付费、却迟迟无法投入使用的最常见原因之一。问题几乎从来不是真正存在授权争议,而是协议签署之前没有人明确规定:由谁签发这份文件、多久内必须交付,以及文件中应该写些什么。
正因如此,LOA 的处理方式其实可以作为判断整体地址资源安排质量的一个很好指标。如果出租方能够快速提供正确的 LOA,一次就准确写明正确的 ASN 和前缀,不需要来回修改三次;当你更换上游时能够迅速重新签发;并且同时保持 ROA 与 route object 一致,那么它实际上正在展示生产环境路由所需要的运营纪律。相反,如果出租方认为 LOA 只是以后再处理的文书工作,那么整个合作关系中的其他环节很可能也会以类似方式处理。文件本身并不复杂,真正重要的是背后的协调能力,而正是这种协调,才能把一段地址空间变成真正可运行的网络基础设施。无论你是租赁还是直接取得地址空间,都应该把路由授权视为一个具有明确期限的正式交付成果,而不是默认它自然会出现。
总结
授权书(LOA)是注册持有者以书面形式授予某个指定方,通过指定 ASN 公告特定前缀的许可。上游服务提供商之所以要求 LOA,是因为仅凭注册数据无法确认公告方是否真正获得授权,而接受未经授权的公告就意味着参与路由劫持。文件会列出持有者、被授权方及 ASN、具体前缀和有效期,并由有权授予该项授权的人签署——它正处于“拥有地址空间”与“能够真正将其路由上线”之间的关键路径上。
最值得记住的区别,是 LOA 能做什么,以及不能做什么。它授权路由公告;它不会转移所有权、不会更改注册信息,也不会授予任何注册管理层面的权利。在租赁关系中,地址空间仍然注册在持有者名下,而租户的公告权来自持有者授予的授权——这也正是为什么 LOA 必须存在,而且必须由持有者出具。再加上由路由器验证的 ROA,以及供过滤系统查询的 route object,LOA 才共同组成将合同权利转化为被网络接受的路由公告所需要的完整记录体系。在部署之前让三者保持一致,在付款之前核实 LOA 的具体内容,才能真正把你已经安排好的地址空间变成可以实际使用的基础设施。
相关阅读
什么是 BGP 劫持?路由劫持如何发生、著名事件以及网络如何防范
RPKI 与 ROA 详解:路由起源授权如何保护你的 IPv4 前缀
什么是 BGP?边界网关协议如何让 IP 地址成为可访问的服务
- 在签署协议之前,确认协议明确要求持有者签发 LOA,并规定具体交付时间。
- 在付款之前取得 LOA,或者至少取得书面的交付保证。
- 核实准确的前缀与实际租赁或取得的地址块完全一致。
- 核实 ASN 与实际将作为起源网络进行公告的 ASN 完全一致。
- 检查有效期是否覆盖整个租赁或部署周期。
- 确认文件使用注册持有者的正式公司抬头,企业资料与注册记录一致,并有可以识别的授权签署人。
- 按照上游要求的格式提交——PDF 是最稳妥的默认选择;图片格式经常会被拒绝。
- 确认如果上游、ASN 或授权范围发生变化,重新签发的流程以及处理时间。
- 确保 LOA、ROA 和 IRR route object 保持一致,让三种授权记录不会互相冲突。
- 保存一份副本——增加其他服务提供商、进行审计或未来修改部署时,都可能再次需要。
来自 i.lease 的实用说明
LOA 是一份很小的文件,但其运营影响远远超过文件本身的复杂程度。它在技术上并不复杂,只要有权签署的人愿意配合,通常几分钟就可以制作出来,但它却是租赁或新取得的地址块已经付费、却迟迟无法投入使用的最常见原因之一。问题几乎从来不是真正存在授权争议,而是协议签署之前没有人明确规定:由谁签发这份文件、多久内必须交付,以及文件中应该写些什么。
正因如此,LOA 的处理方式其实可以作为判断整体地址资源安排质量的一个很好指标。如果出租方能够快速提供正确的 LOA,一次就准确写明正确的 ASN 和前缀,不需要来回修改三次;当你更换上游时能够迅速重新签发;并且同时保持 ROA 与 route object 一致,那么它实际上正在展示生产环境路由所需要的运营纪律。相反,如果出租方认为 LOA 只是以后再处理的文书工作,那么整个合作关系中的其他环节很可能也会以类似方式处理。文件本身并不复杂,真正重要的是背后的协调能力,而正是这种协调,才能把一段地址空间变成真正可运行的网络基础设施。无论你是租赁还是直接取得地址空间,都应该把路由授权视为一个具有明确期限的正式交付成果,而不是默认它自然会出现。
总结
授权书(LOA)是注册持有者以书面形式授予某个指定方,通过指定 ASN 公告特定前缀的许可。上游服务提供商之所以要求 LOA,是因为仅凭注册数据无法确认公告方是否真正获得授权,而接受未经授权的公告就意味着参与路由劫持。文件会列出持有者、被授权方及 ASN、具体前缀和有效期,并由有权授予该项授权的人签署——它正处于“拥有地址空间”与“能够真正将其路由上线”之间的关键路径上。
最值得记住的区别,是 LOA 能做什么,以及不能做什么。它授权路由公告;它不会转移所有权、不会更改注册信息,也不会授予任何注册管理层面的权利。在租赁关系中,地址空间仍然注册在持有者名下,而租户的公告权来自持有者授予的授权——这也正是为什么 LOA 必须存在,而且必须由持有者出具。再加上由路由器验证的 ROA,以及供过滤系统查询的 route object,LOA 才共同组成将合同权利转化为被网络接受的路由公告所需要的完整记录体系。在部署之前让三者保持一致,在付款之前核实 LOA 的具体内容,才能真正把你已经安排好的地址空间变成可以实际使用的基础设施。
相关阅读
什么是 BGP 劫持?路由劫持如何发生、著名事件以及网络如何防范
RPKI 与 ROA 详解:路由起源授权如何保护你的 IPv4 前缀
什么是 BGP?边界网关协议如何让 IP 地址成为可访问的服务
- 它由持有者签发,而不是由公告方自行签发。 有权授予许可的一方,是地址空间的持有者。租户不能自己给自己写一份 LOA。
- 它必须具有明确的针对性。 文件需要列出具体的前缀以及具体的 ASN。仅仅说明某方“信誉良好”并不能构成 LOA;文件中的内容必须与实际将要公告的内容完全匹配。
为什么上游服务提供商要求 LOA?
服务提供商之所以要求 LOA,是因为接受一个未经授权方发出的路由公告,正是前缀劫持发生的方式——而任何负责任的网络都不希望成为传播这种错误公告的一方。
正如我们在BGP 如何运作的指南中所解释的,路由系统在很大程度上是基于信任接受公告的,而各个网络之所以会过滤接收到的路由,正是因为虚假公告可能将属于其他人的流量重定向。这个风险并不是理论上的:未经授权的路由公告正是我们在BGP 劫持指南中所介绍事件的核心机制。如果上游服务提供商在未核实授权的情况下接受公告,那么它就会无意间成为后续事件的参与者。
LOA 填补的正是一个具体的信息缺口。注册记录可以确认地址持有者,但在租赁情况下,注册记录仍然显示原持有者,而实际进行公告的是另一方——因此,上游服务提供商无法仅通过数据库查询来验证租户。LOA 补上了缺失的这一环:由注册记录中可识别的那一方,以书面形式确认实际进行公告的一方已经获得许可。
在实际部署中,这意味着 LOA 位于整个上线流程的关键路径上。路由器已经配置、租赁协议已经签署、地址块已经分配——这些都无法真正带来可达性,直到上游服务提供商接受这条路由公告,而在没有 LOA 的情况下,上游通常不会接受。
LOA 包含哪些内容?
LOA 会明确授权方、被授权方及其 ASN、具体前缀,以及有权授予该项授权人员的签名。 各家服务提供商通常要求的标准组成部分包括:
- 授权方。 即地址空间的注册持有者,其公司名称和相关资料应与注册记录一致。
- 被授权方和 ASN。 文件需要说明谁被允许公告该地址空间,以及最关键的——将通过哪个自治系统编号进行公告。Cloudflare 的文档明确要求 LOA 同时写明被授权的前缀和公告所使用的 ASN——ASN 并不是可有可无的附加信息。
- 准确的前缀。 必须精确列出受授权覆盖的地址块(例如某个具体的 /24)。任何超出 LOA 所列范围的公告,都不属于该授权范围。
- 有效期。 授权的持续时间。对于租赁地址空间,其有效期应与租赁期限保持一致。
- 授权签署人。 包括姓名、职位以及有权代表持有者签署文件的人员签名,并附上联系方式,以便上游服务提供商在有需要时进行核实。
- 公司抬头和文件格式。 LOA 通常应以持有者公司的正式抬头纸制作。Cloudflare 指出,Transit 服务提供商可能会拒绝以图片格式提交的 LOA,而要求使用 PDF;数字签名通常可以接受,但签署人必须能够被清楚识别。
这些要求并不是毫无意义的行政装饰。公司抬头、与注册记录一致的企业资料,以及可识别的授权签署人,正是接收方用于确认文件真实性,以及签署人确实有权授予所声称授权的依据。
什么时候需要 LOA?
只要将由注册持有者以外的一方公告地址空间,通常都需要 LOA——这涵盖了绝大多数 IPv4 租赁、BYOIP 和由服务提供商代为公告的情况。 常见场景包括:
- 通过自己的 ASN 公告租赁的 IPv4。 这是最典型的情况:你租赁了一个地址块,并自行对外公告,因此你的上游需要看到持有者提供的授权。关于这个更完整的租赁流程,可以参考我们的IPv4 租赁指南以及IP 地址租赁如何运作的说明。
- 由服务提供商代表你公告地址空间。 当你的托管服务商、数据中心或平台通过其 ASN 公告你的前缀时,它需要获得你的授权——而它的上游同样需要看到这一授权。
- BYOIP 接入。 将自有 IP 地址空间(BYOIP)带入云平台或边缘平台时,需要授权该平台公告你的前缀,Cloudflare 的要求就是一个典型例子。
- 紧急路由变更。 例如 DDoS 清洗服务,在攻击发生时由服务提供商临时公告你的前缀,这类安排依赖于事先完成授权——这一点我们也在DDoS 缓解指南中进行了介绍。
判断标准其实很简单:如果进行公告的 ASN 并不属于注册持有者本身,那么几乎可以确定需要 LOA。
LOA vs ROA vs IRR Route Object
LOA、ROA 和 IRR route object 都在说明谁可以公告某个前缀——但它们面对不同的受众、采用不同形式,并且作用于不同层面。 它们彼此互补,而不是相互替代。一个正确部署的前缀,通常需要三者保持一致。
LOA vs ROA vs IRR Route Object
项目
LOA
ROA
IRR route object
它是什么
授予路由公告权限的签署文件
RPKI 中经过加密签名的记录
Internet Routing Registry 数据库中的记录
面向对象
人员——上游开通和 NOC 工作人员
执行路由起源验证的路由器
自动生成过滤规则的系统
形式
人类可读、合同性质
加密签名、机器验证
数据库记录
由谁创建
注册持有者(或授权代表)
注册持有者,通过其 RIR 创建
对象的持有者或 maintainer
缺失或错误时的影响
上游拒绝配置该路由公告
公告可能被执行 RPKI 验证的网络判定为 RPKI-Invalid 并拒绝
使用 IRR 数据生成过滤规则的服务提供商可能过滤该公告
最清楚的理解方式是:LOA 决定你的上游工作人员是否愿意配置并接受这项公告;ROA 决定互联网上执行验证的路由器是否认为该起源 ASN 合法;route object 则影响自动化过滤系统是否允许该公告通过。三者都可能独立出现问题,而且每一种失败都会产生不同的症状——这也是为什么部署有时会以看似完全不同的方式卡住,取决于究竟缺少哪一项记录。
这三者之间的互动也越来越紧密。例如,Cloudflare 的自动生成 LOA 流程会依赖经过 RPKI 签名的 ROA 以及所有权验证检查——也就是说,加密记录用于支持这份人工文件,而不是取代它。关于 ROA 的具体机制,包括它如何授权某个特定的起源 ASN,以及配置错误时会发生什么,请参阅我们的RPKI 和 ROA指南。
谁可以合法签发 LOA?
只有地址空间的注册持有者——或者被授权代表该持有者行事的人——才有资格合法签发 LOA。 这一点必须非常准确地说明,因为现实中经常有人把相关概念混淆。
有三个概念值得明确区分:
- LOA 授权的是公告,并不转移所有权。 签署 LOA 只是授予对地址空间进行路由的许可。它不会让被授权方成为该地址空间的持有者,不会更改注册记录,也不会转移任何注册管理层面的权利。当授权终止时,该项公告权限也随之终止。
- 在整个租赁期间,注册信息仍然保留在持有者名下。 在租赁安排中,注册管理机构的记录会继续显示原持有者为注册方。这并不是租赁关系中的漏洞——这正是租赁模式本身的结构。租户的公告权来自所获得的授权,而不是来自注册信息的改变。
- 进行公告不等于持有地址空间。 一个网络公告某个前缀,意味着它正在作为起源网络发布该前缀,这反映的是它获得了授权。公告本身并不能证明所有权。这种区分在概念和实际操作上都非常重要,因为未经授权的公告本身正是路由劫持的定义之一。
对于接收公告的上游服务提供商来说,这些区别最终会转化成一个验证问题:签署人真的拥有他们所声称的授权权力吗?这就是为什么 LOA 通常需要使用持有者的公司抬头纸、公司资料必须与注册记录相符,并由身份和职位明确的人签署。任何无法追溯到注册持有者的文件,都不能算真正的授权——那只能算是一项单方面声明。
LOA 与租赁 IPv4:付款之前应该核实什么?
由于 LOA 位于路由上线流程的关键路径上,因此应该在付款之前确认其处理方式,而不是付款之后才发现问题。 这个失败模式在行业中非常常见:企业签署了租赁协议、配置好路由、通知了上游,然后才被要求提供一份租赁协议中从未提及、而出租方又迟迟无法出具的 LOA。在文件到达之前,地址已经付费,却无法使用。
以下事项应当提前确认:
- 付款前取得 LOA,或者取得书面的交付承诺。 最好直接拿到文件;如果做不到,也应在协议中明确规定,必须在一个确定且较短的时间内交付。如果出租方连这两者中的任何一种都不愿意承诺,那已经说明了后续合作关系可能会是什么样子。
- 确认 LOA 中列出了正确的前缀。 应当准确列出你实际租赁的地址块。LOA 如果覆盖了不同地址块或过大的范围,上游可能会提出质疑;如果覆盖范围小于你所需,也无法授权剩余部分。
- 确认 LOA 中列出了正确的 ASN。 必须是实际会成为起源网络的 ASN——根据你的部署方式,这可能是你自己的 ASN,也可能是上游的 ASN。错误的 ASN 是一份形式上有效的 LOA 仍然无法帮助部署上线的最常见原因之一。
- 核对有效期与租赁期限。 如果授权比租赁期限更早到期,就会在部署过程中产生重新签发 LOA 的依赖。
- 确认文件确实来自注册持有者。 公司抬头和企业资料应与注册记录一致,并由可以识别且确实有授权权限的人签署。
- 确认重新签发流程。 如果你更换上游、更换 ASN,或需要为第二家服务提供商增加一份 LOA,更新文件最快可以在多久内提供?实际部署会发生变化,而授权文件必须能够同步更新。
- 询问 LOA 如何与 ROA 和 route object 配合。 单独拥有 LOA 并不够——正如上面的比较所示,ROA 和 IRR 记录也必须保持一致。能够完整处理这三项内容的出租方,比只提供一份文件然后把其余事情全部交给你的出租方,更适合生产环境部署。
这些问题在签约之前提出几乎没有成本,但签约之后才提出往往代价高昂。综合来看,它们也是判断租赁质量非常可靠的信号:如果一个地址安排将路由授权明确视为具有交付期限的正式交付成果,那么它通常是按照生产环境需求设计的;反之,如果把授权当成事后再处理的细节,那么这个问题往往会在最糟糕的时候暴露出来。
常见 LOA 问题
大多数 LOA 问题并不是围绕授权本身产生争议,而是文件交付太迟、内容错误或已经过期。 常见情况包括:
- 交付延迟。 这是最常见、也是成本最高的问题。只要文件一天没有到位,地址空间就一天无法正常公告,无论其他部分准备得多么充分。
- ASN 错误。 LOA 授权了一个与实际发起公告不同的 ASN——通常是因为文件起草之后部署方案发生变化,或出租方误解了租户的上游安排。
- 前缀错误或不够准确。 文件列出的地址块不正确、范围比协议约定更大,或者描述过于模糊,以至于上游不愿据此配置路由。
- 授权已经过期。 有效期已经结束,通常是在服务提供商重新审核文件,或租赁期内新增上游时才被发现。
- 签署人没有授权或无法验证。 文件由上游无法确认其权限的人签署,或者文件本身无法明确关联到注册持有者。
- 协议中完全没有规定 LOA。 租赁协议完全没有提到 LOA 的签发,因此交付时间和责任都没有定义——而交付延迟问题通常就是从这里开始。
这六类问题都可以在协议阶段提前避免,这也是为什么上面的核实清单比事后进行任何故障排查都更加重要。
实用检查清单
- 在签署协议之前,确认协议明确要求持有者签发 LOA,并规定具体交付时间。
- 在付款之前取得 LOA,或者至少取得书面的交付保证。
- 核实准确的前缀与实际租赁或取得的地址块完全一致。
- 核实 ASN 与实际将作为起源网络进行公告的 ASN 完全一致。
- 检查有效期是否覆盖整个租赁或部署周期。
- 确认文件使用注册持有者的正式公司抬头,企业资料与注册记录一致,并有可以识别的授权签署人。
- 按照上游要求的格式提交——PDF 是最稳妥的默认选择;图片格式经常会被拒绝。
- 确认如果上游、ASN 或授权范围发生变化,重新签发的流程以及处理时间。
- 确保 LOA、ROA 和 IRR route object 保持一致,让三种授权记录不会互相冲突。
- 保存一份副本——增加其他服务提供商、进行审计或未来修改部署时,都可能再次需要。
来自 i.lease 的实用说明
LOA 是一份很小的文件,但其运营影响远远超过文件本身的复杂程度。它在技术上并不复杂,只要有权签署的人愿意配合,通常几分钟就可以制作出来,但它却是租赁或新取得的地址块已经付费、却迟迟无法投入使用的最常见原因之一。问题几乎从来不是真正存在授权争议,而是协议签署之前没有人明确规定:由谁签发这份文件、多久内必须交付,以及文件中应该写些什么。
正因如此,LOA 的处理方式其实可以作为判断整体地址资源安排质量的一个很好指标。如果出租方能够快速提供正确的 LOA,一次就准确写明正确的 ASN 和前缀,不需要来回修改三次;当你更换上游时能够迅速重新签发;并且同时保持 ROA 与 route object 一致,那么它实际上正在展示生产环境路由所需要的运营纪律。相反,如果出租方认为 LOA 只是以后再处理的文书工作,那么整个合作关系中的其他环节很可能也会以类似方式处理。文件本身并不复杂,真正重要的是背后的协调能力,而正是这种协调,才能把一段地址空间变成真正可运行的网络基础设施。无论你是租赁还是直接取得地址空间,都应该把路由授权视为一个具有明确期限的正式交付成果,而不是默认它自然会出现。
总结
授权书(LOA)是注册持有者以书面形式授予某个指定方,通过指定 ASN 公告特定前缀的许可。上游服务提供商之所以要求 LOA,是因为仅凭注册数据无法确认公告方是否真正获得授权,而接受未经授权的公告就意味着参与路由劫持。文件会列出持有者、被授权方及 ASN、具体前缀和有效期,并由有权授予该项授权的人签署——它正处于“拥有地址空间”与“能够真正将其路由上线”之间的关键路径上。
最值得记住的区别,是 LOA 能做什么,以及不能做什么。它授权路由公告;它不会转移所有权、不会更改注册信息,也不会授予任何注册管理层面的权利。在租赁关系中,地址空间仍然注册在持有者名下,而租户的公告权来自持有者授予的授权——这也正是为什么 LOA 必须存在,而且必须由持有者出具。再加上由路由器验证的 ROA,以及供过滤系统查询的 route object,LOA 才共同组成将合同权利转化为被网络接受的路由公告所需要的完整记录体系。在部署之前让三者保持一致,在付款之前核实 LOA 的具体内容,才能真正把你已经安排好的地址空间变成可以实际使用的基础设施。
相关阅读
什么是 BGP 劫持?路由劫持如何发生、著名事件以及网络如何防范
RPKI 与 ROA 详解:路由起源授权如何保护你的 IPv4 前缀
什么是 BGP?边界网关协议如何让 IP 地址成为可访问的服务
- 付款前取得 LOA,或者取得书面的交付承诺。 最好直接拿到文件;如果做不到,也应在协议中明确规定,必须在一个确定且较短的时间内交付。如果出租方连这两者中的任何一种都不愿意承诺,那已经说明了后续合作关系可能会是什么样子。
- 确认 LOA 中列出了正确的前缀。 应当准确列出你实际租赁的地址块。LOA 如果覆盖了不同地址块或过大的范围,上游可能会提出质疑;如果覆盖范围小于你所需,也无法授权剩余部分。
- 确认 LOA 中列出了正确的 ASN。 必须是实际会成为起源网络的 ASN——根据你的部署方式,这可能是你自己的 ASN,也可能是上游的 ASN。错误的 ASN 是一份形式上有效的 LOA 仍然无法帮助部署上线的最常见原因之一。
- 核对有效期与租赁期限。 如果授权比租赁期限更早到期,就会在部署过程中产生重新签发 LOA 的依赖。
- 确认文件确实来自注册持有者。 公司抬头和企业资料应与注册记录一致,并由可以识别且确实有授权权限的人签署。
- 确认重新签发流程。 如果你更换上游、更换 ASN,或需要为第二家服务提供商增加一份 LOA,更新文件最快可以在多久内提供?实际部署会发生变化,而授权文件必须能够同步更新。
- 询问 LOA 如何与 ROA 和 route object 配合。 单独拥有 LOA 并不够——正如上面的比较所示,ROA 和 IRR 记录也必须保持一致。能够完整处理这三项内容的出租方,比只提供一份文件然后把其余事情全部交给你的出租方,更适合生产环境部署。
这些问题在签约之前提出几乎没有成本,但签约之后才提出往往代价高昂。综合来看,它们也是判断租赁质量非常可靠的信号:如果一个地址安排将路由授权明确视为具有交付期限的正式交付成果,那么它通常是按照生产环境需求设计的;反之,如果把授权当成事后再处理的细节,那么这个问题往往会在最糟糕的时候暴露出来。
常见 LOA 问题
大多数 LOA 问题并不是围绕授权本身产生争议,而是文件交付太迟、内容错误或已经过期。 常见情况包括:
- 交付延迟。 这是最常见、也是成本最高的问题。只要文件一天没有到位,地址空间就一天无法正常公告,无论其他部分准备得多么充分。
- ASN 错误。 LOA 授权了一个与实际发起公告不同的 ASN——通常是因为文件起草之后部署方案发生变化,或出租方误解了租户的上游安排。
- 前缀错误或不够准确。 文件列出的地址块不正确、范围比协议约定更大,或者描述过于模糊,以至于上游不愿据此配置路由。
- 授权已经过期。 有效期已经结束,通常是在服务提供商重新审核文件,或租赁期内新增上游时才被发现。
- 签署人没有授权或无法验证。 文件由上游无法确认其权限的人签署,或者文件本身无法明确关联到注册持有者。
- 协议中完全没有规定 LOA。 租赁协议完全没有提到 LOA 的签发,因此交付时间和责任都没有定义——而交付延迟问题通常就是从这里开始。
这六类问题都可以在协议阶段提前避免,这也是为什么上面的核实清单比事后进行任何故障排查都更加重要。
实用检查清单
- 在签署协议之前,确认协议明确要求持有者签发 LOA,并规定具体交付时间。
- 在付款之前取得 LOA,或者至少取得书面的交付保证。
- 核实准确的前缀与实际租赁或取得的地址块完全一致。
- 核实 ASN 与实际将作为起源网络进行公告的 ASN 完全一致。
- 检查有效期是否覆盖整个租赁或部署周期。
- 确认文件使用注册持有者的正式公司抬头,企业资料与注册记录一致,并有可以识别的授权签署人。
- 按照上游要求的格式提交——PDF 是最稳妥的默认选择;图片格式经常会被拒绝。
- 确认如果上游、ASN 或授权范围发生变化,重新签发的流程以及处理时间。
- 确保 LOA、ROA 和 IRR route object 保持一致,让三种授权记录不会互相冲突。
- 保存一份副本——增加其他服务提供商、进行审计或未来修改部署时,都可能再次需要。
来自 i.lease 的实用说明
LOA 是一份很小的文件,但其运营影响远远超过文件本身的复杂程度。它在技术上并不复杂,只要有权签署的人愿意配合,通常几分钟就可以制作出来,但它却是租赁或新取得的地址块已经付费、却迟迟无法投入使用的最常见原因之一。问题几乎从来不是真正存在授权争议,而是协议签署之前没有人明确规定:由谁签发这份文件、多久内必须交付,以及文件中应该写些什么。
正因如此,LOA 的处理方式其实可以作为判断整体地址资源安排质量的一个很好指标。如果出租方能够快速提供正确的 LOA,一次就准确写明正确的 ASN 和前缀,不需要来回修改三次;当你更换上游时能够迅速重新签发;并且同时保持 ROA 与 route object 一致,那么它实际上正在展示生产环境路由所需要的运营纪律。相反,如果出租方认为 LOA 只是以后再处理的文书工作,那么整个合作关系中的其他环节很可能也会以类似方式处理。文件本身并不复杂,真正重要的是背后的协调能力,而正是这种协调,才能把一段地址空间变成真正可运行的网络基础设施。无论你是租赁还是直接取得地址空间,都应该把路由授权视为一个具有明确期限的正式交付成果,而不是默认它自然会出现。
总结
授权书(LOA)是注册持有者以书面形式授予某个指定方,通过指定 ASN 公告特定前缀的许可。上游服务提供商之所以要求 LOA,是因为仅凭注册数据无法确认公告方是否真正获得授权,而接受未经授权的公告就意味着参与路由劫持。文件会列出持有者、被授权方及 ASN、具体前缀和有效期,并由有权授予该项授权的人签署——它正处于“拥有地址空间”与“能够真正将其路由上线”之间的关键路径上。
最值得记住的区别,是 LOA 能做什么,以及不能做什么。它授权路由公告;它不会转移所有权、不会更改注册信息,也不会授予任何注册管理层面的权利。在租赁关系中,地址空间仍然注册在持有者名下,而租户的公告权来自持有者授予的授权——这也正是为什么 LOA 必须存在,而且必须由持有者出具。再加上由路由器验证的 ROA,以及供过滤系统查询的 route object,LOA 才共同组成将合同权利转化为被网络接受的路由公告所需要的完整记录体系。在部署之前让三者保持一致,在付款之前核实 LOA 的具体内容,才能真正把你已经安排好的地址空间变成可以实际使用的基础设施。
相关阅读
什么是 BGP 劫持?路由劫持如何发生、著名事件以及网络如何防范
RPKI 与 ROA 详解:路由起源授权如何保护你的 IPv4 前缀
什么是 BGP?边界网关协议如何让 IP 地址成为可访问的服务
- 它由持有者签发,而不是由公告方自行签发。 有权授予许可的一方,是地址空间的持有者。租户不能自己给自己写一份 LOA。
- 它必须具有明确的针对性。 文件需要列出具体的前缀以及具体的 ASN。仅仅说明某方“信誉良好”并不能构成 LOA;文件中的内容必须与实际将要公告的内容完全匹配。
为什么上游服务提供商要求 LOA?
服务提供商之所以要求 LOA,是因为接受一个未经授权方发出的路由公告,正是前缀劫持发生的方式——而任何负责任的网络都不希望成为传播这种错误公告的一方。
正如我们在BGP 如何运作的指南中所解释的,路由系统在很大程度上是基于信任接受公告的,而各个网络之所以会过滤接收到的路由,正是因为虚假公告可能将属于其他人的流量重定向。这个风险并不是理论上的:未经授权的路由公告正是我们在BGP 劫持指南中所介绍事件的核心机制。如果上游服务提供商在未核实授权的情况下接受公告,那么它就会无意间成为后续事件的参与者。
LOA 填补的正是一个具体的信息缺口。注册记录可以确认地址持有者,但在租赁情况下,注册记录仍然显示原持有者,而实际进行公告的是另一方——因此,上游服务提供商无法仅通过数据库查询来验证租户。LOA 补上了缺失的这一环:由注册记录中可识别的那一方,以书面形式确认实际进行公告的一方已经获得许可。
在实际部署中,这意味着 LOA 位于整个上线流程的关键路径上。路由器已经配置、租赁协议已经签署、地址块已经分配——这些都无法真正带来可达性,直到上游服务提供商接受这条路由公告,而在没有 LOA 的情况下,上游通常不会接受。
LOA 包含哪些内容?
LOA 会明确授权方、被授权方及其 ASN、具体前缀,以及有权授予该项授权人员的签名。 各家服务提供商通常要求的标准组成部分包括:
- 授权方。 即地址空间的注册持有者,其公司名称和相关资料应与注册记录一致。
- 被授权方和 ASN。 文件需要说明谁被允许公告该地址空间,以及最关键的——将通过哪个自治系统编号进行公告。Cloudflare 的文档明确要求 LOA 同时写明被授权的前缀和公告所使用的 ASN——ASN 并不是可有可无的附加信息。
- 准确的前缀。 必须精确列出受授权覆盖的地址块(例如某个具体的 /24)。任何超出 LOA 所列范围的公告,都不属于该授权范围。
- 有效期。 授权的持续时间。对于租赁地址空间,其有效期应与租赁期限保持一致。
- 授权签署人。 包括姓名、职位以及有权代表持有者签署文件的人员签名,并附上联系方式,以便上游服务提供商在有需要时进行核实。
- 公司抬头和文件格式。 LOA 通常应以持有者公司的正式抬头纸制作。Cloudflare 指出,Transit 服务提供商可能会拒绝以图片格式提交的 LOA,而要求使用 PDF;数字签名通常可以接受,但签署人必须能够被清楚识别。
这些要求并不是毫无意义的行政装饰。公司抬头、与注册记录一致的企业资料,以及可识别的授权签署人,正是接收方用于确认文件真实性,以及签署人确实有权授予所声称授权的依据。
什么时候需要 LOA?
只要将由注册持有者以外的一方公告地址空间,通常都需要 LOA——这涵盖了绝大多数 IPv4 租赁、BYOIP 和由服务提供商代为公告的情况。 常见场景包括:
- 通过自己的 ASN 公告租赁的 IPv4。 这是最典型的情况:你租赁了一个地址块,并自行对外公告,因此你的上游需要看到持有者提供的授权。关于这个更完整的租赁流程,可以参考我们的IPv4 租赁指南以及IP 地址租赁如何运作的说明。
- 由服务提供商代表你公告地址空间。 当你的托管服务商、数据中心或平台通过其 ASN 公告你的前缀时,它需要获得你的授权——而它的上游同样需要看到这一授权。
- BYOIP 接入。 将自有 IP 地址空间(BYOIP)带入云平台或边缘平台时,需要授权该平台公告你的前缀,Cloudflare 的要求就是一个典型例子。
- 紧急路由变更。 例如 DDoS 清洗服务,在攻击发生时由服务提供商临时公告你的前缀,这类安排依赖于事先完成授权——这一点我们也在DDoS 缓解指南中进行了介绍。
判断标准其实很简单:如果进行公告的 ASN 并不属于注册持有者本身,那么几乎可以确定需要 LOA。
LOA vs ROA vs IRR Route Object
LOA、ROA 和 IRR route object 都在说明谁可以公告某个前缀——但它们面对不同的受众、采用不同形式,并且作用于不同层面。 它们彼此互补,而不是相互替代。一个正确部署的前缀,通常需要三者保持一致。
LOA vs ROA vs IRR Route Object
项目
LOA
ROA
IRR route object
它是什么
授予路由公告权限的签署文件
RPKI 中经过加密签名的记录
Internet Routing Registry 数据库中的记录
面向对象
人员——上游开通和 NOC 工作人员
执行路由起源验证的路由器
自动生成过滤规则的系统
形式
人类可读、合同性质
加密签名、机器验证
数据库记录
由谁创建
注册持有者(或授权代表)
注册持有者,通过其 RIR 创建
对象的持有者或 maintainer
缺失或错误时的影响
上游拒绝配置该路由公告
公告可能被执行 RPKI 验证的网络判定为 RPKI-Invalid 并拒绝
使用 IRR 数据生成过滤规则的服务提供商可能过滤该公告
最清楚的理解方式是:LOA 决定你的上游工作人员是否愿意配置并接受这项公告;ROA 决定互联网上执行验证的路由器是否认为该起源 ASN 合法;route object 则影响自动化过滤系统是否允许该公告通过。三者都可能独立出现问题,而且每一种失败都会产生不同的症状——这也是为什么部署有时会以看似完全不同的方式卡住,取决于究竟缺少哪一项记录。
这三者之间的互动也越来越紧密。例如,Cloudflare 的自动生成 LOA 流程会依赖经过 RPKI 签名的 ROA 以及所有权验证检查——也就是说,加密记录用于支持这份人工文件,而不是取代它。关于 ROA 的具体机制,包括它如何授权某个特定的起源 ASN,以及配置错误时会发生什么,请参阅我们的RPKI 和 ROA指南。
谁可以合法签发 LOA?
只有地址空间的注册持有者——或者被授权代表该持有者行事的人——才有资格合法签发 LOA。 这一点必须非常准确地说明,因为现实中经常有人把相关概念混淆。
有三个概念值得明确区分:
- LOA 授权的是公告,并不转移所有权。 签署 LOA 只是授予对地址空间进行路由的许可。它不会让被授权方成为该地址空间的持有者,不会更改注册记录,也不会转移任何注册管理层面的权利。当授权终止时,该项公告权限也随之终止。
- 在整个租赁期间,注册信息仍然保留在持有者名下。 在租赁安排中,注册管理机构的记录会继续显示原持有者为注册方。这并不是租赁关系中的漏洞——这正是租赁模式本身的结构。租户的公告权来自所获得的授权,而不是来自注册信息的改变。
- 进行公告不等于持有地址空间。 一个网络公告某个前缀,意味着它正在作为起源网络发布该前缀,这反映的是它获得了授权。公告本身并不能证明所有权。这种区分在概念和实际操作上都非常重要,因为未经授权的公告本身正是路由劫持的定义之一。
对于接收公告的上游服务提供商来说,这些区别最终会转化成一个验证问题:签署人真的拥有他们所声称的授权权力吗?这就是为什么 LOA 通常需要使用持有者的公司抬头纸、公司资料必须与注册记录相符,并由身份和职位明确的人签署。任何无法追溯到注册持有者的文件,都不能算真正的授权——那只能算是一项单方面声明。
LOA 与租赁 IPv4:付款之前应该核实什么?
由于 LOA 位于路由上线流程的关键路径上,因此应该在付款之前确认其处理方式,而不是付款之后才发现问题。 这个失败模式在行业中非常常见:企业签署了租赁协议、配置好路由、通知了上游,然后才被要求提供一份租赁协议中从未提及、而出租方又迟迟无法出具的 LOA。在文件到达之前,地址已经付费,却无法使用。
以下事项应当提前确认:
- 付款前取得 LOA,或者取得书面的交付承诺。 最好直接拿到文件;如果做不到,也应在协议中明确规定,必须在一个确定且较短的时间内交付。如果出租方连这两者中的任何一种都不愿意承诺,那已经说明了后续合作关系可能会是什么样子。
- 确认 LOA 中列出了正确的前缀。 应当准确列出你实际租赁的地址块。LOA 如果覆盖了不同地址块或过大的范围,上游可能会提出质疑;如果覆盖范围小于你所需,也无法授权剩余部分。
- 确认 LOA 中列出了正确的 ASN。 必须是实际会成为起源网络的 ASN——根据你的部署方式,这可能是你自己的 ASN,也可能是上游的 ASN。错误的 ASN 是一份形式上有效的 LOA 仍然无法帮助部署上线的最常见原因之一。
- 核对有效期与租赁期限。 如果授权比租赁期限更早到期,就会在部署过程中产生重新签发 LOA 的依赖。
- 确认文件确实来自注册持有者。 公司抬头和企业资料应与注册记录一致,并由可以识别且确实有授权权限的人签署。
- 确认重新签发流程。 如果你更换上游、更换 ASN,或需要为第二家服务提供商增加一份 LOA,更新文件最快可以在多久内提供?实际部署会发生变化,而授权文件必须能够同步更新。
- 询问 LOA 如何与 ROA 和 route object 配合。 单独拥有 LOA 并不够——正如上面的比较所示,ROA 和 IRR 记录也必须保持一致。能够完整处理这三项内容的出租方,比只提供一份文件然后把其余事情全部交给你的出租方,更适合生产环境部署。
这些问题在签约之前提出几乎没有成本,但签约之后才提出往往代价高昂。综合来看,它们也是判断租赁质量非常可靠的信号:如果一个地址安排将路由授权明确视为具有交付期限的正式交付成果,那么它通常是按照生产环境需求设计的;反之,如果把授权当成事后再处理的细节,那么这个问题往往会在最糟糕的时候暴露出来。
常见 LOA 问题
大多数 LOA 问题并不是围绕授权本身产生争议,而是文件交付太迟、内容错误或已经过期。 常见情况包括:
- 交付延迟。 这是最常见、也是成本最高的问题。只要文件一天没有到位,地址空间就一天无法正常公告,无论其他部分准备得多么充分。
- ASN 错误。 LOA 授权了一个与实际发起公告不同的 ASN——通常是因为文件起草之后部署方案发生变化,或出租方误解了租户的上游安排。
- 前缀错误或不够准确。 文件列出的地址块不正确、范围比协议约定更大,或者描述过于模糊,以至于上游不愿据此配置路由。
- 授权已经过期。 有效期已经结束,通常是在服务提供商重新审核文件,或租赁期内新增上游时才被发现。
- 签署人没有授权或无法验证。 文件由上游无法确认其权限的人签署,或者文件本身无法明确关联到注册持有者。
- 协议中完全没有规定 LOA。 租赁协议完全没有提到 LOA 的签发,因此交付时间和责任都没有定义——而交付延迟问题通常就是从这里开始。
这六类问题都可以在协议阶段提前避免,这也是为什么上面的核实清单比事后进行任何故障排查都更加重要。
实用检查清单
- 在签署协议之前,确认协议明确要求持有者签发 LOA,并规定具体交付时间。
- 在付款之前取得 LOA,或者至少取得书面的交付保证。
- 核实准确的前缀与实际租赁或取得的地址块完全一致。
- 核实 ASN 与实际将作为起源网络进行公告的 ASN 完全一致。
- 检查有效期是否覆盖整个租赁或部署周期。
- 确认文件使用注册持有者的正式公司抬头,企业资料与注册记录一致,并有可以识别的授权签署人。
- 按照上游要求的格式提交——PDF 是最稳妥的默认选择;图片格式经常会被拒绝。
- 确认如果上游、ASN 或授权范围发生变化,重新签发的流程以及处理时间。
- 确保 LOA、ROA 和 IRR route object 保持一致,让三种授权记录不会互相冲突。
- 保存一份副本——增加其他服务提供商、进行审计或未来修改部署时,都可能再次需要。
来自 i.lease 的实用说明
LOA 是一份很小的文件,但其运营影响远远超过文件本身的复杂程度。它在技术上并不复杂,只要有权签署的人愿意配合,通常几分钟就可以制作出来,但它却是租赁或新取得的地址块已经付费、却迟迟无法投入使用的最常见原因之一。问题几乎从来不是真正存在授权争议,而是协议签署之前没有人明确规定:由谁签发这份文件、多久内必须交付,以及文件中应该写些什么。
正因如此,LOA 的处理方式其实可以作为判断整体地址资源安排质量的一个很好指标。如果出租方能够快速提供正确的 LOA,一次就准确写明正确的 ASN 和前缀,不需要来回修改三次;当你更换上游时能够迅速重新签发;并且同时保持 ROA 与 route object 一致,那么它实际上正在展示生产环境路由所需要的运营纪律。相反,如果出租方认为 LOA 只是以后再处理的文书工作,那么整个合作关系中的其他环节很可能也会以类似方式处理。文件本身并不复杂,真正重要的是背后的协调能力,而正是这种协调,才能把一段地址空间变成真正可运行的网络基础设施。无论你是租赁还是直接取得地址空间,都应该把路由授权视为一个具有明确期限的正式交付成果,而不是默认它自然会出现。
总结
授权书(LOA)是注册持有者以书面形式授予某个指定方,通过指定 ASN 公告特定前缀的许可。上游服务提供商之所以要求 LOA,是因为仅凭注册数据无法确认公告方是否真正获得授权,而接受未经授权的公告就意味着参与路由劫持。文件会列出持有者、被授权方及 ASN、具体前缀和有效期,并由有权授予该项授权的人签署——它正处于“拥有地址空间”与“能够真正将其路由上线”之间的关键路径上。
最值得记住的区别,是 LOA 能做什么,以及不能做什么。它授权路由公告;它不会转移所有权、不会更改注册信息,也不会授予任何注册管理层面的权利。在租赁关系中,地址空间仍然注册在持有者名下,而租户的公告权来自持有者授予的授权——这也正是为什么 LOA 必须存在,而且必须由持有者出具。再加上由路由器验证的 ROA,以及供过滤系统查询的 route object,LOA 才共同组成将合同权利转化为被网络接受的路由公告所需要的完整记录体系。在部署之前让三者保持一致,在付款之前核实 LOA 的具体内容,才能真正把你已经安排好的地址空间变成可以实际使用的基础设施。
相关阅读
什么是 BGP 劫持?路由劫持如何发生、著名事件以及网络如何防范
RPKI 与 ROA 详解:路由起源授权如何保护你的 IPv4 前缀
什么是 BGP?边界网关协议如何让 IP 地址成为可访问的服务
- 授权方。 即地址空间的注册持有者,其公司名称和相关资料应与注册记录一致。
- 被授权方和 ASN。 文件需要说明谁被允许公告该地址空间,以及最关键的——将通过哪个自治系统编号进行公告。Cloudflare 的文档明确要求 LOA 同时写明被授权的前缀和公告所使用的 ASN——ASN 并不是可有可无的附加信息。
- 准确的前缀。 必须精确列出受授权覆盖的地址块(例如某个具体的 /24)。任何超出 LOA 所列范围的公告,都不属于该授权范围。
- 有效期。 授权的持续时间。对于租赁地址空间,其有效期应与租赁期限保持一致。
- 授权签署人。 包括姓名、职位以及有权代表持有者签署文件的人员签名,并附上联系方式,以便上游服务提供商在有需要时进行核实。
- 公司抬头和文件格式。 LOA 通常应以持有者公司的正式抬头纸制作。Cloudflare 指出,Transit 服务提供商可能会拒绝以图片格式提交的 LOA,而要求使用 PDF;数字签名通常可以接受,但签署人必须能够被清楚识别。
这些要求并不是毫无意义的行政装饰。公司抬头、与注册记录一致的企业资料,以及可识别的授权签署人,正是接收方用于确认文件真实性,以及签署人确实有权授予所声称授权的依据。
什么时候需要 LOA?
只要将由注册持有者以外的一方公告地址空间,通常都需要 LOA——这涵盖了绝大多数 IPv4 租赁、BYOIP 和由服务提供商代为公告的情况。 常见场景包括:
- 通过自己的 ASN 公告租赁的 IPv4。 这是最典型的情况:你租赁了一个地址块,并自行对外公告,因此你的上游需要看到持有者提供的授权。关于这个更完整的租赁流程,可以参考我们的IPv4 租赁指南以及IP 地址租赁如何运作的说明。
- 由服务提供商代表你公告地址空间。 当你的托管服务商、数据中心或平台通过其 ASN 公告你的前缀时,它需要获得你的授权——而它的上游同样需要看到这一授权。
- BYOIP 接入。 将自有 IP 地址空间(BYOIP)带入云平台或边缘平台时,需要授权该平台公告你的前缀,Cloudflare 的要求就是一个典型例子。
- 紧急路由变更。 例如 DDoS 清洗服务,在攻击发生时由服务提供商临时公告你的前缀,这类安排依赖于事先完成授权——这一点我们也在DDoS 缓解指南中进行了介绍。
判断标准其实很简单:如果进行公告的 ASN 并不属于注册持有者本身,那么几乎可以确定需要 LOA。
LOA vs ROA vs IRR Route Object
LOA、ROA 和 IRR route object 都在说明谁可以公告某个前缀——但它们面对不同的受众、采用不同形式,并且作用于不同层面。 它们彼此互补,而不是相互替代。一个正确部署的前缀,通常需要三者保持一致。
LOA vs ROA vs IRR Route Object
项目
LOA
ROA
IRR route object
它是什么
授予路由公告权限的签署文件
RPKI 中经过加密签名的记录
Internet Routing Registry 数据库中的记录
面向对象
人员——上游开通和 NOC 工作人员
执行路由起源验证的路由器
自动生成过滤规则的系统
形式
人类可读、合同性质
加密签名、机器验证
数据库记录
由谁创建
注册持有者(或授权代表)
注册持有者,通过其 RIR 创建
对象的持有者或 maintainer
缺失或错误时的影响
上游拒绝配置该路由公告
公告可能被执行 RPKI 验证的网络判定为 RPKI-Invalid 并拒绝
使用 IRR 数据生成过滤规则的服务提供商可能过滤该公告
最清楚的理解方式是:LOA 决定你的上游工作人员是否愿意配置并接受这项公告;ROA 决定互联网上执行验证的路由器是否认为该起源 ASN 合法;route object 则影响自动化过滤系统是否允许该公告通过。三者都可能独立出现问题,而且每一种失败都会产生不同的症状——这也是为什么部署有时会以看似完全不同的方式卡住,取决于究竟缺少哪一项记录。
这三者之间的互动也越来越紧密。例如,Cloudflare 的自动生成 LOA 流程会依赖经过 RPKI 签名的 ROA 以及所有权验证检查——也就是说,加密记录用于支持这份人工文件,而不是取代它。关于 ROA 的具体机制,包括它如何授权某个特定的起源 ASN,以及配置错误时会发生什么,请参阅我们的RPKI 和 ROA指南。
谁可以合法签发 LOA?
只有地址空间的注册持有者——或者被授权代表该持有者行事的人——才有资格合法签发 LOA。 这一点必须非常准确地说明,因为现实中经常有人把相关概念混淆。
有三个概念值得明确区分:
- LOA 授权的是公告,并不转移所有权。 签署 LOA 只是授予对地址空间进行路由的许可。它不会让被授权方成为该地址空间的持有者,不会更改注册记录,也不会转移任何注册管理层面的权利。当授权终止时,该项公告权限也随之终止。
- 在整个租赁期间,注册信息仍然保留在持有者名下。 在租赁安排中,注册管理机构的记录会继续显示原持有者为注册方。这并不是租赁关系中的漏洞——这正是租赁模式本身的结构。租户的公告权来自所获得的授权,而不是来自注册信息的改变。
- 进行公告不等于持有地址空间。 一个网络公告某个前缀,意味着它正在作为起源网络发布该前缀,这反映的是它获得了授权。公告本身并不能证明所有权。这种区分在概念和实际操作上都非常重要,因为未经授权的公告本身正是路由劫持的定义之一。
对于接收公告的上游服务提供商来说,这些区别最终会转化成一个验证问题:签署人真的拥有他们所声称的授权权力吗?这就是为什么 LOA 通常需要使用持有者的公司抬头纸、公司资料必须与注册记录相符,并由身份和职位明确的人签署。任何无法追溯到注册持有者的文件,都不能算真正的授权——那只能算是一项单方面声明。
LOA 与租赁 IPv4:付款之前应该核实什么?
由于 LOA 位于路由上线流程的关键路径上,因此应该在付款之前确认其处理方式,而不是付款之后才发现问题。 这个失败模式在行业中非常常见:企业签署了租赁协议、配置好路由、通知了上游,然后才被要求提供一份租赁协议中从未提及、而出租方又迟迟无法出具的 LOA。在文件到达之前,地址已经付费,却无法使用。
以下事项应当提前确认:
- 付款前取得 LOA,或者取得书面的交付承诺。 最好直接拿到文件;如果做不到,也应在协议中明确规定,必须在一个确定且较短的时间内交付。如果出租方连这两者中的任何一种都不愿意承诺,那已经说明了后续合作关系可能会是什么样子。
- 确认 LOA 中列出了正确的前缀。 应当准确列出你实际租赁的地址块。LOA 如果覆盖了不同地址块或过大的范围,上游可能会提出质疑;如果覆盖范围小于你所需,也无法授权剩余部分。
- 确认 LOA 中列出了正确的 ASN。 必须是实际会成为起源网络的 ASN——根据你的部署方式,这可能是你自己的 ASN,也可能是上游的 ASN。错误的 ASN 是一份形式上有效的 LOA 仍然无法帮助部署上线的最常见原因之一。
- 核对有效期与租赁期限。 如果授权比租赁期限更早到期,就会在部署过程中产生重新签发 LOA 的依赖。
- 确认文件确实来自注册持有者。 公司抬头和企业资料应与注册记录一致,并由可以识别且确实有授权权限的人签署。
- 确认重新签发流程。 如果你更换上游、更换 ASN,或需要为第二家服务提供商增加一份 LOA,更新文件最快可以在多久内提供?实际部署会发生变化,而授权文件必须能够同步更新。
- 询问 LOA 如何与 ROA 和 route object 配合。 单独拥有 LOA 并不够——正如上面的比较所示,ROA 和 IRR 记录也必须保持一致。能够完整处理这三项内容的出租方,比只提供一份文件然后把其余事情全部交给你的出租方,更适合生产环境部署。
这些问题在签约之前提出几乎没有成本,但签约之后才提出往往代价高昂。综合来看,它们也是判断租赁质量非常可靠的信号:如果一个地址安排将路由授权明确视为具有交付期限的正式交付成果,那么它通常是按照生产环境需求设计的;反之,如果把授权当成事后再处理的细节,那么这个问题往往会在最糟糕的时候暴露出来。
常见 LOA 问题
大多数 LOA 问题并不是围绕授权本身产生争议,而是文件交付太迟、内容错误或已经过期。 常见情况包括:
- 交付延迟。 这是最常见、也是成本最高的问题。只要文件一天没有到位,地址空间就一天无法正常公告,无论其他部分准备得多么充分。
- ASN 错误。 LOA 授权了一个与实际发起公告不同的 ASN——通常是因为文件起草之后部署方案发生变化,或出租方误解了租户的上游安排。
- 前缀错误或不够准确。 文件列出的地址块不正确、范围比协议约定更大,或者描述过于模糊,以至于上游不愿据此配置路由。
- 授权已经过期。 有效期已经结束,通常是在服务提供商重新审核文件,或租赁期内新增上游时才被发现。
- 签署人没有授权或无法验证。 文件由上游无法确认其权限的人签署,或者文件本身无法明确关联到注册持有者。
- 协议中完全没有规定 LOA。 租赁协议完全没有提到 LOA 的签发,因此交付时间和责任都没有定义——而交付延迟问题通常就是从这里开始。
这六类问题都可以在协议阶段提前避免,这也是为什么上面的核实清单比事后进行任何故障排查都更加重要。
实用检查清单
- 在签署协议之前,确认协议明确要求持有者签发 LOA,并规定具体交付时间。
- 在付款之前取得 LOA,或者至少取得书面的交付保证。
- 核实准确的前缀与实际租赁或取得的地址块完全一致。
- 核实 ASN 与实际将作为起源网络进行公告的 ASN 完全一致。
- 检查有效期是否覆盖整个租赁或部署周期。
- 确认文件使用注册持有者的正式公司抬头,企业资料与注册记录一致,并有可以识别的授权签署人。
- 按照上游要求的格式提交——PDF 是最稳妥的默认选择;图片格式经常会被拒绝。
- 确认如果上游、ASN 或授权范围发生变化,重新签发的流程以及处理时间。
- 确保 LOA、ROA 和 IRR route object 保持一致,让三种授权记录不会互相冲突。
- 保存一份副本——增加其他服务提供商、进行审计或未来修改部署时,都可能再次需要。
来自 i.lease 的实用说明
LOA 是一份很小的文件,但其运营影响远远超过文件本身的复杂程度。它在技术上并不复杂,只要有权签署的人愿意配合,通常几分钟就可以制作出来,但它却是租赁或新取得的地址块已经付费、却迟迟无法投入使用的最常见原因之一。问题几乎从来不是真正存在授权争议,而是协议签署之前没有人明确规定:由谁签发这份文件、多久内必须交付,以及文件中应该写些什么。
正因如此,LOA 的处理方式其实可以作为判断整体地址资源安排质量的一个很好指标。如果出租方能够快速提供正确的 LOA,一次就准确写明正确的 ASN 和前缀,不需要来回修改三次;当你更换上游时能够迅速重新签发;并且同时保持 ROA 与 route object 一致,那么它实际上正在展示生产环境路由所需要的运营纪律。相反,如果出租方认为 LOA 只是以后再处理的文书工作,那么整个合作关系中的其他环节很可能也会以类似方式处理。文件本身并不复杂,真正重要的是背后的协调能力,而正是这种协调,才能把一段地址空间变成真正可运行的网络基础设施。无论你是租赁还是直接取得地址空间,都应该把路由授权视为一个具有明确期限的正式交付成果,而不是默认它自然会出现。
总结
授权书(LOA)是注册持有者以书面形式授予某个指定方,通过指定 ASN 公告特定前缀的许可。上游服务提供商之所以要求 LOA,是因为仅凭注册数据无法确认公告方是否真正获得授权,而接受未经授权的公告就意味着参与路由劫持。文件会列出持有者、被授权方及 ASN、具体前缀和有效期,并由有权授予该项授权的人签署——它正处于“拥有地址空间”与“能够真正将其路由上线”之间的关键路径上。
最值得记住的区别,是 LOA 能做什么,以及不能做什么。它授权路由公告;它不会转移所有权、不会更改注册信息,也不会授予任何注册管理层面的权利。在租赁关系中,地址空间仍然注册在持有者名下,而租户的公告权来自持有者授予的授权——这也正是为什么 LOA 必须存在,而且必须由持有者出具。再加上由路由器验证的 ROA,以及供过滤系统查询的 route object,LOA 才共同组成将合同权利转化为被网络接受的路由公告所需要的完整记录体系。在部署之前让三者保持一致,在付款之前核实 LOA 的具体内容,才能真正把你已经安排好的地址空间变成可以实际使用的基础设施。
相关阅读
什么是 BGP 劫持?路由劫持如何发生、著名事件以及网络如何防范
RPKI 与 ROA 详解:路由起源授权如何保护你的 IPv4 前缀
什么是 BGP?边界网关协议如何让 IP 地址成为可访问的服务
- 它由持有者签发,而不是由公告方自行签发。 有权授予许可的一方,是地址空间的持有者。租户不能自己给自己写一份 LOA。
- 它必须具有明确的针对性。 文件需要列出具体的前缀以及具体的 ASN。仅仅说明某方“信誉良好”并不能构成 LOA;文件中的内容必须与实际将要公告的内容完全匹配。
为什么上游服务提供商要求 LOA?
服务提供商之所以要求 LOA,是因为接受一个未经授权方发出的路由公告,正是前缀劫持发生的方式——而任何负责任的网络都不希望成为传播这种错误公告的一方。
正如我们在BGP 如何运作的指南中所解释的,路由系统在很大程度上是基于信任接受公告的,而各个网络之所以会过滤接收到的路由,正是因为虚假公告可能将属于其他人的流量重定向。这个风险并不是理论上的:未经授权的路由公告正是我们在BGP 劫持指南中所介绍事件的核心机制。如果上游服务提供商在未核实授权的情况下接受公告,那么它就会无意间成为后续事件的参与者。
LOA 填补的正是一个具体的信息缺口。注册记录可以确认地址持有者,但在租赁情况下,注册记录仍然显示原持有者,而实际进行公告的是另一方——因此,上游服务提供商无法仅通过数据库查询来验证租户。LOA 补上了缺失的这一环:由注册记录中可识别的那一方,以书面形式确认实际进行公告的一方已经获得许可。
在实际部署中,这意味着 LOA 位于整个上线流程的关键路径上。路由器已经配置、租赁协议已经签署、地址块已经分配——这些都无法真正带来可达性,直到上游服务提供商接受这条路由公告,而在没有 LOA 的情况下,上游通常不会接受。
LOA 包含哪些内容?
LOA 会明确授权方、被授权方及其 ASN、具体前缀,以及有权授予该项授权人员的签名。 各家服务提供商通常要求的标准组成部分包括:
- 授权方。 即地址空间的注册持有者,其公司名称和相关资料应与注册记录一致。
- 被授权方和 ASN。 文件需要说明谁被允许公告该地址空间,以及最关键的——将通过哪个自治系统编号进行公告。Cloudflare 的文档明确要求 LOA 同时写明被授权的前缀和公告所使用的 ASN——ASN 并不是可有可无的附加信息。
- 准确的前缀。 必须精确列出受授权覆盖的地址块(例如某个具体的 /24)。任何超出 LOA 所列范围的公告,都不属于该授权范围。
- 有效期。 授权的持续时间。对于租赁地址空间,其有效期应与租赁期限保持一致。
- 授权签署人。 包括姓名、职位以及有权代表持有者签署文件的人员签名,并附上联系方式,以便上游服务提供商在有需要时进行核实。
- 公司抬头和文件格式。 LOA 通常应以持有者公司的正式抬头纸制作。Cloudflare 指出,Transit 服务提供商可能会拒绝以图片格式提交的 LOA,而要求使用 PDF;数字签名通常可以接受,但签署人必须能够被清楚识别。
这些要求并不是毫无意义的行政装饰。公司抬头、与注册记录一致的企业资料,以及可识别的授权签署人,正是接收方用于确认文件真实性,以及签署人确实有权授予所声称授权的依据。
什么时候需要 LOA?
只要将由注册持有者以外的一方公告地址空间,通常都需要 LOA——这涵盖了绝大多数 IPv4 租赁、BYOIP 和由服务提供商代为公告的情况。 常见场景包括:
- 通过自己的 ASN 公告租赁的 IPv4。 这是最典型的情况:你租赁了一个地址块,并自行对外公告,因此你的上游需要看到持有者提供的授权。关于这个更完整的租赁流程,可以参考我们的IPv4 租赁指南以及IP 地址租赁如何运作的说明。
- 由服务提供商代表你公告地址空间。 当你的托管服务商、数据中心或平台通过其 ASN 公告你的前缀时,它需要获得你的授权——而它的上游同样需要看到这一授权。
- BYOIP 接入。 将自有 IP 地址空间(BYOIP)带入云平台或边缘平台时,需要授权该平台公告你的前缀,Cloudflare 的要求就是一个典型例子。
- 紧急路由变更。 例如 DDoS 清洗服务,在攻击发生时由服务提供商临时公告你的前缀,这类安排依赖于事先完成授权——这一点我们也在DDoS 缓解指南中进行了介绍。
判断标准其实很简单:如果进行公告的 ASN 并不属于注册持有者本身,那么几乎可以确定需要 LOA。
LOA vs ROA vs IRR Route Object
LOA、ROA 和 IRR route object 都在说明谁可以公告某个前缀——但它们面对不同的受众、采用不同形式,并且作用于不同层面。 它们彼此互补,而不是相互替代。一个正确部署的前缀,通常需要三者保持一致。
LOA vs ROA vs IRR Route Object
项目
LOA
ROA
IRR route object
它是什么
授予路由公告权限的签署文件
RPKI 中经过加密签名的记录
Internet Routing Registry 数据库中的记录
面向对象
人员——上游开通和 NOC 工作人员
执行路由起源验证的路由器
自动生成过滤规则的系统
形式
人类可读、合同性质
加密签名、机器验证
数据库记录
由谁创建
注册持有者(或授权代表)
注册持有者,通过其 RIR 创建
对象的持有者或 maintainer
缺失或错误时的影响
上游拒绝配置该路由公告
公告可能被执行 RPKI 验证的网络判定为 RPKI-Invalid 并拒绝
使用 IRR 数据生成过滤规则的服务提供商可能过滤该公告
最清楚的理解方式是:LOA 决定你的上游工作人员是否愿意配置并接受这项公告;ROA 决定互联网上执行验证的路由器是否认为该起源 ASN 合法;route object 则影响自动化过滤系统是否允许该公告通过。三者都可能独立出现问题,而且每一种失败都会产生不同的症状——这也是为什么部署有时会以看似完全不同的方式卡住,取决于究竟缺少哪一项记录。
这三者之间的互动也越来越紧密。例如,Cloudflare 的自动生成 LOA 流程会依赖经过 RPKI 签名的 ROA 以及所有权验证检查——也就是说,加密记录用于支持这份人工文件,而不是取代它。关于 ROA 的具体机制,包括它如何授权某个特定的起源 ASN,以及配置错误时会发生什么,请参阅我们的RPKI 和 ROA指南。
谁可以合法签发 LOA?
只有地址空间的注册持有者——或者被授权代表该持有者行事的人——才有资格合法签发 LOA。 这一点必须非常准确地说明,因为现实中经常有人把相关概念混淆。
有三个概念值得明确区分:
- LOA 授权的是公告,并不转移所有权。 签署 LOA 只是授予对地址空间进行路由的许可。它不会让被授权方成为该地址空间的持有者,不会更改注册记录,也不会转移任何注册管理层面的权利。当授权终止时,该项公告权限也随之终止。
- 在整个租赁期间,注册信息仍然保留在持有者名下。 在租赁安排中,注册管理机构的记录会继续显示原持有者为注册方。这并不是租赁关系中的漏洞——这正是租赁模式本身的结构。租户的公告权来自所获得的授权,而不是来自注册信息的改变。
- 进行公告不等于持有地址空间。 一个网络公告某个前缀,意味着它正在作为起源网络发布该前缀,这反映的是它获得了授权。公告本身并不能证明所有权。这种区分在概念和实际操作上都非常重要,因为未经授权的公告本身正是路由劫持的定义之一。
对于接收公告的上游服务提供商来说,这些区别最终会转化成一个验证问题:签署人真的拥有他们所声称的授权权力吗?这就是为什么 LOA 通常需要使用持有者的公司抬头纸、公司资料必须与注册记录相符,并由身份和职位明确的人签署。任何无法追溯到注册持有者的文件,都不能算真正的授权——那只能算是一项单方面声明。
LOA 与租赁 IPv4:付款之前应该核实什么?
由于 LOA 位于路由上线流程的关键路径上,因此应该在付款之前确认其处理方式,而不是付款之后才发现问题。 这个失败模式在行业中非常常见:企业签署了租赁协议、配置好路由、通知了上游,然后才被要求提供一份租赁协议中从未提及、而出租方又迟迟无法出具的 LOA。在文件到达之前,地址已经付费,却无法使用。
以下事项应当提前确认:
- 付款前取得 LOA,或者取得书面的交付承诺。 最好直接拿到文件;如果做不到,也应在协议中明确规定,必须在一个确定且较短的时间内交付。如果出租方连这两者中的任何一种都不愿意承诺,那已经说明了后续合作关系可能会是什么样子。
- 确认 LOA 中列出了正确的前缀。 应当准确列出你实际租赁的地址块。LOA 如果覆盖了不同地址块或过大的范围,上游可能会提出质疑;如果覆盖范围小于你所需,也无法授权剩余部分。
- 确认 LOA 中列出了正确的 ASN。 必须是实际会成为起源网络的 ASN——根据你的部署方式,这可能是你自己的 ASN,也可能是上游的 ASN。错误的 ASN 是一份形式上有效的 LOA 仍然无法帮助部署上线的最常见原因之一。
- 核对有效期与租赁期限。 如果授权比租赁期限更早到期,就会在部署过程中产生重新签发 LOA 的依赖。
- 确认文件确实来自注册持有者。 公司抬头和企业资料应与注册记录一致,并由可以识别且确实有授权权限的人签署。
- 确认重新签发流程。 如果你更换上游、更换 ASN,或需要为第二家服务提供商增加一份 LOA,更新文件最快可以在多久内提供?实际部署会发生变化,而授权文件必须能够同步更新。
- 询问 LOA 如何与 ROA 和 route object 配合。 单独拥有 LOA 并不够——正如上面的比较所示,ROA 和 IRR 记录也必须保持一致。能够完整处理这三项内容的出租方,比只提供一份文件然后把其余事情全部交给你的出租方,更适合生产环境部署。
这些问题在签约之前提出几乎没有成本,但签约之后才提出往往代价高昂。综合来看,它们也是判断租赁质量非常可靠的信号:如果一个地址安排将路由授权明确视为具有交付期限的正式交付成果,那么它通常是按照生产环境需求设计的;反之,如果把授权当成事后再处理的细节,那么这个问题往往会在最糟糕的时候暴露出来。
常见 LOA 问题
大多数 LOA 问题并不是围绕授权本身产生争议,而是文件交付太迟、内容错误或已经过期。 常见情况包括:
- 交付延迟。 这是最常见、也是成本最高的问题。只要文件一天没有到位,地址空间就一天无法正常公告,无论其他部分准备得多么充分。
- ASN 错误。 LOA 授权了一个与实际发起公告不同的 ASN——通常是因为文件起草之后部署方案发生变化,或出租方误解了租户的上游安排。
- 前缀错误或不够准确。 文件列出的地址块不正确、范围比协议约定更大,或者描述过于模糊,以至于上游不愿据此配置路由。
- 授权已经过期。 有效期已经结束,通常是在服务提供商重新审核文件,或租赁期内新增上游时才被发现。
- 签署人没有授权或无法验证。 文件由上游无法确认其权限的人签署,或者文件本身无法明确关联到注册持有者。
- 协议中完全没有规定 LOA。 租赁协议完全没有提到 LOA 的签发,因此交付时间和责任都没有定义——而交付延迟问题通常就是从这里开始。
这六类问题都可以在协议阶段提前避免,这也是为什么上面的核实清单比事后进行任何故障排查都更加重要。
实用检查清单
- 在签署协议之前,确认协议明确要求持有者签发 LOA,并规定具体交付时间。
- 在付款之前取得 LOA,或者至少取得书面的交付保证。
- 核实准确的前缀与实际租赁或取得的地址块完全一致。
- 核实 ASN 与实际将作为起源网络进行公告的 ASN 完全一致。
- 检查有效期是否覆盖整个租赁或部署周期。
- 确认文件使用注册持有者的正式公司抬头,企业资料与注册记录一致,并有可以识别的授权签署人。
- 按照上游要求的格式提交——PDF 是最稳妥的默认选择;图片格式经常会被拒绝。
- 确认如果上游、ASN 或授权范围发生变化,重新签发的流程以及处理时间。
- 确保 LOA、ROA 和 IRR route object 保持一致,让三种授权记录不会互相冲突。
- 保存一份副本——增加其他服务提供商、进行审计或未来修改部署时,都可能再次需要。
来自 i.lease 的实用说明
LOA 是一份很小的文件,但其运营影响远远超过文件本身的复杂程度。它在技术上并不复杂,只要有权签署的人愿意配合,通常几分钟就可以制作出来,但它却是租赁或新取得的地址块已经付费、却迟迟无法投入使用的最常见原因之一。问题几乎从来不是真正存在授权争议,而是协议签署之前没有人明确规定:由谁签发这份文件、多久内必须交付,以及文件中应该写些什么。
正因如此,LOA 的处理方式其实可以作为判断整体地址资源安排质量的一个很好指标。如果出租方能够快速提供正确的 LOA,一次就准确写明正确的 ASN 和前缀,不需要来回修改三次;当你更换上游时能够迅速重新签发;并且同时保持 ROA 与 route object 一致,那么它实际上正在展示生产环境路由所需要的运营纪律。相反,如果出租方认为 LOA 只是以后再处理的文书工作,那么整个合作关系中的其他环节很可能也会以类似方式处理。文件本身并不复杂,真正重要的是背后的协调能力,而正是这种协调,才能把一段地址空间变成真正可运行的网络基础设施。无论你是租赁还是直接取得地址空间,都应该把路由授权视为一个具有明确期限的正式交付成果,而不是默认它自然会出现。
总结
授权书(LOA)是注册持有者以书面形式授予某个指定方,通过指定 ASN 公告特定前缀的许可。上游服务提供商之所以要求 LOA,是因为仅凭注册数据无法确认公告方是否真正获得授权,而接受未经授权的公告就意味着参与路由劫持。文件会列出持有者、被授权方及 ASN、具体前缀和有效期,并由有权授予该项授权的人签署——它正处于“拥有地址空间”与“能够真正将其路由上线”之间的关键路径上。
最值得记住的区别,是 LOA 能做什么,以及不能做什么。它授权路由公告;它不会转移所有权、不会更改注册信息,也不会授予任何注册管理层面的权利。在租赁关系中,地址空间仍然注册在持有者名下,而租户的公告权来自持有者授予的授权——这也正是为什么 LOA 必须存在,而且必须由持有者出具。再加上由路由器验证的 ROA,以及供过滤系统查询的 route object,LOA 才共同组成将合同权利转化为被网络接受的路由公告所需要的完整记录体系。在部署之前让三者保持一致,在付款之前核实 LOA 的具体内容,才能真正把你已经安排好的地址空间变成可以实际使用的基础设施。
相关阅读
什么是 BGP 劫持?路由劫持如何发生、著名事件以及网络如何防范
RPKI 与 ROA 详解:路由起源授权如何保护你的 IPv4 前缀
什么是 BGP?边界网关协议如何让 IP 地址成为可访问的服务
- 授权方。 即地址空间的注册持有者,其公司名称和相关资料应与注册记录一致。
- 被授权方和 ASN。 文件需要说明谁被允许公告该地址空间,以及最关键的——将通过哪个自治系统编号进行公告。Cloudflare 的文档明确要求 LOA 同时写明被授权的前缀和公告所使用的 ASN——ASN 并不是可有可无的附加信息。
- 准确的前缀。 必须精确列出受授权覆盖的地址块(例如某个具体的 /24)。任何超出 LOA 所列范围的公告,都不属于该授权范围。
- 有效期。 授权的持续时间。对于租赁地址空间,其有效期应与租赁期限保持一致。
- 授权签署人。 包括姓名、职位以及有权代表持有者签署文件的人员签名,并附上联系方式,以便上游服务提供商在有需要时进行核实。
- 公司抬头和文件格式。 LOA 通常应以持有者公司的正式抬头纸制作。Cloudflare 指出,Transit 服务提供商可能会拒绝以图片格式提交的 LOA,而要求使用 PDF;数字签名通常可以接受,但签署人必须能够被清楚识别。
这些要求并不是毫无意义的行政装饰。公司抬头、与注册记录一致的企业资料,以及可识别的授权签署人,正是接收方用于确认文件真实性,以及签署人确实有权授予所声称授权的依据。
什么时候需要 LOA?
只要将由注册持有者以外的一方公告地址空间,通常都需要 LOA——这涵盖了绝大多数 IPv4 租赁、BYOIP 和由服务提供商代为公告的情况。 常见场景包括:
- 通过自己的 ASN 公告租赁的 IPv4。 这是最典型的情况:你租赁了一个地址块,并自行对外公告,因此你的上游需要看到持有者提供的授权。关于这个更完整的租赁流程,可以参考我们的IPv4 租赁指南以及IP 地址租赁如何运作的说明。
- 由服务提供商代表你公告地址空间。 当你的托管服务商、数据中心或平台通过其 ASN 公告你的前缀时,它需要获得你的授权——而它的上游同样需要看到这一授权。
- BYOIP 接入。 将自有 IP 地址空间(BYOIP)带入云平台或边缘平台时,需要授权该平台公告你的前缀,Cloudflare 的要求就是一个典型例子。
- 紧急路由变更。 例如 DDoS 清洗服务,在攻击发生时由服务提供商临时公告你的前缀,这类安排依赖于事先完成授权——这一点我们也在DDoS 缓解指南中进行了介绍。
判断标准其实很简单:如果进行公告的 ASN 并不属于注册持有者本身,那么几乎可以确定需要 LOA。
LOA vs ROA vs IRR Route Object
LOA、ROA 和 IRR route object 都在说明谁可以公告某个前缀——但它们面对不同的受众、采用不同形式,并且作用于不同层面。 它们彼此互补,而不是相互替代。一个正确部署的前缀,通常需要三者保持一致。
LOA vs ROA vs IRR Route Object
项目
LOA
ROA
IRR route object
它是什么
授予路由公告权限的签署文件
RPKI 中经过加密签名的记录
Internet Routing Registry 数据库中的记录
面向对象
人员——上游开通和 NOC 工作人员
执行路由起源验证的路由器
自动生成过滤规则的系统
形式
人类可读、合同性质
加密签名、机器验证
数据库记录
由谁创建
注册持有者(或授权代表)
注册持有者,通过其 RIR 创建
对象的持有者或 maintainer
缺失或错误时的影响
上游拒绝配置该路由公告
公告可能被执行 RPKI 验证的网络判定为 RPKI-Invalid 并拒绝
使用 IRR 数据生成过滤规则的服务提供商可能过滤该公告
最清楚的理解方式是:LOA 决定你的上游工作人员是否愿意配置并接受这项公告;ROA 决定互联网上执行验证的路由器是否认为该起源 ASN 合法;route object 则影响自动化过滤系统是否允许该公告通过。三者都可能独立出现问题,而且每一种失败都会产生不同的症状——这也是为什么部署有时会以看似完全不同的方式卡住,取决于究竟缺少哪一项记录。
这三者之间的互动也越来越紧密。例如,Cloudflare 的自动生成 LOA 流程会依赖经过 RPKI 签名的 ROA 以及所有权验证检查——也就是说,加密记录用于支持这份人工文件,而不是取代它。关于 ROA 的具体机制,包括它如何授权某个特定的起源 ASN,以及配置错误时会发生什么,请参阅我们的RPKI 和 ROA指南。
谁可以合法签发 LOA?
只有地址空间的注册持有者——或者被授权代表该持有者行事的人——才有资格合法签发 LOA。 这一点必须非常准确地说明,因为现实中经常有人把相关概念混淆。
有三个概念值得明确区分:
- LOA 授权的是公告,并不转移所有权。 签署 LOA 只是授予对地址空间进行路由的许可。它不会让被授权方成为该地址空间的持有者,不会更改注册记录,也不会转移任何注册管理层面的权利。当授权终止时,该项公告权限也随之终止。
- 在整个租赁期间,注册信息仍然保留在持有者名下。 在租赁安排中,注册管理机构的记录会继续显示原持有者为注册方。这并不是租赁关系中的漏洞——这正是租赁模式本身的结构。租户的公告权来自所获得的授权,而不是来自注册信息的改变。
- 进行公告不等于持有地址空间。 一个网络公告某个前缀,意味着它正在作为起源网络发布该前缀,这反映的是它获得了授权。公告本身并不能证明所有权。这种区分在概念和实际操作上都非常重要,因为未经授权的公告本身正是路由劫持的定义之一。
对于接收公告的上游服务提供商来说,这些区别最终会转化成一个验证问题:签署人真的拥有他们所声称的授权权力吗?这就是为什么 LOA 通常需要使用持有者的公司抬头纸、公司资料必须与注册记录相符,并由身份和职位明确的人签署。任何无法追溯到注册持有者的文件,都不能算真正的授权——那只能算是一项单方面声明。
LOA 与租赁 IPv4:付款之前应该核实什么?
由于 LOA 位于路由上线流程的关键路径上,因此应该在付款之前确认其处理方式,而不是付款之后才发现问题。 这个失败模式在行业中非常常见:企业签署了租赁协议、配置好路由、通知了上游,然后才被要求提供一份租赁协议中从未提及、而出租方又迟迟无法出具的 LOA。在文件到达之前,地址已经付费,却无法使用。
以下事项应当提前确认:
- 付款前取得 LOA,或者取得书面的交付承诺。 最好直接拿到文件;如果做不到,也应在协议中明确规定,必须在一个确定且较短的时间内交付。如果出租方连这两者中的任何一种都不愿意承诺,那已经说明了后续合作关系可能会是什么样子。
- 确认 LOA 中列出了正确的前缀。 应当准确列出你实际租赁的地址块。LOA 如果覆盖了不同地址块或过大的范围,上游可能会提出质疑;如果覆盖范围小于你所需,也无法授权剩余部分。
- 确认 LOA 中列出了正确的 ASN。 必须是实际会成为起源网络的 ASN——根据你的部署方式,这可能是你自己的 ASN,也可能是上游的 ASN。错误的 ASN 是一份形式上有效的 LOA 仍然无法帮助部署上线的最常见原因之一。
- 核对有效期与租赁期限。 如果授权比租赁期限更早到期,就会在部署过程中产生重新签发 LOA 的依赖。
- 确认文件确实来自注册持有者。 公司抬头和企业资料应与注册记录一致,并由可以识别且确实有授权权限的人签署。
- 确认重新签发流程。 如果你更换上游、更换 ASN,或需要为第二家服务提供商增加一份 LOA,更新文件最快可以在多久内提供?实际部署会发生变化,而授权文件必须能够同步更新。
- 询问 LOA 如何与 ROA 和 route object 配合。 单独拥有 LOA 并不够——正如上面的比较所示,ROA 和 IRR 记录也必须保持一致。能够完整处理这三项内容的出租方,比只提供一份文件然后把其余事情全部交给你的出租方,更适合生产环境部署。
这些问题在签约之前提出几乎没有成本,但签约之后才提出往往代价高昂。综合来看,它们也是判断租赁质量非常可靠的信号:如果一个地址安排将路由授权明确视为具有交付期限的正式交付成果,那么它通常是按照生产环境需求设计的;反之,如果把授权当成事后再处理的细节,那么这个问题往往会在最糟糕的时候暴露出来。
常见 LOA 问题
大多数 LOA 问题并不是围绕授权本身产生争议,而是文件交付太迟、内容错误或已经过期。 常见情况包括:
- 交付延迟。 这是最常见、也是成本最高的问题。只要文件一天没有到位,地址空间就一天无法正常公告,无论其他部分准备得多么充分。
- ASN 错误。 LOA 授权了一个与实际发起公告不同的 ASN——通常是因为文件起草之后部署方案发生变化,或出租方误解了租户的上游安排。
- 前缀错误或不够准确。 文件列出的地址块不正确、范围比协议约定更大,或者描述过于模糊,以至于上游不愿据此配置路由。
- 授权已经过期。 有效期已经结束,通常是在服务提供商重新审核文件,或租赁期内新增上游时才被发现。
- 签署人没有授权或无法验证。 文件由上游无法确认其权限的人签署,或者文件本身无法明确关联到注册持有者。
- 协议中完全没有规定 LOA。 租赁协议完全没有提到 LOA 的签发,因此交付时间和责任都没有定义——而交付延迟问题通常就是从这里开始。
这六类问题都可以在协议阶段提前避免,这也是为什么上面的核实清单比事后进行任何故障排查都更加重要。
实用检查清单
- 在签署协议之前,确认协议明确要求持有者签发 LOA,并规定具体交付时间。
- 在付款之前取得 LOA,或者至少取得书面的交付保证。
- 核实准确的前缀与实际租赁或取得的地址块完全一致。
- 核实 ASN 与实际将作为起源网络进行公告的 ASN 完全一致。
- 检查有效期是否覆盖整个租赁或部署周期。
- 确认文件使用注册持有者的正式公司抬头,企业资料与注册记录一致,并有可以识别的授权签署人。
- 按照上游要求的格式提交——PDF 是最稳妥的默认选择;图片格式经常会被拒绝。
- 确认如果上游、ASN 或授权范围发生变化,重新签发的流程以及处理时间。
- 确保 LOA、ROA 和 IRR route object 保持一致,让三种授权记录不会互相冲突。
- 保存一份副本——增加其他服务提供商、进行审计或未来修改部署时,都可能再次需要。
来自 i.lease 的实用说明
LOA 是一份很小的文件,但其运营影响远远超过文件本身的复杂程度。它在技术上并不复杂,只要有权签署的人愿意配合,通常几分钟就可以制作出来,但它却是租赁或新取得的地址块已经付费、却迟迟无法投入使用的最常见原因之一。问题几乎从来不是真正存在授权争议,而是协议签署之前没有人明确规定:由谁签发这份文件、多久内必须交付,以及文件中应该写些什么。
正因如此,LOA 的处理方式其实可以作为判断整体地址资源安排质量的一个很好指标。如果出租方能够快速提供正确的 LOA,一次就准确写明正确的 ASN 和前缀,不需要来回修改三次;当你更换上游时能够迅速重新签发;并且同时保持 ROA 与 route object 一致,那么它实际上正在展示生产环境路由所需要的运营纪律。相反,如果出租方认为 LOA 只是以后再处理的文书工作,那么整个合作关系中的其他环节很可能也会以类似方式处理。文件本身并不复杂,真正重要的是背后的协调能力,而正是这种协调,才能把一段地址空间变成真正可运行的网络基础设施。无论你是租赁还是直接取得地址空间,都应该把路由授权视为一个具有明确期限的正式交付成果,而不是默认它自然会出现。
总结
授权书(LOA)是注册持有者以书面形式授予某个指定方,通过指定 ASN 公告特定前缀的许可。上游服务提供商之所以要求 LOA,是因为仅凭注册数据无法确认公告方是否真正获得授权,而接受未经授权的公告就意味着参与路由劫持。文件会列出持有者、被授权方及 ASN、具体前缀和有效期,并由有权授予该项授权的人签署——它正处于“拥有地址空间”与“能够真正将其路由上线”之间的关键路径上。
最值得记住的区别,是 LOA 能做什么,以及不能做什么。它授权路由公告;它不会转移所有权、不会更改注册信息,也不会授予任何注册管理层面的权利。在租赁关系中,地址空间仍然注册在持有者名下,而租户的公告权来自持有者授予的授权——这也正是为什么 LOA 必须存在,而且必须由持有者出具。再加上由路由器验证的 ROA,以及供过滤系统查询的 route object,LOA 才共同组成将合同权利转化为被网络接受的路由公告所需要的完整记录体系。在部署之前让三者保持一致,在付款之前核实 LOA 的具体内容,才能真正把你已经安排好的地址空间变成可以实际使用的基础设施。
相关阅读
什么是 BGP 劫持?路由劫持如何发生、著名事件以及网络如何防范
RPKI 与 ROA 详解:路由起源授权如何保护你的 IPv4 前缀
什么是 BGP?边界网关协议如何让 IP 地址成为可访问的服务
- 它由持有者签发,而不是由公告方自行签发。 有权授予许可的一方,是地址空间的持有者。租户不能自己给自己写一份 LOA。
- 它必须具有明确的针对性。 文件需要列出具体的前缀以及具体的 ASN。仅仅说明某方“信誉良好”并不能构成 LOA;文件中的内容必须与实际将要公告的内容完全匹配。
为什么上游服务提供商要求 LOA?
服务提供商之所以要求 LOA,是因为接受一个未经授权方发出的路由公告,正是前缀劫持发生的方式——而任何负责任的网络都不希望成为传播这种错误公告的一方。
正如我们在BGP 如何运作的指南中所解释的,路由系统在很大程度上是基于信任接受公告的,而各个网络之所以会过滤接收到的路由,正是因为虚假公告可能将属于其他人的流量重定向。这个风险并不是理论上的:未经授权的路由公告正是我们在BGP 劫持指南中所介绍事件的核心机制。如果上游服务提供商在未核实授权的情况下接受公告,那么它就会无意间成为后续事件的参与者。
LOA 填补的正是一个具体的信息缺口。注册记录可以确认地址持有者,但在租赁情况下,注册记录仍然显示原持有者,而实际进行公告的是另一方——因此,上游服务提供商无法仅通过数据库查询来验证租户。LOA 补上了缺失的这一环:由注册记录中可识别的那一方,以书面形式确认实际进行公告的一方已经获得许可。
在实际部署中,这意味着 LOA 位于整个上线流程的关键路径上。路由器已经配置、租赁协议已经签署、地址块已经分配——这些都无法真正带来可达性,直到上游服务提供商接受这条路由公告,而在没有 LOA 的情况下,上游通常不会接受。
LOA 包含哪些内容?
LOA 会明确授权方、被授权方及其 ASN、具体前缀,以及有权授予该项授权人员的签名。 各家服务提供商通常要求的标准组成部分包括:
- 授权方。 即地址空间的注册持有者,其公司名称和相关资料应与注册记录一致。
- 被授权方和 ASN。 文件需要说明谁被允许公告该地址空间,以及最关键的——将通过哪个自治系统编号进行公告。Cloudflare 的文档明确要求 LOA 同时写明被授权的前缀和公告所使用的 ASN——ASN 并不是可有可无的附加信息。
- 准确的前缀。 必须精确列出受授权覆盖的地址块(例如某个具体的 /24)。任何超出 LOA 所列范围的公告,都不属于该授权范围。
- 有效期。 授权的持续时间。对于租赁地址空间,其有效期应与租赁期限保持一致。
- 授权签署人。 包括姓名、职位以及有权代表持有者签署文件的人员签名,并附上联系方式,以便上游服务提供商在有需要时进行核实。
- 公司抬头和文件格式。 LOA 通常应以持有者公司的正式抬头纸制作。Cloudflare 指出,Transit 服务提供商可能会拒绝以图片格式提交的 LOA,而要求使用 PDF;数字签名通常可以接受,但签署人必须能够被清楚识别。
这些要求并不是毫无意义的行政装饰。公司抬头、与注册记录一致的企业资料,以及可识别的授权签署人,正是接收方用于确认文件真实性,以及签署人确实有权授予所声称授权的依据。
什么时候需要 LOA?
只要将由注册持有者以外的一方公告地址空间,通常都需要 LOA——这涵盖了绝大多数 IPv4 租赁、BYOIP 和由服务提供商代为公告的情况。 常见场景包括:
- 通过自己的 ASN 公告租赁的 IPv4。 这是最典型的情况:你租赁了一个地址块,并自行对外公告,因此你的上游需要看到持有者提供的授权。关于这个更完整的租赁流程,可以参考我们的IPv4 租赁指南以及IP 地址租赁如何运作的说明。
- 由服务提供商代表你公告地址空间。 当你的托管服务商、数据中心或平台通过其 ASN 公告你的前缀时,它需要获得你的授权——而它的上游同样需要看到这一授权。
- BYOIP 接入。 将自有 IP 地址空间(BYOIP)带入云平台或边缘平台时,需要授权该平台公告你的前缀,Cloudflare 的要求就是一个典型例子。
- 紧急路由变更。 例如 DDoS 清洗服务,在攻击发生时由服务提供商临时公告你的前缀,这类安排依赖于事先完成授权——这一点我们也在DDoS 缓解指南中进行了介绍。
判断标准其实很简单:如果进行公告的 ASN 并不属于注册持有者本身,那么几乎可以确定需要 LOA。
LOA vs ROA vs IRR Route Object
LOA、ROA 和 IRR route object 都在说明谁可以公告某个前缀——但它们面对不同的受众、采用不同形式,并且作用于不同层面。 它们彼此互补,而不是相互替代。一个正确部署的前缀,通常需要三者保持一致。
LOA vs ROA vs IRR Route Object
项目
LOA
ROA
IRR route object
它是什么
授予路由公告权限的签署文件
RPKI 中经过加密签名的记录
Internet Routing Registry 数据库中的记录
面向对象
人员——上游开通和 NOC 工作人员
执行路由起源验证的路由器
自动生成过滤规则的系统
形式
人类可读、合同性质
加密签名、机器验证
数据库记录
由谁创建
注册持有者(或授权代表)
注册持有者,通过其 RIR 创建
对象的持有者或 maintainer
缺失或错误时的影响
上游拒绝配置该路由公告
公告可能被执行 RPKI 验证的网络判定为 RPKI-Invalid 并拒绝
使用 IRR 数据生成过滤规则的服务提供商可能过滤该公告
最清楚的理解方式是:LOA 决定你的上游工作人员是否愿意配置并接受这项公告;ROA 决定互联网上执行验证的路由器是否认为该起源 ASN 合法;route object 则影响自动化过滤系统是否允许该公告通过。三者都可能独立出现问题,而且每一种失败都会产生不同的症状——这也是为什么部署有时会以看似完全不同的方式卡住,取决于究竟缺少哪一项记录。
这三者之间的互动也越来越紧密。例如,Cloudflare 的自动生成 LOA 流程会依赖经过 RPKI 签名的 ROA 以及所有权验证检查——也就是说,加密记录用于支持这份人工文件,而不是取代它。关于 ROA 的具体机制,包括它如何授权某个特定的起源 ASN,以及配置错误时会发生什么,请参阅我们的RPKI 和 ROA指南。
谁可以合法签发 LOA?
只有地址空间的注册持有者——或者被授权代表该持有者行事的人——才有资格合法签发 LOA。 这一点必须非常准确地说明,因为现实中经常有人把相关概念混淆。
有三个概念值得明确区分:
- LOA 授权的是公告,并不转移所有权。 签署 LOA 只是授予对地址空间进行路由的许可。它不会让被授权方成为该地址空间的持有者,不会更改注册记录,也不会转移任何注册管理层面的权利。当授权终止时,该项公告权限也随之终止。
- 在整个租赁期间,注册信息仍然保留在持有者名下。 在租赁安排中,注册管理机构的记录会继续显示原持有者为注册方。这并不是租赁关系中的漏洞——这正是租赁模式本身的结构。租户的公告权来自所获得的授权,而不是来自注册信息的改变。
- 进行公告不等于持有地址空间。 一个网络公告某个前缀,意味着它正在作为起源网络发布该前缀,这反映的是它获得了授权。公告本身并不能证明所有权。这种区分在概念和实际操作上都非常重要,因为未经授权的公告本身正是路由劫持的定义之一。
对于接收公告的上游服务提供商来说,这些区别最终会转化成一个验证问题:签署人真的拥有他们所声称的授权权力吗?这就是为什么 LOA 通常需要使用持有者的公司抬头纸、公司资料必须与注册记录相符,并由身份和职位明确的人签署。任何无法追溯到注册持有者的文件,都不能算真正的授权——那只能算是一项单方面声明。
LOA 与租赁 IPv4:付款之前应该核实什么?
由于 LOA 位于路由上线流程的关键路径上,因此应该在付款之前确认其处理方式,而不是付款之后才发现问题。 这个失败模式在行业中非常常见:企业签署了租赁协议、配置好路由、通知了上游,然后才被要求提供一份租赁协议中从未提及、而出租方又迟迟无法出具的 LOA。在文件到达之前,地址已经付费,却无法使用。
以下事项应当提前确认:
- 付款前取得 LOA,或者取得书面的交付承诺。 最好直接拿到文件;如果做不到,也应在协议中明确规定,必须在一个确定且较短的时间内交付。如果出租方连这两者中的任何一种都不愿意承诺,那已经说明了后续合作关系可能会是什么样子。
- 确认 LOA 中列出了正确的前缀。 应当准确列出你实际租赁的地址块。LOA 如果覆盖了不同地址块或过大的范围,上游可能会提出质疑;如果覆盖范围小于你所需,也无法授权剩余部分。
- 确认 LOA 中列出了正确的 ASN。 必须是实际会成为起源网络的 ASN——根据你的部署方式,这可能是你自己的 ASN,也可能是上游的 ASN。错误的 ASN 是一份形式上有效的 LOA 仍然无法帮助部署上线的最常见原因之一。
- 核对有效期与租赁期限。 如果授权比租赁期限更早到期,就会在部署过程中产生重新签发 LOA 的依赖。
- 确认文件确实来自注册持有者。 公司抬头和企业资料应与注册记录一致,并由可以识别且确实有授权权限的人签署。
- 确认重新签发流程。 如果你更换上游、更换 ASN,或需要为第二家服务提供商增加一份 LOA,更新文件最快可以在多久内提供?实际部署会发生变化,而授权文件必须能够同步更新。
- 询问 LOA 如何与 ROA 和 route object 配合。 单独拥有 LOA 并不够——正如上面的比较所示,ROA 和 IRR 记录也必须保持一致。能够完整处理这三项内容的出租方,比只提供一份文件然后把其余事情全部交给你的出租方,更适合生产环境部署。
这些问题在签约之前提出几乎没有成本,但签约之后才提出往往代价高昂。综合来看,它们也是判断租赁质量非常可靠的信号:如果一个地址安排将路由授权明确视为具有交付期限的正式交付成果,那么它通常是按照生产环境需求设计的;反之,如果把授权当成事后再处理的细节,那么这个问题往往会在最糟糕的时候暴露出来。
常见 LOA 问题
大多数 LOA 问题并不是围绕授权本身产生争议,而是文件交付太迟、内容错误或已经过期。 常见情况包括:
- 交付延迟。 这是最常见、也是成本最高的问题。只要文件一天没有到位,地址空间就一天无法正常公告,无论其他部分准备得多么充分。
- ASN 错误。 LOA 授权了一个与实际发起公告不同的 ASN——通常是因为文件起草之后部署方案发生变化,或出租方误解了租户的上游安排。
- 前缀错误或不够准确。 文件列出的地址块不正确、范围比协议约定更大,或者描述过于模糊,以至于上游不愿据此配置路由。
- 授权已经过期。 有效期已经结束,通常是在服务提供商重新审核文件,或租赁期内新增上游时才被发现。
- 签署人没有授权或无法验证。 文件由上游无法确认其权限的人签署,或者文件本身无法明确关联到注册持有者。
- 协议中完全没有规定 LOA。 租赁协议完全没有提到 LOA 的签发,因此交付时间和责任都没有定义——而交付延迟问题通常就是从这里开始。
这六类问题都可以在协议阶段提前避免,这也是为什么上面的核实清单比事后进行任何故障排查都更加重要。
实用检查清单
- 在签署协议之前,确认协议明确要求持有者签发 LOA,并规定具体交付时间。
- 在付款之前取得 LOA,或者至少取得书面的交付保证。
- 核实准确的前缀与实际租赁或取得的地址块完全一致。
- 核实 ASN 与实际将作为起源网络进行公告的 ASN 完全一致。
- 检查有效期是否覆盖整个租赁或部署周期。
- 确认文件使用注册持有者的正式公司抬头,企业资料与注册记录一致,并有可以识别的授权签署人。
- 按照上游要求的格式提交——PDF 是最稳妥的默认选择;图片格式经常会被拒绝。
- 确认如果上游、ASN 或授权范围发生变化,重新签发的流程以及处理时间。
- 确保 LOA、ROA 和 IRR route object 保持一致,让三种授权记录不会互相冲突。
- 保存一份副本——增加其他服务提供商、进行审计或未来修改部署时,都可能再次需要。
来自 i.lease 的实用说明
LOA 是一份很小的文件,但其运营影响远远超过文件本身的复杂程度。它在技术上并不复杂,只要有权签署的人愿意配合,通常几分钟就可以制作出来,但它却是租赁或新取得的地址块已经付费、却迟迟无法投入使用的最常见原因之一。问题几乎从来不是真正存在授权争议,而是协议签署之前没有人明确规定:由谁签发这份文件、多久内必须交付,以及文件中应该写些什么。
正因如此,LOA 的处理方式其实可以作为判断整体地址资源安排质量的一个很好指标。如果出租方能够快速提供正确的 LOA,一次就准确写明正确的 ASN 和前缀,不需要来回修改三次;当你更换上游时能够迅速重新签发;并且同时保持 ROA 与 route object 一致,那么它实际上正在展示生产环境路由所需要的运营纪律。相反,如果出租方认为 LOA 只是以后再处理的文书工作,那么整个合作关系中的其他环节很可能也会以类似方式处理。文件本身并不复杂,真正重要的是背后的协调能力,而正是这种协调,才能把一段地址空间变成真正可运行的网络基础设施。无论你是租赁还是直接取得地址空间,都应该把路由授权视为一个具有明确期限的正式交付成果,而不是默认它自然会出现。
总结
授权书(LOA)是注册持有者以书面形式授予某个指定方,通过指定 ASN 公告特定前缀的许可。上游服务提供商之所以要求 LOA,是因为仅凭注册数据无法确认公告方是否真正获得授权,而接受未经授权的公告就意味着参与路由劫持。文件会列出持有者、被授权方及 ASN、具体前缀和有效期,并由有权授予该项授权的人签署——它正处于“拥有地址空间”与“能够真正将其路由上线”之间的关键路径上。
最值得记住的区别,是 LOA 能做什么,以及不能做什么。它授权路由公告;它不会转移所有权、不会更改注册信息,也不会授予任何注册管理层面的权利。在租赁关系中,地址空间仍然注册在持有者名下,而租户的公告权来自持有者授予的授权——这也正是为什么 LOA 必须存在,而且必须由持有者出具。再加上由路由器验证的 ROA,以及供过滤系统查询的 route object,LOA 才共同组成将合同权利转化为被网络接受的路由公告所需要的完整记录体系。在部署之前让三者保持一致,在付款之前核实 LOA 的具体内容,才能真正把你已经安排好的地址空间变成可以实际使用的基础设施。
相关阅读
什么是 BGP 劫持?路由劫持如何发生、著名事件以及网络如何防范
RPKI 与 ROA 详解:路由起源授权如何保护你的 IPv4 前缀
什么是 BGP?边界网关协议如何让 IP 地址成为可访问的服务
- 在签署协议之前,确认协议明确要求持有者签发 LOA,并规定具体交付时间。
- 在付款之前取得 LOA,或者至少取得书面的交付保证。
- 核实准确的前缀与实际租赁或取得的地址块完全一致。
- 核实 ASN 与实际将作为起源网络进行公告的 ASN 完全一致。
- 检查有效期是否覆盖整个租赁或部署周期。
- 确认文件使用注册持有者的正式公司抬头,企业资料与注册记录一致,并有可以识别的授权签署人。
- 按照上游要求的格式提交——PDF 是最稳妥的默认选择;图片格式经常会被拒绝。
- 确认如果上游、ASN 或授权范围发生变化,重新签发的流程以及处理时间。
- 确保 LOA、ROA 和 IRR route object 保持一致,让三种授权记录不会互相冲突。
- 保存一份副本——增加其他服务提供商、进行审计或未来修改部署时,都可能再次需要。
来自 i.lease 的实用说明
LOA 是一份很小的文件,但其运营影响远远超过文件本身的复杂程度。它在技术上并不复杂,只要有权签署的人愿意配合,通常几分钟就可以制作出来,但它却是租赁或新取得的地址块已经付费、却迟迟无法投入使用的最常见原因之一。问题几乎从来不是真正存在授权争议,而是协议签署之前没有人明确规定:由谁签发这份文件、多久内必须交付,以及文件中应该写些什么。
正因如此,LOA 的处理方式其实可以作为判断整体地址资源安排质量的一个很好指标。如果出租方能够快速提供正确的 LOA,一次就准确写明正确的 ASN 和前缀,不需要来回修改三次;当你更换上游时能够迅速重新签发;并且同时保持 ROA 与 route object 一致,那么它实际上正在展示生产环境路由所需要的运营纪律。相反,如果出租方认为 LOA 只是以后再处理的文书工作,那么整个合作关系中的其他环节很可能也会以类似方式处理。文件本身并不复杂,真正重要的是背后的协调能力,而正是这种协调,才能把一段地址空间变成真正可运行的网络基础设施。无论你是租赁还是直接取得地址空间,都应该把路由授权视为一个具有明确期限的正式交付成果,而不是默认它自然会出现。
总结
授权书(LOA)是注册持有者以书面形式授予某个指定方,通过指定 ASN 公告特定前缀的许可。上游服务提供商之所以要求 LOA,是因为仅凭注册数据无法确认公告方是否真正获得授权,而接受未经授权的公告就意味着参与路由劫持。文件会列出持有者、被授权方及 ASN、具体前缀和有效期,并由有权授予该项授权的人签署——它正处于“拥有地址空间”与“能够真正将其路由上线”之间的关键路径上。
最值得记住的区别,是 LOA 能做什么,以及不能做什么。它授权路由公告;它不会转移所有权、不会更改注册信息,也不会授予任何注册管理层面的权利。在租赁关系中,地址空间仍然注册在持有者名下,而租户的公告权来自持有者授予的授权——这也正是为什么 LOA 必须存在,而且必须由持有者出具。再加上由路由器验证的 ROA,以及供过滤系统查询的 route object,LOA 才共同组成将合同权利转化为被网络接受的路由公告所需要的完整记录体系。在部署之前让三者保持一致,在付款之前核实 LOA 的具体内容,才能真正把你已经安排好的地址空间变成可以实际使用的基础设施。
相关阅读
什么是 BGP 劫持?路由劫持如何发生、著名事件以及网络如何防范
RPKI 与 ROA 详解:路由起源授权如何保护你的 IPv4 前缀
什么是 BGP?边界网关协议如何让 IP 地址成为可访问的服务
- 授权方。 即地址空间的注册持有者,其公司名称和相关资料应与注册记录一致。
- 被授权方和 ASN。 文件需要说明谁被允许公告该地址空间,以及最关键的——将通过哪个自治系统编号进行公告。Cloudflare 的文档明确要求 LOA 同时写明被授权的前缀和公告所使用的 ASN——ASN 并不是可有可无的附加信息。
- 准确的前缀。 必须精确列出受授权覆盖的地址块(例如某个具体的 /24)。任何超出 LOA 所列范围的公告,都不属于该授权范围。
- 有效期。 授权的持续时间。对于租赁地址空间,其有效期应与租赁期限保持一致。
- 授权签署人。 包括姓名、职位以及有权代表持有者签署文件的人员签名,并附上联系方式,以便上游服务提供商在有需要时进行核实。
- 公司抬头和文件格式。 LOA 通常应以持有者公司的正式抬头纸制作。Cloudflare 指出,Transit 服务提供商可能会拒绝以图片格式提交的 LOA,而要求使用 PDF;数字签名通常可以接受,但签署人必须能够被清楚识别。
这些要求并不是毫无意义的行政装饰。公司抬头、与注册记录一致的企业资料,以及可识别的授权签署人,正是接收方用于确认文件真实性,以及签署人确实有权授予所声称授权的依据。
什么时候需要 LOA?
只要将由注册持有者以外的一方公告地址空间,通常都需要 LOA——这涵盖了绝大多数 IPv4 租赁、BYOIP 和由服务提供商代为公告的情况。 常见场景包括:
- 通过自己的 ASN 公告租赁的 IPv4。 这是最典型的情况:你租赁了一个地址块,并自行对外公告,因此你的上游需要看到持有者提供的授权。关于这个更完整的租赁流程,可以参考我们的IPv4 租赁指南以及IP 地址租赁如何运作的说明。
- 由服务提供商代表你公告地址空间。 当你的托管服务商、数据中心或平台通过其 ASN 公告你的前缀时,它需要获得你的授权——而它的上游同样需要看到这一授权。
- BYOIP 接入。 将自有 IP 地址空间(BYOIP)带入云平台或边缘平台时,需要授权该平台公告你的前缀,Cloudflare 的要求就是一个典型例子。
- 紧急路由变更。 例如 DDoS 清洗服务,在攻击发生时由服务提供商临时公告你的前缀,这类安排依赖于事先完成授权——这一点我们也在DDoS 缓解指南中进行了介绍。
判断标准其实很简单:如果进行公告的 ASN 并不属于注册持有者本身,那么几乎可以确定需要 LOA。
LOA vs ROA vs IRR Route Object
LOA、ROA 和 IRR route object 都在说明谁可以公告某个前缀——但它们面对不同的受众、采用不同形式,并且作用于不同层面。 它们彼此互补,而不是相互替代。一个正确部署的前缀,通常需要三者保持一致。
LOA vs ROA vs IRR Route Object
项目
LOA
ROA
IRR route object
它是什么
授予路由公告权限的签署文件
RPKI 中经过加密签名的记录
Internet Routing Registry 数据库中的记录
面向对象
人员——上游开通和 NOC 工作人员
执行路由起源验证的路由器
自动生成过滤规则的系统
形式
人类可读、合同性质
加密签名、机器验证
数据库记录
由谁创建
注册持有者(或授权代表)
注册持有者,通过其 RIR 创建
对象的持有者或 maintainer
缺失或错误时的影响
上游拒绝配置该路由公告
公告可能被执行 RPKI 验证的网络判定为 RPKI-Invalid 并拒绝
使用 IRR 数据生成过滤规则的服务提供商可能过滤该公告
最清楚的理解方式是:LOA 决定你的上游工作人员是否愿意配置并接受这项公告;ROA 决定互联网上执行验证的路由器是否认为该起源 ASN 合法;route object 则影响自动化过滤系统是否允许该公告通过。三者都可能独立出现问题,而且每一种失败都会产生不同的症状——这也是为什么部署有时会以看似完全不同的方式卡住,取决于究竟缺少哪一项记录。
这三者之间的互动也越来越紧密。例如,Cloudflare 的自动生成 LOA 流程会依赖经过 RPKI 签名的 ROA 以及所有权验证检查——也就是说,加密记录用于支持这份人工文件,而不是取代它。关于 ROA 的具体机制,包括它如何授权某个特定的起源 ASN,以及配置错误时会发生什么,请参阅我们的RPKI 和 ROA指南。
谁可以合法签发 LOA?
只有地址空间的注册持有者——或者被授权代表该持有者行事的人——才有资格合法签发 LOA。 这一点必须非常准确地说明,因为现实中经常有人把相关概念混淆。
有三个概念值得明确区分:
- LOA 授权的是公告,并不转移所有权。 签署 LOA 只是授予对地址空间进行路由的许可。它不会让被授权方成为该地址空间的持有者,不会更改注册记录,也不会转移任何注册管理层面的权利。当授权终止时,该项公告权限也随之终止。
- 在整个租赁期间,注册信息仍然保留在持有者名下。 在租赁安排中,注册管理机构的记录会继续显示原持有者为注册方。这并不是租赁关系中的漏洞——这正是租赁模式本身的结构。租户的公告权来自所获得的授权,而不是来自注册信息的改变。
- 进行公告不等于持有地址空间。 一个网络公告某个前缀,意味着它正在作为起源网络发布该前缀,这反映的是它获得了授权。公告本身并不能证明所有权。这种区分在概念和实际操作上都非常重要,因为未经授权的公告本身正是路由劫持的定义之一。
对于接收公告的上游服务提供商来说,这些区别最终会转化成一个验证问题:签署人真的拥有他们所声称的授权权力吗?这就是为什么 LOA 通常需要使用持有者的公司抬头纸、公司资料必须与注册记录相符,并由身份和职位明确的人签署。任何无法追溯到注册持有者的文件,都不能算真正的授权——那只能算是一项单方面声明。
LOA 与租赁 IPv4:付款之前应该核实什么?
由于 LOA 位于路由上线流程的关键路径上,因此应该在付款之前确认其处理方式,而不是付款之后才发现问题。 这个失败模式在行业中非常常见:企业签署了租赁协议、配置好路由、通知了上游,然后才被要求提供一份租赁协议中从未提及、而出租方又迟迟无法出具的 LOA。在文件到达之前,地址已经付费,却无法使用。
以下事项应当提前确认:
- 付款前取得 LOA,或者取得书面的交付承诺。 最好直接拿到文件;如果做不到,也应在协议中明确规定,必须在一个确定且较短的时间内交付。如果出租方连这两者中的任何一种都不愿意承诺,那已经说明了后续合作关系可能会是什么样子。
- 确认 LOA 中列出了正确的前缀。 应当准确列出你实际租赁的地址块。LOA 如果覆盖了不同地址块或过大的范围,上游可能会提出质疑;如果覆盖范围小于你所需,也无法授权剩余部分。
- 确认 LOA 中列出了正确的 ASN。 必须是实际会成为起源网络的 ASN——根据你的部署方式,这可能是你自己的 ASN,也可能是上游的 ASN。错误的 ASN 是一份形式上有效的 LOA 仍然无法帮助部署上线的最常见原因之一。
- 核对有效期与租赁期限。 如果授权比租赁期限更早到期,就会在部署过程中产生重新签发 LOA 的依赖。
- 确认文件确实来自注册持有者。 公司抬头和企业资料应与注册记录一致,并由可以识别且确实有授权权限的人签署。
- 确认重新签发流程。 如果你更换上游、更换 ASN,或需要为第二家服务提供商增加一份 LOA,更新文件最快可以在多久内提供?实际部署会发生变化,而授权文件必须能够同步更新。
- 询问 LOA 如何与 ROA 和 route object 配合。 单独拥有 LOA 并不够——正如上面的比较所示,ROA 和 IRR 记录也必须保持一致。能够完整处理这三项内容的出租方,比只提供一份文件然后把其余事情全部交给你的出租方,更适合生产环境部署。
这些问题在签约之前提出几乎没有成本,但签约之后才提出往往代价高昂。综合来看,它们也是判断租赁质量非常可靠的信号:如果一个地址安排将路由授权明确视为具有交付期限的正式交付成果,那么它通常是按照生产环境需求设计的;反之,如果把授权当成事后再处理的细节,那么这个问题往往会在最糟糕的时候暴露出来。
常见 LOA 问题
大多数 LOA 问题并不是围绕授权本身产生争议,而是文件交付太迟、内容错误或已经过期。 常见情况包括:
- 交付延迟。 这是最常见、也是成本最高的问题。只要文件一天没有到位,地址空间就一天无法正常公告,无论其他部分准备得多么充分。
- ASN 错误。 LOA 授权了一个与实际发起公告不同的 ASN——通常是因为文件起草之后部署方案发生变化,或出租方误解了租户的上游安排。
- 前缀错误或不够准确。 文件列出的地址块不正确、范围比协议约定更大,或者描述过于模糊,以至于上游不愿据此配置路由。
- 授权已经过期。 有效期已经结束,通常是在服务提供商重新审核文件,或租赁期内新增上游时才被发现。
- 签署人没有授权或无法验证。 文件由上游无法确认其权限的人签署,或者文件本身无法明确关联到注册持有者。
- 协议中完全没有规定 LOA。 租赁协议完全没有提到 LOA 的签发,因此交付时间和责任都没有定义——而交付延迟问题通常就是从这里开始。
这六类问题都可以在协议阶段提前避免,这也是为什么上面的核实清单比事后进行任何故障排查都更加重要。
实用检查清单
- 在签署协议之前,确认协议明确要求持有者签发 LOA,并规定具体交付时间。
- 在付款之前取得 LOA,或者至少取得书面的交付保证。
- 核实准确的前缀与实际租赁或取得的地址块完全一致。
- 核实 ASN 与实际将作为起源网络进行公告的 ASN 完全一致。
- 检查有效期是否覆盖整个租赁或部署周期。
- 确认文件使用注册持有者的正式公司抬头,企业资料与注册记录一致,并有可以识别的授权签署人。
- 按照上游要求的格式提交——PDF 是最稳妥的默认选择;图片格式经常会被拒绝。
- 确认如果上游、ASN 或授权范围发生变化,重新签发的流程以及处理时间。
- 确保 LOA、ROA 和 IRR route object 保持一致,让三种授权记录不会互相冲突。
- 保存一份副本——增加其他服务提供商、进行审计或未来修改部署时,都可能再次需要。
来自 i.lease 的实用说明
LOA 是一份很小的文件,但其运营影响远远超过文件本身的复杂程度。它在技术上并不复杂,只要有权签署的人愿意配合,通常几分钟就可以制作出来,但它却是租赁或新取得的地址块已经付费、却迟迟无法投入使用的最常见原因之一。问题几乎从来不是真正存在授权争议,而是协议签署之前没有人明确规定:由谁签发这份文件、多久内必须交付,以及文件中应该写些什么。
正因如此,LOA 的处理方式其实可以作为判断整体地址资源安排质量的一个很好指标。如果出租方能够快速提供正确的 LOA,一次就准确写明正确的 ASN 和前缀,不需要来回修改三次;当你更换上游时能够迅速重新签发;并且同时保持 ROA 与 route object 一致,那么它实际上正在展示生产环境路由所需要的运营纪律。相反,如果出租方认为 LOA 只是以后再处理的文书工作,那么整个合作关系中的其他环节很可能也会以类似方式处理。文件本身并不复杂,真正重要的是背后的协调能力,而正是这种协调,才能把一段地址空间变成真正可运行的网络基础设施。无论你是租赁还是直接取得地址空间,都应该把路由授权视为一个具有明确期限的正式交付成果,而不是默认它自然会出现。
总结
授权书(LOA)是注册持有者以书面形式授予某个指定方,通过指定 ASN 公告特定前缀的许可。上游服务提供商之所以要求 LOA,是因为仅凭注册数据无法确认公告方是否真正获得授权,而接受未经授权的公告就意味着参与路由劫持。文件会列出持有者、被授权方及 ASN、具体前缀和有效期,并由有权授予该项授权的人签署——它正处于“拥有地址空间”与“能够真正将其路由上线”之间的关键路径上。
最值得记住的区别,是 LOA 能做什么,以及不能做什么。它授权路由公告;它不会转移所有权、不会更改注册信息,也不会授予任何注册管理层面的权利。在租赁关系中,地址空间仍然注册在持有者名下,而租户的公告权来自持有者授予的授权——这也正是为什么 LOA 必须存在,而且必须由持有者出具。再加上由路由器验证的 ROA,以及供过滤系统查询的 route object,LOA 才共同组成将合同权利转化为被网络接受的路由公告所需要的完整记录体系。在部署之前让三者保持一致,在付款之前核实 LOA 的具体内容,才能真正把你已经安排好的地址空间变成可以实际使用的基础设施。
相关阅读
什么是 BGP 劫持?路由劫持如何发生、著名事件以及网络如何防范
RPKI 与 ROA 详解:路由起源授权如何保护你的 IPv4 前缀
什么是 BGP?边界网关协议如何让 IP 地址成为可访问的服务
- 它由持有者签发,而不是由公告方自行签发。 有权授予许可的一方,是地址空间的持有者。租户不能自己给自己写一份 LOA。
- 它必须具有明确的针对性。 文件需要列出具体的前缀以及具体的 ASN。仅仅说明某方“信誉良好”并不能构成 LOA;文件中的内容必须与实际将要公告的内容完全匹配。
为什么上游服务提供商要求 LOA?
服务提供商之所以要求 LOA,是因为接受一个未经授权方发出的路由公告,正是前缀劫持发生的方式——而任何负责任的网络都不希望成为传播这种错误公告的一方。
正如我们在BGP 如何运作的指南中所解释的,路由系统在很大程度上是基于信任接受公告的,而各个网络之所以会过滤接收到的路由,正是因为虚假公告可能将属于其他人的流量重定向。这个风险并不是理论上的:未经授权的路由公告正是我们在BGP 劫持指南中所介绍事件的核心机制。如果上游服务提供商在未核实授权的情况下接受公告,那么它就会无意间成为后续事件的参与者。
LOA 填补的正是一个具体的信息缺口。注册记录可以确认地址持有者,但在租赁情况下,注册记录仍然显示原持有者,而实际进行公告的是另一方——因此,上游服务提供商无法仅通过数据库查询来验证租户。LOA 补上了缺失的这一环:由注册记录中可识别的那一方,以书面形式确认实际进行公告的一方已经获得许可。
在实际部署中,这意味着 LOA 位于整个上线流程的关键路径上。路由器已经配置、租赁协议已经签署、地址块已经分配——这些都无法真正带来可达性,直到上游服务提供商接受这条路由公告,而在没有 LOA 的情况下,上游通常不会接受。
LOA 包含哪些内容?
LOA 会明确授权方、被授权方及其 ASN、具体前缀,以及有权授予该项授权人员的签名。 各家服务提供商通常要求的标准组成部分包括:
- 授权方。 即地址空间的注册持有者,其公司名称和相关资料应与注册记录一致。
- 被授权方和 ASN。 文件需要说明谁被允许公告该地址空间,以及最关键的——将通过哪个自治系统编号进行公告。Cloudflare 的文档明确要求 LOA 同时写明被授权的前缀和公告所使用的 ASN——ASN 并不是可有可无的附加信息。
- 准确的前缀。 必须精确列出受授权覆盖的地址块(例如某个具体的 /24)。任何超出 LOA 所列范围的公告,都不属于该授权范围。
- 有效期。 授权的持续时间。对于租赁地址空间,其有效期应与租赁期限保持一致。
- 授权签署人。 包括姓名、职位以及有权代表持有者签署文件的人员签名,并附上联系方式,以便上游服务提供商在有需要时进行核实。
- 公司抬头和文件格式。 LOA 通常应以持有者公司的正式抬头纸制作。Cloudflare 指出,Transit 服务提供商可能会拒绝以图片格式提交的 LOA,而要求使用 PDF;数字签名通常可以接受,但签署人必须能够被清楚识别。
这些要求并不是毫无意义的行政装饰。公司抬头、与注册记录一致的企业资料,以及可识别的授权签署人,正是接收方用于确认文件真实性,以及签署人确实有权授予所声称授权的依据。
什么时候需要 LOA?
只要将由注册持有者以外的一方公告地址空间,通常都需要 LOA——这涵盖了绝大多数 IPv4 租赁、BYOIP 和由服务提供商代为公告的情况。 常见场景包括:
- 通过自己的 ASN 公告租赁的 IPv4。 这是最典型的情况:你租赁了一个地址块,并自行对外公告,因此你的上游需要看到持有者提供的授权。关于这个更完整的租赁流程,可以参考我们的IPv4 租赁指南以及IP 地址租赁如何运作的说明。
- 由服务提供商代表你公告地址空间。 当你的托管服务商、数据中心或平台通过其 ASN 公告你的前缀时,它需要获得你的授权——而它的上游同样需要看到这一授权。
- BYOIP 接入。 将自有 IP 地址空间(BYOIP)带入云平台或边缘平台时,需要授权该平台公告你的前缀,Cloudflare 的要求就是一个典型例子。
- 紧急路由变更。 例如 DDoS 清洗服务,在攻击发生时由服务提供商临时公告你的前缀,这类安排依赖于事先完成授权——这一点我们也在DDoS 缓解指南中进行了介绍。
判断标准其实很简单:如果进行公告的 ASN 并不属于注册持有者本身,那么几乎可以确定需要 LOA。
LOA vs ROA vs IRR Route Object
LOA、ROA 和 IRR route object 都在说明谁可以公告某个前缀——但它们面对不同的受众、采用不同形式,并且作用于不同层面。 它们彼此互补,而不是相互替代。一个正确部署的前缀,通常需要三者保持一致。
LOA vs ROA vs IRR Route Object
项目
LOA
ROA
IRR route object
它是什么
授予路由公告权限的签署文件
RPKI 中经过加密签名的记录
Internet Routing Registry 数据库中的记录
面向对象
人员——上游开通和 NOC 工作人员
执行路由起源验证的路由器
自动生成过滤规则的系统
形式
人类可读、合同性质
加密签名、机器验证
数据库记录
由谁创建
注册持有者(或授权代表)
注册持有者,通过其 RIR 创建
对象的持有者或 maintainer
缺失或错误时的影响
上游拒绝配置该路由公告
公告可能被执行 RPKI 验证的网络判定为 RPKI-Invalid 并拒绝
使用 IRR 数据生成过滤规则的服务提供商可能过滤该公告
最清楚的理解方式是:LOA 决定你的上游工作人员是否愿意配置并接受这项公告;ROA 决定互联网上执行验证的路由器是否认为该起源 ASN 合法;route object 则影响自动化过滤系统是否允许该公告通过。三者都可能独立出现问题,而且每一种失败都会产生不同的症状——这也是为什么部署有时会以看似完全不同的方式卡住,取决于究竟缺少哪一项记录。
这三者之间的互动也越来越紧密。例如,Cloudflare 的自动生成 LOA 流程会依赖经过 RPKI 签名的 ROA 以及所有权验证检查——也就是说,加密记录用于支持这份人工文件,而不是取代它。关于 ROA 的具体机制,包括它如何授权某个特定的起源 ASN,以及配置错误时会发生什么,请参阅我们的RPKI 和 ROA指南。
谁可以合法签发 LOA?
只有地址空间的注册持有者——或者被授权代表该持有者行事的人——才有资格合法签发 LOA。 这一点必须非常准确地说明,因为现实中经常有人把相关概念混淆。
有三个概念值得明确区分:
- LOA 授权的是公告,并不转移所有权。 签署 LOA 只是授予对地址空间进行路由的许可。它不会让被授权方成为该地址空间的持有者,不会更改注册记录,也不会转移任何注册管理层面的权利。当授权终止时,该项公告权限也随之终止。
- 在整个租赁期间,注册信息仍然保留在持有者名下。 在租赁安排中,注册管理机构的记录会继续显示原持有者为注册方。这并不是租赁关系中的漏洞——这正是租赁模式本身的结构。租户的公告权来自所获得的授权,而不是来自注册信息的改变。
- 进行公告不等于持有地址空间。 一个网络公告某个前缀,意味着它正在作为起源网络发布该前缀,这反映的是它获得了授权。公告本身并不能证明所有权。这种区分在概念和实际操作上都非常重要,因为未经授权的公告本身正是路由劫持的定义之一。
对于接收公告的上游服务提供商来说,这些区别最终会转化成一个验证问题:签署人真的拥有他们所声称的授权权力吗?这就是为什么 LOA 通常需要使用持有者的公司抬头纸、公司资料必须与注册记录相符,并由身份和职位明确的人签署。任何无法追溯到注册持有者的文件,都不能算真正的授权——那只能算是一项单方面声明。
LOA 与租赁 IPv4:付款之前应该核实什么?
由于 LOA 位于路由上线流程的关键路径上,因此应该在付款之前确认其处理方式,而不是付款之后才发现问题。 这个失败模式在行业中非常常见:企业签署了租赁协议、配置好路由、通知了上游,然后才被要求提供一份租赁协议中从未提及、而出租方又迟迟无法出具的 LOA。在文件到达之前,地址已经付费,却无法使用。
以下事项应当提前确认:
- 付款前取得 LOA,或者取得书面的交付承诺。 最好直接拿到文件;如果做不到,也应在协议中明确规定,必须在一个确定且较短的时间内交付。如果出租方连这两者中的任何一种都不愿意承诺,那已经说明了后续合作关系可能会是什么样子。
- 确认 LOA 中列出了正确的前缀。 应当准确列出你实际租赁的地址块。LOA 如果覆盖了不同地址块或过大的范围,上游可能会提出质疑;如果覆盖范围小于你所需,也无法授权剩余部分。
- 确认 LOA 中列出了正确的 ASN。 必须是实际会成为起源网络的 ASN——根据你的部署方式,这可能是你自己的 ASN,也可能是上游的 ASN。错误的 ASN 是一份形式上有效的 LOA 仍然无法帮助部署上线的最常见原因之一。
- 核对有效期与租赁期限。 如果授权比租赁期限更早到期,就会在部署过程中产生重新签发 LOA 的依赖。
- 确认文件确实来自注册持有者。 公司抬头和企业资料应与注册记录一致,并由可以识别且确实有授权权限的人签署。
- 确认重新签发流程。 如果你更换上游、更换 ASN,或需要为第二家服务提供商增加一份 LOA,更新文件最快可以在多久内提供?实际部署会发生变化,而授权文件必须能够同步更新。
- 询问 LOA 如何与 ROA 和 route object 配合。 单独拥有 LOA 并不够——正如上面的比较所示,ROA 和 IRR 记录也必须保持一致。能够完整处理这三项内容的出租方,比只提供一份文件然后把其余事情全部交给你的出租方,更适合生产环境部署。
这些问题在签约之前提出几乎没有成本,但签约之后才提出往往代价高昂。综合来看,它们也是判断租赁质量非常可靠的信号:如果一个地址安排将路由授权明确视为具有交付期限的正式交付成果,那么它通常是按照生产环境需求设计的;反之,如果把授权当成事后再处理的细节,那么这个问题往往会在最糟糕的时候暴露出来。
常见 LOA 问题
大多数 LOA 问题并不是围绕授权本身产生争议,而是文件交付太迟、内容错误或已经过期。 常见情况包括:
- 交付延迟。 这是最常见、也是成本最高的问题。只要文件一天没有到位,地址空间就一天无法正常公告,无论其他部分准备得多么充分。
- ASN 错误。 LOA 授权了一个与实际发起公告不同的 ASN——通常是因为文件起草之后部署方案发生变化,或出租方误解了租户的上游安排。
- 前缀错误或不够准确。 文件列出的地址块不正确、范围比协议约定更大,或者描述过于模糊,以至于上游不愿据此配置路由。
- 授权已经过期。 有效期已经结束,通常是在服务提供商重新审核文件,或租赁期内新增上游时才被发现。
- 签署人没有授权或无法验证。 文件由上游无法确认其权限的人签署,或者文件本身无法明确关联到注册持有者。
- 协议中完全没有规定 LOA。 租赁协议完全没有提到 LOA 的签发,因此交付时间和责任都没有定义——而交付延迟问题通常就是从这里开始。
这六类问题都可以在协议阶段提前避免,这也是为什么上面的核实清单比事后进行任何故障排查都更加重要。
实用检查清单
- 在签署协议之前,确认协议明确要求持有者签发 LOA,并规定具体交付时间。
- 在付款之前取得 LOA,或者至少取得书面的交付保证。
- 核实准确的前缀与实际租赁或取得的地址块完全一致。
- 核实 ASN 与实际将作为起源网络进行公告的 ASN 完全一致。
- 检查有效期是否覆盖整个租赁或部署周期。
- 确认文件使用注册持有者的正式公司抬头,企业资料与注册记录一致,并有可以识别的授权签署人。
- 按照上游要求的格式提交——PDF 是最稳妥的默认选择;图片格式经常会被拒绝。
- 确认如果上游、ASN 或授权范围发生变化,重新签发的流程以及处理时间。
- 确保 LOA、ROA 和 IRR route object 保持一致,让三种授权记录不会互相冲突。
- 保存一份副本——增加其他服务提供商、进行审计或未来修改部署时,都可能再次需要。
来自 i.lease 的实用说明
LOA 是一份很小的文件,但其运营影响远远超过文件本身的复杂程度。它在技术上并不复杂,只要有权签署的人愿意配合,通常几分钟就可以制作出来,但它却是租赁或新取得的地址块已经付费、却迟迟无法投入使用的最常见原因之一。问题几乎从来不是真正存在授权争议,而是协议签署之前没有人明确规定:由谁签发这份文件、多久内必须交付,以及文件中应该写些什么。
正因如此,LOA 的处理方式其实可以作为判断整体地址资源安排质量的一个很好指标。如果出租方能够快速提供正确的 LOA,一次就准确写明正确的 ASN 和前缀,不需要来回修改三次;当你更换上游时能够迅速重新签发;并且同时保持 ROA 与 route object 一致,那么它实际上正在展示生产环境路由所需要的运营纪律。相反,如果出租方认为 LOA 只是以后再处理的文书工作,那么整个合作关系中的其他环节很可能也会以类似方式处理。文件本身并不复杂,真正重要的是背后的协调能力,而正是这种协调,才能把一段地址空间变成真正可运行的网络基础设施。无论你是租赁还是直接取得地址空间,都应该把路由授权视为一个具有明确期限的正式交付成果,而不是默认它自然会出现。
总结
授权书(LOA)是注册持有者以书面形式授予某个指定方,通过指定 ASN 公告特定前缀的许可。上游服务提供商之所以要求 LOA,是因为仅凭注册数据无法确认公告方是否真正获得授权,而接受未经授权的公告就意味着参与路由劫持。文件会列出持有者、被授权方及 ASN、具体前缀和有效期,并由有权授予该项授权的人签署——它正处于“拥有地址空间”与“能够真正将其路由上线”之间的关键路径上。
最值得记住的区别,是 LOA 能做什么,以及不能做什么。它授权路由公告;它不会转移所有权、不会更改注册信息,也不会授予任何注册管理层面的权利。在租赁关系中,地址空间仍然注册在持有者名下,而租户的公告权来自持有者授予的授权——这也正是为什么 LOA 必须存在,而且必须由持有者出具。再加上由路由器验证的 ROA,以及供过滤系统查询的 route object,LOA 才共同组成将合同权利转化为被网络接受的路由公告所需要的完整记录体系。在部署之前让三者保持一致,在付款之前核实 LOA 的具体内容,才能真正把你已经安排好的地址空间变成可以实际使用的基础设施。
相关阅读
什么是 BGP 劫持?路由劫持如何发生、著名事件以及网络如何防范
RPKI 与 ROA 详解:路由起源授权如何保护你的 IPv4 前缀
什么是 BGP?边界网关协议如何让 IP 地址成为可访问的服务
- LOA 授权的是公告,并不转移所有权。 签署 LOA 只是授予对地址空间进行路由的许可。它不会让被授权方成为该地址空间的持有者,不会更改注册记录,也不会转移任何注册管理层面的权利。当授权终止时,该项公告权限也随之终止。
- 在整个租赁期间,注册信息仍然保留在持有者名下。 在租赁安排中,注册管理机构的记录会继续显示原持有者为注册方。这并不是租赁关系中的漏洞——这正是租赁模式本身的结构。租户的公告权来自所获得的授权,而不是来自注册信息的改变。
- 进行公告不等于持有地址空间。 一个网络公告某个前缀,意味着它正在作为起源网络发布该前缀,这反映的是它获得了授权。公告本身并不能证明所有权。这种区分在概念和实际操作上都非常重要,因为未经授权的公告本身正是路由劫持的定义之一。
对于接收公告的上游服务提供商来说,这些区别最终会转化成一个验证问题:签署人真的拥有他们所声称的授权权力吗?这就是为什么 LOA 通常需要使用持有者的公司抬头纸、公司资料必须与注册记录相符,并由身份和职位明确的人签署。任何无法追溯到注册持有者的文件,都不能算真正的授权——那只能算是一项单方面声明。
LOA 与租赁 IPv4:付款之前应该核实什么?
由于 LOA 位于路由上线流程的关键路径上,因此应该在付款之前确认其处理方式,而不是付款之后才发现问题。 这个失败模式在行业中非常常见:企业签署了租赁协议、配置好路由、通知了上游,然后才被要求提供一份租赁协议中从未提及、而出租方又迟迟无法出具的 LOA。在文件到达之前,地址已经付费,却无法使用。
以下事项应当提前确认:
- 付款前取得 LOA,或者取得书面的交付承诺。 最好直接拿到文件;如果做不到,也应在协议中明确规定,必须在一个确定且较短的时间内交付。如果出租方连这两者中的任何一种都不愿意承诺,那已经说明了后续合作关系可能会是什么样子。
- 确认 LOA 中列出了正确的前缀。 应当准确列出你实际租赁的地址块。LOA 如果覆盖了不同地址块或过大的范围,上游可能会提出质疑;如果覆盖范围小于你所需,也无法授权剩余部分。
- 确认 LOA 中列出了正确的 ASN。 必须是实际会成为起源网络的 ASN——根据你的部署方式,这可能是你自己的 ASN,也可能是上游的 ASN。错误的 ASN 是一份形式上有效的 LOA 仍然无法帮助部署上线的最常见原因之一。
- 核对有效期与租赁期限。 如果授权比租赁期限更早到期,就会在部署过程中产生重新签发 LOA 的依赖。
- 确认文件确实来自注册持有者。 公司抬头和企业资料应与注册记录一致,并由可以识别且确实有授权权限的人签署。
- 确认重新签发流程。 如果你更换上游、更换 ASN,或需要为第二家服务提供商增加一份 LOA,更新文件最快可以在多久内提供?实际部署会发生变化,而授权文件必须能够同步更新。
- 询问 LOA 如何与 ROA 和 route object 配合。 单独拥有 LOA 并不够——正如上面的比较所示,ROA 和 IRR 记录也必须保持一致。能够完整处理这三项内容的出租方,比只提供一份文件然后把其余事情全部交给你的出租方,更适合生产环境部署。
这些问题在签约之前提出几乎没有成本,但签约之后才提出往往代价高昂。综合来看,它们也是判断租赁质量非常可靠的信号:如果一个地址安排将路由授权明确视为具有交付期限的正式交付成果,那么它通常是按照生产环境需求设计的;反之,如果把授权当成事后再处理的细节,那么这个问题往往会在最糟糕的时候暴露出来。
常见 LOA 问题
大多数 LOA 问题并不是围绕授权本身产生争议,而是文件交付太迟、内容错误或已经过期。 常见情况包括:
- 交付延迟。 这是最常见、也是成本最高的问题。只要文件一天没有到位,地址空间就一天无法正常公告,无论其他部分准备得多么充分。
- ASN 错误。 LOA 授权了一个与实际发起公告不同的 ASN——通常是因为文件起草之后部署方案发生变化,或出租方误解了租户的上游安排。
- 前缀错误或不够准确。 文件列出的地址块不正确、范围比协议约定更大,或者描述过于模糊,以至于上游不愿据此配置路由。
- 授权已经过期。 有效期已经结束,通常是在服务提供商重新审核文件,或租赁期内新增上游时才被发现。
- 签署人没有授权或无法验证。 文件由上游无法确认其权限的人签署,或者文件本身无法明确关联到注册持有者。
- 协议中完全没有规定 LOA。 租赁协议完全没有提到 LOA 的签发,因此交付时间和责任都没有定义——而交付延迟问题通常就是从这里开始。
这六类问题都可以在协议阶段提前避免,这也是为什么上面的核实清单比事后进行任何故障排查都更加重要。
实用检查清单
- 在签署协议之前,确认协议明确要求持有者签发 LOA,并规定具体交付时间。
- 在付款之前取得 LOA,或者至少取得书面的交付保证。
- 核实准确的前缀与实际租赁或取得的地址块完全一致。
- 核实 ASN 与实际将作为起源网络进行公告的 ASN 完全一致。
- 检查有效期是否覆盖整个租赁或部署周期。
- 确认文件使用注册持有者的正式公司抬头,企业资料与注册记录一致,并有可以识别的授权签署人。
- 按照上游要求的格式提交——PDF 是最稳妥的默认选择;图片格式经常会被拒绝。
- 确认如果上游、ASN 或授权范围发生变化,重新签发的流程以及处理时间。
- 确保 LOA、ROA 和 IRR route object 保持一致,让三种授权记录不会互相冲突。
- 保存一份副本——增加其他服务提供商、进行审计或未来修改部署时,都可能再次需要。
来自 i.lease 的实用说明
LOA 是一份很小的文件,但其运营影响远远超过文件本身的复杂程度。它在技术上并不复杂,只要有权签署的人愿意配合,通常几分钟就可以制作出来,但它却是租赁或新取得的地址块已经付费、却迟迟无法投入使用的最常见原因之一。问题几乎从来不是真正存在授权争议,而是协议签署之前没有人明确规定:由谁签发这份文件、多久内必须交付,以及文件中应该写些什么。
正因如此,LOA 的处理方式其实可以作为判断整体地址资源安排质量的一个很好指标。如果出租方能够快速提供正确的 LOA,一次就准确写明正确的 ASN 和前缀,不需要来回修改三次;当你更换上游时能够迅速重新签发;并且同时保持 ROA 与 route object 一致,那么它实际上正在展示生产环境路由所需要的运营纪律。相反,如果出租方认为 LOA 只是以后再处理的文书工作,那么整个合作关系中的其他环节很可能也会以类似方式处理。文件本身并不复杂,真正重要的是背后的协调能力,而正是这种协调,才能把一段地址空间变成真正可运行的网络基础设施。无论你是租赁还是直接取得地址空间,都应该把路由授权视为一个具有明确期限的正式交付成果,而不是默认它自然会出现。
总结
授权书(LOA)是注册持有者以书面形式授予某个指定方,通过指定 ASN 公告特定前缀的许可。上游服务提供商之所以要求 LOA,是因为仅凭注册数据无法确认公告方是否真正获得授权,而接受未经授权的公告就意味着参与路由劫持。文件会列出持有者、被授权方及 ASN、具体前缀和有效期,并由有权授予该项授权的人签署——它正处于“拥有地址空间”与“能够真正将其路由上线”之间的关键路径上。
最值得记住的区别,是 LOA 能做什么,以及不能做什么。它授权路由公告;它不会转移所有权、不会更改注册信息,也不会授予任何注册管理层面的权利。在租赁关系中,地址空间仍然注册在持有者名下,而租户的公告权来自持有者授予的授权——这也正是为什么 LOA 必须存在,而且必须由持有者出具。再加上由路由器验证的 ROA,以及供过滤系统查询的 route object,LOA 才共同组成将合同权利转化为被网络接受的路由公告所需要的完整记录体系。在部署之前让三者保持一致,在付款之前核实 LOA 的具体内容,才能真正把你已经安排好的地址空间变成可以实际使用的基础设施。
相关阅读
什么是 BGP 劫持?路由劫持如何发生、著名事件以及网络如何防范
RPKI 与 ROA 详解:路由起源授权如何保护你的 IPv4 前缀
什么是 BGP?边界网关协议如何让 IP 地址成为可访问的服务
- 授权方。 即地址空间的注册持有者,其公司名称和相关资料应与注册记录一致。
- 被授权方和 ASN。 文件需要说明谁被允许公告该地址空间,以及最关键的——将通过哪个自治系统编号进行公告。Cloudflare 的文档明确要求 LOA 同时写明被授权的前缀和公告所使用的 ASN——ASN 并不是可有可无的附加信息。
- 准确的前缀。 必须精确列出受授权覆盖的地址块(例如某个具体的 /24)。任何超出 LOA 所列范围的公告,都不属于该授权范围。
- 有效期。 授权的持续时间。对于租赁地址空间,其有效期应与租赁期限保持一致。
- 授权签署人。 包括姓名、职位以及有权代表持有者签署文件的人员签名,并附上联系方式,以便上游服务提供商在有需要时进行核实。
- 公司抬头和文件格式。 LOA 通常应以持有者公司的正式抬头纸制作。Cloudflare 指出,Transit 服务提供商可能会拒绝以图片格式提交的 LOA,而要求使用 PDF;数字签名通常可以接受,但签署人必须能够被清楚识别。
这些要求并不是毫无意义的行政装饰。公司抬头、与注册记录一致的企业资料,以及可识别的授权签署人,正是接收方用于确认文件真实性,以及签署人确实有权授予所声称授权的依据。
什么时候需要 LOA?
只要将由注册持有者以外的一方公告地址空间,通常都需要 LOA——这涵盖了绝大多数 IPv4 租赁、BYOIP 和由服务提供商代为公告的情况。 常见场景包括:
- 通过自己的 ASN 公告租赁的 IPv4。 这是最典型的情况:你租赁了一个地址块,并自行对外公告,因此你的上游需要看到持有者提供的授权。关于这个更完整的租赁流程,可以参考我们的IPv4 租赁指南以及IP 地址租赁如何运作的说明。
- 由服务提供商代表你公告地址空间。 当你的托管服务商、数据中心或平台通过其 ASN 公告你的前缀时,它需要获得你的授权——而它的上游同样需要看到这一授权。
- BYOIP 接入。 将自有 IP 地址空间(BYOIP)带入云平台或边缘平台时,需要授权该平台公告你的前缀,Cloudflare 的要求就是一个典型例子。
- 紧急路由变更。 例如 DDoS 清洗服务,在攻击发生时由服务提供商临时公告你的前缀,这类安排依赖于事先完成授权——这一点我们也在DDoS 缓解指南中进行了介绍。
判断标准其实很简单:如果进行公告的 ASN 并不属于注册持有者本身,那么几乎可以确定需要 LOA。
LOA vs ROA vs IRR Route Object
LOA、ROA 和 IRR route object 都在说明谁可以公告某个前缀——但它们面对不同的受众、采用不同形式,并且作用于不同层面。 它们彼此互补,而不是相互替代。一个正确部署的前缀,通常需要三者保持一致。
LOA vs ROA vs IRR Route Object
项目
LOA
ROA
IRR route object
它是什么
授予路由公告权限的签署文件
RPKI 中经过加密签名的记录
Internet Routing Registry 数据库中的记录
面向对象
人员——上游开通和 NOC 工作人员
执行路由起源验证的路由器
自动生成过滤规则的系统
形式
人类可读、合同性质
加密签名、机器验证
数据库记录
由谁创建
注册持有者(或授权代表)
注册持有者,通过其 RIR 创建
对象的持有者或 maintainer
缺失或错误时的影响
上游拒绝配置该路由公告
公告可能被执行 RPKI 验证的网络判定为 RPKI-Invalid 并拒绝
使用 IRR 数据生成过滤规则的服务提供商可能过滤该公告
最清楚的理解方式是:LOA 决定你的上游工作人员是否愿意配置并接受这项公告;ROA 决定互联网上执行验证的路由器是否认为该起源 ASN 合法;route object 则影响自动化过滤系统是否允许该公告通过。三者都可能独立出现问题,而且每一种失败都会产生不同的症状——这也是为什么部署有时会以看似完全不同的方式卡住,取决于究竟缺少哪一项记录。
这三者之间的互动也越来越紧密。例如,Cloudflare 的自动生成 LOA 流程会依赖经过 RPKI 签名的 ROA 以及所有权验证检查——也就是说,加密记录用于支持这份人工文件,而不是取代它。关于 ROA 的具体机制,包括它如何授权某个特定的起源 ASN,以及配置错误时会发生什么,请参阅我们的RPKI 和 ROA指南。
谁可以合法签发 LOA?
只有地址空间的注册持有者——或者被授权代表该持有者行事的人——才有资格合法签发 LOA。 这一点必须非常准确地说明,因为现实中经常有人把相关概念混淆。
有三个概念值得明确区分:
- LOA 授权的是公告,并不转移所有权。 签署 LOA 只是授予对地址空间进行路由的许可。它不会让被授权方成为该地址空间的持有者,不会更改注册记录,也不会转移任何注册管理层面的权利。当授权终止时,该项公告权限也随之终止。
- 在整个租赁期间,注册信息仍然保留在持有者名下。 在租赁安排中,注册管理机构的记录会继续显示原持有者为注册方。这并不是租赁关系中的漏洞——这正是租赁模式本身的结构。租户的公告权来自所获得的授权,而不是来自注册信息的改变。
- 进行公告不等于持有地址空间。 一个网络公告某个前缀,意味着它正在作为起源网络发布该前缀,这反映的是它获得了授权。公告本身并不能证明所有权。这种区分在概念和实际操作上都非常重要,因为未经授权的公告本身正是路由劫持的定义之一。
对于接收公告的上游服务提供商来说,这些区别最终会转化成一个验证问题:签署人真的拥有他们所声称的授权权力吗?这就是为什么 LOA 通常需要使用持有者的公司抬头纸、公司资料必须与注册记录相符,并由身份和职位明确的人签署。任何无法追溯到注册持有者的文件,都不能算真正的授权——那只能算是一项单方面声明。
LOA 与租赁 IPv4:付款之前应该核实什么?
由于 LOA 位于路由上线流程的关键路径上,因此应该在付款之前确认其处理方式,而不是付款之后才发现问题。 这个失败模式在行业中非常常见:企业签署了租赁协议、配置好路由、通知了上游,然后才被要求提供一份租赁协议中从未提及、而出租方又迟迟无法出具的 LOA。在文件到达之前,地址已经付费,却无法使用。
以下事项应当提前确认:
- 付款前取得 LOA,或者取得书面的交付承诺。 最好直接拿到文件;如果做不到,也应在协议中明确规定,必须在一个确定且较短的时间内交付。如果出租方连这两者中的任何一种都不愿意承诺,那已经说明了后续合作关系可能会是什么样子。
- 确认 LOA 中列出了正确的前缀。 应当准确列出你实际租赁的地址块。LOA 如果覆盖了不同地址块或过大的范围,上游可能会提出质疑;如果覆盖范围小于你所需,也无法授权剩余部分。
- 确认 LOA 中列出了正确的 ASN。 必须是实际会成为起源网络的 ASN——根据你的部署方式,这可能是你自己的 ASN,也可能是上游的 ASN。错误的 ASN 是一份形式上有效的 LOA 仍然无法帮助部署上线的最常见原因之一。
- 核对有效期与租赁期限。 如果授权比租赁期限更早到期,就会在部署过程中产生重新签发 LOA 的依赖。
- 确认文件确实来自注册持有者。 公司抬头和企业资料应与注册记录一致,并由可以识别且确实有授权权限的人签署。
- 确认重新签发流程。 如果你更换上游、更换 ASN,或需要为第二家服务提供商增加一份 LOA,更新文件最快可以在多久内提供?实际部署会发生变化,而授权文件必须能够同步更新。
- 询问 LOA 如何与 ROA 和 route object 配合。 单独拥有 LOA 并不够——正如上面的比较所示,ROA 和 IRR 记录也必须保持一致。能够完整处理这三项内容的出租方,比只提供一份文件然后把其余事情全部交给你的出租方,更适合生产环境部署。
这些问题在签约之前提出几乎没有成本,但签约之后才提出往往代价高昂。综合来看,它们也是判断租赁质量非常可靠的信号:如果一个地址安排将路由授权明确视为具有交付期限的正式交付成果,那么它通常是按照生产环境需求设计的;反之,如果把授权当成事后再处理的细节,那么这个问题往往会在最糟糕的时候暴露出来。
常见 LOA 问题
大多数 LOA 问题并不是围绕授权本身产生争议,而是文件交付太迟、内容错误或已经过期。 常见情况包括:
- 交付延迟。 这是最常见、也是成本最高的问题。只要文件一天没有到位,地址空间就一天无法正常公告,无论其他部分准备得多么充分。
- ASN 错误。 LOA 授权了一个与实际发起公告不同的 ASN——通常是因为文件起草之后部署方案发生变化,或出租方误解了租户的上游安排。
- 前缀错误或不够准确。 文件列出的地址块不正确、范围比协议约定更大,或者描述过于模糊,以至于上游不愿据此配置路由。
- 授权已经过期。 有效期已经结束,通常是在服务提供商重新审核文件,或租赁期内新增上游时才被发现。
- 签署人没有授权或无法验证。 文件由上游无法确认其权限的人签署,或者文件本身无法明确关联到注册持有者。
- 协议中完全没有规定 LOA。 租赁协议完全没有提到 LOA 的签发,因此交付时间和责任都没有定义——而交付延迟问题通常就是从这里开始。
这六类问题都可以在协议阶段提前避免,这也是为什么上面的核实清单比事后进行任何故障排查都更加重要。
实用检查清单
- 在签署协议之前,确认协议明确要求持有者签发 LOA,并规定具体交付时间。
- 在付款之前取得 LOA,或者至少取得书面的交付保证。
- 核实准确的前缀与实际租赁或取得的地址块完全一致。
- 核实 ASN 与实际将作为起源网络进行公告的 ASN 完全一致。
- 检查有效期是否覆盖整个租赁或部署周期。
- 确认文件使用注册持有者的正式公司抬头,企业资料与注册记录一致,并有可以识别的授权签署人。
- 按照上游要求的格式提交——PDF 是最稳妥的默认选择;图片格式经常会被拒绝。
- 确认如果上游、ASN 或授权范围发生变化,重新签发的流程以及处理时间。
- 确保 LOA、ROA 和 IRR route object 保持一致,让三种授权记录不会互相冲突。
- 保存一份副本——增加其他服务提供商、进行审计或未来修改部署时,都可能再次需要。
来自 i.lease 的实用说明
LOA 是一份很小的文件,但其运营影响远远超过文件本身的复杂程度。它在技术上并不复杂,只要有权签署的人愿意配合,通常几分钟就可以制作出来,但它却是租赁或新取得的地址块已经付费、却迟迟无法投入使用的最常见原因之一。问题几乎从来不是真正存在授权争议,而是协议签署之前没有人明确规定:由谁签发这份文件、多久内必须交付,以及文件中应该写些什么。
正因如此,LOA 的处理方式其实可以作为判断整体地址资源安排质量的一个很好指标。如果出租方能够快速提供正确的 LOA,一次就准确写明正确的 ASN 和前缀,不需要来回修改三次;当你更换上游时能够迅速重新签发;并且同时保持 ROA 与 route object 一致,那么它实际上正在展示生产环境路由所需要的运营纪律。相反,如果出租方认为 LOA 只是以后再处理的文书工作,那么整个合作关系中的其他环节很可能也会以类似方式处理。文件本身并不复杂,真正重要的是背后的协调能力,而正是这种协调,才能把一段地址空间变成真正可运行的网络基础设施。无论你是租赁还是直接取得地址空间,都应该把路由授权视为一个具有明确期限的正式交付成果,而不是默认它自然会出现。
总结
授权书(LOA)是注册持有者以书面形式授予某个指定方,通过指定 ASN 公告特定前缀的许可。上游服务提供商之所以要求 LOA,是因为仅凭注册数据无法确认公告方是否真正获得授权,而接受未经授权的公告就意味着参与路由劫持。文件会列出持有者、被授权方及 ASN、具体前缀和有效期,并由有权授予该项授权的人签署——它正处于“拥有地址空间”与“能够真正将其路由上线”之间的关键路径上。
最值得记住的区别,是 LOA 能做什么,以及不能做什么。它授权路由公告;它不会转移所有权、不会更改注册信息,也不会授予任何注册管理层面的权利。在租赁关系中,地址空间仍然注册在持有者名下,而租户的公告权来自持有者授予的授权——这也正是为什么 LOA 必须存在,而且必须由持有者出具。再加上由路由器验证的 ROA,以及供过滤系统查询的 route object,LOA 才共同组成将合同权利转化为被网络接受的路由公告所需要的完整记录体系。在部署之前让三者保持一致,在付款之前核实 LOA 的具体内容,才能真正把你已经安排好的地址空间变成可以实际使用的基础设施。
相关阅读
什么是 BGP 劫持?路由劫持如何发生、著名事件以及网络如何防范
RPKI 与 ROA 详解:路由起源授权如何保护你的 IPv4 前缀
什么是 BGP?边界网关协议如何让 IP 地址成为可访问的服务
- 它由持有者签发,而不是由公告方自行签发。 有权授予许可的一方,是地址空间的持有者。租户不能自己给自己写一份 LOA。
- 它必须具有明确的针对性。 文件需要列出具体的前缀以及具体的 ASN。仅仅说明某方“信誉良好”并不能构成 LOA;文件中的内容必须与实际将要公告的内容完全匹配。
为什么上游服务提供商要求 LOA?
服务提供商之所以要求 LOA,是因为接受一个未经授权方发出的路由公告,正是前缀劫持发生的方式——而任何负责任的网络都不希望成为传播这种错误公告的一方。
正如我们在BGP 如何运作的指南中所解释的,路由系统在很大程度上是基于信任接受公告的,而各个网络之所以会过滤接收到的路由,正是因为虚假公告可能将属于其他人的流量重定向。这个风险并不是理论上的:未经授权的路由公告正是我们在BGP 劫持指南中所介绍事件的核心机制。如果上游服务提供商在未核实授权的情况下接受公告,那么它就会无意间成为后续事件的参与者。
LOA 填补的正是一个具体的信息缺口。注册记录可以确认地址持有者,但在租赁情况下,注册记录仍然显示原持有者,而实际进行公告的是另一方——因此,上游服务提供商无法仅通过数据库查询来验证租户。LOA 补上了缺失的这一环:由注册记录中可识别的那一方,以书面形式确认实际进行公告的一方已经获得许可。
在实际部署中,这意味着 LOA 位于整个上线流程的关键路径上。路由器已经配置、租赁协议已经签署、地址块已经分配——这些都无法真正带来可达性,直到上游服务提供商接受这条路由公告,而在没有 LOA 的情况下,上游通常不会接受。
LOA 包含哪些内容?
LOA 会明确授权方、被授权方及其 ASN、具体前缀,以及有权授予该项授权人员的签名。 各家服务提供商通常要求的标准组成部分包括:
- 授权方。 即地址空间的注册持有者,其公司名称和相关资料应与注册记录一致。
- 被授权方和 ASN。 文件需要说明谁被允许公告该地址空间,以及最关键的——将通过哪个自治系统编号进行公告。Cloudflare 的文档明确要求 LOA 同时写明被授权的前缀和公告所使用的 ASN——ASN 并不是可有可无的附加信息。
- 准确的前缀。 必须精确列出受授权覆盖的地址块(例如某个具体的 /24)。任何超出 LOA 所列范围的公告,都不属于该授权范围。
- 有效期。 授权的持续时间。对于租赁地址空间,其有效期应与租赁期限保持一致。
- 授权签署人。 包括姓名、职位以及有权代表持有者签署文件的人员签名,并附上联系方式,以便上游服务提供商在有需要时进行核实。
- 公司抬头和文件格式。 LOA 通常应以持有者公司的正式抬头纸制作。Cloudflare 指出,Transit 服务提供商可能会拒绝以图片格式提交的 LOA,而要求使用 PDF;数字签名通常可以接受,但签署人必须能够被清楚识别。
这些要求并不是毫无意义的行政装饰。公司抬头、与注册记录一致的企业资料,以及可识别的授权签署人,正是接收方用于确认文件真实性,以及签署人确实有权授予所声称授权的依据。
什么时候需要 LOA?
只要将由注册持有者以外的一方公告地址空间,通常都需要 LOA——这涵盖了绝大多数 IPv4 租赁、BYOIP 和由服务提供商代为公告的情况。 常见场景包括:
- 通过自己的 ASN 公告租赁的 IPv4。 这是最典型的情况:你租赁了一个地址块,并自行对外公告,因此你的上游需要看到持有者提供的授权。关于这个更完整的租赁流程,可以参考我们的IPv4 租赁指南以及IP 地址租赁如何运作的说明。
- 由服务提供商代表你公告地址空间。 当你的托管服务商、数据中心或平台通过其 ASN 公告你的前缀时,它需要获得你的授权——而它的上游同样需要看到这一授权。
- BYOIP 接入。 将自有 IP 地址空间(BYOIP)带入云平台或边缘平台时,需要授权该平台公告你的前缀,Cloudflare 的要求就是一个典型例子。
- 紧急路由变更。 例如 DDoS 清洗服务,在攻击发生时由服务提供商临时公告你的前缀,这类安排依赖于事先完成授权——这一点我们也在DDoS 缓解指南中进行了介绍。
判断标准其实很简单:如果进行公告的 ASN 并不属于注册持有者本身,那么几乎可以确定需要 LOA。
LOA vs ROA vs IRR Route Object
LOA、ROA 和 IRR route object 都在说明谁可以公告某个前缀——但它们面对不同的受众、采用不同形式,并且作用于不同层面。 它们彼此互补,而不是相互替代。一个正确部署的前缀,通常需要三者保持一致。
LOA vs ROA vs IRR Route Object
项目
LOA
ROA
IRR route object
它是什么
授予路由公告权限的签署文件
RPKI 中经过加密签名的记录
Internet Routing Registry 数据库中的记录
面向对象
人员——上游开通和 NOC 工作人员
执行路由起源验证的路由器
自动生成过滤规则的系统
形式
人类可读、合同性质
加密签名、机器验证
数据库记录
由谁创建
注册持有者(或授权代表)
注册持有者,通过其 RIR 创建
对象的持有者或 maintainer
缺失或错误时的影响
上游拒绝配置该路由公告
公告可能被执行 RPKI 验证的网络判定为 RPKI-Invalid 并拒绝
使用 IRR 数据生成过滤规则的服务提供商可能过滤该公告
最清楚的理解方式是:LOA 决定你的上游工作人员是否愿意配置并接受这项公告;ROA 决定互联网上执行验证的路由器是否认为该起源 ASN 合法;route object 则影响自动化过滤系统是否允许该公告通过。三者都可能独立出现问题,而且每一种失败都会产生不同的症状——这也是为什么部署有时会以看似完全不同的方式卡住,取决于究竟缺少哪一项记录。
这三者之间的互动也越来越紧密。例如,Cloudflare 的自动生成 LOA 流程会依赖经过 RPKI 签名的 ROA 以及所有权验证检查——也就是说,加密记录用于支持这份人工文件,而不是取代它。关于 ROA 的具体机制,包括它如何授权某个特定的起源 ASN,以及配置错误时会发生什么,请参阅我们的RPKI 和 ROA指南。
谁可以合法签发 LOA?
只有地址空间的注册持有者——或者被授权代表该持有者行事的人——才有资格合法签发 LOA。 这一点必须非常准确地说明,因为现实中经常有人把相关概念混淆。
有三个概念值得明确区分:
- LOA 授权的是公告,并不转移所有权。 签署 LOA 只是授予对地址空间进行路由的许可。它不会让被授权方成为该地址空间的持有者,不会更改注册记录,也不会转移任何注册管理层面的权利。当授权终止时,该项公告权限也随之终止。
- 在整个租赁期间,注册信息仍然保留在持有者名下。 在租赁安排中,注册管理机构的记录会继续显示原持有者为注册方。这并不是租赁关系中的漏洞——这正是租赁模式本身的结构。租户的公告权来自所获得的授权,而不是来自注册信息的改变。
- 进行公告不等于持有地址空间。 一个网络公告某个前缀,意味着它正在作为起源网络发布该前缀,这反映的是它获得了授权。公告本身并不能证明所有权。这种区分在概念和实际操作上都非常重要,因为未经授权的公告本身正是路由劫持的定义之一。
对于接收公告的上游服务提供商来说,这些区别最终会转化成一个验证问题:签署人真的拥有他们所声称的授权权力吗?这就是为什么 LOA 通常需要使用持有者的公司抬头纸、公司资料必须与注册记录相符,并由身份和职位明确的人签署。任何无法追溯到注册持有者的文件,都不能算真正的授权——那只能算是一项单方面声明。
LOA 与租赁 IPv4:付款之前应该核实什么?
由于 LOA 位于路由上线流程的关键路径上,因此应该在付款之前确认其处理方式,而不是付款之后才发现问题。 这个失败模式在行业中非常常见:企业签署了租赁协议、配置好路由、通知了上游,然后才被要求提供一份租赁协议中从未提及、而出租方又迟迟无法出具的 LOA。在文件到达之前,地址已经付费,却无法使用。
以下事项应当提前确认:
- 付款前取得 LOA,或者取得书面的交付承诺。 最好直接拿到文件;如果做不到,也应在协议中明确规定,必须在一个确定且较短的时间内交付。如果出租方连这两者中的任何一种都不愿意承诺,那已经说明了后续合作关系可能会是什么样子。
- 确认 LOA 中列出了正确的前缀。 应当准确列出你实际租赁的地址块。LOA 如果覆盖了不同地址块或过大的范围,上游可能会提出质疑;如果覆盖范围小于你所需,也无法授权剩余部分。
- 确认 LOA 中列出了正确的 ASN。 必须是实际会成为起源网络的 ASN——根据你的部署方式,这可能是你自己的 ASN,也可能是上游的 ASN。错误的 ASN 是一份形式上有效的 LOA 仍然无法帮助部署上线的最常见原因之一。
- 核对有效期与租赁期限。 如果授权比租赁期限更早到期,就会在部署过程中产生重新签发 LOA 的依赖。
- 确认文件确实来自注册持有者。 公司抬头和企业资料应与注册记录一致,并由可以识别且确实有授权权限的人签署。
- 确认重新签发流程。 如果你更换上游、更换 ASN,或需要为第二家服务提供商增加一份 LOA,更新文件最快可以在多久内提供?实际部署会发生变化,而授权文件必须能够同步更新。
- 询问 LOA 如何与 ROA 和 route object 配合。 单独拥有 LOA 并不够——正如上面的比较所示,ROA 和 IRR 记录也必须保持一致。能够完整处理这三项内容的出租方,比只提供一份文件然后把其余事情全部交给你的出租方,更适合生产环境部署。
这些问题在签约之前提出几乎没有成本,但签约之后才提出往往代价高昂。综合来看,它们也是判断租赁质量非常可靠的信号:如果一个地址安排将路由授权明确视为具有交付期限的正式交付成果,那么它通常是按照生产环境需求设计的;反之,如果把授权当成事后再处理的细节,那么这个问题往往会在最糟糕的时候暴露出来。
常见 LOA 问题
大多数 LOA 问题并不是围绕授权本身产生争议,而是文件交付太迟、内容错误或已经过期。 常见情况包括:
- 交付延迟。 这是最常见、也是成本最高的问题。只要文件一天没有到位,地址空间就一天无法正常公告,无论其他部分准备得多么充分。
- ASN 错误。 LOA 授权了一个与实际发起公告不同的 ASN——通常是因为文件起草之后部署方案发生变化,或出租方误解了租户的上游安排。
- 前缀错误或不够准确。 文件列出的地址块不正确、范围比协议约定更大,或者描述过于模糊,以至于上游不愿据此配置路由。
- 授权已经过期。 有效期已经结束,通常是在服务提供商重新审核文件,或租赁期内新增上游时才被发现。
- 签署人没有授权或无法验证。 文件由上游无法确认其权限的人签署,或者文件本身无法明确关联到注册持有者。
- 协议中完全没有规定 LOA。 租赁协议完全没有提到 LOA 的签发,因此交付时间和责任都没有定义——而交付延迟问题通常就是从这里开始。
这六类问题都可以在协议阶段提前避免,这也是为什么上面的核实清单比事后进行任何故障排查都更加重要。
实用检查清单
- 在签署协议之前,确认协议明确要求持有者签发 LOA,并规定具体交付时间。
- 在付款之前取得 LOA,或者至少取得书面的交付保证。
- 核实准确的前缀与实际租赁或取得的地址块完全一致。
- 核实 ASN 与实际将作为起源网络进行公告的 ASN 完全一致。
- 检查有效期是否覆盖整个租赁或部署周期。
- 确认文件使用注册持有者的正式公司抬头,企业资料与注册记录一致,并有可以识别的授权签署人。
- 按照上游要求的格式提交——PDF 是最稳妥的默认选择;图片格式经常会被拒绝。
- 确认如果上游、ASN 或授权范围发生变化,重新签发的流程以及处理时间。
- 确保 LOA、ROA 和 IRR route object 保持一致,让三种授权记录不会互相冲突。
- 保存一份副本——增加其他服务提供商、进行审计或未来修改部署时,都可能再次需要。
来自 i.lease 的实用说明
LOA 是一份很小的文件,但其运营影响远远超过文件本身的复杂程度。它在技术上并不复杂,只要有权签署的人愿意配合,通常几分钟就可以制作出来,但它却是租赁或新取得的地址块已经付费、却迟迟无法投入使用的最常见原因之一。问题几乎从来不是真正存在授权争议,而是协议签署之前没有人明确规定:由谁签发这份文件、多久内必须交付,以及文件中应该写些什么。
正因如此,LOA 的处理方式其实可以作为判断整体地址资源安排质量的一个很好指标。如果出租方能够快速提供正确的 LOA,一次就准确写明正确的 ASN 和前缀,不需要来回修改三次;当你更换上游时能够迅速重新签发;并且同时保持 ROA 与 route object 一致,那么它实际上正在展示生产环境路由所需要的运营纪律。相反,如果出租方认为 LOA 只是以后再处理的文书工作,那么整个合作关系中的其他环节很可能也会以类似方式处理。文件本身并不复杂,真正重要的是背后的协调能力,而正是这种协调,才能把一段地址空间变成真正可运行的网络基础设施。无论你是租赁还是直接取得地址空间,都应该把路由授权视为一个具有明确期限的正式交付成果,而不是默认它自然会出现。
总结
授权书(LOA)是注册持有者以书面形式授予某个指定方,通过指定 ASN 公告特定前缀的许可。上游服务提供商之所以要求 LOA,是因为仅凭注册数据无法确认公告方是否真正获得授权,而接受未经授权的公告就意味着参与路由劫持。文件会列出持有者、被授权方及 ASN、具体前缀和有效期,并由有权授予该项授权的人签署——它正处于“拥有地址空间”与“能够真正将其路由上线”之间的关键路径上。
最值得记住的区别,是 LOA 能做什么,以及不能做什么。它授权路由公告;它不会转移所有权、不会更改注册信息,也不会授予任何注册管理层面的权利。在租赁关系中,地址空间仍然注册在持有者名下,而租户的公告权来自持有者授予的授权——这也正是为什么 LOA 必须存在,而且必须由持有者出具。再加上由路由器验证的 ROA,以及供过滤系统查询的 route object,LOA 才共同组成将合同权利转化为被网络接受的路由公告所需要的完整记录体系。在部署之前让三者保持一致,在付款之前核实 LOA 的具体内容,才能真正把你已经安排好的地址空间变成可以实际使用的基础设施。
相关阅读
什么是 BGP 劫持?路由劫持如何发生、著名事件以及网络如何防范
RPKI 与 ROA 详解:路由起源授权如何保护你的 IPv4 前缀
什么是 BGP?边界网关协议如何让 IP 地址成为可访问的服务
- LOA 授权的是公告,并不转移所有权。 签署 LOA 只是授予对地址空间进行路由的许可。它不会让被授权方成为该地址空间的持有者,不会更改注册记录,也不会转移任何注册管理层面的权利。当授权终止时,该项公告权限也随之终止。
- 在整个租赁期间,注册信息仍然保留在持有者名下。 在租赁安排中,注册管理机构的记录会继续显示原持有者为注册方。这并不是租赁关系中的漏洞——这正是租赁模式本身的结构。租户的公告权来自所获得的授权,而不是来自注册信息的改变。
- 进行公告不等于持有地址空间。 一个网络公告某个前缀,意味着它正在作为起源网络发布该前缀,这反映的是它获得了授权。公告本身并不能证明所有权。这种区分在概念和实际操作上都非常重要,因为未经授权的公告本身正是路由劫持的定义之一。
对于接收公告的上游服务提供商来说,这些区别最终会转化成一个验证问题:签署人真的拥有他们所声称的授权权力吗?这就是为什么 LOA 通常需要使用持有者的公司抬头纸、公司资料必须与注册记录相符,并由身份和职位明确的人签署。任何无法追溯到注册持有者的文件,都不能算真正的授权——那只能算是一项单方面声明。
LOA 与租赁 IPv4:付款之前应该核实什么?
由于 LOA 位于路由上线流程的关键路径上,因此应该在付款之前确认其处理方式,而不是付款之后才发现问题。 这个失败模式在行业中非常常见:企业签署了租赁协议、配置好路由、通知了上游,然后才被要求提供一份租赁协议中从未提及、而出租方又迟迟无法出具的 LOA。在文件到达之前,地址已经付费,却无法使用。
以下事项应当提前确认:
- 付款前取得 LOA,或者取得书面的交付承诺。 最好直接拿到文件;如果做不到,也应在协议中明确规定,必须在一个确定且较短的时间内交付。如果出租方连这两者中的任何一种都不愿意承诺,那已经说明了后续合作关系可能会是什么样子。
- 确认 LOA 中列出了正确的前缀。 应当准确列出你实际租赁的地址块。LOA 如果覆盖了不同地址块或过大的范围,上游可能会提出质疑;如果覆盖范围小于你所需,也无法授权剩余部分。
- 确认 LOA 中列出了正确的 ASN。 必须是实际会成为起源网络的 ASN——根据你的部署方式,这可能是你自己的 ASN,也可能是上游的 ASN。错误的 ASN 是一份形式上有效的 LOA 仍然无法帮助部署上线的最常见原因之一。
- 核对有效期与租赁期限。 如果授权比租赁期限更早到期,就会在部署过程中产生重新签发 LOA 的依赖。
- 确认文件确实来自注册持有者。 公司抬头和企业资料应与注册记录一致,并由可以识别且确实有授权权限的人签署。
- 确认重新签发流程。 如果你更换上游、更换 ASN,或需要为第二家服务提供商增加一份 LOA,更新文件最快可以在多久内提供?实际部署会发生变化,而授权文件必须能够同步更新。
- 询问 LOA 如何与 ROA 和 route object 配合。 单独拥有 LOA 并不够——正如上面的比较所示,ROA 和 IRR 记录也必须保持一致。能够完整处理这三项内容的出租方,比只提供一份文件然后把其余事情全部交给你的出租方,更适合生产环境部署。
这些问题在签约之前提出几乎没有成本,但签约之后才提出往往代价高昂。综合来看,它们也是判断租赁质量非常可靠的信号:如果一个地址安排将路由授权明确视为具有交付期限的正式交付成果,那么它通常是按照生产环境需求设计的;反之,如果把授权当成事后再处理的细节,那么这个问题往往会在最糟糕的时候暴露出来。
常见 LOA 问题
大多数 LOA 问题并不是围绕授权本身产生争议,而是文件交付太迟、内容错误或已经过期。 常见情况包括:
- 交付延迟。 这是最常见、也是成本最高的问题。只要文件一天没有到位,地址空间就一天无法正常公告,无论其他部分准备得多么充分。
- ASN 错误。 LOA 授权了一个与实际发起公告不同的 ASN——通常是因为文件起草之后部署方案发生变化,或出租方误解了租户的上游安排。
- 前缀错误或不够准确。 文件列出的地址块不正确、范围比协议约定更大,或者描述过于模糊,以至于上游不愿据此配置路由。
- 授权已经过期。 有效期已经结束,通常是在服务提供商重新审核文件,或租赁期内新增上游时才被发现。
- 签署人没有授权或无法验证。 文件由上游无法确认其权限的人签署,或者文件本身无法明确关联到注册持有者。
- 协议中完全没有规定 LOA。 租赁协议完全没有提到 LOA 的签发,因此交付时间和责任都没有定义——而交付延迟问题通常就是从这里开始。
这六类问题都可以在协议阶段提前避免,这也是为什么上面的核实清单比事后进行任何故障排查都更加重要。
实用检查清单
- 在签署协议之前,确认协议明确要求持有者签发 LOA,并规定具体交付时间。
- 在付款之前取得 LOA,或者至少取得书面的交付保证。
- 核实准确的前缀与实际租赁或取得的地址块完全一致。
- 核实 ASN 与实际将作为起源网络进行公告的 ASN 完全一致。
- 检查有效期是否覆盖整个租赁或部署周期。
- 确认文件使用注册持有者的正式公司抬头,企业资料与注册记录一致,并有可以识别的授权签署人。
- 按照上游要求的格式提交——PDF 是最稳妥的默认选择;图片格式经常会被拒绝。
- 确认如果上游、ASN 或授权范围发生变化,重新签发的流程以及处理时间。
- 确保 LOA、ROA 和 IRR route object 保持一致,让三种授权记录不会互相冲突。
- 保存一份副本——增加其他服务提供商、进行审计或未来修改部署时,都可能再次需要。
来自 i.lease 的实用说明
LOA 是一份很小的文件,但其运营影响远远超过文件本身的复杂程度。它在技术上并不复杂,只要有权签署的人愿意配合,通常几分钟就可以制作出来,但它却是租赁或新取得的地址块已经付费、却迟迟无法投入使用的最常见原因之一。问题几乎从来不是真正存在授权争议,而是协议签署之前没有人明确规定:由谁签发这份文件、多久内必须交付,以及文件中应该写些什么。
正因如此,LOA 的处理方式其实可以作为判断整体地址资源安排质量的一个很好指标。如果出租方能够快速提供正确的 LOA,一次就准确写明正确的 ASN 和前缀,不需要来回修改三次;当你更换上游时能够迅速重新签发;并且同时保持 ROA 与 route object 一致,那么它实际上正在展示生产环境路由所需要的运营纪律。相反,如果出租方认为 LOA 只是以后再处理的文书工作,那么整个合作关系中的其他环节很可能也会以类似方式处理。文件本身并不复杂,真正重要的是背后的协调能力,而正是这种协调,才能把一段地址空间变成真正可运行的网络基础设施。无论你是租赁还是直接取得地址空间,都应该把路由授权视为一个具有明确期限的正式交付成果,而不是默认它自然会出现。
总结
授权书(LOA)是注册持有者以书面形式授予某个指定方,通过指定 ASN 公告特定前缀的许可。上游服务提供商之所以要求 LOA,是因为仅凭注册数据无法确认公告方是否真正获得授权,而接受未经授权的公告就意味着参与路由劫持。文件会列出持有者、被授权方及 ASN、具体前缀和有效期,并由有权授予该项授权的人签署——它正处于“拥有地址空间”与“能够真正将其路由上线”之间的关键路径上。
最值得记住的区别,是 LOA 能做什么,以及不能做什么。它授权路由公告;它不会转移所有权、不会更改注册信息,也不会授予任何注册管理层面的权利。在租赁关系中,地址空间仍然注册在持有者名下,而租户的公告权来自持有者授予的授权——这也正是为什么 LOA 必须存在,而且必须由持有者出具。再加上由路由器验证的 ROA,以及供过滤系统查询的 route object,LOA 才共同组成将合同权利转化为被网络接受的路由公告所需要的完整记录体系。在部署之前让三者保持一致,在付款之前核实 LOA 的具体内容,才能真正把你已经安排好的地址空间变成可以实际使用的基础设施。
相关阅读
什么是 BGP 劫持?路由劫持如何发生、著名事件以及网络如何防范
RPKI 与 ROA 详解:路由起源授权如何保护你的 IPv4 前缀
什么是 BGP?边界网关协议如何让 IP 地址成为可访问的服务
- 授权方。 即地址空间的注册持有者,其公司名称和相关资料应与注册记录一致。
- 被授权方和 ASN。 文件需要说明谁被允许公告该地址空间,以及最关键的——将通过哪个自治系统编号进行公告。Cloudflare 的文档明确要求 LOA 同时写明被授权的前缀和公告所使用的 ASN——ASN 并不是可有可无的附加信息。
- 准确的前缀。 必须精确列出受授权覆盖的地址块(例如某个具体的 /24)。任何超出 LOA 所列范围的公告,都不属于该授权范围。
- 有效期。 授权的持续时间。对于租赁地址空间,其有效期应与租赁期限保持一致。
- 授权签署人。 包括姓名、职位以及有权代表持有者签署文件的人员签名,并附上联系方式,以便上游服务提供商在有需要时进行核实。
- 公司抬头和文件格式。 LOA 通常应以持有者公司的正式抬头纸制作。Cloudflare 指出,Transit 服务提供商可能会拒绝以图片格式提交的 LOA,而要求使用 PDF;数字签名通常可以接受,但签署人必须能够被清楚识别。
这些要求并不是毫无意义的行政装饰。公司抬头、与注册记录一致的企业资料,以及可识别的授权签署人,正是接收方用于确认文件真实性,以及签署人确实有权授予所声称授权的依据。
什么时候需要 LOA?
只要将由注册持有者以外的一方公告地址空间,通常都需要 LOA——这涵盖了绝大多数 IPv4 租赁、BYOIP 和由服务提供商代为公告的情况。 常见场景包括:
- 通过自己的 ASN 公告租赁的 IPv4。 这是最典型的情况:你租赁了一个地址块,并自行对外公告,因此你的上游需要看到持有者提供的授权。关于这个更完整的租赁流程,可以参考我们的IPv4 租赁指南以及IP 地址租赁如何运作的说明。
- 由服务提供商代表你公告地址空间。 当你的托管服务商、数据中心或平台通过其 ASN 公告你的前缀时,它需要获得你的授权——而它的上游同样需要看到这一授权。
- BYOIP 接入。 将自有 IP 地址空间(BYOIP)带入云平台或边缘平台时,需要授权该平台公告你的前缀,Cloudflare 的要求就是一个典型例子。
- 紧急路由变更。 例如 DDoS 清洗服务,在攻击发生时由服务提供商临时公告你的前缀,这类安排依赖于事先完成授权——这一点我们也在DDoS 缓解指南中进行了介绍。
判断标准其实很简单:如果进行公告的 ASN 并不属于注册持有者本身,那么几乎可以确定需要 LOA。
LOA vs ROA vs IRR Route Object
LOA、ROA 和 IRR route object 都在说明谁可以公告某个前缀——但它们面对不同的受众、采用不同形式,并且作用于不同层面。 它们彼此互补,而不是相互替代。一个正确部署的前缀,通常需要三者保持一致。
LOA vs ROA vs IRR Route Object
项目
LOA
ROA
IRR route object
它是什么
授予路由公告权限的签署文件
RPKI 中经过加密签名的记录
Internet Routing Registry 数据库中的记录
面向对象
人员——上游开通和 NOC 工作人员
执行路由起源验证的路由器
自动生成过滤规则的系统
形式
人类可读、合同性质
加密签名、机器验证
数据库记录
由谁创建
注册持有者(或授权代表)
注册持有者,通过其 RIR 创建
对象的持有者或 maintainer
缺失或错误时的影响
上游拒绝配置该路由公告
公告可能被执行 RPKI 验证的网络判定为 RPKI-Invalid 并拒绝
使用 IRR 数据生成过滤规则的服务提供商可能过滤该公告
最清楚的理解方式是:LOA 决定你的上游工作人员是否愿意配置并接受这项公告;ROA 决定互联网上执行验证的路由器是否认为该起源 ASN 合法;route object 则影响自动化过滤系统是否允许该公告通过。三者都可能独立出现问题,而且每一种失败都会产生不同的症状——这也是为什么部署有时会以看似完全不同的方式卡住,取决于究竟缺少哪一项记录。
这三者之间的互动也越来越紧密。例如,Cloudflare 的自动生成 LOA 流程会依赖经过 RPKI 签名的 ROA 以及所有权验证检查——也就是说,加密记录用于支持这份人工文件,而不是取代它。关于 ROA 的具体机制,包括它如何授权某个特定的起源 ASN,以及配置错误时会发生什么,请参阅我们的RPKI 和 ROA指南。
谁可以合法签发 LOA?
只有地址空间的注册持有者——或者被授权代表该持有者行事的人——才有资格合法签发 LOA。 这一点必须非常准确地说明,因为现实中经常有人把相关概念混淆。
有三个概念值得明确区分:
- LOA 授权的是公告,并不转移所有权。 签署 LOA 只是授予对地址空间进行路由的许可。它不会让被授权方成为该地址空间的持有者,不会更改注册记录,也不会转移任何注册管理层面的权利。当授权终止时,该项公告权限也随之终止。
- 在整个租赁期间,注册信息仍然保留在持有者名下。 在租赁安排中,注册管理机构的记录会继续显示原持有者为注册方。这并不是租赁关系中的漏洞——这正是租赁模式本身的结构。租户的公告权来自所获得的授权,而不是来自注册信息的改变。
- 进行公告不等于持有地址空间。 一个网络公告某个前缀,意味着它正在作为起源网络发布该前缀,这反映的是它获得了授权。公告本身并不能证明所有权。这种区分在概念和实际操作上都非常重要,因为未经授权的公告本身正是路由劫持的定义之一。
对于接收公告的上游服务提供商来说,这些区别最终会转化成一个验证问题:签署人真的拥有他们所声称的授权权力吗?这就是为什么 LOA 通常需要使用持有者的公司抬头纸、公司资料必须与注册记录相符,并由身份和职位明确的人签署。任何无法追溯到注册持有者的文件,都不能算真正的授权——那只能算是一项单方面声明。
LOA 与租赁 IPv4:付款之前应该核实什么?
由于 LOA 位于路由上线流程的关键路径上,因此应该在付款之前确认其处理方式,而不是付款之后才发现问题。 这个失败模式在行业中非常常见:企业签署了租赁协议、配置好路由、通知了上游,然后才被要求提供一份租赁协议中从未提及、而出租方又迟迟无法出具的 LOA。在文件到达之前,地址已经付费,却无法使用。
以下事项应当提前确认:
- 付款前取得 LOA,或者取得书面的交付承诺。 最好直接拿到文件;如果做不到,也应在协议中明确规定,必须在一个确定且较短的时间内交付。如果出租方连这两者中的任何一种都不愿意承诺,那已经说明了后续合作关系可能会是什么样子。
- 确认 LOA 中列出了正确的前缀。 应当准确列出你实际租赁的地址块。LOA 如果覆盖了不同地址块或过大的范围,上游可能会提出质疑;如果覆盖范围小于你所需,也无法授权剩余部分。
- 确认 LOA 中列出了正确的 ASN。 必须是实际会成为起源网络的 ASN——根据你的部署方式,这可能是你自己的 ASN,也可能是上游的 ASN。错误的 ASN 是一份形式上有效的 LOA 仍然无法帮助部署上线的最常见原因之一。
- 核对有效期与租赁期限。 如果授权比租赁期限更早到期,就会在部署过程中产生重新签发 LOA 的依赖。
- 确认文件确实来自注册持有者。 公司抬头和企业资料应与注册记录一致,并由可以识别且确实有授权权限的人签署。
- 确认重新签发流程。 如果你更换上游、更换 ASN,或需要为第二家服务提供商增加一份 LOA,更新文件最快可以在多久内提供?实际部署会发生变化,而授权文件必须能够同步更新。
- 询问 LOA 如何与 ROA 和 route object 配合。 单独拥有 LOA 并不够——正如上面的比较所示,ROA 和 IRR 记录也必须保持一致。能够完整处理这三项内容的出租方,比只提供一份文件然后把其余事情全部交给你的出租方,更适合生产环境部署。
这些问题在签约之前提出几乎没有成本,但签约之后才提出往往代价高昂。综合来看,它们也是判断租赁质量非常可靠的信号:如果一个地址安排将路由授权明确视为具有交付期限的正式交付成果,那么它通常是按照生产环境需求设计的;反之,如果把授权当成事后再处理的细节,那么这个问题往往会在最糟糕的时候暴露出来。
常见 LOA 问题
大多数 LOA 问题并不是围绕授权本身产生争议,而是文件交付太迟、内容错误或已经过期。 常见情况包括:
- 交付延迟。 这是最常见、也是成本最高的问题。只要文件一天没有到位,地址空间就一天无法正常公告,无论其他部分准备得多么充分。
- ASN 错误。 LOA 授权了一个与实际发起公告不同的 ASN——通常是因为文件起草之后部署方案发生变化,或出租方误解了租户的上游安排。
- 前缀错误或不够准确。 文件列出的地址块不正确、范围比协议约定更大,或者描述过于模糊,以至于上游不愿据此配置路由。
- 授权已经过期。 有效期已经结束,通常是在服务提供商重新审核文件,或租赁期内新增上游时才被发现。
- 签署人没有授权或无法验证。 文件由上游无法确认其权限的人签署,或者文件本身无法明确关联到注册持有者。
- 协议中完全没有规定 LOA。 租赁协议完全没有提到 LOA 的签发,因此交付时间和责任都没有定义——而交付延迟问题通常就是从这里开始。
这六类问题都可以在协议阶段提前避免,这也是为什么上面的核实清单比事后进行任何故障排查都更加重要。
实用检查清单
- 在签署协议之前,确认协议明确要求持有者签发 LOA,并规定具体交付时间。
- 在付款之前取得 LOA,或者至少取得书面的交付保证。
- 核实准确的前缀与实际租赁或取得的地址块完全一致。
- 核实 ASN 与实际将作为起源网络进行公告的 ASN 完全一致。
- 检查有效期是否覆盖整个租赁或部署周期。
- 确认文件使用注册持有者的正式公司抬头,企业资料与注册记录一致,并有可以识别的授权签署人。
- 按照上游要求的格式提交——PDF 是最稳妥的默认选择;图片格式经常会被拒绝。
- 确认如果上游、ASN 或授权范围发生变化,重新签发的流程以及处理时间。
- 确保 LOA、ROA 和 IRR route object 保持一致,让三种授权记录不会互相冲突。
- 保存一份副本——增加其他服务提供商、进行审计或未来修改部署时,都可能再次需要。
来自 i.lease 的实用说明
LOA 是一份很小的文件,但其运营影响远远超过文件本身的复杂程度。它在技术上并不复杂,只要有权签署的人愿意配合,通常几分钟就可以制作出来,但它却是租赁或新取得的地址块已经付费、却迟迟无法投入使用的最常见原因之一。问题几乎从来不是真正存在授权争议,而是协议签署之前没有人明确规定:由谁签发这份文件、多久内必须交付,以及文件中应该写些什么。
正因如此,LOA 的处理方式其实可以作为判断整体地址资源安排质量的一个很好指标。如果出租方能够快速提供正确的 LOA,一次就准确写明正确的 ASN 和前缀,不需要来回修改三次;当你更换上游时能够迅速重新签发;并且同时保持 ROA 与 route object 一致,那么它实际上正在展示生产环境路由所需要的运营纪律。相反,如果出租方认为 LOA 只是以后再处理的文书工作,那么整个合作关系中的其他环节很可能也会以类似方式处理。文件本身并不复杂,真正重要的是背后的协调能力,而正是这种协调,才能把一段地址空间变成真正可运行的网络基础设施。无论你是租赁还是直接取得地址空间,都应该把路由授权视为一个具有明确期限的正式交付成果,而不是默认它自然会出现。
总结
授权书(LOA)是注册持有者以书面形式授予某个指定方,通过指定 ASN 公告特定前缀的许可。上游服务提供商之所以要求 LOA,是因为仅凭注册数据无法确认公告方是否真正获得授权,而接受未经授权的公告就意味着参与路由劫持。文件会列出持有者、被授权方及 ASN、具体前缀和有效期,并由有权授予该项授权的人签署——它正处于“拥有地址空间”与“能够真正将其路由上线”之间的关键路径上。
最值得记住的区别,是 LOA 能做什么,以及不能做什么。它授权路由公告;它不会转移所有权、不会更改注册信息,也不会授予任何注册管理层面的权利。在租赁关系中,地址空间仍然注册在持有者名下,而租户的公告权来自持有者授予的授权——这也正是为什么 LOA 必须存在,而且必须由持有者出具。再加上由路由器验证的 ROA,以及供过滤系统查询的 route object,LOA 才共同组成将合同权利转化为被网络接受的路由公告所需要的完整记录体系。在部署之前让三者保持一致,在付款之前核实 LOA 的具体内容,才能真正把你已经安排好的地址空间变成可以实际使用的基础设施。
相关阅读
什么是 BGP 劫持?路由劫持如何发生、著名事件以及网络如何防范
RPKI 与 ROA 详解:路由起源授权如何保护你的 IPv4 前缀
什么是 BGP?边界网关协议如何让 IP 地址成为可访问的服务
- 它由持有者签发,而不是由公告方自行签发。 有权授予许可的一方,是地址空间的持有者。租户不能自己给自己写一份 LOA。
- 它必须具有明确的针对性。 文件需要列出具体的前缀以及具体的 ASN。仅仅说明某方“信誉良好”并不能构成 LOA;文件中的内容必须与实际将要公告的内容完全匹配。
为什么上游服务提供商要求 LOA?
服务提供商之所以要求 LOA,是因为接受一个未经授权方发出的路由公告,正是前缀劫持发生的方式——而任何负责任的网络都不希望成为传播这种错误公告的一方。
正如我们在BGP 如何运作的指南中所解释的,路由系统在很大程度上是基于信任接受公告的,而各个网络之所以会过滤接收到的路由,正是因为虚假公告可能将属于其他人的流量重定向。这个风险并不是理论上的:未经授权的路由公告正是我们在BGP 劫持指南中所介绍事件的核心机制。如果上游服务提供商在未核实授权的情况下接受公告,那么它就会无意间成为后续事件的参与者。
LOA 填补的正是一个具体的信息缺口。注册记录可以确认地址持有者,但在租赁情况下,注册记录仍然显示原持有者,而实际进行公告的是另一方——因此,上游服务提供商无法仅通过数据库查询来验证租户。LOA 补上了缺失的这一环:由注册记录中可识别的那一方,以书面形式确认实际进行公告的一方已经获得许可。
在实际部署中,这意味着 LOA 位于整个上线流程的关键路径上。路由器已经配置、租赁协议已经签署、地址块已经分配——这些都无法真正带来可达性,直到上游服务提供商接受这条路由公告,而在没有 LOA 的情况下,上游通常不会接受。
LOA 包含哪些内容?
LOA 会明确授权方、被授权方及其 ASN、具体前缀,以及有权授予该项授权人员的签名。 各家服务提供商通常要求的标准组成部分包括:
- 授权方。 即地址空间的注册持有者,其公司名称和相关资料应与注册记录一致。
- 被授权方和 ASN。 文件需要说明谁被允许公告该地址空间,以及最关键的——将通过哪个自治系统编号进行公告。Cloudflare 的文档明确要求 LOA 同时写明被授权的前缀和公告所使用的 ASN——ASN 并不是可有可无的附加信息。
- 准确的前缀。 必须精确列出受授权覆盖的地址块(例如某个具体的 /24)。任何超出 LOA 所列范围的公告,都不属于该授权范围。
- 有效期。 授权的持续时间。对于租赁地址空间,其有效期应与租赁期限保持一致。
- 授权签署人。 包括姓名、职位以及有权代表持有者签署文件的人员签名,并附上联系方式,以便上游服务提供商在有需要时进行核实。
- 公司抬头和文件格式。 LOA 通常应以持有者公司的正式抬头纸制作。Cloudflare 指出,Transit 服务提供商可能会拒绝以图片格式提交的 LOA,而要求使用 PDF;数字签名通常可以接受,但签署人必须能够被清楚识别。
这些要求并不是毫无意义的行政装饰。公司抬头、与注册记录一致的企业资料,以及可识别的授权签署人,正是接收方用于确认文件真实性,以及签署人确实有权授予所声称授权的依据。
什么时候需要 LOA?
只要将由注册持有者以外的一方公告地址空间,通常都需要 LOA——这涵盖了绝大多数 IPv4 租赁、BYOIP 和由服务提供商代为公告的情况。 常见场景包括:
- 通过自己的 ASN 公告租赁的 IPv4。 这是最典型的情况:你租赁了一个地址块,并自行对外公告,因此你的上游需要看到持有者提供的授权。关于这个更完整的租赁流程,可以参考我们的IPv4 租赁指南以及IP 地址租赁如何运作的说明。
- 由服务提供商代表你公告地址空间。 当你的托管服务商、数据中心或平台通过其 ASN 公告你的前缀时,它需要获得你的授权——而它的上游同样需要看到这一授权。
- BYOIP 接入。 将自有 IP 地址空间(BYOIP)带入云平台或边缘平台时,需要授权该平台公告你的前缀,Cloudflare 的要求就是一个典型例子。
- 紧急路由变更。 例如 DDoS 清洗服务,在攻击发生时由服务提供商临时公告你的前缀,这类安排依赖于事先完成授权——这一点我们也在DDoS 缓解指南中进行了介绍。
判断标准其实很简单:如果进行公告的 ASN 并不属于注册持有者本身,那么几乎可以确定需要 LOA。
LOA vs ROA vs IRR Route Object
LOA、ROA 和 IRR route object 都在说明谁可以公告某个前缀——但它们面对不同的受众、采用不同形式,并且作用于不同层面。 它们彼此互补,而不是相互替代。一个正确部署的前缀,通常需要三者保持一致。
LOA vs ROA vs IRR Route Object
项目
LOA
ROA
IRR route object
它是什么
授予路由公告权限的签署文件
RPKI 中经过加密签名的记录
Internet Routing Registry 数据库中的记录
面向对象
人员——上游开通和 NOC 工作人员
执行路由起源验证的路由器
自动生成过滤规则的系统
形式
人类可读、合同性质
加密签名、机器验证
数据库记录
由谁创建
注册持有者(或授权代表)
注册持有者,通过其 RIR 创建
对象的持有者或 maintainer
缺失或错误时的影响
上游拒绝配置该路由公告
公告可能被执行 RPKI 验证的网络判定为 RPKI-Invalid 并拒绝
使用 IRR 数据生成过滤规则的服务提供商可能过滤该公告
最清楚的理解方式是:LOA 决定你的上游工作人员是否愿意配置并接受这项公告;ROA 决定互联网上执行验证的路由器是否认为该起源 ASN 合法;route object 则影响自动化过滤系统是否允许该公告通过。三者都可能独立出现问题,而且每一种失败都会产生不同的症状——这也是为什么部署有时会以看似完全不同的方式卡住,取决于究竟缺少哪一项记录。
这三者之间的互动也越来越紧密。例如,Cloudflare 的自动生成 LOA 流程会依赖经过 RPKI 签名的 ROA 以及所有权验证检查——也就是说,加密记录用于支持这份人工文件,而不是取代它。关于 ROA 的具体机制,包括它如何授权某个特定的起源 ASN,以及配置错误时会发生什么,请参阅我们的RPKI 和 ROA指南。
谁可以合法签发 LOA?
只有地址空间的注册持有者——或者被授权代表该持有者行事的人——才有资格合法签发 LOA。 这一点必须非常准确地说明,因为现实中经常有人把相关概念混淆。
有三个概念值得明确区分:
- LOA 授权的是公告,并不转移所有权。 签署 LOA 只是授予对地址空间进行路由的许可。它不会让被授权方成为该地址空间的持有者,不会更改注册记录,也不会转移任何注册管理层面的权利。当授权终止时,该项公告权限也随之终止。
- 在整个租赁期间,注册信息仍然保留在持有者名下。 在租赁安排中,注册管理机构的记录会继续显示原持有者为注册方。这并不是租赁关系中的漏洞——这正是租赁模式本身的结构。租户的公告权来自所获得的授权,而不是来自注册信息的改变。
- 进行公告不等于持有地址空间。 一个网络公告某个前缀,意味着它正在作为起源网络发布该前缀,这反映的是它获得了授权。公告本身并不能证明所有权。这种区分在概念和实际操作上都非常重要,因为未经授权的公告本身正是路由劫持的定义之一。
对于接收公告的上游服务提供商来说,这些区别最终会转化成一个验证问题:签署人真的拥有他们所声称的授权权力吗?这就是为什么 LOA 通常需要使用持有者的公司抬头纸、公司资料必须与注册记录相符,并由身份和职位明确的人签署。任何无法追溯到注册持有者的文件,都不能算真正的授权——那只能算是一项单方面声明。
LOA 与租赁 IPv4:付款之前应该核实什么?
由于 LOA 位于路由上线流程的关键路径上,因此应该在付款之前确认其处理方式,而不是付款之后才发现问题。 这个失败模式在行业中非常常见:企业签署了租赁协议、配置好路由、通知了上游,然后才被要求提供一份租赁协议中从未提及、而出租方又迟迟无法出具的 LOA。在文件到达之前,地址已经付费,却无法使用。
以下事项应当提前确认:
- 付款前取得 LOA,或者取得书面的交付承诺。 最好直接拿到文件;如果做不到,也应在协议中明确规定,必须在一个确定且较短的时间内交付。如果出租方连这两者中的任何一种都不愿意承诺,那已经说明了后续合作关系可能会是什么样子。
- 确认 LOA 中列出了正确的前缀。 应当准确列出你实际租赁的地址块。LOA 如果覆盖了不同地址块或过大的范围,上游可能会提出质疑;如果覆盖范围小于你所需,也无法授权剩余部分。
- 确认 LOA 中列出了正确的 ASN。 必须是实际会成为起源网络的 ASN——根据你的部署方式,这可能是你自己的 ASN,也可能是上游的 ASN。错误的 ASN 是一份形式上有效的 LOA 仍然无法帮助部署上线的最常见原因之一。
- 核对有效期与租赁期限。 如果授权比租赁期限更早到期,就会在部署过程中产生重新签发 LOA 的依赖。
- 确认文件确实来自注册持有者。 公司抬头和企业资料应与注册记录一致,并由可以识别且确实有授权权限的人签署。
- 确认重新签发流程。 如果你更换上游、更换 ASN,或需要为第二家服务提供商增加一份 LOA,更新文件最快可以在多久内提供?实际部署会发生变化,而授权文件必须能够同步更新。
- 询问 LOA 如何与 ROA 和 route object 配合。 单独拥有 LOA 并不够——正如上面的比较所示,ROA 和 IRR 记录也必须保持一致。能够完整处理这三项内容的出租方,比只提供一份文件然后把其余事情全部交给你的出租方,更适合生产环境部署。
这些问题在签约之前提出几乎没有成本,但签约之后才提出往往代价高昂。综合来看,它们也是判断租赁质量非常可靠的信号:如果一个地址安排将路由授权明确视为具有交付期限的正式交付成果,那么它通常是按照生产环境需求设计的;反之,如果把授权当成事后再处理的细节,那么这个问题往往会在最糟糕的时候暴露出来。
常见 LOA 问题
大多数 LOA 问题并不是围绕授权本身产生争议,而是文件交付太迟、内容错误或已经过期。 常见情况包括:
- 交付延迟。 这是最常见、也是成本最高的问题。只要文件一天没有到位,地址空间就一天无法正常公告,无论其他部分准备得多么充分。
- ASN 错误。 LOA 授权了一个与实际发起公告不同的 ASN——通常是因为文件起草之后部署方案发生变化,或出租方误解了租户的上游安排。
- 前缀错误或不够准确。 文件列出的地址块不正确、范围比协议约定更大,或者描述过于模糊,以至于上游不愿据此配置路由。
- 授权已经过期。 有效期已经结束,通常是在服务提供商重新审核文件,或租赁期内新增上游时才被发现。
- 签署人没有授权或无法验证。 文件由上游无法确认其权限的人签署,或者文件本身无法明确关联到注册持有者。
- 协议中完全没有规定 LOA。 租赁协议完全没有提到 LOA 的签发,因此交付时间和责任都没有定义——而交付延迟问题通常就是从这里开始。
这六类问题都可以在协议阶段提前避免,这也是为什么上面的核实清单比事后进行任何故障排查都更加重要。
实用检查清单
- 在签署协议之前,确认协议明确要求持有者签发 LOA,并规定具体交付时间。
- 在付款之前取得 LOA,或者至少取得书面的交付保证。
- 核实准确的前缀与实际租赁或取得的地址块完全一致。
- 核实 ASN 与实际将作为起源网络进行公告的 ASN 完全一致。
- 检查有效期是否覆盖整个租赁或部署周期。
- 确认文件使用注册持有者的正式公司抬头,企业资料与注册记录一致,并有可以识别的授权签署人。
- 按照上游要求的格式提交——PDF 是最稳妥的默认选择;图片格式经常会被拒绝。
- 确认如果上游、ASN 或授权范围发生变化,重新签发的流程以及处理时间。
- 确保 LOA、ROA 和 IRR route object 保持一致,让三种授权记录不会互相冲突。
- 保存一份副本——增加其他服务提供商、进行审计或未来修改部署时,都可能再次需要。
来自 i.lease 的实用说明
LOA 是一份很小的文件,但其运营影响远远超过文件本身的复杂程度。它在技术上并不复杂,只要有权签署的人愿意配合,通常几分钟就可以制作出来,但它却是租赁或新取得的地址块已经付费、却迟迟无法投入使用的最常见原因之一。问题几乎从来不是真正存在授权争议,而是协议签署之前没有人明确规定:由谁签发这份文件、多久内必须交付,以及文件中应该写些什么。
正因如此,LOA 的处理方式其实可以作为判断整体地址资源安排质量的一个很好指标。如果出租方能够快速提供正确的 LOA,一次就准确写明正确的 ASN 和前缀,不需要来回修改三次;当你更换上游时能够迅速重新签发;并且同时保持 ROA 与 route object 一致,那么它实际上正在展示生产环境路由所需要的运营纪律。相反,如果出租方认为 LOA 只是以后再处理的文书工作,那么整个合作关系中的其他环节很可能也会以类似方式处理。文件本身并不复杂,真正重要的是背后的协调能力,而正是这种协调,才能把一段地址空间变成真正可运行的网络基础设施。无论你是租赁还是直接取得地址空间,都应该把路由授权视为一个具有明确期限的正式交付成果,而不是默认它自然会出现。
总结
授权书(LOA)是注册持有者以书面形式授予某个指定方,通过指定 ASN 公告特定前缀的许可。上游服务提供商之所以要求 LOA,是因为仅凭注册数据无法确认公告方是否真正获得授权,而接受未经授权的公告就意味着参与路由劫持。文件会列出持有者、被授权方及 ASN、具体前缀和有效期,并由有权授予该项授权的人签署——它正处于“拥有地址空间”与“能够真正将其路由上线”之间的关键路径上。
最值得记住的区别,是 LOA 能做什么,以及不能做什么。它授权路由公告;它不会转移所有权、不会更改注册信息,也不会授予任何注册管理层面的权利。在租赁关系中,地址空间仍然注册在持有者名下,而租户的公告权来自持有者授予的授权——这也正是为什么 LOA 必须存在,而且必须由持有者出具。再加上由路由器验证的 ROA,以及供过滤系统查询的 route object,LOA 才共同组成将合同权利转化为被网络接受的路由公告所需要的完整记录体系。在部署之前让三者保持一致,在付款之前核实 LOA 的具体内容,才能真正把你已经安排好的地址空间变成可以实际使用的基础设施。
相关阅读
什么是 BGP 劫持?路由劫持如何发生、著名事件以及网络如何防范
RPKI 与 ROA 详解:路由起源授权如何保护你的 IPv4 前缀
什么是 BGP?边界网关协议如何让 IP 地址成为可访问的服务
- 付款前取得 LOA,或者取得书面的交付承诺。 最好直接拿到文件;如果做不到,也应在协议中明确规定,必须在一个确定且较短的时间内交付。如果出租方连这两者中的任何一种都不愿意承诺,那已经说明了后续合作关系可能会是什么样子。
- 确认 LOA 中列出了正确的前缀。 应当准确列出你实际租赁的地址块。LOA 如果覆盖了不同地址块或过大的范围,上游可能会提出质疑;如果覆盖范围小于你所需,也无法授权剩余部分。
- 确认 LOA 中列出了正确的 ASN。 必须是实际会成为起源网络的 ASN——根据你的部署方式,这可能是你自己的 ASN,也可能是上游的 ASN。错误的 ASN 是一份形式上有效的 LOA 仍然无法帮助部署上线的最常见原因之一。
- 核对有效期与租赁期限。 如果授权比租赁期限更早到期,就会在部署过程中产生重新签发 LOA 的依赖。
- 确认文件确实来自注册持有者。 公司抬头和企业资料应与注册记录一致,并由可以识别且确实有授权权限的人签署。
- 确认重新签发流程。 如果你更换上游、更换 ASN,或需要为第二家服务提供商增加一份 LOA,更新文件最快可以在多久内提供?实际部署会发生变化,而授权文件必须能够同步更新。
- 询问 LOA 如何与 ROA 和 route object 配合。 单独拥有 LOA 并不够——正如上面的比较所示,ROA 和 IRR 记录也必须保持一致。能够完整处理这三项内容的出租方,比只提供一份文件然后把其余事情全部交给你的出租方,更适合生产环境部署。
这些问题在签约之前提出几乎没有成本,但签约之后才提出往往代价高昂。综合来看,它们也是判断租赁质量非常可靠的信号:如果一个地址安排将路由授权明确视为具有交付期限的正式交付成果,那么它通常是按照生产环境需求设计的;反之,如果把授权当成事后再处理的细节,那么这个问题往往会在最糟糕的时候暴露出来。
常见 LOA 问题
大多数 LOA 问题并不是围绕授权本身产生争议,而是文件交付太迟、内容错误或已经过期。 常见情况包括:
- 交付延迟。 这是最常见、也是成本最高的问题。只要文件一天没有到位,地址空间就一天无法正常公告,无论其他部分准备得多么充分。
- ASN 错误。 LOA 授权了一个与实际发起公告不同的 ASN——通常是因为文件起草之后部署方案发生变化,或出租方误解了租户的上游安排。
- 前缀错误或不够准确。 文件列出的地址块不正确、范围比协议约定更大,或者描述过于模糊,以至于上游不愿据此配置路由。
- 授权已经过期。 有效期已经结束,通常是在服务提供商重新审核文件,或租赁期内新增上游时才被发现。
- 签署人没有授权或无法验证。 文件由上游无法确认其权限的人签署,或者文件本身无法明确关联到注册持有者。
- 协议中完全没有规定 LOA。 租赁协议完全没有提到 LOA 的签发,因此交付时间和责任都没有定义——而交付延迟问题通常就是从这里开始。
这六类问题都可以在协议阶段提前避免,这也是为什么上面的核实清单比事后进行任何故障排查都更加重要。
实用检查清单
- 在签署协议之前,确认协议明确要求持有者签发 LOA,并规定具体交付时间。
- 在付款之前取得 LOA,或者至少取得书面的交付保证。
- 核实准确的前缀与实际租赁或取得的地址块完全一致。
- 核实 ASN 与实际将作为起源网络进行公告的 ASN 完全一致。
- 检查有效期是否覆盖整个租赁或部署周期。
- 确认文件使用注册持有者的正式公司抬头,企业资料与注册记录一致,并有可以识别的授权签署人。
- 按照上游要求的格式提交——PDF 是最稳妥的默认选择;图片格式经常会被拒绝。
- 确认如果上游、ASN 或授权范围发生变化,重新签发的流程以及处理时间。
- 确保 LOA、ROA 和 IRR route object 保持一致,让三种授权记录不会互相冲突。
- 保存一份副本——增加其他服务提供商、进行审计或未来修改部署时,都可能再次需要。
来自 i.lease 的实用说明
LOA 是一份很小的文件,但其运营影响远远超过文件本身的复杂程度。它在技术上并不复杂,只要有权签署的人愿意配合,通常几分钟就可以制作出来,但它却是租赁或新取得的地址块已经付费、却迟迟无法投入使用的最常见原因之一。问题几乎从来不是真正存在授权争议,而是协议签署之前没有人明确规定:由谁签发这份文件、多久内必须交付,以及文件中应该写些什么。
正因如此,LOA 的处理方式其实可以作为判断整体地址资源安排质量的一个很好指标。如果出租方能够快速提供正确的 LOA,一次就准确写明正确的 ASN 和前缀,不需要来回修改三次;当你更换上游时能够迅速重新签发;并且同时保持 ROA 与 route object 一致,那么它实际上正在展示生产环境路由所需要的运营纪律。相反,如果出租方认为 LOA 只是以后再处理的文书工作,那么整个合作关系中的其他环节很可能也会以类似方式处理。文件本身并不复杂,真正重要的是背后的协调能力,而正是这种协调,才能把一段地址空间变成真正可运行的网络基础设施。无论你是租赁还是直接取得地址空间,都应该把路由授权视为一个具有明确期限的正式交付成果,而不是默认它自然会出现。
总结
授权书(LOA)是注册持有者以书面形式授予某个指定方,通过指定 ASN 公告特定前缀的许可。上游服务提供商之所以要求 LOA,是因为仅凭注册数据无法确认公告方是否真正获得授权,而接受未经授权的公告就意味着参与路由劫持。文件会列出持有者、被授权方及 ASN、具体前缀和有效期,并由有权授予该项授权的人签署——它正处于“拥有地址空间”与“能够真正将其路由上线”之间的关键路径上。
最值得记住的区别,是 LOA 能做什么,以及不能做什么。它授权路由公告;它不会转移所有权、不会更改注册信息,也不会授予任何注册管理层面的权利。在租赁关系中,地址空间仍然注册在持有者名下,而租户的公告权来自持有者授予的授权——这也正是为什么 LOA 必须存在,而且必须由持有者出具。再加上由路由器验证的 ROA,以及供过滤系统查询的 route object,LOA 才共同组成将合同权利转化为被网络接受的路由公告所需要的完整记录体系。在部署之前让三者保持一致,在付款之前核实 LOA 的具体内容,才能真正把你已经安排好的地址空间变成可以实际使用的基础设施。
相关阅读
什么是 BGP 劫持?路由劫持如何发生、著名事件以及网络如何防范
RPKI 与 ROA 详解:路由起源授权如何保护你的 IPv4 前缀
什么是 BGP?边界网关协议如何让 IP 地址成为可访问的服务
- LOA 授权的是公告,并不转移所有权。 签署 LOA 只是授予对地址空间进行路由的许可。它不会让被授权方成为该地址空间的持有者,不会更改注册记录,也不会转移任何注册管理层面的权利。当授权终止时,该项公告权限也随之终止。
- 在整个租赁期间,注册信息仍然保留在持有者名下。 在租赁安排中,注册管理机构的记录会继续显示原持有者为注册方。这并不是租赁关系中的漏洞——这正是租赁模式本身的结构。租户的公告权来自所获得的授权,而不是来自注册信息的改变。
- 进行公告不等于持有地址空间。 一个网络公告某个前缀,意味着它正在作为起源网络发布该前缀,这反映的是它获得了授权。公告本身并不能证明所有权。这种区分在概念和实际操作上都非常重要,因为未经授权的公告本身正是路由劫持的定义之一。
对于接收公告的上游服务提供商来说,这些区别最终会转化成一个验证问题:签署人真的拥有他们所声称的授权权力吗?这就是为什么 LOA 通常需要使用持有者的公司抬头纸、公司资料必须与注册记录相符,并由身份和职位明确的人签署。任何无法追溯到注册持有者的文件,都不能算真正的授权——那只能算是一项单方面声明。
LOA 与租赁 IPv4:付款之前应该核实什么?
由于 LOA 位于路由上线流程的关键路径上,因此应该在付款之前确认其处理方式,而不是付款之后才发现问题。 这个失败模式在行业中非常常见:企业签署了租赁协议、配置好路由、通知了上游,然后才被要求提供一份租赁协议中从未提及、而出租方又迟迟无法出具的 LOA。在文件到达之前,地址已经付费,却无法使用。
以下事项应当提前确认:
- 付款前取得 LOA,或者取得书面的交付承诺。 最好直接拿到文件;如果做不到,也应在协议中明确规定,必须在一个确定且较短的时间内交付。如果出租方连这两者中的任何一种都不愿意承诺,那已经说明了后续合作关系可能会是什么样子。
- 确认 LOA 中列出了正确的前缀。 应当准确列出你实际租赁的地址块。LOA 如果覆盖了不同地址块或过大的范围,上游可能会提出质疑;如果覆盖范围小于你所需,也无法授权剩余部分。
- 确认 LOA 中列出了正确的 ASN。 必须是实际会成为起源网络的 ASN——根据你的部署方式,这可能是你自己的 ASN,也可能是上游的 ASN。错误的 ASN 是一份形式上有效的 LOA 仍然无法帮助部署上线的最常见原因之一。
- 核对有效期与租赁期限。 如果授权比租赁期限更早到期,就会在部署过程中产生重新签发 LOA 的依赖。
- 确认文件确实来自注册持有者。 公司抬头和企业资料应与注册记录一致,并由可以识别且确实有授权权限的人签署。
- 确认重新签发流程。 如果你更换上游、更换 ASN,或需要为第二家服务提供商增加一份 LOA,更新文件最快可以在多久内提供?实际部署会发生变化,而授权文件必须能够同步更新。
- 询问 LOA 如何与 ROA 和 route object 配合。 单独拥有 LOA 并不够——正如上面的比较所示,ROA 和 IRR 记录也必须保持一致。能够完整处理这三项内容的出租方,比只提供一份文件然后把其余事情全部交给你的出租方,更适合生产环境部署。
这些问题在签约之前提出几乎没有成本,但签约之后才提出往往代价高昂。综合来看,它们也是判断租赁质量非常可靠的信号:如果一个地址安排将路由授权明确视为具有交付期限的正式交付成果,那么它通常是按照生产环境需求设计的;反之,如果把授权当成事后再处理的细节,那么这个问题往往会在最糟糕的时候暴露出来。
常见 LOA 问题
大多数 LOA 问题并不是围绕授权本身产生争议,而是文件交付太迟、内容错误或已经过期。 常见情况包括:
- 交付延迟。 这是最常见、也是成本最高的问题。只要文件一天没有到位,地址空间就一天无法正常公告,无论其他部分准备得多么充分。
- ASN 错误。 LOA 授权了一个与实际发起公告不同的 ASN——通常是因为文件起草之后部署方案发生变化,或出租方误解了租户的上游安排。
- 前缀错误或不够准确。 文件列出的地址块不正确、范围比协议约定更大,或者描述过于模糊,以至于上游不愿据此配置路由。
- 授权已经过期。 有效期已经结束,通常是在服务提供商重新审核文件,或租赁期内新增上游时才被发现。
- 签署人没有授权或无法验证。 文件由上游无法确认其权限的人签署,或者文件本身无法明确关联到注册持有者。
- 协议中完全没有规定 LOA。 租赁协议完全没有提到 LOA 的签发,因此交付时间和责任都没有定义——而交付延迟问题通常就是从这里开始。
这六类问题都可以在协议阶段提前避免,这也是为什么上面的核实清单比事后进行任何故障排查都更加重要。
实用检查清单
- 在签署协议之前,确认协议明确要求持有者签发 LOA,并规定具体交付时间。
- 在付款之前取得 LOA,或者至少取得书面的交付保证。
- 核实准确的前缀与实际租赁或取得的地址块完全一致。
- 核实 ASN 与实际将作为起源网络进行公告的 ASN 完全一致。
- 检查有效期是否覆盖整个租赁或部署周期。
- 确认文件使用注册持有者的正式公司抬头,企业资料与注册记录一致,并有可以识别的授权签署人。
- 按照上游要求的格式提交——PDF 是最稳妥的默认选择;图片格式经常会被拒绝。
- 确认如果上游、ASN 或授权范围发生变化,重新签发的流程以及处理时间。
- 确保 LOA、ROA 和 IRR route object 保持一致,让三种授权记录不会互相冲突。
- 保存一份副本——增加其他服务提供商、进行审计或未来修改部署时,都可能再次需要。
来自 i.lease 的实用说明
LOA 是一份很小的文件,但其运营影响远远超过文件本身的复杂程度。它在技术上并不复杂,只要有权签署的人愿意配合,通常几分钟就可以制作出来,但它却是租赁或新取得的地址块已经付费、却迟迟无法投入使用的最常见原因之一。问题几乎从来不是真正存在授权争议,而是协议签署之前没有人明确规定:由谁签发这份文件、多久内必须交付,以及文件中应该写些什么。
正因如此,LOA 的处理方式其实可以作为判断整体地址资源安排质量的一个很好指标。如果出租方能够快速提供正确的 LOA,一次就准确写明正确的 ASN 和前缀,不需要来回修改三次;当你更换上游时能够迅速重新签发;并且同时保持 ROA 与 route object 一致,那么它实际上正在展示生产环境路由所需要的运营纪律。相反,如果出租方认为 LOA 只是以后再处理的文书工作,那么整个合作关系中的其他环节很可能也会以类似方式处理。文件本身并不复杂,真正重要的是背后的协调能力,而正是这种协调,才能把一段地址空间变成真正可运行的网络基础设施。无论你是租赁还是直接取得地址空间,都应该把路由授权视为一个具有明确期限的正式交付成果,而不是默认它自然会出现。
总结
授权书(LOA)是注册持有者以书面形式授予某个指定方,通过指定 ASN 公告特定前缀的许可。上游服务提供商之所以要求 LOA,是因为仅凭注册数据无法确认公告方是否真正获得授权,而接受未经授权的公告就意味着参与路由劫持。文件会列出持有者、被授权方及 ASN、具体前缀和有效期,并由有权授予该项授权的人签署——它正处于“拥有地址空间”与“能够真正将其路由上线”之间的关键路径上。
最值得记住的区别,是 LOA 能做什么,以及不能做什么。它授权路由公告;它不会转移所有权、不会更改注册信息,也不会授予任何注册管理层面的权利。在租赁关系中,地址空间仍然注册在持有者名下,而租户的公告权来自持有者授予的授权——这也正是为什么 LOA 必须存在,而且必须由持有者出具。再加上由路由器验证的 ROA,以及供过滤系统查询的 route object,LOA 才共同组成将合同权利转化为被网络接受的路由公告所需要的完整记录体系。在部署之前让三者保持一致,在付款之前核实 LOA 的具体内容,才能真正把你已经安排好的地址空间变成可以实际使用的基础设施。
相关阅读
什么是 BGP 劫持?路由劫持如何发生、著名事件以及网络如何防范
RPKI 与 ROA 详解:路由起源授权如何保护你的 IPv4 前缀
什么是 BGP?边界网关协议如何让 IP 地址成为可访问的服务
- 授权方。 即地址空间的注册持有者,其公司名称和相关资料应与注册记录一致。
- 被授权方和 ASN。 文件需要说明谁被允许公告该地址空间,以及最关键的——将通过哪个自治系统编号进行公告。Cloudflare 的文档明确要求 LOA 同时写明被授权的前缀和公告所使用的 ASN——ASN 并不是可有可无的附加信息。
- 准确的前缀。 必须精确列出受授权覆盖的地址块(例如某个具体的 /24)。任何超出 LOA 所列范围的公告,都不属于该授权范围。
- 有效期。 授权的持续时间。对于租赁地址空间,其有效期应与租赁期限保持一致。
- 授权签署人。 包括姓名、职位以及有权代表持有者签署文件的人员签名,并附上联系方式,以便上游服务提供商在有需要时进行核实。
- 公司抬头和文件格式。 LOA 通常应以持有者公司的正式抬头纸制作。Cloudflare 指出,Transit 服务提供商可能会拒绝以图片格式提交的 LOA,而要求使用 PDF;数字签名通常可以接受,但签署人必须能够被清楚识别。
这些要求并不是毫无意义的行政装饰。公司抬头、与注册记录一致的企业资料,以及可识别的授权签署人,正是接收方用于确认文件真实性,以及签署人确实有权授予所声称授权的依据。
什么时候需要 LOA?
只要将由注册持有者以外的一方公告地址空间,通常都需要 LOA——这涵盖了绝大多数 IPv4 租赁、BYOIP 和由服务提供商代为公告的情况。 常见场景包括:
- 通过自己的 ASN 公告租赁的 IPv4。 这是最典型的情况:你租赁了一个地址块,并自行对外公告,因此你的上游需要看到持有者提供的授权。关于这个更完整的租赁流程,可以参考我们的IPv4 租赁指南以及IP 地址租赁如何运作的说明。
- 由服务提供商代表你公告地址空间。 当你的托管服务商、数据中心或平台通过其 ASN 公告你的前缀时,它需要获得你的授权——而它的上游同样需要看到这一授权。
- BYOIP 接入。 将自有 IP 地址空间(BYOIP)带入云平台或边缘平台时,需要授权该平台公告你的前缀,Cloudflare 的要求就是一个典型例子。
- 紧急路由变更。 例如 DDoS 清洗服务,在攻击发生时由服务提供商临时公告你的前缀,这类安排依赖于事先完成授权——这一点我们也在DDoS 缓解指南中进行了介绍。
判断标准其实很简单:如果进行公告的 ASN 并不属于注册持有者本身,那么几乎可以确定需要 LOA。
LOA vs ROA vs IRR Route Object
LOA、ROA 和 IRR route object 都在说明谁可以公告某个前缀——但它们面对不同的受众、采用不同形式,并且作用于不同层面。 它们彼此互补,而不是相互替代。一个正确部署的前缀,通常需要三者保持一致。
LOA vs ROA vs IRR Route Object
项目
LOA
ROA
IRR route object
它是什么
授予路由公告权限的签署文件
RPKI 中经过加密签名的记录
Internet Routing Registry 数据库中的记录
面向对象
人员——上游开通和 NOC 工作人员
执行路由起源验证的路由器
自动生成过滤规则的系统
形式
人类可读、合同性质
加密签名、机器验证
数据库记录
由谁创建
注册持有者(或授权代表)
注册持有者,通过其 RIR 创建
对象的持有者或 maintainer
缺失或错误时的影响
上游拒绝配置该路由公告
公告可能被执行 RPKI 验证的网络判定为 RPKI-Invalid 并拒绝
使用 IRR 数据生成过滤规则的服务提供商可能过滤该公告
最清楚的理解方式是:LOA 决定你的上游工作人员是否愿意配置并接受这项公告;ROA 决定互联网上执行验证的路由器是否认为该起源 ASN 合法;route object 则影响自动化过滤系统是否允许该公告通过。三者都可能独立出现问题,而且每一种失败都会产生不同的症状——这也是为什么部署有时会以看似完全不同的方式卡住,取决于究竟缺少哪一项记录。
这三者之间的互动也越来越紧密。例如,Cloudflare 的自动生成 LOA 流程会依赖经过 RPKI 签名的 ROA 以及所有权验证检查——也就是说,加密记录用于支持这份人工文件,而不是取代它。关于 ROA 的具体机制,包括它如何授权某个特定的起源 ASN,以及配置错误时会发生什么,请参阅我们的RPKI 和 ROA指南。
谁可以合法签发 LOA?
只有地址空间的注册持有者——或者被授权代表该持有者行事的人——才有资格合法签发 LOA。 这一点必须非常准确地说明,因为现实中经常有人把相关概念混淆。
有三个概念值得明确区分:
- LOA 授权的是公告,并不转移所有权。 签署 LOA 只是授予对地址空间进行路由的许可。它不会让被授权方成为该地址空间的持有者,不会更改注册记录,也不会转移任何注册管理层面的权利。当授权终止时,该项公告权限也随之终止。
- 在整个租赁期间,注册信息仍然保留在持有者名下。 在租赁安排中,注册管理机构的记录会继续显示原持有者为注册方。这并不是租赁关系中的漏洞——这正是租赁模式本身的结构。租户的公告权来自所获得的授权,而不是来自注册信息的改变。
- 进行公告不等于持有地址空间。 一个网络公告某个前缀,意味着它正在作为起源网络发布该前缀,这反映的是它获得了授权。公告本身并不能证明所有权。这种区分在概念和实际操作上都非常重要,因为未经授权的公告本身正是路由劫持的定义之一。
对于接收公告的上游服务提供商来说,这些区别最终会转化成一个验证问题:签署人真的拥有他们所声称的授权权力吗?这就是为什么 LOA 通常需要使用持有者的公司抬头纸、公司资料必须与注册记录相符,并由身份和职位明确的人签署。任何无法追溯到注册持有者的文件,都不能算真正的授权——那只能算是一项单方面声明。
LOA 与租赁 IPv4:付款之前应该核实什么?
由于 LOA 位于路由上线流程的关键路径上,因此应该在付款之前确认其处理方式,而不是付款之后才发现问题。 这个失败模式在行业中非常常见:企业签署了租赁协议、配置好路由、通知了上游,然后才被要求提供一份租赁协议中从未提及、而出租方又迟迟无法出具的 LOA。在文件到达之前,地址已经付费,却无法使用。
以下事项应当提前确认:
- 付款前取得 LOA,或者取得书面的交付承诺。 最好直接拿到文件;如果做不到,也应在协议中明确规定,必须在一个确定且较短的时间内交付。如果出租方连这两者中的任何一种都不愿意承诺,那已经说明了后续合作关系可能会是什么样子。
- 确认 LOA 中列出了正确的前缀。 应当准确列出你实际租赁的地址块。LOA 如果覆盖了不同地址块或过大的范围,上游可能会提出质疑;如果覆盖范围小于你所需,也无法授权剩余部分。
- 确认 LOA 中列出了正确的 ASN。 必须是实际会成为起源网络的 ASN——根据你的部署方式,这可能是你自己的 ASN,也可能是上游的 ASN。错误的 ASN 是一份形式上有效的 LOA 仍然无法帮助部署上线的最常见原因之一。
- 核对有效期与租赁期限。 如果授权比租赁期限更早到期,就会在部署过程中产生重新签发 LOA 的依赖。
- 确认文件确实来自注册持有者。 公司抬头和企业资料应与注册记录一致,并由可以识别且确实有授权权限的人签署。
- 确认重新签发流程。 如果你更换上游、更换 ASN,或需要为第二家服务提供商增加一份 LOA,更新文件最快可以在多久内提供?实际部署会发生变化,而授权文件必须能够同步更新。
- 询问 LOA 如何与 ROA 和 route object 配合。 单独拥有 LOA 并不够——正如上面的比较所示,ROA 和 IRR 记录也必须保持一致。能够完整处理这三项内容的出租方,比只提供一份文件然后把其余事情全部交给你的出租方,更适合生产环境部署。
这些问题在签约之前提出几乎没有成本,但签约之后才提出往往代价高昂。综合来看,它们也是判断租赁质量非常可靠的信号:如果一个地址安排将路由授权明确视为具有交付期限的正式交付成果,那么它通常是按照生产环境需求设计的;反之,如果把授权当成事后再处理的细节,那么这个问题往往会在最糟糕的时候暴露出来。
常见 LOA 问题
大多数 LOA 问题并不是围绕授权本身产生争议,而是文件交付太迟、内容错误或已经过期。 常见情况包括:
- 交付延迟。 这是最常见、也是成本最高的问题。只要文件一天没有到位,地址空间就一天无法正常公告,无论其他部分准备得多么充分。
- ASN 错误。 LOA 授权了一个与实际发起公告不同的 ASN——通常是因为文件起草之后部署方案发生变化,或出租方误解了租户的上游安排。
- 前缀错误或不够准确。 文件列出的地址块不正确、范围比协议约定更大,或者描述过于模糊,以至于上游不愿据此配置路由。
- 授权已经过期。 有效期已经结束,通常是在服务提供商重新审核文件,或租赁期内新增上游时才被发现。
- 签署人没有授权或无法验证。 文件由上游无法确认其权限的人签署,或者文件本身无法明确关联到注册持有者。
- 协议中完全没有规定 LOA。 租赁协议完全没有提到 LOA 的签发,因此交付时间和责任都没有定义——而交付延迟问题通常就是从这里开始。
这六类问题都可以在协议阶段提前避免,这也是为什么上面的核实清单比事后进行任何故障排查都更加重要。
实用检查清单
- 在签署协议之前,确认协议明确要求持有者签发 LOA,并规定具体交付时间。
- 在付款之前取得 LOA,或者至少取得书面的交付保证。
- 核实准确的前缀与实际租赁或取得的地址块完全一致。
- 核实 ASN 与实际将作为起源网络进行公告的 ASN 完全一致。
- 检查有效期是否覆盖整个租赁或部署周期。
- 确认文件使用注册持有者的正式公司抬头,企业资料与注册记录一致,并有可以识别的授权签署人。
- 按照上游要求的格式提交——PDF 是最稳妥的默认选择;图片格式经常会被拒绝。
- 确认如果上游、ASN 或授权范围发生变化,重新签发的流程以及处理时间。
- 确保 LOA、ROA 和 IRR route object 保持一致,让三种授权记录不会互相冲突。
- 保存一份副本——增加其他服务提供商、进行审计或未来修改部署时,都可能再次需要。
来自 i.lease 的实用说明
LOA 是一份很小的文件,但其运营影响远远超过文件本身的复杂程度。它在技术上并不复杂,只要有权签署的人愿意配合,通常几分钟就可以制作出来,但它却是租赁或新取得的地址块已经付费、却迟迟无法投入使用的最常见原因之一。问题几乎从来不是真正存在授权争议,而是协议签署之前没有人明确规定:由谁签发这份文件、多久内必须交付,以及文件中应该写些什么。
正因如此,LOA 的处理方式其实可以作为判断整体地址资源安排质量的一个很好指标。如果出租方能够快速提供正确的 LOA,一次就准确写明正确的 ASN 和前缀,不需要来回修改三次;当你更换上游时能够迅速重新签发;并且同时保持 ROA 与 route object 一致,那么它实际上正在展示生产环境路由所需要的运营纪律。相反,如果出租方认为 LOA 只是以后再处理的文书工作,那么整个合作关系中的其他环节很可能也会以类似方式处理。文件本身并不复杂,真正重要的是背后的协调能力,而正是这种协调,才能把一段地址空间变成真正可运行的网络基础设施。无论你是租赁还是直接取得地址空间,都应该把路由授权视为一个具有明确期限的正式交付成果,而不是默认它自然会出现。
总结
授权书(LOA)是注册持有者以书面形式授予某个指定方,通过指定 ASN 公告特定前缀的许可。上游服务提供商之所以要求 LOA,是因为仅凭注册数据无法确认公告方是否真正获得授权,而接受未经授权的公告就意味着参与路由劫持。文件会列出持有者、被授权方及 ASN、具体前缀和有效期,并由有权授予该项授权的人签署——它正处于“拥有地址空间”与“能够真正将其路由上线”之间的关键路径上。
最值得记住的区别,是 LOA 能做什么,以及不能做什么。它授权路由公告;它不会转移所有权、不会更改注册信息,也不会授予任何注册管理层面的权利。在租赁关系中,地址空间仍然注册在持有者名下,而租户的公告权来自持有者授予的授权——这也正是为什么 LOA 必须存在,而且必须由持有者出具。再加上由路由器验证的 ROA,以及供过滤系统查询的 route object,LOA 才共同组成将合同权利转化为被网络接受的路由公告所需要的完整记录体系。在部署之前让三者保持一致,在付款之前核实 LOA 的具体内容,才能真正把你已经安排好的地址空间变成可以实际使用的基础设施。
相关阅读
什么是 BGP 劫持?路由劫持如何发生、著名事件以及网络如何防范
RPKI 与 ROA 详解:路由起源授权如何保护你的 IPv4 前缀
什么是 BGP?边界网关协议如何让 IP 地址成为可访问的服务
- 它由持有者签发,而不是由公告方自行签发。 有权授予许可的一方,是地址空间的持有者。租户不能自己给自己写一份 LOA。
- 它必须具有明确的针对性。 文件需要列出具体的前缀以及具体的 ASN。仅仅说明某方“信誉良好”并不能构成 LOA;文件中的内容必须与实际将要公告的内容完全匹配。
为什么上游服务提供商要求 LOA?
服务提供商之所以要求 LOA,是因为接受一个未经授权方发出的路由公告,正是前缀劫持发生的方式——而任何负责任的网络都不希望成为传播这种错误公告的一方。
正如我们在BGP 如何运作的指南中所解释的,路由系统在很大程度上是基于信任接受公告的,而各个网络之所以会过滤接收到的路由,正是因为虚假公告可能将属于其他人的流量重定向。这个风险并不是理论上的:未经授权的路由公告正是我们在BGP 劫持指南中所介绍事件的核心机制。如果上游服务提供商在未核实授权的情况下接受公告,那么它就会无意间成为后续事件的参与者。
LOA 填补的正是一个具体的信息缺口。注册记录可以确认地址持有者,但在租赁情况下,注册记录仍然显示原持有者,而实际进行公告的是另一方——因此,上游服务提供商无法仅通过数据库查询来验证租户。LOA 补上了缺失的这一环:由注册记录中可识别的那一方,以书面形式确认实际进行公告的一方已经获得许可。
在实际部署中,这意味着 LOA 位于整个上线流程的关键路径上。路由器已经配置、租赁协议已经签署、地址块已经分配——这些都无法真正带来可达性,直到上游服务提供商接受这条路由公告,而在没有 LOA 的情况下,上游通常不会接受。
LOA 包含哪些内容?
LOA 会明确授权方、被授权方及其 ASN、具体前缀,以及有权授予该项授权人员的签名。 各家服务提供商通常要求的标准组成部分包括:
- 授权方。 即地址空间的注册持有者,其公司名称和相关资料应与注册记录一致。
- 被授权方和 ASN。 文件需要说明谁被允许公告该地址空间,以及最关键的——将通过哪个自治系统编号进行公告。Cloudflare 的文档明确要求 LOA 同时写明被授权的前缀和公告所使用的 ASN——ASN 并不是可有可无的附加信息。
- 准确的前缀。 必须精确列出受授权覆盖的地址块(例如某个具体的 /24)。任何超出 LOA 所列范围的公告,都不属于该授权范围。
- 有效期。 授权的持续时间。对于租赁地址空间,其有效期应与租赁期限保持一致。
- 授权签署人。 包括姓名、职位以及有权代表持有者签署文件的人员签名,并附上联系方式,以便上游服务提供商在有需要时进行核实。
- 公司抬头和文件格式。 LOA 通常应以持有者公司的正式抬头纸制作。Cloudflare 指出,Transit 服务提供商可能会拒绝以图片格式提交的 LOA,而要求使用 PDF;数字签名通常可以接受,但签署人必须能够被清楚识别。
这些要求并不是毫无意义的行政装饰。公司抬头、与注册记录一致的企业资料,以及可识别的授权签署人,正是接收方用于确认文件真实性,以及签署人确实有权授予所声称授权的依据。
什么时候需要 LOA?
只要将由注册持有者以外的一方公告地址空间,通常都需要 LOA——这涵盖了绝大多数 IPv4 租赁、BYOIP 和由服务提供商代为公告的情况。 常见场景包括:
- 通过自己的 ASN 公告租赁的 IPv4。 这是最典型的情况:你租赁了一个地址块,并自行对外公告,因此你的上游需要看到持有者提供的授权。关于这个更完整的租赁流程,可以参考我们的IPv4 租赁指南以及IP 地址租赁如何运作的说明。
- 由服务提供商代表你公告地址空间。 当你的托管服务商、数据中心或平台通过其 ASN 公告你的前缀时,它需要获得你的授权——而它的上游同样需要看到这一授权。
- BYOIP 接入。 将自有 IP 地址空间(BYOIP)带入云平台或边缘平台时,需要授权该平台公告你的前缀,Cloudflare 的要求就是一个典型例子。
- 紧急路由变更。 例如 DDoS 清洗服务,在攻击发生时由服务提供商临时公告你的前缀,这类安排依赖于事先完成授权——这一点我们也在DDoS 缓解指南中进行了介绍。
判断标准其实很简单:如果进行公告的 ASN 并不属于注册持有者本身,那么几乎可以确定需要 LOA。
LOA vs ROA vs IRR Route Object
LOA、ROA 和 IRR route object 都在说明谁可以公告某个前缀——但它们面对不同的受众、采用不同形式,并且作用于不同层面。 它们彼此互补,而不是相互替代。一个正确部署的前缀,通常需要三者保持一致。
LOA vs ROA vs IRR Route Object
项目
LOA
ROA
IRR route object
它是什么
授予路由公告权限的签署文件
RPKI 中经过加密签名的记录
Internet Routing Registry 数据库中的记录
面向对象
人员——上游开通和 NOC 工作人员
执行路由起源验证的路由器
自动生成过滤规则的系统
形式
人类可读、合同性质
加密签名、机器验证
数据库记录
由谁创建
注册持有者(或授权代表)
注册持有者,通过其 RIR 创建
对象的持有者或 maintainer
缺失或错误时的影响
上游拒绝配置该路由公告
公告可能被执行 RPKI 验证的网络判定为 RPKI-Invalid 并拒绝
使用 IRR 数据生成过滤规则的服务提供商可能过滤该公告
最清楚的理解方式是:LOA 决定你的上游工作人员是否愿意配置并接受这项公告;ROA 决定互联网上执行验证的路由器是否认为该起源 ASN 合法;route object 则影响自动化过滤系统是否允许该公告通过。三者都可能独立出现问题,而且每一种失败都会产生不同的症状——这也是为什么部署有时会以看似完全不同的方式卡住,取决于究竟缺少哪一项记录。
这三者之间的互动也越来越紧密。例如,Cloudflare 的自动生成 LOA 流程会依赖经过 RPKI 签名的 ROA 以及所有权验证检查——也就是说,加密记录用于支持这份人工文件,而不是取代它。关于 ROA 的具体机制,包括它如何授权某个特定的起源 ASN,以及配置错误时会发生什么,请参阅我们的RPKI 和 ROA指南。
谁可以合法签发 LOA?
只有地址空间的注册持有者——或者被授权代表该持有者行事的人——才有资格合法签发 LOA。 这一点必须非常准确地说明,因为现实中经常有人把相关概念混淆。
有三个概念值得明确区分:
- LOA 授权的是公告,并不转移所有权。 签署 LOA 只是授予对地址空间进行路由的许可。它不会让被授权方成为该地址空间的持有者,不会更改注册记录,也不会转移任何注册管理层面的权利。当授权终止时,该项公告权限也随之终止。
- 在整个租赁期间,注册信息仍然保留在持有者名下。 在租赁安排中,注册管理机构的记录会继续显示原持有者为注册方。这并不是租赁关系中的漏洞——这正是租赁模式本身的结构。租户的公告权来自所获得的授权,而不是来自注册信息的改变。
- 进行公告不等于持有地址空间。 一个网络公告某个前缀,意味着它正在作为起源网络发布该前缀,这反映的是它获得了授权。公告本身并不能证明所有权。这种区分在概念和实际操作上都非常重要,因为未经授权的公告本身正是路由劫持的定义之一。
对于接收公告的上游服务提供商来说,这些区别最终会转化成一个验证问题:签署人真的拥有他们所声称的授权权力吗?这就是为什么 LOA 通常需要使用持有者的公司抬头纸、公司资料必须与注册记录相符,并由身份和职位明确的人签署。任何无法追溯到注册持有者的文件,都不能算真正的授权——那只能算是一项单方面声明。
LOA 与租赁 IPv4:付款之前应该核实什么?
由于 LOA 位于路由上线流程的关键路径上,因此应该在付款之前确认其处理方式,而不是付款之后才发现问题。 这个失败模式在行业中非常常见:企业签署了租赁协议、配置好路由、通知了上游,然后才被要求提供一份租赁协议中从未提及、而出租方又迟迟无法出具的 LOA。在文件到达之前,地址已经付费,却无法使用。
以下事项应当提前确认:
- 付款前取得 LOA,或者取得书面的交付承诺。 最好直接拿到文件;如果做不到,也应在协议中明确规定,必须在一个确定且较短的时间内交付。如果出租方连这两者中的任何一种都不愿意承诺,那已经说明了后续合作关系可能会是什么样子。
- 确认 LOA 中列出了正确的前缀。 应当准确列出你实际租赁的地址块。LOA 如果覆盖了不同地址块或过大的范围,上游可能会提出质疑;如果覆盖范围小于你所需,也无法授权剩余部分。
- 确认 LOA 中列出了正确的 ASN。 必须是实际会成为起源网络的 ASN——根据你的部署方式,这可能是你自己的 ASN,也可能是上游的 ASN。错误的 ASN 是一份形式上有效的 LOA 仍然无法帮助部署上线的最常见原因之一。
- 核对有效期与租赁期限。 如果授权比租赁期限更早到期,就会在部署过程中产生重新签发 LOA 的依赖。
- 确认文件确实来自注册持有者。 公司抬头和企业资料应与注册记录一致,并由可以识别且确实有授权权限的人签署。
- 确认重新签发流程。 如果你更换上游、更换 ASN,或需要为第二家服务提供商增加一份 LOA,更新文件最快可以在多久内提供?实际部署会发生变化,而授权文件必须能够同步更新。
- 询问 LOA 如何与 ROA 和 route object 配合。 单独拥有 LOA 并不够——正如上面的比较所示,ROA 和 IRR 记录也必须保持一致。能够完整处理这三项内容的出租方,比只提供一份文件然后把其余事情全部交给你的出租方,更适合生产环境部署。
这些问题在签约之前提出几乎没有成本,但签约之后才提出往往代价高昂。综合来看,它们也是判断租赁质量非常可靠的信号:如果一个地址安排将路由授权明确视为具有交付期限的正式交付成果,那么它通常是按照生产环境需求设计的;反之,如果把授权当成事后再处理的细节,那么这个问题往往会在最糟糕的时候暴露出来。
常见 LOA 问题
大多数 LOA 问题并不是围绕授权本身产生争议,而是文件交付太迟、内容错误或已经过期。 常见情况包括:
- 交付延迟。 这是最常见、也是成本最高的问题。只要文件一天没有到位,地址空间就一天无法正常公告,无论其他部分准备得多么充分。
- ASN 错误。 LOA 授权了一个与实际发起公告不同的 ASN——通常是因为文件起草之后部署方案发生变化,或出租方误解了租户的上游安排。
- 前缀错误或不够准确。 文件列出的地址块不正确、范围比协议约定更大,或者描述过于模糊,以至于上游不愿据此配置路由。
- 授权已经过期。 有效期已经结束,通常是在服务提供商重新审核文件,或租赁期内新增上游时才被发现。
- 签署人没有授权或无法验证。 文件由上游无法确认其权限的人签署,或者文件本身无法明确关联到注册持有者。
- 协议中完全没有规定 LOA。 租赁协议完全没有提到 LOA 的签发,因此交付时间和责任都没有定义——而交付延迟问题通常就是从这里开始。
这六类问题都可以在协议阶段提前避免,这也是为什么上面的核实清单比事后进行任何故障排查都更加重要。
实用检查清单
- 在签署协议之前,确认协议明确要求持有者签发 LOA,并规定具体交付时间。
- 在付款之前取得 LOA,或者至少取得书面的交付保证。
- 核实准确的前缀与实际租赁或取得的地址块完全一致。
- 核实 ASN 与实际将作为起源网络进行公告的 ASN 完全一致。
- 检查有效期是否覆盖整个租赁或部署周期。
- 确认文件使用注册持有者的正式公司抬头,企业资料与注册记录一致,并有可以识别的授权签署人。
- 按照上游要求的格式提交——PDF 是最稳妥的默认选择;图片格式经常会被拒绝。
- 确认如果上游、ASN 或授权范围发生变化,重新签发的流程以及处理时间。
- 确保 LOA、ROA 和 IRR route object 保持一致,让三种授权记录不会互相冲突。
- 保存一份副本——增加其他服务提供商、进行审计或未来修改部署时,都可能再次需要。
来自 i.lease 的实用说明
LOA 是一份很小的文件,但其运营影响远远超过文件本身的复杂程度。它在技术上并不复杂,只要有权签署的人愿意配合,通常几分钟就可以制作出来,但它却是租赁或新取得的地址块已经付费、却迟迟无法投入使用的最常见原因之一。问题几乎从来不是真正存在授权争议,而是协议签署之前没有人明确规定:由谁签发这份文件、多久内必须交付,以及文件中应该写些什么。
正因如此,LOA 的处理方式其实可以作为判断整体地址资源安排质量的一个很好指标。如果出租方能够快速提供正确的 LOA,一次就准确写明正确的 ASN 和前缀,不需要来回修改三次;当你更换上游时能够迅速重新签发;并且同时保持 ROA 与 route object 一致,那么它实际上正在展示生产环境路由所需要的运营纪律。相反,如果出租方认为 LOA 只是以后再处理的文书工作,那么整个合作关系中的其他环节很可能也会以类似方式处理。文件本身并不复杂,真正重要的是背后的协调能力,而正是这种协调,才能把一段地址空间变成真正可运行的网络基础设施。无论你是租赁还是直接取得地址空间,都应该把路由授权视为一个具有明确期限的正式交付成果,而不是默认它自然会出现。
总结
授权书(LOA)是注册持有者以书面形式授予某个指定方,通过指定 ASN 公告特定前缀的许可。上游服务提供商之所以要求 LOA,是因为仅凭注册数据无法确认公告方是否真正获得授权,而接受未经授权的公告就意味着参与路由劫持。文件会列出持有者、被授权方及 ASN、具体前缀和有效期,并由有权授予该项授权的人签署——它正处于“拥有地址空间”与“能够真正将其路由上线”之间的关键路径上。
最值得记住的区别,是 LOA 能做什么,以及不能做什么。它授权路由公告;它不会转移所有权、不会更改注册信息,也不会授予任何注册管理层面的权利。在租赁关系中,地址空间仍然注册在持有者名下,而租户的公告权来自持有者授予的授权——这也正是为什么 LOA 必须存在,而且必须由持有者出具。再加上由路由器验证的 ROA,以及供过滤系统查询的 route object,LOA 才共同组成将合同权利转化为被网络接受的路由公告所需要的完整记录体系。在部署之前让三者保持一致,在付款之前核实 LOA 的具体内容,才能真正把你已经安排好的地址空间变成可以实际使用的基础设施。
相关阅读
什么是 BGP 劫持?路由劫持如何发生、著名事件以及网络如何防范
RPKI 与 ROA 详解:路由起源授权如何保护你的 IPv4 前缀
什么是 BGP?边界网关协议如何让 IP 地址成为可访问的服务
授权书(Letter of Authorization,LOA)是一份正式文件,由 IP 地址块的注册持有者授权另一方通过指定的自治系统编号(ASN)公告该地址空间。 它是一份书面授权,将使用地址空间的合同权利与实际进行路由公告的技术行为连接起来——如果没有 LOA,上游服务提供商通常会拒绝接受你的路由公告。
正是这种拒绝,使 LOA 在运营上具有决定性意义,而不仅仅是一项行政文件。Transit 服务提供商、数据中心和电信运营商都需要证明,公告某个前缀的一方确实获得了授权,因为接受未经授权的公告就意味着参与了一次路由劫持。Cloudflare 的 BYOIP 文档对此说明得非常明确:其 Transit 服务提供商要求在接受 Cloudflare 代表客户公告的路由之前提供 LOA,而且文件必须明确列出获得授权的前缀以及将用于公告这些前缀的 ASN。整个行业普遍都有类似要求。一家企业即使已经签署租赁协议、完成路由器配置,仍然可能因为 LOA 尚未提供而无法让服务上线。
这份文件还具体体现了一个重要概念,尤其对于租赁地址空间的企业来说十分关键:LOA 授权的是路由公告——它不会转移所有权,也不会更改注册信息。 地址空间仍然注册在原持有者名下;LOA 所授予的只是对该地址空间进行路由的权限。本文将介绍 LOA 包含哪些内容、为什么服务提供商需要它、它与 ROA 和 IRR route object 有什么区别、谁有资格合法签发 LOA,以及在你为准备公告的地址空间付款之前,究竟应该核实哪些事项。
什么是授权书(LOA)?
LOA 是由 IP 地址空间的注册持有者签署的一份声明,授权指定的一方通过指定的 ASN 公告特定前缀。 它有时也被称为 Letter of Agency,是一份由人撰写、签署并由上游服务提供商工作人员阅读的合同性质文件,而不是由路由器自动读取的技术记录。
它的作用,是回答路由系统本身无法独立回答的一个问题。公共注册数据能够显示某个地址块由哪个组织持有,但不会显示该持有者允许谁公告这个地址块。当注册持有者以外的网络希望成为某个前缀的起源网络时——例如租户公告租赁的地址空间、服务提供商公告客户的地址块,或平台公告客户的 BYOIP 前缀——上游服务提供商就需要证据证明这一安排已经获得授权。LOA 就是这种证据。
它有两个核心特征:
- 在签署协议之前,确认协议明确要求持有者签发 LOA,并规定具体交付时间。
- 在付款之前取得 LOA,或者至少取得书面的交付保证。
- 核实准确的前缀与实际租赁或取得的地址块完全一致。
- 核实 ASN 与实际将作为起源网络进行公告的 ASN 完全一致。
- 检查有效期是否覆盖整个租赁或部署周期。
- 确认文件使用注册持有者的正式公司抬头,企业资料与注册记录一致,并有可以识别的授权签署人。
- 按照上游要求的格式提交——PDF 是最稳妥的默认选择;图片格式经常会被拒绝。
- 确认如果上游、ASN 或授权范围发生变化,重新签发的流程以及处理时间。
- 确保 LOA、ROA 和 IRR route object 保持一致,让三种授权记录不会互相冲突。
- 保存一份副本——增加其他服务提供商、进行审计或未来修改部署时,都可能再次需要。
来自 i.lease 的实用说明
LOA 是一份很小的文件,但其运营影响远远超过文件本身的复杂程度。它在技术上并不复杂,只要有权签署的人愿意配合,通常几分钟就可以制作出来,但它却是租赁或新取得的地址块已经付费、却迟迟无法投入使用的最常见原因之一。问题几乎从来不是真正存在授权争议,而是协议签署之前没有人明确规定:由谁签发这份文件、多久内必须交付,以及文件中应该写些什么。
正因如此,LOA 的处理方式其实可以作为判断整体地址资源安排质量的一个很好指标。如果出租方能够快速提供正确的 LOA,一次就准确写明正确的 ASN 和前缀,不需要来回修改三次;当你更换上游时能够迅速重新签发;并且同时保持 ROA 与 route object 一致,那么它实际上正在展示生产环境路由所需要的运营纪律。相反,如果出租方认为 LOA 只是以后再处理的文书工作,那么整个合作关系中的其他环节很可能也会以类似方式处理。文件本身并不复杂,真正重要的是背后的协调能力,而正是这种协调,才能把一段地址空间变成真正可运行的网络基础设施。无论你是租赁还是直接取得地址空间,都应该把路由授权视为一个具有明确期限的正式交付成果,而不是默认它自然会出现。
总结
授权书(LOA)是注册持有者以书面形式授予某个指定方,通过指定 ASN 公告特定前缀的许可。上游服务提供商之所以要求 LOA,是因为仅凭注册数据无法确认公告方是否真正获得授权,而接受未经授权的公告就意味着参与路由劫持。文件会列出持有者、被授权方及 ASN、具体前缀和有效期,并由有权授予该项授权的人签署——它正处于“拥有地址空间”与“能够真正将其路由上线”之间的关键路径上。
最值得记住的区别,是 LOA 能做什么,以及不能做什么。它授权路由公告;它不会转移所有权、不会更改注册信息,也不会授予任何注册管理层面的权利。在租赁关系中,地址空间仍然注册在持有者名下,而租户的公告权来自持有者授予的授权——这也正是为什么 LOA 必须存在,而且必须由持有者出具。再加上由路由器验证的 ROA,以及供过滤系统查询的 route object,LOA 才共同组成将合同权利转化为被网络接受的路由公告所需要的完整记录体系。在部署之前让三者保持一致,在付款之前核实 LOA 的具体内容,才能真正把你已经安排好的地址空间变成可以实际使用的基础设施。
相关阅读
什么是 BGP 劫持?路由劫持如何发生、著名事件以及网络如何防范
RPKI 与 ROA 详解:路由起源授权如何保护你的 IPv4 前缀
什么是 BGP?边界网关协议如何让 IP 地址成为可访问的服务
- 付款前取得 LOA,或者取得书面的交付承诺。 最好直接拿到文件;如果做不到,也应在协议中明确规定,必须在一个确定且较短的时间内交付。如果出租方连这两者中的任何一种都不愿意承诺,那已经说明了后续合作关系可能会是什么样子。
- 确认 LOA 中列出了正确的前缀。 应当准确列出你实际租赁的地址块。LOA 如果覆盖了不同地址块或过大的范围,上游可能会提出质疑;如果覆盖范围小于你所需,也无法授权剩余部分。
- 确认 LOA 中列出了正确的 ASN。 必须是实际会成为起源网络的 ASN——根据你的部署方式,这可能是你自己的 ASN,也可能是上游的 ASN。错误的 ASN 是一份形式上有效的 LOA 仍然无法帮助部署上线的最常见原因之一。
- 核对有效期与租赁期限。 如果授权比租赁期限更早到期,就会在部署过程中产生重新签发 LOA 的依赖。
- 确认文件确实来自注册持有者。 公司抬头和企业资料应与注册记录一致,并由可以识别且确实有授权权限的人签署。
- 确认重新签发流程。 如果你更换上游、更换 ASN,或需要为第二家服务提供商增加一份 LOA,更新文件最快可以在多久内提供?实际部署会发生变化,而授权文件必须能够同步更新。
- 询问 LOA 如何与 ROA 和 route object 配合。 单独拥有 LOA 并不够——正如上面的比较所示,ROA 和 IRR 记录也必须保持一致。能够完整处理这三项内容的出租方,比只提供一份文件然后把其余事情全部交给你的出租方,更适合生产环境部署。
这些问题在签约之前提出几乎没有成本,但签约之后才提出往往代价高昂。综合来看,它们也是判断租赁质量非常可靠的信号:如果一个地址安排将路由授权明确视为具有交付期限的正式交付成果,那么它通常是按照生产环境需求设计的;反之,如果把授权当成事后再处理的细节,那么这个问题往往会在最糟糕的时候暴露出来。
常见 LOA 问题
大多数 LOA 问题并不是围绕授权本身产生争议,而是文件交付太迟、内容错误或已经过期。 常见情况包括:
- 交付延迟。 这是最常见、也是成本最高的问题。只要文件一天没有到位,地址空间就一天无法正常公告,无论其他部分准备得多么充分。
- ASN 错误。 LOA 授权了一个与实际发起公告不同的 ASN——通常是因为文件起草之后部署方案发生变化,或出租方误解了租户的上游安排。
- 前缀错误或不够准确。 文件列出的地址块不正确、范围比协议约定更大,或者描述过于模糊,以至于上游不愿据此配置路由。
- 授权已经过期。 有效期已经结束,通常是在服务提供商重新审核文件,或租赁期内新增上游时才被发现。
- 签署人没有授权或无法验证。 文件由上游无法确认其权限的人签署,或者文件本身无法明确关联到注册持有者。
- 协议中完全没有规定 LOA。 租赁协议完全没有提到 LOA 的签发,因此交付时间和责任都没有定义——而交付延迟问题通常就是从这里开始。
这六类问题都可以在协议阶段提前避免,这也是为什么上面的核实清单比事后进行任何故障排查都更加重要。
实用检查清单
- 在签署协议之前,确认协议明确要求持有者签发 LOA,并规定具体交付时间。
- 在付款之前取得 LOA,或者至少取得书面的交付保证。
- 核实准确的前缀与实际租赁或取得的地址块完全一致。
- 核实 ASN 与实际将作为起源网络进行公告的 ASN 完全一致。
- 检查有效期是否覆盖整个租赁或部署周期。
- 确认文件使用注册持有者的正式公司抬头,企业资料与注册记录一致,并有可以识别的授权签署人。
- 按照上游要求的格式提交——PDF 是最稳妥的默认选择;图片格式经常会被拒绝。
- 确认如果上游、ASN 或授权范围发生变化,重新签发的流程以及处理时间。
- 确保 LOA、ROA 和 IRR route object 保持一致,让三种授权记录不会互相冲突。
- 保存一份副本——增加其他服务提供商、进行审计或未来修改部署时,都可能再次需要。
来自 i.lease 的实用说明
LOA 是一份很小的文件,但其运营影响远远超过文件本身的复杂程度。它在技术上并不复杂,只要有权签署的人愿意配合,通常几分钟就可以制作出来,但它却是租赁或新取得的地址块已经付费、却迟迟无法投入使用的最常见原因之一。问题几乎从来不是真正存在授权争议,而是协议签署之前没有人明确规定:由谁签发这份文件、多久内必须交付,以及文件中应该写些什么。
正因如此,LOA 的处理方式其实可以作为判断整体地址资源安排质量的一个很好指标。如果出租方能够快速提供正确的 LOA,一次就准确写明正确的 ASN 和前缀,不需要来回修改三次;当你更换上游时能够迅速重新签发;并且同时保持 ROA 与 route object 一致,那么它实际上正在展示生产环境路由所需要的运营纪律。相反,如果出租方认为 LOA 只是以后再处理的文书工作,那么整个合作关系中的其他环节很可能也会以类似方式处理。文件本身并不复杂,真正重要的是背后的协调能力,而正是这种协调,才能把一段地址空间变成真正可运行的网络基础设施。无论你是租赁还是直接取得地址空间,都应该把路由授权视为一个具有明确期限的正式交付成果,而不是默认它自然会出现。
总结
授权书(LOA)是注册持有者以书面形式授予某个指定方,通过指定 ASN 公告特定前缀的许可。上游服务提供商之所以要求 LOA,是因为仅凭注册数据无法确认公告方是否真正获得授权,而接受未经授权的公告就意味着参与路由劫持。文件会列出持有者、被授权方及 ASN、具体前缀和有效期,并由有权授予该项授权的人签署——它正处于“拥有地址空间”与“能够真正将其路由上线”之间的关键路径上。
最值得记住的区别,是 LOA 能做什么,以及不能做什么。它授权路由公告;它不会转移所有权、不会更改注册信息,也不会授予任何注册管理层面的权利。在租赁关系中,地址空间仍然注册在持有者名下,而租户的公告权来自持有者授予的授权——这也正是为什么 LOA 必须存在,而且必须由持有者出具。再加上由路由器验证的 ROA,以及供过滤系统查询的 route object,LOA 才共同组成将合同权利转化为被网络接受的路由公告所需要的完整记录体系。在部署之前让三者保持一致,在付款之前核实 LOA 的具体内容,才能真正把你已经安排好的地址空间变成可以实际使用的基础设施。
相关阅读
什么是 BGP 劫持?路由劫持如何发生、著名事件以及网络如何防范
RPKI 与 ROA 详解:路由起源授权如何保护你的 IPv4 前缀
什么是 BGP?边界网关协议如何让 IP 地址成为可访问的服务
- LOA 授权的是公告,并不转移所有权。 签署 LOA 只是授予对地址空间进行路由的许可。它不会让被授权方成为该地址空间的持有者,不会更改注册记录,也不会转移任何注册管理层面的权利。当授权终止时,该项公告权限也随之终止。
- 在整个租赁期间,注册信息仍然保留在持有者名下。 在租赁安排中,注册管理机构的记录会继续显示原持有者为注册方。这并不是租赁关系中的漏洞——这正是租赁模式本身的结构。租户的公告权来自所获得的授权,而不是来自注册信息的改变。
- 进行公告不等于持有地址空间。 一个网络公告某个前缀,意味着它正在作为起源网络发布该前缀,这反映的是它获得了授权。公告本身并不能证明所有权。这种区分在概念和实际操作上都非常重要,因为未经授权的公告本身正是路由劫持的定义之一。
对于接收公告的上游服务提供商来说,这些区别最终会转化成一个验证问题:签署人真的拥有他们所声称的授权权力吗?这就是为什么 LOA 通常需要使用持有者的公司抬头纸、公司资料必须与注册记录相符,并由身份和职位明确的人签署。任何无法追溯到注册持有者的文件,都不能算真正的授权——那只能算是一项单方面声明。
LOA 与租赁 IPv4:付款之前应该核实什么?
由于 LOA 位于路由上线流程的关键路径上,因此应该在付款之前确认其处理方式,而不是付款之后才发现问题。 这个失败模式在行业中非常常见:企业签署了租赁协议、配置好路由、通知了上游,然后才被要求提供一份租赁协议中从未提及、而出租方又迟迟无法出具的 LOA。在文件到达之前,地址已经付费,却无法使用。
以下事项应当提前确认:
- 付款前取得 LOA,或者取得书面的交付承诺。 最好直接拿到文件;如果做不到,也应在协议中明确规定,必须在一个确定且较短的时间内交付。如果出租方连这两者中的任何一种都不愿意承诺,那已经说明了后续合作关系可能会是什么样子。
- 确认 LOA 中列出了正确的前缀。 应当准确列出你实际租赁的地址块。LOA 如果覆盖了不同地址块或过大的范围,上游可能会提出质疑;如果覆盖范围小于你所需,也无法授权剩余部分。
- 确认 LOA 中列出了正确的 ASN。 必须是实际会成为起源网络的 ASN——根据你的部署方式,这可能是你自己的 ASN,也可能是上游的 ASN。错误的 ASN 是一份形式上有效的 LOA 仍然无法帮助部署上线的最常见原因之一。
- 核对有效期与租赁期限。 如果授权比租赁期限更早到期,就会在部署过程中产生重新签发 LOA 的依赖。
- 确认文件确实来自注册持有者。 公司抬头和企业资料应与注册记录一致,并由可以识别且确实有授权权限的人签署。
- 确认重新签发流程。 如果你更换上游、更换 ASN,或需要为第二家服务提供商增加一份 LOA,更新文件最快可以在多久内提供?实际部署会发生变化,而授权文件必须能够同步更新。
- 询问 LOA 如何与 ROA 和 route object 配合。 单独拥有 LOA 并不够——正如上面的比较所示,ROA 和 IRR 记录也必须保持一致。能够完整处理这三项内容的出租方,比只提供一份文件然后把其余事情全部交给你的出租方,更适合生产环境部署。
这些问题在签约之前提出几乎没有成本,但签约之后才提出往往代价高昂。综合来看,它们也是判断租赁质量非常可靠的信号:如果一个地址安排将路由授权明确视为具有交付期限的正式交付成果,那么它通常是按照生产环境需求设计的;反之,如果把授权当成事后再处理的细节,那么这个问题往往会在最糟糕的时候暴露出来。
常见 LOA 问题
大多数 LOA 问题并不是围绕授权本身产生争议,而是文件交付太迟、内容错误或已经过期。 常见情况包括:
- 交付延迟。 这是最常见、也是成本最高的问题。只要文件一天没有到位,地址空间就一天无法正常公告,无论其他部分准备得多么充分。
- ASN 错误。 LOA 授权了一个与实际发起公告不同的 ASN——通常是因为文件起草之后部署方案发生变化,或出租方误解了租户的上游安排。
- 前缀错误或不够准确。 文件列出的地址块不正确、范围比协议约定更大,或者描述过于模糊,以至于上游不愿据此配置路由。
- 授权已经过期。 有效期已经结束,通常是在服务提供商重新审核文件,或租赁期内新增上游时才被发现。
- 签署人没有授权或无法验证。 文件由上游无法确认其权限的人签署,或者文件本身无法明确关联到注册持有者。
- 协议中完全没有规定 LOA。 租赁协议完全没有提到 LOA 的签发,因此交付时间和责任都没有定义——而交付延迟问题通常就是从这里开始。
这六类问题都可以在协议阶段提前避免,这也是为什么上面的核实清单比事后进行任何故障排查都更加重要。
实用检查清单
- 在签署协议之前,确认协议明确要求持有者签发 LOA,并规定具体交付时间。
- 在付款之前取得 LOA,或者至少取得书面的交付保证。
- 核实准确的前缀与实际租赁或取得的地址块完全一致。
- 核实 ASN 与实际将作为起源网络进行公告的 ASN 完全一致。
- 检查有效期是否覆盖整个租赁或部署周期。
- 确认文件使用注册持有者的正式公司抬头,企业资料与注册记录一致,并有可以识别的授权签署人。
- 按照上游要求的格式提交——PDF 是最稳妥的默认选择;图片格式经常会被拒绝。
- 确认如果上游、ASN 或授权范围发生变化,重新签发的流程以及处理时间。
- 确保 LOA、ROA 和 IRR route object 保持一致,让三种授权记录不会互相冲突。
- 保存一份副本——增加其他服务提供商、进行审计或未来修改部署时,都可能再次需要。
来自 i.lease 的实用说明
LOA 是一份很小的文件,但其运营影响远远超过文件本身的复杂程度。它在技术上并不复杂,只要有权签署的人愿意配合,通常几分钟就可以制作出来,但它却是租赁或新取得的地址块已经付费、却迟迟无法投入使用的最常见原因之一。问题几乎从来不是真正存在授权争议,而是协议签署之前没有人明确规定:由谁签发这份文件、多久内必须交付,以及文件中应该写些什么。
正因如此,LOA 的处理方式其实可以作为判断整体地址资源安排质量的一个很好指标。如果出租方能够快速提供正确的 LOA,一次就准确写明正确的 ASN 和前缀,不需要来回修改三次;当你更换上游时能够迅速重新签发;并且同时保持 ROA 与 route object 一致,那么它实际上正在展示生产环境路由所需要的运营纪律。相反,如果出租方认为 LOA 只是以后再处理的文书工作,那么整个合作关系中的其他环节很可能也会以类似方式处理。文件本身并不复杂,真正重要的是背后的协调能力,而正是这种协调,才能把一段地址空间变成真正可运行的网络基础设施。无论你是租赁还是直接取得地址空间,都应该把路由授权视为一个具有明确期限的正式交付成果,而不是默认它自然会出现。
总结
授权书(LOA)是注册持有者以书面形式授予某个指定方,通过指定 ASN 公告特定前缀的许可。上游服务提供商之所以要求 LOA,是因为仅凭注册数据无法确认公告方是否真正获得授权,而接受未经授权的公告就意味着参与路由劫持。文件会列出持有者、被授权方及 ASN、具体前缀和有效期,并由有权授予该项授权的人签署——它正处于“拥有地址空间”与“能够真正将其路由上线”之间的关键路径上。
最值得记住的区别,是 LOA 能做什么,以及不能做什么。它授权路由公告;它不会转移所有权、不会更改注册信息,也不会授予任何注册管理层面的权利。在租赁关系中,地址空间仍然注册在持有者名下,而租户的公告权来自持有者授予的授权——这也正是为什么 LOA 必须存在,而且必须由持有者出具。再加上由路由器验证的 ROA,以及供过滤系统查询的 route object,LOA 才共同组成将合同权利转化为被网络接受的路由公告所需要的完整记录体系。在部署之前让三者保持一致,在付款之前核实 LOA 的具体内容,才能真正把你已经安排好的地址空间变成可以实际使用的基础设施。
相关阅读
什么是 BGP 劫持?路由劫持如何发生、著名事件以及网络如何防范
RPKI 与 ROA 详解:路由起源授权如何保护你的 IPv4 前缀
什么是 BGP?边界网关协议如何让 IP 地址成为可访问的服务
- 授权方。 即地址空间的注册持有者,其公司名称和相关资料应与注册记录一致。
- 被授权方和 ASN。 文件需要说明谁被允许公告该地址空间,以及最关键的——将通过哪个自治系统编号进行公告。Cloudflare 的文档明确要求 LOA 同时写明被授权的前缀和公告所使用的 ASN——ASN 并不是可有可无的附加信息。
- 准确的前缀。 必须精确列出受授权覆盖的地址块(例如某个具体的 /24)。任何超出 LOA 所列范围的公告,都不属于该授权范围。
- 有效期。 授权的持续时间。对于租赁地址空间,其有效期应与租赁期限保持一致。
- 授权签署人。 包括姓名、职位以及有权代表持有者签署文件的人员签名,并附上联系方式,以便上游服务提供商在有需要时进行核实。
- 公司抬头和文件格式。 LOA 通常应以持有者公司的正式抬头纸制作。Cloudflare 指出,Transit 服务提供商可能会拒绝以图片格式提交的 LOA,而要求使用 PDF;数字签名通常可以接受,但签署人必须能够被清楚识别。
这些要求并不是毫无意义的行政装饰。公司抬头、与注册记录一致的企业资料,以及可识别的授权签署人,正是接收方用于确认文件真实性,以及签署人确实有权授予所声称授权的依据。
什么时候需要 LOA?
只要将由注册持有者以外的一方公告地址空间,通常都需要 LOA——这涵盖了绝大多数 IPv4 租赁、BYOIP 和由服务提供商代为公告的情况。 常见场景包括:
- 通过自己的 ASN 公告租赁的 IPv4。 这是最典型的情况:你租赁了一个地址块,并自行对外公告,因此你的上游需要看到持有者提供的授权。关于这个更完整的租赁流程,可以参考我们的IPv4 租赁指南以及IP 地址租赁如何运作的说明。
- 由服务提供商代表你公告地址空间。 当你的托管服务商、数据中心或平台通过其 ASN 公告你的前缀时,它需要获得你的授权——而它的上游同样需要看到这一授权。
- BYOIP 接入。 将自有 IP 地址空间(BYOIP)带入云平台或边缘平台时,需要授权该平台公告你的前缀,Cloudflare 的要求就是一个典型例子。
- 紧急路由变更。 例如 DDoS 清洗服务,在攻击发生时由服务提供商临时公告你的前缀,这类安排依赖于事先完成授权——这一点我们也在DDoS 缓解指南中进行了介绍。
判断标准其实很简单:如果进行公告的 ASN 并不属于注册持有者本身,那么几乎可以确定需要 LOA。
LOA vs ROA vs IRR Route Object
LOA、ROA 和 IRR route object 都在说明谁可以公告某个前缀——但它们面对不同的受众、采用不同形式,并且作用于不同层面。 它们彼此互补,而不是相互替代。一个正确部署的前缀,通常需要三者保持一致。
LOA vs ROA vs IRR Route Object
项目
LOA
ROA
IRR route object
它是什么
授予路由公告权限的签署文件
RPKI 中经过加密签名的记录
Internet Routing Registry 数据库中的记录
面向对象
人员——上游开通和 NOC 工作人员
执行路由起源验证的路由器
自动生成过滤规则的系统
形式
人类可读、合同性质
加密签名、机器验证
数据库记录
由谁创建
注册持有者(或授权代表)
注册持有者,通过其 RIR 创建
对象的持有者或 maintainer
缺失或错误时的影响
上游拒绝配置该路由公告
公告可能被执行 RPKI 验证的网络判定为 RPKI-Invalid 并拒绝
使用 IRR 数据生成过滤规则的服务提供商可能过滤该公告
最清楚的理解方式是:LOA 决定你的上游工作人员是否愿意配置并接受这项公告;ROA 决定互联网上执行验证的路由器是否认为该起源 ASN 合法;route object 则影响自动化过滤系统是否允许该公告通过。三者都可能独立出现问题,而且每一种失败都会产生不同的症状——这也是为什么部署有时会以看似完全不同的方式卡住,取决于究竟缺少哪一项记录。
这三者之间的互动也越来越紧密。例如,Cloudflare 的自动生成 LOA 流程会依赖经过 RPKI 签名的 ROA 以及所有权验证检查——也就是说,加密记录用于支持这份人工文件,而不是取代它。关于 ROA 的具体机制,包括它如何授权某个特定的起源 ASN,以及配置错误时会发生什么,请参阅我们的RPKI 和 ROA指南。
谁可以合法签发 LOA?
只有地址空间的注册持有者——或者被授权代表该持有者行事的人——才有资格合法签发 LOA。 这一点必须非常准确地说明,因为现实中经常有人把相关概念混淆。
有三个概念值得明确区分:
- LOA 授权的是公告,并不转移所有权。 签署 LOA 只是授予对地址空间进行路由的许可。它不会让被授权方成为该地址空间的持有者,不会更改注册记录,也不会转移任何注册管理层面的权利。当授权终止时,该项公告权限也随之终止。
- 在整个租赁期间,注册信息仍然保留在持有者名下。 在租赁安排中,注册管理机构的记录会继续显示原持有者为注册方。这并不是租赁关系中的漏洞——这正是租赁模式本身的结构。租户的公告权来自所获得的授权,而不是来自注册信息的改变。
- 进行公告不等于持有地址空间。 一个网络公告某个前缀,意味着它正在作为起源网络发布该前缀,这反映的是它获得了授权。公告本身并不能证明所有权。这种区分在概念和实际操作上都非常重要,因为未经授权的公告本身正是路由劫持的定义之一。
对于接收公告的上游服务提供商来说,这些区别最终会转化成一个验证问题:签署人真的拥有他们所声称的授权权力吗?这就是为什么 LOA 通常需要使用持有者的公司抬头纸、公司资料必须与注册记录相符,并由身份和职位明确的人签署。任何无法追溯到注册持有者的文件,都不能算真正的授权——那只能算是一项单方面声明。
LOA 与租赁 IPv4:付款之前应该核实什么?
由于 LOA 位于路由上线流程的关键路径上,因此应该在付款之前确认其处理方式,而不是付款之后才发现问题。 这个失败模式在行业中非常常见:企业签署了租赁协议、配置好路由、通知了上游,然后才被要求提供一份租赁协议中从未提及、而出租方又迟迟无法出具的 LOA。在文件到达之前,地址已经付费,却无法使用。
以下事项应当提前确认:
- 付款前取得 LOA,或者取得书面的交付承诺。 最好直接拿到文件;如果做不到,也应在协议中明确规定,必须在一个确定且较短的时间内交付。如果出租方连这两者中的任何一种都不愿意承诺,那已经说明了后续合作关系可能会是什么样子。
- 确认 LOA 中列出了正确的前缀。 应当准确列出你实际租赁的地址块。LOA 如果覆盖了不同地址块或过大的范围,上游可能会提出质疑;如果覆盖范围小于你所需,也无法授权剩余部分。
- 确认 LOA 中列出了正确的 ASN。 必须是实际会成为起源网络的 ASN——根据你的部署方式,这可能是你自己的 ASN,也可能是上游的 ASN。错误的 ASN 是一份形式上有效的 LOA 仍然无法帮助部署上线的最常见原因之一。
- 核对有效期与租赁期限。 如果授权比租赁期限更早到期,就会在部署过程中产生重新签发 LOA 的依赖。
- 确认文件确实来自注册持有者。 公司抬头和企业资料应与注册记录一致,并由可以识别且确实有授权权限的人签署。
- 确认重新签发流程。 如果你更换上游、更换 ASN,或需要为第二家服务提供商增加一份 LOA,更新文件最快可以在多久内提供?实际部署会发生变化,而授权文件必须能够同步更新。
- 询问 LOA 如何与 ROA 和 route object 配合。 单独拥有 LOA 并不够——正如上面的比较所示,ROA 和 IRR 记录也必须保持一致。能够完整处理这三项内容的出租方,比只提供一份文件然后把其余事情全部交给你的出租方,更适合生产环境部署。
这些问题在签约之前提出几乎没有成本,但签约之后才提出往往代价高昂。综合来看,它们也是判断租赁质量非常可靠的信号:如果一个地址安排将路由授权明确视为具有交付期限的正式交付成果,那么它通常是按照生产环境需求设计的;反之,如果把授权当成事后再处理的细节,那么这个问题往往会在最糟糕的时候暴露出来。
常见 LOA 问题
大多数 LOA 问题并不是围绕授权本身产生争议,而是文件交付太迟、内容错误或已经过期。 常见情况包括:
- 交付延迟。 这是最常见、也是成本最高的问题。只要文件一天没有到位,地址空间就一天无法正常公告,无论其他部分准备得多么充分。
- ASN 错误。 LOA 授权了一个与实际发起公告不同的 ASN——通常是因为文件起草之后部署方案发生变化,或出租方误解了租户的上游安排。
- 前缀错误或不够准确。 文件列出的地址块不正确、范围比协议约定更大,或者描述过于模糊,以至于上游不愿据此配置路由。
- 授权已经过期。 有效期已经结束,通常是在服务提供商重新审核文件,或租赁期内新增上游时才被发现。
- 签署人没有授权或无法验证。 文件由上游无法确认其权限的人签署,或者文件本身无法明确关联到注册持有者。
- 协议中完全没有规定 LOA。 租赁协议完全没有提到 LOA 的签发,因此交付时间和责任都没有定义——而交付延迟问题通常就是从这里开始。
这六类问题都可以在协议阶段提前避免,这也是为什么上面的核实清单比事后进行任何故障排查都更加重要。
实用检查清单
- 在签署协议之前,确认协议明确要求持有者签发 LOA,并规定具体交付时间。
- 在付款之前取得 LOA,或者至少取得书面的交付保证。
- 核实准确的前缀与实际租赁或取得的地址块完全一致。
- 核实 ASN 与实际将作为起源网络进行公告的 ASN 完全一致。
- 检查有效期是否覆盖整个租赁或部署周期。
- 确认文件使用注册持有者的正式公司抬头,企业资料与注册记录一致,并有可以识别的授权签署人。
- 按照上游要求的格式提交——PDF 是最稳妥的默认选择;图片格式经常会被拒绝。
- 确认如果上游、ASN 或授权范围发生变化,重新签发的流程以及处理时间。
- 确保 LOA、ROA 和 IRR route object 保持一致,让三种授权记录不会互相冲突。
- 保存一份副本——增加其他服务提供商、进行审计或未来修改部署时,都可能再次需要。
来自 i.lease 的实用说明
LOA 是一份很小的文件,但其运营影响远远超过文件本身的复杂程度。它在技术上并不复杂,只要有权签署的人愿意配合,通常几分钟就可以制作出来,但它却是租赁或新取得的地址块已经付费、却迟迟无法投入使用的最常见原因之一。问题几乎从来不是真正存在授权争议,而是协议签署之前没有人明确规定:由谁签发这份文件、多久内必须交付,以及文件中应该写些什么。
正因如此,LOA 的处理方式其实可以作为判断整体地址资源安排质量的一个很好指标。如果出租方能够快速提供正确的 LOA,一次就准确写明正确的 ASN 和前缀,不需要来回修改三次;当你更换上游时能够迅速重新签发;并且同时保持 ROA 与 route object 一致,那么它实际上正在展示生产环境路由所需要的运营纪律。相反,如果出租方认为 LOA 只是以后再处理的文书工作,那么整个合作关系中的其他环节很可能也会以类似方式处理。文件本身并不复杂,真正重要的是背后的协调能力,而正是这种协调,才能把一段地址空间变成真正可运行的网络基础设施。无论你是租赁还是直接取得地址空间,都应该把路由授权视为一个具有明确期限的正式交付成果,而不是默认它自然会出现。
总结
授权书(LOA)是注册持有者以书面形式授予某个指定方,通过指定 ASN 公告特定前缀的许可。上游服务提供商之所以要求 LOA,是因为仅凭注册数据无法确认公告方是否真正获得授权,而接受未经授权的公告就意味着参与路由劫持。文件会列出持有者、被授权方及 ASN、具体前缀和有效期,并由有权授予该项授权的人签署——它正处于“拥有地址空间”与“能够真正将其路由上线”之间的关键路径上。
最值得记住的区别,是 LOA 能做什么,以及不能做什么。它授权路由公告;它不会转移所有权、不会更改注册信息,也不会授予任何注册管理层面的权利。在租赁关系中,地址空间仍然注册在持有者名下,而租户的公告权来自持有者授予的授权——这也正是为什么 LOA 必须存在,而且必须由持有者出具。再加上由路由器验证的 ROA,以及供过滤系统查询的 route object,LOA 才共同组成将合同权利转化为被网络接受的路由公告所需要的完整记录体系。在部署之前让三者保持一致,在付款之前核实 LOA 的具体内容,才能真正把你已经安排好的地址空间变成可以实际使用的基础设施。
相关阅读
什么是 BGP 劫持?路由劫持如何发生、著名事件以及网络如何防范
RPKI 与 ROA 详解:路由起源授权如何保护你的 IPv4 前缀
什么是 BGP?边界网关协议如何让 IP 地址成为可访问的服务
- 它由持有者签发,而不是由公告方自行签发。 有权授予许可的一方,是地址空间的持有者。租户不能自己给自己写一份 LOA。
- 它必须具有明确的针对性。 文件需要列出具体的前缀以及具体的 ASN。仅仅说明某方“信誉良好”并不能构成 LOA;文件中的内容必须与实际将要公告的内容完全匹配。
为什么上游服务提供商要求 LOA?
服务提供商之所以要求 LOA,是因为接受一个未经授权方发出的路由公告,正是前缀劫持发生的方式——而任何负责任的网络都不希望成为传播这种错误公告的一方。
正如我们在BGP 如何运作的指南中所解释的,路由系统在很大程度上是基于信任接受公告的,而各个网络之所以会过滤接收到的路由,正是因为虚假公告可能将属于其他人的流量重定向。这个风险并不是理论上的:未经授权的路由公告正是我们在BGP 劫持指南中所介绍事件的核心机制。如果上游服务提供商在未核实授权的情况下接受公告,那么它就会无意间成为后续事件的参与者。
LOA 填补的正是一个具体的信息缺口。注册记录可以确认地址持有者,但在租赁情况下,注册记录仍然显示原持有者,而实际进行公告的是另一方——因此,上游服务提供商无法仅通过数据库查询来验证租户。LOA 补上了缺失的这一环:由注册记录中可识别的那一方,以书面形式确认实际进行公告的一方已经获得许可。
在实际部署中,这意味着 LOA 位于整个上线流程的关键路径上。路由器已经配置、租赁协议已经签署、地址块已经分配——这些都无法真正带来可达性,直到上游服务提供商接受这条路由公告,而在没有 LOA 的情况下,上游通常不会接受。
LOA 包含哪些内容?
LOA 会明确授权方、被授权方及其 ASN、具体前缀,以及有权授予该项授权人员的签名。 各家服务提供商通常要求的标准组成部分包括:
- 授权方。 即地址空间的注册持有者,其公司名称和相关资料应与注册记录一致。
- 被授权方和 ASN。 文件需要说明谁被允许公告该地址空间,以及最关键的——将通过哪个自治系统编号进行公告。Cloudflare 的文档明确要求 LOA 同时写明被授权的前缀和公告所使用的 ASN——ASN 并不是可有可无的附加信息。
- 准确的前缀。 必须精确列出受授权覆盖的地址块(例如某个具体的 /24)。任何超出 LOA 所列范围的公告,都不属于该授权范围。
- 有效期。 授权的持续时间。对于租赁地址空间,其有效期应与租赁期限保持一致。
- 授权签署人。 包括姓名、职位以及有权代表持有者签署文件的人员签名,并附上联系方式,以便上游服务提供商在有需要时进行核实。
- 公司抬头和文件格式。 LOA 通常应以持有者公司的正式抬头纸制作。Cloudflare 指出,Transit 服务提供商可能会拒绝以图片格式提交的 LOA,而要求使用 PDF;数字签名通常可以接受,但签署人必须能够被清楚识别。
这些要求并不是毫无意义的行政装饰。公司抬头、与注册记录一致的企业资料,以及可识别的授权签署人,正是接收方用于确认文件真实性,以及签署人确实有权授予所声称授权的依据。
什么时候需要 LOA?
只要将由注册持有者以外的一方公告地址空间,通常都需要 LOA——这涵盖了绝大多数 IPv4 租赁、BYOIP 和由服务提供商代为公告的情况。 常见场景包括:
- 通过自己的 ASN 公告租赁的 IPv4。 这是最典型的情况:你租赁了一个地址块,并自行对外公告,因此你的上游需要看到持有者提供的授权。关于这个更完整的租赁流程,可以参考我们的IPv4 租赁指南以及IP 地址租赁如何运作的说明。
- 由服务提供商代表你公告地址空间。 当你的托管服务商、数据中心或平台通过其 ASN 公告你的前缀时,它需要获得你的授权——而它的上游同样需要看到这一授权。
- BYOIP 接入。 将自有 IP 地址空间(BYOIP)带入云平台或边缘平台时,需要授权该平台公告你的前缀,Cloudflare 的要求就是一个典型例子。
- 紧急路由变更。 例如 DDoS 清洗服务,在攻击发生时由服务提供商临时公告你的前缀,这类安排依赖于事先完成授权——这一点我们也在DDoS 缓解指南中进行了介绍。
判断标准其实很简单:如果进行公告的 ASN 并不属于注册持有者本身,那么几乎可以确定需要 LOA。
LOA vs ROA vs IRR Route Object
LOA、ROA 和 IRR route object 都在说明谁可以公告某个前缀——但它们面对不同的受众、采用不同形式,并且作用于不同层面。 它们彼此互补,而不是相互替代。一个正确部署的前缀,通常需要三者保持一致。
LOA vs ROA vs IRR Route Object
项目
LOA
ROA
IRR route object
它是什么
授予路由公告权限的签署文件
RPKI 中经过加密签名的记录
Internet Routing Registry 数据库中的记录
面向对象
人员——上游开通和 NOC 工作人员
执行路由起源验证的路由器
自动生成过滤规则的系统
形式
人类可读、合同性质
加密签名、机器验证
数据库记录
由谁创建
注册持有者(或授权代表)
注册持有者,通过其 RIR 创建
对象的持有者或 maintainer
缺失或错误时的影响
上游拒绝配置该路由公告
公告可能被执行 RPKI 验证的网络判定为 RPKI-Invalid 并拒绝
使用 IRR 数据生成过滤规则的服务提供商可能过滤该公告
最清楚的理解方式是:LOA 决定你的上游工作人员是否愿意配置并接受这项公告;ROA 决定互联网上执行验证的路由器是否认为该起源 ASN 合法;route object 则影响自动化过滤系统是否允许该公告通过。三者都可能独立出现问题,而且每一种失败都会产生不同的症状——这也是为什么部署有时会以看似完全不同的方式卡住,取决于究竟缺少哪一项记录。
这三者之间的互动也越来越紧密。例如,Cloudflare 的自动生成 LOA 流程会依赖经过 RPKI 签名的 ROA 以及所有权验证检查——也就是说,加密记录用于支持这份人工文件,而不是取代它。关于 ROA 的具体机制,包括它如何授权某个特定的起源 ASN,以及配置错误时会发生什么,请参阅我们的RPKI 和 ROA指南。
谁可以合法签发 LOA?
只有地址空间的注册持有者——或者被授权代表该持有者行事的人——才有资格合法签发 LOA。 这一点必须非常准确地说明,因为现实中经常有人把相关概念混淆。
有三个概念值得明确区分:
- LOA 授权的是公告,并不转移所有权。 签署 LOA 只是授予对地址空间进行路由的许可。它不会让被授权方成为该地址空间的持有者,不会更改注册记录,也不会转移任何注册管理层面的权利。当授权终止时,该项公告权限也随之终止。
- 在整个租赁期间,注册信息仍然保留在持有者名下。 在租赁安排中,注册管理机构的记录会继续显示原持有者为注册方。这并不是租赁关系中的漏洞——这正是租赁模式本身的结构。租户的公告权来自所获得的授权,而不是来自注册信息的改变。
- 进行公告不等于持有地址空间。 一个网络公告某个前缀,意味着它正在作为起源网络发布该前缀,这反映的是它获得了授权。公告本身并不能证明所有权。这种区分在概念和实际操作上都非常重要,因为未经授权的公告本身正是路由劫持的定义之一。
对于接收公告的上游服务提供商来说,这些区别最终会转化成一个验证问题:签署人真的拥有他们所声称的授权权力吗?这就是为什么 LOA 通常需要使用持有者的公司抬头纸、公司资料必须与注册记录相符,并由身份和职位明确的人签署。任何无法追溯到注册持有者的文件,都不能算真正的授权——那只能算是一项单方面声明。
LOA 与租赁 IPv4:付款之前应该核实什么?
由于 LOA 位于路由上线流程的关键路径上,因此应该在付款之前确认其处理方式,而不是付款之后才发现问题。 这个失败模式在行业中非常常见:企业签署了租赁协议、配置好路由、通知了上游,然后才被要求提供一份租赁协议中从未提及、而出租方又迟迟无法出具的 LOA。在文件到达之前,地址已经付费,却无法使用。
以下事项应当提前确认:
- 付款前取得 LOA,或者取得书面的交付承诺。 最好直接拿到文件;如果做不到,也应在协议中明确规定,必须在一个确定且较短的时间内交付。如果出租方连这两者中的任何一种都不愿意承诺,那已经说明了后续合作关系可能会是什么样子。
- 确认 LOA 中列出了正确的前缀。 应当准确列出你实际租赁的地址块。LOA 如果覆盖了不同地址块或过大的范围,上游可能会提出质疑;如果覆盖范围小于你所需,也无法授权剩余部分。
- 确认 LOA 中列出了正确的 ASN。 必须是实际会成为起源网络的 ASN——根据你的部署方式,这可能是你自己的 ASN,也可能是上游的 ASN。错误的 ASN 是一份形式上有效的 LOA 仍然无法帮助部署上线的最常见原因之一。
- 核对有效期与租赁期限。 如果授权比租赁期限更早到期,就会在部署过程中产生重新签发 LOA 的依赖。
- 确认文件确实来自注册持有者。 公司抬头和企业资料应与注册记录一致,并由可以识别且确实有授权权限的人签署。
- 确认重新签发流程。 如果你更换上游、更换 ASN,或需要为第二家服务提供商增加一份 LOA,更新文件最快可以在多久内提供?实际部署会发生变化,而授权文件必须能够同步更新。
- 询问 LOA 如何与 ROA 和 route object 配合。 单独拥有 LOA 并不够——正如上面的比较所示,ROA 和 IRR 记录也必须保持一致。能够完整处理这三项内容的出租方,比只提供一份文件然后把其余事情全部交给你的出租方,更适合生产环境部署。
这些问题在签约之前提出几乎没有成本,但签约之后才提出往往代价高昂。综合来看,它们也是判断租赁质量非常可靠的信号:如果一个地址安排将路由授权明确视为具有交付期限的正式交付成果,那么它通常是按照生产环境需求设计的;反之,如果把授权当成事后再处理的细节,那么这个问题往往会在最糟糕的时候暴露出来。
常见 LOA 问题
大多数 LOA 问题并不是围绕授权本身产生争议,而是文件交付太迟、内容错误或已经过期。 常见情况包括:
- 交付延迟。 这是最常见、也是成本最高的问题。只要文件一天没有到位,地址空间就一天无法正常公告,无论其他部分准备得多么充分。
- ASN 错误。 LOA 授权了一个与实际发起公告不同的 ASN——通常是因为文件起草之后部署方案发生变化,或出租方误解了租户的上游安排。
- 前缀错误或不够准确。 文件列出的地址块不正确、范围比协议约定更大,或者描述过于模糊,以至于上游不愿据此配置路由。
- 授权已经过期。 有效期已经结束,通常是在服务提供商重新审核文件,或租赁期内新增上游时才被发现。
- 签署人没有授权或无法验证。 文件由上游无法确认其权限的人签署,或者文件本身无法明确关联到注册持有者。
- 协议中完全没有规定 LOA。 租赁协议完全没有提到 LOA 的签发,因此交付时间和责任都没有定义——而交付延迟问题通常就是从这里开始。
这六类问题都可以在协议阶段提前避免,这也是为什么上面的核实清单比事后进行任何故障排查都更加重要。
实用检查清单
- 在签署协议之前,确认协议明确要求持有者签发 LOA,并规定具体交付时间。
- 在付款之前取得 LOA,或者至少取得书面的交付保证。
- 核实准确的前缀与实际租赁或取得的地址块完全一致。
- 核实 ASN 与实际将作为起源网络进行公告的 ASN 完全一致。
- 检查有效期是否覆盖整个租赁或部署周期。
- 确认文件使用注册持有者的正式公司抬头,企业资料与注册记录一致,并有可以识别的授权签署人。
- 按照上游要求的格式提交——PDF 是最稳妥的默认选择;图片格式经常会被拒绝。
- 确认如果上游、ASN 或授权范围发生变化,重新签发的流程以及处理时间。
- 确保 LOA、ROA 和 IRR route object 保持一致,让三种授权记录不会互相冲突。
- 保存一份副本——增加其他服务提供商、进行审计或未来修改部署时,都可能再次需要。
来自 i.lease 的实用说明
LOA 是一份很小的文件,但其运营影响远远超过文件本身的复杂程度。它在技术上并不复杂,只要有权签署的人愿意配合,通常几分钟就可以制作出来,但它却是租赁或新取得的地址块已经付费、却迟迟无法投入使用的最常见原因之一。问题几乎从来不是真正存在授权争议,而是协议签署之前没有人明确规定:由谁签发这份文件、多久内必须交付,以及文件中应该写些什么。
正因如此,LOA 的处理方式其实可以作为判断整体地址资源安排质量的一个很好指标。如果出租方能够快速提供正确的 LOA,一次就准确写明正确的 ASN 和前缀,不需要来回修改三次;当你更换上游时能够迅速重新签发;并且同时保持 ROA 与 route object 一致,那么它实际上正在展示生产环境路由所需要的运营纪律。相反,如果出租方认为 LOA 只是以后再处理的文书工作,那么整个合作关系中的其他环节很可能也会以类似方式处理。文件本身并不复杂,真正重要的是背后的协调能力,而正是这种协调,才能把一段地址空间变成真正可运行的网络基础设施。无论你是租赁还是直接取得地址空间,都应该把路由授权视为一个具有明确期限的正式交付成果,而不是默认它自然会出现。
总结
授权书(LOA)是注册持有者以书面形式授予某个指定方,通过指定 ASN 公告特定前缀的许可。上游服务提供商之所以要求 LOA,是因为仅凭注册数据无法确认公告方是否真正获得授权,而接受未经授权的公告就意味着参与路由劫持。文件会列出持有者、被授权方及 ASN、具体前缀和有效期,并由有权授予该项授权的人签署——它正处于“拥有地址空间”与“能够真正将其路由上线”之间的关键路径上。
最值得记住的区别,是 LOA 能做什么,以及不能做什么。它授权路由公告;它不会转移所有权、不会更改注册信息,也不会授予任何注册管理层面的权利。在租赁关系中,地址空间仍然注册在持有者名下,而租户的公告权来自持有者授予的授权——这也正是为什么 LOA 必须存在,而且必须由持有者出具。再加上由路由器验证的 ROA,以及供过滤系统查询的 route object,LOA 才共同组成将合同权利转化为被网络接受的路由公告所需要的完整记录体系。在部署之前让三者保持一致,在付款之前核实 LOA 的具体内容,才能真正把你已经安排好的地址空间变成可以实际使用的基础设施。
相关阅读
什么是 BGP 劫持?路由劫持如何发生、著名事件以及网络如何防范
RPKI 与 ROA 详解:路由起源授权如何保护你的 IPv4 前缀




