SKNK 中文技术指南
什么是 LOA？什么时候需要 BGP 路由授权书？
BGP 路由什么时候需要 LOA（授权书）？它到底证明什么、和 ROA、IRR 有什么区别，以及 SKNK 在什么情况下签发。
路由领域里最容易被误解的文件，LOA 能排进前三。有人追着要，有人一口咬定必须有，还有不少人把它和 ROA、和租赁合同混成一锅。先把最要紧的一句话说清楚，后面大半的疑问都迎刃而解：
LOA 用来记录并证明路由授权。在很多场景中，它本身也可以构成授权文件；但它不是每次 BGP 宣告都必须存在的文件。
你有一个 ASN，也有一个 IPv6 /48。你把这个 /48 从自己的 ASN 宣告给上游。这时候需要 LOA 吗？
大多数情况下，不需要。
LOA 不会让 BGP 跑起来，BGP 也不会去读它。LOA 是一份文件，用来告诉另一个组织："这个 IP 地址资源的控制方，授权了某组织或某个 ASN 去使用、去宣告这些地址。"它是给流程里的人看的，不是给路由器看的。
开篇定义： LOA（Letter of Authorization，授权书）是由 IP 地址资源控制方出具的一份文件，用于授权或确认某个组织或 ASN 被授权使用或宣告某个指定前缀。它属于运营和 onboarding 文档——不是 BGP 协议对象，不是 RIR 资源，也不能替代 ROA、IRR 记录或合同。
LOA 用来记录并证明路由授权，在很多场景中它本身就是授权文件——但它不是每次宣告都必须附上的文件。
1. 什么是 LOA？
LOA（Letter of Authorization，授权书）是一份书面声明，由控制某个 IP 前缀的一方出具，说明某个组织或 ASN 被允许使用或宣告它。
有些供应商用 "Letter of Agency"（代理授权书）而非 "Letter of Authorization"，网络运维里两者都常缩写为 LOA。
有两句话得先说在前面：
- LOA 没有互联网全行业统一的技术格式。 它是运营和 onboarding 文档，不是注册表对象。两家的 LOA 长得完全不一样，干的却是同一件事。
- 读 LOA 的是人。 是上游的工程师、合规团队、网络运维组在审它。它是证据，不是网络会自动执行的信号。
一份好用的 LOA，通常会写清：前缀、被授权组织、被授权的 origin ASN、资源控制方、授权用途、生效日期，以及到期或撤销条件、核验联系人和签名（或其他验证方式）。
BGP 不会读取 LOA。需要读取 LOA 的是网络运营商和服务提供商。
2. 为什么会有 LOA 这种东西？
互联网路由把几个角色拆开了，而人们常常默认它们属于同一个主体：
- 资源持有方——在注册表里控制这个前缀的人；
- 资源使用方——实际上在操作这些地址的人；
- Origin ASN——在 BGP 里起源这条路由的 ASN；
- Transit Provider（上游）——把路由继续传下去的人；
- 路由服务商——如果涉及 DDoS、Anycast 或代管 BGP 的话。
这几个角色不一定是同一家。前缀可能被 A 公司控制、被 B 公司使用、由 C 的 ASN 起源、再经 D 传出去。
LOA 要记录的就是这条链上的一个切片：前缀控制方，授权了某个组织或 ASN 去使用或起源这些地址。
授权关系可以和实际路由路径分开存在；LOA 记录的是把两者连起来的那份许可。
注意这张图里没有 LOA，这是故意的。LOA 描述的那层授权关系，发生在资源持有方和客户之间；LOA 只是把这份授权写下来，供第三方审阅。
3. 什么时候会用到 LOA？
对 LOA 的大部分困惑，都来自把它当成"要么永远要、要么永远不要"的东西。它是分场景的。反复出现的就这几种：
租赁 IPv4 地址
SKNK 控制：
203.0.113.0/24
客户运营：
AS65001
客户想让自己的 ASN 宣告这个 /24。第三方的上游有理由问一句：我怎么知道这个 /24 的持有方允许 AS65001 来起源它？LOA 就是回答这个问题的文件。这也是 IPv4 PA 租赁最典型的场景之一。
授权第三方 ASN 做 Origin
当 origin ASN 属于和资源持有方不同的另一家——DDoS 清洗、Anycast 网络、代管 BGP、云平台、BYOIP 平台——路由就变成这样：
当另一家组织替你起源前缀时，授权边界就变成了一个需要明确处理的运营问题。
资源是你的，origin ASN 是别人的。这种分离正是 LOA 最擅长的记录对象。其中与 Origin ASN 有关的授权，也可以通过 RPKI ROA 表达。资源控制方可以创建 ROA，授权第三方 ASN 起源该前缀。
DDoS 清洗和代管 BGP
清洗服务商、代管 BGP 服务商，是替你把前缀宣告出去的。他们 onboarding 时，往往要一份文件，把你的前缀和他们会用到的 origin ASN 绑在一起。
BYOIP 和云平台
自带 IP（BYOIP）平台让你在别人的基础设施里宣告或使用自己的地址。接入时通常要证明你控制这些地址，LOA 经常就是证明的一部分。
更大的 IPv6 PA 委派
一个标准 /48 是一回事，/44、/40、/36 是另一回事——范围更大、用途更多，授权边界也更值得写成正式文件。
LOA 本身不会取代 RIPE NCC 的地址分配要求。超过 /48 的 PA assignment 仍需要满足相应的地址使用或路由需求，并由 SKNK 审核。
供应商 onboarding 和合规
这里得留一个关键的余地，把文章写得不那么绝对：
即使从路由技术角度不需要 LOA，某个供应商仍可能要求 LOA 来完成它自己的 onboarding 或合规流程。
路由的现实，和供应商内部的 checklist，是两码事。LOA 可能对路由本身毫无必要，但开账户时就是被要求提供。
4. 什么时候不需要 LOA？
最简单、也是 SKNK 客户最常见的情形，是这样：
客户自己的 ASN 起源自己的前缀时，通常没有额外的 Origin 主体需要 LOA 来授权。
客户拿到 ASN sponsorship 和一个 IPv6 PA /48，然后用自己的 ASN 起源这个 /48。这条路径上，从头到尾没有出现新的第三方 origin ASN。
在这个模型里，通常没有额外的路由主体需要通过 LOA 获得授权：
这里没有额外的路由主体需要 LOA 来授权。
这个措辞很关键。它和"不给你 LOA，因为没必要"不一样——它解释的是为什么标准配置里 LOA 没有用武之地。
想快速判断，只问一个问题：这个前缀是不是由你自己的客户 ASN 起源？ 如果是，通常不需要单独的 LOA；如果不是，就需要审核，结果可能涉及 LOA、IRR 或 ROA 变更、附加协议，或者几项一起做。
5. 为什么 SKNK 标准 ASN + IPv6 PA /48 不默认提供 LOA？
这一节是 SKNK 的政策说明，逻辑直接接上一节。
客户买标准服务：
ASN Sponsorship
+
IPv6 PA /48
典型用法：
SKNK IPv6 PA
↓
客户 /48
↓
客户 ASN
↓
BGP
在这个配置里，前缀是哪个、客户是谁、客户的 ASN 是哪个、预期 origin ASN 是哪个，SKNK 都已经清楚——因为客户本来就应该用分配给自己的那个 ASN，去起源分配给自己的 /48。相关的路由信息，可以通过 IRR 和 RPKI 来表达。
因此：
SKNK 对标准的 ASN + IPv6 PA /48 服务，不默认签发单独的 LOA。
客户应当用分配给自己那个网络的 ASN，起源分配给自己的 /48。标准模型里，一份"授权无关 origin ASN"的独立文件，没有可授权的东西。
6. "我的上游是第三方，是不是就需要 LOA？"
不是。这是最容易被误解的一点。
前缀：2001:db8:1234::/48
Origin：AS65001
Transit：AS174
Cogent、Hurricane Electric、Arelion、NTT 这类上游虽然是第三方，但它们做的是 transit——它们传播 AS65001 起源的路由，自己并不成为 origin。
一条宣告给 AS174 再往外传的路由，AS_PATH 大概长这样：
174 65001
Origin——AS_PATH 里最右边那个 ASN——仍然是 AS65001。上游在传播路由，不是起源路由。
使用第三方 transit 供应商，并不自动意味着第三方在起源你的前缀。
Transit 和 Origin 是两个不同的角色。仅仅使用第三方 transit，不会自动产生 LOA 需求；但上游仍可能基于自己的路由审核或 onboarding 流程要求客户提供 LOA。
7. LOA 和 ROA 有什么区别？
这两个被混为一谈的次数最多，但解决的问题不同。
| LOA | RPKI ROA | |
|---|---|---|
| 全称 | Letter of Authorization | Route Origin Authorization |
| 形式 | 一份文档 | RPKI 签名对象 |
| 读者 | 人——供应商、审核、合规 | RPKI validator / 网络运营商 |
| 目的 | 授予或记录授权关系 | 授权某个 ASN 起源前缀 |
| 加密可验证 | 通常没有 | 有 |
| 参与 BGP Origin Validation | 不参与 | 参与 |
| 能否替代合同 | 否 | 否 |
| 能否证明 IP 所有权 | 否 | 否 |
ROA 声明的是：某个 ASN 被授权从特定前缀起源路由，还可以限定允许的最大前缀长度。起源验证真正检查的，是这个 RPKI 对象。
LOA 告诉运营商"什么被允许"。ROA 让这份 origin 授权可以被加密验证。
8. LOA 和 IRR route/route6 object 有什么区别？
再往下拆一层。IRR 的 route object 记录的是路由意图：
route6: 2001:db8:1234::/48
origin: AS65001
它说的是：AS65001 是这个 IPv6 前缀的 Origin ASN。RIPE Database 里的 route / route6 对象，发布的正是这层"前缀 ↔ origin ASN"的关系，很多运营商拿 IRR 数据来生成路由过滤器。
三层排下来是这样：
LOA、IRR 和 ROA 处在不同层次：人读的授权、公开的路由意图，以及可加密验证的起源授权。
别把箭头读成"谁替代谁"。它们解决的是不同的问题。 LOA 用文字记录商业关系；IRR 对象在注册表里发布路由意图；ROA 让 origin 授权能被机器验证。它们不是同一种机制，也不能在所有场景中互相替代。具体供应商可能接受其中一种或几种机制完成自己的路由验证流程。
9. LOA 不是什么？
想给 LOA 划清边界，最快的办法是列它不是什么。
LOA 不是 IP 所有权证明
互联网号码资源不是房产、域名那类普通产权。LOA 记录的是授权，不决定资源最终归谁。
LOA 不是 RIR 分配
LOA 不会在 RIPE Database 里创建任何资源，也不会登记 inetnum / inet6num。
LOA 不是 ROA
一字之差，机制完全不同。LOA 是给人看的文档，ROA 是给 validator 验的签名对象。
LOA 不是 BGP 的硬性要求
BGP 协议本身不要求 LOA。没有 LOA 仍然可以建立 BGP session 和发送 UPDATE，但上游的路由策略或过滤规则可能拒绝相应前缀。
LOA 不是 IPv4 租赁合同
对租地址的人来说，这条尤其重要。租赁合同定义的是商业关系——费用、期限、可接受使用、滥用处理、终止、责任、资源归还。LOA 只承担"授权使用或起源某个前缀"这一件事。这是两份不同的文件，租 IPv4 时你应当预期它们并存。
10. 一份 LOA 应该包含什么？
如果你要起草或审阅一份 LOA，完整的应该写清：
授权方（资源控制方）
被授权方（客户/组织）
IP 前缀
被授权的 ASN
允许的路由用途
生效日期
到期日期（如适用）
撤销条款
关联编号 / 协议号
核验联系人
授权签名
有两条条款值得坚持写进去，它们保护的是资源持有方：
不转移所有权。 本授权不转移底层互联网号码资源的所有权、注册权或控制权。
可撤销。 当底层服务或租约终止时，本授权随之终止。
11. SKNK 在什么情况下提供 LOA？
这是商业规则，用客户最需要的形式写：
| 服务 | LOA |
|---|---|
| ASN + 标准 IPv6 PA /48 | 默认不签发 |
| 更大或额外的 IPv6 PA | 运营需要时提供，需符合分配资格并经过审核 |
| IPv4 PA 租赁 | 提供 |
| 第三方 origin ASN | 审核后提供 |
| DDoS / BYOIP / 特殊路由 | 审核后提供 |
IPv4 租赁场景下，完整的链条是几份文件协同：IPv4 租赁协议、LOA、IRR route object、RPKI ROA。
12. 如果第三方要求 LOA 怎么办？
别把这当成死路。正确的做法是把路由安排发给 SKNK，让它被审一遍。
发过来：
前缀
请求的 origin ASN
第三方供应商
用途
如有要求的具体措辞
SKNK 会核对这份安排是否已被现有分配覆盖，再判断到底需要什么。
一次把路由安排说清楚，就能判断到底该补哪份文件或哪项注册表变更。
这样能把原本来回解释的 support ticket，变成一个一次就能审完的请求。
FAQ
宣告我的 SKNK IPv6 /48 需要 LOA 吗？
标准的 ASN + PA /48 服务：通常不提供、也不需要单独的 LOA。你用分配给自己的 ASN 起源分配给自己的前缀。
上游需要被写进 LOA 吗？
标准 transit 不需要把上游作为被授权的 Origin ASN。上游只是传播路由；但供应商仍可能要求 LOA 作为路由授权或 onboarding 的证明材料。
别的 ASN 能起源我的前缀吗？
需要提前授权，而且路由记录要匹配。通常意味着 LOA 加上匹配的 IRR 和 RPKI 配置。
LOA 和 ROA 是一回事吗？
不是。LOA 是给人看的文档，ROA 是起源验证会检查的加密签名对象。
LOA 能证明我拥有这些 IP 吗？
不能。它记录的是授权，不是所有权，也不是注册归属。
如果供应商明确要求，SKNK 能提供 LOA 吗？
更大的 IPv6 PA、IPv4 PA 租赁、第三方 origin 或其他特殊路由安排，可以根据路由安排和 SKNK 的审核结果提供。
结尾
不是每条路由都需要一封信。
LOA 的价值，在于需要向第三方证明路由授权关系时派上用场；它不是贴给每一条 BGP 宣告的必备文件。
SKNK 标准 ASN + IPv6 PA /48 服务采用简单的路由模型：客户用自己的 ASN 起源分配给自己的前缀，因此不默认签发单独的 LOA。更复杂的安排——IPv4 租赁、更大的 IPv6 委派、第三方起源——可以根据实际需求提供额外的授权。
Key Takeaways：
- LOA 记录并证明路由授权——在很多场景中它本身就是授权文件；它也不是每次宣告的必备文件。
- BGP 不读 LOA——读它的是网络运营商和 onboarding 团队。
- LOA、IRR route object 和 ROA 解决不同问题；具体供应商可能接受其中一种或多种机制完成路由验证。
- Transit 不是 Origin：用第三方上游，不代表第三方在起源你的前缀。
- SKNK 对标准 ASN + IPv6 PA /48 不默认签发 LOA；IPv4 租赁、更大 IPv6 PA、第三方起源等场景可提供。
一句话总结： LOA 记录的是"前缀控制方授权了某个 ASN 去起源它"——它不是 BGP 硬性要求、不是所有权证明、也不是 ROA——所以 SKNK 标准 ASN + IPv6 /48 默认不需要，而 IPv4 租赁、第三方起源和其他特殊路由安排则是常见的 LOA 使用场景。
继续阅读：
- 什么是 ROA？ —— 授权 origin ASN 的加密签名对象，以及
maxLength为什么重要。 - 什么是 IRR Route Object？ —— 记录"前缀 ↔ origin"路由意图的注册表对象。
- RPKI vs. IRR —— 两套描述路由的体系，各自的位置。
- 如何租用 IPv4 地址 —— LOA 最常出现的租赁场景。
- 怎么通过 BGP 宣告 IPv6 /48 —— IPv6 世界里同一条"起源 → 授权 → 接受"链路。
- SKNK IPv4 租赁 —— 租赁协议、LOA、IRR、ROA 怎么协同。
技术资料核对： RIPE NCC RPKI 与 ROA 说明、RIPE Database route/route6 对象文档、RFC 9582（ROA Profile）、RFC 5737（IPv4 文档地址段）、RFC 3849（IPv6 文档地址段）。